Devs are destroying your patent rights

Companies self-sabotage their rights in their patent portfolio through innocuous dev decisions: a contribution to an open-source project, a library pulled into the codebase, a repository made public. By the time a patent is contemplated the rights may already be gone through licence terms your team agreed to without consideration.

This article addresses one specific and underappreciated risk: the interaction between open-source licensing and patent strategy. The licences your development team accepts when incorporating third-party components, and the licences they grant when contributing to open-source projects, have direct and sometimes irreversible consequences for your patent position.

The two directions of risk

The risk runs in two directions.

Open source dev tooling is so commonly used that potential risks can be underappreciated.

When you use open source components, you accept the licence terms attached to that code. Some of those terms include elements that might be surprising: patent provisions, grants, retaliation clauses, or disclosure obligations. Some of these can intersect, sometimes dramatically, with how you can hold and enforce patents on software that imports these obscure licensing obligations.

When you contribute to open-source projects, you grant licence terms to every downstream user of that project. If your software implements a patented (or potentially patentable) invention, you can inadvertenlly find yourself in a situation in which technically you are nullifying your patent rights by effectively dedicating the invention to the public.

Understanding which licences carry which obligations is not optional for a business with a patent strategy.

The licence that cost Facebook React: BSD+Patents

React, an open source contribution from Meta, is one of the most instructive real-world cases. It is not a patent lawsuit. It is a licensing controversy that implicated one of the most widely adopted JavaScript libraries in the world.

For several years, React (which originated from Facebook) was released under a modified BSD licence with a separate PATENTS file attached: the BSD+Patents licence. The licence granted users a copyright licence under the standard BSD terms, but the patent grant came with a sting. The patent grant would terminate automatically if the licensee, or any of its subsidiaries, corporate affiliates, or agents, initiated directly or indirectly any patent assertion against Facebook, against any party relating to Facebook's software, or against any party relating to the software itself.

The clause was extraordinary in scope. Under a conventional Apache licence, an organisation with a patent claim entirely outside of React could sue Facebook and its rights to the React project would remain unchanged. Under the BSD+Patents licence, any suit, whether within or outside of React, would trigger the termination of patent rights. Build your product on React, and you surrendered the ability to assert any patent against Facebook, including patents with no connection to React whatsoever.

The Apache Software Foundation declared the BSD+Patents licence a Category X licence, meaning it could not be included in any Apache project, on the basis that it passed patent risk downstream to licensees in a manner imbalanced in favour of the licensor. WordPress announced it would stop using React. The developer community across Reddit, Hacker News, and freeCodeCamp began evaluating React alternatives. Under sustained pressure, Facebook relicensed React under MIT in September 2017.

The episode illustrates a risk that most development teams never consider: that adopting a popular, seemingly open-source library can place your entire patent portfolio at risk, or at the least raise serious questions and potential consequences that are best avoided. The BSD+Patents clause was not hidden. It was in a PATENTS file in the repository. But almost nobody read it and considered the consequences.

Apache 2.0: safe to use, dangerous to contribute to

Apache 2.0 is the licence of choice for much of the modern open-source ecosystem. React (post-2017), Android, Kubernetes, TensorFlow, and thousands of other foundational projects. It is broadly compatible with commercial use and, for most purposes, is exactly what it appears to be: a permissive licence with a clear patent grant.

The patent grant is the important part. Each contributor grants users a perpetual, worldwide, royalty-free, irrevocable licence under any patents necessarily infringed by their contribution. This is a feature when you are using Apache 2.0 software, you receive a patent licence from every contributor. When this becomes important is when you are basing your commercial proposition and competitive advantage upon maintaining the exclusive boundary of your patent rights. You are potentially defenceless When you are contributing code that practices your own patented invention, because that grant runs to every user of the project, permanently and without compensation.

Apache 2.0 also carries a patent retaliation clause: if any user initiates patent litigation alleging the Apache 2.0 software infringes a patent, their licence to the project terminates. GPL v3 carries a substantially similar provision.

The practical rule: Apache 2.0 is safe to use. Contributing to an Apache 2.0 project, particularly code that touches a patentable area of your technology, requires a patent clearance review first.

Copyleft licences: the source code disclosure problem

