Re: [gentoo-dev] RFC: license group file format

[Chris Gianelloni]

On Thu, 2006-10-26 at 21:43 +0200, Marius Mauch wrote:
> On Thu, 26 Oct 2006 12:50:01 -0500
> Grant Goodyear <g2boojum@g.o> 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