On Tue, 24 Mar 2009 09:18:41 +0000 Neil Williams <codeh...@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 ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpqupE4jnHgJ.pgp
Description: PGP signature
