ADR 0003: License — Apache 2.0

Summary

aidokit and every package published under the @aidokit/* scope are licensed under Apache License, Version 2.0. The choice is deliberate: it is the most-permissive licence that carries an explicit patent grant, is broadly compatible with the surrounding ecosystem, and is recognised by enterprise legal review without negotiation. The LICENSE file at the repository root is drafted but explicitly not legally reviewed pre-v1.0; reviewer sign-off is a v1.0 GA exit criterion.

Context

aidokit is an open-source CLI intended to grow an ecosystem of third-party adapters and stack packs. The licence choice affects:

• Who can adopt the tool. Enterprise users have legal-review processes that effectively allowlist a small set of licences. A licence outside that set blocks adoption.
• Who can build on top. Adapter authors may want to ship commercial products built on @aidokit/core. The licence must not require them to open-source their own work.
• What patent exposure contributors face. Without an explicit patent grant, contributors who hold patents could later assert them against users — a known failure mode that the Apache 2.0 patent clause directly addresses.
• Compatibility with consumed dependencies. Anything aidokit pulls from npm must be compatible with our outbound licence. Conversely, distributors that bundle aidokit (npm registries, downstream forks, corporate mirrors) must be able to redistribute without friction.

The surrounding ecosystem context:

• The README badge already asserts Apache 2.0.
• The ROADMAP lists "Published LICENSE finalization (drafted, not legally reviewed)" as out of scope for v0.1 — the licence is decided; only the formal review is deferred.
• Many of aidokit's closest neighbours are Apache 2.0 (Kubernetes, Docker, OpenTelemetry, Tekton, Backstage). Apache 2.0 packages and tools predominate in the cloud-native and developer-tooling space.
• Some neighbours are MIT (most of the Node ecosystem, including pnpm, Turborepo, Vitest). Apache 2.0 is one-way-compatible: an Apache 2.0 project can consume MIT dependencies; the reverse is also allowed at the file level.

This ADR records the decision and the reasoning so a future contributor can answer "why not MIT?" without re-litigating it.

Decision

1. The licence is Apache License, Version 2.0

The full text of the licence is placed at the repository root as LICENSE. The SPDX identifier is Apache-2.0. Every published package.json MUST set:

{
  "license": "Apache-2.0"
}

2. The licence applies to every @aidokit/* package and to the unscoped aidokit CLI

All packages under this monorepo inherit the root licence. There is no per-package licence override. Third-party adapters and stack packs (post-v1.0 SDK era) MAY choose their own licence; the @aidokit/core Apache-2.0 grant lets them.

3. A NOTICE file is maintained at the repository root

Apache 2.0 §4(d) requires preservation of NOTICE content from included third-party works. A minimal NOTICE file lists:

• Copyright holder and year for the aidokit project itself.
• Attribution to any bundled third-party assets that carry their own NOTICE requirements (currently none; the file will populate as dependencies accrue).

The NOTICE file is not for general acknowledgements — those live in README.md. It is a legal artefact tied to the licence.

4. No per-file licence header is required

Apache 2.0 §4(a) requires distributors to retain notices, not that authors prefix every file. We do not require a top-of-file licence comment in source files. The repo-level LICENSE and NOTICE files plus the package.json license field satisfy the requirements.

This decision can be revisited if a downstream legal review demands per-file headers; until then, we optimise for diff readability and onboarding speed.

5. Contributor licence agreement (CLA) is not required at v0.1

Contributors implicitly licence their contributions under the project licence by submitting a PR (the GitHub Terms of Service "inbound = outbound" rule). A formal CLA or DCO requirement is deferred to v1.0; the trade-off (legal clarity vs. contribution friction) will be revisited then.

6. The LICENSE file is drafted but not legally reviewed at v0.1

The text is the canonical Apache 2.0 text from the Apache Software Foundation. The copyright line names the project. Legal review by counsel is a v1.0 GA exit criterion (per .docs/ROADMAP.md). Until reviewed, the README and the LICENSE file MUST both state this status.

7. SECURITY.md and trademark policy are out of scope here

SECURITY.md (vulnerability reporting) and trademark policy (use of the aidokit name) are separate documents on the v1.0 critical path. They reference but do not modify this licence decision.

Consequences

Positive

• Patent grant. Contributors and users gain the §3 patent licence from contributors. This is the single largest delta over MIT.
• Enterprise-friendly. Apache 2.0 is on every major enterprise allowlist. No legal-review escalation required for typical adoption.
• Commercial use unblocked. Third-party adapter authors can build proprietary products on @aidokit/core without exposing their source.
• Compatible with the dependency surface. MIT, BSD, and ISC dependencies (the bulk of npm) consume cleanly into an Apache 2.0 distribution.
• Familiar. Contributors do not need a tutorial — Apache 2.0 is the most common licence in the developer-tooling space.
• Trademark clause. §6 of the licence prevents trademark misuse without granting trademark rights — useful even before a formal trademark policy is published.

Negative

• Not GPL-compatible (v2). Code from GPL v2 projects cannot be imported into aidokit without a one-way relicensing. We accept this because we do not currently depend on GPL v2 code and don't intend to. GPL v3 is one-way compatible with Apache 2.0 in the GPL v3 → Apache 2.0 direction (we cannot import GPL v3 code either).
• Longer than MIT. The Apache 2.0 text is ~200 lines vs. MIT's ~20. Readability of the LICENSE file is slightly worse. Mitigated: the file is rarely read.
• NOTICE file maintenance. Adding a dependency that carries its own NOTICE requires updating ours. Easy to forget. Mitigated: a CI check (post-v0.5) can compare the assembled NOTICE against a generated SBOM.
• No CLA. A future legal dispute over a contribution's provenance is marginally harder without a CLA on file. Mitigated: GitHub's inbound = outbound rule is enforceable; CLA is a v1.0 addition if needed.

Neutral

• Cannot relicense unilaterally. Once contributors have submitted code under Apache 2.0, the project cannot retroactively relicense without their consent. This is true of every OSS licence in this category; we accept it.
• Sets precedent for adapter and stack-pack SDKs. The first-party SDK packages (post-v1.0) will inherit Apache 2.0. Third-party SDK consumers remain free to pick their own licence.

Alternatives considered

Alternative 1: MIT

The simplest permissive licence: short, well-understood, ubiquitous in the Node ecosystem.

Pros

• ~20 lines, trivial to read.
• Maximum compatibility with downstream relicensing.
• Familiar to every JS/TS developer.

Cons

• No explicit patent grant. Contributors who hold patents could later assert them.
• Less trademark protection.
• Slightly weaker in enterprise legal review than Apache 2.0 (only because of the missing patent clause).

Reason rejected: the missing patent grant is the deciding factor. We expect contributions from corporate engineers whose employers hold patents; a project that grows into an ecosystem layer should make the patent posture explicit and reciprocal.

Alternative 2: BSD 3-Clause

Similar permissive shape to MIT with an added "no endorsement" clause.

Pros

• Short and familiar.
• The no-endorsement clause is mildly useful for trademark adjacency.

Cons

• No patent grant (same as MIT).
• The no-endorsement clause is weaker than the trademark clause in Apache 2.0.

Reason rejected: same patent-grant gap as MIT, without the simplicity advantage.

Alternative 3: Dual MIT / Apache 2.0 (Rust-style)

Common in the Rust ecosystem: users pick one of the two licences.

Pros

• Maximum downstream flexibility.
• Combines MIT's brevity with Apache 2.0's patent grant for users who pick it.

Cons

• Doubles the legal surface in the LICENSE file.
• Confuses tooling — many SBOM generators and licence scanners don't handle dual licences well.
• The MIT half does not provide the patent grant; sophisticated consumers will pick Apache 2.0 anyway.

Reason rejected: complexity without commensurate benefit. If the Apache 2.0 patent grant is valuable, we want everyone to receive it.

Alternative 4: MPL 2.0 (Mozilla Public License)

File-level copyleft: modifications to MPL-licensed files must remain MPL, but the rest of the work can be any licence.

Pros

• Encourages upstream contributions (modifications must be shared back at file granularity).
• Compatible with commercial use.

Cons

• File-level copyleft is awkward for a scaffolder that emits files into user projects. Are the emitted files subject to MPL? (Probably not under §1.10's "Modifications", but the question alone is friction.)
• Less familiar to enterprise legal review than Apache 2.0.

Reason rejected: the file-level question creates ambiguity about what users own when aidokit init emits files into their project. Apache 2.0 has no such ambiguity.

Alternative 5: GPL v3 / AGPL v3

Strong copyleft: derivatives must also be GPL/AGPL.

Pros

• Forces contributions back upstream.
• Prevents proprietary forks.

Cons

• Blocks the ecosystem story. Third-party commercial adapters become impossible under AGPL; difficult under GPL v3.
• Blocks enterprise adoption in many shops.
• One-way incompatible with permissive consumers.

Reason rejected: aidokit's strategy depends on third parties building adapters and stack packs, including commercial ones. Copyleft kills that motion.

Alternative 6: Unlicense / 0BSD / public domain

Maximally permissive: no restrictions, no requirements.

Pros

• Simplest possible legal posture.

Cons

• Some jurisdictions don't recognise public-domain dedication.
• No patent grant.
• No retention-of-notice clause means downstream forks can strip attribution legally.

Reason rejected: we want some protection (patent grant, notice retention, trademark clause); public-domain-style licences provide none.

Implementation notes

Files at the repository root

• LICENSE — full Apache 2.0 text (canonical text from https://www.apache.org/licenses/LICENSE-2.0.txt). Created as a follow-up task to this ADR.
• NOTICE — minimal at v0.1; one block for the aidokit project copyright. Populated as third-party NOTICE requirements accrue.
• README.md — already badges Apache 2.0; no change required.

package.json fields

Every published package MUST include:

{
  "license": "Apache-2.0"
}

Optional but recommended:

{
  "author": "AIDO maintainers",
  "repository": { "type": "git", "url": "https://github.com/<org>/<repo>" }
}

Copyright line

The copyright line in LICENSE reads:

Copyright {year-of-first-release} {project owner or maintainer entity}

The exact owner string is a v1.0 decision (individual maintainer vs. a created entity vs. a foundation). For the alpha, the maintainer's name is acceptable.

Third-party licence tracking

• pnpm licenses list (built into pnpm) is the v0.1 audit tool.
• A CI step in v0.5+ compares the audit output against an allowlist and fails on disallowed licences (specifically: any copyleft licence appearing in dependencies triggers manual review).
• The allowlist starts as: Apache-2.0, MIT, BSD-2-Clause, BSD-3-Clause, ISC, CC0-1.0, Unlicense, 0BSD.

Validation

This decision is validated when:

• [ ] LICENSE file exists at the repository root with canonical Apache 2.0 text.
• [ ] NOTICE file exists at the repository root with at least the aidokit copyright line.
• [ ] Every package.json in the workspace declares "license": "Apache-2.0".
• [ ] No dependency in the workspace's transitive tree carries a copyleft licence (verified by pnpm licenses list).
• [ ] By v1.0, the LICENSE and NOTICE files have been reviewed by counsel and the README's "drafted, not legally reviewed" caveat is removed.

References

Internal

• ADR 0001 — Runtime + language
• ADR 0002 — Monorepo tooling
• ADR 0004 — Distribution (carries the npm publish surface where licence metadata lives)
• .docs/README.md — License badge and acknowledgements
• .docs/ROADMAP.md — LICENSE finalisation listed as out-of-scope for v0.1

External

• Apache License, Version 2.0 — https://www.apache.org/licenses/LICENSE-2.0
• Apache 2.0 FAQ — https://www.apache.org/foundation/license-faq.html
• SPDX licence identifier list — https://spdx.org/licenses/
• "GPL v3 and Apache 2.0 compatibility" — https://www.apache.org/licenses/GPL-compatibility.html
• GitHub Terms of Service §D.6 — inbound = outbound licence convention