[gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)

[gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)

[Mounir Lamouri]

Hi,

In the context of my GSOC [1] I need to get GLEP 23 [2] fully
implemented and
this means get ACCEPT_LICENSE used with a default value and bug 152593 [3]
fixed.

= GLEP 23 summary =

Most of GLEP 23 features have already been implemented in portage. Some
since
a long time (at least in stable portage) like multiple licenses and
conditional
licenses. License group and ACCEPT_LICENSE is already implemented in portage
2.2 (masked).

= ACCEPT_LICENSE =

Please, have a look at GLEP 23 [2] and read how ACCEPT_LICENSE and license
groups work (it's the main topic). I will repeat some things above but not
everything.

ACCEPT_LICENSE, as ACCEPT_KEYWORDS, will mask/unmask packages based on the
license. User will explicitely know why the package is masked and which
license to accept to have it unmasked. The path of the license is showed to
incite him read it. This feature should help bug 152593 [3] because if
he accepts
the license, we can assume he known what he was doing (ie. we can assume he
read the license) but we will see that in the last part.

= ACCEPT_LICENSE default value =

The ACCEPT_LICENSE default value will impact users, devs and Gentoo.
Users: ebuilds will be masked if their license(s) is(are) not in
ACCEPT_LICENSE
Devs: they will have to maintain license groups and if a specific group is
allowed by default (or not allowed by default) they will have to make
sure new
ebuilds are correctly (un)masked.
Gentoo: we can consider (at least I) that such a value is important and
linked
to our social contract. Are we going to support FSF approved licenses ? OSI
approved ? both ? union of them ? or event more licenses ? This decision is
probably more than only user/dev issue.

There are two ways to see the default value: set it to a set of groups which
will allow automatically a set of licenses or set it to everything
excluding a
set of groups. In other words:
ACCEPT_LICENSE=@APPROVED
or
ACCEPT_LICENSE=* -@NEED_TO_BE_ACCEPTED

That's a main difference because if not checked, an ebuild will be
automatically
masked for license in the first way and automatically unmasked in the
second.

There are some proposition of ACCEPT_LICENSE values for both ways.

* ACCEPT_LICENSE=@NON_EULA
With this value, every license that is not an EULA will have to be in
@NON_EULA
group to let the ebuild available.
PRO: easy for user, except for a few licenses, he will never notice this new
feature.
CON: difficult to maintain for devs: @NON_EULA will be big and you will
have to
think about adding a license to @NON_EULA when pushing it to the tree.

* ACCEPT_LICENSE=* -@EULA
That's actually the unique reason to use the second way (ie. all licenses
accepted except some): masks all EULA. For the user, it's exactly the
same if
everything is done correctly by devs but if the dev forget to add a
license to
the right group, consequences will be different. With this default
value, the
package will be unmasked by default.
In my opinion, the previous default value proposition is in all ways better
than this one. It's probably better to have a forgotten license masked than
unmasked because users will surely complain/file a bug if the package is
masked.

* ACCEPT_LICENSE=@GENTOO_APPROVED
@GENTOO_APPROVED will be a group of approved licenses. It will be different
from NON_EULA as it could be a more restrictive set of licenses like a
combination between @FSF_APPROVED and @OSI_APPROVED. In other words, what
general people call "free software". According to our social contract [4] we
support free software and want Gentoo related work to be licensed in OSI
approved license. And still according to this page, someone (who ?) is
thinking about restrict Gentoo related work to OSI approved _and_ FSF
approved
licenses. Why not set ACCEPT_LICENSE to this same licenses ? It will be more
consistent with our social contract.
PRO: more consistent with social contract
     less work for dev than ACCEPT_LICENSE=@NON_EULA as we can suppose
  @OSI_APPROVED and/or @FSF_APPROVED will not change often
CON: users will probably have more masked packages because of licenses [5]

= About licenses which needs explicit acceptance =

This is not the main topic, but it could be interesting to have your
opinions.

It looks like some licenses need acceptance. I was thinking using a software
means accepting the license. If we really need to make a user accept a
license, printing the license path is enough ? He still can add the license
name in ACCEPT_LICENSE without even reading it. However, I suppose
adding the
license name will be enough for an "approval".
This leads me to think ACCEPT_LICENSE=* should be forbidden.

