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

Bug#633797: copyright-format: "with <keywords> exception" underspecified



On Tue, Nov 15, 2011 at 09:16:18AM +0900, Charles Plessy wrote:
> Le Wed, Jul 13, 2011 at 10:21:58PM +0200, Jakub Wilk a écrit :

> > copyright-format reads:

> > | Exceptions and clarifications are signaled in plain text, by appending
> > | "with <keywords> exception" to the short name.

> > However, it is not specified how different keywords are separated.
> > For example, should one write:
> > "License: GPL-2+ with OpenSSL and Font exception" or
> > "License: GPL-2+ with OpenSSL, Font exception" or maybe
> > "License: GPL-2+ with OpenSSL Font exception"?

> I think that this is a good point, but I am unsure if we have the capacity to
> fix it before releasing version 1.0 of the format.  I definitely would not
> object.

There's no point in declaring the spec "1.0" while ambiguities like this one
remain.  This is in fact on the list of issues that I consider blockers for
DEP5.

On Mon, Nov 14, 2011 at 06:24:18PM -0600, Jonathan Nieder wrote:
> As a workaround, "with <keyword> exception" might work, making this
> "GPL-2+ with OpenSSL exception with Font exception". :)

> Does

> 	GPL-2+ with OpenSSL and Font exceptions

> work (note the plural)?  I would be happiest if "GPL-2+ with
> <anything>" worked, as free-form text.

You can always say GPL-2+-with-anything as a custom license name, but the
value in spelling out standardized license tags at all as part of the spec
is that it allows for mechanical extraction (and eventually, automated
checking of license compatibility and accuracy of license information).  If
it's going to be extended in a free-form manner, what's the value in
partially specifying the name?

One benefit, certainly, is that you can assume that "GPL with <foo>
exception(s)" gives you at *least* all the same rights that the GPL does,
since GPL exceptions can only grant additional permissions and not take them
away.  However, the history of the draft shows that people are concerned
about knowing whether *specific* common exceptions are in effect, so I think
the spec should include a standardized way of expressing these common
exceptions, including in combination.

Of the various options suggested above for combining exceptions, I have no
strong preferences; I think it would be bikeshedding to spend overly long
discussing the options.  Does anyone else have a preferred option that we
could quickly reach consensus on and enact?

I have a slight preference for:

   GPL-2+ with OpenSSL and Font exceptions

because it's both easy to parse and reads naturally in English.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature


Reply to: