> To the extent that it is that straightforward, the correct takeaway is that you do not have permission to include someone else's GPLed code in your Github repository
Or to put that differently;
Using GitHub’s built-in “Fork” feature is probably often a violation of GitHub’s terms of use.
> If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking)
So I can "perform" and "reproduce" content through forking, solely on Github. But I couldn't clone it, nor make modifications to my fork, if I read that correctly.
It makes little sense and could be avoided altogether by disabling forking for un-licensed repositories. Or by simply giving all new projects a default (with an opt-out option for no license or alternate licenses).
> But that is different from logging into Github and having a fork of my repo.
How is it really different? When you push it back up to github it is exactly as if you'd have forked it. The only difference is that it isn't marked as a fork and in this respect not shown when you look at the original repo graph.
It's nice that it works for your usecase, but since it's not a real protection against anything and only looks like a safety measure against abondend accounts that still have a copy of your code, it shouldn't be a feature that's on by default. (Imho)
> Isn't that against Github rules? And doesn't that mean the 150 forks (republishings) are in legal danger?
It’s not against GitHub rules. Were you under the impression users could only host repositories on GitHub that have licenses that fulfill the open source definition? How did you get that misimpression?
> 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.
> That makes perfect sense to me; the fork ON github is what lends the fork legitimacy versus "some dude found code."
No, he made two points. The first one is that this way you don't have your code in random freelancer's accounts, which I'm saying is wrong: a freelancer can take his code, and upload it back to his account.
So if this mechanism makes sense to you as a way of guaranteeing that your code won't be in other people's accounts, you're mistaken too.
In fact if you don't believe me give me access to your private repos and lets see what happens.
> The larger issue is that anyone using GitHub is donating their work for re-use without attribution through Copilot.
Wrong. Lets say a GPL project is not hosted on GitHub officially. I can easily setup a mirror for it though on GitHub as the GPL doesn't prevent me from doing it...
Point is that anyone can put my work on GitHub, even if I don't want to.Assuming the project is under a free license though.
> the very act of publishing to GitHub implies a desire to share the code.
No. Thats like saying the very act of sharing pictures online implies you want someone else to use them, or that printing your book and selling it somehow implies you want the world to copy it.
You share on GitHub because its a source control platform, and your code may be interesting to others. This does NOT mean that you are okay with someone taking the code and using it in their (potentially commercial) program.
That is NOT implied, and thats why licenses exist. You could even argue that, as GitHub has license detection etc. built in, sharing and reading code there should mean you are aware of licensing.
> I don't understand why someone would willingly share their code on github where it is publicly available just to complain when others make use of that knowledge.
People like you should understand that publicly available code doesn't mean "do whatever you want" code.
The majority of publicly available code hosted on Github as a license that tells you what you can and what you cannot do with that code.
If someone uses this code without respecting the license, authors have the right to complain and even legally enforce the license if they want.
Now, you should know that there's nothing "cool" to take other people's work without permission.
This is the real anti-feature. You should only be able to fork a private repo using an account that is directly managed by the organization that owns the repo. That way when you revoke access to the user they automatically lose access to the fork.
It's super weird that it's common to use the same account for work and non-work stuff on GitHub (myself included).
>I really like how github fork can be implemented as new HEAD etc references to the same objects. New commits refer to the original project's objects.
This can be done (more effectively, actually) without the user's explicit involvement in the fork process. You can dedupe blobs across the entire platform on git push.
>Regarding the article, it seems to be saying you can't bazazr-fork a project on github
I'm not saying you can't (I thought that was clear enough), but that GitHub is designed to encourage you to use a different approach.
> I wish more people understood that this is a bad thing.
Why is it a bad thing? If you represent a business you are free to either refrain from using the project, or send a message to the author(s) and request they add a license. Perhaps the author has no intent to allow others to use their code, and they are merely using github as a convenient place to host their code. Like you said, nobody is allowed to use their code without a license, so why bother to use a private repository?
It might be a bad thing if the author actually put their code online with the intent of having random businesses use it, but it's a bit presumptuous to call it a bad thing in general.
> I think GitHub should really have a way for users of your repository to somehow illustrate that they're using your project
I kind of use forking that way (although more when I like a project, it's not necessarily a promise that I'm using it anywhere). This ensures that I have a copy of the project in the state that I originally liked. Then if the project is either (a) taken in a disagreeable direction or (b) deleted, I still have my local copy. I can also always update from upstream if future development occurs that I want to benefit from.
That said, I don't fork all the open source packages I use, although maybe I should.
Just to be clear we can create a branch on github as well as on git though I am not forced to do so on github. This maybe confusing for a beginner as both provide branching.
Or to put that differently;
Using GitHub’s built-in “Fork” feature is probably often a violation of GitHub’s terms of use.
reply