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 either). > 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. Agreed. > 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 compatible. 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 debian/copyright. 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 ftp-master. That's all there is to it AFAICT. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpT3XroEFyrN.pgp
Description: PGP signature