Bug#645696: lintian: missing-license-text-in-dep5-copyright is too strict when considering X+ licenses
Hi Ximin, Jakub Wilk wrote: * Ximin Luo infini...@gmx.com, 2011-10-17, 22:35: Currently the tag missing-license-text-in-dep5-copyright is emitted when the copyright file looks like this: Files: * Copyright: - etc License: MPL-1.1 or GPL-2+ or LGPL-2.1+ License: MPL-1.1 etc License: GPL-2 etc License: LGPL-2.1 etc [...] I can't see anything in the DEP-5 specification that'd support your interpretation. However, if you still feel that this was the intended meaning, please file a bug against debian-policy asking for clarification. Given the current copyright-format spec, this lintian behavior is correct. Would you mind if I merge this with bug#649530 or close it? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645696: lintian: missing-license-text-in-dep5-copyright is too strict when considering X+ licenses
merge 649530 645696 thanks On 01/01/13 20:33, Jonathan Nieder wrote: Hi Ximin, Jakub Wilk wrote: * Ximin Luo infini...@gmx.com, 2011-10-17, 22:35: Currently the tag missing-license-text-in-dep5-copyright is emitted when the copyright file looks like this: Files: * Copyright: - etc License: MPL-1.1 or GPL-2+ or LGPL-2.1+ License: MPL-1.1 etc License: GPL-2 etc License: LGPL-2.1 etc [...] I can't see anything in the DEP-5 specification that'd support your interpretation. However, if you still feel that this was the intended meaning, please file a bug against debian-policy asking for clarification. Given the current copyright-format spec, this lintian behavior is correct. Would you mind if I merge this with bug#649530 or close it? Hi, agreed, I'll merge. Thanks, Jonathan -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature
Bug#645696: lintian: missing-license-text-in-dep5-copyright is too strict when considering X+ licenses
On 15/11/11 21:34, Russ Allbery wrote: Ximin Luo infini...@gmx.com writes: The text explaining the or part appears nowhere as well, when DEP5 forces me to split the tri-license paragraph. The two situations are equivalent, yet you're choosing different solutions for each! That's a good point, and I think that's a bug in DEP5. Alternatively, treat License stanzas as published licenses, and place preamble information in License/Comment entries in File stanzas. This is a much cleaner solution and what I had been interpreting DEP5 to mean. That's certainly a reasonable way of expressing that information. It's not what DEP5 currently says, though, and I'm fairly sure that's intentional (from following the original discussion). But it does seem like a reasonable change. OK, cool :) I will write up a more detailed description of this and submit it to debian-policy tonight. -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature
Bug#645696: lintian: missing-license-text-in-dep5-copyright is too strict when considering X+ licenses
* Ximin Luo infini...@gmx.com, 2011-10-17, 22:35: Currently the tag missing-license-text-in-dep5-copyright is emitted when the copyright file looks like this: Files: * Copyright: - etc License: MPL-1.1 or GPL-2+ or LGPL-2.1+ License: MPL-1.1 etc License: GPL-2 etc License: LGPL-2.1 etc This is unnecessarily strict, because it means we need to have separate paragraphs for both GPL-2 and GPL-2+ licensed portions of the code. Yes, you _do_ need separate paragraphs for GPL-2 and GPL-2+, because the license text is different. I.e., it would normally be something like: | Files: foo | License: GPL-2 | | Files: bar | License: GPL-2+ | | License: GPL-2 | This program is free software; you can redistribute it | and/or modify it under the terms of the GNU General | Public License as published by the Free Software | Foundation; either version 2 of the License, or (at your | opinion) any later version. | . | [warranty diclaimers, etc.] | | License: GPL-2 | This program is free software; you can redistribute it | and/or modify it under the terms of the GNU General | Public License version 2 as published by the Free | Software Foundation. | . | [warranty diclaimers, etc.] I can't see anything in the DEP-5 specification that'd support your interpretation. However, if you still feel that this was the intended meaning, please file a bug against debian-policy asking for clarification. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645696: lintian: missing-license-text-in-dep5-copyright is too strict when considering X+ licenses
On 15/11/11 16:57, Jakub Wilk wrote: * Ximin Luo infini...@gmx.com, 2011-10-17, 22:35: Currently the tag missing-license-text-in-dep5-copyright is emitted when the copyright file looks like this: Files: * Copyright: - etc License: MPL-1.1 or GPL-2+ or LGPL-2.1+ License: MPL-1.1 etc License: GPL-2 etc License: LGPL-2.1 etc This is unnecessarily strict, because it means we need to have separate paragraphs for both GPL-2 and GPL-2+ licensed portions of the code. Yes, you _do_ need separate paragraphs for GPL-2 and GPL-2+, because the license text is different. I.e., it would normally be something like: | Files: foo | License: GPL-2 | | Files: bar | License: GPL-2+ | | License: GPL-2 | This program is free software; you can redistribute it | and/or modify it under the terms of the GNU General | Public License as published by the Free Software | Foundation; either version 2 of the License, or (at your | opinion) any later version. | . | [warranty diclaimers, etc.] | | License: GPL-2 | This program is free software; you can redistribute it | and/or modify it under the terms of the GNU General | Public License version 2 as published by the Free | Software Foundation. | . | [warranty diclaimers, etc.] GPL2+ is not a license, it is a license specification - a description of what licenses apply to the materials in question, just like the string GPL or BSD. FSF publishes no such license called GPL2+. I agree that DEP5 is not clear, but the only logically consistent interpretation is that License: paragraphs refer to licenses, and not license specifications. (e.g. they do not accept specifications of the form A or B). From a machine-parsing point of view, it makes no sense to treat GPL2+ as a separate license, or be treated different from other specifications like GPL or BSD. A more advanced parser might want to answer questions like compatibility between licenses; the simple way to code GPL2+ would be to treat it as ( GPL2 or GPL2.x or GPL3 ... ), not to treat GPL2+ as a separate license. I'll bring this up with debian-policy as well. I can't see anything in the DEP-5 specification that'd support your interpretation. However, if you still feel that this was the intended meaning, please file a bug against debian-policy asking for clarification. -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature
Bug#645696: lintian: missing-license-text-in-dep5-copyright is too strict when considering X+ licenses
Ximin Luo infini...@gmx.com writes: GPL2+ is not a license, it is a license specification - a description of what licenses apply to the materials in question, just like the string GPL or BSD. FSF publishes no such license called GPL2+. I think Jakub is right: it's a different license. GPL-2 allows you to publish your changes under exactly the GPL version 2. GPL-2+ allows you to publish your changes under the GPL version 2 or any later version. The two licenses grant you *different rights*, and hence are different licenses, just as if one of them said that you had to publish a copyright notice and the other one didn't. One of them allows you to relicense; the other one doesn't. Also, from the ftpmaster perspective, ftpmaster wants the actual text of the upstream license included in the copyright file, and if there are multiple different texts, there should all appear. I'll bring this up with debian-policy as well. With my Policy hat on, I'd tell you the same thing, but we can certainly discuss that there if you think my analysis is wrong. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645696: lintian: missing-license-text-in-dep5-copyright is too strict when considering X+ licenses
On 15/11/11 18:44, Russ Allbery wrote: Ximin Luo infini...@gmx.com writes: GPL2+ is not a license, it is a license specification - a description of what licenses apply to the materials in question, just like the string GPL or BSD. FSF publishes no such license called GPL2+. I think Jakub is right: it's a different license. GPL-2 allows you to publish your changes under exactly the GPL version 2. GPL-2+ allows you to publish your changes under the GPL version 2 or any later version. The two licenses grant you *different rights*, and hence are different licenses, just as if one of them said that you had to publish a copyright notice and the other one didn't. One of them allows you to relicense; the other one doesn't. The issue isn't whether they're the same license, it's whether they can be incorporated into the same License: paragraph. As I pointed out already, your argument is inconsistent - MPL or GPL or LGPL allows relicensing as well, but DEP5 requires that we group together the uses of each component MPL, GPL, LGPL, separately. Why treat GPL2+ differently? It's logically equivalent to GPL2 or GPL3 or GPL4 or GPL5 .[1] Inconsistency in a specification to be used for machine-parsing is a big no-no. Why do you think separate paragraphs for GPL2 and GPL2+ is a good idea? Just as with MPL or GPL or LGPL, the relicensing is implicit in the or and implicit in the +. Going back to the previous example, this sort of text: | This program is free software; you can redistribute it | and/or modify it under the terms of the GNU General | Public License as published by the Free Software | Foundation; either version 2 of the License, or (at your | opinion) any later version. should not be in the License: paragraph. It is not a summary of GPL2, nor does it represent what it says, and it is *not* a license. Proper licenses describe conditions for doing things to an *unspecified* set of subject materials (The Software or equiv in legalese); by contrast, the above text is preamble describing which licenses apply to which particular materials, which would normally be on a file header. Sometimes these things are merged, as is the case with shorter licenses, but with legally-written license documents, they are separated. Come to think of it, iirc DEP5 endorses this as an example, which is actually incorrect, and possibly the source of your position. X [1] except that we are not required to provide the full text of the later versions, but we don't do this anyway Also, from the ftpmaster perspective, ftpmaster wants the actual text of the upstream license included in the copyright file, and if there are multiple different texts, there should all appear. I'll bring this up with debian-policy as well. With my Policy hat on, I'd tell you the same thing, but we can certainly discuss that there if you think my analysis is wrong. -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature
Bug#645696: lintian: missing-license-text-in-dep5-copyright is too strict when considering X+ licenses
On 15/11/11 20:40, Russ Allbery wrote: Ximin Luo infini...@gmx.com writes: The issue isn't whether they're the same license, it's whether they can be incorporated into the same License: paragraph. Those seem like the same issues. As I pointed out already, your argument is inconsistent - MPL or GPL or LGPL allows relicensing as well, but DEP5 requires that we group together the uses of each component MPL, GPL, LGPL, separately. Why treat GPL2+ differently? Because you can't do the same thing that you can do with that disjunction, because there's no way to group the + part independently that makes sense. It's logically equivalent to GPL2 or GPL3 or GPL4 or GPL5 .[1] Except that you can't write License stanzas for GPL4 or GPL5, so in essence you have to treat GPL-2+ as a distinct license, since there's no other good way to accurately represent it. It's a similar case to the GPL v2 with an OpenSSL exception. There's a perfectly sensible way to represent it - write a stanza for GPL2, not GPL2+. It's perfectly clear, just as the following is clear: Files: X; License: A or B License: A; fulltext License: B; fulltext Not having stanzas for 3,4,or5 is a different issue, and the separate-GPL2+ method has this issue too. Files: X; License: A+ License: A: fulltext vs Files: X; License: A+ License: A+: fulltext Please explain why the former version is somehow less coherent, or makes less sense. I already indicated why Jakub's example is wrong. For both GPL2+ and GPL2, the full license text in question is the GPL2 as published by the Free Software Foundation, and NOT the preamble added by individual software authors. Why do you think separate paragraphs for GPL2 and GPL2+ is a good idea? I said why I think it's a good idea in my previous message. I understand that you disagree, but I'm not convinced. Going back to the previous example, this sort of text: | This program is free software; you can redistribute it | and/or modify it under the terms of the GNU General | Public License as published by the Free Software | Foundation; either version 2 of the License, or (at your | opinion) any later version. should not be in the License: paragraph. It is not a summary of GPL2, nor does it represent what it says, and it is *not* a license. Proper licenses describe conditions for doing things to an *unspecified* set of subject materials (The Software or equiv in legalese); by contrast, the above text is preamble describing which licenses apply to which particular materials, which would normally be on a file header. Sometimes these things are merged, as is the case with shorter licenses, but with legally-written license documents, they are separated. I think this is an unuseful bit of nitpicking. It captures the licensing information for the software, and would contain the full license text except that you're allowed to replace that full license text with a pointer to common-licenses. Nitpicking uncomfortable corners now saves headaches in the future; besides I already proposed a solution, so why is it a problem? The reason I know about this example is because I have already come across similar situations. If you make the conceptual mistake of including preamble with the license, you must have multiple license blocks for each preamble. You said so yourself earlier - if there are multiple different texts, there should all appear. For example, the MPL standard preamble lists all the different types of authors, instead of being a general preamble. If you have 2 distinct premables, it would be absurd to have both in the MPL License: paragraph, yet that is exactly what above example suggests for GPL2. Example: If you don't understand what I'm talking about, go find yourself a copy of the MPL and scroll down to the bottom section, EXHIBIT A -Mozilla Public License. Specific instantiations of this are dotted around everywhere. It's clearly not feasible to add all the preambles to debian/copyright, AND comply with DEP5. At the end of the day, the reason why you do it this way is because that's what DEP5 says that you should do, and the arguments for changing DEP5 for everyone are not sufficiently compelling (in large part because they create other problems, like how to not lose the + part of the description of the license). You say not sufficiently compelling, I hear too lazy to do something about it. The problems I described will only get worse with more packages. -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature
Bug#645696: lintian: missing-license-text-in-dep5-copyright is too strict when considering X+ licenses
Ximin Luo infini...@gmx.com writes: The issue isn't whether they're the same license, it's whether they can be incorporated into the same License: paragraph. Those seem like the same issues. As I pointed out already, your argument is inconsistent - MPL or GPL or LGPL allows relicensing as well, but DEP5 requires that we group together the uses of each component MPL, GPL, LGPL, separately. Why treat GPL2+ differently? Because you can't do the same thing that you can do with that disjunction, because there's no way to group the + part independently that makes sense. It's logically equivalent to GPL2 or GPL3 or GPL4 or GPL5 .[1] Except that you can't write License stanzas for GPL4 or GPL5, so in essence you have to treat GPL-2+ as a distinct license, since there's no other good way to accurately represent it. It's a similar case to the GPL v2 with an OpenSSL exception. Why do you think separate paragraphs for GPL2 and GPL2+ is a good idea? I said why I think it's a good idea in my previous message. I understand that you disagree, but I'm not convinced. Going back to the previous example, this sort of text: | This program is free software; you can redistribute it | and/or modify it under the terms of the GNU General | Public License as published by the Free Software | Foundation; either version 2 of the License, or (at your | opinion) any later version. should not be in the License: paragraph. It is not a summary of GPL2, nor does it represent what it says, and it is *not* a license. Proper licenses describe conditions for doing things to an *unspecified* set of subject materials (The Software or equiv in legalese); by contrast, the above text is preamble describing which licenses apply to which particular materials, which would normally be on a file header. Sometimes these things are merged, as is the case with shorter licenses, but with legally-written license documents, they are separated. I think this is an unuseful bit of nitpicking. It captures the licensing information for the software, and would contain the full license text except that you're allowed to replace that full license text with a pointer to common-licenses. At the end of the day, the reason why you do it this way is because that's what DEP5 says that you should do, and the arguments for changing DEP5 for everyone are not sufficiently compelling (in large part because they create other problems, like how to not lose the + part of the description of the license). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645696: lintian: missing-license-text-in-dep5-copyright is too strict when considering X+ licenses
Ximin Luo infini...@gmx.com writes: There's a perfectly sensible way to represent it - write a stanza for GPL2, not GPL2+. It's perfectly clear, just as the following is clear: Files: X; License: A or B License: A; fulltext License: B; fulltext Not having stanzas for 3,4,or5 is a different issue, and the separate-GPL2+ method has this issue too. Files: X; License: A+ License: A: fulltext vs Files: X; License: A+ License: A+: fulltext Please explain why the former version is somehow less coherent, or makes less sense. Because the *text* explaining the + part appears nowhere in the file in this case, and I don't believe that's acceptable. We need to include the legal statement from upstream, not just make it implicit in the GPL-2+ tag in the file. Nitpicking uncomfortable corners now saves headaches in the future; besides I already proposed a solution, so why is it a problem? Because I think your solution is wrong. :) The reason I know about this example is because I have already come across similar situations. If you make the conceptual mistake of including preamble with the license, you must have multiple license blocks for each preamble. That's correct. That's my understanding, also, of what ftpmaster says that people should do. For example, the MPL standard preamble lists all the different types of authors, instead of being a general preamble. If you have 2 distinct premables, it would be absurd to have both in the MPL License: paragraph, yet that is exactly what above example suggests for GPL2. There may be some missing DEP5 feature for representing this, but I believe that both of those preambles do indeed need to be in the copyright file, at least ideally. Not having them both is something I consider a bug. (The severity of the bug is arguable.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645696: lintian: missing-license-text-in-dep5-copyright is too strict when considering X+ licenses
On 15/11/11 21:15, Russ Allbery wrote: Ximin Luo infini...@gmx.com writes: There's a perfectly sensible way to represent it - write a stanza for GPL2, not GPL2+. It's perfectly clear, just as the following is clear: Files: X; License: A or B License: A; fulltext License: B; fulltext Not having stanzas for 3,4,or5 is a different issue, and the separate-GPL2+ method has this issue too. Files: X; License: A+ License: A: fulltext vs Files: X; License: A+ License: A+: fulltext Please explain why the former version is somehow less coherent, or makes less sense. Because the *text* explaining the + part appears nowhere in the file in this case, and I don't believe that's acceptable. We need to include the legal statement from upstream, not just make it implicit in the GPL-2+ tag in the file. The text explaining the or part appears nowhere as well, when DEP5 forces me to split the tri-license paragraph. The two situations are equivalent, yet you're choosing different solutions for each! Nitpicking uncomfortable corners now saves headaches in the future; besides I already proposed a solution, so why is it a problem? Because I think your solution is wrong. :) The reason I know about this example is because I have already come across similar situations. If you make the conceptual mistake of including preamble with the license, you must have multiple license blocks for each preamble. That's correct. That's my understanding, also, of what ftpmaster says that people should do. For example, the MPL standard preamble lists all the different types of authors, instead of being a general preamble. If you have 2 distinct premables, it would be absurd to have both in the MPL License: paragraph, yet that is exactly what above example suggests for GPL2. There may be some missing DEP5 feature for representing this, but I believe that both of those preambles do indeed need to be in the copyright file, at least ideally. Not having them both is something I consider a bug. (The severity of the bug is arguable.) Alternatively, treat License stanzas as published licenses, and place preamble information in License/Comment entries in File stanzas. This is a much cleaner solution and what I had been interpreting DEP5 to mean. -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature
Bug#645696: lintian: missing-license-text-in-dep5-copyright is too strict when considering X+ licenses
Ximin Luo infini...@gmx.com writes: The text explaining the or part appears nowhere as well, when DEP5 forces me to split the tri-license paragraph. The two situations are equivalent, yet you're choosing different solutions for each! That's a good point, and I think that's a bug in DEP5. Alternatively, treat License stanzas as published licenses, and place preamble information in License/Comment entries in File stanzas. This is a much cleaner solution and what I had been interpreting DEP5 to mean. That's certainly a reasonable way of expressing that information. It's not what DEP5 currently says, though, and I'm fairly sure that's intentional (from following the original discussion). But it does seem like a reasonable change. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645696: lintian: missing-license-text-in-dep5-copyright is too strict when considering X+ licenses
Package: lintian Version: 2.5.3 Severity: normal Currently the tag missing-license-text-in-dep5-copyright is emitted when the copyright file looks like this: Files: * Copyright: - etc License: MPL-1.1 or GPL-2+ or LGPL-2.1+ License: MPL-1.1 etc License: GPL-2 etc License: LGPL-2.1 etc This is unnecessarily strict, because it means we need to have separate paragraphs for both GPL-2 and GPL-2+ licensed portions of the code. This is also inconsistent with the practise of splitting out (A or B) into separate license paragraphs, with choose at your discretion being implied - since Xn+ means the same as (Xn or Xn+1 or Xn+2 or ...). -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils 2.21.90.20111004-2 ii bzip2 1.0.5-7 ii diffstat 1.54-1 ii file 5.08-1 ii gettext0.18.1.1-5 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.24+b2 ii libclass-accessor-perl 0.34-1 ii libdpkg-perl 1.16.1 ii libemail-valid-perl0.185-1 ii libipc-run-perl0.90-1 ii libparse-debianchangelog-perl 1.2.0-1 ii libtimedate-perl 1.2000-1 ii liburi-perl1.59-1 ii locales2.13-21 ii man-db 2.6.0.2-2 ii patchutils 0.3.2-1 ii perl [libdigest-sha-perl] 5.12.4-4 ii unzip 6.0-5 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch none ii dpkg-dev 1.16.1 ii libhtml-parser-perl3.68-1+b1 ii libtext-template-perl none ii man-db 2.6.0.2-2 ii xz-utils 5.1.1alpha+20110809-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
