From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 59A6B138350 for ; Tue, 5 May 2020 16:30:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8CE02E09C8; Tue, 5 May 2020 16:30:36 +0000 (UTC) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 80683E09C8 for ; Tue, 5 May 2020 16:30:36 +0000 (UTC) Received: by mail-io1-xd2d.google.com with SMTP id i19so2574162ioh.12 for ; Tue, 05 May 2020 09:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oBhd5uM1rEoF/3v2+2CnKO7oXrvYs4MfsOBnOL9KPeU=; b=fdvnC4gYe/4vUPLs0JbbI8Ilse1eZ0+GKbAT+mNlQ8pTNKVw4dJVGKNyM2s1aK1yPx Td3DJwUTnI3/N/3ifLfc05MdOmvEcC0DXpyodzZ8BceVm1UHKjPNWA5Th7a8MTtDYd+5 8N3ydvl56iDKLH9tSd+aMaYxmy40ksa2J3yZIoLpQtgQd5vo5MzltDdwsfgTuRpJrYjm XqO9NGXQXkAfbNJtfrG5pp7knPnWePVaTd76TwrQ3RW1tl7t8Nl/eoWuBxsyz0OZ/2l2 K2isn/kBRypEWFYiabdQ8X6DKJrTWA3ULLyjcpGcENDPIaIxQm+1PVgP5kzHTVpEUuvZ QQpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=oBhd5uM1rEoF/3v2+2CnKO7oXrvYs4MfsOBnOL9KPeU=; b=DGQQK3K++GWE82Byi0sqMwSlN5MJv6Ro4lAYykceJT2J3KpEG3OqfrVq38awzCw7OB OcQWqcNt7XIgJCz7rhdZm1zDCMVJf738CgxCxgRRrQXlz3T5h9b7Z9ThLudC5qZ3VM1i SpESMmlcn/y4iIJUHoPormj6xzR+areBftgBskc08NGHwD7NW5atieYWQyz6zoxZeY63 9m/HpFisWEP5fqAdvdo7Xvo1pc5wevtl7/x5UR6TRN2FoNHI7l+5ER1DaVvYBAShUfE7 KhbEGrofkYRY1Vz2IfMUZi6XIYroOm8Jh+RUuQbUopsflK38a01piafczxVrbDtlAae6 uBDQ== X-Gm-Message-State: AGi0PuaSoDNMmb98D2cOrK3GSsGczSA/zbuqE3sH3K//uVMOMcz0M43w jqrbSu9vSA3pafGCKSfExHcQ4rWD8bNAO5NjEdKEiw== X-Google-Smtp-Source: APiQypIMrTXTRZXh9W6rPtQiXdWeusp7XH//Hn6GDiu1SxD64U05PhkCuM3SGL6aCpb5YEmIWP7zymixwGeO0IKgvrE= X-Received: by 2002:a5d:9493:: with SMTP id v19mr4361476ioj.34.1588696235227; Tue, 05 May 2020 09:30:35 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-nfp@lists.gentoo.org Reply-To: gentoo-nfp@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <8a3cbd9f1e7287ed3a8335a88cc58a791c231564.camel@gentoo.org> In-Reply-To: From: Raymond Jennings Date: Tue, 5 May 2020 09:29:59 -0700 Message-ID: Subject: Re: [gentoo-nfp] Social contract and its effect on upstream software choices To: gentoo-nfp Content-Type: multipart/alternative; boundary="000000000000c1bd1705a4e92ab4" X-Archives-Salt: f672f696-7bcb-4173-9d44-a61e2ced5f57 X-Archives-Hash: 07ed74d8a34200d35583c0d921f61507 --000000000000c1bd1705a4e92ab4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 5, 2020 at 9:13 AM Alec Warner wrote: > On Tue, May 5, 2020 at 1:46 AM Micha=C5=82 G=C3=B3rny = wrote: > >> On Thu, 2020-04-30 at 23:11 -0700, Alec Warner wrote: >> > Consider a case where we have a piece of software and its open source. >> The >> > open source software has various plugins, some of which look useful an= d >> we >> > may wish to deploy them for Gentoo. However, we must consider the soci= al >> > contract, hence this discussion. >> >> First of all, I don't think this should be really about whether we can >> bend the social contract to find X acceptable but whether the particular >> case meets the rationale behind using FLOSS. >> >> > Can we use the plugins if: >> > (1) They are closed source (e.g. upstream provides binaries only with= a >> > restricted non-free license.) >> >> No. That would mean we're fully dependent on upstream providing up-to- >> date and working binaries. If upstream decides to cease providing them >> or simply disappears, we're stuck with software that can become broken >> at any point and we couldn't fix it. >> >> > (2) They are free software (e.g. FSF / OSI approved license) but they >> cost >> > money. >> >> Presuming they're really free software, i.e. unlike grsecurity upstream >> does actually permit redistributing it, I suppose that's acceptable. >> However, I'd find it a bit weird to pay for something if it can be >> redistributed for free. >> >> Of course, if we're talking about making donation to upstream or funding >> a bounty for software we need, that's another thing. >> >> > (b) A subset, its free software and it costs money but it is free f= or >> > open source communities to use. >> >> Same as above. Though I can't imagine why anyone would create such >> a thing as it basically means the first 'open source community' to get >> it would be able to redistribute it without limitations. >> >> > (3) They are open source, but not free (e.g. they have some kind of >> open >> > license but are not FSF / OSI approved.) >> >> If the license permits us to use, modify and redistribute it without >> limitations, I don't see a problem with it. >> >> > (4) They are open source (and free), but we have chosen to use the >> built >> > plugins (rather than building from source) for the sake of time and >> > convenience. >> >> I think it's acceptable but not preferable. The key point here would be >> that if we ever had to patch it, we'd suddenly have to jump through >> a bunch of hoops. >> >> Overall, I think the key point is maintainability here. Whenever we use >> proprietary software, we're on upstream's mercy. On the other hand, >> if we use free software, we can tailor it to our needs and maintain it >> with help of our community if upstream ceases to do so. >> >> However, I suppose this discussion could bring better answers if you >> were more specific. Otherwise, one wonders whether you have some >> disagreeable idea in mind and are asking generic questions to justify it >> without having people get emotional about specifics. >> > > The point of this thread for me was to enumerate some areas of concern fo= r > me and get feedback on them. > My interpretation of the social contract has always been more...let's use > the term, flexible. So I appreciate this thread a lot for bringing in oth= er > views. > > The concrete example you are inferring is Gitlab[1][2], where the > Community edition (CE) is licensed under MIT and the Enterprise Edition > (EE) is licensed under the Gitlab Enterprise Edition license. Based on th= is > thread, the EE license is clearly not OK to use, so we won't be adopting > any EE features[0]. > > >> >> There's of course the part about 'needed' vs 'used without needing' >> but I don't think we ought to use it without good justification >> and some reasonable FLOSS alternative. >> >> Finally, there are edge cases like WordPress. It's apparently open >> source but it's completely unusable without a proprietary anti-spam >> plugin that sends your data to a third party. >> > > It's my personal opinion (others can disagree) that wordpress is not > critical to the operation of Gentoo. > I second this opinion, especially as there are alternatives. > > -A > > [0] Some of the EE features are 'source available' but the license is suc= h > that we cannot use those either, the EE license is pretty restrictive. > [1] We currently have gitlab CE deployed in an alpha state; so we are > currently evaluating which features we can enable. > [2] We also have a Gentoo org on gitlab.com, but it's ~unused but has > access to hosted EE features. I believe we plan on sunsetting this and > replacing it with the self-hosted CE version. > > >> -- >> Best regards, >> Micha=C5=82 G=C3=B3rny >> >> --000000000000c1bd1705a4e92ab4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, May 5, 2020 at 9:13 AM Alec Warne= r <antarus@gentoo.org> wrot= e:
On Tue, May 5, 2020 at 1:46= AM Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> wrote:
On Thu, 2020-04-30 = at 23:11 -0700, Alec Warner wrote:
> Consider a case where we have a piece of software and its open source.= The
> open source software has various plugins, some of which look useful an= d we
> may wish to deploy them for Gentoo. However, we must consider the soci= al
> contract, hence this discussion.

