6 ms·

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 cod

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.

pavon 4y ago
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.
kitkat_new 4y ago
"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 4y ago
  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.
  - ntrz 4y ago
    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 4y ago
      If that came up you could create a GitHub-native fork and add that as a remote.
  - dreamcompiler 4y ago
    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.
- naikrovek 4y ago
  Don't use the "Fork" button in the GitHub UI, then. It is intended for collaboration and establishes and maintains the parent-child relationship of "your fork" and if the parent repo is deleted, so are all forks. If the parent repo is private and goes public, so do all forks. If the parent repo is public and switches to private, so do all forks. This behavior is laid out in docs.github.com and is not secret. This has been the case on github.com for over a decade, and I am slightly shocked that people don't know this. I guess the root of that is that I am surprised that this has not bitten more people than it has. People assuming things are a certain way and never checking to verify that are by far the greatest source of "I shot myself in the foot" statements that will ever be known.
  - kitkat_new 4y ago
    "If the parent repo is private and goes public, so do all forks." nope, that's not true: "GitHub will detach private forks and turn them into a standalone private repository. For more information, see "What happens to forks when a repository is deleted or changes visibility?"" " If the parent repo is public and switches to private, so do all forks." This isn't true either: "GitHub will detach public forks of the public repository and put them into a new network. Public forks are not made private." In these cases, exactly what I would have expected happens.
    - naikrovek 4y ago
      yep I was wrong about that point. generally my point still stands; if you want total control over your repo, don't use the GitHub "Fork" button to create your repo for that code. I linked directly to the documentation about "Fork" in another comment.
  - mattigames 4y ago
    That would make sense if they didn't use the word "fork" for it, that words has a specific meaning when talking about repositiories[0] and it doesn't include a automatically propagating deletions or settings of the original repo, it doesn't actually include ANY automatic propagation, therefore GitHub should use a different word for this kind of fork, something like "Crate child fork" or "Linked fork" or maybe a new word altogether [0] http://www.freekb.net/Article?id=1263 http://www.freekb.net/Article?id=1263
Mystery-Machine 4y ago
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 4y ago
  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/types-of-github-accounts#personal-accounts https://docs.github.com/en/get-started/learning-about-github...
  - geraldwhen 4y ago
    Enterprise Managed Users solves the issue.
- jyrkesh 4y ago
  MIT licensed code doesn't mandate distribution. Companies and organizations are perfectly within their rights to own a private fork of an MIT-licensed codebase in perpetuity. With that in mind, if you fork an organizationally-managed repository, there's a good chance the owner doesn't want you to continue to have access to that codebase if you're no longer a part of the organization. And the local copy? Well there's a good chance you were only allowed to clone the repo on an IT-managed device with specific 2FA policies and some kind of agent/config to prevent/reduce data exfiltration from that device. Is it a perfect system? Hell no. Data leaks, that's part of life. And I'm with you that it certainly could be more user-configurable. But it's also extremely well-documented behavior[1], and seems like a key design choice that GitHub made a long time ago to protect the owners of private repos. Ultimately, if you don't care about who has access to your code, you signal that by making the repo public. Or by telling your private collaborators to make sure they hold on to a local copy. [1]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility https://docs.github.com/en/pull-requests/collaborating-with-...

pavon 4y ago

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.

kitkat_new 4y ago

"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 4y ago
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.
- ntrz 4y ago
  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 4y ago
    If that came up you could create a GitHub-native fork and add that as a remote.
- dreamcompiler 4y ago
  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.
naikrovek 4y ago
Don't use the "Fork" button in the GitHub UI, then. It is intended for collaboration and establishes and maintains the parent-child relationship of "your fork" and if the parent repo is deleted, so are all forks. If the parent repo is private and goes public, so do all forks. If the parent repo is public and switches to private, so do all forks. This behavior is laid out in docs.github.com and is not secret. This has been the case on github.com for over a decade, and I am slightly shocked that people don't know this. I guess the root of that is that I am surprised that this has not bitten more people than it has. People assuming things are a certain way and never checking to verify that are by far the greatest source of "I shot myself in the foot" statements that will ever be known.
- kitkat_new 4y ago
  "If the parent repo is private and goes public, so do all forks." nope, that's not true: "GitHub will detach private forks and turn them into a standalone private repository. For more information, see "What happens to forks when a repository is deleted or changes visibility?"" " If the parent repo is public and switches to private, so do all forks." This isn't true either: "GitHub will detach public forks of the public repository and put them into a new network. Public forks are not made private." In these cases, exactly what I would have expected happens.
  - naikrovek 4y ago
    yep I was wrong about that point. generally my point still stands; if you want total control over your repo, don't use the GitHub "Fork" button to create your repo for that code. I linked directly to the documentation about "Fork" in another comment.
- mattigames 4y ago
  That would make sense if they didn't use the word "fork" for it, that words has a specific meaning when talking about repositiories[0] and it doesn't include a automatically propagating deletions or settings of the original repo, it doesn't actually include ANY automatic propagation, therefore GitHub should use a different word for this kind of fork, something like "Crate child fork" or "Linked fork" or maybe a new word altogether [0] http://www.freekb.net/Article?id=1263 http://www.freekb.net/Article?id=1263

Mystery-Machine 4y ago

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 4y ago
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/types-of-github-accounts#personal-accounts https://docs.github.com/en/get-started/learning-about-github...
- geraldwhen 4y ago
  Enterprise Managed Users solves the issue.
jyrkesh 4y ago
MIT licensed code doesn't mandate distribution. Companies and organizations are perfectly within their rights to own a private fork of an MIT-licensed codebase in perpetuity. With that in mind, if you fork an organizationally-managed repository, there's a good chance the owner doesn't want you to continue to have access to that codebase if you're no longer a part of the organization. And the local copy? Well there's a good chance you were only allowed to clone the repo on an IT-managed device with specific 2FA policies and some kind of agent/config to prevent/reduce data exfiltration from that device. Is it a perfect system? Hell no. Data leaks, that's part of life. And I'm with you that it certainly could be more user-configurable. But it's also extremely well-documented behavior[1], and seems like a key design choice that GitHub made a long time ago to protect the owners of private repos. Ultimately, if you don't care about who has access to your code, you signal that by making the repo public. Or by telling your private collaborators to make sure they hold on to a local copy. [1]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility https://docs.github.com/en/pull-requests/collaborating-with-...