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

[Michael Raskin]

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

Ludovic Courtès wrote:
> To achieve a separation of Free (per
> http://www.gnu.org/philosophy/free-sw.html) and non-free packages in
> Nixpkgs, I’m considering splitting ‘all-packages.nix’ in 3 files such
> that:
> 
>   gnu-packages.nix ⊆ free-packages.nix ⊆ all-packages.nix

I don't get the first step. First part is per-vendor, not per-freedom.
The mere fact that the package is a GNU one, doesn't mean it is more or
less free than any other package with an OSI-approved license.

> The ‘gnu-packages.nix’ file can be easily obtained by grepping for
> “mirror://gnu” and similar.  The second one would include
> ‘gnu-packages.nix’ and definitions for other free software packages; it
> will need auditing work on our side, which is probably going to be a lot
> of work, which can be done incrementally.  Finally, ‘all-packages.nix’
> will include ‘free-packages.nix’ and provide definitions for proprietary
> software and software that hasn’t yet been audited.

Here we have another problem. What is the criterion for free-packages?
Four-freedoms? DFSG? OSI? These three rulesets give slightly different
outcomes. If you want to comply with GNU guidelines for "Fully Free
Distributions", say so explicitly.

> Ideally, each of these files should be usable as a drop-in replacement
> of the current ‘all-packages.nix’.

It will never be so, unless you package HURD and upstart over it.
Because GNU-packages will lack "kernel" package otherwise.

Depending on your point of view, free-packages.nix may need Linux-Libre
kernel package, although if you go four-freedoms way it is not needed.

> If nobody objects, I’d like to start with the first step (moving GNU
> package definitions in ‘gnu-packages.nix’) possibly by the end of the
> week-end.

I feel like what you want to do is slightly misguided. If you want to
separate packages on the basis of their being more or less free, you
should first describe goals and rules.

Maybe the better first step would be introducing some consistent rules
of describing license features in meta and starting a packager's guide
to determining presence of these features.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJKtOhDAAoJEE6tnN0aWvw3As4IAIyDG0fT0jgj4Ee0G8nvPttv
5AiUbZ8VsgTvl4NYex0DOcbRQKU4sUp4Pc6rSAWcP00FwORzACz9r74bCxUx6/c8
9vFeKxnq0Yj/vGGDEDQ6iA47M7XWQVwSBKiPY0n/HsXEEZLwXKW/fpwI8Mgj5TnG
PKPpyAeBNnleFBkxiCyOCq+9DyByRCZHHLzOBpQW7c4gP/GS6fm2wJpGzJIQBw0k
4HqepiMCQ7UXjpJtfPUtkkw5G+6MdhLzcqCw5u4eLsgmdUWG5YHkz+CM7IXJftpD
MbZ28YBH3mzDEexK8U4TuSQBOur8MOFlMtHp53wW38fVIOXkE3yxUkfbgV05iz4=
=U2t9
-----END PGP SIGNATURE-----