RFC-0014: ATX-1 Dual-Licensing Authorization

RFC: RFC-0014
Status: Draft
Version: 0.1.0
Created: 2026-03-29
Updated: 2026-03-29
Author: Ken Tannenbaum, AEGIS Initiative / AEGIS Operations LLC
Repository: aegis-governance
Target milestone: None
Supersedes: None
Superseded by: None

Summary

This RFC seeks retroactive authorization for a licensing change already applied to the ATX-1 threat taxonomy data served at aegis-governance.com. The source data files in docs/atx/data/ are licensed under Apache-2.0; the publicly served versions at site/public/atx-1/ were changed to CC-BY-SA-4.0. This change was made in anticipation of formal approval but without following the constitutional amendment process. This RFC documents the rationale, acknowledges the procedural error, and requests formal authorization to retain the dual-licensing model.

Motivation

The Problem

The ATX-1 threat taxonomy is a proprietary dataset owned by AEGIS Operations LLC. It carries DOI anchors (IEEE DataPort doi:10.21227/f87b-1d57, Zenodo doi:10.5281/zenodo.19225676, doi:10.5281/zenodo.19238844, doi:10.5281/zenodo.19251098) and has been cited in submitted papers to NIST, IEEE Computer, IEEE Data Descriptions, and NCCoE. Protecting the intellectual property rights of this dataset while making it available for public use is a legitimate and necessary concern.

The Apache-2.0 license on the source files permits liberal redistribution, modification, and commercial use with minimal conditions (attribution and license notice). While appropriate for code contributions and internal development, this license provides insufficient protection for a proprietary dataset that is being published for public consumption — particularly one that is DOI-anchored and intended to serve as a normative reference.

CC-BY-SA-4.0 provides stronger protections aligned with the dataset’s intended use:

• Attribution required — consumers must credit AEGIS Operations LLC and the AEGIS Initiative
• ShareAlike — derivative works must be distributed under the same or compatible license, preventing proprietary enclosure of the taxonomy
• No additional restrictions — downstream users cannot impose terms that restrict others from exercising the licensed rights

What Happened

The license on the served ATX-1 data was changed from Apache-2.0 to CC-BY-SA-4.0 in anticipation of this RFC being filed and approved. This was done to protect the proprietary IP position while the formal authorization process was initiated.

This was a procedural error. The AEGIS Constitution requires that governance decisions follow the amendment process — proposal, review, impact analysis, approval, effective date. Changing the license before authorization, regardless of intent, is contrary to this requirement.

What Happens If We Do Nothing

If the licensing change is reverted to Apache-2.0 pending formal approval:

• The dataset would be publicly available under a permissive license that allows unrestricted commercial use, modification, and redistribution without ShareAlike protections
• Third parties could incorporate the ATX-1 taxonomy into proprietary products without contributing modifications back
• The IP position of AEGIS Operations LLC would be weakened during the review period

Given the sensitivity of the IP ownership question, the change has been left in place pending the outcome of this RFC. This RFC acknowledges that this is itself a departure from constitutional process and requests that the community review consider both the substance of the licensing decision and the procedural violation.

Guide-Level Explanation

The ATX-1 threat taxonomy is published in two forms from the aegis-governance repository:

1. Source files (docs/atx/data/ and docs/atx/v2/data/) — the canonical markdown definitions and JSON data files used by contributors and developers. Licensed under Apache-2.0.

2. Served files (site/public/atx-1/) — the machine-readable JSON data served at aegis-governance.com for public consumption by tools, integrations, and automated consumers. Changed to CC-BY-SA-4.0.

This RFC proposes formalizing this split as a deliberate dual-licensing model:

• Contributor-facing source remains Apache-2.0 — permitting contribution, forking, and development without friction
• Consumer-facing served data is CC-BY-SA-4.0 — ensuring attribution and preventing proprietary enclosure of the published taxonomy

This mirrors common practice in standards and dataset publishing, where source contributions are governed by a contributor license and published artifacts carry a more restrictive distribution license.

Reference-Level Explanation

Licensing Model

License Field in JSON Files

Each served JSON file contains a top-level license field. Under this RFC:

• Source files: "license": "Apache-2.0"
• Served files: "license": "CC-BY-SA-4.0"

Documentation Requirements

If approved, the following documentation must be created or updated:

1. A LICENSE-DATA.md file in docs/atx/ explaining the dual-licensing model
2. The CLAUDE.md for aegis-governance must note the dual-licensing policy
3. The site/ README must note that served data carries CC-BY-SA-4.0
4. The repository’s root LICENSE-DOCS (CC-BY-SA-4.0) already covers documentation; this RFC extends that coverage to the served data artifacts

Drawbacks

Procedural Precedent

The most significant drawback is not the licensing decision itself but the precedent of applying a change before authorization. If this RFC is approved, it must be explicitly noted that approval does not validate the procedure — only the substance. The constitutional process exists precisely to prevent well-intentioned changes from bypassing governance review.

Contributor Confusion

Two licenses on the same data in the same repository may confuse contributors. Clear documentation and CI validation (checking license fields in served files) can mitigate this.

License Compatibility