GPL, LGPL, and AGPL licences create a separate but related hazard: mandatory source code disclosure. For businesses with patented inventions, being required to disclose the implementation is damaging even when the patent specification is already published, because it hands competitors both the legal map and the working code.

GPL v2 and v3 require that any software you distribute incorporating GPL code must itself be distributed under the GPL, including source code. If your patented method is implemented in software incorporating GPL components, distributing that software may require disclosing the very implementation that embodies the invention. It also eliminates trade secret protection over any implementation detail not covered by the patent claims.

The AGPL tightens this further. GPL obligations are triggered by distribution. A business running GPL software on its servers to deliver a SaaS product, without distributing the software, has successfully argued that source disclosure is not required. The AGPL removes that argument entirely: if you use AGPL-licensed software to provide a network service, you must make the corresponding source code available to users of that service. For SaaS and cloud-native businesses, AGPL components carry a broader and higher risk than GPL alone , a point the Elastic/AWS conflict over Elasticsearch made very publicly in 2021.

The LGPL provides a limited exception for libraries: commercial software can dynamically link to an LGPL library without triggering source disclosure, provided the end user can replace the library. Static linking can be sufficient to trigger the full copyleft obligation.

The dependency problem: package.json is signing licence agreements for you

Here is where it gets genuinely dangerous for modern development teams. A typical Node.js project with a handful of direct dependencies will, after npm install, have hundreds or even thousands of packages in node_modules. Each one carries its own licence. Most developers have no idea what those licences say.

The issue is transitive dependencies: libraries that your libraries depend on, which their libraries depend on, recursively. A developer adds a utility package under MIT. That package has a dependency under Apache 2.0, which has a sub-dependency under LGPL. None of this is visible from the package.json. The licence exposure is buried three levels down in the dependency graph.

This is not theoretical. A project can have a clean top-level dependency list and still be running GPL-adjacent code in production without anyone on the team being aware of it. A licence change in an upstream dependency. And it happens, including popular packages switching from MIT to AGPL. The issue propagates downstream to every project that depends on it, instantly and silently.

The mitigation is licence scanning, embedded in the CI/CD pipeline rather than run as a one-off audit. Several well-maintained tools on GitHub make this practical.

ScanCode Toolkit (aboutcode-org/scancode-toolkit) detects licences, copyrights, package manifests, and direct dependencies in both source code and binary files. It uses full text comparison against a licence database rather than pattern matching, and is used by the Eclipse Foundation, Red Hat, and the FSF among others. It integrates with GitHub Actions via automated-license-check.

license-checker-rseidelsohn (RSeidelsohn/license-checker-rseidelsohn) is the most widely used tool for Node.js projects specifically, and the actively maintained fork of the original license-checker package. It walks the entire node_modules dependency tree using npm's arborist module, reads every package.json, and identifies licences via SPDX identifiers or by parsing LICENSE, LICENCE, COPYING, and README files. It supports --failOn flags for specific licences, making it straightforward to block GPL or AGPL dependencies at the CI gate:

npx license-checker-rseidelsohn --failOn "GPL;AGPL"

FOSSology (fossology/fossology) provides a more comprehensive compliance workflow including a web UI, database, and support for generating SPDX files and copyright notices. It is suited to teams that need a formal compliance record rather than just a CI gate.

The goal is to make licence compliance a continuous automated check rather than a pre-launch scramble. A --failOn GPL flag in your pull request workflow costs nothing to add and can prevent the kind of licence contamination that surfaces — expensively — during due diligence.

What to do about it

Three steps reduce the risk materially.

Conduct a full licence audit of your dependency tree before any capital raise, product launch, or M&A transaction. Undisclosed licence non-compliance is a material IP risk that sophisticated acquirers will surface, and it is far easier to resolve before a deal is on the table than during one.

Architect the codebase to separate proprietary innovations from copyleft-licensed components. A modular structure that isolates inventive elements from GPL or AGPL dependencies reduces the risk that a licence obligation extends to the patented implementation. This is sound engineering practice as well as IP risk management.

Establish a contribution governance policy. If your development team contributes to open-source projects, a light policy governing what can be contributed and under what conditions prevents inadvertent patent licences being granted through Apache 2.0 or GPL v3 contributions. Contributions that touch patentable areas of the technology should require IP clearance before they go upstream.