IP Strategy
Open Source IP Strategy
GPL copyleft contamination risk, Apache 2.0 patent retaliation, Open Invention Network non-aggression, and how MongoDB, Elastic, and HashiCorp protect commercial open source IP.
FAQ
What is copyleft contamination risk, and how does GPL affect commercial software products?
Copyleft contamination (also called the 'viral' effect of copyleft licenses) is the most significant open source IP risk for commercial software companies, and understanding it requires distinguishing between different GPL license variants and how your software interacts with GPL code: WHAT COPYLEFT MEANS: copyleft licenses require that any software that incorporates or links with copyleft-licensed code must also be released under the same license when distributed; the copyleft 'infects' the combined work; GPL v2 COPYLEFT SCOPE: GPLv2 (Linux kernel; many major open source projects) requires that any 'work based on the program' or 'derived work' distributed in binary form must also be distributed under GPLv2 with complete corresponding source code; CRITICAL QUESTION — WHAT CONSTITUTES A DERIVED WORK: pure aggregation (separate programs on a disk): NOT copyleft trigger; running GPL binary as separate process: NOT copyleft trigger; DYNAMIC LINKING to GPL library: GRAY AREA — Free Software Foundation argues it triggers copyleft; industry practice is more lenient; depends on whether the programs form a single combined work; STATIC LINKING to GPL library: GENERALLY triggers copyleft — the linked binary contains GPL code; LGPL (LESSER GPL) — DESIGNED FOR LIBRARIES: LGPL explicitly allows applications to dynamically link to LGPL libraries without triggering copyleft on the application; modifications TO the LGPL library itself must be released as LGPL; LGPL v2.1 vs. LGPL v3: LGPL v2.1 only requires dynamic linking for library use exception; LGPL v3 closes some loopholes; HOW GPL v3 DIFFERS: GPLv3 adds patent retaliation clause (if you distribute GPLv3 software and sue for patent infringement, your rights under GPLv3 terminate); GPLv3 anti-tivoization (cannot distribute GPLv3 on hardware that prevents users from running modified versions — relevant for IoT/embedded); some companies refuse to use GPLv3 code specifically because of these clauses; AGPL v3 — NETWORK COPYLEFT: closes the 'SaaS loophole'; if you run AGPL software to provide a service over a network, you must provide the source code to network users; used by MongoDB (until 2018); Affero/Elastic (until Amazon hosting dispute); PRACTICAL RISK ASSESSMENT: conduct an open source license audit; identify all GPL/LGPL/AGPL dependencies in your build system; determine link type (static vs. dynamic) for each GPL/LGPL dependency; assess whether any AGPL dependencies could require disclosure if you offer SaaS; resolve high-risk dependencies before fundraising or acquisition (buyers run OSLA audits).
How does the Apache 2.0 patent grant and patent retaliation clause work?
The Apache License 2.0 is widely considered the most enterprise-friendly open source license for patent risk management, because it explicitly addresses both the grant of patent rights and the consequences of asserting patents against Apache-licensed software: APACHE 2.0 PATENT GRANT (Section 3): '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'; SCOPE OF THE GRANT: applies to patents that are 'necessarily infringed' by the contributor's contribution alone or in combination with the Work; this means: contributors who submit code automatically grant a patent license to all users for any patents that are essential to practicing the contribution; this addresses the concern that an open source contributor might contribute code that practices their patents and then later assert those patents against users of the open source project; SIGNIFICANCE FOR ENTERPRISE USERS: a company using Apache 2.0 software gets an explicit patent license from every contributor to the project; this provides more IP clarity than MIT/BSD licenses which are silent on patents; APACHE 2.0 PATENT RETALIATION 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'; IN PLAIN ENGLISH: if you use Apache 2.0 software AND then sue ANYONE (not just the Apache Foundation) claiming that Apache 2.0 software infringes your patent, you automatically lose your Apache 2.0 patent license; result: you can no longer legally use the Apache 2.0 software without a patent license from each individual contributor; STRATEGIC IMPLICATIONS: companies with large patent portfolios must carefully consider whether they want to assert patents that could be argued to read on Apache 2.0 software; loss of Apache 2.0 patent license could mean inability to use major software (Kubernetes; Android; most Apache Foundation projects; many Linux Foundation projects); COMPARISONS WITH OTHER LICENSES: MIT/BSD: no explicit patent grant; no patent retaliation; patent ambiguity; GPL v3: patent retaliation only for GPLv3 violations; broader non-aggression principles; LLVM Exception: specific exception allowing LLVM compiler components in proprietary tools; MOZILLA PUBLIC LICENSE (MPL 2.0): file-level copyleft + Apache-style patent retaliation; OIN (Open Invention Network): broadest patent non-aggression — member companies grant royalty-free patent license for Linux System as defined.
What is the Open Invention Network, and how do large companies use patent pledges around open source?
The Open Invention Network (OIN) is the world's largest patent non-aggression community in history, specifically designed to protect the Linux ecosystem from patent assertions by creating a mutually assured defense framework: OPEN INVENTION NETWORK OVERVIEW: founded in 2005 by IBM; Novell; Philips; Red Hat; Sony; co-funded by NEC and others; mission: protect Linux and the broader open source ecosystem from patent threats; STRUCTURE: each OIN member: grants a royalty-free; patent license to all other members for any patents that read on the 'Linux System' (OIN's defined scope of protected open source software); commits not to assert their patents against the Linux System; in exchange: receives the same non-aggression from all other members; MEMBERSHIP: currently 3,500+ members including IBM; Google; Red Hat; Novell; Sony; Toyota; NEC; HP; Intel; Cisco; Qualcomm; Samsung; and notably MICROSOFT (joined October 2018, the same day as Nadella-era OIN endorsement); KEY CONCEPT — LINUX SYSTEM: OIN's protected scope is not limited to the Linux kernel alone; 'Linux System' is defined by OIN to include a broad range of open source software packages (a detailed list maintained at openinventionnetwork.com) including: the Linux kernel; major GNU utilities; Systemd; GNOME; KDE; Apache HTTP server; MySQL/MariaDB; Python; Perl; PHP; and many others; OIN periodically updates the Linux System definition to add new packages; MICROSOFT'S 2018 OIN MEMBERSHIP: Microsoft's OIN membership was a significant signal in the relationship between Microsoft and open source; Microsoft joined OIN during the period when Nadella was actively repositioning Microsoft as 'open source friendly'; coverage: Microsoft's 60,000+ patent portfolio is now subject to OIN non-aggression within the Linux System scope; NOT covered: Microsoft's OIN membership doesn't cover all open source; just OIN's Linux System definition; CORPORATE PATENT PLEDGES (BEYOND OIN): GOOGLE: Open Patent Non-Assertion Pledge (OPNAP) covering certain standards-essential patents; TESLA (2014): Elon Musk announced Tesla would not sue anyone using Tesla's technology 'in good faith' — a non-binding voluntary pledge; IBM: open source patent promise for software implemented on open source (limited scope); Red Hat: Red Hat patent pledge (not to assert Red Hat patents against open source implementations of open source specifications); PRACTICAL RELEVANCE FOR COMPANIES: membership in OIN is free for most companies; large companies with patent portfolios should evaluate OIN membership as part of open source strategy; startups should evaluate whether competitors are OIN members when assessing FTO against open source-based technologies.
How do commercial open source companies like MongoDB and Elastic protect IP while maintaining open source communities?
The relationship between open source and commercial IP strategy has become one of the most important strategic questions in software business models, following a series of high-profile disputes when cloud providers began offering managed services of open source software: THE FUNDAMENTAL COMMERCIAL OPEN SOURCE IP CHALLENGE: a company publishes open source code → builds a commercial business on top → large cloud provider (AWS; Azure; Google Cloud) offers a managed version of the open source software as a paid service → cloud provider captures significant revenue without contributing code or paying the open source company → open source company loses revenue; STRATEGIC RESPONSES: OPEN CORE MODEL: publish most functionality as open source (under MIT or Apache 2.0); withhold enterprise features as closed-source proprietary software; enterprise features: enterprise SSO/SAML; role-based access control; advanced audit logging; multi-region high availability; compliance features (SOC 2; HIPAA; FedRAMP); IP strategy: patent the enterprise features; trademark the product names; examples: GitLab (community edition MIT + enterprise edition proprietary); HashiCorp Vault/Terraform (MPL 2.0 + enterprise proprietary add-ons until BSL change 2023); DUAL LICENSING: same code licensed under open source + commercial license; users choose: GPL version (free; must open source your changes) or commercial license (proprietary; no copyleft obligation); MySQL (GPL + Oracle commercial); Qt (GPL + Digia/Qt Group commercial); MariaDB (GPL + BSL); CLOUD-HOSTILE LICENSE CHANGES: SERVER SIDE PUBLIC LICENSE (SSPL) — MONGODB 2018: SSPL adds: if you offer MongoDB as a service (cloud-hosted), you must open source ALL software and services that make up that service offering; AWS declined to comply; MongoDB changed from AGPL to SSPL; Amazon launched DocumentDB (MongoDB-compatible but rewritten); BUSINESS SOURCE LICENSE (BSL/BUSL) — HASHICORP 2023: Terraform; Vault; Consul; Boundary; Nomad changed from MPL 2.0 to BSL 1.1; BSL: source is viewable but commercial USE restricted for 4 years after each version; converts to Mozilla Public License after 4 years; prevents cloud providers from hosting without contributing; OpenTofu fork launched (LF-governed; MPL 2.0); ELASTIC LICENSE (ELv2): Elasticsearch + Kibana changed from Apache 2.0 to Elastic License 2.0; ELv2 prohibits: providing ELv2 software as a managed service; using ELv2 to circumvent Elastic's commercial terms; Amazon forked to OpenSearch (Apache 2.0); TRADEMARK STRATEGY (IMPORTANT IP TOOL): trademark is often more durable than license restrictions; register product name as trademark; enforce against cloud providers using the name without license; MongoDB Inc. owns 'MongoDB' trademark; can prevent cloud providers from advertising 'MongoDB-compatible service' using the exact name; HashiCorp owns 'Terraform' trademark — used against OpenTofu initially (later resolved); PATENT STRATEGY FOR COMMERCIAL OPEN SOURCE: patent novel aspects of the enterprise product features; patent the distributed systems algorithms that make the product scale; do not patent the core open source components that would alienate community contributors; use trade secrets for implementation details not disclosed in code.
Related Guides