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

Noone really understands the GPL...

[dagg]

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.

Re:please

[Daniel Dvorkin]

So we're supposed to pump out open source libraries so that giant companies like Micro$oft can write proprietary applications around them and profit from our labor? Would they like us to polish their boots while we're at it?

I don't trust this "article" a bit. $1000000 says it was funded by some big company looking to milk open source advocates for all they're worth.

Um, I rather doubt Lawrence Rosen is a Microsoft shill.

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.

It should be REALLY clear

[blakestah]

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.