On 24/12/12 10:31, Charles Plessy wrote: > Le Tue, Dec 18, 2012 at 11:53:21PM +0000, Ximin Luo a écrit : >> https://github.com/infinity0/debian-policy/compare/bug649350-infinity0 >> >> I've split up my previous patch into more manageable chunks, and added >> extra explanations in the commit messages. >> >> I'm trying to follow the principle that the commit messages should >> already contain enough justification for the changes, but if any of them >> are unclear, please do ask me for further detail. >> >> (Further potential additions, which I've omitted for simplicity, include >> License-Exception: fields, and Location: fields to formalise the concept >> of a "pointer" to a License.) > > Dear Ximin, > > It was nice to split the patch and document the chunks, but I am still > not convinced that the changes you propose are useful. > > In particular, I do not see the benefit from using a syntax for the license > short names, especially that SPDX and other projects do not have one (for > instance GPL-2 and GPL-2+ are seen as separate short names). Also, creating a > syntax is a complex project that I think is beyond the scope of our > machine-readable format. There are corner cases, for instance BSD-3-Clause is > not the upgrade from BSD-2-Clause, or MPL-1.1 can be upgraded to MPL-2.0 > despite its short name is not MPL-1.1+, etc. If you would like to work on a > robust syntax, I propose you do it as an independant specification that can > later be proposed for adoption not ony to use, but also to SPDX, OSI, > ADMS.F/OSS, etc. >
- "GPL-2 and GPL-2+ are seen as separate short names [by SPDX]" - this does not mean my suggestion is a bad idea, nor that my syntax is inconsistent. - "BSD-3-Clause is not the upgrade from BSD-2-Clause" - there is no contradiction with what I suggest here. - "MPL-1.1 can be upgraded to MPL-2.0 despite its short name is not MPL-1.1+" - this is incorrect and due to people *misusing the term MPL-1.1", which my changes *will help communicate and correct*. If you look at MPL-1.1[1] you will notice it makes *no mention* of "or later version". The vast majority of MPL-1.1 uses should actually be "MPL-1.1+", consistent with my proposed changes. [1] http://www.mozilla.org/MPL/1.1/index.txt > Another change that you propose and that I disagree with is to "forbid author- > and software-specific information" in stand-alone paragaphs. A lot of > derivatives from the BSD licenses contain such information. Despite we link > to > a SPDX page where the BSD license terms are generic, I do not think that the > intent in Debian's machine-readable format to is consider them all the same. > At least in my copyright files I only use "BSD-3-Clause" if the copyright > owners are the regents of the university of California. > This is because people misunderstand what a License is; my changes will help communicate and correct this mistake. Different BSD-3-Clause licenses have the *same terms*; that is what makes them BSD-3-Clause. However, as commonly written, people add author- and software-specific information to their statement of the license. We cannot do this in debian/copyright because that would be logically inconsistent, since: If a package contains files under different BSD-3-Clause licenses, each with different owners, but the terms are the same, (according to my changes) the owners would be stripped out and put in the relevant Files: paragraphs, and the common terms would be put in *one* stand-alone License: paragraph. Currently, it is impossible to merge these; you would have to give the licenses each different names. Example: | Files: X | Copyright: A | License: BSD-3-Clause | Copyright 2012 A | terms etc | | Files: Y | Copyright: B | License: BSD-3-Clause | Copyright 2012 B | terms etc This is obviously absurd. My changes would instead force this: | Files: X | Copyright: A | License: BSD-3-Clause | | Files: Y | Copyright: B | License: BSD-3-Clause | | License: BSD-3-Clause | terms etc > Cheers, > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
