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 > > > <groupname> <license1> ... <licenseN> > > > > 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