The point of this message is to get opinions of devs to reach a
consensus then
have this default value approved by the Council.

So, what's your opinion ?

[1] My GSOC is about writing a portage's backend for PackageKit. I will
try to
send a message about it in the next days.
[2] http://www.gentoo.org/proj/en/glep/glep-0023.html
[3] https://bugs.gentoo.org/show_bug.cgi?id=152593
[4] http://www.gentoo.org/main/en/contract.xml
[5] zmedico send me stats about licenses:
"I've attached a script to count how many instances of each license
there are, and how many instances in each group. Here are the group
counts I get:
@FSF-APPROVED 23641
@GPL-COMPATIBLE 22956
@OSI-APPROVED 23284
@other 5998
@total 30549"

Thanks for reading,
Mounir

Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)

[Richard Freeman]

Mounir Lamouri wrote:
> It looks like some licenses need acceptance. 

I prefer the wording: some software vendors claim that their licenses 
must be accepted to use the software.  I'm not aware of any law which 
requires a license to use software - at least not inside the USA (your 
jurisdiction may vary).

A license is certainly required to distribute software - hence 
RESTRICT="mirror" or USE="bindist".  Users typically do not distribute 
software, therefore users typically do not need a license to use it.

 > I was thinking using a software
> means accepting the license. If we really need to make a user accept a
> license, printing the license path is enough ? He still can add the license
> name in ACCEPT_LICENSE without even reading it. However, I suppose
> adding the
> license name will be enough for an "approval".
> This leads me to think ACCEPT_LICENSE=* should be forbidden.
> 

Frankly, I'd like to see ACCEPT_LICENSE=* be the default.  If some are 
concerned about the legal issues then have the default be ACCEPT_LICENSE 
= * -@EULA and let users trim it down to "*" on their own.  Portage 
should not set arbitrary restrictions on preventing accepting *.

I'd definitely like the default to be that packages are accepted unless 
a dev somehow indicates otherwise.  The overwhelming majority of 
packages out there do not have EULA issues.

Keep in mind that licensing is a legal issue, and legal issues are 
determined by the law, and the law is determined by where you live.  If 
a user lives in a country that says you can sell Windows CD-Rs at a 
Lemonade stand, it isn't the job of Gentoo to step in and tell them 
otherwise.  We want to give users the tools they need to help stay 
compliant with the laws that govern them - we don't want to assume the 
responsibility for their compliance.

At least, that is my two cents.

Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)

[Mounir Lamouri]

Richard Freeman wrote:
> Mounir Lamouri wrote:
>> It looks like some licenses need acceptance. 
> I prefer the wording: some software vendors claim that their licenses
> must be accepted to use the software.  I'm not aware of any law which
> requires a license to use software - at least not inside the USA (your
> jurisdiction may vary).
I'm not a lawyer so I can't say for sure some software _need_ explicit
license acceptance to be used. However, I'm quite sure using a software
means accept the license.
Someone experienced in this area is welcome for clarifications.

> A license is certainly required to distribute software - hence
> RESTRICT="mirror" or USE="bindist".  Users typically do not distribute
> software, therefore users typically do not need a license to use it.
I think this vision is too simple. Some licenses add rules and rights
users should know. Some applications can use your personal data (like
picasa) or forbid you to try to do reverse engineering even if
authorized in your country (can't remember name).
So, even if most users don't care, we should at least help them know.
Because, at the moment, I can install something with a license saying "i
can use personal data you put in this app" without even have a clue.

> Frankly, I'd like to see ACCEPT_LICENSE=* be the default.  If some are
> concerned about the legal issues then have the default be
> ACCEPT_LICENSE = * -@EULA and let users trim it down to "*" on their
> own.  Portage should not set arbitrary restrictions on preventing
> accepting *.
>
> I'd definitely like the default to be that packages are accepted
> unless a dev somehow indicates otherwise.  The overwhelming majority
> of packages out there do not have EULA issues.
>
> Keep in mind that licensing is a legal issue, and legal issues are
> determined by the law, and the law is determined by where you live. 
> If a user lives in a country that says you can sell Windows CD-Rs at a
> Lemonade stand, it isn't the job of Gentoo to step in and tell them
> otherwise.  We want to give users the tools they need to help stay
> compliant with the laws that govern them - we don't want to assume the
> responsibility for their compliance.
Sure, licensing is somewhat linked with where you live but I don't think
that's helping your point.
By auto-enabling only a set of licenses we can be sure at 99% users will
be safe. By auto-enabling everything, we can put our users in an illegal
situation where he is living. Better to be a little bit restrictive than
too comprehensive.
I think except for flash plugin and graphic drivers our users will not
be too annoyed by a restrictive ACCEPT_LICENSE. There is only a few app
widely use on GNU/Linux which aren't free. I can only see Skype.
And maybe it will help users to think about alternatives before using
proprietary software.

Mounir

Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)

