我最近遇到的针对开源软件和社区的批评是开源永远不会胜出；专有和封闭源码(closed-source)软件永远都会存在。事实尽管如此，但这并不是开源的失败使然。
那些认为相互竞争的模型、方法或项目的存在就是一种 “失败” 的论调与开源的整个理念恰好背道而驰。自由重点之一就是人们可以选择做自己喜欢的事情。
虽然很多软件都会得益于共享和合作式的开发模型，但可能并非所有软件都会如此。我的一位朋友是自由软件项目的积极贡献者，但他对每年付费使用税务软件毫无怨言，因为根据税法更新软件的研究成本足以使想要投身此类软件的志愿者敬而远之。在某种程度上即便是这些公司已经开始为个人提供免费 软件，但他们大都对真正意义的自由 软件望而却步。
防病毒软件供应商常常不愿分享其代码，他们有自己的理由；病毒制作者具有破译代码库的能力，当然不能让这些病毒制作者轻易得逞。
开发开放源码的派生物
开源倡导者之间也存在一个重要分歧，即该如何划分 GPL 方式的许可和 BSD 方式的许可。如果您基于此代码构建了一个新的项目，那么您也要在相同的许可条款下发布该项目么?
人们通常都会将此视为是一场宗教式的战争。我想这也是公说公有理婆说婆有理的一个典型例子，完全取决于个人的偏好。双方的支持者常常还会有些偏激并会做出一些不合理的争辩，但本质上，二者都是可行的策略。
您请便，我的工作到此为止了
BSD 方式的许可的理念(也为其他的几个许可所用)是生成软件的目标是制作它并让它可用，而其他人对此软件的使用都是额外的奖励。 如果某个开发者想要把这些代码嵌入到一个闭源的应用程序内并从中获利，且不回馈给社区，这种做法也是合理的，因为开发者也是在使用代码，而且这也是代码的一个用途所在。
这种策略的支持者趋向于强调这种策略 “更为自由”，因为它对软件的使用者的限制更少。而批评者则大多会称这种策略有可能会让软件的变体最终演变成高度受限的软件。对 BSD 许可下的软件最常见的伪评判是认为有人会 “夺取” 这种许可所赋予的自由。但是，他们不能。BSD 许可下的原始软件总是存在的，可自由使用，而不管从其派生的项目是何状况。
共享即是关爱、分享
GPL 方式的许可的理念是著名的 “传染性” 许可；其目标不只是此软件应该是免费的，而且所有派生物也必须是同等程度免费的，所以不允许任何人使用此类软件作为非免费软件的一个组件。
此策略的支持者也趋向于强调该种许可 “更为自由”，因为它更能保证对这类软件及其派生软件的持续的自由和开放性。而反对者则多纠缠于这类软件无法用于为数不多(但却实际存在)的禁止为给定代码段使用开源模型的情况。对 GPL 许可下的软件最常见的一种伪评判是这种许可的传染性如何如何厉害。有些人曾告诉过我，当然是很真诚的，如果允许人们利用我在更为宽松的许可下发布的代码并将其链接到 GPL 许可下的代码，那么我就必须要将我的代码也变成是 GPL 许可的并且必须将类似的限制施加给所有其他的用户。这，很显然是无稽之谈。
GPL 的变体很多；而其中有些就是为了解答这类疑问的。
如何选择
我遇到过有关哪种方式的许可更为恰当的问题。上述两种方式对不同的场景有各自的优势。我总结了一些原则，可帮助我为某个项目决定适合的许可方案。
Linux 内核是从 GPL 许可获益良多的典型例子。依我看来，是共享进展中的开发工作的重要性使然。尤其是，如果没有 GPL，供应商就可以借助硬件驱动程序将使用者锁定到它们提供的内核，因为只有这个内核可以支持某个特定的硬件。有了 GPL，内核驱动程序必须能作为源向他人开放，允许他人将这些驱动程序用于其他内核，并在需要的时候做适当的调整。
X Windowing System 则在更少限制的 MIT 许可下发展得不错。尽管人们可以开发商业系统，但由于人们使用的是标准的服务器，所以事实是若硬件驱动程序不能用于标准的 X 服务器，那么肯定会影响硬件的销售。
在某些情况下，很难分辨哪种策略更为适合。BSD 内核的偏好者看起来能够坦然接受商业产品使用其内核而又不向其发回任何驱动程序的可能性(尽管 这种情况似乎非常少)。现在有一些协议或文件格式库是在 GPL 条款下发布的，且得到了一些使用。
如下的这些原则可帮助您做决定：
假设您已经发布了代码，您发现有人正在使用它。但您尚不知道他们是否会发送回更改，您只是听说他们之所以使用您的代码是因为您的代码可以正确解决他们的某个技术问题。
如果上述情形让您很高兴，那么您就可以使用两种许可中的任何一种来允许他们这么做。如果这种情形让您担心他们有可能不会共享，那么就使用一种许可来要求他们共享。如果这种情况让您很恼火，因为他们没有付费给您，那么就不要使用任何开源许可。放松些!
开源和 DRM
Digital Rights Management (DRM) 备受争议，因它不合理地限制了付费用户的权利。但是也有一些情况例外。我曾经使用过 GNU Compiler Collection (GCC) 的修订版，内含了一个对许可管理器的调用。这看起来可能有点奇怪;但显然，它是一个客户请求。客户拥有一组使用了 GCC 的工具的开发者许可，但由于某种原因，对于他们，如果 GCC 能够进行某些许可检查，那么他们将能很容易地跟踪许可使用情况。所以，这些工具使用的 GCC 版本被合理地修改成调用一个外部的许可检查程序。(默认地，它自带总是能立即返回成功结果的外部程序;实际的许可检查是可选的，并且必须被显式启用。)
令人开心的是：由于 GCC 使用的是 GPL 许可，它自带了全部源代码，分为上游版本和供应商补丁。因此，调用许可管理器的代码已经在补丁里了，如果用户愿意，可以删除它，重新构建。
这会创建一个有趣的替代。任那些想要跟踪它的人自愿使用的许可是存在的，但却不适合您。开源模型帮助抵制了诸如构建用 rootkit 来隐匿 DRM 软件这样的荒唐事的诱惑。(后者就是我为何现在只购买无 DRM 的游戏的原因。我厌烦了虽付了钱，程序却还是最终跨掉的情况，而有人下载了它不怎么样的拷贝却仍能顺利运行。)
与专有软件共存
专有软件的继续存在对于很多开源支持者而言无疑是一个痛心的话题。我有时也会介意某些包是闭源的，尤其是当这些包不能正常工作，而其供应商又毫不在乎时，就更是如此。不过，总的来说，专有软件的存在，我是不介意的，而且，如果闭源软件物有所值，我甚至还会购买。
双方都需要接受共存的事实。(您可能已经注意到在涉及不止一个人的人类存在的每个方面，这句话几乎无一例外都是适用的。 ) 推崇开源解决方案的很多人对于那些制作并致力于开源而又与闭源供应商合作的实体过于敌对。同样地，一些对闭源市场十分积极的供应商对开源也心怀敌意。双方的阵营中各有一些人积极地助推了对对方的恐惧、怀疑和不信任。
事实是很多闭源供应商并不那么地邪恶或恶毒，也并不故意要隐藏 rootkit，他们只不过是在试图借助自己的所知所能谋生而已。同样地，很多开源提供者也并非是要肆意破坏所有的物权，也不是要把对手置于死地;他们只是想要追求一种基于真实成本而非人工成本的理想国。
两个模型都是可以工作的，至少在某些程度上是可以的；人们可以参加进来，借此盈利，保住职位以及提供好的股东价值。若二者能够合作，我们将能获得双方更好的产品和服务。
Linux 桌面之年
“下一年” 将是 “Linux 桌面系统之年” 的说法有些过时。Linux 桌面系统时代尚未真正到来，但它还是超出某些人的想象，离我们更近了。
平心而论，在大型的零售卖场，仍看不到很多运行 Linux 的一般用途的计算机在售。但的确可以看到几个本质上构建于开源之上的运行内核和用户空间环境的计算机，并且几乎每个东西都包括了至少几个这类组件。离 Linux 在大众市场真正流行还有一段距离。如果说 10 年前，这仅仅是因为 Linux 桌面环境不那么好用，特别是对于终端用户而言。那么现在，更要紧的是熟悉度和网络效应，比如某些软件包不支持 Linux。
自愿开发工作往往关注的是开发人员的需要。这也是为何开源在编程工具方面做得很好，而桌面和用户界面则总是被置后考虑。不过，现在，在为 Linux 桌面提供好的用户界面的工作上已经有实际的资金支持了，并且效果已经开始显现。我并不期望着会出现排他的、纯粹的 “Linux 桌面系统时代”。我期望的是，随着时间的推移，使用 Linux 作为桌面环境的用户会有所增加，并且软件开发人员也会开始更为积极地针对于 Linux。我亦期望网络效应能从压制技术上的转换迅速转变为加速技术上的转换。
尽管如此，我仍坚持我自己的信念：就采用开源而言，其意义并不那么显著。要紧的是开源现在到处皆是，从烤面包机到火星登陆器，运行在各种设备上，从电话到电视机。
在很多方面，软件已经完成了 “后萧条” 经济的转变。前面还有很长的路要走，但当下，您起码能构建一个硬件并有信心别人能够免费获得开发其上功能所需的基本软件。这在以前是不可想象的遥远的梦想;但现在它是一个那么司空见惯并习以为常的事实。
原文：http://www.ibm.com/developerworks/cn/opensource/os-changeworld3/index.html
【编辑推荐】
