A cautionary LGPL tale
I am a big fan of Open Source software; in fact I canâ€™t imagine doing my job without it. Itâ€™s great to be able to benefit from shared code, and life as a programmer has certainly been a lot more fun since Open Source became prevalent.
Most of us have heard Open Source described as "cancer". I don't agree with that, but I do have to admit that source code covered by the GNU licenses (even the LGPL) has to be treated as a highly infectious pathogen.
Stick with me and I will walk you through one of your managementâ€™s nightmaresâ€¦
For a long time, my company has incorporated software from the Apache Software Foundation into our products. We're a not-for-profit entity, but it's still a commercial product. Recently, we've begun evaluating an LGPL licensed product. The first step in that process was to get our legal group to review the license, and that's where the "fun" began.
The LGPL license (as I understand it) was designed to let you use libraries without having to release your own code base. As long as you don't modify an LGPL'ed library (or use any of its source code), you are under no obligations to release your own source code.
Okay, now here is your Legal department's nightmare scenario of what will happen if you're not careful about quarantining LGPL source code...
Assume that your company has adopted an LGPL library. To insure that developers will be able to debug problems, you download the source code to the library and add it to your source code repository. This seems like a reasonable idea; stepping through the source is often the best way to learn how a library really works.
Here comes the problem: If any of your developers (full time or contract) ever copy code from the LGPL'ed source into your own code base, your company will probably be in violation of the LGPL licensing terms
(I say "probably" because I'm not a lawyer, and try as I might I can't understand the nuances of the LGPL).
I earlier suggested that copying ideas from LGPL'ed source might get you in trouble. I was thinking in terms of "clean room reengineering" to avoid infringing on trade secrets. I was wrong: nobody would put a trade secret in freely distributable code.)
Based on my experience with developers, I am willing to bet that many, many lines of LGPL'ed code has made it into proprietary code bases (and visa-versa). By nature we're sponges... if we see a good piece of code we can't help copying it. It's probably genetic.
As a development manager this scenario is particularly scary since you might have to discipline or fire someone who misunderstood that all "Open Source" licensing terms aren't the same.
To be safe (from a legal perspective), you have to treat LGPL'ed code in the same way that you treat any commercial source code that comes into your company. You must control access to the source code, keep a list of who has seen it, and audit your code base to make sure that it doesn't become infected. Think of the "clean room" procedures that companies have to go through when developing products that compete with former partners. Now you may begin to understand how one little LGPL'ed code library can increase your costs (and why managers don't like it).
All this pain and suffering was avoided by my company in the past by sticking to code that is licensed under Apache and BSD style licenses, but that's not an option in this case.
Authors have the right to pick the license for their software; Your responsibility is to fully comply with that license. Insuring compliance can get expensive very quickly.
I imagine that someone will offer the retort: "All your company's software should be GPL'ed." Well... perhaps, but that's not my call.
As expected, this blog has generated a lot of comments.
I always hope that my blog entries get people to think about topics that they may not have previously considered.
In this case it's obvious from the comments that some folks have never considered the problems that others have in getting approval to use LGPL'ed software, and the extra steps they may have to go through if the software is approved.
I think the conversation also demonstrates that some folks don't take their own choice of license as seriously as commercial consumers have to.
Thanks to all who have participated in this conversation. It's helped me clarify my thoughts on this issue.
Apparently the need to address code-mingling has spawned enough interest to launch a few startup companies.
A recent article on updating the GNU licenses pointed me to two companies (Black Duck and Palamida) that are selling â€œautomated solutions for IP risk management and complianceâ€.
It is unfortunate that developers need to be concerned about these issues, but that's the world we live in.
Problems caused by the proliferation of Open Source licenses is closely related to this topic.
"Confusing as hell"
Incompatible licenses among different products prevent people from sharing code from different open-source projects. Having too many licenses complicates potential sales to corporate customers, which may have to do extensive legal reviews and manage multiple kinds of open-source contracts.
"It's confusing as hell to explain to customers," said Michael Olson, CEO of open-source database company Sleepycat Software. "It's confusingâ€¦because we are just wrapping our heads around what (different licenses) mean to us as businesspeople."