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

[Michael Raskin]

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

Ludovic Courtès wrote:

Seems that now there is an opportunity to discuss some differences in
detail..

>> 2) possibility to present more detailed licensing information
>> 3) possibility to process data automatically
>> 4) guidelines for analyzing the license
> 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.. You ask for a
single bit, I claim that it is of very limited use unless it can be
easily expanded.

I will gladly support solution which describes four-freedoms bit first
with a clear, consistent and convenient way to support more data.
free-packages.nix does not look like such a solution.

>> 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.. But responses seem to indicate that my opinion matches what
others feel.

So, we need to store this information in a way that doesn't affect the
rest of package information.

>   2. Does not rely on non-trivial cooperation from other Nixpkgs
>      contributors, such as defining accurate ‘meta.license’ or
>      ‘meta.license.reviewed’ attributes, etc. 

Let me state my counter-point once more. I agree that no guaranteed
cooperation by action is to be expected. Do you not also believe in
cooperation by lack of action?

If you think that even that is too much to ask, 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.

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.

Imagine a very useful debugging tool (like a library you need to link
with) with a license allowing only redistribution of source tarball
verbatim, and separate distribution of patches. I find depending on such
a tool totally fine for myself as I consider it "essentially 4-freedoms
compliant", but it may end up in non-free part. I am not pushing reality
too much - after all, remember Knuth's TeX licensing (he included a
convenient mechanism to apply patches just not to leave any respectable
reason to distribute modified tex.web).

Now, I want to debug a gnu package gone crazy. I decide to use that tool
and move the GNU package to all-packages.nix for convenience of
combining these tools. Now I fix the problem, remove the debugging
library and commit. Oops, I forgot to move the package back. Too bad.

>   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
(verbatim redistribution only reference implementation of a standard?).
It may even be legal to distribute the result, and morally acceptable to
most of us to do so. I agree that the result should be tagged as
non-free, but it should be easy to do so anyway. Oops, we again need a
single package list.

>   4. Allows licensing meta-data to be maintained accurately for free
>      software packages that have been audited.
>> 4) guidelines for analyzing the license

Seems to go better together.. What you propose doesn't include mandatory
developing such guidelines.



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.

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

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

Now it is your turn to give some arguments on (1) vs (3) (let us stop
discussing priorities until we agree about facts), and maybe proposing
more alternative solutions to compare.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJKt1KbAAoJEE6tnN0aWvw3vyEH+wc3A/zxbKpWNrzKCWba5TlQ
9HiCYQmgKvPOalwUYVtceKcLU/lOC8v9i5PVSzvqpRUEK69pqHXe6LDdTTxlxUTU
NRpvcY5qLbcLSyBgmyIX3favGYfaRVqsm2bvyfehmHZIcy/UceeuSn5s2kbjbSZD
lU4webol59ICTYOk0Hm+cVJlFZtuAF9G1XQgiwoLw9LALZV3mVNLHyjGGGdt7gvC
50qaVEca3MqhK9qUsHl/ksWHsVxyU/nSFaD9pKdY+9VlvQ9+aTDGIC9psL1ipj2V
WyDA6+ADdGAuaiLGogr+3HyDTF/cHxNHRqFcPwPT3xieIetJtbNQerVNiP4zsoY=
=t5Zg
-----END PGP SIGNATURE-----