3 ms·

> this sort of thing shows up in due diligence Everyone throws around the phrase "due diligence", but what exactly does that mean? How is this kind of thing sh

> this sort of thing shows up in due diligence Everyone throws around the phrase "due diligence", but what exactly does that mean? How is this kind of thing showing up in "due diligence", assuming a side project could be at any stage? Do they interview employees? Go through their social accounts? Github repositories? Lurk at IRC chat rooms?

nostrademons 11y ago
My understanding of the process (I've never been through it myself, but my wife does it as part of her job) is that the acquirer or institutional investor will request a pile of documents, including: audited financials for the company; the cap table, and any investment documents; tax returns; company bank statements & other financials; all agreements that employees have signed with the company; all agreements with partners & customers; commit logs for the repository, and oftentimes samples of actual source code; etc. Then a team of people - usually including financiers, lawyers, accountants, and occasionally domain experts like programmers for a software startup or biologists for a biotech company - will go over that with a fine-toothed comb, looking for inconsistencies. If the documentation is inconsistent or missing, you will be grilled on it. For things like missing partner or employee agreements, you will have to go back to those people and get them to sign the appropriate agreements. For audited financials, if there is an inconsistency you may have to restate earnings. If your commit logs show that some of your code was written by a person who was not an employee of the company at the time of the commit, you will be asked to produce a license or otherwise explain how you can legally use that code. If it turns out that they were an employee of some other company at the time, with IP assignment to their employer, then you'll have to go to that company and get them to sign a release or license agreement to use that code, and if they won't do that, it may torpedo the deal.
- x0x0 11y ago
  I've done it recently as an employee of an acquired company. In addition, acquirers can (and do!) interview the developers as well. We got questions that approximated how one would take git and turn that into the running system. The acquirer also crawled through all our software license agreements; wee discovered we weren't licensed quite correctly for a commercial db, so had to rip it out in a real rush. For each customer agreement, it has to be either assignable, or you will have to go to that customer and get them to agree to make it assignable. Each customer that doesn't so agree, or each customer that is slow to respond, will have to be individually negotiated with the acquirer in the period before the deal closes. I'd imagine that one of the big risks acquirers of small companies care about is the company somehow fucked up and doesn't own, or there is a colorable claim they don't own, their source code. Having an overlap of git commits with your previous employer could cause you a lot of heartburn at minimum. And good luck getting a timely response from your previous employer that they don't own that code. Your previous employer, even if they have no intentions of being dicks, simply have no incentive to sign (and definitely no incentive to promptly sign) such an agreement.

nostrademons 11y ago

My understanding of the process (I've never been through it myself, but my wife does it as part of her job) is that the acquirer or institutional investor will request a pile of documents, including: audited financials for the company; the cap table, and any investment documents; tax returns; company bank statements & other financials; all agreements that employees have signed with the company; all agreements with partners & customers; commit logs for the repository, and oftentimes samples of actual source code; etc. Then a team of people - usually including financiers, lawyers, accountants, and occasionally domain experts like programmers for a software startup or biologists for a biotech company - will go over that with a fine-toothed comb, looking for inconsistencies. If the documentation is inconsistent or missing, you will be grilled on it. For things like missing partner or employee agreements, you will have to go back to those people and get them to sign the appropriate agreements. For audited financials, if there is an inconsistency you may have to restate earnings. If your commit logs show that some of your code was written by a person who was not an employee of the company at the time of the commit, you will be asked to produce a license or otherwise explain how you can legally use that code. If it turns out that they were an employee of some other company at the time, with IP assignment to their employer, then you'll have to go to that company and get them to sign a release or license agreement to use that code, and if they won't do that, it may torpedo the deal.

x0x0 11y ago
I've done it recently as an employee of an acquired company. In addition, acquirers can (and do!) interview the developers as well. We got questions that approximated how one would take git and turn that into the running system. The acquirer also crawled through all our software license agreements; wee discovered we weren't licensed quite correctly for a commercial db, so had to rip it out in a real rush. For each customer agreement, it has to be either assignable, or you will have to go to that customer and get them to agree to make it assignable. Each customer that doesn't so agree, or each customer that is slow to respond, will have to be individually negotiated with the acquirer in the period before the deal closes. I'd imagine that one of the big risks acquirers of small companies care about is the company somehow fucked up and doesn't own, or there is a colorable claim they don't own, their source code. Having an overlap of git commits with your previous employer could cause you a lot of heartburn at minimum. And good luck getting a timely response from your previous employer that they don't own that code. Your previous employer, even if they have no intentions of being dicks, simply have no incentive to sign (and definitely no incentive to promptly sign) such an agreement.