企业如何选择合适的开源软件
2010-05-08 09:44:17 
阿炯
开源软件的普及正在给那些意欲选用的企业带来难题，过去在选择非开源软件时，总是有不同的IT供应商对客户进行轮番“骚扰”，并历数各自产品的优点，但开源领域由于还没有形成那么大的市场规模，再加上开源软件繁多，企业自身选择什么样的开源软件，渐成问题。
开源的越来越主流化，企业需要确保自己所使用开源软件产品的可信赖性，于是，开源许可证变得越来越重要，但它实现起来并不容易，据报道，如今业内有超过 33万个开源软件供各种类型的企业使用。如此繁多的开源软件，不仅要保证其开源许可证，还要保证其高可靠性，这对于使用者来说，无疑是个难题。要选择正确的开源软件，最基本的判定方式就是通过开源许可证，目前也有相应的权威部门和机构来进行开源软件的认证，这样的部门有一套切实可行的认证管理以及说明文件。
除此之外，还有一些其他条件可以缩小选择开源软件的范围。例如：新的开源软件项目评估方法：SOS开源系统，这是源于开源策略专家Roberto Galoppini的自动化方法论。该工具使企业可以确定任何既定开源软件的风险水平。SOS开源系统使用24度量方法，并从开源项目目录中收集信息。Galoppini还说，SOS 开源系统敏锐地集中在项目实力上，在项目稳定性和成熟性方面进行监测，并能够确定该项目是否具有一个可预测的切实可行的社区支持。
但是如果开发者已经在没有经过允许的情况下使用了开源资源该怎么办？当然，还是有应用程序解决这个问题的。如Black Duck软件，OpenLogic和Protecode为用户提供的服务可以跟踪开源软件的使用情况。事实上，这些供应商甚至可以通过内部编码应用程序的方法来保证开源资料或者代码碎片不违法他们设计的许可。
对于那些还没有设置开源使用政策的公司，再也没有比现在更好的时机了。通过这些判定手段，企业可以更方便地选择到适合自己应用的开源软件。有鉴于此，这里从开发者、商业公司、开源社区等多个方面来讲解他们之间的复杂关系。
开源，理想自由还是作茧自缚？
当我们谈论开源时，很少谈论自由，尽管开源与自由同行。从 1998 年开源一词兴起时，我们就无法把开源和自由分割开来。因为它孕育于自由软件运动，自由使用、复制、修改、分发源码，其精神内核一直延续至今。“自由”，为何对开源如此重要？我们将依次用《开源，是背叛自由还是以退为进？》、《开放协作：赋予开发者的自由》、《商业自由：从边缘到核心贡献》三篇文章来回答这个问题。
作者：肖滢，以下三篇文章转自她的oschina的博客，感谢作者。
开源，是背叛自由还是以退为进？
为软件用户的自由而战
事后二十多年，Richard Matthew Stallman(RMS)对施乐公司拒绝提供打印机源码的愤怒仍然挥之不去，以至于他在开展自由软件运动演说时频频提及。
20 世纪八十年代初，麻省理工学院 AI 实验室获赠了一台新的激光打印机，机器能以更高的精度打印图形，并减少了 90% 的打印时间，但经常会出现卡纸的情况，这很常见。如果在以前，RMS只要简单地修改一下源码，就可以通知人来解决这个问题，然而这一次，赠送打印机的施乐公司没有像以前一样提供人类可读的源码，这意味着他无法自己修改。而后向开发人员索求源码也遭到拒绝，对方称签署了保密协议。
打印机事件让 RMS 切身感受到，商业公司为了利益，限制他人使用源码或者停止提供源码剥夺了自己的自由。那段时期，实验室计算机的密码保护、黑客成员的流失、商业公司对源码的保密，让他不止一次意识到，其引以为傲的黑客文化——自由共享源码、创新、合作，由于商业行为的冲击正在消亡。
而随着微处理器的出现，计算机进一步小型化，个人计算机时代到来，成千上万带有使用许可证和保密协议的专有软件扑向了用户。这些用户并不是开发者，他们只关心新软件、新功能，并不关心是否有源码。
但对于 RMS 来说，则陷入了两难的境地：要么默许使用专有软件，但他曾多次旗帜鲜明地反对专有软件捍卫软件自由；要么创造一套自由的软件系统，但这是一项浩大的工程。
在此之前，为了反击 Symbolics 公司不再给提供更新后的源码，他曾有几个月的时间，在实验室单枪匹马写代码，以改进 Lisp 机器 ，实现了 Symbolics 一个团队才能完成的各种新功能和 Bug 修正。这让他对走第二条路充满了信心。他决定避免使用专有软件，并且创造一套完全自由的操作系统及其外围软件，来帮助其他用户获得完全控制软件的自由。
首先是要开发一套自由的操作系统。因为每一台计算机都需要一个操作系统，然而在20世纪八十年代，几乎所有的软件都是专有软件，操作系统也一样。
于是在 1983 年 9 月，RMS 公开发布了 GNU 项目的初始声明。声明提到，要编写一个完全和 Unix 兼容的软件系统 GNU。为什么要与 Unix 兼容？因为 Unix 的整体设计历经考验并且可移植，而且兼容性会让 Unix 用户很容易从 Unix 系统转移到 GNU 系统。
RMS 提出了明确的构想：GNU 会有一个内核，以及一系列编写和运行 C 程序所需要的应用：编辑器、shell、C 编译器、连接器、汇编器以及一些其他程序。此后，还会加入文本排版工具、Yacc、 Empire 游戏、电子表格和数百个其他应用。
GNU 项目初始声明的发布，标志着自由软件运动拉开了序幕。
开始的过程并不那么顺利，他想把 VUCK 编译器纳入 GNU，却被告知不允许；想用 Gosling 的代码编写解释器避免重复造轮子却被告知有版权保护，这让 RMS 更加坚定了自由软件运动的政治目标。
1985 年 ，RMS 终于发布了 GNU 项目的第一款软件——GNU Emacs 编辑器，同时还发布了“GNU 宣言”。宣言是对 1983 年 9 月发布的初始声明的扩展。为了更好地推动 GNU 计划，RMS等人成立了自由软件基金会(FSF)，还设计了 GNU 通用公共许可证(GNU GPL)，并以该许可证发行大部分软件。
GPL 是最能体现 RMS 自由思想的证据之一，因为它是 Copyleft 许可，在最大程度上保护了所有用户的自由。Copyleft 一词虽然不是 RMS 创造，但是他赋予其更加丰富、确切的含义。Copyleft 是一种方法，确保用户拥有使用、研究、复制、分发、修改及再分发作品的自由。还有一些许可同样授予这些自由，不同的是，Copyleft 还确保 Copyleft 许可作品的任何修改版本，也必须授予这些自由。要指出的是，Copyleft 是一种抽象的概念，抽象的概念无法直接使用，因此，Copyleft 以许可证形式存在。
站在后续或衍生版本的软件发布者角度来看，Copyleft 是一种限制；站在原始软件及后续或衍生版本的所有用户来看，Copyleft 是慷慨地给予。
当时，大部分的自由软件许可向直接的下游开发者提供了最大的自由，包括将代码用于闭源项目。然而，代码用于闭源项目之后，等同于断送了用户学习、分发、修改和再分发该软件的自由。而 Copyleft 许可 ，则保证了这些“自由”不被中断，可以随着后续或衍生版本延续下去。
商业软件开发人员通过 Copyright(版权)剥夺了用户的自由，而 RMS 通过 Copyleft 来给予用户自由，而且是最大程度上的自由。
开源是对自由软件的背叛吗？
在1991 年，GNU 操作系统大部分组件都已经选择好或开发完成，包括强大的 GNU 编译器套件 GCC，但独独缺了一个重要的内核。因为原定的 GUN Hurd 内核开发进展缓慢，迟迟未能发布。 直到 1992 年 2 月，事情迎来了转机，Linus Torvalds 发布了 Linux 内核 0.12 版，也是从这个版本开始，Linux 内核采用了GNU GPL 许可证，成为了自由软件。 几乎完成的 GNU 系统和 Linux 内核的结合，诞生了第一款完全自由的操作系统 GNU / Linux ，现在，我们称之为 Linux 系统。
在此之前，尚不存在完全自由的操作系统，而 Linux 内核补上了最后一块拼图。
Hurd 的难产以及 Linux 的成功，让前 GNU 成员 Eric Steven Raymond(ESR) 开始思考软件项目管理问题。而思考的成果，掀起了一场轰轰烈烈的开源软件运动。
RMS 不会想到，1998 年 4 月他未被邀请的那场小型的“自由软件峰会”，让 ESR 等人达成了用“开源”一词取代自由软件的共识。参会的关键人物还包括 Linux 内核创始人 Linus Torvalds、Apache 主要开发者 Brian Behlendorf、 Sendmail 创始人 Eric Allman、Perl 语言创始人 Larry Wall、Python 语言创始人 Guido Rossum 等人。之后，自由软件阵营中的部分成员分裂出来，以“开源”的名义开展活动。几个月后，它通过报纸、杂志等媒体流行开来，并得到了企业及开发人员的广泛支持。
一开始，RMS 并没有持反对意见，但很快他就发现，开源这个词所代表的主张已经开始异化，使得其背后的逻辑与自由软件运动的初衷相去甚远，因此他坚定地撇清自由软件与开源软件的关系。RMS 认为：“自由软件运动为用户的计算自由而战斗；这是一个为自由和公正而战的运动。相反，开源理念重视的是实用优势而不是原则利害。我们因此不赞同开源运动，也不使用开源这个词。”尽管他自己也承认，“自由软件”和“开源”基本上指的是同一范围的程序。
他曾解释过开源异化的原因：“一旦支持者开始为开源营销的时候，自由软件运动所珍视的那些价值观就被抛诸脑后。于是，‘开源’一词很快就单纯地和各种实用主义的价值观联系起来。比如说怎么能创造一个强大、稳定的软件。很多开源支持者从一开始就把这些价值观推崇至极，也难怪局外人会有如此联系了。大多数‘开源’的讨论都绝口不谈是非对错，而只是讨论流行与成功。”
但这并不能说是 ESR 等人对自由软件运动的背叛，恰恰相反，他们的本意是要让“自由软件”获得主流企业的支持，从而实现更广泛地传播。
我们可以从 ESR 于 1998 年 2 月发表的《再见，自由软件；你好，开源软件》一文轻易得出结论。他认为，“free software”一词的问题是双重的。因为 “free” 一词的意思令人困惑，因为它既有免费的意思，也有自由的意思。“free”是意味着“不收费”，还是指“任何人都可以自由修改”，还是其他什么意思？其次，“free”一词的免费含义，让很多企业感到紧张，应该用一个新的定义来争取他们的认可。这也是 ESR 首次公开呼吁使用“开源”一词。
ESR 为何会说企业对“free software”感到紧张？因为在几天前，他试图通过网景公司受自由软件文化影响从而公开源码的案例来说服企业效仿，却遇到了阻碍。多数企业高管在第一次听到“free software”时，将其解释为“零成本”的同义词，明显与追求利益背道而驰。尽管一直以来，RMS和其他黑客尽了最大努力宣传，自由软件中的“free”一词代表自由而不是价格。
开源促进会(OSI)由 ESR 等人成立，是开源运动的主要支持者和倡导者之一，它曾公开发表观点称，“free software”一词已被商业人士误解，他们将分享的意愿误认为是反商业主义，或者更糟，是盗窃。主流企业 CEO 和 CTO 永远不会购买“免费软件”。但是，如果把同样的传统，同样的人，同样的自由软件许可证和标签更改为“开源”，他们会买。
比起 RMS 热衷于自由软件所表达的政治主张，ESR 等人更看重自由软件的开放、协作的开发模式。Linux 内核的开发就是基于这一模式。
在 Linux 之前，复杂的软件是由小团体精心设计的，源代码在软件发行后公开，但在软件的每个版本开发过程中都由一个专属的团队所控管，比如 GNU Emacs 及 GCC 就是在这种模式下开发的，ESR 将其称之为大教堂模式。但 Linux 以完全不同的方式发展。几乎从一开始，源码就被公开，它被大量志愿者查看并参与开发，仅通过互联网进行协调。质量不是通过严格的标准或独裁来保持的，而是通过每周发布并在几天内从数百名用户那里获得反馈这样简单的策略来保持，这被成为集市模式。除了 Linux 项目之外，ESR 自己的项目 Fetchmail 也沿用这一模式开发并且获得了成功。
这两种模式最后被 ESR 整理成论文《大教堂与集市》，于 1997 年对外发表。网景公司也正是受到这篇文章的启发，公开网页浏览器的源代码，并启动 Mozilla 项目。
从这一层面来说，ESR 等开源倡导者的确是有意避开政治运动。但不可否认的是，撇开政治隐喻不谈，开源软件运动在捍卫软件用户自由上，实际上与自由软件运动是大体一致的。事实上，由 OSI 发布的“开源软件”的官方定义，间接源自自由软件的标准。虽然这些运动有不同的价值观和目标，但并不妨碍开源社区和自由软件社区的人们在实际项目中进行合作。
可以这么认为，开源软件运动是向商业公司妥协后的自由软件运动，听起来是有些软弱，但确实起到了实质性的作用，“开源”一词的出现，极大地推动了开源历史进程。没有了对“free”一词的误解，也没有了剑拔弩张的政治运动，许多大型机构和企业如雨后春笋般涌现，以支持开源软件运动的发展。Apache 软件基金会(ASF)就是其中之一，此后贡献了Apache Hadoop 等多个顶级开源项目。1998 年，四款自由软件 Linux、Apache、MySQL 和 PHP 组成的“LAMP 包”成为替代商业包的典型代表被展示在杂志上，在很长一段时间内，它都是交付 Web 应用程序的最常见方式之一。
发展到今天，开源软件已经极其普遍，几乎存在于全球 2000 强企业的所有关键任务软件组合中。以至于当 Marc Andreessen 发出“软件吞噬世界”的感叹时，有人补上了后一句，“开源吞噬软件”。
这么说的话，开源并不是背叛自由，而是以退为进，将自由软件运动的精神内涵承袭下来，以更加柔和、包容的方式对外宣传开去。
开放协作：赋予开发者的自由
自由共享的精神与开放协作的开发模式，像两条绳子拧成了一股，成为开源项目生存和发展的核心支柱，一直延续至今。开放协作，赋予了开发者参与开源项目最大程度上的自由。这种自由，在Linux 内核的开发上首次攀上了高峰。
一群极客的狂欢
Linux 内核第一次大规模吸引用户，是在 1992 年 1 月 0.12 版发布之后。尽管当时功能有限，但作为一款类 Unix 的操作系统内核，本身就已经具有相当大的优势，尤其是在 Unix 作为一款专有软件对外售价不菲时。特别之处在于，设计者 Linus 开放了一个专门提交代码的站点。这意味着，除了核心小组的六个成员之外，开发者可以直接参与 Linux 内核的开发，自由地提交代码，以解决一些问题，或者实现一些功能。
Linus 经常把 Linux 内核的更新情况发布在 Minix 新闻组，这里聚集了一批 Minix 操作系统的铁杆粉丝。对一群热衷于技术的开发者来说 ，一个新的操作系统，确实存在致命的吸引力。 Linux 的用户数量迅速增加。
1992 年，使用 Linux 操作系统的用户已经近千人，其中大部分是热衷于技术的黑客高手。到了 1993 年，通过互联网参与内核修改和编写的开发者已经有近百个。1994年，伴随着 Linux 1.0 的正式发布，内核的开发也进入了良性循环。1995 年 3 月 1.2 版发布时，Linux 内核已经有了25万行代码。新杂志 《 Linux Journal 》的发行量达到了一万本。Linux 系统也能同时适用于英特尔处理器、DEC 的处理器以及 Sun 公司的SPARC处理器了。Linux 跨出了一大步。
几年以后， Linux 社区的开发者已经成千上万，他们依靠邮件列表以及彼此之间制定的规范进行联系和开发，自由提出功能需求，自由维护和升级。“一切工作都按部就班地进行，不用投票表决，不用组织拉票，更不用重新计票，反正大家都知道谁是活跃分子，谁是他们信得过的人 ”。在 Just for Fun:the Story of an Accidental Revolutionary 一书中，Linus 描述了这种协作方式。
在此之前，没有多少项目会把开发过程完全对外开放，让用户参与进来。比如在 GNU 工程的各项目开发中，贡献代码的往往只有少部分人，只有当新版本完善后才会对外公布源码，版本发布间隔的时间可能要几个月。对于社区的众多开发者来说，他们能做的仅仅是测试软件，提出问题或者功能需求，尽管这也很重要，不过参与程度极其有限。
在软件项目管理方面，当时流行的理论是布鲁克斯定律，即向项目添加开发人员只会导致进一步的项目延迟。该定律由 IBM System/360 系统之父 Fred Brooks 在 The Mythical Man-Month: Essays on Software Engineering 中首次阐明。布鲁克斯定律预测，一个拥有数千名贡献者的项目应该是一片片状、不稳定的烂摊子。
Linux 社区无疑是打破了这一理论。随着越多的开发者加入，Linux 逐渐成为一款高质量的操作系统内核。1996年，Linux 内核的全球用户量已经迅速增长到350万。在 Linus 看来，这一切都要归功于他的两个缺点：一是懒，二是因为喜欢占别人劳动成果的便宜。因为懒和喜欢占便宜，所以他把一些功能交给其他人开发，坐享其成。除了最终决定权属于 Linus 之外，其他开发者都是平等的，都可以增加系统功能。这也是“Linux 开发模式”的特别之处，没有局限于六个核心成员之间，而是邀请所有用户参与，集思广益。 《大教堂与集市》的作者 ESR 如此评价：Linux 是第一个有意识地成功利用整个世界作为其人才库的项目。
早期，软件用户多为具备编程能力的开发人员，因此，当 “自由软件之父”RMS 提出保护软件用户运行、复制、分发、学习、修改及再分发源码的自由时，实际上就是指开发者的自由。毕竟，普通用户可不关心软件供应商有没有提供源码。而 Linus 则用开放、协作的方式，进一步把开发者的自由扩大化、具体化了。对开发者这一角色而言，最好的自由不就是开发的自由吗？
这种自由，让每个贡献代码的开发者都成为项目的创造者，而不再是旁观者、局外人。本来是Linus 一个人的狂欢，最后变成了一群极客的狂欢。自由带来的热忱，推动了Linux 内核的成功。在众多开发者的协同开发下，截至 2021 年，Linux 内核 5.11 版本的代码量达到了 3034 万行。
ESR 正是从 Linux 内核的成功中受到启发，最后写下了著名的《大教堂与集市》一文，引起了众多软件企业的关注，从而掀起了轰轰烈烈的开源软件运动。Linux 成功的关键——开放协作的开发模式，就这样成为了开源协作模式的典型代表。
不自由的代价
Linux 内核不是第一个利用该模式进行开发的项目，但从项目热度、开放程度、协作深度，以及波及广度来看，产生的影响却是最大的。在20世纪90年代后期，越来越多的开源项目转而采用这一模式，星星之火已成燎原之势。
1997年，一群开发者因不满 GCC (GNU 编译器系统)缓慢且封闭的创作环境，组织了一个名为EGCS(Experimental/Enhanced GNU Compiler System)的项目。GCC 和 EGCS 是两个并行产品——两者都来自相同的互联网开发人员群体，都来自相同的 GCC 源代码库，都使用几乎相同的 Unix 工具集和开发环境。这些项目的不同之处仅在于 ，EGCS 有意识地尝试采用开放协作的开发策略，而 GCC 保留了一个原先的组织模式，开发组较为封闭，发布次数不频繁。
几个月之后，EGCS 版本在功能上大大领先，不仅能更好地支持 FORTRAN 和 C++，而且比 GCC 最新的稳定版本更可靠，主要的 Linux 发行版也都开始转向 EGCS。1999 年 4 月，自由软件基金会( FSF )解散了原来的 GCC 开发小组，正式将项目控制权交给了 EGCS 指导小组。
如果说 GCC 的教训还不够深刻，那 Mozilla 开源的历程或许能更好地归因开源的成与败。
网景公司是第一个将商业产品开源的企业。1998 年 1 月，网景公司宣布将浏览器套件开源，代号叫 Mozilla，并建立了专门负责该项目的组织，希望借助全球开发者的力量挽狂澜于既倒。彼时，它正与微软在浏览器市场激战正酣。微软攻势猛烈，将 IE 浏览器与 Windows 捆绑销售，并且免费提供，这使得曾经风靡全球的网景浏览器(Netscape Navigator)节节败退，尽管其市场占有率一度高达 90%。最后仍由 IE 浏览器占据了半壁江山。
然而事实再一次证明，不够开放、自由的开源项目，无法调动开发者的兴趣，无法吸引开发者广泛参与。一个开源项目没有了用户，就如同没有了生命，即便能够风靡一时，也终究会被时代抛弃。
网景公司公开的源代码是老旧的开发版本，存在诸多问题；Mozilla 使用了NPL许可证，这允许网景公司将后续版本作为专有软件发布，而其他人却不可以；源码还混入了很多非自由软件的代码；Mozilla 不接受公司外部开发者的代码，仅靠公司内部人员维护。其中种种，让网景公司负面缠身。这种遮遮掩掩、重内排外的开源方式，完全背离了自由共享、开放协作的开源精神。在 Linus 看来，网景公司不过是提供了一大堆源代码而已。
彼时，ESR 等开源倡导者都看到了这些问题，但没人敢提出批评的声音，怕给刚诞生的开源“抹黑”，只能焦灼地看着网景浏览器的市场份额不断输给 IE。
网景公司也意识到，这样的“开源”无济于事，在10 月重做了 Mozilla 项目，实现了真正意义上的开源。这取得了一些令人激动的效果。11 月，网景浏览器就扭转了市场份额下滑的局面，并开始在与 IE 的竞争中获利。然而已经太迟了。这对于当时的网景公司来说，无异于杯水车薪，终究未能挽救颓势。1999年，网景公司被美国在线公司收购。
庆幸的是，开源使 Mozilla 得以保留了火种。经过几年的发展，诞生了基于 Mozilla 源码的火狐浏览器(Firefox)。在 Mozilla 基金会官网上，是这样介绍 Mozilla 项目的：“它旨在利用互联网上成千上万程序员的创造力，推动浏览器市场实现前所未有的创新水平。”今天， Mozilla 确实做到了。它已经是一个成功且瞩目的开源项目，旗下的开源软件 Firefox 每月都会按计划发布一个新版本，在浏览器市场，它已经占据了稳定的市场份额。
Mozilla 曾经走过弯路，但及时调转了船头。不可否认的是，网景公司开源 Mozilla 是有划时代意义的。继网景之后，Sun、IBM 、Informix、Oracle 等大型企业都相继加入到开源运动中来，从开放接口，一步一步到软件开源。
如今只道是寻常
二十多年来，开放协作的模式在不断演化，更加自由，更加开放，协作人数日益增加，参与范围扩至全球，成为了开源项目最为普遍的开发模式，甚至成为了开源协作模式的代名词。伴随而来的是，更多能够实践这一模式的工具和平台被创造出来，开发者的自由再一次攀上新的高峰。
当前流行的开源分布式版本管理工具 Git， 就是 Linus 为了让更多的人同步开发而设计的。
在 1991 至 2002 年间，绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上，这是参与者迅速蹿升带来的不可避免的问题。 到了 2002 年，整个项目组开始启用 BitKeeper 来管理和维护代码，这是一个专有的分布式版本控制系统。
三年之后，开发 BitKeeper 的商业公司与 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权利。 这就迫使 Linux 开源社区，特别是 Linus，基于使用 BitKeeper 时的经验教训，开发出自己的版本系统。经众多开发者十几年的努力，Git 已经成为开放协作模式的主流配置。
Github、Gitlab都是基于 git 的开源协作平台，它们的出现为开发者参与开源提供了更加高效、便利的方式，不仅能够为他人的项目贡献代码，甚至可以快速建立自己的项目——就算社区不接受提交的代码，也可以一键 fork 自己的分支。
每年，都会有大量开发者通过 Github、Gitlab 等协作平台投身开源之中。《GitHub 2020 数字洞察报告》显示，2020 年，Github 的活跃代码仓为 5421 万个，同比增长 36%；活跃开发者数为 1454 万人，同比增长 22%。正是因为开发者的积极参与，Linux、MySQL、Hadoop、Kubernetes、TensorFlow、React、VS Code 等基础软件迸发出蓬勃生命力。
身处 Github 织造的协作网络之中，自由唾手可得，开放协作的自由理念已经深入人心，不会时常提及，但无一不涉及，一旦遇到威胁，就会引起警觉。2018 年，当微软宣布以 75 亿美元收购 GitHub 时，很多开发者及对 GitHub 未来的独立性表示怀疑，因此把托管在 Github 上的开源项目迁移到Gitlab上。
仅仅在一周之内，Gitlab 的项目迁入量就达到了一万以上。尽管这个数量对 Github 上几千万个活跃代码仓而言，不过是沧海一粟。
但它的意义很是鼓舞人心。是的，即便是一个全球范围内最大的开源协作平台，即便是一直以来给予其极大程度上自由的平台，对部分开发者而言，一旦成了微软——一个靠专有软件发家致富的巨头企业——的一部分，就变得不再可靠。一方面，Github 虽然可以免费托管开源项目，并且为开源事业做出了许多贡献，但 Github 的网站和软件并没有开源，以后若有什么不利于开源的动作也合乎情理；另一方面，微软过去反对开源，影响过于深刻，以致于让人忽略了今天的微软已经是 GitHub 上最大的企业贡献者。
“叛逃”Github，让人意识到，开放协作的自由，是开发者一直以来追寻的旗帜，是开发者从未放弃的权利。
从思想启蒙，到方法实践，再到工具创新，哪一样不是为了开发者的自由而来？自由不是与生俱来的，而是一批又一批开源先驱前赴后继开辟出来的。当专有软件切断了开发者的自由，RMS 站了出来；当布鲁克斯定律框住了开发者的自由，Linus 站了出来。不管是有意还是无意，是主动还是被动，只要有人在追逐自由的光，那就会趟出一条自由的路。
开源与自由 | 商业自由：从边缘到核心贡献
不得不承认的是，个人英雄式的独立开发者时代已经落幕，随之而来的是，互联网科技企业成为开源社区的主要力量。
当企业成为开源的主体，开源一定需要商业自由。那么，开源与商业是怎样的关系？商业自由能为开源带来什么？为了保证商业自由，企业做了什么样的选择？无限制地放开商业自由，对开源会有什么影响？
不是二选一
我们提到过，1998 年 Mozilla 的开源，具有划时代意义。由它开始，掀开了企业大规模开源的序幕。在 20 世纪七八十年代，还没有开源的说法，只有“自由软件”，自由软件主要由个人或者大学等机构主导，GNU 工程就是其中典型的代表。而发布自由软件的企业屈指可数，它们处于自由软件世界的边缘位置。
自由软件在商业企业中并不受欢迎。它赋予用户分发软件源代码的自由，在很大程度上损害了企业的利益。
微软 CEO 比尔·盖茨于1976年发布的一封公开信，可以反映出企业对分享软件这一行为的普遍态度。他在信中抱怨，未经授权使用 Altair BASIC 的情况太普遍，导致新成立的微软公司回报甚微，并指出那些分享拷贝软件的人是剽窃者。“谁能负担得起白做专业工作？哪个业余爱好者可以花 3 年时间进行编程、查找所有错误、记录他的产品并免费分发？事实是，除了我们之外，没有人在业余爱好软件上投入大量资金。你所做的就是盗窃。”
不过，自由软件本身并不抵制商业化。自由软件基金会(FSF)就明确表示，自由软件无关价格。很多人以为，GNU 计划的精神是不应该为分发软件副本收费，或者应该尽可能少收费——刚好足以支付成本。这是一种误解。实际上，他们鼓励重新分发自由软件的人尽可能多地收费，以此来支持开发。“分发自由软件是为开发筹集资金的机会。不要浪费它！”当然，这一切都建立在保证用户有自由运行、学习、修改以及再发行原版或是修订版软件的前提下。
“开源”的出现，更是为商业自由而来。1998 年，正是因为 ESR 等一批自由软件运动的倡导者考虑到“free software”中的“free”有免费的意思，对商业不友好，才出现了用“开源”一词替代“自由软件”，以方便对外宣传，吸引更多的企业加入到自由软件运动中来。随后，开源促进会(OSI)批准了第一批许可证，其中就包括 BSD 许可、MIT 许可两个商业友好型的许可证。OSI 维护着开源定义(OSD)，判定一份许可证是否属于开源许可证，以 OSI 认证为准。
从一开始，开源与商业不是二选一的关系，而是共生的关系。
早在上世纪 90 年代后期，RedHat、MySQL AB 等公司就证明了，利用开源软件来赚钱是可行的。尤其是 RedHat 在1999 年以创纪录的 IPO 公开上市，更是令不少企业艳羡不已。而今开源已经是一种成熟的商业模式，一头扎进去，人才、市场、名声，全都可以握在手里，足够顺利的话，甚至还能建立一个以开源项目为核心的产业生态，坐收渔翁之利。
2007 年，为避免苹果公司的移动操作系统 iOS 垄断市场，谷歌主动开源 Android 操作系统( 该开源项目简称：AOSP)。由此，Android 系统在移动端的市场份额一路飙升，2020 年超过 70%。这也为谷歌移动服务(GMS)带来广阔的市场。要知道，GMS 每年为谷歌带来数百亿美元收入。
用开源的手段扩张市场，在软件行业已经屡见不鲜，除了谷歌这样的科技巨头，不少初创企业也加入进来。MongoDB 公司的 CEO Dev Ittycheria 就明确表示，开源就是为了获得市场。公司成立的第三年，MongoDB 已经初步开发完成，却没有足够的资源面向整个庞大的市场进行营销，因此想利用开源的病毒性传播属性，让软件得到广泛使用。这一策略确实奏效，几年之后，MongoDB 成为了最受欢迎的 NoSQL 数据库之一。
微软收购全球最大的软件开发平台 GitHub 进一步表明，大公司正在寻求成为开源的主要供应商，并准备在其中投入大量资金。
商业反哺开源
企业是商业自由的最大受益者，同时也在反哺开源。它已经从最初的开源软件使用者，转变成集创建者、使用者以及贡献者多重身份于一体的角色。开源已经离不开企业，离不开商业自由。
最直接的证据是，企业贡献了一大批顶级的开源项目，成为开源技术的引领者，尤其是在近几年尤为活跃的人工智能、大数据、云计算等新兴技术领域。微软创建了源码编辑器 VSCode，谷歌创建了机器学习平台 TensorFlow、容器编排平台 Kubernetes，Facebook 创建了移动应用开发框架 React Native。众所周知，这些技术领域的创新都源于开源生态，企业功不可没。
它们同样也为其他开源项目贡献代码。尤其是软件巨头，成为了最大、最活跃的贡献者。根据 Open Source Contributor Index 公布的 2020 全球开源厂商 GitHub 开源贡献排名，谷歌和微软两大互联网巨头排在榜单前二位，二者参与开源贡献的活跃贡献者人数都超过了 5000 人，参与的开源社区超过 10000 个。微软、谷歌、IBM、Oracle、Facebook 五家科技巨头企业参与的开源项目数超过 20000 个。
在一些大型的、复杂的、生命周期长的开源项目上，企业所具有的软件工程调度能力，会比零散的个人开发者更具有优势。红帽博客编辑总监 Joe Brockmeier 认为，理想情况下，企业开源结合了两个世界的优点——开源的优势与企业软件提供的稳定性、性能、支持和生态系统。
也正是因为开源允许商业自由，才有更多商业模式诞生，吸引更多企业加入。从最早期的“RedHat”模式，发展到 SaaS 模式、Open Core 模式、限制性许可模式、混合许可模式等，越来越多的企业在尝试构建新的开源商业模式。在过去的十年中，Open Core 模式成为了最成功和最常用的方法。Elasticsearch 和 MongoDB 就是该模式下商业化的开源项目，二者也都成为了商业开源软件公司(COSS)。对于其他跃跃欲试的企业来说，一套成功的商业模式无疑是具有鼓动性的。
此外，企业结合开源软件实现商业转化，获得收入之后也能够更好地回馈开源社区，让项目可持续。一个现实问题是，很少有人有足够的空闲时间将其用于真正的开源贡献。因此，不少通过开源获益的企业会付钱给开发人员或运营人员，让他们为开源软件做出贡献。
难以想象，在企业取代个人成为开源领域绝对主流的时代，没有了商业自由，开源会变成什么。
许可证的选择
在开源世界，什么会限制企业的商业自由？那自然是规则，也就是开源许可证。选择什么样的许可证，关系到企业的开源商业模式。
开源许可证大体可以分为两大类：一类是 Copyleft 许可，另一类是宽松型许可。宽松型许可证对他人如何使用开源组件的限制最小，几近于无。它们允许用户在不同程度下自由使用、修改和重新分发开源代码，并允许在专有衍生作品中使用宽松型许可的开源组件，几乎不需要任何回报。
简而言之，宽松型意味着不强制开源，条条框框少了，对商业友好，企业利用开源软件发展业务更加便利。
一个越来越明显的趋势是，宽松型开源许可证使用量明显增长，而 Copyleft 许可证，尤其是GPL 许可证的使用量继续减少。根据 WhiteSource 发布的数据显示，2020年，76% 的开源组件拥有宽松型许可，比上一年提高了 9 个百分点。24% 的开源组件是 Copyleft 许可，比上一年减少了 9 个百分点。在 2012 年，Copyleft 许可证还牢牢占据上风，有 59% 的使用率，而宽松型许可证的使用率仅为 41%。
宽松型许可证大行其道，开源项目创建者的意志起了决定性的作用。近年来，互联网科技企业成为了开源项目的主要创建者，而不再是个人。使用 Copyleft 许可证，就意味着失去自己的私有软件的控制权，从商业角度出发，限制较少的宽松型许可证是企业的最佳选项。对用户限制越少，对自己也就越有利，企业本身就是最大的用户。
MIT 许可证及 Apache 2.0 许可证 ，就是典型的宽松型许可证。2020 年，使用 MIT 许可证或 Apache 2.0 许可证的开源项目超过一半，其中不乏一些备受瞩目的开源项目。例如，Ruby on Rails、jQuery 和 Angular.js 使用 MIT 许可证，Kubernetes、TensorFlow 和 Swift 首选 Apache 2.0 许可证。事实上，所有 ASF 项目——其中一些被广泛使用——都在 Apache 2.0 许可下。
用户也选择以宽松型许可证授权的开源组件，这样可以最大限度地减少法律部门对开源许可证合规性的挑战。而针对许可证不符合企业要求的开源项目，已经有不少企业制定了黑名单，禁止开发人员引用相关代码，从而避免风险。比如，Google 就禁用了以 AGPL 授权的软件。AGPL 是 Copyleft 许可，其中一条特别规定是，即使软件被运行在向公众提供服务的服务器上，那么该软件的任何修改也必须开源。
总之，为了保证商业自由，企业做出了使用宽松型许可的选择，无论是作为创建者的角色——将软件开源，还是作为使用者的角色——引入开源软件，更遑论作为贡献者的角色提交代码了。
商业自由的“度”
站在自由软件之父 RMS 的角度，将自由软件代码用于专有软件，就是在剥夺了用户使用、学习、修改软件的自由；站在 OSI 的角度，将开源软件代码用于专有软件是符合开源精神的，这是在保护用户基于任何目的使用软件的自由，哪怕是将代码用于专有软件。OSD 规定，开源许可不得歧视个人或团体，不得歧视任何领域。企业用户也是用户，商业自由也是自由。
当开源许可证成为商业自由的保护伞，一视同仁对待所有用户时，就有人开始不满。尤其是不少开源软件创建者，从选择许可证开始，尽可能地让自己拥有更多权利，尽可能地限制他人的自由，从而保护自己的利益。
历史上不是没有发生过这种事。网景最初开源 Mozilla 项目，就是采用了自己制定的 Netscape 公共许可证，其最显著的特点是它给予了 Mozilla 的原始开发者，也就是网景它自己，有权分发后续及衍生软件，其他贡献者却不可以，最后结果证明了这条路根本行不通。
随着 SaaS 交付模式日益流行，使用与贡献不对等的情况变得严峻。云服务供应商依托开源软件大举盈利，却不需要贡献任何代码，在这种情况下，无限制地放开商业自由，就是对开源厂商的伤害。贝恩资本的 Salil Deshpande 曾表示：“需要明确的是，这并不违法。但我们认为这是错误的，不利于可持续的开源社区。”
为解决这一问题而诞生的开源许可证—— AGPL 曾被寄予厚望，但由于它的限制条件有些模糊，比如“用户通过网络进行交互”可以延伸到什么程度没有具体说明，且它是强 Copyleft 许可证，最终被部分开源厂商抛弃。
不能没有商业自由，但又不能无限制地放开商业自由，商业自由的“度”在哪里？
面对云服务供应商的“吃白食”行为，有厂商在发布开源项目时，在许可证之外，还会添加限制条款。Nebula Graph 是一款开源的分布式图数据库，基于 Apache 2.0 许可证分发。不久前，开源厂商 Nebula Graph 为了防止云服务供应商从项目中获利而不作出回报，在项目中加入了 Common Clause 1.0 条款。不过在 ASF 的要求下，Nebula 团队最终移除了该条款。
也有很多开源厂商直接变更许可证，以防止云服务供应商从他们的代码中构建服务。2021 年 1 月，Elastic 公司宣布，把根据 Apache 2.0 许可授权的 Elasticsearch 和 Kibana 源代码变更为双重授权许可模式，即 SSPL+Elastic 许可。
SSPL 是 MongoDB 在基于 GPL v3 的基础上，面向服务器端制定的许可证。该许可证虽然允许用户使用及修改产品源代码，但有一个基本要求，就是在该协议下，如果企业将产品作为服务对外提供，则必须同时提供“服务源代码”。所谓“服务源代码”，是指程序或修改版本的相应源代码，以及用于提供此服务的软件源码，包括但不限于管理软件、用户界面、应用程序接口、自动化软件、监控软件、备份软件、存储软件和托管软件，所有这些让用户可以使用可用源码运行服务实例。而 Elastic 许可则更加严格，直接禁止将软件作为托管或托管服务提供给第三方。
除此之外，Confluent、MongoDB、Cockroach Labs、Redis Labs、Timescale 和 Graylog 等，也都从 OSI 批准的开源许可转向非“开源”的许可。
如果一个软件限制云厂商使用，那还能算是开源软件吗？当然不算。根据 OSD 第六条，不得歧视任何领域，这就表示，不让商用，不让云服务用，这些行为都是禁止的。把云厂商排除在外的许可证，不是 OSI 所认可的开源许可证。没有采用开源许可证的软件自然也算不上开源软件。 对于 SSPL，OSI 就明确表示，它不是开源许可证，因为它实际上剥夺了用户权利。
面对开源厂商的相继出逃，开源还应该坚持无限制地放任商业自由吗？如果不限制，那么谁来为贡献者的劳动成果买单？企业的角色注定了，开源对它而言，不会是一项只求付出，不求回报的活动。
如果能够找出让贡献者和使用者之间平衡的点在哪里，或许就会知道，开源能够允许的商业自由的“度”在哪里。从云计算上升的发展势头来看，这个问题将会成为长期争议的焦点。
开源的越来越主流化，企业需要确保自己所使用开源软件产品的可信赖性，于是，开源许可证变得越来越重要，但它实现起来并不容易，据报道，如今业内有超过 33万个开源软件供各种类型的企业使用。如此繁多的开源软件，不仅要保证其开源许可证，还要保证其高可靠性，这对于使用者来说，无疑是个难题。要选择正确的开源软件，最基本的判定方式就是通过开源许可证，目前也有相应的权威部门和机构来进行开源软件的认证，这样的部门有一套切实可行的认证管理以及说明文件。
除此之外，还有一些其他条件可以缩小选择开源软件的范围。例如：新的开源软件项目评估方法：SOS开源系统，这是源于开源策略专家Roberto Galoppini的自动化方法论。该工具使企业可以确定任何既定开源软件的风险水平。SOS开源系统使用24度量方法，并从开源项目目录中收集信息。Galoppini还说，SOS 开源系统敏锐地集中在项目实力上，在项目稳定性和成熟性方面进行监测，并能够确定该项目是否具有一个可预测的切实可行的社区支持。
但是如果开发者已经在没有经过允许的情况下使用了开源资源该怎么办？当然，还是有应用程序解决这个问题的。如Black Duck软件，OpenLogic和Protecode为用户提供的服务可以跟踪开源软件的使用情况。事实上，这些供应商甚至可以通过内部编码应用程序的方法来保证开源资料或者代码碎片不违法他们设计的许可。
对于那些还没有设置开源使用政策的公司，再也没有比现在更好的时机了。通过这些判定手段，企业可以更方便地选择到适合自己应用的开源软件。有鉴于此，这里从开发者、商业公司、开源社区等多个方面来讲解他们之间的复杂关系。
开源，理想自由还是作茧自缚？
当我们谈论开源时，很少谈论自由，尽管开源与自由同行。从 1998 年开源一词兴起时，我们就无法把开源和自由分割开来。因为它孕育于自由软件运动，自由使用、复制、修改、分发源码，其精神内核一直延续至今。“自由”，为何对开源如此重要？我们将依次用《开源，是背叛自由还是以退为进？》、《开放协作：赋予开发者的自由》、《商业自由：从边缘到核心贡献》三篇文章来回答这个问题。
作者：肖滢，以下三篇文章转自她的oschina的博客，感谢作者。
开源，是背叛自由还是以退为进？
为软件用户的自由而战
事后二十多年，Richard Matthew Stallman(RMS)对施乐公司拒绝提供打印机源码的愤怒仍然挥之不去，以至于他在开展自由软件运动演说时频频提及。
20 世纪八十年代初，麻省理工学院 AI 实验室获赠了一台新的激光打印机，机器能以更高的精度打印图形，并减少了 90% 的打印时间，但经常会出现卡纸的情况，这很常见。如果在以前，RMS只要简单地修改一下源码，就可以通知人来解决这个问题，然而这一次，赠送打印机的施乐公司没有像以前一样提供人类可读的源码，这意味着他无法自己修改。而后向开发人员索求源码也遭到拒绝，对方称签署了保密协议。
打印机事件让 RMS 切身感受到，商业公司为了利益，限制他人使用源码或者停止提供源码剥夺了自己的自由。那段时期，实验室计算机的密码保护、黑客成员的流失、商业公司对源码的保密，让他不止一次意识到，其引以为傲的黑客文化——自由共享源码、创新、合作，由于商业行为的冲击正在消亡。
而随着微处理器的出现，计算机进一步小型化，个人计算机时代到来，成千上万带有使用许可证和保密协议的专有软件扑向了用户。这些用户并不是开发者，他们只关心新软件、新功能，并不关心是否有源码。
但对于 RMS 来说，则陷入了两难的境地：要么默许使用专有软件，但他曾多次旗帜鲜明地反对专有软件捍卫软件自由；要么创造一套自由的软件系统，但这是一项浩大的工程。
在此之前，为了反击 Symbolics 公司不再给提供更新后的源码，他曾有几个月的时间，在实验室单枪匹马写代码，以改进 Lisp 机器 ，实现了 Symbolics 一个团队才能完成的各种新功能和 Bug 修正。这让他对走第二条路充满了信心。他决定避免使用专有软件，并且创造一套完全自由的操作系统及其外围软件，来帮助其他用户获得完全控制软件的自由。
首先是要开发一套自由的操作系统。因为每一台计算机都需要一个操作系统，然而在20世纪八十年代，几乎所有的软件都是专有软件，操作系统也一样。
于是在 1983 年 9 月，RMS 公开发布了 GNU 项目的初始声明。声明提到，要编写一个完全和 Unix 兼容的软件系统 GNU。为什么要与 Unix 兼容？因为 Unix 的整体设计历经考验并且可移植，而且兼容性会让 Unix 用户很容易从 Unix 系统转移到 GNU 系统。
RMS 提出了明确的构想：GNU 会有一个内核，以及一系列编写和运行 C 程序所需要的应用：编辑器、shell、C 编译器、连接器、汇编器以及一些其他程序。此后，还会加入文本排版工具、Yacc、 Empire 游戏、电子表格和数百个其他应用。
GNU 项目初始声明的发布，标志着自由软件运动拉开了序幕。
开始的过程并不那么顺利，他想把 VUCK 编译器纳入 GNU，却被告知不允许；想用 Gosling 的代码编写解释器避免重复造轮子却被告知有版权保护，这让 RMS 更加坚定了自由软件运动的政治目标。
1985 年 ，RMS 终于发布了 GNU 项目的第一款软件——GNU Emacs 编辑器，同时还发布了“GNU 宣言”。宣言是对 1983 年 9 月发布的初始声明的扩展。为了更好地推动 GNU 计划，RMS等人成立了自由软件基金会(FSF)，还设计了 GNU 通用公共许可证(GNU GPL)，并以该许可证发行大部分软件。
GPL 是最能体现 RMS 自由思想的证据之一，因为它是 Copyleft 许可，在最大程度上保护了所有用户的自由。Copyleft 一词虽然不是 RMS 创造，但是他赋予其更加丰富、确切的含义。Copyleft 是一种方法，确保用户拥有使用、研究、复制、分发、修改及再分发作品的自由。还有一些许可同样授予这些自由，不同的是，Copyleft 还确保 Copyleft 许可作品的任何修改版本，也必须授予这些自由。要指出的是，Copyleft 是一种抽象的概念，抽象的概念无法直接使用，因此，Copyleft 以许可证形式存在。
站在后续或衍生版本的软件发布者角度来看，Copyleft 是一种限制；站在原始软件及后续或衍生版本的所有用户来看，Copyleft 是慷慨地给予。
当时，大部分的自由软件许可向直接的下游开发者提供了最大的自由，包括将代码用于闭源项目。然而，代码用于闭源项目之后，等同于断送了用户学习、分发、修改和再分发该软件的自由。而 Copyleft 许可 ，则保证了这些“自由”不被中断，可以随着后续或衍生版本延续下去。
商业软件开发人员通过 Copyright(版权)剥夺了用户的自由，而 RMS 通过 Copyleft 来给予用户自由，而且是最大程度上的自由。
开源是对自由软件的背叛吗？
在1991 年，GNU 操作系统大部分组件都已经选择好或开发完成，包括强大的 GNU 编译器套件 GCC，但独独缺了一个重要的内核。因为原定的 GUN Hurd 内核开发进展缓慢，迟迟未能发布。 直到 1992 年 2 月，事情迎来了转机，Linus Torvalds 发布了 Linux 内核 0.12 版，也是从这个版本开始，Linux 内核采用了GNU GPL 许可证，成为了自由软件。 几乎完成的 GNU 系统和 Linux 内核的结合，诞生了第一款完全自由的操作系统 GNU / Linux ，现在，我们称之为 Linux 系统。
在此之前，尚不存在完全自由的操作系统，而 Linux 内核补上了最后一块拼图。
Hurd 的难产以及 Linux 的成功，让前 GNU 成员 Eric Steven Raymond(ESR) 开始思考软件项目管理问题。而思考的成果，掀起了一场轰轰烈烈的开源软件运动。
RMS 不会想到，1998 年 4 月他未被邀请的那场小型的“自由软件峰会”，让 ESR 等人达成了用“开源”一词取代自由软件的共识。参会的关键人物还包括 Linux 内核创始人 Linus Torvalds、Apache 主要开发者 Brian Behlendorf、 Sendmail 创始人 Eric Allman、Perl 语言创始人 Larry Wall、Python 语言创始人 Guido Rossum 等人。之后，自由软件阵营中的部分成员分裂出来，以“开源”的名义开展活动。几个月后，它通过报纸、杂志等媒体流行开来，并得到了企业及开发人员的广泛支持。
一开始，RMS 并没有持反对意见，但很快他就发现，开源这个词所代表的主张已经开始异化，使得其背后的逻辑与自由软件运动的初衷相去甚远，因此他坚定地撇清自由软件与开源软件的关系。RMS 认为：“自由软件运动为用户的计算自由而战斗；这是一个为自由和公正而战的运动。相反，开源理念重视的是实用优势而不是原则利害。我们因此不赞同开源运动，也不使用开源这个词。”尽管他自己也承认，“自由软件”和“开源”基本上指的是同一范围的程序。
他曾解释过开源异化的原因：“一旦支持者开始为开源营销的时候，自由软件运动所珍视的那些价值观就被抛诸脑后。于是，‘开源’一词很快就单纯地和各种实用主义的价值观联系起来。比如说怎么能创造一个强大、稳定的软件。很多开源支持者从一开始就把这些价值观推崇至极，也难怪局外人会有如此联系了。大多数‘开源’的讨论都绝口不谈是非对错，而只是讨论流行与成功。”
但这并不能说是 ESR 等人对自由软件运动的背叛，恰恰相反，他们的本意是要让“自由软件”获得主流企业的支持，从而实现更广泛地传播。
我们可以从 ESR 于 1998 年 2 月发表的《再见，自由软件；你好，开源软件》一文轻易得出结论。他认为，“free software”一词的问题是双重的。因为 “free” 一词的意思令人困惑，因为它既有免费的意思，也有自由的意思。“free”是意味着“不收费”，还是指“任何人都可以自由修改”，还是其他什么意思？其次，“free”一词的免费含义，让很多企业感到紧张，应该用一个新的定义来争取他们的认可。这也是 ESR 首次公开呼吁使用“开源”一词。
ESR 为何会说企业对“free software”感到紧张？因为在几天前，他试图通过网景公司受自由软件文化影响从而公开源码的案例来说服企业效仿，却遇到了阻碍。多数企业高管在第一次听到“free software”时，将其解释为“零成本”的同义词，明显与追求利益背道而驰。尽管一直以来，RMS和其他黑客尽了最大努力宣传，自由软件中的“free”一词代表自由而不是价格。
开源促进会(OSI)由 ESR 等人成立，是开源运动的主要支持者和倡导者之一，它曾公开发表观点称，“free software”一词已被商业人士误解，他们将分享的意愿误认为是反商业主义，或者更糟，是盗窃。主流企业 CEO 和 CTO 永远不会购买“免费软件”。但是，如果把同样的传统，同样的人，同样的自由软件许可证和标签更改为“开源”，他们会买。
比起 RMS 热衷于自由软件所表达的政治主张，ESR 等人更看重自由软件的开放、协作的开发模式。Linux 内核的开发就是基于这一模式。
在 Linux 之前，复杂的软件是由小团体精心设计的，源代码在软件发行后公开，但在软件的每个版本开发过程中都由一个专属的团队所控管，比如 GNU Emacs 及 GCC 就是在这种模式下开发的，ESR 将其称之为大教堂模式。但 Linux 以完全不同的方式发展。几乎从一开始，源码就被公开，它被大量志愿者查看并参与开发，仅通过互联网进行协调。质量不是通过严格的标准或独裁来保持的，而是通过每周发布并在几天内从数百名用户那里获得反馈这样简单的策略来保持，这被成为集市模式。除了 Linux 项目之外，ESR 自己的项目 Fetchmail 也沿用这一模式开发并且获得了成功。
这两种模式最后被 ESR 整理成论文《大教堂与集市》，于 1997 年对外发表。网景公司也正是受到这篇文章的启发，公开网页浏览器的源代码，并启动 Mozilla 项目。
从这一层面来说，ESR 等开源倡导者的确是有意避开政治运动。但不可否认的是，撇开政治隐喻不谈，开源软件运动在捍卫软件用户自由上，实际上与自由软件运动是大体一致的。事实上，由 OSI 发布的“开源软件”的官方定义，间接源自自由软件的标准。虽然这些运动有不同的价值观和目标，但并不妨碍开源社区和自由软件社区的人们在实际项目中进行合作。
可以这么认为，开源软件运动是向商业公司妥协后的自由软件运动，听起来是有些软弱，但确实起到了实质性的作用，“开源”一词的出现，极大地推动了开源历史进程。没有了对“free”一词的误解，也没有了剑拔弩张的政治运动，许多大型机构和企业如雨后春笋般涌现，以支持开源软件运动的发展。Apache 软件基金会(ASF)就是其中之一，此后贡献了Apache Hadoop 等多个顶级开源项目。1998 年，四款自由软件 Linux、Apache、MySQL 和 PHP 组成的“LAMP 包”成为替代商业包的典型代表被展示在杂志上，在很长一段时间内，它都是交付 Web 应用程序的最常见方式之一。
发展到今天，开源软件已经极其普遍，几乎存在于全球 2000 强企业的所有关键任务软件组合中。以至于当 Marc Andreessen 发出“软件吞噬世界”的感叹时，有人补上了后一句，“开源吞噬软件”。
这么说的话，开源并不是背叛自由，而是以退为进，将自由软件运动的精神内涵承袭下来，以更加柔和、包容的方式对外宣传开去。
开放协作：赋予开发者的自由
自由共享的精神与开放协作的开发模式，像两条绳子拧成了一股，成为开源项目生存和发展的核心支柱，一直延续至今。开放协作，赋予了开发者参与开源项目最大程度上的自由。这种自由，在Linux 内核的开发上首次攀上了高峰。
一群极客的狂欢
Linux 内核第一次大规模吸引用户，是在 1992 年 1 月 0.12 版发布之后。尽管当时功能有限，但作为一款类 Unix 的操作系统内核，本身就已经具有相当大的优势，尤其是在 Unix 作为一款专有软件对外售价不菲时。特别之处在于，设计者 Linus 开放了一个专门提交代码的站点。这意味着，除了核心小组的六个成员之外，开发者可以直接参与 Linux 内核的开发，自由地提交代码，以解决一些问题，或者实现一些功能。
Linus 经常把 Linux 内核的更新情况发布在 Minix 新闻组，这里聚集了一批 Minix 操作系统的铁杆粉丝。对一群热衷于技术的开发者来说 ，一个新的操作系统，确实存在致命的吸引力。 Linux 的用户数量迅速增加。
1992 年，使用 Linux 操作系统的用户已经近千人，其中大部分是热衷于技术的黑客高手。到了 1993 年，通过互联网参与内核修改和编写的开发者已经有近百个。1994年，伴随着 Linux 1.0 的正式发布，内核的开发也进入了良性循环。1995 年 3 月 1.2 版发布时，Linux 内核已经有了25万行代码。新杂志 《 Linux Journal 》的发行量达到了一万本。Linux 系统也能同时适用于英特尔处理器、DEC 的处理器以及 Sun 公司的SPARC处理器了。Linux 跨出了一大步。
几年以后， Linux 社区的开发者已经成千上万，他们依靠邮件列表以及彼此之间制定的规范进行联系和开发，自由提出功能需求，自由维护和升级。“一切工作都按部就班地进行，不用投票表决，不用组织拉票，更不用重新计票，反正大家都知道谁是活跃分子，谁是他们信得过的人 ”。在 Just for Fun:the Story of an Accidental Revolutionary 一书中，Linus 描述了这种协作方式。
在此之前，没有多少项目会把开发过程完全对外开放，让用户参与进来。比如在 GNU 工程的各项目开发中，贡献代码的往往只有少部分人，只有当新版本完善后才会对外公布源码，版本发布间隔的时间可能要几个月。对于社区的众多开发者来说，他们能做的仅仅是测试软件，提出问题或者功能需求，尽管这也很重要，不过参与程度极其有限。
在软件项目管理方面，当时流行的理论是布鲁克斯定律，即向项目添加开发人员只会导致进一步的项目延迟。该定律由 IBM System/360 系统之父 Fred Brooks 在 The Mythical Man-Month: Essays on Software Engineering 中首次阐明。布鲁克斯定律预测，一个拥有数千名贡献者的项目应该是一片片状、不稳定的烂摊子。
Linux 社区无疑是打破了这一理论。随着越多的开发者加入，Linux 逐渐成为一款高质量的操作系统内核。1996年，Linux 内核的全球用户量已经迅速增长到350万。在 Linus 看来，这一切都要归功于他的两个缺点：一是懒，二是因为喜欢占别人劳动成果的便宜。因为懒和喜欢占便宜，所以他把一些功能交给其他人开发，坐享其成。除了最终决定权属于 Linus 之外，其他开发者都是平等的，都可以增加系统功能。这也是“Linux 开发模式”的特别之处，没有局限于六个核心成员之间，而是邀请所有用户参与，集思广益。 《大教堂与集市》的作者 ESR 如此评价：Linux 是第一个有意识地成功利用整个世界作为其人才库的项目。
早期，软件用户多为具备编程能力的开发人员，因此，当 “自由软件之父”RMS 提出保护软件用户运行、复制、分发、学习、修改及再分发源码的自由时，实际上就是指开发者的自由。毕竟，普通用户可不关心软件供应商有没有提供源码。而 Linus 则用开放、协作的方式，进一步把开发者的自由扩大化、具体化了。对开发者这一角色而言，最好的自由不就是开发的自由吗？
这种自由，让每个贡献代码的开发者都成为项目的创造者，而不再是旁观者、局外人。本来是Linus 一个人的狂欢，最后变成了一群极客的狂欢。自由带来的热忱，推动了Linux 内核的成功。在众多开发者的协同开发下，截至 2021 年，Linux 内核 5.11 版本的代码量达到了 3034 万行。
ESR 正是从 Linux 内核的成功中受到启发，最后写下了著名的《大教堂与集市》一文，引起了众多软件企业的关注，从而掀起了轰轰烈烈的开源软件运动。Linux 成功的关键——开放协作的开发模式，就这样成为了开源协作模式的典型代表。
不自由的代价
Linux 内核不是第一个利用该模式进行开发的项目，但从项目热度、开放程度、协作深度，以及波及广度来看，产生的影响却是最大的。在20世纪90年代后期，越来越多的开源项目转而采用这一模式，星星之火已成燎原之势。
1997年，一群开发者因不满 GCC (GNU 编译器系统)缓慢且封闭的创作环境，组织了一个名为EGCS(Experimental/Enhanced GNU Compiler System)的项目。GCC 和 EGCS 是两个并行产品——两者都来自相同的互联网开发人员群体，都来自相同的 GCC 源代码库，都使用几乎相同的 Unix 工具集和开发环境。这些项目的不同之处仅在于 ，EGCS 有意识地尝试采用开放协作的开发策略，而 GCC 保留了一个原先的组织模式，开发组较为封闭，发布次数不频繁。
几个月之后，EGCS 版本在功能上大大领先，不仅能更好地支持 FORTRAN 和 C++，而且比 GCC 最新的稳定版本更可靠，主要的 Linux 发行版也都开始转向 EGCS。1999 年 4 月，自由软件基金会( FSF )解散了原来的 GCC 开发小组，正式将项目控制权交给了 EGCS 指导小组。
如果说 GCC 的教训还不够深刻，那 Mozilla 开源的历程或许能更好地归因开源的成与败。
网景公司是第一个将商业产品开源的企业。1998 年 1 月，网景公司宣布将浏览器套件开源，代号叫 Mozilla，并建立了专门负责该项目的组织，希望借助全球开发者的力量挽狂澜于既倒。彼时，它正与微软在浏览器市场激战正酣。微软攻势猛烈，将 IE 浏览器与 Windows 捆绑销售，并且免费提供，这使得曾经风靡全球的网景浏览器(Netscape Navigator)节节败退，尽管其市场占有率一度高达 90%。最后仍由 IE 浏览器占据了半壁江山。
然而事实再一次证明，不够开放、自由的开源项目，无法调动开发者的兴趣，无法吸引开发者广泛参与。一个开源项目没有了用户，就如同没有了生命，即便能够风靡一时，也终究会被时代抛弃。
网景公司公开的源代码是老旧的开发版本，存在诸多问题；Mozilla 使用了NPL许可证，这允许网景公司将后续版本作为专有软件发布，而其他人却不可以；源码还混入了很多非自由软件的代码；Mozilla 不接受公司外部开发者的代码，仅靠公司内部人员维护。其中种种，让网景公司负面缠身。这种遮遮掩掩、重内排外的开源方式，完全背离了自由共享、开放协作的开源精神。在 Linus 看来，网景公司不过是提供了一大堆源代码而已。
彼时，ESR 等开源倡导者都看到了这些问题，但没人敢提出批评的声音，怕给刚诞生的开源“抹黑”，只能焦灼地看着网景浏览器的市场份额不断输给 IE。
网景公司也意识到，这样的“开源”无济于事，在10 月重做了 Mozilla 项目，实现了真正意义上的开源。这取得了一些令人激动的效果。11 月，网景浏览器就扭转了市场份额下滑的局面，并开始在与 IE 的竞争中获利。然而已经太迟了。这对于当时的网景公司来说，无异于杯水车薪，终究未能挽救颓势。1999年，网景公司被美国在线公司收购。
庆幸的是，开源使 Mozilla 得以保留了火种。经过几年的发展，诞生了基于 Mozilla 源码的火狐浏览器(Firefox)。在 Mozilla 基金会官网上，是这样介绍 Mozilla 项目的：“它旨在利用互联网上成千上万程序员的创造力，推动浏览器市场实现前所未有的创新水平。”今天， Mozilla 确实做到了。它已经是一个成功且瞩目的开源项目，旗下的开源软件 Firefox 每月都会按计划发布一个新版本，在浏览器市场，它已经占据了稳定的市场份额。
Mozilla 曾经走过弯路，但及时调转了船头。不可否认的是，网景公司开源 Mozilla 是有划时代意义的。继网景之后，Sun、IBM 、Informix、Oracle 等大型企业都相继加入到开源运动中来，从开放接口，一步一步到软件开源。
如今只道是寻常
二十多年来，开放协作的模式在不断演化，更加自由，更加开放，协作人数日益增加，参与范围扩至全球，成为了开源项目最为普遍的开发模式，甚至成为了开源协作模式的代名词。伴随而来的是，更多能够实践这一模式的工具和平台被创造出来，开发者的自由再一次攀上新的高峰。
当前流行的开源分布式版本管理工具 Git， 就是 Linus 为了让更多的人同步开发而设计的。
在 1991 至 2002 年间，绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上，这是参与者迅速蹿升带来的不可避免的问题。 到了 2002 年，整个项目组开始启用 BitKeeper 来管理和维护代码，这是一个专有的分布式版本控制系统。
三年之后，开发 BitKeeper 的商业公司与 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权利。 这就迫使 Linux 开源社区，特别是 Linus，基于使用 BitKeeper 时的经验教训，开发出自己的版本系统。经众多开发者十几年的努力，Git 已经成为开放协作模式的主流配置。
Github、Gitlab都是基于 git 的开源协作平台，它们的出现为开发者参与开源提供了更加高效、便利的方式，不仅能够为他人的项目贡献代码，甚至可以快速建立自己的项目——就算社区不接受提交的代码，也可以一键 fork 自己的分支。
每年，都会有大量开发者通过 Github、Gitlab 等协作平台投身开源之中。《GitHub 2020 数字洞察报告》显示，2020 年，Github 的活跃代码仓为 5421 万个，同比增长 36%；活跃开发者数为 1454 万人，同比增长 22%。正是因为开发者的积极参与，Linux、MySQL、Hadoop、Kubernetes、TensorFlow、React、VS Code 等基础软件迸发出蓬勃生命力。
身处 Github 织造的协作网络之中，自由唾手可得，开放协作的自由理念已经深入人心，不会时常提及，但无一不涉及，一旦遇到威胁，就会引起警觉。2018 年，当微软宣布以 75 亿美元收购 GitHub 时，很多开发者及对 GitHub 未来的独立性表示怀疑，因此把托管在 Github 上的开源项目迁移到Gitlab上。
仅仅在一周之内，Gitlab 的项目迁入量就达到了一万以上。尽管这个数量对 Github 上几千万个活跃代码仓而言，不过是沧海一粟。
但它的意义很是鼓舞人心。是的，即便是一个全球范围内最大的开源协作平台，即便是一直以来给予其极大程度上自由的平台，对部分开发者而言，一旦成了微软——一个靠专有软件发家致富的巨头企业——的一部分，就变得不再可靠。一方面，Github 虽然可以免费托管开源项目，并且为开源事业做出了许多贡献，但 Github 的网站和软件并没有开源，以后若有什么不利于开源的动作也合乎情理；另一方面，微软过去反对开源，影响过于深刻，以致于让人忽略了今天的微软已经是 GitHub 上最大的企业贡献者。
“叛逃”Github，让人意识到，开放协作的自由，是开发者一直以来追寻的旗帜，是开发者从未放弃的权利。
从思想启蒙，到方法实践，再到工具创新，哪一样不是为了开发者的自由而来？自由不是与生俱来的，而是一批又一批开源先驱前赴后继开辟出来的。当专有软件切断了开发者的自由，RMS 站了出来；当布鲁克斯定律框住了开发者的自由，Linus 站了出来。不管是有意还是无意，是主动还是被动，只要有人在追逐自由的光，那就会趟出一条自由的路。
开源与自由 | 商业自由：从边缘到核心贡献
不得不承认的是，个人英雄式的独立开发者时代已经落幕，随之而来的是，互联网科技企业成为开源社区的主要力量。
当企业成为开源的主体，开源一定需要商业自由。那么，开源与商业是怎样的关系？商业自由能为开源带来什么？为了保证商业自由，企业做了什么样的选择？无限制地放开商业自由，对开源会有什么影响？
不是二选一
我们提到过，1998 年 Mozilla 的开源，具有划时代意义。由它开始，掀开了企业大规模开源的序幕。在 20 世纪七八十年代，还没有开源的说法，只有“自由软件”，自由软件主要由个人或者大学等机构主导，GNU 工程就是其中典型的代表。而发布自由软件的企业屈指可数，它们处于自由软件世界的边缘位置。
自由软件在商业企业中并不受欢迎。它赋予用户分发软件源代码的自由，在很大程度上损害了企业的利益。
微软 CEO 比尔·盖茨于1976年发布的一封公开信，可以反映出企业对分享软件这一行为的普遍态度。他在信中抱怨，未经授权使用 Altair BASIC 的情况太普遍，导致新成立的微软公司回报甚微，并指出那些分享拷贝软件的人是剽窃者。“谁能负担得起白做专业工作？哪个业余爱好者可以花 3 年时间进行编程、查找所有错误、记录他的产品并免费分发？事实是，除了我们之外，没有人在业余爱好软件上投入大量资金。你所做的就是盗窃。”
不过，自由软件本身并不抵制商业化。自由软件基金会(FSF)就明确表示，自由软件无关价格。很多人以为，GNU 计划的精神是不应该为分发软件副本收费，或者应该尽可能少收费——刚好足以支付成本。这是一种误解。实际上，他们鼓励重新分发自由软件的人尽可能多地收费，以此来支持开发。“分发自由软件是为开发筹集资金的机会。不要浪费它！”当然，这一切都建立在保证用户有自由运行、学习、修改以及再发行原版或是修订版软件的前提下。
“开源”的出现，更是为商业自由而来。1998 年，正是因为 ESR 等一批自由软件运动的倡导者考虑到“free software”中的“free”有免费的意思，对商业不友好，才出现了用“开源”一词替代“自由软件”，以方便对外宣传，吸引更多的企业加入到自由软件运动中来。随后，开源促进会(OSI)批准了第一批许可证，其中就包括 BSD 许可、MIT 许可两个商业友好型的许可证。OSI 维护着开源定义(OSD)，判定一份许可证是否属于开源许可证，以 OSI 认证为准。
从一开始，开源与商业不是二选一的关系，而是共生的关系。
早在上世纪 90 年代后期，RedHat、MySQL AB 等公司就证明了，利用开源软件来赚钱是可行的。尤其是 RedHat 在1999 年以创纪录的 IPO 公开上市，更是令不少企业艳羡不已。而今开源已经是一种成熟的商业模式，一头扎进去，人才、市场、名声，全都可以握在手里，足够顺利的话，甚至还能建立一个以开源项目为核心的产业生态，坐收渔翁之利。
2007 年，为避免苹果公司的移动操作系统 iOS 垄断市场，谷歌主动开源 Android 操作系统( 该开源项目简称：AOSP)。由此，Android 系统在移动端的市场份额一路飙升，2020 年超过 70%。这也为谷歌移动服务(GMS)带来广阔的市场。要知道，GMS 每年为谷歌带来数百亿美元收入。
用开源的手段扩张市场，在软件行业已经屡见不鲜，除了谷歌这样的科技巨头，不少初创企业也加入进来。MongoDB 公司的 CEO Dev Ittycheria 就明确表示，开源就是为了获得市场。公司成立的第三年，MongoDB 已经初步开发完成，却没有足够的资源面向整个庞大的市场进行营销，因此想利用开源的病毒性传播属性，让软件得到广泛使用。这一策略确实奏效，几年之后，MongoDB 成为了最受欢迎的 NoSQL 数据库之一。
微软收购全球最大的软件开发平台 GitHub 进一步表明，大公司正在寻求成为开源的主要供应商，并准备在其中投入大量资金。
商业反哺开源
企业是商业自由的最大受益者，同时也在反哺开源。它已经从最初的开源软件使用者，转变成集创建者、使用者以及贡献者多重身份于一体的角色。开源已经离不开企业，离不开商业自由。
最直接的证据是，企业贡献了一大批顶级的开源项目，成为开源技术的引领者，尤其是在近几年尤为活跃的人工智能、大数据、云计算等新兴技术领域。微软创建了源码编辑器 VSCode，谷歌创建了机器学习平台 TensorFlow、容器编排平台 Kubernetes，Facebook 创建了移动应用开发框架 React Native。众所周知，这些技术领域的创新都源于开源生态，企业功不可没。
它们同样也为其他开源项目贡献代码。尤其是软件巨头，成为了最大、最活跃的贡献者。根据 Open Source Contributor Index 公布的 2020 全球开源厂商 GitHub 开源贡献排名，谷歌和微软两大互联网巨头排在榜单前二位，二者参与开源贡献的活跃贡献者人数都超过了 5000 人，参与的开源社区超过 10000 个。微软、谷歌、IBM、Oracle、Facebook 五家科技巨头企业参与的开源项目数超过 20000 个。
在一些大型的、复杂的、生命周期长的开源项目上，企业所具有的软件工程调度能力，会比零散的个人开发者更具有优势。红帽博客编辑总监 Joe Brockmeier 认为，理想情况下，企业开源结合了两个世界的优点——开源的优势与企业软件提供的稳定性、性能、支持和生态系统。
也正是因为开源允许商业自由，才有更多商业模式诞生，吸引更多企业加入。从最早期的“RedHat”模式，发展到 SaaS 模式、Open Core 模式、限制性许可模式、混合许可模式等，越来越多的企业在尝试构建新的开源商业模式。在过去的十年中，Open Core 模式成为了最成功和最常用的方法。Elasticsearch 和 MongoDB 就是该模式下商业化的开源项目，二者也都成为了商业开源软件公司(COSS)。对于其他跃跃欲试的企业来说，一套成功的商业模式无疑是具有鼓动性的。
此外，企业结合开源软件实现商业转化，获得收入之后也能够更好地回馈开源社区，让项目可持续。一个现实问题是，很少有人有足够的空闲时间将其用于真正的开源贡献。因此，不少通过开源获益的企业会付钱给开发人员或运营人员，让他们为开源软件做出贡献。
难以想象，在企业取代个人成为开源领域绝对主流的时代，没有了商业自由，开源会变成什么。
许可证的选择
在开源世界，什么会限制企业的商业自由？那自然是规则，也就是开源许可证。选择什么样的许可证，关系到企业的开源商业模式。
开源许可证大体可以分为两大类：一类是 Copyleft 许可，另一类是宽松型许可。宽松型许可证对他人如何使用开源组件的限制最小，几近于无。它们允许用户在不同程度下自由使用、修改和重新分发开源代码，并允许在专有衍生作品中使用宽松型许可的开源组件，几乎不需要任何回报。
简而言之，宽松型意味着不强制开源，条条框框少了，对商业友好，企业利用开源软件发展业务更加便利。
一个越来越明显的趋势是，宽松型开源许可证使用量明显增长，而 Copyleft 许可证，尤其是GPL 许可证的使用量继续减少。根据 WhiteSource 发布的数据显示，2020年，76% 的开源组件拥有宽松型许可，比上一年提高了 9 个百分点。24% 的开源组件是 Copyleft 许可，比上一年减少了 9 个百分点。在 2012 年，Copyleft 许可证还牢牢占据上风，有 59% 的使用率，而宽松型许可证的使用率仅为 41%。
宽松型许可证大行其道，开源项目创建者的意志起了决定性的作用。近年来，互联网科技企业成为了开源项目的主要创建者，而不再是个人。使用 Copyleft 许可证，就意味着失去自己的私有软件的控制权，从商业角度出发，限制较少的宽松型许可证是企业的最佳选项。对用户限制越少，对自己也就越有利，企业本身就是最大的用户。
MIT 许可证及 Apache 2.0 许可证 ，就是典型的宽松型许可证。2020 年，使用 MIT 许可证或 Apache 2.0 许可证的开源项目超过一半，其中不乏一些备受瞩目的开源项目。例如，Ruby on Rails、jQuery 和 Angular.js 使用 MIT 许可证，Kubernetes、TensorFlow 和 Swift 首选 Apache 2.0 许可证。事实上，所有 ASF 项目——其中一些被广泛使用——都在 Apache 2.0 许可下。
用户也选择以宽松型许可证授权的开源组件，这样可以最大限度地减少法律部门对开源许可证合规性的挑战。而针对许可证不符合企业要求的开源项目，已经有不少企业制定了黑名单，禁止开发人员引用相关代码，从而避免风险。比如，Google 就禁用了以 AGPL 授权的软件。AGPL 是 Copyleft 许可，其中一条特别规定是，即使软件被运行在向公众提供服务的服务器上，那么该软件的任何修改也必须开源。
总之，为了保证商业自由，企业做出了使用宽松型许可的选择，无论是作为创建者的角色——将软件开源，还是作为使用者的角色——引入开源软件，更遑论作为贡献者的角色提交代码了。
商业自由的“度”
站在自由软件之父 RMS 的角度，将自由软件代码用于专有软件，就是在剥夺了用户使用、学习、修改软件的自由；站在 OSI 的角度，将开源软件代码用于专有软件是符合开源精神的，这是在保护用户基于任何目的使用软件的自由，哪怕是将代码用于专有软件。OSD 规定，开源许可不得歧视个人或团体，不得歧视任何领域。企业用户也是用户，商业自由也是自由。
当开源许可证成为商业自由的保护伞，一视同仁对待所有用户时，就有人开始不满。尤其是不少开源软件创建者，从选择许可证开始，尽可能地让自己拥有更多权利，尽可能地限制他人的自由，从而保护自己的利益。
历史上不是没有发生过这种事。网景最初开源 Mozilla 项目，就是采用了自己制定的 Netscape 公共许可证，其最显著的特点是它给予了 Mozilla 的原始开发者，也就是网景它自己，有权分发后续及衍生软件，其他贡献者却不可以，最后结果证明了这条路根本行不通。
随着 SaaS 交付模式日益流行，使用与贡献不对等的情况变得严峻。云服务供应商依托开源软件大举盈利，却不需要贡献任何代码，在这种情况下，无限制地放开商业自由，就是对开源厂商的伤害。贝恩资本的 Salil Deshpande 曾表示：“需要明确的是，这并不违法。但我们认为这是错误的，不利于可持续的开源社区。”
为解决这一问题而诞生的开源许可证—— AGPL 曾被寄予厚望，但由于它的限制条件有些模糊，比如“用户通过网络进行交互”可以延伸到什么程度没有具体说明，且它是强 Copyleft 许可证，最终被部分开源厂商抛弃。
不能没有商业自由，但又不能无限制地放开商业自由，商业自由的“度”在哪里？
面对云服务供应商的“吃白食”行为，有厂商在发布开源项目时，在许可证之外，还会添加限制条款。Nebula Graph 是一款开源的分布式图数据库，基于 Apache 2.0 许可证分发。不久前，开源厂商 Nebula Graph 为了防止云服务供应商从项目中获利而不作出回报，在项目中加入了 Common Clause 1.0 条款。不过在 ASF 的要求下，Nebula 团队最终移除了该条款。
也有很多开源厂商直接变更许可证，以防止云服务供应商从他们的代码中构建服务。2021 年 1 月，Elastic 公司宣布，把根据 Apache 2.0 许可授权的 Elasticsearch 和 Kibana 源代码变更为双重授权许可模式，即 SSPL+Elastic 许可。
SSPL 是 MongoDB 在基于 GPL v3 的基础上，面向服务器端制定的许可证。该许可证虽然允许用户使用及修改产品源代码，但有一个基本要求，就是在该协议下，如果企业将产品作为服务对外提供，则必须同时提供“服务源代码”。所谓“服务源代码”，是指程序或修改版本的相应源代码，以及用于提供此服务的软件源码，包括但不限于管理软件、用户界面、应用程序接口、自动化软件、监控软件、备份软件、存储软件和托管软件，所有这些让用户可以使用可用源码运行服务实例。而 Elastic 许可则更加严格，直接禁止将软件作为托管或托管服务提供给第三方。
除此之外，Confluent、MongoDB、Cockroach Labs、Redis Labs、Timescale 和 Graylog 等，也都从 OSI 批准的开源许可转向非“开源”的许可。
如果一个软件限制云厂商使用，那还能算是开源软件吗？当然不算。根据 OSD 第六条，不得歧视任何领域，这就表示，不让商用，不让云服务用，这些行为都是禁止的。把云厂商排除在外的许可证，不是 OSI 所认可的开源许可证。没有采用开源许可证的软件自然也算不上开源软件。 对于 SSPL，OSI 就明确表示，它不是开源许可证，因为它实际上剥夺了用户权利。
面对开源厂商的相继出逃，开源还应该坚持无限制地放任商业自由吗？如果不限制，那么谁来为贡献者的劳动成果买单？企业的角色注定了，开源对它而言，不会是一项只求付出，不求回报的活动。
如果能够找出让贡献者和使用者之间平衡的点在哪里，或许就会知道，开源能够允许的商业自由的“度”在哪里。从云计算上升的发展势头来看，这个问题将会成为长期争议的焦点。