Licensing software means defining the legal terms under which others can use, modify, or distribute your code. Whether you’ve built a commercial product or an open-source tool, the license you choose controls how people interact with your software and whether (and how) you get paid. The process involves picking a licensing model, writing or adopting license terms, setting a price structure if applicable, and enforcing those terms technically.
Choose a Licensing Model
Your licensing model determines how customers pay for and access your software. Three models dominate the market, and each fits different types of products.
Perpetual licensing lets a buyer pay once and own that version of the software indefinitely. If you want to offer ongoing maintenance, support, or updates, you charge a separate annual fee. This model works well for desktop applications or specialized tools where customers expect long-term ownership. The tradeoff: you collect a larger payment upfront but lose the predictable recurring revenue that comes with other models.
Subscription licensing charges a recurring fee, usually monthly or annually, for continued access. Microsoft 365 and Adobe Creative Cloud both use this approach. Customers get regular updates and support as long as they keep paying. For you as the creator, subscriptions produce steady, predictable income and make it easier to plan development budgets. Most modern SaaS (software as a service) products default to this model.
Usage-based licensing ties cost to how much a customer actually uses the product. The metric could be storage consumed, API calls made, transactions processed, or time spent. Customers typically purchase credits in advance, and units get deducted with each use. Cloud infrastructure providers popularized this model, and it’s increasingly combined with subscription pricing in hybrid arrangements where customers pay a base fee plus overage charges.
A fourth option, site licensing, grants an entire organization unlimited use for a flat fee. This simplifies administration for large buyers and can be structured as either a perpetual or subscription arrangement.
Set Your Pricing Structure
Once you’ve picked a model, you need to decide how granularly to price it. The most common approach for subscription software is tiered pricing: you offer multiple plans at different price points, each unlocking additional features or capacity. A typical setup might include a free or low-cost starter tier, a mid-range professional tier, and an enterprise tier with premium support and advanced functionality. This lets you serve individuals, small teams, and large organizations without forcing everyone into the same plan.
Seat-based pricing (also called per-user pricing) charges based on the number of people using the software. It’s simple to understand and scales naturally as a customer’s team grows. Value-based pricing takes a different angle: instead of charging per user or per feature, you tie the price to the outcome the software delivers. If your tool saves a company $100,000 a year, charging $10,000 annually feels reasonable regardless of how many people log in.
Hybrid models that blend subscription fees with usage-based charges are becoming standard. A customer might pay $50 per month for base access, then $0.01 per additional API call beyond a set limit. This gives buyers cost predictability while letting you capture revenue from heavy users.
Pick a License for Open-Source Software
If you’re releasing open-source software, you don’t need to build a pricing model, but you absolutely need a license. Without one, your code is technically “all rights reserved” by default, which means nobody can legally use it even if it’s publicly visible on GitHub.
Three licenses cover the vast majority of open-source projects:
- MIT License: The simplest permissive license. Anyone can use, modify, and distribute your code, including in commercial products, as long as they include your original copyright notice. They don’t have to share their changes or release their source code. This is the most popular choice for libraries and tools where you want maximum adoption.
- Apache License 2.0: Similar to MIT but adds an explicit grant of patent rights, meaning contributors can’t later sue users for patent infringement related to the code. It also requires that anyone who modifies the code document what they changed. Good for projects where patent protection matters.
- GNU GPLv3: A “copyleft” license that requires anyone who modifies or builds upon your code to release their version under the same license and make the source code available. This prevents companies from taking your open-source work, making it proprietary, and selling it without contributing back. It’s a strong philosophical choice but limits commercial adoption since many businesses avoid GPL dependencies.
To apply any of these, you create a file called LICENSE in your project’s root directory and paste in the full license text. Replace the placeholder copyright line with your name and year. That’s the entire process.
Draft a Commercial License Agreement
For proprietary software, your license agreement is a legal contract between you and your customers. It’s commonly called an End User License Agreement (EULA) or Software License Agreement. At minimum, it should cover these elements:
- Grant of rights: What the customer can do with the software. Can they install it on multiple devices? Can they let employees use it? Can they modify it?
- Restrictions: What the customer cannot do. Typical restrictions include reverse-engineering, sublicensing, reselling, or using the software for illegal purposes.
- Payment terms: How much the license costs, when payment is due, and what happens if the customer stops paying.
- Term and termination: How long the license lasts, under what conditions either party can end it, and what happens to the customer’s data and access when it ends.
- Intellectual property: A clear statement that you retain ownership of the software and the customer is only receiving a license to use it, not ownership of the code.
- Warranties and liability limits: What you promise the software will do (or, more often, what you don’t promise). Most commercial licenses limit the developer’s liability to the amount the customer has paid.
For simple products sold to individuals, the EULA can be a single page that customers accept during installation or sign-up. For enterprise deals, expect a longer negotiated contract. Templates are widely available online, but the specifics matter enough that having a lawyer review your first version is worth the cost.
Enforce Your License Technically
A license agreement only works if you can verify that users are actually complying with it. For downloadable software, the most common enforcement method is a license key: a unique alphanumeric string that customers enter during installation. Your software validates the key against a database, confirming it’s legitimate and hasn’t been used beyond its allowed number of activations.
Cloud-based software has a simpler enforcement path. Since the application runs on your servers, you control access through user accounts and authentication. A customer who stops paying simply loses the ability to log in. This is one reason the SaaS model has become so dominant: piracy is essentially impossible when the software never leaves your infrastructure.
For desktop or on-premise software, online activation adds a layer of protection. The software contacts your server during installation to confirm the license is valid, then periodically checks in. If the license expires or gets flagged as stolen, the software can deactivate itself. Hardware locking ties a license to a specific device by reading the machine’s unique identifiers during activation, preventing a single license from being shared across multiple computers.
License management platforms can handle key generation, activation tracking, and compliance monitoring for you. These are worth investigating once you have more than a handful of customers, since manually tracking license keys in a spreadsheet breaks down quickly.
Distribute and Deliver the License
How you deliver the license depends on your distribution channel. For SaaS products, the license terms are typically presented as a clickwrap agreement during account creation: the user checks a box confirming they’ve read and accepted the terms. For downloadable software, the EULA usually appears during the installation process.
If you sell through app stores or marketplaces, the platform often handles license delivery and may impose its own terms on top of yours. Read the platform’s developer agreement carefully, because it may require you to offer refunds, limit your pricing flexibility, or grant the platform certain rights to your software.
For enterprise customers, license delivery is usually part of a sales process. You negotiate terms, sign a contract, and then provision access or send license keys directly. Enterprise deals often include volume discounts, custom support arrangements, and specific data handling commitments that wouldn’t appear in a standard consumer license.
Whatever your channel, make the license terms easy to find after the initial acceptance. Post them on your website, link to them from your application’s settings or help menu, and include them in your documentation. Customers who can’t find the terms they agreed to are more likely to violate them unintentionally.