Linked by Thom Holwerda on Fri 13th Mar 2009 08:28 UTC
GNU, GPL, Open Source The whole FAT licensing saga between Microsoft and TomTom just got a whole lot more complicated. Microsoft sued TomTom because the satnav maker had not licensed FAT from Microsoft, even though several others have. This left TomTom in a difficult position: not license it, and face legal penalties - license it, and violate the GPL. The second part, however, is up for debate now: the terms under which Microsoft licenses FAT may not violate the GPL at all. Near-instant update: On Slashdot, Bruce Perens and Jeremy Allison have explained that the FAT terms are still a GPL violation. Allison accidentally emailed the journalist who wrote this story with the wrong information.
Thread beginning with comment 353070
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: GPL - go read it
by PowerMacX on Fri 13th Mar 2009 14:52 UTC in reply to "RE[3]: GPL - go read it"
PowerMacX
Member since:
2005-11-06

In a software authorship sense, a "derivative work" is one that contains a copy of someone else's original work. In a software sense, statically linking to a library actually includes a copy of the library in the new work, does it not? So to get permission to do that the original library would have to be licensed LGPL


As far as I know, you *can't* statically link an LGPL library without releasing your own software under the same license, you can only do that if you link dynamically. OTOH, in the case of a GPL library, as opposed to LGPL, you can't link at all unless your software is released as GPL too.

I think the static vs. dynamic is an artificial distinction and that no library should actually be released as LGPL: either select GPL, that forces everyone to adopt your license or release it under a BSD/MIT license that gives developers the freedom to link however they prefer and later release using their favorite license.

Reply Parent Score: 2

RE[5]: GPL - go read it
by Lennie on Sun 15th Mar 2009 13:15 in reply to "RE[4]: GPL - go read it"
Lennie Member since:
2007-09-22

Are you kidding me ?

LGPL is really very useful.

For example glibc, do you think Oracle would have ported their database-system to Linux if glibc was GPL ?

Actually I think a lot of developers that create libraries actually might relicense there library as LGPL, if the difference is properly explained to them.

Reply Parent Score: 1

RE[5]: GPL - go read it
by lemur2 on Sun 15th Mar 2009 23:42 in reply to "RE[4]: GPL - go read it"
lemur2 Member since:
2007-02-17

"In a software authorship sense, a "derivative work" is one that contains a copy of someone else's original work. In a software sense, statically linking to a library actually includes a copy of the library in the new work, does it not? So to get permission to do that the original library would have to be licensed LGPL
As far as I know, you *can't* statically link an LGPL library without releasing your own software under the same license, you can only do that if you link dynamically. OTOH, in the case of a GPL library, as opposed to LGPL, you can't link at all unless your software is released as GPL too. I think the static vs. dynamic is an artificial distinction and that no library should actually be released as LGPL: either select GPL, that forces everyone to adopt your license or release it under a BSD/MIT license that gives developers the freedom to link however they prefer and later release using their favorite license. "

Static linking and dynamic linking are quite different. With the former, you actually include a copy of the linked library inside your own work. This unquestionably makes static linking fall well within the definition of "derived work" as it is used within copyright law.

Dynamic linking is more vague. Altohough your calling program doesn't physically include within itself the functions that are encoded within the linked library, nevertheless your program does include that functionality. That is the tricky bit.

I cannot say for certain (IANAL), but I think there is a possibility that the GPL/LGPL situation is "one level more permissive" than what you imagine. I think it is fine for closed source programs to run on a system that has a GPL OS ... and that that is, will always be, and always was the intention of the GPL. A closed source program running under a GPL OS can dynamically link to GPL libraries without violating the GPL license.

The closed source program may not INCLUDE any GPL libraries, however. That amounts to re-distributing a derived work of GPL code. The GPL says that in order to do that the source code must be made available.

This problem is, AFAIK, the entire reason for the LGPL. In many cases, staic linking of a library avoids some problems that dynamic linking can create. In order to allow static linking of a library, a specific exception for doing just that was added to the GPL to create a new, related, slightly more permissive license called the LGPL.

So, AFAIK, I think the situation is as follows: a closed-source program may dynamically link to un-modified GPL code, and it may in addition statically or dynamically link to un-modified LGPL libraries, without violating the GPL/LGPL license conditions.

PS- Obligatory supporting link here:
http://answers.google.com/answers/threadview/id/439136.html

"Q2a: What is the implication of static linking?
A2a: You need to comply with the license requirements. Eban Moglen in
http://www.spinics.net/lists/xf/msg02311.html
indicates that you are producing a "derivative work" of the code in the library. In the United States the US Copyright Office states at
http://www.copyright.gov/circs/circ14.html
A ?derivative work,? that is, a work that is based on (or derived from) one or more already existing works ... [copyright statements]. Both of those statements are pretty clear so section 6 of the LGPL applies. Note that you can distribute (6a) ... [your work] as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. You can thus distribute object files (and protect your source code) and still comply with the requirements of the LGPL.

However, others (in particular, Richard Stallman) does not necessarily interpret the LGPL in this way. I strongly recommend you contact the copyright holder prior to building a statically linked application for
distribution as a commercial product."


Eban Moglen is a (highly qualified) lawyer, whereas Richard Stallman is not.

Nevertheless, there is unquestionably some considerable uncertainty over this topic.

Edited 2009-03-15 23:58 UTC

Reply Parent Score: 2