# XVII. LICENSING

## 17.1 Commons Rights Doctrine

### 17.1.1 Public-good licensing.

Licensing under the Distributed Digital Public Goods Framework shall be treated as a core public-good governance function, not a purely administrative or legal afterthought. Every DDPGF object shall carry a recorded rights posture that defines how the object may be accessed, cited, copied, modified, localized, translated, forked, reused, redistributed, displayed, taught, integrated, evaluated, archived, corrected, withdrawn, recalled, or included in lawful handoff context. Public-good licensing shall support reuse, transparency, learning, interoperability, public-safe publication, national localization, correctionability, and institutional memory while preserving privacy, data rights, protected knowledge, public authority boundaries, community safeguards, Indigenous protocols where applicable, security controls, and no-conversion discipline.

Public-good licensing shall not mean that every object must be fully open. DDPGF shall apply the rule **open where safe, controlled where necessary, restricted where required, and always clear by record**. The licensing posture of each object shall be aligned with its object class, access class, data-use label, AI-use label, sensitivity class, public-safe status, support class, review status, Registry status, Marketplace status, repository location, and handoff status. A licensing record shall not create warranty, certification, procurement status, public authority approval, financeability, insurability, deployment authorization, consent, or execution authority by implication.

### 17.1.2 Open licensing.

Open licensing shall be used where an object can be safely and lawfully made available for broad public-good reuse, adaptation, translation, distribution, learning, research, implementation preparation, or contribution. Open licensing may apply to public-good software, open technical baselines, reference implementations, public-safe reports, open educational resources, documentation, schemas, metadata, public-safe data, notebooks, public-safe dashboards, public-safe guides, and other objects cleared for open release. Open licensing shall be accompanied by clear attribution requirements, version information, support status, license text, citation guidance, correction pathway, and no-conversion notices.

Open licensing shall not override privacy, security, protected knowledge, Indigenous protocol-sensitive controls where applicable, community safeguards, third-party rights, data-use restrictions, AI-use restrictions, export controls, public authority restrictions, or applicable law. Open license availability shall not mean that the object is certified, warranted, procurement-ready, financeable, insurable, endorsed, deployable, or executable by default.

### 17.1.3 Controlled licensing.

Controlled licensing shall be used where public-good reuse is desired but unrestricted access, modification, redistribution, commercial use, AI training, onward transfer, or public display would create unacceptable risk, rights conflict, boundary confusion, protected knowledge exposure, public authority sensitivity, data protection risk, cyber risk, community harm, Indigenous protocol concern where applicable, or downstream misuse. Controlled licenses may restrict access class, user class, purpose, geography, redistribution, derivative works, publication, AI use, commercial use, handoff use, or secure-room-only review.

Controlled licensing shall be explicit, readable, recorded, and linked to the relevant Registry record. Controlled licensing shall not create hidden exclusivity, sponsor control, provider capture, pay-to-access authority, pay-to-prioritize review, or private enclosure of public-good objects. Restrictions shall be used to preserve trust, rights, safety, and lawful use, not to defeat the public-good purpose of DDPGF.

### 17.1.4 Data licensing.

Data licensing shall define the rights, restrictions, permissions, limitations, attribution duties, access conditions, reuse conditions, derivative-use conditions, redistribution rules, AI-use conditions, cross-border conditions, privacy conditions, public-safe conditions, and correction duties applicable to data objects. Data licensing shall distinguish raw data, processed data, public-safe data, aggregated data, synthetic data, metadata-only records, data dictionaries, codebooks, schemas, data pipelines, feature sets, benchmark datasets, DRI datasets, Observatory datasets, National Portfolio datasets, and controlled data.

Data licensing shall not create unrestricted data rights unless expressly recorded. Dataset publication, metadata visibility, repository deposit, DOI assignment, Marketplace listing, Registry record, data-room access, compute-to-data access, or citation shall not create permission to reuse, train AI systems, transfer across borders, identify persons or communities, publish derivatives, commercialize, hand off, or deploy based on data unless the relevant license and data-use record expressly permit such use.

### 17.1.5 Model licensing.

Model licensing shall define the rights and restrictions applicable to model objects, AI system objects, AI-agent objects, model cards, system cards, benchmark cards, evaluation harnesses, simulation models, digital twin models, risk models, forecasting models, classifiers, optimization models, retrieval-augmented systems, fine-tuned models, foundation-model interfaces, and agentic workflows. Model licensing shall record permitted uses, prohibited uses, access conditions, redistribution rules, derivative rules, fine-tuning conditions, training restrictions, evaluation use, secure-room restrictions, public-safe output rules, human review requirements, withdrawal conditions, and incident response expectations.

