Bug#336982: dh-make: Difficulties with the debian/copyright template
Package: dh-make
Version: 0.40
Severity: important
File: debian/copyright
The problem is with the template ./debian/copyright files created by
/usr/bin/dh_make, not /u/s/d/dh-make/copyright.
I'm Cc: debian-legal, and I checked the BTS documentation so its going
to work right This Time.
Please, add comments as necessary; I've tried to do my best to create
a sane template, and to dicuss the present problems.
Lots of people see and are affected by the dh_make templates, so I
think lots of people should comment on changes there. Please keep in
mind that lots of new developers will use the New Maint Guide, which
essentially has as step 1, Run /usr/bin/dh_make. So it should be easy
to understand, and intuitively clear how to do the right thing, even
to someone who has no formal education in copyright law.
I filed bug #286843: "Please use 'Copyright Holder: <boilerplate>'",
and dh_make now does so. It looks like:
Copyright Holder: <put author(s) name and email here>
This has to include a copyright year, also. Please update the
boilerplace to indicate that. Also, the copyright holder is not
necessarily the author. This is necessary, I think, in the case that
one tries to investigate the "trail" from authorship, through a list
of people between whom copyright may have been transferrred.
There is also an issue with the license boilerplace. Consider the
developer who notices that their package is apparently (by cursory
inspection of a ./COPYING file, or a header in the sources files)
under the GPL license. They will be tempted to run: dh_make -c gpl.
However, that will cause their packages' copyright file to include the
"version 2 or later" clause, even if it wasn't present in the upstream
sources! The same goes for the LGPL.
In fact, with the LGPL, there is also the issue of s/package/program/
and s/library/lesser/. I think it is confusing and in bad form to
include a modified distribution license covering another's work.
Updating the FSF postal address should be okay IMHO.
There is another annoyance; .. dh_make -c specifies the license. The
-l option is taken by "library package". To me, -c means "copyright",
but then the user is specifying "-c gpl", and the gpl is not a
copyright holder (which is the most of the motivation behind these
bugs).
The best solution I came up with involves removing the -c option,
thusly removing any implied confusion between copyright and license.
Then update the templates, which could become:
Upstream Authors:
<template>
Include the names and contact addresses of all upstream authors;
this is useful, for example, in the case that they need to be
contacted regarding licensing issues. It might also make sense to
include support addresses here.
Example:
Justin Pryzby <pryzbyj@justinpryzby.com>
Support Address <package@example.com>
Legal Issues <legal@example.com>
</template>
Copyright Statements:
<template>
Include the names of all copyright holders here. Also include the
range of years during which they made contributions to the package.
The copyright holder is not necessarily the same as the upstream
author; employers usually hold the copyright on works for hire;
other works are placed in the public domain by their authors, which
means that copyright is relinquished; other times, copyright is
transferred from the author to a publishing agent.
All source files must be accounted for; oftentimes, multiple authors
are involved in a given software package. You should at least look
for evidence of this with a command like: grep -ir copyright .
A typical copyright reference will look like:
Copyright (C) 2005 Justin Pryzby <pryzbyj@justinpryzby.com>
</template>
Distribution Licenses:
<template>
Include the licenses of all source files here. Oftentimes, there
are multiple licenses involved in a single software package, and
each msut be clearly documented. Be particularly careful of such
things as the GPL "version 2 or later clause"; include that clause
if and only if the upstream license includes it.
</template>
Lintian should error on m/<template>/i; I have bug #286842 which is
relevant.
Reply to: