OSS Licenses

calendar Oct 17, 2026  ·
Share on: linkedin copy

OSS Licenses

An OSS (Open Source Software) license is a legal agreement that defines who may use, modify, redistribute, and embed the software under what conditions. When you incorporate OSS into your service or publish a derivative work, you are legally obligated to comply with the license terms.

Even when a repository on GitHub ships a LICENSE file, the conditions around commercial use, obligations to publish modified source, and the presence of patent clauses vary significantly by license. This page summarizes the main licenses adopted by the OSS projects featured on this site, including their key features, obligations, and official references.

Three Categories of OSS Licenses

OSS licenses are broadly classified into three groups based on how they treat derivative works.

Category Summary Representative Licenses
Permissive Only requires preserving copyright notice and license text. No obligation to publish modified source. Easy to embed in commercial products. Apache-2.0 / MIT / BSD
Weak Copyleft Modified source for licensed files must be published, but obligations do not propagate to separately-linked proprietary code. MPL-2.0 / LGPL
Strong Copyleft Entire derivative work is subject to the license. Source publication obligations extend to modified and linked code. GPL and AGPL differ in whether SaaS use triggers propagation. GPL / AGPL

Official Reference Sites

For authoritative information, refer to the following official sites.

Apache License 2.0

Category: Permissive

Overview: A permissive license drafted by the Apache Software Foundation. Commercial use, modification, and redistribution are almost unrestricted. Key features compared to MIT/BSD are the explicit patent license grant and the automatic termination of license upon patent litigation. Adopted as an industry standard by Google, Apple, Amazon, and many others.

Permissions: Commercial use / Modification / Distribution / Sublicense / Private use / Explicit patent grant

Conditions:

  • Preserve copyright notice and full license text
  • State changes if modified (ship NOTICE file)
  • Trademark use requires separate permission

Limitations: No warranty / No liability / No trademark use

Projects on this site using Apache-2.0: Harbor / OpenSearch / Backstage / VictoriaMetrics / gRPC-Java / k0s / kaniko / Kubeshark / VerneMQ / Cloud Robotics Core

Official References:

MIT License

Category: Permissive

Overview: The simplest license, originating at MIT. The text is short — commercial use, modification, and redistribution are permitted provided the copyright notice and license text are preserved. The biggest difference from Apache-2.0 is that MIT does not include patent clauses, so patent risk must be managed separately.

Permissions: Commercial use / Modification / Distribution / Sublicense / Private use

Conditions:

  • Preserve copyright notice and full license text

Limitations: No warranty / No liability / No patent clause

Projects on this site using MIT: Patroni / SigNoz (core) / InfluxDB (v1 series)

Official References:

BSD License (2-Clause / 3-Clause)

Category: Permissive

Overview: Originated at UC Berkeley. The 2-Clause (Simplified) and 3-Clause (New / Modified) variants are the most common. The 3-Clause adds a "no endorsement using contributor names" clause. Many companies, including NVIDIA, adopt their own BSD-style variants.

Permissions: Commercial use / Modification / Distribution / Private use

Conditions:

  • Preserve copyright notice and full license text
  • (3-Clause only) No endorsement using contributor names

Limitations: No warranty / No liability / No patent clause