Apache-2.0 is one-way compatible with CC-BY-SA-4.0 (Apache-2.0 work can be incorporated into CC-BY-SA-4.0, but not the reverse). This means contributions made under Apache-2.0 can flow into the served CC-BY-SA-4.0 artifacts, but served data cannot be re-imported into Apache-2.0-only contexts. This is the intended direction of flow.

Alternatives Considered

1. Apache-2.0 for Everything

Rejected. Does not provide ShareAlike protection. Third parties could incorporate the ATX-1 taxonomy into proprietary products without contributing modifications back. Weakens the IP position of the canonical dataset.

2. CC-BY-SA-4.0 for Everything

Rejected. CC-BY-SA-4.0 is not designed for code contributions and creates friction for developers who want to fork, modify, and contribute back to the source data. The Apache-2.0 contributor path should remain open.

3. CC-BY-4.0 (Attribution Only, No ShareAlike)

Rejected. Permits proprietary enclosure of derivative works. Does not meet the IP protection requirements.

4. Custom License

Rejected. Non-standard licenses create adoption friction and legal review burden for organizations evaluating AEGIS. Standard, well-understood licenses are preferred.

Compatibility

Breaking Changes

• For consumers of aegis-governance.com JSON endpoints: The license field in served JSON files has changed from Apache-2.0 to CC-BY-SA-4.0. Consumers who redistribute or create derivative works from the served data must now comply with CC-BY-SA-4.0 terms (attribution, ShareAlike).
• For Zenodo deposits: Future DOI snapshots must note the dual-licensing model in their metadata.

Deprecations

None.

Backwards Compatibility

• Existing DOI-anchored snapshots (v1.0, v2.0, v2.1) retain their original license metadata. This RFC does not retroactively change the license on published DOI artifacts.
• Source file licensing is unchanged.
• The repository’s existing dual-license structure (Apache-2.0 for code, CC-BY-SA-4.0 for documentation via LICENSE-DOCS) already establishes the pattern this RFC extends.

Implementation Notes

If approved:

1. Create docs/atx/LICENSE-DATA.md documenting the dual-licensing model
2. Update CLAUDE.md to note the ATX-1 dual-licensing policy
3. Update site/README.md (or create one) noting served data is CC-BY-SA-4.0
4. Verify all served JSON files in site/public/atx-1/ contain "license": "CC-BY-SA-4.0"
5. Verify all source JSON files in docs/atx/data/ and docs/atx/v2/data/ contain "license": "Apache-2.0"
6. Add a CI check validating license field consistency between source and served files
7. Log the decision in AEGIS_DECISIONS.log (or equivalent ADR) with reference to this RFC

Open Questions

• Does the constitutional amendment process formally apply to operational licensing decisions, or only to changes to constitutional text? If the former, this RFC satisfies the requirement. If the latter, an ADR may be the more appropriate vehicle — but this RFC was filed to err on the side of the more rigorous process.
• Should future DOI snapshots carry dual-license metadata explicitly, or should the DOI metadata reference this RFC for the licensing explanation?
• Should the docs/atx/v2/data/ files be updated to note that served versions carry a different license, or is the LICENSE-DATA.md file sufficient?

Procedural Note

This RFC acknowledges a constitutional process violation. The licensing change described herein was applied to the served ATX-1 data before this RFC was filed, in anticipation of approval. This is contrary to the requirements established in the AEGIS Constitution:

• Article X (Constitutional Supremacy): “The remedy for bad governance is the amendment process — not circumvention by the governed system.”
• Amendments Process: Changes require proposal, community review, impact analysis, approval, and effective date — in that order.
• Interpretation Rule #2: “Explicit over implicit — explicit authorization is required; permission is never assumed.”

The change was left in place rather than reverted due to the sensitivity of the IP ownership position — reverting to Apache-2.0 during the review period would expose the dataset to the very risks this RFC is designed to address. This pragmatic decision is itself a governance tradeoff that the community review should consider.

The AEGIS Initiative holds itself to the same standards it prescribes for governed systems. This RFC is filed in that spirit — not to justify the procedural error, but to correct it through the process that should have been followed in the first place.

Success Criteria

1. The dual-licensing model is formally documented and discoverable by any consumer of the ATX-1 data
2. A LICENSE-DATA.md exists in docs/atx/ explaining the split
3. CI validates license field consistency between source and served files
4. The decision is logged in the project’s decision record with a reference to this RFC
5. The procedural violation is acknowledged in the decision record as a precedent to be avoided

References

• AEGIS Constitution v0.2.0 — aegis-initiative/aegis-constitution, Articles VI, VII, X; Amendments; Interpretation
• ATX-1 Threat Taxonomy — docs/atx/ATX-1_TECHNIQUE_TAXONOMY.md
• ATX-1 v2.1 DOI — doi:10.5281/zenodo.19251098
• ATX-1 v2.0 DOI — doi:10.5281/zenodo.19238844
• ATX-1 v1.0 DOI (Zenodo) — doi:10.5281/zenodo.19225676
• ATX-1 v1.0 DOI (IEEE DataPort) — doi:10.21227/f87b-1d57
• Repository LICENSE — Apache-2.0 (code)
• Repository LICENSE-DOCS — CC-BY-SA-4.0 (documentation)
• REFERENCES.md — Canonical bibliography

AEGIS™ | “Capability without constraint is not intelligence”™ AEGIS Initiative — AEGIS Operations LLC