# Specification Commons License v0.1 (SCL-0.1)
**Pre-Release Draft — February 2026**
> *"Protecting the intent, not just the implementation."*
---
## Preamble
Software creation has fundamentally changed. When an AI agent can
re-implement a complex system from a well-written specification in minutes
for negligible cost, the code itself has near-zero marginal value. The
scarce, valuable artifacts are now the domain insights that identify what
needs building, the specifications that describe it precisely, and the
evaluation criteria that determine whether it was built correctly.
Existing open source licenses — MIT, Apache 2.0, GPL, BSD — were designed
to govern the sharing and protection of source code: the implementation
layer. They answer the question "who can use, modify, and distribute this
code?" That question mattered when code was the expensive artifact. It is
no longer the right question.
The Specification Commons License (SCL) is designed for a world where:
- **Specifications** are the primary creative artifact, not code
- **AI agents** routinely generate implementation from specifications
- **Domain knowledge**, once locked in human heads, is now externalized
into machine-readable formats
- **Evaluation scenarios** encode irreplaceable expertise about what
"correct" means
- **Provenance** — knowing where ideas came from — matters more than
controlling where code goes
This license governs the five layers of the modern software creation stack,
giving each layer the protections and freedoms appropriate to its economic
properties.
---
## Article 1 — Definitions
### 1.1 The Five Layers
This license recognizes five distinct layers of software creation, each
with different sharing and protection characteristics:
**"Domain Insight"** — The understanding that a problem exists and what
solving it requires. Includes market knowledge, user needs analysis,
regulatory understanding, operational experience, and the identification
of problems worth solving. Domain Insight is the rarest and most valuable
layer.
**"Specification"** — A precise, structured description of what software
should do. Includes behavioral contracts, functional requirements,
interface definitions, scenario descriptions, architectural constraints,
and any document intended to be consumed by a human or automated system
to produce an implementation. Specifications are the new source code.
**"Architecture"** — Structural decisions about how components relate,
what technologies to use, and how a system decomposes. Architecture may
be embedded within a Specification or expressed independently.
**"Implementation"** — Executable source code, compiled binaries, and
associated build artifacts in any programming language. Implementation is
the layer that existing open source licenses govern and that AI agents
now routinely generate.
**"Evaluation Scenarios"** — Holdout behavioral tests, acceptance
criteria, digital twin configurations, integration test suites, and any
artifact that encodes domain knowledge about what "correct" means for a
given Specification. Evaluation Scenarios may be licensed independently
from the Specifications they validate.
### 1.2 Roles
**"Author"** — Any person or organization that creates or contributes to
a Licensed Artifact at any layer.
**"Recipient"** — Any person, organization, or automated system that
receives, reads, or processes a Licensed Artifact.
**"Generative System"** — Any automated system, including but not limited
to AI agents, code generators, specification synthesizers, and autonomous
development pipelines, that consumes Licensed Artifacts as input and
produces new artifacts as output.
**"Dark Factory"** — A software development pipeline in which Generative
Systems produce Implementation from Specifications with minimal or no
human intervention in the implementation process.
**"Specification Commons"** — The collective body of Specifications
released under this license.
### 1.3 Artifact Types
**"Licensed Artifact"** — Any artifact at any of the Five Layers that is
released under this license.
**"Generated Artifact"** — Any artifact produced by a Generative System
that consumed one or more Licensed Artifacts as input during the
generation process. This includes artifacts produced at inference time,
not artifacts influenced solely through model training.
**"Provenance Manifest"** — A machine-readable record identifying which
Licensed Artifacts were consumed in the production of a Generated
Artifact, including their versions, authors, and license terms.
---
## Article 2 — Grant of Rights
### 2.1 Specifications (The Core Grant)
Subject to the terms of this license, the Author grants every Recipient
a worldwide, royalty-free, non-exclusive, perpetual license to:
**(a) Read and Learn** — Study, analyze, discuss, teach from, and
reference the Specification for any purpose, including commercial
research, education, and internal evaluation. This right is unconditional.
**(b) Implement Manually** — Use the Specification as a reference to
write Implementation by hand (or with non-autonomous tooling such as
autocomplete or code suggestion) without further obligation beyond
attribution as described in Article 3.
**(c) Generate Implementation** — Use the Specification as input to a
Generative System that produces Implementation, subject to:
- **(i)** The Generated Artifact must include a Provenance Manifest
identifying this Specification as a source (see Article 3).
- **(ii)** The Generated Artifact does not itself become subject to
this license unless the Recipient chooses to release it under SCL.
Generated Implementation may be released under any license, including
proprietary licenses. (But see Section 2.6 for the reciprocal
sharing variant.)
- **(iii)** The Generative System must not strip, obscure, or fail to
propagate the Provenance Manifest through the generation pipeline.
**(d) Fork and Modify** — Create derivative Specifications based on this
Specification, provided that:
- **(i)** Derivative Specifications must also be released under SCL-0.1
or a later version of the Specification Commons License.
- **(ii)** Derivative Specifications must include provenance attribution
to the original Specification (see Article 3).
- **(iii)** Derivative Specifications must be clearly marked as
modified versions and must not misrepresent the original Author's
intent.
**(e) Distribute** — Distribute the Specification in its original or
modified form, subject to the terms of this license, through any medium
including public repositories, private networks, and commercial products.
### 2.2 Domain Insights
Domain Insights included in or accompanying a Licensed Artifact are
shared under the same terms as Specifications (Section 2.1) when they
are externalized in written, structured, or machine-readable form.
Domain Insights that remain tacit (in human knowledge, experience, or
judgment) are not governed by this license.
### 2.3 Architecture
Architectural descriptions included in or accompanying a Licensed
Artifact are shared under the same terms as Specifications (Section 2.1).
### 2.4 Implementation
Implementation released under this license is governed by the terms of
Section 2.1(a) through 2.1(e) as applied to code rather than
specifications. Authors may additionally or alternatively release
Implementation under any OSI-approved license (MIT, Apache 2.0, GPL,
etc.) alongside this license.
For the avoidance of doubt: Implementation that is Generated from a
Licensed Specification does not automatically fall under this license.
The obligation flows to the Provenance Manifest (Article 3), not to the
license of the generated code.
### 2.5 Evaluation Scenarios
Evaluation Scenarios may be licensed independently from their associated
Specifications under one of three tiers:
**(a) Open Scenarios** — Released under the same terms as Specifications
(Section 2.1). The Author grants full rights to read, use, modify, and
distribute the scenarios.
**(b) Restricted Scenarios** — Available for reference and learning
(Section 2.1(a)) but may not be used as input to a Generative System or
incorporated into automated evaluation pipelines without separate
written permission from the Author. Restricted Scenarios may be used for
manual testing and human-driven quality assurance without restriction.
**(c) Proprietary Scenarios** — Not released under this license.
Referenced in the Specification's metadata as existing but not included
in the Licensed Artifact. The Author retains all rights. This tier
enables the "Open Spec, Closed Scenario" (OSCS) model where
specifications are shared but the quality bar remains a competitive
advantage.
The Author must clearly designate which tier applies to each set of
Evaluation Scenarios. If no designation is made, Evaluation Scenarios
included alongside a Licensed Specification default to Open Scenarios.
### 2.6 Reciprocal Specification Sharing Variant (SCL-RS)
Authors may choose to release Specifications under the **SCL-RS**
(Reciprocal Sharing) variant. Under SCL-RS, Section 2.1(c)(ii) is
replaced with:
> If a Recipient uses this Specification as input to a Generative System
> that produces Implementation which is distributed to third parties or
> deployed as a service, the Recipient must release the Specification(s)
> used to generate that Implementation under SCL-RS or a compatible
> later version of the Specification Commons License within 90 days of
> first distribution or deployment.
This variant applies the copyleft principle to the specification layer:
you may use open specifications to build commercial products, but the
specifications themselves must remain open. The generated implementation
may still be released under any license.
SCL-RS is the recommended variant for Authors who wish to build a
specification commons where community contributions compound over time.
---
## Article 3 — Attribution and Provenance
### 3.1 Attribution Requirements
Every Licensed Artifact must include, in a reasonably discoverable
location:
**(a)** The name(s) of the Author(s) or a designated pseudonym/organization
name.
**(b)** A reference to this license (including version number).
**(c)** A URI or content-addressable hash identifying the original
Licensed Artifact, if available.
### 3.2 The Provenance Manifest
Any Generated Artifact produced by a Generative System that consumed one
or more Licensed Artifacts must include a Provenance Manifest. The
Provenance Manifest must be:
**(a)** Machine-readable, in a format specified by the SCL Tooling
Standard (see Article 7) or, until that standard is published, in any
structured format (JSON, YAML, TOML, or equivalent).
**(b)** Included in or alongside the Generated Artifact in a reasonably
discoverable location (e.g., a `PROVENANCE.json` file in the repository
root, a header in generated files, or embedded metadata).
**(c)** Inclusive of the following information for each consumed Licensed
Artifact:
- Artifact name and version (or content-addressable hash)
- Author(s)
- License (SCL version and variant)
- Evaluation Scenario tier designation (if applicable)
- URI or location of the original artifact
- Nature of consumption (direct input, reference, partial inclusion)
### 3.3 The Generative Bill of Materials (GBOM)
The Provenance Manifest is part of a broader **Generative Bill of
Materials (GBOM)** — a complete record of what a Generative System
consumed during a generation run. The GBOM extends the Provenance
Manifest to include:
**(a)** Non-SCL artifacts consumed (with their respective licenses).
**(b)** The identity and version of the Generative System used.
**(c)** Timestamp of the generation run.
**(d)** Configuration parameters that materially affected the output.
Inclusion of a full GBOM is encouraged but not required under this
license. The Provenance Manifest (Section 3.2) is the minimum
requirement.
### 3.4 Provenance Chain Integrity
Recipients must not:
**(a)** Remove, alter, or obscure Provenance Manifests from Licensed or
Generated Artifacts.
**(b)** Falsify provenance information.
**(c)** Claim authorship of Licensed Artifacts they did not create.
Automated systems that process Licensed Artifacts must propagate
Provenance Manifests through their pipelines. A Generative System that
consumes a Generated Artifact with its own Provenance Manifest must
include that upstream provenance in its output's Manifest (transitive
provenance).
---
## Article 4 — Legacy Compatibility
### 4.1 Specification Extraction from Legacy Code
Specifications extracted from existing codebases under other licenses
(MIT, Apache 2.0, GPL, BSD, proprietary, etc.) are treated as
**independent works** under this license, analogous to how a book review
is an independent work from the book it reviews. A Specification
describes *what* software does. Existing licenses protect *how* software
does it. These are distinct intellectual contributions.
The following conditions apply to extracted Specifications:
**(a)** The Specification must describe functional behavior, interfaces,
and requirements — not reproduce substantial portions of the original
source code.
**(b)** The Provenance Manifest must record the source codebase(s) from
which the Specification was extracted, including their original
license(s) and author(s).
**(c)** Extraction does not grant any rights over the original codebase
beyond those already provided by its own license.
### 4.2 Legacy Attribution
When a Specification is extracted from or influenced by legacy
open-source code, the original maintainers receive permanent,
machine-readable attribution in the Specification's Provenance Manifest.
This attribution persists through all derivative Specifications and
Generated Artifacts in the provenance chain.
### 4.3 Dual Licensing
Authors may release artifacts under both this license and any other
license simultaneously. For Implementation artifacts, dual licensing
with an OSI-approved license is explicitly encouraged to maintain
compatibility with existing open source ecosystems.
### 4.4 Consumption of SCL Artifacts by Legacy Systems
Licensed Specifications may be read and manually implemented by
developers working on projects under any license, subject only to the
attribution requirements of Section 3.1. The SCL does not impose
obligations on manually-written code beyond attribution.
---
## Article 5 — Limitations and Boundaries
### 5.1 No Warranty
LICENSED ARTIFACTS ARE PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT.
### 5.2 No Liability
IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING
FROM, OUT OF, OR IN CONNECTION WITH THE LICENSED ARTIFACTS OR THE USE OR
OTHER DEALINGS IN THE LICENSED ARTIFACTS.
### 5.3 No Endorsement
The name(s) of the Author(s) may not be used to endorse or promote
products derived from Licensed Artifacts without specific prior written
permission, except as required for attribution under Article 3.
### 5.4 Severability
If any provision of this license is held to be unenforceable, the
remaining provisions remain in full force and effect.
### 5.5 No Restriction on Domain Insights
Nothing in this license restricts the use of Domain Insights that a
Recipient independently possesses or develops. This license governs the
externalized, written forms of Domain Insights included in Licensed
Artifacts — not knowledge itself.
---
## Article 6 — Governance and Evolution
### 6.1 Versioning
This license will evolve. Future versions will be published by the
Specification Commons Stewards (see Section 6.2) with a version number.
Licensed Artifacts specify which version(s) of the SCL they are released
under. Recipients may use Licensed Artifacts under the terms of the
specified version or any later version, at the Recipient's choice,
unless the Author explicitly restricts to a specific version.
### 6.2 Stewardship
Until a formal governance body is established, the Author(s) of this
license serve as interim stewards. The goal is to establish an
independent Specification Commons Foundation with multi-stakeholder
governance within 18 months of this license's initial publication.
### 6.3 Community Process
Changes to this license will follow an open process:
**(a)** Proposed changes will be published for public comment with a
minimum 30-day review period.
**(b)** Material changes (new obligations, changed rights) require a new
major version number.
**(c)** Clarifications and non-material changes may be published as
minor version updates.
---
## Article 7 — Tooling Standards (Forthcoming)
The following standards are referenced by this license and will be
published separately:
**(a)** **SCL Provenance Manifest Format** — The canonical machine-readable
format for Provenance Manifests, likely based on an extension of SPDX or
CycloneDX.
**(b)** **SCL Specification Format** — A recommended (not required)
format for Specifications that enables automated processing, provenance
tracking, and scenario association.
**(c)** **SCL Scenario Tier Markers** — Standard metadata fields for
designating Evaluation Scenario tiers (Open, Restricted, Proprietary).
**(d)** **GBOM Standard** — The canonical format for full Generative
Bills of Materials.
Until these standards are published, Authors should use reasonable
structured formats and clearly document their choices.
---
## How to Apply This License
### To a Specification:
Include the following notice at the top of your Specification or in an
accompanying LICENSE file:
```
Copyright (c) [year] [Author name]
This Specification is licensed under the Specification Commons License,
Version 0.1 (SCL-0.1).
Evaluation Scenario Tier: [Open | Restricted | Proprietary]
You may obtain a copy of this license at:
[URI to be established]
```
For the reciprocal sharing variant, replace `SCL-0.1` with `SCL-RS-0.1`.
### To a Project with Multiple Layers:
Include a `LICENSING.md` file in the project root that maps each artifact
to its license:
```markdown
# Licensing
## Specifications (`/specs/`)
Licensed under SCL-0.1 (or SCL-RS-0.1)
## Evaluation Scenarios (`/scenarios/`)
- `/scenarios/open/` — SCL-0.1 (Open Scenarios)
- `/scenarios/restricted/` — SCL-0.1 (Restricted Scenarios)
- `/scenarios/proprietary/` — Proprietary (not included in this repository)
## Implementation (`/src/`)
Licensed under [MIT | Apache 2.0 | your choice]
## Provenance
See PROVENANCE.json for the Generative Bill of Materials.
```
### Minimal Provenance Manifest Example:
```json
{
"scl_version": "0.1",
"generated_at": "2026-02-22T00:00:00Z",
"generator": {
"name": "Claude Code",
"version": "1.x"
},
"sources": [
{
"name": "Example Billing Specification",
"version": "2.1.0",
"hash": "sha256:abc123...",
"authors": ["Original Author"],
"license": "SCL-0.1",
"scenario_tier": "open",
"uri": "https://example.com/specs/billing",
"consumption": "direct_input"
}
],
"legacy_sources": [
{
"name": "legacy-billing-lib",
"version": "3.4.1",
"original_license": "MIT",
"authors": ["Legacy Maintainer"],
"uri": "https://github.com/example/legacy-billing",
"relationship": "specification_extracted_from"
}
]
}
```
---
## Short-Form License Identifiers
For use in package managers, file headers, and SPDX-compatible tooling:
| Identifier | Meaning |
|----------------|--------------------------------------------------|
| `SCL-0.1` | Specification Commons License v0.1 (permissive) |
| `SCL-RS-0.1` | SCL v0.1 with Reciprocal Specification Sharing |
| `SCL-0.1-OS` | SCL v0.1, Open Scenarios tier |
| `SCL-0.1-RS` | SCL v0.1, Restricted Scenarios tier |
| `SCL-0.1-PS` | SCL v0.1, Proprietary Scenarios tier |
---
*The Specification Commons License is itself released under SCL-0.1.
You may fork, modify, and redistribute this license under its own terms.*