Advertisement
lowfatcomputing

New GitHub Terms of Service require removing many ...

Mar 1st, 2017
126
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 5.41 KB | None | 0 0
  1. MIRROR of https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm
  2.  
  3. New GitHub Terms of Service require removing many Open Source works from it 01.03.2017 by tg@
  4. Tags: bug debian event grml news pcli rant security tip work
  5. The new Terms of Service of GitHub became effective today, which is quite problematic — there was a review phase, but the problems were not answered, and, while the language is somewhat changed from the draft, they became effective immediately.
  6.  
  7. Now, the new ToS are not so bad that one immediately must stop using their service for disagreement, but it’s important that certain content may no longer legally be pushed to GitHub. I’ll try to explain which is affected, and why.
  8.  
  9. I’m mostly working my way backwards through section D, as that’s where the problems I identified lie, and because this is from easier to harder.
  10.  
  11. Note that using a private repository does not help, as the same terms apply.
  12.  
  13. Anything requiring attribution (e.g. CC-BY, but also BSD, …)
  14.  
  15. Section D.7 requires the person uploading content to waive any and all attribution rights. Ostensibly “to allow basic functions like search to work”, which I can even believe, but, for a work the uploader did not create completely by themselves, they can’t grant this licence.
  16.  
  17. The CC licences are notably bad because they don’t permit sublicencing, but even so, anything requiring attribution can, in almost all cases, not “written or otherwise, created or uploaded by our Users”. This is fact, and the exceptions are few.
  18.  
  19. Anything putting conditions on the right to “use, display and perform” the work and, worse, “reproduce” (all Copyleft)
  20.  
  21. Section D.5 requires the uploader to grant all other GitHub users…
  22.  
  23. the right to “use, display and perform” the work (with no further restrictions attached to it) — while this (likely — I didn’t check) does not exclude the GPL, many others (I believe CC-*-SA) are affected, and…
  24. the right to “reproduce your Content solely on GitHub as permitted through GitHub's functionality”, with no further restructions attached; this is a killer for, I believe, any and all licences falling into the “copyleft” category.
  25. Note that section D.4 is similar, but granting the licence to GitHub (and their successors); while this is worded much more friendly than in the draft, this fact only makes it harder to see if it affects works in a similar way. But that doesn’t matter since D.5 is clear enough.
  26.  
  27. This means that any and all content under copyleft licences is also no longer welcome on GitHub.
  28.  
  29. Anything requiring integrity of the author’s source (e.g. LPPL)
  30.  
  31. Some licences are famous for requiring people to keep the original intact while permitting patches to be piled on top; this is actually permissible for Open Source, even though annoying, and the most common LaTeX licence is rather close to that. Section D.3 says any (partial) content can be removed — though keeping a PKZIP archive of the original is a likely workaround.
  32.  
  33. But what if I just fork something under such a licence?
  34.  
  35. Only “continuing to use GitHub” constitutes accepting the new terms. This means that repositories from people who last used GitHub before March 2017 are excluded.
  36.  
  37. Even then, the new terms likely only apply to content uploaded in March 2017 or later (note that git commit dates are unreliable, you have to actually check whether the contribution dates March 2017 or later).
  38.  
  39. And then, most people are likely unaware of the new terms. If they upload content they themselves don’t have the appropriate rights (waivers to attribution and copyleft/share-alike clauses), it’s plain illegal and also makes your upload of them or a derivate thereof no more legal.
  40.  
  41. Granted, people who, in full knowledge of the new ToS, share any “User-Generated Content” with GitHub on or after 1ˢᵗ March, 2017, and actually have the appropriate rights to do that, can do that; and if you encounter such a repository, you can fork, modify and upload that iff you also waive attribution and copyleft/share-alike rights for your portion of the upload. But — especially in the beginning — these will be few and far between (even more so taking into account that GitHub is, legally spoken, a mess, and they don’t even care about hosting only OSS / Free works).
  42.  
  43. Conclusion (Fazit)
  44.  
  45. I’ll be starting to remove any such content of mine, such as the source code mirrors of jupp, which is under the GNU GPLv1, now and will be requesting people who forked such repositories on GitHub to also remove them. This is not something I like to do but something I am required to do in order to comply with the licence granted to me by my upstream. Anything you’ve found contributed by me in the meantime is up for review; ping me if I forgot something. (mksh is likely safe, even if I hereby remind you that the attribution requirement of the BSD-style licences still applies outside of GitHub.)
  46.  
  47. (Pet peeve: why can’t I “adopt a licence” with British spelling? They seem to require oversea barbarian spelling.)
  48.  
  49. The others
  50.  
  51. Atlassian Bitbucket has similar terms (even worse actually; I looked at them to see whether I could mirror mksh there, and turns out, I can’t if I don’t want to lose most of what few rights I retain when publishing under a permissive licence). Gitlab seems to not have such, but requires you to indemnify them… YMMV. I think I’ll self-host the removed content.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement