[Nix-dev] Package coding standards (was Re: Separating Free/non-free package)

[Tony White]

2009/9/22 Eelco Dolstra <e.dolstra at tudelft.nl>:
> Hi all,
>
> Ludovic Courtès wrote:
>
>> Eelco Dolstra <e.dolstra at tudelft.nl>
>> writes:
>>
>>> - A while ago I did some work on a "virtual RMS" for Nix, though I didn't get
>>> very far.  The idea is that you can say
>>>
>>>   $ nix-vrms /etc/nixos/nixos -A system
>>
>> That sounds cool.  Where can we get it?
>
> It's vapourware.  Like I said, I didn't get very far :-)
>
> I'll try to finish a simple prototype.
>
>>> - I'm not so worried that the meta.license field will be incorrect (just
>>> missing, but that's a matter of policy - we can require it for all new
>>> packages).
>>
>> Unfortunately, that there’s been no such policy for years makes
>> ‘meta.license’ essentially unusable.  It’s also been argued that the
>> recommendations in ‘meta.xml’ are way too vague.  And it appears that,
>> e.g., Nicolas, would consider “free” in the sense of “gratis”, which
>> adds to the confusion.
>
> Then the description needs to be improved.  (If it's gratis but not free, it
> should be "unfree-redistributable".)
>
>> So I’m glad if a policy is instated and actually followed.  However I’m
>> afraid it’d happen too late and would be foreign to most contributors.
>> Nixpkgs contributors have been used to “free-style” cooperation, a
>> custom that’s going to be hard to change IMO (think ‘builderDefs’
>> vs. ‘stdenv’, ‘pythonNew’ vs. ‘python’, ‘args: with args;’, etc., etc.).
>
> It's good to provide opportunity for experimentation, but I think that now we
> need some package coding standards.  In particular:
>
> - Packages should have a consistent external calling interface.  I.e., "import
> ./pkg.nix { ... deps ... }", not (for example) "builderDefsPackage
> (selectVersion ./dir "1.8") { ... deps ... }", as this exposes implementation
> details.
>
> - There are a number of alternative styles of writing packages than the old
> stdenv.mkDerivation, such as builderDefs and composableDerivation.  We should
> think about what works and merge it into stdenv.mkDerivation.
>
> - Customization should be done consistently.  For instance getConfig is used
> kind of arbitrarily in all-packages.nix.  Also, some packages have ad-hoc
> mechanisms for external customisation (e.g. the nixUnstable function now has
> "nameSuffix" and "patches" arguments), but there are more general ways to do that.
>
> - Some guidelines with respect to versioning (e.g. when to keep expressions for
> old versions around, and how to name them).
>
> Comments welcome.
>
>>> The solution is to finish the virtual RMS tool and add missing
>>> meta.license fields :-)
>>
>> Is VRMS able to analyze SWIG’s license [0]?  Real life is full of
>> examples like this one.
>
> VRMS wouldn't analyse any software, it's up to the packager to correctly
> classify the package.  For complicated licenses, that's what the "free" and
> other catch-all license values are for.
>
> --
> Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/
> _______________________________________________
> nix-dev mailing list
> nix-dev at cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev
>

Hi guys,
I can see you are all quite interested in the categorisation of libre
and non-free software by license and applying it to nix.
It's obvious that it's not something that can be easily implemented
but how far you guys go with it depends on your overall objectives.
What exactly are they? A fsf approved distribution?

I can see problems like this, which I'm sure you're aware of :
A software project licensed by the gnu gpl does not always mean that
it is truely libre software. The example I propose for my statement is
that the gpl v2 licensed Linux kernel source code contains firmware
blobs that are considered "non-free" By the fsf. For that very reason
the debian packagers have separated the firmware blobs that are
shipped with the Linux kernel separately as a package called
linux-firmware and it is not installed by default on debian.
So essentially, this whole "Freedom software" Thing is quite difficult
to audit because gpl doesn't always mean the four fsf freedoms, while
really, it should.

The only software that can be easily distinguished as four freedoms
software is software that belongs to the gnu project.
The fsf state that licenses like the BSD license do not follow the
four freedoms because they are not copy left. So what is that? A
license the gnu project don't recommend because they don't believe in
it and see it as a threat? So that would make it non free right?
Who knows? And that's one of my points; would you categorise anything
non gnu as non free just to satisfy the fsf's four freedoms rhetoric
or audit each project's license individually and apply your own
definition?

I will guess that the purpose of categorising software by license is
so that people concerned about licensing; may either opt to select
libre (I'm still not happy with the fsf's definition,) Which if the
NixOs distribution was to be categorised as a proper fsf "Libre"
Distribution would be default. Or for those of us that are not
convinced entirely by fsf rhetoric and currently use things like
nvidia xorg drivers may go for the non-free stuff, if we wanted to;
instead.

So for the user to make the choice, if non-free/free was a true or
false switch in for example; in configuration.nix, would that not
cause a nuisance because :

A : Who says what's libre? Is it gnu project software only? Must be
compatible with the gpl 2 or 3 licences and have the freedoms or what
exactly?
B : The huge amount of extra work involved in auditing, editing and
the future maintenance of every single expression in the nixpkgs
archive along with setting policy regarding it?
C : Dependencies. Package broken without non-free?

If anything like a clear line between free and non-free software is to
be drawn, would it be an idea to add a switch to nix-env that queries
an expression for what is considered either free or non-free?
So you could ask nix-env :
How many packages are there in the current copy of nixpkgs expressions
that are non-free or free (Libre) And optionally list either one.
How many packages are installed that are non-free or free (Libre) And
optionally list either one.
How many packages have no license information and list them (Useful
for auditing and appending the correct license.)

That way the nixpkg expressions could be slowly queried, migrated and
easily audited. Maybe even eventually, if a target is set to make sure
that all nixpkgs expressions must have their correct license(s)
Specified; then a free  = true or false switch could be implemented
into say, configuration.nix once that was done.
>From then on coding standards should be that all new expressions added
to the nixpkgs must contain the correct license string.
I think the nix definition of what libre software really is should be
decided first of all. If it already has and it is the fsf's four
freedoms gnu licenses, fair enough but it wouldn't be my choice. It's
far too extreme.

I think as far as distributing NixOs in iso form goes, there is
definitely stuff that you wouldn't want to include by accident as part
of an operating system and the distinction between free and non-free
would help prevent that. However, I can't see anything I would benefit
from personally if NixOs aspired to be a strict four freedoms, etc
distribution because while I agree with some of the fsf rhetoric, I'm
actually more of an open source software supporter. However if you
guys are going to take it to task, I wish you all the luck in the
world, it's certainly not an easy thing to want to implement. :)

Thanks,
Tony