开源大事件：MariaDB公司改弦易辙，远离开源

Posted 2021-05-01 智多趣

让人大跌眼镜的是，新版本的MaxScale数据库代理软件采用了专有许可证，这种数据库代理软件正是大规模部署MariaDB的关键。

图片来源：Thinkstock

MariaDB公司近日宣布，版本2.0的MaxScale数据库代理软件此后不再是开源软件。这家企业组织的这款软件的源代码改而采用一种专有许可证，并承诺：一旦过期，每个版本最终会成为开源。

MaxScale可谓是MariaDB公司的创收变现战略的核心――它是大规模部署MariaDB数据库的关键。其想法似乎是，通过强行收取许可费，因而从原本试图免费使用它的财力雄厚的大公司获得丰厚收入。此举对一家建立在MariaDB基础上的公司来说似乎不同寻常，毕竟MariaDB当初是为了将mysql从甲骨文的铁掌解放出来而开发的。

相应的许可证名为商业源代码许可证（Business Source License），由MySQL的开发者迈克尔·蒙蒂·维德纽斯（Michael "Monty" Widenius）在2013年设计。它允许用于评估，并设定了源代码何时采用GPL许可证的日期，但它是明确的专有许可证，为了追逐商业利益。

蒙蒂长期以来就想试用商业源代码许可证，所以这个想法不是什么新闻，甚至称不上多新颖，因为其他许可证也试图如出一辙，推迟版本发布的想法由根深蒂固。这家公司在MariaDB本身方面无法亦步亦趋，因为甲骨文拥有MySQL（MariaDB的鼻祖）防止许可证变更。但是我认为，无论是从社区的角度还是从商业的角度，让MaxScale采用专有许可证对MariaDB公司来说都不是明智的举措。

开源社区迅速作出了回应，既有一个分支，又有Percona的一名员工宣布了一个竞争性项目。他认为这个名称取得不好，甚至称商业源代码许可证（BSL）为“狗屎许可证”（BS License）。许可证的全面变更基本上没有显示社区规划的迹象，把不是客户的所有社区成员都当成了寄生虫：

• 它实际上消除了共同开发软件的任何可能性，因为软件自由完全被摈弃了。这还意味着，代码的任何部分不会有任何的替代用途――没有人能“站在巨人的肩膀上”。

• 这背叛了开源版本的现有用户，他们无法获得2.0版本中包括的任何（众多）修正版。MariaDB公司应该发布一款最终的开源版本以实现转型，包括错误修正版。

• 这就引起了重大问题：任何代码是否源自采用GPL许可证的源代码，这可能违反规定――而甲骨文是违规的那一方。

• 这进一步扇了MariaDB基金会一记耳光，现在该基金会监管与专有产品有关的MariaDB商标。

也许这就是为什么就此向社区作出解释的那个人在宣布前不久离职？值得赞扬的是，MariaDB公司没有表示这是开源许可证（它绝对不是开源许可证），但是它坚持声称“有一天会开源”，仍在利用开源市场的商誉为自己造势。

这是误入歧途。由于没有共同开发的社区，它只是一种托管安排而已。它甚至不是一种很好的安排，因为如果公司失败，软件仍然会保持专有性，直到许可证变更那天。蒙蒂声称这避免了锁定，但是我觉得事实并非如此。整个公司的视角就跟社区视角一样薄弱：

• 专有许可证的锁定期很长――多个次要版本，还有可能一两个主要版，这意味着切实可行的开源软件有很长时间不会出现；就算出现，它也早就过时了，易受攻击。

• 由于专有锁定期如此之长，任何现有社区不太可能会喜欢使用它或集成它，即便许可证允许这么做。

• 至于承诺的保持开放不再让人相信，类似甲骨文的封闭完全有可能。

• 由于最终许可证仍是GPLv2+，企业用户可能会认为它不适合托管。

• 最重要的是，正如贾斯廷·斯旺哈特（Justin Swanhart）指出的那样，它意味着，MariaDB现在是一个生态系统，针对大规模部署所必需的整个系列的软件，替代服务提供商无法支持客户。MariaDB公司可能会从市场获得更大的一块份额，但是整个市场会比较小。

正因为如此，如果企业用户使用这种模式的软件，它们并不控制其架构和投入；非商用用户无法随意改动代码，以满足自己的要求。那些分别是软件自由的商业好处和个人好处，这两种好处在MaxScale中荡然无存。

MaxScale举动表示，MariaDB公司想要摈弃类似红帽的服务和支持模式，改而采用类似Sugar的独家厂商方案。我不认为客户会买这个账。这种动向恰恰表明了你为什么绝不允许由一家公司合并开源项目的版权，尤其是制定的开源业务愿景目光短浅的公司，此举可能会阻碍MariaDB存活下来的能力。