...
- Binary Code License (BCL)
- Special exceptions to the GNU GPL (e.g. GNU Classpath)
- GNU General Public License (GPL)
- GNU "Lesser" General Public License (LGPL) (see section below on "Special Considerations for LGPL")
- GNU Affero General Public License (AGPL) v3
- Netscape Public License (NPL) 1.0 / Netscape Public License (NPL) 1.1
- Q Public License (QPL) 1.0
- Sleepycat License
- Microsoft Limited Public License (Ms-LPL)
...
See the Creative Commons Public Domain Tools area for more information about best practices for placing intellectual property into the Public Domain.
Special Considerations for LGPL
There is a difference between including things with the source code distribution of a project and with various binary distributions of a project. Our primary concern is the licensing of the source code distribution. As long as we are not including any Category X (including GPL or LGPL) code with the source code distributions, then we are achieving our primary goal.
It is also good to keep binary distributions as clean as we can from a licensing standpoint. But a bit more latitude around common things that are LGPL is reasonable and we should still be able to distribute the entire binary distribution under the Apache license in those circumstances. Including GPL is another story – inclusion of any GPL code, even unmodified binaries, would mean the entire binary distribution would have to be done under the GPL. This would still be okay, but it would have to be clear that this binary distribution is under more restrictive licensing than normal for Jasig.
There has historically been some confusion/disagreement as to how LGPLv2 works in Java applications. Specifically as to whether Java libraries packaged as jar files that are licensed under the LGPL and are then included with larger application will create a "derivative work" and cause the copyleft aspects of LGPL to kick in. Since Java isn't technically "linking" in quite the way the LGPL discusses, some camps have believed that the LGPL and GPL are actually identical when it comes to Java. In fact, the Apache Foundation specifically stays away from LGPL code because of this concern, as you can see in some old mailing list discussions here and here, and that position is still present in their licensing policies and is why it is on their Category X list and also on ours. LGPLv3 is considered somewhat clearer on this matter, although the issues are still largely the same.
The Free Software Foundation (the author and maintainer of the GPL and LGPL) has generally been quite clear that they believe the LGPL works as intended with Java and that we should not be concerned about this. See their article The LGPL and Java for details.
All this being said, we think it's okay (but not desirable) to include LGPL libraries in binary distributions, as long as we avoid pulling them into the original source code distributions.
Another interesting side note about GPL and LGPL projects is that even though they are distributed with a specific version of the license, many of them allow consumption under any later version of the license. So some GPLv2 and LGPLv2 licensed projects can actually be consumed under GPLv3 and LGPLv3. You have to check the source code headers to see what they say about the version of GPL/LGPL that applies to the code.