On Tue, Feb 5, 2019 at 6:49 PM Kristian Fiskerstrand <k_f@gentoo.org> wrote:
On 1/26/19 10:04 PM, Kristian Fiskerstrand wrote:
> I would like to point the community at the following bug
> https://bugs.gentoo.org/676248:
> Bug 676248 - non-free licenses are accepted without user prompt
>
> In summary the question is whether non-free licenses should be accepted
> by default in Gentoo. today only licenses requiring EULA are not
> accepted by default. So this is a good opportunity to discuss whether we
> should deviate substantially from other distros like Debian.
>
> My personal opinion is we should have a default accepting FSF and OSI
> approved free/libre licenses and require acceptance for anything else
> though package.license / ACCEPT_LICENSE. Since we have this model
> already we don't need a separate repository like debian does for its
> binary packages, so any change has relatively minor impact on our users
> as long as it is presented properly and with a proper timeline.
>

This topic has been discussed from time to time, including in 2013 in
https://archives.gentoo.org/gentoo-project/message/b36af97cdf6172217974a3afb30475bd
. However, context change and 6 years is likely enough time to permit a
new discussion.

What constitute free software is a broad discussion, so for the context
of these discussions I recommend we keep to the FSF and OSI definitions.
These definitions protects the user's rights to copy/modify/use the
application without repercussions, and that is exactly why it should be
the default license.

So I think the TL;DR for me here is that I'd rather the Council have decided that "We interpret the social contract in a way whereby Gentoo should espouse free software and we believe we can do better here by setting the default ACCEPT_LICENSE to "-* @FREE". I think some of your comments below go further than that and I'm not sure that helps your case (and at least the comments concern me slightly.)

I believe that irrespective of any ideology that @FREE does provide benefits, namely that:
 - The OSI and FSF are stewards of the OSD and they will vet and review licenses that meet the OSD. This is beneficial to end users who want a vetted and controlled licensing experience for such software.
 - Users trust the OSI and FSF (and by extension, licenses@gentoo.org, who populate the in-tree copy) with this task.

Delegation is a useful tool that removes the burden from users who would have to vet on their own.


As soon as a user start using a non-free license the user needs to
make judgments on how it will impact on further choice, and likely need
to consult a lawyer for practicality if using it in any commercial context.

In particular in a scenario where the license change unexpectedly this
can be an interesting twist, as seen with MongoDB. To quote

http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/003739.html
:
"Developers don’t always pay attention and given they have stated any
updates to older versions moving forward are SSPL a developer just
grabbing a security update suddenly means you’re not under AGPL anymore
but SSPL."

The consequences for a user arise when using non-free licenses, so the
default should be to allow free licenses by default.

I mostly don't find this argument valuable. OSI and FSF have consequences to anyone who redistributes them, but somehow they are allowed by default (because freedom?) This is why I continue to advocate for a deliberate choice based on the social contract ("Gentoo is and will remain Free and thus the default should be "-* @FREE" rather than some kind of objective choice based on 'consequences'; which I think just muddle the point.
 

A more puritan approach could be to not provide any approved license at
all, but the Gentoo Social contract says "Gentoo is and will remain free
software", which makes @FREE the natural choice.

I agree w/this FWIW.
 

Most of the issues from the previous discussions have been solved by
now, increasing the value of re-opening the discussion, and the
user-impact is minimal for setting a default of @FREE given proper
documentation in the handbook.

I'm going to re-iterate william's comment here in that I don't think the council has a good idea of what the user impact is; however I suspect this is not an intractable issue and I don't think it blocks any decision (and as noted in the meeting, we can always make changes later.)
 
-A



--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3