Question: If I am writing closed source PHP software intended for distribution (not just for use as a web service, see http://radar.oreilly.com/archives/2007/07/the_gpl_and_sof_1.html), and I incorporate a few GPL components, does my software become "infected" and necessarily GPL as well?
Answer:
The answer to this question would matter to someone who has invested, or is about to invest, significant resources in what he/she may consider an original work, but who may also be tempted to incorporate freely available GPL'd software in the process.
From information you can gather from the Free Software Foundation, the answer seems simple:
"[P]eople have been wondering what the rules are when you link to some GPLv3-covered code. They're the same as they were under GPLv2: the combined work you create needs to be GPLed as well."(from http://www.fsf.org/blogs/licensing/2007-10-18-gplv3-fud)
or from Richard Stallman:
"I once found out about a non-free program which was designed to use Readline [a library covered by GPL], and told the developer this was not allowed. He could have taken command-line editing out of the program, but what he actually did was rerelease it under the GPL."(from http://www.gnu.org/philosophy/pragmatic.html)
and even more directly from GNU:
"You cannot incorporate GPL-covered software in a proprietary system.... A system incorporating a GPL-covered program is an extended version of that program.... [and] must be released under the GPL."(from http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem)
Despite these forceful admonitions that if A, a GPL work, is combined with B, then the resulting A+B then has to be GPL, there are places where even GNU concedes that it is not always the case that when one piece of GPL software is distributed with some other software, that the GPL will always override whatever "some other's" redistribution license might have been.
For example, the Linux kernel is GPL2 only (not "or any later version") and might never be changed by the kernel developers to GPL3 (http://radar.oreilly.com/archives/2007/04/gplv3_linux_and.html), while many other GNU programs in the GNU/Linux may soon be GPL3. If these separate pieces of inter-operable software are distributed together under two incompatible licenses (GPLv2 is incompatible with GPLv3, http://www.gnu.org/licenses/license-list.html#GNUGPL), then that would prove that just because B relies on, and is distributed with GPL'd A, does not mean that B is required to have the same, or even a compatible, license as A.
The possibility that proprietary software may in some circumstances use GPL'd parts is explored a bit on GNU's site:
"in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program."(from http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem)
So, the trick to keeping an original work closed, when part of its function depends upon other GPL'd work, is to maintain separation between the projects. How this is technically achieved is not completely clear.
In the case of PHP or other interpreted languages, the "include" and "require" statements that one might use to bring in some functionality from GPL source (like a template engine or WYSIWYG editor) do not necessarily involve the same level of integration as static or dynamically linked libraries, which GNU advocates have argued clearly results in all parts combining into a single GPL whole.
Whatever technical means used in keeping separation, if you want your source to stay closed, the functions performed by the GPL software should not be the core functions of your proprietary program. For example, if you have some proprietary data manipulation software and would like to add a graph to a report it generates, it might be fine to distribute a GPL graphing script alongside your program without it necessarily "infecting" your closed license and forcing it open. However, if you were producing some closed reporting software whose primary or significant function was generating graphs, then you could not include GPL graphing software to perform that function and expect to keep your source closed.
Another requirement that I've assumed this far in the discussion is that your closed project actually is an original work, and not a "derivative" one. This is because the obligations imposed by the GPL only arise when a work is derived from the GPL work. Derivative is a term defined relatively loosely by US copyright law but involves the same analysis as with books and movies. For example, if I were to write a novel describing the adventures of Harry Potter after his 27th birthday, my work would be derived from the fictional universe created and copyrighted by J.K. Rowling, and since her work is not GPL, my work would be infringing. However, if I were to write a novel about a fictional boy who reads the Potter series and spends the rest of his life trying to learn magic, I am much more likely to have created an original, non-derivative work, deserving of independent copyright.
Whether your software that uses a GPL component is derivative of that component, therefore, depends. Were portions of your work copied from GPL source? Is your version just a wrapper around a GPL core? Or is your work a distinct entity that happens to be able to interact with GPL software?
It is possible to write non-free software that talks back and forth with GPL software, without losing your proprietary license status. The boundary is just fuzzy how close the relationship with GPL software can be, beyond which you will infect your closed project. If it is too close, the risk is that your work will be deemed legally "derivative" of the GPL one, and forced open by the GPL. But if you make sure the two projects keep their distance, talk at arms' length, and keep your project's core purpose distinct from the GPL one, then you will have created a new, non-derivative, copyrighted work and can avoid any sudden GPL "infection."
Of course, there is still much uncertainty in this area. For example, some companies refuse to write drivers for Linux because they believe (whether because of FUD or otherwise) doing so would cause the GPL to spread through their intellectual property like a disease, opening source to competitors for free, and harming themselves financially. After this analysis, I don't think that would actually be the legal outcome, but there's not a black and white answer. Perhaps with more research, there would be.
References:
http://blog.lab49.com/archives/659
http://drupal.org/node/25768
http://www.linuxjournal.com/article/6366
http://www.linuxjournal.com/article/5935
http://www.redhat.com/magazine/007may05/features/compliance/
http://tech.amikelive.com/node-14/the-gpl-myth-opensource-is-free-of-charge/
http://www.techdirt.com/article.php?sid=20070921/145609
http://radar.oreilly.com/archives/2007/07/the_gpl_and_sof_1.html
http://www.gnu.org/licenses/gpl-faq.html
http://www.gnu.org/philosophy/pragmatic.html
http://en.wikipedia.org/wiki/Open_source_vs._closed_source
Posts
No comments:
Post a Comment