何种授权模式是安全软件的正确选择

ZDNet安全频道原创翻译 转载请注明作者以及出处

在安全软件领域，存在三种不同的通用授权方式。怎样做才能选择出最适合自己软件发展的那一种呢？全世界似乎都以为软件开发是一个竞争环境，但实际情况上并不是这样的。实际上，安全软件发展和传播的关键是合作。
--------------------------------------------------------------------------------------------

关于严格意义上竞争的问题

我们首先看到的，就是封闭源代码的商业软件开发领域。实际上，在封闭源代码的商业软件开发领域，供应商之间的关系确实是竞争。它不需要向开发小组之外的人员透露相关的情况，因此，最终的结果就是团队之间的竞争不是不可避免的。之所以是不可避免的是因为软件开发的模式，更进一步说，是商业模式决定了这一点，如果他或她是敌人的话，竞争就是世界上每一个人不可避免的后果。但一些企业已经证明，开放源代码软件的发展可以提供带来大量利润的机会。

在开源的世界，有一个不是那么明显的例子。很多开源软件开发者和倡导者似乎认为，开源软件开发模式的最大对手是封闭源代码的开发模式。这个论点似乎是这样的：

1. 让封闭源代码的开发者为开源项目作出贡献的唯一办法是让他们别无选择。因此，开源项目应使用反版权（copyleft）的许可。简单的说，反版权的许可就是一个保障任何人都拥有对该作品及其衍生品的使用、修改和重新发布的许可。
 
2. 让更多的人使用开放源代码软件的唯一办法是让开源软件看起来似乎优于同等的封闭源代码软件（不论实际上是不是更好）。因此，这需要对封闭源代码的开发者进行“惩罚”以促进开放源代码软件的发展。

还有其它一些可以提出的论据，但在软件开发阶段，没有一个主题是和竞争相关的。

对于开源软件开发模式来说，一半的技术（而不是意识形态）原因是信任，而另一半是合作。合作给开放源代码软件带来的好处包括以下方面的内容：

1. 可以利用程序员的业余爱好时间开发软件功能，以及进行补丁开发和测试等工作。

2. 这样的话，就有机会进行更多的同行评议，发现存在漏洞的可能性就会上升。

3. 对一个项目的兴趣可能会增加其它开发商把你的工作纳入他们团队的机会。

你可能会注意到，实际上即使是在封闭源代码的软件开发模式下，这些事情也没有一个需要严格竞争的关系。实际上，在该列表上的第三个项目更可能被当作与封闭源代码的软件开发模式进行利益合作，而不是与它们进行竞争的方法。

采用这种授权的立场结果是，在每次有人改善了软件的性能后，人们就必须“作出贡献回馈社会”，并且强迫它坚持著作权的保护，这实际上对开源软件开发模式并没有起到真正的帮助作用。它做的只是在开源软件开发团队和封闭源代码的软件开发商之间建立一道墙，将两者明确地分开。这样的话，封闭源代码的软件开发商对于类似GNU通用公共许可证（GPL）这样的授权将是极其谨慎的，因为这种授权将会“包括”它“接触到”的其它代码。

关于GNU通用公共许可证的许可现在存在争论，但它是存在的，这样的话，至少从软件开发商（和管理人员以及和股东）的角度来看，保持其源代码封闭是必要的。正因为如此，由于使用了这样的软件许可，就必须依法承担任何代码的责任，这让封闭源代码软件开发商感觉这是错误的途径，使得它们必须发布自己开发的新代码。因此，软件开发商的反应通常是相反的：它们会拒绝使用采用了这种授权的代码，而自己编写新的代码，或者以其它的方式避免采用开源项目的代码。

这不会限制封闭源代码软件开发模式的发展。版权许可几乎总是相互排斥，因为每一个授权都将与代码相关，并且会进行重新分配。反版权的许可，这样就出现了相互矛盾的情况，让共享代码（但并不完全相同）的项目成为非法的存在。对于GNU通用公共许可证之类的反版权许可来说，也许更具有讽刺意味的是GNU通用公共许可证下的代码也有可能来自BSD许可证类型的自由拷贝（Copyfree）许可。当自由拷贝（Copyfree）类型许可的代码被包含在GNU通用公共许可证下的代码里的时间，它也会因为害怕受到来自GNU通用公共许可证的版权主张而被封闭源代码软件开发商所拒绝。

即使是“敌人”也有合作的价值

令人担忧的是，如果开源软件提供自由拷贝（Copyfree）类型许可的话，象BSD许可证的条款——它不需要“贡献”修改的代码，也不会有助于封闭源代码软件开发商回到“社区”。关于这个想法存在的问题是，它假设了如果没有开源软件的帮助，封闭源代码软件开发商根本不能（在某种意义上）成功，如果没有共享的修改代码。它们甚至不能更新。为什么很多人选择GNU通用公共许可证，还有一些其它方面的问题；他们希望对得到了好处而不知道回馈社会的开源软件进行“惩罚”。对于他们来说，这种动机非常强大。

有一个很著名的例子就可以说明这些不同风格的许可证是怎么影响代码共享，它和和两个最流行的开放源代码数据库管理系统相关。在这个例子中，一个开放源代码数据库管理系统采用了反版权的许可，而另一个采用了自由拷贝（Copyfree）类型许可。MySQL采用的是GNU通用公共许可证。而PostgreSQL则在BSD许可证的控制下。对于相信让封闭源代码的软件开发模式对开源项目作出贡献的唯一途径是“强迫”它们这么做的人来说，事实恰恰是相反的。实际上，PostgreSQL项目的代码就来自不少商业公司的贡献。举例来说，数据库厂商EnterpriseDB就被包括在内。

EnterpriseDB公司在PostgreSQL的基础上对功能进行了扩展，推出了Postgres Plus。在使用PostgreSQL和Postgres Plus的时间，它也可以提供额外的工具和服务。EnterpriseDB公司的整个商业模式是建立在作出重大贡献的PostgreSQL项目上的。它并不是依靠法律上的任何条款的要求而这么做的，而是因为有能力在PostgreSQL进行开发并且利用数据库管理系统的新功能参与到核心的发展中。并且，在项目核心中添加新功能生成新版本与一遍又一遍将功能移植到新版本相比更方便可靠。

EnterpriseDB公司展示的是一个成功的商业模式，而对于PostgreSQL来说，也是一个成功的发展途径。它是如此的成功，以至于可以声称，在可扩展性、遵守标准以及更强大的功能集方面都是最佳的选择，而MySQL仅仅在速度方面有一定的优势；在最近几年，与MySQL相比，PostgreSQL可以说在几乎所有方面都处于领先的位置。而在速度方面的一点劣势，也通常是因为MySQL牺牲了其他方面的重要能力才获得的。例如，只有在按照数据库系统必备的四种特性（指数据库的不可部分完成性（又称原子性，Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability））的标准进行对比，MySQL的性能标准才能表现的稍微好一点。当然，EnterpriseDB公司并非PostgreSQL数据库成功大大超越MySQL的唯一原因，但也应该算是非常重要的原因之一。

因此，我认为这样的结果看起来似乎很明显，与让封闭源代码软件开发商“采取”代码“回馈”的手段相比，加强双方之间的合作应该是更好的途径。尤其是当封闭源代码软件开发商对开源软件产生兴趣并采用也会吸引更多的人来使用开源软件。正如我已经在前面提到的，为了“保证胜利”，有许多种要求禁止封闭源代码的软件开发商利用开源软件，除非它们同意将开发过程也进行开源的想法。相比之下，考虑如何来开始使用开源软件（假设你希望这样做的话）可能是值得的，

到目前为止，你在阅读本文的时间也应该肯定是使用的封闭源代码软件。实际上，我自己就是一个特别引人注目的例子：从全部使用封闭源代码软件到几乎完全使用开放源代码软件。我经历的道路现在看来是漫长而曲折的。从一个封闭源代码软件环境里的一个开源应用程序开始，我逐渐增加开放源代码软件的使用比例，以替换正在使用的封闭源代码软件。让人们使用开放源代码软件，并逐渐适应是有可能的。但你不能通过禁止使用，让人们转移到开放源代码软件上。即使在开放源代码的环境下，也不能禁止人们使用封闭源代码软件。

