Re: Bug #189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps
Steve Langasek wrote:
>It is not "mere aggregation", for the same reason that a bug in a
>library that makes it unusable by applications is a grave, not a
>critical, bug: one piece of software is not "unrelated" to another if
>the former depends on the latter.
Ah, I get what I was missing earlier... so you're claiming that there's
a legal status for a combination C of A and B, which does *not* make C a
derived work derived from work B, but where C is also not a mere
aggregation of work A with work B.
I don't think there is. I could be wrong, of course. IANAL.
>If removal of foo makes bar unusable, the combination of the two cannot
>be considered mere aggregation.
Is that a quote from a legal opinion? If so, I defer to your expertise.
I didn't think that was the legal ruling on the nature of derived
works. But if it *is*, if it's a combination involving copyrightable
elements and it's not 'mere aggregation', then it's a derived work. I
think there's no 'third state'. Again, I could be wrong here!
>Not all: the terms of section 3 talk about covered source code in very
>broad terms of "all modules [the work] contains". Can you expand on
>your understanding of this phrase?
"The work" is the *derived work* derived from the original GPLed work.
It has to be *one work*. For the GPL to apply to it as a consequence of
section 2b, it has to be a *derived work* of the original.
The "modules" are independent pieces which can be extracted from the
derived work, but may individually not constitute derived works.
Suppose we have:
GPLed source file A
My source file B
Object file C, compiled into a program from A, B, and C.
Object file B, compiled from B alone
Executable file C is one "work", which is a derivative of work A. The
source file B is the source code for a "module" which is not a
derivative of work A. The source file A is the source code for a
"module" (which is work A.) That was my interpretation of "modules"; I
assumed that it was mainly an effort to elaborate on requiring
*complete* source code for an object code file, given the context it's in.
The "special exception" for operating systems still remains meaningful,
because it covers OS header files, which may not be freely
distributable, and are, in fact, source code for the compiled object file.
I was more interested in the phrases about "identifiable sections" in
section 2, but they clearly start from the assumption that there is a
"modified work", such as executable file C.
>Noted. I've come to believe that the basis for claiming the >application
>is a derived work in these cases is very weak, but it still seems
>prudent to treat dynamically-linked works as covered by the GPL's
>source code requirements for the time being.
This, we agree on 100%. :-)
--Nathanael
Reply to: