The September 16 ruling in Doe v. GitHub narrowed a specific claim about AI-generated code. The Ninth Circuit affirmed dismissal of the programmers' claim under the Digital Millennium Copyright Act's copyright-management-information provisions. The decision concerns an attribution theory; it does not resolve every question about training data, generated output, or open-source licenses.
What the court decided
The programmers alleged that Copilot and Codex could reproduce their code without its attribution and license information. The court reasoned that the alleged outputs were newly generated works that had never contained that information, rather than existing copies from which it had been removed or altered.
The panel declined to consider the separate training-input theory because the plaintiffs had forfeited it. The opinion also states that two contract claims remained pending. It distinguished the DMCA question from ordinary copyright infringement and did not decide whether similarities in generated code could support an infringement claim.
That leaves a narrower result than a headline about AI training might suggest. A dismissal under one provision should not become a promise that every generated code fragment is cleared for commercial use.
What a release review should check
For a small software company, the useful response is a repeatable review process for code entering the product. This is an engineering recommendation, separate from the court's holding.
- Trace unusual code: when a suggestion contains a substantial implementation, distinctive comments, or an unfamiliar algorithm, investigate its origin before merging it.
- Review dependencies: record the packages introduced, their versions, their licenses, and any notices that need to accompany distribution.
- Keep the evidence: link the generated change to its pull request, tests, reviewer, and any source or license investigation.
- Escalate uncertainty: give the reviewer a way to pause a change and seek a qualified license review when its provenance is unresolved.
These steps provide a record of what the company inspected. They also make later maintenance easier: an engineer can see why a library was selected, where a notice came from, and who approved the change.
A concrete example for a product team
Suppose an assistant proposes a PDF-import feature and adds a parsing library. The code compiles and the happy-path tests pass. That establishes some functional behavior, but the release review still needs to inspect the library's license, the intended distribution method, and required notices.
The pull request can include a short dependency record: package and version, source location, license identifier, intended use, notice location, and reviewer. If the assistant also produced a long custom parser, the reviewer can examine distinctive sections for matches and document the result. A failed search is not proof of independent origin; it is one part of the review.
This is also a better basis for customer communication. A company can describe an established dependency-review process and its scope when it actually follows one. Broad statements that AI-generated software is automatically free of intellectual-property concerns are harder to substantiate and can become customer commitments the team has never tested.
Source context
The factual account above comes from the published September 16 opinion, No. 24-7700. Reuters reported the decision the same day. The release checklist and PDF-import example are AyNcode's proposed engineering practice, not findings made by the court.
Image: James R. Browning Courthouse, Courtroom 1, Sam Wheeler, CC BY-SA 3.0. The photograph shows the courthouse interior, not proceedings in this case.