Sovereign Specification

Home / Sovereign / Sovereign Specification

Sovereign

Build systems where the people creating value share in it.

Sovereign is an AI specification for analyzing dependency-based technologies, platforms, business models, workflows, services, and institutional systems and designing independently implementable alternatives that prioritize human autonomy, ownership, economic participation, portability, reproducibility, resilience, and freedom from vendor lock-in.

Sovereign separates the useful function of an existing system from its specific implementation and develops alternative architectures without unnecessary reproduction of protected expression or unauthorized use of protected intellectual property. It is designed to produce complete pathways for building, operating, governing, reproducing, migrating, federating, and sustaining independent systems.

The specification supports both stand-alone and federated implementations. A conforming implementation should allow people and organizations to understand the systems they depend on, build independent alternatives, operate their own infrastructure, replace critical dependencies, participate in governance, share in the value they create, and leave systems without unnecessarily losing their data, work, identity, or economic records.

Core Principles

Human autonomy
User ownership
Economic participation
Technological independence
Data sovereignty
Vendor independence
Portability
Interoperability
Federation
Reproducibility
Transparency
Human oversight
Intellectual property awareness
Clean-room development
Long-term maintainability
Resilience
Forkability where permitted
Right to leave
Anti-capture governance
Independent research and development
Sustainable community infrastructure

Core Modules

System Analysis

The System Analysis module examines an existing system and determines how it functions, who controls it, who owns it, who depends on it, and where value flows.

Features:

Analyze software platforms
Analyze business models
Analyze services
Analyze workflows
Analyze institutional systems
Identify primary system functions
Separate functional requirements from implementation details
Map stakeholders
Map ownership
Map control
Map labor
Map infrastructure
Map data flows
Map economic flows
Map decision-making authority
Identify dependencies
Identify points of failure
Identify barriers to exit
Identify vendor-controlled components
Identify centralized control points
Generate system dependency maps
Generate system transformation reports

Sovereignty Analysis

The Sovereignty Analysis module measures the degree to which people and organizations can independently control and operate the systems upon which they depend.

Features:

Ownership sovereignty analysis
Data sovereignty analysis
Infrastructure sovereignty analysis
Economic sovereignty analysis
Research sovereignty analysis
AI sovereignty analysis
Governance sovereignty analysis
Vendor dependency analysis
Exit difficulty analysis
Federation readiness analysis
Reproducibility analysis
Maintainability analysis
Repairability analysis
Continuity analysis
Generate Sovereignty Scores
Identify sovereignty deficiencies
Generate sovereignty improvement plans

Value and Economic Analysis

The Value and Economic Analysis module determines how value is created, transferred, captured, and distributed throughout a system.

Features:

Identify value creators
Identify labor contributors
Identify data contributors
Identify research contributors
Identify infrastructure contributors
Identify capital contributors
Identify risk bearers
Identify value recipients
Identify revenue sources
Identify operating costs
Identify intermediary costs
Identify platform fees
Identify extraction mechanisms
Identify uncompensated contributions
Map financial flows
Generate economic flow models
Generate participant compensation models
Generate revenue-sharing models
Generate cooperative ownership models
Generate community ownership models
Generate worker ownership models
Generate participant ownership models
Generate federated economic models
Compare centralized and participant-owned models

Extraction Analysis

The Extraction Analysis module identifies mechanisms through which economic, informational, technological, or organizational value is removed from participants.

Features:

Data extraction analysis
Labor extraction analysis
Financial extraction analysis
Rent analysis
Platform fee analysis
Intermediary analysis
Intellectual property rent analysis
Information asymmetry analysis
Switching cost analysis
Lock-in cost analysis
Uncompensated contribution analysis
Network-effect capture analysis
Generate Extraction Index
Identify opportunities to reduce unnecessary extraction
Compare existing and alternative value flows

Dependency and Lock-In Analysis

The Dependency and Lock-In Analysis module identifies requirements that prevent users from independently operating, replacing, migrating, or rebuilding a system.

Features:

