Re: [gentoo-dev] ACCEPT_LICENSE revisited

[Chris Gianelloni]

On Sat, 2006-11-18 at 18:35 -0800, Brian Harring wrote:
> Meanwhile, the point that interactivty requires a seperate mechanism
> still stands (see gpl example above).

No, it doesn't.  A GPL package has a GPL license.  If that package
requires files from a CD or not has *nothing* to do with the *license*
requiring interactive acceptance.  We're talking licenses here.

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

What does requiring a CD have to do with a license requiring acceptance?

We aren't even *trying* to solve that issue with this.  That is a
separate issue for a separate discussion.

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

Yes and no.  Sure, it means portage will now stop the package from being
installed, rather than it being at the ebuild level, but it will still
be asking the user to accept the license.

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

No, it isn't.

GLEP23 is for things like Enemy Territory
GLEP52 is for things like Maya, UT2004, etc.

They cover different areas of responsibility.  Were it not for the
license, Enemy Territory would *not* be interactive in any way.  This
means we need *two* mechanisms here, one for the license, and one for
the ebuild, which is *exactly* what we have with both GLEPs.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation