As far as I can find, neither the FSF nor the GNUnet project [0] has
officially commented (did GNUnet even know that those GitHub mirrors of
it existed? they weren't its primary repository, as the FSF already had
a policy of not hosting on GitHub for different reasons [1]). It has
been mentioned on an FSF mailing list [2], but with the same links we
already have here.
I find it unlikely that GitHub *intended* the scarier interpretations,
as they seem likely to hurt rather than help GitHub:
-Using these extra rights to take apparently-copylefted projects
proprietary? Seems unlikely to be more profitable than doing the same
to an intentionally permissive-licensed project:
--The new terms explicitly don't grant GitHub the right to sell the content.
--The PR consequences would be more negative, as people would feel cheated.
--If they wanted large projects, they'd need to wait long enough for new
ones to form and grow (as already-large projects are likely to have had
some contributors who became inactive before the change), and even then
it's likely that the project would have copied from other projects or
accepted patches sent to it outside GitHub, which would make this
legally dangerous.
--Anyone who had the free version could still distribute it (elsewhere),
and while the proprietary version could avoid mentioning this, this is
unlikely to be much more effective than what's allowed with a BSD
project (can't *remove* the license notice, but *can* hide it in an
obscure part of the documentation and/or change the project name).
-Trying to scare away people who consider free-as-in-freedom important,
on the grounds that they'll never use the private repository or
on-premises hosting services that are what GitHub actually makes money
on? Likely to also lose them a higher number of people they would want:
project owners who see free-as-in-freedom as a good thing but not an
absolute moral rule, and don't-care contributors following a project
that left.
-Trying to generally reduce the size (and hence hosting cost) of the
free service? More use of their existing "excessively resource-heavy
projects may be asked/required to cut down or leave" rule and/or
explicit size restrictions would make far more sense.
However, I would prefer to see the uncertainty cleared up.
(Note that if there is a problem, it's not necessarily specific to
copylefted projects: might the waiver of your right to attribution be
interpreted as a prohibition on uploading content in which someone else
has a right to attribution?)
[0] https://gnunet.org/ ,
http://lists.gnu.org/archive/html/gnunet-developers/
[1] https://www.gnu.org/software/repo-criteria-evaluation.html
[2]
http://lists.gnu.org/archive/html/repo-criteria-discuss/2017-03/msg00002.html
