Unpacking the Significance of LinkedIn's Open Source DisclosureBy http://profile.typepad.com/jeremy23 // January 29, 2011 in Guest Posts, Licensing, My Favorite Risk Factors
Note from Bill: The following is a "re-posting" of a comment Jeremy left on this blog, and posted to his own blog, yesterday. Jeremy is writing about the following risk factor in a registration statement filed Thursday with the SEC in anticipation of LinkedIn's planned IPO:
"[W]e use open source software in our solutions and will use open source software in the future. From time to time, we may face claims against companies that incorporate open source software into their products, claiming ownership of, or demanding release of, the source code, the open source software and/or derivative works that were developed using such software, or otherwise seeking to enforce the terms of the applicable open source license. These claims could also result in litigation, require us to purchase a costly license or require us to devote additional research and development resources to change our solutions, any of which would have a negative effect on our business and operating results."
Let me see if I can do this succinctly (in-joke):
1. What’s the issue with open source?
Chances are that, even if you’re building a proprietary software application, it will include some open source. This will either be a deliberate decision to take advantage of pre-existing, tested, and free (or affordable) code, or a reality that comes from developers choosing to incorporate open source into a product despite corporate policy to the contrary, most likely for reasons of perceived efficiency.
Even then, whether the open source code may cause a problem for your proprietary model will depend on the license terms that apply to the code. While you should always be aware of the license terms that apply, most people confine their concerns to “copyleft” or “hereditary” license terms such as the GPL or L-GPL license terms.
At a very high level, the terms of copyleft or hereditary open source licenses may require you to disclose or distribute source code for other code you “combine” with the open source (including your proprietary code), or license code “combined” with the open source to the general public to enable them to modify it. In other words, you may be required to make public code you would prefer to keep secret.
If you don’t comply with the disclosure and modification licensing requirements of copyleft or hereditary open source license, then your use of the open source code will very possibly be treated as an infringement of the copyrights of the open source owner (or an organization to which they’ve transferred their enforcement rights) – which exposes you to damages claims (i.e., financial liability) and the possibility that you may be forced either to comply with the requirements (i.e., disclose and share your proprietary code), or to remove the open source from your product (i.e., re-engineer, and force your users to upgrade).
2. Why the reference to the miserable associate?**
The GPL licenses have been well-described as software developers’ revenge on intellectual property lawyers for making software the subject of copyright law. While the copyright law works “OK” for software, it isn’t a straightforward or intuitive fit. With the GPL licenses, software developers attempted to re-define copyright law concepts in a way that they believed both met their “free software” goals, and applied copyright law concepts more appropriately to software. The result, and I genuinely will not pick sides on this, is that it is incredibly complex to try to determine how the courts would apply the GPL license terms in determining the point at which a “combination” of GPL software and proprietary code would require disclosure and sharing of the proprietary code. Every time I get a call from a client saying, “Hey! It looks like we’ve included some GPL code in our proprietary product (and we want to release it tomorrow). Is this a problem?” I open up the GPL license terms and am reminded of Robert Falcon Scott’s words on reaching the South Pole – “Great God this is an awful place …”
3. But everyone’s using L-GPL, and plenty of people are using GPL – why can’t we?
This is true, and there are ways in which you can engineer your products so as to “insulate” your proprietary code from copyleft or hereditary software. But you have to do it right, and there will be some element of uncertainty owing to the challenging nature of the license terms for the open source code.
To be fair, this isn’t always the fault of the people who wrote the open source licenses or the lawyers who interpret them. For example, L-GPL is a less restrictive version of GPL designed to apply to libraries. But some developers don’t realize this and, thinking that L-GPL is simply a less restrictive version of GPL, apply it to code that isn’t a library at all. At that stage, you get an already complex license whose application to the technology it’s intended to cover is now incredibly difficult to interpret.
4. Why did LinkedIn disclose this as a risk factor?
My guess is that LinkedIn’s developers have built a significant portion of LinkedIn’s code using copyleft or hereditary code, but may not have sufficiently insulated LinkedIn’s proprietary code, so they may face exposure for infringement claims. “Ideally,” LinkedIn would have had better controls on their inbound licensing processes – but as those experienced with start-ups and early stage tech companies know, controls and processes are not always a priority.
**Refers to this bit of yesterday's comment thread.