Raise your hand if you’ve ever been involved in a contentious intellectual property dispute. (Ok, put your hand down, this is a blog, and I can’t see you.) I asked a room full of developers this question last year, and I saw that about 5-10% of the people in the room raised a hand. My next question was, “Ok, those of you who raised your hand, keep them raised if you enjoyed the experience.” Of course, this question was a setup, no one’s hand was in the air. These developers and I share an experience -- we’ve had to go through the arduous task of dissecting years of commit history and IP clearance to support litigation. This experience is becoming more and more common (and complex) as many companies start to use open source software without understanding the ramifications of certain licenses.
As someone who has been through the process of supporting litigation I want to share my experience so that you understand what could happen when your organization incorporates OSS components under the wrong license or deals with code of questionable provenance. I’m writing this blog entry to convey the experience of being a developer who has to support litigation - it isn’t fun or productive, and it usually something that is completely avoidable.
The (avoidable) issue
Let me tell you why the experience is awful. First, if you are reading this blog it is because you enjoy writing code and learning about new technology. You probably don’t enjoy sitting in a room with a lawyer and trying to explain how open source works. Every time I try to explain what open source is to a technical “layperson” I end up sounding like a naive idealist because, let’s just admit it, the idea of open source software sounds crazy to people that are not participating in the culture and economy it creates.
You probably don’t enjoy having to walk through every single email you’ve sent and received over the past 24 months in a room without air conditioning in downtown Chicago with a lawyer who doesn’t understand technical terms. This was my experience. Printing out a two foot tall stack of company email and walking through each message in detail: “Tim, what did you mean when you said, ‘we don’t need that code, we can just use commons-beanutils’? Were you saying his code was full of bugs? Also, what is ‘commons’?” If you are lucky enough to be selected, you’ll have to sit for a long deposition that focuses on who checked in what code where, and what constitutes an open source contribution. Meetings like this consumed a month of my time, and this was all because the company I worked for didn’t require explicit guarantees on code provenance and IP assignment.
It was a mess, but it didn’t have to be that way. Instead of just leaving open source component selection up to contractors and development partners, the company could have taken a proactive approach to open source governance. If they started that same project today, I’d insist that they use a tool like Sonatype Insight and generate a constant stream of reports that would identify newly incorporated open source licenses. If the company I had been working with almost ten years ago had had a similar tool they would have saved themselves a few hundred thousands dollars in lawyer’s fees, and they would have saved me a substantial amount of wasted time and effort.
The outcome
The company entered into a joint development contract with a subcontractor. The company entered into other agreements with additional partners and the subcontractor wasn’t happy with the arrangement. A wide-ranging lawsuit ensued that involved exploring the boundaries between open source contribution and the provenance of code in a currently shipping product. The question was whether our partner’s consumption of a GPL-licensed OSS component infected the larger work with a copyleft license. I had visibility into a part of the process that involved open source contribution - specifically what code was covered under what license and what code was distributed to whom when. Because of this, I was the one having to give depositions and communicate with the subcontractors.
In my case, the company I worked for had a crack team of expert lawyers and all the patience in the world to go through a very long process. Other companies don’t have that sort of luxury, and the only reason why my company ended up prevailing was because we had prepared ourselves. We could have saved a lot of time if we had been able to produce a bill of materials that included the license type of every included component.
The takeaway
It would have saved that company hundreds of thousands of dollars, and (more importantly) months of lost opportunity if they had used a tool like Sonatype Insight. Insight identifies the licenses of included components during development so that you don’t have to clean up after the fact. In the years since my own experience with the legal system, this issue has only become more complex and more pervasive. If you are using open source, you need to keep track of what’s going into your software.
