My experience (SF) is more like "don't ask, don't tell"
If you do something blatantly competitive, e.g. launch a product that competes with your employer's product, try to use employer's customer relationships, you'll get sued. If you do something outright illegal, like steal IP, you're probably going to jail.
But most managers I've worked for don't really care if it doesn't affect your day job, and in fact, might quietly encourage it as it lets you scout the new hotness and then bring it back to your day job, if it's good.
I suspect the norms around this depend highly on where you work, but I think this attitude is pretty common in SF tech.
Your manager probably doesn't care as long as you don't rub it in his face. The company only cares if you're becoming a direct competitor or try to get it to buy back IP that was created on company time anyway. However, potential investors care a lot - this sort of thing shows up in due diligence, and it's negotiating leverage that can be used against you in any potential lawsuit or acquisition.
It's fine to do side projects anytime you want - it's not like the company has the ability to restrict what you can do in your free time. But if it looks like the side project may turn into something more than a side project, it may be a good idea to quit your job, throw away the code, and rewrite everything from scratch.
In CA, state law offers a bit of protection (on your own time, no company equipment, unrelated to company business) but still, following nostrademons' advice is probably best. I know of two ycombinator startups sued by founders' former employers just off the top of my head: adgrok by murthy nukala, who appears to be a complete dick; shred video by smule.
>"But if it looks like the side project may turn into something more than a side project, it may be a good idea to quit your job, throw away the code, and rewrite everything from scratch."
Or, you could perhaps ask the people in charge to (on paper) waive certain provisions in your non-compete, or IP-sections in your work contract. They are human, and if it doesn't work, you would have learnt a great deal about your current employer just from trying.
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?
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.
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.
If you do something blatantly competitive, e.g. launch a product that competes with your employer's product, try to use employer's customer relationships, you'll get sued. If you do something outright illegal, like steal IP, you're probably going to jail.
But most managers I've worked for don't really care if it doesn't affect your day job, and in fact, might quietly encourage it as it lets you scout the new hotness and then bring it back to your day job, if it's good.
I suspect the norms around this depend highly on where you work, but I think this attitude is pretty common in SF tech.