/[gentoo]/xml/htdocs/proj/en/glep/glep-0023.txt
Gentoo

Contents of /xml/htdocs/proj/en/glep/glep-0023.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.4 - (show annotations) (download)
Sat Nov 18 07:27:47 2006 UTC (7 years, 9 months ago) by genone
Branch: MAIN
Changes since 1.3: +38 -25 lines
File MIME type: text/plain
Update ACCEPT_LICENSE glep to reflect current status

1 GLEP: 23
2 Title: Portage handling of ACCEPT_LICENSE
3 Version: $Revision: 1.3 $
4 Last-Modified: $Date: 2004/10/26 00:21:28 $
5 Author: Jason Stubbs <jstubbs@gentoo.org>, Marius Mauch <genone@gentoo.org>
6 Status: Accepted
7 Type: Standards Track
8 Content-Type: text/x-rst
9 Created: 9-Mar-2004
10 Post-History: 8-Mar-2004 10-Mar-2004 25-Oct-2004 18-Nov-2006
11
12
13 Abstract
14 ========
15
16 Currently, every ebuild in the portage tree is required to have a valid
17 LICENSE entry. However, the syntax of this entry is not officially
18 defined and the entry itself is only used when outputting package
19 details.
20
21 Status Update
22 =============
23
24 Repoman has been updated to check for the LICENSE syntax.
25 A development portage branch with support for ACCEPT_LICENSE
26 and license groups exists.
27
28 Motivation
29 ==========
30
31 Many users wish to regulate the software they install with regards to
32 licenses for various reasons [1]_. Some want a system free of any
33 software that is not OSI-approved; others are simply curious as to what
34 licenses they are implicitly accepting.
35
36 Furthermore, some software requires that a user interactively accept its
37 license for its author's to consider it legally binding. This is
38 currently implemented using ``eutils.eclass``.
39
40
41 Specification
42 =============
43
44 Ebuild LICENSE Variable
45 -----------------------
46
47 Most ebuilds are for software which is released under a single license.
48 In these cases, the current LICENSE variable can remain as is. For
49 example:
50
51 ::
52
53 LICENSE="single-license"
54
55 However, there are several ebuilds for software which is released under
56 several licenses, of which the user must accept one, some or all [2]_.
57 To complicate this, some ebuilds include optional components which fall
58 under a different license.
59
60 To accomodate these cases, LICENSE syntax should accomodate all
61 functionality offered by a DEPEND string. To keep things simple, this
62 GLEP proposes that the syntax be identical. For example:
63
64 ::
65
66 LICENSE="mandatory-license
67 || ( choosable-licence1 chooseable-license-2 )
68 useflag? ( optional-component-license )"
69
70
71 License Groups
72 --------------
73
74 Almost all users are willing to install any software that is
75 FSF-approved. Other users are willing to install any software and
76 implicitly accept its license. To this end, portage will also need to
77 handle grouping of licenses.
78
79 At a minimum, there needs to be the groups ``GPL-COMPATIBLE``,
80 ``FSF-APPROVED``, ``OSI-APPROVED`` and ``NON-INTERACTIVE``.
81 ``NON-INTERACTIVE`` licenses are those that don't require interactive
82 acceptance for to be considered legally binding. This is the current
83 behaviour of portage.
84
85 These groups are defined in a new file ``license_groups`` in
86 the ``profiles`` subdirectory of the tree (or overlays).
87 The format of this file is
88
89 ::
90
91 <groupname> <license1> <license2> ... <licenseN>
92
93 Also any line starting with # is ignored and may be used for comments.
94 License groups may not contain negated elements, so a group
95
96 ::
97
98 mygroup foo -bar -bla
99
100 is illegal.
101
102
103 ACCEPT_LICENSE
104 --------------
105
106 This GLEP proposes that a user be able to explicitly accept or decline
107 licenses by editing a new variable ``ACCEPT_LICENSE`` in
108 ``/etc/make.conf``. Again, to keep things simple, the syntax should be
109 similar to that of other incrementals. For example:
110
111 ::
112
113 ACCEPT_LICENSE="-* accepted-license -declined-license"
114
115 As an extension, ``ACCEPT_LICENSE`` must also support `license groups`_.
116 This GLEP proposes that the license group be prepended by the special
117 character "``@``". For example:
118
119 ::
120
121 ACCEPT_LICENSE="-* @FSF-APPROVED"
122
123 License groups may be negated with the result that all elements of that group
124 are also negated.
125
126 Portage Behaviour
127 -----------------
128
129 Unaccepted licenses will be treated like any other masked package, that is
130 emerge will display a message listing any license that has to be accepted
131 before the package can be merged with a pointer to the exact license text.
132
133 Past versions of this document proposed to handle license-masked packages
134 like blockers, but this would be inconsistent with other visibility
135 filters as well as the current blocker system (as a blocker affects two
136 packages) and be more complicated to implement.
137
138 Rationale
139 =========
140
141 An implementation of this proposal should make it easy for users wishing
142 to regulate their software without affecting those that don't.
143
144
145 Reference Implementation
146 ========================
147
148 Available in portage svn repository under main/branches/license-masking
149
150
151 Backwards Compatibility
152 =======================
153
154 There should be no change to the user experience without the user
155 explicitly choosing to do so. This mandates that the
156 configuration variable be named ``ACCEPT_LICENSE`` as some users may
157 already have it set due to ebuilds using ``eutil.eclass``'s
158 implementation. It also mandates that the default ``ACCEPT_LICENSE`` be
159 set to ``@NON-INTERACTIVE`` in the main gentoo repository as there will
160 be no internal default in portage.
161
162 References
163 ==========
164
165 .. [1] Gentoo Linux Bug 17367
166 (http://bugs.gentoo.org/show_bug.cgi?id=17367)
167 .. [2] Gentoo Linux Bug 34146
168 (http://bugs.gentoo.org/show_bug.cgi?id=34146)
169
170
171 Copyright
172 =========
173
174 This document has been placed in the public domain.

  ViewVC Help
Powered by ViewVC 1.1.20