|
|
Subscribe / Log in / New account

An update to GitHub's terms of service

March 8, 2017

This article was contributed by Antoine Beaupré

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 historically had an anti-copyleft culture, which was created in large part by their former and now ousted CEO, Preston-Warner. However, recently, I've seen people at GitHub truly reach out to me and others in the copyleft community to learn more and open their minds. I thus have a hard time believing that there was some anti-copyleft conspiracy in this ToS change.

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
GuestArticlesBeaupré, Antoine


to post comments

An update to GitHub's terms of service

Posted Mar 8, 2017 11:08 UTC (Wed) by Lekensteyn (guest, #99903) [Link] (1 responses)

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.

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.

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.

An update to GitHub's terms of service

Posted Mar 8, 2017 12:39 UTC (Wed) by juliank (guest, #45896) [Link]

The license is likely intended to be a default, but it's not really written that way. The ToS includes its own additional license grant, whereas it should defer to the chosen license if that license is sufficient.

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] (2 responses)

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]

I actually setup a Gitea instance to replaces my gitolite+cgit setup I had previously. I found out about it because of all the news/discussion about github's new ToS. Couldn't be happier with it so far.

An update to GitHub's terms of service

Posted Mar 9, 2017 13:34 UTC (Thu) by robbe (guest, #16131) [Link]

I would expect something like Gitea to self-host … not point people at their github presence. Dogfood and all.

An update to GitHub's terms of service

Posted Mar 8, 2017 15:27 UTC (Wed) by joey (guest, #328) [Link] (2 responses)

I'm trying to understand Bkuhn's "ultimately, failure to comply with a copyleft license is a copyright infringement" statement.

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]

I think that your interpretation of TOS is a nightmare also for github.

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]

> 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."

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] (7 responses)

This is a bit of a plug, but we've been running a github-style site based off of Gogs for more than 2 years now at https://notabug.org. Our terms of service are here: https://notabug.org/tos

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] (2 responses)

s/sets three cookies in your browser/requests your browser to set three cookies/

An update to GitHub's terms of service

Posted Mar 9, 2017 11:40 UTC (Thu) by robbe (guest, #16131) [Link]

input == output

... 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 (guest, #85566) [Link]

That three could be reduced to zero in the common case (an anonymous visitor):

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] (3 responses)

This probably isn’t the best forum to ask the question, but do you guys have a script or something which would let me mass-migrate from GitHub to NotABug?

An update to GitHub's terms of service

Posted Mar 10, 2017 19:50 UTC (Fri) by TMM (subscriber, #79398) [Link] (2 responses)

You can migrate your git repos easy enough. For issues and pr we haven't got a solution yet. In nab 2.0 we'll have it, we're expecting to release that in about a month.

An update to GitHub's terms of service

Posted Mar 10, 2017 21:09 UTC (Fri) by mina86 (guest, #68442) [Link] (1 responses)

But if I have 40 repositories, I have to go through the mirroring/migration web UI work-flow 40 times. I was hoping for a script which would do that for me.

An update to GitHub's terms of service

Posted Mar 10, 2017 23:29 UTC (Fri) by TMM (subscriber, #79398) [Link]

Send me an email on the address listed on notabug.org and I'll write you a script for use with the somewhat underdocumented API we have. :)

An update to GitHub's terms of service

Posted Mar 9, 2017 0:02 UTC (Thu) by smurf (subscriber, #17840) [Link] (1 responses)

> 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?

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]

If github had a non-GPL license to normally GPLed software, they could modify software and not distribute the modifications.

An update to GitHub's terms of service

Posted Mar 9, 2017 12:18 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]

I'm not interested in being a paramedic, but I'm glad that others are.
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] (2 responses)

So why has email failed so horribly? The combination of gitorious, cgit, and mailed patches (preferably with a gateway to NNTP for the archives) works fantastically for me. But I'm old.

An update to GitHub's terms of service

Posted Mar 10, 2017 14:51 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> So why has email failed so horribly?

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]

Coincidentally I believe the social problem is tied directly to an entirely different ToS issue-

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).


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds