The GPL Proxy Delegation Trick Nobody is Talking About

There's a mechanism buried in the GNU General Public License that almost nobody talks about, and it's about to become one of the most important tools in open-source licensing. It's called proxy delegation, and it lives in Section 14 of the GPL.

Here's the short version: when you release software under the GPL, you can designate a proxy who has the authority to decide which future versions of the GPL your software can be used under. This proxy can upgrade the license terms for your software without your direct involvement.

Sounds obscure. Sounds academic. But in a world where AI model licensing is becoming the most contentious issue in tech, this mechanism is incredibly relevant.

How Section 14 Actually Works

The GPL has always had the concept of "or any later version." When you release code under GPL v2, you can specify "GPL v2 or any later version." This means that anyone using your code can choose to follow the terms of GPL v2, GPL v3, or whatever future version the Free Software Foundation publishes.

Section 14 of GPL v3 takes this further. It allows you to designate a proxy (a person or organization) who can decide which future versions of the GPL apply to your software. The original author doesn't have to make this decision themselves. They delegate it.

Why would you want this? Several reasons.

If you're a large project with hundreds of contributors, getting consensus on a license upgrade is nearly impossible. The Linux kernel is famously stuck on GPL v2 partly because relicensing requires agreement from thousands of contributors. A proxy delegation would have solved this upfront.

If you're a foundation managing an open-source project, proxy delegation lets you adapt licensing to future conditions that the original authors couldn't have anticipated. The foundation can respond to new legal landscapes, new business models, or new threats without going back to every contributor.

If you're an individual developer who doesn't want to stay involved with a project forever, delegating license decisions to a trusted organization means the project can evolve legally even after you've moved on.

Why This Matters Now

The open-source licensing world is in crisis, and most people in the industry haven't fully processed it.

The problem is AI. Specifically, the question of whether training an AI model on open-source code constitutes a use that's covered by the license. And if it is covered, what obligations does the model creator have?

GPL says if you distribute derivative works, you must share the source under the same license. But is an AI model trained on GPL code a derivative work? The legal answer is genuinely unclear. The model's weights don't contain the original source code in any recognizable form. But the model's behavior was shaped by that code. It can reproduce patterns, functions, and sometimes exact snippets from the training data.

Current licenses weren't designed for this scenario. GPL v2 was written in 1991. GPL v3 was written in 2007. Neither anticipated a world where code would be used not as software but as training input for a statistical model that generates new code.

This is exactly the kind of situation where proxy delegation becomes powerful. If a project designated the Free Software Foundation as its proxy, the FSF could publish a GPL v4 that explicitly addresses AI training. And every project using proxy delegation would automatically be covered by those new terms.

Without proxy delegation, updating license terms requires going back to every contributor. For projects with thousands of contributors, many of whom have moved on or are unreachable, this is effectively impossible. The code is locked into license terms that don't address the most pressing question in open-source today.

The AI Model Licensing Connection

Now here's where this gets really interesting. The proxy delegation concept doesn't just apply to code licenses. It could be adapted for AI model licenses.

The AI model licensing landscape is a mess. Some models are released under Apache 2.0. Some use custom licenses like Llama's community license. Some use new purpose-built licenses like RAIL. There's no consensus, and the terms vary wildly.

The problem with AI model licenses is similar to the problem with code licenses before proxy delegation. Nobody knows what the future holds. Today's license terms might be fine. But what happens when a new use case emerges that the license didn't anticipate? What happens when regulation changes the legal landscape?

Imagine if popular AI models were released under licenses that included proxy delegation. A trusted organization (maybe the Linux Foundation, maybe a new AI-focused foundation) could be designated as the proxy with authority to update terms in response to new developments.

Model released under a permissive license today, but tomorrow a government mandates specific safety requirements for AI models? The proxy updates the license terms to include those requirements, and all models using proxy delegation are automatically covered.

This isn't a hypothetical. AI regulation is coming. The EU AI Act is already law. The US is working on its own framework. License terms for AI models will need to evolve as the regulatory landscape evolves. Proxy delegation provides a mechanism for that evolution without requiring the original model creators to individually update every release.

Why Nobody Is Doing This Yet

Given how useful proxy delegation is, why isn't it more widely used?

Trust is the first barrier. Delegating license authority to a proxy means trusting that proxy to make decisions aligned with your values. Not everyone trusts the FSF. Not everyone would trust a hypothetical AI licensing foundation. And there's no good mechanism for accountability if the proxy makes decisions the community disagrees with.

Awareness is the second barrier. Most developers don't know Section 14 exists. License selection is usually a quick decision ("MIT or Apache? Whatever") rather than a strategic choice. The nuances of proxy delegation don't enter the conversation.

Precedent is the third barrier. There aren't many high-profile examples of proxy delegation being used successfully. Without proof that it works in practice, people are hesitant to try it. It's a chicken-and-egg problem.

Complexity is the fourth. Adding proxy delegation to your license requires careful legal drafting. You need to specify the proxy, the scope of their authority, and any constraints on what changes they can make. This is lawyer territory, and most open-source developers don't have lawyers.

What Should Happen

A few things need to happen for proxy delegation to reach its potential.

Major open-source projects should start using it. If even one high-profile project designates a proxy for license upgrades, it normalizes the practice and provides a template for others to follow.

The AI model licensing community needs to adopt the concept. The current approach of inventing a new custom license for every model release is unsustainable. A standard license with proxy delegation for future updates would provide both flexibility and consistency.

Trusted organizations need to step up. The Linux Foundation, Apache Foundation, OSI, or a new purpose-built organization needs to be willing to serve as a proxy and to develop governance structures that give the community confidence in their decision-making.

Legal tooling needs to improve. Templates, guides, and automated tools for implementing proxy delegation would lower the barrier to adoption.

The Bigger Point

Open-source licensing is infrastructure. Like roads and bridges, it works best when nobody has to think about it. But unlike roads and bridges, software licenses can't be patched after deployment. Once you've released code under a specific license, changing those terms is extremely difficult.

Proxy delegation is the best mechanism we have for building adaptability into licensing infrastructure. It acknowledges that the future is unpredictable and provides a structured way to respond to changes without the impossible task of retroactive relicensing.

The AI era is creating licensing challenges that the open-source movement has never faced before. The tools to address those challenges already exist in the GPL. We just need to start using them.

Section 14 is sitting right there. Waiting. And the longer we ignore it, the messier the AI licensing landscape is going to get.