Slashdot Mirror
Derivative Works And Open Source
marvin826 writes "
Larry Rosen has a nice article in the current issue of the Linux Journal about the legal interpretation of derivative works. Seems there are two camps in the world in terms of using open-source libraries, such as GPL licensed libraries, in proprietary software. Read this article and see which camp you are in! Having people working full-time on proprietary software, using open-source libraries, can only help the open-source software get better?
"
do we consider libraries to be part of the OS or the program?
Personally, I'd consider anything that's part of another program installed on the computer as a dependency to be fair game. If I see that Program X requires me to have GAIM installed, fine. if Program X takes GAIM source, closes, and sells it in their program that way, that's bad. So as long as it only utilizes your install of GAIM rather than including it itself, then it's all good.
Note, I also don't object to them putting it on the CD with the software, as long as it's clearly seperate from their software, even if it's a dependency, as long as they provide it within GPL terms.
In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
Yes, you are. You see, the draw of open source was supposed to be a better model for software and for business. No one should want to do business with a closed source vendor like MS since you can't look under the hood yourself.
Unless the Open Source advocates have lost faith in their "superior" software model, this really shouldn't be a problem.
What about the other side? MS wrote a lot of windows libraries. And a lot of people write open source programs that use those proprietary libraries. Ooooh.
Know what else? Commercial software companies write programs that use MS libraries too. And they profit from MS labor. And if they don't give any money to MS in the process (such as buying VS.NET or something) then MS don't get crap from it.
The problem here is determining whether using a program withing a program is derivitive. And is a library a seperate piece of software or part of the software that uses it, or part of the OS. If you were to argue technically it could go on for days. What we need is to know legally which it is. Which wont happen until we upgrade our laws to better ones that take into account modern technology.
The GeekNights podcast is going strong. Listen!
For an interesting read of why usage constituting a derivative work would be important to free software (and is part of the GPL) read Why you shouldn't use the Library GPL for your next library from gnu.org.
I myself have written popular Java libraries that I license under the GPL (not the LGPL) because I want to encourage free software development.
If you wanted to make a movie, and in your movie you had another movie playing in the background on a tv on the set, do you think you should have the right to distribute your movie containing somebody else's movie? (Ignoring fair use such as parody) I don't think you should be able to.
The article seems to be written to allay fears of business leaders that they occur legal risk by using open source software. The article does not offer good advice. I would recommend, that if you were to use open source software in closed source, look for a license that specifically allows you to do so (such as the LGPL) rather than relying on an untested definition of derivative work.
The problem is that Rosen propose 4 points:
1) The primary indication of whether a new program is a derivative work is whether the source code of the original program was used, modified, translated or otherwise changed in any way to create the new program. If not, then I would argue that it is not a derivative work.
This I agree.
2) The meaning of derivative work will not be broadened to include software created by linking to library programs that were designed and intended to be used as library programs. When a company releases a scientific subroutine library, or a library of objects, for example, people who merely use the library, unmodified, perhaps without even looking at the source code, are not thereby creating derivative works of the library.
If I understand correctly, this is expressly prohibited in GPL, but is allowed in LGPL. So, I disagree with his point here. If we allow this, companies will extort this and take advantages as much as possible -- which, of course we don't want.
3) Derivative works are not going to encompass plugins and device drivers that are designed to be linked from off-the-shelf, unmodified, programs. If a GPL-covered program is designed to accept separately designed plugin programs, you don't create a derivative work by merely running such a plugin under it, even if you have to look at the source code to learn how.
I think this is also expressly prohibited in GPL, but allowed in LGPL. So, I believe plugin system should also be discouraged in GPL, otherwise it will make a "major loophole" (like making a main program out of a plugin).
4) In most cases we shouldn't care how the linkage between separate programs was technically done, unless that fact helps determine whether the creators of the programs designed them with some apparent common understanding of what a derivative work would look like. We should consider subtle market-based factors as indicators of intent, such as whether the resulting program is being sold as an ``enhanced'' version of the original, or whether the original was designed and advertised to be improvable ``like a library''.
See reason #2 & #3. If we allow companies sell enhanced versions of GPL programs: We're in a *deep* trouble. Imagine MS taking Advanced Gnome for their own... Golly!
--
Error 500: Internal sig error
God, why do people mod this stuff up? Just because you spell Microsoft with a dollar sign?
By your logic, virtually every peice of software written for windows belongs to microsoft, as it uses their libraries. And a book report on Cujo belongs to Stephen King because his work is quoted and listed in the bibliography.
Making calls to a library that already exists on a system does not make a derivative work. IMO static vs dynamic linking should be a non-issue as well.
This is where the GPL turns to shit.
I write and maintain one app where I work, which uses proprietary libraries to generate maps. I know going in if a specific client wants to use the mapping features, he/she must either buy the mapping component seperately, or through me.
Never is there any notion that the company creating the 3rd party libraries I use gets any rights at all to my software. Yet, if the library was GPL'ed tomorrow, all of a sudden my work should be free?
I don't need no instructions to know how to rock!!!!
And why shouldn't they be scared away? If they want to make proprietary software, then let them. They just can't use GPL'd software programs or libraries as a replacement for paying for development of their own. There is always BSD licensed work to explore, if they are so inclined.
The article disingenuously ignores cases where works were held to be derived even when they did not include any part of the original work, but only (e.g.) recycled characters from the original. When the second work makes sense only in light of the original, it's derivative. A program that works only when a GPLed library is present is derivative of that library.
Claiming that dependency other than copying doesn't count is a disservice to Mr. Rosen's clients, and to readers at large. An honest article would have at least acknowledged that serious legal scholars disagree with him.
From Rosen:
3) Derivative works are not going to encompass plugins and device drivers that are designed to be linked from off-the-shelf, unmodified, programs. If a GPL-covered program is designed to accept separately designed plugin programs, you don't create a derivative work by merely running such a plugin under it, even if you have to look at the source code to learn how.
I think this is also expressly prohibited in GPL, but allowed in LGPL. So, I believe plugin system should also be discouraged in GPL, otherwise it will make a "major loophole" (like making a main program out of a plugin).
No, this sort of means that when you code a GPL program and specifically define a "plug-in" interface, that any binary that "plugs" in is not a derivative. In copyright terms, the fact that a "plug-in" interface is well-defined is enough to remove derivative status. In fact, a guiding principle here is that if there is a wall separating dependences (like a defined plug-in interface), then that wall removes derivative status.
You have already argued that this creates a loophole - I think the legal view will be that you cannot take GPL'd software and make a plug-in interface out of an existing interface for the purpose of removing derivative status. However, adding a novel plug-in interface to GPL'd software would be seen in a different light.
Remember, you have to take the point of view of someone looking at copyright history and trying to apply its law to software, and not the view of someone who wants to make the GPL as powerful as possible. A well-defined dependence "wall" is adequate to remove derivative status. If that creates loopholes, there are other ways to address that. I can't help it if the law ends up looking like a mess.
Only if you wanted to redistribute the library for free. Today, you can't distribute the library for free at all: you or your customer must buy it.
If the library was GPLed, it would not change the situation one bit. You would still have to buy it from the author under a different license in order to distribute it with your binary app. Some other people could use the library for free under different circumstances, but that wouldn't affect your usage. How is this a problem?
The GPL doesn't say that you can't create derivative works without giving them away. It says you can't
*distribute* derivative works without giving them
away.
If you're building proprietary software for use internally by the company, then they are not, legally, distributing it! In effect, it is purely free, so long as you don't distribute your derivative works.
-Mark
However I am now failing to see how a program could simply "use" a library. If someone could enlighten me I would appreciate it.
Okay, let's imagine a hypothetical GPL'd glibc. Then you write a generic "Hello World" program. Your program merely uses glibc. It does not derive from it.
When someone asks you which libraries are involved in running your "Hello World" program, they will say "what libraries do you use", and not "what libraries have you derived from."
1) The C API is essentially in the public domain. There are many implementations of it, and your program has no way of knowing which implementation it is linking to.
2) The linkage happens at run time. It is the end user who actually shoves the program and the library into the same process space. Not the developer. What you are distributing has zero glibc code in it.
3) glibc was *meant* to be used in such a manner. It has been created and distributed for wide general use by people outside of the GNU project. This is the main point of the second bulletted item in the article.
4) Dependency is not derivation. It may seem so in some software languages, but they are two distinct things when it comes to copyright.
A Government Is a Body of People, Usually Notably Ungoverned