Advice for Entrepreneurs, Mergers and Acquisitions, Editorial, Pre-sale Planning, Selling a Business, Technology, Software
Now before I start, let me say that this is not a judgement on the use of open source as a part of your development strategy. My opinion is that in general that open source initiative has been a great boon to the software development community and by sharing code and tools, developers have saved a ton of time and avoided a lot of redundancy, which has helped them to be more efficient. Open source has even spawned complete new operating systems (like Linux) creating a more competitive environment vs giants like Microsoft and Apple.
But the notion that everything open source is free and unencumbered is a common misconception. Use of many open source components comes with strings attached. The strings could be as simple as submitting fixes or giving credit where credit is due; or as complex as requiring some form of license agreement. Given this, the fact as it relates to selling your business is that many major corporations view these “obligations” as unnecessary and unwanted. These potential buyers of your business may even have policies prohibiting the distribution (or even use) of open source routines. Others may simply require documentation of use and proof of licensing (or other compliance with rules of use).
As a result, when preparing to sell your company it is important to understand your potential exposure, what it would take to remediate the situation if required, and the policy of your potential buyers. Having a documented company policy is a good start, but not sufficient. Open source finds many ways to creep into your code, sometimes without you even being aware of its presence. Once a policy is in place, policing adherence on a regular basis to assure compliance is a smart thing to do. As a colleague of mine one put it, reviewing your code for open source “is like brushing your teeth, just something you have to do,” and by the way, if you don’t do it, it is more than likely a potential buyer is going to require it anyway.
Enter open source review companies. These independent organizations essentially bounce your source code against a database, of often millions of open source routines, to identify if you have any open source embedded in your code. Now you may be thinking “not me, I know every inch of my source code,” but believe it or not many companies with excellent open source policies are surprised as to where open source has crept into their programs. Like any issue though, the important first step though is identification of the facts. Once the facts are known, then you can make a business decision on what, if any, remediation is necessary. (BTW there are also some very good free tools to help you identify open source. These are helpful, but may not be comprehensive and will probably not satisfy a potential buyer).
- Have an open source policy
- Be proactive in policing that policy
- Have a backup remediation plan if your buyer prohibits use of open source
- Make sure offering documents for your business accurately reflect your open source position
- Use a neutral 3rd party auditor to determine your exposure (if not regularly, at least in preparation before you go to market)
- If you choose not to be proactive, be prepared for audit requirements from potential buyer:
- Understand the requirement during pre-LOI Due Diligence
- Set aside time and budget for examination during due diligence.
With a little bit of planning and some help from a software experienced investment banker negotiating on your behalf, dealing with the open source issue can be as simple as brushing your teeth.