前文提到，Monty 得知 Oracle 收购 Sun 的提案得到了美国政府的支持后，发动社区用户向欧盟委员会请愿，希望通过反垄断的名义让 Oracle 知难而退，进而实现剥离 MySQL 的目的。而 Oracle 为了得到欧盟委员会的许可，迅速提出了十条针对 MySQL 生态厂商和用户的承诺，最终获得了欧盟的同意，于 2010 年初完成了交易。
那么，Oracle 完成收购后是如何处置 Sun 的核心资产的呢？让我们将视线稍微拉远一点，看看后面发生了什么事情。
- Solaris 操作系统
- 2010.3，Oracle 修改了 Solaris 10 的授权条款，将“永久免费商用”变成了“90 天内免费使用”。
- 2010.8，Oracle 取消了 OpenSolaris 开源项目，并宣布以 Solaris 11 Express 取代开源二进制分发版本。
- 2011.11，Oracle 发布了 Solaris 11，这是最后一个 Solaris 大版本。
- 2012.10-2015.10，Oracle 发布了 Solaris 11.1 / 11.2 / 11.3。
- 2017.9，Oracle 被曝裁了大量 SPARC 和 Solaris 工程师，Austin、Santa Clara 和 Burlington 等地全军覆没。
- 2018.8，Oracle 发布了 Solaris 11.4，这是最后一个 Solaris 小版本。
- Java 编程语言
- 2019 年，Oracle 修改了 JDK 8 的许可政策，不再提供 Oracle JDK 8 的免费更新。
- 2021 年，Oracle 宣布从 JDK 11 开始，将以 NFTC 许可发布 Oracle JDK。
- 2023 年，Oracle 调整了 Java SE 的订阅模式，以员工数和服务器数计算费用。
Oracle 是一个极其关注技术竞争力和商业回报的公司，这也决定了它在开源方面采取的动作会非常保守，甚至可以说倒退。Oracle 关闭 OpenSolaris 开源项目之前，内部漏出了一些邮件，从中可以看出 Oracle 的决策逻辑：
致 Oracle Solaris 工程团队：
今天，我们将宣布一系列关于 Solaris 11 发展路径的决策，并回答有关开源、开放开发、软件和二进制许可证的关键问题，以及开发者和早期采用者在 Solaris 11 2011年发布之前如何使用 Solaris 11 技术的问题。
众所周知，“OpenSolaris”一词通常被用来泛指一系列源代码、一个开发模型、一个网站、一个标志、一个二进制发布版本、一个源代码许可证、一个社区以及许多其他相关事物。因此，从组织和商业角度考虑每个问题，并确定正确的下一步行动需要一些时间。因此，请仔细阅读这里的所有细节。我们将首先讨论我们的策略，然后是实施该策略的政策和流程的决策和变化。
Solaris 策略
Solaris 是第一大企业级操作系统。我们在今天的 Solaris 上拥有领先的商业应用份额，包括 SPARC 和 x64。我们的应用基础是 AIX 和 HP-UX 的两倍多。我们的品牌代表创新、品质、安全和信任，这是基于我们对 Solaris 操作系统工程 20 年的投资。
从商业角度看，我们对 Solaris 工程上投资目的是推动我们的整体服务器业务，包括 SPARC 和 x64，并推动由 Oracle 组合中多个组件集成带来的业务优势。这包括将我们的服务器与我们的存储、我们的交换机、Oracle 应用与 Solaris 结合起来，以及由这些组合带来的服务体验的效果。总之，Solaris 推动了以数十亿美元计的整体业务，并具有显著的增长潜力。
我们正在增加对 Solaris 的投资，包括从整个行业招聘操作系统专家，这是我们对这些目标承诺的标志。Solaris 不是我们外包给其他人的东西，它不是某个第三方技术的组装，也不是仅供维护的产品。我们期望业内顶尖的操作系统工程师，即你们所有人，都能创造并交付创新，继续使 Solaris 独一无二、有区别性，并对我们的客户及我们的业务产生价值。
Solaris 必须作为 Oracle 企业级客户的最佳操作系统而存在。我们希望所有人都认为“如果要运行的话，它就应该运行在 Solaris 上。”这就是 Solaris 品牌。这就是可扩展性重要的地方，不仅仅是几个 CPU 插槽和几个 GB 的 DRAM。这就是为什么我们可靠地交付数百万 IOPS 的存储、网络和 Infiniband。这就是为什么我们在文件和数据管理、安全和命名空间隔离、故障管理和可观测性方面具有独特属性。我们还希望我们的客户知道，Solaris 将继续是新想法和新技术的来源——这些技术简化了他们的业务并优化了他们的应用程序。这就是为什么 Solaris 10 是有史以来最具创新性的操作系统发布。同样的关注点将推动 Solaris 11 中一系列新的创新。
为了使 Solaris 成为 Oracle 完整和开放组合中最佳的操作系统，它必须在其他服务器硬件上运行良好，并且执行每个应用程序，同时为我们的硬件和我们的应用程序提供独特的优化。这是 Oracle 完整、开放和集成策略的核心价值主张。这些是互补而非矛盾的目标，我们将通过适当的设计和工程实现这些目标。
Solaris 的增长机会从未如此之大。例如，约有 40% 的 Oracle 企业客户使用 Solaris，这意味着我们仅在顶级客户中就有 60% 的增长机会。就绝对数字而言，仅在北美就有 130,000 个 Oracle 客户尚未使用我们的服务器和存储，全球客户基础为 350,000（之前的 Sun 基础约为 35,000）。作为一个合并后的公司，这是一个我们可以攻克的巨大机会，它将增加 Solaris 的采用率和整体硬件服务器收入。我们的成功还将增加 ISV 为 Solaris 优化其应用程序所做的努力。
我们将继续培养一个充满活力的开发者和系统管理员社区。交付二进制版本，以源代码或二进制形式交付 API，交付开源代码，交付技术文档，以及为常见行业技术（如 Apache、Perl、OFED 等）进行上游贡献，将是该活动的一部分。但我们还将做出具体决策，说明我们何时以及为何进行这些事情，遵循两个核心原则：
(1) 我们不能做所有事情。限制因素是我们的工程带宽，以人和时间衡量。因此，我们必须确保我们的首要任务是推动 top 1 企业操作系统 Solaris 11 的交付，以增长我们的系统业务；
(2) 我们希望我们的技术和知识产权的采用能加速实现整体目标，而不是允许竞争对手在我们之前从我们的创新中获得商业优势（或制造不确定性、恐惧和怀疑）。
我们正在利用我们在核心 Solaris 创新和工程方面的投资来推动多个业务，通过多个产品线。这已经包括了我们的企业级操作系统 Solaris 和我们的 ZFS 存储产品线，并将很快包括其他 Oracle 产品。这个策略完全是关于从一组共同的软件投资中创造更多价值：它使你们所做的一切更有价值，被全球更多人使用。这也意味着，作为一个工程师或经理，你有更大的责任去了解你的工程部署所在的更广泛的商业和技术背景。
Solaris 决策
我们将继续在几乎所有 Solaris 源代码文件中使用 CDDL 许可声明。我们不会从任何已适用 CDDL 的 Solaris 文件中移除 CDDL，新创建的源代码文件将遵循当前关于应用 CDDL 的政策（简单来说，usr/src 文件将采用 CDDL，而在 usr/closed 中的极少数文件可能不会采用）。在非 ON 聚合中继续使用其他开放许可证（例如，在桌面区域使用 GPL）也将持续。和以前一样，更改与源代码相关联的许可证的请求将逐案决定。
我们将在完整发布我们的企业级 Solaris 操作系统后，分发获批准的 CDDL 或其他开源许可的代码更新。通过这种方式，新的技术创新将首先在我们的发布版本中出现。我们将不再实时地分发整个 Solaris 操作系统的源代码，例如每晚的构建。
任何使用 CDDL（无论是片段还是作为 OpenSolaris 源代码分发或其衍生产品的一部分）消费 Solaris 代码的用户，将能够在我们发布更新时，根据 CDDL、LGPL 或适用的任何其他许可证的条款，使用这些更新。
我们将设立一个技术合作伙伴计划，通过 Oracle 技术网络（OTN），允许我们的行业合作伙伴全面访问正在开发中的 Solaris 源代码。这将包括对代码和二进制文件的早期访问，以及在适当的情况下对我们的贡献。所有此类合作伙伴关系将根据具体情况进行评估，但我们的核心现有技术合作伙伴关系，例如与 Intel 的合作，是受重视的参与示例。
我们将鼓励并倾听对 Solaris 技术的所有许可请求，无论是部分还是全部。所有此类请求将根据具体情况进行评估，但我们相信存在许多互补领域，新的合作机会可以扩大我们的知识产权使用。
我们将继续在特定加速我们整体 Solaris 目标的领域中进行积极的开放式开发，包括上游贡献。示例包括我们围绕 Gnome 和 X11、IPS 打包的活动，以及我们在 Solaris 上优化 Apache、OpenSSL 和 Perl 生态系统的工作。
我们将通过我们的 OTN Solaris 存在形式，提供技术设计信息，包括文档、设计文件和源代码描述。我们将不再默认发布每个 ARC 案例的预先技术描述，表明未来 Solaris 发布可能包含哪些技术创新。当它服务于特定有用需求时，我们可以随时做出发布任何项目的预先技术信息的特定决定。
我们将有一个名为 Solaris 11 Express 的 Solaris 11 二进制分发版本，它将有一个免费的开发者 RTU 许可证和一个可选的支持计划。Solaris 11 Express 将在今年年底前首次亮相，我们将对其进行更新，直至 2011 年 Solaris 11 的完整发布。
Oracle 在 Solaris 技术的二进制分发方面的所有努力将集中在 Solaris 11 上。我们将不会发布任何其他二进制分发版本，如 Solaris 二进制的每日或双周构建，或 OpenSolaris 2010.05 或更新版本的分发。我们将确定一种简单、经济有效的方式，使之前 OpenSolaris 二进制版本的企业用户迁移到 S11 Express。
我们将设立一个名为 Solaris 11 Platinum 的客户计划，包括直接的工程参与和反馈，针对使用我们 Solaris 11 技术的客户。我们将邀请你们所有人参与这一努力，借助以前 Sun Platinum 计划的优势，同时利用我们作为合并公司现在可用的更大的宣传渠道。
我们期待每个人在 Solaris 11 上持续工作。我们的目标很简单，就是使其成为有史以来最好、最重要的 Solaris 发布版本。
Oracle 对 SPARC、Solaris 的热情持续几年后，终于在 2017 年散去了。在这一年，SPARC 迎来了最后一次发布；而 Solaris 随后在 2018 年迎来了最后一个小版本。2019 年开始，Oracle 又开始频繁折腾 Sun 硕果仅存的最后一笔遗产 Java。从历史的角度看，Oracle 折腾 MySQL 是一个必然事件，这也是 Monty 最担心的事情。不过出乎意料的是，虽然 Oracle 的投入虽然远远没有达到令 Monty 满意的程度，但是后继的版本都正常发布了，而且功能、性能还得到了持续完善：
- 2010.12，Oracle 发布了 MySQL 5.5。
- 2013.2，Oracle 发布了 MySQL 5.6。
- 2015.10，Oracle 发布了 MySQL 5.7。
- 2018.4，Oracle 发布了 MySQL 8.0。
- 2023.7，Oracle 发布了 MySQL 8.1。
对于 Oracle 收购 Sun 之后发布的 MySQL 5.5，Monty 给予了肯定，同时也给 MariaDB 打了些广告。
祝贺 Oracle 和 MySQL 团队成功发布 5.5 版本！
首先，我必须承认，由于在过去的两年中，MySQL 6.0、5.4 和 5.5 的大部分规划都是在闭门进行的，没有社区的洞察，我无法像我希望的那样密切关注 MySQL 5.5 的发展。虽然到最近为止，提交记录一直是开放的，但仅仅通过查看提交记录来了解正在发生的事情并不容易。我确信我在下面遗漏了一些 5.5 版本中的重要功能，并忘记了感谢那些在 5.5 版本上做出了杰出工作的人们。
…………
现在已经距离 MySQL 5.1 GA 发布几乎整整两年了，那么对于 5.5 版本的结论是什么呢？
InnoDB 存储引擎和 DLL 锁的改进让我印象深刻。尽管像 Windows 上的速度提升这样的结果很棒，但大多数新功能都是小的（技术上的）调整。作为一个技术人员，我认为这都是些几小时内就能完成的事情，而且本可以在 5.1 版本中轻松实现，所以没有让我感到惊喜。
最让我担忧的是 MySQL 5.5 中缺失的那些功能。一些原本应该包含在下一个 MySQL 版本中的功能包括：
线程池（而不是像 MySQL 5.1 那样每个连接一个线程）。
- 据我所知，这个功能已被移到 5.6 企业版中，并不会包含在社区服务器版本中。
一个开源的、免费的备份工具和备份 API，适用于所有存储引擎。这可能是 MySQL 有史以来最受期待的功能！
- 这个项目在功能被认为准备好加入到 5.5 版本的同一天被 Oracle 停止了。
在 5.5 版本中，一些内部子系统，如 safemalloc（一个可移植的内存检查器），也被移除了。
我还担心的另一个问题是，在重要的核心开发者继续离开的情况下，Oracle 能够持续开发 MySQL 多长时间。在上面提到的人中，Konstantin Osipov 和 Vladislav Vaintroub 已经离开了甲骨文，剩下的老员工不多了。
…………
问题在于，很难评估 5.5 版本的稳定性究竟如何，因为 5.5 版本还没有被大家充分测试过，而且公开的 Bug 系统中的某些 bug 信息无法被访问，比如致命的 #33082。Bug 系统显示 MySQL 5.1 有 294 个未解决的 Bug，而 MySQL 5.5 有 150 个。然而我还没有时间评估所有公开的 Bug，所以我不知道它们的严重程度如何。稳定性还取决于 GA 版本发布后，被提交上来的 Bug 数量。
对于 MySQL 8.0 版本，Monty 的态度就更负面一些，给 MariaDB 打的广告也更赤裸裸：
上周，Oracle 宣布 MySQL 8.0 版本正式可用。这对数据库用户来说是个好消息，因为这意味着 Oracle 仍在继续开发 MySQL。
…………
在许多方面，MySQL 8.0 已经赶上了 MariaDB 的一些早期版本。例如，在四年前的 MariaDB 10.0 中，我们引入了角色（roles）。在三年前的 MariaDB 10.1 中，我们引入了加密的 Redo 日志和 Undo 日志（encrypted redo/undo logs）。一年前的 MariaDB 10.2 中，我们引入了窗口函数和公用表表达式（CTEs）。然而，MySQL 仍需追赶 MariaDB 10.2 服务器的一些功能，如检查约束（check constraints）、Binlog 日志压缩（binlog compression）和基于日志的回滚（log-based rollback）。
…………
在 Roadmap 方面，MySQL 在小心避免引入那些能够缩小 MySQL 与 Oracle 差距的功能。MariaDB 则没有这样的限制。在 MariaDB 10.3 中，我们引入了 **PL/SQL 兼容性（Oracle 的存储过程）**和 AS OF（带有按时间点查询功能的内置系统版本表）。MariaDB 是第一个实现这两个功能的开源数据库。我不认为 Oracle 会在 MySQL 中提供上述功能！
同样在 Roadmap 方面，MySQL 并没有与生态系统合作拓展功能。在 2017 年，MariaDB 一年之内接受的代码贡献量，比 MySQL 在其整个生命周期中接受的还要多，而且差距还在拉大！
我相信，如果 MySQL 采用一个开放的开发模式，让社区能够轻松参与到 MySQL 的持续开发和测试中，我在测试 MySQL 8.0 的体验会显著改善。大多数让人困惑的错误信息和奇怪行为都会在 GA 前被发现并修复。
…………
MySQL 8.0 似乎是一条通向未知未来的单行道。在 MySQL 5.7 及之前版本，迁移到 MariaDB 是很简单的事情，而且可以随时通过 mysqldump 返回到 MySQL。所有 MySQL 客户端库都能与 MariaDB 兼容，所有 MariaDB 客户端库也都能与 MySQL 兼容。但是到了 MySQL 8.0，情况往不好的方向发展了。
只要你使用的是 MySQL 5.7 或更低版本，你对未来还有选择权，但在 MySQL 8.0 之后，你的选择就非常有限了。但不要绝望，因为 MariaDB 总是能够加载 mysqldump 文件，并且将你的旧 MySQL 安装升级到 MariaDB 也非常简单 😃
希望你试用 MySQL 8.0（以及即将到来的 MariaDB 10.3）顺利！
从实际发生的情况看，Oracle 对 MySQL 采取了完全不一样的策略，既没有修改 MySQL 的开源协议，也没有强迫客户转向更加封闭的商业版本。相反，Oracle 在 MySQL 上面投入的资源有点让人吃惊。根据内部员工的爆料， 尽管 MySQL 为 Oracle 带来的营收可以忽略不计，但是董事会要人给人、要钱给钱。这是为什么？
这个问题如果从数据库角度看，并不容易得出答案，因为 Oracle 自始自终的定位就不仅仅是一个数据库厂商，而是一个企业级软硬件解决方案供应商。在 2010 年之前，Oracle 的主要竞争对手是 IBM、SAP、Salesforce 以及 Microsoft，竞争的领域主要集中在系统硬件、CRM 和 ERP 方面；在 2010 年之后，随着云计算和 SaaS 服务的兴起，Oracle 和传统竞争对手们都发现 AWS 才是最大的威胁。无论是 Oracle 还是 Microsoft，都为自家产品在 AWS 上面的部署设置了歧视性定价规则，但都没有阻碍 AWS 抢夺市场的脚步。反而，AWS 充分利用了开源生态的开放性大赚特赚，前有 RDS 收割开源红利，后有 Aurora 变现高端客群。因此 Oracle 拿着的 MySQL 实属烫手山芋，用力做会让竞争对手收割，而不用力做则会流失潜在用户。
AWS 后来创建了 OpenSearch（针对 ElasticSearch），并赞助了 Valkey（针对 Redis），这也坐实了 Oracle 的顾虑。如果 Oracle 修改了 MySQL 的 License，AWS 很可能会拉着社区创建一个新的 MySQL 分支，然后尝试用这个分支聚拢存量用户群体。无论是 Monty 的 MariaDB 还是 Peter 的 Percona，想必都会乐见其成。那么究竟该如何处置 MySQL 这个烫手山芋，才能尽可能避免被 AWS 收割？ Oracle 做了如下几个举动：
- 从 2011 年起，将更多功能以闭源插件的方式放到 MySQL 企业版里。
- 从 2012 年起，不再开源新的测试用例，并且隐藏了代码的修改记录。
- 从 2022 年起，在包括 AWS 在内的云平台上推出 MySQL Heatwave 托管服务。
虽然 Oracle 已经把能做的事情都做了，但是最重要的目标始终没有完成，就是从 AWS RDS 或者 Aurora 的收入里面分一杯羹。实际上，没有任何一个数据库厂商能够直接从 AWS 的托管服务里面分到钱，只能通过差异化的功能或者服务登陆 Marketplace，被 AWS 二次收割。事实上，保证研发投入能够被高效货币化的开源数据库，很可能有且只有 MongoDB 一家。PostgreSQL 虽然流行，但是背后的大金主 EnterpriseDB 主要靠语法兼容性在吃存量 Oracle 市场；而 SQLite 作为漂亮的半成品，目前还看不到太多独立商业化的可能性。
在“云计算”这个庞然大物面前，开源世界的理念已经摇摇欲坠，就连以“竭泽而渔”闻名的 Oracle 都拿插管吸血的 AWS 没什么办法。在各大开源数据库厂商纷纷改弦易辙之前，Monty 已经在知识产权上吃过亏，那他又是怎么应对这个问题的呢？
请关注本系列文章的最后一篇：MySQL 开源到商业（五）：开源和养家糊口
参考资料
https://bell-sw.com/announcements/2022/02/24/java-licensing-changes-in-2021/#mcetoc_1gj4sikuu46
https://arstechnica.com/information-technology/2010/03/solaris-10-no-longer-free-as-in-beer-now-a-90-day-trial/
https://web.archive.org/web/20100816225601/http://mail.opensolaris.org/pipermail/opensolaris-discuss/2010-August/059310.html
https://www.theregister.com/2017/09/04/oracle_layoffs_solaris_sparc_teams/
End
KubeBlocks 已发布 v0.8.0！KubeBlocks v0.8.0 推出了 Component API，让数据库引擎的组装变得更加简单。Addon 机制也有了重大改进，数据库引擎的 helm chart 从 KubeBlocks repo 中拆分出去，从此数据库引擎或者版本的变动已与 KubeBlocks 发版解绑。v0.8.0 还支持多版本的数据库引擎定义。Pika、ClickHouse、OceanBase、MySQL、PostgreSQL、Redis 等均有功能更新，快来试试看！
小猿姐诚邀各位体验 KubeBlocks，也欢迎您成为产品的使用者和项目的贡献者。跟我们一起构建云原生数据基础设施吧！
💻 官网: www.kubeblocks.io
🌟 GitHub: https://github.com/apecloud/kubeblocks
🚀 Get started: https://kubeblocks.io/docs/preview/user_docs/try-out-on-playground/try-kubeblocks-on-your-laptop
关注小猿姐，一起学习更多云原生技术干货。
