LGPL and the obligation to replace the library


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.
Top 15 Open Source Licenses (in Source Auditor)


GNU General Public License (GPL) 2.0
GNU Lesser General Public License (LGPL) 2.1
GNU General Public License (GPL) 3.0
Mozilla Public License (MPL) 1.1