Open-Source Patent Risks

GPL creates two types of patent exposure: copyleft and explicit patent license provisions: GPL VERSION 2 (v2) COPYLEFT: when you distribute a product that 'links' or 'combines' GPL v2 code with proprietary code, the GPL v2 may require you to distribute the ENTIRE combined work under GPL v2; this is the 'copyleft' or 'viral' effect; CONSEQUENCE: proprietary source code that was combined with GPL v2 code may need to be made publicly available; once source code is public, competitors can use it; this is not technically a patent issue but is often the primary business risk; GPL v2 AND PATENTS (IMPLICIT): GPL v2 includes an implicit patent non-assertion provision: if a company distributes GPL v2 code and CANNOT grant the patent rights the GPL v2 requires (e.g., because the company is under a license that restricts sublicensing of patent rights), the company CANNOT distribute the GPL v2 code at all; this creates a problem for companies that receive a restricted patent license and then want to distribute GPL v2 software; GPL VERSION 3 (v3) EXPLICIT PATENT PROVISIONS: GPL v3 contains far more explicit patent provisions: TIVOIZATION FIX: an 'installation information' requirement designed to prevent hardware restrictions that prevent users from running modified versions; PATENT GRANT: each contributor grants an explicit, worldwide, royalty-free, non-exclusive patent license under the contributor's essential patent claims in the software; PATENT NON-AGGRESSION: if you distribute GPL v3 code, you must not enter into any arrangement that prevents third parties from exercising their GPL v3 rights; RETALIATION CLAUSE: if you bring a patent infringement lawsuit against ANYONE (not just GPL violators) asserting any patent claim that is necessary to practice the GPL v3 software, all of your patent licenses from other contributors to the GPL v3 project automatically TERMINATE; THIS IS VERY BROAD: a patent suit against a third party that is unrelated to the GPL v3 software could terminate all your rights to use the GPL v3 software if any of the asserted patents happen to be necessary to practice the GPL v3 software; LGPL (LESSER GPL): similar copyleft provisions but limited to the LGPL library itself (dynamically linked; not the whole application); AGPL (AFFERO GPL): extends copyleft to software-as-a-service (cloud computing loophole closed); if you run AGPL software as a service, you must make your source code available to users.

Apache 2.0 is the most enterprise-friendly major open-source license partly because of its explicit patent provisions: SECTION 3 OF APACHE LICENSE 2.0 — THE PATENT GRANT: 'Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted'; WHAT THIS MEANS: each person who contributes code to an Apache 2.0-licensed project automatically grants all downstream users a patent license covering the contributor's patents that are necessarily infringed by that specific contribution; this is an express patent grant that runs with the software to all downstream users; THE DEFENSIVE TERMINATION CLAUSE (SECTION 3): 'If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed'; YOU LOSE YOUR APACHE LICENSE if you sue ANYONE for infringing patents that are necessarily part of the Apache 2.0 licensed work; SCOPE OF TERMINATION: ONLY the specific Apache 2.0 project you sued about; your rights under other Apache 2.0 projects are not affected; COMPARED TO GPL v3: GPL v3 retaliation clause is broader (any patent suit against anyone that involves the GPL v3 software); Apache 2.0 is narrower (only suits alleging the specific Apache work infringes); PATENT AGGRESSION STRATEGY CONFLICT: companies that assert patents aggressively must audit their Apache 2.0 dependencies to avoid losing the right to use critical infrastructure software when they bring patent suits; KUBERNETES, LINUX, ANDROID: major platform software (Apache HTTP, Hadoop, Spark, Kubernetes components) uses Apache 2.0; enterprise reliance on these platforms creates risk for companies with aggressive patent programs.

Permissive licenses are largely silent on patents, which creates both risk and opportunity: MIT LICENSE AND PATENTS: the MIT license does NOT include an express patent grant; the license grants permission to 'use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software' but these rights are copyright rights only; there is NO express grant of patent rights; IMPLICATION FOR USERS: using MIT-licensed code that happens to be covered by a contributor's patent does NOT give you a patent license; you may still infringe the contributor's patents even if you have a valid MIT license; this is sometimes called the 'patent gap' in permissive licenses; BSD LICENSE (2-CLAUSE, 3-CLAUSE): same as MIT on patent silence; BSD licenses grant copyright permissions only; no express patent grant; ISC LICENSE: same as MIT; no express patent grant; BOOST LICENSE: no express patent grant; COMPARISON TABLE: Express patent grant: Apache 2.0 (YES); GPL v3 (YES); MIT (NO); BSD (NO); ISC (NO); Defensive termination: Apache 2.0 (YES — specific project); GPL v3 (YES — broad); MIT (N/A); BSD (N/A); Copyleft: Apache 2.0 (NO); GPL v3 (YES — strong); MIT (NO); BSD (NO); PRACTICAL IMPACT: for companies using MIT/BSD code: the lack of express patent grant means you are relying on implied patent license (legal theory that argues the licensor implicitly grants patent rights needed to exercise the copyright rights) — this theory has not been fully tested in court; the safer approach is to assume that MIT/BSD code may be covered by patents you have no license to; for small contributions, the risk is typically low; for core infrastructure (crypto libraries; codecs; compression), the risk is higher; RECOMMENDATION: audit high-value MIT/BSD dependencies for potential patent exposure; identify the main contributors and check their patent portfolios; consider whether a formal patent license or covenant-not-to-sue from key contributors is needed.