如果你让用户使用他们喜欢的产品，不论怎么选择，最后的结果都会是性能更好的那种，除非基本功能上差别不大、感觉和费用上没什么不同。在安全软件这个领域，这就意味着，经过同行评议的更受到欢迎。从另一方面来看，就是如果你强迫用户选择其它产品的话，最有可能成功的结果就是说服他们坚持已经作出的选择。

这一切和安全有什么关系？

作为我的读者，你是无疑非常敏锐的，并已发现的至少一种涉及到安全的方式。在这里我指的发现漏洞的更多机会是依靠业余爱好的力量实现，在开发的时间它可以用来修复和测试程序。

我的提法的另一个（也许不那么明显）暗示关于开源开发模式采用两种技术之一带来的好处是：信任。向世界开放的代码更容易被信任。封闭源代码软件采用这样的代码并不意味着你会读，或者有时间去阅读它，甚至想知道读的结果。但是，这也就意味着，世界上的任何人都可以拿起你们的源代码，并进行分析，这样的话，你不太可能试图掩盖错误的东西，甚至令人产生怀疑的东西也不可能在代码（国家安全局建议使用椭圆曲线加密算法）中出现。如果你这么做，在代码中添加信息防止被发觉，其它人就有可能会发现它并将它的信息提供给他人（国家安全局的技术可以找出隐藏在椭圆曲线加密算法里的后门） 。

有（至少）一个或者更多的和安全相关问题的影响在这里出现：

安全不仅仅是一个和窗口的露水一样昙花一现的问题，仅仅对未经授权的用户或代码关闭系统的入口，运行入侵检测和全面的审核软件是远远不够的。安全也是一个生态系统。他人的安全和你自身的安全是息息相关的。在越来越多人的计算机被病毒感染，越来越多人的计算机被当作攻击的发起者而拥有者却并不知情的时间，你的收件箱将收到更多的垃圾邮件，收到来自朋友的受感染文件和危险连接而你自己却没有发觉的可能也会大大增加，互联网的整体环境将变得更加危险。因此，帮助别人变得更加安全也有利于自己的安全。

这并不是全部。你是否曾经想知道为什么加密通讯没有更快的普及？部分原因就是兼容性的问题。你不能发送没有办法解密的加密邮件，而希望它会产生什么用处。二十二条军规的黑色幽默就这样出现了：你需要人们使用加密软件，以便能够通过加密频道与他们进行沟通，但他们不太可能开始使用加密软件，除非更多的人使用它。

真正让我控制不住自己的是那些一边感叹缺乏加密的广泛使用，接着又宣称反版权是真正的许可模式，因为封闭源代码的软件开发商不应该能够受益于开源软件开发商的努力而没有“回馈”的人。当然，反版权许可往往意味着是封闭源代码软件厂商不愿意利用开源加密软件，为它们的客户提供加密通讯的功能，尤其是在GNU通用公共许可证是目前世界上销售情况最好的开源许可而开源世界以外的很多人甚至不知道这不是唯一的开放源码许可模式的时间。

如果你真想实现随时随地的加密，就应该选择PostgreSQL的模式，而不是Linux内核的模式。

一句话，曲线反而更容易达到目标：

1. 前提—个人的安全取决于不仅仅要依靠自身。它也取决于生态系统中每个人的安全情况。

2. 前提—不论采用什么样的许可，只要越来越多的人开始使用开放源码软件，它的发展就更容易受到支持。也就是说，会变得更好。

3. 前提—如果你想最大限度地保证整个生态系统的安全，实现这一目标最有效的方式就是确保将所有和安全相关的软件都提供给大家，而不论它们采用的开发模式是什么样的。

4. 结论—如果你想从一种软件中获得最大限度的安全的话，忘掉版权和反版权的吹嘘，只要有可能就选择自由拷贝（Copyfree）类型许可。

显然，你不应该只是因为采用不同的授权模式而抵制安全方面的相关软件。你只要了解问题的关键是什么就可以了，提高整体的安全性，并寻找机会，将系统迁移到一个更好的许可证模式下。

同样重要的一点请不要忘记，实际上所有的软件最终都是安全软件。安全始于基础软件的选择—如操作系统内核，甚至引导方式—软件的每一层都是一个组成部分，所有的方式都是面向用户界面的。因此，为安全相关的软件选择正确的授权模式并不仅仅适用于应用程序，列表本身就是“安全软件”。