First of all, I don't think this should be really about whether we can<= br> bend the social contract to find X acceptable but whether the particular case meets the rationale behind using FLOSS.

> Can we use the plugins if:
>=C2=A0 (1) They are closed source (e.g. upstream provides binaries only= with a
> restricted non-free license.)

No.=C2=A0 That would mean we're fully dependent on upstream providing u= p-to-
date and working binaries.=C2=A0 If upstream decides to cease providing the= m
or simply disappears, we're stuck with software that can become broken<= br> at any point and we couldn't fix it.

>=C2=A0 (2) They are free software (e.g. FSF / OSI approved license) but= they cost
> money.

Presuming they're really free software, i.e. unlike grsecurity upstream=
does actually permit redistributing it, I suppose that's acceptable. However, I'd find it a bit weird to pay for something if it can be
redistributed for free.

Of course, if we're talking about making donation to upstream or fundin= g
a bounty for software we need, that's another thing.

>=C2=A0 =C2=A0 (b) A subset, its free software and it costs money but it= is free for
> open source communities to use.

Same as above.=C2=A0 Though I can't imagine why anyone would create suc= h
a thing as it basically means the first 'open source community' to = get
it would be able to redistribute it without limitations.

>=C2=A0 (3) They are open source, but not free (e.g. they have some kind= of open
> license but are not FSF / OSI approved.)

