It seems like this may not be entirely reliable. See one of a handful of refutals posted already.
That’s my reading, here- this is much-ado about the standard sort of text for any file hosting service. “Look, we’re going to need to make copies of your stuff, and sometimes when we show it, we’re only going to show parts of it, so, y'know, just FYI. Don’t come yelling at us if this somehow violates a license, blame whoever put the code here.”
Short version: the new license effectively gives a BSD-like, transferable license to all projects hosted on Github and raises issues with attribution requirements of other licenses.
Update: after reviewing a few other comments, I’m not sure it’s the case. But that’s the point made in the article of course. :)
Relevant part of TOS: https://help.github.com/articles/github-terms-of-service/#d-user-generated-content
Your Content belongs to you, and you are responsible for Content you post even if it does not belong to you. However, we need the legal right to do things like host it, publish it, and share it. 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.
That means you’re giving us the right to do things like reproduce your content (so we can do things like copy it to our database and make backups); display it (so we can do things like show it to you and other users); modify it (so our server can do things like parse it into a search index); distribute it (so we can do things like share it with other users); and perform it (in case your content is something like music or video).
This license does not grant GitHub the right to sell your Content or otherwise distribute it outside of our Service.
Any Content you post publicly, including issues, comments, and contributions to other Users' repositories, may be viewed by others. By setting your repositories to be viewed publicly, you agree to allow others to view and “fork” your repositories (this means that others may make their own copies of your Content in repositories they control).
If you set your pages and repositories to be viewed publicly, 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. You may grant further rights if you adopt a license.
Whenever you make a contribution to a repository containing notice of a license, you license your contribution under the same terms, and you agree that you have the right to license your contribution under those terms. If you have a separate agreement to license your contributions under different terms, such as a contributor license agreement, that agreement will supercede.
Isn’t this just how it works already? Yep. This is widely accepted as the norm in the open-source community; it’s commonly referred to by the shorthand “inbound=outbound”. We’re just making it explicit.
I must say, sadly, the discussion here right now is not up to the usual standard of rigor and sobriety we have come to hold ourselves to.
He does raise a valid point. If the code I want to publish is GPL’d, and I’m not the original author, just someone who forked it, how am I allowed to put that code on github???
I don’t think it’s just an issue for GPL and other copyleft licenses but BSD/MIT/ISC as well since they also require attribution. If you aren’t the copyright holder, how can you possibly grant a license exception for someone else’s work? GitHub has essentially stated that they are exempt from the one and only requirement of the ISC license.
[Comment removed by author]
Don’t forget that there are quite a few git web servers that provide a decent amount of what Github does, between Gitlab, Gogs and Gitweb.
If you want to self-host, and are willing to learn a different SCM, I can also recommend fossil
darcs and pijul are already there, they’re just not terribly popular in comparison to git. And many organizations (most companies, at least) lean towards a central pattern, anyway.
Check out git-ssb, a decentralized Github alternative (so issues as well as repo hosting). It’s built on top of secure scuttlebutt, an up and coming decentralized network protocol.
This is a link to a list of posts. The post’s permalink is https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm.
Although I don’t necessarily like GitHub, this interpretation of the ToS strikes me as rather unusual. Point by point:
Section D.7 requires the person uploading content to waive any and all attribution rights.
This is not true in this broad sense. §D.7 first asserts “You retain all moral rights to Content you upload”, which sets the general direction. The next sentence is what the author is hanging up on: “However, you waive these rights” — now continue reading and you see the sentence continues: “and agree not to assert them against us,”. The further explanation in that sentence and the subsequent grant of rights paragraph make clear that you grant the waiver only to GitHub Inc. and not to anybody else.
It is true that you cannot waive rights you don’t own, though. The one true point in this critique is that uploading works not owned by you (or for which you don’t have the rights to grant waivers) is probably a bad idea now.
Section D.5 requires the uploader to grant all other GitHub users… the right to “use, display and perform” the work
This is nonsense. The author likes to not read complete sentences it appears and tear them all apart. While his interpration is possible, it would basically contradict the entire environment of the snippet he quotes. Let me put this straight by counterquoting with an elision:
If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to […] use, display and perform your Content […] solely on GitHub as permitted through GitHub’s functionality.
If read like that, it is clear that you grant these rights only for use on GitHub and not anywhere else. It only declares now finally legal which is perceived as normal: If you upload something publically to GitHub, you want that people can look on it and you want people can use the “fork” button on it. Also please note that the clause explicitely only refers to public repositories.
Anything requiring integrity of the author’s source
I’m not sure what the author is getting at here. I think he worries that GitHub may remove some content from your repository while leaving the rest intact, thereby making you an infringer of the LPPL (LaTeX Project Public License) which appearently forbids such partial removal (I haven’t checked the LPPL, I just assume this is true in the following). If GitHub doesn’t notify you of such partial removal, you should be able to successfully argue that you didn’t know, which should get you off all liability other than removal of the content. If GitHub does notify you of their removal (almost certainly), you have enough time to conduct a complete removal. As a side note, in such a case GitHub would probably actually break the LPPL on its own also as they distribute the partial repository.
This means that repositories from people who last used GitHub before March 2017 are excluded.
Rather not. If you have an account and have not explicitely disagreed with the ToS, you’re in, regardless of whether you used or not used GitHub.
My conclusion: Much ado about nothing. Don’t upload content you don’t own (which you shouldn’t anyway), and you’re fine.
FYI: I’m a law student.
Following this, Joey Hess has already removed his git mirrors from Github…
It’s best to host your code repository yourself, this is what our focus was since few years. Open source code management such as RhodeCode or Gitlab is always better when it comes to privacy and security.
While I definitely see the benefit of hosting your own repositories as a primary source, I would make the addendum that if you want to do this, you should have a mirror on GitHub. There’s a lot to be said for the centralized repository of open source code that GitHub has become, for contributors and users alike.
I don’t know about gitlab, but RhodeCode is very easy to deploy as it has a great installer based on NIX package manager. You can have it running in minutes without configuring anything
RhodeCode is very easy to deploy
Unless you are on a non-linux system :P
I recently tried to get RhodeCode up and running on OpenBSD - It doesn’t seem to be a trivial task. Is there something I am missing for other OS’s? or are they just not supported?
We have a strict OS check in installer, we’ll look into this.
Btw, you can download the sources of community edition, and after installing nix package manager on OpenBSD, run nix-shell to see if it would work on your system
Unfortunately, the requirement to have an external package management system (outside of the ports framework) is another showstopper.
Isn’t the Linux kernel hosted on GitHub? Wouldn’t it technically run afoul of these terms?
It isn’t officially hosted on GitHub, it is hosted on https://www.kernel.org. The repository on GitHub is a mirror.
Potentially shooting themselves in the foot. Git isn’t a Facebook silo. The repo is highly portable. The metadata such as description, issues and releases can be replicated lossily, but it wouldn’t be the end of the world. The worst case for github would be if a large percentage of projects decided to up and leave off their own bat, which is unlikely, but is a risk with any policy change.
I expect the big thing tying projects to GitHub would be all the integrations—CI systems, code review helpers, test-coverage tracking, automated merge-bots, the usual workflow stuff.
Can someone change this URL to https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm? The main traffic is over so we are no longer DOS'ing the site, but it still would be nice given that the author has requested it. Thanks!