Memorised copyleft code in open-weight models and the obligations European Union law leaves undefined

Copyleft licences depend on provenance. A distributor passing on software can ordinarily identify the work being distributed, the licence governing it, the copyright notices that must accompany it and the corresponding source that must be made available. Those four elements make copyleft obligations performable. Model weights may be the first software artefact capable of preserving the protected expression while severing the provenance on which those obligations depend.

This article examines the consequences if memorised copyleft code is capable of subsisting in model weights as a reproduction. Two recent judgments of the Regional Court of Munich I placed that premise squarely before European copyright law. In GEMA v. OpenAI (LG München I, 42 O 14139/24, 11 November 2025) and GEMA v. Suno (LG München I, 42 O 763/25, 31 July 2026), the court held that protected expression memorised in a generative model may itself constitute a reproduction. Neither judgment is final. The copyright reasoning underpinning those decisions, and the proposition that protected expression may subsist as a reproduction in model weights, is examined in detail in my earlier article, “Is the model the infringement? Memorisation, reproduction and the weights of AI models under European Union law”. This article assumes that premise and asks a different question: what follows if the reproduced work is software distributed under a copyleft licence?

The question that this article examines is whether copyleft can still identify the obligations attached to that copy. Code-generating models are trained on public repositories containing substantial quantities of software released under the GNU General Public Licence (GPL) and the GNU Affero General Public Licence (AGPL). If protected GPL code is reproduced within the weights, a company downloading or serving those weights may possess and distribute an artefact containing copyleft-licensed expression while being unable to identify which covered work has been reproduced, which licence governs it, whose notices must accompany it or what constitutes the corresponding source. The legal difficulty is therefore not that the GPL demands too much. It is that the provenance needed to determine what the GPL demands may no longer be recoverable.

The distinction reflects a deeper difference between copyright and copyleft. Copyright can recognise reproduction through what this article calls functional identifiability: it is enough that protected expression can be extracted from the artefact, without locating where that expression is represented internally. Copyleft compliance depends instead on provenance identifiability: the ability to connect that expression back to the work from which it came and to the obligations attached to that work. Model weights may satisfy the first requirement while defeating the second.

The consequence is practical rather than theoretical. Companies deploying open-weight code models may assume a copyright and licensing exposure that ordinary open-source compliance processes were never designed to govern, not because the obligations disappear, but because the information needed to identify them may disappear first.

The analysis proceeds in five stages. Section I asks whether the GPL can attach to model weights at all and why, if it does, its conditions lose their practical referents. Section II examines how much memorised code is likely to remain protected after both technical and legal filtering. Section III identifies which companies carry the resulting exposure depending on whether they possess, modify or merely access the model. Section IV turns from doctrine to governance and considers the practical measures available to reduce that exposure. Section V returns to the broader implication: whether existing copyleft licences are capable of governing model weights at all, or whether that question ultimately belongs to licence design rather than copyright doctrine. Practitioners interested primarily in implementation guidance may wish to begin with Section IV before returning to the legal analysis that precedes it.

I. How GPL obligations could attach to model weights, and why provenance becomes untraceable

Assume Munich is right, and protected expression memorised in a model’s parameters is a reproduction within the meaning of Article 2 of Directive 2001/29/EC (the Information Society Directive, ‘InfoSoc’), transposed into German law by Section 16 of the German Copyright Act (Urheberrechtsgesetz, ‘UrhG’). A memorised fragment of a GPL-licensed program then sits in the weights the way a memorised melody does. The premise is contested, and the contest is factual: in Getty Images v. Stability AI ([2025] EWHC 2863 (Ch)) the High Court of England and Wales found on the evidence before it that Stability AI’s weights did not contain copies of the particular Getty works, while laying down no rule that weights can never be copies.

A reproduction is not yet an attachment. Copyright answers one question, which is whether a copy exists. Liability under the GPL requires a second, and the two are habitually run together. The GPL is an exercise of the rights copyright confers rather than a rule of copyright itself: it grants a permission that copyright would otherwise withhold, and subjects the grant to conditions. The first requirement is conveying. The licence defines it as any propagation that enables another party to make or receive copies. The second is that the thing conveyed must itself be the covered work or a modified version of it. Munich decides whether a copy exists. It says nothing about whether the weights are a form of the covered work.

The distinction matters because the argument that follows is not automatic. A court could accept every word of the Munich reasoning, hold that the weights reproduce GPL-licensed expression, and still conclude that the licence’s own vocabulary does not reach them: that a field of parameters is no covered work, no object code and no modified version, and that handing it over conveys nothing within the meaning of the licence. Nothing in European copyright law settles that, because it is a question about the text of a private instrument.

The third version of the licence supplies a textual argument for attachment, but only if the prior premise is satisfied: that the weights are a form of the covered work. GPLv3 defines the source code of a work as the form preferred for making modifications to it, and object code as any non-source form of a work. The taxonomy is binary: a thing either is the preferred form for modification or it is not. Weights are plainly not the preferred form for modifying a memorised function, since a developer wanting to change that function would not begin from a set of parameters. So if the reproduction in the weights is regarded as a form of the covered work at all, GPLv3’s own taxonomy supplies a strong textual argument for treating that form as object code. The prior premise therefore remains unresolved. But if the weights are accepted as a form of the covered work, the licence’s own taxonomy strongly supports treating them as object code.

Cross that bridge and the ordinary conditions of the licence apply. Where a covered work is conveyed in object form, GPLv3 requires, among other things, that the licence text reach the recipient, that the copyright and licence notices be preserved, and that the Corresponding Source accompany the object or be made available with it. GPLv3 defines that source expansively, as all the source code needed to generate, install and run the object code and to modify the work, together with the scripts controlling those activities, excluding only System Libraries and general-purpose tools. None of this is exotic. It is the machinery every distributor of copyleft software already operates, and it works because the distributor knows what it is handing over.

That knowledge is what the weights withhold. What the artefact fails to expose is an addressable mapping from the expression it reproduces back to the four things the licence needs identified: the covered work the expression came from, the licence governing that work, the authors whose notices attach to it, and the source that corresponds to it. Some of that provenance may survive outside the model, in a published corpus, a repository manifest or a developer’s internal training records. None of it answers the question the licence asks, because complete training records establish what went into a model and not which of those works were memorised, still less which memorised expression corresponds to which source.

Here copyright and copyleft come apart, and the difference is one of granularity. Munich is satisfied by what may be called functional identifiability: the reproduction is established by what the artefact yields, without anyone locating the expression among individual parameters. Copyleft compliance requires provenance identifiability, which is the ability to connect that expression back to a particular covered work and to the licence, notices and source that work carries, because copyleft obligations attach to the work rather than to the artefact in which it is embodied. The two bodies of law therefore demand different forms of identification, and a model may satisfy the first while defeating the second.

The questions a distributor would have to answer are that missing mapping seen from four sides. 

• Which covered work does the memorised expression belong to? Nothing in the parameters names it, and the works cannot be listed because they cannot be read out by inspection. 
• Which licence governs it? A single model may carry fragments under GPLv2, GPLv3, the Lesser General Public Licence (LGPL) and the AGPL, terms that are not mutually compatible. 
• Whose notices must be preserved? The expression may come from any of thousands of repositories and hundreds of thousands of contributors, none of them recorded in the artefact.
• What is the Corresponding Source? The weights were never compiled from the function, and the function cannot be regenerated from them in the form preferred for modification.

None of this makes the obligation impossible in principle. The covered work exists. The governing licence exists. The copyright notices exist. The Corresponding Source exists, somewhere in the repositories from which the model was trained. What is missing is not those objects themselves, but the ability to connect any of them to the particular expression embodied in the weights. The obligation therefore has an object in principle and no ascertainable object in practice. The obstacle is one of identification rather than performance.

Everything above assumes that the licence conditions arise through conveyance. Much commercial deployment of open-weight models, however, involves no conveyance at all. A company that modifies GPL software and runs it only as a network service distributes no copies, and that is precisely the gap the AGPL was written to close. Section 13 applies where a modified version is made available for remote interaction over a network and requires the operator to offer the Corresponding Source to its users. The same attachment question therefore arises by a different route. If the proposition developed above is correct, and a model carrying memorised AGPL code constitutes a modified version of the covered work, the obligation to provide the Corresponding Source may arise through network use alone, without any copy changing hands. Both predicates remain unsettled. If they are satisfied, the obligation is no more identifiable than the corresponding-source obligation arising on distribution.

---

II. How much memorised code is actually protected by copyright?

