An update to GitHub's terms of service
| Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net. |
On February 28th, GitHub published a brand new version of its Terms of Service (ToS). While the first draft announced earlier in February didn't generate much reaction, the new ToS raised concerns that they may break at least the spirit, if not the letter, of certain free-software licenses. Digging in further reveals that the situation is probably not as dire as some had feared.
The first person to raise the alarm was probably Thorsten Glaser, a
Debian developer, who stated that the "new GitHub Terms of
Service require removing many Open Source works from it
". His
concerns are mainly about section
D of the document, in particular
section D.4 which states:
You grant us and our legal successors the right to store and display your Content and make incidental copies as necessary to render the Website and provide the Service.
Section D.5 then goes on to say:
[...] You 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
ToS versus GPL
The concern here is that the ToS bypass the normal provisions of licenses like the GPL. Indeed, copyleft licenses are based on copyright law which forbid users from doing anything with the content unless they comply with the license, which forces, among other things, "share alike" properties. By granting GitHub and its users rights to reproduce content without explicitly respecting the original license, the ToS may allow users to bypass the copyleft nature of the license. Indeed, as Joey Hess, author of git-annex, explained :
The new TOS is potentially very bad for copylefted Free Software. It potentially neuters it entirely, so GPL licensed software hosted on Github has an implicit BSD-like license
Hess has since removed all his content (mostly mirrors) from GitHub.
Others disagree. In a well-reasoned blog post, Debian developer Jonathan McDowell explained the rationale behind the changes:
My reading of the GitHub changes is that they are driven by a desire to ensure that GitHub are legally covered for the things they need to do with your code in order to run their service.
This seems like a fair point to make: GitHub needs to protect its own
rights to operate the service. McDowell then goes on to do a detailed
rebuttal of the arguments made by Glaser, arguing specifically that
section D.5 "does not grant [...] additional rights to reproduce
outside of GitHub
".
However, specific problems arise when we consider that GitHub is a
private corporation that users have no control over. The "Services"
defined in the ToS explicitly "refers to the applications, software,
products, and services provided by GitHub
". The term "Services" is
therefore not limited to the current set of services. This loophole
may actually give GitHub the right to bypass certain provisions of
licenses used on GitHub. As Hess detailed in a
later blog post:
If Github tomorrow starts providing say, an App Store service, that necessarily involves distribution of software to others, and they put my software in it, would that be allowed by this or not?
If that hypothetical Github App Store doesn't sell apps, but licenses access to them for money, would that be allowed under this license that they want to my software?
However, when asked on IRC, Bradley M. Kuhn of the Software Freedom
Conservancy explained that "ultimately, failure to comply with a
copyleft license is a copyright infringement" and that the ToS do
outline a process to deal with such infringement. Some lawyers have
also publicly expressed their disagreement with Glaser's assessment,
with
Richard Fontana from
Red Hat saying that the analysis is "basically wrong
". It all comes
down to the intent of the ToS, as Kuhn (who is not a lawyer)
explained:
any license can be abused or misused for an intent other than its original intent. It's why it matters to get every little detail right, and I hope Github will do that.
He went even further and said that "we should assume the ambiguity in their ToS as it stands is favorable to Free Software".
The ToS are in effect since February 28th; users "can accept
them by clicking the broadcast announcement on your dashboard or by
continuing to use GitHub
". The immediacy of the change is one of the
reasons why certain people are rushing to remove content from GitHub:
there are concerns that continuing to use the service may be
interpreted as consent to bypass those licenses. Hess even hosted
a separate copy of the
ToS [PDF] for people to be able to read the
document without implicitly consenting. It is, however, unclear how a
user should remove their content from the GitHub servers without
actually agreeing to the new ToS.
CLAs
When I read the first draft, I initially thought there would be concerns about the mandatory Contributor License Agreement (CLA) in section D.5 of the draft:
[...] unless there is a Contributor License Agreement to the contrary, whenever you make a contribution to a repository containing notice of a license, you license your contribution under the same terms, and agree that you have the right to license your contribution under those terms.
I was concerned this would establish the controversial practice of forcing
CLAs on every GitHub user. I managed to find a post from a lawyer,
Kyle E. Mitchell, who commented
on the draft and, specifically, on the CLA. He outlined issues with wording
and definition problems in that section of the draft. In particular, he
noted that "contributor license agreement is not a legal term of art,
but an industry term
" and "is a bit fuzzy
". This was
clarified in the final draft, in section
D.6, by removing the use of the CLA term and by explicitly mentioning
the widely accepted norm for licenses: "inbound=outbound". So it seems that
section
D.6 is not really a problem: contributors do not need to
necessarily delegate copyright ownership (as some CLAs require) when they
make a
contribution, unless otherwise noted by a repository-specific CLA.
An interesting concern he raised, however, was with how GitHub conducted the drafting process. A blog post announced the change on February 7th with a link to a form to provide feedback until the 21st, with a publishing deadline of February 28th. This gave little time for lawyers and developers to review the document and comment on it. Users then had to basically accept whatever came out of the process as-is.
Unlike every software project hosted on GitHub,
the ToS document is not part of a Git repository people can propose
changes to or even collaboratively discuss. While Mitchell
acknowledges that "GitHub are within their rights to update their
terms, within very broad limits, more or less however they like,
whenever they like
", he sets higher standards for GitHub than for
other corporations, considering the community it serves and the
spirit it represents. He described the process as:
[...] consistent with the value of CYA, which is real, but not with the output-improving virtues of open process, which is also real, and a great deal more pleasant.
Mitchell also explained that, because of its position, GitHub can have a major impact on the free-software world.
And as the current forum of preference for a great many developers, the knock-on effects of their decisions throw big weight. While GitHub have the wheel—and they’ve certainly earned it for now—they can do real damage.
In particular, there have been some concerns that the ToS change may be an attempt to further the already diminishing adoption of the GPL for free-software projects; on GitHub, the GPL has been surpassed by the MIT license. But Kuhn believes that attitudes at GitHub have begun changing:
GitHub response
However, it seems that GitHub has actually been proactive in reaching out to the free software community. Kuhn noted that GitHub contacted the Conservancy to get its advice on the ToS changes. While he still thinks GitHub should fix the ambiguities quickly, he also noted that those issues "impact pretty much any non-trivial Open Source and Free Software license", not just copylefted material. When reached for comments, a GitHub spokesperson said:
While we are confident that these Terms serve the best needs of the community, we take our users' feedback very seriously and we are looking closely at ways to address their concerns.
Regardless, free-software enthusiasts have other concerns than the new ToS if they wish to use GitHub. First and foremost, most of the software running GitHub is proprietary, including the JavaScript served to your web browser. GitHub also created a centralized service out of a decentralized tool (Git). It has become the largest code hosting service in the world after only a few years and may well have become a single point of failure for free software collaboration in a way we have never seen before. Outages and policy changes at GitHub can have a major impact on not only the free-software world, but also the larger computing world that relies on its services for daily operation.
There are now free-software alternatives to GitHub. GitLab.com, for example, does not seem to have similar licensing issues in its ToS and GitLab itself is free software, although based on the controversial open core business model. The GitLab hosting service still needs to get better than its grade of "C" in the GNU Ethical Repository Criteria Evaluations (and it is being worked on); other services like GitHub and SourceForge score an "F".
In the end, all this controversy might have been avoided if GitHub was generally more open about the ToS development process and gave more time for feedback and reviews by the community. Terms of service are notorious for being confusing and something of a legal gray area, especially for end users who generally click through without reading them. We should probably applaud the efforts made by GitHub to make its own ToS document more readable and hope that, with time, it will address the community's concerns.
| Index entries for this article | |
|---|---|
| GuestArticles | Beaupré, Antoine |
(Log in to post comments)
An update to GitHub's terms of service
Posted Mar 8, 2017 11:08 UTC (Wed) by Lekensteyn (guest, #99903) [Link]
When I contacted Github about possible concerns regarding 5. License Grant to Other Users, I got this reply from Elizabeth (Github Support):Thanks for your feedback. We've gotten a number of questions about the new Terms and we're taking another look at them to see whether or not they could be clarified further.The problematic interpretation is when the license is violated, do the "defaults" then apply (effectively giving more rights than allowed) or is it only applied in case no license exist? Neither the ToS nor this reply make it clear.To address your specific question, if you have adopted a license for your content, such as the GPL, then that license controls what rights users have to your content; the Terms of Use are just a default.
An update to GitHub's terms of service
Posted Mar 8, 2017 12:39 UTC (Wed) by juliank (guest, #45896) [Link]
It also unclear whether "solely on GitHub" refers only to "reproduce" or to "use, display, and perform" as well. English language, having no real operator precedence (nor enough operators...) easily leads to ambiguities.
An update to GitHub's terms of service
Posted Mar 8, 2017 15:06 UTC (Wed) by jkingweb (subscriber, #113039) [Link]
There is also self-service-only repository software like Go Git Service and its fork Gitea for those really concerned about their software being abused by a third party.
An update to GitHub's terms of service
Posted Mar 9, 2017 0:02 UTC (Thu) by simcop2387 (subscriber, #101710) [Link]
An update to GitHub's terms of service
Posted Mar 9, 2017 13:34 UTC (Thu) by robbe (guest, #16131) [Link]
An update to GitHub's terms of service
Posted Mar 8, 2017 15:27 UTC (Wed) by joey (guest, #328) [Link]
As I read the TOS, it licenses software to Github (and their partners, contractors etc) under a license which is not a copyleft license. So Github can disregard copyleft licenses without infringing.
I hope that the Conservancy finds time to post a fuller analysis than the couple of quotes here from Bkuhn. The FSF also has yet to weigh in publically. It seems premature for LWN to say "Digging in further reveals that the situation is probably not as dire as some had feared."
An update to GitHub's terms of service
Posted Mar 8, 2017 20:27 UTC (Wed) by diegor (subscriber, #1967) [Link]
What does it happen if I upload gpl code, and I'm not the only author? I'm can't legally relicense the code. So if the tos are incompatible with the GPL, every project, where the uploader is not the owner of all the code uploaded, should be removed, for copyright infrangement.
Think about linux kernel. Even if is uploaded by Torvalds, he is not owner of the code, so he can't relicense with a differente license. And I suspect that the majority of project on github have the same "problem".
Also, when they talk of "content" the content is usally the source code, so permitting (to github) the redistribution of source code is coherent with the aim of the gpl.
An update to GitHub's terms of service
Posted Mar 15, 2017 1:16 UTC (Wed) by anarcat (subscriber, #66354) [Link]
Well, I can only paste so much from Bkuhn without making this article being *all* about what Conservancy is saying. :) What he said is on record, and i have logs if you are curious, but they essentially boil down to the arguments I've made in the article. Therefore, I am not sure Conservancy will post a fuller analysis - they have answered their projects directly with a statement, and will probably do the same to you if you ask them directly. :)
I still stand by my statement that the situation is not so bad, and I don't think it was premature. I weighted the arguments brought forward by you and Glaser and brought them up in the article (faithfully, I hope!) and compared them with arguments I heard elsewhere in the community, from other Debian developers and lawyers, and reached my own conclusions. I could of course be mistaken, but I do not see how.
Furthermore, you might like to know that the FSF did finally publish a statement, here:
http://www.fsf.org/blogs/licensing/do-githubs-updated-ter...
They seem to pretty much follow the arguments I bring forward in the article as well. The TL;DR is basically that the ToS are unclear, should be clarified, but are not a threat to free software, and you should of course host your stuff elsewhere, but for other reasons than the ToS, mostly...
An update to GitHub's terms of service
Posted Mar 8, 2017 20:03 UTC (Wed) by TMM (subscriber, #79398) [Link]
NotABug.org is ran by volunteers and we have no business model other than "If we get so many users it gets to expensive to run we'll ask for donations."
We're working on a federated version of the software now, we're expecting to launch 'nab 2.0' in the next month or so with this new software, which will of course be licensed under a free license without a CLA and no 'open core' model. :)
Email us if you have any questions!
An update to GitHub's terms of service
Posted Mar 9, 2017 4:11 UTC (Thu) by pabs (subscriber, #43278) [Link]
An update to GitHub's terms of service
Posted Mar 9, 2017 11:40 UTC (Thu) by robbe (guest, #16131) [Link]
... or, in other words, your regexp did not match.
An update to GitHub's terms of service
Posted Mar 22, 2017 6:03 UTC (Wed) by flussence (subscriber, #85566) [Link]
I don't need a login session cookie before I log in, a CSRF protection cookie isn't necessary either if I'm browsing around unauthenticated and have no edit permissions for anything, and I don't need a persistent language cookie (that's what the Accept-Language request header is for).
I know the site is well-intentioned and it's just careless design on upstream's part, but it's not much more effort to put right (when you're already working on the code) than to write out a section in the privacy policy to justify it.
An update to GitHub's terms of service
Posted Mar 10, 2017 19:44 UTC (Fri) by mina86 (guest, #68442) [Link]
An update to GitHub's terms of service
Posted Mar 10, 2017 19:50 UTC (Fri) by TMM (subscriber, #79398) [Link]
An update to GitHub's terms of service
Posted Mar 10, 2017 21:09 UTC (Fri) by mina86 (guest, #68442) [Link]
An update to GitHub's terms of service
Posted Mar 10, 2017 23:29 UTC (Fri) by TMM (subscriber, #79398) [Link]
An update to GitHub's terms of service
Posted Mar 9, 2017 0:02 UTC (Thu) by smurf (subscriber, #17840) [Link]
> necessarily involves distribution of software to others, and they
> put my software in it, would that be allowed by this or not?
Maybe I'm dumb, but why should that be a problem? Github presumably provides the source code, therefore this hypothetical business model would comply with the GPL. So would, presumably, any other model that doesn't hide the source code.
An update to GitHub's terms of service
Posted Mar 9, 2017 18:00 UTC (Thu) by joey (guest, #328) [Link]
An update to GitHub's terms of service
Posted Mar 9, 2017 12:18 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]
Similarly, I just don't have so much skin in the game with code on GitHub, but I'm grateful for those that do and who strive to keep the whole ecosystem stable.
An update to GitHub's terms of service
Posted Mar 9, 2017 22:50 UTC (Thu) by ejr (subscriber, #51652) [Link]
An update to GitHub's terms of service
Posted Mar 10, 2017 14:51 UTC (Fri) by pizza (subscriber, #46) [Link]
Because most mail clients are atrotious, and folks aren't willing to do things differently.
(It's a social problem, not technical one..)
ToS matter I think
Posted Mar 16, 2017 4:57 UTC (Thu) by Garak (guest, #99377) [Link]
https://lwn.net/Articles/658006/
Paraphrased- to do anything fun on the internet requires the ability to host your own arbitrary server without begging permission from a gatekeeper ISP first. If everyone could do that, we'd see something that looks like a cross between godzilla and squirrelmail within a month. Maybe one of these days someone will have a nice library to layer IP over WebRTC and we can have fun with UDP and TCP again. Sigh, Mozilla will not save us (they care too much about paying their high silicon valley rents).
