[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Sponsorship requirements and copyright files

On Tue, 24 Mar 2009 07:37:48 +0100
Mike Hommey <mh@glandium.org> wrote:

> On Sun, Mar 22, 2009 at 12:55:58PM -0700, Russ Allbery wrote:
> > Well, the one thing that I think we need to clarify here is whether we
> > need to list the licenses for files that aren't source code for what goes
> > into the binary distribution, such as the build system.  The files from
> > Autoconf and Automake have a bunch of different licenses and documenting
> > them is a fair bit of work for each package.
> Actually, thinking about it for a little while, I think we're all
> missing the point.
> Who cares that file foo.c is licensed under GPL and bar.c under BSD?

Only if foo.c is compiled into libfoo and bar into an application
called bar - i.e. separate compiled objects like plugins or multiple
libraries per package. 

There is nothing in debian/copyright to help with that decision (nor
should there be, before anyone suggests it, because that doesn't scale

> People that want to take the source and use it elsewhere. These people
> are obviously looking at the sources, and don't really need
> debian/copyright information.

> But on the other hand, what are people looking at debian/copyright
> probably expecting? (and all the use cases for a machine parseable format
> I've seen quoted so far do respect this rule)
> Licensing terms for the *binary* files. They don't care that file foo.c
> is licensed under GPL and bar.c under BSD, they care that libfoo.so is
> licensed under GPL and libbar.so under BSD, or that libfoobar.so is
> under GPL/BSD, foo.h under GPL and bar.h under BSD...

Exactly - but that is what debian/copyright does not provide and by
basing the proposed format on source files, there is nothing to gain
there either.

Identifying the licence of individual binary components of a package
requires detailed knowledge of the build systems - most packages are
relatively clean and try to keep one component to one sub-directory but
there are frequent cases of AM_CFLAGS having -I../../foo/ and LD_FLAGS
having -L../../foo/libfoo.la - correlating all those in even a medium
sized package would be a horrible burden - and, again, those linkages
can change more frequently than the licences themselves, especially in
the case of how an application links against private libraries where
there are no transitions to worry about. As with discussions about the
source code listings, this simply does not scale.

I could pick out the dependencies in an autotools package because I'm
familiar with autotools, but it would be much harder to identify what
was going on in Scons or CMake or other systems.

I fail to see any development use case for parsing debian/copyright that
does not inevitably lead to a detailed study of the source code in
order to actually make any real-life decision to do with whether to use
a particular package as a dependency of my own code - at which point
debian/copyright becomes irrelevant anyway.

The licence is always only one part of such a decision process - if the
functionality is not appropriate, it is better to use a different
library with a different licence, as long as the licences are strictly

Vague ideas about users being extra-picky about the licences of
packages that they install from main seem completely impractical and the
likelihood of ever being able to convert Debian into GNewSense simply
by choosing licences at install time is unreasonably slim IMHO.
Principally this is because the existing licence information relates to
the source code, not the binaries and converting it to apply to
binaries is not scalable to Debian or particularly useful to
upstream developers.

Even lintian tests for licence incompatibilities are going to be very
hard to make reliable because lintian isn't going to know which source
files were compiled into which objects. Having a "hotlist" of libraries
that may require exceptions to be added to the GPL etc. is not
particularly easy to implement and would rely on objdump, not

Are we getting to the point of considering debian/copyright is largely
irrelevant to development/users and only really applies to distribution
of the binaries? If so, the sole arbiter of what goes into
debian/copyright should be ftp-master because it is only actions based
on distribution that have any real relevance to the contents of the
file and those considerations should be solely driven by the
requirements of the licence(s).

I must admit, when I'm doing upstream work and looking for libraries
that I can use to assist me, I have never ONCE looked at
debian/copyright for those packages - I have always gone to the
upstream source code. Each debian/copyright file I've written has been
written with the objective of meeting the requirements of ftp-master
and without any consideration of those who want to use the package in
development of other code, simply because I don't consider it wise to
base such decisions on debian/copyright and would be very surprised if
any other upstream developers would disagree.

When I talk about readability of debian/copyright, I'm thinking solely
of my work as a sponsor where I have to check that the file is (in my
estimation) going to meet the requirements of ftp-master when I finally
upload the package to NEW.

So far, this thread has failed to identify a single real-world use case
for debian/copyright that is not solely the remit of ftp-master.

Unless ftp-master want a particular format, I'm not sure that there is
any point choosing one version over another beyond human readability. I
just want to be able to read debian/copyright in packages that I offer
to sponsor and be sure that I can understand it and that I can satisfy
myself that it will be OK for ftp-master. In that respect, I still
consider the later revisions of the format to be unhelpful and I won't
be using it or recommending it. If, when sponsoring, I find any
debian/copyright file that I cannot read or understand, I will require
changes to the file whether that breaks the "format" or not, until I'm
happy that the file contains all information likely to be necessary for

That's all there is to it AFAICT.


Neil Williams

Attachment: pgpT3XroEFyrN.pgp
Description: PGP signature

Reply to: