From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 6619F158090 for ; Sun, 8 May 2022 05:48:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A40C6E088B; Sun, 8 May 2022 05:48:06 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7B5A2E088B for ; Sun, 8 May 2022 05:48:06 +0000 (UTC) Received: from oystercatcher.gentoo.org (unknown [IPv6:2a01:4f8:202:4333:225:90ff:fed9:fc84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id ACA86341503 for ; Sun, 8 May 2022 05:48:05 +0000 (UTC) Received: from localhost.localdomain (localhost [IPv6:::1]) by oystercatcher.gentoo.org (Postfix) with ESMTP id 64B80445 for ; Sun, 8 May 2022 05:48:04 +0000 (UTC) From: "Ulrich Müller" To: gentoo-commits@lists.gentoo.org Content-Transfer-Encoding: 8bit Content-type: text/plain; charset=UTF-8 Reply-To: gentoo-dev@lists.gentoo.org, "Ulrich Müller" Message-ID: <1651574851.b393fd4f412720d6d01664abdacc791211b643a3.ulm@gentoo> Subject: [gentoo-commits] data/glep:master commit in: / X-VCS-Repository: data/glep X-VCS-Files: glep-0023.rst X-VCS-Directories: / X-VCS-Committer: ulm X-VCS-Committer-Name: Ulrich Müller X-VCS-Revision: b393fd4f412720d6d01664abdacc791211b643a3 X-VCS-Branch: master Date: Sun, 8 May 2022 05:48:04 +0000 (UTC) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-commits@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply X-Archives-Salt: 0d3176e5-8b2a-4f04-b1be-99fb2cb3301d X-Archives-Hash: 8e3dbbe22656ababe0c485237cef524f commit: b393fd4f412720d6d01664abdacc791211b643a3 Author: Ulrich Müller gentoo org> AuthorDate: Tue May 3 10:47:31 2022 +0000 Commit: Ulrich Müller gentoo 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 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 :: - + ... 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)