Owner: Chief Technology Officer (CTO) and General Counsel (GC)
Review cadence: Annual and upon material legal/license change
Purpose. Establish one conservative, developer‑friendly IP and open‑source governance model for all Nexus projects, ensuring permissive reuse, patent safety, standards integrity, and clean separation between the public‑interest stack and enterprise delivery. Integrates with Annex B (Regulatory Perimeter), Annex C (Privacy), Annex D (SDZ/Transfers), Annex E (Security/SLSA/SBOM), Annex H (Trademarks/Marks), and contractual licenses.
1) Scope & Equal‑Treatment Baseline
Applies equally to all regional operators (APAC, Middle East, East Africa, Southern Africa, EU/France, USA, Canada, Brazil/LatAm, Senegal/West Africa, Switzerland/GRF seat), NatCos, Program SPVs, and contributors (employees, contractors, partners, startups). Where host‑law or customer rules exceed this baseline, the stricter control prevails.
2) Roles & Ownership Map (Today)
-
NE Inc (DE) — IP originator for code, models, schemas created within Nexus projects; grants:
– Public‑Interest License (PIL) to GRF/GCRI (limited field‑of‑use: standards/evidence; non‑sublicensable).
– Enterprise License to SNC/NatCos/SPVs (commercial delivery; sublicensing to delivery entities only). - GRF (Zug) — steward of marks/badges and standards conformance in the interim; holds no equity in for‑profits.
- (Future) NSF — protocol authority (on novation from GRF for marks/protocol), without corporate control over for‑profits.
Nothing in this Annex grants nonprofits ownership or corporate control over for‑profits; it governs licenses and conduct only.
3) Baseline Licenses & Artefact Classes
| Artefact Class | Default License | Notes |
|---|---|---|
| Software (code, SDKs, tooling) | Apache‑2.0 | Permissive + patent grant + termination on patent aggression; include NOTICE file. |
| Documentation, Schemas, Specs | CC‑BY 4.0 | Attribution required; not suitable for software; include version and attribution block. |
| Datasets (non‑personal) | CC‑BY 4.0 (or ODC‑By where appropriate) | Ensure provenance + rights clearance; no PII; attach data dictionary and lineage. |
| ML Models & Weights | Apache‑2.0 + Model Weights Addendum (or OpenRAIL‑style where required) | Addendum covers safety use‑restrictions, evaluation transparency, and third‑party content disclosures. |
| Standards Text & Reference Profiles | CC‑BY 4.0 | FRAND/RAND participation rules; reference implementations under Apache‑2.0. |
Inbound = Outbound Rule. All contributions are accepted only under the same outbound license applicable to the artefact class to preserve license clarity and downstream rights.
4) Contributor Agreements & Attribution
- CLA (Contributor License Agreement): Required for external contributors. Grants: copyright license + patent license consistent with Apache‑2.0; confirms right to contribute; no confidential or export‑controlled material.
- DCO (Developer Certificate of Origin): Signed‑off‑by line required in every commit.
-
Attribution: Maintain
NOTICE(code) and attribution blocks (docs/data). Record contributor metadata inCONTRIBUTORS.md.
5) Third‑Party Dependencies & License Hygiene
- Allow‑list: Permissive licenses (Apache‑2.0, MIT, BSD, ISC) and weak copyleft (MPL‑2.0) are generally allowed.
- Deny‑list: Strong copyleft (GPL‑2.0/3.0, AGPL‑3.0) not permitted in core repositories. If required, it must be isolated in adapters/plugins with clear dynamic‑link boundaries and legal review.
- Scanning: Automated license scans in CI for every merge; block if violation.
- SBOM linkage: SBOM (SPDX/CycloneDX) generated for every build (Annex E) and stored with artefacts; license metadata must match allow/deny policy.
6) Trademarks, Badges & Brand Usage (summary)
- Ownership: “Nexus”, GRF/NSF wordmarks, and conformance badges are owned/stewarded by GRF (interim) and later NSF.
- Usage: Requires a valid Marks & Conformance License and passing audits (CL/EQL).
- No implied endorsement: OSS use does not grant right to claim certification or endorsement.
- Name spacing: Repos/projects must follow naming guidelines to avoid confusion (see Annex H for full policy).
7) Repository Governance & Process
-
Required files:
LICENSE,NOTICE,SECURITY.md(embargo & reporting),CONTRIBUTING.md,CODE_OF_CONDUCT.md,GOVERNANCE.md(maintainers/decision rules),RELEASE.md. - Maintainer model: Meritocratic maintainers with a Steering Group (CTO chair + two maintainers + Legal) for tie‑breaks and roadmap.
- Change control: Use RFCs for breaking changes or policy‑affecting features; public comment period ≥14 days; record decisions.
- Versioning: Semantic versioning; LTS branches with backport policy; signed tags/releases.
8) Security & Vulnerability Disclosure (OSS)
- SECURITY.md: Includes reporting email, PGP key, and embargo window (typically ≤90 days).
- Triage: Follow Annex F severity SLAs; coordinate disclosure with affected vendors.
- Provenance: Signed commits; reproducible builds; release signatures; publish SLSA provenance attestations with releases.
- Malicious packages: Immediate de‑publish/takedown and communiqué to downstreams.
9) Data & Model Governance
- No PII in OSS repos. Use synthetic or anonymised datasets; if not feasible, keep data in SDZs with access controls (Annex D).
-
Dataset provenance: Include
DATAPROV.mdwith source, rights, collection method, known biases/limitations, and consent/ethics notes. -
Model cards: Publish
MODEL_CARD.md(intended use, limitations, evaluation metrics, risks, and safety mitigations). - Evaluation transparency: Release benchmarks, seed configs, and scripts where lawful and safe.
10) Dual‑Licensing & Commercial Interfaces
- Enterprise features (proprietary connectors, dashboards, deployment tooling) remain NE Inc IP and are distributed under commercial license; never merge enterprise code into OSS repos.
- Clean interfaces: OSS defines stable APIs; enterprise modules consume via these APIs to avoid license contamination.
- Public‑Interest License (PIL): GRF/GCRI receive PIL for standards/evidence artefacts; no sublicensing for commercial delivery.
- Conformance artefacts: Reference implementations remain OSS; certification tooling may be enterprise but must publish interoperability specs.
11) Export Controls & Sanctions
- Screening: Do not accept contributions from sanctioned persons/entities; automated checks on PR authors where feasible.
- Crypto/dual‑use modules: Tag with export warnings; seek GC review for strong cryptography or geofencing features.
-
Notices: Include export‑control disclaimer in
READMEfor relevant repos.
12) Records & Evidence
Maintain for 7 years: CLAs/DCO attestations, license scan reports, SBOMs, provenance attestations, governance decisions (RFCs), release notes, and takedown logs. Link each to the program’s Assurance & Evidence Pack (AEP).
13) Exceptions & Waivers
- Use the OSS/IP Exception Register for any variance (e.g., GPL dependency in adapter). Requires CTO + GC approval, risk assessment, compensating controls, and expiry. Report material exceptions to the Board.
14) Training & Communications
- Annual OSS/IP training for engineers, product, legal, and procurement; new‑joiner onboarding covers inbound=outbound, CLA/DCO, trademarks, and export.
- Publish contributor guides and office hours; maintain a public roadmap where appropriate.
15) Enforcement
Breaches (license contamination, trademark misuse, export‑control violations, security embargo breach) may lead to access suspension, disciplinary action, takedowns, revocation of marks, and legal remedies.
16) Effective Date & Governance
Adopted by the Board(s) of all regional operators on [●] and incorporated by reference into Charters/Bylaws, contribution workflows, and vendor/customer contracts. Class B to amend/strengthen; Class A required to weaken license posture (e.g., permit strong copyleft in core) or reduce safeguards.