[gentoo-nfp] Social contract and its effect on upstream software choices

[gentoo-nfp] Social contract and its effect on upstream software choices

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

Hi,

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 and we
may wish to deploy them for Gentoo. However, we must consider the social
contract, hence this discussion.

Can we use the plugins if:
 (1) They are closed source (e.g. upstream provides binaries only with a
restricted non-free license.)
 (2) They are free software (e.g. FSF / OSI approved license) but they cost
money.
   (b) A subset, its free software and it costs money but it is free for
open source communities to use.
 (3) They are open source, but not free (e.g. they have some kind of open
license but are not FSF / OSI approved.)
 (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.

Which are allowed, and which are not?

-A

[-- Attachment #2: Type: text/html, Size: 1096 bytes --]

Re: [gentoo-nfp] Social contract and its effect on upstream software choices

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]

>>>>> On Fri, 01 May 2020, 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 and we may wish to deploy them for Gentoo. However, we must
> consider the social contract, hence this discussion.

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

IMHO it would contradict the Social Contract:
"However, Gentoo will never depend upon a piece of software or metadata
unless it conforms to the GNU General Public License, the GNU Lesser
General Public License, the Creative Commons - Attribution/Share Alike
or some other license approved by the Open Source Initiative (OSI)."

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

No problem there. Also, we can freely redistribute them if they are free
software.

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

Same as (2).

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

"Open source" has a well defined meaning. If the software is under an
open source license (i.e., a license in our @FREE group) then I don't
see any difference to (2).

OTOH, if they're only "free as in beer" then pretty much the same
argument as for (1) applies.

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

That's not the Gentoo way of doing things. However, I don't see a
problem with the Social Contract.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-nfp] Social contract and its effect on upstream software choices

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

On Fri, 2020-05-01 at 12:34 +0200, Ulrich Mueller wrote:
> > > > > > On Fri, 01 May 2020, 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 and we may wish to deploy them for Gentoo. However, we must
> > consider the social contract, hence this discussion.
> > Can we use the plugins if:
> >  (1) They are closed source (e.g. upstream provides binaries only with
> > a restricted non-free license.)
> 
> IMHO it would contradict the Social Contract:
> "However, Gentoo will never depend upon a piece of software or metadata
> unless it conforms to the GNU General Public License, the GNU Lesser
> General Public License, the Creative Commons - Attribution/Share Alike
> or some other license approved by the Open Source Initiative (OSI)."
> 
> >  (2) They are free software (e.g. FSF / OSI approved license) but they
> > cost money.
> 
> No problem there. Also, we can freely redistribute them if they are free
> software.

Are we talking of grsecurity here?  ;-)

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-nfp] Social contract and its effect on upstream software choices

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 318 bytes --]

>>>>> On Fri, 01 May 2020, Michał Górny wrote:

>> No problem there. Also, we can freely redistribute them if they are
>> free software.

> Are we talking of grsecurity here?  ;-)

Opinions differ if that was free software. If it cannot be redistributed
for whatever reason, then it isn't (IMHO).

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-nfp] Social contract and its effect on upstream software choices

[Francisco Blas Izquierdo Riera (klondike)]

[-- Attachment #1.1: Type: text/plain, Size: 2492 bytes --]

Hi Alec!

I have taken a refresher from reading https://opensource.org/osd and  and https://www.gentoo.org/get-started/philosophy/social-contract.html

The relevant part of the social contract is "However, Gentoo will never depend upon a piece of software or metadata unless it conforms to the GNU General Public License, the GNU Lesser General Public License, the Creative Commons - Attribution/Share Alike or some other license approved by the Open Source Initiative (OSI)."



El 1/5/20 a las 8:11, Alec Warner escribió:
> Hi,
>
> 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 and we may wish to deploy them for Gentoo. However, we must consider the social contract, hence this discussion.
>
> Can we use the plugins if:
>  (1) They are closed source (e.g. upstream provides binaries only with a restricted non-free license.)


This is likely against the social contract. Specially if the Gentoo project in anyways needs such plugin for operating normally.


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

This is fine AS LONG AS ADDITIONAL LICENSE TERMS ARE NOT ADDED. Software doesn't have to be free as in free beer to be free as in freedom.


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


If such subset is still FSF/OSI approved and additional license terms are not added, this should be fine too.


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


If we follow the letter of the social contract this is clearly not okay. If we follow the spirit though this is probably okay. In the last case, the trustees and/or council should decide if a license fulfills the expectation in a case by case basis.

A clear example of such a license is the WTFPL. The license is overly permissive, it fulfills all of OSI requirements but is not OSI approved. Yet I doubt anybody would say that using such software is not okay.


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


As long as you can have access to the source code and modify, redistribute, and compile it, this is fine (unless in the building process the plugin is combined with proprietary software).



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-nfp] Social contract and its effect on upstream software choices

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]

