Re: [gentoo-dev] ACCEPT_LICENSE revisited

[Kevin F. Quinn]

On Tue, 21 Nov 2006 14:03:08 -0500
Chris Gianelloni <wolf31o2@g.o> wrote:

> On Tue, 2006-11-21 at 17:59 +0100, Kevin F. Quinn wrote:
> > Am I correct in thinking that the ACCEPT_LICENSE behaviour will just
> > affect how portage calculates whether something can be installed or
> > not (much like the behaviour w.r.t. KEYWORDS)?  In this is the case,
> > interactivity doesn't have much to do with it.  As Brian suggests, a
> > RESTRICT=interactive seems to be the most appropriate way to allow
> > the admin to prevent portage from trying to install packages that
> > need interaction during the install (whether it's for inserting CDs,
> > accepting licenses, or any other reason).  It depends on what
> > "ACCEPT_LICENSE" means to the package manager.  I take it to mean
> > that the package may be considered for inclusion during emerge -
> > i.e. the sysadmin is happy for portage to attempt to install
> > packages under those licenses onto the system - rather than that
> > licenses are actually accepted by the admin or user.  If that's
> > correct, perhaps naming it "ACCEPTABLE_LICENSES" would be clearer.
>
> It is used to mask the package, correct.  When a package is masked, it
> gives the output of the license, or, if the license it too large (I
> think Marius set it at 20K) informs the user to read the license file.
> It also explains to the user that they will need to read and accept
> the license.
>
> RESTRICT="interactive" should be restricted to only the contents of
> the ebuild.  ACCEPT_LICENSE="RTCW-ETEULA" emerge enemy-territory is
> *not* interactive,

That's what I've missed then.  I didn't realise that setting
ACCEPT_LICENSE would inhibit the interactive confirmation that the
license has been read.  It means that ACCEPT_LICENSE is a list of
licenses that have been accepted (which is not what I thought it was).

> whereas "emerge ut2004-data" always is.  This is
> exactly why we are trying to keep licensing separate from ebuild
> interactivity. They are not the same thing, at all.
>
> ACCEPT_LICENSE needs to be used for backwards compatibility.  It is
> being used currently by many Gentoo users, myself included, for
> licenses which I have accepted.  ACCEPT_LICENSE is very much like
> ACCEPT_KEYWORDS.  We don't use ACCEPTABLE_KEYWORDS, do we?

The suggestion to use ACCEPTABLE_LICENSE was to highlight the
difference; i.e. that ACCEPT_LICENSE means matching licenses have
actually been accepted, rather than ACCEPTABLE_LICENSE meaning licenses
that the system owner allows users to accept.  Since ACCEPT_LICENSE does
affirm the license has been accepted, ACCEPTABLE_LICENSE would be wrong
and that suggestion goes down the pan.  In retrospect it's complete
garbage.

> > Some packages require each user to accept the license explicitly
> > when it is run (e.g. Acrobat Reader), some require it to be accepted
> > explicitly during install (Enemy Territory) - in neither case should
> > portage be taking automatic responsibility for actually accepting
> > the license.
>
> It isn't.  The package manager will not be accepting anything.  The
> *system administrator* does the accepting... just like if I were to
> "emerge enemy-territory" now.
>
> > On naming - please can we avoid calling any group "NOT-<something>".
> > Since the ACCEPT_LICENSE syntax allows -<license>, it's much better
> > to use affirmative names always; in this case for example
> > INTERACTIVE-INSTALL-ACCEPTANCE instead of NON-MUST-HAVE-READ.  One
> > can define
> >
> >   ACCEPTABLE_LICENSES="* -@INTERACTIVE-INSTALL-ACCEPTANCE"
> >
> > easily enough.
>
> Except we don't want that.
>
> We don't want to support ACCEPT_LICENSE="*" including the interactive
> licenses, since that *would* be skipping the requirements on the
> license.  This has been discussed on the bug report, already, but
> unless we made "*" not really equal "*", then it won't work, as it
> won't fill the requirement that the license is accepted.

OK that's fine.  I'd still like to see a positive rather than a
negative name, but I admit I can't think of a good one to cover what
NOT-MUST-HAVE-READ would cover.  Following the discussion about "*"
from the bug (#152593 for those who don't know), I can see why
you'd rather not have a positive list of restricted licenses.  The best
name I can think of to replace "NOT-MUST-HAVE-READ", is "UNRESTRICTED".
That clearly doesn't say anything about interactivity - it's just a
list of all the licenses that have no restrictions on the operation of
portage.

> Now, I ask everyone to go read the bug before posting any more
> comments, since most of this has been discussed quite a bit there,
> and doesn't need to be rehashed.

I didn't realise there was a bug (#152593) - I was responding to the
posting of the GLEP and discussion I've seen here recently.  I've read
it now...

-- 
Kevin F. Quinn