---
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](pds-xrpc.md) 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](pds-xrpc.md) 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](pds-xrpc.md)'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.