The hidden liabilities in open source AI model adoption

The problem nobody's talking about

When you grab a model from Hugging Face or GitHub, you see one license: Apache 2.0, MIT, or whatever. What you don't see is the mountain of training data with its own potentially conflicting licenses lurking underneath. Constraints on that data are inherited by the model. It's like buying a house and later finding out that the foundation was built on someone else's property.

Here's what we found.

• 76% of models have at least one training dataset with a license that's either incompatible with or considerably more restrictive than the model's declared license.
• 25% of all training datasets either have no recorded license or no concrete information on where they came from.
• 381 million downloads have been served under these sketchy conditions.

If you're responsible for software using open source AI in any regulated or commercial context, this is a problem you need to understand.

Three levels of license trouble

Not all these incompatibilities are created equally. Some are worse than others.

Level 1: What license?

This is the scariest category: models trained on datasets where we literally have no idea what the license is.

• Unlicensed datasets (33 cases, 15% of all the datasets we examined): The dataset has no license declaration at all. In most countries, "no license declared" means "all rights reserved." You can't legally use it. Full stop. Yet models trained on this data are slapped with "Apache 2.0" and shipped worldwide.
• Unknown datasets (21 cases, 10% of the datasets): Even worse in some ways—we don’t know the license and we don't know where the data came from. You can't verify the quality, you can't check for bias, you can't even confirm it's legitimate. It's like pulling a box off the shelf in the grocery store and finding no list of ingredients.

Put these together and 25% of all training datasets raise major concerns. And more than 50% of the models were trained on problematic—either unknown or unlicensed—datasets.

Level 2: You can't use this commercially (The practical problem)

Some datasets come with Creative Commons noncommercial licenses (CC BY-NC) or research-only restrictions. The restrictions are clear: You can’t use models commercially that are trained on this data.

We found 15 dataset cases (6.5%) with explicit noncommercial restrictions that were used in over 30% of models analyzed, and those had over 23 million downloads.

The absurdity? Those same datasets end up in models released under Apache 2.0, which explicitly says that you can use this for commercial purposes. You end up with a model that claims to be commercially safe while trained on data that isn't. Your lawyers will tell you this is not good.

Level 3: The copyleft and ShareAlike problem

Copyleft licenses like GPL and Creative Commons ShareAlike come with a catch: If you build something on top of them, those derivative works must be released under the same license.

We found 18 datasets (8% of models) using copyleft-licensed data. The law is not yet clear on how this would apply to trained models. If a court says the model inherits those license terms, suddenly your proprietary model is legally required to be open source. The fix? Retrain the model—usually not practical if it's even possible. Otherwise, don't use the model.

One model in our audit had been trained with 49 datasets that included multiple copyleft-licensed ones. That's a legal powder keg waiting to go off.

But it's not just a licensing problem

Uncertainty about where data comes from creates operational risks beyond just lawyers getting nervous. If you don't know where training data came from, you can't verify

• Data quality: Is this actually good data?
• Bias characteristics: How is this model likely to perpetuate past human failings?
• Privacy compliance: Was this data collected legally?
• Regulatory alignment: Will this pass EU AI Act requirements?

The EU AI Act requires you to document where training data comes from. If you deployed a model without checking, and that model was trained on unknown or unlicensed datasets, you're liable to need a very long conversation with compliance teams.

And that's the thing: Once you notice the problem, fixing it retroactively is expensive. Asking the right questions upfront costs way less.

What you should actually be doing about this

If you're using AI models in products, this guidance will serve you well.

• Don't just trust the model license. Go one level deeper. Pull up the model card or documentation and look at the training datasets. Don't deploy until you've done deeper investigation.
• Treat unlicensed and unknown data as high-risk. These aren't just boring paperwork issues—they're signals that something is wrong with the provenance or documentation. This becomes especially critical in regulated industries where legal accountability, auditability, and risk tolerance thresholds are much stricter than in general commercial software.
• Create a Software Bill of Materials for every model you use in production. Document
  • Which training datasets were used
  • Their license status (including unlicensed and unknown flags)
  • When you verified this
  • Any legal review that happened
• Watch for upstream changes. A model can be compliant today and noncompliant tomorrow if a dataset's terms of use change. Check this whenever updating to a newer version of the model.
• Build this into your model selection process. Pick a cool model but build the guardrails to ensure it doesn’t come with baggage. It's not sexy, but it's how mature software ecosystems handle this problem. Your processes should, too.

If you are acquiring a company that uses AI models in products, our experience shows that following these steps are in your best interests.

• Run an AI model audit before close. Same vibe as a traditional code audit, but now you're checking training data lineage, not just open source packages. You could be inheriting models with problematic licensing chains. Make this a part of due diligence, not an afterthought.
• Document every model. You're buying the company and the legal liability that comes with their AI stack. If they haven't documented which training datasets power their production models, that's a red flag. Create (or demand they create) a complete Bill of Materials before integration.
• Check for EU AI Act compliance. If they're operating in Europe or planning to and they can't prove where their training data came from, you've got a regulatory nightmare waiting to happen. This isn't just risky—it's potentially illegal soon.
• Plan for remediation costs. If you discover post-acquisition that their key model was trained on incompatible or copyleft-licensed data, you can't just shrug it off. Budget (both dollars and roadmap time) for retraining, new data acquisition, or replacing the model entirely.
• Integrate their data practices into yours. Don't let the acquired company's AI practices drift. Fold its model governance into your compliance framework immediately. "They've always done it this way" is not a defense when regulators come knocking.