OpenMDW-1.1 and AI License Provenance

1. What is OpenMDW-1.1

On May 28, 2026, the Linux Foundation and NVIDIA announced OpenMDW-1.1, a permissive license designed specifically for AI model distributions. Unlike traditional software licenses that cover source code alone, OpenMDW-1.1 treats model weights, training data documentation, and accompanying software as a unified whole under a single license grant.

NVIDIA has adopted OpenMDW-1.1 for several of its model families, including Cosmos, Isaac GR00T, Ising, and Nemotron. The license addresses a long-standing gap in open-source AI: the question of what license actually covers the trained weights, which are neither source code nor data in the traditional sense.

Key properties of OpenMDW-1.1:

• Permissive terms for commercial and research use of model weights
• Covers the complete model distribution: weights, training metadata, and tooling
• Compatible with existing open-source licenses for upstream and downstream dependencies
• Designed for composability with adapter layers and fine-tuning outputs

2. The License Drift Problem

Modern AI systems rarely operate under a single license. A typical production deployment combines multiple components, each carrying distinct licensing terms:

• A base model released under Apache-2.0 or MIT
• LoRA adapters or fine-tuning layers released under CC-BY-4.0 or CC-BY-NC
• Training or fine-tuning data covered by proprietary agreements
• Inference libraries and runtime dependencies under various open-source licenses

No single license covers the assembled inference stack. When an organization deploys a model composed of these layers, the effective licensing terms become a composite that must be evaluated as a whole. Auditors reviewing a production system cannot determine what license obligations apply at inference time without detailed provenance records.

This creates measurable compliance risk. Under the EU AI Act, Article 53(1)(d) requires GPAI providers to document training data licensing. Without structured, timestamped evidence of license composition, organizations face gaps that auditors and regulators will flag. The introduction of OpenMDW-1.1 simplifies the base model layer but does not eliminate the composition problem when adapters and data carry separate terms.

3. SWT3 AI-LIC.1: License Provenance Witnessing

New Procedure

AI-LIC.1 is a new SWT3 procedure that creates immutable witness evidence of license composition at inference time. Each time a model stack is witnessed, AI-LIC.1 records the number of components checked, whether all components are license-compliant, and the primary license classification of the stack.

Factor Design

The resulting SWT3 Witness Anchor records these factors alongside the standard fingerprint, timestamp, and tenant context. This creates a permanent, verifiable record that a license evaluation occurred and what the outcome was.

4. SDK Integration

Python

from swt3_ai import Witness

witness = Witness(endpoint="https://sovereign.tenova.io", api_key="axm_live_...")

# Witness a model stack using OpenMDW-1.1 base with Apache-2.0 adapter
anchor = witness.witness_license_provenance(
    components_checked=3,
    all_compliant=True,
    license_type="openmdw",
    base_model_license="OpenMDW-1.1",
    adapter_licenses=["Apache-2.0"],
    spdx_ids=["LicenseRef-OpenMDW-1.1", "Apache-2.0"],
)

TypeScript

import { Witness } from "@tenova/swt3-ai";

const witness = new Witness({
  endpoint: "https://sovereign.tenova.io",
  apiKey: "axm_live_...",
  tenantId: "YOUR_TENANT",
});

const anchor = witness.witnessLicenseProvenance({
  componentsChecked: 3,
  allCompliant: true,
  licenseType: "openmdw",
  baseModelLicense: "OpenMDW-1.1",
  adapterLicenses: ["Apache-2.0"],
  spdxIds: ["LicenseRef-OpenMDW-1.1", "Apache-2.0"],
});

Both SDKs mint an AI-LIC.1 anchor with the license composition recorded in the observations field. The spdx_ids array preserves the exact SPDX identifiers for each component, enabling automated license compatibility analysis downstream.

5. License Type Codes

When a model stack combines components under different license types, the factor_c value should reflect the most restrictive license in the composition. For example, a stack with an OpenMDW-1.1 base model and a copyleft adapter would use code 1 (copyleft) as the effective license type.

6. SPDX Integration

The spdx_ids field accepts standard SPDX license identifiers as defined by the SPDX License List. Each component in the model stack should be identified by its canonical SPDX identifier where one exists.

OpenMDW-1.1 does not yet have an official SPDX identifier in the SPDX License List. Per the SPDX specification for custom licenses, use LicenseRef-OpenMDW-1.1 as the identifier until an official entry is assigned. This follows the LicenseRef- convention defined in SPDX 2.3 for licenses not yet cataloged in the standard list.

Common SPDX identifiers used in AI model stacks:

• Apache-2.0 - Apache License 2.0
• MIT - MIT License
• CC-BY-4.0 - Creative Commons Attribution 4.0
• CC-BY-NC-4.0 - Creative Commons Attribution NonCommercial 4.0
• GPL-3.0-only - GNU General Public License v3.0 only
• LicenseRef-OpenMDW-1.1 - Linux Foundation OpenMDW 1.1 (custom identifier)

Recording SPDX identifiers at witness time enables downstream tooling to perform automated compatibility checks, generate SBOM license sections, and produce audit-ready reports without manual license identification.

7. Regulatory Mapping

AI-LIC.1 does not replace legal review of license terms. It creates independent, timestamped evidence that a license evaluation was performed and records the outcome. This evidence is available to auditors, regulators, and downstream deployers through the standard SWT3 verification and export mechanisms.