Most developers I know hate software patents. I hate software patents. The idea that you can monopolize an algorithm or a workflow — an abstract idea dressed up in legalese — has always felt antithetical to how software actually gets built: standing on shoulders, iterating on existing ideas, combining concepts in new ways.
So when I came across Naresh Jain’s piece on Martin Fowler’s site, I expected to nod along to a familiar anti-patent screed. What I got instead was something more honest and more uncomfortable.
Jain opens from a position of principled resistance. Software patents, he argues, stifle innovation and primarily serve large incumbents with deep legal budgets — the classic critique, and one I agree with. But then something happened to him directly: patent aggression. A real threat, not a hypothetical.
And this is where it gets interesting.
The Asymmetry Problem
The trap that Jain describes is one I’ve seen play out at smaller companies: the legal system around patents isn’t designed for fairness, it’s designed for attrition. If a larger entity threatens you with a patent suit, your options are:
- Fight it (expensive, slow, uncertain)
- Settle (expensive, demoralizing)
- Have your own patents to cross-license (leverage)
Defensive patenting is essentially building a nuclear deterrent you never wanted and hope you never use. It’s the MAD doctrine applied to IP law.
Jain’s conclusion — filing patents not to assert them offensively, but to create a defensive shield — is exactly the kind of reluctant pragmatism the title promises. It’s not a betrayal of principles so much as an acknowledgment that principles don’t automatically protect you from legal reality.
What This Means for Developers
For most of us building things at the indie or small-team level, software patents are a background hum of anxiety we don’t think about until we do. Building a Discord bot or a side project? Probably fine. The moment you start getting traction, raising money, or operating in a space where incumbents feel threatened, the calculus shifts.
The uncomfortable takeaway from Jain’s experience isn’t that software patents are good — they’re not. It’s that the ecosystem is structured in a way that punishes ideological purity. You can refuse to participate in the patent system on principle, and that’s a valid choice. But you should do it with clear eyes about what you’re opting out of.
The Systemic Problem Remains
Jain’s individual pragmatism doesn’t fix anything at the systemic level, and I think he knows that. Defensive patent portfolios still clog the system, still cost money to maintain, and still represent a tax on building things. Every startup that defensively patents is also, from another startup’s perspective, an entity with patents that could theoretically be used offensively someday.
The real fix is policy — patent reform, narrower eligibility criteria for software patents, stronger obviousness standards. That’s a longer game than any individual founder can play.
But in the meantime, reading accounts like Jain’s is valuable. It strips away the comfortable abstraction that you can just ignore the patent system and build. Sometimes the system comes for you, and it helps to have thought through your position before that moment arrives.