18

This recent post tends to say that the new GitHub TOS make most open source projects at odds to comply with both their FOSS licensing and the TOS.

Is this right?

Anything copyleft (GPL, AGPL, LGPL, CC--SA) or requiring attribution (CC-BY-, but also 4-clause BSD, Apache 2 with NOTICE text file, …) are affected

6
  • 8
    To summarize, the issue described here is that if Bob posts Alice's open source code to GIthub, Github requires specific rights to the code that Alice may not have granted in her open source license. For example, Alice might license her code under the GPL and then say, "You granted rights to Github that I never gave you the right to grant (like to reproduce my code without attribution or reproduce it without necessary downstream GPL requirements); I'm suing you or issuing a DMCA takedown." I don't know to what degree this is legally sound reasoning, but it seems credible at first glance.
    – apsillers
    Mar 3, 2017 at 1:02
  • @apsillers care for posting this as an answer? Mar 3, 2017 at 10:23
  • 6
    @PhilippeOmbredanne links rot. Can you please add some more context from that blog and the ToS so that this question will continue to make sense 10 years from now?
    – RubberDuck
    Mar 5, 2017 at 12:25
  • @RubberDuck sure. let me do this. Mar 5, 2017 at 15:24
  • 2
    FTR, GitHub is proposing a new update to its TOS (github.com/github/site-policy/pull/1) and it includes a change to the part discussed here. In particular it makes clearer that when uploading content that one doesn't own, they just have to check whether the content is properly licensed and the license allows for their basic needs.
    – Zimm i48
    Jul 18, 2017 at 17:39

3 Answers 3

18

FSF has published an answer now: https://www.fsf.org/blogs/licensing/do-githubs-updated-terms-of-service-conflict-with-copyleft

It begins:

GitHub's updated terms caused a great deal of concern, but while they are confusing, they do not appear to be incompatible with copyleft. The Free Software Foundation (FSF), though, still recommends using other code hosting sites.

So no, it appears as if this is not a kiss of death for oss projects.

4
  • 7
    For anyone concerned about "The FSF[...] recommends using other code hosting sites" - The FSF is pretty fundamentalist about Free Software, and will not recommend using proprietary software in any situation whatsoever. If you share their ethical views, then this is useful information, but if you don't, you might not care for their recommendations anyway. Stack Exchange itself is proprietary software, so I doubt the average reader does share the FSF's beliefs.
    – Kevin
    Jul 16, 2017 at 21:42
  • @Kevin Actually, the FSF's recommendation not to use Github is mostly not concerned with whether or not the server code is free -- They think there are no ethical issues with using proprietary online services so long as they aren't SaaSS. As you can see here and here, to them GitHub's JavaScript, country restrictions, and license recommendations are much more important than the server code.
    – habs
    Apr 14, 2018 at 17:26
  • 1
    @Harry: I reiterarte: The average reader is using Stack Exchange's proprietary JavaScript in order to read this answer, and is therefore unconcerned with GitHub's use of the same.
    – Kevin
    Apr 14, 2018 at 17:29
  • @Kevin Apologies, you're correct -- my reply was misworded, I intended it to provide more details rather than being an "actually" as it turned out.
    – habs
    Apr 14, 2018 at 17:41
16
+50

There's two steps to answering this question:

  • Is there actually a credible legal issue here?
  • Is that legal issue going to be a practical impediment to open source code on Github?

Is there really a legal issue here? What is it?

The issue described here is that if Bob posts Alice's open source code to Github, Github requires specific rights to the code that Alice may not have granted in her open source license. For example, Alice might license her code under the GPL and then say, "You granted rights to Github that I never gave you the right to grant (like to reproduce my code without attribution or reproduce it without necessary downstream GPL requirements); I'm suing you or issuing a DMCA takedown."

In short, Github now requires a license grant that is outside of the scope of what is required by the open source definition (or free software definition), so many open source licenses do not offer sufficient permission to allow someone other than the copyright holder to ensure that these rights can be offered to Github. Possibly these rights could fall under fair use or de minimis or some other justification, but they are certainly outside the explicit grant of many open source licenses, so this sounds like a legitimate legal concern.

The preconditions of legal trouble speculated in the article are

  • Alice, the original author of a project, grants some rights to her project to Bob under an open source license
  • Bob uploads that project to Github (as-is, or modified, or included inside another porject)
  • Github requires rights outside the scope of the license that Alice granted to Bob; Bob wrongly affirms his ability to grant those rights by accepting the terms of service
  • Alice decides to take legal action against Bob

If such legal action did take place, I cannot begin to speculate how a court would rule on it, but it's a credible concern.

This is not an issue for an original author like Alice, assuming she holds copyright on all of her code. Also, it's plausible (though I cannot say for sure) that if Alice has her code on Github already, then Bob can offer the rights Github requires (or perhaps does not need to offer them) since Github has them already via Alice. However, I cannot say for sure, and you certainly shouldn't rely on this barely-armchair analysis as legal advice if you're planning to put someone else's work on Github.

The FSF has a statement about the new Github terms saying that at worst they may be read in a way that is incompatible with the GPL, but hopefully not:

But licenses like the GNU GPL already give the necessary permissions to make, use, and modify local copies of a work. Are the new GitHub ToS asking for more than that? It's not fully clear. While the grant language could fit within the scope of the GPL, other words used in the section like "share" or "distribute" could be understood to mean something that wouldn't line up with the GPL's terms.

[...]

Because it's highly unlikely that GitHub intended to destroy their business model and user base, we don't read the ambiguity in the terms as granting or requiring overly broad permissions outside those already granted by the GPL. It would be inconsistent with changes they made last year on choosealicense.com to treat copyleft better. The relevant sections of the ToS seem to be just restatements of typical free license terms.

Is this legal issue a serious threat to the reuse of open source code on Github?

This is now pure crystal-ball speculation, but probably not. Looking at the legal analysis above, you'll see that Alice the author has to actually want the code to be gone from Github. In general people release code under an open source license because they want to share it. That's exactly what a downstream reuser like Bob is doing, so I'd expect that in the overwhelming majority of cases, there's no issue: Alice wanted her code to be shared and reused, and Github's terms of service don't materially interfere with that goal in any way.

The concessions that Github asks for -- to reproduce snippets of the code in a search feature, or reproduce the entire repository as part of the fork feature -- are so trivial that it's hard to image why Alice would go to the trouble of even doing so much as a DMCA takedown (never mind a full blown lawsuit). The most likely cases I would expect are that Alice has a vendetta against Bob or Github for some reason, or she doesn't like having code under the GPLv3 anymore (but it's explicitly irrevocable) and is trying to remove Bob's code in a fit of licencor's remorse. These don't seem like common cases; overall, open source development on Github will continue as usual.

Again, this is speculation, not legal advice, so don't come crying to me when you get sued (but do let me know -- I'd be interested in updating this answer). :)

7

Absolutely not. They look like sensible ToS for what Github needs to function.

In short, the ToS essentially require authors to give Github a license to display uploaded code outside their original licenses, such as without attributing it to the authors by name, and without displaying the license. Github has already been doing this for years in their search service. I would guess that they previously thought it was acceptable under fair use, but their lawyers have told them to make it explicit through the ToS.

If you're the author of the code you're uploading to Github, then these new ToS make no new restrictions on the licenses of code you can upload, because as the author you always have the right to distribute your code under another license. The new explicit licenses are directed to Github the company (to use and modify the code as needed to run the website) and to Github's users (essentially the right to clone repositories, bringing further clarity to the question of users' rights over all rights reserved repositories, as discussed here previously).

The author of the blog post is wrong to say that Copyleft or licenses which require changes to be published only as patches aren't welcome at Github. They are welcome! But if I'm understanding the ToS correctly, they can only be uploaded by the original copyright authors. What these new more explicit ToS make clear is that if you're uploading someone else's code you need to be able to give Github a license that will allow them function. As most FLOSS licenses grant you a license to redistribute the code only with attribution intact, this means that to be safe you should only upload your own code, code in the public domain (or WTFPL), or code you have permission from the author to upload. As most code on Github is from the original authors and unaffected by these restrictions they are definitely not a "kiss of death". And realistically, I expect most people to ignore them. These ToS are to protect Github from liability, and will be ignored as most site's ToS are.

12
  • 2
    What about all the copyleft projects which moved to GitHub long after having started and have never enforced some sort of copyright centralization (e.g. Linux)? That's kind of the point of the blog post author I suppose.
    – Zimm i48
    Mar 5, 2017 at 12:56
  • 1
    "to be safe you should only upload your own code, code in the public domain (or WTFPL), or code you have permission from the author to upload" - how is this not a "kiss of death for (at least some) open-source projects"? Open source software development is all about reusing, adapting and integrating other people's code for one's own projects, while adhering to the respective license terms. Mar 5, 2017 at 21:07
  • 2
    "As great a website as Github is, open source has survived a long time without it." - maybe that wasn't clear, but I interpreted "kiss of death for open source projects" to refer to Github being their home, not that open source projects in general were going to vanish. "It may be unfortunate that you can't revive an old abandoned project on Github, but it doesn't mean that anything is killed." - well, it's the end of such projects on Github. "Personally I think they should have left it to fair use" - this might evoke problems when the code in question was created in a jurisdiction ... Mar 5, 2017 at 21:52
  • 2
    @curiousdannii: "If it wasn't already the case that the majority of projects on Github were uploaded by their authors" - already when you wrote that for the first time, I wondered what makes you so sure most projects do not incorporate any portion of code by someone else, or derived by the author from someone else's code. "I think this would be a significant problem." - anyhow, there's a long way between "not the majority" and "insignificantly few". Mar 5, 2017 at 22:07
  • 4
    I think in order to support the initial "absolutely not" this answer needs to explain more about how it applies to people uploading third-party code (which is the chief focus of the linked article, not people uploading their own code, which is indeed not an issue), and why either this is not a legal issue or why the legal issue is not a practical issue. The post clearly limits the scope of its consideration to "...a work the uploader did not create completely by themselves..."
    – apsillers
    Mar 6, 2017 at 17:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.