Mar 2

When most people think about the LGPL 2.1 license, they focus on the requirement to redistribute any changes they make to the library and the ability to safely use the LGPL 2.1 licensed library within commercial products as long as the library is clearly separated from the proprietary code.

What is sometimes overlooked is the obligation to allow the replacement of the LGPL 2.1 library. Section 6 of the LGPL 2.1 license describes the obligations if you distribute a commercial product containing an LGPL 2.1 library. This has several implications on the commercial license and the packaging of the product. Depending on your software and hardware architecture this may be an easy obligation to meet or a difficult one.

In the case of Java, the class files of an LGPL 2.1 library can be dynamically linked when the application starts, making it easy to replace the LGPL 2.1 library. As long as the user knows where the library is located and the Java code is not packaged in an “obfuscated” manner, the library can be easily replaced. The user must be allowed to debug and make work any such changes and this may require changes to your commercial license if it has a “no reverse engineering clause”.

Things get a bit trickier if you’re using an LGPL 2.1 package in software embedded in a device. Since the license requires that a mechanism must be provided to allow the library to be replaced, you will likely need to provide some mechanism for replacing the firmware on the device with a version of the firmware containing a replaced LGPL 2.1 library.

Perhaps the most challenging situation is when the LGPL 2.1 libraries are used in security sensitive code. There are over 100 encryption software packages on Source Forge offered under LGPL 2.1 or LGPL 3.0. If such software can be replaced, how do you ensure security of the software? Complying with this license obligation will now require the user to be rather careful and sophisticated to not accidently open up a security hole when replacing such sensitive libraries. While many users may be able to maintain or even enhance the security of the product with this capability, opening it up to all users could create a security problem. If your software is used to protect other software or media you may have obligations to maintain a level of security not practical with the requirements of this obligation.

In all cases, the supportability of the software must be considered. If the user replaces a library, what does that mean to the support you provide to your customers? This will likely have impact on your support terms and support processes.

Net, the LGPL 2.1 obligation to allow the user to replace the library is sometimes a challenging obligation to meet. This is another item to consider in setting the policy for the open source licenses that your organization will allow inside your commercially licensed software.


Nov 16
This is a list of the top 15 open source licenses as seen in Source Auditor. Each link leads to the license text for that license.  This is useful in generating your policy as to which open source licenses are acceptable to your organization, and which open source licenses are not.  We will periodically update this list and add more licenses.

GNU General Public License (GPL) 2.0

GNU Lesser General Public License (LGPL) 2.1

Artistic License (Perl)

BSD License 2.0

GNU General Public License (GPL) 3.0

Apache License 2.0

MIT License

Mozilla Public License (MPL) 1.1

Common Public License (CPL)

zlib/libpng License

Eclipse Public License (EPL)

Python Software Foundation License

Apache License 1.1

PHP License Version 3.0

Open Software License (OSL)