[HN Gopher] Tell HN: GitHub will delete your private repo if you...
___________________________________________________________________
Tell HN: GitHub will delete your private repo if you lose access to
the original
I was surprised to see this in my email today: > Your private
repository baobabKoodaa/laaketutka-scripts (forked from
futurice/how-to-get-healthy) has been deleted because you are no
longer a collaborator on futurice/how-to-get-healthy. That was an
MIT-licensed open source project I worked on years ago. We
published the source code for everyone to use, so I certainly did
not expect to lose access to it just because someone at my previous
company has been doing spring cleaning at GitHub! I had a 100%
legal fork of the project, and now it's gone... why? Turns out I
don't even have a local copy of it anymore, so this actually caused
me data loss. I'm fine with losing access to this particular
codebase, I'm not using HN as customer support to regain access. I
just wanted everyone to be aware that GitHub does this.
Author : baobabKoodaa
Score : 189 points
Date : 2023-01-31 19:56 UTC (3 hours ago)
| csteinbe wrote:
| This is documented at: https://docs.github.com/en/pull-
| requests/collaborating-with-...
| fragmede wrote:
| "But the plans were on display..."
|
| "On display? I eventually had to go down to the cellar to find
| them."
|
| "That's the display department."
|
| "With a flashlight."
|
| "Ah, well, the lights had probably gone."
|
| "So had the stairs."
|
| "But look, you found the notice, didn't you?"
|
| "Yes," said Arthur, "yes I did. It was on display in the bottom
| of a locked filing cabinet stuck in a disused lavatory with a
| sign on the door saying 'Beware of the Leopard."
|
| -- Douglas Adams, The Hitchhiker's Guide to the Galaxy
| agolio wrote:
| To clarify the appropriateness of this analogy:
|
| This is unexpected behaviour from Github here which may (and
| has, by the anecdote of OP) cause permanent data loss.
| Documentation is not good enough, as users should not have
| been expected to have read the entire documentation.
| Barrin92 wrote:
| I don't think it's an unexpected at all given that the
| original repo was private, not just the fork. Secondly a
| GitHub "user" isn't really a user in the consumer sense.
| They're a developer, as a developer/professional you can be
| expected to consult the documentation of a tool you use so
| you understand default behavior.
| chrisfosterelli wrote:
| I guess this is a question of who should have been given
| further information. For example, whoever at the
| organization deleted the repo would have been given a very
| clear warning screen including the number of forks that
| would be deleted by their action prior to them doing it.
|
| On that note, an organization admin can _directly_ delete
| your private fork without even deleting the source
| repository if they want. GitHub's permission model is
| fairly direct that private forks you make through your
| membership in an organization are more the organization's
| property than the forker's.
| capableweb wrote:
| > I guess this is a question of who should have been
| given further information. For example, whoever at the
| organization deleted the repo would have been given a
| very clear warning screen including the number of forks
| that would be deleted by their action prior to them doing
| it.
|
| This is exactly how it works today already. If I try to
| delete a private repository people have forked, I see the
| following:
|
| > We will also delete all 4 forks since this is a private
| repository.
|
| Clicking on the delete button, again:
|
| > Unexpected bad things will happen if you don't read
| this!
|
| > This will also delete all 4 forks since this is a
| private repository.
|
| > [type name of repository]
| chrisfosterelli wrote:
| Yes, that's what I said. It sounds like the parent poster
| is suggesting that the fork account should instead have
| that notice.
| themitigating wrote:
| Is it unexpected though? The repo was forked from an org by
| the person who was a member of that org.
|
| I know this isn't common but I actually use a unique user
| for my company "myname-company"
| darekkay wrote:
| That's why I usually don't use the official "fork" feature, but
| clone and push the repository manually instead. I would like to
| keep the fork network connection on Github, but I don't want to
| see my fork deleted because of an error, malice or simply lack
| of knowledge.
| devmunchies wrote:
| Same. Another reason is I don't like how Github inserts
| "Forked from ..." in the project name. If your "fork" becomes
| extremely divergent after a couple years (maybe you had a
| different vision for the project), you are still stuck with
| the "Fork from..." sub-header, which basically tells users
| that they should look at the original. I'm otherwise fine
| putting attribution in a README.
| rezonant wrote:
| It will only be deleted if the repo you fork from is a
| private repository. The documentation [1] covers the other
| scenarios, in all of which you keep your copy of the code
| (including when the public repository is made private later).
|
| [1] https://docs.github.com/en/pull-requests/collaborating-
| with-...
| darekkay wrote:
| TIL, thanks! I probably confused this with the GitHub
| takedowns, when forks are removed as well (as it happened
| to the youtube-dl repo). I could imagine my manual clone
| not withstanding such takedown either, though.
| rezonant wrote:
| Yeah for cases like that, keep a local copy, thankfully
| many people did
| andyjohnson0 wrote:
| > It will only be deleted if the repo you fork from is a
| private repository
|
| This makes sense. Thank you for clarifying that important
| detail. It seems to be missing from the parts of the
| discussion I've read here.
| TheRealPomax wrote:
| No, it doesn't. It only makes sense until you stop and go
| "Wait, no, hold on a minute. Why would they _delete_ the
| fork instead of simply severing the fork relation in
| their fork relations table? ".
| remram wrote:
| What if the original is made private and then deleted? Does
| your fork remain?
| tux3 wrote:
| I think this is under the assumption of "employee has a private
| fork of the company repo, then leaves, employee should not keep
| the fork"
|
| So when "removed as a collaborator" which apparently includes the
| original being deleted, you lose access to the main repo and all
| forks, even yours. As if leaving a company.
| jiggawatts wrote:
| Microsoft does this a lot, where they assume that rules that
| apply to their own organisations apply to _all_ organisations
| in precisely the same way.
|
| If a Microsoft IC leaves, they _should_ lose access to all Git
| repos, including forks.
|
| If Joe Random open-source contributor is removed from an open
| source repo's access list, their fork shouldn't be wiped.
|
| But Microsoft has One Rule To Rule Them All, so they won't make
| exceptions for unimportant people like their customers.
|
| I see this a lot. A good example is Azure Active Directory,
| which is basically "Microsoft 365 Authentication" that they
| rebranded and sold to developers for their own use, i.e.: Azure
| AD Enterprise Apps, App Registrations, and B2C.
|
| There are many aspects of the AAD design that make zero sense
| until you pause for a second and realise that it is _not
| designed for you_. It 's designed for Microsoft 365!
|
| For example, auditing. My customers are typically government
| agencies or banks, and they have _strict_ auditing
| requirements, especially related to data access. All user
| authentication MUST be logged, including client IP address, and
| everything else. Most such as access is by their own staff, or
| by other orgs that have signed various contracts or agreements.
|
| This is basically impossible with many configurations of AAD.
| It just _refuses_ to collect meaningful audit logs. Why?
| Because GDPR applies to Microsoft 365 and they don 't _care_
| about the data hosted on services such as SharePoint Online.
| That 's not Microsoft's data, that's their customers' data, so
| its up to the customers to enable logging "on their end", in
| their individual AAD tenants.
|
| There is no way to centrally collect logs as a service provider
| using AAD in a multi-tenant scenario.
|
| When I asked Microsoft about this, they waffled on about GDPR
| and privacy regulations -- which apply to them, _but not us_.
| evouga wrote:
| This doesn't make any sense to me.
|
| My private forks are * _mine*_ and I most certainly do not want
| GitHub guessing at whether and when to permanently delete them
| without my consent.
|
| Companies of course have the right to manage access to their
| proprietary source code, for example by only giving access to
| corporate accounts under their control and reclaiming those
| accounts when an employee leaves.
| nly wrote:
| What's the point? You can always clone locally and push to a
| new repo without forking on GitHub. Repos will be unlinked and
| history will be intact.
| chrisfosterelli wrote:
| It's for the same reason that you don't leave ex-employees
| with access to other intellectual property. Just because they
| could make their own copies during their tenure doesn't mean
| you shouldn't try to reduce your exposure.
| charcircuit wrote:
| Github knows the license of projects. It knows if you forked an
| open source project.
| jzb wrote:
| It knows the license applied to the repository. For a private
| repo it may not be "released" under that license but planned
| for release.
|
| If AcmeCorp is planning to release - but hasn't - a project
| under MIT or whatever, they may have the license declared in
| the repo but that's not a guarantee it's ever going to be
| released.
|
| If it's a private repo, and your access has been under your
| status as an employee, then I don't know that counts as
| distributed to you under that license. If AcmeCorp later
| decides to change licenses or not release the software as
| open source, then it makes sense for GitHub not to let
| someone continue access.
|
| There are a LOT of holes in the system, but I'm not sure
| GitHub is in the wrong for deleting access to a private repo
| if you lose access to an organization or whatever.
| chrisfosterelli wrote:
| Yeah I understand how this is unfortunate but for 99% of cases
| this is what you want to happen when you remove someone's
| access to a private codebase.
|
| It seems like this is an unusual use case that OP had an MIT-
| licensed open source project whose source only exists in a
| private repo.
| Sephr wrote:
| GitHub also blocks their built-in fork UI functionality when the
| original repo's owner uses the site's "block" feature against
| you, which doesn't align with my expectations. Ironically, anyone
| affected by this poorly implemented blocking behavior (and
| thereby copying the full repo instead of forking) would be
| protected from this bug by the OP.
| smeagull wrote:
| This destroys the very basic idea of opensource. That the first
| developer on a project can hand off to someone else to take over
| the project, and have the project continue past their
| involvement.
|
| Now if the first developer deletes their account or repo
| everything dies.
| glitchc wrote:
| Do you have a local clone? If yes, just populate a new remote
| with the local clone. If not, always a good idea to keep an
| updated clone of every remote repo. That's how git is supposed to
| work. The latest pull is the backup.
| j45 wrote:
| Looks like a gitlab.com backup of everything is mandatory.
| amelius wrote:
| Why a mail saying that something was deleted instead of a warning
| that something _will be_ deleted??
| shagie wrote:
| If you worked at a company and had a fork of a private repo
| that company maintained of some software... do you want
| employees who have left to have their access to the repos
| removed? or an email that says that it will be removed?
| amelius wrote:
| I'd prefer it if the repo was returned to the company, rather
| than removed.
| shagie wrote:
| That gets complicated. It's in (for example) my namespace.
| So shagie/foo.git
|
| And now you want to return it to BigOrg/foo.git - where
| does it go in that namespace of BigOrg? What are the
| permissions for who should have access to that? Who gets
| billed with a scheduled action runs and chews up a lot of
| CI credits as a parting gift?
|
| The workflows for anything other than "delete it" gets
| GitHub in a bit of a mess.
| kitkat_new wrote:
| one of many scenarios in which it is probably(!) desirable to
| revoke access.
|
| What about other scenarios?
| xigoi wrote:
| What prevents them from having the code locally?
| shagie wrote:
| Same nothing that prevents a person from copying it onto a
| USB stick before they leave.
|
| However, that's not GitHub's problem. GitHub is "told" (by
| removing the person's access from the repo) that they
| shouldn't have access to the repository or its code. It is
| within GitHub's ability to remove access to their fork and
| remove it.
| filoleg wrote:
| > What prevents them from having the code locally?
|
| Likely lack of initial intent and effort.
|
| Just like having firewalls and the most recent security
| updates doesn't mean that you are inpenetrable. After all,
| the most common attack vector is the good old phishing
| email tactics and other ways of social engineering someone
| anyway. However, it doesn't mean that you shouldn't have a
| firewall (or other ways of defending your server) or that
| you should neglect timely security updates.
|
| There are layers to this. Sure, someone who had an intent
| to do it from the start could've cloned the repo locally
| ahead of time. But for a lot of people it could be a crime
| of opportunity. Or it could also be that their account with
| access to the fork on github gets compromised later and a
| malicious third party got access to it.
|
| My point is, having this restriction on forks won't prevent
| a determined attacker from getting it preserved locally
| ahead of time, you are correct. But it will prevent a lot
| of other unwanted scenarios that could result from not
| having the current restriction on forks of repos that went
| private.
| thewellington wrote:
| I wonder if this works the other way around. - create new repo in
| your personal GitHub acct. - fork it to company repo. - leave
| company years later - revoke access to company codebase. :)
| Alex3917 wrote:
| Thanks for the heads up, this is pretty nuts.
| josephcsible wrote:
| Never use the fork feature on private repos. Instead, clone the
| repo locally, create a fresh GitHub repo, and push your local
| clone manually to that. Doing so will protect you from this
| attack.
| theossuary wrote:
| It'd be nice to be able to manually specify an upstream for a
| repo, that's the main benefit of forking in the UI.
| pvaldes wrote:
| Totally expected from the minute one after Microsoft buy the
| vault, earning full control over the software and the people's
| access to the platform. I will not be surprised at all if some of
| this closed projects would appear included into closed software
| under new authors after a year.
| capableweb wrote:
| Is this behavior new? It has been like that for as long as I
| can remember, certainly before Microsoft bought GitHub.
| autophagian wrote:
| It is not. I also remember this behavior around forking
| private repos from before the acquisition. But then again,
| this doesn't lend itself to a conveniently pithy comment
| about Microsoft ruining everything.
| IncRnd wrote:
| > Your private repository baobabKoodaa/laaketutka-scripts (forked
| from futurice/how-to-get-healthy) has been deleted because you
| are no longer a collaborator on futurice/how-to-get-healthy.
|
| > and now it's gone... why?
|
| Because it was a private not a public repo.
| kitkat_new wrote:
| so what?
|
| Private doesn't imply (common sense) that the original
| repository has power over any fork.
| dboreham wrote:
| It does, otherwise github just wouldn't allow forking private
| repositories. If they did allow that, and retained no control
| over the forked copy, now you can ride a coach and horses
| through the access control to a private repo by simply
| forking it when you have access. My guess is that forking a
| private repository is a feature github intended to be used
| where employees or contractors of an enterprise want to fork
| their _employer 's_ repository as part of their development
| activities for that employer. Github sees those forks as
| transitively controlled under the organization's access
| policies.
| zxcvbn4038 wrote:
| I have a number of git repos that the original developers deleted
| - because I sync'd them to a usb stick with gitea. I think that
| is how you have to do it - never entrust a service, especially a
| free one, with your only copy of anything you value.
|
| If the YouTube algorithm nukes your account and all your videos,
| you should be ready to upload them to a new account. Same with
| anything else digital.
|
| My current is standard is one copy in AWS S3 which is super
| reliable but too pricy for daily use, and one copy in Cloudflare
| R2 or Backblaze B2 which might or might not be reliable (time
| will tell) but is hella cheap for daily use.
| stuaxo wrote:
| Wonder if any data hoarders have made scripts to clone every
| site you have started on GitHub?
| wjdp wrote:
| For this I have a NAS with a pretty basic script that runs
| nightly to clone any new repos I have and update those already
| backed up. They get organised into a directory structure
| mirroring that of Github: `./github.com/user/repo`
|
| If of any use to anyone else:
| https://gist.github.com/wjdp/a20cb15f76b651124b3b27cde06d121...
| capableweb wrote:
| > because I sync'd them to a usb stick with gitea
|
| Just a tip: no need to use gitea if you want to replicate a git
| repository to somewhere else on disk/other disk.
|
| Just do something like this: mkdir
| /media/run/usb-drive/my-backup-repo (cd /media/run/usb-
| drive/my-backup-repo && git init) git remote add backup
| /media/run/usb-drive/my-backup-repo git push backup
| master
|
| And now you have a new repository at /media/run/usb-drive/my-
| backup-repo with a master branch :) It's just a normal git
| repository, that you also can push to over just the filesystem
| josephg wrote:
| Even better with cd /media/run/usb-
| drive/my-backup-repo && git init --bare
|
| Bare repositories don't have a working directory. You can
| still git clone / git pull from them to get the contents. You
| can also git push to them without clobbering any "local
| changes" (there aren't any).
|
| More detail here:
|
| https://www.atlassian.com/git/tutorials/setting-up-a-
| reposit...
| capableweb wrote:
| Yeah, better in terms of saving space, but I think it
| confuses some people, hence I didn't use it in my above
| example. Previous time I recommended a co-worker to use the
| `push to a directory` way of copying a git repository, I
| made them create a bare repository, and they ended up going
| into the directory to verify it worked and not seeing what
| they expected. Cue me having to explain the difference
| between a normal repository and a bare one. It also
| confused them into thinking that a bare repository isn't
| just another git repository but a "special" one you can
| sync to, while the normal one you couldn't.
|
| So in the end, simple is simple :) Unless you're creating
| remote repositories at scale, you probably won't notice a
| difference in storage usage.
| josephg wrote:
| I hear all that, but --bare is necessary in this case
| because git (by default) won't let you push to a non-bare
| filesystem branch: ~/temp/a:master $
| git push backup Enumerating objects: 3, done.
| Counting objects: 100% (3/3), done. Writing
| objects: 100% (3/3), 212 bytes | 212.00 KiB/s, done.
| Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
| remote: error: refusing to update checked out branch:
| refs/heads/master remote: error: By default,
| updating the current branch in a non-bare repository
| remote: is denied, because it will make the index and
| work tree inconsistent remote: with what you
| pushed, and will require 'git reset --hard' to match
| remote: the work tree to HEAD. ... To
| ../b ! [remote rejected] master -> master (branch
| is currently checked out) error: failed to push
| some refs to '../b'
| dabber wrote:
| You can even take it a step further and have a push to origin
| update your backup as well.
|
| https://stackoverflow.com/a/14290145
| capableweb wrote:
| > In recent versions of Git you can add multiple pushurls
| for a given remote
|
| Woah, that's really cool, didn't know about that. This is
| really useful! Thanks for sharing that.
| benatkin wrote:
| Have you tried running gitea? It's very light on resources,
| has good documentation, and also defualts to a _main_ branch.
| It 's also very easy to control where all the data is stored,
| and works well w/ sqlite.
| simcop2387 wrote:
| The biggest reason to do this is thah it supports "mirror"
| repositories where it will keep your copy up to date, even
| using github keys to get at a private repo if you want.
| benatkin wrote:
| Yes, and if you stop the process and start it again,
| gitea doesn't complain and picks up right up where it
| left off. Ditto if you lose internet connectivity. It's a
| well-designed piece of software. I considered using it as
| a BaaS and am actually thinking again of using it as one.
| capableweb wrote:
| Yes, I've tried it (and actually run a personal instance
| myself), but I would never try to run an application meant
| as an webapp when I want to copy something from one
| filesystem to another, when git can do it already without
| any external programs.
|
| Also, the `master` is just an example, it works for `main`
| as well, don't worry :) The created git repository on your
| usb-stick works like a regular git repository, you can use
| whatever branch names you want.
|
| Btw, way to focus on the absolutely least interesting part
| of my comment, what I chose to name the branch...
| tryauuum wrote:
| Is the "main" branch an advantage? I guess only if >50
| percent of your repos use "main" branch
| benatkin wrote:
| It makes more sense. The use of the default branch varies
| greatly. Some use it as development and some use it as
| production. Main is less specific. Master, besides its
| negative connotation, seems to be linked with shrinkwrap
| software. https://en.wiktionary.org/wiki/master_copy
|
| It's also two less characters and one less syllable.
| [deleted]
| no_butterscotch wrote:
| > If the YouTube algorithm nukes your account and all your
| videos, you should be ready to upload them to a new account.
| Same with anything else digital.
|
| Do you know if this is a common occurrence?
|
| Also, I'm only a YouTube viewer and am not familiar with all
| the creator tools, problems, communities, etc. But would a
| creator really re-upload _all_ their back-catalog if deleted?
| Just to try to get back to views and things?
| MonkeyMalarky wrote:
| There were a whole bunch of artist and genre specific mixes I
| used to listen to on yt that are gone now. The uploaders
| accounts have all been nuked too. The sad thing is I can
| listen to it all on Spotify but it's not the same.. the
| creator's did not insignificant work to mix the songs
| together.
| ChrisMarshallNY wrote:
| I remember someone posting an agonized screed, some time ago,
| about YT deleting their channel, and all the videos.
|
| Apparently, they had not kept the source/rendered originals
| of the videos, so it actually clobbered their business.
|
| I am a scarred, limping old coot, and have learned [the hard
| way] that backups are _goooood_.
| tpxl wrote:
| A few weeks ago, youtube changed their swearword policy. A
| creator I follow basically had to delete half their channel
| or risk termination.
| sidewndr46 wrote:
| I'm reasonably certain that if YouTube deletes your account
| uploading them to a new account is expressly forbidden.
| Gordonjcp wrote:
| How exactly can they stop you?
| yunohn wrote:
| What do you mean? They have extensive content ID/checks.
| Gordonjcp wrote:
| Post it somewhere else. Youtube is largely a waste of
| time, unless you're some right-wing idiot scamming money
| out of teenagers.
| j45 wrote:
| I've read having a secondary test account to post videos
| under to pass YouTube scans before posting to the real
| account helps minimize issues.
| mattl wrote:
| Your fork wasn't public?
| baobabKoodaa wrote:
| Correct.
| rezonant wrote:
| I have to assume that the original repository was private when
| you forked it. If it was public, and then made private, then this
| should not happen.
|
| If the original code was "open source", then why exactly was it
| in a private repository? Putting "MIT licensed open source" into
| a private repository is not publishing that source code for the
| world to use.
|
| It sounds like nothing weird happened here other than this
| company thinking a private repository was "publishing it as open
| source".
| baobabKoodaa wrote:
| > If the original code was "open source", then why exactly was
| it in a private repository?
|
| It's been too many years to remember the exact reasons, but
| this was not the only repo in the project. This was the
| "working directory" that had all kinds of random stuff that a
| data science project might accrue over time. Later in the
| project we published 3 repos which were more "cleaned up" to be
| potentially useful to outsiders (I use scare quotes around
| "cleaned up" because the codebases are still a mess, sorry).
|
| Anyway, 3 of the 4 repos appear to still be public:
|
| https://github.com/futurice/health-visualizations
| https://github.com/futurice/health-visualizations-front
| https://github.com/futurice/laaketutka-prereqs
| chrisfosterelli wrote:
| It would have had to be privately forked. If you change your
| repository from public to private, GitHub detaches the forks
| and leaves them public, so a repo owner can't just delete
| someone's public fork.
| bastardoperator wrote:
| It's not your code or data, it's your previous employers IP and
| they determine who has access and who doesn't and what licenses
| do or don't apply. Forks have worked like this for awhile and I
| consider it a feature, especially in cases like this.
| baobabKoodaa wrote:
| That's not how MIT license works
| camsjams wrote:
| So you're suggesting GitHub should determine the total
| "average" license of a private repo and determine if your
| fork is indeed valid or not, before revoking access.
| camsjams wrote:
| Instead, you might just want to reach out and ask for
| access or a zip file from the owners
| baobabKoodaa wrote:
| > So you're suggesting GitHub should determine the total
| "average" license of a private repo and determine if your
| fork is indeed valid or not, before revoking access.
|
| No, I'm not suggesting that. In fact, I didn't say anything
| about what GitHub should or shouldn't do. My comment
| related to how licenses work, not how GitHub works or
| should work.
|
| In particular, I was responding to this comment:
|
| > It's not your code or data, it's your previous employers
| IP and they determine who has access and who doesn't and
| what licenses do or don't apply.
|
| The claim in the above comment is incorrect. I stated that
| the claim is incorrect. That is unrelated to the issue of
| how GitHub should deal with private repo forks.
| pavon wrote:
| You mentioned in another post that the company only
| released a cleaned up version publicly. That cleaned up
| code which they published is clearly and unambiguously
| under the MIT license. Any other modifications that were
| made and not published (including any you made in your
| fork as an employee) are not automatically licensed as
| MIT. Your employer holds the copyright to that. They
| might be fine with those internal changes being released
| as MIT or they might not, but it is up to them.
| [deleted]
| bastardoperator wrote:
| No, but that's how private repos work. It's really hard to
| open source code from a repo no one has access to.
| Encrypt-Keeper wrote:
| Self hosting something like Gitea and mirroring to that is a good
| solution to this.
| sbierwagen wrote:
| Is futurice/how-to-get-healthy a public repo? It's not visible on
| https://github.com/orgs/futurice/repositories
|
| If you fork a private repo and they remove you from the
| collaborators list, it's reasonable that your fork would be
| removed.
| baobabKoodaa wrote:
| Well, it's not reasonable to me, but we'll just have to
| respectfully disagree on this.
| IncRnd wrote:
| It probably seems more reasonable to the people who own the
| repo.
| baobabKoodaa wrote:
| I don't think the people who removed my access had any
| intention of deleting private repos. It's just somebody
| cleaning up ex-employee access from GitHub.
| bspammer wrote:
| Pretty bizarre behaviour given how easy it is to get around this.
| Instead of forking, just
|
| git remote set-url origin <new-remote-repo>
|
| The new remote can even still be on GitHub. So what's the point?
| Anyone relying on this to retroactively remove access to source
| code has a false sense of security.
| Dork1234 wrote:
| Does it go into GitHub Desktop and remove it from your computer
| as well?
| bdcravens wrote:
| I'm sorry to hear that whoever trained you on using Github didn't
| explain this to you.
| [deleted]
| gregwebs wrote:
| This unfortunately makes sense because it is a private repo. Even
| if a repo is labeled as being MIT and has an MIT license in it,
| it still may contain other code of a different license.
|
| Github could do better by warning the repo owner when they delete
| a private repo. Github could ask the repo owner if they want to
| convert it to public first (a "set it free" option) or otherwise
| give the option to avoid deleting the forks of others.
| kitkat_new wrote:
| "This unfortunately makes sense because it is a private repo."
|
| I disagree. I expect a (i.e. my) fork to be independent of the
| original repository, no matter if it is private or not.
|
| It's enough if a fork of a private repository is private then
| too.
| bcrosby95 wrote:
| This is why I don't use github's fork feature. There's more
| than just this restriction they impose upon you.
|
| Instead I prefer to use a "git" fork. I just clone it and
| upload it to my own repo. Assuming the license permits of
| course.
| dreamcompiler wrote:
| This is the right answer: Break the fork link. I sometimes
| do this to make a private "fork" of a public repo so that I
| can add my own notes about how to use it, remind myself
| what happened when I tried it, add a config script for my
| own peculiar setup, etc.
|
| It's unfortunate because not having a "real" fork makes it
| harder to send pull requests and track the upstream. But
| it's sometimes necessary to get around stupid github
| policies.
| ntrz wrote:
| Don't you need to have an "GitHub-approved" fork (i.e. use
| the GitHub fork button) if you want to create pull requests
| on the upstream project in GitHub? Or is there a way to do
| that from the kind of repo you're describing?
| edaemon wrote:
| If that came up you could create a GitHub-native fork and
| add that as a remote.
| Mystery-Machine wrote:
| GitHub is not supposed to make such decisions for the user
| here. It is user's responsibility to make sure they delete
| their private forks if they shouldn't have access to the
| repo/fork anymore.
|
| What's next? Should we all install spyware on our computers and
| let GitHub automatically delete local copies of forks as well?
|
| GitHub and the company/person, who deleted the original private
| repo, should inform the owner of the fork that the main repo
| was deleted. If need be, company/person can request fork owner
| to delete their private fork and local clone as well.
| pavon wrote:
| I think this incident reinforces that private repos on
| github.com are a weird hybrid of the public github and on-
| premise github which creates various practical problems and
| misunderstandings when those two security models collide.
|
| First off is the fact that forking a repo is often a
| necessary step in contributing to project if you don't have
| push permission, so these forks will be created during the
| normal development processes, not necessarily because the
| employee was intentionally trying to save off their own copy.
| So it is perfectly normal for the employer to consider those
| forks to be something it should own and manage, just like it
| would on an on-premise installation.
|
| On the otherhand, github still encourages people to use a
| single account for both personal use and work[1]. Naturally
| the employees reasonably consider all the forks that are in
| their personal account to be something that they should own
| and manage. So you end up with situtations like this.
|
| The lesson - mixing work and personal
| accounts/computers/devices is a horrible idea regardless of
| what Github says. Employers shouldn't allow it, and employees
| should avoid it even if allowed. Then both will have a clear
| idea of who owns and controls what.
|
| [1] https://docs.github.com/en/get-started/learning-about-
| github...
| pavon wrote:
| Yes, and under most FLOSS licenses (including
| BSD/MIT/LGPL/GPL/AGPL), companies are perfectly free to
| maintain modified versions of the software internally with no
| obligation to publish the source externally, until/unless they
| distribute the modified software externally (or allow external
| use the software remotely in the case of AGPL). All of the
| modifications are copyright the company and it is their choice
| whether to release them publicly. Employees having access to
| the modifications doesn't mean that the modifications have been
| licensed to them under the original license, and thus doesn't
| give them permission to distribute the modified software to
| others under that license.
|
| Essentially what I just said is the same as what you did. The
| private modifications cannot be assumed to be under the same
| license as the original software. Gitlab has no way of knowing
| all these details, and have promised to keep private repos
| private, so their current policy is the correct one.
| nobody9999 wrote:
| I completely understand your frustration. It's a dick move to
| delete your content without (at least) giving you a chance to
| archive that work.
|
| At the same time this situation points up an important issue: if
| you don't own/control the infrastructure where your data lives,
| you don't own that data. Full stop.
|
| If you host your data "in the cloud" (i.e., on _someone else 's
| servers_) then you don't own that data, or at least not any
| copies stored there).
|
| I'm not advocating for any specific action/solution in this
| comment (see my comment history for more about centralization vs.
| decentralization and "the cloud"), but the above is an important
| consideration, especially WRT long-term storage of your data.
| kaushikc wrote:
| It's simple! Maintain the control and the capability to
| retrieve your important data at all times. The internet is a
| wild place and everything you don't save could potentially be
| gone forever.
| nobody9999 wrote:
| >It's simple! Maintain the control and the capability to
| retrieve your important data at all times.
|
| An excellent point, but I'd go further and say that one
| should maintain multiple copies of important data, with at
| least one of those on hardware/infrastructure you control
| _and_ have physical access to.
| bdowling wrote:
| GitHub probably does this to protect itself from potential
| copyright claims by the copyright owner. In most cases, copyright
| owners will want Github to stop distributing copies of their code
| to people whose access they revoked. They won't care whether the
| copies are in a fork or not. If Github didn't revoke access to
| the code, including in forked repos, then the copyright owners
| could send DMCA takedown notices and potentially sue Github.
| Processing those takes time and money, so they do the easier and
| cheaper thing.
___________________________________________________________________
(page generated 2023-01-31 23:00 UTC)