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

Re: Sponsorship requirements and copyright files

On Tue, 24 Mar 2009 09:18:41 +0000
Neil Williams <codehelp@debian.org> wrote:

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

Actually, I'm reconsidering that a bit - separate copyright files for
separate binary packages could be good for various reasons, unrelated
to the format of the files themselves. I must admit, I hadn't
considered that option - I was assuming all along that there would only
be one debian/copyright file and that it would remain tied to the
source package.

It could be good to split a 48kb copyright file into a number of
smaller files. (libx11-data has a 48kb copyright file)

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

That still applies though - some packages would have severe problems
implementing copyright files for specific binary packages.
> 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.

(or people in a similar position who need to distribute parts of Debian)

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

As far as the format goes, that still stands - the use of per-binary
copyright files is (or can be) distinct from the format of those files.


Neil Williams

Attachment: pgpbnaBYGELTx.pgp
Description: PGP signature

Reply to: