Re: [gentoo-dev] RFC: license group file format
On Thu, 26 Oct 2006 21:43:56 +0200 Marius Mauch <[EMAIL PROTECTED]> wrote: | > At the risk of reopening a large can of worms, can somebody explain | > to me why the license groups idea won't run into the same conceptual | > issues that derailed GLEP 29 (USE groups)? Am I missing something | > obvious? | | Maybe my memory is wrong, but wasn't the problem only that people | couldn't agree on one set of semantics for negations and being afraid | of confusing users? No. The big problem with use groups was that they were designed to solve one particular problem: bulk enabling / disabling of use flags, but certain people also wanted to use them for use flag categorisation, for which the proposal sucked. -- 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] RFC: license group file format
On Thu, 26 Oct 2006 21:43:56 +0200 Marius Mauch <[EMAIL PROTECTED]> wrote: > On Thu, 26 Oct 2006 12:50:01 -0500 > Grant Goodyear <[EMAIL PROTECTED]> wrote: > > > Marius Mauch wrote: [Thu Oct 26 2006, 12:02:59PM CDT] > > > Ok, as there is currently a lot of work going on for GLEP 23 > > > (licese based visibility filtering aka ACCEPT_LICENSE) the topic > > > of license groups came up, in particular the way how they should > > > be (technically) defined. > > > > > > The simplest way is a line based format > > > ... > > > > At the risk of reopening a large can of worms, can somebody explain > > to me why the license groups idea won't run into the same conceptual > > issues that derailed GLEP 29 (USE groups)? Am I missing something > > obvious? > > Maybe my memory is wrong, but wasn't the problem only that people > couldn't agree on one set of semantics for negations and being afraid > of confusing users? In that case I don't see a big problem as long as > the semantics are clearly defined, as most users will probably stick > with just one predefined group (if they use this feature at all) > adjusted by a few handpicked licenses. Little discussion in #gentoo-portage resulted in the conclusion that license groups may only contain positive elements, and negating a license group will negate all elements contained in it. This avoids the nasty problem of double negation that was IIRC one of the killers for GLEP 29. 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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: license group file format
On Thu, 2006-10-26 at 21:43 +0200, Marius Mauch wrote: > On Thu, 26 Oct 2006 12:50:01 -0500 > Grant Goodyear <[EMAIL PROTECTED]> wrote: > > > Marius Mauch wrote: [Thu Oct 26 2006, 12:02:59PM CDT] > > > Ok, as there is currently a lot of work going on for GLEP 23 > > > (licese based visibility filtering aka ACCEPT_LICENSE) the topic of > > > license groups came up, in particular the way how they should be > > > (technically) defined. > > > > > > The simplest way is a line based format > > > ... > > > > At the risk of reopening a large can of worms, can somebody explain to > > me why the license groups idea won't run into the same conceptual > > issues that derailed GLEP 29 (USE groups)? Am I missing something > > obvious? > > Maybe my memory is wrong, but wasn't the problem only that people > couldn't agree on one set of semantics for negations and being afraid of > confusing users? In that case I don't see a big problem as long as the > semantics are clearly defined, as most users will probably stick with > just one predefined group (if they use this feature at all) adjusted by > a few handpicked licenses. Well, many license groups are already defined for us. I think a simple solution is for us to severely limit the number of arbitrary groups that we create. Here's some groups that I see as non-arbitrary currently: OSI approved[1] GPL compatible/Free software[2] GPL incompatible/Free software[3] FSF Approved (the above two groups together) FSF Non-Free software[4] (This one might not be as easy) Free Documentation[5] FSF Non-Free Documentation[6] (Again, this one might not be sufficient) There are a couple other pre-defined groups on http://www.gnu.org/philosophy/license-list.html but I really don't know how they would be used. There's also Debian's list[7] of licenses, but I don't know if they overlap with any of the above enough to warrant using them by themselves. There's also two groups that are somewhat defined already within Gentoo. These are: Non-Interactive Interactive Currently, all license fall under the "Non-Interactive" group except for the few licenses that are checked via check_license in eutils.eclass due to restrictions within the licenses themselves. A good example of this is the RTCW-ETEULA license, which was actually the license that brought about check_license in the first place. Remember that GLEP 23 mandates that ACCEPT_LICENSE is set to @NON-INTERACTIVE by default, which means there will be no changes for most users. The only changes that will be noticed by anyone are: - Packages with a license you haven't accepted will now be masked during dependency resolution by portage, displaying a message pointing the user to the Handbook/man page, which will tell the user how to add a license to ACCEPT_LICENSE in make.conf - Users will be able to, for example, set ACCEPT_LICENSE="-* @FSF-APPROVED @OSI-APPROVED" Since both check_license and portage itself will be using the same variable ACCEPT_LICENSE, users won't be bothered by a masked package and then also asked interactively to accept the license. This also moves the failing/pausing because of a license from when the package is being merged to dependency resolution, meaning no more getting caught on package 142/348 because of a license. At this point, nobody is talking about creating our own license groups, but that could be done (at any time, really). At this point, it is irrelevant, since we're interested in getting the support in portage itself, as well as ensuring that users are not impacted heavily. [1] http://www.opensource.org/licenses/ [2] http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses [3] http://www.gnu.org/philosophy/license-list.html#GPLIncompatibleLicenses [4] http://www.gnu.org/philosophy/license-list.html#NonFreeSoftwareLicense [5] http://www.gnu.org/philosophy/license-list.html#FreeDocumentationLicenses [6] http://www.gnu.org/philosophy/license-list.html#NonFreeDocumentationLicenses [7] http://www.debian.org/legal/licenses/ -- 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] RFC: license group file format
On Thu, 26 Oct 2006 12:50:01 -0500 Grant Goodyear <[EMAIL PROTECTED]> wrote: > Marius Mauch wrote: [Thu Oct 26 2006, 12:02:59PM CDT] > > Ok, as there is currently a lot of work going on for GLEP 23 > > (licese based visibility filtering aka ACCEPT_LICENSE) the topic of > > license groups came up, in particular the way how they should be > > (technically) defined. > > > > The simplest way is a line based format > > ... > > At the risk of reopening a large can of worms, can somebody explain to > me why the license groups idea won't run into the same conceptual > issues that derailed GLEP 29 (USE groups)? Am I missing something > obvious? Maybe my memory is wrong, but wasn't the problem only that people couldn't agree on one set of semantics for negations and being afraid of confusing users? In that case I don't see a big problem as long as the semantics are clearly defined, as most users will probably stick with just one predefined group (if they use this feature at all) adjusted by a few handpicked licenses. 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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: license group file format
On Thu, 26 Oct 2006 10:15:56 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > Marius Mauch wrote: > > Ok, as there is currently a lot of work going on for GLEP 23 > > (licese based visibility filtering aka ACCEPT_LICENSE) the topic of > > license groups came up, in particular the way how they should be > > (technically) defined. > > > > The simplest way is a line based format > > ... > > however this doesn't allow for any addition of metadata (for example > > descriptions to explain the purpose of a group), these (if wanted) > > would have to be defined in another file. The alternative would be > > to use a more complex file format, for example so called ini-style > > > > [groupname] > > licenses=license1 license2 ... licenseN > > description=Sample license group > > constains_stupid_licenses=1 > > Some way to express metadata makes sense, but ini-style doesn't fit in > with any existing configuration format portage (in the broader sense, > not the sys-apps/portage sense) uses (make.conf, metadata.xml, etc) -- > does it? Well, there have been long-term plans to introduce it into portage (for example to replace the make.conf parser which suffers from a few limitations or to make $FEATURES more flexible), but just plans so far. Thing is that most formats we currently have are one-dimensional (a=b) while for this (groups with metadata) we would need something two-dimensional (a[b]=c). Mind that I mentioned the ini-style format just as an example (it has the benefit that we'd get the parser for free), we're completely open to alternatives. 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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: license group file format
Uhoh, forgive me for not reading the other replies before writing a completely redundant one. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: license group file format
Marius Mauch wrote: > Ok, as there is currently a lot of work going on for GLEP 23 > (licese based visibility filtering aka ACCEPT_LICENSE) the topic of > license groups came up, in particular the way how they should be > (technically) defined. > > The simplest way is a line based format > ... > however this doesn't allow for any addition of metadata (for example > descriptions to explain the purpose of a group), these (if wanted) would > have to be defined in another file. The alternative would be to use a > more complex file format, for example so called ini-style Uhm, what kind of metadata are we talking about here? Descriptions can just be placed in comments above the group specification line, no? -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: license group file format
Marius Mauch wrote: [Thu Oct 26 2006, 12:02:59PM CDT] > Ok, as there is currently a lot of work going on for GLEP 23 > (licese based visibility filtering aka ACCEPT_LICENSE) the topic of > license groups came up, in particular the way how they should be > (technically) defined. > > The simplest way is a line based format > ... At the risk of reopening a large can of worms, can somebody explain to me why the license groups idea won't run into the same conceptual issues that derailed GLEP 29 (USE groups)? Am I missing something obvious? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpLeK9kqToiv.pgp Description: PGP signature
Re: [gentoo-dev] RFC: license group file format
On Thu, 26 Oct 2006 20:18:40 +0200 Harald van Dijk <[EMAIL PROTECTED]> wrote: > On Thu, Oct 26, 2006 at 07:02:36PM +0200, Marius Mauch wrote: > > Ok, as there is currently a lot of work going on for GLEP 23 > > (licese based visibility filtering aka ACCEPT_LICENSE) the topic of > > license groups came up, in particular the way how they should be > > (technically) defined. > > > > The simplest way is a line based format > > ... > > however this doesn't allow for any addition of metadata (for example > > descriptions to explain the purpose of a group), these (if wanted) > > would have to be defined in another file. > > A description could be provided in the same file, by allowing > comments. Hmm, that's an option I hadn't considered yet, though means we can't use grablist() for parsing :( [not a big issue though] > > The alternative would be to use a > > more complex file format, for example so called ini-style > > > > [groupname] > > licenses=license1 license2 ... licenseN > > description=Sample license group > > constains_stupid_licenses=1 > > Something like contains_stupid_licenses (even in an objective form) > could be handled differently: a STUPID_LICENSES group, so that > ACCEPT_LICENSE can contain "@GROUP1 @GROUP2 [EMAIL PROTECTED]". Do you > have an example of metadata other than the description that cannot be > dealt with another way? Not at this time, that's why I invented this one (it's completely made up by me with no meaning whatsoever, just in case anybody wonders what it might be supposed to do). However as this is rather new territory I'm not sure if we should limit ourselves to one metadata value at this time. 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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: license group file format
On Thu, Oct 26, 2006 at 07:02:36PM +0200, Marius Mauch wrote: > Ok, as there is currently a lot of work going on for GLEP 23 > (licese based visibility filtering aka ACCEPT_LICENSE) the topic of > license groups came up, in particular the way how they should be > (technically) defined. > > The simplest way is a line based format > ... > however this doesn't allow for any addition of metadata (for example > descriptions to explain the purpose of a group), these (if wanted) would > have to be defined in another file. A description could be provided in the same file, by allowing comments. > The alternative would be to use a > more complex file format, for example so called ini-style > > [groupname] > licenses=license1 license2 ... licenseN > description=Sample license group > constains_stupid_licenses=1 Something like contains_stupid_licenses (even in an objective form) could be handled differently: a STUPID_LICENSES group, so that ACCEPT_LICENSE can contain "@GROUP1 @GROUP2 [EMAIL PROTECTED]". Do you have an example of metadata other than the description that cannot be dealt with another way? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: license group file format
Marius Mauch wrote: > Ok, as there is currently a lot of work going on for GLEP 23 > (licese based visibility filtering aka ACCEPT_LICENSE) the topic of > license groups came up, in particular the way how they should be > (technically) defined. > > The simplest way is a line based format > ... > however this doesn't allow for any addition of metadata (for example > descriptions to explain the purpose of a group), these (if wanted) would > have to be defined in another file. The alternative would be to use a > more complex file format, for example so called ini-style > > [groupname] > licenses=license1 license2 ... licenseN > description=Sample license group > constains_stupid_licenses=1 Some way to express metadata makes sense, but ini-style doesn't fit in with any existing configuration format portage (in the broader sense, not the sys-apps/portage sense) uses (make.conf, metadata.xml, etc) -- does it? Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: license group file format
Ok, as there is currently a lot of work going on for GLEP 23 (licese based visibility filtering aka ACCEPT_LICENSE) the topic of license groups came up, in particular the way how they should be (technically) defined. The simplest way is a line based format ... however this doesn't allow for any addition of metadata (for example descriptions to explain the purpose of a group), these (if wanted) would have to be defined in another file. The alternative would be to use a more complex file format, for example so called ini-style [groupname] licenses=license1 license2 ... licenseN description=Sample license group constains_stupid_licenses=1 So what do you prefer? 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. -- gentoo-dev@gentoo.org mailing list
