Yes, the LGPL is more akin to the BSD license where not only can you make derived works and not release the code, you can also SELL compiled binaries. Big chunks of Windows actually contain Berkley developed and BSD licensed code. The license itself is really just a formality for legal indemification and whatnot.
The BSD and LGPL are very different. You are not required to release the source of derived works with the BSD style licenses under any circumstances. With the LGPL, this is only true when you dynamically link with the LGPLed binaries. Anything that is statically linked to LGPLed code is then considered a derived work. That's why the LGPL is referred to as the "Library GPL".
You can also SELL compiled GPL binaries. The GPL does not prevent you from selling anything. It just requires that you make the source available to anyone who obtains the binary. Free software is "free" as in "libre", not "free" as in "gratis" (that's called freeware).
Think about what you've said for a second. If this were true, no commercial software written to run on Linux would ever exist. NVidia has closed source drivers for Linux and there's no legal path for anyone to take to force them to open the code because its simply not a requirement. See at some point they had to compile the drivers and the drivers need to be able to read code from the Linux Kernel Source tree. If what you said were true then those NVidia binaries would violate the GPL because they're directly linked to the Linux Kernel Sourc
.
I direct you to
this page. There is a myth in the Linux world that the Linux is distributed under a version of the GPL which has a special exception for binary modules. The referenced page has a lengthy discussion on the issue. Linus Torvalds participated. Below are quotes from him that are directly relevant to our discussion:
Nope. No such exception exists.
There's a clarification that user-space programs that use the standard
system call interfaces aren't considered derived works, but even that
isn't an "exception" - it's just a statement of a border of what is
clearly considered a "derived work". User programs are _clearly_ not
derived works of the kernel, and as such whatever the kernel license is
just doesn't matter.
And in fact, when it comes to modules, the GPL issue is exactly the same.
The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result,
anything that is a derived work has to be GPL'd. It's that simple.
Now, the "derived work" issue in copyright law is the only thing that
leads to any gray areas. There are areas that are not gray at all: user
space is clearly not a derived work, while kernel patches clearly _are_
derived works.
But one gray area in particular is something like a driver that was
originally written for another operating system (ie clearly not a derived
work of Linux in origin). At exactly what point does it become a derived
work of the kernel (and thus fall under the GPL)?
THAT is a gray area, and _that_ is the area where I personally believe
that some modules may be considered to not be derived works simply because
they weren't designed for Linux and don't depend on any special Linux
behaviour.
Basically:
- anything that was written with Linux in mind (whether it then _also_
works on other operating systems or not) is clearly partially a derived
work.
- anything that has knowledge of and plays with fundamental internal
Linux behaviour is clearly a derived work. If you need to muck around
with core code, you're derived, no question about it.
...these days it would be hard to argue that a new driver or
filesystem was developed without any thought of Linux. I think the NVidia
people can probably reasonably honestly say that the code they ported had
_no_ Linux origin. But quite frankly, I'd be less inclined to believe that
for some other projects out there..
If you're still not getting it, think about plugins. If you wanna write a plugin for a GPL'd application, your plugin doesn't have to be GPL just because the application is.
This depends largely on the nature of the plugin architecture. The "interface" of an API cannot be licensed, but the implementation can. If the plugin architecture relies on a particular GPL implementaion of an API, then the plugins will be considered derived works and must also be GPLed. However, if the plugins were not dependent on a particular implementation, then they could not be considered derived works. This follows from Linus' comments that I quoted above.
And some code can't be GPL'd. Code that contains state secrets or personal information.
That is irrelevant. If you can't release your code as GPL it doesn't change the nature of the license. You just can't derive your work from GPL code.
What about databases? If I write some script that does some stuff to a GPL'd database server, my code doesn't also become GPL'd just because its linked to a GPL'd application. And if you look at it from a certain perspective, database data is just "code" that tells the database what to do. That code doesn't become GPL just because its stored in and gets to manipulate an application that its linked to.
I'm not sure what you are getting at. From the perspective of using SQL on a GPL database, that does not make your application a derived work. However, if you link to a GPLed database library - then yes you are creating a derived work and must abide by the GPL. MySQL is licensed under multiple licenses, but if you choose the GPL option then your application becomes a derived work if it links with the C-API MySQL ships with.
Actually you're wrong. You would be required to release the changes you made to the GPL'd source as source and you could release compiled binaries of that source along with your other compiled binaries that are linked to that source but you don't have to release the code that you've written that's not a derived work of the GPL'd game engine.
That's not true. All of your code that uses the GPLed code would become a derived work. You can't mix and match. It's not a selective license. The GPL is the most viral open source license in existence. If you add anything to the Quake 3 code base, not just modifications but some completely new system, you are required by the GPL to make that source available to anyone who gets your binaries.
Its a perfect example actually. Win32 isn't derived from GPL'd stuff but the code you just wrote is (for the purposes of this example). Just flip them around and its the same example. The position of the variables is irrelevent.
It's very relevant. The GPL works in one direction: it affects workd derived from GPLed code. You can't retrofit existing software with a GPL license just because a GPLed application uses it. That's ridiculous. The existing software
is not a derived work of the GPLed software that uses it. I don't know how you can see it otherwise.
Umm you don't "derive" your code from the Win32 API, you link to it. We really need to have a good understanding of all of the concepts we're talking about here before using them in sentences. You link to libraries. You derive from previous works. Linking to a library is not the same thing as creating a derived work. Making changes to code creates a derived work. Linking only creates references and invokes stuff, it doesn't derive.
This is perhaps the biggest source of confusion surrounding the GPL and LGPL licenses. What constitutes a derived work? Logically, there's no problem with your distinction between deriving and linking. But your definition doesn't matter. Neither does mine. The only definitions that matter are those described by the GPL and LGPL. I can't remember exactly, but I don't recall that the GPL says anything about "linking". All it is concerned with is what is a derived work and what isn't (see below).
That would really be silly if all it took to force a company to open their source would be to create a GPLed application that links to theirs. There's absolutely no way such a thing could be enforcable.
Umm no shit and isn't that what I've been trying to say the whole time? Right? How is:
Shard Scripts (not GPL) vs DOL (GPL)
different from:
Win32 API (not GPL) vs GPL Example Application (GPL)?
These are two extremely different scenarios. I don't understand why you can't see the difference.
You are creating the shard scripts using DOL internals. Without DOL, there are no shard scripts. The scripts are wholly dependent upon DOL and are therefore a derived work of DOL (according to the GPL definition of 'derived').
The Win32 API existed before your GPL Example Application. It exists whether your GPL application does or not. It is not a derived work of your GPL application. The fact that your GPL app uses the API does not change this.
Basically you guys are just saying you want all scripts that run on DOL to be GPL because that's just how you want it. There's nothing in the GPL that actually requires this.
Wrong. The GPL does require this.
It doesn't matter if the process that compiles your code is the same process that executes it or not, the location of compilation is irrelevent. It is only when you change the original source code that your code becomes virally GPL'd. And its not ALL of your code, only the CHANGES to the GPL'd code also become GPL'd. That's what they mean by derived works: new "works" created by modifying the original work.
I direct you to the
following entry in the GPL FAQ, which clarifies this much better than I can:
Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program.
Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL--if you can't, or won't, do that, you may not combine them.
What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
As you say, nobody is right until a court decides. But the FAQ illustrates the intent of the GPL, and Richard Stallman, being the original force behind the GPL, has made his intent known in writings and discussions for years. When interpreting the GPL, it is best to interpret it in accordance with that intent as outlined in the FAQ.
The best course, of course, is to avoid the GPL altogether. BSD is much more palatable.
hopefuly all this stuff is figured out b4 I go live 
