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

[Ludovic Courtès]

Michael Raskin <7c6f434c at mail.ru> writes:

> 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

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.

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

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

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.

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

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.

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

Right.

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

> 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?

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

Thanks,
Ludo’.