[gnutls-help] The development list is now read-only

Ludovic Courtès ludo at gnu.org
Thu Jul 19 14:39:22 CEST 2018

Hi Nikos,

Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> skribis:

> On Mon, 2018-07-16 at 14:27 +0200, Ludovic Courtès wrote:


>> Gitlab.com’s ToS contain fairly obnoxious terms.  In particular,
>> Section
>> 15 uses broad wording that I’m uncomfortable with:
>>   15. Indemnification
>>   You agree to indemnify and hold harmless GitLab, its affiliates,
>> […]
>>   from and against any and all claims and expenses, including
>> attorneys’
>>   fees […]
>> I wouldn’t want my savings to go to GitLab’s attorneys should someone
>> attack them for something vaguely related to GnuTLS.
> I am not a lawyer and I cannot offer any advice on that. It does not
> look unreasonable to me however, that gitlab wouldn't want to take the
> blame for something the gnutls project may be sued for.

People could sue them based on incorrect allegations about GnuTLS, and
you would personally pay for their attorneys.  This is hopefully an
unlikely scenario, but it’s one GitLab protects itself against, so each
one of us might want to protect themself against it as well.

What bothers me (but it’s a problem that goes beyond GnuTLS, of course)
is that I would end up signing a contract with a company I don’t want to
deal with, possibly taking risks, when all I want is to contribute my
time to a free software project I care about.

I’m happy to engage in a “moral contract” with contributors to the
project.  I’m not interested in having to sign a contract with a company
that has nothing to do with the project.

Free software started as work done by the people for the people.  We
used to rely a lot on non-profits to host our services (the FSF, Gna!,
Tux Family, and so on) and the mission of these non-profits is/was
precisely to support our free development efforts.  We built the
commons.  Now that companies with different interests are in charge of
some of our critical infrastructure, free software development seems to
be more vulnerable: hosting sites close, companies are bought, ToS
change, we have a distributed VCS but everything else is centralized,

I don’t have a good solution but since you already have the services in
place, I’d suggest keeping the mailing list accessible and making it
clear that patches are also accepted through that medium.


Thanks for listening.  :-)


PS: I wasn’t planning to join this discussion since I haven’t really
    contributed to GnuTLS in recent years, but I was reminded of this
    situation when gitlab.com rejected a “git push” from me in another
    project unless I signed their new ToS.

More information about the Gnutls-help mailing list