OSS licences vs. ToS: grants of rights

[mirabilos]

EDITED to reflect the remaining issues for the July 2017 upgrade. Original PR at bottom.

The ToS §D.4f. in the July 2017 update still include an unconditional licence grant on content uploaded which the user may not be able to fulfil, as virtually all licences require certain terms to be enforced for any kind of redistribution (same licence for copyleft licences, retaining some words of the licence usually for Ⓕ copyfree licences).

The offending sections must be modified to apply only to repositories in which not every file is already available under a licence granting GitHub and its users “enough” rights to do what’s described. For practicality reasons, all Open Source / Open Knowledge / FSF-free / DFSG-free / Copyfree licences are, after reading their definitions, considered “enough”, and any other licences are outside the scope of this problem report.

---

The original PR before the edit follows:

---

Even after #1 there are still some remaining issues. This one is about §D.3ff. (grants of rights).

---

§D.3 says “If you upload Content that already comes with a license granting GitHub the permissions we need to run our Service, no additional license is required.”

Please clarify here explicitly that any of the usual OSS licences are sufficient to fulfil this ToS requirement, including honouring their termination clauses and all.

I grant you that you may include the text body of that list of free licence lists in your ToS or elsewhere. I collected this list myself. For review, it should be sufficient to review the inclusion criteria (e.g. the OSD (Open Source Definition) for the OSI list, etc.) because, as far as I can tell, any licence that fulfils the criteria to be listed in one of those lists is required to grant enough rights for GitHub and its users to do the necessary things.

Do note that I included non-code licence lists; this is often necessary for documentation, audiovisual works, etc. (such as game data, etc). My intent here is to “defang” ToS §D.3–D.5 if the entirety of the repository is available under (a combination of) Free/OSS licences, because these grant both GitHub and every GitHub user enough rights already to, in practice, do what you request.

---

§D.4 says “share it with other users”

Please make it explicitly clear that, if such an OSS licence (see above) applies to the work, any users will still have to comply with the licence on the work (including all of its restrictions).

This should not be a problem because those licences and the law already have provisions for service providers that include hosting, backing up the work, and transit, as long as the recipient, when sharing, is bound to the licences’ terms.

---

§D.4 says “This license does not grant GitHub the right”…

Please make it clear that the OSS licences (as above) supersede this anyway.

---

§D.5 says “you grant each User of GitHub a […] license […]”

Please make it explicitly clear here that, if any such OSS licence as above applies to the work, this additional grant is not necessary, and that this clause does not “defang” the conditions the OSS licences put on dealings in the works licenced under them.

This is also not a problem for either you or your users because the licences and, again, the usual laws, permit users rights to do some things locally with the works, and virtually all of the conditions those licences have only trigger when users further share the work.

Please make it also clear that “Content you upload is licensed under terms that grant these permissions” is also sufficiently fulfilled if such content is available under the OSS licences mentioned.

---

This is a follow-up on a part of the new ToS draft, partly from my prior review which I assume you know, but, if not, suggest to read. The list of free licences on my website is new, created after that article.

[bluemazzoo]

Hi @mirabilos, thanks for your feedback! Since you have a few different concerns within this issue, we ask that you split them up so that each issue contains a single problem that you'd like to address. While the issues may be related, having multiple concerns in a single issue will make focused discussions more difficult to hold, and may result in issues remaining open longer than is necessary. Thanks!

[mirabilos]

Hi @mirabilos, thanks for your feedback! Since you have a few different concerns within this issue, we ask that you split them up so that each issue contains a single problem that you'd like to address.

As far as I can tell, I already split the issues I have along a logical boundary: all changes in either issue are a direct result of one specific executive decision (one about stating that each OSS licence already suffices, the other about dropping the attribution waiver). I'll reread to see whether I can split something off, though.

[nsqe]

Hi, @mirabilos,

Thank you so much for these well thought-out comments. We've given them a lot of thought since you proposed them, and we believe our new ToS draft sufficiently addresses these issues. However, we're going to leave these issues open, so if other users have comments, we'd like to see them.

We don't want to put an explicit list of FOSS licenses in the Terms of Service, because that list can be limiting in the event that new licenses come out or that projects use unique, one-off licenses (which does happen). Instead, we have explained the minimal requirements we need — and we've made them as limited as we possibly could — and we've asked users to make sure that the content they post is compliant.

It isn't appropriate for us to give legal advice, such as by making a blanket statement about any single open source license and how it interacts with our Terms of Service agreement. Open source licenses can be complex and nuanced. We can only do our best to make our Terms as clear as possible, so it's easy for our users to understand what we need.

That said, a lot of your suggestions are really good, they would just work better for a FAQ or an explanatory article than for a Terms of Service agreement, because we're trying to keep it as short and easy to read as possible. Adding more text that isn't part of the legal contract doesn't help to strengthen the agreement.

We really do appreciate all of the feedback you've given us. It's so important to us to make sure that our Terms don't conflict with the licenses that control content on our site. We're interested in any other comments our community has on this topic.

[mirabilos]

I’ve rechecked the issue against the latest draft and added a pull request with suggested language to make the goal clear (also to protect against suggestions like those from #37 and #38 which invite an even less compatible-with-OSS-projects licence grant).

[nsqe]

Hey, @mirabilos,

I'm coming back to this, and I'm commenting here instead of the pull requests, but I've read the discussion in #52 extensively, and the discussion @wking built off of it in #54.

What I'm coming back to is essentially what I said in #7 (comment): we just can't put a list of FOSS licenses in the Terms of Service.

However, we think it would be absolutely reasonable for us to write a guideline to how various major open source licenses interact with the GitHub Terms of Service, and put that in our Help documentation. We can't do that before the current comment period is over, but we have added it to our roadmap. We hope to address not only what happens if a user uploads content with particular license requirements, but also what happens if someone else forks the content (or adapts it).

We hope this should answer any lingering questions about how our license grant affects content posted with open source licenses...and of course, we'll want feedback on it once we're done!

[mirabilos]

I’ve reviewed the §D.3—§D.6 of the current ToS (“Effective date: October 11, 2017”), and I double-checked with GNU GPLv1 and GPLv2, and I believe that my concerns are now addressed. (Sorry for taking so long.) Thanks!