Re: 'GPL encumbrance problems'

Erwin Rol wrote:
On Wed, 2006-01-18 at 07:33 -0700, David G. Miller (aka DaveAtFraud)

mailinglists@xxxxxxxxxxxx wrote:

The point of the goose/gander paragraph is simply linking to someone else's code does *not* contaminate your code with their license. Lots of talk and FUD about this but linking doesn't foist a license since the headers and interface (which aren't protectable elements) are all that is copied. Just because you program uses a GPL library *does not* contaminate it. As an example, I somehow doubt that an Oracle implementation running on Linux makes no use of GPLed library or system calls. Same for VMware and lots of other proprietary software that runs on a Linux platform.

Linking is a "technical" term and is not of importance for the license,
the more legal term is "deriving". If your work is derived from GPL work
you have to put your work under the GPL (or compatible license).

For Oracle running on Linux, I would love to know what GPL libraries
they use? I bet the don't use any GPL library, they will use LGPL
libraries like the C-Library. The same with VMWare, I believe their GUI
is now GTK based, and GTK is licensed under the LGPL.

For the Linux kernel, the copyright holder clearly stated that running
programs in userspace on top of the OS does not count as "deriving", and
hence those programs do not have to be GPLed simply because they can run
on Linux.

Again, IANAL, but I find the argument that the library somehow gets "included" in the program to be totally bogus as long as said library is a shared object that is still normally distributed. This argument might be made for static libraries or if you literally copy and compile the code but that's a different animal.

Once again you are mixing up "linking" and "deriving". The fact that a
library is a shared object or "source included" does not change the fact
that your product is derived from that library code or not. A good
indication seems to be if your program would also function without the
GPL library, and i bet it will not.

This is untrue. I suggest that you actually *read* the LGPL. I quote from


5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled
or linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.

However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.


6. As an exception to the Sections above, you may also combine or link a
"work that uses the Library" with the Library to produce a work
containing portions of the Library, and distribute that work under terms
of your choice, provided that the terms permit modification of the work
for the customer's own use and reverse engineering for debugging such


And this is where the problem comes in. If I also link with
*another* proprietary library, then the LGPL wants that
library to be open to reverse engineering. And the vendor
who licensed me the other library has trade secrets in
his code, which he must not allow to be reverse engineered,
or lose them forever.

The easiest way out is "if you don't like it, don't use it", it really
is that simple.

Which, in many case, means "Do not build for Linux".

This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

fedora-list mailing list
To unsubscribe: