On 18/12/11 17:52, Steve Langasek wrote: > On Sun, Dec 18, 2011 at 12:24:03AM -0600, Jonathan Nieder wrote: >>> I disagree strongly. The cost of giving maintainers *different* ways to >>> represent the license status is much higher than the cost of requiring >>> maintainers to separately reproduce license headers for components that are >>> GPL-2 licensed vs. GPL-2+. > >> Reading this in the context of the text you are replying to, I fear I >> don't understand. I didn't mention multiple licenses or multiple ways >> to represent license status at all, so this reply feels like a >> non-sequitor. While it's useful to see that you disagree strongly, >> I'm not sure what you disagree strongly with. > > In your message, you said that you didn't think it should be required to > split the license notice into a comment field but that it should be allowed, > and you offered a patch addressing this. "Allowed" means the author of the > file has a choice about which way to do it, and that's not appropriate. > >> However, I don't think there is anything to act on immediately in this >> report, except clarifying one detail: > >> Since standalone license paragraphs are used to "expand license short >> names" and "GPL-2+ with OpenSSL exception" is not a short name but a >> short name with an exception, do I understand correctly that license >> exceptions cannot be put in stand-alone License paragraphs? > > I don't believe that's the intent at all. I think this is perfectly valid: > > > Files: * > Copyright: The Man in the Moon, 2007 > License: GPL-2+ with OpenSSL exception > > License: GPL-2+ with OpenSSL exception > This program is free software [...] as a special exception, [...] > On Debian systems, [...] > > > Perhaps the spec should be clarified to make this more explicit? > Yes, the current DEP5 supports this and has it as an explicit example. Just to be clear though, we've been talking about a proposal to change the spec, and much of the discussion here has been within the context of this proposal, *not* the current DEP5. I think your example above is not the best way to represent license exceptions. Roughly, the specification of a license can be described by this sort of grammar: CompositeLicense :: AND ( CompositeLicense1 CompositeLicense2 ... ) :: OR ( CompositeLicense1 CompositeLicense2 ... ) :: CompositeLicense with LicenseException :: PublishedLicense or later :: PublishedLicense I think License: stanzas should only refer to PublishedLicenses, rather than CompositeLicenses such as "GPL2+ with OpenSSL exception". The reason is to make re-use easy, and also to make parsing easy. For example: < allowed by current DEP5 > | Files: X | License: SomePL2 | | License: SomePL2 | [FULL TEXT] | | Files: Y | License: SomePL2+ with OpenSSL Exception | | License: SomePL2+ with OpenSSL Exception | [FULL TEXT] | [Exception notice] could be re-written as: < allowed by new proposal > | Files: X | License: SomePL2 | | Files: Y | License: SomePL2+ with OpenSSL Exception | Comment: [clarifying this complex license, if deemed necessary] | | License: SomePL2 | [FULL TEXT] | | License-Exception: OpenSSL Exception to the SomePL | [Exception notice] Now obviously this is only useful for very complex packages, most of the time you should just be able to bundle everything into the License: *field* of the File: stanza, like this: | Files: X | License: SomePL2+ with OpenSSL Exception | [FULL TEXT] | [Exception notice] -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0
Attachment:
signature.asc
Description: OpenPGP digital signature