Hacker News Reader

Comment by Novosell | Hacker News Reader

The Github ToS gives users the right to fork any public repos.

It's not clear that Github's ToS can do such a thing, is it? What gives them the right to overrule the license from Winamp to me?

Because Winamp agreed to the ToS of GitHub by uploading their code to GitHub.

The legal system don't work that way.

That ToS is between wimamp and GitHub, not you.

You have to do the due diligence to get the permission from winamp.

You might be able to get away by suing GitHub and have them sue winamp. ..

https://www.law.cornell.edu/wex/third-party_beneficiary

Is the ToS a contract? Even if it is would the remedy to Winamp breaking it be modifying the license Winamp provides?

Yes, every ToS is a contract. As for the most appropriate remedy, that's for a court to decide.

Doesn't that just mean that Github should be mad at them? Doesn't seem obvious that it actually gives me a license to do anything.

Pretty much all open source projects on GitHub rely on section D.6 of GitHub TOS (when you submit PR, it's licensed under project license and you have a right to do so).

TOS are not just fluff and paper, but legally binding. Granted, when there is a conflict between two conflicting requirements, it's never clear cut, but it's not just "GitHub will be mad."

Any project I've been involved in has its own explicit license, that allows such things (really allows much more, I don't touch anything closed source).

```Any User-Generated Content you post publicly, including issues, comments, and contributions to other Users' repositories, may be viewed by others. 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).```

Section D.5

Whoever the user that is posting the content is agreeing to the terms of service. If they don't actually have permission to agree to those terms with the content, then where that liability falls will likely fall to a court, but I'm sure I would argue as a user who forked the content, that I was given permission via the TOS which has to be followed by the user posting the content.

A repo's license doesn't overrule GitHub's policy.

Seems a lot like that would be the other way around, copyright law overrules random company's policy.

The implication of this is not what you think. Basically github can go after Winamp and say they violated GitHub terms that is it. Just because winamp violated GitHubs terms of service does not mean they lose their copyright rights

So someone steals my source code and posts it on GitHub, now i no longer have copyright rights? The duty is on the copier to ensure they are granted a license.

That's obviously not the case. GitHub even has their DMCA takedowns public. You can't redistribute copyrighted material unless it's under a license that allows for it.

Open source projects on GitHub rely on D6 section of GitHub TOS. That is the part where a user declares that when s/he makes a contribution to a project, s/he does so under repository license. Also that you have right to do so (e.g. when you are on employer clock, your employer must agree).

It's not just a duty of copier to ensure they are granted a license. Legal stuff is never clear cut, but if someone agreed to TOS, it should be generally (that's a funny word that can mean anything) safe to assume that s/he does abide by it.

In this case, there is an obvious conflict and when there are two conflicting clasuses... that's fun for laywers.

On Github. Doesn't give them a license to fork it to their workstation.

One of the many bad things that Github did was to name the button that does the `git clone` action `Fork`.

Like, I get why they did it, but (as we can see) it resulted in this stupid terminology confusion.

A fork is a linked copy, a clone is just a copy. They are not the same.

  Deleting your repository or changing its visibility affects that repository's forks.

Forks predate GitHub and have another almost opposing definition that sets up for a confusion here. By that lingo forks go their own way (like a fork in the road) independently of the upstream and clones are copies of an upstream.

I agree it does...

  fork() creates a new process by duplicating the calling process.

Thats similar to what happens on git providers, you create a new repo by duplicating it, and the repo is linked aka child.

Many forks do go their own way. You can choose to pull from upstream or completely ignore it.

  Deleting your repository or changing its visibility affects that repository's forks.

Sure, but this only matters for 'private' repos. See <https://docs.github.com/en/pull-requests/collaborating-with-...>.

Github does some cute things behind the scenes to save space, but for all 'public' or 'internal' repos, what Github calls a fork is (from a Github user's perspective) identical to what happens when you run 'git clone' on your machine.

Fork, then clone. Simple as.

Reply on news.ycombinator.com