ADR-018: Code, Data And Third-Party Licensing

• Status: Accepted
• Date: 2026-08-18
• Roadmap task: F1-010
• Decision owners: project and data provenance maintainers

Context

Munderecat contains software, documentation, project-produced certification data and visual legacy references. Future phases may add source text, translations, Ottoman forms, dictionary material and annotations from several origins. One repository-wide license would blur two different questions:

1. Under what terms may project-authored code and documentation be reused?
2. Which rights, if any, may the project grant in a database and its individual contents?

Public availability is not a license. Deriving hashes, boundaries or annotations from a source also does not automatically transfer copyright in the underlying text. Conversely, leaving project-authored code and data unlicensed prevents the open collaboration this repository is intended to support.

Relevant references:

• OSI MIT License
• Creative Commons Attribution 4.0
• Creative Commons guidance for data and databases

Creative Commons states that version 4.0 licenses can cover copyright and applicable sui generis database rights, but providers must hold the rights they license and clearly demarcate excluded contents.

Decision

Software And Documentation

Project-authored software source code and project documentation use the MIT License in root LICENSE. The standard text is not modified. Copyright is identified as 2026 Munderecat contributors so later contributors do not need a central copyright assignment.

MIT does not cover data merely because data is processed by the software.

Project-Authored Data

Project-authored data/database rights use CC BY 4.0 under root LICENSE-DATA. The grant currently covers project-produced manifests, baselines and schemas under data/, except material explicitly excluded by path or notice.

Future annotation, alignment and curated database releases do not inherit the license from their directory alone. Their release manifest must positively record rights basis, attribution and license classification. This prevents an imported third-party content item from being silently relicensed by location.

Attribution identifies Munderecat contributors, artifact/release identity, license and canonical project/release location; modifications must be stated.

Excluded Contents

The project grants no rights it does not hold. Root NOTICE.md and LICENSE-DATA explicitly exclude:

• legacy frontend screenshots and their displayed contents,
• source/facsimile/rendered text,
• translations, dictionary/lexicon contents and Ottoman source material,
• legacy repos, databases, backups and private extraction artifacts,
• third-party packages and media,
• any imported record without a release-level rights classification.

Current screenshots remain in Git because F0 uses them as fixed regression evidence. This operational retention is not a downstream reuse grant.

Third-Party Dependencies

Lockfiles reference, but do not relicense, external packages. Installed package trees and binaries remain outside Git. Release packaging must derive notices from its exact resolved dependency graph; this general NOTICE is not a frozen bill of materials for every future build.

Consequences

Benefits

• Project-owned code and data become reusable under standard licenses.
• Code and data attribution obligations are not conflated.
• Source-content uncertainty cannot spread through a directory-wide implied grant.
• A future release can include mixed provenance while retaining record/package specific rights and notices.
• External contributions can use the same two license lanes without a CLA or DCO, once intake templates exist.

Costs

• Every public data release needs a rights/provenance classification step.
• Reusers must consult both license files and release-specific notices.
• Legacy screenshots remain redistributable only to the extent independently permitted; the project provides no additional content license for them.
• Dependency notices must be generated from each actual distribution rather than copied once from the development lock.

Alternatives Considered

One MIT License For Everything

MIT is written for software and would make the scope of database and individual content rights unclear. It was rejected for data.

CC BY 4.0 For The Entire Repository

Creative Commons does not recommend CC licenses for software. Applying it to code would also blur package-license expectations. It was rejected for code.

License Every Source-Derived Item Now

No corpus release exists in the repository, and the current F0 manifests do not constitute a source-by-source rights audit. Public availability was not treated as permission. Source-content decisions are deferred to release provenance.

ODC-BY For Database Structure

ODC-BY separates database rights from individual contents, but would add a third licensing lane while CC BY 4.0 can cover project-owned database rights and contents with explicit exclusions. CC BY 4.0 was selected for a simpler attribution contract.

Revisit Conditions

• A source license requires share-alike, noncommercial, no-derivatives or other terms incompatible with a planned release.
• A release includes material whose copyright/database status cannot be represented by the manifest boundary.
• The project begins distributing dependency binaries or media that require bundled full license texts/notices.
• A legal review requires different attribution wording or jurisdiction-specific treatment.