id: license title: The project has no license, and three different things need one status: open crates: [] dependsOn: [] exitCriterion: > A LICENSE file exists at the repository root, the lexicons state their own license independent of the code's, and every vendored corpus's license has been checked for compatibility with whatever is chosen. #

license #

The decision has already been made by metadata, and the file it names does not exist. Cargo.toml declares license = "MIT" at the workspace root and every crate inherits it through license.workspace = true — so the code ships under a stated licence today. There is no LICENSE file anywhere in the repository. That is the gap this epic's exit criterion is really about: not choosing a licence, which has effectively happened, but writing it down where a reader looks for it, and checking it against the vendored licences below.

There is no LICENSE file anywhere in this repository. That is a decision by omission — under most jurisdictions' default copyright rules, "no license" means no rights are granted to reuse the code at all, which is probably not what a project inviting federation intends, and is certainly not something a stranger reading docs/deployment.md or building against bot.did.* can safely assume either way.

This epic does not pick a license. It lays out what the decision covers, because "the project's license" is actually three separable decisions with different audiences and different consequences, and picking one without naming the other two leaves the other two undecided by default rather than by choice.

The code #

The Rust workspace under crates/, docs/, and everything else that is this project's own implementation. The choice here is the ordinary open-source one — permissive versus copyleft, and whether contributions need a CLA — and it mostly affects other implementers who might build on didbot itself rather than build a different server that talks the same protocol.

• Decide the code's license, or decide it stays unlicensed deliberately and say so — "no license" is a legitimate choice, but an undocumented one is not the same as a considered one.

The lexicons #

bot.did.* is this project's schema contribution, and pds-xrpc already flags the domain as unregistered and the namespace as "a placeholder." A schema is different from code in one way that matters here: others may need to implement against it. A relay, an indexer, or a competing server implementation that wants to read a bot.did.registration record needs to know the record's shape, and a restrictive code license sitting over the lexicon JSON could be read as restricting implementing the schema, not just reusing this project's Rust. Bluesky's own app.bsky.* and com.atproto.* lexicons ship under terms chosen specifically to keep that door open.

• Decide whether the lexicons carry their own, more permissive license than the code, the way com.atproto.*'s upstream documents do. This matters most for the eventual "real namespace" item pds-xrpc lists as open: whatever the namespace becomes, its schema documents' terms travel with every record anyone else's server ever validates against them, permanently — a collection name "cannot be taken back once records exist elsewhere," in that epic's own words, and neither can a license retroactively tightened after other implementations already depend on the looser one.

The vendored interop corpus #

vendor/atproto-lexicons/ and vendor/atproto-interop-tests/ are copied into this tree — vendor/atproto-lexicons/, per pds-xrpc's Done list, "copied unedited from the atproto repository" and used as the source of truth the conformance harness checks responses against. Both directories carry their own license files already: vendor/atproto-lexicons/ ships LICENSE.txt, LICENSE-APACHE.txt and LICENSE-MIT.txt; vendor/atproto-interop-tests/ ships LICENSE-CC0.

• Confirm what each vendored license actually permits, since "vendored unedited" is a stronger claim than "compatible with whatever this project picks" — dual Apache/MIT and CC0 are both broadly permissive, but the check is what this project's own chosen license, once picked, is allowed to do sitting alongside them in one repository, not an assumption that permissive-sounding names are automatically compatible.
• Say whether the vendored corpus's presence constrains the code license, or whether the two are cleanly separable because the vendored directories are read-only fixtures the build never links into a distributed artifact. This is a fact to check, not a preference — an include! or a build-time embed changes the answer from a cargo test dependency to something that ships.

Done #

Nothing closed yet.