debian/copyright for files not part of the binary packages? [firstname.lastname@example.org: Re: freetds_0.82-2_amd64.changes REJECTED]
I have recently had a package rejected out of NEW on the grounds that the
debian/copyright file was incomplete for not listing the GFDL, which is used
as the license for some documentation that is shipped in the source but not
included in the binary packages.
This is not a legal issue; the GFDL documents are themselves distributed
properly, and everywhere they appear (i.e., in the source only), they're
accompanied by the license text. It is not a freeness issue, because the
documents are licensed under the GFDL in the manner which has been approved
for main. And it is not a Policy issue: Policy states only that every
binary package must include its copyright and license in
/usr/share/doc/<package>/copyright, there is no requirement at all that
debian/copyright list licenses for files that don't contribute to the
copyright of the binary packages. (Indeed, the ftpmaster who rejected
the package acknowledges that this requirement is not applied to files such
as config.sub which do not impact the copyright of the binary packages.)
Finally, it is not in the least a regression vs. what's in the archive,
because this package was only in binary NEW and the GFDL docs in question
are already present in stable.
Yet the package was rejected from the NEW queue, on the grounds that this is
the ftpmaster "policy". Well, the only announced policy that I can find is
is not at all explicit about listing licenses that apply only to unused
files in the source package. Is this a policy that others have actually had
applied to their package uploads? Is it *acceptable* for the ftp team to
apply such a policy, which is not grounded in law, the DFSG, Debian policy,
or considerations of archive integrity, as a condition of inclusion in the
I don't think that it is. I think it's outside the ftpmasters' authority to
declare this a bug *and reject the package for it* when there has never been
public discussion within the project that this is a requirement. As far as
I'm concerned, it's not even a bug - I consider it a *regression* to accost
users with legalese in the copyright file that has no bearing on those
binary packages, and I don't think I should have to ship an extra
copyright file (one for the source and one for the binaries) just to satisfy
this ftpmaster concern. Obviously the ftpmasters can find out the licenses
of source without relying on debian/copyright, or this supposed bug would
never have been noticed and the package would never have been rejected!
Since nothing about this package would be grounds for removal from the
archive (AFAICS), should it really be grounds for keeping an upload out of
For reference, a copy of my email exchange with Joerg Jaspert is included
Awaiting your thoughts,
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
 Technically, in spite of using "debian/copyright" as a section title,
Policy doesn't require debian/copyright to exist at all - the implication is
that the copyright file in the binary packages will be copied from
debian/copyright in the source package, but this isn't required. I concede
that this is probably a Policy bug, since it's impractical for the ftp team
to verify that source packages are compliant without a single location where
they can find the source of /usr/share/doc/<package>/copyright.
 Ultimately I intend to ship these docs in a separate binary package, at
which point I would obviously need to start docmuenting the license. But
I'm not planning to do that yet, and in the meantime this frivolous NEW
rejection has blocked a library transition which had been approved and
coordinated with the release team for lenny.
----- Forwarded message from Joerg Jaspert <email@example.com> -----
X-Spam-Status: No, score=-1.1 required=3.0 tests=BAYES_05 autolearn=ham
From: Joerg Jaspert <firstname.lastname@example.org>
To: Steve Langasek <email@example.com>
Cc: Joerg Jaspert <firstname.lastname@example.org>
Subject: Re: freetds_0.82-2_amd64.changes REJECTED
Date: Fri, 04 Jul 2008 23:07:28 +0200
X-GPG-FP: DF7D EB2F DB28 FD2B A9FB FA6D 715E D6A0 7E7B 8AC9
X-message-flag: Formating hard disk. please wait... 10%... 20%...
On 11436 March 1977, Steve Langasek wrote:
> - This GFDL documentation is already in the archive. It is not a new
> addition to the source package, and rejecting the new upstream version
> does nothing to benefit the licensing status of anything in the archive.
Its the place where I see it, so naturally the place where I take action.
> - The GFDL documentation is not part of the binary packages. The *primary*
> use of the debian/copyright is to document the license of the binary
> packages, where users don't have the full source code to hand in order to
> check licenses directly. It has never been a Debian *policy* to require
> documenting the licenses of extraneous files in the source package that
> don't contribute to the copyright status of the binary packages. While it
> may be helpful to some subset of users who are working with the source, it
> also clutters the copyright file in the binary package with information
> that is not relevant to users of those binary packages. This is
> equivalent to requiring listing the GPL for all packages that include a
> copy of config.sub, and should not be the policy.
Its ftpmaster policy in NEW for, err, years now to list everything for
which we distribute files, which includes stuff in the source.
There are a few exceptions, as that would set too many packages
insta-buggy, like the config.* you mention.
> - The FreeTDS User Guide is licensed under GFDL 1.1 or any later version,
> with no Invariant Sections, Front-Cover Texts, or Back Cover Texts. I
> would expect that if an ftpmaster were going to use this as grounds for a
> package rejection, he would have verified this directly instead of
> requiring maintainers to deal with false-positive rejects.
Its the maintainers job to check (and list) the licenses (and the
license options used) for their packages, not the ftpmasters. We just
check if they are there.
[GPG Keysigning stuff]
The web of thrust would become completely unthrustful.
----- End forwarded message -----