On 2020.05.01 07:11, Alec Warner wrote:
> Hi,
> 
> 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
> and we
> may wish to deploy them for Gentoo. However, we must consider the
> social
> contract, hence this discussion.
> 
> Can we use the plugins if:
>  (1) They are closed source (e.g. upstream provides binaries only with
> a
> restricted non-free license.)
>  (2) They are free software (e.g. FSF / OSI approved license) but they
> cost
> money.
>    (b) A subset, its free software and it costs money but it is free
> for
> open source communities to use.
>  (3) They are open source, but not free (e.g. they have some kind of
> open
> license but are not FSF / OSI approved.)
>  (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.
> 
> Which are allowed, and which are not?
> 
> -A
> 

Alec,

The key word is "depend" and in UK English, it has a different meaning
than "use". It may be different again in American.

Think of "depend" as being essential to Gentoo in some way and "use"
as being a convenience, that would have little or no effect if were removed.

It follows, for example, that Gentoo can "use" MS Windows but not 
"depend" upon it.

A more realistic example is github. Its a convenience, set up as a mirror. 
The master repo is not on github, so if it went away, we would lose that 
path for user contributions but several others already exist. Thus,
Gentoo does not "depend" on github.

Thinking back to to github mirror several devs were not happy about it.

My view is that "use" only applies if there are live, maintained and 
exercised alternatives in place. If Gentoo was impacted while an 
alternative was put in place, that falls under "depend".

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

[-- Attachment #2: Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-nfp] Social contract and its effect on upstream software choices

[Rich Freeman]

On Mon, May 4, 2020 at 7:37 AM Roy Bamford <neddyseagoon@gentoo.org> wrote:
>
> My view is that "use" only applies if there are live, maintained and
> exercised alternatives in place. If Gentoo was impacted while an
> alternative was put in place, that falls under "depend".

I think the nature of the impact also matters.  Gentoo has had
tinderboxes at some points in time, and not at others.  These have
often been individual dev initiatives, and they might or might not
have been 100% FOSS at various points in time.  In any case they were
largely inaccessible to most of the devs.  They (at times) operated
mostly as a black box - somebody was pulling our repo, doing some
tests, and filing bugs.

Such as service wasn't really a "Gentoo" service per-se and so the
social contract wasn't as important.

I realize that the QA team does CI/etc more systematically these days
and I'm sure that is more likely to be hosted on infra and be FOSS
now.  I'm not really referring to that, but more the ebb and flow of
ancillary services that random developers have provided at various
points in time.

I think a key factor is whether something is actually hosted on Gentoo
infra and becomes part of Gentoo policy.  For example, we have
policies around how bugs are filed/keyworded/etc, and our bug tracker
complies with the social contract.  If I as a dev do some personal
testing of packages and file bugs, it is less important what tools I
used to do that testing, because as far as Gentoo is concerned I'm
just a random person reporting legitimate errors.  Whether I just
manually ran emerge -1 foo or had some fancy script that
systematically builds every package in the tree and scours the logs,
the interface to Gentoo is the same.

That said, Gentoo is a pretty decentralized distro as far as
contributions go, so there will probably always be some debate over
whether some particular activity is an essential part of the distro or
not.  In any case, I think the Council/Trustees have been reasonably
practical about such matters, even if they occasionally prompt email
debates.

-- 
Rich

Re: [gentoo-nfp] Social contract and its effect on upstream software choices

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3211 bytes --]

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 and we
> may wish to deploy them for Gentoo. However, we must consider the social
> 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 for
> 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.

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.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-nfp] Social contract and its effect on upstream software choices

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 4599 bytes --]

On Tue, May 5, 2020 at 1:46 AM Michał Górny <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 and
> we
> > may wish to deploy them for Gentoo. However, we must consider the social
> > 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 for
> > 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 for
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 other
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 this 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.

-A

[0] Some of the EE features are 'source available' but the license is such
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ł Górny
>
>

