About the LGPL
NOTE: Prior to the release of version 1.9, the licensing terms for Teem changed from the LGPL, to LGPL plus exceptions which facilitate static linking (following FLTK's example). This changes addresses legitimate concerns about the practicality of using LGPL's code in binary-only applications. Specifically, Section 6 of the LGPL no longer applies to binary works linking with Teem. The licensing changes also renders moot many of the technical details of the write-up below (especially point #4), which I originally wrote in an effort to allay common fears and misconceptions about the LGPL.
It is also interesting to note, however, that while the text of the GPL and LGPL assert that linking with the library creates a derived work, some legal experts believe that linking creates a compilation, in the copyright sense, and not a derived work. This has implications for how people who normally resist reciprocal licenses like LGPL should understand their scope. Lawrence Rosen's Open Source Licensing covers this issue in Chapters 6 and 12
My software, Teem, is released under the GNU Lesser General Public License ("LGPL"), for a variety of reasons. Most importantly, this license best implements to the notion of "share and share alike" which is fundamental to academic research. Also, because the development of this software was largely funded by the tax paying American public, I feel obligated to prevent situations where my software is used but can not be inspected, understood, or altered at the level of source code.
It is important to understand the difference between the LGPL and the GNU General Public License ("GPL"). Some people dismiss all GNU licenses as "viral", which is both unfortunate and false. The most important difference between GPL and LGPL is that if your software uses Teem, you are in no way required to release the source for your software. However, because my software is not in the public domain, or under a "BSD-Style" free license, there are certain requirements. See this page for clarification on the different kinds of licenses. Keep in mind, however, that the LGPL-related requirements kick in only when you start distributing your software outside of your school, lab, or company.
After reading through the LGPL very carefully, I wrote up the following description of it, and the (minimal) responsibilities you have if you release software which uses Teem. Others have found it helpful because it clarifies whether or not the LGPL makes a distinction between static versus dynamic linking (the answer is no, and yes). Also, it enumerates exactly what you'd need to do if you release software that uses Teem (not much). Please read on.
The notion of a "derived work" is central to copyright law, because copyright concerns itself not just with a work, but with anything which is a modified version of the original work, or a translated version of the work, or which is (or contains) a significant portion of the work, and so on.
If you link my library with your program, the resulting binary is derived from my library (in the copyright sense) because the binary contains translated portions of my code. The GNU licenses make no distinction between static and dynamic linking insofar as the definition of a derived work, as applied to compiled software, is concerned. From the Preamble of the LGPL: "When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library."
One reason that the LGPL is a longer and more complicated document than the GPL is that the LGPL makes a distinction between different kinds of derived works, which the GPL does not make. Section 2(b) of the GPL applies to any derived work that you distribute or publish, requiring that the derived work be licensed under the GPL. Read the GPL for exactly what that entails; it involves distribution of your program's source code. The LGPL also says that it applies to all derived works. But the basic thing to understand is that how the LGPL applies in fact depends on the nature of the derived work:
The important distinction here is that those responsibilities, which I'll describe below, amount to something less than the full LGPL. Those responsibilities are mandated and defined by the LGPL (since the LGPL governs the distribution of any derived work), but they are not the same as the LGPL. Most confusion about the LGPL revolves around this basic property: Section 6 of the LGPL constrains (mildly) how you distribute compiled software using a LGPL'd library, but because those constraints are not the same as the LGPL, the LGPL does not propagate itself in the same way that the GPL does. This is in contrast to what is required when the derived work involves modification of my source, in which case the full LGPL does apply. However, if you have found bugs or API deficiencies in my software, please tell me, so that everyone can benefit. Since this software is how I do research, I'll be supporting it for quite a while.
So, if you distribute a program that links against Teem, without modifying Teem, Section 6 of the LGPL requires you to do four things:
Copyright (C) 2005 Gordon Kindlmann Copyright (C) 2004, 2003, 2002, 2001, 2000, 1999, 1998 University of Utah
I feel that the four points of compliance, described above, are clear, fair, and very easy to deal with, especially if you take the shared library route. Also, if you've read this far, please help by clearing up misunderstandings about the LGPL when you encounter them.