--- xml/htdocs/proj/en/glep/glep-0023.html 2004/10/25 17:04:01 1.3 +++ xml/htdocs/proj/en/glep/glep-0023.html 2006/10/10 20:25:14 1.4 @@ -8,9 +8,252 @@ --> - + GLEP 23 -- Portage handling of ACCEPT_LICENSE - + -
- +
@@ -33,9 +275,9 @@ - + - + @@ -43,7 +285,7 @@ - + @@ -52,8 +294,8 @@
Title:Portage handling of ACCEPT_LICENSE
Version:1.2
Version:1.3
Last-Modified:2004/03/11 02:35:40
Last-Modified:2004/10/26 00:21:28
Author:Jason Stubbs <jstubbs at gentoo.org>,
Type:Standards Track
Content-Type:text/x-rst
Content-Type:text/x-rst
Created:9-Mar-2004

-
-

Contents

+
+

Contents

-
-

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 +

+

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

+
+

Status Update

Repoman has been updated to check for the LICENSE syntax.

-
-

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 +

+

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 +

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 +

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 +

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
@@ -116,96 +358,97 @@
     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 +

+

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 +

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.

-
-

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 +

+

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:

+

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"
 
-
-

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 +

+

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 +

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 +

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.

-
-

Rationale

-

An implementation of this proposal should make it easy for users wishing +

+

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

+ -
-

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.

-
-
-

References

- +
+

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 (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)
- - +