MirOS: "New GitHub Terms of Service /require/ removing many Open Source works from it"

Moritz Bartl moritz at headstrong.de
Wed Mar 1 22:21:23 UTC 2017


Opinions? My initial gut feeling is "I don't believe this is true", but
I haven't had the time to go through it and review properly.

https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm#e20170301-tg_wlog-10

Thorsten Glaser, 1.3.2017
MirOS: New GitHub Terms of Service /require/ removing many Open Source
works from it

The new Terms of Service of GitHub became effective today, which is
quite problematic — there was a review phase, but my reviews pointing
out the problems were not answered, and, while the language is somewhat
changed from the draft, they became effective immediately.

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.

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.

Note that using a private repository does not help, as the same terms apply.
Anything requiring attribution (e.g. CC-BY, but also BSD, …)

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.

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.
Anything putting conditions on the right to “use, display and perform”
the work and, worse, “reproduce” (all Copyleft)

Section D.5 requires the uploader to grant all other GitHub users…

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

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.

This means that any and all content under copyleft licences is also no
longer welcome on GitHub.
Anything requiring integrity of the author’s source (e.g. LPPL)

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.
Affected licences

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. BSD-style licences without advertising clause (MIT/Expat,
MirOS, etc.) are probably not affected… if GitHub doesn’t go too far and
dissociates excerpts from their context and legal info, but then nobody
would be able to distribute it, so that’d be useless.
But what if I just fork something under such a licence?

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.

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

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.

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).
Conclusion (Fazit)

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

(Pet peeve: why can’t I “adopt a licence” with British spelling? They
seem to require oversea barbarian spelling.)
The others

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.
And now?

I’m in contact with someone from GitHub Legal (not explicitly in the
official capacity though) and will try to explain the sheer magnitude of
the problem and ways to solve this (leaving the technical issues to
technical solutions and requiring legal solutions only where strictly
necessary), but for now, the ToS are enacted (another point of my
criticism of this move) and thus, the aforementioned works must go off
GitHub right now.

That’s not to say they may not come back later once this all has been
addressed, if it will be addressed to allow that. The new ToS do have
some good; for example, the old ToS said “you allow every GitHub user to
fork your repositories” without ever specifying what that means. It’s
just that the people over at GitHub need to understand that, both
legally and technically¹, any and all OSS licences² grant enough to run
a hosting platform already³, and separate explicit grants are only
needed if a repository contains content not under an
OSI/OKFN/Copyfree/FSF/DFSG-free licence. I have been told that “these
are important issues” and been thanked for my feedback; we’ll see what
comes from this.

① maybe with a little more effort on the coders’ side³

② All licences on one of those lists or conformant to the DFSG, OSD or
OKD should do⁴.

③ e.g. when displaying search results, add a note “this is an excerpt,
click HERE to get to the original work in its context, with licence and
attribution” where “HERE” is a backlink to the file in the repository

④ It is understood those organisations never un-approve any licence that
rightfully conforms to those definitions (also in cases like a grant
saying “just use any OSS² licence” which is occasionally used)



More information about the Discussion mailing list