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.
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.
That's just as much a derivative work as if you had added another function that relied on other portions of the CGI library to work.
Either that, or the GPL and LGPL are unenforceable. If they were unenforceable, then why aren't more companies challenging the GPL? Or any companies for that matter? Answer: they don't want to invlidate their own licenses that make similar end-user restrictions.
By validating the GPL's ability to enforce such restrictions, they are affirming their own ability to enforce their own restrictions.
So it seems to me that the companies disagree with our man Rosen here.
Regarding point 2, where the GPL expressly forbids it. The question is can the GPL actually do that. The problem of the GPL in that instance is that it forbids something that cannot be clearly defined. For example it is allowed by the GPL for you to create an executable and call that executable from a propriatary program. In legal terms how does that differ from doing a library call? Ok at a technical level HUGE difference. But what I think the person was arguing is that at a legal level that distinction is not so clear.
And in part GPL decision (I think MySQL) a judge made the decision that if the program could be substituded with another then there is no binding. Therefore it could be concluded that if I create a neutral API a'la ODBC I could bind to a GPL program, without having to give up my sources.
Of course all of this is yet to be decided in a court of law....
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
There's a certain minimum amount of copied material required before it becomes copyright infringement, isn't there? If it's only one line you might be OK, since there can't be that much creativity in just one line of code.
Out of curiosity, how did they do it?
Your right to not believe: Americans United for Separation of Church and
They would quite likely love to cut costs by using GPL'd software of various sorts as the foundation for their proprietary software. Their railing against the cancerous nature of the GPL seems to indicate their frustration at not being given free reign to do with such software as they wish.
I would guess that there are a number of programmers who GPL specifically to ensure that their work is never legally usable by Microsoft. I think they would be quite displeased with this interpretation.
In this essay, where he condemns Microsoft's "Shared Source" initiative, he points out (correctly!) that if you so much as look at Microsoft source code, anything similar that you write later could be declared to be a derivative work. (He uses, as an example, the George Harrison "My Sweet Lord" case, in which Harrison was convicted of "unconscious" copyright infringement because he had once heard a song with a similar melody.)
However, in the essay cited in this Slashdot article, Rosen doesn't warn of this danger. What's more, he does not warn in either essay that it's just as much a danger when one looks at GPLed code as when one looks at Microsoft code.
This is an issue which both Rosen and the FSF have consistently ducked. If you look at GPLed source, and later write something similar, you could potentially be sued for infringement and required to release your work under the GPL -- forfeiting any payment you might have been able to get for licensing it. (The GPL requires that you license derivative works "at no cost.")
In short, in the essay mentioned in this Slashdot item, Rosen both omits vital information and fails to warn of a serious danger. Worse still, he shows inappropriate bias: he points out that danger in the case of Microsoft's "shared source," but not in the case of the GPL. This brings his objectivity and reliability as a source into question. His advice to software authors on the subject of copyrights and derivative works should be factual and based on concrete principles. It shouldn't be biased by who -- the FSF or Microsoft -- happens to own the software.