Category: Litigation & Enforcement

Current through June 9, 2026.

The OpenAI copyright multidistrict litigation matters because it has already produced claim-specific rulings and unusually consequential discovery disputes involving model-development records, privilege, and large sets of ChatGPT conversation logs.

No court has entered a final judgment on whether OpenAI's model training is fair use. The litigation still gives companies a practical warning: ordinary decisions about retention, deletion, vendor terms, and internal records can become central evidence in a major lawsuit.

Where the MDL stands

The Judicial Panel on Multidistrict Litigation created MDL No. 3143 on April 3, 2025, transferring four actions to the Southern District of New York for coordinated or consolidated pretrial proceedings. Additional actions have since been transferred.

The consolidated cases are not identical. They include claims by authors, newspapers, publishers, and other rights holders involving model training, allegedly infringing outputs, contributory infringement, and provisions of the Digital Millennium Copyright Act concerning copyright-management information.

An MDL coordinates overlapping pretrial work, but it does not turn every plaintiff’s theory into one claim or decide that any claim will succeed.

The case has moved beyond consolidation

In a December 15, 2025 ruling involving Ziff Davis, the court allowed several claims to proceed past a motion to dismiss, including contributory-infringement and certain DMCA copyright-management-information claims. It dismissed other theories, including the claim that disregarding robots.txt instructions constituted circumvention of an effective technological measure. The ruling did not decide liability, but it showed that the litigation will turn on specific claims, facts, and model behavior rather than one sweeping answer about AI and copyright.

Discovery has become just as important as the pleading rulings:

• In January 2026, Judge Stein upheld orders requiring production of a sample of 20 million de-identified ChatGPT conversation logs.
• In March 2026, Magistrate Judge Wang granted in part a request involving additional reservoirs of 78 million and 10 million logs, subject to a protocol addressing de-identification and user privacy.
• In May 2026, the court ordered OpenAI to produce deposition testimony from separate litigation involving Sam Altman, Greg Brockman, Satya Nadella, and an OpenAI corporate designee after finding the narrowed request relevant and proportional.
• In February 2026, Judge Stein set aside a magistrate judge’s ruling that OpenAI had waived attorney-client privilege over certain 2022 communications concerning the Books1 and Books2 datasets and Library Genesis.

Those developments do not establish infringement. They do show what an AI copyright case can demand once it reaches coordinated discovery.

The clearest governance lesson is about data

The MDL has made retention and discovery policy part of the copyright-risk discussion.

For enterprise users, the immediate lesson is not that their prompts will necessarily become evidence in this case. It is that vendor data practices, contractual promises, litigation holds, and court-ordered discovery can interact in ways that are easy to overlook during procurement.

Legal, privacy, security, and procurement teams should ask:

• What prompts, outputs, metadata, and logs does the vendor retain?
• Which retention settings are defaults, and which require an enterprise plan or approval?
• Can ordinary deletion schedules be suspended by a legal hold, court order, or regulatory obligation?
• What data may be used to improve models, and what requires an affirmative opt-in?
• Which internal repositories or systems can the tool access?
• Can the company preserve its own audit trail without collecting more sensitive content than it needs?

OpenAI states that business-product and API data are not used to train its models by default. It also states that API inputs and outputs are generally removed after 30 days unless legal requirements require retention, and that eligible customers may request zero-data-retention controls for qualifying endpoints. Those are meaningful controls, but buyers still need to understand exceptions, product-specific settings, and what happens when litigation or another legal obligation changes the ordinary retention rules.

Procurement terms need operational follow-through

Contract review remains important, but contract language alone is not a governance program.

Buyers should evaluate vendor representations about training data, output restrictions, indemnity, retention, confidentiality, security, and cooperation during disputes. They should also make sure internal settings and workflows match the negotiated terms.

A contract may promise strong business-data protections while employees continue using consumer accounts. A zero-retention option does little if it was never enabled for the relevant endpoint. A restriction on confidential data will not help if the organization has no practical rule for deciding which repositories or matters an AI coding or research tool may access.

