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

[Alec Warner]

On Tue, May 5, 2020 at 1:46 AM Michał Górny <mgorny@g.o> 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
>
>