Jonathan Nieder <jrnie...@gmail.com> writes:
> 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.

I think you may have missed my point.  :)  I believe that all of those
variants should, as is currently required, be separately represented in
the debian/copyright file.

The one change that I want to make is to allow them to all have the same
short name for the aid of automated analysis.  There isn't any way to do
that right now since there isn't any way to indicate a License paragraph
for the specific license text without changing the short name.  This new
syntax would allow using the correct short name but still giving each
distinct License paragraph a unique name that can then be referred to in
Files paragraphs.  I do think it's reasonable to give all those variants
the same short name as long as there's some other way to mark them
uniquely.

> 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.

Agreed.

>  * 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.

As I stated in my message, I believe the current wording does not allow
for this since it requires that the short name be unique within the
copyright file, but indeed it could use some clarification.

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

I believe this is the only acceptable thing to do when declaring the
copyright file compliant with version 1.0.  Hence the above proposal for a
version 1.1.

For a specific example of a package with this problem, see:

http://packages.debian.org/changelogs/pool/main/r/remctl/current/copyright

and note the MIT-Kula and MIT-Martinez license short names.  It would be
better to be able to note these licenses are versions of a standard,
well-known license.  (I use the copyright format for both the upstream
LICENSE file and the debian/copyright file.  It's mechanically constructed
from the license notices in each file via a script.)

-- 
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

Reply via email to