Not exactly; it's simply that under California law, non-compete clauses are unenforceable in employment contracts.
The California Business and Professions Code section 16600 states that “every contract by which anyone is restrained from engaging in a lawful profession, trade, or business of any kind is to that extent void.”
What you're saying might be true about the personal opinion of judges; I have no knowledge of that either way. But the fact of the matter is that state law makes non-competes void in employment contracts.
That doesn't mean you can take your company's IP with you, however, as we've seen happen in other high-profile cases, like the engineer who went to Uber with a bunch of tech stolen from his previous self-driving car company: https://www.nytimes.com/2017/05/30/technology/uber-anthony-l... "Uber Fires Former Google Engineer at Heart of Self-Driving Dispute".
But general knowledge of cryptography and blockchain primitives is not that sort of IP, unless the company has some truly novel cryptographic construction, or the engineers in question are trying to take code with them – I'm sure they're smarter than that. Besides, blockchain code for one project wouldn't necessarily be useful for an entirely different project unless it was an almost exact duplicate. Lastly, for blockchains to succeed they likely need to be open source or at least shared-source; no one will trust a closed-source, single-party controlled blockchain. There's no point in using the technology that way: you might as well just have a ledger in a database. So any successful blockchain tech will end up being open source, and there would be strong indications of copying unless the people working on it make a massive effort to obfuscate and rewrite.
Let me put it a different way: if you had the source code for AWS's S3 or DynamoDB, they wouldn't be of any use to you. They're so complex and proprietary that if you wanted to form a company to offer competing services, you'd be better off and would get a product to market faster by building the functionality from the ground up (unless you could somehow take the entire team that has expertise with the existing software with you). The source would probably have value for bug-bounty hunters and blackhat hackers, but someone wanting to build similar services would be better off starting from scratch with the latest platforms (e.g. Rust) and programming/validation techniques.
Very specialized cutting-edge areas like self-driving cars and computer vision that have advanced algorithms and machine learning are exceptions. I think blockchain tech is well enough understood that it's past that stage, except perhaps for complex smart contracts, especially ones that involve multiple blockchains, and maybe advances to speed up network transaction speed.
I have no blockchain expertise whatsoever, but I'm pretty sure I could build a cryptocurrency from scratch from first principles given my existing knowledge of cryptographic primitives, and having skimmed Satoshi's original whitepaper and read casually on the topic. There's probably some fine-tuning magic in getting a few parameters right (like block size, difficulty, whether to be deflationary, etc.) but the basic structure of blockchain tech is pretty well understood by this point by people interested in the technology, even casually interested folks like myself. You submit a transaction for publication onto the blockchain and offer a fee for a miner to include it in their block. (How the network propagates these requests effectively peer-to-peer I'm not entirely sure, but I imagine that the wallet clients have hardcoded seed servers that they use to discover others for broadcast, after which candidate blocks move peer to peer across the network. There may be discovery techniques similar to other P2P networks.) So-called full nodes probably discover and maintain connections to a suite of other full nodes, which they use to broadcast transactions and candidate blocks across the network.
A miner successfully cracks the hash for the next block, based on the current difficulty level (set by time since last block), and includes all the pending transactions they know about that fit into the block (limited by block size). The pending transactions are cryptographically validated by their respective wallet public key signatures. You'll need to get that signature validation just right to make sure it's validating every input. Pending transactions include an operation code instructing what operation should be performed: transfer funds to another wallet, transfer funds to another wallet given N out of M signatures from other identities, and so on. More advanced blockchains than BTC have sophisticated programming models with many operations to make "smart contracts"possible involving multiple actors, but you don't need that complexity for a basic working network that can move blockchain currency. Bitcoin has basic operations and multi-signature transactions; Ethereum has a fully Turing-complete programming model, to enable its smart contracts and sophisticated constructs like the DAO. To prevent abuse and infinite loops you have to "pay" for the amount of computational power your transaction/contract uses based on its complexity, and also set a maximum number of operations it will perform before stopping (and you still have to pay for its execution if that happens).
If I was truly going to implement a cryptocurrency from scratch I'd probably start either with Satoshi's original code as a reference minimal implementation, and compare it with the current mainstream BTC clients (which have fixed bugs etc. since then). That's all open source, then adjust as necessary to meet your goals.
The California Business and Professions Code section 16600 states that “every contract by which anyone is restrained from engaging in a lawful profession, trade, or business of any kind is to that extent void.”
What you're saying might be true about the personal opinion of judges; I have no knowledge of that either way. But the fact of the matter is that state law makes non-competes void in employment contracts.
That doesn't mean you can take your company's IP with you, however, as we've seen happen in other high-profile cases, like the engineer who went to Uber with a bunch of tech stolen from his previous self-driving car company: https://www.nytimes.com/2017/05/30/technology/uber-anthony-l... "Uber Fires Former Google Engineer at Heart of Self-Driving Dispute".
But general knowledge of cryptography and blockchain primitives is not that sort of IP, unless the company has some truly novel cryptographic construction, or the engineers in question are trying to take code with them – I'm sure they're smarter than that. Besides, blockchain code for one project wouldn't necessarily be useful for an entirely different project unless it was an almost exact duplicate. Lastly, for blockchains to succeed they likely need to be open source or at least shared-source; no one will trust a closed-source, single-party controlled blockchain. There's no point in using the technology that way: you might as well just have a ledger in a database. So any successful blockchain tech will end up being open source, and there would be strong indications of copying unless the people working on it make a massive effort to obfuscate and rewrite.
Let me put it a different way: if you had the source code for AWS's S3 or DynamoDB, they wouldn't be of any use to you. They're so complex and proprietary that if you wanted to form a company to offer competing services, you'd be better off and would get a product to market faster by building the functionality from the ground up (unless you could somehow take the entire team that has expertise with the existing software with you). The source would probably have value for bug-bounty hunters and blackhat hackers, but someone wanting to build similar services would be better off starting from scratch with the latest platforms (e.g. Rust) and programming/validation techniques.
Very specialized cutting-edge areas like self-driving cars and computer vision that have advanced algorithms and machine learning are exceptions. I think blockchain tech is well enough understood that it's past that stage, except perhaps for complex smart contracts, especially ones that involve multiple blockchains, and maybe advances to speed up network transaction speed.
I have no blockchain expertise whatsoever, but I'm pretty sure I could build a cryptocurrency from scratch from first principles given my existing knowledge of cryptographic primitives, and having skimmed Satoshi's original whitepaper and read casually on the topic. There's probably some fine-tuning magic in getting a few parameters right (like block size, difficulty, whether to be deflationary, etc.) but the basic structure of blockchain tech is pretty well understood by this point by people interested in the technology, even casually interested folks like myself. You submit a transaction for publication onto the blockchain and offer a fee for a miner to include it in their block. (How the network propagates these requests effectively peer-to-peer I'm not entirely sure, but I imagine that the wallet clients have hardcoded seed servers that they use to discover others for broadcast, after which candidate blocks move peer to peer across the network. There may be discovery techniques similar to other P2P networks.) So-called full nodes probably discover and maintain connections to a suite of other full nodes, which they use to broadcast transactions and candidate blocks across the network.
A miner successfully cracks the hash for the next block, based on the current difficulty level (set by time since last block), and includes all the pending transactions they know about that fit into the block (limited by block size). The pending transactions are cryptographically validated by their respective wallet public key signatures. You'll need to get that signature validation just right to make sure it's validating every input. Pending transactions include an operation code instructing what operation should be performed: transfer funds to another wallet, transfer funds to another wallet given N out of M signatures from other identities, and so on. More advanced blockchains than BTC have sophisticated programming models with many operations to make "smart contracts"possible involving multiple actors, but you don't need that complexity for a basic working network that can move blockchain currency. Bitcoin has basic operations and multi-signature transactions; Ethereum has a fully Turing-complete programming model, to enable its smart contracts and sophisticated constructs like the DAO. To prevent abuse and infinite loops you have to "pay" for the amount of computational power your transaction/contract uses based on its complexity, and also set a maximum number of operations it will perform before stopping (and you still have to pay for its execution if that happens).
If I was truly going to implement a cryptocurrency from scratch I'd probably start either with Satoshi's original code as a reference minimal implementation, and compare it with the current mainstream BTC clients (which have fixed bugs etc. since then). That's all open source, then adjust as necessary to meet your goals.