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
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130101190531.GB16387@elie.Belkin
