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

Bug#238245: license choice - consensus on dual MIT/GPL-2+ ?

On Sat, 21 Jan 2012 11:08:55 -0400 David Prévot wrote:

> Le 20/01/2012 13:53, Francesco Poli a écrit :
> > On Wed, 18 Jan 2012 23:51:55 +0100 Stefano Zacchiroli wrote:
> >> On Wed, Jan 18, 2012 at 07:42:05PM +0100, Francesco Poli wrote:
> >>> If this is what you mean, then it should be noted that "dual-licensed
> >>> under Expat/MIT and GPLv2+" is effectively equivalent to "licensed
> >>> under the Expat/MIT",
> >> You're quite right (at least, under most interpretations of the two
> >> licenses; cause with these things you really never know...).  As in
> >> other cases of dual MIT/GPL licensing, the point is being clear in the
> >> fact that recipient can choose both
> > I think it would make a number of people (wrongly) think that the
> > Debian Project decision-makers know very little about licenses...
> I take it as a remark, not as an objection,

Well, I intended it to be a minor objection (thus a "non-blocking"
objection), but anyway...

> and thus propose the
> attached patch if we agree on the dual licensing (@@date@@ will of
> course be replaced once agreed on the license choice and its wording).
> You can have a look at the built page on my test server:
> 	http://tilapin.org/debian/license.en

I would use the classical Expat URL for the Expat/MIT license:
rather than the one hosted by OSI.
Moreover, as far as the Expat license is concerned, I would not talk
about any "latest version", since the Expat license is not given any
distinguishing version number: I would therefore just say
"(which is usually available at http://www.jclark.com/xml/copying.txt)"

The rest seems to be OK (apart from the very idea of the Expat/GPL
dual-licensing, which I have already commented previously).

> If my understanding of dual licensing is not too defective, we will be
> able to drop one of them later if we feel strongly about it. Therefore I
> assume that Francesco's point can be raised later if it really matters,
> and thus is not a blocker here and now.

This seems to be true, even though such a strategy looks sub-optimal to

 New GnuPG key, see the transition document!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

Attachment: pgpkpiKQvVF3p.pgp
Description: PGP signature

Reply to: