【IT168 评论】我最近遇到的针对开源软件和社区的批评是开源永远不会胜出;专有和封闭源码(closed-source)软件永远都会存在。事实尽管如此，但这并不是开源的失败使然。

　　那些认为相互竞争的模型、方法或项目的存在就是一种 “失败” 的论调与开源的整个理念恰好背道而驰。自由重点之一就是人们可以选择做自己喜欢的事情。

　　虽然很多软件都会得益于共享和合作式的开发模型，但可能并非所有软件都会如此。我的一位朋友是自由软件项目的积极贡献者，但他对每年付费使用 税务软件毫无怨言，因为根据税法更新软件的研究成本足以使想要投身此类软件的志愿者敬而远之。在某种程度上即便是这些公司已经开始为个人提供免费 软件，但他们大都对真正意义的自由 软件望而却步。

　　防病毒软件供应商常常不愿分享其代码，他们有自己的理由;病毒制作者具有破译代码库的能力，当然不能让这些病毒制作者轻易得逞。

　　开发开放源码的派生物

　　开源倡导者之间也存在一个重要分歧，即该如何划分 GPL 方式的许可和 BSD 方式的许可。如果您基于此代码构建了一个新的项目，那么您也要在相同的许可条款下发布该项目么?

　　人们通常都会将此视为是一场宗教式的战争。我想这也是公说公有理婆说婆有理的一个典型例子，完全取决于个人的偏好。双方的支持者常常还会有些偏激并会做出一些不合理的争辩，但本质上，二者都是可行的策略。

　　您请便，我的工作到此为止了

　　BSD 方式的许可的理念(也为其他的几个许可所用)是生成软件的目标是制作它并让它可用，而其他人对此软件的使用都是额外的奖励。 如果某个开发者想要把这些代码嵌入到一个闭源的应用程序内并从中获利，且不回馈给社区，这种做法也是合理的，因为开发者也是在使用代码，而且这也是代码的 一个用途所在。

　　这种策略的支持者趋向于强调这种策略 “更为自由”，因为它对软件的使用者的限制更少。而批评者则大多会称这种策略有可能会让软件的变体最终演变成高度受限的软件。对 BSD 许可下的软件最常见的伪评判是认为有人会 “夺取” 这种许可所赋予的自由。但是，他们不能。BSD 许可下的原始软件总是存在的，可自由使用，而不管从其派生的项目是何状况。

　　共享即是关爱、分享

　　GPL 方式的许可的理念是著名的 “传染性” 许可;其目标不只是此软件应该是免费的，而且所有派生物也必须是同等程度免费的，所以不允许任何人使用此类软件作为非免费软件的一个组件。

　　此策略的支持者也趋向于强调该种许可 “更为自由”，因为它更能保证对这类软件及其派生软件的持续的自由和开放性。而反对者则多纠缠于这类软件无法用于为数不多(但却实际存在)的禁止为给定代 码段使用开源模型的情况。对 GPL 许可下的软件最常见的一种伪评判是这种许可的传染性如何如何厉害。有些人曾告诉过我，当然是很真诚的，如果允许人们利用我在更为宽松的许可下发布的代码并 将其链接到 GPL 许可下的代码，那么我就必须要将我的代码也变成是 GPL 许可的并且必须将类似的限制施加给所有其他的用户。这，很显然是无稽之谈。

　　GPL 的变体很多;而其中有些就是为了解答这类疑问的。

　　如何选择

　　我遇到过有关哪种方式的许可更为恰当的问题。上述两种方式对不同的场景有各自的优势。我总结了一些原则，可帮助我为某个项目决定适合的许可方案。

　　Linux 内核是从 GPL 许可获益良多的典型例子。依我看来，是共享进展中的开发工作的重要性使然。尤其是，如果没有 GPL，供应商就可以借助硬件驱动程序将使用者锁定到它们提供的内核，因为只有这个内核可以支持某个特定的硬件。有了 GPL，内核驱动程序必须能作为源向他人开放，允许他人将这些驱动程序用于其他内核，并在需要的时候做适当的调整。

　　X Windowing System 则在更少限制的 MIT 许可下发展得不错。尽管人们可以开发商业系统，但由于人们使用的是标准的服务器，所以事实是若硬件驱动程序不能用于标准的 X 服务器，那么肯定会影响硬件的销售。

　　在某些情况下，很难分辨哪种策略更为适合。BSD 内核的偏好者看起来能够坦然接受商业产品使用其内核而又不向其发回任何驱动程序的可能性(尽管 这种情况似乎非常少)。现在有一些协议或文件格式库是在 GPL 条款下发布的，且得到了一些使用。

　　如下的这些原则可帮助您做决定：

　　假设您已经发布了代码，您发现有人正在使用它。但您尚不知道他们是否会发送回更改，您只是听说他们之所以使用您的代码是因为您的代码可以正确解决他们的某个技术问题。

　　如果上述情形让您很高兴，那么您就可以使用两种许可中的任何一种来允许他们这么做。如果这种情形让您担心他们有可能不会共享，那么就使用一种许可来要求他们共享。如果这种情况让您很恼火，因为他们没有付费给您，那么就不要使用任何开源许可。放松些!