Source Code Disclosure vs Protection

[MarianOrr307]

With respect to Preliminary Note 1 (b) (1) (i) Disclosures-> Initial Disclosure ->Source Code: we’d like to propose that Initial Development Teams have an option to keep their source code confidential for a certain grace period (18 – 24 months), under the condition that during the grace period, the source code can be accessed by signing a standard NDA. Both the template and the executed NDA should be published and accessible to the general public to demonstrate who has access to the source code under what conditions.    We fully understand that instead of a centralized third party, token communities have to trust the source code for mission critical tasks. A simple NDA may further encourage and facilitate disclosure, while protecting the source code mitigates unintended consequences while a network is maturing.  Bitcoin’s source code has been copied in whole or part to create multiple tokens, many with Bitcoin in the name.  Recently, UniSwap source code has been copied in whole or part by pseudonymous authors to create SushiSwap and PancakeSwap, and other projects.  

-Marian Orr

[zenzen-sol]

If a project insists on protection against clones, it can use a Business Source License similar to that used in Uniswap V3.

My own view is that closed source is antithetical to investor protection in crypto markets, as:

1. Contract risk is the number one risk for investors in this space.
2. Independent source code review/audit is the only way to mitigate contract risk.
3. A fundamental principle of blockchain technology is trust minimization.

Personally, I think even the BSL introduces a "walled garden" mentality that is unnecessary and unwelcome in crypto communities, but it's ultimately up to the markets to determine that.

Also, "Standard NDA" sounds problematic unless the SEC is willing to bless a form of NDA.

[MarianOrr307]

ZenZen,

Great feedback! We believe the Initial Development Team should have the option to determine whether their project needs protection against clones at their own discretion, as one or two clone cases can easily consume a small team’s limited funds and bandwidth. To the extent that UniSwap’s 3.0 Business Source License (BSL) cannot preempt anonymous bad actors to clone projects, an NDA is a better way to provide legal protection. We believe a BSL is only useful if the Initial Development Team has the funds and resources to seek legal recourse in court after the damage is done - which can often be too little, too late!   A simple SEC authorized Standard NDA, as you suggested, would be great! Is this something you’d be interesting in taking a crack at and sharing it here? (For clarity, only those users who want to see the source code need to sign the NDA - providing an option as mentioned above.)

ZenZen, would love to get your ideas of how best to protect the network from opportunistic clones as the network begins to grow.  We'll enjoy working on this together!

Marian Orr

[zenzen-sol]

1. I don't want to wade into a very long-standing debate about whether and how to protect closed source software, so I'll just let the SEC articulate its reasons for requiring disclosure of source code. My personal view is that closed-source projects are anti-investor and anti-consumer and contrary to the fundamental use case for blockchains, for the reasons I mentioned above.
2. I'm not very hopeful that the SEC will bless an NDA form, but they could surprise us. I can see a lot of problems with that process, though, having worked on template NDAs in other contexts.