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

[Nicolas Pierron]

Hi,

2009/9/21 Ludovic Courtès <ludo at gnu.org>:
> Michael Raskin <7c6f434c at mail.ru> writes:
>> Ludovic Courtès wrote:
>>>> 1) not breaking existing workflows
>>>   1. Is the least intrusive for other contributors (e.g., does not
>>>      change the way they work.)
>>
>> I think that splitting a file into small pieces is intrusive, you
>> don't.
>
> I didn’t say that.  The ‘free-packages.nix’ approach was the least
> intrusive solution I could think of back then, but I’m happy if a less
> intrusive solution can be found.

IMO, a package _possess_ a license (the LICENSE file is inside the
distributed sources or near the download location).  So I don't
understand why you are wondering where to put the license information?
The best place to put the license of a package is inside the nix
expression of the package or near the nix expression of the package.

I don't see any reasons why the package license should leak in our
file hierarchy.  Knowing which packages are respecting a minimum of
freedom, is filtering packages based on their licenses.

>>>   2. Does not rely on non-trivial cooperation from other Nixpkgs
>>>      contributors, such as defining accurate ‘meta.license’ or
>>>      ‘meta.license.reviewed’ attributes, etc.
>
>> If you think that even that is too much to ask,
>
> I think so.  Otherwise Nixpkgs wouldn’t have non-existent or inaccurate
> ‘meta.license’ tags in the first place.
>
>> you need all information stored so that a developer is not interacting
>> with it at all unless meaning to update or query license data. That
>> means separate file(s).  top-level/licenses.nix could be the solution.
>
> I think it’s reasonable to expect ‘meta.license’ to be left unchanged
> once it’s been corrected/reviewed.  But the information that it’s been
> reviewed must be stored reliably somewhere.
>

I agree, no attributes are safe enough because they are easy to write.
 What you need is something that can not be created by hand unless you
really want it.  You want somebody which is responsible to check the
validity of the license.

So you need:
- The package sources (version).
- The license.
- The name of the reviewer.

All these data should be used to generate a Hash which is used to
ensure that all previous information are correct and unchanged since
the last review/audit.

Again, having a location which is not near the package (like
top-level/licenses.nix) is not a good solution.
You may want to have your packages stored inside one directory, such
as adding a package inside Nixpkgs (after building & testing) is just
moving one directory to the repository.

>>>   3. Makes it as easy as possible to share work between the free and
>>>      non-free variants of Nixpkgs.
>>
>> You may want to link a free tool with a half-free auxillary library
>
> There’s no such thing as “half-free software”, to me.

This problem can be solved with a license filter.  The current problem
of all-packages.nix is that every package use all other packages
without limitations.  With the callPackages added by Eelco recently,
you can filter packages based on their license and then use again
callPackages on the filtered set to ensure that you only have
dependencies matching your restrictions.


-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron