1 |
Hi, |
2 |
|
3 |
In the context of my GSOC [1] I need to get GLEP 23 [2] fully |
4 |
implemented and |
5 |
this means get ACCEPT_LICENSE used with a default value and bug 152593 [3] |
6 |
fixed. |
7 |
|
8 |
= GLEP 23 summary = |
9 |
|
10 |
Most of GLEP 23 features have already been implemented in portage. Some |
11 |
since |
12 |
a long time (at least in stable portage) like multiple licenses and |
13 |
conditional |
14 |
licenses. License group and ACCEPT_LICENSE is already implemented in portage |
15 |
2.2 (masked). |
16 |
|
17 |
= ACCEPT_LICENSE = |
18 |
|
19 |
Please, have a look at GLEP 23 [2] and read how ACCEPT_LICENSE and license |
20 |
groups work (it's the main topic). I will repeat some things above but not |
21 |
everything. |
22 |
|
23 |
ACCEPT_LICENSE, as ACCEPT_KEYWORDS, will mask/unmask packages based on the |
24 |
license. User will explicitely know why the package is masked and which |
25 |
license to accept to have it unmasked. The path of the license is showed to |
26 |
incite him read it. This feature should help bug 152593 [3] because if |
27 |
he accepts |
28 |
the license, we can assume he known what he was doing (ie. we can assume he |
29 |
read the license) but we will see that in the last part. |
30 |
|
31 |
= ACCEPT_LICENSE default value = |
32 |
|
33 |
The ACCEPT_LICENSE default value will impact users, devs and Gentoo. |
34 |
Users: ebuilds will be masked if their license(s) is(are) not in |
35 |
ACCEPT_LICENSE |
36 |
Devs: they will have to maintain license groups and if a specific group is |
37 |
allowed by default (or not allowed by default) they will have to make |
38 |
sure new |
39 |
ebuilds are correctly (un)masked. |
40 |
Gentoo: we can consider (at least I) that such a value is important and |
41 |
linked |
42 |
to our social contract. Are we going to support FSF approved licenses ? OSI |
43 |
approved ? both ? union of them ? or event more licenses ? This decision is |
44 |
probably more than only user/dev issue. |
45 |
|
46 |
There are two ways to see the default value: set it to a set of groups which |
47 |
will allow automatically a set of licenses or set it to everything |
48 |
excluding a |
49 |
set of groups. In other words: |
50 |
ACCEPT_LICENSE=@APPROVED |
51 |
or |
52 |
ACCEPT_LICENSE=* -@NEED_TO_BE_ACCEPTED |
53 |
|
54 |
That's a main difference because if not checked, an ebuild will be |
55 |
automatically |
56 |
masked for license in the first way and automatically unmasked in the |
57 |
second. |
58 |
|
59 |
There are some proposition of ACCEPT_LICENSE values for both ways. |
60 |
|
61 |
* ACCEPT_LICENSE=@NON_EULA |
62 |
With this value, every license that is not an EULA will have to be in |
63 |
@NON_EULA |
64 |
group to let the ebuild available. |
65 |
PRO: easy for user, except for a few licenses, he will never notice this new |
66 |
feature. |
67 |
CON: difficult to maintain for devs: @NON_EULA will be big and you will |
68 |
have to |
69 |
think about adding a license to @NON_EULA when pushing it to the tree. |
70 |
|
71 |
* ACCEPT_LICENSE=* -@EULA |
72 |
That's actually the unique reason to use the second way (ie. all licenses |
73 |
accepted except some): masks all EULA. For the user, it's exactly the |
74 |
same if |
75 |
everything is done correctly by devs but if the dev forget to add a |
76 |
license to |
77 |
the right group, consequences will be different. With this default |
78 |
value, the |
79 |
package will be unmasked by default. |
80 |
In my opinion, the previous default value proposition is in all ways better |
81 |
than this one. It's probably better to have a forgotten license masked than |
82 |
unmasked because users will surely complain/file a bug if the package is |
83 |
masked. |
84 |
|
85 |
* ACCEPT_LICENSE=@GENTOO_APPROVED |
86 |
@GENTOO_APPROVED will be a group of approved licenses. It will be different |
87 |
from NON_EULA as it could be a more restrictive set of licenses like a |
88 |
combination between @FSF_APPROVED and @OSI_APPROVED. In other words, what |
89 |
general people call "free software". According to our social contract [4] we |
90 |
support free software and want Gentoo related work to be licensed in OSI |
91 |
approved license. And still according to this page, someone (who ?) is |
92 |
thinking about restrict Gentoo related work to OSI approved _and_ FSF |
93 |
approved |
94 |
licenses. Why not set ACCEPT_LICENSE to this same licenses ? It will be more |
95 |
consistent with our social contract. |
96 |
PRO: more consistent with social contract |
97 |
less work for dev than ACCEPT_LICENSE=@NON_EULA as we can suppose |
98 |
@OSI_APPROVED and/or @FSF_APPROVED will not change often |
99 |
CON: users will probably have more masked packages because of licenses [5] |
100 |
|
101 |
= About licenses which needs explicit acceptance = |
102 |
|
103 |
This is not the main topic, but it could be interesting to have your |
104 |
opinions. |
105 |
|
106 |
It looks like some licenses need acceptance. I was thinking using a software |
107 |
means accepting the license. If we really need to make a user accept a |
108 |
license, printing the license path is enough ? He still can add the license |
109 |
name in ACCEPT_LICENSE without even reading it. However, I suppose |
110 |
adding the |
111 |
license name will be enough for an "approval". |
112 |
This leads me to think ACCEPT_LICENSE=* should be forbidden. |
113 |
|
114 |
The point of this message is to get opinions of devs to reach a |
115 |
consensus then |
116 |
have this default value approved by the Council. |
117 |
|
118 |
So, what's your opinion ? |
119 |
|
120 |
[1] My GSOC is about writing a portage's backend for PackageKit. I will |
121 |
try to |
122 |
send a message about it in the next days. |
123 |
[2] http://www.gentoo.org/proj/en/glep/glep-0023.html |
124 |
[3] https://bugs.gentoo.org/show_bug.cgi?id=152593 |
125 |
[4] http://www.gentoo.org/main/en/contract.xml |
126 |
[5] zmedico send me stats about licenses: |
127 |
"I've attached a script to count how many instances of each license |
128 |
there are, and how many instances in each group. Here are the group |
129 |
counts I get: |
130 |
@FSF-APPROVED 23641 |
131 |
@GPL-COMPATIBLE 22956 |
132 |
@OSI-APPROVED 23284 |
133 |
@other 5998 |
134 |
@total 30549" |
135 |
|
136 |
Thanks for reading, |
137 |
Mounir |