"What would you tell your brother-in-law?"...about open source licensing issues, if he ran a software startup. That was the question I kicked around with Black Duck colleagues when preparing for a panel discussion with a group of entrepreneurs.
First, Bro, read my last blog to learn the basics of open source licensing and the associated intellectual property (IP) concerns, then think about those concerns from the perspective of an acquirer.
A buyer needs to know what they're buying and will thus be very focused on your IP. 18th century American financier Daniel Drew once said, "He who sells what isn't his'n, must buy it back or go to prison." To avoid such trouble buyers will ask you to document the origins and terms under which you are using everything in your code base.
The buyer will also gauge the credibility of your answers. Have you been tracking all this with a real process, or do you reactively run off to piece the answers together after the fact? During due diligence they will verify everything you provide by inspecting the code manually or with automated tools. Third party code that you didn't identify raises credibility questions. Excessive licensing conflicts could put the deal on hold while you remediate and/or reduce valuation and/or blow it up.
To avoid any issues, you need what big companies need: Policy, processes and education.
Your policy should be simple. Many companies take a red/yellow/green approach. Green licenses are OK any time, Yellow licenses under some conditions with approval, and Red licenses, never. Certain licenses may be fine for internal use, but not for distribution, so if you want to be more sophisticated, look at each use case. It's worth getting advice from an IP attorney or open source consultant to save you many downstream headaches.
Processes can be pretty simple for a company with 10 or 20 developers. First appoint an open source czar. It's important to have a resident expert to champion the effort. The other key elements are an approval process and a centralized catalog documenting open source components, where they are used and under what license. It all could be as simple as: You need to get permission from Joe and he maintains the spreadsheet and license docs. Automated solutions required by a big company would be overkill for you.
None of this will work unless your developers are bought in, so it's essential they understand the whys behind what may be perceived as a pain in the neck. A key part of the czar's charter should be to build grassroots support through education.
That will cover you going forward, but you should also assess the risk of problems in your current code base. Perform your own diligence with your developers. First, assess how conversant they are about the issues. If they seem to be tuned in, you are probably OK, if they want to know what you mean by "license," you need to dig deeper and may want to consider a third party code assessment.
Follow these simple guidelines, and I'm sure you'll be able to send all my nieces to college.