Open source software, which not so long ago used to cause IP lawyers major concern and sometimes even minor hysterics, and which is still a significant issue in almost every software-related transaction, has now become almost ho-hum in the context of day-to-day commercial work. However, just because open-source software is no longer a hot-button issue,  doesn’t mean that we can now be complacent about it.

When we first became aware that software developers, bless their efficient little hearts, were using open-source software a lot more often than their managers thought they were (because face it, why would a programmer re-write something that someone else had already written and which was offered for free on the Internet?), we put an express clause into our clients’ development agreements, requiring the developers to warrant  that they would not use any open-source software in the course of development. If they refused, the client would often seek an alternate developer. There was a whiff of self-righteousness in the air; a sort of “we don’t want to work with that sort of developer” (clearly not something that was found in the R&D departments, where lots of people were merrily using open source software under management’s oblivious noses). Over time, the clauses became longer, the definitions more torturous and the requirement less absolute. Now we began to require the developers to warrant that they would be in compliance with any open source software licenses applicable to their software, and that, in essence, their use of open source software wouldn’t adversely impact our client’s codebase, nor put the client at risk of having to disclose any code. We’re still doing this, more or less.

Open source software has become a fact of life. No court that I’m aware of has actually ordered a licensee to disclose its proprietary code because such code has been linked to “viral” or “copyleft” software components. Failure to comply with the conditions of an open-source license has been held to constitute copyright infringement, exposing the recalcitrant company to statutory damages and an injunction against the use of the infringing software, which, while not pleasant, is as far as lawsuits have gone. I still think that two open-source fanatics – an aggressive plaintiff and a sympathetic judge – is all it would take to change this position, but I’m no longer certain this is ever going to happen.

The truth is that use of open source software can still be risky stuff. A major client withdrew from a transaction a few years ago because the target’s open-source governance practices were not rigorous enough and the potential purchaser wasn’t willing to take the risk of tainting its own codebase.  We’re still finding ourselves having to explain to development teams and their managers why the fact that something is freely available on the web does not necessarily mean that it comes with no strings attached. Programmers are probably still using a lot more open-source software than they’ll admit.

So if the risk hasn’t really changed, why are we no longer prone to palpitations whenever we review a target’s response to the open-source section of an IP due diligence questionnaire? To my mind, the answer is a combination of two things. The first is the frog in hot water syndrome (a frog dropped into a boiling pot of water will probably leap right back out again, but a frog placed in a pot of lukewarm water that is then slowly and gradually boiled will most likely cook). In other words, the fact is that we’ve become used to the presence of the risk. The second is the flip-side of the same coin: the fact that no open-source case has been taken all the way to requiring disclosure of code. The longer we go without that particular portion of the sky falling, the less anxious we seem to be getting about it ever really becoming an eventuality.

And maybe the reason is that the programmers are right. Maybe the world has changed and this is just another instance of watching the law playing desperate catch-up with technology. Until the law does catch up, though, I still strongly recommend having in place a robust open-source policy that allows management to keep control of the use of open source, acting in compliance with whatever open-source software is being used in your organization and continuing to insist upon contractual protections vis a vis software developers by way of allocating and mitigating risks.