Model licensing shall not create AI safety certification, general validation, automated decision authority, public authority approval, procurement readiness, financeability, insurability, deployment authorization, or execution authority. Where model objects are released only as cards, summaries, APIs, hosted interfaces, evaluation records, or controlled-room workflows, the licensing record shall make clear that access to model descriptions does not create access to model weights, training data, raw outputs, or deployment rights.

### 17.1.6 Software licensing.

Software licensing shall define the rights and restrictions applicable to repositories, libraries, services, applications, dashboards, APIs, SDKs, connectors, adapters, command-line tools, notebooks, templates, infrastructure-as-code, test suites, public-good technical baselines, and reference implementations. Software licenses shall be selected to support public-good reuse, contribution, interoperability, auditability, correctionability, security review, national localization, and sustainable maintenance. Software licensing shall include license text, attribution requirements, copyright notices, contribution terms, patent notices where applicable, dependency-license considerations, support status, security-disclosure pathway, and no-warranty notices.

Software licensing shall not create warranty, service-level obligation, procurement recommendation, vendor validation, production approval, deployment authorization, security certification, or execution authority. Reference implementation status shall be clearly separated from production approval or operational suitability.

### 17.1.7 Knowledge licensing.

Knowledge licensing shall govern reports, technical notes, public-safe summaries, learning objects, open textbooks, guides, training materials, documentation, methodological notes, knowledge products, public-safe dashboards, community guides, public authority learning guides, handoff literacy guides, and other knowledge objects. Knowledge licensing shall support learning, citation, translation, localization, public-safe reuse, public-good dissemination, and correction while preserving attribution, version integrity, public-safe boundaries, protected knowledge restrictions, sensitive content restrictions, and no-conversion notices.

Knowledge licensing shall not convert learning material into professional certification, legal advice, public authority guidance, finance advice, insurance advice, procurement advice, public warning, medical advice, safety approval, or deployment authorization. Knowledge objects shall be used within recorded scope and corrected where outdated, unsafe, misleading, or overclaimed.

### 17.1.8 Protected knowledge restrictions.

Protected knowledge restrictions shall apply to knowledge, data, methods, locations, practices, community information, Indigenous knowledge where applicable, ecological information, sensitive species data, sacred or culturally sensitive materials, health-sensitive information, youth-sensitive information, humanitarian-sensitive information, cyber-sensitive information, infrastructure-sensitive information, public authority-sensitive information, and other materials that should not be made openly available. Protected knowledge may be excluded from publication, described only through metadata, summarized publicly only after transformation, restricted to protected knowledge rooms, or withheld from AI training, export, handoff, or derivative use.

Protected knowledge restrictions shall override ordinary openness where necessary. Public-good objectives shall not justify extraction, unauthorized disclosure, AI training, commercialization, operationalization, publication, translation, handoff, or implementation using protected knowledge without proper authority, safeguards, protocols, consent where required, and recorded permission.

## 17.2 License Classes

### 17.2.1 Open-source software licenses.

Open-source software licenses may be used for DDPGF software objects where broad reuse, inspection, modification, redistribution, contribution, localization, and interoperability are safe and appropriate. License selection shall consider copyleft or permissive posture, compatibility with dependencies, patent provisions, contributor expectations, public-good continuity, enterprise handoff implications, national localization, security disclosure, and long-term maintainability.

Open-source licensing shall not mean the software is supported, warranted, secure-certified, production-ready, procurement-ready, or deployment-authorized. The software record shall include support status, release class, known limitations, security pathway, correction pathway, and no-warranty notice.

### 17.2.2 Open data licenses.

Open data licenses may be used for data objects that are lawfully available, public-safe, non-restricted, non-sensitive, rights-cleared, and suitable for broad reuse. Open data licensing shall identify attribution duties, derivative-use conditions, redistribution conditions, database rights where applicable, data-use labels, AI-use labels, update status, quality limitations, and correction pathway.

Open data licensing shall not apply to restricted data, protected knowledge, personal data, sensitive geospatial data, public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, health-sensitive data, youth data, cyber-sensitive data, infrastructure-sensitive data, or handoff-recipient-only data unless appropriate transformation and permissions have occurred and are recorded.

### 17.2.3 Creative Commons licenses.

Creative Commons licenses may be used for reports, documentation, guides, public-safe summaries, learning objects, open textbooks, public-safe images, public-safe diagrams, public-safe metadata, and other knowledge objects where the selected license aligns with public-good dissemination and rights protection. License selection shall consider attribution, share-alike, non-commercial, no-derivatives, translation, adaptation, public-safe transformation, and downstream reuse requirements.

Creative Commons licensing shall not override third-party rights, privacy, protected knowledge, data-use restrictions, AI-use restrictions, public authority sensitivity, community safeguards, Indigenous protocols where applicable, or confidential information. Attribution under a Creative Commons license shall not imply endorsement.

### 17.2.4 Documentation licenses.

Documentation licenses shall govern README files, developer guides, maintainer guides, user guides, API documentation, data dictionaries, model documentation, system cards, benchmark cards, public-safe technical notes, repository instructions, installation guides, release notes, changelogs, support statements, and handoff literacy guides. Documentation licensing shall support accurate reuse and translation while preserving version integrity, attribution, public-safe status, and boundary notices.

Documentation shall not be used to imply warranty, deployment authorization, procurement recommendation, public authority approval, or operational instruction beyond recorded scope.

### 17.2.5 Model licenses.

Model licenses shall govern use of model objects, model weights where released, model interfaces, model cards, system cards, benchmark cards, evaluation harnesses, fine-tuned models, retrieval-augmented systems, agentic workflows, simulation models, digital twin models, and decision-support models. Model licenses may restrict prohibited uses, high-stakes uses, surveillance uses, military or law-enforcement uses where appropriate, AI training reuse, fine-tuning, redistribution, commercial use, automated decision use, agentic tool use, and public authority decision use.

Model licenses shall be accompanied by AI-use labels, intended-use notes, prohibited-use notes, human-review requirements, incident pathways, withdrawal pathways, and no-AI-safety-certification notices.

### 17.2.6 Dataset licenses.

Dataset licenses shall govern dataset access, reuse, redistribution, modification, AI training, commercial use, attribution, derivative datasets, benchmark use, public-safe transformation, and citation. Dataset licenses shall distinguish between raw data, processed data, aggregated data, public-safe data, synthetic data, metadata-only records, and controlled data. Dataset license records shall be linked to data-use records, AI-use records, sensitivity classes, and correction pathways.

Dataset licenses shall not grant rights that the steward does not hold. Where dataset rights are uncertain, restricted, third-party, community-sensitive, protected, or jurisdictionally constrained, the dataset shall not be openly licensed until rights are clarified and recorded.

### 17.2.7 Restricted-use licenses.

Restricted-use licenses shall apply where an object may be shared only for limited purposes, limited users, limited rooms, limited jurisdictions, limited research, limited learning, limited review, limited handoff context, or limited public-safe use. Restricted-use licenses may prohibit redistribution, derivative works, commercial use, AI training, public display, download, export, operational use, high-stakes use, or handoff without further approval.

Restricted-use licenses shall be written clearly enough that users understand what is permitted, what is prohibited, what permissions are needed, what correction duties apply, and what boundary notices travel with the object.

### 17.2.8 Non-commercial restrictions where appropriate.

Non-commercial restrictions may be applied where commercial reuse would undermine public-good purposes, violate contributor expectations, risk enclosure, exploit community or protected knowledge, create rights conflicts, or generate misuse risk. Non-commercial restrictions shall be applied carefully, because they may reduce adoption, interoperability, enterprise handoff utility, and sustainability. Where used, they shall be explicit and justified by object class, rights basis, safeguard needs, or public-good continuity.

Non-commercial restrictions shall not be used to create hidden sponsor advantage, provider exclusivity, private control, or gatekeeping inconsistent with DDPGF public-good purpose.

### 17.2.9 No-AI-training restrictions where appropriate.

No-AI-training restrictions may be applied to datasets, reports, public-safe summaries, protected knowledge, community-sensitive materials, Indigenous protocol-sensitive materials where applicable, youth data, health data, sensitive geospatial data, cyber-sensitive materials, infrastructure-sensitive information, learning records, contributor records, images, interviews, and other objects where AI training would be unsafe, unauthorized, unfair, privacy-invasive, extractive, or inconsistent with rights and permissions.

No-AI-training restrictions shall be recorded in the license, data-use label, AI-use label, metadata, repository terms, Marketplace listing, Registry record, and public-safe notices where applicable. Absence of an explicit no-AI-training restriction shall not automatically imply AI training permission where data-use, privacy, protected knowledge, or license constraints remain unresolved.

### 17.2.10 Handoff-recipient-only restrictions.

Handoff-recipient-only restrictions shall apply to objects, packages, notes, data contexts, method contexts, Studio contexts, Grid inputs, TRL notes, public-safe status records, safeguard status records, dependency packages, and correction pathways made available only to identified lawful handoff recipients. Such restrictions shall define recipient class, purpose, access class, confidentiality obligations, data-use limits, AI-use limits, onward sharing limits, recipient responsibilities, correction duties, recall duties, and archive obligations.

Handoff-recipient-only restrictions shall not transfer intellectual property, data rights, implementation authority, procurement status, financeability, insurability, public authority approval, provider selection, community consent, Indigenous consent, deployment authorization, or execution authority unless separately and expressly recorded through competent processes.

## 17.3 Attribution and Credit

### 17.3.1 Author attribution.

Author attribution shall identify authors, drafting stewards, report writers, technical note authors, learning object authors, documentation authors, methodology authors, and other creators of knowledge objects. Attribution shall include name or approved identifier, role, affiliation where appropriate, contribution scope, date or version, and citation format where applicable. Author attribution may be public, controlled, pseudonymous, aggregate, or withheld where privacy, safety, youth protection, security, or protected knowledge concerns require.

Author attribution shall not imply institutional endorsement, public authority approval, professional certification, legal responsibility beyond recorded role, or execution authority.

### 17.3.2 Contributor attribution.

Contributor attribution shall recognize contributors to code, data, documentation, review, translation, accessibility, learning materials, Campaigns, Foundry objects, DRI objects, GRIx objects, Observatory objects, Studio workflows, Reports, public-safe summaries, and correction records. Contributor attribution may be linked to iCRS, ILA, repository records, Registry records, Marketplace records, or contribution logs where appropriate.

Contributor attribution shall not create employment, compensation, equity, token rights, procurement qualification, credential status, provider validation, or endorsement by default. Contributors may choose limited display or non-public attribution where permitted.

### 17.3.3 Maintainer attribution.

Maintainer attribution shall identify persons, teams, institutions, Working Groups, Competence Cells, National Nodes, Foundry teams, Registry stewards, Marketplace stewards, repository stewards, data stewards, model stewards, or documentation stewards responsible for maintaining an object. Maintainer attribution shall record maintainer scope, version scope, support scope, contact pathway where appropriate, and correction responsibility.

Maintainer attribution shall not create professional licensing, public authority status, deployment authority, procurement authority, finance authority, or personal warranty by default.

### 17.3.4 Data source attribution.

Data source attribution shall identify the source of data where lawful, safe, and appropriate. It may include dataset title, source institution, jurisdiction, collection method, version, date, DOI or identifier, license, data-use label, public-safe status, and limitations. Where source disclosure would create privacy, security, protected knowledge, community, Indigenous protocol, or public authority sensitivity risks, attribution may be generalized, controlled, or metadata-only.

Data source attribution shall not create permission to access, reuse, republish, train AI systems on, transfer, commercialize, or hand off the data.

### 17.3.5 Model source attribution.

Model source attribution shall identify model origins, base models, model interfaces, fine-tuning sources, evaluation tools, benchmark sources, model cards, system cards, benchmark cards, and related documentation where lawful and safe. It shall distinguish model source, model steward, model provider, model contributor, evaluator, and downstream user where appropriate.

Model source attribution shall not imply model validation, AI safety approval, provider endorsement, deployment authorization, procurement readiness, financeability, insurability, or public authority approval.

### 17.3.6 Sponsor acknowledgment.

Sponsor acknowledgment may recognize sponsor support, donor support, infrastructure support, event support, translation support, accessibility support, repository support, publication support, Campaign support, Academy support, Foundry support, Nexus Universe support, or other support recorded through support ledgers. Sponsor acknowledgment shall use approved language and shall be separated from object approval, review status, Registry status, Marketplace placement, technical conclusions, and handoff relevance.

Sponsor acknowledgment shall not imply sponsor ownership, sponsor control, sponsor endorsement, preferred status, procurement relevance, finance relevance, influence over content, influence over review, or validation of the sponsor.

### 17.3.7 Provider contribution acknowledgment.

Provider contribution acknowledgment may recognize technical, software, infrastructure, data, cloud, compute, model, API, repository, documentation, translation, or support contributions made by providers or enterprise actors. Acknowledgment shall identify contribution scope and shall include provider-neutrality notices where appropriate.

Provider contribution acknowledgment shall not imply provider validation, vendor approval, product certification, procurement recommendation, preferred supplier status, technical superiority, deployment authorization, or endorsement.

### 17.3.8 Public authority participation acknowledgment.

Public authority participation acknowledgment may record that a public authority participant attended, observed, contributed to learning, joined a public authority learning room, reviewed non-decisional materials, participated in a National Portfolio learning process, or engaged in Nexus Universe learning. Such acknowledgment shall be carefully worded to preserve non-decision status.

Public authority acknowledgment shall not imply official approval, policy adoption, regulatory acceptance, public finance allocation, procurement decision, permit, license, public warning, emergency command, or governmental endorsement.

### 17.3.9 Community contribution acknowledgment.

Community contribution acknowledgment may recognize community input, lived-risk knowledge, local context, resilience priorities, accessibility needs, public-interest review, community-facing correction, Campaign participation, or public-safe reporting contributions. Community acknowledgment shall be non-extractive, consent-aware, privacy-protective, and respectful of sensitive knowledge.

Community contribution acknowledgment shall not imply community consent, social license, approval, endorsement, permission to implement, permission to publish protected knowledge, or permission to operationalize local knowledge.

### 17.3.10 Indigenous protocol-sensitive acknowledgment where applicable.

Where Indigenous knowledge, participation, institutions, protocols, communities, territories, languages, or protected knowledge are involved, acknowledgment shall follow applicable Indigenous protocols, consent requirements, naming preferences, collective attribution rules, restrictions on disclosure, and protected knowledge controls. Acknowledgment may be withheld, generalized, controlled, or restricted where required by protocol, safety, or community direction.

Indigenous protocol-sensitive acknowledgment shall not imply consent, approval, transfer of knowledge rights, permission to disclose, permission to train AI systems, permission to commercialize, permission to implement, or permission to hand off unless separately and lawfully recorded.

## 17.4 IP Governance

### 17.4.1 Pre-existing IP.

Pre-existing intellectual property shall remain owned or controlled by its lawful owner unless separately licensed, assigned, contributed, or otherwise recorded. DDPGF shall require identification of pre-existing IP where objects incorporate third-party software, datasets, models, documentation, images, diagrams, trademarks, patents, research materials, training content, community knowledge, protected knowledge, or proprietary inputs. The applicable rights, restrictions, attribution duties, derivative-use limits, and redistribution conditions shall be recorded before release or reuse.

Pre-existing IP shall not be treated as DDPGF-owned, open, sublicensable, handoff-ready, or reusable merely because it appears in a Nexus workflow, repository, Studio environment, report, Marketplace listing, Registry record, or Nexus Universe output.

### 17.4.2 New IP.

New intellectual property created within DDPGF workflows shall be governed by the applicable contribution terms, employment or contractor terms where relevant, institutional policies, repository terms, license selection, support records, public-good purpose, and object-class requirements. New IP may be released openly, held under controlled license, restricted, assigned, jointly stewarded, archived, or excluded from release depending on rights, safety, public-good purpose, and downstream use.

New IP governance shall preserve public-good continuity, contributor fairness, institutional clarity, and correctionability. New IP shall not create execution authority, deployment authorization, procurement status, financeability, or provider preference by implication.

### 17.4.3 Joint contributions.

Joint contributions shall be recorded where multiple persons, institutions, communities, National Nodes, Working Groups, Competence Cells, providers, sponsors, public authority learning participants, universities, labs, or downstream actors contribute to an object. Joint contribution records shall identify contribution scope, rights basis, license terms, attribution expectations, contributor agreements where required, conflict issues, support expectations, and correction responsibilities.

Joint contribution shall not create joint venture, partnership, agency, shared liability, endorsement, procurement authority, public authority status, ownership transfer, or execution authority unless separately and expressly recorded by competent legal instruments.

### 17.4.4 Contributor agreements.

Contributor agreements may be required for software, documentation, data, models, learning objects, reports, translations, schemas, ontologies, dashboards, Studio workflows, or other DDPGF objects where rights clarity, contribution licensing, patent grants, moral rights, attribution, privacy, confidentiality, protected knowledge restrictions, or downstream reuse requires formal terms. Contributor agreements may be individual, organizational, repository-based, project-based, national, or object-specific.

Contributor agreements shall be proportionate and clear. They shall not disguise employment, waive statutory rights improperly, transfer protected knowledge without authority, create hidden enclosure, or enable sponsor or provider capture.

### 17.4.5 Patent-sensitive issues.

Patent-sensitive issues shall be identified where software, methods, models, technical baselines, protocols, APIs, hardware interfaces, telecom objects, AI-RAN/O-RAN-related objects, HPC workflows, cyber methods, digital twins, sensors, robotics, advanced manufacturing, semiconductors, biosecurity-sensitive systems, or other technical objects may implicate patents or patent applications. Patent notes may identify known patent considerations, contributor patent grants where applicable, patent exclusions, standards-interface concerns, and handoff dependency notes.

Patent-sensitive review shall not constitute freedom-to-operate opinion, patent validity opinion, legal advice, procurement approval, deployment authorization, or certification. Competent legal review shall be required for reliance.

### 17.4.6 Trade secret exclusions.

Trade secrets and confidential proprietary information shall not be incorporated into open DDPGF objects unless the owner has expressly authorized release and the release is lawful, safe, and recorded. Where proprietary information is reviewed in secure rooms, data rooms, readiness rooms, or handoff-recipient-only contexts, it shall remain subject to confidentiality, access controls, purpose limitation, output review, and archive controls.

DDPGF shall not convert trade secrets into public goods by exposure. Confidential review shall not create ownership, reuse rights, publication rights, AI training rights, or handoff rights.

### 17.4.7 Protected knowledge exclusions.

Protected knowledge shall be excluded from open release, unrestricted licensing, AI training, Marketplace exposure, Reports publication, public dashboards, repository publication, public handoff, or derivative use unless an appropriate lawful, protocol-compliant, and consent-aware process authorizes a defined use. Protected knowledge exclusions shall apply regardless of whether the knowledge was contributed verbally, through data, through community engagement, through fieldwork, through documents, through sensors, through geospatial layers, or through digital traces.

Protected knowledge exclusion shall be treated as a core public-good safeguard. Public-good purpose shall never be used as a justification for extraction or unauthorized disclosure.

### 17.4.8 Commercialization boundaries.

DDPGF may support lawful enterprise handoff, commercial reuse under license, professional services, national implementation, Project SPV pathways, National Consortium Company pathways, provider-supported implementation, and downstream enterprise activity where permitted. However, commercialization shall not capture public-good objects, misrepresent public-good status, violate licenses, bypass national ownership, override public authority dependencies, exploit protected knowledge, convert contributions into hidden private assets, or imply Nexus endorsement, procurement approval, financeability, insurability, or deployment authorization.

Commercialization boundaries shall be recorded in licenses, support statements, handoff notes, Marketplace listings, Registry records, provider contribution records, sponsor records, and no-conversion notices.

### 17.4.9 Handoff IP notes.

Handoff IP notes shall identify the IP status of objects included in lawful handoff context, including license terms, ownership, contributor rights, third-party rights, data rights, model rights, patent-sensitive issues, trade secret exclusions, protected knowledge exclusions, commercial-use limits, AI-use limits, derivative-use limits, support status, and recipient responsibilities. Handoff IP notes shall travel with handoff dependency packages.

A handoff IP note shall not transfer ownership, license rights, implementation rights, data rights, patent rights, trade secret rights, protected knowledge rights, procurement status, financeability, deployment authorization, or execution authority unless separately and expressly recorded through competent legal instruments.

### 17.4.10 Archive rights.

Archive rights shall define how DDPGF objects may be preserved, cited, displayed, sealed, restricted, withdrawn, recalled, superseded, or made non-continuing after active use ends. Archive rights may differ from active-use rights. Some objects may remain visible; some may become metadata-only; some may be sealed; some may be deleted where lawful and required; some may be preserved only in secure repositories.

Archive rights shall preserve institutional memory, correction traceability, attribution, public-safe history, and lawful retention without reviving current use rights, support rights, deployment rights, or execution authority.

## 17.5 Commons Anti-Capture Controls

### 17.5.1 No enclosure by sponsor.

No sponsor, donor, funder, host, or supporter shall enclose, privatize, control, restrict, rebrand, exclusively appropriate, or redirect DDPGF objects because of support provided. Sponsor support may be acknowledged, recorded, and linked to support ledgers, but shall not determine license selection, review outcome, Marketplace placement, Registry status, public-safe language, technical conclusions, handoff relevance, or downstream routing.

Sponsor support shall remain support without control. Any attempted enclosure shall trigger rights review, sponsor-boundary review, correction, public-safe notice where appropriate, and potential suspension of acknowledgment or support relationship.

### 17.5.2 No provider capture.

No provider, vendor, platform, infrastructure actor, technical contributor, consultant, operator, cloud provider, model provider, software contributor, or enterprise actor shall use DDPGF contribution to obtain provider validation, preferred-provider status, procurement advantage, exclusive technical control, Marketplace dominance, Registry influence, standards-interface control, or handoff routing control. Provider contributions shall be recorded with provider-neutrality notices.

Provider capture may occur through proprietary dependencies, restrictive APIs, hidden lock-in, opaque model access, controlled data dependencies, unsupported forks, paywalled essential components, exclusive support channels, or marketing overclaims. Such risks shall be reviewed, corrected, and restricted where necessary.

### 17.5.3 No hidden exclusivity.

DDPGF shall prohibit hidden exclusivity in licensing, access, support, Marketplace listing, Registry status, repository access, handoff routing, National Portfolio use, Nexus Universe presentation, Studio workflows, or public authority learning contexts. Any exclusivity required for legal, security, privacy, protected knowledge, data rights, or handoff reasons shall be expressly recorded, justified, time-bounded where appropriate, and subject to correction.

Hidden exclusivity shall be treated as a public-good firewall risk and may trigger correction, delisting, suspension, or withdrawal.

### 17.5.4 No pay-to-prioritize.

Payment, sponsorship, donation, support, infrastructure contribution, or provider contribution shall not purchase review priority, listing priority, Registry priority, Grid priority, TRL priority, public-safe publication priority, Nexus Universe priority, handoff priority, or National Portfolio priority by default. Priority shall be based on public-good relevance, risk, urgency, evidence need, correction urgency, national ownership, safeguard need, and recorded governance criteria.

Support may fund capacity, but it shall not buy influence over public-good status.

### 17.5.5 No pay-to-validate.

No actor shall obtain validation, endorsement, certification, approval, maturity status, TRL status, Marketplace feature, Registry status, public-safe status, public authority relevance, finance-readiness status, procurement relevance, provider neutrality status, or handoff status by payment, sponsorship, donation, or in-kind contribution. Review outcomes shall be evidence-based, role-separated, conflict-managed, and correctionable.

Any appearance of pay-to-validate shall require conflict review, public-safe correction where appropriate, and potential suspension of the affected record.

### 17.5.6 No restrictive downstream lock-in.

DDPGF shall avoid licensing, architecture, dependency, API, data, model, repository, cloud, compute, identity, or support arrangements that create unnecessary downstream lock-in inconsistent with public-good purpose, national localization, interoperability, correctionability, or lawful handoff. Where restrictions are necessary, they shall be transparent, justified, and bounded.

Lock-in risks shall be recorded in dependency records, license records, support records, Marketplace listings, Registry records, and handoff notes. Lock-in shall not be disguised as interoperability.

### 17.5.7 Fork governance.

Forks of DDPGF objects shall be governed to preserve license compliance, attribution, version clarity, public-safe notices, support status, correction pathways, security notices, Registry linkages where applicable, and no-conversion boundaries. Fork governance shall distinguish authorized forks, community forks, national localization forks, experimental forks, unsupported forks, deprecated forks, harmful forks, and withdrawn forks.

A fork shall not inherit endorsement, Registry status, support status, TRL status, public-safe status, handoff status, or Nexus affiliation unless separately reviewed and recorded. Forks shall not remove boundary notices or misrepresent origin.

### 17.5.8 Community stewardship.

Community stewardship shall support public-good continuity, contributor participation, localization, translation, accessibility, issue reporting, public-safe improvement, correction, and responsible reuse. Community stewardship may include maintainers, reviewers, translators, accessibility contributors, data stewards, Academy contributors, Foundry contributors, Campaign contributors, National Node contributors, and community-facing reviewers.

Community stewardship shall not permit capture by the loudest contributors, sponsors, providers, dominant institutions, external political interests, or private actors. Stewardship shall remain role-separated, record-based, conflict-managed, and correctionable.

### 17.5.9 Public-good continuity.

Public-good continuity shall require that DDPGF objects remain usable, traceable, correctable, and preservable across institutional cycles, sponsor cycles, provider changes, maintainer transitions, repository migrations, national localization, Nexus Universe cycles, Foundry cycles, Reports cycles, Marketplace changes, Registry changes, and handoff pathways. Continuity may require open formats, documented dependencies, archive mirrors, successor maintainers, license clarity, escrow-like documentation where appropriate, and non-continuation records where continuity cannot be preserved.

Public-good continuity shall not create indefinite support obligation, warranty, operational guarantee, or execution duty. Where continuity cannot be maintained, discontinuation shall be recorded honestly.

### 17.5.10 Correction of rights claims.

Rights claims shall be correctable. If an object is released under the wrong license, misattributes contributors, omits data source restrictions, exposes protected knowledge, misstates sponsor rights, misstates provider rights, violates third-party IP, overstates open status, omits AI-use restrictions, omits data-use restrictions, misstates handoff rights, or creates enclosure risk, the relevant record shall be corrected, suspended, withdrawn, recalled, superseded, or archived as appropriate.

Rights corrections shall propagate to repositories, Reports, Marketplace listings, Registry records, Studio workflows, Grid inputs, TRL notes, learning objects, Campaign materials, National Portfolio records, Nexus Universe outputs, and handoff packages where affected.

## 17.6 Licensing Boundary Rules

### 17.6.1 Public availability is not unrestricted use.

Public availability, repository access, Marketplace listing, Registry recording, Report publication, DOI assignment, open viewing, download availability, citation, or public-safe summary release shall not mean unrestricted use. Use remains subject to license terms, data-use labels, AI-use labels, access class, sensitivity class, attribution duties, public-safe restrictions, protected knowledge controls, community safeguards, Indigenous protocols where applicable, privacy obligations, security limits, third-party rights, and applicable law.

### 17.6.2 License is not warranty.

A license grants or restricts certain rights of use; it does not create warranty, fitness-for-purpose representation, security guarantee, accuracy guarantee, uptime commitment, professional reliance, public authority approval, procurement readiness, financeability, insurability, deployment authorization, or execution authority unless separately and lawfully stated in a competent agreement.

### 17.6.3 Attribution is not endorsement.

Attribution of authors, contributors, maintainers, data sources, model sources, sponsors, providers, public authority participants, communities, universities, funders, National Nodes, Working Groups, Competence Cells, or Indigenous institutions where applicable shall not imply endorsement, approval, validation, certification, public authority adoption, community consent, Indigenous consent, procurement recommendation, financeability, insurability, deployment authorization, or execution authority.

### 17.6.4 Sponsor support is not ownership.

Sponsor support, donor support, in-kind support, infrastructure support, translation support, accessibility support, event support, publication support, repository support, Campaign support, Foundry support, Academy support, or Nexus Universe support shall not create ownership, control, exclusivity, approval rights, review rights, Registry influence, Marketplace influence, handoff influence, public authority status, procurement relevance, finance relevance, or execution authority unless separately and lawfully recorded in a manner consistent with public-good firewall controls.

### 17.6.5 Provider contribution is not validation.

Provider contribution to software, data, models, APIs, dashboards, infrastructure, documentation, support, repositories, Studio workflows, secure rooms, or handoff context shall not validate the provider, certify the provider’s product, create preferred-provider status, create procurement recommendation, create technical superiority, create production approval, create security approval, create financeability, create public authority approval, or authorize deployment. Provider contributions shall remain bounded by provider-neutrality records and conflict controls.

### 17.6.6 Handoff note is not IP transfer unless separately recorded.

A handoff note, handoff context package, Marketplace handoff listing, Registry handoff record, Grid input, TRL note, Studio demonstration, Report, repository package, or public-safe summary shall not transfer intellectual property, data rights, model rights, software rights, patent rights, trade secret rights, protected knowledge rights, license rights, commercialization rights, deployment rights, procurement rights, finance rights, insurance rights, public authority rights, community consent, Indigenous consent, or execution authority unless a separate competent legal instrument expressly records that transfer or permission within defined scope.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/operations/frameworks/distributed-digital-public-goods-framework-ddpgf/xvii.-licensing.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.