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: http://www.jclark.com/xml/copying.txt 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 me... -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpi82d89m50R.pgp
Description: PGP signature
