Dynamic...Static...hmmm

Updated the post - the link to the pictures at the end should be fixed. (That's what you get for setting up something in 3 minutes from O'Hare between flights.) Also putting in a great comment I got privately by someone who asks to remain annonymous. Excellent points though and worth adding here.

I have been reading Ian Murdock's blog entry on the latest flap around the implications of source licensing. (I'm a nerd on this stuff, can't keep away from it.) Here is what Ian has to say about the issue with Nexenta and Solaris (read GPL and CDDL).

The issue in this case: Nexenta links GPL-licensed programs (including dpkg) with the Sun C library, which is licensed under the GPL-incompatible but still free software/open source CDDL license. Granted, Nexenta didn’t go about introducing themselves to the Debian community in the best way, and there may (may) be issues around whether or not what they are doing is permitted by the GPL, but couldn’t we at least engage them in a more constructive manner?

In terms of the actual issue being discussed here, am I the only one who doesn’t get it? It seems to me the argument that linking a GPL application to a CDDL library and asserting that that somehow makes the library a derivative work of the application is, to say the least, a stretch—not to mention the fact that we’re talking about libc here, a library with a highly standard interface that’s been implemented any number of times and, heck, that’s even older than the GPL itself. It’s interpretations like this, folks, that give the GPL its reputation of being viral, and I know how much Richard Stallman hates that word. It’s one thing to ensure that actual derivative works of GPL code are themselves licensed under similar terms; it’s quite another to try to apply the same argument to code that clearly isn’t a derivative work in an attempt to spread free software at any cost. I’ve been a big GPL advocate for a long time, but that just strikes me as wrong.

I don't know Ian, but he strikes me as an extremely bright guy and has also pretty clearly shown he has chops in the Free Software development space. So what is the rub here? The fact is, if you ask the Free Software Foundation GC Eben Moglin about his opinion regarding static vs. dynamic linking (which I have), he asserts a rather startling thing. His interpretation is that BOTH a static and dynamic link represent aggregation and the terms of the GPL (if you distribute) apply. When I have asked this same question of the commercial OSS players (particularly the Linux vendors) they will adamantly state that it is only static linking that would do it.

This strikes me as a very important question for all organizations seeking to do work with code licensed in this way. How many ISVs building commercial apps on Linux would care about this? I know that SAP, for example, explicitly dictates which version of the C library you may use. I would assume that means they are making use of it in a dynamic fashion. (feel free to correct me on that one). 

The other issue that comes up in the text from Ian's blog is that of compatibility of licenses. The community that is concerend about this situation is correct in that the CDDL and GPL are expressly incompatible. In fact, all reciprocal licenses are incompatible. That is the nature of reciprocal terms. The Ms-CL, GPL, CPL, MPL, EPL...all incompatible with each other. I don't think there is nefarious intent behind this incompatibility - rather, this incompatibility lies at the heart of the protection of rights that the FSF states was their goal.

I posted 2 simple images here (hope it works), that shows the complexity of source licensing within two popular distros of Linux. If the dynamic linking statement is true from the FSF - what is the result of these two images?

Food for thought for sure.

UPDATED COMMENTS ADDED - 11/13/2005

This comment was sent to me privately and the sender has requested to be anonymous. Interesting points...

I'm with Eben on the distinction between dynamic and static linking. That's a run-time technical detail, not a difference in the fundamental intent or use of the combined work. I don't like to try to codify restrictions along those lines in license language, because the technology for linking changes over time. My view is that if you build an app that uses Berkeley DB, you are subject to Berkeley DB's license restrictions, regardless of whether you link at the time you write the compiled program to disk, or at the time that you read it back into memory.

That said, I'm in absolute agreement with Ian on the issue of libc. In fact, glibc uses Berkeley DB, but we don't insist that every glibc user must individually comply with the terms of the Sleepycat license. First, app developers calling the standard C library really aren't thinking about ways to exploit the Berkeley DB bits that live beneath the covers. More fundamentally, though, taking that stance would alienate developers.

My intent is not to ding the GPL with this posting. Rather, it is to highlight an important point of confusion relative to the commercialization of OSS. As Microsoft continues to work with ISVs who are building solutions with FLOSS technologies (think back to the JBOSS announcement), and as we release technologies under our own reciprocal license, we will have to be cognizant of these issues. I know that the GPL 3.0 effort is in process and these types of issues are on the table. I recently sat through a speech by Eben at OSBC East and was as impressed as always with his erudition on this subject.