Página principal de PROFESIONALESPCM.ORG Página principal de PROFESIONALESPCM.ORG Afíliate el Partido Comunista de España

ESPACIO 2017 - Centenario de la Revolució Soviética!

Sección: Software y Conocimiento Libre

Título: Do GitHub's updated terms of service conflict with copyleft?- Enlace 1

Texto del artículo:

Do GitHub's updated terms of service conflict with copyleft?

GitHub's updated terms caused a great deal of concern, but while they are confusing, they do not appear to be incompatible with
copyleft. The Free Software Foundation (FSF), though, still recommends using other code hosting sites.

GitHub recently updated their terms of service (ToS). Users of
the site are raising many concerns over the new terms, fearing that
the ToS could be incompatible with the copyleft licenses on works
uploaded to GitHub. In particular, section D of the new terms, which
handles rights granted to GitHub and GitHub users, makes many hackers
very uncomfortable.

Section D.4 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. " At first
glance that might appear to grant permissions on your work without the
concomitant protective guarantees found in copyleft licenses like the
GNU General Public License (GPL). Users who care about ensuring
that their software never becomes proprietary would not want to give
such unconditional permission. And those uploading works that
incorporate third-party copylefted code may not even be able to grant
such permissions.

But licenses like the GNU GPL already give the necessary permissions
to make, use, and modify local copies of a work. Are the new GitHub
ToS asking for more than that? It's not fully clear. While the grant
language could fit within the scope of the GPL, other words used in
the section like "share" or "distribute" could be understood to mean
something that wouldn't line up with the GPL's terms.

We find a similar situation in D.5 of the ToS, which states, "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." Again, looking at the
terms, one could get the impression that GitHub is asking you to grant
unconditioned permissions on your work, this time to other users of
GitHub. But once more, licenses like the GPL already allow users to
download a covered work and make their own local modifications. It
isn't clear that GitHub is asking for anything more than that. Further
to the point, the new terms do not appear to be radically different
from those found in the previous ToS.

We understand why users are concerned; the terms are difficult to
parse. This is a general problem with terms of service and end-user
license agreements. With the protections provided by copyleft licenses
at risk, users are particularly cautious. Because it's highly unlikely
that GitHub intended to destroy their business model and user base, we
don't read the ambiguity in the terms as granting or requiring overly
broad permissions outside those already granted by the GPL. It would
be inconsistent with changes they made last year on
choosealicense.com to treat copyleft better. The relevant sections of
the ToS seem to be just restatements of typical free license terms.
But some added clarity—to say that if the uploaded work already
comes with a license granting GitHub the permissions it needs to run
its service, no additional license is required—would go a long way
towards quelling the confusion, and we hope GitHub will do another
revision soon to add it.

If you are concerned, then by all means stop uploading your code to
GitHub. GNU previously granted GitHub a grade of "F" according to its
Ethical Repository Criteria, for a number of reasons important to
those seeking to have their freedom respected as users and to respect
the freedom of others, including that important functionality on the
site requires the use of proprietary JavaScript.

The FSF has been in contact with GitHub about both the ToS and the
other software freedom issues. We will continue to do what we can to
get the ToS ambiguities clarified, to remove doubts about their
compatibility with the important protections provided by copyleft
licenses. Here's what you can do to help: