[Nix-dev] Re: Separating Free/non-free package

[Michael Raskin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ludovic Courtès wrote:
>>> I want to be able to automatically distinguish between free [0] and
>>> non-free software,
>> Here we have the first difference. I find your opinion too
>> black-and-white. I mostly consider world grey-and-gray.
> Let’s separate mechanism from policy.  I want to choose a policy of
> installing only free software.  A mechanism is needed to allow it, which
> is the only focus of the message that started this thread.

Yes, but your mechanism should better be useful for someone else.

>>>   2. Does not rely on non-trivial cooperation from other Nixpkgs
>>>      contributors, such as defining accurate ‘meta.license’ or
>>>      ‘meta.license.reviewed’ attributes, etc.
>> If you think that even that is too much to ask,
> I think so.  Otherwise Nixpkgs wouldn’t have non-existent or inaccurate
> ‘meta.license’ tags in the first place.

Well, non-existent is completely natural: it means lack of action. Wrong
tags in presence of fatally vague policy is also non-surprising.

> I think it’s reasonable to expect ‘meta.license’ to be left unchanged
> once it’s been corrected/reviewed.  But the information that it’s been
> reviewed must be stored reliably somewhere.

Do you think that meta.license.reviewed is not enough? OK.

>>>   3. Makes it as easy as possible to share work between the free and
>>>      non-free variants of Nixpkgs.
>> You may want to link a free tool with a half-free auxillary library
> There’s no such thing as “half-free software”, to me.

There are lots of border cases. You may give precise answers, but
reaching consensus among all of us (even among all of us two, not to say
all of us developers..) will be impossible.

>> Seems to go better together.. What you propose doesn't include mandatory
>> developing such guidelines.
> 
> As I said, the guideline is that “free” is defined as in
> http://www.gnu.org/philosophy/free-sw.html.  Corner cases can be handled
> by looking at http://www.gnu.org/licenses/license-list.html,
> http://groups.fsf.org/wiki/Software_blacklist, the debian-legal archive
> and similar sources, and by discussing among us.

The blacklist you linked to contains Mono with a stated problem that
copyright has to be reassigned to Novell for upstream inclusion. I agree
that there is some moral problem with the project, but I don't agree
that that makes Mono non-free. You see that the procedure is not
unambiguous and some things should better be described in more details
for everyone's benefit.

>> So, what solutions do we see?
>>
>> 1. Splitting files
>> 3. top-level/licenses.nix
> I don’t think whether a package is free can be determined automatically
> by looking at its license.  We could devise a “license calculus” for
> common licenses, but it wouldn’t work with custom licenses.

There are license features. Can you redistribute the package, can you
distribute binaries of modified build etc.

> For this reason, I think the main focus should be on “free
> vs. non-free”, not on accurate license tags.  That doesn’t mean I don’t
> value accurate license tags: I think they are important, but they’re not
> enough to achieve the goal of distinguishing free and non-free software.
> 
> Thus I think (1) brings us closer to that goal than (3).
> 
> What do you think?

licenses.nix could contain whatever information we find useful about the
license. You could start with the following:

1) clarify interpretation of "four freedoms" for it to be likely to be
consistent in all the corner cases.

2) for every verified package, put the following in the licenses.txt:
  packageName = {
    fourFreedoms = true; /* or false */
  }

Now, you could also be nice to someone else's needs and include
licenseUrl tag, too. Or maybe licensePath (relative to store path). Or
maybe licenseName.

I also think smart retriever can be written. It could contain rules like
"GPLv3+ -> fourFreedoms". I may later come and add "redistributable" tag.

At any moment I can quickly get the list of packages where value of
license feature "A" is known and value of feature "B" is false, or
whatever query I come up with. Not even to mention that I can trivially
check that the package hasn't been renamed in all-packages.

What I don't like in your approach (1):
1. The change is intrusive.
2. You put off describing the border as precisely as possible.
3. All the intrusive change doesn't allow others to build upon for their
needs.
4. You already admit that you are going to slightly change the semantics
of what you do anyway while designing a hard-to-extend system.

So it seems that you slightly misunderstood (3). You can use it as you
would use the split. You just need to declare exact rules for the tag.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJKt2cuAAoJEE6tnN0aWvw3wikIAIqpIKvTbsacblgQU2txJG5o
Vv8oamQNCT67inyO6Zrn87n8liwKUzvlMdmwHVF46FEBd+Urh4Ymd0/v/s9zibSm
n5yEVZLJWrJlTDjLCuqK42QpERYM0Oyt/8tqmpz7VNSy3XzyF90vjeIeBaRTf1iC
OLdDLW1oKAUPyG6biaJcEfcyxqJUaBKvrhuGAVCZeKv1Uw6pvJI+HmE9rsgk0red
oUe5RTr8Iejcj4iH39bg66xEpVDcA3VWXSdg4oIZlS4FRIMxY2kOCN/oz/EFIPI5
oOAHQiMUjOQJQvyUYDfTS21FsN0p7Ago88QpY9KbjsOaVHtUR7yN6fZ0djq6UGk=
=doMf
-----END PGP SIGNATURE-----