glep-0023: Delete trailing whitespace

Signed-off-by: Ulrich Müller <ulm@gentoo.org>

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)