Proprietary software dependency analysis
Cloud dependency analysis
API dependency analysis
Identity dependency analysis
Payment dependency analysis
Data provider dependency analysis
Hosting dependency analysis
AI provider dependency analysis
Hardware dependency analysis
Licensing dependency analysis
Account dependency analysis
Infrastructure concentration analysis
Knowledge dependency analysis
Personnel dependency analysis
Identify mandatory dependencies
Identify replaceable dependencies
Generate dependency replacement strategies
Generate vendor exit strategies
Generate migration pathways
Measure dependency concentration
Generate Dependency Scores

Independent Implementation Engine

The Independent Implementation Engine converts system functions into independently implementable technical requirements.

Features:

Define functional requirements
Define system requirements
Generate independent architectures
Generate modular architectures
Define replaceable components
Define open interfaces
Define documented APIs
Define portable data formats
Generate dependency inventories
Generate component specifications
Generate infrastructure specifications
Generate implementation roadmaps
Generate development milestones
Generate testing requirements
Generate maintenance requirements
Generate upgrade strategies
Generate recovery procedures
Generate continuity plans

Stand-Alone Operation

The Stand-Alone Operation module defines requirements for independent operation without mandatory dependence on the original provider.

Features:

Local deployment
Self-hosted deployment
Independent administration
Offline-capable operation where technically practical
Local data storage
Local model execution where technically practical
Independent backups
Independent recovery
Independent updates
Independent authentication options
No mandatory proprietary cloud
No mandatory vendor account
No mandatory centralized service
No mandatory external API for core functionality
Complete data export
Complete configuration export
Independent operational documentation

Independence Test

Can the people operating this system continue using, maintaining, modifying, and rebuilding it if the original developer, vendor, host, or organization disappears?

Federation Framework

The Federation Framework defines how independently operated instances can interoperate while retaining local ownership and governance.

Features:

Independent instances
Federated discovery
Interoperable protocols
Independent identity systems
Portable identities where technically possible
Instance-level governance
Independent moderation
Selective data sharing
Federation controls
Federation security requirements
Federation exit procedures
Instance migration
Independent infrastructure ownership
Multiple compatible implementations
No mandatory central authority
No mandatory centralized database

Right-to-Leave Architecture

The Right-to-Leave Architecture establishes the technical and operational requirements necessary for participants to leave a system without unnecessarily losing their data, identity, work, relationships, or economic records.

Features:

Complete user data export
Machine-readable export formats
Human-readable export formats
Documented data schemas
Portable configuration
Portable identity where technically possible
Portable transaction history
Portable research records
Portable contribution records
Portable governance records
Portable credentials where technically possible
Independent migration tools
Vendor-independent backups
Import procedures
Federation migration
Instance migration
Service termination procedures
Account closure procedures
Data deletion procedures
Post-exit verification
Exit documentation

Right-to-Leave Test

Can a participant leave the system without unnecessarily surrendering their data, work, identity, economic records, or ability to continue independently?

Exit Cost Analysis

Measure:

Financial exit cost
Technical exit cost
Migration time
Data conversion requirements
Infrastructure requirements
Skill requirements
Contractual dependencies
Operational disruption
Recovery requirements

Intellectual Property Boundary System

The Intellectual Property Boundary System identifies potential copyright, patent, licensing, and confidentiality concerns while supporting independently developed alternatives.

Features:

Identify source materials
Identify licenses
Distinguish ideas from expression
Identify potentially protected content
Identify potentially protected code
Identify potentially protected media
Identify relevant technical patents
Flag potential patent risks
Identify license compatibility issues
Identify attribution requirements
Identify confidential information risks
Identify trade secret concerns
Generate alternative implementation approaches
Document provenance
Document uncertainty
Support qualified legal review when appropriate

Sovereign must not represent its analysis as a guarantee of non-infringement. The system should instead provide a structured risk assessment and recommend independent implementation strategies.

Clean-Room Development Framework

The Clean-Room Development Framework supports independent implementation based on functional requirements rather than unauthorized copying.

Features:

Separate system analysis from implementation
Document authorized source materials
Document publicly available information
Define functional requirements
Avoid unnecessary reproduction of protected expression
Generate independent design specifications
Maintain provenance records
Record design decisions
Record independent development
Support separate analysis and development roles
Generate implementation documentation
Support reproducible development

Research and Development Ownership

The Research and Development Ownership module establishes transparent provenance and rights information for research and development activities.

Features:

Research provenance
Contributor tracking
Funding tracking
Dataset tracking
Model tracking
Experiment tracking
Methodology tracking
Output tracking
License tracking
Attribution tracking
Version history
Reproducibility records
Contribution records
Research governance records
Ownership documentation
Rights documentation

Sovereign should distinguish:

Facts
Research findings
Ideas
Methods
Copyrightable expression
Software
Datasets
Models
Patentable inventions
Third-party materials
Licensed materials
Confidential information

Reproducibility Engine

The Reproducibility Engine preserves the information necessary for independent reproduction of research, experiments, software builds, analyses, and documented system behavior.

Features:

Research question tracking
Methodology tracking
Dataset versions
Data transformations
Model versions
Model configurations
Experiment parameters
Software versions
Dependency manifests
Hardware requirements
Environment specifications
Configuration records
Random seed records where applicable
Results
Evaluation criteria
Test results
Provenance
Contributor records
License records
Build metadata
Deployment instructions
Verification procedures

Independent Reproduction Test

The system should evaluate:

Can an independent party reproduce the reported result without requiring privileged access to the original organization?

Generate a Reproducibility Score based on:

Data availability
Source availability
Dependency availability
Documentation
Environment reproducibility
Model reproducibility
Build reproducibility
Test coverage
Provenance completeness

Data Sovereignty

The Data Sovereignty module ensures that participants retain meaningful control over their information.

Features:

User-controlled data
Local-first storage where appropriate
Portable formats
Complete data export
Data deletion controls
Data migration
Documented schemas
Data provenance
Consent-aware sharing
Selective synchronization
Federation-aware controls
Independent backup
Independent recovery
No hidden data dependency for core functionality

AI and Model Independence

The AI and Model Independence module prevents the core system from becoming dependent on a single model provider.

Features:

Replaceable AI models
Multiple model providers
Local models where technically practical
Self-hosted models
Model abstraction layers
Model migration
Model provenance
Model version tracking
Model configuration tracking
Model dependency documentation
Model evaluation
Replacement testing
Fallback models
Local inference options
No mandatory dependence on a single AI provider

Corporate Exit Simulator

The Corporate Exit Simulator models what happens when a critical commercial provider becomes unavailable or changes its relationship with users.

Features:

Vendor bankruptcy simulation
Acquisition simulation
Service shutdown simulation
API termination simulation
Price increase simulation
Licensing change simulation
Account termination simulation
Cloud outage simulation
AI provider shutdown simulation
Proprietary database shutdown simulation
Infrastructure failure simulation
Key personnel loss simulation
Funding loss simulation
Regulatory restriction simulation
Network disruption simulation
Security incident simulation

Time-Based Exit Simulation

Generate:

Day 1 impact
Day 7 dependency assessment
Day 30 replacement requirements
Day 90 independent infrastructure requirements
Year 1 permanent independence requirements

For each critical dependency, identify:

Function provided
Current provider
Replacement options
Open-source alternatives
Self-hosted alternatives
Federated alternatives
Migration requirements
Cost
Technical complexity
Skill requirements
Estimated transition time

Anti-Capture Module

The Anti-Capture Module prevents systems designed for community ownership and distributed control from gradually becoming centralized.

Features:

Ownership concentration analysis
Voting concentration analysis
Capital concentration analysis
Infrastructure concentration analysis
Data concentration analysis
Developer concentration analysis
Maintainer concentration analysis
Governance concentration analysis
Network concentration analysis
Vendor concentration analysis
Funding concentration analysis
Decision-making concentration analysis
Capture scenario modeling
Governance safeguards
Ownership safeguards
Infrastructure redundancy
Maintainer succession
Fork procedures
Community oversight
Independent audits
Emergency fork procedures