Most of what a code model retains is not protected expression, and the accurate measure of the exposure is smaller than the alarming account and more interesting than the dismissive one.

The most useful controlled evaluation is LiCoEval (Weiwei Xu, Kai Gao, Hao He and Minghui Zhou, “LiCoEval: Evaluating LLMs on License Compliance in Code Generation”, ICSE 2025, arXiv:2408.02487). Its authors built a standard of striking similarity designed to rule out independent creation, evaluated fourteen models in current use for code generation, and found that even the better performers produced output meeting that standard in between 0.88% to 2.01% of the generations tested.

That figure records the result of a particular benchmark under a particular prompting method. It is not an estimate that between one and two percent of all code written in ordinary commercial work reproduces open-source software. Read for what it measures, it establishes that close reproduction is uncommon rather than absent.

A more recent study complicates the finding. In “Detecting Functional Memorization in Code Language Models” (Matthieu Meeus and others, arXiv:2606.12764, 11 June 2026), researchers at Meta and Imperial College London built a counterfactual comparison. They tested a model exposed to a body of target code against a reference model of identical architecture and pretraining that had never seen it, so as to separate genuine memorisation from convergence on the obvious solution.

Measured against strict textual identity across 7,422 Python functions, the counterfactual figures were very small: 8 functions, or 0.11%, were reproduced verbatim by the exposed model where the reference model was not, and 43 functions, or 0.58%, were reproduced near-verbatim on the same basis. The picture changed once the authors evaluated functional rather than textual similarity, reaching 1.8% under the data-flow component of one structural metric, 2.1% under another, 3.9% under the authors’ own and most conservative evaluation of functional equivalence, and 14.0% under a more permissive evaluator, with 20.0% of functions flagged by at least one metric. Under the most stringent test employed in the study, execution-based verification, 0.28% of generations were confirmed as functional clones of a training function. The authors present that figure as a lower bound because most candidate pairs could not be executed.

The study therefore does not merely report larger numbers under different metrics. It argues that textual and functional similarity capture different forms of memorisation, so that an assessment confined to textual overlap may systematically underestimate the amount of training logic reproduced by a code model.

European law narrows the protected population further. Under Directive 2009/24/EC (the Software Directive), as interpreted by the Court of Justice in SAS Institute v. World Programming (Case C-406/10, EU:C:2012:259), copyright in computer programs extends only to the expression of the program rather than to its functionality, programming language or data file formats. Infopaq International v. Danske Dagblades Forening (Case C-5/08, EU:C:2009:465) further confines that protection to expression that is the author’s own intellectual creation. Routine coding conventions, standard implementations and customary ways of expressing a solution therefore fall outside copyright even before any question of memorisation arises.

On that legal narrowing the technical literature lays a mechanical one. The foundational study of the subject establishes that memorisation is driven strongly by duplication, so that the more often a fragment recurs across the training data the more reliably it is retained, and that removing duplicates is the single most effective way to suppress it (Zhou Yang and others, “Unveiling Memorization in Code Models”, ICSE 2024, arXiv:2308.09932).

One further inference follows, although it remains an inference rather than an empirical finding established by the literature. Material that is duplicated many times across repositories is often the very material that software development standardises: licence headers, boilerplate, helper routines and shared scaffolding. That overlap suggests that the code most readily memorised may also be among the least likely to satisfy the originality threshold. The inference has limits. Duplication is not the opposite of originality, and an original function may itself be copied thousands of times because it is useful.

After both the legal and the technical narrowing, the protected residue appears relatively small. United States law reaches a comparable result by a different analytical route. The abstraction-filtration-comparison test developed in Computer Associates International v. Altai (982 F.2d 693, 2d Cir. 1992), removes unprotectable elements before comparing the remaining expression, reflecting the same practical reality that much of any computer program consists of material copyright does not protect.

Two qualifications remain important. 

First, the reported figures are better understood as floors than ceilings. Each reflects only what a particular extraction methodology succeeded in identifying, and more capable techniques may identify additional instances. Narrow therefore means difficult to detect rather than demonstrably absent. 

Secondly, copyleft obligations do not vary with the volume of protected material reproduced. A single protected function capable of attracting the licence conditions presents the same legal question as thousands. The exposure that survives the legal and technical narrowing is therefore likely to be limited in scope, but it cannot be dismissed as immaterial, and if the analysis in the previous section is correct, it remains an exposure a distributor cannot map to the works from which it originates.

---

III. Which companies carry the copyright exposure from open-weight AI models?

The exposure follows the artefact. The more control a company exercises over the model weights, the more of that exposure it carries. Three situations therefore need to be distinguished. The first is the company that downloads and runs an open-weight model without changing it. The second is the company that modifies the weights through continued training or fine-tuning. The third is the company that never possesses the weights at all, but accesses the model through an inference service. The legal position differs because the relationship each company has with the artefact differs.

A. Downloading and self-hosting an open-weight model

The first company does not create the reproduction identified in the Munich judgments. That act belongs to the developer who trained the model and first embodied the memorised expression in its parameters. But neither does the company remain outside the reproduction right. Downloading the model onto its own infrastructure reproduces the weights, and if those weights themselves contain a reproduction of protected expression, the company reproduces that expression as well. The copyright analysis therefore follows the copy rather than the authorship of the training process.

That conclusion is uncomfortable precisely because it separates responsibility for training from responsibility for possession. The Suno judgment located the relevant reproduction in Germany because the models were stored on German servers. If that reasoning survives appeal, the same logic applies to any company that stores the weights on its own servers within the EU. The company has not trained the model, but it nevertheless possesses and reproduces the artefact in which the protected expression is said to subsist.

The United States Copyright Office reaches a similar point from a different direction. In Copyright and Artificial Intelligence, Part 3: Generative AI Training (pre-publication version, May 2025) it concludes that, where protected expression remains embodied in model weights, subsequent distribution or use of those weights may in principle expose parties who took no part in the original training. The district court in Andersen v. Stability AI (No. 3:23-cv-00201-WHO, N.D. Cal.), likewise permitted claims to proceed on the basis that protected material allegedly persisted within the weights themselves. Neither authority decides the European question, but both illustrate the same proposition: once the model itself is treated as the relevant artefact, the legal analysis no longer ends with the original developer.

The company also faces the familiar and independent exposure at the level of output. If code generated by the model reproduces protected GPL expression and is incorporated into a commercial product, the ordinary copyleft obligations attach to that distribution exactly as they always have. The model-level exposure therefore supplements the traditional output-level analysis rather than replacing it. The company may simultaneously hold a reproduction in the weights and distribute another through the code it ships.

B. Fine-tuning or otherwise modifying the model weights

The second company goes further. It does not merely possess the artefact but changes it.

That distinction matters because fine-tuning does not replace the original weights with a new copyright history. It produces a derived model whose parameters continue from the existing ones, and whether particular memorised expression survives in those derived weights is a factual question about the resulting model rather than a legal consequence of the act of modification itself. Nothing in copyright law suggests that further training cleanses a reproduction simply because additional parameters have been adjusted.

The technical literature points in the same direction. Continued training may dilute particular memorised material, and sufficiently extensive retraining may overwrite some of it altogether. Equally, lighter forms of fine-tuning appear to leave much of the original memorisation intact, while some apparently forgotten material may later become extractable again. The extent to which any particular reproduction survives is therefore an empirical question capable of being investigated by extraction. European copyright supplies no threshold at which a sufficiently modified model ceases, as a matter of law, to contain whatever protected expression remains embodied within it.

The practical consequence is that the company has now created its own model while remaining unable to determine how much of the original memorisation continues to exist inside it. Greater control over the artefact therefore brings greater uncertainty rather than less. The company is no longer only reproducing another developer’s weights. It is distributing and operating a derived set of weights whose copyright history it cannot fully reconstruct.

The regulatory position under Regulation (EU) 2024/1689 (the “AI Act”), should be kept separate from that copyright analysis. A downstream modifier may become the provider of the modified model where the modification is sufficiently significant, but the Commission’s guidance makes clear that ordinary enterprise fine-tuning will usually fall well below that threshold. Provider status therefore remains an exceptional regulatory consequence rather than the ordinary legal effect of modifying an open-weight model. Whether the company becomes a provider under the AI Act says little about whether protected expression continues to subsist within the derived weights.

C. Using an inference service without possessing the weights

The third company never receives the artefact at all. It accesses a model through an inference service, whether that service exposes a proprietary model or an open-weight model operated by someone else.

That distinction substantially changes the analysis developed in this article. If the company never downloads or stores the weights, it never reproduces the artefact in which the memorised expression is said to reside. Whatever model-level exposure exists therefore remains with the party operating the inference service rather than passing to the customer. The customer’s legal position begins, and ordinarily ends, with the generated output.

This explains why the practical consequences of the Munich reasoning differ so markedly between open-weight deployment and inference services. Two companies may rely on exactly the same underlying model while carrying different legal exposures solely because one possesses the weights and the other never does. The former reproduces and controls the artefact to which the analysis in this article attaches. The latter receives only its outputs.

The distinction should not be overstated. Output-level exposure remains exactly the same. A company that incorporates protected GPL code into its own software cannot avoid the consequences merely because the code arrived through an API rather than a locally hosted model. What changes is only the model-level analysis developed in this article. The exposure attached to the weights follows the party that possesses and controls those weights.

---

IV. How companies can reduce copyright and copyleft risk when using open-weight AI models

The previous sections identify a legal exposure. This section asks a different question: what a company can do about it. None of the measures below removes the reproduction that, on the analysis in this article, already exists in the weights. They reduce its practical consequences instead, by governing the points where a company can still intervene: possession of the weights, the choice and provenance of the model, the treatment of generated output, and the contractual allocation of whatever risk remains. The objective is to manage the exposure before it reaches production.

The measures follow the order in which a company meets the risk. The first is architectural, and asks whether the company needs to possess the weights at all. The second concerns the model, and asks what can be established about an artefact the company has decided to hold. The third concerns the development process, and governs generated code before it enters a product. The fourth concerns the exposure that survives those controls, and asks how far it can be shifted by contract.

 A. Treating possession of the weights as a variable

Section III attaches the model-level exposure to possession and control of the weights. The first governance measure follows directly. A company that uses a model without receiving or storing its weights never makes the additional copy of the artefact in which the memorised expression is said to subsist. Its exposure stays at the level of generated output. Where business requirements allow inference in place of self-hosting, the deployment architecture is therefore itself a governance decision, and it is the earliest point at which the model-level exposure can be reduced.

There are indeed more options than the familiar opposition between self-hosting and a public API. Between downloading the weights onto the company’s own infrastructure and sending requests to a public endpoint lies a range of managed arrangements. 

A model may be served through a private endpoint (a connection open only to the customer rather than to the public internet), or run inside a logically isolated environment (a partitioned area of shared cloud infrastructure, walled off so that one customer’s workload cannot reach another’s), or operated under other arrangements built to meet enterprise needs for confidentiality, network isolation and data residency. The question that matters here is a narrow one: under the particular architecture, who actually receives, stores and controls the weights. Isolating the network and possessing the model are two different things, and each has to be checked on its own.

That distinction gives a company room to meet requirements that look at first as though they demand self-hosting, while the weights stay with the provider. Confidential source code may call for private connectivity and limits on how the provider uses or retains prompts. Personal or regulated data may require processing in a named location. Security policy may require isolation from public networks. Latency may favour running the model close to the company’s systems. Some managed arrangements can satisfy combinations of these while the provider continues to hold and control the model itself.

The due diligence question should be put precisely. A company should establish whether the proposed architecture requires it to receive or store the weights, or whether its requirements can instead be met by controlling the environment in which inference happens, while possession of the model stays elsewhere. That question has to be answered against the actual technical and contractual arrangement proposed by the vendor as to establish with certainty where the weights are located. This is why the label matters less than the arrangement beneath it. 

• If the weights stay with the provider, so does the model-level reproduction analysed in this article, and the company has genuinely avoided it. 
• If the arrangement puts a copy of the weights onto infrastructure the customer controls, the company is holding the weights after all, and the exposure comes with them, whatever the service is called. Managed inference reduces the exposure only when it actually keeps the weights out of the customer’s hands.

 None of this touches output-level exposure. If the company ships software containing protected GPL code, it carries the ordinary consequences of copyright and copyleft law, whether that code came from a locally hosted model, a private inference service or a public API. Keeping the weights with the provider removes the model-level exposure and only that. It is the first measure a company can take, not the last, which is why the sections that follow address the code the model produces.

B. Assessment of the model

Where a company decides it must hold the weights, the next opportunity to reduce exposure lies in which model it chooses. The provenance of the training corpus sets how far the exposure can be assessed before the artefact ever reaches the company’s systems.

