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, 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 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 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 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.254&r2=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="*" 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. > > > > 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 ? Might want to reread bug 152593 in detail, summary being "legal issues". 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 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 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 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 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 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 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
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-". > > Since the ACCEPT_LICENSE syntax allows -, 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 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 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
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 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 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 Mon, Nov 20, 2006 at 08:05:03PM +0900, Jason Stubbs wrote: > On Sunday 19 November 2006 06:25, Brian Harring wrote: > > 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. > > You're missing the point. It is nothing to do with interactivity. *Cough*, you do realize you're saying that 'NON-INTERACTIVE' has nothing to do with interactivity, right? If that's the case, I'd suggest y'all find a better name for "NON-INTERACTIVE" ;-) Meanwhile, the point that interactivty requires a seperate mechanism still stands (see gpl example above). Read on please, despite the jokes what I'm trying to make y'all see is that interactivity (literal, the ebuild waits on stdin) is a seperate thing from LICENSE (even if a specific license may always require interactive confirmation), as such using such a name (let alone it as default) doesn't make much sense. > It is to do > with check_license and ebuilds for packages that must have their license > explicitly accepted. And what of cdrom_get_cds and friends? They're going to require a restrict due to them being interactive, unless y'all are proposing a special case addition to the ebuilds restrict for when its license is a member of NON-INTERACTIVE... ACCEPT_LICENSE is just a visibility filter on what the user is willing to deal with; it's not a binding agreement to that particular license (wouldn't have to use check_license for EULAs if that were the case), as such the mechanism of actually *accepting* the license is outside of ACCEPT_LICENSE's purview. It's just a filter on *licenses*, not on the mechanism of accepting a license. Try to cram interactivity into it (even if just a badly labeled license group name), give more meaning to the group then what LICENSE is actually about. Label it EULA's if you like. Short and sweet, you still need a matching restrict; as such such a default/name is bleeding restrict into license; again, they're seperate things. > In other words there should be no "*" and the default > ACCEPT_LICENSE should default to everything except ebuilds that are currently > using check_license. Again... what of cdrom_load_next_cd and friends? That functionality (which can require interactivity) may be dealing strictly in GPL code. Do you really think a user who hits that is going to care that NON-INTERACTIVE actually means "non click through EULA licenses"? They're going to be annoyed that the set NON-INTERACTIVE, came back 4 hours later to find that portage is hung waiting on interactive input. In other words... the name at the very least seriously sucks, but wait, theres more! :) > The NON-INTERACTIVE group specified in the original GLEP > specified that set. Then the glep is inconsistant, since the backwards compatibility claims- "There should be no change to the user experience without the user explicitly choosing to do so." NON-INTERACTIVE obviously is not accept all licenses, as such there *is* a change in the behaviour. Further, if you think through the implications of such a label, you're going to realize that without the matching restrict (which is the *real* filtering of interactive ebuilds), someone is going to wind up shoving a fake license into NON-INTERACTIVE for a license that doesn't require user click through. My suggestion would be to drop the NON-INTERACTIVE crap, go back to the '*' original assumptino folks had, and finish off glep52; either that or find a helluva lot better name for NON-INTERACTIVE since it's duplication of what glep52 should address. ~harring pgpE2e7dKOdJg.pgp Description: PGP signature
Re: [gentoo-dev] ACCEPT_LICENSE revisited
On Sunday 19 November 2006 06:25, Brian Harring wrote: > Left out that if it's unset, it should default to ACCEPT_LICENSE=* , > meaning no license filtering. [...] > > 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. You're missing the point. It is nothing to do with interactivity. It is to do with check_license and ebuilds for packages that must have their license explicitly accepted. In other words there should be no "*" and the default ACCEPT_LICENSE should default to everything except ebuilds that are currently using check_license. The NON-INTERACTIVE group specified in the original GLEP specified that set. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
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
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
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 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
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 Sat, Nov 18, 2006 at 01:25:57PM -0800, Brian Harring wrote: > >... 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
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
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, 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/.
> ...
>
> 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 respectiv
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
[gentoo-dev] ACCEPT_LICENSE revisited
Hi, in the past weeks Jason, Zac and myself have been working to implement license based visibility fitlering (aka ACCEPT_LICENSE). This is also discussed in GLEP 23, however the original versions of that document didn't quite go along with the implementation and lacked some details. So here is a new version of it, the main changes are: - added definition of license group files - added license group negation semantics - updated proposed portage behavior to match current implementation (using visibility filtering system instead of blocker system) - added requirement for default ACCEPT_LICENSE in profiles 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). 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. GLEP: 23 Title: Portage handling of ACCEPT_LICENSE Version: $Revision: 1.4 $ Last-Modified: $Date: 2006/11/18 07:27:47 $ Author: Jason Stubbs <[EMAIL PROTECTED]>, Marius Mauch <[EMAIL PROTECTED]> Status: Accepted Type: Standards Track Content-Type: text/x-rst Created: 9-Mar-2004 Post-History: 8-Mar-2004 10-Mar-2004 25-Oct-2004 18-Nov-2006 Abstract Currently, every ebuild in the portage tree is required to have a valid LICENSE entry. However, the syntax of this entry is not officially defined and the entry itself is only used when outputting package details. Status Update = Repoman has been updated to check for the LICENSE syntax. A development portage branch with support for ACCEPT_LICENSE and license groups exists. Motivation == Many users wish to regulate the software they install with regards to licenses for various reasons [1]_. Some want a system free of any software that is not OSI-approved; others are simply curious as to what licenses they are implicitly accepting. Furthermore, some software requires that a user interactively accept its license for its author's to consider it legally binding. This is currently implemented using ``eutils.eclass``. Specification = Ebuild LICENSE Variable --- Most ebuilds are for software which is released under a single license. In these cases, the current LICENSE variable can remain as is. For example: :: LICENSE="single-license" However, there are several ebuilds for software which is released under several licenses, of which the user must accept one, some or all [2]_. To complicate this, some ebuilds include optional components which fall under a different license. 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: :: LICENSE="mandatory-license || ( choosable-licence1 chooseable-license-2 ) useflag? ( optional-component-license )" 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 :: ... 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. 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. 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 e
