Working In And Around Licenses

Recently our group has been confronted with the issue of how to interoperate with non-GPL compatible code. Previously, a professor, whom I work with, has been considering this issue along with how to allow GPL incompatible or more specifically closed source application to interoperate with our P2P library, Brunet. At the root of the problem is the "viral" nature of the GPL. Namely that all derived works must also be GPLed, see this. Of particular interest in the GPLv2 is the definition of derived works and what consists of distribution.

During a recent discussion, one thought was that we could use a binary or conversion interface to bypass this issue and another was that we could use sockets, both of which were shot down by this message. Which made me wonder, how do other non-free applications link to GPL applications and what it falls under is distribution. Primarily, you cannot distribute non-GPL code that interacts with GPL code together, the intent is a derived work. Using a socket or a wrapper library effectively yields the same purpose, a circumvention of the GPL. Now what seems to be entirely possible is to define a binary interface or object interface licensed using a non-viral license, such as MIT/X11, use that interface to implement a GPL-incompatible application and distribute the two separately.

Before I go any further, there are a couple important things to consider here, who owns the code at hand and what is their interpretation of the GPL. The owners appear to be UCLA, some students at UF, and primarily the professor introduced at the beginning of this blog. Our first goal is try to get UCLA to allow a relicense of the software into MIT/X11 or even relinquish their right over the software, at which point, we could keep that license wrapped up and then relicense the software publicly as needed. More importantly that would mean the GPL interpretation used would primarily be the professor's, thereafter, it would be distributors such as students and even Linux distributions such as Debian, Ubuntu, and Redhat.

This leads to a more interesting question, what is generally accepted. Based upon the message I linked to above, it leads me to believe we either need to have a GPL friendly version or the application needs to work with out it. Furthermore, the application must be distributed separately and the GPL code cannot have auto-install or configuration scripts that bypass the GPL. Then users who install the non-GPL libraries would be not breaking the GPL in so long as they themselves do not distribute the set publicly. Of course, the auto-install / configure scripts could be part of the GPL-incompatible code.

This leads me into a more interesting question, can we distribute these in a VM? Given that the GPL allows use of "OS libraries" be mixed together, both GPL and GPL-incompatible, I believe that a VM Appliance can have such applications bundled together.

This all really boils down to what the intent of the GPL is and more specifically the license owners. My opinion is that no one wants to see their source code be eaten up and used without at least recognition and bug fixes being trickled into mainstream code. Closed source developers that desire stability would contribute both bug fixes and features that they deem in the critical path to the maintainers of Brunet, otherwise they would have to deal with maintaining complicated sets of patches.

Taking a step back, can someone stop me from distributing a library or application that links to MIT/X11 code, I think in all cases, the answer is no. Can someone stop me from bundling said binaries especially in the case of GPL-incompatibility with a GPL application, I think the answer is clearly yes. I am very curious how others see this issue. Most importantly, I really look forward to understanding all the points of view in the group. It has become very apparent to me that everyone has an opinion on this and I wouldn't be surprised that we don't find out whether or not we went the right or wrong way until someone else tells us.