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 "[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.
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 [EMAIL PROTECTED] 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
pgpjNiL1kf6em.pgp
Description: PGP signature
