[packagekit] Free and non-free filter

[Tom "spot" Callaway]

On Mon, 2007-12-03 at 21:49 +0000, Richard Hughes wrote:
> On Mon, 2007-12-03 at 16:32 -0500, Robin Norwood wrote:
> > Alrighty.  Do you want to consider the Fedora license list page
> > 'canonical' for the license tags, or do you want to maintain a separate
> > list?
> 
> I don't see the need in a separate list - I really don't want to
> maintain two lists. Do any of the other distros have such a list? The
> fedora one seems to be the most comprehensive.

I think that its a good starting point. At least Mandriva uses our list
(and licensing policies) as is. I doubt Debian will, but their list is a
fraction of what ours is, at this point.

> > With the Fedora page, other distros would have to use our tags, which
> > they probably won't want to do.  Maintaining our own list would be a
> > huge PITA though.
> 
> Tell me about it. :-)
> 
> > Also, at least in Fedora, dual-licensing syntax is allowed.  For
> > instance, the License field for perl is:
> > 
> > (GPL+ or Artistic) and (GPLv2+ or Artistic)
> > 
> > I blame the lawyers.  Well, and Spot, but mostly the lawyers. :-)

You are welcome to blame me, but the truth is that the packages are
entirely to blame, we're only doing what we can to be correct.

> > How do you propose we deal with beasts like the above?  FWIW, the
> > associated comment reads:
> > 
> > # Modules Tie::File and Getopt::Long are licenced under "GPLv2+ or Artistic,"
> > # we have to reflect that in the sub-package containing them.
> > # FIXME: Digest::MD5 has a must-advertise-RSA license with an exception,
> > # the tag does not reflect that (yet).
> 
> Well, which is the "worst" licence?

Honestly, here's what I think you want to do. Break it down into its
chunks, programatically. In perl's case, that would be:

1. GPL+ or Artistic

AND

2. GPLv2+ or Artistic

Then, parse each license in each item.

1. FREE or NON-FREE

AND

2. FREE or NON-FREE

Now, since we've got each with an or, we know we'd be able to choose the
FREE license, and thus the package is FREE. If one of our items came up
as "FREE and NON-FREE", then we'd know that it was a NON-FREE package,
but honestly, we should almost have none of those by this point, a few
Artistic only licensed bits, packages with unapproved licenses (about 15
or so), etc.

> > So, in this case, I'm not entirely sure why the entire package doesn't
> > count as 'GPLv2+ or Artistic', since that's the most specific license
> > that covers the whole package...not counting the Digest::MD5 stuff.
> 
> Again, err on the bad.

You can't really do that, because there is a significant, and
independent portion of that perl package for which it is equally correct
to be used under the terms of GPLv1.

Now, when things are linked together, we don't have to play this game,
we just use the end result of the licensed files in the package, and
only list that in the License tag.

e.g.
"GPLv2 licensed file-gpl.c" linked to "MIT licensed file-mit.c" results
in "GPLv2 licensed binary file"
License: GPLv2

"GPLv2 licensed look.c" compiled into standalone binary "look"
"MIT licensed touch.c" compiled into standalone binary "touch"
License: GPLv2 and MIT

It only gets more complicated from there, but trust me when I say that
if there is an easy, legal out, we've already taken it in the License
tag. This is my world of pain, and trust me, you don't want to stop
here, this is BAT COUNTRY.

> > Fwiw, I don't think the License field for Fedora packages is fully
> > intended to be machine parsable, *but* it is pretty regular, so we can
> > probably get 95% of the way there.
> 
> Sure. I would really like it to be machine readable. Tom, would it be
> possible to formalize more the licence format?

It's extremely formalized, and should already be machine readable.
rpmlint is parsing it right now.

Keep in mind that I'm in India right now for FOSS.in, so my responses
will be massively delayed.

Thanks,

~spot