Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
On Wed, Jun 3, 2009 at 1:22 AM, Mounir Lamouri volk...@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)
Nirbheek Chauhan wrote: On Wed, Jun 3, 2009 at 1:22 AM, Mounir Lamouri volk...@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
Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
Nirbheek Chauhan wrote: On Tue, Jun 2, 2009 at 3:56 AM, Mounir Lamouri volk...@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)
Ciaran McCreesh wrote: On Fri, 29 May 2009 19:17:03 +0200 Mounir Lamouri volk...@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)
On Mon, 01 Jun 2009 23:01:04 +0200 Mounir Lamouri volk...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
Ciaran McCreesh wrote: On Mon, 01 Jun 2009 23:01:04 +0200 Mounir Lamouri volk...@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)
On Tue, Jun 2, 2009 at 3:56 AM, Mounir Lamouri volk...@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)
-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)
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)
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.
