Re: [gentoo-dev] ACCEPT_LICENSE revisited

[Brian Harring]

Chris, kindly bunch up your responses into a single email in the 
future- you wind up carpet bombing any thread you have interest in via 
responding to each and every point (even when you're repeating the 
same thing you already said in another retort).

Bit annoying.  Meanwhile...

On Mon, Nov 20, 2006 at 10:14:44AM -0500, Chris Gianelloni wrote:
> On Sat, 2006-11-18 at 13:25 -0800, Brian Harring wrote:
> > > 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.
>
> Except that it shouldn't.  It should be set to @NON-INTERACTIVE, as the
> GLEP says, to match what we currently have with the combination of
> portage+eutils.eclass settings.

ACCEPT_LICENSE is not legally binding; sticking a license in there 
doesn't mean you agree to a license.

I'll repeat that.

It's a filter on what you are willing to deal in, not a binding 
agreement; you agree to the license via usage of the material or via 
click through if it's required.

Doubt?  Read down, Chris you provided an example of why it can only 
be a filter.

I as an admin, set ACCEPT_LICENSE=RTCW-ETEULA; now if a user I've 
granted sudo to, goes and merges enemy-territory, have they 
explicitly agreed to the license?  Note the 'explicit', not 'implicit' 
as the glep throws around.

Licenses are not 'implicit', they're 'explicit'.  The scenario above 
has the user _implicitly_ agreeing to it, not _explicitly_ as the 
annoying licenses require.

Meaning the check_license interactive crap still is required.  Hell, 
your example in bug 152593, RTCW-ETEULA requires

"YOU ACKNOWLEDGE THAT YOU HAVE READ THIS AGREEMENT, YOU UNDERSTAND 
THIS AGREEMENT, AND UNDERSTAND THAT BY CONTINUING THE DOWNLOAD OR 
INSTALLATION OF THE SOFTWARE, BY LOADING OR RUNNING THE SOFTWARE, OR 
BY PLACING OR COPYING THE SOFTWARE ONTO YOUR COMPUTER HARD DRIVE OR 
RAM, YOU AGREE TO BE BOUND BY THE TERMS AND CONDITIONS OF THIS 
AGREEMENT.  YOU FURTHER AGREE THAT, EXCEPT FOR WRITTEN SEPARATE 
AGREEMENTS, IF ANY, BETWEEN ID AND YOU, THIS AGREEMENT IS A
COMPLETE AND EXCLUSIVE STATEMENT OF THE RIGHTS AND LIABILITIES OF THE 
PARTIES HERETO, RELATING TO THE SUBJECT MATTER HEREOF.  THIS AGREEMENT 
SUPERSEDES ALL PRIOR ORAL AGREEMENTS, PROPOSALS OR UNDERSTANDINGS, AND 
ANY OTHER COMMUNICATIONS, IF ANY, BETWEEN ID AND YOU RELATING TO THE 
SUBJECT MATTER OF THIS AGREEMENT."

Read that again.  It requires that anyone even *using* the software 
has to have read the agreement, meaning that anyone merging it still 
needs to see the license (and have time to at the very least read it 
through, technically that in a multi-user setup any user able to even 
access that software has to be forced through agreement to the 
license.

What I'm trying to point out here is that y'all seem to assume 
ACCEPT_LICENSE is binding; in a single-user setup, that claim *might* 
be valid, if you limit licenses involved; The text above directly 
contradicts that, since it requires reading the license, not just 
setting a var without reading it.  Multi-user env, 
ACCEPT_LICENSE as a binding agreement doesn't even remotely fly.

Chris, you stated in 152593 the concern was that of the foundation not 
being sued; pointing out above that even with this support, there is 
no gurantee that the end/merging user has actually even agreed to the 
license (multi-user again), let alone that in single user they've 
actually _really_ agreed to the license as it may require, or that 
they've even seen the license (since ACCEPT_LICENSE doesn't fly in N 
user setups).

ACCEPT_LICENSE does *not* put us in the legal clear as you claim in 
comment #15, matter of fact tend to think it makes things worse since 
the setup assumes that one user setting ACCEPT_LICENSE is binding for 
all which is not a gurantee that can be made when it comes to the 
wording of all licenses.

If y'all are going to keep pushing ACCEPT_LICENSE as binding, I'd 
suggest you query some lawyers about that whole "multi-user" thing 
unix does, and if ACCEPT_LICENSE set by some random user is able to 
bind another user into an agreement (IANAL, but willing to bet 
laughing in your face would follow shortly, followed by an 
explanation even I could understand).

Seriously, go ask; no one commenting here are lawyers, but some folk 
seem to be acting as if they were- if y'all are after pushing 
ACCEPT_LICENSE as a binding mechanism then it would be wise to ensure 
it's not opening up *more* holes.


> Certain packages will *always* require interactive acceptance of the
> license, as they currently do.

Certain licenses, not packages.  It's possible for a package to be 
available under dual licenses, one requiring click through, one not; 
sounds daft, but it's possible since LICENSE depset supports use 
conditionals/flags.  Terminology mind you, but folks get confused 
(right marius?).


> > > 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.
>
> Not really.
>
> Go look at some of my games ebuilds.  While *portage* doesn't do
> anything with the license, the ebuild does, due to licensing
> restrictions.  The idea here is to not lose functionality by moving this
> to portage itself.

Spose I should point out that what folks requested originally was a 
way to filter propietary crap from being used, _not_ try to make 
ACCEPT_LICENSE into a binding agreement on licenses potentially used.

Thing is, user *still* has to do the legwork for most of the 
EULAs due to fun reqs like "must have read this in full"; 
ACCEPT_LICENSE as a binding agreement frankly doesn't work, what folks 
wanted and what actually works is ACCEPT_LICENSE as a filter.

Now... to cover peoples asses, you have to do acceptance at the time 
of merging since one user cannot agree for another.  Meaning you've 
got double acceptance- acceptance in configuration, and a required 
RESTRICT=unattended interactive acceptance.

Not sure why y'all don't see that overlap, but it's there, hence why I 
keep pointing out trying to have a default of NON-INTERACTIVE is 
*actually* getting into the interactive crap.

You can rename it as NON-MUST-HAVE-READ as marius tried, but that's 
just being stupid.  Doesn't change the nature of what it's implying 
(even marius can understand that).


Finally... I'll again point out that the glep is inaccurate.  Claiming 
that there is no change to behaviour (backwards compatibility) while 
turning around leveling a new filter on viewable packages is a change 
in behaviour, claiming otherwise means only that you've not tried the 
patch (or haven't thought it through).

Prior to this glep, you could at least do emerge -p enemy-territory; 
after this glep, you can't, because enemy-territory is masked due to 
license.

Go fix the glep on that issue, it's minor and stupid but it *is* a 
change and no amount of "there are no changes!" claims will change 
reality.

~harring