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

[Michael Raskin]

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

Ludovic Courtès wrote:
>> Yes, but your mechanism should better be useful for someone else.
> Like who?  For what?
> 
> I’m under the impression that you’re not interested in software freedom.
> Am I right?

I am interested in software freedom. I will choose temporarily
underdeveloped free solution over temporarily more feature-complete
proprietary one. But it is not the only thing I am interested in.

I do think that using free-to-use software for compatibility tests is
acceptable if this compatibility is important. I do think that tracking
such software in NixPkgs and being able to check for erroneous
redistribution is a good thing.

I also don't want to make defense of software freedom look like a job
only for Well Intentioned Extremists - especially when there is a way to
do the same useful work in a way that annoys less contributors to free
software projects.

>>> There’s no such thing as “half-free software”, to me.
>> There are lots of border cases.
> No.  90% of the time, it’s easy to tell whether a package provides the 4
> freedoms.  Luckily, many people have already studied at length the
> remaining 10%, so we can build on their work.

Except that they _always_ have some slightly different target, and so we
need to do extra work to read all the conclusions. Also there are some
border cases (some include even TeX) where free-or-not decision is not
universally agreed upon. In such cases it is better to log all discoveries.

>> There are license features. Can you redistribute the package, can you
>> distribute binaries of modified build etc.
> Free software licenses have, by definition, at least the 4 “features”
> described in the definition.  I’m not interested in software that has
> less than 4, and it doesn’t matter to me if it has “extra features”.

Some people have other opinions. The idea is to make it easy to mutually
reuse the efforts.

> Overall I think a license calculus is a huge amount of work, and the
> work of lawyers more than that of hackers.

Well, there are some lawyers in major distribution teams, and if we can
extract some knowledge from their advice, it is good idea not to impede
preservation of that data.

> My original intention in this thread was much less ambitious, and also
> much more practical, as it’s already been done several times.
> 
>> 2) for every verified package, put the following in the licenses.txt:
>>   packageName = {
>>     fourFreedoms = true; /* or false */
>>   }
> 
> Sounds good to me!  I’d rather call the attribute ‘libre’ or ‘free’,
> with a pointer to the definition of the term, but other than that that’s
> fine with me.

"libre" is OK. "free" is asking for a trouble when someone else starts
extending the markup.

>> What I don't like in your approach (1):
>> 1. The change is intrusive.
>> 2. You put off describing the border as precisely as possible.
> You mean the border between “free” and “non-free”?  As I said, I want to
> stick to the 4 freedoms, and building on others’ work in “suspicious
> cases”.  If a conflict arises that’s not clearly covered by the various
> sources I cited earlier, I’m happy to discuss it.  But I expect it to be
> very rare.

Work of others doesn't remove opportunities for opinion conflict in
worst 5% "nearly free" cases. Or may be 1%. 1% of Nixpkgs means 15
packages. Seems enough for an infinite flamewar in my opinion.

>> 3. All the intrusive change doesn't allow others to build upon for their
>> needs.
> 
> I don’t understand this sentence.

free-packages.nix separation is not friendly to someone volunteering to
do some other license-related research. Attribute sets (wherever they
are stored) are friendlier.

>> 4. You already admit that you are going to slightly change the semantics
>> of what you do anyway while designing a hard-to-extend system.
> Which semantics?  What’s “what you do”?

You currently mention software freedom as defined by four freedoms. You
do not exclude that you will want to separate software acceptable by FSF
Fully Free Distribution Guidelines. The problem is that these guidelines
are stricter than four freedoms.

> Anyway, I *think* we’re getting very close to a consensus with what you
> suggested above, so thank you for taking the time to debate!  :-)

As we see, option (4) is quite attractive not just to me.. So reaching
global consensus will take more time.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJKt9QpAAoJEE6tnN0aWvw3O00IAIv73WDzLkXR6iAo2HPqImgV
r7IgZgyq/FSyOv4vPFv8xzk6ABrYK5c9YR5L3Q++/OA3OBWwGe7FlEhA9BNSZ9OO
6OB5iezUKzs0/VJyudSVLjawGVlVmJek8TflThmNZpOhVnE7xle2oX7vY1zp5PkE
586PfEBqCvzqThRgJa4/mSkWw2Dbhoc9ZkWipT16iam/W8BoqFruaQUbOb6AUMDv
Jjw3aPpumCo6l4MIb6InxOg/1dqcXnWTAVyB5vzhEaXxZQPQVw4Bm+jCpOoTYW48
FMZAsjjZ2W3hJ60RqDSaJjUXuuiAzRoL3o+1aAcGgs/NZKVbyj/NvVP99clVQSk=
=enOs
-----END PGP SIGNATURE-----