The OIN is the world's largest patent non-aggression community for open-source software: WHAT IS THE OIN: the Open Invention Network (OIN) is a non-profit company founded in 2005 by IBM, Sony, Phillips, Red Hat, NEC, and Novell; OIN owns a large patent portfolio and licenses it royalty-free to members; in exchange, members agree to a non-aggression covenant with all other OIN members and licensees; WHO IS A MEMBER: any company can join OIN by signing the OIN license agreement (royalty-free; perpetual); current members include Google, IBM, Microsoft, Red Hat, Toyota, Amazon, Samsung, Intel, and thousands of others (3,500+ licensees as of 2024); WHY JOIN OIN: you receive royalty-free access to OIN's portfolio of patents that cover Linux and the Linux system; you receive protection from patent aggression by other OIN members; you signal to the open-source community that you are a good actor; WHY NOT JOIN OIN: joining requires you to commit not to assert your OWN patents against any OIN member or licensee for use within the 'Linux System' definition; the 'Linux System' definition is broad — it covers Linux, plus many common open-source applications (Android; OpenStack; GNU tools); joining is an IRREVOCABLE commitment; SCOPE OF THE NON-AGGRESSION COMMITMENT: you agree not to assert claims on your own patents against any OIN licensee for any claims that are 'NECESSARY CLAIMS' for implementing the Linux System definition; the Linux System definition is updated periodically to include new open-source projects; OIN AND M&A: if you acquire a company that is NOT an OIN member, you inherit their patent portfolio; those patents are NOT subject to the OIN commitment UNLESS you choose to make them subject to it; many M&A transactions involving patent portfolios carefully analyze whether a seller was an OIN member and whether that restricts the portfolio; OIN AND PATENT ASSERTIONS: OIN membership significantly restricts your ability to bring patent suits against other OIN members in the Linux space; companies with aggressive patent programs should carefully analyze OIN membership before joining.

Managing open-source patent risk requires both legal and engineering processes: OPEN-SOURCE POLICY AND GOVERNANCE: INTAKE REVIEW: before incorporating any open-source component, classify the license type (permissive; weak copyleft; strong copyleft); approve based on company policy; typical policies: GREEN (Apache 2.0; MIT; BSD; ISC — approved for most uses); YELLOW (LGPL; MPL — require review); RED (GPL v2; GPL v3; AGPL — restricted use); SOFTWARE COMPOSITION ANALYSIS (SCA): use SCA tools to scan all code for open-source components and their licenses; tools: Black Duck (Synopsys); FOSSA; WhiteSource (Mend); Snyk; these tools identify open-source license types across the entire codebase; DUAL-LICENSING AWARENESS: many open-source projects offer both an open-source license and a commercial license; for GPL-licensed components, commercial licenses are often available that: (a) do not require copyleft propagation; (b) may include patent grants; evaluating commercial alternatives is often the right solution for core infrastructure components; PATENT RISK FROM CONTRIBUTIONS: if your company contributes code to an Apache 2.0 project, you have granted a patent license under Section 3; audit what patents your company holds that might be 'necessarily infringed' by contributions your engineers make to Apache 2.0 projects; many companies have contribution policies that require IP team review before employees contribute; PATENT TERMINATION TRIGGERS IN APACHE 2.0: if your company brings a patent suit alleging an Apache 2.0 project infringes your patents, you lose your license to use that project; audit which Apache 2.0 projects are in your production stack before bringing patent suits; OPEN-SOURCE DUE DILIGENCE IN M&A: standard IP due diligence for technology acquisitions includes: SCA scan of target's codebase; identify GPL-contaminated code that may need to be rewritten; identify obligations created by contributions to Apache 2.0 projects; identify OIN membership and related commitments; GPL CONTAMINATION REMEDIATION: if GPL code was improperly incorporated into proprietary code, options include: rewrite the GPL component; license a commercial version; seek a retroactive GPL exception from the copyright holder; change the architecture to meet LGPL dynamic linking rules.