4 ms·

The LGPL addresses these concerns, and is in the sweet spot, I think: You can use the library without opening the code using the library, but any changes to the

by dima55 14y ago

The LGPL addresses these concerns, and is in the sweet spot, I think: You can use the library without opening the code using the library, but any changes to the library itself must be given back.

afsina 14y ago
Actually MPL or CDDL are like that. I am not an expert but I think they are easier to re-distiribute than LGPL.
saurik 14y ago
It is very easy to work around the LGPL: the main thing it ends up protecting the user from is not being able to modify the exact functionality provided by the LGPL library inside of the surrounding software system. As a case example: Apple has modifications to their version of WebCore (lower-level than WebKit, for context), a project shipped under LGPL (unlike WebKit, which is distributed under a modified BSD license). However, they don't want to have to give out those changes, so they provide the source code to a WebKit with some minimal changes to call into new code that they then don't provide: it will compile, but you will get link errors. Understand: this new code may be critical to the functionality of the library, and may be modifying the behavior of or even outright replacing key APIs and mechanisms of the LGPL library, in this case WebKit. They then provide binary object files for the new functionality that they added, and the result is compiled together to form the unified WebCore dynamic library. Even though the result is a single linked-together library, this is totally legal under the LGPL, as I can still modify the original WebKit code if I wish and still manage to build Apple's modified WebKit binary. In essence, the boundary around the LGPL code can be made very tight indeed, such that even code that is semantically required for the library to function does not fall under the redistribution requirements of the GPL part of the LGPL code.
- saurik 14y ago
  (Every usage of "WebKit" in this comment that was not "lower-level than WebKit" and "unlike WebKit" should have been "WebCore". I wish I had noticed that mistake earlier. ;P)

by dima55 14y ago

The LGPL addresses these concerns, and is in the sweet spot, I think: You can use the library without opening the code using the library, but any changes to the library itself must be given back.

afsina 14y ago

Actually MPL or CDDL are like that. I am not an expert but I think they are easier to re-distiribute than LGPL.

saurik 14y ago

It is very easy to work around the LGPL: the main thing it ends up protecting the user from is not being able to modify the exact functionality provided by the LGPL library inside of the surrounding software system. As a case example: Apple has modifications to their version of WebCore (lower-level than WebKit, for context), a project shipped under LGPL (unlike WebKit, which is distributed under a modified BSD license). However, they don't want to have to give out those changes, so they provide the source code to a WebKit with some minimal changes to call into new code that they then don't provide: it will compile, but you will get link errors. Understand: this new code may be critical to the functionality of the library, and may be modifying the behavior of or even outright replacing key APIs and mechanisms of the LGPL library, in this case WebKit. They then provide binary object files for the new functionality that they added, and the result is compiled together to form the unified WebCore dynamic library. Even though the result is a single linked-together library, this is totally legal under the LGPL, as I can still modify the original WebKit code if I wish and still manage to build Apple's modified WebKit binary. In essence, the boundary around the LGPL code can be made very tight indeed, such that even code that is semantically required for the library to function does not fall under the redistribution requirements of the GPL part of the LGPL code.

saurik 14y ago
(Every usage of "WebKit" in this comment that was not "lower-level than WebKit" and "unlike WebKit" should have been "WebCore". I wish I had noticed that mistake earlier. ;P)