Partager via

Dynamic...Static...hmmm

  • Article

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.

Comments

  • Anonymous
    November 13, 2005
    Your images don't work. I definately want to comment here; hopefully I'll rememeber to do so in the morning, but it's bedtime for me now. (I'm in GMT.)
  • Anonymous
    November 13, 2005
    The comment has been removed
  • Anonymous
    November 13, 2005
    images aren't working here, Jason.
  • Anonymous
    November 13, 2005
    My understanding of the GPL - well, practically everything concerning grants of authority and authenticity - has always been that authorizationand authentification goes upwards/upstream.

    That is to say, what depends on something relies on its authenticity, therefore its authority. In consequence, a library is not affected by the software it is bound with; the software it is bound with is affected by its license. RMS used that argument as a basis for the long and extensive development of the GNU C Library and the GCC compiler suite; it was one of the reasons why we now have KDE and Gnome - because KDE although GPLed itself, was dependant on the then non-GPLed QT graphics library.

    (It is also one of the reasons why I recommended in a previous post that Microsoft seize the day and clear up the "Shared Source" hooey surrounding the WinCE "Shared Source" license proliferation - because a certain number of Open Source developers must needs use the MS WinXX platform, they have developed a sizeable library of functions, etc, that uses and/or mimics the Win32 API - eg, Wine, Twin, MinGW, CygWin, etc. Microsoft is now in danger of losing control of its own Win32 API, like it or not. Jump in and enjoy the surf, is my advice ;)

    For Moglen to argue that way is to break with precedence. I think he should think again.

    AFAIK, dynamic linking, since it only exists for the period of that linkage, doesn't constitute a single work under copyright law, whereas static linking does create a single work that lasts for longer than its loading into memory.

    In a way it's like citations versus plagiarism - a citation has stated links to its original work and is not presented as an integral part of the present work; plagiarism has no stated links to its original work and is presented as an integral part of the present work.

    From my point of view, this Nexenta hoohaa is something that should be resolved with a template set of exemptions - if linking with such-and-such a library in such-and-such a linkage, such-and-such exemptions apply: it does not violate such-and-such a license to dynamically link from either the upstream or the downstream ... it's what I think should be considered as well in relation to device drivers in Linux and the *BSD and other such Open Source OSes .... I can dream! ;)
  • Anonymous
    November 13, 2005
    I think you are making a mountain out of a molehill. GPLed code has always been able to link to proprietary C libraries. Otherwise you would never see bash or other GPLed programs on a proprietary UNIX.
  • Anonymous
    November 23, 2005
    glibc is LGPL licensed, so that you can easyly make (and distribute) software for Linux under any (most) licenses. You can even link proprietary software to glibc.

    The problem with Nexenta is its Sun libc, licensed under the CDDL. This means you can't (legally) distribute GPL programs linked to Sun's libc.