Patenting for Inventors Ep. 174: You Patented It… But Did Open Source Just Blow It Up? The Legal Risks of Using Open Source Code

Open source code feels communal and risk-free, but combining it with patent strategy creates real friction. Patents protect your exclusive right to an invention. Many open source licenses—especially copyleft licenses like GPL—require that derivative works remain open to others. When both collide, your patent's practical value shrinks fast.

In this episode, Adam Diament explores how permissive licenses differ from copyleft, why even tiny snippets matter, and what to know about your codebase before you file.

Patenting for Inventors Ep. 174:

Podcast Transcript:

Hello, and welcome to the Patenting for Inventors podcast. I’m your host, Adam Diament, a registered patent attorney and partner at the law firm of Nolan Heimann in Los Angeles, California. This episode is You Patented It… But Did Open Source Just Blow It Up? The Legal Risks of Using Open Source Code.

So let me start with a question I get all the time, usually right after someone tells me how clever their product is. If I used open source code, that’s fine, right? I mean, it’s free. Everyone uses it. What could possibly go wrong. And honestly, I get why people think that way. Open source feels friendly. It feels communal. It feels like borrowing a cup of sugar from your neighbor. But in the patent world, borrowing sugar can accidentally come with a contract taped to the cup. 

Here’s the deal. Open source code is not just code you found on the internet that no one owns. It is code that someone very intentionally shared under specific terms. And those terms matter a lot when you are thinking about patents. Because patents are about exclusivity. Open source licenses are often about sharing. Sometimes those two ideas get along. Sometimes they absolutely do not. 

Imagine you build a product that relies on a chunk of open source code. That code might be governed by a permissive license, like MIT or BSD. Those are the easygoing ones. They usually say something like, go ahead, use it, modify it, sell it, just keep the copyright notice. From a patent perspective, those are usually manageable. Not always risk free, but manageable. 

But then there are other licenses that are more opinionated. Licenses like GPL. These licenses come with expectations. They can require that if you distribute a product using that code, you also make your own source code available. That might be fine if you are building a hobby project. It might be a nightmare if your business model depends on keeping certain implementation details secret. 

Now here is where inventors get surprised. Even if you wrote brand new code around the open source portion, the license can still reach into your product. And if your patent application describes an invention that relies on that code, you may be telling the world how something works that the license already requires you to share anyway. At that point, your patent might still exist on paper, but the practical exclusivity you thought you had starts to shrink. 

There is also the inventorship issue. Patents require that you list the true inventors. Open source contributors are usually not inventors of your invention just because you used their code. But if your claimed invention is really just a thin wrapper around existing open source functionality, you may run into problems showing that your claims are actually new and non obvious. Examiners love prior art. Open source repositories are basically a candy store for prior art. 

Another thing people miss is that some open source licenses include patent clauses. These can be patent grants or patent retaliation provisions. Translation in normal human language. By using the code, you might be granting a patent license to others. Or you might be agreeing that if you sue someone for patent infringement, you lose rights under the license. That can get very awkward very fast if your business plan includes patent enforcement. 

And look, none of this means you should never use open source code. That would be ridiculous. Modern software would grind to a halt. The thing is, you want to be intentional. You want to know what code you are using, what license applies, and how that code shows up in your patent claims. There is a big difference between patenting a system that happens to use open source tools, and patenting the tool itself. 

One practical way to think about it is this. Your patent claims should focus on what you added. The architecture. The workflow. The technical improvement. Not the fact that you used a popular library that half the internet already uses. If your patent lives or dies based on that library, that is a warning sign. 

I also see problems when teams treat open source like a black box. Someone pulls in a dependency. Then another dependency. Then another. Before you know it, no one really knows what licenses apply. When you file a patent application, that lack of clarity can come back to bite you. Especially during diligence. Investors love asking about IP risk. Open source always comes up. 

So the takeaway here is not panic. It is awareness. Open source is powerful. Patents are powerful. But power tools need instructions. If you are building something you want to patent, slow down just enough to ask what code you are using and why. That simple pause can save you a lot of pain later. 

