Sunday, November 8, 2009

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.

Sunday, November 1, 2009

My Impressions of DTLS and OpenSSL

So after a weekend of fun with DTLS, OpenSSL, and OpenSSL.NET, I am not entirely onboard with the idea of using it as the backend for our P2P Security system. So let me list my pros and cons of using DTLS:

Pros:
  • Maintained by someone else
  • FIPS certified
  • Availble for all platforms
  • Popular, well documented protocols
Cons:
  • Lacks the level of documentation found for most of the other libraries I've used
  • DTLS is scarcely mentioned on the website and it is unclear to me how well it is actually maintained
  • DTLS (manual) renegotiation is broken
  • The library doesn't really make it easy to determine when a SSL session should be aborted
  • There is no async callbacks for when data is ready, which would be really helpful for handshake messages
  • Platform dependent (i.e. library -- ABI -- is not portable, API is)
  • The DTLSv1_methods lack the reliability layer that is actually in the DGRAM BIO
Given that there is an existing Security library in Brunet that actually handles the above cons lacking FIPS and support by others, it feels like I am between a rock and a hard place. My real goal was to get enough knowledge to add the details in my paper comparing my experiences with a standard DTLS implementation in comparison to a home brewed version. Since the transition to DTLS hasn't been entirely smooth sailing, I am a little hesitant to jump on board. I suppose two things need to be ensured to me, that renegotiation works and that messages are still transferable during renegotiation. While waiting, I may just test out what actually happens in systems that rely on DTLS, because I have a feeling that the libraries are significantly faster than .NET crypto libraries.

Note: I stand corrected, the DTLS bug is fixed in version 1.0.0 betas, though with a new added twist of segmentation faults!