Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sun, 2006-11-26 at 13:07 -0500, Mike Frysinger wrote: On Saturday 18 November 2006 02:53, Marius Mauch wrote: Anyone interested in this feature should review the attached version. i've come to the party a bit late ... i cant seem to divine the answer to my question from reading this thread and the GLEP and the bugzilla, so perhaps someone can explicitly spell it out for me ... is there a way in the new GLEP to say never bother me with any license bullcrap ? i made sure the current check_license() function respected the idea of * so that i can put this in my make.conf: ACCEPT_LICENSES=* Ehh... I removed that support some time ago specifically because it allowed people to bypass the checking, which wasn't something *we* can provide while still standing on the legal high ground. So, to answer your question, no. There is no way defined in the GLEP to completely ignore all licensing, which matches what is currently in the tree. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sun, 2006-11-26 at 18:52 -0500, Mike Frysinger wrote: On Sunday 26 November 2006 18:38, Marius Mauch wrote: Mike Frysinger [EMAIL PROTECTED] wrote: is there a way in the new GLEP to say never bother me with any license bullcrap ? i made sure the current check_license() function respected the idea of * so that i can put this in my make.conf: ACCEPT_LICENSES=* Not directly, you'd need to define a local license group including all licenses (could automate that with a postsync hook I guess) and use that in ACCEPT_LICENSE. in other words, your only proposed solution is a hack ? No, the only proposed solution is one that *we* don't provide. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sun, 26 Nov 2006 18:52:19 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: On Sunday 26 November 2006 18:38, Marius Mauch wrote: Mike Frysinger [EMAIL PROTECTED] wrote: is there a way in the new GLEP to say never bother me with any license bullcrap ? i made sure the current check_license() function respected the idea of * so that i can put this in my make.conf: ACCEPT_LICENSES=* Not directly, you'd need to define a local license group including all licenses (could automate that with a postsync hook I guess) and use that in ACCEPT_LICENSE. in other words, your only proposed solution is a hack ? If you want to word it that way: yes. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Monday 27 November 2006 10:48, Marius Mauch wrote: Mike Frysinger [EMAIL PROTECTED] wrote: On Sunday 26 November 2006 18:38, Marius Mauch wrote: Mike Frysinger [EMAIL PROTECTED] wrote: is there a way in the new GLEP to say never bother me with any license bullcrap ? i made sure the current check_license() function respected the idea of * so that i can put this in my make.conf: ACCEPT_LICENSES=* Not directly, you'd need to define a local license group including all licenses (could automate that with a postsync hook I guess) and use that in ACCEPT_LICENSE. in other words, your only proposed solution is a hack ? If you want to word it that way: yes. so why arent we providing a real solution ? -mike pgp4Ma7O3lQpC.pgp Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Mon, Nov 27, 2006 at 05:42:31PM +0100, Marius Mauch wrote: On Mon, 27 Nov 2006 10:53:43 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: On Monday 27 November 2006 10:48, Marius Mauch wrote: Mike Frysinger [EMAIL PROTECTED] wrote: On Sunday 26 November 2006 18:38, Marius Mauch wrote: Mike Frysinger [EMAIL PROTECTED] wrote: is there a way in the new GLEP to say never bother me with any license bullcrap ? i made sure the current check_license() function respected the idea of * so that i can put this in my make.conf: ACCEPT_LICENSES=* Hmm, you sure about that? I don't see how it's doing that as it requires a literal match and globbing is explicitly disabled. That's because of a relatively recent change (as a result of the bug you mentioned in the rest of your message): http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/eutils.eclass?r1=1.254r2=1.255 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Mon, 27 Nov 2006 10:53:43 -0500
Mike Frysinger [EMAIL PROTECTED] wrote:
On Monday 27 November 2006 10:48, Marius Mauch wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
On Sunday 26 November 2006 18:38, Marius Mauch wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
is there a way in the new GLEP to say never bother me with
any license bullcrap ? i made sure the current
check_license() function respected the idea of * so that i
can put this in my make.conf: ACCEPT_LICENSES=*
looks to me like check_license() will effectively ignore '*' in
ACCEPT_LICENSE:
...
local shopts=$-
local alic
set -o noglob #so that bash doesn't expand *
for alic in ${ACCEPT_LICENSE} ; do
if [[ ${alic} == ${l} ]]; then
set +o noglob; set -${shopts} #reset old shell opts
return 0
fi
done
...
It then falls through to interactively requesting confirmation.
Not directly, you'd need to define a local license group
including all licenses (could automate that with a postsync
hook I guess) and use that in ACCEPT_LICENSE.
in other words, your only proposed solution is a hack ?
If you want to word it that way: yes.
so why arent we providing a real solution ?
As I understand it, they're providing a solution that goes as far as it
can without violating the licenses themselves. So you'll be able to
specify all the licenses that don't require explicit acceptance at
installation (@NOT_MUST_HAVE_READ, in the glep proposal), you just won't
be able to say '*' to include the licenses that require explicit
acceptance as well. Since some licenses always have to be excluded,
allowing * would be misleading because it wouldn't be allowed to
match all licenses. Some of the licenses that can't be wildcarded or
grouped are the games licenses from ID Software, for example.
From Chris Gianelloni, earlier in the thread:
We don't want to support ACCEPT_LICENSE=* including the interactive
licenses, since that *would* be skipping the requirements on the
license. This has been discussed on the bug report, already
(re. bug #152593)
I think the sort of license text this is trying to address is:
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.
in particular the download installation bits (loading, running being
user concerns, not sys-admin/portage concerns). IANAL so of course I
can't say whether the proposed rules are necessary and sufficient.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Monday 27 November 2006 11:42, Marius Mauch wrote: Might want to reread bug 152593 in detail, summary being legal issues. no one in there is qualified to give any sort of legal opinion and/or advice if you want a real answer, talk to the pro-bono lawyers that are helping out the Foundation and leave * support in for people who want to opt in for this behavior -mike pgpLwREgyNf09.pgp Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Saturday 18 November 2006 02:53, Marius Mauch wrote: Anyone interested in this feature should review the attached version. i've come to the party a bit late ... i cant seem to divine the answer to my question from reading this thread and the GLEP and the bugzilla, so perhaps someone can explicitly spell it out for me ... is there a way in the new GLEP to say never bother me with any license bullcrap ? i made sure the current check_license() function respected the idea of * so that i can put this in my make.conf: ACCEPT_LICENSES=* the way this is defined matters not so long as the behavior can be achieved (in other words, i dont care if the required setting is * or or unset or ...) -mike pgpq6PB8qZJ1t.pgp Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sun, 26 Nov 2006 13:07:21 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: is there a way in the new GLEP to say never bother me with any license bullcrap ? i made sure the current check_license() function respected the idea of * so that i can put this in my make.conf: ACCEPT_LICENSES=* Not directly, you'd need to define a local license group including all licenses (could automate that with a postsync hook I guess) and use that in ACCEPT_LICENSE. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Tue, 21 Nov 2006 14:03:08 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: It is used to mask the package, correct. When a package is masked, it gives the output of the license, or, if the license it too large (I think Marius set it at 20K) informs the user to read the license file. It also explains to the user that they will need to read and accept the license. The limit was at 2k, however I've dropped that feature before I updated the GLEP as it would only cover about 35% of the licenses in the tree (the rest are 2k) and it would have major issues with non-plaintext licenses (and there are a few licenses using pdf, html or other formats), so now emerge will only refer the user to the licenses file by printing the filename (still need to decide if/how to account for licenses in overlays). Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sunday 26 November 2006 18:38, Marius Mauch wrote: Mike Frysinger [EMAIL PROTECTED] wrote: is there a way in the new GLEP to say never bother me with any license bullcrap ? i made sure the current check_license() function respected the idea of * so that i can put this in my make.conf: ACCEPT_LICENSES=* Not directly, you'd need to define a local license group including all licenses (could automate that with a postsync hook I guess) and use that in ACCEPT_LICENSE. in other words, your only proposed solution is a hack ? -mike pgpIF5BDaabeJ.pgp Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Wed, 2006-11-22 at 01:10 +0100, Marien Zwart wrote: On Tue, Nov 21, 2006 at 04:37:39PM -0500, Chris Gianelloni wrote: Well, we specifically didn't allow a * setting because of this. Ah, I missed that. Thanks. Perhaps we should make it simple and specify that no interactive license should belong to a group? That would mean that since we don't include it in a group, it won't be part of the wildcard NON-INTERACTIVE (or whatever it's called) which would make the behavior the same as we currently have with check_license, since I think adding group support to check_license would be pointless when we're trying to replace it. I think that would be a good idea. Alternatively portage could export ACCEPT_LICENSES with the groups expanded. I think that would be slightly less confusing, although I agree it will probably not come up in practice (since it is not that likely that licenses used with check_license will be used in a group). But relying on that not happening would be a bit icky. Hrrrmn... expanding ACCEPT_LICENSE would make things less ambiguous. I still think that defining that no interactive licenses should be a part of a group would be a good idea. Am I correct in assuming that check_license will be phased out eventually (at some undefined time when everyone runs a portage supporting ACCEPT_LICENSE)? Perhaps it would be a good idea to include some information about how this new portage feature interacts with ACCEPT_LICENSE in the glep (I am assuming more people than just me were not aware check_license checked the ACCEPT_LICENSE env var)? That is, explain licenses included in ACCEPT_LICENSE cause check_license to be silent, and explain if new ebuilds should be using it or not? Correct, check_license will be phased out, as portage will do the job of displaying the license and instructing the user on how to accept it. I do think some more information on how things currently work and how they will work could be useful, as it would remove some of the questions. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Tue, 21 Nov 2006 14:03:08 -0500 Chris Gianelloni [EMAIL PROTECTED] wrote: On Tue, 2006-11-21 at 17:59 +0100, Kevin F. Quinn wrote: Am I correct in thinking that the ACCEPT_LICENSE behaviour will just affect how portage calculates whether something can be installed or not (much like the behaviour w.r.t. KEYWORDS)? In this is the case, interactivity doesn't have much to do with it. As Brian suggests, a RESTRICT=interactive seems to be the most appropriate way to allow the admin to prevent portage from trying to install packages that need interaction during the install (whether it's for inserting CDs, accepting licenses, or any other reason). It depends on what ACCEPT_LICENSE means to the package manager. I take it to mean that the package may be considered for inclusion during emerge - i.e. the sysadmin is happy for portage to attempt to install packages under those licenses onto the system - rather than that licenses are actually accepted by the admin or user. If that's correct, perhaps naming it ACCEPTABLE_LICENSES would be clearer. It is used to mask the package, correct. When a package is masked, it gives the output of the license, or, if the license it too large (I think Marius set it at 20K) informs the user to read the license file. It also explains to the user that they will need to read and accept the license. RESTRICT=interactive should be restricted to only the contents of the ebuild. ACCEPT_LICENSE=RTCW-ETEULA emerge enemy-territory is *not* interactive, That's what I've missed then. I didn't realise that setting ACCEPT_LICENSE would inhibit the interactive confirmation that the license has been read. It means that ACCEPT_LICENSE is a list of licenses that have been accepted (which is not what I thought it was). whereas emerge ut2004-data always is. This is exactly why we are trying to keep licensing separate from ebuild interactivity. They are not the same thing, at all. ACCEPT_LICENSE needs to be used for backwards compatibility. It is being used currently by many Gentoo users, myself included, for licenses which I have accepted. ACCEPT_LICENSE is very much like ACCEPT_KEYWORDS. We don't use ACCEPTABLE_KEYWORDS, do we? The suggestion to use ACCEPTABLE_LICENSE was to highlight the difference; i.e. that ACCEPT_LICENSE means matching licenses have actually been accepted, rather than ACCEPTABLE_LICENSE meaning licenses that the system owner allows users to accept. Since ACCEPT_LICENSE does affirm the license has been accepted, ACCEPTABLE_LICENSE would be wrong and that suggestion goes down the pan. In retrospect it's complete garbage. Some packages require each user to accept the license explicitly when it is run (e.g. Acrobat Reader), some require it to be accepted explicitly during install (Enemy Territory) - in neither case should portage be taking automatic responsibility for actually accepting the license. It isn't. The package manager will not be accepting anything. The *system administrator* does the accepting... just like if I were to emerge enemy-territory now. On naming - please can we avoid calling any group NOT-something. Since the ACCEPT_LICENSE syntax allows -license, it's much better to use affirmative names always; in this case for example INTERACTIVE-INSTALL-ACCEPTANCE instead of NON-MUST-HAVE-READ. One can define ACCEPTABLE_LICENSES=* [EMAIL PROTECTED] easily enough. Except we don't want that. We don't want to support ACCEPT_LICENSE=* including the interactive licenses, since that *would* be skipping the requirements on the license. This has been discussed on the bug report, already, but unless we made * not really equal *, then it won't work, as it won't fill the requirement that the license is accepted. OK that's fine. I'd still like to see a positive rather than a negative name, but I admit I can't think of a good one to cover what NOT-MUST-HAVE-READ would cover. Following the discussion about * from the bug (#152593 for those who don't know), I can see why you'd rather not have a positive list of restricted licenses. The best name I can think of to replace NOT-MUST-HAVE-READ, is UNRESTRICTED. That clearly doesn't say anything about interactivity - it's just a list of all the licenses that have no restrictions on the operation of portage. Now, I ask everyone to go read the bug before posting any more comments, since most of this has been discussed quite a bit there, and doesn't need to be rehashed. I didn't realise there was a bug (#152593) - I was responding to the posting of the GLEP and discussion I've seen here recently. I've read it now... -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Wed, 2006-11-22 at 15:53 +0100, Kevin F. Quinn wrote: RESTRICT=interactive should be restricted to only the contents of the ebuild. ACCEPT_LICENSE=RTCW-ETEULA emerge enemy-territory is *not* interactive, That's what I've missed then. I didn't realise that setting ACCEPT_LICENSE would inhibit the interactive confirmation that the license has been read. It means that ACCEPT_LICENSE is a list of licenses that have been accepted (which is not what I thought it was). Basically, this allows ACCEPT_LICENSE to fill the requirements of allowing filtering on license and *also* allows it to fill the requirements for explicit license acceptance. By default, all licenses that do not require interactive and explicit acceptance are accepted. Now, let's say you didn't want to use any BSD-licensed software. ACCEPT_LICENSE=-BSD would mean, in essence, ACCEPT_LICENSE=@NON-INTERACTIVE -BSD which would give you any package that doesn't require interactive acceptance, except for BSD. ACCEPT_LICENSE=-BSD RTCW-ETEULA would allow you to install Enemy Territory, but not Unreal Tournament 2004. We don't want to support ACCEPT_LICENSE=* including the interactive licenses, since that *would* be skipping the requirements on the license. This has been discussed on the bug report, already, but unless we made * not really equal *, then it won't work, as it won't fill the requirement that the license is accepted. OK that's fine. I'd still like to see a positive rather than a negative name, but I admit I can't think of a good one to cover what NOT-MUST-HAVE-READ would cover. Following the discussion about * from the bug (#152593 for those who don't know), I can see why you'd rather not have a positive list of restricted licenses. The best name I can think of to replace NOT-MUST-HAVE-READ, is UNRESTRICTED. That clearly doesn't say anything about interactivity - it's just a list of all the licenses that have no restrictions on the operation of portage. I'll be honest. I don't care what it is called, so long as the functionality is the same. UNRESTRICTED seems fine to me, but doesn't give a clue as to what restriction it doesn't have. After all, Microsoft's licenses on their corefonts would be UNRESTRICTED under this license, even though it is far from unrestricted. ;] Now, I ask everyone to go read the bug before posting any more comments, since most of this has been discussed quite a bit there, and doesn't need to be rehashed. I didn't realise there was a bug (#152593) - I was responding to the posting of the GLEP and discussion I've seen here recently. I've read it now... No problem. I thought it had been mentioned when the original posting from Marius was done, but it might not have been. Anyway, I'm glad that I've now pointed people there so they can see the discussion that took place to get us to where we are now. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ACCEPT_LICENSE revisited
Ciaran McCreesh wrote: On Sat, 18 Nov 2006 13:49:12 -0800 Mike Doty [EMAIL PROTECTED] wrote: | The other option is to submit patches for X and KDE and Gnome to use | a unified license. At least in the X case, it's not that the patches | arn't welcome, it's that the maintainers have things more important | to do than cleaning up after the mess upstream made of the licenses. So you're saying that the X maintainers have more important things to do than fixing their ebuilds to follow policy? You keep saying it breaks policy but you've never actually cited any policy it breaks. And yes, I do have better things to do than incredibly boring tasks like this. I do Gentoo stuff because it's interesting. If this interests you, submit a patch -- it would probably take less time than all the complaining you've done about it. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sun, 19 Nov 2006 00:10:59 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | So you're saying that the X maintainers have more important things | to do than fixing their ebuilds to follow policy? | | You keep saying it breaks policy but you've never actually cited any | policy it breaks. It breaks GLEP 23, which is an accepted GLEP and thus policy. It also flies in the face of how everyone else does their thing. You don't see one licence per package for anything else. | And yes, I do have better things to do than incredibly boring tasks | like this. I do Gentoo stuff because it's interesting. That is not an excuse to commit broken things that hurt the users. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
Ciaran McCreesh wrote: On Sun, 19 Nov 2006 00:10:59 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | So you're saying that the X maintainers have more important things | to do than fixing their ebuilds to follow policy? | | You keep saying it breaks policy but you've never actually cited any | policy it breaks. It breaks GLEP 23, which is an accepted GLEP and thus policy. Which part of GLEP 23 does it break? Please show me the text. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sun, 19 Nov 2006 12:13:33 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Sun, 19 Nov 2006 00:10:59 -0800 Donnie Berkholz | [EMAIL PROTECTED] wrote: | | So you're saying that the X maintainers have more important | | things to do than fixing their ebuilds to follow policy? | | | | You keep saying it breaks policy but you've never actually cited | | any policy it breaks. | | It breaks GLEP 23, which is an accepted GLEP and thus policy. | | Which part of GLEP 23 does it break? Please show me the text. Cut the crap, Donnie. We all know you're not that stupid, so stop pretending you are. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sat, 18 Nov 2006 08:53:36 +0100 Marius Mauch [EMAIL PROTECTED] wrote: | Anyone interested in this feature should review the attached version. | Unless there are major objections (or we find large problems in the | implementation) this will be merged in one of the next portage | releases (definitely not in 2.1.2 though). 133594 will need to be fixed before this is usable for most users. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sat, Nov 18, 2006 at 08:53:36AM +0100, Marius Mauch wrote:
Anyone interested in this feature should review the attached version.
Unless there are major objections (or we find large problems in the
implementation) this will be merged in one of the next portage releases
(definitely not in 2.1.2 though).
Gleps have to be approved prior to being merged mind you
(ain't process fun?).
To accomodate these cases, LICENSE syntax should accomodate all
functionality offered by a DEPEND string. To keep things simple, this
GLEP proposes that the syntax be identical. For example:
Would label that 'offered by a DepSet', although requires codifying
the rules of it (referencing depend string only always struck me as
odd since it implies that rdepends/pdepends differ, which they don't).
License Groups
--
Almost all users are willing to install any software that is
FSF-approved. Other users are willing to install any software and
implicitly accept its license. To this end, portage will also need to
handle grouping of licenses.
At a minimum, there needs to be the groups ``GPL-COMPATIBLE``,
``FSF-APPROVED``, ``OSI-APPROVED`` and ``NON-INTERACTIVE``.
``NON-INTERACTIVE`` licenses are those that don't require interactive
acceptance for to be considered legally binding. This is the current
behaviour of portage.
These groups are defined in a new file ``license_groups`` in
the ``profiles`` subdirectory of the tree (or overlays).
The format of this file is
Resurrecting an old arguement, but profiles is the wrong location for
this; it's repository metadata (global), not specific to the profile,
thus should be in metadata/.
groupname license1 license2 ... licenseN
Also any line starting with # is ignored and may be used for comments.
License groups may not contain negated elements, so a group
::
mygroup foo -bar -bla
is illegal.
Route of a bit of duplication I'd think; since you're disallowing
groups to be used in defining other groups, negation isn't needed;
that said, I don't see why groups aren't allowed (if they were,
negation must be allowed)...
If you're going to disallow groups used to define other groups, should
lay out the reasoning in the glep.
ACCEPT_LICENSE
--
This GLEP proposes that a user be able to explicitly accept or decline
licenses by editing a new variable ``ACCEPT_LICENSE`` in
``/etc/make.conf``. Again, to keep things simple, the syntax should be
similar to that of other incrementals. For example:
::
ACCEPT_LICENSE=-* accepted-license -declined-license
As an extension, ``ACCEPT_LICENSE`` must also support `license groups`_.
This GLEP proposes that the license group be prepended by the special
character [EMAIL PROTECTED]. For example:
::
ACCEPT_LICENSE=-* @FSF-APPROVED
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.
Portage Behaviour
-
Unaccepted licenses will be treated like any other masked package, that is
emerge will display a message listing any license that has to be accepted
before the package can be merged with a pointer to the exact license text.
Glep doesn't say anything about overlay stacking of it; know I'll be
implementing it such that overlay specific license groups only affect
that overlay, but also know that portage will collapse that and have
it affect the full repository stack (meaning a redefine in an overlay
changes the group for PORTDIR).
Would suggest clarifying that.
Backwards Compatibility
===
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 [EMAIL PROTECTED] 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.
Finally, NON-INTERACTIVE shouldn't be a license group;
RESTRICT=interactive is the route there; you can have gpl software
distributed on cds that must be interactive (feed cds in as
requested).
The only solution there would to be to invent a fake license group for
it and tag it in... which is not what license is about.
Interactivity is a seperate thing from license; keep it that way.
Finally... stupid, but s/portage/package manager/; should be
an agnostic specification ('specially considering the other two
already do non-group license filtering since their respective
inceptions).
~harring
Re: [gentoo-dev] ACCEPT_LICENSE revisited
Ciaran McCreesh wrote: On Sat, 18 Nov 2006 08:53:36 +0100 Marius Mauch [EMAIL PROTECTED] wrote: | Anyone interested in this feature should review the attached version. | Unless there are major objections (or we find large problems in the | implementation) this will be merged in one of the next portage | releases (definitely not in 2.1.2 though). 133594 will need to be fixed before this is usable for most users. I'm sure it's been talked about before, but the ability to group licenses would solve that. Just create a X.Org license group and add all the individual modular X licenses to it. --Mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sat, 18 Nov 2006 15:22:36 -0600 Mike Doty [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Sat, 18 Nov 2006 08:53:36 +0100 Marius Mauch [EMAIL PROTECTED] | wrote: | | Anyone interested in this feature should review the attached | | version. Unless there are major objections (or we find large | | problems in the implementation) this will be merged in one of the | | next portage releases (definitely not in 2.1.2 though). | | 133594 will need to be fixed before this is usable for most users. | | I'm sure it's been talked about before, but the ability to group | licenses would solve that. Just create a X.Org license group and add | all the individual modular X licenses to it. And then create a KDE licence group, and a Gnome licence group, and so on? Remember that there are only a few X licences once you ignore copyright line differences, just as there are only a few KDE licences once you ignore copyright line differences. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sat, Nov 18, 2006 at 01:25:57PM -0800, Brian Harring wrote: groupname license1 license2 ... licenseN Minor addendum here (dotting the i's as it were), but valid license names aren't actually defined anywhere; would suggest nailing down the exact rules of it. [a-Z][0-9]-_. looks to roughly cover it. ~harring pgp1LjbNfk2og.pgp Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
Ciaran McCreesh wrote: On Sat, 18 Nov 2006 15:22:36 -0600 Mike Doty [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Sat, 18 Nov 2006 08:53:36 +0100 Marius Mauch [EMAIL PROTECTED] | wrote: | | Anyone interested in this feature should review the attached | | version. Unless there are major objections (or we find large | | problems in the implementation) this will be merged in one of the | | next portage releases (definitely not in 2.1.2 though). | | 133594 will need to be fixed before this is usable for most users. | | I'm sure it's been talked about before, but the ability to group | licenses would solve that. Just create a X.Org license group and add | all the individual modular X licenses to it. And then create a KDE licence group, and a Gnome licence group, and so on? Remember that there are only a few X licences once you ignore copyright line differences, just as there are only a few KDE licences once you ignore copyright line differences. The other option is to submit patches for X and KDE and Gnome to use a unified license. At least in the X case, it's not that the patches arn't welcome, it's that the maintainers have things more important to do than cleaning up after the mess upstream made of the licenses. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Saturday 18 November 2006 22:49, Mike Doty wrote: The other option is to submit patches for X and KDE and Gnome to use a unified license. Would like to precise that KDE team reports correctly as GPL-2 or LGPL-2.1 the licenses for every package. The only problem there is that there's no way to differentiate between GPL-2 and GPL-2+ but that's beside the point. So no, there's no need to submit patches to the KDE team. I think the same applies to GNOME, but I'll leave those who handle that to answer by theirselves. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpWKDdSTq0cJ.pgp Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sat, 18 Nov 2006 13:49:12 -0800 Mike Doty [EMAIL PROTECTED] wrote: | The other option is to submit patches for X and KDE and Gnome to use | a unified license. At least in the X case, it's not that the patches | arn't welcome, it's that the maintainers have things more important | to do than cleaning up after the mess upstream made of the licenses. So you're saying that the X maintainers have more important things to do than fixing their ebuilds to follow policy? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sat, 18 Nov 2006 22:59:36 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | So no, there's no need to submit patches to the KDE team. I think the | same applies to GNOME, but I'll leave those who handle that to answer | by theirselves. Right. Gnome is also correct, despite having lots of packages that use maybe a dozen licences between them. Which was my point... Everyone else manages to get it right... -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
And then create a KDE licence group, and a Gnome licence group, and so on? Remember that there are only a few X licences once you ignore copyright line differences, just as there are only a few KDE licences once you ignore copyright line differences. The other option is to submit patches for X and KDE and Gnome to use a unified license. At least in the X case, it's not that the patches arn't welcome, it's that the maintainers have things more important to do than cleaning up after the mess upstream made of the licenses. The problem is being overlooked here. Fact is, a feature which *is* being added to portage in the next few releases will be very problematic for folks wishing to install X using portage. Whether the X maintainers feel they have time or not is irrelevant if the portage devs go ahead with this. -Steve signature.asc Description: PGP signature
