.png)
Software licensing decisions rarely feel urgent in the early months of building. You're moving fast, installing dependencies without reading their terms, and the abstract question of which license governs your codebase sits well below the line of things that need attention today.
They surface at the worst moments: in M&A due diligence, when an acquirer's counsel asks for a full inventory of your dependency licenses; in an enterprise sales cycle, when a procurement team at a venue group or conference operator asks whether your product incorporates any AGPL components; when a competitor launches a managed service built on top of your open-source code and you have no legal mechanism to stop them.
This guide covers the major license types, how licensing decisions compound across company stages, the most common pitfalls and how they actually play out, and where the landscape is heading. It's written for product and engineering leaders who need a working understanding, not a legal reference.
The thesis running through all of it: the license you choose matters less than most founders expect. Most licensing problems are caused by not tracking what got incorporated into the codebase, and not reassessing choices at the inflection points — fundraising, enterprise sales, M&A — where those choices become visible.
A software license is a legal agreement between the software owner and anyone who uses, modifies, or distributes the software. Without a declared license, software is legally ambiguous — in most jurisdictions, the absence of a license means all rights are reserved by the author, which typically isn't what either party intended and creates real problems for contributors, users, and downstream integrators.
Most licenses address four things: usage rights (what you're allowed to do with the software — run it commercially, embed it in consumer products); modification rights (whether you can alter the source code, and whether changes must be published); distribution rights (whether you can share, bundle, or sell the software — distribution is where most compliance obligations are triggered); and patent and liability clauses (some licenses include explicit patent grants protecting users from infringement claims by contributors; Apache 2.0 is the most notable example). Almost all licenses disclaim warranties and limit the licensor's liability.
Under a proprietary license, the software owner retains full control. Source code is not shared, and users cannot modify, redistribute, or sublicense the software without explicit permission. The license is typically granted in exchange for a fee — one-time, subscription-based, or usage-based — and the terms are defined in an EULA. This model is most common in commercial SaaS platforms, enterprise software, and products where the codebase itself is the competitive moat.
The downside for end users is real: you can't audit the code, you can't fix bugs yourself, and you're dependent on the vendor's roadmap and pricing decisions. For companies building on top of proprietary tools, this dependency compounds as integration deepens — if a vendor raises prices, discontinues a product, or changes their terms, recourse is limited. Proprietary licensing makes sense when you're selling a finished product or managed service and unauthorized modification would directly undermine the business model.
Permissive licenses allow anyone to use, modify, and redistribute the software with minimal conditions. Modifications can be kept private, and the software can be incorporated into proprietary products without triggering any open-sourcing requirement.
The MIT License is about as minimal as a license gets: you can do almost anything with the software, provided you include the original copyright notice. Apache 2.0 adds two meaningful provisions — an explicit patent grant from contributors, protecting users from patent claims by the people who wrote the code, and a requirement to include a NOTICE file if one exists. BSD licenses come in two and three-clause variants; the three-clause version adds restrictions on using the project's name in advertising.
Permissive licenses have become the default for developer tooling, frameworks, and infrastructure software where adoption is the primary goal. Node.js (MIT), React (MIT), ASP.NET Core (Apache 2.0), and TensorFlow (Apache 2.0) all use permissive licenses. The reasoning is that broad adoption often creates more value than controlling who can use the software commercially.
For companies building on permissive-licensed software, the main advantage is a clear legal path to incorporate the code without worrying about your codebase becoming subject to open-source requirements. The tradeoff is symmetrical: others have the same freedom and can take the software, build a commercial product with it, and contribute nothing back.
Copyleft licenses are designed to keep software and its derivatives permanently in the open-source commons. Any modification or derivative work must be distributed under the same license terms — fork a GPL project and ship that fork, and the fork must also be open-source under the GPL.
The most important copyleft licenses for product companies are the GPL and the AGPL. They differ in what exactly triggers the obligation.
GPL applies when you distribute software. Modify a GPL-licensed program and ship it to users — packaging it in a product or making it available for download — and you must release those modifications under the GPL. Internal use is explicitly carved out: you can modify GPL software for use inside your company without any disclosure requirement. The obligation only arises on external distribution.
AGPL closes what's commonly called the "SaaS loophole." Because GPL only triggers on distribution, a company can take GPL-licensed code, build a SaaS product on top of it, and serve that product over the network without ever distributing the software — technically complying with the GPL while keeping all modifications proprietary. The AGPL addresses this directly: if you offer a network service built on AGPL-licensed software, you're required to make your modifications available to users of that service. Cal.com and Plausible Analytics use AGPL precisely to prevent other companies from spinning up competing managed services on their code without giving anything back. MongoDB switched from AGPL to its own Server Side Public License (SSPL) for similar reasons after cloud providers started offering managed MongoDB services.
The practical implication for proprietary product companies: if GPL-licensed code is compiled into your product or linked in ways that make it a derivative work, your product may legally need to be open-sourced under the GPL. This is why companies like Google have strict internal policies about GPL usage. The safe pattern is to keep GPL components isolated — running in separate processes, communicating via APIs — rather than deeply integrating them with proprietary code.
The LGPL sits between permissive and copyleft. It allows you to use and link against LGPL-licensed libraries in proprietary software without triggering an open-source requirement for your own code — but modifications to the LGPL library itself must be published under the LGPL.
FFmpeg is available under both GPL and LGPL depending on build configuration. A company building proprietary video processing software can link against the LGPL build and keep its own code private, but must publish any changes made to FFmpeg itself. Using an LGPL library as a dependency is generally considered linking and is permitted without disclosure. Changing the library's source code is modification and requires publishing those changes. The line between linking and creating a derivative work can be blurry in specific architectures, which is worth a legal review before committing to LGPL components in anything sensitive.
Dual licensing makes the same software available under two different licenses simultaneously. The typical arrangement is an open-source license for non-commercial or community use, and a commercial license for businesses that need proprietary integration rights or want to avoid the obligations of the open-source version.
MySQL is the canonical example: distributed under the GPL for open-source use, and under a commercial license for companies that can't or won't comply with the GPL. Qt uses the same approach. The model gives vendors a lever for monetization without fully closing the source — the open-source version builds community and adoption; the commercial license captures revenue from businesses that benefit from the software but don't want to deal with copyleft obligations.
Dual licensing requires the vendor to hold copyright over all contributions, which means requiring contributors to sign a Contributor License Agreement (CLA) transferring their rights. Without CLAs, relicensing requires consent from every contributor — effectively impossible once a project has meaningful outside participation. More on CLAs below.
At early stage, permissive licenses are almost always the right default for both your own code and the third-party dependencies you adopt. MIT and Apache 2.0 minimize legal friction, don't create obligations that could complicate your IP position, and are widely understood by investors and acquirers.
The more important discipline at this stage isn't which license you choose — it's building the habit of tracking what you're incorporating. Most early-stage engineering teams install dependencies without reading their license terms. This is understandable, but it creates a debt that compounds. A GPL library embedded in the codebase because it was convenient in week two of development can surface as a serious problem during Series A due diligence or M&A review, when someone audits the dependency tree for the first time.
A basic approach: maintain a manifest of your key dependencies and their licenses. Note anything under GPL, AGPL, or licenses you haven't reviewed. A spreadsheet works. Having it means you're not starting from scratch when someone asks.
For your own software: if you're releasing anything publicly, choose a license and declare it. Add a LICENSE file to the root of your repository and a license header to your source files. This prevents ambiguity for contributors and users and establishes your intent from the start.
One timing consideration that's easy to get wrong: moving from open-source to proprietary later is hard. Once you've released code under the MIT License, you can't revoke those rights from people who already have the code. You can change the license for future versions, but the open-source version stays open-source. If you have any expectation that you'll want to control commercial use of your software, working that out before you publish is significantly easier than trying to walk it back afterward.
As you scale, licensing decisions that felt academic become operationally significant.
The support gap in open-source. Open-source tools offer flexibility but don't come with SLAs, guaranteed response times, or dedicated support engineers. At early stage, your team can absorb the cost of troubleshooting a configuration issue. At scale, the same issue can affect a large portion of your customers at significantly higher cost per hour of downtime. This isn't an argument for proprietary software over open-source — many companies run mission-critical infrastructure on open-source without issues — but it is an argument for being deliberate about where you invest in support relationships.
Vendor lock-in is a function of integration depth, not just license type. The risk of being locked into a proprietary platform isn't primarily about the license terms — it's about how deeply the platform's APIs, data models, and abstractions are embedded in your product. When evaluating proprietary tools, assess integration depth and migration complexity alongside cost. A platform deeply woven into your data pipelines, event processing logic, and reporting infrastructure is practically locked in regardless of what its license says.
Enterprise sales introduces compliance requirements. When you start selling to enterprise customers, they will audit your software supply chain. An event management platform moving upmarket into large venue groups or conference operators will encounter procurement and security teams asking specifically what open-source components are in the product, whether any are under copyleft terms, and whether there's a process for keeping dependencies updated. This is often the first moment a scaling startup realizes it needs formal software composition analysis.
Tools like FOSSA, Snyk, and WhiteSource scan your full dependency tree and flag licenses — not just direct dependencies. The practical version of the copyleft risk isn't usually a deliberate decision to incorporate GPL code — it's an indirect dependency that arrives as a transitive dependency of something you installed deliberately. Your package manager resolves dependencies recursively, and most teams don't audit the full tree systematically. Running one of these tools early, and integrating it into CI, is significantly more effective than running a manual audit after the dependency tree has grown to hundreds of packages.
CLAs become relevant here. If you're maintaining an open-source project and considering dual licensing, a CLA is what makes that option available to you. A CLA is an agreement a contributor signs before their code can be merged; it typically grants the project maintainer a broad license to use the contribution, and often the right to relicense it. Without CLAs, relicensing requires consent from every contributor — effectively impossible once a project has meaningful outside participation.
If you're contributing to a project that requires a CLA, read what you're signing. Some are narrow, granting a limited license to use the contribution in the project. Others transfer copyright entirely or grant the maintainer unlimited sublicensing rights. For employees contributing on behalf of a company, CLAs typically require employer sign-off.
At maturity, the licensing calculus shifts further toward IP protection and compliance management.
For your own software, this often means moving toward proprietary licenses for the core product, potentially combined with an open-source strategy for peripheral components or integrations. PostHog does this by keeping its core analytics product open-source under MIT while offering paid enterprise features on top. Elastic originally took a similar approach with Elasticsearch before switching to a proprietary license in response to AWS's managed offering — a decision that illustrates both the risk of permissive licensing at scale and the friction that comes with relicensing an established open-source project.
For third-party software, compliance becomes a systematic concern rather than a periodic check. A mature product typically has hundreds of dependencies, each governed by different license terms; managing this manually doesn't scale. Integrating license scanning into CI/CD — so new dependencies are flagged before they're merged — is significantly more effective than periodic audits after the fact.
In regulated industries, the scope expands further. HIPAA, GDPR, FedRAMP — each carries requirements your software stack must meet. Open-source software doesn't come with compliance certifications. If you're using an open-source component in a healthcare or financial services product, validating that component's security and compliance posture is your responsibility; proprietary vendors are contractually bound to maintain theirs.
Misunderstanding what GPL copyleft actually requires. Two common misreadings, in opposite directions. The first is thinking that using GPL software in your development environment triggers the open-source obligation — it doesn't. GPL applies to distribution; internal use is explicitly carved out. The second is thinking that running GPL software as an isolated component you communicate with via API is categorically safe. This pattern is generally correct and widely used deliberately, but "generally correct" isn't the same as settled law, and the line between a legitimate architectural choice and an attempt to circumvent copyleft has been contested in specific contexts. If you're incorporating copyleft-licensed software in a commercial product, a legal review of the specific integration architecture is worth having before you're too far in.
Letting dependency licenses go untracked. The risk is almost always in transitive dependencies, not direct ones. You installed a library that itself depends on a GPL-licensed library. Your package manager resolved it silently. This is preventable with tooling; it's essentially random without it.
Deep proprietary lock-in without an exit strategy. No one decision locks you in — it's a series of decisions that each seemed reasonable in isolation: a proprietary database chosen for performance, pipelines built to its specific query patterns, proprietary tooling adopted because it was easier. Three years later, migrating would require rewriting substantial parts of the product. The mitigation isn't avoiding proprietary tools — it's evaluating integration depth at selection time and maintaining abstraction layers that isolate vendor-specific implementation details from your core business logic.
Not licensing your own software. If you release or share code without a declared license, the legal status defaults to all rights reserved in most jurisdictions. For code shared with contractors, partners, or published publicly, the absence of a license creates real uncertainty. The mechanics are simple: a LICENSE file in the repository root, a brief header in each source file, and licensing terms in user agreements for commercial software.
Treating licensing as a one-time decision. The license that fit your product at seed stage may be actively misaligned two years later. Several inflection points commonly trigger a reassessment: entering enterprise sales, preparing for fundraising or M&A, adding a significant new product line, or discovering that competitors are building on your open-source code without contributing back. Licensing decisions are reversible in some directions and effectively irreversible in others — the asymmetry is worth understanding before you need to act on it.
Hybrid licensing as the default for developer tools. The combination of an open-source core and a proprietary commercial layer has become the standard business model for a significant category of developer tools. PostHog (MIT core, commercial enterprise features), HashiCorp (BSL for newer releases), and MongoDB (SSPL) all represent variations on this approach. The model threads the needle between community adoption — which requires some form of openness — and revenue protection — which requires some form of control.
The tension is real. When HashiCorp switched Terraform from an open-source license to the Business Source License in 2023, it triggered a fork (OpenTofu) and significant community backlash. Both sides had legitimate positions: the company's commercial interests were real, and so were the community's concerns about relicensing an established project. Community trust is part of the asset, and licensing decisions perceived as extractive can damage it in ways that are hard to repair.
AGPL as infrastructure protection. As major cloud providers have built managed services around open-source projects — often without contributing substantially back — AGPL has become a more deliberate tool for open-source maintainers. The logic is that AGPL forces anyone offering a network service based on the software to publish their modifications, which either brings improvements back to the project or creates license friction that makes the managed service model less commercially attractive.
This trend is accelerating. Companies releasing new open-source infrastructure — including in event tech and developer platforms — are increasingly choosing AGPL or purpose-built licenses like SSPL, specifically because permissive licenses have proven to give cloud providers a free ride. For companies building on these tools, the practical implication is that "open source" no longer reliably means "minimal obligations." Assuming permissive rights because a project is described as open-source is increasingly risky without reading the specific terms.
AI model licensing is genuinely unsettled. The software licensing frameworks developed over the past four decades were designed for code. They don't map cleanly onto the new categories of IP that AI has introduced: model weights, training datasets, fine-tuned derivatives, inference outputs, and embeddings.
The Apache 2.0 license on Hugging Face's core libraries covers the framework code. What it doesn't clearly address is the legal status of model weights trained on proprietary data, or the rights you have to a fine-tuned derivative of a foundation model. Licenses like the Llama community license and variants created by other AI labs often contain restrictions that don't appear in standard software licenses — prohibiting commercial use above certain user thresholds, restricting use in specific applications, or requiring attribution for outputs.
If your product is built on or around foundation models, reading the specific license for each model you use is not optional. The term "open" in AI contexts has been applied to models with significantly varying levels of actual openness, and assuming permissive rights because a model is described as open-source is a real compliance risk.
Ethical licensing remains marginal but is worth tracking. Licenses like the Hippocratic License restrict use cases that cause harm or violate human rights. Adoption is limited — partly because legal enforceability hasn't been tested in court, and partly because the definition of "harm" is subjective enough to create uncertainty for potential users. The category reflects a broader conversation about whether software licenses can constrain the social impact of technology — one that's happening in the open-source community, in AI policy contexts, and increasingly in enterprise procurement.
For your own software: MIT or Apache 2.0 for open-source projects where adoption matters. A proprietary license when your competitive advantage depends on controlling the codebase. If you want community adoption and commercial revenue simultaneously, design the dual-license structure from the beginning — including CLA requirements for contributors — rather than trying to retrofit it after accepting contributions without them.
For third-party dependencies: default to permissive-licensed components. Treat GPL dependencies with care in proprietary products, and AGPL dependencies as requiring explicit architectural decisions before you're committed. Don't incorporate copyleft-licensed code without understanding the compliance implications.
For compliance infrastructure: start tracking dependency licenses earlier than feels necessary. Integrate scanning into your build process before the dependency tree gets large enough that auditing it manually is impractical. If you're approaching enterprise sales, get ahead of the audit rather than running it in response to a procurement request.
The right licensing structure isn't static. It should evolve as your product matures, your market position changes, and the licensing environment shifts — and in AI and open-source infrastructure, that environment is shifting faster than it was five years ago.
Think of us as your tech guide, providing support and solutions that evolve with your product.
.png)
