.png)
Software licensing decisions shape how you build, how you grow, and how much control you retain over what you've built. Whether you're choosing a license for your own product or evaluating a third-party tool, getting this right early saves painful reconfiguration later.
This guide covers the major license types, how to think about licensing at each company stage, 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 of these decisions, not a legal textbook.
A software license is a legal agreement between the software owner and anyone who uses, modifies, or distributes the software. It defines what's permitted and what isn't: Can you run this in a commercial product? Can you modify the source code? Can you redistribute it? Are you required to publish any changes you make?
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.
Licenses aren't a formality you deal with once and forget. They carry ongoing obligations, and those obligations can compound as your codebase grows and your product evolves. The license governing a library you added in your first sprint might create compliance requirements that only surface two years later when you're preparing for acquisition due diligence.
Most licenses address four things:
Usage rights. What you're allowed to do with the software—run it commercially, use it in government contexts, embed it in consumer products. Some licenses restrict certain categories of use entirely.
Modification rights. Whether you can alter the source code and under what conditions. Some licenses require you to publish modifications; others let you keep them private.
Distribution rights. Whether you can share the software with others, bundle it with your product, or sell it. Distribution is where most compliance obligations are triggered.
Patent and liability clauses. Some licenses include explicit patent grants (Apache 2.0 is notable here), protecting users from infringement claims by contributors. 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 End User License Agreement (EULA). This model is most common in commercial SaaS platforms, enterprise software, and products where the codebase itself is the competitive moat.
The licensor determines what features are available, sets the pricing, and controls the update cadence. Users trade flexibility for the reliability, support, and polish that typically comes with a commercial product. Proprietary licensing makes sense when you're selling a finished product or a managed service, and where unauthorized modification or redistribution would directly undermine your business model. It also makes internal security and quality control easier—you control the entire stack and aren't dependent on community contributions for stability.
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. For companies building on top of proprietary tools, this dependency compounds over time. If a vendor raises prices, discontinues a product, or changes their terms, you may have limited recourse.
Strengths: Strong IP protection; reliable support and SLAs; predictable revenue model for vendors; clear legal boundaries.
Weaknesses: Limited flexibility for end users; higher cost of adoption; meaningful lock-in risk; no recourse if the vendor makes changes you don't like.
Permissive licenses—the MIT License, BSD License, and Apache License 2.0 being the most widely used—allow anyone to use, modify, and redistribute the software with minimal conditions. Critically, 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. The Apache License 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, with the three-clause version including 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), TensorFlow (Apache 2.0), and the core Hugging Face libraries all use permissive licenses. The reasoning is straightforward: the more broadly a framework is adopted, the more it becomes a standard, and that standardization is often more valuable than controlling who can use it commercially.
For companies building on permissive-licensed software, the main advantage is a clear legal path to incorporate the code into your product without worrying about your codebase becoming subject to open-source requirements. The tradeoff is that others have the same freedom—anyone can take the software, build a commercial product with it, and contribute nothing back.
Strengths: Maximum flexibility; no redistribution or disclosure obligations; clear patent protection under Apache 2.0; encourages broad ecosystem adoption.
Weaknesses: No mechanism to ensure improvements flow back to the community; others can commercialize your work without contributing; less leverage over how the software is used downstream.
Copyleft licenses take a fundamentally different approach. Rather than maximizing freedom to use the software any way you want, they're designed to keep the software and its derivatives permanently in the open-source commons. Any modification or derivative work must be distributed under the same license terms—which means if you fork a GPL project and ship that fork, your fork must also be open-source under the GPL.
The most important copyleft licenses for product companies are the GNU General Public License (GPL), the GNU Affero General Public License (AGPL), and the Mozilla Public License (MPL). They differ in scope and in what exactly triggers the copyleft obligation.
GPL applies when you distribute software. If you modify a GPL-licensed program and ship it to users—whether that's packaging it in a product or making it available for download—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 when you distribute externally.
AGPL closes what's commonly called the "SaaS loophole." Because the 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 was written specifically to address this: if you offer a network service built on AGPL-licensed software, you're required to make your modifications available to users of that service. Plausible Analytics and Cal.com use AGPL precisely because they want to prevent other companies from spinning up competing managed services using their code without giving back. MongoDB switched from AGPL to its own Server Side Public License (SSPL) for similar reasons after cloud providers started offering managed MongoDB services.
MPL is a weaker form of copyleft that applies at the file level rather than the project level. Modifications to MPL-licensed files must be released under the MPL, but those files can coexist in a project with proprietary code in other files. This makes it more workable in mixed commercial/open-source environments than the GPL.
The practical implication for companies building proprietary products: GPL and AGPL code requires careful handling. The copyleft "infection" is real—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 as well. This is one reason companies like Google have strict internal policies about GPL usage. The safe approach is to keep GPL components isolated—running in separate processes, communicating via APIs—rather than deeply integrating them with proprietary code.
Strengths: Ensures modifications remain available to the public; discourages purely extractive commercial use; creates strong contributor incentives in community-driven projects.
Weaknesses: Creates real compliance complexity in proprietary products; AGPL imposes obligations on SaaS companies that can be difficult to plan around; incompatible with many commercial licensing scenarios.
The LGPL occupies a middle position between permissive and copyleft. It allows you to use and link against LGPL-licensed libraries in proprietary software without triggering the open-source requirement for your own code. However, any modifications made to the LGPL library itself must still be published under the LGPL.
The practical use case is straightforward: you need a powerful open-source library, but you don't want your entire codebase to fall under copyleft terms. FFmpeg, for example, is available under both GPL and LGPL depending on the build configuration. A company building proprietary video editing software can link against the LGPL build, keep its own code private, but must publish any changes it makes to FFmpeg itself.
The distinction between "linking against" and "modifying" matters a lot here. Using an LGPL library as a dependency and calling its functions from your proprietary code is generally considered linking—permitted under LGPL without disclosure obligations. Changing the library's source code is modification—that requires publishing those changes.
Strengths: Enables use of open-source libraries in commercial products; modifications to the library remain part of the commons.
Weaknesses: Modifications to LGPL components must be disclosed; requires maintaining clear separation between your code and the library; the legal line between "linking" and "creating a derivative work" can be blurry.
Freeware is closed-source software provided at no cost. Users can run it, but can't access or modify the source code. The vendor retains full rights.
Shareware provides a trial or limited version for free, with payment unlocking full functionality or continued use after a trial period. This is the original freemium model, predating the term.
Neither model is particularly relevant for companies building infrastructure or developer tools, but both appear frequently in productivity software, utilities, and consumer applications. The key characteristic both share is that "free" refers to price, not freedom—you're getting access, not rights.
For product companies evaluating third-party freeware, the main concerns are the lack of customization options and the licensing terms that typically prohibit reverse engineering or redistribution.
Dual licensing is a licensing strategy where the same software is made 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 license.
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, the application framework, uses the same approach. This model gives vendors a lever for monetization without fully closing the source code. 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 the GPL's obligations.
The downside is that dual licensing requires the vendor to hold copyright over all contributions, which typically means requiring contributors to sign a Contributor License Agreement (CLA) transferring their rights. This creates friction in the contribution process and can reduce community involvement.
CLAs are frequently overlooked until they become a problem. A CLA is an agreement a contributor signs before their code can be merged into a project. It typically grants the project maintainer a broad license to use the contribution—and often, the right to relicense it.
For companies, CLAs matter in two directions. If you maintain an open-source project and accept external contributions, a CLA ensures you have the rights to relicense the project later (necessary for dual licensing) and protects you from patent claims by contributors. Without a CLA, relicensing becomes legally complex—you'd need consent from every contributor.
If you're contributing to an open-source project that requires a CLA, read what you're signing. Some CLAs are narrow (limited license to use the contribution in the project). Others are broad (transferring copyright entirely, or granting the maintainer unlimited rights to sublicense). For employees contributing on behalf of a company, CLAs typically require employer sign-off.
At the 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 licenses you're incorporating. Most early-stage engineering teams install dependencies without reading their license terms. This is understandable but creates a debt that compounds. A GPL library embedded in your codebase because it was convenient in week two of development can create a serious problem during Series A due diligence or M&A review, when someone actually audits your dependency tree.
A basic approach: maintain a manifest of your key dependencies and their licenses. Note anything under GPL, AGPL, or licenses you haven't reviewed. This doesn't need to be sophisticated—a spreadsheet works—but 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 clearly. Add a LICENSE file to the root of your repository. Add 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 of your code stays open-source. If you have any expectation that you'll want to control commercial use of your software, thinking about that before you publish is significantly easier than trying to walk it back afterward.
As you scale, licensing decisions that felt academic become operationally significant. A few dynamics worth understanding:
The support gap in open-source. Open-source tools offer flexibility but typically don't come with SLAs, guaranteed response times, or dedicated support engineers. At early stages, your team can absorb the cost of troubleshooting a Kubernetes configuration or debugging a Redis edge case. At scale, that same issue can affect thousands of customers and costs significantly more 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 and where you rely on community resources.
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. AWS Lambda functions written in Python can run elsewhere. An application tightly coupled to DynamoDB's specific query patterns, Lambda's invocation model, and API Gateway's configuration format is practically locked in, regardless of what the license says. When evaluating proprietary tools, assess integration depth and migration complexity alongside cost.
Enterprise sales introduces new compliance requirements. When you start selling to enterprise customers, they will audit your software supply chain. Enterprise procurement and security teams want to know what open-source components are in your product, whether you're using anything under copyleft terms, and whether you have a process for keeping dependencies updated. This is often the first time a scaling startup realizes it needs formal software composition analysis. Tools like FOSSA, Snyk (for license scanning), and WhiteSource can automate dependency auditing and flag licensing issues before they become a due diligence problem.
At maturity, the licensing calculus shifts further toward IP protection and compliance management. You've built something with real commercial value, and the licensing structure needs to reflect that.
For your own software, this often means moving toward proprietary licenses for your core product, potentially combined with an open-source strategy for peripheral components or integrations. The goal is to protect what's competitively differentiating while maintaining an open ecosystem around it. 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 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 your CI/CD pipeline—so new dependencies are flagged before they're merged—is significantly more effective than running periodic audits after the fact.
If you operate in a regulated industry, the compliance scope expands further. HIPAA in healthcare, GDPR in Europe, FedRAMP in federal contracting—each carries requirements that 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 product, validating that component's security and compliance posture is your responsibility. Proprietary vendors often provide explicit compliance documentation and are contractually bound to maintain it; with open-source, you're doing that work yourself.
The GPL's copyleft requirement is frequently overstated and occasionally understated. Two common misunderstandings:
The first is thinking that simply using GPL software in your development environment triggers the open-source obligation. It doesn't. The GPL applies to distribution. If your developers use GPL-licensed tools internally and never distribute those tools or their modifications, there's no obligation.
The second is thinking that running GPL software as an isolated component—a separate process you communicate with via API—doesn't create any derivative work issue. This is generally correct, and it's why many companies use this architectural pattern deliberately: communicate with GPL components via clean interfaces rather than linking against them. 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.
The AGPL closes a third misunderstanding that many SaaS companies have relied on: that serving GPL software over a network, without ever distributing it, is categorically different from distributing it. Under the AGPL, it isn't.
If you're incorporating any copyleft-licensed software in a commercial product, get a legal review of the specific integration architecture before you're too far in.
The practical version of the copyleft risk isn't usually a deliberate decision to incorporate GPL code—it's an indirect dependency that comes in as a transitive dependency of something you installed deliberately. Your package manager resolves dependencies recursively. A library you added might itself depend on a GPL-licensed library, which means you've incorporated GPL code without knowing it.
Modern package managers make it easy to audit direct dependencies. Auditing transitive dependencies is harder, and most teams don't do it systematically. Tools like FOSSA, Snyk, and WhiteSource scan your full dependency tree and flag licenses—not just your direct dependencies. Running one of these early, and integrating it into CI, is the most reliable way to prevent licensing surprises.
The risk here accumulates gradually. No one decision locks you in—it's a series of decisions that each seemed reasonable in isolation. You chose a proprietary database because it had the best performance characteristics. You built data pipelines optimized for its specific query patterns. You adopted the vendor's proprietary change data capture tooling because it was easier. Three years later, your entire data infrastructure is deeply coupled to a single vendor's implementation choices, and migrating would require rewriting substantial parts of your product.
The mitigation isn't avoiding proprietary tools—it's evaluating integration depth at selection time and actively maintaining escape hatches. Use open standards and data formats where possible. Maintain abstraction layers that isolate vendor-specific implementation details from your core business logic. Know, concretely, what a migration would require. If you don't know, that's worth investigating before you're in a situation where you need to move.
If you release or share code—even internally within a company—without a declared license, the legal status is ambiguous. Most jurisdictions default to "all rights reserved," meaning no one can legally use, modify, or distribute the code. For internal tools this may not matter, but for code shared with contractors, partners, or published publicly, the absence of a license creates real uncertainty.
The mechanics are simple: add a LICENSE file to your repository root containing the full text of your chosen license. Add a brief license header to each source file with the license name, copyright holder, and year. For commercial software, include licensing terms in your user agreements and on your website.
If you want to encourage broad adoption while retaining commercial control, a dual-license model is worth considering: open-source (MIT or Apache) for non-commercial use, commercial license for businesses. This is how many developer tools and frameworks are monetized. The requirement is that you hold copyright over the entire codebase—which means requiring CLAs from external contributors.
The license that fit your product at seed stage may be actively misaligned two years later. Several inflection points commonly trigger a licensing reassessment: entering enterprise sales (where customers audit your licensing posture), preparing for fundraising or M&A (where investors and acquirers review your software supply chain), 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. Moving from open-source to proprietary is hard—you can't revoke rights already granted, though you can change the license for future versions. Moving from proprietary to open-source is easier but changes your commercial model in ways that are difficult to undo. These asymmetries are worth understanding before you need to act on them.
The combination of an open-source core and a proprietary commercial layer has become the default 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 theme. 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 in this model 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. The company's commercial interests were legitimate; the community's concerns about relicensing an established project were also legitimate. This dynamic illustrates the limits of open-source as a purely commercial strategy—community trust is part of the asset, and licensing decisions perceived as extractive can damage it.
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 attractive.
This trend is accelerating. Companies releasing new open-source infrastructure projects are increasingly choosing AGPL or purpose-built licenses like SSPL precisely because permissive licenses have proven to give cloud providers a free ride. For companies building on top of these tools, the implication is that the license landscape for open-source infrastructure is getting more complex—"open source" no longer reliably means "minimal obligations."
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 is clear—it 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 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.
Licenses like the Hippocratic License restrict use cases that cause harm or violate human rights. Adoption is limited—partly because legal enforceability of such restrictions hasn't been tested in court, and partly because the definition of "harm" is subjective enough to create uncertainty for potential users.
The category is worth monitoring because it reflects a broader conversation about whether software licenses can or should be used to constrain the social impact of technology. That conversation is happening in the open-source community, in AI policy contexts, and increasingly in enterprise procurement. Whether or not ethical licenses become mainstream, the underlying questions about acceptable use are likely to appear in other forms—contractual restrictions, platform terms, regulatory requirements.
For most product companies, the defaults are:
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 a dual-license structure from the beginning—including CLA requirements for contributors.
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 about integration. Never 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 your dependency tree gets large enough that auditing it manually is impractical.
For vendor evaluation: assess integration depth alongside license terms. The license is one factor; how difficult it would be to migrate away is often a more important one.
The right licensing structure isn't static. It should evolve as your product matures, your market position changes, and the regulatory environment shifts. The companies that manage this well treat licensing as a continuous operational concern—reviewing their choices at major inflection points and adjusting before they're forced to.
Think of us as your tech guide, providing support and solutions that evolve with your product.
.png)
