The company I am working on is heading for the annual audit process. Apart from the security and compliance issues that the internal auditor needs to find, the auditors will find whether we have unlicensed and underlicensed applications. Underlicense situation will rise if the current licenses we have do not adequately cover all the software installation or deployment.
In our discussion, we come across several licensing schemes and surprisingly nobody has a clear understanding about them. Two most prominent licensing schemes: GPL (General Public License) and LGPL (Lesser GPL) seems to confuse many as they look similar but actually are very different.
The GPL license allows free use and modification of the software, as long as we credited back to the original author and release the application (that utilizes the GPL'ed software) as open source. This is a major road block for commercial project to use GPL'ed software.
On the other hand, the LGPL license does not require the application to be distributed as open source and thus can be used in a commercial application. This licensing is increasingly popular among software libraries. However, there is an extra complication: any modification or addition (and even wrapper) to the LGPL'ed library must also be released under LGPL/GPL scheme. Other parts of the software which do not use the library are not affected and therefore can be released under any licensing scheme. Therefore, in practice, if we create a wrapper class of the LGPL'ed library, or create a class that inherits from the library, then our library code must be released under LGPL scheme. In the .NET project, as a class library is compiled into an assembly, then the assembly and its source code must be released under LGPL. Not a pretty situation for a commercial project!
In summary, whenever your software project needs to use a third-party library/application, make sure you understand its licensing very well and judge carefully whether it fits with the licensing of your software.
Subscribe to:
Post Comments (Atom)
1 comment:
Hi,
your point, that "if we create a wrapper class of the LGPL'ed library, or create a class that inherits from the library, then our library code must be released under LGPL scheme." IS obviously WRONG: http://www.gnu.org/licenses/lgpl-java.html
"The only difference between Java and C from the LGPL's perspective is that Java is an object-oriented language, supporting inheritance. The LGPL contains no special provisions for inheritance, because none are needed. Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls."
Post a Comment