The million euro question for startups: did you “borrow”, steal or create your software?
I’ve been doing technical due diligence for VC’s for at least ten years now. My job is to find out whether you, as a startup, created, borrowed or stole your software. This is not a trivial matter: I have seen investments go south because of this, and unfortunately I notice time and time again that most startups never think about this.
Startups: do you have an IP strategy? Yes/No
So you created this SaaS or packaged software solution. You and your team worked thousands of hours. Weekends are just another two days in the working week. You lined up funding. You’re excited about moving your startup into the next phase. And then comes the time when your VC investment manager – or your technical due diligence investigator – is going to ask you these million euro questions:
- “Did you develop this product on your own?”
- “Did you use external frameworks/components?”
- “Which licenses do all these frameworks and components have?”
This is the moment for startups to avoid jaw dropping. It’s also an illusion to think that you will ever get funding without answering these questions to the VC’s satisfaction. You might think: we’ll find another VC, but you would be wrong. Most VC’s know each other, and they’re all very much aware of the importance of having the right licenses.
Startups have to understand that these questions are fair and legitimate: it’s the VC’s job to ask these questions, and to obtain good, solid answers to them. The good news is: startups can prepare themselves.
How you do this is:
- you create a list with all external components used within your product.
- for every component write down the name, the version number, URL of the project and the license text.
In general I request such a list and ask for delivery within 18 hours. If the startup has no clue what to deliver the answer to the due diligence question “Does the startup have an IP strategy? yes/no” is pretty much finished.
Version numbers are important: there are packages around – iText for example – that changed licensing on version numbers. For commercial external components prepare a copy of the license and quote or contract. During this exercise it is most important not to guess! If you cannot find the license for an external component – tell it to the VC / due diligence team. Ask them for a solution.
This is a good start, but it is not enough. Some answers missing with this approach are:
- Are there any code snippets from external sources in your code with ‘contaminated’ licenses? Things like this happen in most cases when it’s 4 in the morning, a developer needs a quick fix and goes on the internet to find one. That’s when a contaminated code snippet finds its way into your product. The programmer doesn’t know he or she did something wrong, because programmers are no license experts!
- Did you check all art work? All pictures and icons have the right licenses? An innocent looking country flag icon can get in big trouble.
- Bonus question: is your external license combination robust enough to change your business model from SaaS to on premise? Some licenses make it impossible for you to install your SaaS software on premise. I’ve seen companies not getting funding based on this, and it’s not hard to understand why: it can literally kill your business model. You might think that it’s a matter of choice to run your business like a SaaS or on premise, but if your license won’t let you, you’re doomed, and all your hard work was wasted. (And no VC will fund you). Googling ”fsf gpl violation” or visiting gpl-violations.org will give you good starting point.
- Most important: while you created your list with external components you probably assumed that the outside license label is right. Unfortunately, this is not always the case. What if the outside label told you “Apache License 2.0” and the one who packed the files included GPL code snippets in a sub-sub-sub directory in there?
A startup can – in general – demonstrate “good faith” by preparing a list of components they believe they are using. Good faith and honesty is the right direction, it’s not enough for getting money.
The whole process of doing a formal technical software intellectual property due diligence can be completed in a majority of cases within two weeks. If there are problems, they can be solved based on the findings and come up with a solution.
Receive our top stories in your mailbox every day!
Sign up here:
Photo: Flickr, TheGreatGonzo
Powered by Facebook Comments