This is going to be a long rambling post. So, here's a summary in case you want the highlights. 

TL;DR

Some AI tools can do more than answer questions. They can make plans, send messages, buy things, or use other computer tools. These systems are called AI agents.

I'm writing this post to ask an important question. 

Who is responsible if an AI agent makes a mistake or hurts someone? 

The AI itself is not a person. Responsibility may belong to the people or companies that built, changed, sold, or used it.

To decide who should be responsible, the article says we should ask:

1. Who controlled the AI?
2. Who gave it the power to act?
3. Who knew about the danger?
4. Who could have prevented the harm?

For example, a company may let an AI agent buy supplies. If the AI buys the wrong items, the company may still be responsible because it gave the AI permission to make purchases. Laws in the United States already recognize that computer programs can help form contracts Agency and Electronic Agents.

The article also explains open weights. Weights are important numbers that help an AI model work. A company may let people download these weights, but that does not always make the AI fully “open source.” True open-source AI gives people broader freedom and enough information to use, study, change, and share the system Open Source AI and Open Weights.

Licenses can set rules for using open weights. For example, a license might require people to:

• Test the AI before using it;
• Explain how they changed it;
• Protect private information;
• Watch for safety problems;
• Report serious incidents; and
• Keep records of what the AI did.

But a license cannot erase every legal duty. A company may still be responsible if it uses AI carelessly or places it in a dangerous situation Negligence and Enterprise Liability.

The article connects these ideas to the LinkedIn post I wrote called, 11 Pillars of a Scalable AI Governance Framework. The pillars encourage organizations to create clear leadership, use good data, protect security and privacy, treat people fairly, allow human review, make AI accessible, monitor it, follow the law, and train workers Introduction.

What I Hope You Takeaway

AI should help people, but people and companies must remain responsible. They should test AI, set clear limits, keep records, protect users, and make sure a human can step in when an important decision is being made.

Beyond Just Models - Thinking About Agentic Liability and Open-Weights Licensing

Abstract

Agentic AI does not fit neatly into familiar legal categories. It uses software systems that can plan, route work, negotiate, call tools, and carry out tasks with little real-time human review. At the same time, the market for “open” AI has split into three legally different groups. These are truly open-source AI, source-available model releases, and open-weights distributions. Open weights give users a model’s learned parameters, but not all the freedoms that come with open source. argue that the law should address these two changes together. We should not decide liability by treating the model like a person. Instead, the law should assign responsibility across the AI value chain based on control, capability, knowledge, and risk. A license cannot replace public law. But it can put governance into practice by setting duties for provenance, or where data and models came from; evaluations; notices to later users; incident reports; audits; security; and control over operations.

compare U.S. and EU law. I cover agency and attribution, which ask whose acts count under the law. I also cover contracts made by electronic agents, negligence, product liability, enterprise liability, causation, evidence burdens, copyright, license enforcement, warranties, disclaimers, indemnities, audit rights, and regulatory duties. I place those rules within the EU AI Act, Directive (EU) 2024/2853 on defective products, the U.S. E-SIGN Act and UETA, and recent U.S. Copyright Office guidance on AI. I then draw on my October 8, 2025 governance model, called the “11 Pillars of a Scalable AI Governance Framework.” The model offers a practical structure for assigning risk before harm occurs, or ex ante, and enforcing accountability afterward, or ex post.[^1] The result treats agentic liability and open-weights licensing as two sides of the same governance problem, not as separate debates.

Introduction

The key legal question about agentic AI is not whether a model is “autonomous.” The question is who should answer for what happens when it acts. An agentic system may find information, choose tools, write messages, make recommendations, place orders, or start the next step in a workflow. But people and organizations still stand behind every act. They may include the model developer, licensor, fine-tuner, deployer, infrastructure provider, principal, and user. The law already knows how to divide responsibility in systems with many actors. What it needs is a clear method for applying old legal rules to these new technical layers.[^2]

AI licensing raises a related problem. The label “open” no longer has one clear meaning. The Open Source Initiative’s Open Source AI Definition requires real freedom to use, study, change, and share a system. It also requires access to the preferred form for changing the system and its key parts.[^3] In contrast, many well-known “open” releases provide model weights under custom terms, limits on use, or limited documents. Model weights are the learned numerical parameters that shape the model’s output. These releases may be useful and easy to reuse. Still, they are not always open source in the legal sense. They are better called open-weights or source-available models.[^4]

These two debates meet because a license is often the first tool an AI provider uses to manage later risk. Licensors may ban certain uses, disclaim warranties, require credit, require notices to later users, and keep audit rights. But contract terms alone cannot decide liability when a model is used to sort healthcare cases, rank job applicants, or make purchases on its own. Courts and regulators will ask familiar questions. Who controlled the system? Who knew about the risk? Who could have reduced it at the lowest cost? Who gained from the deployment? And who was best able to save the evidence?[^5]

make three claims. First, the law should assign agentic liability by looking at what each actor did. It should not pretend that the “AI” itself is a legal person. Second, an open-weights license should serve as a layer of governance, not just as an intellectual property, or IP, tool. Third, my “11 Pillars of a Scalable AI Governance Framework” connect legal rules to daily practice. The pillars describe the controls that courts and regulators increasingly expect: governance structure, data controls, security, privacy, transparency, fairness, human oversight, accessibility, monitoring, legal alignment, and documentation.[^1]

Relevant Doctrines

A. Agency, Attribution, and Electronic Agents

U.S. and EU law start with a basic rule. Software does not become a legal person just because it can act without live human review. In the United States, E-SIGN says a contract does not lose legal effect only because one or more electronic agents helped form it. But the agent’s act must be legally tied, or attributed, to the person who will be bound.[^6] UETA follows the same approach. It also says electronic agents may form a contract with each other even if no person reviewed the final terms at that moment.[^7]

This matters for agentic AI in two ways. First, attribution is still central. The legal question is not whether the machine “meant” to cause the result. It is whether the law ties the act to the principal because of authorization, programming, deployment rules, or the parties’ past dealings. Second, laws on electronic agents support automated contracts. But they do not erase common rules about mistake, authority, unconscionability, fraud, or acts within the scope of employment.[^7] For example, a purchasing bot may bind a company when it accepts a vendor’s quote within limits set by the company. A defense may still apply if the vendor knew the bot had failed, took advantage of a clear error, or manipulated the system.

EU law takes a different path to a similar result. It relies less on a special law for electronic agents. Instead, it uses ordinary rules on attribution, authority to act for another, consumer protection, and conduct in platforms and markets. In short, responsibility falls on the legal actor that runs the system, not on the model itself.

B. Negligence and Enterprise Liability

Negligence remains the most flexible legal rule for harms caused by agents. The questions are familiar: Was the harm foreseeable? Did the actor use reasonable care? Did the actor breach that duty? Did the breach cause harm and damages? AI changes what reasonable care may require. For agentic systems, it increasingly includes:

• capability testing before deployment;

• boundary setting on tool use and authority;

• prompt and policy controls;

• logging and record retention;

• monitoring for drift, jailbreaks, hallucination patterns, and unsafe escalation;

• human review thresholds for high-stakes decisions; and

• incident response processes.

Enterprise liability becomes especially important when an organization gives work to an AI agent to cut labor costs or operate at a larger scale. The principal gets the benefits of automation. It is also often the party that can prevent harm at the lowest cost. For both legal and practical reasons, the organization should not be able to shift all responsibility to end users through terms of service alone.

C. Product Liability in the EU and Its Spillover Significance

The EU’s revised Product Liability Directive, Directive (EU) 2024/2853, is especially important. It updates strict liability, which can apply without proof of negligence, for products that use digital tools and AI. The Directive clearly includes software in its product rules. It treats some parties that make major changes as manufacturers. It also says courts must judge defects in light of cybersecurity and learning that occurs after sale. When a claimant faces extreme technical difficulty, a court may order disclosure of evidence and use rebuttable presumptions, which are findings the other side may disprove.[^8]

Several parts of the Directive matter for agentic systems. A court may judge whether a product is defective by looking at how it was presented, its instructions, its reasonably foreseeable use, its ability to learn after sale, its links to other products, and cybersecurity rules tied to safety.[^8] So model cards, safety documents, limits on tool use, and warnings to later users can have legal weight. They are not just good ideas. The Directive also makes proof easier in some cases. If a defendant does not share key evidence, or if technical complexity makes proof far too hard, a court may presume a defect or causation. The defendant may rebut that presumption.[^8] In a hard-to-see AI stack, access to evidence may matter as much as the merits.

The Directive also takes a careful approach to free and open-source software. Software supplied outside commercial activity is generally outside the Directive. But when that software becomes part of a commercial product, the commercial maker may be liable for defects that result.[^9] This rule will likely shape disputes about later use of open weights. An open release by an upstream provider does not shield a downstream company that puts it into a commercial product.

D. Causation and Evidentiary Burdens

Causation is often the hardest legal issue in disputes about agentic AI. Causation asks whether the challenged conduct led to the harm. AI systems have many layers, can adapt, and often work by probability rather than certainty. Harm may come from prompt design, fine-tuning, a tool call, a collection of retrieved material, a business rule, user misuse, or workplace incentives. This complexity creates an evidence gap. Claimants often do not have the logs, model documents, internal tests, or failure reports held by the other side.

The EU addresses that evidence gap more directly than the United States. Its Product Liability Directive uses disclosure and presumptions to help claimants in some cases.[^8] U.S. law is more scattered. Still, ordinary evidence rules, discovery duties, the risk of spoliation, or loss of evidence, and adverse inferences still matter. An adverse inference lets a court draw a harmful conclusion when a party failed to preserve evidence. In practice, an organization should be able to rebuild what an AI agent saw, decided, and did. If it cannot, it may lose both trust and an advantage in court.

E. Copyright, IP Scope, and License Enforceability

Open-weights licenses sit on top of several uncertain and overlapping IP rights. U.S. copyright law clearly covers code, documents, and many datasets. It is less clear how far copyright covers model weights or learned parameters by themselves. The U.S. Copyright Office has made two useful points. First, an AI-assisted output needs enough human authorship to receive copyright. Second, the Office is still studying the use of copyrighted works in AI training. It released Part 3 of its AI report in pre-publication form on May 9, 2025.[^10] The practical lesson for deal lawyers is simple. A license may involve a mix of rights, so drafters should not claim more certainty than the law supports.

U.S. courts have enforced open-source licenses. In Jacobsen v. Katzer, the Federal Circuit held that open-source license terms can act as enforceable copyright conditions.[^11] Courts have also allowed contract claims for breaking an open-source license when the complaint properly alleges agreement and exchange. The Ghostscript/Hancom dispute is one example.[^12] The lesson for AI licenses is clear. Rules about credit, notices to later users, or redistribution are not just good manners. When drafted correctly, they may have legal force.

Still, copyright cannot do all the work. Limits on a field of use, duties to test a model, or safety-reporting rules may be contract covenants even when copyright coverage is unclear. A covenant is a promise in a contract. AI licenses should therefore use both copyright conditions and contract covenants where appropriate.

Open Source AI, Source-Available Models, and Open Weights

These legal categories matter because policy debates often mix them together.

Category	Core Legal Character	Typical Access	Typical Restrictions	Best Description
Open-source AI	Released on terms that allow use, study, change, and sharing, with access to the preferred form for changing the system	Weights, code, and enough data, documents, or similar information	No limits based on the field of use, as understood in classic open source	True open-source release
Open weights	Model parameters are public, but other parts may be missing or under separate licenses	Weights and some documentation; code/data may be partial	May or may not include use restrictions	Weight-access release
Source-available model	Access is given under proprietary or custom terms	Varies widely	Often includes rules for acceptable use, competition, or scale	Publicly available, but not open source

The OSI’s Open Source AI Definition 1.0 centers on the classic freedoms to use, study, change, and share. For machine-learning systems, the needed materials include the architecture, parameters, inference code, and information needed to understand and change the system.[^3] As a result, many familiar releases are not legally open source, even if anyone can download them.

Meta’s Llama licenses show the difference. They make model materials widely available and allow many kinds of use and change. But they also use custom license terms and limits in their use policies. These releases are best described as source-available, open-weight models, not OSI-compliant open-source AI.[^4] RAIL-style licenses also support broad reuse while adding responsible-use limits. That approach may help governance, but it is not the same as an open-source software license.[^13] The PyTorch Foundation’s OpenMDW effort rests on a related point. AI models need licenses built for a mix of materials, including architecture, weights, code, documents, data, and related rights. Simply extending a software-only license is not enough.[^14]

A Proposed Framework: Control, Capability, Knowledge, and Risk

The law should divide agentic liability across the AI stack by using four factors.

1. Control

Who set the system’s operating rules, permissions, connections, limits, and use setting?

• High-control actors include deployers, organizational principals, and fine-tuners that can set guardrails for a field.

• Moderate-control actors include infrastructure and tool providers that control APIs, routing, permissions, rate limits, or safety layers.

• Lower-control actors include upstream weight licensors that cannot access a deployment and did not keep governance controls.

2. Capability

Who created or greatly changed the ability that caused the harm?

• base-model developers, for broad reasoning or tool-use abilities;

• fine-tuners, for patterns of action in a certain field;

• deployers, for workflow connections and business rules;

• tool providers, for ways to act, such as payment APIs or permission to write to a customer relationship management system, or CRM.

3. Knowledge

Who knew, or should have known, how the system could fail?

• actual knowledge from tests, incident reports, red-team findings, or user complaints;

• constructive knowledge, meaning what the actor should have known, from public benchmarks, common failures, or regulatory warnings;

• greater knowledge shown by sole access to logs, model cards, or internal tests.

4. Risk

Who created, increased, or made money from the risk? Who could reduce it at the lowest cost?

• organizations that give high-stakes decisions to agents should have greater duties;

• companies that put open weights into products should not push all risk onto upstream communities;

• keeping the financial benefit supports assigning liability to the enterprise.

Allocation Matrix

Actor	Primary Duties	Typical Liability Theories	Best Risk Controls
Model developer / licensor	explain abilities and limits; train and test responsibly; publish sources and warnings	negligence; product liability in some places; misrepresentation; breach of license	model cards, evals, usage limits, security controls
Fine-tuner / modifier	assess major changes; test task fitness again; record differences	negligence; substantial-modification liability; contract	change logs, benchmark differences, tests for the field
Deployer / integrator	set the scope of authority; review outputs; ensure the workflow is lawful	negligence; enterprise liability; sectoral compliance	human-in-the-loop, or HITL, review gates; escalation limits; logs; policy rules
Tool / infrastructure provider	secure ways to act; keep records; enforce permissions	negligence; aiding theories; contract	API controls, authentication, audit trails
Organizational principal	governance, training, oversight, incident response	agency and attribution; rules like respondeat superior, which can make an employer answer for a worker’s acts; negligence	board-level governance, approval matrices
User / operator	lawful use; follow instructions; avoid misuse	contributory fault; contract	training, notices, access controls

This framework avoids two bad extremes. It does not blame the model as if it were a person. It also does not excuse everyone just because the output came from a complex system.

Real-Life Applicability

A. Autonomous Purchasing Agent

Suppose a company uses a purchasing agent. The agent may find office equipment and buy it through a payment API up to a set dollar limit. The agent accepts a vendor listing that someone has manipulated and buys fake devices. Under U.S. law on electronic agents, the contract may still count as the company’s act if the system stayed within the authority the company gave it.[^6] The dispute then turns to negligence, mistake, the vendor’s knowledge, and the company’s controls. Did the deployer check signs about the vendor’s reputation? Did it limit product types, sellers, or payment methods? Did the tool provider keep logs? If the vendor knowingly used a weakness in the system, that fact affects both contract and tort claims. A tort is a civil wrong that causes harm. Still, the company receives the main benefit from automation and will likely bear most of the loss.

B. Customer-Service Agent Making Commitments

Now suppose a customer-service agent can offer refunds and service credits. It starts making promises outside company policy. This happens because its source documents are old and its conversation rules do not limit its authority. Customers rely on those promises. Ordinary attribution rules give a clear answer. The company built and branded the interface, then asked customers to rely on it. The more the agent appears to have authority, the harder it is for the company to argue later that “the bot was unauthorized.” Contract law, estoppel-like rules, consumer protection, and negligence all point in the same direction. Estoppel can stop a party from denying a claim when another person reasonably relied on its words or conduct. The answer is not to deny agency. It is to build limits, such as a fixed list of offers, approval for exceptions, and policy sources that the agent cannot change.

C. Healthcare or Employment Workflow

Liability has more layers in healthcare triage and job screening because special duties for those fields are stronger. A hospital may use an agent to summarize records and decide which cases need quick review. If the work is high stakes and important error rates are foreseeable, the hospital cannot rely on a broad disclaimer from an upstream provider. An employer that uses an agent to rank applicants or draft reasons for rejection also faces concerns about fairness, discrimination, and records. In both settings, human review must be real, not for show. The organization chose where to use the system, placed it in an important process, and controls how to correct harm. Under my framework, the deployer and principal carry the most responsibility. The upstream developer’s responsibility grows if it knew the model could fail in that field and did not clearly disclose the risk.

D. Downstream Deployment of Open Weights

Finally, consider a startup that downloads open weights. It fine-tunes them to screen legal clients and offers the result to consumers. The startup cannot fairly claim that an open upstream release removes its own duties. Under the EU Product Liability Directive, a party that makes a major change may count as a manufacturer. Under the AI Act, a downstream provider may have its own duties based on the system’s legal class and how it enters the market.[^8] An upstream licensor may avoid some AI Act transparency duties when it uses a qualifying free and open-source license. Even then, duties about copyright policy and summaries of training content may remain. And the exemption does not apply to general-purpose AI, or GPAI, models with systemic risk.[^15]

Governance Architecture Through My Eleven Pillars

My October 8, 2025, article is hopefully useful. It treats AI governance as part of how an organization runs, not as an extra compliance checklist.[^1] For agentic liability and open-weights licensing, my 11 pillars work as follows:

My Pillar	Liability Function	Licensing Function
Organizational structure	sets who may decide and who is accountable	identifies licensor, modifier, deployer roles
Data/input governance	reduces harm from bad inputs and disputes about sources	requires the source history of datasets and notices about use
Security	reduces prompt injection, model theft, and tool abuse	requires stronger security and incident reports
Privacy	limits misuse of sensitive inputs and outputs	assigns duties for following privacy law
Transparency / explainability / ability to challenge	supports attribution, evidence, appeals	requires model cards, downstream notices
Fairness / equity	reduces discrimination exposure	requires evaluation disclosures
Human oversight	stops too much delegation in high-stakes settings	defines reserved decisions and override rights
Accessibility / internationalization	reduces exclusion and misunderstanding	requires local language and accessible notices
Monitoring / audit	keeps evidence and catches drift, or change over time	creates audit rights and logging duties
Legal / ethical alignment	connects the system to the law in each place	ties use rights to compliance obligations
Documentation / training	proves reasonable care	supports duties passed to later users and promises to provide training

A generous commenter suggested adding Cultural Adoption. Adoption is incredibly important because without it, the organization has not implemented. For the purposes of this article, I've left it out of the analysis, but Ben's comment should be incorporated an overarching organizational framework. 

I hope this framework helps both in running organizations and legal disputes. Courts and regulators increasingly ask whether governance, testing, records, escalation, and audits matched the level of risk. My pillars can therefore serve as evidence that an organization acted with care, not just as a list of best practices.

Licensing Recommendations for Open Weights

An open-weights license should be a governance tool. It should clearly assign operating duties that can be enforced. The following terms matter most.

A. Permitted Scope and Controlled Use

Clearly say whether the allowed use is commercial, noncommercial, only for research, or limited to a certain field. If some uses are banned, say whether each limit is a license condition, a contract covenant, or both. Unclear terms are harder to enforce.

B. Attribution, Provenance, and Downstream Notices

Require retention of:

• attribution notices;

• model/version identifiers;

• modification and fine-tuning records;

• available information about the sources of training or test materials; and

• notices to later users about known limits.

C. Evaluations, Security, and Incident Reporting

For capable models, include obligations to:

• run basic safety tests and tests for the field before deployment;

• preserve records of those evaluations;

• use reasonable security against model extraction, abuse of jailbreaks, and unsafe tool calls; and

• report serious incidents within defined periods.

These terms match new AI Act expectations for records, tests of systemic risk, cybersecurity, and reports of serious incidents.[^15]

D. Allocation of Control

The license should specify which party controls:

• base weights;

• fine-tuned variants;

• deployment prompts and policies;

• tool integrations;

• safety layers;

• end-user interfaces; and

• post-deployment monitoring.

This makes it harder to shift blame and helps the parties design indemnities. An indemnity requires one party to cover certain losses of another.

E. Modification and Fine-Tuning Terms

Require material modifiers to:

• rename materially altered variants;

• document significant parameter, dataset record major changes to parameters, datasets, or policies;

• re-run stated evaluations for sensitive uses; and

• take responsibility for new ways the model may fail because of fine-tuning.

F. Warranties, Disclaimers, Indemnities, and Insurance

Disclaimers remain useful, but they are not talismans. Upstream licensors should disclaim merchantability, fitness, and uninterrupted performance to the maximum extent permitted, while recognizing that mandatory law may override such terms. Deployers in regulated or high-stakes settings should not expect an upstream disclaimer to protect them from claims by users or regulators. Indemnities should match each party’s risk:

• licensor indemnity for knowing IP misrepresentation or intentional malware/backdoor insertion;

• modifier indemnity for harms arising from material changes;

• deployer indemnity for workflow misuse, unlawful sectoral deployment, or failure to implement required oversight.

Insurance requirements may be appropriate for high-risk enterprise deployments.

G. Audit Rights

Audit rights should be targeted, not punitive. A mature structure includes:

• records-access rights tied to suspected serious breach;

• confidentiality protections and trade-secret handling;

• third-party assessor options;

• remediation periods; and

• termination rights for uncured critical violations.

Recommendations

1. Adopt a role-based liability map before deployment. Every agentic system should have a written matrix assigning responsibility across developer, modifier, deployer, infrastructure provider, and principal.

2. Treat logging and evidence preservation as core safety functions. In both litigation and regulation, inability to reconstruct system behavior is itself a governance failure.

3. Use the term “open source” precisely. If a release does not satisfy OSI-style openness, call it open weights or source-available, not open source.

4. Draft AI licenses as dual-track instruments. Separate copyright conditions from contractual operational covenants.

5. Reserve human authority for consequential acts. Commitments involving payment, employment, healthcare, legal rights, or safety should have explicit escalation thresholds.

6. Bind substantial modifiers. Fine-tuners and downstream integrators should inherit baseline duties and assume liability for material alterations.

7. Align governance with my eleven pillars. The framework offers a practical checklist for proving reasonable care, organizational ownership, and continuous compliance.[^1]  

Conclusion

Agentic AI does not require law to invent a robotic personhood doctrine. It requires law to see clearly where authority, capability, knowledge, and risk actually sit. Once that is done, familiar doctrines, like agency, negligence, product liability, enterprise responsibility, causation, and evidentiary allocation, remain surprisingly adaptable. The harder challenge lies in implementation: documenting who controlled what, who changed what, and who knew what when the system acted.

Open-weights licensing sits at the center of that implementation challenge. It cannot displace public law, but it can distribute governance obligations through the AI supply chain. The most defensible path forward therefore combines doctrinal realism with operational specificity: precise categorization of openness, carefully segmented contractual duties, and institutional controls consistent with my eleven-pillar architecture. Beyond the model, accountability belongs to the humans and entities who build, release, modify, deploy, and profit from agentic systems.

Footnotes

[^1]: Daphné Pierre, 11 Pillars of a Scalable AI Governance Framework (LinkedIn, Oct. 8, 2025). I identify eleven governance pillars: organizational structure; data/input governance; security; privacy; transparency, explainability, and contestability; fairness; human oversight; accessibility and internationalization; monitoring and audit; legal and ethical alignment; and documentation and training.

[^2]: See Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024, art. 1, art. 2, 2024 O.J. (L 1689) 1 (establishing a Union-wide framework governing providers and deployers of AI systems and GPAI models); European Commission, AI Act (application timeline noting entry into force on Aug. 1, 2024 and general applicability from Aug. 2, 2026, with exceptions). (eur-lex.europa.eu)

[^3]: Open Source Initiative, The Open Source AI Definition 1.0 (defining Open Source AI around the freedoms to use, study, modify, and share, together with access to the preferred form for modifications and the means to use the system). (opensource.org)

[^4]: See Meta, Llama 2 Community License Agreement (granting broad rights but under bespoke terms and an incorporated acceptable-use policy); Meta, Introducing Llama 3.1 (describing an openly available model release while also discussing license changes and ecosystem controls). These features make Llama-style releases better understood as source-available open-weight models than OSI-compliant open-source AI. See also Hugging Face, OpenRAIL: Towards Open and Responsible AI Licensing Frameworks (explaining licenses that combine broad access with use restrictions). (ai.meta.com)

[^5]: See NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0); NIST AI RMF Playbook, Govern function (emphasizing governance, documentation, legal/regulatory understanding, and continuous risk management across the AI lifecycle). (nvlpubs.nist.gov)

[^6]: Electronic Signatures in Global and National Commerce Act, 15 U.S.C. §§ 7001(h), 7006(3) (providing that contracts involving electronic agents may not be denied legal effect solely for that reason, if the action is legally attributable to the person to be bound, and defining “electronic agent”). (law.cornell.edu)

[^7]: Unif. Elec. Transactions Act §§ 9, 14 (Unif. L. Comm’n 1999) (addressing attribution and automated transactions); id. prefatory note and comments (stating that the Act validates electronic transactions without displacing underlying substantive law and that electronic agents bind the user of the machine). (uniformlaws.org)

[^8]: Directive (EU) 2024/2853 of the European Parliament and of the Council of 23 October 2024 on liability for defective products, arts. 7–10, 2024 O.J. (L 2853) 1 (defectiveness, liable economic operators, disclosure of evidence, burden of proof, and presumptions); id. art. 8(2) (treating certain substantial modifiers as manufacturers). (eur-lex.europa.eu)

[^9]: Id. recitals concerning software and free/open-source software supplied outside commercial activity, while preserving liability for downstream commercial manufacturers integrating such software into products. (eur-lex.europa.eu)

[^10]: U.S. Copyright Office, Copyright and Artificial Intelligence (noting Part 2 on copyrightability issued Jan. 29, 2025, and Part 3 on generative AI training released in pre-publication form on May 9, 2025); U.S. Copyright Office, Copyright Registration Guidance: Works Containing Material Generated by Artificial Intelligence (Mar. 16, 2023); U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability (concluding that copyrightability turns on sufficient human authorship, not prompts alone). (copyright.gov)

[^11]: Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008) (recognizing that open-source license terms may operate as enforceable copyright conditions). (cafc.uscourts.gov)

[^12]: Artifex Software, Inc. v. Hancom, Inc., No. 3:16-cv-06982 (N.D. Cal.) (allowing contract theories tied to alleged open-source license noncompliance to proceed past the pleading stage, and later settling). See also Artifex, Artifex and Hancom Reach Settlement Over Ghostscript Open Source Dispute. (app.midpage.ai)

[^13]: Hugging Face, OpenRAIL: Towards Open and Responsible AI Licensing Frameworks (describing RAIL licenses as combining open access with identified responsible-use restrictions). (huggingface.co)

[^14]: PyTorch Foundation, The Open Source Legacy and AI’s Licensing Challenge (describing OpenMDW as a purpose-built license for model architecture, parameters, code, documentation, data, and related rights, developed to operationalize the Model Openness Framework). (pytorch.org)

[^15]: AI Act art. 53(1)–(2), art. 54(6), art. 55, art. 56 (GPAI obligations, open-source exceptions, systemic-risk obligations, and codes of practice); European Commission, Guidelines on Obligations for General-Purpose AI Providers (published July 18, 2025) (clarifying that open-source GPAI providers may be exempt from certain technical-documentation, downstream-documentation, and EU-representative obligations if conditions are met, but still owe copyright-policy and training-summary duties, and that systemic-risk models remain fully covered). (eur-lex.europa.eu)