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

[Michael Raskin]

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

Ludovic � wrote:
>> When I don't care about it, I will not care about free-packages.nix
> Which is fine.  The idea is that people who don’t care about software
> freedom don’t have to worry about ‘free-packages.nix’.  Even more:
> people who don’t care about software freedom should not modify that
> file, so that it remains accurate and useful for those who care.

I have to correct you: they may still need to modify this file to
correct a list of package imports. That is important point: they do
modify it, just so as to not destroy license information.

>> a) Remove all the inaccurate meta.license tags.
> That’s a lot of work and it won’t prevent people from committing more
> inaccurate tags IMO.

Not more than auditing all the packages 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).

> I could be wrong but I doubt this would work better than the current
> situation, since the current guidelines in ‘doc/meta.xml’ aren’t always
> followed (and they’re arguably more vague than is necessary).

These guidelines (I consider only license part):
1) were never discussed on the ML to the point of consensus;
2) are too vague;
3) prescribe data format inconvenient for automated processing;
4) do not prescribe data format that can be sanity-checked

No wonder nobody follows them.

If we describe an attrSet structure, putting a string license attribute
will be found by a trivial check (done by Hydra?), and consistently
filling it with outright wrong data but according to format requires
reading the guidelines, deliberation and significant negligence. Sorry,
free-packages.nix is no better protected.

> The bottom line is that in Nixpkgs contributors can commit essentially
> whatever they want.  Conversely, Debian Developers are bound with the
> Debian Social Contract, so they basically commit to providing accurate
> license information, among other things.

We still have some (mostly unwritten) rules of conduct. They mostly
focus on not causing trouble to each other. I guess that some
awareness-raising is needed so that everybody knows about new license
guidelines. This thread is probably going to help with it..

>> 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.
> 
> Right.  For this reason, I think the ‘license’ tag is only useful for
> “stock” licenses.  For free software that uses a custom license, we need
> some other mechanism allowing us to specify that the license has been
> checked to be 4-freedom free; in such cases, the ‘license’ field can be
> used to provide a pointer to the license text.

Sorry, you missed my point. The world is not black-and-white here. While
checking for four freedoms (note that you will actually check only
number 0 and number 3) you may discover other particular interesting
bits. Like whether original work has to be attached to modified copies
(original pine), does every about box / advertisement need a mention of
inclusion of the code from the project (original BSD License), do you
need to provide link to the project homepage if you include it and so on.

For every license we can answer some questions:
- - is commercial use allowed?
- - is redistribution allowed?
- - is redistribution of modified copies allowed?
..

- - what is the name of the license?
- - what is the URL to download the license?



>> 2. The tags can only be accurate and consistent when a way to make them
>> accurate and consistent is agreed upon.
> 
> I argue that it takes more than this.  Inaccurate or imprecise tags
> (e.g., “free”, “GPL”) can’t be attributed solely to the shortcomings of
> the ‘license’ tag as a license description mechanism.

"free" is prescribed my meta.xml... The problem is that deep.

Discouraging from committing incorrect information gives non-zero result.

>> Separating free-packages.nix requires agreeing on exact interpretation
>> of four freedoms anyway - why not go one step further?
> I’m confident that conflicts will rarely happen.  Do you have experience
> suggesting otherwise?

Original Pine package.

>> 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.
> I agree.  Actually, I think a ‘meta.license’ tag is more likely to be
> modified (intentionally or not) than a separate file with a clear
> purpose such as the proposed ‘free-packages.nix’.

OK, if this concerns you so much, maybe licensing-auditing.nix in
top-level would do? It would just import packages from all-packages.nix
and add licensing information. That way you can check the properties you
want to check. You do not need to move the packages themselves. At first
you will only fill in fourFreedoms attribute, but as the time goes you
can add other attributes and describe them in the header comment.

What I care about is:
1) not breaking existing workflows
2) possibility to present more detailed licensing information
3) possibility to process data automatically
4) guidelines for analyzing the license
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJKtV+eAAoJEE6tnN0aWvw3lMMIAKN5L+yYCUs8cc6iPSe51qj1
xmtMab2Bcpyeo+HLZQBhr2IZe1Uankta5UIRlHPL6Tv0gNF5aCkPXa7la5uVJWem
Fv64IQQ10TO/ELnEc9Imv9v4f+gSv24GdY5Reaj+y3xUnzhyvhAe6PlRl6FPwKDc
EQjOa53H8fXsdwKJped3QZ59wcKozj2MgKYeDcmG7z2se9pEO3bFeoD72uvLezAV
DUiJhhK++R1XzbOCWANhTWFIRBBq/HNzRuJYo7NgjoGQGm6oen6PFy19KRB/IDaj
aKTnoVHR982WOaQh0AZXoftQogwLK9E10eRtNERQrsYoAqgOzJoRPd8/v+gw6+Y=
=+2Sg
-----END PGP SIGNATURE-----