Re: GPL, yet again. (The kernel is a lot like a shared library)
** Mark Rafn ::
> On Wed, 7 Sep 2005, Joe Smith wrote:
>
> > It is generally belived that the GPL 'derivative' clauses may
> > actually be upheld in the case of static libraries. The fact
> > that linking the .o's of the library directly with your program
> > is equivelent to linking the library with the object files of
> > your program, seems to verify this. The question still debated
> > is whether Shared libraries are like this also.
>
> I haven't heard it debated very hotly in recent memory. General
> acceptance seems to be that it applies equally to static and
> dynamic linking. Dynamic linking DOES open up the possibility of
> distributing the using code and not distributing the library
> itself. The combination of the two may be un-distributable,
> however.
One of two apply: either both Michael K. Edwards and I are in your
killfile OR you haven't payed a lot of attention lately.
My (and his) argument goes more or less like this:
1. GPL section 0 defines the expression "a work based on the
Program", which will be used in the rest of the license as being
"either the Program or any derivative work under copyright law";
after that, it paraphrases (separating the explanation with a colon)
trying to explain what a derivative work is under copyright law, and
failing, because it says "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." which is blatantly false,
because the definition of a derivative work is "the work that
results on an intellectually-novel transformation over the original
work."
1.1. this leads me to the conclusion that (1) above defines "a work
based on the Program" as a synonym for "a derivative work of the
Program (or the Program itself)".
2. GPL section 0, paragraph 1 states that "Activities other than
copying, distribution and modification are not covered by this
License; they are outside its scope. The act of running the Program
is not restricted". Hold on to your hats and I'll mention this
later.
3. GPL section 2, paragraph 3 states that "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."
3.1. this leads me to the conclusion that, even if at some point in
time (run-time) the works (GPL-incompatible library and GPLd
program, for instance) will be combined to form interdependent
chunks of computer memory, as the program is NOT a derivative work
of the library nor vice-versa, distributing in the same CD, website,
or whatever both the program package and the library package will
invoke section 2 paragraph 3, because they are not interdependent in
the moment of the distribution.
3.2. and, in the light of (2) above, this is even not contributory
infringement, because the GPL section 0 paragraph 1 _explicitly_
licenses the final user to do what he needs to _use_ the program.
3.3. it seems to me that it's absurd to think, for instance, that
Debian cannot dynamic link a GPLd program with OpenSSL. Why? Because
if I write a completely-compatible MassaSSL library and install it
in my system just in the same places/names/sonames/whatever OpenSSL
is installed, this would change the copyright status of _the_
_program_!!
Because of the argument above, I don't think the combination of the
two would be undistributable at all.
Why is all that different in the case of static linking? Because in
the case of static linking, the "intermingled" executable can be
considered (altough I don't think so) "not merely aggregated", as
the fixups are already resolved, etc, etc.
>
> > The linux kernel 'copying' file states this: NOTE! This
> > copyright does *not* cover user programs that use kernel
> > services by normal system calls - this is merely considered
> > normal use of the kernel, and does *not* fall under the heading
> > of "derived work". If that statement is true and if it does not
> > qualify as a licence exception, then the following argument
> > would hold:
>
> I think this is a license exception (or at least a clarification
> that applies specifically to this work). It is not a statement
> about GPL-licensed work in general.
In this, you are right.
>
> > NOTE! The GPL does *not* cover programs that use shared
> > library services by normal function calls - this is merely
> > considered normal use of the shared library, and does *not*
> > fall under the heading of "derived work".
>
> The copyright holder of a given library would have to make that
> statement for the library in question for it to apply.
Agreed.
--
HTH,
Massa
Reply to: