Open Source Licensing for Startups: MIT, GPL, Apache & Compliance (2025)

Open source software powers the modern startup ecosystem—but using or releasing open source code comes with legal obligations. Open source licenses are copyright licenses that grant broad permissions while imposing specific conditions. Misunderstanding these conditions can expose your startup to compliance violations, forced code disclosure, and legal liability.

Why open source licensing matters:

  • Compliance risks: GPL/AGPL violations can force you to open-source your proprietary code
  • License compatibility: Combining incompatible licenses can create legal conflicts
  • Business model implications: Your choice of license affects how you monetize your software
  • Investor diligence: VCs audit your open source dependencies and licensing compliance
  • Corporate policies: Many enterprises ban AGPL and strong copyleft dependencies

Two main categories of open source licenses:

  1. Permissive licenses (MIT, Apache 2.0, BSD): Minimal restrictions, allow commercial use and proprietary modifications
  2. Copyleft licenses (GPL, LGPL, AGPL): Require derivative works to maintain the same license and disclose source code

This guide covers:

  • Permissive vs copyleft licenses
  • MIT, Apache 2.0, BSD (permissive)
  • GPL v2/v3, LGPL, AGPL (copyleft)
  • License compatibility and compliance
  • Choosing the right license for your project
  • Contributor License Agreements (CLA) vs Developer Certificate of Origin (DCO)
  • Open source business models (dual licensing, open core, SaaS)
  • Using open source dependencies in your startup

What is Open Source Software?

Open source software is software whose source code is publicly available and licensed under terms that allow anyone to use, modify, and distribute the software.

Open Source Initiative (OSI) Definition

The Open Source Initiative defines open source through 10 criteria:

  1. Free redistribution: No restriction on selling or giving away the software
  2. Source code: Must be included or readily available
  3. Derived works: Must allow modifications and derived works under the same license
  4. Integrity of author's source code: May require modified versions to carry different names
  5. No discrimination against persons or groups
  6. No discrimination against fields of endeavor: Can't restrict commercial use
  7. Distribution of license: Rights apply to all recipients without additional agreements
  8. License must not be specific to a product: Rights not dependent on being part of a particular distribution
  9. License must not restrict other software: Can't require all distributed software to be open source
  10. License must be technology-neutral: No provisions predicated on specific technologies

Copyright vs License

Key distinction:

  • Copyright: The legal right that protects creative works (including software code)
  • License: Permission granted by the copyright holder to use the work under specified conditions

Open source licenses are copyright licenses that grant broad permissions (use, modify, distribute) while imposing conditions (attribution, license propagation, source disclosure).

Without a license, copyright law applies by default:

  • All rights reserved to the copyright holder
  • No one else can use, copy, modify, or distribute the code
  • Including code without a license in your project = copyright infringement

Open Source vs Source-Available vs Proprietary

Type Source Code Available? OSI-Approved License? Example Licenses
Open source Yes Yes MIT, Apache 2.0, GPL v3
Source-available Yes No (restrictions on use) Business Source License (BSL), Elastic License 2.0, Server Side Public License (SSPL)
Proprietary No No Microsoft Windows, Adobe Photoshop

Source-available licenses (like BSL, SSPL) allow source code inspection but impose restrictions that make them non-OSI-compliant (e.g., prohibiting commercial hosting).

Permissive Licenses Overview

Permissive licenses (also called "BSD-style" or "Apache-style") impose minimal restrictions on how software can be used, modified, and distributed.

Key Characteristics

What permissive licenses allow:

  • ✅ Commercial use
  • ✅ Modification and creation of derivative works
  • ✅ Distribution in binary form without source code
  • ✅ Incorporation into proprietary software
  • ✅ Sublicensing under different terms

What permissive licenses require:

  • ✅ Copyright notice and license text in source distributions
  • ✅ Attribution to original authors
  • ❌ No requirement to disclose source code
  • ❌ No requirement to license derivatives under the same license

Most Popular Permissive Licenses

  1. MIT License: Most popular, shortest, fewest restrictions
  2. Apache License 2.0: Includes patent grant and trademark protection
  3. BSD 2-Clause: Similar to MIT, slightly more formal
  4. BSD 3-Clause: Adds non-endorsement clause

When to Use Permissive Licenses

Use permissive licenses when:

  • You want maximum adoption and contribution
  • You're building libraries, frameworks, or developer tools
  • You want to allow commercial use without restrictions
  • You're not concerned about proprietary forks
  • You want corporate-friendly licensing

Example projects using permissive licenses:

  • React (MIT): Facebook's JavaScript library
  • Kubernetes (Apache 2.0): Container orchestration
  • Ruby on Rails (MIT): Web application framework
  • Node.js (MIT): JavaScript runtime

MIT License

The MIT License is the most popular open source license, known for its simplicity and minimal restrictions.

Full MIT License Text

MIT License

Copyright (c) [year] [fullname]

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

MIT License Key Provisions

Permissions granted:

  • Commercial use
  • Modification
  • Distribution
  • Private use

Conditions:

  • Include copyright notice and license text
  • Include license notice in all copies or substantial portions

Limitations:

  • No liability
  • No warranty

MIT License Advantages

✅ Shortest and simplest major open source license ✅ Maximum compatibility with other licenses (including GPL) ✅ Corporate-friendly: No compliance concerns for enterprises ✅ No patent grant: Simpler than Apache 2.0 (but less protective) ✅ High adoption: Used by majority of JavaScript/Node.js ecosystem

MIT License Disadvantages

❌ No patent grant: Doesn't explicitly grant patent rights ❌ No trademark protection: Doesn't prevent trademark confusion ❌ Minimal attribution: Only requires notice in source distributions, not binaries ❌ Allows proprietary forks: Companies can take your code proprietary

When to Use MIT License

Best for:

  • JavaScript libraries and frameworks
  • Developer tools and utilities
  • Projects prioritizing ease of adoption
  • When you're indifferent to proprietary forks

Used by:

  • React, Angular, Vue.js (JavaScript frameworks)
  • Ruby on Rails (web framework)
  • Node.js (JavaScript runtime)
  • jQuery (JavaScript library)

Apache License 2.0

The Apache License 2.0 is a permissive license that includes an explicit patent grant and trademark protection.

Apache 2.0 Key Provisions

Permissions granted:

  • Commercial use
  • Modification
  • Distribution
  • Patent use (explicit grant)
  • Private use

Conditions:

  • Include copyright notice and license text
  • State changes made to the code
  • Include NOTICE file (if present)
  • Preserve all copyright, patent, trademark, and attribution notices

Limitations:

  • No liability
  • No warranty
  • No trademark rights (explicitly excluded)

Apache 2.0 vs MIT: Key Differences

Feature MIT License Apache License 2.0
Length ~200 words ~9,000 words
Patent grant Implicit only Explicit patent grant
Patent retaliation No Yes (license terminates if you sue for patent infringement)
Trademark protection No Yes (explicitly excludes trademark rights)
Change documentation No requirement Must state modifications
NOTICE file No Must preserve if present
GPL compatibility GPL v3 (yes), GPL v2 (no) GPL v3 (yes), GPL v2 (no)

Apache 2.0 Patent Grant

Section 3 of Apache 2.0:

"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..."

Patent retaliation clause: If you sue any contributor for patent infringement related to the work, your patent license terminates automatically.

Why this matters:

  • Defensive protection: Prevents patent trolls from using Apache-licensed code then suing over patents
  • Corporate safety: Enterprises prefer explicit patent grants (reduces litigation risk)
  • Contributor protection: Contributors don't have to worry about patent claims from users

When to Use Apache License 2.0

Best for:

  • Projects with patent-sensitive technology
  • Enterprise and infrastructure software
  • Projects seeking corporate contributions
  • When you want stronger legal protection than MIT

Used by:

  • Kubernetes (container orchestration)
  • Hadoop (big data framework)
  • Kafka (streaming platform)
  • TensorFlow (machine learning)
  • Android OS (Google)

BSD Licenses (2-Clause and 3-Clause)

The BSD licenses (Berkeley Software Distribution) are permissive licenses similar to MIT, with slightly different attribution requirements.

BSD 2-Clause License ("Simplified BSD")

Key provisions:

  • Redistribution allowed in source and binary forms
  • Copyright notice and disclaimer required
  • No endorsement implied

Conditions:

  1. Redistributions of source code must retain copyright notice, list of conditions, and disclaimer
  2. Redistributions in binary form must reproduce the above in documentation

Differences from MIT:

  • More explicit about source vs binary distributions
  • Slightly more formal language
  • Functionally equivalent to MIT

BSD 3-Clause License ("Modified BSD")

Adds a third condition:

"Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."

Why the non-endorsement clause matters:

  • Prevents derivative works from implying official endorsement
  • Protects the original author's reputation
  • Common in university-developed software

When to Use BSD Licenses

Best for:

  • Academic and research projects
  • When you want permissive licensing with formal attribution
  • Projects prioritizing trademark/reputation protection (3-Clause)

Used by:

  • FreeBSD, OpenBSD, NetBSD (operating systems)
  • nginx (web server)
  • Many university-developed projects

Copyleft Licenses Overview

Copyleft licenses (also called "viral" or "reciprocal") require that derivative works be licensed under the same terms and source code be disclosed.

Key Characteristics

What copyleft licenses require:

  • ✅ Derivative works must use the same license
  • ✅ Source code must be disclosed when distributing
  • ✅ Copyright notice and license text must be included
  • ✅ Changes must be documented
  • ❌ Cannot be incorporated into proprietary software (in most cases)

What copyleft licenses allow:

  • ✅ Commercial use (you can sell copyleft software)
  • ✅ Modification
  • ✅ Distribution (with source disclosure)
  • ✅ Private use (no distribution = no obligation)

Strong vs Weak Copyleft

Type Scope Examples When Triggered
Strong copyleft Entire combined work GPL v2, GPL v3, AGPL Any derivative work or combination
Weak copyleft Only the licensed component LGPL, MPL Only modifications to the component itself

Copyleft Philosophy: Software Freedom

Richard Stallman and the Free Software Foundation created copyleft to ensure:

  1. Freedom to use: Software can be run for any purpose
  2. Freedom to study: Source code must be available
  3. Freedom to modify: Users can adapt software to their needs
  4. Freedom to distribute: Modified versions can be shared

Copyleft prevents "closed-source capture":

  • MIT/BSD code can be taken proprietary (e.g., Apple's use of BSD Unix)
  • GPL code remains free forever (derivatives must also be GPL)

When to Use Copyleft Licenses

Use copyleft licenses when:

  • You want to ensure modifications remain open source
  • You're building community-driven software
  • You want to prevent proprietary competitors from free-riding
  • You're pursuing a dual licensing business model
  • You support the free software philosophy

Example projects using copyleft:

  • Linux kernel (GPL v2): Operating system kernel
  • WordPress (GPL v2): Content management system
  • MySQL (GPL v2 + commercial): Database (dual licensed)
  • MongoDB (AGPL + commercial): Database (dual licensed)

GNU GPL v2 and v3

The GNU General Public License (GPL) is the most popular strong copyleft license, ensuring derivative works remain open source.

GPL v2 vs GPL v3

Feature GPL v2 GPL v3
Release date 1991 2007
Patent grant Implicit Explicit
Tivoization Allowed Prohibited
License compatibility Less compatible More compatible (Apache 2.0)
Termination Automatic (permanent) Automatic (curable within 60 days)
DRM/anti-circumvention Not addressed Addressed (DMCA exemption)

GPL Key Obligations

When you distribute GPL software (modified or unmodified), you must:

  1. Provide complete source code

    • Include all source code needed to build the software
    • Provide build scripts, configuration files, and dependencies
    • Make available for at least 3 years (or as long as you distribute binaries)

  2. License derivatives under GPL

    • Any modifications must be GPL
    • Combined works must be GPL (strong copyleft)
    • Cannot add additional restrictions

  3. Preserve copyright notices

    • Include all copyright notices
    • Include GPL license text
    • Document changes made

  4. Provide installation information (GPL v3 only)

    • For "User Products," must provide information necessary to install modified versions
    • Prevents "Tivoization" (hardware that rejects modified software)

What Triggers GPL Obligations?

Distribution triggers obligations:

  • ✅ Internal use: No obligation (can use GPL software internally without releasing source)
  • ✅ Modification without distribution: No obligation
  • ❌ Distribution (binary or source): Must provide source code under GPL
  • ❌ Offering as a service: No obligation for GPL (but AGPL triggers)

Example: GPL compliance violation:

  • Company incorporates GPL library into proprietary product
  • Distributes product to customers without providing source code
  • Copyright holder (or FSF) sends cease-and-desist
  • Company must either: (1) open-source entire product, or (2) stop distribution

GPL Patent Grant (GPL v3)

Section 11 of GPL v3:

"Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version."

Patent retaliation: If you sue anyone for patent infringement related to GPL v3 software, your patent license terminates.

GPL and Proprietary Software: The Boundary

Can you use GPL software with proprietary software?

General rule: GPL requires the "entire work" to be GPL if it's a "derivative work" or "combined work."

Safe scenarios:

  • ✅ Separate programs: GPL and proprietary programs communicating via APIs, pipes, or sockets (generally safe)
  • ✅ Plugins: Proprietary plugins to GPL software (gray area, depends on coupling)
  • ✅ System libraries exception: Can link to GPL software using standard system libraries

Risky scenarios:

  • ❌ Static linking: Compiling GPL code into proprietary binary (clearly derivative)
  • ❌ Dynamic linking: Linking proprietary code to GPL libraries (FSF view: derivative; legal gray area)
  • ❌ Modification: Modifying GPL software and distributing (clearly derivative)

LGPL solves the linking problem (see next section).

When to Use GPL

Best for:

  • Operating systems and system software (Linux kernel is GPL v2)
  • Community-driven projects prioritizing freedom over adoption
  • Dual licensing business models (GPL + commercial)
  • When you want to prevent proprietary competitors

Used by:

  • Linux kernel (GPL v2)
  • WordPress (GPL v2)
  • MySQL (GPL v2 + commercial)
  • GIMP (GPL v3)
  • Git (GPL v2)

GNU LGPL (Lesser GPL)

The GNU Lesser General Public License (LGPL) is a weak copyleft license designed for libraries.

LGPL vs GPL: Key Difference

GPL:

  • Any software that links to GPL library must be GPL
  • Strong copyleft applies to combined work

LGPL:

  • Software can link to LGPL library without being LGPL
  • Weak copyleft applies only to the library itself
  • Modifications to the LGPL library must remain LGPL

LGPL Key Provisions

What LGPL requires:

  1. Modifications to the library must be LGPL

    • If you modify LGPL library code, modifications must be LGPL
    • Must provide source code for your modifications

  2. Applications using the library can be proprietary

    • Dynamically linking to LGPL library: proprietary application OK
    • Statically linking to LGPL library: must allow relinking with modified library version

  3. Source code availability

    • Must provide source for the LGPL library (and modifications)
    • No requirement to provide source for applications using the library

LGPL Use Cases

Why LGPL was created:

  • Encourage adoption of free software libraries
  • Compete with proprietary libraries (e.g., Qt with LGPL option)
  • Allow proprietary software to use free software components

When to use LGPL:

  • You're creating a library and want wide adoption
  • You want to ensure library improvements remain open source
  • You're okay with proprietary applications using your library

Used by:

  • Qt (LGPL v3 + commercial): Cross-platform application framework
  • glibc (LGPL v2.1): GNU C Library
  • FFmpeg (LGPL v2.1): Multimedia framework
  • GStreamer (LGPL v2.1): Multimedia framework

GNU AGPL (Affero GPL)

The GNU Affero General Public License (AGPL) is GPL with an additional condition: network use triggers source disclosure.

AGPL vs GPL: The Network Use Loophole

GPL loophole:

  • GPL requires source disclosure when you distribute software
  • Offering software as a service (SaaS) is not distribution
  • Example: Google can modify GPL software, run it on servers, and never release source code

AGPL closes the loophole:

  • AGPL requires source disclosure when users interact with the software over a network
  • SaaS providers must provide source code to users

AGPL Key Provisions

Section 13 of AGPL v3:

"If you run a modified version of the Program on a server and let other users communicate with it there, your server must also offer those users an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge..."

What this means:

  • Deploy modified AGPL software as a SaaS → must provide source code
  • Internal use (employees only) → no obligation
  • Distribute AGPL software → same obligations as GPL

Why Startups Avoid AGPL

Corporate aversion to AGPL:

  • Many enterprises ban AGPL dependencies entirely
  • Concerns about "accidental" source disclosure obligations
  • Legal uncertainty about what constitutes "network interaction"

Example: MongoDB SSPL controversy:

  • MongoDB was originally AGPL (dual licensed with commercial)
  • 2018: MongoDB switched from AGPL to Server Side Public License (SSPL)
  • SSPL requires SaaS providers to open-source their entire infrastructure
  • OSI rejected SSPL as not open source (too restrictive)
  • Result: MongoDB is now source-available, not open source

AGPL and Dual Licensing

AGPL is ideal for dual licensing business models:

  • Offer AGPL version for free (community/personal use)
  • Offer commercial license for enterprises and SaaS providers
  • AGPL compliance burden drives customers to commercial license

Example: Dual licensed AGPL projects:

  • MongoDB (was AGPL + commercial, now SSPL + commercial)
  • iText (PDF library): AGPL + commercial
  • SugarCRM: AGPL + commercial

When to Use AGPL

Best for:

  • SaaS products you want to prevent cloud providers from hosting
  • Dual licensing business models
  • Network services prioritizing software freedom

Avoid AGPL if:

  • You want maximum adoption (especially enterprise)
  • You're building libraries or developer tools
  • You want your software used in proprietary SaaS products

Used by:

  • MongoDB (until 2018, now SSPL)
  • Mastodon (decentralized social network)
  • OnlyOffice (office suite)

License Comparison: Permissive vs Copyleft

Comprehensive License Comparison Table

Feature MIT Apache 2.0 BSD 3-Clause GPL v3 LGPL v3 AGPL v3
Type Permissive Permissive Permissive Strong copyleft Weak copyleft Strong copyleft
Commercial use ✅ ✅ ✅ ✅ ✅ ✅
Modification ✅ ✅ ✅ ✅ ✅ ✅
Distribution ✅ ✅ ✅ ✅ (with source) ✅ (with source) ✅ (with source)
Private use ✅ ✅ ✅ ✅ ✅ ✅
Patent grant ❌ ✅ Explicit ❌ ✅ Explicit ✅ Explicit ✅ Explicit
Trademark ❌ ✅ Protected ✅ 3-Clause ❌ ❌ ❌
Source disclosure ❌ ❌ ❌ ✅ Required ✅ (library only) ✅ Required
License propagation ❌ ❌ ❌ ✅ Required Partial ✅ Required
SaaS trigger ❌ ❌ ❌ ❌ ❌ ✅ Yes
Corporate-friendly ✅ High ✅ High ✅ High ❌ Low ⚠️ Medium ❌ Very low
GPL compatible ✅ Yes ✅ v3 only ✅ Yes ✅ Yes ✅ Yes ✅ Yes

Choosing the Right License for Your Project

Decision Framework

Consider these factors:

  1. Business model

    • SaaS/commercial product → Permissive or dual licensing (AGPL + commercial)
    • Community project → GPL or permissive
    • Library/framework → Permissive or LGPL

  2. Adoption priority

    • Maximum adoption → MIT or Apache 2.0
    • Quality contributions > quantity → GPL or AGPL
    • Enterprise adoption → Apache 2.0 (avoid AGPL)

  3. Protection from proprietary forks

    • Prevent proprietary competitors → GPL or AGPL
    • Don't care about forks → MIT or BSD

  4. Patent concerns

    • Patent-sensitive technology → Apache 2.0 or GPL v3
    • No patent concerns → MIT

  5. Philosophy

    • Software freedom → GPL or AGPL
    • Pragmatic adoption → Permissive

License Selection by Project Type

Project Type Recommended License Rationale
JavaScript library MIT Maximum adoption, ecosystem standard
Web framework MIT or Apache 2.0 Corporate-friendly, wide adoption
Developer tools MIT or Apache 2.0 Ease of use, no compliance burden
System software GPL v2 or v3 Ensure improvements remain open
Library (linking) LGPL or Apache 2.0 Allow proprietary use, compete with closed libraries
SaaS product AGPL (+ commercial) Dual licensing business model
Database AGPL or Apache 2.0 AGPL for dual licensing, Apache for adoption
Operating system GPL v2 Standard for OS kernels (Linux model)
Mobile app Apache 2.0 or MIT Corporate-friendly, patent protection

Dual Licensing Strategy

What is dual licensing?

  • Offer software under two licenses: copyleft (GPL/AGPL) + commercial
  • Users choose: free copyleft version with obligations, or paid commercial version without

Example: MongoDB (historical, pre-SSPL):

  • Community Edition: AGPL (free, must open-source modifications if deployed as SaaS)
  • Enterprise Edition: Commercial license (paid, no source disclosure)

When to dual license:

  • You're building infrastructure or database software
  • Primary customers are businesses (who'll pay to avoid AGPL)
  • You can provide commercial support and enterprise features

Open Source Compliance and Risk Management

GPL/AGPL Compliance Requirements

To comply with GPL/AGPL when distributing:

  1. Provide complete corresponding source code

    • All source files needed to build the software
    • Build scripts, configuration files, and installation instructions
    • Available for at least 3 years after distribution

  2. Include license text and notices

    • Full GPL/AGPL license text
    • All copyright notices
    • Attribution notices

  3. Document modifications

    • State changes made to the software
    • Include modification dates

  4. For AGPL: Provide source via network

    • If running modified AGPL software as a service, provide source download link
    • Must be "at no charge" and accessible

Common Compliance Violations

1. Distributing GPL software without source code

  • Scenario: Company ships product with GPL library, provides binaries only
  • Violation: Failed to provide corresponding source code
  • Remedy: Provide source immediately, or stop distribution

2. Adding restrictions to GPL software

  • Scenario: Company distributes modified GPL software with additional EULA restrictions
  • Violation: GPL prohibits additional restrictions
  • Remedy: Remove additional restrictions

3. Combining GPL and incompatible licenses

  • Scenario: Product combines GPL v2 code with Apache 2.0 code
  • Violation: GPL v2 and Apache 2.0 are incompatible
  • Remedy: Use GPL v3 (compatible with Apache 2.0), or separate the components

4. AGPL SaaS without source disclosure

  • Scenario: SaaS provider modifies AGPL software, deploys as service, doesn't provide source
  • Violation: AGPL requires source disclosure for network use
  • Remedy: Provide source download link, or obtain commercial license

Consequences of License Violations

1. Copyright infringement

  • No valid license = copyright infringement
  • Copyright holder can sue for damages

2. Injunctive relief

  • Court order to stop distribution immediately
  • Can shut down product sales

3. GPL compliance enforcement

  • Free Software Foundation (FSF) and Software Freedom Conservancy (SFC) enforce GPL
  • Typically seek compliance rather than damages
  • Process: cease-and-desist → negotiations → compliance or litigation

4. Reputational damage

  • Public shaming in open source community
  • Loss of developer trust

5. M&A deal-breakers

  • Acquirers conduct open source audits
  • License violations can kill acquisitions or reduce valuation

Corporate Open Source Policies

Many enterprises have policies banning:

  • ❌ AGPL (any version)
  • ❌ GPL v3 (some companies, due to patent and DRM provisions)
  • ⚠️ GPL v2 (requires legal review)
  • ✅ LGPL (usually allowed for dynamic linking)
  • ✅ Permissive licenses (MIT, Apache, BSD)

Why this matters for startups:

  • Enterprise customers may refuse to use your software if it depends on AGPL
  • Due diligence for acquisition will flag copyleft dependencies
  • Build your dependency list with corporate customers in mind

License Compatibility and Combining Licenses

What is License Compatibility?

License compatibility determines whether software under different licenses can be legally combined.

Two licenses are compatible if:

  • Obligations of both licenses can be satisfied simultaneously
  • No conflicts between license terms

GPL Compatibility

GPL-compatible licenses can be combined with GPL code (result is GPL):

  • ✅ MIT
  • ✅ BSD (2-Clause, 3-Clause)
  • ✅ Apache 2.0 (GPL v3 only, not GPL v2)
  • ✅ LGPL (can upgrade to GPL)
  • ✅ AGPL (can combine with GPL v3)

GPL-incompatible licenses cannot be combined with GPL:

  • ❌ Apache 2.0 (GPL v2 incompatible due to patent clause)
  • ❌ Original BSD 4-Clause (advertising clause)
  • ❌ Proprietary licenses

License Compatibility Matrix

Combine with → MIT Apache 2.0 GPL v2 GPL v3 LGPL AGPL
MIT ✅ MIT ✅ Apache ✅ GPL v2 ✅ GPL v3 ✅ LGPL ✅ AGPL
Apache 2.0 ✅ Apache ✅ Apache ❌ ✅ GPL v3 ✅ LGPL ✅ AGPL
GPL v2 ✅ GPL v2 ❌ ✅ GPL v2 ❌ ✅ GPL v2 ❌
GPL v3 ✅ GPL v3 ✅ GPL v3 ❌ ✅ GPL v3 ✅ GPL v3 ✅ GPL v3
LGPL ✅ LGPL ✅ LGPL ✅ GPL v2 ✅ GPL v3 ✅ LGPL ✅ AGPL
AGPL ✅ AGPL ✅ AGPL ❌ ✅ GPL v3 ✅ AGPL ✅ AGPL

Result license is the most restrictive (e.g., MIT + GPL v3 = GPL v3).

Practical Compatibility Scenarios

Scenario 1: Building a web application

  • Using MIT libraries (React, Express) ✅
  • Using Apache 2.0 libraries (Kubernetes client) ✅
  • Result: Can license application as MIT, Apache, or proprietary

Scenario 2: Building with GPL library

  • Using MIT libraries ✅
  • Using one GPL v3 library ⚠️
  • Result: Entire application must be GPL v3 (if distributed)

Scenario 3: GPL v2 + Apache 2.0

  • GPL v2 project wants to use Apache 2.0 library ❌
  • GPL v2 and Apache 2.0 are incompatible
  • Solutions: Upgrade to GPL v3, or avoid Apache 2.0 library

Contributor Management: CLA vs DCO

When accepting contributions to your open source project, you need a mechanism to ensure contributors have the right to contribute and you have the right to distribute.

Contributor License Agreement (CLA)

What is a CLA? A legal agreement signed by contributors that:

  • Grants the project maintainer license to use the contribution
  • May assign copyright to the maintainer (assignment CLA)
  • Confirms contributor has rights to contribute
  • May grant patent license

Example: Apache CLA:

  • Contributor grants copyright license to Apache Software Foundation
  • Contributor grants patent license
  • Contributor represents they have right to contribute

CLA types:

  1. Individual CLA (ICLA): Signed by individual contributor
  2. Corporate CLA (CCLA): Signed by employer on behalf of employees

Advantages of CLAs: ✅ Legal protection for project maintainer ✅ Clear chain of copyright (important for relicensing) ✅ Patent protection ✅ Can enable dual licensing

Disadvantages of CLAs: ❌ Friction for contributors (must sign before contributing) ❌ Perceived as corporate-friendly, community-hostile ❌ Can reduce contribution volume ❌ Requires infrastructure to manage (DocuSign, etc.)

Developer Certificate of Origin (DCO)

What is DCO? A lightweight alternative to CLAs where contributors certify they have the right to contribute by adding a "Signed-off-by" line to commits.

DCO text:

Developer Certificate of Origin Version 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

How DCO works:

  • Contributor adds Signed-off-by: Name <email> to commit message
  • Git commit flag: git commit -s automatically adds sign-off
  • Automated tools (like DCO bot) enforce DCO on pull requests

Advantages of DCO: ✅ Minimal friction (one command) ✅ Community-friendly (used by Linux kernel) ✅ No separate signature required ✅ Clear audit trail (part of Git history)

Disadvantages of DCO: ❌ Less legal protection than CLA ❌ Doesn't grant patent license explicitly ❌ Doesn't enable easy relicensing ❌ May not satisfy corporate legal departments

CLA vs DCO: Which to Choose?

Factor CLA DCO
Legal protection High Medium
Contributor friction High (must sign) Low (one flag)
Patent protection Explicit Implicit
Community perception Corporate Community-friendly
Relicensing Possible Difficult
Used by Apache, Google, Facebook Linux, GitLab, Node.js

Recommendation:

  • DCO: For community-driven projects prioritizing contributions (most open source projects)
  • CLA: For dual licensing business models or when relicensing flexibility is needed (commercial open source)

Open Source Business Models

1. Dual Licensing

Model:

  • Offer software under copyleft license (GPL/AGPL) for free
  • Offer commercial license for fee (proprietary use without copyleft obligations)

How it works:

  • Community/individuals use free copyleft version
  • Enterprises/SaaS providers pay for commercial license to avoid source disclosure

Requirements:

  • Copyright ownership of all code (requires CLAs from contributors)
  • Strong copyleft license (AGPL most effective for SaaS era)

Examples:

  • MySQL: GPL v2 + commercial (Oracle)
  • Qt: LGPL v3 + commercial (The Qt Company)
  • MongoDB (historical): AGPL + commercial

Pros: ✅ Direct monetization of open source software ✅ AGPL compliance burden drives commercial license sales ✅ Sustainable funding for development

Cons: ❌ Requires copyright assignment (CLAs reduce contributions) ❌ AGPL limits adoption ❌ Tension between community and commercial interests

2. Open Core

Model:

  • Core product is open source (permissive or copyleft)
  • Enterprise features are proprietary (paid)

How it works:

  • Community edition: Free, open source, basic features
  • Enterprise edition: Paid, proprietary, advanced features (HA, security, management, support)

Examples:

  • GitLab: MIT core + proprietary enterprise features
  • Elastic (historical): Apache 2.0 core + proprietary features (before Elastic License 2.0)
  • Confluent: Apache Kafka (open source) + proprietary enterprise features

Pros: ✅ Permissive license encourages adoption ✅ Clear value proposition (free vs paid) ✅ Large community on free version

Cons: ❌ Community may fork and add enterprise features ❌ Tension over which features stay open ❌ Competitors can offer managed services of open core

3. SaaS/Managed Services

Model:

  • Software is open source (any license)
  • Revenue from hosting, managing, and supporting the software

How it works:

  • Users can self-host for free
  • Many prefer to pay for managed service (convenience, support, SLA)

Examples:

  • Red Hat: Enterprise Linux (GPL) + subscriptions for support and managed services
  • Automattic: WordPress (GPL) + WordPress.com hosting
  • Elastic (historical): Elasticsearch (Apache 2.0) + Elastic Cloud managed service

Pros: ✅ Works with any license (including permissive) ✅ Sustainable recurring revenue ✅ Strong incentive to keep software open (community contributions improve product)

Cons: ❌ Cloud providers can compete (AWS, Google, Azure) ❌ Requires operational expertise ❌ Difficult to prevent free-riding by cloud providers

Note: AGPL provides some protection against cloud provider competition (forces them to open-source modifications or obtain commercial license).

4. Support and Consulting

Model:

  • Software is free and open source
  • Revenue from training, consulting, customization, and support contracts

How it works:

  • Large enterprises pay for support contracts
  • Consulting on implementation, customization, integration

Examples:

  • Red Hat: Support subscriptions for RHEL
  • Canonical: Ubuntu support and consulting
  • Percona: MySQL support and consulting

Pros: ✅ Works with any license ✅ Direct monetization of expertise ✅ Builds long-term customer relationships

Cons: ❌ Doesn't scale (time-based revenue) ❌ Competitors can offer same support ❌ Requires large customer base

5. Open Source + Proprietary Extensions

Model:

  • Core is open source
  • Proprietary add-ons, plugins, or integrations sold separately

Examples:

  • Sidekiq: MIT open source background job processor + paid Pro and Enterprise versions
  • Sentry: BSD open source error tracking + proprietary SaaS and enterprise features

Using Open Source Dependencies in Your Startup

Open Source Dependency Audit

Before using any open source dependency:

  1. Identify the license

    • Check LICENSE file in repository
    • Use tools: npm ls, pip-licenses, cargo license

  2. Assess compatibility

    • Is the license compatible with your product's license?
    • If GPL/AGPL: Can you comply with source disclosure?

  3. Check for corporate policies

    • Does your target customer base ban AGPL?
    • Will this dependency block enterprise sales?

  4. Evaluate legal risk

    • Is the project well-maintained?
    • Are there patent concerns?
    • Any known license violations?

Open Source Auditing Tools

Automated tools for dependency license scanning:

  1. FOSSA (https://fossa.com)

    • Commercial tool for license compliance
    • Scans dependencies and flags compliance issues
    • Integrates with CI/CD

  2. Black Duck (Synopsis)

    • Enterprise open source security and license compliance
    • M&A due diligence tool

  3. WhiteSource (Mend)

    • Open source security and license compliance
    • Real-time alerts for new vulnerabilities

  4. FOSSology (Linux Foundation)

    • Open source license compliance tool
    • Scans source code for license information

  5. npm-license-checker (npm)

    • Command-line tool: npm install -g license-checker
    • Lists all dependency licenses

  6. pip-licenses (Python)

    • Command-line tool: pip install pip-licenses
    • Lists all dependency licenses

Best Practices for Using Open Source

  1. Maintain a Software Bill of Materials (SBOM)

    • List all open source dependencies
    • Track licenses, versions, and sources

  2. Automate license scanning in CI/CD

    • Fail builds if incompatible licenses detected
    • Alert on AGPL or GPL additions

  3. Establish open source policy

    • Define allowed licenses (e.g., MIT, Apache 2.0, BSD)
    • Define restricted licenses (e.g., AGPL, GPL)
    • Require legal review for copyleft

  4. Review dependencies regularly

    • Update SBOM quarterly
    • Check for new license changes (rare but happens)

  5. Contribute back to projects you use

    • Bug fixes and improvements benefit community
    • Builds goodwill and reputation

Common Open Source Mistakes

1. Using GPL/AGPL Without Understanding Obligations

Mistake:

  • Startup incorporates GPL library into SaaS product
  • Doesn't realize AGPL triggers source disclosure for network use
  • Customer audit reveals violation

Solution:

  • Audit all dependencies before use
  • Ban GPL/AGPL unless explicitly approved
  • Use permissive licenses (MIT, Apache 2.0) for maximum safety

2. Releasing Open Source Without Choosing a License

Mistake:

  • Developer publishes code on GitHub without LICENSE file
  • Community assumes they can use it
  • Actually: all rights reserved by default (copyright law)

Solution:

  • Always include LICENSE file
  • Use GitHub's license chooser or https://choosealicense.com
  • Add license badge to README

3. Dual Licensing Without Copyright Assignment

Mistake:

  • Company wants to dual license (GPL + commercial)
  • Accepted contributions without CLA
  • Cannot offer commercial license (don't own all copyright)

Solution:

  • Implement CLA from day one if planning dual licensing
  • Retroactively getting CLAs is painful (may need to remove contributions)

4. Combining Incompatible Licenses

Mistake:

  • Project combines GPL v2 code with Apache 2.0 code
  • Licenses are incompatible
  • Distribution violates both licenses

Solution:

  • Check license compatibility before combining code
  • Use GPL v3 (compatible with Apache 2.0)
  • Keep components separate if licenses incompatible

5. Ignoring AGPL in Dependencies

Mistake:

  • Startup uses AGPL library in SaaS product
  • Raises Series A
  • Investor diligence flags AGPL dependency
  • Must rewrite application to remove AGPL code

Solution:

  • Ban AGPL in dependency policy
  • Automated scanning in CI/CD
  • Regular SBOM audits

6. Not Providing License Notices

Mistake:

  • Company distributes product using MIT libraries
  • Doesn't include license text or attribution
  • Violates MIT license (requires notice)

Solution:

  • Include LICENSE or NOTICES file in distributions
  • List all open source dependencies and licenses
  • Automate generation of NOTICES file

7. Misunderstanding "Linking" and Derivatives

Mistake:

  • Company dynamically links to GPL library
  • Thinks GPL doesn't apply because "not modifying GPL code"
  • FSF's position: linking creates derivative work

Solution:

  • Avoid GPL libraries if distributing proprietary software
  • Use LGPL or permissive alternatives
  • Consult lawyer if GPL linking is unavoidable

8. Relicensing Without Contributor Permission

Mistake:

  • Project starts as MIT, wants to change to GPL
  • Project has many contributors (no CLA)
  • Cannot relicense without permission from all contributors

Solution:

  • Choose license carefully at project start (relicensing is hard)
  • Use CLA if you anticipate relicensing needs
  • Outbound license compatibility: Choose license that allows upgrading (e.g., GPL v2 "or later")

Best Practices for Open Source Licensing

For Releasing Open Source Software

  1. Choose license at project start

    • Consider business model, adoption goals, and philosophy
    • Default: MIT or Apache 2.0 (maximum adoption)
    • Copyleft: GPL v3 or AGPL (ensure freedom)

  2. Include LICENSE file

    • Full license text in root directory
    • Name file LICENSE or LICENSE.txt
    • Add SPDX identifier to source files: SPDX-License-Identifier: MIT

  3. Add copyright notices

    • Copyright line in LICENSE file: Copyright (c) 2025 Company Name
    • Copyright header in source files (especially for copyleft)

  4. Create CONTRIBUTING.md

    • Explain how to contribute
    • Specify CLA or DCO requirements
    • Include DCO text if using DCO

  5. Implement CLA or DCO

    • DCO: Add DCO bot to GitHub repo
    • CLA: Use CLA Assistant (https://cla-assistant.io)
    • Document requirement in CONTRIBUTING.md

  6. Add license badge to README

    [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)

For Using Open Source Software

  1. Establish open source policy

    • Define approved licenses (MIT, Apache 2.0, BSD)
    • Define restricted licenses (AGPL, GPL)
    • Require legal review for copyleft

  2. Automate license scanning

    • Integrate FOSSA, WhiteSource, or open source tools in CI/CD
    • Fail builds on policy violations

  3. Maintain Software Bill of Materials (SBOM)

    • List all dependencies, versions, and licenses
    • Update quarterly or on major releases

  4. Review licenses before adding dependencies

    • Check LICENSE file in repository
    • Verify compatibility with your product's license

  5. Comply with attribution requirements

    • Include license notices in distributions
    • Generate NOTICES file (automate with tools)

  6. Contribute back

    • Submit bug fixes upstream
    • Document your customizations
    • Support projects you depend on (financially or with contributions)

For Startups Considering Open Source

  1. Open source is not a free marketing strategy

    • Requires community management, documentation, and support
    • Consider time and resources needed

  2. Open source early or late, not in between

    • Open source from day one: Maximum community, harder to monetize
    • Open source after product-market fit: Harder to build community, clearer business model

  3. Choose business model first, license second

    • Dual licensing → AGPL + CLA
    • Open core → Permissive (MIT, Apache) for core
    • SaaS → Permissive or AGPL (depending on cloud provider strategy)

  4. Consider enterprise customer policies

    • AGPL = dealbreaker for many enterprises
    • GPL may require legal review
    • Permissive licenses have no adoption barriers

Frequently Asked Questions

General Open Source Questions

Q: Can I use open source software in my commercial product?

A: Yes. All major open source licenses (MIT, Apache, GPL, AGPL) allow commercial use. The difference is in the obligations:

  • Permissive licenses (MIT, Apache): No restrictions on commercial use
  • Copyleft licenses (GPL, AGPL): Commercial use allowed, but source code disclosure required when distributing

Q: Do I have to open source my code if I use open source libraries?

A: Depends on the license:

  • MIT, Apache 2.0, BSD: No, you can keep your code proprietary
  • LGPL: No, if you're just linking to the library (modifications to LGPL library must be open-sourced)
  • GPL: Yes, if you distribute the combined work
  • AGPL: Yes, if you deploy as a network service (SaaS)

Q: What's the most popular open source license?

A: MIT License is the most popular, used by ~30% of open source projects. GitHub's 2025 data shows:

  1. MIT (30%)
  2. Apache 2.0 (15%)
  3. GPL v3 (12%)
  4. BSD 3-Clause (6%)
  5. GPL v2 (5%)

License Choice Questions

Q: Should I choose MIT or Apache 2.0?

A:

  • MIT: Choose for simplicity, maximum adoption, and JavaScript/Node.js ecosystem compatibility
  • Apache 2.0: Choose for explicit patent protection, trademark protection, and enterprise software

Both are permissive and corporate-friendly. Apache 2.0 is more legally comprehensive (patent grant, trademark clause, change documentation requirement).

Q: When should I use GPL instead of MIT?

A: Use GPL if:

  • You want to ensure modifications remain open source
  • You want to prevent proprietary competitors from free-riding
  • You support the free software philosophy
  • You're pursuing a dual licensing business model

Use MIT if:

  • You prioritize maximum adoption over preventing proprietary forks
  • You want corporate-friendly licensing with minimal compliance burden

Q: What's the difference between GPL v2 and GPL v3?

A: Key differences:

  • Patent grant: GPL v3 has explicit patent grant; GPL v2 implicit only
  • Tivoization: GPL v3 prohibits hardware restrictions on modified software; GPL v2 allows
  • Apache compatibility: GPL v3 compatible with Apache 2.0; GPL v2 is not
  • License termination: GPL v3 allows curing violations within 60 days; GPL v2 automatic permanent termination

Most new projects should use GPL v3 (more legally robust and compatible with modern licenses).

Copyleft Questions

Q: Can I use GPL software in my SaaS product without open-sourcing my code?

A: GPL: Yes (loophole). GPL triggers only on distribution, and SaaS is not distribution. You can modify GPL code and run it on your servers without disclosing source.

AGPL: No. AGPL closes the SaaS loophole—network use triggers source disclosure obligations.

Q: What happens if I violate the GPL?

A:

  1. You lose your license to use the GPL software (automatic termination)
  2. Copyright holder can send cease-and-desist
  3. You must either: (a) comply by open-sourcing, (b) remove GPL code, or (c) negotiate commercial license
  4. Copyright holder can sue for damages (rare; enforcement typically seeks compliance)
  5. Reputational damage in open source community

Q: Is "dynamic linking" to a GPL library safe?

A: Gray area.

  • FSF position: Dynamic linking creates a derivative work, so GPL obligations apply
  • Industry practice: Many companies link to LGPL (not GPL) to avoid issue
  • Safe approach: Use LGPL or permissive alternatives instead of GPL libraries

AGPL Questions

Q: Why do companies avoid AGPL?

A:

  1. SaaS trigger: Network use triggers source disclosure (not just distribution)
  2. Compliance uncertainty: Unclear what constitutes "network interaction"
  3. Corporate bans: Many enterprises prohibit AGPL dependencies entirely
  4. M&A risk: AGPL dependencies can complicate acquisitions

Q: If I use an AGPL library in my SaaS product, do I have to open-source my entire application?

A: Yes, if the AGPL library is integrated into your application (strong copyleft applies). You must:

  • Provide source code for the entire combined work
  • License it under AGPL
  • Provide a download link to users accessing your SaaS

Exception: If the AGPL library is a separate program (communicating via API), you may avoid AGPL obligations (depends on degree of integration).

Contributor Questions

Q: What's the difference between CLA and DCO?

A:

  • CLA (Contributor License Agreement): Legal contract signed by contributors, grants copyright/patent license to project maintainer. More legally protective, but creates friction.
  • DCO (Developer Certificate of Origin): Lightweight certification via Signed-off-by in commits. Less friction, but less legal protection.

Recommendation: Use DCO for community projects, CLA for dual licensing business models.

Q: Do I need a CLA for my open source project?

A: Only if:

  • You plan to dual license (need full copyright ownership)
  • You want flexibility to relicense in the future
  • You want maximum legal protection

Otherwise, DCO is sufficient for most projects.

Compliance Questions

Q: How do I know what licenses my dependencies use?

A: Use automated tools:

  • Node.js: npm install -g license-checker && license-checker
  • Python: pip install pip-licenses && pip-licenses
  • Rust: cargo install cargo-license && cargo license
  • Java: Maven License Plugin or Gradle License Plugin
  • Commercial: FOSSA, Black Duck, WhiteSource

Q: What should I include in my product to comply with open source licenses?

A: At minimum:

  1. LICENSE or NOTICES file listing all open source components and their licenses
  2. Full license text for each component (especially MIT, BSD)
  3. Copyright notices for each component
  4. Source code (if using GPL/AGPL and distributing)

Many companies generate a "NOTICES" file automatically from dependency metadata.

Business Model Questions

Q: Can I make money from open source software?

A: Yes. Common models:

  1. Dual licensing: Free AGPL + paid commercial license
  2. Open core: Free community edition + paid enterprise edition
  3. SaaS: Free self-hosted + paid managed service
  4. Support: Free software + paid support contracts

Q: What's the best license for a dual licensing business model?

A: AGPL + commercial license. AGPL's network use trigger creates compliance burden for SaaS companies, driving them to purchase commercial licenses. Examples: MongoDB (historical), iText PDF.

Q: Should I open source my startup's product?

A: Consider:

  • Pros: Community contributions, faster adoption, transparency, reduced sales friction
  • Cons: Harder to monetize, requires community management, competitors can fork

Recommendation: Open source if:

  • You're building infrastructure/developer tools (high community leverage)
  • You have a clear business model (dual licensing, open core, SaaS)
  • You can provide enterprise value beyond the open source version

Additional Resources

License Choosers and Guides

  • Choose a License (https://choosealicense.com): GitHub's license selection guide
  • TL;DR Legal (https://tldrlegal.com): Plain-English license summaries
  • OSI License List (https://opensource.org/licenses): Official Open Source Initiative approved licenses
  • SPDX License List (https://spdx.org/licenses): Standardized license identifiers

License Texts

  • MIT License (https://opensource.org/licenses/MIT)
  • Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0)
  • GNU GPL v3 (https://www.gnu.org/licenses/gpl-3.0.en.html)
  • GNU AGPL v3 (https://www.gnu.org/licenses/agpl-3.0.en.html)
  • GNU LGPL v3 (https://www.gnu.org/licenses/lgpl-3.0.en.html)

Open Source Organizations

  • Open Source Initiative (OSI) (https://opensource.org): Steward of the Open Source Definition
  • Free Software Foundation (FSF) (https://www.fsf.org): Advocates for software freedom, maintains GPL
  • Software Freedom Conservancy (https://sfconservancy.org): Non-profit supporting GPL enforcement
  • Linux Foundation (https://www.linuxfoundation.org): Supports open source projects and communities

Compliance Tools

  • FOSSA (https://fossa.com): Commercial license compliance and security
  • Black Duck (https://www.synopsys.com/software-integrity/security-testing/software-composition-analysis.html): Enterprise open source management
  • WhiteSource (Mend) (https://www.mend.io): Open source security and license compliance
  • FOSSology (https://www.fossology.org): Open source license scanning

Books and Articles

  • "Understanding Open Source and Free Software Licensing" by Andrew M. St. Laurent (O'Reilly)
  • "The International Free and Open Source Software Law Book" (Open Source Press)
  • GNU GPL FAQ (https://www.gnu.org/licenses/gpl-faq.html): FSF's comprehensive GPL FAQ
  • GitHub's Open Source Guides (https://opensource.guide): Community-driven open source best practices

Work with Promise Legal on Open Source Licensing

Choosing the right open source license—and ensuring compliance with licenses you use—can have long-term implications for your startup's business model, fundraising, and exit options.

Promise Legal helps startups with:

  • License selection: Choose the right license for your business model and goals
  • Open source audits: Identify GPL/AGPL compliance risks in your dependencies
  • Contributor agreements: Implement CLA or DCO for your open source project
  • Dual licensing: Structure dual licensing business models (AGPL + commercial)
  • M&A due diligence: Prepare open source compliance documentation for investors and acquirers
  • GPL/AGPL compliance: Remediate license violations and negotiate with copyright holders

Schedule a consultation: Contact Promise Legal to discuss your open source licensing strategy.

Disclaimer

This guide provides general information about open source licensing and is not legal advice. Open source licensing is complex and fact-specific. For advice on your specific situation, consult a licensed attorney familiar with intellectual property and open source licensing.

Last updated: January 2025

Related guides:

This button allows you to scroll to the top or access additional options. Alt + A will toggle accessibility mode.