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

[Nicolas Pierron]

2009/9/21 Ludovic Courtès <ludo at gnu.org>:
> Nicolas Pierron
>> free should be deduced from the license, not provided by hand.
>
> As I said earlier, that is *not* possible unless a “license calculus” is
> devised.  That would be a different project and I’m not going to take
> that route.

Why not?

I am not saying that we should have a tool which understand the
license and generate the free/non-free flag.  I am just saying that
you need to translate Licenses in terms of computable values.  You
have already to categorized common license as free ("LGPLv2+" -> {
free = true; }).

The idea here is to do the same things as types.  In one file you have
a list of common types declared with mkType, but you don't have any
restriction to declare your own type if none of the previous are
matching yours.

So deducing the free flag from the license is not understanding all
languages in the world, this is just mapping License (hash) to an
attribute set.  A different hash for the license file means that some
modification exists between the licenses and this may help you to find
them.

>>>    in
>>>      if (fullName == pkg.name
>>>          && pkg ? meta
>>>          && pkg.meta ? license
>>>          && license == pkg.meta.license)
>>
>> I don't understand, you are duplicating license information if the
>> license is correct?  Then I don't understand the purpose of this file,
>> you just need "yes it's correct" line.
>
> Correct, that’s what this file is for.  (See earlier messages for a
> rationale.)

I still think this is pointless.  Adding more (unrelated) effort does
not give you any guaranties about the review process. This just means
that the person was motivated enough to do it.

>>>  reviewedPackageList = [
>>>    (reviewed "guile" "1.8.7" "LGPLv2+" true)
>>>    (reviewed "libunistring" "0.9.1.1" "LGPLv3+" true)
>>>    (reviewed "flashplayer" "10.0.32.18" "non-free" false)
>>>  ];
>>
>> Yet Another List of Unmaintainable Things ...
>
> That *is* a fair amount of work to maintain, but I have yet to see a
> better proposal.

Specifying them inside each package (directory?), keeps things
consistent and self-contained.

>>>  { inherit reviewedPackages freePackages; }
>>
>> What If I want only non-free packages?
>
> It’s easily derived.

And you are going to hard code every cases?

>> I don't see how such file is more secure than any other file.
>> Everybody can modify this file.
>
> The assumption is that it likely won’t be modified inadvertently (as
> opposed to ‘meta.license’), and that any malicious committer could be
> found very quickly.  ;-)

indeed, but if you provide a hash in a file contained in the same
directory, this provide much more security against modifications and
the system can warn you if it is not updated.

A simple example:
- You have a package with the License A
- You register your package as having the license A
- Some add a patch with License B to the package
- The hash difference warn you that a modification need to be reviewed.

>> You need a Hash somewhere which say that the package with its license
>> are correct as emphasized by the <person name> reviewer.
>
> A hash of what?

For quality and security.

> The reviewer name can be obtained by “svn blame x.nix | grep PACKAGE”.

- svn blame is not a good solution because this can be changed by
playing with the layout or with the list order.
- The review/audit author may not have commit access. (person from the
mailing list)

>> So, what is the point of duplicating things?
>
> Having accurate license information.

Having multiple times information does not means that it is accurate.
(Many people can have the same bad answer, that does not mean it is
true.)
This explains why we need the name of the reviewer(s), because the
quality of the review depends on the capacity of the reviewer.

>> "Free" is not an intrinsic property of the license.  This may depends
>> on who use it (are you a commercial, an non-profit association).
>
> It’s “free” as in “free speech”, not as in “free beer”.  See
> http://www.gnu.org/philosophy/free-sw.html for details.

Ok, so you have to define what free means for all users, and what If I
want "free beer", do you have another flag for it?  So you have
highlighted the issue which is that "free" is not an easy term and you
need to add more detail to it.

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