The clearest illustration remains the original StarCoder project, developed by Hugging Face and ServiceNow. The model was trained on a documented subset of The Stack made up of permissively licensed repositories, and it was released with the preprocessed corpus published, a repository opt-out mechanism, and tooling that could trace generated code back to its sources. The way the corpus changed over time is just as instructive. Material under the Mozilla Public Licence, the Eclipse Public Licence and the LGPL was removed from later versions, a documented case of a provider making deliberate licensing choices about its training data.

Those choices map onto the mechanisms set out earlier in this article. Deduplication reduces memorisation, because duplicated material is retained more readily than unique material. A published account of the corpus lets an adopter assess an exposure that would otherwise stay opaque. Deliberate licence filtering shrinks the population of works that can give rise to the copyleft problem considered here.

Model selection therefore becomes a matter of legal due diligence, alongside benchmark performance, security and operational fit. The diligence comes down to a short set of questions about the training corpus:

• Was the corpus deduplicated, and is the method documented?
• Which copyleft licences were included, excluded or filtered?
• Has the provider published the training data, or an account of it detailed enough to permit a meaningful licence assessment?
• Does the provider document the provenance and licensing applied to any later training, continued pretraining or fine-tuning of the released model?

The answers sort models into two groups: those a company can assess and those it cannot. A provider that documents its deduplication, states which licences it filtered and gives a real account of the corpus hands the adopter what it needs to assess the risk and to show its work. A provider that supplies little leaves the company unable to tell a low exposure from a high one, and an exposure that cannot be assessed has to be rated as if it were real. Openness of the weights does little here. What counts is transparency about where the training data came from, and that is worth more than access to the parameters themselves.

C. Governance of generated code before production

Once a model is deployed, whether as received or after fine-tuning, the practical opportunities to reduce risk move to its output. These controls address a different exposure from the measures above. They do not remove protected expression that may sit in the weights. They aim to stop protected expression generated from those weights from entering software the company then distributes.

The most developed controls work at snippet level. Software composition analysis has moved beyond checking declared dependencies, and can now fingerprint individual snippets of source code against large collections of open-source repositories. Where generated code reproduces a GPL-licensed function, or a substantial part of one, snippet-level analysis can surface the matching source and the licence attached to it. Tools such as SCANOSS and FOSSA illustrate the approach, combining snippet-level matching with established licence-compliance workflows. SCANOSS also supports Software Bills of Materials (a formal inventory of the components inside a piece of software) in the SPDX and CycloneDX formats, and snippet analysis built to catch similarities beyond exact file-level copies.

Detection reduces exposure when it is part of the release control rather than an optional developer tool. For code produced with generative AI, that control belongs in the same workflow through which code enters the production codebase. A proposed change can be scanned before it is merged, with defined categories of copyleft match triggering a required review. Repository controls can then hold the change out of the codebase until that review is done.

The response to a match calls for judgment, not automatic rejection every time. The scan can identify the licence attached to it. A reviewer can then weigh whether the snippet contains protected expression, whether the match is to standard or otherwise unprotectable code, whether the snippet should be removed or independently rewritten, and whether the licence conditions can be met if the company keeps it. 

That workflow turns output scanning from a detection product into a compliance control: 

generated or AI-assisted change → snippet scan → identified match → review → remediation or licence compliance → approved merge

The record matters alongside the technical result. It establishes what the company tested, what the test identified and how the finding was resolved. Where questions of knowledge, fault or damages later arise, a repeatable control supported by retained evidence places the company in a materially different position from one that allowed generated code into production without review.

Companies using generated code at scale should consequently preserve durable provenance information about AI-assisted changes. This does not require physically separating generated code from the rest of the repository, which becomes impractical once developers edit, refactor and combine it with other code. The workable objective is to keep enough metadata to identify the affected commits, pull requests or changes later. 

Keeping that information makes later re-scanning possible. A company can re-examine the identifiable body of AI-assisted code when fragment databases grow, detection methods improve, or a newly discovered source gives a reason for targeted review. The latent character of the exposure makes this worth doing: a negative result today can stay part of the record, while better detection tomorrow can be applied to the same identifiable body of code.

Output filtering works earlier in the same chain and complements snippet-level scanning. GitHub Copilot’s public-code matching controls illustrate the approach. A filter can suppress or flag suggestions that match public code before the developer takes them into the codebase, reducing the amount of potentially problematic material that reaches the later gate. 

