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.
I've contracted for multiple fortune 100 companies and personally installed 1000's (literally) of GPL'd modules onto their server machines. Those modules are all critical components of their mission critical software. It would have cost tens of thousands of hours to make the software function without the GPL'd software. But you know what? These companies don't have a clue what GPL even means. As far as they are concerned, the GPL software is just free.
Sex - Find It
Did you RTFA? It's as much descriptive as prescriptive; as I read it, he's basically saying, "Here are some of the legal issues to be considered in deciding what constitutes a 'derivative work,' and they're tricky issues, so define your terms carefully." Which is entirely reasonable, especially in light of the mindless GPL-vs.-BSD flamewars.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
I wish there was some there was some way that I could be outside playing basketball, in the rain, and not get wet.
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!!!!
A good overview of the issues.
However, I think that the classic issue that has stumped the traditional wisdom is not coverdd. That is the case of "interface definitions" that must be loaded and merged with your source code at compile time. These include C or C++ "header files", or the "modules" of Perl. In interpreted languages the issue gets really sticky because you can modify those external libraries at run-time.
For example, is this Perl module a derivative work?
package CGIOverride;
use CGI;
sub import {}
package CGI;
sub params { die }
sub new { die }
sub start_html { die }
1;
__END__
Here I basically edit the CGI module, but I do it at compile-time. If the law has to start getting into compile-time vs. pre-compile-time distinctions, I think we're going to be in for a bumpy ride!
Even worse... one way to resolve the above is to say that I'm not editing CGI, I'm editing the CGI namespace. At that point, we have to decide if a namespace is something that is protected under copyright law! Are namepsaces just a loosely maintained analog of the domain name system? Is a Perl module or a C++ header analogous to a programmer's Web site? *shudder*
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.
That this is a complete mess, legally.
There are, however, some guiding principles. One of the is that of the non-unique well-defined interface. For example, if a program only used POSIX libc calls, it is not a derivative work of any C library it uses. This independence is because you can change the C library freely, and the program's function doesn't change. So we can easily establish that libraries that adhere to a spec, for which multiple DIFFERENT libraries exist to fulfill that spec, do not make derivatives of programs that dynamically link to them.
Static linking I think is highly likely to make the calling program a derivative, since the library forms part of the functional binary.
Now, on to dynamic linking with a unique library. This case is the REALLY interesting one. Some people argue that inclusion of the header files makes something a derivative. This is utter nonsense. A header file is made specifically so that a calling program may include it. Also, you could replace the header file with another file that provided the same functionality trivially (it defines an interface, a function, and it not really expression in the same sense that the main program is). I don't think this argument will ever fly. But, in this case the program cannot function at all without one specific library. So, it is likely a judge would rule that it is dependent in copyright, and a derivative. Note that if someone coded a clone replacement library, then the dependence vanishes, as does the derivative nature of the work. Larry Rosen disagrees with this point of view, b/c he claims libraries are MADE to be linked with. But, this point is still to be decided by a judge.
There are other cases that are clear. Plug-in interfaces, for example, are like walls that separate dependences. The interface is well-defined so that no one on either side of the interface needs to know anything except the interface itself. Not a derivative.
As you can see, the rules are not hard and fast, and there is a slippery slope to tread.
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?
I'd like to suggest a pragmatic approach: What definition does more to advance the cause of promoting the use of open-source systems? If we say that linking to system libraries makes an application subject to GPL, we can expect the makers of proprietary software to avoid open-source platforms in droves. This would help M$ to maintain the "applications barrier to entry" that has so far discouraged many people from switching to Linux.
In my opinion, we should say that calling library routines does not make the calling program subject to GPL.