贵司为 MySQL 掏过钱吗？或者说，你使用的是 MySQL Enterprise Edition 类的产品还是 MySQL Community Edition 类？

开源软件最常见的盈利模式便是基于开源版本提供付费的企业版本，刚刚提到的 MySQL Enterprise Edition 就需要付费才能使用，而 MySQL Community Edition 用 GPL 开源，无需付费。

通常，基于一款开源软件，可能会有许多公司提供企业版开发与服务，比如在 Linux 之上，RedHat、SUSE 等都通过提供企业订阅产品生存。但在 MySQL 这里，只有一个唯一供应商——Oracle，通过实行双许可证的模式，对于想要用 MySQL 做商业化的公司，就必须要向 Oracle 付费，从而实现“单一供应商商业开源”。

这便是当下开源软件实现营收的一种方式——开源许可证+商业授权的双许可模式。许多公司用脚投票，把双许可当做是开源软件创收的一种保障。此外，双许可问题还常常出现在许可证兼容的场景之下。

我开源的软件只能我拿来赚钱

“我认为开源是开发软件的更好方式，但你仍然需要赚够钱来招聘员工，成立公司去跟闭源社区竞争。MySQL 是第一款做到这一点的产品。”——MySQL 之父 Monty。

MySQL 的作者 Monyt 自 1981 年在芬兰公司 Tapio Laakso Oy 做程序员时，写下了 MySQL 的前身。1995 年，Monty 和好友 Allan、David 一起成立了 MySQL AB，也就是那一年，在Allan 和 David 的游说下，Monty 决定在他写的东西之上增加一个 SQL 层。1996 年 10 月，MySQL 发布了，由于其快速、可靠并且易学，快速风靡。

相较 MySQL 的正式发布时间，Monyt 开源软件创收的意识“觉醒”得更早。在 1985 年的一场开源大会上，Monty 发表过观点：“我们都希望回馈给开源社区一点东西，哪怕有人想拷贝或者偷盗我们的代码，我们认为自己能挣的钱也不会比现在少。”开发者社区可以帮助开源项目把软件做得更好，但从商业角度来看，想要实现营收就要困难多了。

为了解决问题，Monty 补充了一个条款，那就是如果任何企业想要用 MySQL 来赚钱的话，就需要付费授权。对此 MySQL 的代码里面并没有进行任何限制，但就靠这样的制度，MySQL 实现了扩张并开始赚钱。

在 Sun 收购 MySQL AB、Oracle 收购 Sun 之后，MySQL 延续了这个模式。目前，Oracle 治下的 MySQL 有多个版本：商业版本 MySQL Enterprise Edition 需要购买，其许可证仅作为订阅提供，被称为 MySQL Enterprise Edition Subscription。MySQL 标准版（MySQL 标准版订阅）和 MySQL 集群 CGE（MySQL 集群运营商级版本订阅）也同样需要购买。此外，MySQL Classic Edition 或 MySQL Community Edition 版本可以免费使用，在 GPL 之下开源。

2010 年，研究者 Dirk Riehle 创造出一个词语，专门形容为商业目的而施行双许可下的开源软件——单一供应商商业开源。

根据 Riehle 的说法：单一供应商商业开源公司围绕他们完全控制的开源软件项目建立业务，通常是通过开发软件、并且从未与第三方共享控制权，拥有代码和相关知识产权（如专利和商标）的完整版权来完成的。而免费的​​开源版本则是根据 GPL 等互惠许可提供的，以推动开源社区用户使用、但阻止可能的竞争对手“薅羊毛”。然后像传统软件供应商一样，根据商业许可提供软件的付费版本，这也被称为商业开源的双许可策略。

Qt 的生产商也是较早使用双许可模式的厂商。1990 年，Trolltech 公司的两位创始人开始开发并在 5 年后发布 Qt1.0 版本。基于 Qt，Trolltech 公司研发了操作环境产品 Qtopia。在 Qtopia 首次公开发布（1.5 版）之际，Trolltech 的联合创始人兼首席执行官 Haavard Nord 曾谈谈及 Qtopia 的市场目标——和微软的个人电脑做竞争。

一段时间内，Qtopia 确实实现了这个目标，通过与硬件厂商合作，包括当时的夏普、数码相机制造商、初创公司等等合作，不断拓展市场。

在 Haavard Nord 看来，这些成就与许可证的使用密不可分：“对我们来说，它帮助我们在开源许可、自由软件许可下分发我们的技术，它也给了我们一个赚钱的机会。”

用户可以获取 GPL 下的 Qtopia 库和工具，并遵守 GPL 的规定，“如果你的软件商业模式不同，拿出你的支票簿，为商业 SDK 支付非常合理的 200 美元。”就这样，双许可证系统运行良好，Nord 说，在桌面上使用 Qt 的 KDE 项目在蓬勃发展，并且免费的 Qtopia SDK 的可用性意味着许多开发人员正在将 KDE 应用程序移植到 Qtopia 上。

现在，Qt 本身也继续实行双许可证制度，LGPL 和商业协议并行，不同版本下代码一致，但权利义务则不尽相同。

这类的软件不在少数，包括 SugarCRM、Oracle 的 NetBeans IDE、Asterisk、Modelio、ZeroC 的 Ice、Magnolia CMS、JUCE、wolfSSL 等等。此外，后来的一些许可证在设置上，也更多考量了开源软件商业化的需求，比如 AGPLv3 的存在，使商业许可的双重许可证变得可行，其取得的巨大的成功离不开初创社区中的应用。MongoDB、RethinkDB、OpenERP、SugarCRM 以及 WURFL 现在都使用 AGPLv3 作为双重商业许可的工具。

摩擦点

既然单一供应商不允许别人直接拿开源产品来盈利，那换一种思路，Fork 一个开源版本，对其进行独立开发，从而创建一个相较独立的软件。当然，这往往也意味着社区的分裂。

单一供应商商业开源模式研究者 Simon RB Berdal 曾指出，双许可下的 OSS 在治理中会呈现出一种偏向商业考量的趋势，因此，为了防止社区的争议与分裂，必须要在商业考量和“开放”利益之间取得平衡。

以 SugarCRM 为例，仔细比对来自 SugarCRM 社区的声音之后，Berdal 总结出 5 个显著的摩擦点，支持商业开源（COSS）和 SugarCRM 的一派，与支持 FOSS 的一派之间观点对比鲜明。当然不仅仅是在 SugarCRM 身上，下文这几个摩擦事件基本上可以概括单一供应商商业开源软件的一些共性。首先可以站在 COSS/SugarCRM 的立场上去看做这些事情的理由。

第一，贡献者的代码需要进行版权转让。支持转让是因为版权转让是双重许可的先决条件，否则软件会有版权风险，就不具有商业可持续性。

第二，部分功能不会在社区版中开放。COSS/SugarCRM 认为，这是针对 OSS 的 Fork 版的先发制人的优势，保留一些有价值的功能也会增大商业版与社区版的差异，从而有助于提升价格。此外，社区用户也可以冲着更好地功能迁移到商业版本。

第三，由 SugarCRM 提供商标。官方认为，这是承认所投资作品的合法作者的署名，有助于品牌推广，并且阻止 Fork 尝试，扼杀未经请求的外部代码的重用。

第四， 采用相较“封闭”的治理模式，甚至受到 COSS 标准的限制。COSS/SugarCRM 派认为，由公司主导的管理与控制，可以确保有效满足客户的需求，同时也会限制 FOSS 爱好者对社区的影响。

第五，商业附属社区成员和第三方优惠待遇。从商业视角来看，合理的差异化对待方法，可以利用 SugarCRM 产品平台，提升商业既得利益，包括借助合作伙伴的能力拓展公司销售渠道，刺激需求驱动的定制化业务发展，增加产品平台的整体价值等等。

以上这五点都是 FOSS 支持派所反对的做法，主要原因集中在不道德，对贡献者不公平，比如贡献者进行版权转让，社区贡献出的代码如果连版权也转让出去了，会有被商业公司拿来直接做私有化的风险，因此不鼓励作出贡献。而保留一些有价值的功能，紧握商标权这些行为也与自由开放的精神不相符合。社区的较封闭治理与商业成员优待，则凸显了开源软件社区的不公平。

在大量摩擦点爆发之后，SugarCRM 决定停止开发其开源版本，继而 Fork 版的 SuiteCRM 项目出现，成为 HubSpot、Salesforce 和 Microsoft Dynamics CRM 应用程序等大公司专有 CRM 软件的替代品。而SuiteCRM 出现之后也多次获得全球最佳开源 BOSSIE 奖，曾被赞誉“在短短一年多的时间里，SuiteCRM 激发了社区并成为开源 CRM 的新领导者。”

许可证兼容问题

双许可又或是多许可的第二个用途便是为了许可证兼容。

“如果你要把两个自由程序合二为一，或者把其中之一的代码并入另一个，那么就会有一个它们的许可证是否允许/禁止这样做的问题。”Richard Stallman 也曾专门研究过这个问题。在许可证相同的情况下，无需多虑，但许可证不同时，如果有方法可以合并代码而又能同时遵循各个代码的许可证，那么这些许可证才能称之为“兼容的”。

Richard Stallman 将许可证分成 3 类：宽松型，包括 BSD、X11、Expat、Apache、Python；中间型；copyleft 型，包括 GPL v2、GPL v3 等等。

松散型许可证通常相互之间可以互相兼容，甚至不介意专有闭源软件使用其代码。中间型许可证限制但并不禁止专有软件使用其代码。copyleft 许可证禁止专有软件使用其代码，它明确要求所有使用其代码的程序都要使用同样的许可证。此外，除非两者之间有明确的兼容条款，通常 copyleft 许可证之间无可避免地不兼容。因此 copyleft 的理念是 “修改和扩展的版本必须延用同样的许可证”，相当于不兼容是一种与生俱来的特点。

对此，FSF 给出的解决办法是建议人们按照 “遵循 GNU GPL 版本 N 或任何以后版本”来发布程序，解决兼容性问题，这个办法实际上相当于加上一个兼容方面的“豁免条例”。比如软件作者想使用 GPL3 协议，便可以使用“GPL 3 或以后版” 来当做软件的许可证，以解决以后可能会随着 GPL 更新所带来的兼容性问题。

当然，这世界上不仅仅只有 GPL 系列的许可证，那么开发者如何在有需要时判断许可证兼容性问题，提前避坑？信通院可信开源曾发布《开源许可证兼容性指南》，列举出许可证的兼容性列表的两种情况，给出兼容性指示图：

• 合并/修改代码：从要组合的代码中取出整体/部分代码，修改或不修改都可以，然后把它添加到你的代码中构成一个作品。
• 使用库：没有直接复制代码，在编译或运行时通过链接、导入或其他典型的机制（例如静态与动态链接）把要组合的开源代码绑定在一起。

详情可查看：https://gitee.com/trustworthy-open-source-community/License-Compatibility/blob/master/%E5%BC%80%E6%BA%90%E8%AE%B8%E5%8F%AF%E8%AF%81%E5%85%BC%E5%AE%B9%E6%80%A7%E6%8C%87%E5%8D%97.md