[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#487201:



On 28/08/11 02:33, Steve Langasek wrote:
> On Sun, Aug 28, 2011 at 02:00:33AM +0100, Ximin Luo wrote:
>> Thanks for the explanation; I didn't find this in the places I looked. Still,
>> the fact that "the right way" takes much more effort than the multitude of
>> "wrong" ways is not a good thing.
> 
> This is often true of both life and software.  The solution is to make it
> easier to get it right, not to change our mind about what the right thing
> is.
> 

If you have an overly-strict impression of the "right" thing to do, this is
naive and you will be forced to change both.

The proposed solution (adding MPL to some shared package for licenses) both
makes it easier to get it "right", whilst still allowing users to view the full
text of the license easily (which is a more flexible view of what "right" we
want to achieve.)

>> If you were to write a program that could report the copyright status of
>> every single file on the system, it would be weird if you showed a
>> slightly different GPL3 for different files.  Even if you parsed a license
>> text to a canonical form, I doubt this would be a visually pleasing form,
>> or even one that has a coherent logical structure.  e.g.  Steve suggested
>> collapsing whitespace - but this loses (e.g.) paragraph information.
> 
> How you decide to format the license text for display is an *entirely*
> separate question from checking whether the license text is correct.  I
> never suggested using the case- and whitespace-smashed form for display (or
> even storing it as a file).
> 

In any case, the current situation makes this (formatting) hard to do. It's not
a good solution programatically, to have a "canonical" form that isn't easily
formattable.

>> Realistically, I don't think anyone is going to choose the MPL simply
>> because they see it in /usr/share/common-licenses.  Also, it seems the
>> anti-MPL stance is just from a few people, rather than the Debian project
>> as a whole, e.g.  [1] says it's fine.  It would be equally wrong to omit
>> the MPL for the same reason.
> 
>> [1] http://wiki.debian.org/DFSGLicenses#Mozilla_Public_License_.28MPL.29
> 
> This documents that Debian has decided that the MPL meets the DFSG and that
> it's acceptable for inclusion in main.  That does *not* mean that it is a
> license that Debian (or Debian developers individually) recommends the use
> of or would like to see adopted more widely.
> 
> In fact, one of the two mails cited by that wiki page as supporting
> evidence[1] includes this comment from Anthony Towns:
> 
>   That a license is DFSG-free doesn't mean it's "good" any more than a
>   license not being DFSG-free means it's "bad" -- there are lots of reasons
>   to not use DFSG-free licenses or software under the licenses, and there
>   are lots of reasons to use and work on software that's under DFSG-non-free
>   licenses.  The DFSG is *Debian's* free software guidelines, that're meant
>   to be useful for *Debian* to make decisions.
> 
>   Personally, if I've got a choice, I don't use licenses that are GPL
>   incompatible, eg, which the MPL certainly is.
> 

This is irrelevant, and actually that quote does not support your argument at
all. "That a license is DFSG-free doesn't mean it's "good"" -- in other words,
people should not treat inclusion in DFSG (and by extension common-licenses) as
endorsement from Debian.

Further, this argument is consistent with arguing against the existence of
MPL-licensed packages in Debian-main - "people will treat this as endorsement".
What matters is simply DFSG, which MPL is.

X

-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: