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

[Ludovic Courtès]

Hello,

Michael Raskin <7c6f434c at mail.ru> writes:

> 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.

>>> 1) not breaking existing workflows
>>   1. Is the least intrusive for other contributors (e.g., does not
>>      change the way they work.)
>
> I think that splitting a file into small pieces is intrusive, you
> don't.

I didn’t say that.  The ‘free-packages.nix’ approach was the least
intrusive solution I could think of back then, but I’m happy if a less
intrusive solution can be found.

>>   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.

> you need all information stored so that a developer is not interacting
> with it at all unless meaning to update or query license data. That
> means separate file(s).  top-level/licenses.nix could be the solution.

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.

> Let me explain in more details why with free-packages/all-packages there
> is the same risk of negligence as with meta.license.reviewed clause.

IMO it’s easier to audit a single file (e.g., run “svn annotate” on
‘free-packages.nix’, pay attention to commit logs when that file is
touched, etc.) than to a whole set of files.

>>   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.

> 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.

> So, what solutions do we see?
>
> 1. Splitting files
> 2. Branch
> 3. top-level/licenses.nix
> 4. meta.license overhaul
>
> Now let us kill dominated strategies. (2) has unique advantages (no
> silent package mutation) but it is too heavy to be strictly better than
> something else.

Agreed.

> Of 1,3,4 (4) seems to be the most fragile, but it follows the "package
> information resides in the package" maxima. It also avoids creating new
> global entities. So the comparison of (4) with everything else depends
> on priorities (and our opinions differ here).

Agreed.

> On the other hand, I fail to find any significant reason why (1) may be
> better than (3).

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.

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?

Thanks,
Ludo’.