Stephen O’Grady’s State of Open Source Licensing in 2026 at RedMonk is essential reading. The headline finding — that the long shift from copyleft to permissive licensing has continued, with Apache and MIT consolidating their dominance among the survivors — surprises no one who has been watching the space. The interesting question, as always, is what the data leaves out.

The data leaves out PostgreSQL.

PostgreSQL is not in any of those charts. It predates the package-registry era that deps.dev measures, and it isn’t an npm or Maven artifact. But it is, by any reasonable measure, one of the most successful permissively-licensed projects in the history of the field. RDS for PostgreSQL, Aurora, Cloud SQL, and Azure Database for PostgreSQL together generate millions upon millions of dollars in annual revenue. None of that revenue is captured by the project, by its contributors, or by anyone with the standing to influence the license. That last clause is the interesting part, and it’s the subject of this post.

A short legal vocabulary

Three terms first. The post will use them without further apology.

A license is permission to use someone else’s copyrighted work. The owner says: you may do these things with my work, under these conditions. The license does not transfer ownership.

A copyright assignment is an actual transfer of ownership. The original author signs a paper that says: I no longer own this; the FSF (or the Apache Software Foundation, or my employer) owns it now. After assignment, the assignor has no more rights in the work than a stranger does.

A Contributor License Agreement (CLA) is a document a project requires every contributor to sign, granting the project (or its sponsoring foundation) a broad license to use, sublicense, and relicense the contribution. A CLA is a license, not an assignment, but it’s broad enough that for most practical purposes it functions like one.

PostgreSQL has none of these mechanisms. Not assignment, not a CLA, not even the lightweight Developer Certificate of Origin that Linux uses. Most projects of comparable scale have at least one. PostgreSQL has none. This will matter.

What “permissive” actually means here

The PostgreSQL License is its own license — not BSD-2-Clause, not MIT, but a close relative of both. It is one of the simplest licenses in active use: a copyright notice, a permission grant, and a disclaimer of warranty. The substantive operative text fits in a paragraph. It says, more or less: do whatever you want with this code, including fork it, sell it, ship it inside proprietary products, and redistribute modified versions under any license you like — just leave the copyright notice in place, and don’t sue us.

Compare the obligations of GPLv2 (you must distribute source for any binary you ship), AGPLv3 (you must distribute source even if you only run the modified version as a service), or even Apache 2.0 (you must include the license text and a NOTICE file, and you grant a patent license that is revoked if you sue anyone over patents). The PostgreSQL License has none of those. It is, as licenses go, very nearly a no-op.

This is the principal reason PostgreSQL won. A company that wanted a database it could fork, modify, and ship inside its own product without legal exposure had — has — exactly one industrial-grade option, and that’s PostgreSQL. MySQL was always a hostile environment for closed-source forks: GPLv2, murky linking implications, and an increasingly aggressive copyright owner in Oracle. Permission has compound interest. Twenty-five years of compound interest produces what we have now.

The ownership problem

Here is where PostgreSQL departs from every other major open-source project I can name.

Linux uses GPLv2 with the Developer Certificate of Origin. Contributors retain their copyrights, but every patch is signed off with a Signed-off-by: line attesting to the contributor’s right to submit the work under the project’s license. There is a paper trail, however thin, on every commit.

Most Apache Software Foundation projects require contributors to sign a CLA, which licenses the contribution broadly to the ASF. The ASF is then in a strong position to enforce, defend, or, at the limit, relicense.

GNU projects historically required copyright assignment to the Free Software Foundation, which gives the FSF complete ownership of the contribution.

PostgreSQL does none of this. There is no DCO. There is no CLA. There is no assignment. There is no foundation that owns the code. Contributors submit patches; committers commit them; the patches go into a tree that is distributed under the PostgreSQL License. There is no document anywhere in the workflow where a contributor explicitly says “I license this under the PostgreSQL License.”

It is implied. Whether it would be enforceable as an implied license is a question U.S. courts have not squarely answered. The Ninth Circuit’s standard implied-license test (Asset Marketing Systems v. Gagnon, 542 F.3d 748, building on Effects Associates v. Cohen, 908 F.2d 555) was designed for contractor relationships where the licensee requests the work; it doesn’t fit unsolicited contributions cleanly. The conduct-based theory from Field v. Google is a better doctrinal hook for OSS contributions, but it’s a district-court case (D. Nev. 2006) and has not been applied to OSS contribution scenarios specifically. Most modern projects sidestep the question entirely by using a CLA, a DCO, or a platform like GitHub whose Terms of Service supply an explicit inbound=outbound license. PostgreSQL has none of these, and PostgreSQL is not developed on GitHub — patches go to the pgsql-hackers mailing list and are committed by committers. The implied license is what the project relies on, and nobody has tested it.

What this means in practice is that PostgreSQL’s source tree is a patchwork of copyrights. Every line of code is owned by whoever wrote it. For contributors who wrote on their own time, that’s the contributor. For contributors who wrote as part of their employment — which is most of the substantial work, especially in recent years — it is the contributor’s employer, under the work-for-hire doctrine. (A salaried programmer at a database vendor does not own the patches she writes during business hours. Her employer does. This surprises people who haven’t thought about it.) For deceased contributors, copyright passes to their heirs by ordinary inheritance law.

