67 lines
2.8 KiB
Markdown
67 lines
2.8 KiB
Markdown
# ADR 0003: Project license and upstream attribution boundary
|
|
|
|
- Status: Proposed
|
|
- Date: 2026-10-21
|
|
|
|
## Context
|
|
|
|
The Pirate Ray is intended to become open source, but the repository currently
|
|
has no project license. Rayforge and MeerK40t are both pinned under MIT terms,
|
|
and the leading architecture is a Rayforge addon informed by BalorMK behavior.
|
|
ADR 0002 forbids copied upstream source until license compatibility and exact
|
|
attribution are recorded.
|
|
|
|
## Proposed decision
|
|
|
|
1. License original The Pirate Ray code under MIT.
|
|
2. Keep exact upstream repositories, revisions, license notices and contract
|
|
hashes in the public repository.
|
|
3. Include applicable notices in every source or binary distribution set.
|
|
4. Treat Rayforge's documented addon API as the preferred host boundary.
|
|
5. Isolate any unavoidable internal Rayforge registry access behind one
|
|
compatibility adapter and remove it when a supported upstream API exists.
|
|
6. Use BalorMK as a pinned behavioral oracle until a separately reviewed
|
|
decision authorizes adaptation of specific MIT-licensed implementation
|
|
files.
|
|
|
|
## Why MIT is proposed
|
|
|
|
MIT matches both principal upstreams, is compatible with contributing the
|
|
addon upstream, and imposes a small, auditable notice obligation. It does not
|
|
solve safety, warranty, trademark or third-party-data questions; those remain
|
|
separate project responsibilities.
|
|
|
|
## Consequences
|
|
|
|
- A root project `LICENSE` can be added only after Kaz accepts this ADR.
|
|
- Source provenance becomes part of code review and release acceptance.
|
|
- A Windows installer may not be published alone; its verified license
|
|
sidecar and checkpoint manifest are part of the distribution set.
|
|
- BalorMK code adaptation must identify source files and preserve the
|
|
MeerK40t notice.
|
|
- A Rayforge upgrade fails closed when a pinned license, source hash or
|
|
required symbol changes.
|
|
|
|
## Alternatives considered
|
|
|
|
- **Remain unlicensed:** acceptable for research snapshots but blocks the
|
|
intended open-source product and upstream code adaptation.
|
|
- **Apache-2.0:** provides an explicit patent grant but adds notice and license
|
|
complexity without a current upstream requirement.
|
|
- **GPL-family license:** may be appropriate for stronger reciprocity, but it
|
|
is a larger product-policy decision and is not required by the current MIT
|
|
dependencies.
|
|
|
|
## Acceptance
|
|
|
|
Kaz must explicitly choose the project license. Until then this ADR remains
|
|
Proposed, the README's no-license statement remains authoritative, and no root
|
|
`LICENSE` file is created.
|
|
|
|
The compatibility-adapter part of item 5 is implemented for the offline addon
|
|
and fails closed outside Rayforge addon API 23. This implementation evidence
|
|
does not accept this ADR or select the project license.
|
|
|
|
See the
|
|
[upstream contract and license audit](../research/upstream-contract-and-license-audit.md)
|
|
for the evidence and API-stability assessment.
|