diff options
| -rw-r--r-- | glep-0023.rst | 80 |
1 files changed, 40 insertions, 40 deletions
diff --git a/glep-0023.rst b/glep-0023.rst index 9113464..e8df911 100644 --- a/glep-0023.rst +++ b/glep-0023.rst @@ -24,20 +24,20 @@ Abstract ======== Currently, every ebuild in the main Gentoo repository is required to have a -valid LICENSE entry. However, the syntax of this entry is not officially -defined and the entry itself is only used when outputting package +valid LICENSE entry. However, the syntax of this entry is not officially +defined and the entry itself is only used when outputting package details. Motivation ========== -Many users wish to regulate the software they install with regards to -licenses for various reasons [1]_. Some want a system free of any -software that is not OSI-approved; others are simply curious as to what +Many users wish to regulate the software they install with regards to +licenses for various reasons [1]_. Some want a system free of any +software that is not OSI-approved; others are simply curious as to what licenses they are implicitly accepting. -Furthermore, some software requires that a user interactively accept its -license for its author's to consider it legally binding. This is +Furthermore, some software requires that a user interactively accept its +license for its author's to consider it legally binding. This is currently implemented using ``eutils.eclass``. @@ -47,21 +47,21 @@ Specification Ebuild LICENSE Variable ----------------------- -Most ebuilds are for software which is released under a single license. -In these cases, the current LICENSE variable can remain as is. For +Most ebuilds are for software which is released under a single license. +In these cases, the current LICENSE variable can remain as is. For example: :: LICENSE="single-license" -However, there are several ebuilds for software which is released under -several licenses, of which the user must accept one, some or all [2]_. -To complicate this, some ebuilds include optional components which fall +However, there are several ebuilds for software which is released under +several licenses, of which the user must accept one, some or all [2]_. +To complicate this, some ebuilds include optional components which fall under a different license. To accommodate these cases, LICENSE syntax should accommodate all -functionality offered by a DEPEND string. To keep things simple, this +functionality offered by a DEPEND string. To keep things simple, this GLEP proposes that the syntax be identical. For example: :: @@ -78,34 +78,34 @@ begin with a hyphen, a dot or a plus sign. License Groups -------------- -Almost all users are willing to install any software that is -FSF-approved. Other users are willing to install any software and -implicitly accept its license. To this end, implementations will also +Almost all users are willing to install any software that is +FSF-approved. Other users are willing to install any software and +implicitly accept its license. To this end, implementations will also need to handle grouping of licenses. -At a minimum, there needs to be the groups ``GPL-COMPATIBLE``, -``FSF-APPROVED``, ``OSI-APPROVED`` and ``NON-MUST-HAVE-READ``. -``NON-MUST-HAVE-READ`` licenses are those that don't require manual -acceptance for to be considered legally binding. This is the current +At a minimum, there needs to be the groups ``GPL-COMPATIBLE``, +``FSF-APPROVED``, ``OSI-APPROVED`` and ``NON-MUST-HAVE-READ``. +``NON-MUST-HAVE-READ`` licenses are those that don't require manual +acceptance for to be considered legally binding. This is the current behaviour of portage. -These groups are defined in a new file ``license_groups`` in +These groups are defined in a new file ``license_groups`` in the ``profiles`` subdirectory of the tree (or overlays). Details of handling groups defined in overlays is implementation dependent. The format of this file is :: - + <groupname> <license1> <license2> ... <licenseN> Also any line starting with # is ignored and may be used for comments. -Group names use the same syntax as normal license names. Also license groups +Group names use the same syntax as normal license names. Also license groups may contain other groups. License groups may not contain negated elements, so a group :: - + mygroup foo -bar -bla is illegal. @@ -114,17 +114,17 @@ is illegal. ACCEPT_LICENSE -------------- -This GLEP proposes that a user be able to explicitly accept or decline -licenses by editing a new variable ``ACCEPT_LICENSE`` in -``/etc/make.conf``. Again, to keep things simple, the syntax should be +This GLEP proposes that a user be able to explicitly accept or decline +licenses by editing a new variable ``ACCEPT_LICENSE`` in +``/etc/make.conf``. Again, to keep things simple, the syntax should be similar to that of other incrementals. For example: :: ACCEPT_LICENSE="-* accepted-license -declined-license" -As an extension, ``ACCEPT_LICENSE`` must also support `license groups`_. -This GLEP proposes that the license group be prepended by the special +As an extension, ``ACCEPT_LICENSE`` must also support `license groups`_. +This GLEP proposes that the license group be prepended by the special character "``@``". For example: :: @@ -142,19 +142,19 @@ Behaviour --------- Unaccepted licenses will be treated like any other masked package, that is -the user interface of an implementation will display a message listing any -license that has to be accepted before the package can be merged with a +the user interface of an implementation will display a message listing any +license that has to be accepted before the package can be merged with a pointer to the exact license text. Past versions of this document proposed to handle license-masked packages -like blockers, but this would be inconsistent with other visibility -filters as well as the current blocker system (as a blocker affects two +like blockers, but this would be inconsistent with other visibility +filters as well as the current blocker system (as a blocker affects two packages) and be more complicated to implement. Rationale ========= -An implementation of this proposal should make it easy for users wishing +An implementation of this proposal should make it easy for users wishing to regulate their software without affecting those that don't. @@ -167,11 +167,11 @@ Available in portage svn repository under main/branches/license-masking Backwards Compatibility ======================= -There should be no change to the user experience without the user -explicitly choosing to do so. This mandates that the -configuration variable be named ``ACCEPT_LICENSE`` as some users may -already have it set due to ebuilds using ``eutils.eclass``'s -implementation. It also mandates that the default ``ACCEPT_LICENSE`` be +There should be no change to the user experience without the user +explicitly choosing to do so. This mandates that the +configuration variable be named ``ACCEPT_LICENSE`` as some users may +already have it set due to ebuilds using ``eutils.eclass``'s +implementation. It also mandates that the default ``ACCEPT_LICENSE`` be set to ``@NON-MUST-HAVE-READ`` in the main Gentoo repository as implementations are not required to provide an internal default. @@ -180,7 +180,7 @@ References .. [1] Gentoo Linux Bug 17367 (http://bugs.gentoo.org/show_bug.cgi?id=17367) -.. [2] Gentoo Linux Bug 34146 +.. [2] Gentoo Linux Bug 34146 (http://bugs.gentoo.org/show_bug.cgi?id=34146) |