从开源许可到商业运营
2022-02-03 16:09:54 
阿炯
在2021年末，《国内首例违反 GPL 协议侵权案一审结束》一文提出一个冷门却又重要的知识点：GPL 许可证之下的开源项目，可以分叉出来闭源吗？大家非常关心这类问题，但是却普遍缺乏相应知识。
其实这算是国内开源的一个弊病 —— 开源知识普及不够。不少实践者因为接触此类知识的途径有限，加上相关意识也不足，很容易犯错，造成误会和麻烦。就比如以上案件中的原告罗盒公司，之所以后期会将 GPLv3 许可证下的开源项目闭源，大概率就是这个原因。又比如之前被机械妖姬上门索要源码的国内公司，后来其实也很配合地公布了源码，究其根源也大概是这个原因。
总的来说，许多开发者主要是两个方面知识没有补课到位：
第一，在选择开源许可证的时候，不知道该怎么选，更不知道选择这个许可证对项目来说到底意味着什么？
第二，选择开源项目变现时的商业模式为了难，不是想闭源 GPL，就是乱加附加条款。
自打开源诞生，从来都没有拒绝过商业化，只不过需要掌握一些知识和技巧罢了。以下是一些关于开源许可证和开源商业模式的科普知识，都是我在查找资料过程中发现的宝藏文章的节选，有关来源我也一并给出，大家感兴趣可以查看原文，全面掌握。
1、开源许可证都会保留版权，差别在于共享权限
从 RMS (Richard Mattew Stallman)提出 GPL 开始，开源许可证发展到现在已经有了上百种，但流行的其实并不多。原教旨一些，只有被 OSI (Open Source Intiative)认可才能称之为开源许可证，而其它一些例如 SSPL、Elastic 等都是商业许可证。那些官方认证的开源许可证被罗列在了 OSI 官网上。网站上将所有其认可的开源许可证分为“流行且广泛使用或拥有强大社区”的许可证、国际许可证、特殊用途许可证、不可重复使用的许可证、被取代的许可证等几大类。
其中出现频率最高、最常被使用的无非是以下几种：
本站也提供了相关的说明：《如何选择开源许可证》
开源许可证虽然五花八门，但共同点都是保留版权，而在商业兼容性或共享权限上体现区别。在一些科普文章中，经常将这些开源许可证分为三大类，这里我们将中国信通院在 2018 年 3 月发表的《开源治理白皮书》中的一段节选出来：
一类是传染型开源许可证(Copyleft)：
传染型开源许可证明确修改版本须以同一许可证发布， 如果一个软件包含该协议下部分代码，完全发布时必须作为整体适用 该协议，GNU General Public License Version 2 或 Version 3 (下 称“GPL V2”或“GPL V3”)作为传染型开源许可证给予任何人自由 复制、修改和发布 GPL 代码的权利，但是作为回报，所有以 GPL 协议 发布的源代码的衍生，也必须按照 GPL 发布。
第二类是弱传染型开源 许可证(Weak-Copyleft)：
如果一个软件包含该协议下部分代码，完 全发布时某些部分必须适用该许可证，其它部分可在其它协议下发 布，如 LGPL、MPL 等。
第三类是获准型许可证：
对已修改代码的许可方式没有任何要求，如 BSD 要求许可证附上许可证的原文以及所有开发者的版权资料，它允许原作品及修改版发行不公开源代码或以其它 许可证发行。广泛使用的开源许可证包括 Apache-2.0、 BSD-3-Clause、BSD-2-Clause、GPL、LGPL、MIT、MPL-2.0、CDDL-1.0、Eclipse 2.0。
此外，《开源治理白皮书》也罗列一些常用许可证各自的特点：
-- GPL(GNU General Public License，GNU 通用公共许可证): 一种广泛使用的自由软件许可证，保证用户可以自由的运行、学习、分 享和修改软件。许可证最初由自由软件基金会 (FSF) Richard Stallman 为 GNU 项目所撰写。GPL 是一个非盈利版权许可证，要求衍生作品只能在相同的许可条款下发布。GPL 的出发点是代码的开源使用和引用代码开源使用，不允许修改后和衍生的代码作为闭源的商业软件发布和销售。
--LGPL (GNU Lesser General Public License，GNU 宽通用公共 许可证): 一种由 FSF 颁布的自由软件许可证，允许开发者或公司在私有软件中使用，不要求使用 LGPL 许可代码的软件以 LGPL 方式发布。与 GPL 的强制性开源方式不同，LGPL 允许商业软件通过类库引用的方式使用 LGPL 类库而不需要开源商业软件的代码。
--BSD (Berkeley Software Distribution): 允许使用者修改和重新发布代码，也允许使用或在 BSD 代码上开发商业软件并发布和销售。
--MIT License: 允许开发者任意处置该软件，包括使用、复制、修改、合并、发表、分发、再授权或者销售。唯一的限制是，软件中必须包含许可提示。
--Apache License: 一种由 Apache 软件基金会发布的自由软件许 可证，相对比较友好，被授权者可以发布商业化软件。
--MPL (Mozilla Public License 1.1): MPL 协议允许免费重发 布、免费修改，但要求修改后的代码版权归软件的发起者。
--CDDL (Common Development and Distribution License): CDDL 开源许可证，是 MPL 的扩展协议，它允许公共版权使用，无专利费，并提供专利保护，可集成于商业软件中，允许自行发布许可。
--EPL (Eclipse Public License 1.0 ): EPL 允许 Recipients 任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。
还有一个知识点值得关注：开源软件的专利该如何处理？这个问题在《写了开源软件没申专利，反被索赔该怎么办》一文中已经阐述了，大家可以扩展阅读。
2、不同许可证适合的商业模式也不一样
开源软件企业如何通过一定的盈利模式来持续获取利润？之前，知乎博主刘博用了一篇大长文《“技术-经济范式”视角下的开源软件演进剖析》来剖析，其中对开源商业模式的总结十分全面。为了大家快速找到重点，节选了这一部分：
根据开源软件商业模式与软件本身的紧密程度，国内外常见的 10 种商业模式可分为三大类：许可证类、直接配套类、间接配套类以及附属产品类。
其中典型主流的商业模式包括:
a.销售专业服务模式(selling professional services)
销售专业服务模式是指通过为开源软件提供专业服务获利，比如培训、技术支持或者技术咨询等。许多企业没有资源也没有能力来维护自身的IT 系统，于是就出现了专门为企业提供基于开源软件的IT服务公司。因为开源软件的特性，使得公司有编程能力的工程师可以熟练掌握，并利用专业所长为其他企业提供相应的服务。
在该模式下，免费用户仅能获得开源软件的源代码而不包括可执行的二进制代码，付费用户则可同时获得可执行的二进制代码，并且包括软件编译和打包等商业化服务；此外还可同时提供物理安装媒体(比如DVD)。
红帽公司就主要通过订阅模式向客户提供专业服务，逐渐成长为最成功的开源软件公司。
b.双许可模式(dual-licensing)
双许可模式是最常见的开源软件商业模式之一，指开发者不仅在开源许可证下提供软件，还在专有软件许可证下提供软件。
在该模式中，产品的源代码主要来源于开源社区或软件厂商，这两部分的源代码共同组成了核心产品，再通过两类许可证(专有许可证和开源的copyleft 许可证)分别许可给免费用户和付费用户。专有版本的营收将用于下一个版本开源软件的研发中。
双许可模式中，用户在开始阶段被免费的开源版本所吸引，在使用过程中通过不断了解厂商所能提供的商业化技术支持和服务，进而成为购买付费版本的客户。以MySQL 数据库为例，公司同时推出面向个人的开源版本和面向企业的专有版本两种，所采用的商业模式就是开源 copyleft 许可证(GPLv2)和专有软件许可证的双重许可。
c.再许可专有化模式(re-licensing under aproprietary license)
再许可专有化模式是指在某些宽松许可证下，允许软件厂商将自身的专有软件与宽松许可证下的开源软件进行组合，组合后的软件产品可以不提供源代码。
该模式的软件供应商可以针对最终的软件产品在专有许可证下进行销售，甚至直接对某些开源软件进行修改后进行销售。软件产品是由开源社区和软件供应商两部分开发者开发的软件组合而成(两者所开发的不是同一个软件)。开源社区的开发者们开发的是一款开源软件，并且该开源软件应用了宽松的开源许可证，允许再次许可闭源；而软件供应商开发的是专有软件，软件供应商将该专有软件与开源软件进行组合开发，然后形成一款新的软件产品，并在专有许可证下进行销售。
该商业模式被众多公司采用，以苹果公司操作系统Mac OS 为代表，该系统就是利用再许可专有化模式来开发其软件产品的，苹果 Mac 个人电脑的系统基于 BSD 操作系统内核进行开发，现为苹果公司专有软件产品进行销售。
d.嵌入广告模式(advertising-supported software)
嵌入广告模式是指依靠开源软件的快速推广而使软件内的嵌入广告得以传播。软件厂商将广告嵌入开发的软件产品中，软件产品即由软件本身和厂商嵌入的广告两部分构成。整个软件产品作为开源软件提供给广大的用户，开源软件的推广会带来越来越多的客户，这样就使得软件中嵌入的广告产生了传播的价值，广告厂商达到了产品推广的效果，更愿意向软件厂商投放广告，而软件厂商获利则会继续投入到开源软件的开发中，形成一个良性循环。
多数开源软件企业倾向于率先采用嵌入广告的商业模式来获得收入、维持经营。例如，Android 平台为Google带来了大量的移动广告流量。
随着开源软件的发展，企业由以往采用单一开源软件商业模式的策略向采用多种组合的策略转变，例如Red Hat 公司不仅提供订阅专业服务，还进行配套专有软件的销售。
此外，结构化分析结果表明，开源软件的不同商业模式所用许可证类别具有很大的差别。
开源许可证管理公司黑鸭子软件数据显示，从2009 年到2015 年期间，MIT 许可证的份额上升了15.7%，Apache 的份额上升了12.4%，而GPLv2 和v3的份额下降了21.4%。GitHub 调查数据显示，MIT以45% 的占有率成为最流行的许可证；与之相比，GPLv2 只有13%。大多数开源软件商业模式都要求宽松许可证，发展趋势显示，大量软件从限制性许可证转到宽松许可证，与之相关的商业模式也越来越倾向于使用宽松许可证。
本文主要转载了来自lola_chen在oschina上的文章，感谢原作者。
全球 22 种开源商业收入模式
作者：郭炜（郭大侠）
近些年来开源在全球成为越来越火爆的话题，越来越多的开源项目获得了大量的投资或者最终上市。开源是根据一些开源协议把代码公开在互联网上并拥有开源社区和使用者的一种开发模式，那么开源项目代码是开放的，又是如何能够形成商业闭环形成商业收入的呢？
笔者参考了全球多个论文网站和公司材料，最终于2022年9月总结了全球大部分开源项目形成收入的商业模式，一共 22 种，如果是开源爱好者或者有自己的开源项目，可以从这些开源商业公司的商业模式中找到一些启发。
核心开源，非核心闭源
首先最常见的就是软件核心代码部分开源，非核心部分闭源从而通过各种形式收费的商业模式，细分下来这种收入模式一共有 4 个子类别：
第 1 类收费模式是开源商业 SaaS 模式，也就是核心代码开源，但是商业的 SaaS 云服务背后的代码闭源，且其中部分功能是开源版所没有的。比较典型的就是我们耳熟能详的 Databricks，它开源的 Apache Spark 是以 Apache 协议开源的，但是 Databricks 的云服务是闭源的，且其中的性能和功能要远超过其开源的 Spark 版本。
第 2 类就是 open-core 商业软件模式，也就是核心代码开源，但是部分功能代码是闭源，最终形成了闭源的代码软件进行售卖。比如大家最熟悉的支持开源 Apache Hadoop 的 Cloudera 公司所售卖 Cloudera Data Platform 就是这种软件模式的代表。当然随着云化的发展，这些以软件为初始售卖的商业公司，现在也都提供了自己云版本。但依然有很多常见开源软件是利用这种模式去售卖的。
第 3 类是 Plug-in 收费模式，软件本身都是开源的，但是它上面的插件是收费的，这些插件可以帮助这个软件更快地在行业当中提高它的使用效率或者完成特定的目标功能，部分 CAD 开源软件公司使用这种商业模式。
第 4 类是素材收费模式，也就是软件本身是开源的，但是它在运行或者使用时需要相关的素材，而这些素材是需要购买的。这种商业模式在游戏引擎方面比较常见，因为引擎本身只是一个计算核心，而周边的材质配齐了才能够快速开发相关的游戏，这个商业模式例子是 Arx Fatalis，Catacomb 3-D 等这样的引擎。
上面介绍的 4 类其实都是核心代码开源，但是周边有部分的能力是要收费的模式。
托管和整合
第 5 种就是我们常见的云托管模式，它的代码几乎和开源项目完全一样，只在云账号和相关的服务上面有略有不同，用户无需自己再去安装开源软件，也不用雇相关人员进行维护开源软件，直接使用相关的服务即可，比较典型的就是 MongoDB、Elastic 公司提供的托管服务。
第 6 种是硬件和开源软件整合到一起的一体机模式，例如，当年的 Sun 公司将开源的 Solaris 捆绑在自己的服务器上面进行售卖，最终的用户不需要自己再安装软件调试或者适配也可以直接使用硬件提供商提供的相关开源软件。
上面两种核心的商业模式其实都是帮助企业节约安装调试和部分运维成本而出现的商业模式。
软件市场模式
这种一种更为宏大的生态型商业模式。
第 7 种是软件市场（marketplace），这种商业模式一般出现在操作系统或者用户量极大的基础软件。例如 Android，Mozilla 的 Firefox，他们有庞大的用户使用基础。同时很多人会基于这个软件环境开发自由软件或插件，当用户购买他上面的这些软件时，公司通过收取中间的抽成来实现收入。
专业服务
第 8 种是提供普通运维和问答服务来进行（Professional Service），例如 Hortonworks（被 Cloudera 收购之前）的 HDP 和 Redhat 都是这种模式。它的软件代码是和开源同一套代码，企业需要支付支持和咨询费用来确保这些软件正常使用。
第 9 种是软件本身开源，通过升级服务收费来进行收入的。这种一般软件本身非常容易使用，但是它自身的数据却非常重要，每次升级的过程当中，用户为了保证企业数据完整性以及升级之后的软件稳定性，会购买专业开源原厂公司的升级服务。
售卖代码
第 10 种是售卖软开源软件的二次分发授权进行收入，例如大家熟悉的 macOS 基于 BSD Unix operating system kernel 专属权进行开发的，那么 BSD Linux 靠此授权来获得收入。
第 11 种是售卖同样开源代码软件且提供相关服务来进行收入。例如 ardour 和 radium，他们是售卖一模一样的开源软件的二进制代码以及相关的服务来进行收入，一般这种模式小型软件居多。
延迟开源
靠商业软件获得收入之后再进行开源的模式。这样的方式可以保证最新版本的商业收入，同时能保证开源社区的活力。
第 12 种开源商业模式就是延迟开源模式，也就是新版闭源，旧版本开源的模式，比较典型的就是 MariaDB Corporation。它的新版本都是商业版，但当他研发出更新的商业版本之后，他原来的商业版就会被开源出来让大家使用。
第 13 种叫退市开源，这种模式是商业软件已经基本上完成了它的商业生命周期，在退市的时候，它会被开源出来。很多游戏软件其实都是这种模式，所以我们能看到很多的 MOD 游戏模式都是基于这样的退市的游戏软件开发出来的，比较典型的就是 id Software and 3D Realms 公司相关的游戏软件。
围绕开源周边服务
第 14 种开源商业模式是卖认证。软件本身是开源的，但是它所提供的基于该软件的相关内容或相关服务要收费，因为它是软件和模式的发起者。所以，它可以通过认证的模式来进行收入。经过他认证的体系会更加权威，用户可以更加放心地购买，比如早期的 Unix v3 v8 的认证，和现在的 Moodle 模式。
第 15 种开源商业模式是卖培训和周边的参考资料，开源软件本身不一定是由公司建立的，但是他可以卖相关培训和出版相关资料进行收入，例如 O'Reilly 出版公司就是以售卖开源书籍著名的。
利用开源社区的用户流量
第 16 种是经营开源社区合作来进行收入。例如比较著名的谷歌的开源之夏（GSoC），它的收入模式就是帮助各种社区组织开发者经营活动来实现部门收入。
第 17 种是售卖开源软件上的流量赚取费用。软件本身是开源的，用户流量多了，软件利用其中的流量进行收入。在谷歌 chrome 插件里面最流行的 AdBlock Plus 就是如此，每年谷歌都会要付大量的费用来让他不 block 来自谷歌的广告。AdBlock Plus 靠此来进行收入。
有偿开源
下面两种都是参与开源项目的公司或个人进行收入的方法。
第 18 种叫悬赏开源，也就是在开源社区里面悬赏相关任务，最终开发者完成相关任务。获得相关奖励，最终实现个人和公司的收入。比如 Mozilla 曾经悬赏志愿者或公司去解决它的安全隐患然后付出相关费用。
第 19 种叫做众筹。也就是一个开源项目，会对他的用户进行预售，筹划到一定的金额后，再雇佣开源开发者完成这个项目，并且以开源的形式开放出来，例如 OpenGL 4.3 extension for the Mesa librar 就是这种模式开发出来的开源项目。
捐献
下面的两种开源都是比较佛系的。不靠软件本身赚钱，而是靠周边和捐献来获得收入维持。
第 20 种是接纳捐献来获得收入。例如 Mozilla Foundation，每年都会受到 Google 大量的捐赠来维持整个 Mozilla 基金会的运作。类似还有中国的华人开发者尤雨溪做的 VUE 也接受了各种公司大量的捐助。
第 21 种是售卖品牌周边进行收入，例如 Mozilla Foundation 和 Wikimedia Foundation 都有相关的情怀 T 恤或者马克杯。最近的 Apache Con Aisa 个人票当中的飞盘、贴纸、杯子、帽子，其实都是周边售卖获得收入的。
Web3 to Developer
第 22 种，也是最后一种，是我非常看好但还是在发展过程当中的开源收入模式，这就是 Web3 to Developer。开源社区本身就是一个 DAO，只不过目前的开源还很难通过衡量个人的贡献来获得收入。开源软件也很难变成一个像 NFT 一样的组织来获得收入和获利。但是我觉得随着 DAO 理论的发展和相关技术的进步一定会解决相关的问题，从而真正实现每一个开源贡献者劳有所得，每一个开源公司贡献有所收获，每一个投资者投资都有回报，这才是开源社区的最终解决方案。
综上，花了挺长时间整理了各种各样的开源到商业的玩法，我也在 Gitee 上建立了一个开源商业的项目，并把这篇文章和表格进行了开源，欢迎在里面去评论或者 PR 或者提 issue 来贡献，共同把开源社区的商业化做到极致，感谢各位。
OSI 报告：从历史角度看延迟开源发布(DOSP)
Open Source Initiative (OSI) 于2024年1月发布了一份名为《Delayed Open Source Publication: A Survey of Historical and Current Practices》的新报告，深入研究了 DOSP 的历史、模式以及发展趋势。DOSP是是首先在专有许可证下分发或公开部署软件，然后以开源许可证有计划地发布该软件源代码的做法；Business Source License (BSL) 就是一种广为人知的 DOSP 许可。
在整个开源软件历史中，软件生产商都一直在实践 DOSP；报告收集了一些示例，并对其进行分类以进行分析。最早的 DOSP 实例之一是 1998 年左右根据 "Aladdin Free Public License" 发布的 Aladdin GhostScript，后来过渡到同时采用专有许可和 GPL 的发布模型。KDE 的 Qt 库也是一个鲜明的示例，它将 DOSP 作为防止潜在开发中止的一种保障措施。Qt 的许可历史很复杂，如今其可以在商业和开源 GPL 2.0、GPL 3.0 和 LGPL 3.0 许可下使用。
研究人员发现 DOSP 大致有 3 种类型：
1.Unconditional scheduled relicensing。这种直接的方法涉及在过渡到开源许可之前预先定义的时间延迟。
2.Event-driven relicensing。在这种情况下，开源发布与特定事件相关联，比如发布新的专有版本，促使其前身开源。虽然这种方式曾经很常见，但现在已经很少使用了。
3.Conditional relicensing。这种类型取决于某些条件，例如在转向开源之前获得资金或找到合适的非营利组织。但这个承诺可能会存在不会兑现的风险。
与 DOSP 相关的一个变种是 "visible source" 或 "source available"。在这些模型中，源代码通常是可用的，但没有 Open Source Definition (OSD) 所保证的自由。近期比较著名的例子就是 Meta 的 AI 大语言模型 Llama 2 Community License，其代码是可用的，但商业使用受到限制。
OSI 研究人员发现，在 DOSP 早期，DOSP通常是为了垄断直接的商业收入：许可证将授予开源所需的大部分权限，但关键是不允许商业使用软件。这一限制适用于包括用户在内的所有下游被许可方，而不仅仅是开发者。然而最近一些 DOSP 许可证是为了防止任何被许可人在与某些特定类型的软件竞争的产品或服务中使用该软件，而这些软件对许可人来说具有重要的战略意义，与直接收入无关。
例如为 MariaDB 编写的 BSL 1.1 不允许在生产中使用许可代码，除非许可人使用 "Additional Use Grant (AUG)" 机制。但 AUG 因公司而异，也正因如此，每个 BSL 实例实际上都是一个本质上不同的许可证。
现如今 BSL 正在兴起。HashiCorp 在2022年宣布变更核心产品的开源协议，从 MPL 2.0 迁移到 BSL 1.1，CouchBase、DragonflyDB 和 ArangoDB 等十来个项目都也使用了 BSL 协议。
除了 DOSP 许可证，MongoDB 和 Redis 等几个面向云的软件项目在过去几年中也放弃了开源许可证，转而采用带有非竞争条款的许可证 (如 SSPL)。
研究认为，DOSP是企业用来保持商业优势，同时试图尽可能多地保留开源的优势的一种方式。但随着延迟的增加，开源的好处也会越来越少。探索这些好处与独占利用期限之间的权衡是未来值得研究的方向。此外，DOSP 的实验和多样性也都比我们所意识到的要多得多 -- 尝试 DOSP 的项目、以及尝试的方式都要远远多出想象。
报告还提出了一些未来值得继续研究的方向，包括：AGPL 与 DOSP 许可对比、对外部贡献的影响、首次发布开源代码后的重新授权等等。更多详情可查看完整报告。
OSI 发布报告研究 BSL 这样的 “延迟开源发布”
Open Source Initiative（OSI）2024年2月发布了一个报告《Delayed Open Source Publication: A Survey of Historical and Current Practices》（延迟开源发布：历史与当前实践调研），作者是 Seth Schoen、James Vasile 和 Karl Fogel。
Delayed Open Source Publication，简称 DOSP，延迟开源发布的意思，这份报告研究了它的历史和现状。报告核心要点：
延迟开源发布（DOSP）定义：DOSP 是指软件最初在专有许可下发布，然后计划性地在某个时间点将源代码以开源许可的形式公开。
历史背景：DOSP 的做法可以追溯到 GNU 项目，并且一直延续至今。公司尝试各种商业模式，以在有限时间内保持独家权利，然后过渡到 OSI（开放源代码倡议）批准的许可。
策略类型：DOSP 分为三种类型：无条件计划性重新许可、事件驱动的重新许可和有条件的重新许可。
商业源许可（BUSL）：BUSL 是一种新兴的 DOSP 许可方式，它要求在特定的 “变更日期” 后，软件的许可将变为开源许可。这种做法在数据库系统中尤为常见。BUSL 的采用正在迅速增长，尤其是在云和软件即服务（SaaS）领域。（以往也叫 BSL）
以下是当前知名的 16 个使用 BUSL 的项目，都是延迟几年后转型成开源协议：
反竞争条款：一些 DOSP 许可中包含反竞争条款，旨在防止许可证持有者使用软件提供与许可方直接竞争的服务。
后果和影响：从开源许可转变为 DOSP 许可的项目可能会受到批评，有时会导致用户转向其他项目或维护竞争性的分支。
未来研究问题：报告提出了一些未来研究的问题，包括 AGPL 与 DOSP 许可的比较、DOSP 对外部贡献的影响、BUSL 额外使用授权的分类、以及在初始开源发布后重新许可的策略。
结论：DOSP 自开源运动早期以来一直在使用，公司通常利用它来保持商业优势，同时尽可能保留开源的优势。报告强调，DOSP 的实验性和多样性比预期的要多，且这种趋势可能会继续。
详情可以查看报告原文。
其实这算是国内开源的一个弊病 —— 开源知识普及不够。不少实践者因为接触此类知识的途径有限，加上相关意识也不足，很容易犯错，造成误会和麻烦。就比如以上案件中的原告罗盒公司，之所以后期会将 GPLv3 许可证下的开源项目闭源，大概率就是这个原因。又比如之前被机械妖姬上门索要源码的国内公司，后来其实也很配合地公布了源码，究其根源也大概是这个原因。
总的来说，许多开发者主要是两个方面知识没有补课到位：
第一，在选择开源许可证的时候，不知道该怎么选，更不知道选择这个许可证对项目来说到底意味着什么？
第二，选择开源项目变现时的商业模式为了难，不是想闭源 GPL，就是乱加附加条款。
自打开源诞生，从来都没有拒绝过商业化，只不过需要掌握一些知识和技巧罢了。以下是一些关于开源许可证和开源商业模式的科普知识，都是我在查找资料过程中发现的宝藏文章的节选，有关来源我也一并给出，大家感兴趣可以查看原文，全面掌握。
1、开源许可证都会保留版权，差别在于共享权限
从 RMS (Richard Mattew Stallman)提出 GPL 开始，开源许可证发展到现在已经有了上百种，但流行的其实并不多。原教旨一些，只有被 OSI (Open Source Intiative)认可才能称之为开源许可证，而其它一些例如 SSPL、Elastic 等都是商业许可证。那些官方认证的开源许可证被罗列在了 OSI 官网上。网站上将所有其认可的开源许可证分为“流行且广泛使用或拥有强大社区”的许可证、国际许可证、特殊用途许可证、不可重复使用的许可证、被取代的许可证等几大类。
其中出现频率最高、最常被使用的无非是以下几种：
本站也提供了相关的说明：《如何选择开源许可证》
开源许可证虽然五花八门，但共同点都是保留版权，而在商业兼容性或共享权限上体现区别。在一些科普文章中，经常将这些开源许可证分为三大类，这里我们将中国信通院在 2018 年 3 月发表的《开源治理白皮书》中的一段节选出来：
一类是传染型开源许可证(Copyleft)：
传染型开源许可证明确修改版本须以同一许可证发布， 如果一个软件包含该协议下部分代码，完全发布时必须作为整体适用 该协议，GNU General Public License Version 2 或 Version 3 (下 称“GPL V2”或“GPL V3”)作为传染型开源许可证给予任何人自由 复制、修改和发布 GPL 代码的权利，但是作为回报，所有以 GPL 协议 发布的源代码的衍生，也必须按照 GPL 发布。
第二类是弱传染型开源 许可证(Weak-Copyleft)：
如果一个软件包含该协议下部分代码，完 全发布时某些部分必须适用该许可证，其它部分可在其它协议下发 布，如 LGPL、MPL 等。
第三类是获准型许可证：
对已修改代码的许可方式没有任何要求，如 BSD 要求许可证附上许可证的原文以及所有开发者的版权资料，它允许原作品及修改版发行不公开源代码或以其它 许可证发行。广泛使用的开源许可证包括 Apache-2.0、 BSD-3-Clause、BSD-2-Clause、GPL、LGPL、MIT、MPL-2.0、CDDL-1.0、Eclipse 2.0。
此外，《开源治理白皮书》也罗列一些常用许可证各自的特点：
-- GPL(GNU General Public License，GNU 通用公共许可证): 一种广泛使用的自由软件许可证，保证用户可以自由的运行、学习、分 享和修改软件。许可证最初由自由软件基金会 (FSF) Richard Stallman 为 GNU 项目所撰写。GPL 是一个非盈利版权许可证，要求衍生作品只能在相同的许可条款下发布。GPL 的出发点是代码的开源使用和引用代码开源使用，不允许修改后和衍生的代码作为闭源的商业软件发布和销售。
--LGPL (GNU Lesser General Public License，GNU 宽通用公共 许可证): 一种由 FSF 颁布的自由软件许可证，允许开发者或公司在私有软件中使用，不要求使用 LGPL 许可代码的软件以 LGPL 方式发布。与 GPL 的强制性开源方式不同，LGPL 允许商业软件通过类库引用的方式使用 LGPL 类库而不需要开源商业软件的代码。
--BSD (Berkeley Software Distribution): 允许使用者修改和重新发布代码，也允许使用或在 BSD 代码上开发商业软件并发布和销售。
--MIT License: 允许开发者任意处置该软件，包括使用、复制、修改、合并、发表、分发、再授权或者销售。唯一的限制是，软件中必须包含许可提示。
--Apache License: 一种由 Apache 软件基金会发布的自由软件许 可证，相对比较友好，被授权者可以发布商业化软件。
--MPL (Mozilla Public License 1.1): MPL 协议允许免费重发 布、免费修改，但要求修改后的代码版权归软件的发起者。
--CDDL (Common Development and Distribution License): CDDL 开源许可证，是 MPL 的扩展协议，它允许公共版权使用，无专利费，并提供专利保护，可集成于商业软件中，允许自行发布许可。
--EPL (Eclipse Public License 1.0 ): EPL 允许 Recipients 任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。
还有一个知识点值得关注：开源软件的专利该如何处理？这个问题在《写了开源软件没申专利，反被索赔该怎么办》一文中已经阐述了，大家可以扩展阅读。
2、不同许可证适合的商业模式也不一样
开源软件企业如何通过一定的盈利模式来持续获取利润？之前，知乎博主刘博用了一篇大长文《“技术-经济范式”视角下的开源软件演进剖析》来剖析，其中对开源商业模式的总结十分全面。为了大家快速找到重点，节选了这一部分：
根据开源软件商业模式与软件本身的紧密程度，国内外常见的 10 种商业模式可分为三大类：许可证类、直接配套类、间接配套类以及附属产品类。
其中典型主流的商业模式包括:
a.销售专业服务模式(selling professional services)
销售专业服务模式是指通过为开源软件提供专业服务获利，比如培训、技术支持或者技术咨询等。许多企业没有资源也没有能力来维护自身的IT 系统，于是就出现了专门为企业提供基于开源软件的IT服务公司。因为开源软件的特性，使得公司有编程能力的工程师可以熟练掌握，并利用专业所长为其他企业提供相应的服务。
在该模式下，免费用户仅能获得开源软件的源代码而不包括可执行的二进制代码，付费用户则可同时获得可执行的二进制代码，并且包括软件编译和打包等商业化服务；此外还可同时提供物理安装媒体(比如DVD)。
红帽公司就主要通过订阅模式向客户提供专业服务，逐渐成长为最成功的开源软件公司。
b.双许可模式(dual-licensing)
双许可模式是最常见的开源软件商业模式之一，指开发者不仅在开源许可证下提供软件，还在专有软件许可证下提供软件。
在该模式中，产品的源代码主要来源于开源社区或软件厂商，这两部分的源代码共同组成了核心产品，再通过两类许可证(专有许可证和开源的copyleft 许可证)分别许可给免费用户和付费用户。专有版本的营收将用于下一个版本开源软件的研发中。
双许可模式中，用户在开始阶段被免费的开源版本所吸引，在使用过程中通过不断了解厂商所能提供的商业化技术支持和服务，进而成为购买付费版本的客户。以MySQL 数据库为例，公司同时推出面向个人的开源版本和面向企业的专有版本两种，所采用的商业模式就是开源 copyleft 许可证(GPLv2)和专有软件许可证的双重许可。
c.再许可专有化模式(re-licensing under aproprietary license)
再许可专有化模式是指在某些宽松许可证下，允许软件厂商将自身的专有软件与宽松许可证下的开源软件进行组合，组合后的软件产品可以不提供源代码。
该模式的软件供应商可以针对最终的软件产品在专有许可证下进行销售，甚至直接对某些开源软件进行修改后进行销售。软件产品是由开源社区和软件供应商两部分开发者开发的软件组合而成(两者所开发的不是同一个软件)。开源社区的开发者们开发的是一款开源软件，并且该开源软件应用了宽松的开源许可证，允许再次许可闭源；而软件供应商开发的是专有软件，软件供应商将该专有软件与开源软件进行组合开发，然后形成一款新的软件产品，并在专有许可证下进行销售。
该商业模式被众多公司采用，以苹果公司操作系统Mac OS 为代表，该系统就是利用再许可专有化模式来开发其软件产品的，苹果 Mac 个人电脑的系统基于 BSD 操作系统内核进行开发，现为苹果公司专有软件产品进行销售。
d.嵌入广告模式(advertising-supported software)
嵌入广告模式是指依靠开源软件的快速推广而使软件内的嵌入广告得以传播。软件厂商将广告嵌入开发的软件产品中，软件产品即由软件本身和厂商嵌入的广告两部分构成。整个软件产品作为开源软件提供给广大的用户，开源软件的推广会带来越来越多的客户，这样就使得软件中嵌入的广告产生了传播的价值，广告厂商达到了产品推广的效果，更愿意向软件厂商投放广告，而软件厂商获利则会继续投入到开源软件的开发中，形成一个良性循环。
多数开源软件企业倾向于率先采用嵌入广告的商业模式来获得收入、维持经营。例如，Android 平台为Google带来了大量的移动广告流量。
随着开源软件的发展，企业由以往采用单一开源软件商业模式的策略向采用多种组合的策略转变，例如Red Hat 公司不仅提供订阅专业服务，还进行配套专有软件的销售。
此外，结构化分析结果表明，开源软件的不同商业模式所用许可证类别具有很大的差别。
开源许可证管理公司黑鸭子软件数据显示，从2009 年到2015 年期间，MIT 许可证的份额上升了15.7%，Apache 的份额上升了12.4%，而GPLv2 和v3的份额下降了21.4%。GitHub 调查数据显示，MIT以45% 的占有率成为最流行的许可证；与之相比，GPLv2 只有13%。大多数开源软件商业模式都要求宽松许可证，发展趋势显示，大量软件从限制性许可证转到宽松许可证，与之相关的商业模式也越来越倾向于使用宽松许可证。
本文主要转载了来自lola_chen在oschina上的文章，感谢原作者。
全球 22 种开源商业收入模式
作者：郭炜（郭大侠）
近些年来开源在全球成为越来越火爆的话题，越来越多的开源项目获得了大量的投资或者最终上市。开源是根据一些开源协议把代码公开在互联网上并拥有开源社区和使用者的一种开发模式，那么开源项目代码是开放的，又是如何能够形成商业闭环形成商业收入的呢？
笔者参考了全球多个论文网站和公司材料，最终于2022年9月总结了全球大部分开源项目形成收入的商业模式，一共 22 种，如果是开源爱好者或者有自己的开源项目，可以从这些开源商业公司的商业模式中找到一些启发。
核心开源，非核心闭源
首先最常见的就是软件核心代码部分开源，非核心部分闭源从而通过各种形式收费的商业模式，细分下来这种收入模式一共有 4 个子类别：
第 1 类收费模式是开源商业 SaaS 模式，也就是核心代码开源，但是商业的 SaaS 云服务背后的代码闭源，且其中部分功能是开源版所没有的。比较典型的就是我们耳熟能详的 Databricks，它开源的 Apache Spark 是以 Apache 协议开源的，但是 Databricks 的云服务是闭源的，且其中的性能和功能要远超过其开源的 Spark 版本。
第 2 类就是 open-core 商业软件模式，也就是核心代码开源，但是部分功能代码是闭源，最终形成了闭源的代码软件进行售卖。比如大家最熟悉的支持开源 Apache Hadoop 的 Cloudera 公司所售卖 Cloudera Data Platform 就是这种软件模式的代表。当然随着云化的发展，这些以软件为初始售卖的商业公司，现在也都提供了自己云版本。但依然有很多常见开源软件是利用这种模式去售卖的。
第 3 类是 Plug-in 收费模式，软件本身都是开源的，但是它上面的插件是收费的，这些插件可以帮助这个软件更快地在行业当中提高它的使用效率或者完成特定的目标功能，部分 CAD 开源软件公司使用这种商业模式。
第 4 类是素材收费模式，也就是软件本身是开源的，但是它在运行或者使用时需要相关的素材，而这些素材是需要购买的。这种商业模式在游戏引擎方面比较常见，因为引擎本身只是一个计算核心，而周边的材质配齐了才能够快速开发相关的游戏，这个商业模式例子是 Arx Fatalis，Catacomb 3-D 等这样的引擎。
上面介绍的 4 类其实都是核心代码开源，但是周边有部分的能力是要收费的模式。
托管和整合
第 5 种就是我们常见的云托管模式，它的代码几乎和开源项目完全一样，只在云账号和相关的服务上面有略有不同，用户无需自己再去安装开源软件，也不用雇相关人员进行维护开源软件，直接使用相关的服务即可，比较典型的就是 MongoDB、Elastic 公司提供的托管服务。
第 6 种是硬件和开源软件整合到一起的一体机模式，例如，当年的 Sun 公司将开源的 Solaris 捆绑在自己的服务器上面进行售卖，最终的用户不需要自己再安装软件调试或者适配也可以直接使用硬件提供商提供的相关开源软件。
上面两种核心的商业模式其实都是帮助企业节约安装调试和部分运维成本而出现的商业模式。
软件市场模式
这种一种更为宏大的生态型商业模式。
第 7 种是软件市场（marketplace），这种商业模式一般出现在操作系统或者用户量极大的基础软件。例如 Android，Mozilla 的 Firefox，他们有庞大的用户使用基础。同时很多人会基于这个软件环境开发自由软件或插件，当用户购买他上面的这些软件时，公司通过收取中间的抽成来实现收入。
专业服务
第 8 种是提供普通运维和问答服务来进行（Professional Service），例如 Hortonworks（被 Cloudera 收购之前）的 HDP 和 Redhat 都是这种模式。它的软件代码是和开源同一套代码，企业需要支付支持和咨询费用来确保这些软件正常使用。
第 9 种是软件本身开源，通过升级服务收费来进行收入的。这种一般软件本身非常容易使用，但是它自身的数据却非常重要，每次升级的过程当中，用户为了保证企业数据完整性以及升级之后的软件稳定性，会购买专业开源原厂公司的升级服务。
售卖代码
第 10 种是售卖软开源软件的二次分发授权进行收入，例如大家熟悉的 macOS 基于 BSD Unix operating system kernel 专属权进行开发的，那么 BSD Linux 靠此授权来获得收入。
第 11 种是售卖同样开源代码软件且提供相关服务来进行收入。例如 ardour 和 radium，他们是售卖一模一样的开源软件的二进制代码以及相关的服务来进行收入，一般这种模式小型软件居多。
延迟开源
靠商业软件获得收入之后再进行开源的模式。这样的方式可以保证最新版本的商业收入，同时能保证开源社区的活力。
第 12 种开源商业模式就是延迟开源模式，也就是新版闭源，旧版本开源的模式，比较典型的就是 MariaDB Corporation。它的新版本都是商业版，但当他研发出更新的商业版本之后，他原来的商业版就会被开源出来让大家使用。
第 13 种叫退市开源，这种模式是商业软件已经基本上完成了它的商业生命周期，在退市的时候，它会被开源出来。很多游戏软件其实都是这种模式，所以我们能看到很多的 MOD 游戏模式都是基于这样的退市的游戏软件开发出来的，比较典型的就是 id Software and 3D Realms 公司相关的游戏软件。
围绕开源周边服务
第 14 种开源商业模式是卖认证。软件本身是开源的，但是它所提供的基于该软件的相关内容或相关服务要收费，因为它是软件和模式的发起者。所以，它可以通过认证的模式来进行收入。经过他认证的体系会更加权威，用户可以更加放心地购买，比如早期的 Unix v3 v8 的认证，和现在的 Moodle 模式。
第 15 种开源商业模式是卖培训和周边的参考资料，开源软件本身不一定是由公司建立的，但是他可以卖相关培训和出版相关资料进行收入，例如 O'Reilly 出版公司就是以售卖开源书籍著名的。
利用开源社区的用户流量
第 16 种是经营开源社区合作来进行收入。例如比较著名的谷歌的开源之夏（GSoC），它的收入模式就是帮助各种社区组织开发者经营活动来实现部门收入。
第 17 种是售卖开源软件上的流量赚取费用。软件本身是开源的，用户流量多了，软件利用其中的流量进行收入。在谷歌 chrome 插件里面最流行的 AdBlock Plus 就是如此，每年谷歌都会要付大量的费用来让他不 block 来自谷歌的广告。AdBlock Plus 靠此来进行收入。
有偿开源
下面两种都是参与开源项目的公司或个人进行收入的方法。
第 18 种叫悬赏开源，也就是在开源社区里面悬赏相关任务，最终开发者完成相关任务。获得相关奖励，最终实现个人和公司的收入。比如 Mozilla 曾经悬赏志愿者或公司去解决它的安全隐患然后付出相关费用。
第 19 种叫做众筹。也就是一个开源项目，会对他的用户进行预售，筹划到一定的金额后，再雇佣开源开发者完成这个项目，并且以开源的形式开放出来，例如 OpenGL 4.3 extension for the Mesa librar 就是这种模式开发出来的开源项目。
捐献
下面的两种开源都是比较佛系的。不靠软件本身赚钱，而是靠周边和捐献来获得收入维持。
第 20 种是接纳捐献来获得收入。例如 Mozilla Foundation，每年都会受到 Google 大量的捐赠来维持整个 Mozilla 基金会的运作。类似还有中国的华人开发者尤雨溪做的 VUE 也接受了各种公司大量的捐助。
第 21 种是售卖品牌周边进行收入，例如 Mozilla Foundation 和 Wikimedia Foundation 都有相关的情怀 T 恤或者马克杯。最近的 Apache Con Aisa 个人票当中的飞盘、贴纸、杯子、帽子，其实都是周边售卖获得收入的。
Web3 to Developer
第 22 种，也是最后一种，是我非常看好但还是在发展过程当中的开源收入模式，这就是 Web3 to Developer。开源社区本身就是一个 DAO，只不过目前的开源还很难通过衡量个人的贡献来获得收入。开源软件也很难变成一个像 NFT 一样的组织来获得收入和获利。但是我觉得随着 DAO 理论的发展和相关技术的进步一定会解决相关的问题，从而真正实现每一个开源贡献者劳有所得，每一个开源公司贡献有所收获，每一个投资者投资都有回报，这才是开源社区的最终解决方案。
综上，花了挺长时间整理了各种各样的开源到商业的玩法，我也在 Gitee 上建立了一个开源商业的项目，并把这篇文章和表格进行了开源，欢迎在里面去评论或者 PR 或者提 issue 来贡献，共同把开源社区的商业化做到极致，感谢各位。
OSI 报告：从历史角度看延迟开源发布(DOSP)
Open Source Initiative (OSI) 于2024年1月发布了一份名为《Delayed Open Source Publication: A Survey of Historical and Current Practices》的新报告，深入研究了 DOSP 的历史、模式以及发展趋势。DOSP是是首先在专有许可证下分发或公开部署软件，然后以开源许可证有计划地发布该软件源代码的做法；Business Source License (BSL) 就是一种广为人知的 DOSP 许可。
在整个开源软件历史中，软件生产商都一直在实践 DOSP；报告收集了一些示例，并对其进行分类以进行分析。最早的 DOSP 实例之一是 1998 年左右根据 "Aladdin Free Public License" 发布的 Aladdin GhostScript，后来过渡到同时采用专有许可和 GPL 的发布模型。KDE 的 Qt 库也是一个鲜明的示例，它将 DOSP 作为防止潜在开发中止的一种保障措施。Qt 的许可历史很复杂，如今其可以在商业和开源 GPL 2.0、GPL 3.0 和 LGPL 3.0 许可下使用。
研究人员发现 DOSP 大致有 3 种类型：
1.Unconditional scheduled relicensing。这种直接的方法涉及在过渡到开源许可之前预先定义的时间延迟。
2.Event-driven relicensing。在这种情况下，开源发布与特定事件相关联，比如发布新的专有版本，促使其前身开源。虽然这种方式曾经很常见，但现在已经很少使用了。
3.Conditional relicensing。这种类型取决于某些条件，例如在转向开源之前获得资金或找到合适的非营利组织。但这个承诺可能会存在不会兑现的风险。
与 DOSP 相关的一个变种是 "visible source" 或 "source available"。在这些模型中，源代码通常是可用的，但没有 Open Source Definition (OSD) 所保证的自由。近期比较著名的例子就是 Meta 的 AI 大语言模型 Llama 2 Community License，其代码是可用的，但商业使用受到限制。
OSI 研究人员发现，在 DOSP 早期，DOSP通常是为了垄断直接的商业收入：许可证将授予开源所需的大部分权限，但关键是不允许商业使用软件。这一限制适用于包括用户在内的所有下游被许可方，而不仅仅是开发者。然而最近一些 DOSP 许可证是为了防止任何被许可人在与某些特定类型的软件竞争的产品或服务中使用该软件，而这些软件对许可人来说具有重要的战略意义，与直接收入无关。
例如为 MariaDB 编写的 BSL 1.1 不允许在生产中使用许可代码，除非许可人使用 "Additional Use Grant (AUG)" 机制。但 AUG 因公司而异，也正因如此，每个 BSL 实例实际上都是一个本质上不同的许可证。
现如今 BSL 正在兴起。HashiCorp 在2022年宣布变更核心产品的开源协议，从 MPL 2.0 迁移到 BSL 1.1，CouchBase、DragonflyDB 和 ArangoDB 等十来个项目都也使用了 BSL 协议。
除了 DOSP 许可证，MongoDB 和 Redis 等几个面向云的软件项目在过去几年中也放弃了开源许可证，转而采用带有非竞争条款的许可证 (如 SSPL)。
研究认为，DOSP是企业用来保持商业优势，同时试图尽可能多地保留开源的优势的一种方式。但随着延迟的增加，开源的好处也会越来越少。探索这些好处与独占利用期限之间的权衡是未来值得研究的方向。此外，DOSP 的实验和多样性也都比我们所意识到的要多得多 -- 尝试 DOSP 的项目、以及尝试的方式都要远远多出想象。
报告还提出了一些未来值得继续研究的方向，包括：AGPL 与 DOSP 许可对比、对外部贡献的影响、首次发布开源代码后的重新授权等等。更多详情可查看完整报告。
OSI 发布报告研究 BSL 这样的 “延迟开源发布”
Open Source Initiative（OSI）2024年2月发布了一个报告《Delayed Open Source Publication: A Survey of Historical and Current Practices》（延迟开源发布：历史与当前实践调研），作者是 Seth Schoen、James Vasile 和 Karl Fogel。
Delayed Open Source Publication，简称 DOSP，延迟开源发布的意思，这份报告研究了它的历史和现状。报告核心要点：
延迟开源发布（DOSP）定义：DOSP 是指软件最初在专有许可下发布，然后计划性地在某个时间点将源代码以开源许可的形式公开。
历史背景：DOSP 的做法可以追溯到 GNU 项目，并且一直延续至今。公司尝试各种商业模式，以在有限时间内保持独家权利，然后过渡到 OSI（开放源代码倡议）批准的许可。
策略类型：DOSP 分为三种类型：无条件计划性重新许可、事件驱动的重新许可和有条件的重新许可。
商业源许可（BUSL）：BUSL 是一种新兴的 DOSP 许可方式，它要求在特定的 “变更日期” 后，软件的许可将变为开源许可。这种做法在数据库系统中尤为常见。BUSL 的采用正在迅速增长，尤其是在云和软件即服务（SaaS）领域。（以往也叫 BSL）
以下是当前知名的 16 个使用 BUSL 的项目，都是延迟几年后转型成开源协议：
反竞争条款：一些 DOSP 许可中包含反竞争条款，旨在防止许可证持有者使用软件提供与许可方直接竞争的服务。
后果和影响：从开源许可转变为 DOSP 许可的项目可能会受到批评，有时会导致用户转向其他项目或维护竞争性的分支。
未来研究问题：报告提出了一些未来研究的问题，包括 AGPL 与 DOSP 许可的比较、DOSP 对外部贡献的影响、BUSL 额外使用授权的分类、以及在初始开源发布后重新许可的策略。
结论：DOSP 自开源运动早期以来一直在使用，公司通常利用它来保持商业优势，同时尽可能保留开源的优势。报告强调，DOSP 的实验性和多样性比预期的要多，且这种趋势可能会继续。
详情可以查看报告原文。