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.

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.

> My private forks are mine

Your employment agreement disagrees. Blame the confusion on the blurry line GitHub draws between forking work repos into personal accounts.

Did you forget the part where this code is MIT-licensed? Yes, they don't own it, but the code is still 'theirs' to keep forever as they see fit.

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.

IANAL but…

> 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.