Open Source has been in turn hailed as a panacea and denounced as a scourge (remember Steve Ballmer’s “cancer” outburst). It is neither. Nor is it a monolithic concept one can fit in a box. As many already know, Open Source is both a community based software development model (as contrasted with “proprietary” models) AND a software licensing model. As such, it means very different things whether you’re an engineer, a business owner or a lawyer.

Engineers like using Open Source for the very simple reason that it saves them time and money when developing or testing a product. Who wouldn’t want that? They also like the fact that the community –not them- is maintaining the code and fixing bugs. Nobody likes fixing bugs. Let the other guy do it!  Business owners are more pragmatic; if it saves money and gets the product out the door faster with no apparent downsides, they’re all for it. They just don’t want trouble later on. Enter the lawyers!

Whether you belong to the IT or biotech industry, it’s almost impossible to build a product or conduct R&D without coming across a certain amount of open source software (“OSS”). This phenomenon has been accelerated by the fact that most OSS components are free of charge and that they are readily available off the web. The problem is, because people are used to treating OSS as one big label, they think all OSS items bear the same price tag. Nothing could be further from the truth. By the latest account, there are close to 2000 different open source software licenses (either self proclaimed or certified) in circulation. Now, would you expect each of them to carry exactly the same terms and conditions? Of course not! Nor would you shop at Best Buy and assume –solely because they all come from the same store- that all items for sale carry the same price, have the same warranties and disclaimers and must be used in a similar fashion.

What this means is that each OSS component has to be looked at and analyzed individually before one can reasonably determine the implication of its use in a given product . Of course, there are common families of licenses that have emerged over time (e.g. ‘copyleft’, BSD and Mozilla types) that makes this assessment a little easier in some cases. But there is still no substitute for going through the analysis each time, the same way you have to understand the conditions and limitations of each component when procuring commercial software.

So, you ask yourself, what could go so wrong? Well, in fact, many things if you’re not careful or don’t know what you’re getting yourself into. First, regardless of the license agreement that an OSS component may be subject to, one thing you’ll almost never find in there are representations and warranties backing the software. In other words, if all hell breaks loose, the OSS component is corrupted by some virus or malware and wipes yours and all your clients’ data, you’re on your own. That is one of the downside of community based software; nobody is responsible. There is no support, no SLA, etc. Or say, you get a nasty letter from someone’s lawyer stating your use of that OSS component –now well integrated into your code- infringes upon their patent, nobody has your back, period. And you can’t sue the community at large. It’s like declining to buy insurance: in reality the software may be of excellent quality and you’ll never have those problems, but you have to factor that in your cost/benefit analysis when running a business.

A related problem is that you don’t really know who wrote the code. That is often referred to as the “pedigree” issue. Since most people like OSS because they don’t have to write the code themselves, you’re bound to have someone at some point contributing code that they didn’t write or that they wrote on their employer’s time and dime, which comes down to the same point. Then it gets merged with other code and repackaged under some OSS license. Think of this as the sub prime mortgage derivatives of the software world! You may inherit code that the real author has never meant to license or didn’t have the right to.

If you think that is bad enough to give you pause, it can get really ugly is when the license contains some ‘copyleft’ provisions (e.g. GPL family of licenses). In those cases, by design on the part of the crafters of those licenses who don’t want you to profit commercially from their sweat of the brow, you may end up subjecting your modifications or, worse, your entire product to the terms and conditions of such ‘copyleft’ license. This means you may be legally obligated to reveal the totality of your source code, for free, to the rest of the world… The extent to which this may apply will vary depending on how the component is used in (or called by) your product, whether you made modifications or whether you distribute the component or not along with your code. You’re and ASP providing services in the cloud? There are even some licenses (e.g. Affero GPL) that will trigger the ‘copyleft’ effect in hosting scenarios.Just picture the impact on your business model. Not to mention your company’s valuation. That might be a quick exit, but not the one you had in mind!

So let’s be honest there: these are real issues, not lawyers’ concoctions or anti open source activists’ talking points. Our firm recently conducted an OSS audit for a small, yet sophisticated software company. Based on their initial response to our questionnaire, we were expecting to find at most a handful of OSS components in their code. It turned out there where hundreds! Most  of them unbeknownst to the senior management! Imagine having this comes up during a funding round due diligence…

Based on our own experience in several M&A transactions and as reported from time to time in the press, many a deals where a small company was to be acquired fell through or the tag price revised significantly (downward) after the due diligence revealed some open source dependencies. Any potential investor or acquirer worth their salt will ask you about OSS. Even clients that take in your product will request that you warrant your software being free of OSS (or at least of the ‘copyleft’ type), as they don’t want to contaminate their product downstream. There are also tools out there used in IP due diligence that will find any string of code that comes from the Open Source community, whether the license and even the header files have been tampered with.

Does this mean you should stay away from OSS? Not at all. As I’ve seen quoted once, “Open Source is not to be feared, but to be managed”. There are great OSS tools and libraries out there that are virtually risk free, as long as you don’t look for a warranty. It is important however to really understand the underlying limitations and weigh the short term benefits against the potential long term consequences of using some OSS components.  And you can’t unfortunately substitute for the legal analysis of the relevant license(s).

Below are 10 tips* to keep in mind when approaching and dealing with Open Source. If you’d like to know more about an OSS training and audit for your own business, please contact us.

1. Understand the Different Approaches That the Open Source Licenses Take. It is important not to think about the Open Source licenses in monolithic terms.
2. Pay Special Attention to the General Public License. If you choose only one thing to have policies about and require special review of, it should be the General Public License.
3. Remember the Source Code. In simplest terms, the biggest difference between Open Source software and commercial software relates to the source code of the program.
4. Make Reasonable Comparisons with Commercial Software. It’s easy to find frantic concerns about Open Source software over reasons that apply just as easily to commercial software.
5. Think in Terms of Choosing, Rather Than Negotiating, Open Source Licenses. As frustrating as it can be to lawyers, the best approach is to evaluate the available choices and weigh the consequences, not to think in terms of ways to tinker with or improve the terms of agreements.
6. Do Not Confuse Open Source with Public Domain. Make no mistake – Open Source software is real intellectual property that is governed by a real license that puts limits on your rights and imposes certain obligations.
7. Inventory and Assess What You May Already Be Using. It has become very important for both business decision-makers and lawyers to have a good understanding of the technology issues, including what the software does and the alternatives available.
8. Open Source Use Requires Open Source Training. Knowing the right questions to ask is half the battle, but IT staff, contract negotiators and legal personnel, including outside lawyers, must be trained on the legal issues involved with Open Source as well as on the policies and procedures that you decide to take.
9. Reasonable Policies and Procedures Are Not Optional. Many business people believe that if you give a lawyer a look at a business process and he or she will find the need for a written policy. However, a reasonable, evolving set of policies and procedures crafted to fit the business needs and corporate risk comfort level of your company will invariably be the best approach to take.
10. Treat Open Source Policy as a Team Game. If the lawyer only looks at the legal issues and the CIO looks only at the IT issues, you increase the likelihood of finger-pointing when an unexpected, but quite predictable, bad result occurs.”

*Source: David Kennedy, esq.

Originally published by Louis Carbonneau