Title:Portage handling of ACCEPT_LICENSE
Last-Modified:2004/03/08 17:26:04
Author:Jason Stubbs <jstubbs at>,
Type:Standards Track



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.


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.


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:


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 OSI-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 OSI-APPROVED and NON-INTERACTIVE. NON-INTERACTIVE licenses are those that don't require interactive acceptance for it to be considered legally binding. This is the current behaviour of portage.


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:


Emerge Behaviour

At a minimum, emerge must handle unaccepted licenses the same way that it handles blockers. That is, with the --pretend flag the not-yet-accepted license should be listed in the output. Without the --pretend flag, emerge should stop before any software is installed.

This GLEP proposes that, unlike blockers, dependencies for software should be checked regardless of license acceptance. Doing so will allow the user to review all necessary licenses before initiating an actual emerge.

It is also proposed that the --ask option will display an unaccepted license and ask for acceptance, but not update any configuration files at this stage. Finally, the --verbose option should also list the licenses accepted for each package.


An implementation of this proposal should make it easy for users wishing to regulate their software without affecting those that don't.

Reference Implementation


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.


[1]Gentoo Linux Bug 17367 (
[2]Gentoo Linux Bug 34146 (