[gentoo-dev] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Simon Stelling
Hello all,

I would like you to share your comments on the attached GLEP with me.

Thanks in advance!

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
GLEP: 52
Title: License Managment in Portage
Version: $Revision: $
Last-Modified: $Date: $
Author: Simon Stelling [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 20-Sep-2006
Post-History: 20-Sep-2006

Abstract


GLEP 23 [1]_ was brought into existance 31 May 2003 to help users that
do not want to implicitly accept any license. Three and a half years later, it
is still not implemented. This GLEP aims at exactly the same target as GLEP
23, but with a different technical approach.

Credits
===

The ideas found in this GLEP originate from or are heavily influenced by 
Iván Pérez Domínguez's and other people's comments on bug 17367 [2]_.

Motivation
==

GLEP 23 has failed to get implemented. This GLEP proposes a quick and easy, yet
elegant way to enhance portage's license handling.

Specification
=

If a certain package requires to - implicitly or explicitly - accept licenses,
it obviously depends upon acceptance of said licenses. The set of licenses a
package depends on may vary, e.g. on the selected USE flags. Dependencies on
specific licenses should be treated no different than dependencies on other
packages, i.e. they should be defined using ``[R,]DEPEND`` syntax.

Every license which a package in the portage tree depends on gets a package in
the ``txt-licenses/`` category. Its ebuild must install the license text to 
``/usr/shared/licenses/``. The initial version shall be 1 if there is no version
specified.

There will also be a bunch of meta-packages: At least

* ``txt-licenses/osi-disapproved-licenses``, 
* ``txt-licenses/fsf-disapproved-licenses``, and 
* ``txt-licenses/gpl-incompatible-licenses``

should exist and be a dependency of
all licenses that possess the respective attribute.

Users can then assure that they do not implicitly agree with a license they
would not agree with explicitly by masking the license's package. If they only
want to accept packages that are e.g. approved by the FSF, they can simply mask
the ``txt-licenses/fsf-disapproved`` package.

Licenses that need to be explicitly accepted before installation of a package
(and only these) should be package.masked by default with a header like
the following:

::

# Simon Stelling [EMAIL PROTECTED] (20 Sep 2006)
# This license needs to be agreed on explicitly to be considered
# legally binding.
# By unmasking and installing the package you agree with its terms.
txt-licenses/wierd-license

As a lot of licenses have the same name as the packages that use it, the 
license's package name should contain a ``-license`` appendix.

The ``LICENSE`` variable currently used in ebuilds should be kept. However, it
should no longer use DEPEND syntax (e.g. || ( )) but a simple list of license
names. This is useful for package indexes like packages.gentoo.org and simple 
What license does this package use? queries.

Backwards Compatibility
===

For a reasonable amount of time, ``repoman`` should simply warn if there is not
at least one dependency to a license package. New ebuilds should make use of the
package-based system.

Once (almost) all ebuilds are ported to the new system, repoman should consider
the lack of a license dependency an error.

References
==

.. [1] GLEP 23
http://www.gentoo.org/proj/en/glep/glep-0023.html
.. [2] Gentoo Bug 17367
http://bugs.gentoo.org/show_bug.cgi?id=17367

Copyright
=

This document has been placed in the public domain.


Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Steev Klimaszewski
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Simon Stelling wrote:
 Hello all,
 
 I would like you to share your comments on the attached GLEP with me.
 
 Thanks in advance!
 
 
 
snip
I think it is over engineering of a non-issue.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFET2j1c+EtXTHkJcRAladAJ9r8VK6WUzjv9Pnextkh8b4N6xPFQCfX+pW
7EBxySyIomhsSDEL7noSFig=
=6LAs
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Steev Klimaszewski
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steev Klimaszewski wrote:
 Simon Stelling wrote:
 Hello all,

 I would like you to share your comments on the attached GLEP with me.

 Thanks in advance!



 snip
 I think it is over engineering of a non-issue.
And to expand, per blubb's request, all you are doing is moving
/usr/portage/licenses out somewhere else on the filesystem.  Now instead
of one file per license, I need a minimum of 5 - the license ebuild,
metadata, changelog, manifest and digest
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFEUBP1c+EtXTHkJcRAjreAJ0Wa1Jj5kmfd4iprrDUTDUbqORm8gCfbyV1
Ee8/WXmCWpMES+9qHjjUxWs=
=IcFw
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Simon Stelling
Steev Klimaszewski wrote:
 I think it is over engineering of a non-issue.

Which non-issue in particular?

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Simon Stelling
Krzysiek Pawlik wrote:
  # Simon Stelling [EMAIL PROTECTED] (20 Sep 2006)
  # This license needs to be agreed on explicitly to be considered
  # legally binding.
  # By unmasking and installing the package you agree with its terms.
  txt-licenses/wierd-license
 
 Why not make the ebuild ask for confirmation? Would work with versioned 
 licenses
 (for example: txt-licenses/wierd-license-2.1 and
 txt-licenses/wierd-license-2.999 - both would require ACK). Breaks portage in 
 a
 way it's interactive, but it's already happening in few ebuilds
 (eutils.eclass::check_license()).

Even assuming you have multiple versions of such a license, the user can
still unmask specific versions in case he really agrees with one version
but not another. If he unmasks just the package, then you can take that
as a he's fine with all of them. The reasoning for doing it this way
is that merges should really be non-interactive wherever possible. Sure,
there are a few exeptions, but they should be kept as rarely as
possible, and avoiding it IS possible in this case.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Michael Cummings
On Wed, 2006-09-20 at 13:36 +0200, Simon Stelling wrote:

 Every license which a package in the portage tree depends on gets a package in
 the ``txt-licenses/`` category. Its ebuild must install the license text to 
 ``/usr/shared/licenses/``. The initial version shall be 1 if there is no 
 version
 specified.

This doesn't make sense to me. I have a copy of every license used in
the portage tree already in /usr/portage/licenses - why dup that again?
We already have an existing LICENSE keywording in the ebuilds, why not
just focus on patching portage to allow a make.conf variable for allowed
licenses and block based on that? 

-- 

-o()o--
Michael Cummings   |#gentoo-dev, #gentoo-perl
Gentoo Perl Dev|on irc.freenode.net 
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E
-o()o--


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Luca Barbato
Simon Stelling wrote:

 GLEP: 52

I don't like it: too complex, glep 23 is fine.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Vlastimil Babka

Michael Cummings wrote:

This doesn't make sense to me. I have a copy of every license used in
the portage tree already in /usr/portage/licenses - why dup that again?
We already have an existing LICENSE keywording in the ebuilds, why not
just focus on patching portage to allow a make.conf variable for allowed
licenses and block based on that? 



+1

--
Vlastimil Babka (Caster)
Gentoo/Java
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Mike Frysinger
On Wednesday 20 September 2006 07:36, Simon Stelling wrote:
 I would like you to share your comments on the attached GLEP with me.

why not just implement GLEP 23
-mike


pgpZSKauYbIhF.pgp
Description: PGP signature


Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Stephen Bennett
On Wed, 20 Sep 2006 13:36:11 +0200
Simon Stelling [EMAIL PROTECTED] wrote:

 I would like you to share your comments on the attached GLEP with me.

It seems to me to be an attempt to move what is obviously the package
manager's job into the tree, and making it far more complex than it
needs to be in the process. The necessary metadata is already in
ebuilds, and has even been changed to a more depend-like syntax for
exactly the purpose of making license handling easier; why duplicate it
in so many places?

The necessary package manager support isn't even all that difficult, so
it's not yet been implemented seems like a poor excuse for offloading
the work onto every single developer instead.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Kevin F. Quinn
On Wed, 20 Sep 2006 10:05:00 -0400
Michael Cummings [EMAIL PROTECTED] wrote:

 On Wed, 2006-09-20 at 13:36 +0200, Simon Stelling wrote:
 
  Every license which a package in the portage tree depends on gets a
  package in the ``txt-licenses/`` category. Its ebuild must install
  the license text to ``/usr/shared/licenses/``. The initial version
  shall be 1 if there is no version specified.
 
 This doesn't make sense to me. I have a copy of every license used in
 the portage tree already in /usr/portage/licenses - why dup that
 again?

Plus the copies in /usr/share/doc.

 We already have an existing LICENSE keywording in the ebuilds,
 why not just focus on patching portage to allow a make.conf variable
 for allowed licenses and block based on that? 

Sounds good enough to me.  Perhaps two variables; ALLOW_LICENSES and
DENY_LICENSES (with wildcard support).

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Mike Frysinger
On Wednesday 20 September 2006 12:43, Kevin F. Quinn wrote:
 Michael Cummings [EMAIL PROTECTED] wrote:
  We already have an existing LICENSE keywording in the ebuilds,
  why not just focus on patching portage to allow a make.conf variable
  for allowed licenses and block based on that?

 Sounds good enough to me.  Perhaps two variables; ALLOW_LICENSES and
 DENY_LICENSES (with wildcard support).

it's called ACCEPT_LICENSES and it's outlined in GLEP 23
-mike


pgp3ftFgsrUeC.pgp
Description: PGP signature


Re: [gentoo-dev] GLEP 52 - GLEP 23 revisited

2006-09-20 Thread Josh Saddler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Simon Stelling wrote:
 Hello all,
 
 I would like you to share your comments on the attached GLEP with me.
 
 Thanks in advance!

While this has a novel approach to the problem (at least, I haven't seen
anything else that tries to solve the LICENSE issue this way), the existing GLEP
23 really does have a much simpler solution. And in this case, the KISS
principle should apply. Rather than adding more stuff to ebuilds or multiple new
directories to the user's system, it's a lot easier to just use existing LICENSE
info and a single line in make.conf to specify what's allowed.

'Course, easier and simpler still don't mean that it's been done yet. *shrug*
IIRC, the other two alternative package managers have implemented it in some
form -- why not take a look at how they did it to see if there are any good
technical solutions (or ideas) present. Or maybe offer a bounty of some sort to
the first person that comes up with the patch for Portage.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFEXuSrsJQqN81j74RAmm5AJ938b0VYR7cylytoJGY3gBi7Uiy7QCgiJjq
79oDXSqIrYvL/o7SWxcmotA=
=AeFg
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list