[Richard Freeman]

Disclaimer - I too am not a lawyer.

Mounir Lamouri wrote:
> I'm not a lawyer so I can't say for sure some software _need_ explicit
> license acceptance to be used. However, I'm quite sure using a software
> means accept the license.
> Someone experienced in this area is welcome for clarifications.
>

Well, the basic gist of the argument is this:
1.  A license is required to do something that you otherwise wouldn't be 
allowed to do.  For example, in my town I'm not allowed to burn garbage, 
but if I got special permission (a license) from the local government I 
could legally disregard the law.
2.  There are no laws that state that it is illegal to run software.
3.  Therefore, I don't need a license to run software - if I obtained it 
legally then it is mine to do with as I wish.

Copying or distribution is a different matter - copyright law forbids 
doing these (except under fair use), and therefore to distribute copies 
of software one requires a license.

> I think this vision is too simple. Some licenses add rules and rights
> users should know. 

Well, some licenses _claim_ to add rules and rights.  Whether they 
actually do so is debatable, and it can depend on the specifics of the 
situation and your legal jurisdiction.

 > Some applications can use your personal data (like
> picasa) or forbid you to try to do reverse engineering even if
> authorized in your country (can't remember name).

Use of personal data is probably more about using an online service, and 
that falls more under the category of a service agreement and not a 
license.  They really aren't the same thing even if companies tend to 
blend them together.  Legally they aren't quite the same thing.

I am not aware of any court which has upheld license provisions that 
prohibit reverse engineering.  Again, almost EVERY proprietary license 
out there makes that claim, but that doesn't make it legally binding.

> So, even if most users don't care, we should at least help them know.
> Because, at the moment, I can install something with a license saying "i
> can use personal data you put in this app" without even have a clue.

I agree that we should make this information available, and I'm all for 
giving users tools to pick and choose what kinds of licenses they're 
willing to potentially subject themselves to.  I just don't think we 
want to be the license police - so even if ACCEPT_LICENSE doesn't 
default to "*" we shouldn't prohibit this setting (and the example 
config file should contain a comment that clearly indicates that portage 
has this option).

Also - any service that makes use of personal data without going to a 
fair amount of effort to ensure the user has agreed with this is asking 
for trouble.  Indeed, in many countries this kind of data is subject to 
a great deal of protection no matter what the dialog box might say to 
the contrary.

> By auto-enabling only a set of licenses we can be sure at 99% users will
> be safe. By auto-enabling everything, we can put our users in an illegal
> situation where he is living. Better to be a little bit restrictive than
> too comprehensive.

I do see the virtue of your argument - probably the practical solution 
would be ACCEPT_LICENSE="* -@EULA" or equivalent.  However, we should 
certainly allow users to change this to ACCEPT_LICENSE=* if they so 
desire.  In any case, not doing so is silly - somebody will just issue a 
patch for portage that does exactly this if we make it hard.  I'd be 
happy to host it in an overlay (or in portage if there were no strong 
objections - though it seems silly to have an internal fork of the 
package manager which is why it should simply be configurable).  Gentoo 
is about choice - we provide the tools, we don't tell users that live in 
Freedomland that Freedom isn't allowed for Gentoo users.  Likewise, if 
Saint Ignutious wants to run "-* GPL" more power to him.

> And maybe it will help users to think about alternatives before using
> proprietary software.
> 

