Re: [gentoo-dev] ACCEPT_LICENSE revisited

[Brian Harring]

On Sat, Nov 18, 2006 at 08:53:36AM +0100, Marius Mauch wrote:
> 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).

Gleps have to be approved prior to being merged mind you 
(ain't process fun?).

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

Would label that 'offered by a DepSet', although requires codifying 
the rules of it (referencing depend string only always struck me as 
odd since it implies that rdepends/pdepends differ, which they don't).


> 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

Resurrecting an old arguement, but profiles is the wrong location for 
this; it's repository metadata (global), not specific to the profile, 
thus should be in metadata/.


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

Route of a bit of duplication I'd think; since you're disallowing 
groups to be used in defining other groups, negation isn't needed; 
that said, I don't see why groups aren't allowed (if they were, 
negation must be allowed)...

If you're going to disallow groups used to define other groups, should 
lay out the reasoning in the glep.


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

Left out that if it's unset, it should default to ACCEPT_LICENSE=* , 
meaning no license filtering.


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

Glep doesn't say anything about overlay stacking of it; know I'll be 
implementing it such that overlay specific license groups only affect 
that overlay, but also know that portage will collapse that and have 
it affect the full repository stack (meaning a redefine in an overlay 
changes the group for PORTDIR).

Would suggest clarifying that.


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

The current default in portage however is that of ACCEPT_LICENSE=*; 
since portage doesn't yet filter on licenses, and since interactive 
ebuilds already exist, _that_ is the default.

Finally, NON-INTERACTIVE shouldn't be a license group; 
RESTRICT=interactive is the route there; you can have gpl software 
distributed on cds that must be interactive (feed cds in as 
requested).

The only solution there would to be to invent a fake license group for 
it and tag it in... which is not what license is about.

Interactivity is a seperate thing from license; keep it that way.


Finally... stupid, but s/portage/package manager/; should be 
an agnostic specification ('specially considering the other two 
already do non-group license filtering since their respective 
inceptions).

~harring