In October, the OSI hosted the State of the Source Track at All Things Open designed to connect developers with the big policy conversations shaping our ecosystem. Pamela Chestek, emeritus OSI Board member, opened the track with Licensing 201, an advanced but practical look at how licenses get approved and why the right choice matters for community health.

Licensing 201

This essential session is an advanced primer on Open Source licenses and why one should care, which are most commonly used and why. Also included are insights into the OSI license process and who are involved in considering and approving new licenses based on the Open Source Definition, plus which have been approved in the last five years. Topics include challenges, successes, best practices, operational policies, and resources.

Video summary

Pamela Chestek:** ** All right, as Deb mentioned, thank you very much for the introduction. A little about myself: I’m a former board member of the Open Source Initiative. My term on the board has ended, and I’m now a lawyer in private practice, focusing on trademarks and open source software licensing. I currently live in California but used to live in Raleigh, so it’s nice to be back here for a visit.

We’re calling this session “Open Source 201” because we’re assuming that everyone here already has a good understanding of open source licensing—so this isn’t 101. That said, we’ll start with a short refresher to make sure we’re all on the same page.

---

Agenda

We’ll begin with a quick review of terminology and basic concepts, then talk about the current state of open source licensing—including some recently approved licenses, current issues, and emerging topics like AI licensing. I’ll also explain the license review process—how it works and what to expect if you want your license approved by the OSI.

---

Open Source Definition Refresher

Here are the ten elements of the Open Source Definition. You don’t need to memorize them all; I certainly haven’t. But there are three that tend to come up most often when we review licenses—they’re the ones that most frequently cause problems:

1. Not granting sufficient rights to derivative works.
2. Discrimination against persons, groups, or fields of endeavor.
3. Restrictions on other software.

For example, any license that says “non-commercial use only” will never be approved by the Open Source Initiative, because that discriminates against commercial users—a violation of the definition.

---

Basic Vocabulary

Let’s go through a few key terms.

Copyleft – This is the philosophy underlying many open source licenses. There are two general categories of licenses: permissive and copyleft.

• Permissive licenses let you do almost anything with the software.
• Copyleft licenses add a condition: if you modify or combine the software with others, your modified work must also be distributed under the same license.

It’s a mechanism to ensure that improvements remain available to everyone—a “rising tide lifts all boats” philosophy.

BSD License – The Berkeley Software Distribution license. It’s one of the oldest open source licenses, very permissive, and exists in several variants because certain clauses have been dropped over time. The wording is old-fashioned, but it’s still recognized and widely used.

Model Weights – A newer term relevant to AI. Model weights are the numerical values assigned to nodes in an AI model, determining how the model processes information and produces output. Adjusting these weights changes the model’s behavior.

Defensive Termination – A clause that’s appeared in newer licenses. It says if you use this software and then sue someone for patent infringement, your license terminates. It’s designed to discourage patent lawsuits within the open source community.

---

Current State of Open Source Licensing

It was interesting to revisit some of the licenses we reviewed recently.

From the State of Open Source Report, in 2025 the top reason people said they use open source was “no license cost.” In 2023, it was “functionality,” but that flipped in 2024–2025.

Top support challenges include:

1. Updates and patches
2. Meeting security and compliance policies
3. Maintaining end-of-life versions

---

Recently Approved Licenses

These are some of the licenses recently approved by OSI. Most are older or specialized:

• Los Alamos National Labs BSD-3 Variant
• CDDL 1.1
• OSC License 1.1 (German) – Created for use by the city of Solingen, Germany. There had been longstanding uncertainty about whether the MIT license’s limitation of liability clause was enforceable under German law. This license was crafted to address that concern.
• Blue Oak Model License 1.0.0 – About five years old, recently submitted and approved. Somewhat controversial but valid.

Writing a good license is extremely difficult. Once it’s published and software is released under it, you can’t easily change it. That’s why the review process is so careful. Reviewers in the OSI process are some of the best contract analysts I’ve ever worked with—they find loopholes, edge cases, and ensure the license truly aligns with open source principles.

