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