Hi,
in the past weeks Jason, Zac and myself have been working to implement
license based visibility fitlering (aka ACCEPT_LICENSE). This is also
discussed in GLEP 23, however the original versions of that document
didn't quite go along with the implementation and lacked some details.
So here is a new version of it, the main changes are:
- added definition of license group files
- added license group negation semantics
- updated proposed portage behavior to match current implementation
(using visibility filtering system instead of blocker system)
- added requirement for default ACCEPT_LICENSE in profiles
Anyone interested in this feature should review the attached version.
Unless there are major objections (or we find large problems in the
implementation) this will be merged in one of the next portage releases
(definitely not in 2.1.2 though).
Marius
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
GLEP: 23
Title: Portage handling of ACCEPT_LICENSE
Version: $Revision: 1.4 $
Last-Modified: $Date: 2006/11/18 07:27:47 $
Author: Jason Stubbs <[EMAIL PROTECTED]>, Marius Mauch <[EMAIL PROTECTED]>
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
::
<groupname> <license1> <license2> ... <licenseN>
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 "[EMAIL PROTECTED]". 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 [EMAIL PROTECTED] 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.