---

Licenses Under Review and Withdrawn

Under Review:** ** The ModelGo family of licenses—designed for AI models specifically. They’re being rewritten several times to get them right. AI licenses are complex and need precise language because AI systems are very different from traditional software.

Withdrawn Licenses:

• MGB 1.0 License – Proposed by Massachusetts General Brigham Hospital. They needed a healthcare-specific license with special liability disclaimers but couldn’t finalize a workable version.
• PPPL BSD-3 License – Duplicated an existing license, so it was withdrawn.
• Irrevocable MIT License – Attempted to prevent relicensing or removing repositories, but included problematic terms (like requiring perpetual hosting). It wasn’t workable as drafted.

Most submissions are well-meaning—people want to strengthen the open source ecosystem—but translating those goals into sound legal text is hard.

---

Key Challenges in Open Source Licensing

1. Complexity – Modern codebases use thousands of third-party components, often pulled from registries like npm, PyPI, and RubyGems. These can introduce security risks.

2. Attribution – Every open source license requires attribution and inclusion of the license text. Manually tracking thousands of dependencies is nearly impossible.

3. License Compatibility – A persistent issue. The main question: can you comply with all applicable licenses at once?

For example, the GPLv2 and GPLv3 licenses are incompatible with each other—you can’t merge software under both because each requires the combined work to be distributed under its own terms. The same applies between GPLv2 and the Apache License (according to the Free Software Foundation).

There’s no definitive court ruling on these issues in the U.S.; the community operates largely on shared norms and interpretations.

---

Legal Developments

One major case is Software Freedom Conservancy (SFC) vs. Vizio. SFC sued Vizio for failing to provide source code for GPLv2 and LGPLv2 components in their televisions. Uniquely, SFC sued as a purchaser of the TV—not a copyright holder—claiming they were a third-party beneficiary of the GPL license terms.

They’re seeking only the source code, not damages. The case will go to trial in January 2026. If successful, it could significantly expand who has standing to enforce open source licenses.

---

AI and Open Source Licensing

AI introduces new challenges. The Open Source Initiative recently defined “Open Source AI” as an AI system—and “system” is key—made available under terms that grant the freedoms to use, study, modify, and share it.

However, OSI emphasizes that this must apply to the entire system—not just the model weights or code fragments. Many entities today release “open models” that share only parameters, not the training data or code, which doesn’t meet the OSI’s definition.

To qualify as Open Source AI:

• The full system must be available.
• Data information must be provided in enough detail for others to recreate the system.
• Code must be under OSI-approved licenses.
• Model parameters must be shared under OSI-compliant terms.

Using open licenses is necessary but not sufficient—you must also provide enough transparency for others to reproduce or modify the system.

---

Other Trends and Challenges

In the broader landscape, we’re seeing new attempts to reshape open source for particular goals:

• Ethical Source Licenses and Responsible AI (RAIL) Licenses aim to restrict harmful or unethical uses (e.g., military, medical, or nuclear applications). While well-intentioned, these violate the Open Source Definition because they limit fields of endeavor. They also risk shifting liability to end users.
• Commercial Restrictions (like Meta’s Llama license) reintroduce non-commercial clauses, which are fundamentally incompatible with open source principles.

Despite these challenges, OSI continues to emphasize that open source licensing must remain truly open—free of discrimination, transparent, and reusable by anyone.

---

License Review Considerations

When reviewing a license, OSI looks for:

• Reusability by anyone, not just the license creator.
• No special privileges for the original author.
• Clarity and precision—legal writing must be exact.
• Compliance must be possible in practice.
• The license must fill a genuine gap not already covered by existing licenses.

Because human creativity has no limits, the OSI can’t list every unacceptable provision—but its guiding principle is simple:

Does this license advance or inhibit the adoption and use of open source software?