When Defensive Patents Become the Only Rational Choice

Naresh Jain, founder of Specmatic and a longtime advocate for open, people-centric engineering, has never been comfortable with patents. Ideologically, he aligns with Richard Stallman: ideas should move freely, innovation should compound in the open, and progress should not be fenced off by legal constructs. For years, he believed software patents cause more harm than good.

That belief was tested in 2016, during his time at Hike Messenger. An emergency boardroom meeting was called after the company received a legal notice from a large messaging platform alleging IP violation. The patents in question, US10051104B2 and US20130305164A1, cover delivery and read receipts—seemingly basic UX elements that users instinctively expect in any messaging app. The shock was not that such patents existed, but that fundamental product primitives could be weaponized to decide who gets to innovate freely.

Martin Fowler has articulated the core dysfunction clearly: too few software patents hold true novelty, and too many claim vague, overly broad territory. They act less as incentives for invention and more as reinforcements for existing power structures. Based on that direct experience, Jain agrees with Fowler's diagnosis. But the question, he argues, is not whether the system is broken—it is what startups are supposed to do while operating inside it.

From Ideology to Reluctant Pragmatism

While building Specmatic, whose core is open source, Jain and his team faced a practical reality. They had to ensure they could protect their own innovation. Reluctantly, they filed a couple of patents—not to monetize or block others, but as a defensive measure so they would never be locked out of their own work again.

The patent filing process itself proved to be an unexpected act of clarity. It does not permit hiding behind vision decks, buzzwords, or piles of code. It demands precise answers to uncomfortable questions:

  • What is actually unique here?
  • What problem are we solving that others have not?
  • Where does prior art end and our idea begin?
  • If everything else is stripped away, what is the irreducible core of our innovation?

Answering these questions forced a discipline that felt less like legal paperwork and more like the most rigorous design review the team had ever undertaken—one conducted against the backdrop of the industry's entire history.

The prior art search was equally enlightening, though in a humbling way. Seeing how others had tackled similar problems, sometimes decades earlier, revealed where the team was building on existing work, where the industry had stalled, and where genuinely unexplored areas remained. In several cases, it sparked new ideas. In others, it simplified what they were building. Ironically, the process made their thinking more open, not more defensive.

Jain's stance on the patent system itself has not changed—he still considers it deeply flawed. What has changed is his understanding of power asymmetry. Large players use patents to extract royalties and fend off competition. Startups, on the other hand, often have no choice but to patent execution paths to protect their work from appropriation or exclusion. When legal leverage outweighs originality or execution, ideology alone does not provide protection.

This insight is especially relevant for startups building foundational infrastructure in spaces dominated by companies with better lawyers than engineers. In a sense, the fact that startups like Specmatic feel compelled to file defensive patents proves Fowler's point: when a system rewards legal capacity instead of technical merit, even those who believe deeply in openness are forced to engage with it out of necessity, not conviction.

Examining the Alternatives

Defensive patents were not the first option considered. Jain and his team examined several alternatives designed to preserve openness without resorting to patenting.

Communities like the Open Invention Network (OIN) encode intent and reduce harm within defined open-source ecosystems, particularly around the Linux System. They have value, but they do not eliminate the underlying asymmetry. They cannot prevent third parties from patenting your ideas, and they do not guarantee protection when patents are asserted outside the Linux System's core scope—which is exactly where Specmatic falls. Builders still have to navigate a system where legal protection and capacity are unevenly distributed.

Open-source licenses also provide no direct defense. Patent law and copyright law operate as entirely separate systems. Open-source licenses, including Apache 2.0 and GPLv3 with their patent retaliation clauses, work under copyright—which does not protect the underlying idea, concept, or method. Another developer can independently write different code with the same functionality without infringing copyright. Patents, by contrast, protect methods and systems, allowing the holder to exclude others from practicing an invention regardless of the specific code they write.

Specmatic's core is released under the MIT License, a choice made intentionally to maximize reach and composability. MIT optimizes for frictionless adoption, not control. The trade-off is structural: MIT has no patent retaliation clause and no implicit non-aggression pact. Openness maximizes adoption, but it does not neutralize power.

Principles and Realism

The lesson Jain draws is not to abandon ideals, but to pair them with clear-eyed realism. For anyone building something genuinely novel—particularly infrastructure, tooling, or platforms—leaving innovation unprotected can make you vulnerable, sometimes to the point of being excluded from the very work you created. The system is imperfect. Holding on to principles is essential, but principles alone do not shield anyone from reality. Pragmatism, in this case, means accepting that a broken system still demands strategic engagement from those who wish to change it.