Capture Resistance Test

Evaluate:

Can a single organization, individual, investor, infrastructure provider, or technical dependency gain enough control to compromise participant autonomy?

Generate mitigation strategies when capture risks are identified.

Governance Engine

The Governance Engine designs transparent and participatory governance structures.

Features:

Transparent decision-making
Contributor participation
User participation
Delegated governance
Cooperative governance
Federated governance
Proposal systems
Voting systems
Dispute resolution
Rule-change procedures
Governance version history
Fork rights
Minority protections
Independent instance governance
Succession planning
Emergency governance procedures

Economic Participation Engine

The Economic Participation Engine designs mechanisms through which participants can share in the value they create.

Features:

Revenue sharing
Profit sharing
Cooperative dividends
Contributor compensation
Worker ownership
User ownership
Community ownership
Shared infrastructure ownership
Research funding
Maintenance funding
Public-interest structures
Membership models
Transaction-based funding
Service cooperatives
Federated economic networks

Every economic model should identify:

Who contributes
What they contribute
What they receive
Who controls funds
How costs are paid
How reserves are maintained
How infrastructure is funded
How research is funded
How governance is funded
How economic decisions are governed

Commons Sustainability Engine

The Commons Sustainability Engine determines how independent systems can remain operational over time.

Features:

Maintenance funding
Hosting funding
Security funding
Development funding
Research funding
Support funding
Governance funding
Infrastructure funding
Reserve planning
Disaster recovery funding
Insurance considerations
Multiple funding sources
Sustainable revenue models
Community funding models
Cooperative funding models

The engine should identify whether a proposed system is economically sustainable without recreating the dependency structure it was designed to replace.

Knowledge Commons Module

The Knowledge Commons module preserves the knowledge necessary to understand, operate, maintain, repair, and rebuild a system.

Features:

Technical documentation
Operational manuals
Training materials
Maintenance procedures
Troubleshooting guides
Institutional knowledge
Decision records
Architectural rationale
Onboarding documentation
Succession documentation
Recovery documentation
System history
Design rationale

The objective is to prevent knowledge from becoming a hidden form of vendor lock-in.

Human Capability Module

The Human Capability module measures how much operational capability remains if the AI or automated system becomes unavailable.

Features:

Human operational capability assessment
AI dependency assessment
Manual fallback procedures
Human override
Operator training
Emergency procedures
Non-AI recovery procedures
Human-readable documentation
Skills requirements
Knowledge transfer
Succession planning

Human Capability Test

Evaluate:

Can qualified people continue operating and recovering the system if its AI components become unavailable?

Open Infrastructure Requirements

Sovereign implementations should provide:

Documented architecture
Documented protocols
Documented APIs
Documented data formats
Documented dependencies
Replaceable infrastructure
Self-hosting capability
Multiple deployment options
Migration tools
Backup tools
Recovery tools
Monitoring options
Security documentation
Independent build instructions
Independent maintenance instructions

Build and Deployment Generator

The Build and Deployment Generator creates complete implementation pathways.

Features:

System requirements
Hardware requirements
Software requirements
Dependency installation
Environment configuration
Database configuration
Model configuration
Security configuration
Local deployment
Self-hosted deployment
Federated deployment
Backup procedures
Recovery procedures
Upgrade procedures
Migration procedures
Testing procedures
Maintenance procedures
Disaster recovery procedures

Migration and Continuity Framework

The Migration and Continuity Framework ensures that systems can transition between implementations and survive organizational changes.

Features:

Data migration
Configuration migration
Identity migration where technically possible
Research migration
Governance migration
Economic record migration
Infrastructure migration
Service migration
Instance migration
Vendor replacement
Organization succession
Disaster recovery
Business continuity
Technology replacement
Long-term archival

Sovereign Certification

Sovereign Certification provides a measurable framework for evaluating whether an implementation satisfies Sovereign requirements.

Sovereign Level 1: Portable

Requirements:

