GLEP: 23 Title: Portage handling of ACCEPT_LICENSE Version: $Revision: 1.4 $ Last-Modified: $Date: 2006/11/18 07:27:47 $ Author: Jason Stubbs , Marius Mauch Status: Accepted Type: Standards Track Content-Type: text/x-rst Created: 9-Mar-2004 Post-History: 8-Mar-2004 10-Mar-2004 25-Oct-2004 18-Nov-2006 Abstract ======== Currently, every ebuild in the portage tree 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 details. Status Update ============= Repoman has been updated to check for the LICENSE syntax. A development portage branch with support for ACCEPT_LICENSE and license groups exists. 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 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 currently implemented using ``eutils.eclass``. 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 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 under a different license. To accomodate these cases, LICENSE syntax should accomodate all functionality offered by a DEPEND string. To keep things simple, this GLEP proposes that the syntax be identical. For example: :: LICENSE="mandatory-license || ( choosable-licence1 chooseable-license-2 ) useflag? ( optional-component-license )" 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, portage 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-INTERACTIVE``. ``NON-INTERACTIVE`` licenses are those that don't require interactive 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 the ``profiles`` subdirectory of the tree (or overlays). The format of this file is :: ... Also any line starting with # is ignored and may be used for comments. License groups may not contain negated elements, so a group :: mygroup foo -bar -bla 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 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 character "``@``". For example: :: ACCEPT_LICENSE="-* @FSF-APPROVED" License groups may be negated with the result that all elements of that group are also negated. Portage Behaviour ----------------- Unaccepted licenses will be treated like any other masked package, that is emerge 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 packages) and be more complicated to implement. Rationale ========= An implementation of this proposal should make it easy for users wishing to regulate their software without affecting those that don't. Reference Implementation ======================== 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 ``eutil.eclass``'s implementation. It also mandates that the default ``ACCEPT_LICENSE`` be set to ``@NON-INTERACTIVE`` in the main gentoo repository as there will be no internal default in portage. References ========== .. [1] Gentoo Linux Bug 17367 (http://bugs.gentoo.org/show_bug.cgi?id=17367) .. [2] Gentoo Linux Bug 34146 (http://bugs.gentoo.org/show_bug.cgi?id=34146) Copyright ========= This document has been placed in the public domain.