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

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification



Russ Allbery wrote:

> It might be worthwhile to recognize some sort of syntax similar to license
> exceptions so that one can tag the license as "BSD-3-Clause by <copyright
> holder>" or the like.  That would let one use standalone license
> paragraphs for those licenses without the ambiguity problem, while still
> making it clear for automated license analysis that the license in
> question is the BSD-3-Clause license (which using something like
> BSD-3-Clause-<holder> doesn't do).

It's worse than that, I think.  Pedantically speaking, 3-clause
BSD-style licenses require reproducing the warranty disclaimer
verbatim, along with the permission notice and list of copyright
holders.  The list of copyright holders is adequately preserved in the
"Copyright" field.  But the warranty disclaimer varies from project to
project:

	THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER(S) ``AS IS''
	AND [...]

	THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS
	IS'' AND

	THIS SOFTWARE IS PROVIDED BY <COPYRIGHT HOLDER> ''AS IS'' AND

	THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND

	THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS
	IS'' AND 

	THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
	CONTRIBUTORS “AS IS” AND

	THIS SOFTWARE IS PROVIDED BY GEOFF KUENNING AND CONTRIBUTORS
	"AS IS" AND

The next sentence "IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE
LIABLE" also varies, and not always in the same way as the first.

Common practice seems to vary from package to package:

 * Some ignore this detail and cite /usr/share/common-licenses
   despite the license not matching.  I suspect that violates both
   policy and copyright-format.

 * Some reproduce all variants of the warranty notice used, giving
   all variants the short name BSD-3-Clause.  I'm not sure whether the
   copyright-format permits this --- it would be nice to clarify how
   rigid the definitions in the "Meaning" column for license short
   names are meant to be.

 * Some give each variant a different short name.  This is clearly
   allowed by the spec, though it would presumably make automated
   analysis harder.

Jonathan


Reply to: