Hacker News Reader

The license to "use, display and perform your Content" isn't limited to the GitHub site or functionality. Only the "access your Content" and "reproduce your Content" are limited to GitHub.

> The only real problem I see here is that unless you created the work entirely by yourself ("you" here can mean a group), you can't grant the rights necessary to upload to Github, even if you're well intentioned or the original authors may be fine with it. And these rules apply to private repos, too. I wish the author had focused more on that.

The author did explicitly mention that. But I think it's worth listing all the issues with the ToS, not just one.

> The license to "use, display and perform your Content" isn't limited to the GitHub site

Right. If you put up your code publicly you are implicitly allowing other people to do those things, since there's nothing you can do to stop it. How could you stop someone from privately running your code on their hardware?

You're also implicitly allow people to fork and download the code, since Github doesn't allow public projects to restrict those abilities. Your particular license may restrict making further copies, though.

> Right. If you put up your code publicly you are implicitly allowing other people to do those things,

As one example, "display" isn't made contingent on attribution. As an unusual but plausible example: a GitHub user could grab a pile of code from across GitHub and render it to construct a "movie hacking UI" for a film, without even an attribution for the code they used.

> since there's nothing you can do to stop it. How could you stop someone from privately running your code on their hardware?

(Also, "nothing you can do to stop it" is not a grant of permission.)

As one example, "display" isn't made contingent on attribution.

That's fine, but in general these software licenses do not cover "display", they cover _distribution_. If you consider "using code in a movie hacking UI" to be distribution, then you would already have been bound by the license. If you don't, then you're not. Nothing changes.

> That's fine, but in general these software licenses do not cover "display", they cover _distribution_.

Yes, that means that "display", insofar as that corresponds to a copyright-protected exclusive right like performance, is not licensed by the license, and (if you aren't the original copyright holder) you have no authority to grant a sublicense to GitHub that covers display.

> Also, "nothing you can do to stop it" is not a grant of permission.

Okay, well, I give you permission to copy the words in this sentence into your brain, but you're not allowed to process their semantic content into a coherent idea. If you do, I will sue you.

Surprisingly, the law is neither completely consistent nor interpreted by a computer.

Largely to avoid that sort of thing.

If the code were kept secret, or if you could prevent such use with DRM, copyright law would be irrelevant.

By having the code in the open, you don't 'implicitly allow' unlicensed uses -- you just become reliant on copyright law as your protection.

> The license to "use, display and perform your Content" isn't limited to the GitHub site or functionality. Only the "access your Content" and "reproduce your Content" are limited to GitHub.

Hmmm, I see how the and can be read that way. They really need to use more punctuation in these instead of so many 'and's.

But so if they can only access and reproduce your content through Github, what constitutes use/display/perform, and in what ways could they do that? Judging by the way D.4 is written, I take it to mean things like playing an audio file or running some executable code within the browser.

> The author did explicitly mention that. But I think it's worth listing all the issues with the ToS, not just one.

Yeah, I get that they mentioned it, I meant I wished they spent more than a sentence on it because I feel that's the bigger issue.

> But so if they can only access and reproduce your content through Github, what constitutes use/display/perform, and in what ways could they do that?

IANAL, nor do I have a dog in this fight, since I prefer contracts to copyrights. However...

I think there are at least a few scenarios that require some thinking about, anyway:

Given that the TOS forces allowance of use and performance of content uploaded to Github without regard to any license you might have been bound by otherwise, it seems as though it effectively negates any other such restriction. CC BY-NC doesn't allow commercial use, but now they can just point to the implicit license they got with it because you shared it on Github, right?

The AGPL requires that modified source used to furnish a direct service must be republished. If usage of Github means that you have granted a license, separately from the AGPL, to every user of Github to use your software, then publishing AGPL software via Github seems to negate the license: anyone who has it and who got it using Github may use it to run a server and need not follow the terms of the AGPL to do so.

But this leads to problems with other restrictive licenses as well, such as the GPL, since as long as someone is only distributing your software via Github, they have a license to reproduce it without regard to other terms like modification of source, and other Github users have a license to download and use it.

Even if we see it as a granted license, separately from the AGPL, it would be "solely on GitHub" that people can enjoy those permissions and the permission do not allow making copies that leaves github.

This would of course not work if github became in future a hosting service where people could run projects as services on their platform.

The paragraph in question is one of the paragraphs under [D.5, License Grant to Other Users](https://help.github.com/articles/github-terms-of-service-dra...):

    If you set your pages and repositories to be viewed publicly, you hereby grant each User of GitHub a nonexclusive, worldwide license to access your Content through the GitHub Service, and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub's functionality. You may grant further rights if you adopt a license.

There seem to me (remember, IANAL) to be three rights granted here to each user of github:

1. to access your Content through the GitHub Service,

2. [and] to use, display and perform your Content,

3. [and] to reproduce your Content solely on GitHub as permitted through GitHub's functionality.

The second right is not limited to "on GitHub". Therefore, if your content is anything that can be used by linking, such as an image, javascript, etc, you're granting each github user the right to use that on their site.

From the pushback on this point here and in other comments, I wonder if people are parsing this as

1. a nonexclusive, worldwide license to access your Content through the GitHub Service,

2. and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub's functionality.

...which seems wrong to me. If that were the intent, then I think it would have been easier to say

    [...]through the GitHub Service, and to use, display, perform, and reproduce your Content solely on GitHub as permitted through GitHub's functionality.

In that way, usage, display, performance, and reproduction rights would be connected to "solely on GitHub".

I agree that the wording is odd if as you say they intended it to only be "on github", through there is one problem. The rights granted by 2 can't be used in isolation from 1 and 3.

If you ran the program locally by accessing the content through the GitHub Service, without reproducing the content, 2 should grant you the right to use, display and perform the content. I don't see how you could do that using anything requiring a linker, but I can see how agpl javascript could be in danger if script tags on a website can be linked directly to a file on a github. In that way the content is "access through the GitHub Service", used locally by the browser, but depending on legal theory, not reproduced.

In the general case however it is hard to use, display or perform content for which someone can't access or copy.

> And these rules apply to private repos, too.

To quote your quote:

>> If you set your pages and repositories to be viewed publicly

This is the same non-story that goes around any time someone reads the terms of service of twitter/facebook/dropbox/etc. These services need some license grant to do what you want them to do.

Note that any OSS license fulfills the requirements. I always assumed a free license was a requirement anyway. If that's the case, nothing really changed.

Your quote only covers section D.5, other users. You still need to grant Github themselves that right, even for private repos, in section D.4

Any OSS licence fulfils the requirements EXCEPT for GitHub’s requirement to not add any requirements to the grant. See my updated post.

Section D7 seems to specify that they're talking about moral rights. I understood these to be intrinsic rights in some legal environments, e.g. France, that were distinct from anything that any open source licence might insist on. (As an aside, in the UK there are sadly no moral rights in computer programs, the only one that should apply being expressly excluded in sec 79 of the Copyright Designs & Patents Act 1988)