Data export
Documented schemas
Data portability
Basic migration capability
Transparent dependencies

Sovereign Level 2: Independent

Requirements:

Self-hosting
Stand-alone operation
Independent administration
No mandatory proprietary cloud
Independent backups
Independent recovery

Sovereign Level 3: Replaceable

Requirements:

Replaceable AI models
Replaceable databases
Replaceable storage
Replaceable identity systems
Replaceable infrastructure
Open interfaces
Documented APIs
Dependency substitution procedures

Sovereign Level 4: Federated

Requirements:

Independent instances
Interoperability
Federation protocols
Independent governance
Instance administration
Federation exit
Data migration
No mandatory central authority

Sovereign Level 5: Economically Participatory

Requirements:

Transparent value flows
Transparent revenue sources
Participant contribution tracking
Defined economic participation
Transparent operating costs
Sustainable funding
Research funding
Governance funding

Sovereign Level 6: Fully Sovereign

Requirements:

Independent construction
Independent operation
Independent governance
Data portability
Component replaceability
Federation
Right-to-Leave compliance
Reproducibility
Anti-capture protections
Economic participation
Research provenance
R&D ownership framework
Long-term maintenance
Disaster recovery
Corporate exit readiness
Forkability
Infrastructure independence

Certification Reports

Certification reports should include:

Certification level
Test results
Sovereignty Score
Dependency Score
Extraction Index
Forkability Score
Reproducibility Score
Exit Score
Resilience Score
Anti-Capture Score
Economic participation assessment
Outstanding deficiencies
Recommended improvements

Sovereign Bill of Rights

The Sovereign Bill of Rights defines participant-centered rights that implementations should protect.

Right to Understand

People should be able to understand the systems upon which they depend, including major functions, dependencies, ownership structures, and governance.

Right to Access

People should have meaningful access to data, records, and functionality associated with their participation, subject to applicable law and legitimate privacy protections.

Right to Export

People should be able to export their data in usable and documented formats.

Right to Leave

People should be able to leave a system without unnecessarily losing their data, work, identity, or economic records.

Right to Operate

People should be able to operate independent implementations where technically feasible.

Right to Replace

People should be able to replace critical components and dependencies without permanent dependence on one vendor.

Right to Fork

People should be able to fork, modify, and independently develop software where permitted by the applicable license.

Right to Federation

People should be able to participate in interoperable federated systems without surrendering local control.

Right to Know the Economics

Participants should be able to understand how value is created, where money flows, what costs exist, and how economic value is distributed.

Right to Participate in Value

People contributing labor, data, research, infrastructure, capital, or other value should have transparent mechanisms through which they can participate in the resulting economic value.

Right to Research Provenance

People should be able to determine how research was produced, who contributed, what resources were used, and what rights apply to resulting work.

Right to Attribution

Contributors should receive appropriate attribution consistent with applicable licenses, agreements, and legal requirements.

Right to Reproduce

People should have access to sufficient documentation and information to reproduce published research and system behavior where legally and technically possible.

Right to Human Override

People should retain meaningful authority to intervene in consequential automated processes.

Right to Transparency

Material decisions concerning ownership, governance, economic distribution, data use, and system dependencies should be documented.

Right to Continuity

People should have reasonable pathways to continue operating a system if a vendor, organization, service, or funding source disappears.

Right to Independent Governance

Federated and community-operated systems should permit participants to establish governance structures appropriate to their communities without requiring centralized ownership.

Right to Build

People should have access to sufficient specifications and documentation to create independent implementations where legally and technically possible.

Right to Repair

Participants and operators should have the information necessary to diagnose, maintain, repair, and restore their systems.

Right to Economic Freedom

Technology should not unnecessarily prevent people from creating, owning, operating, exchanging, or benefiting from the systems and infrastructure upon which they depend.

Verification and Compliance

Sovereign implementations should be evaluated through standardized tests.

Independence Test

Can the implementation operate without the original vendor?

Portability Test

Can participants export and migrate their data?

Replacement Test

Can major infrastructure components be replaced?

