DeepSeek总结的PostgreSQL因选择而宽松，因偶然而永久

因选择而宽松，因偶然而永久

https://thebuild.com/blog/permissive-by-choice-permanent-by-accident/

2026-04-28

9 分钟

PostgreSQL

Stephen O'Grady 在 RedMonk 发表的《2026 年开源许可状况》是必读之作。其头条发现------从 copyleft 到宽松许可的长期转变仍在继续，Apache 和 MIT 在幸存者中巩固了主导地位------对任何一直关注这个领域的人来说都不意外。有趣的问题一如既往，是数据遗漏了什么。

数据遗漏了 PostgreSQL。

PostgreSQL 不在那些图表中的任何一个里。它早于 deps.dev 所测量的包注册表时代，而且它不是 npm 或 Maven 制品。但以任何合理的标准衡量，它都是该领域历史上最成功的宽松许可项目之一。RDS for PostgreSQL、Aurora、Cloud SQL 和 Azure Database for PostgreSQL 合计每年产生数百万又数百万美元的收入。这些收入没有一分被项目、其贡献者或任何有地位影响许可证的人所捕获。最后一句才是有趣的部分，也是本文的主题。

简短的法定词汇

先说三个术语。本文之后将不再赘述地使用它们。

许可证（license） 是使用他人受版权保护作品的许可。所有者说：你可以在这些条件下用我的作品做这些事。许可证不转让所有权。

版权转让（copyright assignment） 是实际的所有权转移。原作者签署一份文件，说：我不再拥有这个；FSF（或 Apache 软件基金会，或我的雇主）现在拥有它。转让后，转让人对作品的权利不比陌生人更多。

贡献者许可协议（CLA） 是项目要求每位贡献者签署的文件，授予项目（或其赞助基金会）使用、再许可和重新许可该贡献的广泛许可。CLA 是许可证，不是转让，但它足够广泛，以至于在大多数实际目的上，它的作用类似转让。

PostgreSQL 没有这些机制。没有转让，没有 CLA，甚至没有 Linux 使用的轻量级开发者原创证书。大多数同等规模的项目至少有一个。PostgreSQL 一个都没有。这很重要。

"宽松"在这里实际意味着什么

PostgreSQL 许可证是它自己的许可证------不是 BSD-2-Clause，不是 MIT，而是两者的近亲。它是正在使用中的最简单的许可证之一：一份版权声明、一份许可授予，以及一份保证免责声明。实质性的操作文本只有一段。它大致说：你可以用这段代码做任何你想做的事，包括 fork 它、卖掉它、把它装进专有产品发布，并以任何你喜欢的许可证重新分发修改版本------只要保留版权声明，并且不要起诉我们。

比较一下 GPLv2 的义务（你必须为你发布的任何二进制文件分发源代码）、AGPLv3（即使你只是把修改版作为服务运行，你也必须分发源代码），甚至 Apache 2.0（你必须包含许可证文本和 NOTICE 文件，而且你授予的专利许可如果你因专利起诉任何人就会被撤销）。PostgreSQL 许可证没有这些。就许可证而言，它几乎是一个空操作。

所有权问题

这里是 PostgreSQL 与我能说出的其他所有主要开源项目分道扬镳的地方。

Linux 使用 GPLv2 加上开发者原创证书。贡献者保留他们的版权，但每个补丁都用 Signed-off-by: 行签署，证明贡献者有权在项目许可证下提交该作品。每次提交都有纸面记录，无论多么单薄。

大多数 Apache 软件基金会项目要求贡献者签署 CLA，将贡献广泛地许可给 ASF。ASF 因此处于强势地位，可以执行、辩护，或者在极限情况下重新许可。

GNU 项目历史上要求将版权转让给自由软件基金会，这赋予 FSF 对贡献的完全所有权。

PostgreSQL 什么都不做。没有 DCO。没有 CLA。没有转让。没有拥有代码的基金会。贡献者提交补丁；提交者提交它们；补丁进入一棵以 PostgreSQL 许可证分发的代码树。在整个工作流中，没有任何文件让贡献者明确说"我以 PostgreSQL 许可证许可这个"。

它是隐含的。它作为隐含许可证是否可执行，是美国法院尚未明确回答的问题。第九巡回法院的标准隐含许可测试（Asset Marketing Systems v. Gagnon, 542 F.3d 748，建立在 Effects Associates v. Cohen, 908 F.2d 555 之上）是为被许可人请求作品的承包商关系设计的；它不能干净地套用于主动贡献。Field v. Google 中基于行为的理论对开源贡献来说是更好的法理钩子，但它是地区法院案件（D. Nev. 2006），尚未被具体应用于开源贡献场景。大多数现代项目通过使用 CLA、DCO，或像 GitHub 这样其服务条款提供明确 inbound=outbound 许可证的平台来完全回避这个问题。PostgreSQL 这些都没有，而且 PostgreSQL 不是在 GitHub 上开发的------补丁发到 pgsql-hackers 邮件列表，由提交者提交。隐含许可证是项目所依赖的，而没有人测试过它。

这在实践中意味着 PostgreSQL 的源代码树是版权的拼凑物。每一行代码都由写下它的人拥有。对于在业余时间写作的贡献者，那就是贡献者。对于作为雇佣工作的一部分写作的贡献者------这是大部分实质性工作，尤其是近年来------根据雇佣作品原则，那是贡献者的雇主。（数据库供应商的一名受薪程序员不拥有她在工作时间写的补丁。她的雇主拥有。这会让没想过这件事的人感到惊讶。）对于已故贡献者，版权通过普通继承法传给他们的继承人。

