**Author:** [[3. Resources/Authors/Heather Meeker|Heather Meeker]] # Open Source for Business ![[Open Source for Business Visual.excalidraw]] --- ## Book Overview ### About the Author **Heather Meeker** is one of the world's leading attorneys in open source software licensing. With over 25 years of experience in technology law, she has advised countless companies on open source compliance, licensing strategy, and software transactions. She is a partner at O'Melveny & Myers LLP specializing in technology transactions and licensing. Meeker is also a prolific author and speaker on open source legal issues, and she drafted the original Fair Source License and has been involved in creating several other software licenses. She's known for her practical, business-focused approach to open source legal issues. ### Central Thesis Open source software licensing represents the most significant development in software licensing since licensing itself began. However, contrary to common misconceptions, "free" in free software refers to freedom (libre), not price (gratis). The open source model is fundamentally a licensing model that enables a collaborative development model - and understanding both is essential for businesses. The book argues that open source compliance is not about achieving perfection but about risk management. The key principle is ensuring that your "inbound rights" (licenses granted to you) are equal to or greater than your "outbound rights" (rights you exercise or grant to others). When you use more rights than you have, you're infringing on someone else's intellectual property. For businesses, the challenge is navigating between two extremes: the anti-business rhetoric of early free software advocates and the fear-based "just say no" approach of many lawyers. The book provides a practical middle path, showing how companies can use open source software responsibly while managing legal risks. Understanding the nuances between different license types - particularly the difference between permissive licenses (like MIT, BSD, Apache) and copyleft licenses (like GPL) - is essential for any technology business. ### Why This Book Matters This is the definitive practical guide to open source licensing for legal professionals, engineers, and business people. As Meeker notes, "software has eaten the world, and open source has eaten software." No technology business can afford to ignore open source - it's the backbone of e-commerce, cloud computing, and modern software development. Yet the legal landscape remains complex, with limited case law and many unanswered questions. The third edition (2020) is particularly valuable because it covers recent developments including: - Commercial open source business models - Source-available licensing (as distinct from true open source) - The rise of "ethos licensing" and ethical source movements - Updates to major enforcement cases - Modern compliance tooling and practices --- ## Part Summaries ### Part I: Foundation #### Chapter 1: The Philosophy of Free and Open Source Software The chapter traces the philosophical divide between "free software" (Richard Stallman's FSF camp) and "open source" (the OSI camp). Stallman's copyleft philosophy uses copyright law to compel sharing - using the power of a system he finds morally objectionable to undermine that very system. The Open Source Initiative was created to reconcile free software advocates with business interests. Key insight: "Free" means freedom, not price. Free software licenses don't prohibit selling software - that's actually more the domain of proprietary vendors with educational licenses. The LAMP stack (Linux, Apache, MySQL, PHP) is free infrastructure precisely because its users make money selling goods over the web, not selling access to the web itself. The chapter distinguishes between the **licensing model** (the legal terms) and the **development model** (the collaborative process). Eric Raymond's "Cathedral and the Bazaar" analogy captures this: proprietary development is like building a cathedral (centralized, controlled, limited by resources), while open source is like a bazaar (decentralized, market-driven, collaborative). #### Chapter 2: A Tutorial on Computer Software A technical primer covering: - **Source code vs. object code**: Source is human-readable; object code is compiled binary - **Compilation and linking**: How software is built from source to executable - **Static vs. dynamic linking**: Critical distinction for GPL compliance - **Libraries and dependencies**: Understanding software supply chains - **Copyright in software**: What's protectable and what isn't This chapter establishes the technical foundation necessary to understand licensing questions. The distinction between static and dynamic linking becomes crucial in later chapters on GPL compliance. ### Part II: Basic Open Source Theory and Compliance #### Chapter 3: Common Open Source Licenses The chapter surveys major license families: **Permissive Licenses:** - **MIT License**: Minimal conditions, essentially "do what you want, keep the copyright notice" - **BSD Licenses**: Similar to MIT, various versions (2-clause, 3-clause, 4-clause) - **Apache 2.0**: Adds patent grants and trademark restrictions **Copyleft Licenses:** - **GPL 2.0**: The original copyleft license, requires source distribution with binaries - **GPL 3.0**: Adds patent provisions, anti-Tivoization, addresses modern concerns - **LGPL**: Lesser GPL, allows proprietary linking under specific conditions - **AGPL**: Affero GPL, triggers on network use (not just distribution) - **MPL 2.0**: File-level copyleft, more permissive than GPL **Creative Commons**: Designed for content, not software - the NC (non-commercial) variants are NOT open source. #### Chapter 4: License Compatibility License compatibility is about whether you can combine code under different licenses. The key principle: your outbound license must be compatible with all inbound licenses. Major compatibility issues: - **GPL is "viral"**: Code combined with GPL must also be GPL-licensed - **Apache 2.0 vs GPL 2.0**: One-way compatible (Apache into GPL, not reverse) - **Multiple copyleft licenses**: Generally incompatible with each other The chapter introduces the concept of "diligence" - ensuring inbound rights >= outbound rights. #### Chapter 5: Conditional Licensing Copyleft licenses are "conditional" - the broad license grant is contingent on meeting certain conditions. Fail to meet the conditions, and you lose your license rights, potentially making your use copyright infringement. Key conditions across licenses: - Attribution/notice requirements - Source code availability - Copyleft propagation (for derivative works) - Patent peace provisions #### Chapter 6: What Is Distribution? "Distribution" is the trigger for many open source license obligations. The chapter examines: - **Traditional distribution**: Shipping software to users - **SaaS and cloud services**: Generally NOT distribution (except under AGPL) - **Internal use**: Usually not distribution - **Contractor relationships**: Complex - may or may not be distribution - **OEM/bundling relationships**: Typically is distribution Understanding what constitutes distribution is critical because copyleft obligations typically only trigger upon distribution. #### Chapter 7: Notice Requirements Most open source licenses require preserving copyright notices and license texts. This chapter covers: - Attribution requirements - License notice inclusion - NOTICE files (Apache 2.0) - README and documentation requirements - Practical compliance for different distribution models ### Part III: Advanced Compliance #### Chapter 8: The GPL 2 Border Dispute The "border" refers to the boundary between GPL-licensed code and proprietary code. The core question: when does combining code with GPL code create a "derivative work" requiring the combined code to be GPL-licensed? Key concepts: - **Static linking**: Almost always creates derivative work - **Dynamic linking**: Disputed - the famous "gray area" - **Separate programs**: Can interact with GPL code without infection - **The kernel module debate**: Linux kernel modules as test case The FSF takes expansive views; industry practice is often more permissive. #### Chapter 9: LGPL 2.1 Compliance The "Lesser" GPL allows proprietary programs to link against LGPL libraries while remaining proprietary, under specific conditions: - Must allow re-linking (user must be able to swap in modified library) - Must provide object code or source for the proprietary portions - Complex technical requirements around linking #### Chapter 10: GPL 3 and Affero GPL 3 GPL 3 addressed several issues: - **Patent provisions**: Explicit patent license grant - **Anti-Tivoization**: Prohibits hardware restrictions on software modification - **DRM provisions**: Disclaims anti-circumvention claims - **Compatibility improvements**: Better compatibility with other licenses AGPL 3 adds the "network copyleft" - if you run modified AGPL software as a network service, users must be able to get the source code. #### Chapter 11: Open Source Policies Companies need formal policies covering: - **Inbound policies**: What licenses can be used, approval processes - **Outbound policies**: What licenses to release under, contribution policies - **Training**: Developer education on open source obligations - **Tooling**: Software composition analysis, license scanning The chapter emphasizes policy should be practical and risk-based, not fear-based. #### Chapter 12: Audits and Due Diligence Due diligence is critical in M&A, financing, and customer relationships. The process: 1. **Identify open source**: Bill of materials, scanning tools 2. **Classify by license**: Understand obligations for each 3. **Assess compliance**: Are you meeting all conditions? 4. **Remediate issues**: Fix problems in priority order 5. **Document**: Create compliance records Key principle: "Diligence is not about perfection; it is about risk management." ### Part IV: Intersection with Patents and Trademarks #### Chapter 13: Open Source and Patents Many open source licenses include patent provisions: - **Express grants**: Apache 2.0, GPL 3.0 grant patent licenses - **Defensive termination**: Patent aggression against the project terminates your license - **Implied licenses**: Even without express terms, use may imply patent license The chapter covers patent pledges, standards-essential patents, and open source patent litigation. #### Chapter 14: Open Source and Patent Litigation Strategy Strategic considerations when patents intersect with open source: - Defensive patent portfolios - Patent pools and pledges - Litigation involving open source components - Indemnification and insurance #### Chapter 15: Trademarks Trademarks in open source are often overlooked but important: - Project names and logos may be trademarked separately from code - Forking a project usually requires rebranding - Trademark policies in major projects (Linux, Firefox, etc.) - Community trademark management ### Part V: Contributions and Code Releases #### Chapter 16: Open Source Releases When releasing code as open source: - **License selection**: Match business model and community expectations - **Contributor agreements**: CLAs, DCOs, and alternatives - **Governance models**: Foundation, BDFL, corporate-backed - **Inbound contributions**: Ensuring clean IP chain - **Trademark strategy**: Protecting project identity ### Part VI: Additional Topics #### Chapter 17: Mergers & Acquisitions and Other Transactions Open source due diligence in transactions: - Identifying open source in target's products - Assessing compliance posture - License obligations that transfer with assets - Representations and warranties - Post-acquisition remediation #### Chapter 18: Government Regulation Special considerations for government procurement: - FAR clauses and open source compatibility - Data rights under government contracts - Security and export control issues - Open source mandates in some jurisdictions #### Chapter 19: Enforcement and Obstacles to Enforcement Survey of enforcement actions: - **GPL enforcement history**: BusyBox cases, Software Freedom Conservancy - **The Principles of Community-Oriented GPL Enforcement** - **Commercial enforcement vs. community enforcement** - **Defenses and obstacles**: Standing, damages, injunctive relief Key case discussions including Jacobsen v. Katzer, Artifex v. Hancom, and others. #### Chapter 20: Open Standards and Open Source The intersection of standards bodies and open source: - FRAND (Fair, Reasonable, and Non-Discriminatory) licensing - Royalty-free standards - Patent pledges in standards contexts - When open standards require open source implementations #### Chapter 21: Open Hardware and Data Beyond software: - Open hardware licenses (CERN OHL, TAPR OHL) - Open data licensing - Creative Commons for non-software content - Challenges specific to hardware (patents, masks, etc.) #### Chapter 22: Recent Developments Modern trends (as of 2020): - **Commercial open source**: Open core, dual licensing, services models - **Source-available licensing**: Licenses that provide source access but don't meet OSI definition - **Ethos licensing**: Ethical source, Hippocratic License, attempts to restrict harmful use - **License proliferation and simplification efforts** --- ## Key Themes and Highlights ### The Fundamental Principle: Inbound >= Outbound The core concept for open source compliance: > "From an overarching point of view, diligence is the process of making sure your inbound rights are equal to or greater than your outbound rights." If you grant or use more rights than you have been granted, you're infringing. ### Risk Management, Not Perfection > "The diligence process is not about perfection; it is about risk management. There is no such thing as perfect compliance; the software landscape, even for a simple product or business, is too complicated for that." Compliance is about triaging problems and making reasoned decisions, not achieving an impossible ideal. ### The Development Model Creates the Value > "The open source development model is actually what creates the value of open source software. The licenses do not; they are merely vehicles to enable the development model." Understanding this distinction is crucial - licenses are means to an end. ### Free as in Freedom > "The word 'free' in 'free software' refers to freedom, not price—it is libre, not gratis. As the Free Software Foundation (FSF) says, 'Think free speech, not free beer.'" This common misconception still trips up many newcomers to open source. ### The Cathedral and the Bazaar The chapter references Eric Raymond's influential essay comparing development models: - **Cathedral**: Centralized, controlled, limited by resources - **Bazaar**: Decentralized, market-driven, collaborative --- ## Analytical Reading ### Main Arguments 1. **Open source is now unavoidable** - Any technology business must understand and work with open source software. 2. **The licensing model enables the development model** - Licenses are tools to enable collaboration, not ends in themselves. 3. **Compliance is risk management** - Perfect compliance is impossible; the goal is managing risk through reasonable processes. 4. **Understanding triggers is essential** - Knowing when obligations trigger (distribution, modification, linking) is key to compliance. 5. **Different licenses serve different purposes** - Permissive vs. copyleft represents fundamentally different philosophies and use cases. 6. **Policy and process matter** - Companies need systematic approaches, not ad-hoc decisions. ### Methodology Meeker builds her analysis through: - Historical context (UNIX, Linux, the free software movement) - Technical foundations (how software is built and distributed) - Legal analysis (copyright, licensing, case law) - Practical guidance (policies, processes, checklists) - Case studies and real-world examples ### Strengths - **Authoritative**: Written by a leading practitioner with decades of experience - **Practical**: Focused on real-world compliance, not just theory - **Comprehensive**: Covers the full landscape from basics to advanced topics - **Current**: Third edition addresses modern developments (cloud, SaaS, commercial open source) - **Accessible**: Explains technical and legal concepts for non-specialists ### Limitations - **US-centric**: Primarily focused on US law and practice - **Rapidly evolving field**: Some details may become outdated - **Dense material**: Can be challenging for complete beginners - **Limited treatment of some topics**: International issues, specific industry contexts --- ## Personal Reflection ### Key Takeaways 1. **The inbound/outbound framework** is a powerful mental model for thinking about license compliance. 2. **Distribution is the key trigger** for most copyleft obligations - understanding what constitutes distribution is essential. 3. **Linking and combination** questions remain unresolved gray areas - the industry operates on convention as much as settled law. 4. **Policy and process** are as important as understanding individual licenses - systematize your approach. 5. **Risk management, not perfection** - focus on the highest-risk issues first and work through them systematically. ### Questions Raised - How will cloud-native development change distribution analysis? - What is the future of copyleft in the age of SaaS? - How should companies think about source-available vs. true open source? - What's the appropriate balance between community norms and legal enforceability? ### Connections to Other Works - **"The Cathedral and the Bazaar" by Eric Raymond** - The foundational essay on open source development models - **"Working in Public" by Nadia Eghbal** - Modern perspective on open source maintainer economics - **"Producing Open Source Software" by Karl Fogel** - Practical guide to running open source projects - **"Open Sources: Voices from the Revolution"** - Historical perspectives from key figures - **"The Success of Open Source" by Steven Weber** - Academic analysis of the open source phenomenon --- ## Reading Notes Read in January 2026 as preparation for: - Understanding open source licensing for developer relations work - Advising organizations on open source policy - Contributing to open source projects with proper understanding of legal frameworks - Evaluating open source business models and sustainability Particularly relevant sections for frequent reference: - Chapter 3 (Common Open Source Licenses) - License taxonomy - Chapter 4 (License Compatibility) - Combination analysis - Chapter 6 (What Is Distribution?) - Trigger analysis - Chapter 11 (Open Source Policies) - Policy frameworks - Chapter 12 (Audits and Due Diligence) - Compliance processes