CommonPackagingMistakes updated -- notes about debian/copyright

[Matthew Palmer]

On Sun, Jul 23, 2006 at 04:35:58PM +0200, Stefan Potyra wrote:
> Am Sonntag 23 Juli 2006 03:03 schrieb Matthew Palmer:
> > On Sat, Jul 22, 2006 at 11:47:58PM +0200, Stefan Potyra wrote:
> > > == Prelude ==
> > > When reviewing packages, one major common error I find is that
> > > the copyright file is missing some information. However with
> > > debian/copyright wrong or incomplete, you'll get a veto from me for sure.
> > > The reason is simple: If something is missing in debian/copyright, that's
> > > a violation of the involved licenses which makes the package per se
> > > undistributable.
> >
> > On what do you base the assertion that information missing from
> > debian/copyright automatically makes a package undistributable?
> 
> As an example Section 1 of the GPL:
> "... provided that you
> conspicuously and appropriately publish on each copy an appropriate
> copyright notice ..."
> 
> violating against sec 1 will mean that the GPL isn't fullfilled and that will 
> mean that no license is given at all. 

You're going to need to decide if you're writing a Legal Requirements
document or a "this is how we do things here" document.  The GPL doesn't
require you to put stuff in debian/copyright.  No licence (AFAIK) requires
you to put anything in debian/copyright.  You disagree with me here on the
basis that "this is how we do things", but later you disagree with me
because you were talking from a purely legal-theoretic point of view.

I'd suggest ensuring that the entire document talks about things as Ubuntu
wants them done.  Things that are legal niceties should be covered as part
of that, but only insofar as they are how Ubuntu wants them done.  If you
start talking about legal requirements, you'll just confuse people.  Keep It
Real Simple.

> > > == The importance of debian/copyright ==
> > > The most important thing of debian/copyright is, that it holds the
> > > copyright information for the binary package.
> >
> > Unless you're writing per-binary-package copyright files (very uncommon),
> > then the same copyright file will be shipped in each binary package,
> > potentially making parts of the copyright file inapplicable to one or more
> > of those binary packages.
> 
> But it's true that the copyright information of a binary package needs to be 
> contained inside debian/copyright, isn't it? (I'm thinking here of the fact 
> that you can install a binary package w.o. having to install the 
> sourcepackage). Imho it thus should be made clear which copyright applies to 
> the binary package(s). Can you shed some more light on this topic?
> 

You said "debian/copyright [...] holds the copyright information for the
binary package", when in fact it holds the copyright information for the
*source* package.

The source package's copyright information should be a proper superset of
the info for the binary package, but that's a side effect.

> > > licenses. There is no such thing as a general rule of thumb to get it
> > > right: Different licenses have different requirements for redistribution.
> > > While a public domain license may even state that you can do everything
> > > with the sourcecode (which would mean that you needn't put anything into
> > > debian/copyright,
> >
> > Like hell you shouldn't.  If all of the copyrightable material has been
> > placed into the public domain, that should be documented in
> > debian/copyright.
> 
> The intent of this paragraph was that you can omit it from a *legal* POV. Of 
> course this information should always be in there. I'll clarify this.

As above.

> > > === Example 1: GPL ===
> > > The GPL requires that the complete license text is distributed (you can
> > > refer to /usr/share/common-licenses/GPL, which is always there on
> > > debian/ubuntu
> > > systems), the authors and the short disclaimer of warranty (which you
> > > should include into debian/copyright). An example is in the license
> > > itself, but I'll post it here again for clarity:
> >
> > Never, ever use the boilerplate.  It probably won't match what the author
> > put in the source.  Find the licence statement in the source files and copy
> > it in -- not reference, *copy*.  That way you'll be getting *exactly* what
> > the author specified, instead of some (possibly misleading) boilerplate. 
> > As an added bonus, this generalises to any licence, so you can drop a
> > couple of hundred lines of repetitive examples.
> 
> Yep. Actually this is my position for that as well, though there are
> different opinions (like about changing the FSF-address) among the motu
> reviewers.

Changing the wording of the licence grant in any way in debian/copyright is
wrong.  If you want to change the address, that is a patch that should be
applied upstream *first*.  If you want, you can note that "the current
address for the FSF is <new address here>" *after* the licence grant, but
changing the text itself is just plain *wrong*.

> > > What licenses can be combined can be found at
> > > [http://www.gnu.org/licenses/license-list.html]
> >
> > That would be "the Free Software Foundation's opinion on what licences can
> > be combined".  Useful, but unless the copyright is held by the FSF, it
> > isn't the final word.
> 
> I beg to differ: If for example a license adds additional restrictions and the 
> whole is licensed under GPL, the resulting license would be void, since it 
> contradicts itself. Example: 
> 
> <http://lists.debian.org/debian-legal/2006/05/msg00309.html>

But the FSF's opinion, whilst almost certainly a good one, is merely
advisory in the case of a GPL'd work where copyright is held by another
party.  That other party's interpretation of the GPL (and hence it's effect
on licence compatibility and even *distributability*) is the more important
one.

> > > Usually you'll need to list the different licenses as well in
> > > debian/copyright.
> >
> > "Usually"?  Can you give an example of a case where the different licences
> > *wouldn't* have to be listed in debian/copyright?
> 
> This again is from a legal POV. Example would be the BSD-like license of 

As above.

> > > A good way to do this, is to list files with a different license together
> > > with the license in question. Wether you'll actually need to list the
> > > different
> > > licenses depends solely on the license involved.
> >
> > The licence text needs to be included either explicitly or by reference to
> > one of the standard forms in /usr/share/common-licenses.
> (see above, again this was meant from a legal POV).

As above.

- Matt