Projects on this site using BSD: Megatron-LM (NVIDIA's own BSD-style variant)

Official References:

MPL 2.0 (Mozilla Public License 2.0)

Category: Weak Copyleft

Overview: A weak-copyleft license drafted by the Mozilla Foundation. Copyleft applies per-file, so modifications to MPL files must be published as source, but obligations do not propagate to separately-linked proprietary code. Designed to be easy to combine with commercial products.

Permissions: Commercial use / Modification / Distribution / Sublicense / Private use / Patent use

Conditions:

  • Publish source for modified MPL files
  • Preserve copyright notice and license text
  • When combining with code under a different license in the same binary, each file retains its own license

Limitations: No warranty / No liability / No trademark use

Projects on this site using MPL-2.0: Syncthing / OpenGFW

Official References:

LGPL (GNU Lesser General Public License)

Category: Weak Copyleft

Overview: A library-oriented license that relaxes GPL's constraints. When linking dynamically to an LGPL library, GPL propagation to proprietary applications does not occur. However, modifying the LGPL library itself requires publishing those modifications. Static linking or build-in usage triggers additional obligations.

Permissions: Commercial use / Modification / Distribution / Dynamic linking

Conditions:

  • Publish source for modifications to the LGPL library itself
  • Provide end-users with a mechanism to replace the LGPL portion (dynamic linking or object code)
  • Preserve copyright notice and license text

Limitations: No warranty / No liability

Official References:

GPL (GNU General Public License)

Category: Strong Copyleft

Overview: A strong-copyleft license drafted by the Free Software Foundation. GPL propagates to all binaries that link, embed, or derive from GPL code, triggering a source disclosure obligation upon redistribution. No distribution obligation applies for purely internal use. Compared to v2, v3 adds patent clauses and DRM prohibition clauses.

Permissions: Commercial use / Modification / Distribution / Private use

Conditions:

  • Publish source of the entire derivative work (upon redistribution)
  • Preserve copyright notice and license text
  • Redistribute under the same license (GPL)

Limitations: No warranty / No liability / No sublicensing / Restrictions on combination with proprietary software

Projects on this site using GPL: Smile (requires separate dual-license agreement for commercial use)

Official References:

AGPL v3 (GNU Affero General Public License)

Category: Strong Copyleft + SaaS Propagation

Overview: Extends GPL v3 so that providing the software as a network service also triggers source disclosure obligations. When operating a SaaS with modified AGPL code, users must receive the modified source. AGPL is one of the licenses most strongly avoided by commercial SaaS providers.

Permissions: Commercial use / Modification / Distribution / Private use

Conditions:

  • Publish source of the entire derivative work
  • Source disclosure obligation also applies to network-provided services
  • Redistribute under the same license (AGPL)

Limitations: No warranty / No liability / No sublicensing

Official References:

CC-BY-SA 4.0 (Creative Commons Attribution-ShareAlike)

Category: ShareAlike (for documents / content)

Overview: A license used for documents, images, and content rather than code. Obligates attribution of the original author and requires licensing modified/derivative works under the same CC-BY-SA. Commonly applied to the documentation portions of OSS projects (e.g., k0s, Kubernetes docs).

Permissions: Commercial use / Modification / Distribution / Adaptation

Conditions:

  • Attribution (BY)
  • Modified/derivative works must also be published under CC-BY-SA 4.0 (SA = ShareAlike)
  • Explicit license notice with link

Limitations: No warranty / Prohibition of technological restrictions that impede reuse

Projects on this site using CC-BY-SA: k0s (docs/ only)

Official References:

Practical License Selection Guide

1. When planning to embed into a commercial product

Recommended: Apache-2.0 / MIT / BSD / MPL-2.0

These coexist easily with proprietary code and can be selected according to business requirements such as patent risk coverage (Apache-2.0) or per-file copyleft (MPL-2.0).

2. When you want to preserve OSS lineage / encourage derivative work disclosure

Recommended: GPL / LGPL / AGPL

Choose based on the desired strength of copyleft. AGPL is effective when you want to encourage OSS contribution from SaaS providers as well.

3. Licenses that SaaS providers should be most cautious about

  • AGPL: Embedding modified AGPL code in a SaaS triggers an obligation to provide the modified source to end-users
  • GPL: Redistributing your own product propagates GPL to the whole product
  • Business Source Licenses (BSL / SSPL): Strictly speaking not OSI-approved and therefore not OSS, but adoption by projects migrating from OSS has grown in recent years

4. Mixing multiple licenses (License Compatibility)

When combining OSS, you must check license compatibility. For example, GPL and Apache-2.0 are compatible only in one direction (Apache→GPLv3 only) due to patent clause differences.

5. Checkpoints when using OSS internally

  1. License identification: Asset management (SBOM) based on SPDX identifiers
  2. Obligation inventory: Copyright notices / NOTICE / change history / source publication, etc.
  3. Patent risk: Non-Apache-2.0 licenses lack patent clauses; investigate separately
  4. Copyleft propagation check: Validate your product's integration pattern
  5. Dual-license check: Some OSS require a separate commercial agreement for commercial use (e.g., Smile)

Reference: License Management Tools

Disclaimer

The content on this page is reference information intended to help you understand each license. For legally binding information, refer to each license's official reference. For actual commercial use, modification, or redistribution, we recommend consulting your legal team or a specialist.

Recommended Reading