-
-> Not necessarily. Simply understand the licenses and their implications.
-
-That's one problem. The licence is long and complicated. I cannot feel
-confident that I understand the terms in either the same sense that the creator
-of the software intended (and that's important to me), or in the same way that
-a court would interpret it. Under the circumstances I tend to avoid even LGPL
-because, even if /I/ am satisfied that some use is OK, I cannot be sure that
-the users of my libraries will see it the same way.
-
-The confusion in this thread, and in others like it I've seen, makes it clear
-that many intelligent people simply do not understand the LGPL. Under the
-circumstances I am suspicious of (a) my own understanding, (b) the
-understanding of any other programmer or non-legal expert.
I understand where you're coming from. A long time ago I took the time to
understand the intent behind the licenses. It goes a long way to clarifying
its terms.
Stallman et. al. gave specificity, and therefore complexity, because if they
were not specific, then someone would try to exploit the code under the license
in some loophole or another. There's a guy who now lives in gnu.misc.discuss
that states that basically all the terms are null and void under the U.S
copyright first sale doctrine.
In its basic form the LGPL is pretty simple:
1) Any one can use LGPL code unchanged.
2) You code can be combined with LGPL code and binaries only distributed as
long as you don't make modifications to the LGPL code AND you give the
end users you distribute to a way to change/update the LGPL code. No
license terms are applied to your code or to the resulting binaries
other than the end users right to change/update the LGPL code.
3) Any changes or additions to the LGPL code itself are subject to the LGPL
even if you wrote them. So changes to the library itself must be distributed.
-> Dynamic linking makes
-> this requirement easy as the end user can simply load the new dynamic
-> library. But static linking doesn't comtaminate anything. You can in fact
-> offer the end user a compiled object to link in, never showing the end
-> user your code. But relinking is a requirement for you as a developer to
-> use the library.
-
-You see ? I hadn't read that into the license. Unless and until it is
-rephrased in a way that makes it plain /in a technology independent way/ what
-constitutes linking, then I shall continue to treat it with suspicion.
Don't think about linking. Linking is the action and it isn't important. Look
at the intent. A binary consists of some LGPL code (a library) and some non
LGPL code (say a proprietary application). Independant of mechanism (linking)
the end use of the binary must be able to update the LGPL library to create a
new binary.
There's no point in trying to enumerate the 50 million ways this can be
implemented. Just give the user a way to update the library and the clause is
satisfied.
One failure point is in embedded systems where the combination occurs via
compilation. Then the only way to implement updates is by giving the end user
the code, even though the code may not in fact be subject to the LGPL.
- It's
-worth mentioning that quite a few libraries I've been looking at recently have
-come with a license that is the LGPL plus some explicit riders to make it clear
-that (say) static linking is allowed.
Static linking was never disallowed. What you saw was a dismissal of the relink
requirement associated with static linking. But it potentially hurts the end user
because if the LGPL library, which is supposed to be free (in the freedom) sense
was ever significantly improved, users subject to the exception now have no recourse
if they wanted to update the library, because the proprietary developers of the
applications code are not subject to help end users updating by providing them
with the application in an updatable form.
Every clause in the GPL and LGPL has a purpose. CSS developers get annoyed with
them because they inhibit the wholesale incorporation of "free" code into their
stuff just like the original poster thought he could do.
The funny thing is that the average user could really care less. Simply drop an
object file on the CD (or put it on a passworded web site) and be done. Nothing
says the end user has to actually ever update anything, but the license gives
them the right to do so.
-
-And it's important that the wording is technology independent. I mostly work
-in Smalltalk and Java these days, and while there are certainly some cases
-where a use of some code is clearly dynamic linking under the terms of the
-LGPL, there are other cases that are less clear. This particularly applies to
-software that is not written in a DLL-ish language (such as C -- and neither
-Smalltalk or Java are DLL-ish), but also can apply to 'C'. E.g. I was looking
-at one library, LGPLed, that is coded only to support static linking. So I can
-write a DLL that uses that library, and then call that from Smalltalk, that's
-not a problem technically, but I simply don't know to what extent the DLL is
-now covered by the LGPL.
The DLL has to be updatable with the library. So send an linkable object of
the DLL (or the source) along with every distributed copy.
Simply answer the question of how to change:
application (which calls) DLL (which calls) old LGPL library... to
application (which calls) DLL (which calls) new LGPL library.
Note the application doesn't have to change and isn't subject to the license.
The DLL must be able to be updated with the new library, in whatever form
facilitates it. dynamic linking is a done deal, static linking can be done too
by sending something for the DLL that's linkable to the new library. Send the
source for the DLL to solve the problem.
You want mechanism. But there can be new ways for the DLL and the library to
interact that folks haven't implemented yet. As long as there is a way to
substitute the new LGPL library for the old one, then any method suffices.
Like I said, it's easier to understand when you understand the intent of
clause (the LGPL library must be updatable) as opposed to the mechanism
(static or dynamic linking and the like).
- I don't greatly mind if it is (my stuff is free, as
-in beer, anyway) but I don't the hassle of, say, finding that I have to
-distribute the source to the original library (not least because I don't like
-becoming a secondary source of potentially out-of-date information).
You only have to distribute the original LGPL library source if and only if you
change it. Otherwise a simple pointer to where someone can get it will suffice.
However if you change the library itself, then that code must be distributed
so that downstream users and developers can work on it. Intentwise it means
that while your applications code can belong to you, the LGPL library code
belongs to the whole community, so if you must change the community code, then
you have to share it.
I too find the relink requirement problematic especially for embedded stuff BTW.
Lately I've been looking at the wxWindows Library Licence for embedded stuff.
It is essentially the LGPL with some modifications for the relink issue.
http://www.opensource.org/licenses/wxwindows.php
BAJ
