Building on the story of this thread: https://forum.dfinity.org/t/gplv3-the-story-and-why-it-may-be-interesting/75049/8
Ok, this is where we are now. Working on changing the Neutron Kernel License, and it will be in production soon. Comments are welcome. I want to make Neutron a fair game that’s not going to end in a few weeks owned by someone with users unable to control their neutrons.
Tech alone seems to be a hard way of doing it in crypto. It ends up with tokens and trying to decentralize that, then going around trying to convince someone it’s decentralized.
Luckily, the GPL, and v3 in particular, demonstrates the existance of more tools we can use. The way the copyleft and anti-Tivoization are made feels like programming a decentralized protocol inside the license: “You can sell, share… but… and you can… but…” It worked for Linux with GPLv2.
Then the combination of tech, ICP, Neutron + License can create a tokenless decentralized protocol that’s a game where the rules are written in from the start and can’t be messed with. In such a game, the ICP governance machine just stays governing the IC protocol. It’s part of it, like TCP/HTTP/ICP/…, and the IC doesn’t govern the game; it just supports it, and cycle cost is just something that needs to be paid. The whole economic value of ICP guarantees its core protocol functions will keep working.
The GPLv3 anti-Tivoization just provides a way of handling the rest, but it’s questionable whether that covers our desired case, and it is made for software over hardware, not software inside canisters. So I tried to make a license that has the rules, not just the copyleft machinery.
Important note:
The NSUPL doesn’t ask anything from ordinary users, app developers, or the ICP network. It governs the people who develop & distribute the Neutron Kernel.
NSUPL DRAFT LICENSE here → https://gist.github.com/infu/646994cb98762f9471894af560c36a97
User-sovereign personal canisters are just a start; from there we can build community-sovereign ecosystems.
It’s complex machinery using both crypto and copyright law in an attempt to give more power to users and application developers. Usually, you have this set the other way.
The application developer can also pick a license they like for their app. They can also use a license that allows use of their apps only inside user-sovereign NSUPL-compliant canisters. This way, app devs’ work doesn’t magically land in non-user-sovereign canisters controlled by someone and empowers the community-sovereign ecosystem.
I think we can all support this initiative, given that decentralization is the poster child of crypto and ICP, there is theoretically nothing more decentralized than apps running in user-sovereign canisters. We can have the crypto protocol and legal license machinery protecting that soveregnity. If someone doesn’t like a part of the license and it feels like it’s not going towards the goal, let us know. It’s still a draft.
ChatGPT generated overview:
### The central idea
The license is built around what it calls a **“Sovereign User”**: one natural person whose personal software environment—the **User Deployment**—exists primarily for that person’s benefit.
The philosophy is essentially:
> Giving someone source code isn’t enough if the vendor still controls whether that person can actually install modified software on their own system.
So NSUPL combines conventional source-code copyleft with what you could call **deployment sovereignty**. The preamble says users should be able to inspect packages, choose public or private software, compile their system, install modified versions, and continue doing so without a maintainer, registry, provider, or governance body having a veto.
### The most unusual part: the User Upgrade Path
Section 5 is probably the heart of the license.
A compliant personal deployment must give its user an effective **User Upgrade Path**. Among other things, the user must be able to inspect what is installed; choose official, modified, unsigned, unlisted, privately distributed, or differently governed packages; compile/install or replace the complete Wasm; and do this without a deployment-specific third party’s permission or secret.
That’s substantially stronger than simply saying, “here is the source.”
For example, imagine a company publishes all of its platform source code but retains a secret signing key, and your particular installation will refuse modified versions unless the company signs them. **That appears to be exactly the sort of arrangement NSUPL is designed to prevent.**
It also addresses controller-level power. Third-party controller authority can exist, but generally only following specific, affirmative, default-off user consent, with appropriate warnings; afterward it must remain removable or revocable through the upgrade path.
### It explicitly attacks “Daoization”
The license introduces an interesting term: **Daoization**.
Under section 6, governance itself isn’t prohibited. A DAO or other governance body can publish and recommend software. The problem arises when a governance mechanism becomes a **mandatory gate controlling an individual user’s deployed canister**.
For example, if replacing your system requires:
* a DAO vote,
* an allowlist,
* somebody else’s signature,
* a co-signature,
* a secret held by somebody else, or
* an ongoing external service,
then the deployment can fall within the license’s definition of Daoization.
That’s a pretty distinctive position. It effectively says **decentralized governance isn’t equivalent to individual sovereignty**. A thousand token holders collectively controlling your canister is still someone other than you controlling your canister.
### There’s another major principle: Kernel neutrality
The NSUPL also separates **Kernel infrastructure** from **Applications**.
The Kernel can provide general-purpose capabilities—storage, networking, identity, cryptography, etc.—but similarly situated third-party applications are supposed to receive those capabilities under materially equal rules.
That creates something resembling an **anti-self-preferencing rule embedded directly into the software license**.
For example, suppose Neutron’s developer makes a first-party photo application. The Kernel shouldn’t secretly give that application privileged storage APIs that competing photo applications can’t access merely because the application comes from the Kernel developer.
The license goes even further with its **“No Sherlocking or evasion”** provision: a Kernel licensor can compete with third-party developers, but is supposed to do so through an ordinary Application operating under the same rules rather than absorbing a competing product’s functionality into privileged Kernel infrastructure.
### Private users have unusually explicit protection
Another interesting section makes clear that an individual Sovereign User doesn’t trigger publication obligations merely by customizing their own system.
The user can receive public **or private** packages, compile them in the browser, modify them privately, assemble them into their personal deployment, and install them without having to publish their modifications, package list, hashes, combined Wasm, deployment records, etc.
So the license isn’t trying to turn every user’s canister into a public source-code repository.
The obligations become much more significant when someone **Provides** the software to someone else—either by conveying it or by operating a deployment for another person.