/[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.2 - (show annotations) (download)
Thu Mar 11 02:35:40 2004 UTC (10 years, 9 months ago) by g2boojum
Branch: MAIN
Changes since 1.1: +12 -11 lines
File MIME type: text/plain
updated glep

1 GLEP: 23
2 Title: Portage handling of ACCEPT_LICENSE
3 Version: $Revision: 1.1 $
4 Last-Modified: $Date: 2004/03/08 17:26:04 $
5 Author: Jason Stubbs <jstubbs@gentoo.org>,
6 Status: Draft
7 Type: Standards Track
8 Content-Type: text/x-rst
9 Created: 9-Mar-2004
10 Post-History: 8-Mar-2004 10-Mar-2004
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
22 Motivation
23 ==========
24
25 Many users wish to regulate the software they install with regards to
26 licenses for various reasons [1]_. Some want a system free of any
27 software that is not OSI-approved; others are simply curious as to what
28 licenses they are implicitly accepting.
29
30 Furthermore, some software requires that a user interactively accept its
31 license for its author's to consider it legally binding. This is
32 currently implemented using ``eutils.eclass``.
33
34
35 Specification
36 =============
37
38 Ebuild LICENSE Variable
39 -----------------------
40
41 Most ebuilds are for software which is released under a single license.
42 In these cases, the current LICENSE variable can remain as is. For
43 example:
44
45 ::
46
47 LICENSE="single-license"
48
49 However, there are several ebuilds for software which is released under
50 several licenses, of which the user must accept one, some or all [2]_.
51 To complicate this, some ebuilds include optional components which fall
52 under a different license.
53
54 To accomodate these cases, LICENSE syntax should accomodate all
55 functionality offered by a DEPEND string. To keep things simple, this
56 GLEP proposes that the syntax be identical. For example:
57
58 ::
59
60 LICENSE="mandatory-license
61 || ( choosable-licence1 chooseable-license-2 )
62 useflag? ( optional-component-license )"
63
64
65 License Groups
66 --------------
67
68 Almost all users are willing to install any software that is
69 FSF-approved. Other users are willing to install any software and
70 implicitly accept its license. To this end, portage will also need to
71 handle grouping of licenses.
72
73 At a minimum, there needs to be the groups ``GPL-COMPATIBLE``,
74 ``FSF-APPROVED``, ``OSI-APPROVED`` and ``NON-INTERACTIVE``.
75 ``NON-INTERACTIVE`` licenses are those that don't require interactive
76 acceptance for to be considered legally binding. This is the current
77 behaviour of portage.
78
79
80 ACCEPT_LICENSE
81 --------------
82
83 This GLEP proposes that a user be able to explicitly accept or decline
84 licenses by editing a new variable ``ACCEPT_LICENSE`` in
85 ``/etc/make.conf``. Again, to keep things simple, the syntax should be
86 similar to that of other incrementals. For example:
87
88 ::
89
90 ACCEPT_LICENSE="-* accepted-license -declined-license"
91
92 As an extension, ``ACCEPT_LICENSE`` must also support `license groups`_.
93 This GLEP proposes that the license group be prepended by the special
94 character "``@``". For example:
95
96 ::
97
98 ACCEPT_LICENSE="-* @FSF-APPROVED"
99
100
101 Emerge Behaviour
102 ----------------
103
104 At a minimum, emerge must handle unaccepted licenses the same way that
105 it handles blockers. That is, with the --pretend flag the
106 not-yet-accepted license should be listed in the output. Without the
107 --pretend flag, emerge should stop before any software is installed.
108
109 This GLEP proposes that, unlike blockers, dependencies for software
110 should be checked regardless of license acceptance. Doing so will allow
111 the user to review all necessary licenses before initiating an actual
112 emerge.
113
114 It is also proposed that the --ask option will display an unaccepted
115 license and ask for acceptance, but not update any configuration files
116 at this stage. Finally, the --verbose option should also list the
117 licenses accepted for each package.
118
119
120 Rationale
121 =========
122
123 An implementation of this proposal should make it easy for users wishing
124 to regulate their software without affecting those that don't.
125
126
127 Reference Implementation
128 ========================
129
130 TODO
131
132
133 Backwards Compatibility
134 =======================
135
136 There should be no change to the user experience without the user
137 explicitly choosing to do so. This mandates that the
138 configuration variable be named ``ACCEPT_LICENSE`` as some users may
139 already have it set due to ebuilds using ``eutil.eclass``'s
140 implementation. It also mandates that the default ``ACCEPT_LICENSE`` be
141 set to ``@NON-INTERACTIVE``.
142
143
144 References
145 ==========
146
147 .. [1] Gentoo Linux Bug 17367
148 (http://bugs.gentoo.org/show_bug.cgi?id=17367)
149 .. [2] Gentoo Linux Bug 34146
150 (http://bugs.gentoo.org/show_bug.cgi?id=34146)
151
152
153 Copyright
154 =========
155
156 This document has been placed in the public domain.

  ViewVC Help
Powered by ViewVC 1.1.20