If the license permits us to use, modify and redistribute it without
limitations, I don't see a problem with it.

>=C2=A0 (4) They are open source (and free), but we have chosen to use t= he built
> plugins (rather than building from source) for the sake of time and > convenience.

I think it's acceptable but not preferable.=C2=A0 The key point here wo= uld be
that if we ever had to patch it, we'd suddenly have to jump through
a bunch of hoops.

Overall, I think the key point is maintainability here.=C2=A0 Whenever we u= se
proprietary software, we're on upstream's mercy.=C2=A0 On the other= hand,
if we use free software, we can tailor it to our needs and maintain it
with help of our community if upstream ceases to do so.

However, I suppose this discussion could bring better answers if you
were more specific.=C2=A0 Otherwise, one wonders whether you have some
disagreeable idea in mind and are asking generic questions to justify it without having people get emotional about specifics.
<= br>
The point of this thread for me was to enumerate some areas o= f concern for me and get feedback on them.
My interpretation of t= he social contract has always been more...let's use the term, flexible.= So I appreciate this thread a lot for bringing in other views.
<= br>
The concrete example you are inferring is Gitlab[1][2], where= the Community edition (CE) is licensed under MIT and the Enterprise Editio= n (EE) is licensed under the Gitlab Enterprise Edition license. Based on th= is thread, the EE license is clearly not OK to use, so we won't be adop= ting any EE features[0].
=C2=A0

There's of course the part about 'needed' vs 'used without = needing'
but I don't think we ought to use it without good justification
and some reasonable FLOSS alternative.

Finally, there are edge cases like WordPress.=C2=A0 It's apparently ope= n
source but it's completely unusable without a proprietary anti-spam
plugin that sends your data to a third party.

It's my personal opinion (others can disagree) that wordpress is= not critical to the operation of Gentoo.

I second this opinion, especially as there are alternative= s.
=

-A

=
[0] Some of the EE features are 'source available' but the lic= ense is such that we cannot use those either, the EE license is pretty rest= rictive.
[1] We currently have gitlab CE deployed in an alpha= state; so we are currently evaluating which features we can enable.
<= /div>
[2] We also have a Gentoo org on gitlab.com, but it's ~unused but has access to host= ed EE features. I believe we plan on sunsetting this and replacing it with = the self-hosted CE version.=C2=A0


--
Best regards,
Micha=C5=82 G=C3=B3rny

--000000000000c1bd1705a4e92ab4--