Do Quantized, LoRA, or Fine-Tuned Models Still Fall Under the Original License? ​

We · October 2026

This is the third article in our "Open Source and Commercial Use" series. Why Companies Open Source explains why clauses are written the way they are, Why Open-Source Projects Change Licenses Mid-Stream explains how clauses get rewritten, and this article covers the third situation: after you modify the model, do the clauses still apply? The classifications in this article are based on each license text and our existing license compilation, queried as of October 2026. This article does not constitute legal advice, does not rewrite or replace original clauses, and all conclusions are subject to the LICENSE file of the specific version you are using.

I. Let's Be Clear: Modifying the Model Does Not Replace the Contract ​

Our audio.cpp Model Licenses and Commercial Use page has already established one principle: quantization does not change the license. This article takes it further — not just quantization, but the vast majority of model modifications do not change the license.

The reason is not moral — it is textual. The three major license families (permissive, copyleft, non-commercial) each carry their own definition of "what counts as a derivative work," and attach obligations to that definition. Apache 2.0 defines derivative works as "resulting from any revision, annotation, elaboration, or other modification to the original work that, as a whole, represents an original work of authorship," and requires that the original license notice be retained upon distribution. The GPL family requires that "works based on the original program" carry the same license as a whole. In the CC 4.0 family, BY requires attribution, NC extends the non-commercial restriction to adaptations, and ND restricts distribution of adapted material.

In other words, the clauses already anticipated that you would modify it. The more you change, the more you are operating within the paragraph they wrote.

So we need to distinguish two things that are often conflated:

Each layer of the chain carries its own contract. The rights you hold are the intersection of all of them. Our Open-Source Software Licenses Explained has been covering this two-layer structure; this article breaks the "layers" down further.

II. Five Actions, Examined One by One ​

Quantization deserves an extra word. Quantization simply lowers the numerical precision of the numbers in a model, in exchange for smaller file size, faster speed, and less VRAM. Files are often named something like "model-name-4bit." In local deployment, this is usually what the user ends up with. Many people therefore treat it as a new model, even feeling "I'm not using the official version."

What we want to say is: what changed is precision, not rights. Our established principle bears repeating here: quantization is merely a numerical precision conversion of the original weights. It is a derivative work of the original model, and the original license terms apply word for word.

The LoRA illusion comes from its distribution form. A几十 MB adapter file looks completely unrelated to the multi-GB base, so it is easy to think "I trained this myself, it should be mine." The real constraint kicks in at load time: the adapter file must be paired with the base weights to function, and what the user gets is the combination of both.

If you distribute the two packaged together, the base's terms definitely travel with it. If you distribute only the small file and let users download the base themselves, you still need to confirm two things: whether the base license permits this usage, and whether it requires attribution.

There is also a genuine gap here worth explaining. Apache 2.0, when defining derivative works, explicitly excludes "components that can be separated from the original work and are invoked only through linking or interfacing." That sentence was written for software. Whether a small offset file counts as such a separable component is not directly answered in the license text — weights do not fit neatly into software language. In these situations, our only advice is "read the original text, consult legal counsel." We will not fill in the blanks for the clauses.

ND governs something else entirely. The ND in CC-BY-NC-ND does not restrict "whether you can charge money" — it restricts whether adapted material can be distributed externally. Modifying privately is one thing; distributing modified weights is another. ND blocks the latter. The NC in the same license separately prohibits commercial use. Vevo2 (voice conversion) in our catalog carries CC-BY-NC-ND, with both restrictions stacked. Such clauses are often misread as "just no commercial use, I can modify it myself," but the actual scope is wider.

III. Three Layers Most Easily Overlooked in the Chain ​

Layer 1: Sub-components. At runtime, the model loads separate tokenizers, text encoders, and vocoders, often from different projects under different licenses. The same documentation has noted this point: bundled sub-components are also subject to their own constraints. You audited the main model but missed the vocoder — the chain breaks at its weakest link.

Layer 2: Training data. This layer best explains one thing: why projects with permissive code can have non-permissive weights. OmniVoice in our catalog is a typical example. Its code is Apache-2.0, but its weights are CC-BY-NC, because the training dataset itself carries non-commercial restrictions. Restrictions at the data layer propagate upward to the weight layer. How this propagation forms on the publishing side is covered in Why People Who Don't Run a Business Also Open-Source: most academic teams and small teams are not trying to impose restrictions — they are simply passing through the constraints on upstream materials and data as-is.

The same principle applies to you. If you fine-tune using publicly scraped audio, someone else's voice packs, or text of uncertain provenance, those restrictions will propagate through your output. Conversely, this is the only layer in the entire chain that is entirely within your control: data you recorded yourself, purchased, or that explicitly permits commercial use will not add new constraints to your work.

Layer 3: Software. The frameworks, interfaces, and inference engines you run locally are under separate licenses (mostly Apache-2.0 or MIT, but also GPL and AGPL). They govern "how the software is distributed" and do not grant any model usage rights. This is the other half of the reminder from Where Model Files Come From: see the file clearly, and also see the license name next to it.

One more reality visible in our catalog: different generations within the same product line can carry completely different licenses. IndexTTS 1 is Apache-2.0, while IndexTTS 2 and 2.5 are under the bilibili Model Use License Agreement; ACE-Step's bundled 1.5 is MIT, while v1-3.5B is Apache-2.0. Some catalog entries even list five licenses in a single row: the audio.cpp WebUI license field reads Apache-2.0, MIT, CC BY-NC, Research Only, Non-Commercial License. In entries like this, "taking the intersection" is not a rhetorical device — it literally means five licenses intersected.

IV. Can My Fine-Tuned Model Be Used Commercially? Can It Be Closed-Source? ​

One framework first: the more permissive the base license, the more freedom your derivative has; if the base license carries conditions, those conditions travel with the derivative. Looking at it category by category (categories follow our software license article; here we only address consequences for the weight side):

One more question deserves a separate answer: can content generated by the model be used commercially? This is an independent layer in the chain. Permissive licenses generally do not restrict this, but some clauses do address it explicitly. Two clear examples: Llama 2 and 3 licenses prohibit using model outputs to train other models; from 3.1 onward this is allowed but requires attribution; Stability's community license prohibits using outputs to train competing foundation models.

In other words, clauses can directly govern what you do with the outputs. People delivering work for clients are most likely to trip on this point, because their product is the output itself.

As for "whether AI-generated content has copyright and who owns it," we do not write conclusions here. It depends on current regulations and case-by-case determinations in each jurisdiction, and what we can verify is the clause text, not the judicial standard. If you are delivering commercial projects, this question should be answered by your legal counsel, not by an article on our site.

V. Documenting the Chain Before Delivery: Six Items ​

The habit we have been recommending — recording version number and license name — needs to expand into a full chain when you are producing your own model output. Engineering-wise this is lighter than it sounds; the cost is one table:

The last row is the most practical. "Personal use" and "distribution" have completely different answers. Without external distribution, most copyleft open-source obligations do not trigger at all; once bundled with software for distribution or delivered to a client, obligations take effect immediately. Conversely, a research license that feels harmless for internal use may become commercial use the moment you "deliver to a client." Get this row wrong, and no amount of neatness in the previous five rows can save you.

These forms have their own set of questions in campus settings: what does classroom demonstration, distributing images to students, running an online course platform, or paid training each trigger — Do Schools and Research Labs Need to Worry About Licenses? covers this specifically; we do not expand on it here.

VI. Our Take ​

First, license obligations follow "dependency," not "filename." The more your output depends on the base weights, the harder it is to call it an independent work. Quantization, fine-tuning, and merging all deepen dependency — they do not sever it. The only two things that can genuinely change the conclusion are: switching to a different base, or purchasing a commercial license. The latter is exactly the path the publisher left open, as described in Why Companies Open Source.

Second, the data layer is the only one entirely within your control — and the one most likely to contaminate the entire chain. You can read, choose, and switch weight licenses; the provenance of training data, however, is often not questioned. The combination in OmniVoice — "permissive code, non-commercial weights" — is essentially the result of data-layer restrictions propagating upward. When you do your own fine-tuning, the same mechanism will act on your output.

Third, do not expect "modification" to wash away restrictions, but you can expect "documentation" to rescue your position. The distinction between these two sentences is important: the first is self-deception, the second is extremely low-cost risk management. License changes, takedowns, and license tightening — the kinds of things you read about in Why Open-Source Projects Change Licenses Mid-Stream — will genuinely happen to your base. When that day comes, the only three things you will be able to state clearly are: which version I was using, what contract it carried at the time, and what I built on top of it.

One of the values of local deployment is that it lets you get your hands on these files: compress, fine-tune, swap in your own voice. What we want to say is simply that the minute you spend modifying them is free, but the table you fill out afterward is where the real work lies. Displaying each of these license layers inside the installation and delivery workflow — rather than leaving them in documentation for someone to look up — is what local deployment tools should look like when they reach the last mile.

Disclaimer: This article is our synthesis of license texts and our existing license compilation. It does not constitute legal advice. Clause descriptions are based on each repository's LICENSE file at the time; classifications follow the conventions of audio.cpp Model Licenses and Commercial Use and Open-Source Software Licenses Explained, and may change with upstream updates. The determination of derivative works and the ownership of generated content are subject to dispute across jurisdictions. For decisions involving real commercial interests, consult professional legal counsel.