Software Licensing: OSS Licenses, IP Protection, and Licensing Models [2026]

A single wrong license choice can force you to open-source your product's codebase. Using a GPL-licensed library in a commercial application without understanding the implications can create legal obligations that are expensive to unwind. A poorly drafted SaaS EULA can expose the business to liability that insurance cannot cover.

Software licensing sits at the intersection of engineering decisions and legal obligations. Most engineering teams understand neither well enough — and most legal teams understand the engineering context poorly enough — that the gap between them creates real risk. This guide closes that gap: clear explanations of OSS license mechanics, commercial licensing models, IP protection strategies, and the EULA elements that matter for SaaS businesses.

Software Licensing: Open Source License Landscape

Open source licenses divide into two families: copyleft and permissive. Understanding this distinction is the most important software licensing concept for engineers and product teams.

Permissive licenses allow the licensed code to be used in any project — proprietary or open source — with minimal restrictions. The primary obligation is attribution: preserve the copyright notice and license text. You can incorporate MIT-licensed code into a commercial product, distribute the binary, and never release your source code.

Copyleft licenses require that derivative works be distributed under the same license. The "viral" effect: if you incorporate GPL-licensed code into your software and distribute it, you must distribute your software's source code under the GPL as well. The strength of the copyleft effect varies by license.

MIT License

MIT is the most widely used permissive license on GitHub. It grants unrestricted use, modification, and distribution rights — including commercial use — with one condition: the original copyright notice and license text must be preserved in any distribution.

For commercial software: MIT-licensed dependencies are almost always safe to use. You can include a MIT-licensed library in a proprietary product, ship the compiled binary, and retain your source code as a trade secret. The only obligation is a copyright notice in your distribution (typically in a LICENSE file or about screen).

MIT is appropriate for your own open-source projects when you want maximum adoption with minimal friction. React, Vue.js, and Babel are MIT-licensed, which is a significant factor in their ecosystem growth.

Apache 2.0

Apache 2.0 is a permissive license with one key addition over MIT: an explicit patent grant. Contributors to Apache 2.0-licensed projects automatically license any patents they hold that cover their contribution. This patent peace provision is why major enterprises (Google, Apache Software Foundation, Microsoft) favor Apache 2.0 for projects they contribute to — it reduces patent litigation risk for users.

Apache 2.0 also requires documenting modifications and preserving NOTICE files. These obligations are straightforward but matter for compliance tracking.

Projects using Apache 2.0: Kubernetes, TensorFlow, Android, Apache Kafka.

GPL v2 and v3

GPL is the canonical copyleft license and the license of the Linux kernel (GPLv2) and GNU tools (GPLv3). The copyleft requirement is strong: software that incorporates GPL code and is distributed to external parties must make its complete source code available under the GPL.

The critical word is "distributed." Running GPL code on a server to provide a web service does not trigger the copyleft obligation (this gap is sometimes called the "ASP loophole" — the Affero GPL addresses it). But shipping a product with GPL code — as a downloaded application, embedded firmware, or SaaS software installed on-premise — does.

GPLv2 vs GPLv3: GPLv3 adds tivoization prevention (hardware manufacturers cannot prevent users from running modified GPL software on their hardware), an explicit patent grant, and enhanced compatibility provisions. For most software development contexts, the practical difference is minor, but some organizations specifically require GPLv2-only (including the Linux kernel) due to GPLv3's additional provisions.

Commercial risk: Including GPL code in a proprietary commercial product without releasing source is a license violation. The remedy typically requires either releasing the source, removing the GPL code, or negotiating a commercial license with the copyright holder. The cost of that situation — legal fees, engineering work, and reputational damage — is why compliance matters.

LGPL

The Lesser GPL was designed for libraries. Unlike GPL, LGPL does not require that software dynamically linking to an LGPL library release its own source code. However, modifications to the LGPL library itself must remain LGPL, and users must be able to update the library.

If your commercial product links to an LGPL library as an external dependency (not statically compiled in), you are generally safe to keep your own code proprietary. This distinction matters: glibc and Qt (in some versions) use LGPL, which allows commercial software to use them without triggering full copyleft obligations.

AGPL

AGPL closes the ASP loophole. It extends GPL's copyleft requirement to cover network use: if you provide a service using AGPL-licensed software over a network, you must make the complete source code available to your users.

This matters significantly for SaaS businesses. Using AGPL-licensed server software as the foundation for a commercial SaaS product creates an obligation to release that product's source code. Cloud providers that want to commercialize open-source software without contributing back were the target of AGPL's design — MongoDB (pre-4.4), Grafana, and Nextcloud used AGPL specifically to prevent this.

BSL and SSPL

Newer license types have emerged as open-source companies sought protection from cloud provider commercialization:

Business Source License (BSL/BUSL): The software has production use restrictions for a specified period (typically 4 years), after which it converts to an open-source license (usually Apache 2.0 or GPL). HashiCorp's Terraform moved to BSL, as did MariaDB and others. BSL is technically not an "open source" license under the OSI definition, which has created community controversy.

Server Side Public License (SSPL): MongoDB's AGPL-inspired license that extends the copyleft requirement to all software used in delivering a service built on SSPL-licensed software. More aggressive than AGPL in its copyleft scope. Rejected by OSI as a non-open-source license.

Understanding these newer licenses is important for teams evaluating infrastructure dependencies that may have recently relicensed.

Commercial Licensing Models

Beyond OSS licenses, commercial software uses several distinct licensing structures.

Perpetual License

One-time payment for indefinite use rights. Standard for traditional desktop software and on-premise enterprise software. Maintenance and updates typically sold separately (15–20% of license price annually). Predictable one-time cost for the customer; unpredictable long-term revenue for the vendor.

Perpetual licensing has declined with the shift to SaaS but remains relevant for compliance-sensitive sectors (government, defense, healthcare infrastructure) that require on-premise deployment.

Subscription License

Time-limited use rights with recurring payment. The dominant model for SaaS products. Lower upfront cost, predictable recurring revenue (ARR/MRR), easier to update and deprecate, creates ongoing customer relationship.

Subscription pricing may be: per seat (per user), per usage (API calls, data volume, compute), or flat-rate (unlimited users up to a tier). The choice of metric affects adoption dynamics and revenue scalability.

Usage-Based / Consumption Pricing

Charges based on actual use: API calls, data processed, storage consumed, messages sent. AWS, Stripe, Twilio, and Datadog use variants of this model. Low entry barrier (pay nothing until you use it), scales naturally with customer growth, but creates revenue unpredictability and requires careful margin modeling.

Open Core

Core functionality is open source; advanced enterprise features are commercial. GitLab CE vs EE, Elastic Open Source vs Elastic Cloud, Redis Community vs Redis Enterprise. The business model requires careful calibration: the free tier must be useful enough to drive adoption, while the commercial tier must offer features worth paying for.

The most common open core failure mode: giving away too much, leaving insufficient reason to pay. The second most common: giving away too little, preventing adoption entirely.

SaaS EULA: Key Components

A SaaS EULA (End User License Agreement) or Terms of Service governs the relationship between the service provider and the customer. Poorly drafted SaaS agreements create ambiguity that becomes expensive when disputes arise.

Service level commitments: Define the uptime guarantee (SLA), how uptime is measured, the remedies for SLA violations (typically service credits), and what circumstances are excluded from SLA calculations (scheduled maintenance, force majeure, customer-caused outages). An SLA without a defined remedy is marketing, not a commitment.

Data ownership and portability: Customers' data belongs to them. The EULA should be explicit that the provider does not claim ownership of customer data, how customer data is processed and protected, and what happens to data upon contract termination (export window, deletion timeline). Vendor lock-in disputes often originate in ambiguous data portability provisions.

Intellectual property: The provider owns the platform; the customer owns their data and any content they create. Neither party should be able to claim ownership of the other's IP through a EULA provision. Spell this out explicitly.

Liability limitation: Commercial SaaS agreements typically limit the provider's aggregate liability to 12 months of fees paid. Without a liability cap, a service outage that affects a large customer could expose the provider to damages that exceed the value of the contract.

Acceptable use policy (AUP): Define prohibited uses (illegal activity, security attacks, data scraping) and the provider's right to suspend service for AUP violations. AUP violations are the most common legitimate reason for service termination, and the suspension mechanism should be defined in the contract, not improvised.

Privacy and data processing: GDPR requires a Data Processing Agreement (DPA) for processors handling EU personal data. CCPA creates similar requirements for California residents. If your service processes any personal data, the EULA or an associated DPA must specify lawful basis for processing, sub-processor disclosure, and data subject rights fulfillment obligations.

Intellectual Property Protection

Copyright

Software is protected by copyright automatically from the moment it is created. No registration is required (in most jurisdictions), though registration provides evidentiary advantages in litigation. Copyright protects the expression — the specific code — not the underlying idea, algorithm, or concept.

API design's copyright status is contested following Oracle v. Google. The Supreme Court's 2021 ruling found Google's use of Java APIs in Android to be fair use, but did not resolve the general question of whether APIs are copyrightable. Teams building compatible reimplementations of existing APIs should consult legal counsel.

Best practices: include copyright notices in source files (// Copyright 2026 Smart Maple. All rights reserved.), document ownership of work created by contractors or vendors, and ensure employment agreements include IP assignment clauses for work created during employment.

Trade Secrets

Source code not intended for distribution can be protected as a trade secret. Unlike copyright or patents, trade secret protection has no expiration — it persists as long as the information remains confidential. The obligation is to take reasonable measures to maintain confidentiality: access controls, NDAs, and security policies.

Trade secret protection is often more practical for proprietary algorithms and architectural patterns than patent protection, because patents require public disclosure. A proprietary recommendation algorithm protected as a trade secret does not need to be disclosed to anyone; a patented algorithm is published in the patent application.

Patents

Software patents protect the functional approach — the technical solution to a technical problem — rather than the specific code. In the United States, software patents are available for processes implemented in software that produce a technical result. In Europe and most other jurisdictions, the scope is narrower: software must have a "technical character" to be patentable.

Patent protection is expensive: $10,000–$50,000+ per patent for prosecution, maintenance fees, and potential litigation. The 20-year protection period is substantial, but the prior art search, prosecution timeline (2–3 years), and public disclosure requirements make patents appropriate only for genuinely novel technical approaches with significant commercial value.

For most software companies, trade secret protection (for proprietary core algorithms) plus copyright (for code and documentation) is a more practical IP protection strategy than active patent prosecution.

License Compliance Tools

Managing license obligations across a project with hundreds of dependencies requires tooling.

FOSSA: Automated dependency scanning with license identification, copyleft contagion analysis, and SBOM (Software Bill of Materials) generation. Integrates with CI/CD to block merges that introduce incompatible licenses. Enterprise-grade compliance reporting for customers who require it.

Snyk License Compliance: Combines security vulnerability scanning with license risk identification. Useful for teams already using Snyk for security who want to add license compliance without a separate tool.

FOSSology: Open-source license scanning tool that analyzes source files for license notices and copyright statements. Suitable for teams that want an on-premise solution and full control over the scanning infrastructure.

TLDR Legal (tldr.legal): Not an automated tool, but a plain-English summary of common open-source license terms. Useful for quick reference when evaluating a dependency.

License compliance tooling should be integrated into the dependency management process, not run as a periodic audit. By the time a license incompatibility is discovered in an audit, the codebase has usually been built around the affected dependency for months.

Outsourced Development IP Ownership

When software is developed by external contractors or agencies, IP ownership must be explicitly contractual. Leaving ownership ambiguous creates disputes when the working relationship ends.

Three common arrangements:

Work-for-hire: The hiring party is the statutory author. All IP belongs to the hiring party from creation. Works made by employees within the scope of employment are automatically work-for-hire in the United States (different rules apply in other jurisdictions). For contractors, work-for-hire status requires an explicit written agreement.

IP assignment: The contractor creates the work and immediately assigns all rights to the client via an IP assignment agreement. Functionally similar to work-for-hire but more explicit and portable across jurisdictions.

License grant: The contractor retains ownership but grants the client a license to use the work. Appropriate when the contractor builds general-purpose tools or frameworks that they want to reuse across clients. The license terms (exclusivity, scope, sublicensing rights) must be precisely defined.

Critical distinction: background IP (existing tools, libraries, frameworks the contractor brings to the project) vs. foreground IP (work created specifically for this project). Background IP typically cannot be assigned without the contractor losing reusable assets; foreground IP should be assigned. The contract must distinguish clearly.

Conclusion

Software licensing decisions have legal and commercial consequences that compound over time. A permissive license choice enables commercial adoption but limits your ability to control downstream use. A copyleft dependency choice simplifies procurement but creates source disclosure obligations. A weak EULA creates liability exposure that could exceed revenue in an adverse scenario.

The engineers and product managers who understand license mechanics are in a better position to make these decisions than those who treat licensing as a legal department problem. Legal counsel is essential for drafting, reviewing, and litigating — but the technical understanding of what code does and how dependencies work is engineering knowledge, and the licensing decisions that flow from it benefit from engineering judgment.

Smart Maple advises software development teams on licensing strategy, dependency compliance, and IP protection as part of broader software architecture and product development engagements.