Again, as long as the implementation is one that is designed to _help_ 
our users I think that this is exactly the gentoo way to do things. 
What we don't want to do is police our users, or "help" them in ways 
they don't want to be helped.

Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mounir Lamouri wrote:
> "I've attached a script to count how many instances of each license
> there are, and how many instances in each group. Here are the group
> counts I get:
> @FSF-APPROVED 23641
> @GPL-COMPATIBLE 22956
> @OSI-APPROVED 23284
> @other 5998
> @total 30549"
> 
> Thanks for reading,
> Mounir

I always thought that @OSI-APPROVED would be a proper superset of @FSF-APPROVED,
but these numbers say otherwise.

Marijn

- --
If you cannot read my mind, then listen to what I say.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoisFUACgkQp/VmCx0OL2yujgCfXO3b9ecobv5plZWR+ybdWfXU
ukQAoJWCU28z172+YQu6oiWmH7VshKqn
=4nwA
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On Fri, 29 May 2009 19:17:03 +0200
Mounir Lamouri <volkmar@gentoo.org> wrote:
> Most of GLEP 23 features have already been implemented in portage.
> Some since
> a long time (at least in stable portage) like multiple licenses and
> conditional
> licenses. License group and ACCEPT_LICENSE is already implemented in
> portage 2.2 (masked).

The main show-stopper for this last time it came up was all those X
packages using their package name as a licence. Have you thought of how
to get that glaring QA issue addressed?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)

[Mounir Lamouri]

Ciaran McCreesh wrote:
> On Fri, 29 May 2009 19:17:03 +0200
> Mounir Lamouri <volkmar@gentoo.org> wrote:
>   
>> Most of GLEP 23 features have already been implemented in portage.
>> Some since
>> a long time (at least in stable portage) like multiple licenses and
>> conditional
>> licenses. License group and ACCEPT_LICENSE is already implemented in
>> portage 2.2 (masked).
>>     
>
> The main show-stopper for this last time it came up was all those X
> packages using their package name as a licence. Have you thought of how
> to get that glaring QA issue addressed?
>   
That's a very bad issue I never heard about before.
I would say there is the easy workaround: we fix ACCEPT_LICENSE="*
-@EULA" and this issue will never pop with a "default" configuration.

But I don't like it because anyone setting ACCEPT_LICENSE to anything
will stuck in in.
So, why not creating a Generic-Free-License that could be set for
packages with no clear/clean license but still free. The con of this
solution is we will surely lost some information because we can set
LICENSE="Generic-Free-License" or LICENSE="|| ( Generic-Free-License
MyCreepyLicense )" because we need to have at least
LICENSE="Generic-Free-License".

I see no other options.

If anyone has an idea or suggestion...

Mounir

Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 778 bytes --]

On Mon, 01 Jun 2009 23:01:04 +0200
Mounir Lamouri <volkmar@gentoo.org> wrote:
> > The main show-stopper for this last time it came up was all those X
> > packages using their package name as a licence. Have you thought of
> > how to get that glaring QA issue addressed?
>
> That's a very bad issue I never heard about before.
> 
> I see no other options.
> 
> If anyone has an idea or suggestion...

Honestly, I suggest you find some poor sucker to do what the xorg team
should have done two years ago. It's a fair bit of work to fix all the
licences, but it's the best long term solution. Perhaps you could ask
the Council to see if they could nominate it as a special priority
project and encourage every developer to fix one package.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)

[Mounir Lamouri]

Ciaran McCreesh wrote:
> On Mon, 01 Jun 2009 23:01:04 +0200
> Mounir Lamouri <volkmar@gentoo.org> wrote:
>   
>>> The main show-stopper for this last time it came up was all those X
>>> packages using their package name as a licence. Have you thought of
>>> how to get that glaring QA issue addressed?
>>>       
>> That's a very bad issue I never heard about before.
>>
>> I see no other options.
>>
>> If anyone has an idea or suggestion...
>>     
>
> Honestly, I suggest you find some poor sucker to do what the xorg team
> should have done two years ago. It's a fair bit of work to fix all the
> licences, but it's the best long term solution. Perhaps you could ask
> the Council to see if they could nominate it as a special priority
> project and encourage every developer to fix one package.
>   
I agree it's the best long term solution but I've the feeling this is
going to take a very long time.
This feature (ACCEPT_LICENSE) is important to remove check_license()
call from ebuilds which need user input while merging. Interaction in
ebuild should be avoided and it is a blocker for a fully functional
portage backend for packagekit (my gsoc project).

