Re: Let’s turn DEP5 into something useful
Robert Collins <robertc@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
Reply to: