Remove license grant or clarify that free software licenses take precedence

[ossguy]

1. What's the name of the policy?

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md#4-license-grant-to-us

5. Why do you think this section or language needs improvement?

While I see that similar issues have been discussed at length in #7, #52, and #54, I'd like to offer a slightly different approach that may be simpler. Instead of editing or replacing the existing wording, we could instead add the following clause to the end of this section:

"If the Content's license is a license approved by the Open Source Initiative, then the Content's license will govern GitHub's (and its legal successors', assignees', and delegates') reproduction, display, modification, distribution, and performance of the Content and the above license will not apply."

Note that the list of extra entities included above is required due to https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md#2-non-assignability , which mentions that "GitHub may assign or delegate these Terms of Service".

If a more complex change is desired, I generally approve of the approach of #52, though I think using the OSI list of licenses is sufficient (as opposed to using the nearly-exhaustive list of lists in #52), especially since GitHub self-identifies as "The largest open source community in the world" (see https://github.com/open-source ) and so GitHub should be fine with agreeing to the terms of licenses that the Open Source Initiative approves.

There are a number of problems with leaving this section as-is (without a change like #52 or that described above), not least of which is that, under some readings, GitHub could, for example, use an AGPL-licensed project to provide some of its Service without making the source code available to its users, even if GitHub modified the project. This holds true in spite of the last sentence of the current section ("This license does not grant GitHub the right to sell your Content or otherwise distribute it outside of our Service") since that says nothing about GitHub using the Content internally in violation of its stated license (as the rest of the section appears to grant GitHub rights beyond those of the Content's stated license).

If GitHub does not want to make the above change (or a similar one clarifying that open source licenses take precedence), I would appreciate if a GitHub employee could comment on this ticket to indicate which permissions GitHub needs in order to operate its Service that are not already granted by all of the OSI-approved licenses.

An alternative would be for GitHub to remove the "License Grant to Us" section completely, and rely on the usual caching and similar "common carrier"-related laws that most web companies rely on already. This would be even better than having to add more text (since then the existing license for Content would implicitly apply, without needing to say it in the Agreement), and would satisfy GitHub's desire "to keep it short and easy to read" as expressed in #7 (comment) (as the Agreement would be even shorter).

[wking]

On Fri, Jul 28, 2017 at 06:57:34PM +0000, Denver Gingerich wrote: If a more complex change is desired, I generally approve of the approach of #52, though I think using the OSI list of licenses is sufficient (as opposed to using the nearly-exhaustive list of lists in #52), especially since GitHub self-identifies as "The largest open source community in the world" (see https://github.com/open-source ) and so GitHub should be fine with agreeing to the terms of licenses that the Open Source Initiative approves.

The “explicitly whitelist licenses” approach suggested here and in #52 means that folks whose licenses cover the permissions required by GitHub but which are not approved by the license-categorization bodies listed will still need to grant the rights covered in §D.4. For projects where the GitHub poster is not the sole copyright holder, that may not be possible. #54, on the other hand, only requires a new right-grant when the license does not already supply the required permission.

An alternative would be for GitHub to remove the "License Grant to Us" section completely, and rely on the usual caching and similar "common carrier"-related laws that most web companies rely on already.

I don't think that's possible. Consider someone hosting their own all-rights-reserved content in a public GitHub repo [1]. In that case, nobody is authorized to copy the content, but GitHub clearly needs to make local copies and display them to other users as part of reliable hosting it. Without §D.4, GitHub has no right to make or display those local copies, just like the general public is not allowed to copy/distribute that work. Fair use (and presumably similar things outside the US) may cover the rights GitHub needs for excerpts like search results. But I don't think they go so far as to sharing copies of the complete work ;). [1]: #38 (comment)

[ossguy]

Google caches copies of entire web pages/sites (see the drop-down next to one of its search results to get the cached version) so I think there is at least some law protecting it and similar companies from redistributing complete copies of all-rights-reserved works, at least in some circumstances.

Hopefully GitHub will be able to respond with its rationale for either (a) not relying on the existing caching or fair use provisions in the law or (b) requiring more permissions than the licenses in the OSI-approved list offer.

[wking]

On Fri, Jul 28, 2017 at 08:01:32PM +0000, Denver Gingerich wrote: Google caches copies of entire web pages/sites (see the drop-down next to one of its search results to get the cached version) so I think there is at least some law protecting it and similar companies from redistributing complete copies of all-rights-reserved works, at least in some circumstances.

A quick hunt around turned up [1]. I'm not entirely convinced by the discussion (e.g. it claims that “it is the user, not Google, who creates and downloads a copy of the cached Web page” and that “automated copying by machines occasioned by others not sufficient” [2]). But regardless of whether that makes sense or not, the second argument about implied license (also starting on [2]) makes sense to me. However, if you're relying on an implied license to serve the pages (“of course we're copying and sharing these, the posted explicitly chose to put them in a public repo”), I wouldn't be surprised if GitHub prefered to have an explicit license (via the ToS section) instead ;). [1]: https://en.wikipedia.org/wiki/Field_v._Google,_Inc. [2]: http://fairuse.stanford.edu/primary_materials/cases/fieldgoogle.pdf#page=11

[nsqe]

Hey, @ossguy and @wking,

I've just answered @mirabilos's suggestion about FOSS licenses else-issue. I think that may resolve this as well, so I'm going to close this. Please keep an eye out for our new document!