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

Comments

This article is not legal advice

[DeadSea]

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 is not the definition of derivative work that is assumed by the GPL. The GPL assumes that a derivative work is any work that uses another work. (In the GPLs case, by linking to it). If this were (legaly) not the case, as the article exists, then there would be very little difference between the GPL and the LGPL (which specifically allows usage without modification).

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.

Re:please

[robbyjo]

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!

Re:please

[stratjakt]

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?

Re:please

[blakestah]

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.

Re:Noone really understands the GPL...

[MarkCC]

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