Add this up over a quarter century of contributions and you have a copyright structure that would give any IP lawyer a small panic attack. There is no central registry of copyright holders. There is no master list of who would need to sign off on a license change. The community knows roughly who the major contributors are, but “roughly” is doing a lot of work in that sentence.

Governance: elegant, bizarre, or both

What governance does exist around PostgreSQL is, depending on your taste, either elegant or bizarre. Three regional non-profits handle narrow, specific functions. The PostgreSQL Community Association of Canada holds the project’s trademarks outside the EU, and nothing else. The United States PostgreSQL Association runs events and administers scholarships and sponsorship programs, and nothing else. PostgreSQL Europe combines both functions for the EU. None of these organizations own the source code. None of them control the project’s technical direction.

Technical direction lives with the core team. Infrastructure lives with the infrastructure team. Neither the core team nor the infrastructure team is a formal organization at all — they are groups of people, recognized by the community, doing the work. There is no incorporation papers, no bylaws, no board of directors. There is no entity, anywhere, that owns PostgreSQL the codebase or controls PostgreSQL the project. That’s not how it was set up.

The trap

Now consider what would happen if PostgreSQL — for whatever reason — wanted to change its license.

Suppose, hypothetically, that the community decided cloud providers were taking too much and giving back too little, and that PostgreSQL should move to AGPLv3 (as Elastic and Redis recently did) or to a source-available license like SSPL or BSL. To do that legally — without ripping out and rewriting every line that any objector ever touched — you would need every copyright holder to agree.

Every. Single. One.

For Elastic and Redis, this was achievable because Elastic and Redis are corporations that own their codebases. Their CLAs gave the company the right to relicense. They flipped the switch, took the political hit, and moved on.

PostgreSQL cannot do this. Not because the community wouldn’t want to. Because there is no entity with the legal standing to flip the switch, and there is no realistic process for getting unanimous consent from a population of copyright holders that includes employers of contributors who have moved on, the heirs of contributors who have died, and an unknown number of contributors whom nobody has reliable contact information for. Even if you somehow corralled every copyright holder onto a single page, there is no entity on the receiving end to flip the switch in the first place. You’d have to invent one. The only practical alternative would be a clean-room rewrite of every line of code that anyone objects to — which, in a hostile relicensing scenario, is functionally all of it.

PostgreSQL is structurally locked into its current license. Permissive by choice, in 1995. Permanent by accident, ever since.

The fairness question

Which brings us to the part that, depending on your priors, is either the natural consequence of the permissive licensing model or its central injustice.

The economic beneficiaries of PostgreSQL — measured in revenue — are dominated by the cloud providers. RDS, Aurora, Cloud SQL, Azure Database for PostgreSQL, Neon, Supabase, and a long tail of others. The combined annual revenue from PostgreSQL-derived hosted products is, by any reasonable estimate, millions upon millions of dollars.

The people who actually wrote PostgreSQL fall into a few categories.

Some are paid by PostgreSQL-focused companies — EDB, Crunchy Data, Cybertec, PGX, and others — to work on the project as part of their job. These people are compensated, sometimes well. Their employers’ revenue, though, is a small fraction of the cloud providers’.

Some are researchers, often graduate students or faculty, whose institutional support is incidental to the work. A grant doesn’t generally pay you to fix a planner regression.

Some are independent contributors, who do it for love, for reputation, or because they happen to need a feature their employer won’t pay for.

And some started on PostgreSQL as a hobby, became experts, and got hired into one of the categories above. This is the most common pipeline, and it’s worth noticing that the pipeline is essentially “contribute for free for years, hope someone notices.”

The cloud providers, until quite recently, contributed effectively nothing back to PostgreSQL core. That has improved in the last several years — AWS and Microsoft both employ committers now, and Google has done more visible upstream work — but the contribution-to-extraction ratio remains heavily asymmetric. This is the classic free-rider problem in textbook form: a public good, paid for by some, consumed by everyone, with no enforcement mechanism for proportional contribution.

It is precisely the structural argument that drove Elastic, Redis, and MongoDB to source-available licenses. Their argument was: cloud providers were taking commercial open-source projects, hosting them as a service, capturing the bulk of the revenue, and contributing little. Source-available licenses are an attempt — not always well-executed, and not without their own collateral damage — to reset the bargain.

PostgreSQL cannot run that play, even if it wanted to. We are back to the trap.

I have no clean answer here, and I’m not sure one exists. The permissive license is the reason PostgreSQL won; you don’t get one without the other. It is also the reason a substantial fraction of the people who built PostgreSQL did so for free, while a small number of cloud providers built business empires on their work. Both of these are true. Both are consequences of the same legal structure, and the legal structure is, for all practical purposes, immutable.

The RedMonk piece notes a faint signal of permissive licenses ticking down in the most recent data, possibly an artifact of sampling, possibly a real shift. If it is a real shift, the lesson PostgreSQL offers the next generation of OSS projects is probably this: choose your license deliberately, but choose your contribution governance even more deliberately. The license is the headline. The CLA is the ballast.