Maybe cleaning licenses should be done before making this feature
available/mandatory but we should avoid creating a never-ending task.

Mounir

Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)

[Nirbheek Chauhan]

On Tue, Jun 2, 2009 at 3:56 AM, Mounir Lamouri <volkmar@gentoo.org> wrote:
> This feature (ACCEPT_LICENSE) is important to remove check_license()
> call from ebuilds which need user input while merging. Interaction in
> ebuild should be avoided and it is a blocker for a fully functional
> portage backend for packagekit (my gsoc project).
>

Most licenses aren't for usage, but for distribution -- surely you mean EULAs?

-- 
~Nirbheek Chauhan

Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)

[Mounir Lamouri]

Nirbheek Chauhan wrote:
> On Tue, Jun 2, 2009 at 3:56 AM, Mounir Lamouri <volkmar@gentoo.org> wrote:
>   
>> This feature (ACCEPT_LICENSE) is important to remove check_license()
>> call from ebuilds which need user input while merging. Interaction in
>> ebuild should be avoided and it is a blocker for a fully functional
>> portage backend for packagekit (my gsoc project).
>>
>>     
>
> Most licenses aren't for usage, but for distribution -- surely you mean EULAs?
>   
License and EULA is the same for most users and it's exactly the same
for ebuilds/portage.
I don't get your point. check_license() is used to print the license
(it's probably only used for EULA's actually) and wait for user approval
before resume the merge process. The printed license is the license from
LICENSE var.

I'm sorry if I misunderstood something.

Thanks,
Mounir

Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)

[Nirbheek Chauhan]

On Wed, Jun 3, 2009 at 1:22 AM, Mounir Lamouri <volkmar@gentoo.org> wrote:
> Nirbheek Chauhan wrote:
>> Most licenses aren't for usage, but for distribution -- surely you mean EULAs?
>>
> License and EULA is the same for most users and it's exactly the same
> for ebuilds/portage.

EULA is an End-User license agreement, and is to be agreed upon by the
*user*. Not the person installing the program. This means they're (or
should be) prompted at first start-up, not at install. If they're
prompted at install, it's broken.

> I don't get your point. check_license() is used to print the license
> (it's probably only used for EULA's actually) and wait for user approval
> before resume the merge process. The printed license is the license from
> LICENSE var.
>

Since they're prompted at install, *that* behaviour needs to be
changed, not worked around. It should be prompted for every user,
probably by using a config file in ~/.config/eulas + a wrapper which
checks for the EULA having been accepted.


-- 
~Nirbheek Chauhan

Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)

[Mounir Lamouri]

Nirbheek Chauhan wrote:
> On Wed, Jun 3, 2009 at 1:22 AM, Mounir Lamouri <volkmar@gentoo.org> wrote:
>   
>> Nirbheek Chauhan wrote:
>>     
>>> Most licenses aren't for usage, but for distribution -- surely you mean EULAs?
>>>
>>>       
>> License and EULA is the same for most users and it's exactly the same
>> for ebuilds/portage.
>>     
>
> EULA is an End-User license agreement, and is to be agreed upon by the
> *user*. Not the person installing the program. This means they're (or
> should be) prompted at first start-up, not at install. If they're
> prompted at install, it's broken.
>
>   
>> I don't get your point. check_license() is used to print the license
>> (it's probably only used for EULA's actually) and wait for user approval
>> before resume the merge process. The printed license is the license from
>> LICENSE var.
>>
>>     
>
> Since they're prompted at install, *that* behaviour needs to be
> changed, not worked around. It should be prompted for every user,
> probably by using a config file in ~/.config/eulas + a wrapper which
> checks for the EULA having been accepted.
>   
I don't think EULA's have to be accepted by users when launching the
program but when installing it.  It's the way it's done in most cases in
Windows and it has to be done because some EULA's add limitation on
numbers of installations (mostly games).
I admit "End User" should be the real user but you can't install a
program if you do not agree to EULA in most cases. That's funny but some
FOSS on Windows also prompt GPL to make sure the user accept it before
installing.

Mounir