1 |
On Sat, Nov 18, 2006 at 08:53:36AM +0100, Marius Mauch wrote: |
2 |
> Anyone interested in this feature should review the attached version. |
3 |
> Unless there are major objections (or we find large problems in the |
4 |
> implementation) this will be merged in one of the next portage releases |
5 |
> (definitely not in 2.1.2 though). |
6 |
|
7 |
Gleps have to be approved prior to being merged mind you |
8 |
(ain't process fun?). |
9 |
|
10 |
> To accomodate these cases, LICENSE syntax should accomodate all |
11 |
> functionality offered by a DEPEND string. To keep things simple, this |
12 |
> GLEP proposes that the syntax be identical. For example: |
13 |
|
14 |
Would label that 'offered by a DepSet', although requires codifying |
15 |
the rules of it (referencing depend string only always struck me as |
16 |
odd since it implies that rdepends/pdepends differ, which they don't). |
17 |
|
18 |
|
19 |
> License Groups |
20 |
> -------------- |
21 |
> |
22 |
> Almost all users are willing to install any software that is |
23 |
> FSF-approved. Other users are willing to install any software and |
24 |
> implicitly accept its license. To this end, portage will also need to |
25 |
> handle grouping of licenses. |
26 |
> |
27 |
> At a minimum, there needs to be the groups ``GPL-COMPATIBLE``, |
28 |
> ``FSF-APPROVED``, ``OSI-APPROVED`` and ``NON-INTERACTIVE``. |
29 |
> ``NON-INTERACTIVE`` licenses are those that don't require interactive |
30 |
> acceptance for to be considered legally binding. This is the current |
31 |
> behaviour of portage. |
32 |
> |
33 |
> These groups are defined in a new file ``license_groups`` in |
34 |
> the ``profiles`` subdirectory of the tree (or overlays). |
35 |
> The format of this file is |
36 |
|
37 |
Resurrecting an old arguement, but profiles is the wrong location for |
38 |
this; it's repository metadata (global), not specific to the profile, |
39 |
thus should be in metadata/. |
40 |
|
41 |
|
42 |
> <groupname> <license1> <license2> ... <licenseN> |
43 |
> |
44 |
> Also any line starting with # is ignored and may be used for comments. |
45 |
> License groups may not contain negated elements, so a group |
46 |
> |
47 |
> :: |
48 |
> |
49 |
> mygroup foo -bar -bla |
50 |
> |
51 |
> is illegal. |
52 |
|
53 |
Route of a bit of duplication I'd think; since you're disallowing |
54 |
groups to be used in defining other groups, negation isn't needed; |
55 |
that said, I don't see why groups aren't allowed (if they were, |
56 |
negation must be allowed)... |
57 |
|
58 |
If you're going to disallow groups used to define other groups, should |
59 |
lay out the reasoning in the glep. |
60 |
|
61 |
|
62 |
> ACCEPT_LICENSE |
63 |
> -------------- |
64 |
> |
65 |
> This GLEP proposes that a user be able to explicitly accept or decline |
66 |
> licenses by editing a new variable ``ACCEPT_LICENSE`` in |
67 |
> ``/etc/make.conf``. Again, to keep things simple, the syntax should be |
68 |
> similar to that of other incrementals. For example: |
69 |
> |
70 |
> :: |
71 |
> |
72 |
> ACCEPT_LICENSE="-* accepted-license -declined-license" |
73 |
> |
74 |
> As an extension, ``ACCEPT_LICENSE`` must also support `license groups`_. |
75 |
> This GLEP proposes that the license group be prepended by the special |
76 |
> character "``@``". For example: |
77 |
> |
78 |
> :: |
79 |
> |
80 |
> ACCEPT_LICENSE="-* @FSF-APPROVED" |
81 |
> |
82 |
> License groups may be negated with the result that all elements of that group |
83 |
> are also negated. |
84 |
|
85 |
Left out that if it's unset, it should default to ACCEPT_LICENSE=* , |
86 |
meaning no license filtering. |
87 |
|
88 |
|
89 |
> Portage Behaviour |
90 |
> ----------------- |
91 |
> |
92 |
> Unaccepted licenses will be treated like any other masked package, that is |
93 |
> emerge will display a message listing any license that has to be accepted |
94 |
> before the package can be merged with a pointer to the exact license text. |
95 |
|
96 |
Glep doesn't say anything about overlay stacking of it; know I'll be |
97 |
implementing it such that overlay specific license groups only affect |
98 |
that overlay, but also know that portage will collapse that and have |
99 |
it affect the full repository stack (meaning a redefine in an overlay |
100 |
changes the group for PORTDIR). |
101 |
|
102 |
Would suggest clarifying that. |
103 |
|
104 |
|
105 |
> Backwards Compatibility |
106 |
> ======================= |
107 |
> |
108 |
> There should be no change to the user experience without the user |
109 |
> explicitly choosing to do so. This mandates that the |
110 |
> configuration variable be named ``ACCEPT_LICENSE`` as some users may |
111 |
> already have it set due to ebuilds using ``eutil.eclass``'s |
112 |
> implementation. It also mandates that the default ``ACCEPT_LICENSE`` be |
113 |
> set to ``@NON-INTERACTIVE`` in the main gentoo repository as there will |
114 |
> be no internal default in portage. |
115 |
|
116 |
The current default in portage however is that of ACCEPT_LICENSE=*; |
117 |
since portage doesn't yet filter on licenses, and since interactive |
118 |
ebuilds already exist, _that_ is the default. |
119 |
|
120 |
Finally, NON-INTERACTIVE shouldn't be a license group; |
121 |
RESTRICT=interactive is the route there; you can have gpl software |
122 |
distributed on cds that must be interactive (feed cds in as |
123 |
requested). |
124 |
|
125 |
The only solution there would to be to invent a fake license group for |
126 |
it and tag it in... which is not what license is about. |
127 |
|
128 |
Interactivity is a seperate thing from license; keep it that way. |
129 |
|
130 |
|
131 |
Finally... stupid, but s/portage/package manager/; should be |
132 |
an agnostic specification ('specially considering the other two |
133 |
already do non-group license filtering since their respective |
134 |
inceptions). |
135 |
|
136 |
~harring |