把这一切在四分之一世纪的贡献中加起来，你就有了一个会让任何知识产权律师小小恐慌一下的版权结构。没有版权持有者的中央登记处。没有谁需要对许可证变更签字的主列表。社区大致知道主要贡献者是谁，但"大致"在这个句子里承担了很多工作。

治理：优雅、怪异，还是两者兼有

PostgreSQL 周围确实存在的治理，取决于你的品味，要么优雅，要么怪异。三个区域性非营利组织处理狭窄、具体的职能。PostgreSQL Community Association of Canada 持有项目在欧盟以外的商标，仅此而已。United States PostgreSQL Association 举办活动并管理奖学金和赞助项目，仅此而已。PostgreSQL Europe 为欧盟结合了这两种职能。这些组织都不拥有源代码。它们都不控制项目的技术方向。

技术方向属于核心团队。基础设施属于基础设施团队。核心团队和基础设施团队都不是正式组织------它们是被社区认可、在做工作的一群人。没有公司注册文件，没有章程，没有董事会。任何地方都没有一个实体拥有 PostgreSQL 这个代码库或控制 PostgreSQL 这个项目。它不是这样建立起来的。

陷阱

现在考虑一下，如果 PostgreSQL------无论出于什么原因------想要改变它的许可证，会发生什么。

假设，假设性地，社区认定云提供商拿得太多、给回太少，PostgreSQL 应该转向 AGPLv3（就像 Elastic 和 Redis 最近所做的那样），或者转向像 SSPL 或 BSL 这样的源码可用许可证。要合法地做到这一点------而不撕掉并重写任何反对者碰过的每一行------你需要每一位版权持有者同意。

每一位。单独的。每一位。

对于 Elastic 和 Redis，这是可以实现的，因为 Elastic 和 Redis 是拥有其代码库的公司。它们的 CLA 给了公司重新许可的权利。它们扳动开关，承受政治打击，然后继续前进。

PostgreSQL 做不到这一点。不是因为社区不想。而是因为没有一个有法律地位的实体来扳动开关，也没有现实可行的流程来获得版权持有者群体的全体同意，这个群体包括已经离职的贡献者的雇主、已经去世的贡献者的继承人，以及未知数量、没人有可靠联系方式的贡献者。即使你不知怎么把每一位版权持有者都集中到一页纸上，接收端也没有一个实体来扳动开关。你必须发明一个。唯一实际的替代方案是对任何人反对的每一行代码进行净室重写------而在敌意重新许可的场景中，这实际上就是全部代码。

PostgreSQL 在结构上被锁定在其当前许可证中。1995 年因选择而宽松。自那以后因偶然而永久。

公平问题

这就把我们带到那个取决于你的先验，要么是宽松许可模式的自然结果，要么是其核心不公的部分。

PostgreSQL 的经济受益者------以收入衡量------由云提供商主导。RDS、Aurora、Cloud SQL、Azure Database for PostgreSQL、Neon、Supabase，以及一长串其他公司。来自 PostgreSQL 衍生的托管产品的合计年收入，以任何合理估计，都是数百万又数百万美元。

真正写下 PostgreSQL 的人分为几类。

一些由专注于 PostgreSQL 的公司------EDB、Crunchy Data、Cybertec、PGX 等------付钱，作为他们工作的一部分来从事该项目。这些人得到报酬，有时报酬不错。不过，他们雇主的收入只是云提供商的一小部分。

一些是研究人员，通常是研究生或教职员工，其机构支持与工作只是附带关系。一笔资助通常不会付钱让你修复规划器回归。

一些是独立贡献者，他们出于热爱、出于声誉，或者因为他们恰好需要某个雇主不愿付钱买的功能而做这件事。

还有一些人从 PostgreSQL 作为爱好开始，成为专家，然后被雇入上述某一类。这是最常见的管道，值得注意的是，这个管道本质上是"免费贡献多年，希望有人注意到"。

云提供商直到最近，实际上没有向 PostgreSQL 核心贡献任何东西。过去几年这有所改善------AWS 和 Microsoft 现在都雇用了提交者，Google 也做了更多可见的上游工作------但贡献与提取的比率仍然严重不对称。这是教科书形式的经典搭便车问题：一种公共品，由一些人付费，被所有人消费，没有按比例贡献的执行机制。

这正是驱使 Elastic、Redis 和 MongoDB 转向源码可用许可证的结构性论点。它们的论点是：云提供商拿走商业开源项目，将其作为服务托管，攫取大部分收入，却贡献很少。源码可用许可证是一种尝试------并不总是执行得好，也不是没有自己的附带损害------重置这笔交易。

PostgreSQL 即使想，也玩不了这个把戏。我们又回到了陷阱。

我在这里没有干净的答案，我也不确定存在这样的答案。宽松许可证是 PostgreSQL 胜出的原因；你无法只要一个而不要另一个。它也是相当一部分构建 PostgreSQL 的人免费这样做，而少数云提供商在他们的工作上建立商业帝国的原因。这两者都是真的。两者都是同一法律结构的结果，而法律结构实际上是不可变的。

RedMonk 的文章指出，最近数据中有一个宽松许可证略微下降的微弱信号，可能是采样假象，也可能是真实转变。如果它是真实转变，PostgreSQL 给下一代开源项目的教训大概是：审慎地选择你的许可证，但更要审慎地选择你的贡献治理。许可证是头条。CLA 是压舱物。

（我通过 PGX Inc. 提供 PostgreSQL 咨询服务。）