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?
"
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.
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*
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.
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.