I feel most people are fundamentally misunderstanding what forking means.
Generally, forking means making a copy and modifying it.
Github, however, seems to define "fork" as just making a copy.
So, in fact there is no "TOS violation". The license forbids making a copy and modifying it, while github requires that you allow making copies. There is no conflict between the two.
Even if it were, just having a license that contradicts the github TOS is not a TOS violation (unless that is separately mentioned somewhere).
You have to make a fork aka copy and modify to contribute via pull requests. The license is fundamentally broken.
Yes, but that has nothing to do with Github TOS. It does not require you to accept or even allow pull requests.
@sweng@BrikoX No, the TOS "just" says that by making the repo public you are granting all github users the right to fork it. So that right has already been granted.
The TOS actually does not say you are granting users permissions to fork in the usually understood sense. The TOS gives you permission to copy, which Github calls "forking" even though it isn't.
> you agree to allow others to view and "fork" your repositories
How did you come to the conclusion that this does not grant the permissions to fork? It's literally in the sentence. Where else did you find the definition of "forking", if not here? This is what Github defines in the TOS, this is the label on the button in github UI, so clearly this is also what winamp means when they forbid "forking" and that means it's against the TOS. There is no other "forking".
I got it from the TOS:
By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories (this means that others may make their own copies of Content from your repositories in repositories they control).
They explicitly define it as making copies. There is no mention of being allowed to modify said copy. Also note the quotes around "fork", since it differs from the usual definition.
In software engineering, a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct and separate piece of software.
(Emphasis mine)
@sweng But what else would "forking" mean? As you said "in the usual sense". This is the usual sense - making a copy of the repo on github = forking.
I edited my reply to include the definition from Wikipedia, but there are of course many other sources.
Look, I can't help you if you don't even read the things you are posting. 🤷♂️
How about you continue reading a bit further, until you hit the word "and".
take a copy of source code from one software package and start independent development
(emphasis mine).
Github defines "forking" as just copying, while normally it is understood as copying + further development (creating a "fork" in the development history, hence the name).
> By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories (this means that others may make their own copies of Content from your repositories in repositories they control).
Just because you can do something, does not mean you are allowed to.
makmarian@fedia.io to 
I feel most people are fundamentally misunderstanding what forking means.
Generally, forking means making a copy and modifying it.
Github, however, seems to define "fork" as just making a copy.
So, in fact there is no "TOS violation". The license forbids making a copy and modifying it, while github requires that you allow making copies. There is no conflict between the two.
Even if it were, just having a license that contradicts the github TOS is not a TOS violation (unless that is separately mentioned somewhere).
You have to make a fork aka copy and modify to contribute via pull requests. The license is fundamentally broken.
Yes, but that has nothing to do with Github TOS. It does not require you to accept or even allow pull requests.
@sweng @BrikoX No, the TOS "just" says that by making the repo public you are granting all github users the right to fork it. So that right has already been granted.
The TOS actually does not say you are granting users permissions to fork in the usually understood sense. The TOS gives you permission to copy, which Github calls "forking" even though it isn't.
@sweng
> you agree to allow others to view and "fork" your repositories
How did you come to the conclusion that this does not grant the permissions to fork? It's literally in the sentence. Where else did you find the definition of "forking", if not here? This is what Github defines in the TOS, this is the label on the button in github UI, so clearly this is also what winamp means when they forbid "forking" and that means it's against the TOS. There is no other "forking".
I got it from the TOS:
They explicitly define it as making copies. There is no mention of being allowed to modify said copy. Also note the quotes around "fork", since it differs from the usual definition.
E.g. wikpedia (https://en.m.wikipedia.org/wiki/Fork_(software_development) defines it thusly:
(Emphasis mine)
@sweng But what else would "forking" mean? As you said "in the usual sense". This is the usual sense - making a copy of the repo on github = forking.
I edited my reply to include the definition from Wikipedia, but there are of course many other sources.
@sweng
> take a copy of source code
?
@sweng
Look, I can't help you if you don't even read the things you are posting. 🤷♂️
How about you continue reading a bit further, until you hit the word "and".
(emphasis mine).
Github defines "forking" as just copying, while normally it is understood as copying + further development (creating a "fork" in the development history, hence the name).
I'm not sure if it's spelled out in the ToS, but there is no way to prevent pull requests on public repos, it's a functional requirement.
@BrikoX @sweng
It's in the linked issue, spelled out alright:
> By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories (this means that others may make their own copies of Content from your repositories in repositories they control).
Just because you can do something, does not mean you are allowed to.