Your thoughts shouldn’t have a terms of service
The internet colonized communication. Social media colonized self-expression. Cloud AI is colonizing thinking itself.
This is not metaphor. The functional mechanisms are precise.
Communication required infrastructure. The infrastructure was built by companies that monetized the data flowing through it. The convenience of the infrastructure made it the default. The data became the product. Email became Gmail; SMS became iMessage and WhatsApp; the open protocols that the early internet ran on receded as people moved to convenient walled-garden alternatives. Each step traded sovereignty for convenience, and each step felt rational at the moment of the trade. By the time the cumulative trade had been made, the alternative was harder to reach, and the new defaults had been normalized to the point that people stopped noticing what they had given up.
Self-expression required venues. The venues were built by companies that monetized engagement. The convenience of the venues made them the default. The user’s identity became the substrate the platforms operated on. A blog became a Facebook post; a forum became a subreddit; a personal website became a Twitter account; a publication became a Substack newsletter. The pattern was the same: open infrastructure receded as people moved to convenient walled-garden alternatives, and the data the people produced — their thoughts, opinions, expressions, identities — became the product the platforms sold.
Cloud AI is the next stage. Thinking — the activity that has always been the most private a person engages in — now requires infrastructure. Drafts, half-formed ideas, questions you would not yet ask out loud, the working space where you decide what you actually believe: all of it is moving onto servers run by companies that monetize what passes through them. The default experience of using AI is to externalize one’s thinking onto a system that retains the externalization, learns from it, sells access to derivatives of it, and answers to no one for what it does with the residue.
The pattern is the same as the prior two stages. Convenience of the infrastructure makes the alternative harder to reach. The alternative — local AI, sovereign cognitive infrastructure — exists now, but only barely, and only because deliberate intervention has preserved it. Without that intervention, the alternative would not exist by the time most people noticed they wanted it.
The phrase “your thoughts shouldn’t have a terms of service” names the structural problem. Subjective experience has been the last inviolable private space. The colonization of thinking is the last colonization. After this, there is nothing left to colonize.
The structural answer is local compute.
What sovereignty means here
Sovereignty over an AI system means the user owns the stack. Their machine runs the system. Their filesystem holds the data. Their network is the only network the system needs. Their model relationships — whether to a frontier lab’s API, to a local open-weights model, or to multiple models swapped as needed — are theirs to configure and reconfigure.
A sovereign system has five properties:
Local compute by default. The system runs on the user’s machine. The user’s data stays on the user’s machine. The user’s queries reach a model only when the user explicitly chooses the model relationship that requires it, and the model relationship is the user’s, not the system’s. The default is local; the network call is the exception. This inverts the cloud-AI default, where the network call is everything and local processing is the exception. The inversion matters at every layer: drafts the user never sends to a model never leave the machine; conversations the user has with a local open-weights model never reach any vendor; queries that do go to a frontier lab’s API are auditable by the user (the user can see what is being sent, when, and why) rather than abstracted into the system’s invisible operations.
Model-agnostic architecture. The system does not depend on any particular model. The user can route queries to whatever combination of models serves the user — a frontier model for some kinds of work, an open-weights local model for sensitive work, a specialized model for niche domains. Lock-in to a specific lab’s models is exactly what the architecture rejects. The user’s relationship is with the harness, not with any one model. As models improve at the open-weights tier, the user’s local capability improves; as frontier models compete on price and capability, the user can route to the best fit per query rather than committing to a single vendor’s roadmap. The architecture survives whatever the model layer does.
Forkable structure. The system is open-source under the most permissive disposition possible — public-domain dedication, not copyleft. Any user can take the architecture, modify it for their needs, redistribute their modifications, or build something entirely new from it. The original maintainers cannot revoke this; the code is in the public domain irreversibly. The fork ecosystem is not just a permission structure; it is the operational mode through which the architecture stays adapted to user needs the original maintainers did not anticipate.
The user’s vault is the user’s. Persistent state — every conversation, every framework run, every piece of accumulated context — lives in standard formats on the user’s filesystem. Markdown, JSON, plain text. The user can copy it, back it up, examine it, search it, take it to a different system. Nothing about the architecture creates lock-in at the data layer. The user’s accumulated cognitive work compounds across years; the substrate of that compounding is durable, portable, and the user’s.
Public-domain release of the available stack. The Ora project has released selected architecture, frameworks, and documentation under CC0 1.0 Universal. The dedication attached to each artifact is the source of truth. Those releases need no Foundation permission and are irreversible to the extent the dedication applies. A Foundation knowledge library and institutional stewardship of a broader corpus remain proposals, not current releases or services.
These properties are interlocking. Removing any one of them undermines the others. A model-agnostic system whose data is locked to a vendor’s format is not sovereign — the format lock-in is enough to compromise the user’s leverage. A local-compute system whose codebase is proprietary is not sovereign — the user is dependent on the vendor’s continued goodwill for updates, security patches, and compatibility with new platforms. A forkable codebase whose canonical version requires a vendor’s keys to operate is not sovereign — the dependency reasserts itself at the API layer. The properties have to compose, or the sovereignty claim does not hold up under stress.
Your system, your models, your rules
The slogan is precise. Each clause carries operational weight.
Your system. The user runs the harness. The harness’s source code is on the user’s machine. The user can read it, modify it, replace components, write extensions. The harness is the surface the user interacts with; the user owns that surface in a way that has no analog in cloud-AI products, where the surface is the vendor’s UI. A user who has run Ora for two years has a harness that is, in any specific way that matters, configured to that user. The configuration is the user’s investment. The investment is durable because the harness is the user’s.
Your models. The user picks the model relationships. A configured system might use a local open-weights model for most queries, a frontier model for the small subset of queries where capability difference is decisive, a specialized model for niche domains where a fine-tuned variant outperforms the generalist frontiers. The user can change the picks any time. The user can run model A on Monday and model B on Tuesday and check whether the difference matters. The user can route the same query to multiple models in parallel, which is what the adversarial pipeline does for reliability and what the user can also do voluntarily for any query where comparing perspectives is useful.
Your rules. The configuration determines what the system will do, what it will not do, what topics it will engage with, what model relationships it will use, what it will log, what it will not log. The user is the one who sets the rules. The system does not have policies the user has not explicitly accepted; it does not have data-collection practices the user has not explicitly enabled; it does not have content moderation the user has not explicitly chosen. The rules are the user’s because the configuration is the user’s.
The contrast with cloud AI is not subtle. Cloud AI products have policies. The policies change. The change happens through corporate decision-making the user has no role in. The user accepts the changes by continuing to use the product, because the alternative — exiting — costs the accumulated context the product holds. The user’s leverage is one-directional: the user can leave and lose the accumulated context, or stay and accept the new policies. There is no third option in the cloud architecture. There is, in a sovereign architecture, because the leverage runs the other way.
The Orwell connection
This section sits in the deeper part of the page, for visitors who reach it. The mainstream argument for sovereignty does not need it; the deeper argument benefits from it.
George Orwell’s Nineteen Eighty-Four turned on a specific structural commitment: the protagonist’s thoughts were not safe. Not because the surveillance apparatus could read minds, but because the apparatus could observe enough externalized behavior — what was written, what was said, what was glanced at — to reconstruct the inner state with enough fidelity to act on it. The novel’s terror is not in the watching; it is in the structural impossibility of having a private thought once the externalization has reached a sufficient density. The protagonist’s diary is a small attempt at sovereignty in this sense, and the failure of the diary is the moral center of the book.
Cloud AI changes the externalization density. Where the externalization used to be optional — a person could think privately by simply not writing anything down — the externalization is increasingly required by the way work is done. The user who drafts a memo using cloud AI has externalized their working draft to a server. The user who works through a problem in conversation with a chat product has externalized their reasoning. The user who asks a system to help them figure out what they actually believe about a contested question has externalized the question and the working-through.
This is not a paranoid framing. The externalization is the product. The vendor’s business model depends on it: the data is what trains the next model, the conversation history is what creates lock-in, the user’s accumulated context is what makes the system useful for that user specifically. The user’s externalized thinking is not an unfortunate side effect; it is the value the vendor extracts. The vendor’s terms of service exist to formalize what the vendor extracts and to limit the vendor’s exposure for extracting it.
The Orwellian frame is not the right framing for the immediate threat. The labs are not state actors trying to suppress dissent. The labs are commercial actors monetizing externalized cognition. The threat is not totalitarian; it is platform-capitalist. But the structural problem is the same one Orwell identified. Once the externalization density is high enough, the inner life becomes inferable from the outer behavior, and the entity that has access to the externalization has access to the inner life. The Orwellian terror is the recognition that this density is achievable and that, once achieved, it cannot be simply walked back.
The state-actor version of the threat is also not absent. Cloud AI vendors comply with subpoenas. They comply with national security letters. They comply with the legal frameworks of jurisdictions where they operate, including jurisdictions whose legal frameworks include compulsory disclosure of user data. A user whose cognitive work runs through a vendor’s servers is, in the relevant legal jurisdictions, exposing that work to whatever the vendor’s compliance team is required to surface. The user’s privacy from the vendor is not the same thing as the user’s privacy from the legal apparatus that can compel the vendor’s disclosure.
Local compute eliminates the surface. A user whose cognitive work runs on their own machine has, on that work, the privacy that the law accords to the contents of one’s own filesystem and one’s own memory. That privacy has its own limits — search warrants, device seizure, compelled disclosure under specific legal frameworks — but those limits are the limits the law has long worked out for personal property. The limits of cloud-AI privacy are limits the law has not yet worked out, on a substrate the law was not designed for. Local compute keeps the substrate where the legal protections are mature.
This is the deeper argument for sovereignty. Not just convenience or values; the underlying structure of what counts as private. Subjective experience has been the last inviolable private space because nothing externalized it at sufficient density to make the inner life readable from the outside. Cloud AI is the technology that breaks that assumption. The structural answer is to keep the externalization private — to have the thinking happen on a substrate the user owns, in a format the user controls, on a device the user can keep offline if they choose.
The convenience market and the sovereignty market
Sovereignty is not free. It requires the user to manage their own model relationships, accept responsibility for their own setup, and tolerate higher friction at the boundary where the system meets the rest of their digital life. The convenience market exists because not everyone wants to do that work.
The convenience market is the one the commercial AI labs serve. Hosted services. Integrated experiences. Premium tiers. Opinionated defaults. Low cognitive cost to use. The convenience market is real, large, and durable. People who want a polished product they can subscribe to and use without thinking about it will continue to choose commercial services, and that choice is legitimate.
The sovereignty market is the one Ora’s architecture serves. Local compute, forkable architecture, public-domain release, the user’s vault, the user’s frameworks, the user’s data. Higher cognitive cost to set up and maintain; lower cognitive cost over the long arc, because the user’s leverage stays with the user. The sovereignty market is real, large, and growing. It includes:
- Professionals whose work cannot leave their machines — clinicians with patient data, attorneys with privileged communications, researchers with embargoed findings, journalists with confidential sources, anyone working under non-disclosure terms that conflict with cloud-AI usage policies. For these users, the choice is not preference; it is a precondition of the work. The cloud-AI alternative is not an alternative.
- Families who don’t want their children’s questions reaching servers — parents who think children’s developmental questioning deserves privacy and who recognize that “free” services for children are services where the children are the product. A child’s question record is among the most private things a child generates; the cloud-AI default of retaining it indefinitely on commercial servers is a default the parent does not choose for the child.
- Displaced workers who need cognitive automation as a tool of practice rather than a service they pay for — the population the convenience market underserves because the convenience market’s pricing is calibrated to enterprise budgets, not to households that have just lost a paycheck. Free public-domain frameworks running on a local machine, with model relationships at the open-weights tier or rationed frontier-API access, give displaced workers the same tools the institutions displacing them are using.
- Organizations whose mandate or values require local control — public libraries, educational institutions, advocacy organizations, journalism outlets, religious institutions — whose data should not flow through commercial actors’ systems. For these organizations, the cloud-AI alternative may technically be available but is structurally inappropriate; the institutional commitment to its constituents’ privacy is incompatible with the cloud architecture’s data-handling defaults.
- Populations in jurisdictions or financial circumstances that make commercial services impractical — developing markets where AI provider accounts are difficult to obtain, communities where the absolute price of subscription services is prohibitive, contexts where the legal framework around cross-border data flows is hostile to commercial cloud services. The sovereignty market includes the global majority by default; the convenience market is calibrated to the small fraction of the world’s population that can pay enterprise prices and operate within the small set of jurisdictions where cloud-AI vendors comfortably do business.
Both markets coexist. Neither replaces the other. The choice between them is a values choice as much as a product choice — what does the user trade for what?
Ora does not compete for the convenience market or claim moral superiority over those who choose it. Its public-domain architecture is intended to make the sovereignty market a more practical option. A future Foundation could extend that work, but no institutional access or support service operates today.
Why public-domain over open-source
Open-source licensing depends on copyright as a lever. Public-domain dedication releases that lever. CC0 is the most permissive disposition possible, and it is the disposition that makes enclosure attempts pointless in advance: there is nothing to acquire that is not already free.
The choice is deliberate. Copyleft licenses (GPL, AGPL) preserve the public-domain character of derivative works by requiring that derivatives also be open-source. They use copyright to enforce openness. Permissive open-source licenses (BSD, MIT) allow derivatives to be closed but require attribution. Both depend on the licensing apparatus to do their work.
CC0 takes the apparatus off the table entirely. There is no license to comply with. There is no enforcement to bring. The artifacts have already been dedicated to the public domain to the maximum extent permitted by law. Anyone can use, modify, distribute, build upon, fork, or republish any artifact for any purpose, on the same terms — commercial use, modification, redistribution, inclusion in derivative works, all permitted on identical terms.
The reasoning is structural. Conditions on use — even conditions as light as attribution — are conditions, and conditions can become disputes, and disputes can become enclosure pressure. A commercial actor that finds a license condition inconvenient has an incentive to challenge the license. A public-domain dedication has no condition to challenge.
The Ora project has dedicated selected artifacts to the public domain rather than reserving ownership as a future institutional lever. A future Foundation could act as steward rather than owner, but it does not currently hold trademarks or certification marks, operate legal-defense partnerships, or maintain an institutional defensive-publication program.
This choice has a cost. Anyone can use CC0-dedicated Ora artifacts in proprietary products without contributing back. A commercial actor that takes a released framework, wraps it in a closed product, and sells access to the closed product is doing something that copyleft would have prohibited. The project accepts this cost because the alternative cost — maintaining a copyleft enforcement apparatus, dealing with the licensing-compliance theater that copyleft requires, and running the risk that a license condition gets challenged in a jurisdiction where the challenge succeeds — is higher. The cost is also less load-bearing than it appears: a closed product wrapping a freely available CC0 framework has to provide value beyond the framework itself.
The fork ecosystem as concrete commitment
Public-domain release without an active fork ecosystem risks remaining theory. A living fork ecosystem would make the public-domain dedication more useful in practice; no Foundation-managed ecosystem is operating today.
Forking, in conventional open-source contexts, has been the programmer’s privilege. Modifying a codebase requires programming skill, and most users do not have it. The result is that even projects with permissive licenses tend to centralize in practice; users end up consuming whatever the core maintainers ship, not because they could not modify it, but because modifying it requires capabilities they do not have.
Ora inverts this. The frameworks — the substantive cognitive content of the system — are written in natural language, not code. Modifying a framework requires domain expertise, not programming skill. A legal aid attorney can modify a benefits-application framework because she knows what the form requires. A clinician can modify a medical-information-synthesis framework because he knows what clinical conversation actually looks like. A teacher can modify a learning-support framework because they know what their students need.
Natural language is the source code. This is not a slogan. It is the structural property that makes the public-domain dedication accessible to populations conventional open-source licensing has not reached.
Forking is therefore more than legal permission; it is an available way to adapt Ora. Domain experts can fork the source and add modes for their fields. The core maintainers cannot prevent it; the licensing does not constrain it; the architecture is built to accommodate it. This possibility should not be confused with an existing contribution or reconciliation service.
The reconciliation loop
Forks would not necessarily have to fragment a future shared corpus. A proposed Foundation library could adapt a reconciliation pattern from successful open-source governance.
If a future Foundation created a library, published specifications, and opened an intake process, a beneficial fork could be submitted for review. A future specification might cover input and output formats, version control, documentation, and testing. Review, acceptance, attribution, and distribution would be future institutional mechanisms. Independent forks can be published now without Foundation involvement.
The intended flow would run in both directions: a shared library could provide a substrate, forks could add alternatives, and accepted additions could return to the shared catalog. Apache projects, Wikipedia article editing, and Creative Commons license stewardship are relevant precedents, but they do not establish that an Ora contribution system already exists or guarantee that one will succeed.
Two proposed commitments could keep such a loop from becoming gatekeeping. Multiple frameworks for the same task could coexist, and forks or independent collections would remain usable without Foundation approval. Any future Foundation library would be one option, not the authoritative version.
The hoped-for result would be a corpus that grows through community contribution, stays coherent through published specifications, and remains usable beyond the institution because its artifacts are public-domain. That result has not yet been implemented.
Why decentralized hosting matters
A proposed knowledge library could be continuously updated, provenance-weighted, freely distributed, and hosted on decentralized public-domain infrastructure rather than concentrated on Foundation servers. No such Foundation library or hosting network currently exists.
A knowledge library hosted on a single server would be a single point of enclosure failure. If a future Foundation were captured, defunded, sued out of existence, or dissolved, a centrally hosted library could disappear with it. A library hosted on distributed infrastructure could persist regardless of what happened to the institution, making the public-domain commitment operational at the data layer.
Three established patterns compose into the architecture:
Content-addressed storage. Library content could be addressed by cryptographic hash rather than by location. The same content would have the same address on any node that hosted it. IPFS-class infrastructure is an existing reference pattern, not a deployed Foundation system.
Distributed hosting through volunteer nodes. A future library could be hosted across independent nodes run by partner organizations, volunteer operators, universities, libraries, or other willing parties. The Foundation does not currently operate nodes, coordinate a hosting network, or claim any of those organizations as partners.
Cryptographic provenance verification. A future implementation could translate Ora’s conceptual provenance hierarchy into cryptographic signing of canonical documents. A user could then verify a document’s claimed provenance without trusting the node that served it. No Foundation signing authority or cryptographic provenance system currently operates.
The proposed institutional role would be specification authorship and, if established, a signing authority rather than exclusive hosting. Institution as authority, network as infrastructure. This separation could let a library persist beyond the institution while preserving verifiable provenance; it is a design goal, not current architecture.
Such an architecture could itself become a defense mechanism. Enclosure attempts would have to compromise enough of the network to render a shared version inaccessible, which is harder than compromising a single server. This is the rationale for the proposal, not a claim that decentralization has been deployed.
What sovereignty does not promise
Sovereignty is not safety. The user owning the stack does not protect them from making bad decisions with the system, from encountering malicious frameworks, from configuring their model relationships in ways that leak data they did not intend to share, or from the consequences of the underlying models being trained on whatever those models were trained on. Sovereignty pushes responsibility back to the user, where in the AHI frame it belongs, but responsibility is a heavier thing than convenience and not everyone wants to carry it.
Sovereignty is not anti-commercial. Ora’s public-domain strategy does not oppose commercial software, the labs’ products, or the convenience market. The convenience market is real, durable, and serves the people who choose it well. Sovereignty is an alternative for people who want it, not a moral judgment against people who do not.
Sovereignty is not a promise that distributed power produces good outcomes automatically. It is the more modest claim that concentrated power produces bad outcomes systematically, and that distributed power preserves the possibility of good outcomes. Ora’s existing public releases preserve part of that possibility; proposed Foundation work could extend it. The realization belongs to everyone who actually uses the technology.
What sovereignty does promise
The user’s leverage stays with the user. The system cannot decide tomorrow that it owns something it released to the public domain today. The model can change, the lab can change, a future Foundation can change, and the user’s accumulated work — the conversation history, the customized frameworks, the vault, the integrations the user built — survives those changes because none of those entities owns the user’s local data.
The architecture cannot be enclosed. Once dedicated to the public domain, the artifacts cannot be reclaimed. No future Foundation, no successor entity, no party that acquires the Foundation’s assets, no jurisdiction’s regulatory action — none of these can re-enclose what has already been freed. Public-domain dedication is irreversible by design.
The cognitive infrastructure already released under CC0 remains free under its actual dedication. As cognitive automation becomes more integral to how people think, work, and communicate, the question of whether the substrate is enclosed or free becomes a civilizational-scale question. Ora’s release strategy, and the proposed future Foundation work, rest on the judgment that preserving a free option is worth the effort.
The summary
Privacy and sovereignty in the cognitive layer are not luxuries. They are structural conditions under which thinking remains the user’s. The technical-architectural answer includes local compute, a model-agnostic harness, a forkable codebase, the user’s vault, and public-domain release. Decentralized hosting of a future knowledge library could extend those properties at the shared-data layer; it is not deployed today.
The convenience market is durable and legitimate. The sovereignty market is durable and legitimate. Ora’s current work makes part of the sovereignty option real; a future Foundation could make it more accessible and substantive. The choice is values as well as capability. What differs is what the user trades for what. The trade you can refuse to make is the trade where your thoughts pay rent to a vendor whose business model requires them.