mailinglists@erwinrol.com wrote:
On Tue, 2006-01-17 at 20:57 -0700, David G. Miller (aka DaveAtFraud) wrote:
jdow@earthlink.net wrote:
From: "Jeff Vian" jvian10@charter.net
> On Tue, 2006-01-17 at 21:40 +0000, Andy Green wrote: >
Up until recently I worked for a company that developed and marketed a closed source, Linux based, network monitoring product (http://www.vericept.com). The company lawyers saw no problem with us building and selling a closed source product that included calls to a variety of GPLed and LGPLed libraries. As has been extensively discussed over at Groklaw (http://www.groklaw.net) and elsewhere on the 'net, headers and interfaces are *not* protectable elements under copyright law. The only way the GPL kicks (via copyright law) in is if you actually modify executable GPLed code for your product. At worst, you would then need to make only these changes to the GPLed code available as source (there's also nothing that says the maintainer has to accept your changes; just publishing them is sufficient).
The GPL kicks in if you distribute your product. If your program needs a GPL library the program is a derived work from that library and so if you distribute that program you have to distribute it in a GPL compatible way (for example by putting the program under the GPL).
If you have a LGPL library the use of that library is not seen as a derived work and hence you are free to choose the license for your program.
What's good enough for the goose is good enough for the gander so the GPL zealots can't have it both ways. Either implementing libraries that are compatible with existing Unix(tm) headers and interfaces violates someone's (say SCO's) copyrights or using GPLed headers and interfaces to GPLed libraries in proprietary code is legal. That being said, the open source folks have a lot more to lose if headers and interfaces are suddenly found to be subject to copyright protection.
That headers aren't protected by copyright doesn't mean the implementation of the logic behind those headers isn't protected by copyright. If you have a GPL library, copyright doesn't prevent you from rewriting (from scratch) that library with compatible headers. Copyright does however prevents you from using that GPL library in a way that is not compatible with its license.
So GPL zealots, as you call them, can implement libraries that are compatible with other libraries, without violating anybodies copyright. And they can put libraries under the GPL and force you to follow that GPL when you use their libraries. You, of course, can reimplement those libraries too if you want and put them under a different license.
- Erwin
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.
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.
Cheers, Dave
On Wed, 2006-01-18 at 07:33 -0700, David G. Miller (aka DaveAtFraud) wrote:
mailinglists@erwinrol.com 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.
The easiest way out is "if you don't like it, don't use it", it really is that simple.
- Erwin
Erwin Rol wrote:
On Wed, 2006-01-18 at 07:33 -0700, David G. Miller (aka DaveAtFraud) wrote:
mailinglists@erwinrol.com 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 http://www.gnu.org/copyleft/lesser.html
[QUOTE MODE ON]
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.
[snip]
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 modifications.
[QUOTE MODE OFF]
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".
Mike
On Wed, 2006-01-18 at 15:47 +0100, Erwin Rol wrote:
If your work is derived from GPL work you have to put your work under the GPL (or compatible license).
Nope. If you create a work derived from a GPL'd work, then your work *must* be also released under the GPL, and no other license. However, you can legally created a GPL'd work derived from non-GPL'd code, if that code is released under a GPL-compatible license.
-
David G. Miller (aka DaveAtFraud) -
Erwin Rol -
Mike McCarty -
Peter Gordon