Code-generation controls remain useful, but they are a separate issue

AI-generated code presents a related but distinct set of copyright and open-source-license risks. Companies should not treat the OpenAI MDL as proof that generated code infringes or that any particular compliance control is legally required.

Still, software companies have practical reasons to treat AI-generated code like third-party code until it is reviewed:

• use approved enterprise coding tools and accounts;
• enable public-code matching or reference features where available;
• require human review for long or unusually specific generated snippets;
• scan generated code for open-source and snippet-level risks before release;
• document remediation of flagged code; and
• restrict sensitive repository and file access.

GitHub documents a policy that can block Copilot suggestions matching publicly available code or allow them with code references. Cursor states that Privacy Mode enables zero data retention for model providers, while also explaining that some code data may still be stored to provide additional features and that codebase indexing involves uploads for embedding. These controls address different risks. Public-code matching is not a confidentiality control, and privacy settings are not license-clearance tools.

What legal teams should do now

1. Map which AI products are in use, including consumer accounts and tools embedded in other software.
2. Record the actual retention, training, access, and deletion settings for each approved product.
3. Reconcile vendor contracts with technical configuration and employee practice.
4. Decide what AI-use records are genuinely needed for audit, compliance, or litigation readiness.
5. Apply separate controls for confidential data, generated code, external-facing content, and high-risk decisions.
6. Revisit the program when vendor terms, product settings, or major court rulings change.

What to watch next

The most consequential developments will be rulings that clarify training-copy theories, output-based claims, fair use, DMCA liability, and the permissible scope of discovery. Additional transfer orders also matter because they determine which disputes enter the coordinated proceeding.

For enterprise users, the discovery fights may be as instructive as the eventual merits rulings. They show that AI governance is not limited to deciding whether employees may use a tool. It includes knowing what the tool retains, what the company can control, and what may have to be preserved or produced when litigation begins.

Sources

• JPML transfer order creating MDL No. 3143
• Ziff Davis motion-to-dismiss ruling
• January 2026 order upholding ChatGPT-log discovery
• March 2026 discovery order
• May 2026 deposition-transcript order
• February 2026 privilege order
• OpenAI business-data privacy
• GitHub Copilot code-suggestion documentation
• Cursor data-use and privacy overview

Current snapshot: June 4, 2026.

Federal courts are not moving toward one uniform AI rule. They are moving toward a patchwork. Some judges prohibit AI use in filings. Some require disclosure or certification. Others simply remind lawyers that Rule 11, candor, confidentiality, and sanctions rules still apply.

That makes the practical rule simple: check the forum before filing, check the judge before drafting, and verify every AI-assisted citation, quotation, factual assertion, and legal proposition before it goes to court.

1. No-use or near no-use orders

The strictest orders do not merely require disclosure. They prohibit AI use for filings or memoranda.

Judge Christopher A. Boyko of the Northern District of Ohio has a standing order stating that no attorney or pro se party may use AI in preparing any filing submitted to the court. Judge Sharon Johnson Coleman of the Northern District of Illinois similarly states in her standing requirements that parties may not use AI to draft memoranda or as authority to support motions.

These orders are still the minority approach, but they matter because they show that some courts view AI-assisted drafting itself as the risk, not just unverified AI output.

2. Disclose if AI was used

The more common approach is disclosure. These rules do not necessarily forbid AI. They require the filer to say when AI was used and sometimes to identify the tool or the AI-generated portions.

The Northern District of Texas now requires a brief prepared using generative AI to disclose that fact on the first page under the heading “Use of Generative Artificial Intelligence.” If the required disclosure is absent, the filing operates as a certification that no part of the brief was prepared using generative AI.

Judge Michael M. Baylson of the Eastern District of Pennsylvania requires a clear factual statement disclosing AI use in papers filed in cases assigned to him and a certification that all citations to law or the record have been verified. The Southern District of California Bankruptcy Court uses a disclosure and certification form for generative AI use in pleadings, motions, and papers.

3. Certify or verify the work

Some courts focus less on whether AI was used and more on whether a human verified the final filing.

The District of Nebraska’s local rule requires a certificate stating either that no generative AI was used or that a human verified all generated text, including citations and legal authority. The District of Kansas reminds lawyers and pro se litigants that AI-assisted filings remain subject to existing duties of candor and accuracy and warns that the court may strike filings, impose sanctions, or require sworn AI-use statements.

This bucket is likely to grow because it fits comfortably with the existing professional-responsibility framework: AI can assist, but it cannot be the final authority.

4. Treat AI output as an unverified source

Some orders frame the problem as source reliability. The District of Hawaii’s General Order 23-1 treats AI-generated material as an unverified source and requires a declaration when counsel or a pro se party submits material generated by an unverified source.

That framing is useful. It avoids treating AI as uniquely mysterious and instead places it beside other unverified material: useful as a lead, not good enough as filed authority unless checked.

But Hawaii’s approach also creates a line-drawing problem. The order defines unverified sources to include AI-generated briefs and memoranda, along with online briefs or memoranda drafted by paid writers that are not tailored to a specific case. The risk is that lawyers may now have to decide not only whether they used AI, but whether a particular research output, template, summary, or purchased work product counts as an “unverified source.”

The last paragraph of the order matters because it carves out ordinary legal research. The court says the order does not affect basic research tools such as Westlaw, Lexis, or Bloomberg, and that no declaration is required when the sources can be found on those tools. That is a sensible safe harbor for conventional citation checking, but it also raises practical questions as legal research platforms add generative AI features. If a lawyer uses a research platform’s AI summary, answer, or drafting aid, is the source the underlying case law, the research database, or the AI-generated synthesis?

For lawyers, the safest reading is narrow: a source is not verified merely because it appeared inside a trusted platform. The underlying authority still has to be located, read, and checked. Hawaii’s final paragraph reduces friction for traditional legal research, but it should not be read as a blanket blessing for every AI-assisted feature embedded inside a legal research product.

5. Protect confidential and proprietary information

Other orders focus on confidentiality. Judge Stephen Vaden of the Court of International Trade requires disclosure when a filing contains text drafted with generative AI and a certification that the AI use did not disclose confidential or business proprietary information to an unauthorized party.

This is the piece many lawyers miss. AI orders are not just about fake cases. They are also about what happens when privileged, confidential, sealed, trade secret, business proprietary, health, financial, or export-controlled information is entered into a tool that may store, train on, or transmit user input.

6. Proposed Federal Rule of Evidence 707

The most important federal rulemaking item is not a filing-disclosure rule. It is proposed Federal Rule of Evidence 707, which would address machine-generated evidence. The pending rules materials place proposed new Evidence Rule 707 on the December 1, 2027 track.

That issue is different from AI-assisted drafting. Filing orders ask whether lawyers verified what they submitted. Evidence rules ask whether machine-generated evidence is reliable enough to be admitted.

What lawyers should do now

• Check district-wide local rules and judge-specific standing orders before drafting or filing.
• Do not assume a general Rule 11 review is enough if the judge requires a separate disclosure or certificate.
• Keep enough internal record of AI use to answer a court question without waiving privilege or exposing mental impressions unnecessarily.
• Do not enter confidential, privileged, sealed, business proprietary, trade secret, protected health, financial, or export-controlled information into public AI tools.
• Verify every citation, quotation, factual assertion, record reference, and legal proposition outside the AI tool.

Help us keep the tracker current

Clearon AI is tracking federal and state court AI orders, standing orders, local rules, protective-order language, and sanctions decisions. If you have found a court order on AI that is not reflected here, please send it through the Contact page.

The most helpful submissions include the court, judge, date, docket number or rule number, a link to the order or PDF, and a short note on what the order requires. We will verify submissions against primary court sources before adding them to the tracker.

Primary sources checked

• Northern District of Texas Local Civil Rule 7.2(f)
• District of Kansas Standing Order 26-01
• District of Nebraska Civil Rule 7.1(d) materials
• District of Hawaii General Order 23-1
• Judge Baylson standing order, Eastern District of Pennsylvania
• Southern District of California Bankruptcy Court General Order 210 notice
• Court of International Trade Judge Vaden order
• Judge Boyko standing order, Northern District of Ohio
• Judge Coleman standing requirements, Northern District of Illinois
• Pending Rules and Forms Amendments: proposed Evidence Rule 707

Companies are reporting meaningful efficiency gains from AI, and that kind of advantage is quickly making AI tools essential to staying competitive. In software development, tools like GitHub Copilot can speed routine work, shorten timelines, and help teams do more with less.

But essential does not mean risk-free. From a legal perspective, AI-generated code can create licensing, attribution, and compliance problems if companies are not paying attention. The GitHub Copilot litigation is a useful example because it helps show how those risks can move from the tool provider into the user’s own codebase.

This article explains the risk and offers practical guidance on both the front end and the back end to help companies reduce it.

The Copilot case is a warning sign, not a final doctrinal answer

The district court’s January 22, 2024 order dismissed a number of claims at the pleading stage and narrowed the case substantially, which is an important reminder that the litigation does not establish broad liability simply because the technology is controversial. But the dispute has continued through appeal-related proceedings, including the appellate activity described in this Courthouse News report on the Ninth Circuit argument. For companies watching from the sidelines, that matters. No business needs to wait for a final appellate roadmap before addressing an obvious governance issue.

It would be a mistake to view the Copilot litigation as a problem limited to GitHub, Microsoft, OpenAI, or the named plaintiffs. The more important corporate question is what happens when a developer accepts AI-generated code and merges it into a proprietary codebase. If the generated output is substantially similar to open-source code, the company may inherit a provenance problem. If the code at issue is associated with a copyleft license, the consequences may be more disruptive than a missed notice or attribution defect. The company may face the argument that its own use, distribution, or incorporation of the code triggers obligations it never intended to accept.

What makes copyleft risk different

Many companies already know how to manage conventional open-source software under permissive licenses such as MIT, BSD, or Apache 2.0. Those licenses impose real conditions, but they are usually manageable through familiar inventory, notice, and compliance processes. Copyleft licenses create a different category of concern because they can impose reciprocal obligations that become much more uncomfortable for companies trying to protect proprietary and confidential code. The GNU Project’s explanation of what copyleft means is a useful starting point, even for non-specialists. And courts have long recognized that open-source license conditions can carry real legal force, as the Federal Circuit explained in Jacobsen v. Katzer and as the Northern District of California reinforced in Artifex Software, Inc. v. Hancom, Inc..

From a practical corporate perspective, the fear is easy to understand: a company may face the argument that code it believed it exclusively owned is subject to broader disclosure, source-availability, or licensing obligations.

That is the nightmare scenario.

It is also important not to overstate it. Copyleft consequences are not automatic. Whether any particular use of generated code would trigger meaningful license obligations depends on a fact-intensive analysis and, in a litigated case, on how a court evaluates both the code and the remedy sought. But uncertainty is not a comfort. In many settings, legal ambiguity increases risk because it increases the cost of getting to an answer. Even if a company ultimately prevails, a dispute over provenance, licensing, and code inheritance can produce delay, remediation expense, customer friction, diligence problems in M&A or financing, and significant litigation leverage.

This is not just a lawyer problem

AI-generated code often arrives in a form that feels operationally harmless: a helpful function, a well-structured block, a clean suggestion that appears to solve the task at hand. That experience makes it easy to treat the output as legally equivalent to code written from scratch. But provenance is often opaque, and that opacity is the problem. One recurring legal theory in the Copilot case has involved alleged failures to preserve copyright-related information, an issue tied to 17 U.S.C. § 1202.

A developer may not know whether a snippet is generic, independently generated, loosely informed by training data, or very close to code published in a repository under specific licensing terms. Once that code is accepted, revised, and blended into a broader codebase, tracing the issue later becomes much more expensive.

So the legal risk begins as a workflow issue. It starts with one prompt, one suggestion, and one merge. It becomes a company problem later, when the code is shipped, reviewed in diligence, examined in discovery, or challenged in a dispute. By then, the cheap fix may be gone.

The harshest risk should be described carefully — but not ignored

The worst-case scenario is easy to understand: a claimant argues that the company’s use of AI-generated code has triggered copyleft obligations requiring disclosure or broader licensing of code the company considers confidential and proprietary. That result is not automatic, and it would be careless to say otherwise. Whether such a remedy is plausible in any given case depends on the license, the facts, the nature of the alleged copying, the role of the generated code in the larger work, whether distribution occurred, and the court’s view of appropriate relief. The GNU Project’s GPL FAQ gives a sense of why these questions quickly become complex, even before a court gets involved.

But companies should not take comfort from the fact that a remedy would be contested. The wiser position is not to become the test case.

What companies should do now

The answer is not to ban AI coding tools. The answer is to govern them like they matter.

That starts with front-end controls:

• decide which AI coding tools are approved
• define where they can and cannot be used
• restrict use in especially sensitive or high-value proprietary repositories
• train developers not to accept generated code reflexively
• treat prompts and outputs as compliance-relevant, not just productivity artifacts

It also requires back-end controls:

• human code review with a provenance lens
• open-source scanning and similarity review where appropriate
• escalation paths for suspicious snippets
• documentation of AI-generated code use in development workflows
• rewrite questionable code early instead of litigating over it later

Governance frameworks can help here. The NIST AI Risk Management Framework is not specific to software licensing, but it provides a useful model for building governance-based controls around AI adoption. Tool selection matters as well. Enterprise-grade offerings with stronger logging, administrative controls, and contractual commitments are often easier to defend than ad hoc usage with little visibility. And for organizations that want a more structured compliance program around open-source use generally, the Linux Foundation’s open-source guidance resources are a practical place to start.

Front-end controls, however, are not enough. Companies should assume that some risky code may still get through and build back-end review mechanisms designed to catch it before release. That means human review with a provenance lens. Code review should not stop at whether the code compiles, performs, or passes security checks. Where AI coding tools are in use, reviewers should also be alert to suspiciously polished, oddly specific, or poorly explained generated code, especially in contexts where open-source inheritance would create real business pain.

Technical controls can reinforce that process. Open-source scanning tools, similarity review, provenance checks, and escalation procedures can help surface issues while they are still cheap to solve. If a snippet raises concern, rewriting it may be far less expensive than litigating later about whether the original output carried hidden obligations. Documentation also matters. If AI-generated code is used in development, the company should have some way to record where, when, and under what conditions. Those records can help with internal compliance, incident response, diligence, and eventual litigation posture.

This is not bureaucracy for its own sake. It is part of building a defensible process.

How precautions may matter in court

Reasonable precautions do more than reduce the underlying compliance risk. They also affect how a company looks if a dispute arises. Courts pay attention to conduct. A company that rolled out AI coding tools with no restrictions, no training, no review, and no audit trail presents a very different picture from a company that adopted policies, trained developers, implemented controls, and addressed concerns when they surfaced. That difference may not eliminate liability. But it can matter when a court evaluates intent, proportionality, equitable relief, and remedy. The Supreme Court’s decisions in eBay Inc. v. MercExchange, L.L.C. and Winter v. Natural Resources Defense Council, Inc. are reminders that severe equitable relief is not automatic and depends on traditional equitable principles.

That point is especially important where the feared remedy is severe. A company that can show genuine preventive and detective efforts is better positioned to argue that any relief should be tailored rather than effectively punitive. Put more plainly, a court may be less inclined to force the harshest result where the defendant can show it tried to prevent the problem on the front end and catch it on the back end.

Bottom line

The lesson from the Copilot litigation is not that companies must abandon AI coding tools. It is that they should stop treating those tools as legally neutral. Where generated code may carry hidden open-source obligations, especially copyleft risk, the cost of inattention can be far greater than a routine compliance problem. Companies that adopt sensible controls on the front end and disciplined review on the back end will be better positioned to reduce both the underlying risk and the chance that a court views severe remedies as justified.