CODE: Software Licensing — A Developer's Guide

Every piece of software you write, every library you use, and every open-source project you contribute to operates under a software license. Licenses define legal rights and obligations: who can use the software, under what conditions, and what requirements exist for derivative works. Misunderstanding licensing can expose your company to legal liability or prevent you from using valuable open-source code in your product.

Why Software Licensing Matters

When code is created, the author automatically holds copyright over it. Without a license, no one else has the legal right to use, copy, modify, or distribute that code. A software license is the legal mechanism that grants those rights — under specific conditions.

For software developers, licensing matters in two directions:

When you create software:

• What can others do with your code?
• Can they use it in commercial products?
• Must they share their changes?

When you use software:

• What are your obligations when using a library?
• Can you incorporate it into a proprietary product?
• Do you need to publish your source code?

The Two Fundamental Categories

Software licenses divide into two broad families based on a single key question: when someone modifies your code and distributes it, must they share the source?

Software License Categories:

+--------------------+          +--------------------+
|    Permissive      |          |    Copyleft         |
|                    |          |                     |
| Free to use        |          | Free to use         |
| Free to modify     |          | Free to modify      |
| Free to distribute |          | MUST share source   |
| No source required |          | for derivative work |
+--------------------+          +--------------------+
   MIT, BSD, Apache                GPL, LGPL, AGPL

Permissive Licenses

Permissive licenses grant broad rights to use, modify, and distribute software with minimal restrictions. You do not need to share your source code when using permissive-licensed libraries.

This makes permissive licenses ideal for:

• Libraries and frameworks used in commercial products
• Code you want to share broadly with minimal friction
• Infrastructure tools adopted across the industry

MIT License

The MIT License is one of the simplest and most permissive licenses available:

MIT License Permissions:
✓ Commercial use
✓ Modification
✓ Distribution
✓ Private use
✓ Sublicensing

Requirements:
- Include the original copyright notice and license text

No guarantee of warranty

The entire MIT license is fewer than 200 words. Its simplicity and permissiveness have made it the most widely used open-source license. Examples: Node.js, jQuery, React (historically), many npm packages.

BSD Licenses (Berkeley Software Distribution)

BSD licenses are similar to MIT but come in variants:

2-Clause BSD (Simplified BSD):

• Same as MIT in practice
• Must retain copyright notice in source and binary distributions

3-Clause BSD (New BSD):

• Adds a non-endorsement clause: you cannot use the project name to endorse your products
• Must retain copyright in source, binary, and documentation

BSD 2-Clause vs MIT: Functionally equivalent
BSD 3-Clause: Adds: no endorsement using project name

Examples: FreeBSD, OpenBSD, many academic and research codebases.

Apache License 2.0

The Apache License 2.0 is a permissive license with additional features:

Apache 2.0 Additions over MIT/BSD:
- Explicit patent grant: contributors grant you patent rights
- Patent retaliation clause: you lose the license if you sue contributors for patent infringement

This patent grant is significant for commercial software. Apache 2.0 is the preferred license for many corporate-backed open-source projects. Examples: Android, Apache web server, TensorFlow, Kubernetes.

Copyleft Licenses

Copyleft licenses — sometimes called "viral" licenses — require that if you distribute modified versions of the software, you must release those modifications under the same license. The intent is to ensure the software and all improvements remain freely available to the community.

GPL — GNU General Public License

The GPL is the most widely used copyleft license. Its core requirement is often called the "share-alike" condition:

GPL Key Principle:
If you distribute a program that includes GPL-licensed code,
the entire combined work must be distributed under the GPL,
and you MUST provide the source code.

This makes GPL unsuitable for most proprietary commercial products. A company cannot use GPL code in a closed-source product without releasing all their source code.

GPLv2 vs GPLv3:

GPLv2 was released in 1991. GPLv3 was released in 2007 with a key addition: the Tivoization clause.

The Tivoization Problem:
TiVo used the Linux kernel (GPLv2) in their DVRs.
They provided the source code as required by GPLv2,
but modified their hardware to only run TiVo-signed binaries.
Result: Users could get the source but couldn't run modified versions on their hardware.

GPLv3 Response:
Added the anti-Tivoization clause: if you distribute GPLv3 software
on a device, users must be able to install and run modified versions
on that device.

Important: The Linux kernel chose to remain GPLv2 and explicitly
NOT upgrade to GPLv3. The kernel project felt GPLv3's hardware
requirements were too restrictive for embedded use cases.

LGPL — GNU Lesser General Public License

The LGPL was created to address a specific use case: open-source libraries that you want permissively-licensed programs to be able to use, while still keeping the library itself under a share-alike license.

LGPL Core Rule:
- You may LINK to an LGPL library in your proprietary program
- You do NOT need to open-source your proprietary code
- BUT: if you MODIFY the LGPL library itself, those modifications must be shared

LGPL = "Link but don't modify without sharing"

The LGPL is specifically designed for libraries:

Usage Scenario:
Your proprietary app
    |
    | (dynamic link)
    v
LGPL library  ← modifications to THIS must be shared
    (e.g., GCC libraries)

Your proprietary code does NOT need to be shared.

This makes LGPL a practical choice for open-source library authors who want broad adoption while preventing proprietary forks of the library itself.

Examples: Qt (LGPL option), GCC runtime libraries, GNU C Library (glibc).

AGPL — GNU Affero General Public License

The AGPL extends GPL to cover a gap: what about software that runs on a server but is never "distributed"?

The SaaS Loophole:
GPL requires sharing source when you DISTRIBUTE software.
If you run GPL software on a server and offer it as a service (SaaS),
you never "distribute" it — so GPL doesn't require you to share source.

AGPL Closes This:
If users interact with AGPL software over a network,
you must provide them the source code, even without distributing binaries.

AGPL is used by companies and projects that want to prevent commercial cloud providers from taking their open-source code, running it as a service, and not contributing back. Examples: MongoDB (early versions), Grafana AGPL edition.

License Compatibility

Not all open-source licenses can be combined. Understanding compatibility is critical when building a project that uses multiple open-source libraries:

License Compatibility Overview:
+-------------+-----+-------+-------+------+------+------+
|             | MIT | BSD   | Apache| LGPL | GPLv2| GPLv3|
+-------------+-----+-------+-------+------+------+------+
| MIT         |  ✓  |  ✓    |  ✓    |  ✓   |  ✓   |  ✓   |
| BSD 2/3     |  ✓  |  ✓    |  ✓    |  ✓   |  ✓   |  ✓   |
| Apache 2.0  |  ✓  |  ✓    |  ✓    |  ✓   |  ✗   |  ✓   |
| LGPL        |  ✓  |  ✓    |  ✓    |  ✓   |  ✓   |  ✓   |
| GPLv2       |  ✓  |  ✓    |  ✗    |  ✓   |  ✓   |  ✗   |
| GPLv3       |  ✓  |  ✓    |  ✓    |  ✓   |  ✗   |  ✓   |
+-------------+-----+-------+-------+------+------+------+

✓ = Compatible (can be combined in a single work)
✗ = Incompatible (cannot legally be combined)

The Apache 2.0 / GPLv2 incompatibility is a practical concern: some projects cannot use Apache-licensed dependencies because the project is under GPLv2 (like the Linux kernel).

Choosing a License for Your Project

Decision Guide:
+----------------------------------------+
| Do you want others to be able to use   |
| your code in closed-source products?   |
+----------------------------------------+
           |              |
          YES             NO
           |              |
           v              v
+------------------+  +------------------+
| Permissive       |  | Copyleft         |
| MIT / BSD /      |  | GPL / LGPL /     |
| Apache 2.0       |  | AGPL             |
+------------------+  +------------------+
           |              |
           v              v
    Maximum adoption   Ensures code and
    Easy corporate     improvements stay
    adoption           open source

When to choose permissive (MIT/BSD/Apache):

• You want maximum adoption
• You want corporate users to be able to contribute and use freely
• You are building an industry standard or infrastructure

When to choose copyleft (GPL/LGPL/AGPL):

• You want to ensure improvements to your project are shared back
• You are building a library and want to prevent proprietary forks (LGPL)
• You are offering software as a service and want to close the SaaS loophole (AGPL)

Practical Rules for Engineers

Engineering Checklist for Licenses:
1. Before using any library: check its license
2. GPL code cannot go into proprietary products (without commercial license)
3. LGPL code can be dynamically linked into proprietary code
4. MIT/BSD/Apache: use freely, keep copyright notices
5. Document all third-party licenses in your project
6. When in doubt: ask your legal team
7. The Linux kernel is GPLv2 (NOT GPLv3)

License Identifiers (SPDX)

The Software Package Data Exchange (SPDX) project maintains standardized identifiers for licenses:

Modern open-source projects include SPDX identifiers in their source files:

// SPDX-License-Identifier: MIT
// Copyright (c) 2025 Your Name

Conclusion

Software licensing is not a topic engineers can safely ignore. Every library you include in your project, every tool you use in your build chain, and every open-source repository you clone has a license with legal implications.

The key distinctions are simple:

• Permissive licenses (MIT, BSD, Apache) impose minimal restrictions and allow use in proprietary products.
• Copyleft licenses (GPL, LGPL, AGPL) require that modifications be shared under the same license.
• LGPL is the middle ground for libraries: link freely, but share modifications to the library itself.

Understanding these distinctions protects you, your team, and your organization from unintended legal exposure and enables you to choose the right license when releasing your own work.