Open-source AI feels simple at first.
You find a model on a repo. You pull the weights. You fine-tune it on your own data. You ship a feature.
Then a customer asks: “Can you prove you’re allowed to use this model in our product?”
And suddenly, it is not simple.
Because “open-source AI” is not one thing. It is three different things stacked on top of each other:
- the code license (the training and serving code)
- the weights license (the model file you download)
- the data rights (the data used to train it, and the data you use to fine-tune it)
If any one of those is wrong, your deal can stall. Your product can get pulled. Your company can look risky to buyers and investors.
Tran.vc exists for this exact kind of early problem. If you are building AI, robotics, or deep tech, you need clean IP early. Not later. Not “after we raise.” You can apply anytime here: https://www.tran.vc/apply-now-form/
This article is the first part: the introduction and the frame. I’ll keep it short, then we can go deep.
What “compliance” really means for open-source AI
When people hear “compliance,” they think of some big company checklist.
Founders should think of something else:
Compliance is proof.
Proof that you have permission. Proof that you kept the promises in the license. Proof that you can sell to a real business without fear.
Most AI startups do not fail because they “broke a law.” They fail because they cannot answer hard questions during sales, security review, or due diligence.
And these questions show up early now, even for small deals:
- “What model are you using?”
- “What license is the model under?”
- “Did you change the weights?”
- “Are you required to share your changes?”
- “Is this model allowed for commercial use?”
- “Did you train on customer data?”
- “Can you delete customer data?”
- “Do you have a record of where the training data came from?”
- “Can we use your product if our data cannot leave the EU?”
- “Does the model contain copyrighted content?”
- “Do you indemnify us?”
You do not need to be a lawyer to handle this. But you do need a clean system.
And you need it before you are in the middle of a big customer call.
If you want help building that system while also building a real IP moat (patents that fit your product, not generic filings), apply here: https://www.tran.vc/apply-now-form/
The simple model: code, weights, data
Here is the core idea that saves you from confusion:
Code is not weights. Weights are not data.
Many founders treat them like one bundle called “the model.” But in real life, they can have different rules.
Code
This includes:
- training scripts
- inference code
- libraries you use in your stack
- the wrappers you build around the model
Code is often under classic open-source licenses like MIT, Apache-2.0, or GPL.
Weights
Weights are the trained model files. This is the part that “knows” things.
Weights can be under:
- a permissive license
- a custom “community” license
- a “research only” license
- a license with limits on certain uses
- a license that forces you to share changes
Two projects can use the same code license, but have different weight licenses. That is why reading only the GitHub “LICENSE” file is not enough.
Data
Data is where things get real.
There are two data sets that matter:
- training data used to create the base model
- your fine-tuning data (including customer data, scraped data, synthetic data, and labeled data)
Even if code and weights are “open,” the data might create risk:
- privacy issues
- contract issues
- copyright issues
- database rights issues
- rules about scraping
- rules about user consent
- rules about data export
In some cases, the biggest risk is not the model license at all. It is that you cannot explain your data.
Why this matters more for B2B and deep tech
If you build a consumer app, you might get away with fuzzy answers for a while.
If you sell to enterprises, hospitals, banks, defense contractors, or robotics companies, you will not.
B2B buyers do not care that “everyone uses this model.” They care about what they can get sued for, and what their auditors will flag.
Also, deep tech products have longer sales cycles. The risk shows up before revenue, not after. That makes it harder to fix later.
If you are building robotics, AI agents, computer vision, or anything that touches real-world systems, you want your IP and compliance story to be tight. Tran.vc helps founders do that early with up to $50,000 in in-kind patent and IP services. Apply anytime: https://www.tran.vc/apply-now-form/
The most common mistakes founders make
I’ll keep this short, but these are the traps that come up again and again.
Mistake 1: “It’s on GitHub, so it must be open-source.”
A repo can be public and still be under a license that blocks commercial use. Or it can be missing key files. Or the weights can be under a separate policy.
Mistake 2: “Apache-2.0 means we’re safe.”
Apache-2.0 for code is usually friendly. But it does not automatically cover weights. And it does not solve data rights.
Mistake 3: “We didn’t train the base model, so we don’t need to care about training data.”
Customers may still ask. Investors may still ask. And if the model is later challenged, your product can still get impacted.
Mistake 4: “We fine-tuned it, so it’s ours.”
Fine-tuning does not erase the original license. Your new weights can still be tied to the upstream terms.
Mistake 5: “We’ll clean it up later.”
Later is expensive. Later is messy. Later is when you have customers and deadlines and stress. Early is when you can do it cleanly.
What you should aim for: a simple “AI Bill of Materials”
In software security, teams build an SBOM (software bill of materials). For AI, you need the same idea, but for models.
Not a giant legal doc. A clear record.
At a minimum, you want to be able to answer:
- Which base model are you using?
- Where did you get it?
- What is the license for the code?
- What is the license for the weights?
- Did you modify weights?
- If yes, what did you change and when?
- What data did you use for fine-tuning?
- Do you have rights to that data?
- Do you have permission to use it for commercial work?
- Can you remove it if asked?
- Where does customer data go during training and inference?
If you can answer those in plain words, you can pass many reviews.
If you cannot, you are gambling with your pipeline.
Where patents fit into this
Many founders think patents and open-source are opposites.
They are not.
Open-source compliance is about permission and proof.
Patents are about protection and leverage.
You can comply with open-source rules and still build a strong patent wall around:
- your method of fine-tuning
- your robotics control loop
- your data pipeline
- your model routing system
- your evaluation method
- your safety guardrails
- your on-device optimization approach
In fact, if you use public models, patents can become even more important. Because you need a moat that is not just “we use the same base model.”
Tran.vc is built to help founders do this the right way: clean IP, clear strategy, filings that match real product value. If you want to see if you fit, apply here: https://www.tran.vc/apply-now-form/
Licenses
Why licenses are not “just a legal thing”
Most founders treat licenses like background noise.
But in B2B, a license is a sales blocker or a sales enabler.
A buyer is not asking to be difficult. They are asking because they are the one who will get blamed if something goes wrong.
So the goal is not to “be perfect.” The goal is to be clear, consistent, and able to prove what you did.
When you can explain your license position in plain words, you remove fear.
When you cannot, the buyer assumes the worst and slows down.
The first distinction: code license vs weight license
A common trap is to read the repo license and stop there.
A GitHub page might show “Apache-2.0” and that feels safe.
But the model weights can be under a different set of terms.
You must treat them as separate assets, even if they live in the same folder.
Code is instructions. Weights are the trained “brain.” They can carry different rules.
The second distinction: model license vs the license of what it depends on
Even if your base model license is clean, your stack may not be.
Your serving code can pull in libraries with their own obligations.
Your training pipeline may use tools that have commercial limits.
Your dataset pipeline might use content governed by site terms or contracts.
Compliance is not only about the biggest piece. It is about the chain.
That is why you want a habit of tracking what you use, as you use it.
Permissive licenses and what they usually mean in practice
Permissive licenses like MIT and Apache-2.0 are common in AI code.
They are popular because they let you use, change, and ship the code in a product.
They still come with duties, like keeping notices and license text.
Apache-2.0 also has patent language that can matter in disputes.
Founders often ignore these details, but the good news is that these duties are usually easy to meet.
The hard part is not the duties. The hard part is knowing which license applies to which asset.
Copyleft licenses and the question you must answer early
Copyleft licenses, like GPL family licenses, can force you to share source code in some cases.
That does not always mean “you can’t use it.” It means you need to understand the trigger.
The trigger is often linked to how you distribute software.
If you ship a device, or ship software to customers, you may trigger obligations.
If you run software as a service, the outcome can differ by license type.
Many AI startups do not plan for this until a customer procurement team asks.
By then, changing dependencies can be painful.
So you want to decide early: are you okay with copyleft obligations, or do you want to avoid them?
“Open weights” does not always mean “free for business”
This is the point that surprises most teams.
Some weight licenses allow research use only.
Some allow commercial use but restrict certain industries.
Some require you to publish your changes to the weights.
Some require you to include specific notices in your product.
Some ban certain kinds of user content or certain deployment settings.
So when you pick a model, you are also picking a set of promises.
If your product plan conflicts with those promises, you either change your plan or change the model.
Custom community licenses and why they require extra care
A lot of AI models use custom licenses written by the publisher.
They may be called “community license,” “open model license,” or something similar.
These can be fair and clear, but they are not standard.
That means the meaning is not always familiar to buyers.
It also means you cannot rely on a quick gut feel.
You need to read the terms, map them to your use case, and capture the result in writing.
Even if the license is allowed for commercial use, the limits can still surprise you later.
The practical reading method: what you are allowed to do, and what you must do
When you read a license, keep it simple.
First, ask: what does it allow?
Are you allowed to use it in a paid product?
Are you allowed to modify it?
Are you allowed to distribute it, like shipping weights inside an app or device?
Are you allowed to host it and sell access as a service?
Then ask: what does it require?
Do you need to keep notices?
Do you need to share source code?
Do you need to share modified weights?
Do you need to publish attribution in a UI or docs?
Do you need to pass license terms downstream to your customers?
When you capture these answers in plain words, you can respond fast in security reviews.
Distribution vs service: the question that changes the outcome
A founder will often say, “We’re SaaS, so we’re safe.”
Sometimes that is true. Sometimes it is not.
Some licenses focus on distribution. That is, giving the software to others.
Some licenses also focus on network use. That is, running it for others over a network.
This distinction matters a lot for AI.
If you sell an API, you might not “distribute” weights, but you are still using them.
If you ship an edge device, you likely distribute weights and code together.
So the way you deliver your product changes the license risk.
You should decide your delivery model early, because it shapes what you can safely use.
Fine-tuning and derivative works: why you cannot assume it becomes yours
Fine-tuning creates new weights, but it does not erase the upstream terms.
Your new weights can still be treated as a derivative.
Some licenses allow derivatives with no extra duties.
Some require you to share the fine-tuned weights.
Some restrict how you can share them, or whether you can share them at all.
Even when a license is permissive, your customer might ask: “Is your fine-tuned model redistributable?”
That matters if you plan to deploy inside a customer environment.
So the right move is to decide, before you fine-tune, what you want to be true later.
The simplest compliance artifact you can create this week
If you do nothing else, create a one-page record per model.
Write down the model name, version, link to the source, and the exact license text or file reference.
Write down whether you are using the base weights, modified weights, or fine-tuned weights.
Write down how you deploy it, like SaaS API, on-device, or customer VPC.
Then write down the few duties that apply, in plain language.
This is not busy work. This is a revenue tool.
It cuts weeks off procurement cycles when you can answer cleanly.
Where Tran.vc fits when licenses touch your moat
Founders often feel stuck between “move fast” and “be safe.”
There is a better path: move fast with a clean record and a defensible plan.
That plan should include how licensing choices affect your long-term IP.
If a license forces you to share your key changes, you may want to shift your moat.
If a model license blocks your target market, you may want a different base model.
If your model choice is common, you may want to patent what makes your system unique.
Tran.vc helps teams do this early, when it is still easy to choose well.
If you are building AI, robotics, or deep tech and want to build a real moat without slowing down, apply here: https://www.tran.vc/apply-now-form/
Weights
Why weights are treated differently than code
Code tells a computer what to do.
Weights carry learned behavior, which can include hidden issues you did not intend.
That is why weight licenses are often more strict than code licenses.
It is also why buyers ask more questions about weights than about code.
They worry about what is inside, where it came from, and what obligations follow it.
So you should treat weights like a product component, not like a random download.
Weight files move across teams, and that creates silent risk
In many startups, weights get passed around informally.
One engineer downloads a model, puts it in a bucket, and shares it.
Later, someone else fine-tunes it, renames it, and deploys it.
Now the company has weights in production with no clear record.
When a customer asks for proof, the team scrambles.
This is why you want a single “source of truth” for weights.
Not a huge system. Just one place where you track what you use.
Base weights, fine-tuned weights, and merged weights are not the same thing
Base weights are what you download from the publisher.
Fine-tuned weights are created when you adapt the model using your data.
Merged weights happen when you combine adapters or do merges across models.
From a compliance view, each step can change what you must disclose.
From a business view, each step can change what you can sell and how you can deliver.
So when you say “we use model X,” you should be able to say which weights, which version, and what changes.
Commercial use limits: where teams get surprised late
Some weight licenses ban use in certain categories.
Some limit use above a size threshold or user count.
Some require you to register, accept extra terms, or follow an acceptable use policy.
Some require that you do not use the model to train a competing model.
These limits can collide with growth plans.
So you want to check them before you build your product roadmap around that model.
Sharing obligations: what “we must open it” can really mean
Some licenses require that if you change the weights, you share those changes.
That might mean releasing your fine-tuned model publicly.
Or it might mean sharing it with recipients who receive your product.
Or it might mean offering the source and scripts needed to reproduce the weights.
The exact duty depends on the license and how you distribute.
If your moat is in your fine-tuning, this can be a big deal.
So you should decide early whether you want your moat in weights, or in the system around the model.
Deployment mode changes weight risk in a very real way
If you only serve the model through your own API, customers may accept it more easily.
They do not receive the weights, and you can control access.
If you deploy into a customer VPC, you may need rights to share weights with them.
If you ship a robot or edge device, you may be distributing weights with hardware.
Each mode triggers different duties and different buyer questions.
So your go-to-market plan and your compliance plan must match.
A simple weights checklist that stays readable
For each weight file you use, you want to capture a few facts.
Where did it come from? What version is it?
What license covers this exact file?
Did we modify it? If yes, how?
Where is it stored, and who can access it?
How is it deployed, and does any customer receive it?
This is not meant to slow engineers down.
It is meant to stop “we think it’s fine” from turning into a real problem.
How weights connect to your IP story
In AI startups, investors often ask: “What is defensible here?”
If your answer is only “we fine-tuned a public model,” it can feel weak.
But if your answer is “we built a system that makes the model perform in a new way,” that is stronger.
This is where patents can fit well.
You can protect the unique parts of your pipeline, even when you use public weights.
That makes your business less dependent on a single upstream license.
If you want to build that kind of defensible foundation early, you can apply to Tran.vc here: https://www.tran.vc/apply-now-form/
Data
Data is the part that creates the biggest trust questions
Licenses feel like paperwork.
Data feels personal, because it touches users, customers, and sometimes the public.
When buyers ask about compliance, data is where they lean in.
They want to know where data came from, what consent exists, and where it goes.
If you cannot explain this clearly, they assume risk.
And risk kills deals.
Training data vs fine-tuning data: the key separation
You usually do not control the base model’s training data.
But you still inherit the consequences if that base model is challenged or restricted.
You do control your fine-tuning data, and buyers hold you accountable for it.
So you must keep these two buckets separate in your story.
When you mix them, you create confusion.
When you separate them, you sound responsible and credible.
Public data is not always “free to use”
This is where many teams make a costly assumption.
A page being visible on the internet does not mean you can copy it into a dataset.
A site can have terms that limit scraping.
A dataset can have a license that restricts commercial use.
A forum post can contain personal data, even if it is public.
If your model learns from that, you may create privacy issues.
So “public” is not the same as “safe.”
Customer data needs rules that you can explain in one breath
If you use customer data for training, you must be able to say so.
If you do not use it for training, you must be able to say that too, and mean it.
Many B2B customers require that their data is not used to improve your models.
Some will allow it only with opt-in and strict limits.
Some require data to stay in a certain region.
So you need clear defaults, clear contracts, and clear technical controls.
Even small startups can do this well if they decide early.
Synthetic data still needs a rights story
Some founders assume synthetic data removes all risk.
It can reduce risk, but it does not erase it.
If your synthetic data is built from copyrighted or private source data, questions can still arise.
If the synthetic pipeline reproduces real examples too closely, it can still leak.
If you use a third-party tool to generate synthetic data, that tool may have its own terms.
So synthetic data is a tool, not a magic shield.
A practical way to document data without slowing the team
You do not need a giant policy manual.
You need a record that answers simple questions.
What sources do we use? Who approved them?
What are we allowed to do with that data?
Where is it stored? How long do we keep it?
Who can access it?
What happens if someone asks us to delete it?
When you can answer these, you can handle enterprise reviews with calm confidence.
Data is also where your moat can live
If your model is not unique, your data can be.
Unique labeled datasets, unique sensor data, unique workflows, and unique feedback loops can become real value.
But only if you own the rights and can prove it.
This is one reason IP strategy matters early.
A clean data pipeline plus thoughtful patents can turn “we built a demo” into “we built an asset.”
Tran.vc helps founders build that asset from day one.
If you want to explore that path, apply here: https://www.tran.vc/apply-now-form/