Re: xcdroast does no longer work with wodim: Who to blame?
Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) writes:
> Matthew Johnson <email@example.com> wrote:
>> On Tue Mar 03 11:07, Joerg Schilling wrote:
>> > The rules of the GPL end at "work" limit and neither libc nor
>> > libschily or libscg are part of the "work" mkisofs. For this reason,
>> > there is no problem with the fact that mkisofs links against libschily
>> > and libscg.
>> The FSF certainly believes (and I think it is supported by at least US
>> copyright law) that the complete work of mkisofs linked against
>> libschily and libscg (i.e. the binary form, rather than the source) is a
>> single work which is a derivative work of all three individual (source)
>> works. Therefore, it must be distributed under terms which are
>> compatible with the licences of all three.
> Repeating false claims does not make them correct.
> In order to create a derived work, you need to add own code of a sufficient
> creation level. The simple act of compiling does of course not create a derived
You do not even have to create derived work. Only a "Program" as in
The "Program", below, refers to any such program or work, and a
"work based on the Program" means either the Program or any
derivative work under copyright law: that is to say, a work
containing the Program or a portion of it, either verbatim or with
modifications and/or translated into another language.
> In addition: if ever, mkisofs could be a derived work if libschily but not vice
> Do you really like to tell us that compiling:
> printf("hello world\n");
> makes libc a derived work of the program "hello world"?
Please do read all of the mail and try to follow each step. And if you
have a counter argument please first check that it isn't negated
The point you are not getting is that the program "hello world" comes
under the GPL because
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
Clearly the "hello world" program contains "in whole or in part" your
main() function. To make arguments simple lets first assume you have
build a static "hello world". So the statically linked "hello world"
as a whole must be under GPL. And that includes any part of libc you
linked into it.
It does not mean libc must be GPL (compatible) but only if it is you
may distribute the statically linked "hello world". Otherwise you
violate the licenses.
But your next argument surely is that you don't link statically and
the "hello world" source and libc are independent and separate works
in themself. This is also mentioned in the GPL:
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works.
This seems to agree with your interpretation. But behold, read on:
But when you distribute the same sections as part of a whole which
is a work based on the Program, the distribution of the whole must
be on the terms of this License, whose permissions for other
licensees extend to the entire whole, and thus to each and every
part regardless of who wrote it.
And we are back again at everything must be GPLed. The fact that you
have 2 seperate works (hello world and libc), even if packaged as 2
seperate *.deb files, is negated by it being distributed together.
[I do see that it says 'modified work' above while we could distribute
an 'unmodified work'. But the DFSG reqires that we are able to patch
sources. So we must be able to distribute 'modified work' and one could
even say that packaging itself modifies the work already. So for the
purpose of Debian the above applies.]
So now why does that not mean everything in Debian must be GPLed or
nothing at all? Reading on in the GPL you have one exception:
In addition, mere aggregation of another work not based on the
Program with the Program (or with a work based on the Program) on a
volume of a storage or distribution medium does not bring the other
work under the scope of this License.
So the final question is:
Is hello-world.deb and libc.deb distributed together a mere aggregation
There is a simple test you can do for yourself. If they are
independent works in themselves then I should be able to take either
one of them and have a functioning work:
GNU C Library stable release version 2.9, by Roland McGrath et al.
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
Compiled by GNU CC version 4.3.3.
Compiled on a Linux >>2.6.28-1-amd64<< system on 2009-02-22.
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
For bug reporting instructions, please see:
That seems to be a functioning work on its own.
But "hello world" is not. A dynamically linked "hello world" binary is
not functioning without libc.
So hello-world.deb and libc.deb are no mere aggregation of
works. Therefore both hello-world.deb and libc.deb must be under GPL.
But hey, what about the exception for system libraries:
However, as a special exception, the source code distributed need
not include anything that is normally distributed (in either source
or binary form) with the major components (compiler, kernel, and so
on) of the operating system on which the executable runs, unless
that component itself accompanies the executable.
Note the _unless_that_component_itself_accompanies_the_executable_.
Since Debian distributes compiler, kernel, libraries, programs all
together the special exception can not be used.
So again we end up with the conclusion that the "hello world" program
requires that both hello world source and libc must be GPL. And the
same argument works for mkisofs linked against libschilly and libscg.