AI-Generated Code Just Made Your Copyright Warranties Unsignable, and the Contracts Haven't Noticed
The Developer Certificate of Origin, Apache's contributor agreement and every IP warranty above them assume the authorship of code is knowable and provable. AI-generated code has falsified that assumption, and open source's split over it is only the visible symptom.
Every patch accepted into the Linux kernel, and into thousands of projects that copied its process, carries a Signed-off-by line. That line certifies the first clause of the Developer Certificate of Origin: 'The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file.' Apache's individual contributor licence agreement makes the same promise in different words: 'You represent that each of Your Contributions is Your original creation.' Those sentences were drafted when the only candidate authors were people, and every document above them in the commercial stack (procurement questionnaires, customer IP warranties, the disclosure schedules in an acquisition) inherits their central assumption: that the copyright status of code is something its author can know and its owner can prove. AI-generated code has quietly falsified that assumption. The clauses are still being signed every day. Read literally, many of them can no longer be signed truthfully by anyone.
Why can't anyone verify the copyright of AI-generated code?
Follow the mechanism. The systems that generate code were trained on public repositories under every licence and copyright state imaginable, and nothing in their output records what any given suggestion derives from; there is no ledger to consult. The developer who accepted the suggestion can't prove the licence of what arrived, and neither can the vendor of the tool that produced it. This is not a verification problem that better tooling solves next year: the information was never captured, so it cannot be retrieved. Every clause built on provable authorship, from a contributor sign-off to the IP warranty in a share purchase agreement, now rests on a fact that is no longer knowable.
The commercial consequences arrive long before any courtroom does. Due-diligence questionnaires in procurement and acquisitions now ask directly about code provenance. Customers in regulated sectors want representations that shipped code is free of licence contamination. Warranty and indemnity terms are priced on what can be evidenced. In each case the paperwork was drafted for a world where a competent audit could, at least in principle, trace every line to an author and a licence. You can still commission the audit, but it can no longer answer the question.
Open source has already split over the proof gap
The clearest evidence of how seriously engineers take this sits in open-source governance. Gentoo's council banned AI-generated contributions in 2024, citing copyright among its reasons. NetBSD's commit guidelines presume AI-generated code to be tainted and bar it without core-team approval. QEMU declines it for precisely the reason this article opened with: contributors cannot honestly certify its origin under the sign-off every patch requires. Notice the shape any softer policy has to take. A rule admitting AI-generated code only where the contributor can verify its copyright status sounds like a compromise, but since the verification does not exist it is a full ban dressed as a permission slip. These are community-governed projects whose one irreplaceable asset is a defensible chain of title, and they will forgo contributions to keep it.
The other half of the ecosystem is sprinting the opposite way, with payroll behind it. On Alphabet's third-quarter 2024 earnings call, Sundar Pichai told analysts that 'more than a quarter of all new code at Google is generated by AI, then reviewed and accepted by engineers', a remark widely reported at the time, and the Linux Foundation's largest corporate backers sell the tools driving numbers like that. Neither camp, though, can demonstrate what its code actually contains. No detector of machine-written code has demonstrated reliability at the accuracy a licence audit would require, so enforcement runs on self-declaration; the Linux kernel has leaned towards disclosure rather than prohibition, but a disclosure rule measures only the contributors who choose to comply. Whatever the true share of AI-assisted patches, an honour system can report a floor, never a measurement. Provenance problems are also transitive: a strict project still imports dependencies maintained under permissive policies, and commercially employed contributors maintain great tracts of the plumbing every distribution ships. A project's AI policy tells you its risk appetite. It tells you almost nothing about its repository.
An SBOM can't answer the question your warranty asks
The reflex response is to point at the software bill of materials. It won't help, and the standards say as much in their structure. The fields defined by SPDX and CycloneDX describe components: names, versions, suppliers, declared licences, dependency relationships. Nowhere in either format is there a field asserting how the code inside a component came to exist, or whether a person wrote it. SPDX 3.0 did add an AI profile, but it exists to describe AI systems shipped as deliverables, not to record the authorship of ordinary source code. An SBOM inventories what you run; it was never designed to prove where any of it came from. Letting it stand in for a provenance guarantee is a category error, and due-diligence reviewers are starting to notice.
Is AI-generated code a copyright risk for your business?
The law is unsettled, and waiting for it to settle is not a strategy, because the exposure is contractual and reputational long before it is legal. The useful response is to move licence hygiene from a one-time checkbox to a standing, per-dependency judgement. Know the AI policies of the upstreams you actually rely on, and treat 'silent' as its own risk category. Get warranty and indemnity language reviewed against what is now provable rather than what used to be assumed; an unqualified 'original creation' representation is a promise your engineers cannot keep on your behalf. Make the risk-appetite decision deliberately, at the level where architecture is decided: this is exactly the exposure a serious technical strategy review should surface by default, and it belongs in the same conversation as AI readiness before you build. If your own teams generate code with AI, the same discipline applies internally, which is one more argument for keeping humans in control of AI output rather than treating the tool as an author.
Every one of those project policies is really a choice of risk appetite, and your business faces the same ballot one dependency, and one signature, at a time. The organisations that come through this well won't be the ones that picked the 'clean' camp. They'll be the ones that noticed there was no way to check, and priced it in.
Questions people ask
Can software detect whether code was written by AI?
Not reliably. No detector of machine-generated code has demonstrated the accuracy a licence audit would require; classifiers misfire in both directions and trivial edits defeat them. That is why open-source projects rely on contributor self-declaration rather than scanning, and why any stated AI percentage should be treated as a minimum, not a measurement.
Can developers still sign the Developer Certificate of Origin if they use AI coding tools?
It depends on the project. QEMU's guidelines conclude that contributors cannot honestly certify the origin of AI-generated code and decline such patches, while the Linux kernel has favoured labelled disclosure. Check each project's policy before contributing, because a sign-off is a legal statement about provenance, not a formality.
What should we ask vendors about AI code provenance?
Ask for their policy on AI-assisted development, how AI contributions are labelled and reviewed, whether their IP warranties reflect what is actually provable rather than assumed, and who carries the indemnity if the provenance of shipped code is ever challenged.
Related
- Epic v Google: The App Catalogue Remedy That Hands Rivals the Moat
- Memory Prices Turned. Renegotiate the Supply Contract Before the Next Refresh.
- How AI Makes Bad Bosses Worse: The Agreeability Machine in the Corner Office
- Digital Business
Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.