Re: [gentoo-dev] ACCEPT_LICENSE revisited

[Brian Harring]

On Mon, Nov 20, 2006 at 08:05:03PM +0900, Jason Stubbs wrote:
> On Sunday 19 November 2006 06:25, Brian Harring wrote:
> > 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.
>
> You're missing the point. It is nothing to do with interactivity.

*Cough*, you do realize you're saying that 'NON-INTERACTIVE' has 
nothing to do with interactivity, right?  If that's the case, I'd 
suggest y'all find a better name for "NON-INTERACTIVE" ;-)

Meanwhile, the point that interactivty requires a seperate mechanism 
still stands (see gpl example above).

Read on please, despite the jokes what I'm trying to make y'all see is 
that interactivity (literal, the ebuild waits on stdin) is a seperate 
thing from LICENSE (even if a specific license may always require 
interactive confirmation), as such using such a name (let alone it as 
default) doesn't make much sense.


> It is to do
> with check_license and ebuilds for packages that must have their license
> explicitly accepted.

And what of cdrom_get_cds and friends?  They're going to require a 
restrict due to them being interactive, unless y'all are proposing a 
special case addition to the ebuilds restrict for when its license is 
a member of NON-INTERACTIVE...

ACCEPT_LICENSE is just a visibility filter on what the user is willing 
to deal with; it's not a binding agreement to that particular license 
(wouldn't have to use check_license for EULAs if that were the case), 
as such the mechanism of actually *accepting* the license is outside 
of ACCEPT_LICENSE's purview.

It's just a filter on *licenses*, not on the mechanism of accepting a 
license.  Try to cram interactivity into it (even if just a badly 
labeled license group name), give more meaning to the group then what 
LICENSE is actually about.  Label it EULA's if you like.

Short and sweet, you still need a matching restrict; as such such a 
default/name is bleeding restrict into license; again, they're 
seperate things.


> In other words there should be no "*" and the default
> ACCEPT_LICENSE should default to everything except ebuilds that are currently
> using check_license.

Again... what of cdrom_load_next_cd and friends?  That functionality 
(which can require interactivity) may be dealing strictly in GPL code.

Do you really think a user who hits that is going to care that 
NON-INTERACTIVE actually means "non click through EULA licenses"?  
They're going to be annoyed that the set NON-INTERACTIVE, came back 4 
hours later to find that portage is hung waiting on interactive input.

In other words... the name at the very least seriously sucks, but 
wait, theres more! :)


> The NON-INTERACTIVE group specified in the original GLEP
> specified that set.

Then the glep is inconsistant, since the backwards compatibility 
claims-
"There should be no change to the user experience without the user 
explicitly choosing to do so."

NON-INTERACTIVE obviously is not accept all licenses, as such there 
*is* a change in the behaviour.

Further, if you think through the implications of such a label, you're 
going to realize that without the matching restrict (which is the 
*real* filtering of interactive ebuilds), someone is going to wind up 
shoving a fake license into NON-INTERACTIVE for a license that doesn't 
require user click through.

My suggestion would be to drop the NON-INTERACTIVE crap, go back to 
the '*' original assumptino folks had, and finish off glep52; either 
that or find a helluva lot better name for NON-INTERACTIVE since it's 
duplication of what glep52 should address.

~harring