Proposal to Relicense the ZERA Network & Tooling (Existing and New by Default) Under the MIT License

Summary

This proposal recommends that the ZERA Network's core protocol and core codebase be relicensed under the MIT License, replacing the existing ZERA Open Use and Revenue Sharing License (v1.0). It also establishes that all governance-funded tools (past and future) adopt MIT licensing by default unless governance explicitly approves an alternative.

The goal is to maximize developer adoption, reduce integration friction, and position ZERA as an open, standards-aligned, next-generation blockchain platform.

Motivation

The current ZERA License v1.0?while innovative?imposes restrictions that hinder adoption.
ZERA's potential depends heavily on attracting developers, enterprises, and tooling providers. A restrictive license reduces experimentation, slows ecosystem growth, and weakens network effects.

Re-licensing under MIT aligns ZERA with the licensing norms of leading blockchain ecosystems and removes unnecessary adoption barriers.

Problems With the Current License (ZERA License v1.0)

The following items reflect common open-source adoption patterns and practical considerations.

1. Mandatory Revenue Sharing (25% of gross revenue)

Requiring derivatives or forks to remit a portion of gross protocol revenue is a major deterrent.

(1) Developers avoid licenses with revenue obligations.
(2) Enterprises face fiduciary and regulatory incompatibilities.
(3) Using "gross revenue" ignores operational costs.

This effectively blocks participation from L2 and rollup builders.

2. Mandated Fee Parity / Price Restrictions

The rule preventing forks from offering lower fees creates:

(1) Legal ambiguity
(2) Economic rigidity
(3) Compliance complexity

Ecosystems grow through differentiation. Fee parity restricts experimentation and economic innovation.

3. Required Publication of Modifications

The requirement to publish all modifications within 90 days discourages:

(1) Enterprises with proprietary systems
(2) Researchers developing private prototypes
(3) General innovation

Permissive licenses like MIT do not include forced disclosure.

4. Legal Enforcement via Token Holder Litigation

Allowing any token holder to initiate enforcement introduces:

(1) Liability risk
(2) Adoption uncertainty
(3) Difficulty for institutional partners
(4) Heightened potential for frivolous claims

Successful protocols rely on incentives, not litigation.

5. Single Licensee Per Project & Anti-Circumvention Rules

These rules complicate:

(1) Multi-entity collaborations
(2) Multi-region corporate structures
(3) Layered technical deployments
(4) SaaS and enterprise integrations

They do not reflect how modern organizations build software.

Why MIT Licensing Aligns With ZERA's Vision

The MIT License is:

(1) Permissive
(2) Simple
(3) Developer-friendly
(4) Enterprise-friendly
(5) Proven across top blockchain networks

MIT allows:

(1) Forking without obligations
(2) Revenue models without entanglements
(3) Tooling without reciprocity clauses
(4) Competition based on merit, not licensing constraints

This aligns with ZERA's philosophy of decentralization, permissionlessness, and community-driven growth.

Proposal Details

1. Re-license Core ZERA Network Software Under MIT

This includes:

(1) Core protocol code
(2) Consensus components
(3) Runtime and WASM execution layers
(4) Core libraries supporting ZERA functionality
(5) Everything else under the ZERA Network

Governance may choose make certain items under different licenses in the future.

2. Retire Revenue-Sharing, Fee Parity, and Mandatory Disclosure Requirements

Once transitioned:

(1) Revenue-sharing is removed
(2) Fee-parity restrictions are removed
(3) Mandatory public disclosure of code changes is removed

Forks and derivatives will operate without these constraints.

3. Governance-Funded Tools Default to MIT Licensing

Any tool, contract, or library funded by ZERA governance structures (e.g., IIT, ZMT, Treasury) will be:

MIT-licensed by default unless governance votes for an alternative.

This allows:

(1) Maximum reusability
(2) Zero friction for integrators
(3) Predictable licensing
(4) A strong tooling ecosystem

Exemption: Any license associated with private code associated with proposals that is not intended to be for public use remains at the discretion of the creator. For example, off-chain backend API systems.

Expected Outcomes

Short-Term

(1) Increased developer interest
(2) More experimentation
(3) Easier integrations for wallets and explorers
(4) Reduced enterprise licensing concerns

Medium-Term

(1) Expansion of independent tooling
(2) Increase of community-driven repositories
(3) More L2s and ecosystem projects adopting ZERA

Long-Term

(1) Stronger network effects
(2) ZERA positioned as a leading WASM governance-first chain
(3) Increased demand for ZERA-native usage
(4) Greater legitimacy as a permissionless public infrastructure

Conclusion

The ZERA License v1.0 is creative but ultimately too restrictive to support a large-scale ecosystem.

MIT licensing removes friction, aligns ZERA with open-source standards, and accelerates growth.

Default MIT licensing for governance-funded tools further reinforces transparency and developer empowerment?core to the ZERA ethos.