[-- Attachment #2: Type: text/html, Size: 5725 bytes --]

Re: [gentoo-nfp] Social contract and its effect on upstream software choices

[Raymond Jennings]

[-- Attachment #1: Type: text/plain, Size: 4872 bytes --]

On Tue, May 5, 2020 at 9:13 AM Alec Warner <antarus@gentoo.org> wrote:

> On Tue, May 5, 2020 at 1:46 AM Michał Górny <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 and
>> we
>> > may wish to deploy them for Gentoo. However, we must consider the social
>> > 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 for
>> > 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 for
> 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 other
> 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 this
> 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 such
> 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ł Górny
>>
>>

[-- Attachment #2: Type: text/html, Size: 6273 bytes --]

Re: [gentoo-nfp] Social contract and its effect on upstream software choices

[Rich Freeman]

On Tue, May 5, 2020 at 12:13 PM Alec Warner <antarus@gentoo.org> wrote:
>
> [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.
>

FWIW, I know/trust somebody who has access to the source code for the
EE that is running on gitlab.com, and they have vouched that aside
from the EE-only additions the source code of the core product is
identical with CE.  That is, all the stuff that is in the CE source
code is present in the hosted version using the same version of the
source code, and there aren't any special gitlab.com
patches/branches/etc.  Obviously if you use the EE-only stuff then
that isn't present in CE.

So, in theory self-hosted CE should be identical to using gitlab.com
and avoiding the use of the EE-only features.

Obviously I have nothing to go on beyond their word, but even with
100% FOSS when you don't do the hosting you basically have to take the
word from the hosting provider that what they're hosting is actually
what they say they're hosting.

So, if making use of their hosting (which is often free to FOSS
organizations - if we don't already have that I could make inquiries
if there is official interest) would make a big difference in its
usefulness, this is probably something worth keeping in mind.
Obviously self-hosting is better in a lot of ways, but I was under the
impression that its design was holding us back from that.

-- 
Rich

Re: [gentoo-nfp] Social contract and its effect on upstream software choices

[Denis Dupeyron]

[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]

On Tue, May 5, 2020 at 12:57 PM Rich Freeman <rich0@gentoo.org> wrote:

> FWIW, I know/trust somebody who
> blah blah blah

So, in theory self-hosted CE should be identical to using gitlab.com
> and avoiding the use of the EE-only features.
> blah blah
>

Yeah, right. I work my ass off on this crap job all day and make peanuts.
It's weird though, because in theory I could be a billionaire.

Knowing that gitlab.com is neither CE nor EE, and that there's this hosting
thing to self-hosted, we couldn't spin up a proper GitLab service like the
one on gitlab.com overnight if they pulled the plug on us. In other words,
making use of and relying on their hosting, even using only CE features,
would make us totally dependent on them, and hence not respecting our
social contract. On the contrary, self hosting our own service, even using
EE features, wouldn't make us necessarily dependent on them since
EE-specific features are mostly useless (so is their support). The social
contract does not forbid usage of non-free software, but dependence on it.
Even if we were to use these EE features, knowing what they are I can
hardly imagine they'd be a big loss if we decided or were forced to not use
them any longer.

GitLab is a very mediocre product for a large, security-focused company.
The bad news is anything else is worse. The good news is a self-hosted CE
GitLab service could be just what we need.

I happen to know someone too. Someone who has spent 100% of his time for
the better part of the last two years setting up such a service at a large
company with a platinum GitLab license. This person is currently sitting
between my keyboard and my chair.

[-- Attachment #2: Type: text/html, Size: 2273 bytes --]

Re: [gentoo-nfp] Social contract and its effect on upstream software choices

[Rich Freeman]

On Tue, May 5, 2020 at 9:25 PM Denis Dupeyron <calchan@gentoo.org> wrote:
>
> On Tue, May 5, 2020 at 12:57 PM Rich Freeman <rich0@gentoo.org> wrote:
>>
>> blah blah blah

My goal was to offer information.  IMO this is unwarranted.

> Yeah, right. I work my ass off on this crap job all day and make peanuts. It's weird though, because in theory I could be a billionaire.

I don't recall anybody making this personal or mentioning you in any way?

>
> Knowing that gitlab.com is neither CE nor EE, and that there's this
> hosting thing to self-hosted, we couldn't spin up a proper GitLab
> service like the one on gitlab.com overnight if they pulled the plug
> on us. In other words, making use of and relying on their hosting,
> even using only CE features, would make us totally dependent on them,
> and hence not respecting our social contract.

Are you suggesting that we can't make use of hosted FOSS-only
solutions because that would make us dependent on somebody else?

I completely agree that this needs to be done cautiously, but in the
case of FOSS-only externally hosted solutions I don't see how this is
contrary to the social contract.

Now, in the case of gitlab.com I can see the argument that the
software they're hosting isn't purely FOSS, so it is much more of a
judgement call.  However, I don't think this has anything to do with
the fact that it is hosted, but just with the fact that it isn't
purely FOSS.

Again, I'm speaking to the social contract, which was the main topic
of this thread.  Practical concerns around any kind of externally
hosted solution are completely valid, but IMO a separate issue.

> I happen to know someone too. Someone who has spent 100% of his time
> for the better part of the last two years setting up such a service
> at a large company with a platinum GitLab license. This person is
> currently sitting between my keyboard and my chair.

So, I wasn't suggesting that anybody listen to me as some kind of
expert on GitLab.  Since the topic of gitlab.com came up, and I had
information that perhaps not everybody else had, I felt it would be
helpful to share it.  I mentioned (vaguely) the source of the info
because that sort of thing is useful when vetting information.  If it
were a strong concern I wouldn't be surprised if we could (perhaps
privately) obtain formal assurances around this from GitLab, if that
would sway any decisions one way or another.

I'm not advocating for or against the use of GitLab here, whether
self-hosted or hosted by them.  gitlab.com was mentioned, and I
figured I'd add something to the discussion,  If the information isn't
useful, well, don't use it.

And if you just wanted to say that you think it is wiser not to rely
on anything externally-hosted whether it is FOSS or not, that could
have been done in a sentence, and would IMO be a completely reasonable
argument.

Apologies if I misinterpreted the mood of your email.  It just seemed
half-worded like a personal attack, in what is otherwise a pretty
straightforward discussion around the social contract...

-- 
Rich