Hi,
In the context of my GSOC [1] I need to get GLEP 23 [2] fully
implemented and
this means get ACCEPT_LICENSE used with a default value and bug 152593 [3]
fixed.
= GLEP 23 summary =
Most of GLEP 23 features have already been implemented in portage. Some
since
a long time (at least in stable portage) like multiple licenses and
conditional
licenses. License group and ACCEPT_LICENSE is already implemented in portage
2.2 (masked).
= ACCEPT_LICENSE =
Please, have a look at GLEP 23 [2] and read how ACCEPT_LICENSE and license
groups work (it's the main topic). I will repeat some things above but not
everything.
ACCEPT_LICENSE, as ACCEPT_KEYWORDS, will mask/unmask packages based on the
license. User will explicitely know why the package is masked and which
license to accept to have it unmasked. The path of the license is showed to
incite him read it. This feature should help bug 152593 [3] because if
he accepts
the license, we can assume he known what he was doing (ie. we can assume he
read the license) but we will see that in the last part.
= ACCEPT_LICENSE default value =
The ACCEPT_LICENSE default value will impact users, devs and Gentoo.
Users: ebuilds will be masked if their license(s) is(are) not in
ACCEPT_LICENSE
Devs: they will have to maintain license groups and if a specific group is
allowed by default (or not allowed by default) they will have to make
sure new
ebuilds are correctly (un)masked.
Gentoo: we can consider (at least I) that such a value is important and
linked
to our social contract. Are we going to support FSF approved licenses ? OSI
approved ? both ? union of them ? or event more licenses ? This decision is
probably more than only user/dev issue.
There are two ways to see the default value: set it to a set of groups which
will allow automatically a set of licenses or set it to everything
excluding a
set of groups. In other words:
accept_licen...@approved
or
ACCEPT_LICENSE=* -...@need_to_be_accepted
That's a main difference because if not checked, an ebuild will be
automatically
masked for license in the first way and automatically unmasked in the
second.
There are some proposition of ACCEPT_LICENSE values for both ways.
* accept_licen...@non_eula
With this value, every license that is not an EULA will have to be in
@NON_EULA
group to let the ebuild available.
PRO: easy for user, except for a few licenses, he will never notice this new
feature.
CON: difficult to maintain for devs: @NON_EULA will be big and you will
have to
think about adding a license to @NON_EULA when pushing it to the tree.
* ACCEPT_LICENSE=* -...@eula
That's actually the unique reason to use the second way (ie. all licenses
accepted except some): masks all EULA. For the user, it's exactly the
same if
everything is done correctly by devs but if the dev forget to add a
license to
the right group, consequences will be different. With this default
value, the
package will be unmasked by default.
In my opinion, the previous default value proposition is in all ways better
than this one. It's probably better to have a forgotten license masked than
unmasked because users will surely complain/file a bug if the package is
masked.
* accept_licen...@gentoo_approved
@GENTOO_APPROVED will be a group of approved licenses. It will be different
from NON_EULA as it could be a more restrictive set of licenses like a
combination between @FSF_APPROVED and @OSI_APPROVED. In other words, what
general people call "free software". According to our social contract [4] we
support free software and want Gentoo related work to be licensed in OSI
approved license. And still according to this page, someone (who ?) is
thinking about restrict Gentoo related work to OSI approved _and_ FSF
approved
licenses. Why not set ACCEPT_LICENSE to this same licenses ? It will be more
consistent with our social contract.
PRO: more consistent with social contract
less work for dev than accept_licen...@non_eula as we can suppose
@OSI_APPROVED and/or @FSF_APPROVED will not change often
CON: users will probably have more masked packages because of licenses [5]
= About licenses which needs explicit acceptance =
This is not the main topic, but it could be interesting to have your
opinions.
It looks like some licenses need acceptance. I was thinking using a software
means accepting the license. If we really need to make a user accept a
license, printing the license path is enough ? He still can add the license
name in ACCEPT_LICENSE without even reading it. However, I suppose
adding the
license name will be enough for an "approval".
This leads me to think ACCEPT_LICENSE=* should be forbidden.
The point of this message is to get opinions of devs to reach a
consensus then
have this default value approved by the Council.
So, what's your opinion ?
[1] My GSOC is about writing a portage's backend for PackageKit. I will
try to
send a message about it in the next days.
[2] http://www.gentoo.org/proj/en/glep/glep-0023.html
[3] https://bugs.gentoo.org/show_bug.cgi?id=152593
[4] http://www.gentoo.org/main/en/contract.xml
[5] zmedico send me stats about licenses:
"I've attached a script to count how many instances of each license
there are, and how many instances in each group. Here are the group
counts I get:
@FSF-APPROVED 23641
@GPL-COMPATIBLE 22956
@OSI-APPROVED 23284
@other 5998
@total 30549"
Thanks for reading,
Mounir
