Robert Collins <robe...@robertcollins.net> writes: > On Sat, 2009-06-13 at 13:35 +0200, Andreas Rottmann wrote: >> >> For that to work, you'd have to somehow indicate which files' licenses >> are going to be relevant to which binary package. For instance, many >> packages have (parts of the) build-system machinery GPL'd (e.g. the >> ltmain.sh from libtool is GPL-2+), but the rest of the package uses a >> laxer license (e.g. LGPL). > > I'm fairly sure that ltmain.sh has a GPL exception stating that things > output by that script are not GPL'd. > OK, that indeed was a bad example, as ltmain.sh indeed has a GPL exception.
> A build tool that pollutes the licence of what its used to build would > be rather problematic > Indeed. But do you always need an exception? I had the impression that the output of a GPL'd tool could be licensed at will, unless the output contained parts from the tool itself, as is the case with autoconf, for example, which has an exception for this reason: [...] You need not follow the terms of the GNU General Public License when using or distributing such scripts, even though portions of the text of Autoconf appear in them. [...] > - do you have any actual examples? > A real-life example from libunistring (which I've filed an ITP for [1]): The source files that will constitute the resulting library package are all LGPL-3+'d, but the source tarball also contains a test suite, which is GPL-3+ (without any exception). Now is the license of the test suite relevant to the resulting library package, effectivly rendering it GPL-3+? I don't think so, but looking at a debian/copyright file using the current DEP-5 format, one cannot really tell that the libunistring package is actually under the LGPL-3+, hence my suggestion to add information about which license applies to which binary package. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532125 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org