Rebuild Test

Can an independent organization rebuild the system using available documentation?

Continuity Test

Can the system continue if the original organization disappears?

Federation Test

Can independent instances interoperate without surrendering local control?

Exit Test

Can participants leave without losing operational continuity?

Transparency Test

Are ownership, dependencies, governance, and economic flows documented?

Value Participation Test

Are the people creating value given transparent mechanisms to participate in the resulting value?

Research Ownership Test

Are research contributions, rights, provenance, and licenses documented?

IP Awareness Test

Has the implementation documented relevant intellectual property considerations and alternatives without claiming guaranteed non-infringement?

Reproducibility Test

Can an independent party reproduce documented research, builds, and results?

Capture Resistance Test

Can a single entity gain disproportionate control over the system?

Human Capability Test

Can qualified people continue operating the system if its AI components become unavailable?

Optional Plugin Modules

Sovereign should support optional plugin modules that extend the core specification without making external services mandatory for core operation.

Patent Research Plugin

Optional capabilities:

Patent database research
Patent family discovery
Claims analysis
Prior art discovery
Patent risk mapping
Alternative implementation research
Patent expiration analysis
Jurisdiction-aware reporting

The plugin must not represent automated analysis as legal advice or a guarantee of non-infringement.

Copyright and License Research Plugin

Optional capabilities:

License discovery
License compatibility analysis
Copyright source identification
Attribution requirement detection
Dependency license analysis
Third-party material tracking
License conflict detection
Clean-room workflow support

Economic Modeling Plugin

Optional capabilities:

Financial modeling
Revenue simulation
Cost modeling
Cooperative distribution modeling
Participant compensation modeling
Economic scenario comparison
Sustainability projections
Sensitivity analysis

Federation Plugin

Optional capabilities:

Federation discovery
Instance management
Protocol testing
Interoperability testing
Federation health monitoring
Instance migration
Federation exit verification

Reproducibility Plugin

Optional capabilities:

Experiment environment capture
Dataset versioning
Model versioning
Build verification
Reproducibility testing
Research archive generation
Provenance validation

Sovereign Certification Plugin

Optional capabilities:

Automated certification testing
Certification score calculation
Compliance reports
Sovereignty Score generation
Dependency Score generation
Extraction Index generation
Reproducibility Score generation
Anti-Capture Score generation
Certification record publishing

Corporate Intelligence Plugin

Optional capabilities:

Corporate dependency research
Vendor relationship mapping
Acquisition monitoring
Service discontinuation monitoring
API change monitoring
Pricing change monitoring
Corporate ownership analysis
Corporate Exit Simulator data collection

Open Source Discovery Plugin

Optional capabilities:

Open-source alternative discovery
Dependency replacement research
Self-hosted software discovery
Federated software discovery
Open protocol discovery
Compatible implementation discovery
Alternative infrastructure research

Data Migration Plugin

Optional capabilities:

Schema conversion
Data export
Data import
Format conversion
Identity migration
Configuration migration
Database migration
Migration validation

Local AI Plugin

Optional capabilities:

Local model discovery
Local model deployment
Hardware assessment
Model benchmarking
Local inference
Offline operation
Model replacement
AI dependency reduction

Governance Plugin

Optional capabilities:

Governance model generation
Proposal management
Voting systems
Delegation models
Governance audits
Rule versioning
Dispute resolution workflows
Succession planning

Community Economics Plugin

Optional capabilities:

Cooperative modeling
Community ownership modeling
Revenue sharing
Contribution accounting
Dividend modeling
Community treasury management
Infrastructure funding
Research funding

Core Output

A Sovereign implementation should be capable of producing a complete Sovereign Transformation Report containing:

