In the past two years, more and more teams have been building their own systems using open-source large models. DeepSeek's latest V4-Pro uses the MIT license, which sounds very permissive: download it freely, modify it freely, and use it freely to do business.
Open-source models are so popular now because their capabilities have genuinely caught up. An evaluation by the UK AI Safety Institute in July this year said that the gap between open-weight models and closed-source frontier models has narrowed from six to ten months last year to four to seven months. The price difference remains substantial: in the same batch of cyber offense and defense tests, the open-source model cost a few tenths of a yuan per question, while the closed-source model used for comparison cost more than ten US dollars per question. With comparable capabilities and lower prices, more and more people are using it as a foundation.
The problem lies in how many people understand the word "open source." They assume that because they are using MIT-licensed weights, the entire system is governed by MIT and they can use and sell it however they like. Only when they conduct a legal review before launch do they discover that it is not so simple: MIT governs only the weights, and the data you use for fine-tuning is not governed by it; if you also call closed-source interfaces such as OpenAI or Claude and use what they output, that part is even less governed by MIT. A single system contains several different sources, and each source is subject to a different set of constraints.
To explain this clearly, we must first clear up a misunderstanding.
"Open-source licenses" are not a single catch-all category
Everyone says "open-source license" as if it were one and the same thing. In fact, the differences between them are far greater than you might think.
By analogy: they are all called "contracts," but a lease, an employment contract, and a non-compete agreement are not the same thing; what they govern and how strongly they restrict differ enormously. You would not use a lease to understand a non-compete agreement. The same applies to open source. The "licenses" you encounter on the market fall into at least four categories, and what they license, what restrictions they retain, and whether commercial use is permitted all differ.
Let us go through them one by one.
Category one: MIT and its permissive siblings
MIT is the most permissive category. It essentially says one thing: take it and use it however you like, as long as you do not remove my attribution and this license notice.
A recipe is the most apt analogy. A chef publishes a recipe in a book with a note: "Please credit the source when making this dish." You may use this recipe to open a restaurant, modify the recipe, or write another book and publish it for sale; no one will stop you, and you may even lock down your modified recipe and not share it. The only thing you must do is retain that attribution.
The core grant text of the MIT license:
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software... subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Translation: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software... subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Starting from version V3-0324, DeepSeek has uniformly applied the MIT license to both its code and weights. Other licenses in the same category include Apache 2.0, BSD, and ISC; all are permissive and impose no obstacles to commercial use.
Apache 2.0 has one additional element compared with MIT that merits separate mention: an express patent license. MIT addresses only copyright and does not mention patents; Apache 2.0 expressly guarantees that contributors will not turn around and assert patents in the technology against you. Using the recipe analogy again, Apache 2.0 not only gives you the recipe but also adds, "I will not come after you with a patent application covering this dish." For large companies, this guarantee is valuable because it reduces one layer of risk from patent ambushes. That is why Google chose Apache 2.0 for Android rather than the stricter license used by its upstream Linux.
Second category: GPL, open source that "infects"
GPL is also open source, but its temperament is exactly the opposite. It carries an "infectious" clause, known in jargon as copyleft.
This means: if you use GPL code to create something new, then as long as you release it externally, the new thing must also be open-sourced and released under the same GPL; you may not make modifications and then keep it behind closed doors and sell it as closed-source software.
Take farming as an analogy. Someone gives you seeds for free on the condition that "whoever uses my seeds to grow grain must also share the harvest." If you want to keep things behind closed doors and sell, then do not touch these seeds. This is precisely where enterprises are truly wary of GPL: you intended to save effort by using open-source code, but then, without noticing, the part you worked hard to build is also swept in and must be disclosed. Therefore, when commercial companies make technology selections, most will steer around GPL, or specifically isolate GPL code so that it does not infect core products.
On the same matter, MIT and GPL give completely different answers. MIT says you may close the source as you wish; GPL says closing the source is not allowed. This is why the statement "they are all called open source" can be misleading.
Third category: called "open weights," but not open source
The third category is the easiest to stumble over, because it looks the most like open source and often has open in its name.
Meta's Llama and Alibaba's Tongyi Qianwen both follow this path. They release model weights for you to download, which looks very open, but the license agreements contain additional conditions. The most typical is a "user-scale threshold": Llama's community license states that companies with more than 700 million monthly active users must separately negotiate a license with Meta; Tongyi Qianwen's license has a similar arrangement, requiring a separate application once monthly active users exceed 100 million. In addition to scale thresholds, such agreements often restrict the applicable territory, withdraw the right to "sublicense," and attach a usage policy prohibiting certain uses.
For example, a shopping mall hangs a large sign at the entrance saying "free entry," and only when you get closer do you see the small print: chain stores with daily foot traffic above a certain number of tens of thousands must sign a separate contract to enter. It looks as if anyone may enter, but in fact a gate has been set for big players.
It is precisely because of this distinction that the industry now deliberately separates the two terms: one is called Open Weights, and the other is called Open Source. Open weights means "I give you the parameters"; open source means "I give you the rights as well, without additional restrictions." The OSI, an international organization that governs the definition of open source, issued an Open Source AI Definition in 2024. Measured against that yardstick, the Llama and DeepSeek series do not in fact fully meet the standard. So the next time you see a model describing itself as "open source," do not rush to feel reassured; you need to open its license agreement and read it carefully to see whether it is actually giving you the rights, or merely lending you the weights for your use.
Let me add a note on a judicial controversy here, so as not to state the matter too absolutely. Where manufacturers add commercial restrictions to self-drafted agreements, Chinese courts are not entirely consistent on whether such restrictions are valid. In one case (case number (2019) Yue 73 Zhi Min Chu No. 207), the Guangzhou Intellectual Property Court tended to hold that one cannot arbitrarily add commercial restrictions to a standard open-source license; but in another case (case number (2021) Zui Gao Fa Zhi Min Zhong No. 1547), the Supreme People's Court recognized a company's self-drafted open-source license agreement, holding that even if it contains restrictive clauses, they cannot be deemed invalid across the board. Therefore, whether the restrictive clauses of a self-drafted agreement are effective depends on how they are specifically drafted and how they are specifically applied; there can be no one-size-fits-all approach.
Category Four: the terms of service for closed-source interfaces are not open-source licenses at all
The first three categories at least remain within the spectrum of "open source." The fourth category is something else entirely.
When you call the OpenAI or Claude interfaces, what you sign is not any open-source license, but an ordinary commercial contract called a "services agreement." It does not give you any weights at all; it governs a different matter: what you may do with the output you obtain from the interface.
The buffet analogy fits best. You enter a buffet restaurant run by someone else; you may take dishes freely, and whatever lands on your plate is yours to eat (the output is yours); but a notice is posted at the restaurant entrance: you may not reverse-engineer the recipes of my dishes and take them to open a shop next door that competes with me.
OpenAI's current commercial services agreement (the version effective in January 2026, for enterprises and developers, not the individual version) is designed in exactly this way. On the one hand it says the customer owns the output, while on the other hand it restricts you from using the output to develop a model that competes with it. These two provisions must be read together:
Article 4.1 of the OpenAI Services Agreement (Customer owns Output):
As between Customer and OpenAI, to the extent permitted by applicable law, Customer: (a) retains all ownership rights in Input; and (b) owns all Output. OpenAI hereby assigns to Customer all OpenAI's right, title, and interest, if any, in and to Output.
Translation: As between Customer and OpenAI, and to the extent permitted by applicable law, Customer: (a) retains all ownership of Input; (b) owns all Output. OpenAI hereby assigns to Customer all of its right, title, and interest, if any, in and to Output.
Article 3.3(e) of the OpenAI Services Agreement (no using Output to train competing models):
Customer will not, and will not permit End Users to: ... (e) except for a Permitted Exception, use Output to develop artificial intelligence models that compete with OpenAI's products and services.
Translation: Customer shall not, and shall not permit its end users to: ... (e) except as permitted under a Permitted Exception, use Output to develop artificial intelligence models that compete with OpenAI's products and services.
Do you see the problem? Article 4.1 says the output is owned by you, while Article 3.3(e) says you may not use it to train competing models.“Owning” and “being able to use it for training” are two different things。
This layer is the most easily misunderstood, so let us use a book as an analogy again. You spend money to buy a book; the book is yours, and you can read it, give it away, or underline key passages in it. But “the book belongs to you” does not mean “you can photocopy the entire book thousands of times and sell the copies.” The former is ownership; the latter is a license to use. The same applies to outputs: ownership being granted to you does not mean a training license has also been granted to you.
Owning outputs does not mean being able to use them for training
OpenAI also has Article 4.3, which places responsibility on the customer for the input side as well: you must ensure on your own that you have the right to feed into the API whatever you feed into it, and you bear the consequences yourself if infringement issues arise.
Article 4.3 of the OpenAI Services Agreement (rights and responsibilities for input rest with the customer):
Customer is responsible for all Input and represents and warrants that it has all rights, licenses, and permissions required to provide Input to the Services. Customer is solely responsible for all use of the Outputs and for evaluating the accuracy and appropriateness of Output for Customer's use case.
Translation: The customer is responsible for all inputs and represents and warrants that it has all rights, licenses, and authorizations necessary to provide inputs to the service. The customer bears sole responsibility for all use of outputs and for evaluating whether outputs are accurate and appropriate for its own use cases.
The rules on Claude’s side are almost the same, but the details differ. The explanation updated in March of this year in Anthropic’s official Help Center is very direct: you own outputs, but without its written permission, you may not use outputs to train or develop AI models. It also leaves an opening: training models that do not compete with it is permitted, such as specialized small tools for sentiment analysis, content classification, summarization, and information extraction; but general-purpose chatbots and open-ended text-generation models that directly compete are prohibited.
Both prohibit competitive training and both leave openings for non-competitive uses, but “what counts as competition” and “where the exceptions end” are written differently by each. This brings up a very practical problem: if your system calls APIs from several providers at the same time, you need to build a separate checklist of terms for each provider and compare them one by one; you cannot expect a single MIT license to cover the entire call chain.
Four types of agreements at a glance
There is also a gate specific to China
Even after sorting out all the licenses and terms above, one final gate remains: China’s regulation.
This gate has only one question that determines whether it opens: is this system for your own internal use, or is it provided externally to the public?
The Interim Measures for the Administration of Generative Artificial Intelligence Services draw this boundary very clearly. Where enterprises or research institutions develop and apply such technology internally, the Measures do not apply so long as they do not provide services to the public within China. Therefore, where hospitals or government agencies carry out localized private deployments and use the technology behind closed doors, they generally do not directly fall within the many obligations under the Measures.
Article 2 of the Interim Measures for the Administration of Generative Artificial Intelligence Services:
These Measures apply to services that use generative artificial intelligence technology to provide the public within the territory of the People's Republic of China with generated text, images, audio, video and other content (hereinafter referred to as generative artificial intelligence services).
Where the State has other provisions on the use of generative artificial intelligence services to engage in activities such as news publishing, film and television production, and literary and artistic creation, those provisions shall prevail.
Where industry organizations, enterprises, education and research institutions, public cultural institutions, relevant professional institutions and others develop and apply generative artificial intelligence technology without providing generative artificial intelligence services to the public within China, the provisions of these Measures do not apply.
However, once this gate is crossed, obligations immediately stack up as soon as services begin to be provided to the public. Among them, the most fundamental is the requirement that the sources of training data and foundation models be lawful. There is no problem with using MIT-licensed weights as a base, but as for the batch of data fed in for fine-tuning, you must clearly account for whether its source is lawful, whether it infringes the intellectual property rights of others, and whether it involves personal information.
Article 7 of the Interim Measures for the Administration of Generative Artificial Intelligence Services:
Generative artificial intelligence service providers (hereinafter referred to as providers) shall lawfully carry out training data processing activities such as pre-training and optimization training, and shall comply with the following provisions:
(1) use data and foundation models with lawful sources;
(2) where intellectual property rights are involved, not infringe the intellectual property rights lawfully enjoyed by others;
(3) where personal information is involved, obtain the consent of the individual or satisfy other circumstances provided by laws and administrative regulations;
(4) take effective measures to improve the quality of training data and enhance the authenticity, accuracy, objectivity and diversity of training data;
(5) Other relevant provisions of laws and administrative regulations such as the Cybersecurity Law of the People's Republic of China, the Data Security Law of the People's Republic of China, and the Personal Information Protection Law of the People's Republic of China, as well as relevant regulatory requirements of the competent authorities.
Therefore, the statement "MIT weights can be used freely" ceased to be the complete answer the moment they were made available to the public.
Returning to that question: whose terms does a derivative system actually have to follow?
After going around in a circle, we return to the very beginning. For a system that both uses open-source weights and incorporates outputs from closed-source interfaces, and that is assembled from base weights, adapters, fine-tuning data, closed-source interface outputs, and the final model, which license actually governs it?
The answer is: several licenses govern it at the same time, and the strictest one applies. MIT governs the weights, the terms of service govern the interface outputs, the fine-tuning data has its own respective sources, and the intensity of regulation depends on whether you make it available to the public. No layer can be omitted; omitting one layer leaves a hidden risk.
Therefore, the truly cost-saving approach is not to litigate after a dispute arises following launch, but rather, before launch, to break the system down into a ledger and record it clearly layer by layer: what license the base weights are under, what license the adapters are under, where each batch of fine-tuning data came from, under whose terms the interface outputs are used, and whether the final model is for internal use or made available to the public. For each layer, state the source, the license, whether notices must be retained, and whether there are use restrictions. Once this ledger is solid, compliance shifts from after-the-fact firefighting to ex ante verifiability.
Before launch, break these five layers down into a ledger
Different people should look at different places
For the same matter, depending on where you stand, the places you need to watch are completely different.
Ordinary users who only use and do not build their own systemsIf you ordinarily use ChatGPT or run open-source models to write something, these terms are basically irrelevant to you; using the outputs yourself or posting them on social media is fine. The only thing to keep in mind is this: if you plan to use AI-generated content for commercial purposes, such as making it into a product for sale or printing it into a book for sale, first look back at the model or interface you used to see whether it imposes separate conditions on whether outputs may be used commercially. The vast majority do not, but certain open-weight agreements and API terms do say so; spend two minutes reading them clearly so as to avoid being caught off guard later.
Technical teams building their own systems with open-source modelsYou are the person who most needs to read this article, and there are three things to do in order. First, retain the notices. If you use MIT-licensed weights, keep their copyright and license notices in your project; this is the only hard requirement of the MIT license, and you cannot skip it. Second, clear the rights for your fine-tuning data. For every batch of data you feed into fine-tuning, record clearly, batch by batch, whether it is your own, purchased, or scraped from the internet, and whether it involves copyright or personal information; on the day you open it to the public, this is the first thing regulators will ask you about. Third, keep an eye on output flowing back in. This step is where things most easily go wrong: many people assume that "the output belongs to me anyway" and directly take what the GPT or Claude API spits out to train their own models. Ownership does not equal a license to train, especially when what you are training is a model that directly competes with it; in that case, you are very likely crossing the red line in the terms of service. If you really want to use it, first distinguish whether you are training a competing model or a non-competing specialized small tool.
Entrepreneurs building AI products to sellOn top of the three points above, think about two more layers. One layer is "open to whom": is your product an internal tool or a service offered to the public? This directly determines whether the Chinese regulation applies to you, whether you need to file, and whether you bear compliance obligations for training data; do not wait until the product becomes popular and users arrive before remembering this gate. The other layer is "how many providers you call": if your system connects to several closed-source APIs at the same time, do not expect one checklist to cover everything; you need to build a separate terms matrix for each provider and compare them one by one, noting which one permits non-competing uses and where each one draws its exceptions.
Purchasers of AI products and in-house counselIf you are the buyer, write the chain of rights into the contract: require the supplier to explain clearly what license the base model uses, where the fine-tuning data came from, and whether outputs from closed-source APIs were used. Do not just look at the feature demo; if an infringement dispute actually arises, these clauses in the contract can shield you to some extent.
Closing
"Open source" is not a switch; it is a spectrum. An "open-source license" is not a single catch-all bin either; it is at least four types of legal tools with completely different temperaments. MIT is broad, GPL is strict, open weights look open but actually come with thresholds, and the terms of service for closed-source APIs are not on the open-source line at all. When they are used together, whose terms a derivative system follows is never answered by "choosing the right license," but by "taking the whole chain apart and clearing it layer by layer."
Seeing clearly who governs each layer is more important than memorizing what each license is called.
If you are working on private AI deployment, model fine-tuning, or building a system that mixes calls to multiple models, and you are unsure which layers of licenses and terms govern what you have, you can talk to me. Sorting out the chain of rights before launch is always cheaper than handling disputes after launch.
References
- DeepSeek-V4-Pro official model card (official HuggingFace model repository)
- UK AI Safety Institute (AISI): "How Far Behind the Frontier are Leading Open Weight Models on Cyber?" (July 2026)
- OpenAI Services Agreement (version updated December 2025, effective January 1, 2026, Sections 3.3, 4.1 and 4.3)
- Anthropic Official Help Center: "Can I use my Outputs to train an AI model?" (March 2026)
- Interim Measures for the Administration of Generative Artificial Intelligence Services (Cyberspace Administration of China and six other departments, effective August 15, 2023, Articles 2 and 7)
- OSI Open Source AI Definition (OSAID) 1.0 (October 2024)
- Guangzhou Intellectual Property Court, (2019) Yue 73 Zhi Min Chu No. 207; Supreme People's Court, (2021) Zui Gao Fa Zhi Min Zhong No. 1547
Author of this article:Lü Yinghui, a lawyer at Mankun (Shenzhen) Law Firm. A graduate of China University of Political Science and Law, with nearly ten years of deep experience in the legal industry and prior work at a Shenzhen court. Focused on legal services for the new-generation economy, with extensive practical experience and deep insight in fields such as Web3 and artificial intelligence. Account on all platforms: Lao Lü Talks New Money; you are welcome to follow.