Now, here’s where people sometimes fall into a bit of a trap. They’ll think, “Well, I just used a little snippet from some GitHub project. It’s only like, 20 lines of code. That can’t be a big deal, right?” But it absolutely can. Even tiny chunks of code can be protected under copyright. And if that code was released under a copyleft license, it’s not about how much you used, it’s about whether you’ve created a derivative work. And a derivative work, under those licenses, usually comes with obligations—like releasing your own source code or allowing others to use your invention under the same terms. 

That’s where this butts up against patent law. Because if you’re trying to get exclusive rights to something through a patent—basically telling the world, “Hey, no one else can make or use this invention without my permission”—but you’ve also bundled in open-source code that legally says, “Anyone can use this, and they can use it in anything built on top of it,” well… now you’ve got a problem. You’re kind of speaking out of both sides of your mouth, and the courts—or more likely, a competitor’s lawyer—will notice. 

And just to be clear, this doesn’t mean you can’t ever use open-source code in a project you plan to patent. But you’ve got to be extremely careful about which licenses you’re dealing with. Some are permissive, like the MIT License or the BSD License. Those usually just say, “Go ahead, use it—just give us credit and don’t sue us.” That’s a totally different animal from something like the GPL, which is like, “Sure, use it, but only if you play by our open-source rules all the way down the chain.” 

So let’s say you’re a startup founder, and you’ve built this amazing new mobile app that uses a machine learning model to do something clever—let’s say, identify plant species based on a photo. Now, your model uses a framework that’s licensed under Apache 2.0, and that’s fine, because Apache is pretty permissive. But maybe, to save time, one of your developers pulled a pre-trained model from some GitHub repo, and that repo is under the GPL. You might not even notice. But if that code becomes essential to your invention and gets described in your patent application—or worse, embedded in a commercial product—then you might’ve just introduced GPL obligations into your invention without realizing it. 

And if a competitor figures that out? They might not even sue you. They might just call the whole patent into question. Say you filed a patent on the invention, but you don’t actually have the right to exclude others because the GPL code you used already obligates you to share. That undercuts your exclusive rights, which is kind of the whole point of the patent. And that’s not even getting into the risk of a copyright infringement lawsuit if you’re violating the license outright. 

Also, here’s a sneaky thing that happens sometimes. A company builds a product, uses a little open-source code in it, gets a patent, and then goes out and tries to enforce that patent against someone else. The person on the other end looks at the patent, digs around in the code, and goes, “Wait a minute. You’re using GPL code in here.” And boom—now they’ve got a defense, maybe even a counterclaim. You tried to use a sword, and they turned it into a boomerang. 

So what should you do if you’re in this situation? Well, number one, you’ve got to know what’s in your codebase. That’s not just a legal thing—it’s a business hygiene thing. Use tools that scan for open-source licenses. Have policies in place for how code gets added. Make sure your team understands that “free” doesn’t always mean “risk-free.”  

And look, even if you’re super clean with your own code, be careful with contractors. I’ve seen people hire overseas developers who throw in open-source code left and right because they don’t care about license compatibility. Or they just assume everything online is up for grabs. That’s not how it works. The liability still falls on your company, not the guy in Bulgaria who added a GPL module into your backend. 

One other thing to keep in mind here—open-source isn’t just code. There are also models, data sets, libraries, images, and other resources that fall under these licenses. If your patent describes or relies on any of that, the same issues can pop up. A lot of inventors are using things like open AI models these days. You’ve got to read the license. Some are fine. Some are restrictive. And some change over time, which is a whole other headache. 

So here’s my big takeaway. If you’re building something patentable and you’re using any open-source anything, pause. Double-check those licenses. Talk to legal. Be clear with your developers. Don’t wait until your patent is about to issue—or worse, after you’ve enforced it—to figure out there’s a licensing time bomb in your code. Because once it’s out in the world, it’s hard to pull it back. And the damage can go way beyond the patent. It can hit your funding, your reputation, your partnerships—everything. 

That’s it for today’s episode, and if you need help filing a patent application, or other intellectual property, give me a call at 424-281-0162. Until next time, I’m Adam Diament, and keep on inventing!