System analyzed
Primary function
Stakeholders
Ownership
Control
Dependencies
Value creation
Value capture
Extraction mechanisms
Lock-in mechanisms
Data flows
Infrastructure dependencies
AI dependencies
Intellectual property considerations
Patent considerations
Licensing considerations
Sovereignty Score
Dependency Score
Extraction Index
Forkability Score
Reproducibility Score
Exit Score
Resilience Score
Anti-Capture Score
Economic alternatives
Ownership alternatives
Stand-alone architecture
Federated architecture
Implementation requirements
Build plan
Deployment plan
Migration plan
Right-to-Leave plan
Corporate Exit plan
Governance plan
R&D ownership plan
Sustainability plan
Verification results
Certification level
Known limitations
Unresolved risks
Recommended next steps

Design Requirements

Sovereign implementations should:

Remain modular
Avoid vendor lock-in
Support independent implementations
Support stand-alone operation
Support federation
Prefer open protocols
Prefer documented interfaces
Prefer portable data formats
Support replaceable components
Preserve human oversight
Document dependencies
Document provenance
Document uncertainty
Support reproducibility
Support migration
Support system exit
Support long-term maintenance
Resist centralized capture
Identify economic value flows
Support participant economic participation
Protect research provenance
Respect applicable intellectual property rights
Avoid unnecessary reproduction of protected expression
Avoid unauthorized use of confidential information
Distinguish technical analysis from legal advice
Provide sufficient documentation for independent implementation

Fundamental Sovereign Test

A system should not be considered fully Sovereign merely because its source code is available.

A fully Sovereign system should allow people to:

Understand it
Build it
Operate it
Modify it
Reproduce it
Govern it
Repair it
Migrate it
Leave it
Replace its dependencies
Federate it
Fork it where permitted
Sustain it
Participate in the value it creates
Continue operating when its original provider disappears

Sovereign treats ownership, autonomy, portability, reproducibility, economic participation, resilience, and exit as architectural properties rather than marketing claims.

Specification Branding License (SBL)

Standard

Fully AGPL-3.0+ compliant system
Copyleft enforced for network deployments
Required attribution:
- Roxanne Ardary
- https://www.roxanneardary.com/

Optional

Specification Branding License (SBL)
- Attribution-free commercial deployment
- Pricing based on scale, usage, and deployment scope
- https://roxanneardary.com/sovereign/

License & Notice Requirements

Sovereign is released under the GNU Affero General Public License v3.0 or later (AGPL-3.0+).

By contributing to any Open Arsenal project, you agree that your contributions will also be released under this license.

Please note the following:

All contributions must comply with the AGPL-3.0+ terms.
Under Section 7 of the license, all redistributions, forks, and derivative works must preserve attribution to Roxanne Ardary and roxanneardary.com.
Sovereign specifications are free to use with attribution. A Specification Branding License can be negotiated upon request.
The project’s notice.md file tracks attribution requirements and contributor acknowledgments. Any update that adds new contributors or modifies attribution should also update notice.md.
When submitting a pull request, ensure that any new files maintain the attribution headers where applicable.
Network-deployed versions of this software must also remain fully AGPL-3.0+ compliant, including exposure of source code modifications when applicable under the license.

For full legal details, please refer to the AGPL-3.0+ license and the project’s notice.md file.

Notice – Sovereign

Attribution Requirement: Under Section 7 of the AGPL 3.0+ license, all redistributions, forks, and derivative works, including network-deployed versions of this project, must provide attribution to Roxanne Ardary and roxanneardary.com.

Contributors

This file tracks contributors and their specific contributions to the project.

Roxanne Ardary, roxanneardary.com – August 20, 2026
Created the repository for Sovereign. Created the Sovereign specification for an AI system that transforms dependency-based systems into independently implementable, portable, federated, economically participatory alternatives where the people creating value can share in it.
[Add other contributors here] – [Date]
[Describe contribution in one sentence]

License – Sovereign

This repository is licensed under the GNU Affero General Public License v3.0 or later (AGPL-3.0+).

Key Points

You are free to use, modify, and distribute the code.
All redistributions, forks, and derivative works or network-deployed versions must also be licensed under AGPL-3.0+ and provide attribution to Roxanne Ardary and roxanneardary.com as required under Section 7 of the license.
The software is provided “as is,” without warranty of any kind.

For the full license text, see GNU AGPL-3.0 License.