commit: b393fd4f412720d6d01664abdacc791211b643a3
Author: Ulrich Müller <ulm <AT> gentoo <DOT> org>
AuthorDate: Tue May 3 10:47:31 2022 +0000
Commit: Ulrich Müller <ulm <AT> gentoo <DOT> org>
CommitDate: Tue May 3 10:47:31 2022 +0000
URL: https://gitweb.gentoo.org/data/glep.git/commit/?id=b393fd4f
glep-0023: Delete trailing whitespace
Signed-off-by: Ulrich Müller <ulm <AT> gentoo.org>
glep-0023.rst | 80 +++++++++++++++++++++++++++++------------------------------
1 file 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)
