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

[Michael Raskin]

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

Ludovic Courtès wrote:
> Of course, that’s the first solution I had in mind, but then I thought
> it wouldn’t work for the following reasons:
> 
>   * Some of us currently don’t care about ‘meta.license’, or don’t want
>     to take the time to define it.

When I don't care about it, I will not care about free-packages.nix

>   * Sometimes ‘meta.license’ is inaccurate or non-informative (e.g.,
>     “license = "free"”).

Wes, and this is the problem to solve. We have no idea on what to write
there. Of course, this discourages us from ever specifying this
attribute because the effort spent will be hard to use anyway.

>   * I don’t think Nixpkgs as a project would adopt a policy saying that
>     packages aren’t committed unless they have undergone licensing
>     review leading to an accurate ‘meta.license’ attribute (which is a
>     consequence of the points above.)

> Based on this, the only solutions I could think of are:
> 
>   1. Use a separate file for free software, which is known to be
>      4-freedom-free because it’s been audited.
> 
>   2. Use a separate branch.

3. Combined approach.

a) Remove all the inaccurate meta.license tags. You can remove all of
them as well because they are not exactly usable now anyway.
b) Establish a new format for meta.license which can be parsed and that
can be extended to include more information about the license.
c) Write guidelines for filling all the fields introduced in b).
d) Adopt license specification guidelines. The main point should be:
don't commit the information if you are not sure. If any information is
committed, the it should comply with guidelines developed in b) and c).
e) Write scripts to quickly find out the packages with unspecified
license information.
f) Slowly fill in the information for the undescribed packages in the
descending order of importance and encourage maintainers to do it for
their packages. Never break the d) guidelines, i.e. being sure trumps
being specific.

Benefits relative to 2: you only have maintain what you set out to
maintain, i.e. licensing information about packages.

Comparison with 1:

Supposed "+": less intrusive changes. It creates zero inconvenience for
those who ignore it (they need just not to touch license attribute). In
your scenario searching for a niche package without knowing whether it
has been audited becomes more complicated. This creates opposition and
search for a better solution.

Supposed "-": people will ignore it as before. So what? How is a package
without license attribute different from a fresh package in
all-packages.nix? Even more, in your scenario you need to separate
non-free and non-audited packages somehow.

Different tradeoff: in your scenario you only need to check the license
for 4 freedoms, my proposal makes you fill in more fields (or at least
encourages you to do so). I claim this is still better
return-on-investment. I generally see three types of licenses:
  a) stock licenses. I just see lib.licenses.gpl2plus attribute appearing.
  b) short permissive custom licenses. Usually they are all very similar
to revised BSD. So we can copy-paste (or even do a function call) a
default description, and change license name/license URL.
  c) non-trivial license. Unfortunately, you have to read it very
carefully anyway. It may not be necessary for making sure you can use it
and not care, but for verifying that 4-th freedom is not violated by
some minor clause, you need to read the license slowly and think of
implications of every letter. Or look up Debian-Legal on this license.
After all this work, not writing down all the basic facts you have found
seems more like a waste of work than economy of time.

Addition to the previous point: you will have easier time later. "Four
freedoms" is not the same as FSF Fully Free Distribution Guidelines. The
latter forbids promoting non-free software.

Let me summarize my answer specifically to your points that
"meta.license" doesn't work:
1. Those who don't care will not care about all-packages.nix vs
free-packages.nix, but they are not worsening situation.
2. The tags can only be accurate and consistent when a way to make them
accurate and consistent is agreed upon. Separating free-packages.nix
requires agreeing on exact interpretation of four freedoms anyway - why
not go one step further?
3. While Nixpkgs is not likely to adopt a policy requiring work not
required not to break things (be it in technical, maintenance or legal
sense), adopting a policy to be careful not to destroy each other's work
is plausible.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJKtTjyAAoJEE6tnN0aWvw3vAUIAKE9jbvATnK6zZuDya4i0Doz
R/HXmTGZiyIVwwRHCP40dalgnRGxkZdeCCCfNZzcHrM53m6AfeRb1idjVtTP3CxJ
BkK1ut7i0JUJA/HNnVuUiTBY0MlbygO8vYl4hx4hccTdlbjGDs72BHypuuEKkizH
sRC6yE/Z1nAi4h/jFL+OilVOJeF8OwZYtQb5u1cFt+dyutN37jJlhWeU+MTa5sDS
KmvQedgLyUg3YuIRq4LQ0ZIWccSks4Uot8jxhCYsosywCBGwZZzsj4Z/2rhjXs8v
qHm2TXIczx9lIvaHWc1AEyqPANZWIyzQ75uuiAcqJV0WnrJ5lnIJXdPHHK0rN7k=
=NsIH
-----END PGP SIGNATURE-----