You built something genuinely new on top of TensorFlow, PyTorch, or Hugging Face. A smarter training method. A retrieval pipeline that actually works. An architecture nobody else has shipped. Then a thought stops you cold: “I built this on free, open-source tools, so I probably can’t patent it, right?”
You can. Patenting AI built on open-source frameworks is allowed. The open-source license you agreed to controls one thing: the copyright in the framework’s code. It says nothing about your right to patent the new method, architecture, or training technique you invented on top of it. Those are two different kinds of intellectual property, and founders mix them up all the time.
Below is where the real line sits, the four things that actually decide whether your AI invention is patentable, and the one timing trap that quietly kills patent rights before founders even know they had them.
The license covers the code, not your invention
An open-source license is a copyright license. When you pull in PyTorch or TensorFlow, the license tells you what you’re allowed to do with that code: use it, modify it, redistribute it, ship it in a commercial product. That’s copyright territory.
But a patent protects something different. It protects an invention, a new and useful method or process, not a specific block of code. You’re not trying to patent PyTorch. You’re trying to patent the novel thing your system does that no one has done before.
So the framework being free and open doesn’t transfer to your invention. The MIT license on a library doesn’t reach forward and grab the new training technique you built six months later. Copyright in the framework and a patent on your method live in separate lanes.
I cover how copyright and patents each protect a startup in copyright for startups. For this question, the license is a copyright deal, and your invention is a patent question.
You don’t patent the software. You patent what it does.
You can’t get a patent on “an AI model” or “software that uses a neural network.” That’s too abstract on its own. Instead, what you can patent is a specific technical method your system performs. The “how,” not the “what.”
For example, say you built a fine-tuning method that cuts training cost in half by reordering how data flows through the model. The invention isn’t the Python. It’s the method, the specific steps that produce the technical improvement. In turn, your patent claims describe those steps. The code is just one way to carry them out.
That distinction decides most AI patents. Get it right and you have something defensible. Get it wrong and you’ve described an abstract idea, which runs straight into the main hurdle. This is the heart of what is patentable when software is involved: a real method, not a result.
Clearing Section 101: the abstract idea problem
The biggest reason examiners reject AI and software patents is 35 U.S.C. 101, the section on what subject matter is even eligible for a patent. You’ve probably heard “you can’t patent software” or “you can’t patent math.” That’s a misread of a real rule.
The rule comes from a Supreme Court case, Alice Corp. v. CLS Bank. So examiners run a two-step test. Step one: is the claim aimed at an abstract idea, like a mathematical formula or a basic business concept? If yes, step two: does it add something more, a real technical improvement, or is it just that abstract idea run on a generic computer?
Alice does not ban software patents. It does not ban AI patents. It bans patents that take an abstract idea and bolt it onto an ordinary computer without adding anything inventive. So the fix is to claim a specific technical improvement, not a result.
The 2024 USPTO guidance on AI
The USPTO made this clearer with updated AI guidance that took effect in July 2024. It confirmed that examiners judge AI inventions on the same footing as any other technology. Using AI tools to build your invention doesn’t hurt your eligibility either. The guidance even added worked examples, including neural-network anomaly detection and AI speech separation, showing what passes.
From that guidance, three things tend to push a claim from “abstract” to “patentable”:
- Tie the invention to a specific use. Not “an AI that predicts things.” An AI method that detects a specific kind of network anomaly in real time, for example.
- Explain the technical improvement in your application. Spell out how your method improves the technology, faster inference, less memory, better accuracy on a hard problem, in concrete terms.
- Include claim steps a person couldn’t just do in their head. Real-time neural-network processing, data transmission, a physical action triggered by the model. Steps that are technically grounded, not mental math.
If you prefer the short video version, I break down what actually survives examination in Software Patents: What Actually Gets Approved. It’s three minutes and it’s the same point: the technical “how” is what carries a software or AI patent.
A human has to be the inventor
A patent application has to name a human inventor. You can’t list the AI, even if you “had the AI design it.” The Federal Circuit settled this in Thaler v. Vidal, holding that an inventor under the Patent Act has to be a natural person. The Supreme Court declined to take it up, and turned away a related AI authorship case in March 2026, so this is settled.
You can use AI tools all day to help you build and refine. But a person has to have made the actual inventive contribution, and that person goes on the application. The USPTO’s 2024 guidance backs this up: how you developed the invention, including using AI tools, doesn’t change whether it’s eligible. A human still has to be the one who conceived it.
Still, for most founders this is a non-issue. You built the thing, you’re the inventor. Just don’t assume the model gets a line on the paperwork. It doesn’t.
The open-source license traps people actually hit
The license won’t block your patent. But two real things in these licenses catch founders off guard.
The Apache 2.0 retaliation clause
TensorFlow and a lot of ML projects use the Apache 2.0 license. Section 3 of that license does two things. First, it grants you a free patent license to use whatever patents the framework’s contributors put into the code. That’s a gift, it protects you.
Second, there’s a catch called the retaliation clause. If you turn around and sue, claiming the framework itself infringes one of your patents, your patent license to that framework ends as of the day you file suit.
The worry runs backwards. The clause only kicks in if you sue over the framework. It does not stop you from patenting your own invention, and it does not touch the patent on your novel method. The retaliation clause governs one narrow case: suing over the open-source code you used. So building your patent on top of Apache-licensed tooling is completely fine.
By the way, PyTorch historically used the MIT license, which has no patent clause at all. Different license, same result for you: neither one blocks your patent.
Publishing your code starts a clock
The moment you push your code to a public repo, publish a paper, or demo the method publicly, you’ve made a public disclosure. Under 35 U.S.C. 102(b)(1), that disclosure starts a 12-month clock in the United States. You have one year from your own first public disclosure to file, or you lose the right to patent it here.
But the bigger problem is the rest of the world. Most countries have no grace period at all. If you open-source your code before filing anything, you can permanently lose your patent rights in Europe, China, and most major markets. Gone, before you ever knew the clock existed.
So the order of operations is simple. File first, then publish. Even a provisional patent application before you go public protects your filing date and keeps your foreign options open. I get into this timing in Provisional Patents: 3 Reasons Startups Need One, and the open-source angle is exactly why it’s worth a few minutes.
File a PPA before you go public
A provisional patent application is the practical move for a founder who’s about to open-source code or pitch investors.
A PPA holds your filing date for 12 months and gives you “patent pending” status while you finalize the full non-provisional application. It buys you time to keep building, talk to investors, and refine the invention, all while your priority date is locked in. The one hard rule: there’s no extension. Miss the 12-month deadline and you lose that date.
On cost, here’s the real picture for 2026 (always worth confirming at filing, since the USPTO revises fees):
- PPA filing fee: $325 large entity, $130 small entity, $65 micro entity.
- Non-provisional utility application (filing, search, and exam combined): roughly $2,000 large, $800 small, $400 micro.
- Issue fee when it’s allowed: roughly $1,200 / $600 / $300.
Small entity status knocks about 60% off most fees, and micro entity about 80%, if you qualify on income and prior-filing limits. Those are government fees only. Drafting an AI patent application well is skilled work and costs more than the filing fee, but it’s also where claims live or die. I put real ranges on the whole thing in Patent Costs in 2026.
One reason not to do this part yourself: AI claim drafting is exactly the kind of nuance that DIY filings get wrong, and a weak PPA can fail to support your later claims. I get into why that backfires in a DIY provisional patent application.
Should you even patent it?
Not every AI invention should be a patent. A patent requires you to publicly describe how your invention works, that’s the trade for the protection.
If your edge is something you can keep hidden, a trade secret might protect it better. Think proprietary training data, model weights, or an internal pipeline nobody can see from the outside. But publishing open-source code can blow that secrecy wide open. Once it’s public, it’s not a secret anymore. That tension is worth thinking through before you push to a public repo, and I lay out the choice in patent vs. trade secret strategy.
There’s also a timing reason to move. AI patent filings are surging. The USPTO logged around 45,600 AI-related applications in 2023, up roughly 20% in a single year. A crowded field raises the bar for being “non-obvious” under 35 U.S.C. 103, and it rewards founders who file early. If your method is genuinely novel today, it may not stay novel for long.
FAQs
No, the license is a copyright license to the framework’s code. It governs how you can use and redistribute that code. It does not waive or block your right to patent your own novel method built on top of it. Ultimately, the two are separate forms of IP.
You can patent the novel method your model performs, as long as it’s new, useful, and non-obvious. The patent covers your specific technical improvement, not TensorFlow or PyTorch. Those tools are just how you built it.
No, Apache 2.0 grants you a patent license to use the framework. The retaliation clause only applies if you sue claiming the framework infringes your patent. So it has no effect on your ability to patent your own invention.
No, a patent has to name a human inventor under Thaler v. Vidal. You can use AI tools to help build the invention, but a person has to have made the inventive contribution and be named on the application.
In the United States, publishing starts a 12-month clock to file. Miss it and you lose your rights here. In most other countries there’s no grace period, so publishing first can permanently bar foreign patents. File first, even a PPA, then publish.
Next Steps
If you’ve built something novel on open-source tooling, you face a sequencing decision: open-source the rest, pitch it, or lock it down first. It’s worth getting that order right before you publish anything. Once code is public, some doors close on their own.
I’m happy to take a look at what you’ve built and give you a straight read on whether it’s patentable, whether a PPA makes sense before you go public, and what it would actually cost. No pressure either way. Here’s a link to my calendar. Grab a time that works for you and we’ll sort out where you stand.
