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.
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.
Any (quite relevant actually) discussion of SCM policy and management aside, you've got to remember: There is no 'cloud', it's just somebody else's computer.
Which also shows the right way to delete a private repo if you want people to be able to keep their forks:
If a private repository is made public, each of its private forks is turned into a standalone private repository and becomes the upstream of its own new repository network. Private forks are never automatically made public because they could contain sensitive commits that shouldn't be exposed publicly.
If a private repository is made public and then deleted, its private forks will continue to exist as standalone private repositories in separate networks.
The right way is to make it public first? That's insanity. Making a repo public just to delete it would be a huge information leak even if it was short in duration.
So they did think about this use case (deleting a private repo without deleting forks) but did not bother implementing a proper choice for the repo delete flow?
This seems really bizarre to me. They seem to want people to have the network of connected GH repositories, but this behavior promotes "forking" a project in a way that breaks that network, which is to `git clone` and then create a new repo from that clone.
To put it another way, if the user had "forked" the GH repo onto GitLab, there would be no data loss, but that behavior would promote using GH in a way that breaks the upstream/downstream relationship that you see on GH.
It's even worse that the deleted fork was private. What impact does GH expect deleting the hosted private repository has on folks who really want to keep a private copy of the repo, such as offline or on another git hosting site? I'm really struggling to see any real-world positive sides to this mechanism. Seems like an ineffectual legal or compliance CYA.
> 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.
This is how it should be done, but is too much overhead for many "IT as a cost centre" companies.
Yes, I believe that if you push a repo to GitHub from a local copy instead of using their web-based "fork" feature it will not deduplicate the repositories. IDK if this affects your ability to submit pull requests though.
My client recently moved from GitLab (self hosted - many teams had their own isolated server) to GitHub.com and managing access for the thousands of developers has been a small headache. We were encouraged to use our personal GitHub accounts instead of making new ones.
They are promoting "internal open source", yet due to a wild variety of permissions, colleagues can't fork to their own space or push a branch for a PR. Chasing the repo owners or at least someone with authority to grant permission is rarely worth the hassle.
Er, kinda presumptuous of you (and GitHub), no? None of my private repos, forks of other people's private repos, or other people's forks of my private repos are in any way governed by an employment agreement, and if they were, there's no way for GH to know what that agreement says.
The original code may be licensed MIT. The MIT license allows for the project to be relicensed, closed source and it is also possible for a proprietary contributions that aren't MIT license to be added to it that are protected as any other closed source code. The MIT license is not "viral" and doesn't require that everything following from it is.
The person may be able to find the original code that was MIT licensed but that doesn't mean that the work done in house is also MIT licensed and that they have any right to it.
> The original code may be licensed MIT. The MIT license allows for the project to be relicensed, closed source
… this is less compelling to me than this:
> and it is also possible for a proprietary contributions that aren't MIT license to be added to it that are protected as any other closed source code. The MIT license is not "viral" and doesn't require that everything following from it is.
AFAIK, changing the licensing terms of an MIT project isn’t retroactive to prior licenses. A quick search seems to confirm that.
The possibility of more restrictive or revocable licensing of subcomponents is more compelling as a rebuttal to “mine” at a philosophical level, but it’s not compelling from the perspective of GitHub revoking access. They’re welcome to comply with relevant legal actions, but they’re not actually the police of your licensee status and don’t even attempt to be.
Ultimately it’s the person who maintains the private repo who is responsible for and to any license challenges. GitHub isn’t a party or privy to those agreements, and again doesn’t have any pretense of such except compelled by legal action. And I give them the benefit of the doubt that this isn’t their motive.
This behavior is part of their own permissions model, and their own model of the relationship between “forks” and “private”, as defined by their own use cases. It’s a surprising one, but it needn’t have anything at all to do with their view of any given user’s repo’s license compliance.
The first part sets up the second part that unlike the GPL, the MIT license doesn't require that future contributions to the project be any particular license.
Presumably the OP can find the open source project MIT licensed without the company's contributions to it.
The only thing that the MIT license requires is:
> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
It doesn't even require attribution in the compiled application or any other notices.
And so, it is possible (and I would dare say likely) that the contributions that the OP made while working on the repo at the company unless specific permission was given otherwise would be considered as work for hire or as part of the work product as condition for employment and completely owned by the company (and not MIT licensed).
If the OP thinks that they should have access to the code because of the MIT license, that is something to take up with a lawyer. My IANAL senses suggest that that would be rather fruitless.
I don't find GitHub's model particularly surprising but rather the most reasonable one that opens GitHub up to the least liability for accidental disclosures of content. Error on the side of least privilege and if there's something to work out beyond that, that's something for the contributors to work out themselves - GitHub isn't the arbitrator for that.
> And so, it is possible (and I would dare say likely) that the contributions that the OP made while working on the repo at the company unless specific permission was given otherwise would be considered as work for hire or as part of the work product as condition for employment and completely owned by the company (and not MIT licensed).
This is a radical interpretation of the text if I’ve ever seen one. To the extent any of their contributions were merged upstream, they’re inherently MIT licensed by virtue of being in the same codebase which offers that license. To the extent they have unmerged changes, they may well be works for hire but it isn’t GitHub’s role to decide that between a second and third party.
Again nor do they want to. GitHub is extremely hands off about forks and the licensing implications thereof.
This isn’t a GH posture towards licensing disputes, it’s their posture towards their own authorization model. And that’s fine, but we shouldn’t conflate the two when they’re quite distinct.
Open source project and publicly accessible upstream? Yep. They're likely MIT licensed in accordance with the CLA.
Internal company copy of an MIT project? Unlikely unless legal says they are.
If the organization that I worked for made an internal copy of Influxdb ( https://github.com/influxdata/influxdb ), my contributions to the private and internally hosted copy are not inherently MIT licensed too and furthermore don't need to be redistributed.
If those changes were submitted upstream to the influxdata/influxdb repo, and I signed the CLA with them - then yes they would be.
What's more, if I left the organization, then I don't necessarily have a right to the contributions that I made to the private and internally hosted copy's codebase.
However, the work done while at the employer may not have been done under the MIT license unless permission to license it and distribute it under the MIT license was given by legal.
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.
OP states that it was "an MIT-licensed open source project". It appears that Microsoft has lack of licensing understanding not only when it comes to copilot.
If they are punishing users just under an assumption that user is doing what they are doing (using someone's codebase with non-permissive licence, possibly unlawfully), it's just silly.
It really sounds like the forking and access should be "license aware" which sounds like an absolute nightmare to manage but that would help in this specific scenario?
I can see it simply creating more worms than helpful.
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 access is by their own staff, or by other orgs that have signed various contracts or agreements, so there is no expectation of privacy.
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.
Another example is Microsoft Teams, which hides the name of the organisation people are coming from. In large multi-org meetings this is infuriating, because you have no idea where anyone is from. Microsoft does this because they use outsourcers like MindTree for support, and they don't want their customers to see this in Teams meetings for Azure support tickets. No-one is allowed to see where people are from so that Microsoft can bullshit their customers.
> 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!
Business Basic accounts being limited to 7 days of login logs is a huge middle finger to the entire small business sector. Of course they think everyone should just buy Enterprise subscriptions. It's nothing more than a corporate version of "don't be poor".
Segmenting an enterprise version of a product is generally about finding features that are disproportionately valuable to enterprise (centralized control, policy enforcement, auditing, etc) separating them into a different offering. This lets you charge less to small businesses without having your small business product cannibalize your enterprise business.
This seems basically fine to me? If there are a lot of small businesses who are unsatisfied with Business Basic and can't afford Enterprise then there's an opening for a competitor.
The particular segmentation is a questionable choice.
Small enterprises are likely to have small IT/Security staff, and the most likely, therefore, to not notice something awry for a few days, at which point, vital log info has already rolled off the 7-day window.
This is exactly the issue. No one monitors the logs and, by the time they figure out something is wrong, there isn't enough info available to properly assess the scope of the damage.
Another problem is the Business Basic product is too complex for what small businesses need (reliable email) and buying something even more complex to get a couple of extra features like proper logging is counterproductive.
As is, if a small business ends up with a compromised admin account I don't think it's unreasonable to consider migrating them to a different service. It's nearly impossible to guarantee a bad actor hasn't hidden a back door somewhere in all that complexity if your only tools for assessment are the ones offered in the Business Basic subscriptions.
Maybe the small businesses you've encountered are different from the ones I have? My expectation is that most have no security staff and wouldn't use this feature even if it had indefinite retention.
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.
No, the software becomes "Open Source" or "Free Software" the moment someone licenses it to somebody else under such a license. Simply copying a file named LICENSE into some private directory has no legal relevance. As an employee, you usually don't get a license to the work artifacts you are working on.
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.