I recently went through some involved discussions with a client who has traditionally not used open-source software when a library package licensed under the GNU Lesser General Public License (LGPL) seemed to be the best choice for our needs. I kept a number of notes during these conversations and felt it was probably something that should be shared since, no matter how comfortable you are working with open-source licensed software, you probably work with (or for) someone who doesn’t share that comfort. How do you talk to them about using open source software, particularly as part of some product that you are releasing?
While you are reading this, keep in mind some things:
1) The primary focus is on the GNU LGPL since that was the center of our discussions. Some of the topics talked about here may not be similar for other licenses.
2) There are tons of all-inclusive articles about open-source software that cover all of the details of nearly every type of license. This isn’t one of those.
3) I AM NOT A LAWYER! Everything here is based on my limited understanding of the legal dealings and nothing here should be taken as any type of legal advice.
If you have worked in software development for more than 10 years you’ve probably noticed a trend with respect to open source software: it has become integral to the industry. It is very difficult to do any type of work without encountering at least some form of open-source licensed software. If you have bought a television in the last few years, chances are that the User Guide has a page dedicated to the licenses for open-source software used in the television. It truly is that pervasive. Many of us have accepted and embraced this trend while many businesses are still wary of using it.
In the 90s, to most people the term “open sourced” meant a step above total anarchy as far as professional licensing was concerned. The different licenses could be confusing and seemingly a land-mine as far as who owned what intellectual property. While this isn’t necessarily the case anymore, you have to forgive people who know little about open-source licensing beyond the old GNU GPL model where, to the layman, it seemed like if you touched it you had to, by legal contract, give all your possessions away and become a join a tribe of software developing monks in a remote area of east Asia.
So, how do you make someone more comfortable with open-sourced software? Let them know their concerns are real. This isn’t Nam; There are rules. You just have to understand what they are.
Open Source Overview
Since there are a number of different types of open source licenses, many of which may be unfamiliar to many companies, there can sometimes be lots of confusion and understandable concern over whether it is safe to use third party open source software in your own work. To understand what open-source software means to you, it makes sense to understand why open-source software exists in the first place.
The most common reason for releasing software under an open source license is that a commercial or non-profit group is developing commercial software but would like to allow for some pieces of it to be adopted more globally outside of that group. As a result, users get the benefit of using well-tested, professionally developed software and the company receives public collaboration: a wealth of feedback and often publicly published changes to the software that potentially make it better software. Often a company offers the software free but with paid support options. Another potential goal is to gain products for a platform. For example, the open source OS Android, released under the permissive Apache license, encourages adoption of Android-based phones and Google products and services.
An important aspect to some licenses (including LGPL, discussed below) is that users cannot legally change the software without providing those changes back to the owner and/or community. This gives a company the added benefit of having control over what code is actually considered part of that package.
Ordinary GNU General Public License (GPL)
The original Ordinary GNU General Public License (GPL) is nearly always applicable to specific applications (EULA), not libraries, which are modules that an application can utilize but don’t necessarily need to include within the application. On windows these are usually called dynamically linked libraries (or DLLs).
The GPL was intended to make sure that anyone could use the software but not distribute it without distributing the source code for it as well. Basically, any type of end users could use the software. However, to summarize the restrictions, if you used part of their application in your own work, then you were required to release your work under the same license, which means that you also would need to release your source code.
GNU Library/Lesser General Public License (LGPL)
The above “copyleft” license didn’t work for many software libraries because no one who was releasing any type of software commercially or under an alternative license would use them, which was the whole purpose of releasing the libraries. To try to get more developers to adopt open source library usage, the GNU Library General Public License was created. The primary difference was that the licensed library could be linked to and distributed with any software, regardless of whether it is commercial proprietary software or free open source software.
The “Library” was changed to “Lesser” in later versions of the license but the general terms did not change significantly. The name change was made primarily because the original name including “library” led people to believe that LGPL should be used for libraries and GPL should be used for programs, which was not the case; It is possible to release libraries under the ordinary GPL.
In summary the LGPL states that any non-derivative work can be released under any terms or licenses; Basically that means releasing software that simply uses a LGPL library. A derivative work would be one that makes changes to the source, creating a different work than the originally licensed work. In the case of derivative works, you would be forced to share the source for debugging/inspection purposes. A standalone executable that “dynamically links” to a library through a .so, .dll, or similar medium is generally accepted as not being a derivative work as defined by the LGPL.
Remember, LGPL software makers don’t have the intention of dictating how you, as a user of their software, should release your product.
The goal of the LGPL is to allow for using their software “freely” without being restrictive of how it is used. Remember, LGPL software makers don’t have the intention of dictating how you, as a user of their software, should release your product. The restrictions of including unedited LGPL software in your product are fairly simple and can be (somewhat over-simplistically) summarized as: make sure you note the LGPL software you are using, include the license of the LGPL software, and make sure anyone that can use your product has access to the software.
(*Yes, that’s this is very simplified and you need to actually read and understand the license before going nuts with it but if you follow this basic guideline, you will be fine.)
The first version of the Lesser GPL was 2.1 (in 1999), which contained no significant differences from the Library GPL.
There is a family of permissive free software licenses, which generally allow the user of the software the freedom to use the software for any purpose, to distribute it, to modify it, and to distribute modified versions of the software, under the terms of the license, without concern for royalties. Usually the only restriction is something along the lines of inclusion of copyright information, license, or usage disclaimer for the used software. The most common are MIT, BSD, MPL, Apache, and any software declared in the public domain.
LPGL is in the family of permissive licenses with the primary exception that the source of the library cannot be modified, without also releasing those modifications under the LGPL.
Standard Practice Use of OSS
Inclusion of LGPL code deemed to be of reputable quality is a standard business practice in software engineering today. For example, see Apple complying with LGPL requirements for millions of lines of open source code shipped as part of their iOS operating system:
One common method of ensuring third party software licensing is correctly applied is to maintain a single text file with the licenses for all third party software used.
While the question of ownership is slightly more tricky in the realm of open source software, this is not an issue exclusive to open source software. The potential exists for ownership rights questions in commercially licensed software as well and carries similar potential for litigation. It is important when selecting any open source package to ensure that it is a well-known, reputable package that has a well-known and documented history of ownership or source custodianship (in the case of multiple contributors, which is common in open source communities).
As I stated in the beginning of the article, if someone is concerned about using open-source software, don’t pretend that their concerns aren’t valid. Licensing is a legal issue and any legal issue is something that should be heavily considered when making development decisions. Hopefully this article helps clear up some of the more often-expressed concerns for people not comfortable with open-source software, specifically the LGPL, and makes the decision to use it a little easier.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.