Its function should stay distinct from the scan run before release. Filtering acts at generation and reduces what enters the development process. Snippet-level analysis acts on the code the company proposes to merge or distribute, which is the artefact that matters for the company’s own distribution decision. Used together, the two create successive controls at generation and at release, while leaving the model-level reproduction itself untouched.

D. Contractual allocation of the residual risk 

The final governance layer concerns the risk that remains after architecture, provenance diligence and output controls have been applied.

Commercial AI providers increasingly address intellectual property exposure through representations, contractual commitments and indemnities, though the scope of that protection varies widely. Some commercial coding assistants indemnify against infringement claims arising from generated output, often on conditions about the use of public-code filters, prescribed configurations or other safeguards. Those provisions can transfer part of the output-level exposure back to the provider.

For the analysis in this article, the first contractual question is one of scope. An indemnity covering claims arising from generated output addresses the conventional risk that protected code enters a product. It does not necessarily cover a claim that the model weights themselves reproduce protected expression. A company relying on contractual allocation should therefore establish which artefact and which acts the protection covers: generated code, use of the service, possession of the model, distribution of the weights, or some combination.

The remaining terms decide how much protection that allocation really provides. Procurement review should look at representations about rights in or compliance relating to training data, the categories of intellectual property claim covered, exclusions tied to modification or fine-tuning, conditions requiring particular safeguards, control of the defence and settlement, liability caps, and whether protection survives where the model is deployed through a private or dedicated architecture. A broad statement that a product carries an intellectual-property indemnity says little until those limits are understood.

The allocation shifts as the customer takes on more technical control. A managed coding assistant or inference service leaves the provider in continuing control of the model, and can therefore support contractual protection tied to how the provider operates it. Downloading open weights hands control of deployment to the customer, while the licence under which those weights are released may carry extensive warranty and liability disclaimers. Fine-tuning widens the gap further, because the customer creates a derived artefact whose final state the provider neither controls nor necessarily agrees to defend.

The contractual analysis therefore tracks the technical one. Greater control over the weights tends to reduce the scope for shifting their legal consequences to someone else. That relationship should form part of the deployment decision itself, rather than being taken up only after the architecture has been chosen.

Taken together, the measures in this section operate at four successive points. A company can structure deployment so that possession of the weights stays elsewhere. Where possession is necessary, it can select a model whose training provenance permits a meaningful assessment and preserve equivalent provenance for any fine-tuning it performs. It can subject AI-assisted code to controls before that code enters the product and keep records good enough to revisit the assessment as detection improves. It can then allocate part of the remaining exposure through contractual protection whose scope matches the identified risk.

None of those measures alters protected expression that may already subsist in the model’s parameters. Their value is in reducing the number of situations in which that latent model-level exposure becomes an operational or distribution problem, while preserving the evidence needed to understand the decisions the company made. They turn the legal uncertainty of the earlier sections into a sequence of choices that can be built into architecture, procurement, development and contracting.

---

V. The unresolved question: can copyleft licences govern model weights?

This article has not argued that every open-weight model contains protected copyleft code, nor that every company deploying one infringes copyright. It has argued something narrower, and for that reason more difficult to dismiss. If memorised protected code is capable of subsisting in model weights as a reproduction, then the legal question does not end with copyright. It becomes necessary to ask whether the obligations attached to that code can still be identified and performed once the provenance connecting expression to its originating work has disappeared.

That question matters because the answer determines where governance should be directed. The practical measures available today do not remove whatever reproduction may already exist in the weights. They instead reduce the consequences of carrying it. Companies can choose not to possess the weights, select models whose provenance is better documented, examine generated code before release and negotiate contractual protection where it exists. None of those measures resolves the underlying legal uncertainty. They recognise it and govern around it.

The deeper implication lies beyond compliance programmes. Copyleft licences were drafted for software whose provenance remained observable throughout distribution. Model weights present a different kind of artefact. If copyright law comes to recognise reproductions embodied within those weights, while the provenance needed to identify the corresponding licence obligations can no longer be reconstructed, the limitation lies not in copyright doctrine but in the architecture of the licensing system itself.

Whether existing copyleft licences can accommodate that new reality, or whether model-weight distribution ultimately requires licensing mechanisms designed specifically for machine-learning models, is therefore a question of licence design rather than of copyright law. The Munich judgments have not answered that question. They have, however, made it possible to ask it.