SAIL-GPLSECURITY THAT TRAVELS

Secure Super AI General Public License

Let the
proof travel.

A model can change hands. Its provenance, disclosed risks and security obligations should follow. SAIL-GPL makes release evidence part of the license.

Read the draft license Try the verifier

For SAI (Super AI) model artifacts and their derivatives.

An artifact with an inspectable proof chain A model artifact connects to a signed manifest and its release evidence. A separate externally trusted key authenticates the publisher. MODEL ARTIFACT weights / config tokenizer / code release evidence SHA-256 FILE INVENTORY Signed manifest SAIL SRM v2 EXTERNAL TRUST Publisher key obtained separately EVIDENCE INSIDE Origin. Risk. Evaluation. INSPECTABLE BY DESIGN
Illustrative release structure, not a live verification result

A license proposal.
A working evidence toolkit.

1.0License draft
1.1Toolkit release
v2Native SRM format
01 / THE PRINCIPLE

Ownership changes.
Assurance should stay.

A signature can show that files are intact. A responsible release also explains where the model came from, what was evaluated and how to report a vulnerability. SAIL-GPL proposes that this evidence follows every distribution.

01

Know what you received.

A signed manifest binds the model files and release documents. A SAI Bill of Materials (SAIBOM) records declared upstream components, licenses, data provenance and pipeline references.

02

See the limits, too.

The model card and signed evaluation disclose intended use, limitations and test results. Failed tests can be reported honestly. A valid signature never turns a weak model into a safe one.

03

Carry it forward.

Fine-tuning, merging and quantization create a new release obligation. Refresh the evidence, record the parent signature, sign the derivative and preserve coordinated disclosure duties.

One artifact. An inspectable release record.

Secure-Release Metadata / SRM

  1. 01 / INTEGRITYSigned manifestFile hashes and signed release policy.
  2. 02 / PROVENANCESAI Bill of MaterialsDeclared materials and parent lineage.
  3. 03 / CONTEXTModel cardIntended use, limits and known risks.
  4. 04 / EVALUATIONSecurity attestationExplicit tests, outcomes and evidence.
  5. 05 / RESPONSEDisclosure policyA named contact and a CVD process.
02 / FROM MODEL TO RELEASE

Make the next handoff
verifiable.

The draft couples permission to distribute a model with a duty to ship its evidence. The toolkit handles the technical record. The steward remains responsible for truthful declarations and appropriate evaluation.

  1. 01

    Prepare.

    Collect the model files. Write a meaningful model card and publish a disclosure contact and process.

  2. 02

    Declare.

    Supply the SAIBOM and actual adversarial evaluation results. Choose the tier that fits the model distribution and its risk.

  3. 03

    Sign.

    Bind the files and evidence to a release manifest. Keep private keys outside the distributed artifact.

  4. 04

    Verify.

    Check the release and pin trusted keys obtained separately. For a derivative, renew the record and repeat.

LICENSE SCOPE

SAIL-GPL covers model artifacts and derivatives. Independently licensed software retains its own terms. This draft does not make a claim of compatibility with another software license.

03 / PROPORTIONATE EVIDENCE

Different risk.
A higher bar.

Explore how the release requirements change from a narrow model release to a high-risk distribution. All three tiers require the core evidence bundle.

T0 covers internal research that is not conveyed to third parties. Distribution triggers at least T1. Applicable law may impose further obligations.

A complete, lightweight release record.

For small or narrow models distributed to third parties. The evaluator may self-report, with explicit results for the minimum test set.

Manifest, SAIBOM and model card
Required
Security evaluation
Explicit self-reported results
Signature algorithm
Classical, PQ or hybrid
Publisher authentication
External key pin optional
Transparency evidence
Optional signed receipt
Disclosure contact and CVD process
Required

Without a trusted publisher key, verification establishes integrity only. Any supplied receipt requires a trusted log key.

04 / INSPECT IT YOURSELF

Trust begins with
a check you can run.

The open Python toolkit builds and verifies native SAIL SRM v2 bundles. Clone the repository, install the toolkit dependencies, then try the signed demonstration release.

RUN FROM THE REPOSITORY ROOT
PYTHONPATH=sail/src python -m sail verify example-model --trusted-key sail/examples/example-public-key.json

VERIFIED means the checked technical evidence passed. It is not a legal or safety certification, a promise of secure behavior or proof of superhuman competence.

Installation and CLI guide Native v2 format specification Inspect the example bundle

The key is part
of the decision.

The example key is published for a reproducible demonstration. In a real release, obtain and authenticate the publisher key through a trusted channel outside the model bundle. Default T1 and T2 verification checks integrity without establishing publisher identity. T3 also requires distinct trusted evaluator and log keys. Endpoint availability, truthful claims and operational disclosure handling remain outside the verifier's technical scope.

A public draft, open for scrutiny

Better releases start with
evidence we can inspect.

Review the license language, examine the wire format or test the toolkit. SAIL-GPL 1.0 is a proposal for community and counsel review. It has no OSI approval or registered SPDX license identifier.

Explore the repository