没有免费的（软件）午餐 -

2004年6月14日
第2卷，第3期

没有免费的（软件）午餐

Jay Michaelson，Wasabi Systems

每个开发者都应该了解的关于开源许可的知识

“大多数软件的许可旨在剥夺您分享和更改它的自由。相比之下，GNU 通用公共许可证旨在保证您分享和更改自由软件的自由，以确保软件对所有用户都是自由的。”1 GNU 通用公共许可证（GPL）就是这样开头的，它已成为使用最广泛的开源软件许可证。《自由》是口号——撰写 GPL 的组织名为自由软件基金会并非巧合——而且世界各地的开源开发者都在宣称：“信息渴望自由。”

正如 GPL 在两个段落后指出的那样，然而，“为了保护您的权利，我们需要做出限制，禁止任何人剥夺您的这些权利或要求您放弃这些权利。”2 正如大多数开源软件开发者所知，这意味着，实际上，GPL 实际上是“自由度”较低的软件许可证之一，因为它要求任何修改 GPL 许可程序的任何人，如果该程序“分发”给他人，则必须免费提供该程序的代码。

天塌下来了吗？

微软和其他专有软件业务的大型厂商几乎 постоянно 被指责散布大量关于这一特定要求的 FUD（恐惧、不确定性和怀疑）3。他们及其盟友甚至辩称，GPL 威胁国家安全。此外，有些人还声称 Linux 服务器的内容可能不受保护，并且他们警告说，除了天塌下来之外，什么都可能发生——而且一旦有人获得云的专利，他们可能会警告说云也会塌下来。

Linux 社区也做出了回应，并且为了完全公平地对待像微软这样的公司，也利用了一些大型用户的同样偏执的恐惧。例如，中国政府有一项使用 Linux 的官方政策，因为它认为微软软件是美国统治世界阴谋的一部分。4

所有这些混乱对开发者意味着，通常很难知道 GPL 是否会成为给定项目的一个因素。本文应有助于澄清情况。

现在，为了给您公平的警告，我本人并非完全客观，因为我恰好是 BSD（伯克利软件发行版）开发公司 Wasabi Systems 的创始人之一。我们的许多业务都基于帮助 OEM 将 NetBSD 嵌入到网络存储设备、互联网基础设施和其他嵌入式系统中。我们还广泛使用 GNU 工具，其中大多数工具都受 GPL 管辖。因此，您可能会说我是一个开源的拥护者，尽管可能不太算是 Linux 的拥护者。

开源许可证

以下是关于各种开源许可证的简要讨论：我们已经讨论过 GPL——它是使用最广泛的开源许可证。 GPL 的拥护者喜欢称其为“保护性许可证”，因为它确保受其约束的代码将永远保持开源。除了 GPL 之外，此类许可证还包括 Artistic License,5 LGPL（GNU 宽松通用公共许可证）v.2.1,6 IBM Public License v.1.0,7 Mozilla Public License v.1.0 和 v.1.1,8 Open Software License v.1.1,9 和 Sun Public License v.1.0.10

所有这些许可证都有细微的差异，并且还有大约十几个正在使用中。事实上，开源许可证是开源社区开发的一些最精细设计的产品。

BSD 许可证

BSD 许可证是第二大广泛使用的开源许可证。它与 GPL 最显着的区别在于它不要求任何东西都必须开源。如果您愿意，您可以获取整个 NetBSD 操作系统，更改一行代码，然后将整个系统变为专有的，并尝试将其作为 YourOS 出售。因此，BSD 的一个变体现在是第二大广泛使用的桌面计算机操作系统。苹果公司采用了 Mach、FreeBSD 和 NetBSD 的一部分，创建了 Darwin，然后将 Darwin 衍生为 Mac OS X。 OS X 的很大一部分现在是闭源软件，即使它们是基于 BSD 的。这就是 BSD 许可证的特点之一：它将是否分享的决定权留给了像史蒂夫·乔布斯和苹果公司的人。

与 BSD 许可证类似的还有 Academic Free License v.1.2,11 Apache Software License v.1.1,12 Artistic License（管辖 Perl）,13 Attribution Assurance License,14 BSD License,15 Sun Industry Standards Source License,16 University of Illinois/NCSA Open Source License,17 Vovida Software License v.1.0,18 W3C Software Notice and License,19 和 Zope Public License v.2.0.20 再次强调，还有其他许可证。

微软共享源代码

最近，微软一直在推广共享源代码软件,21 这一举动在某些人看来像是试图利用开源的潮流。共享源代码基本上意味着，符合条件的开发者和公司如果注册该计划，就可以访问某些微软软件的代码。到目前为止，由于共享源代码计划仍处于起步阶段，其开发者社区的命运尚无法预测。

免费——某种程度上

最后，还有一些软件许可证根本不共享代码。有些软件可能可以免费使用，但不能免费修改或剖析。当然，还有一些软件您必须付费才能使用，而且您永远看不到代码，就像我现在使用的文字处理器一样（Corel WordPerfect——我是一个死忠粉）。

哈佛法学院教授劳伦斯·莱西格，《代码和其他网络空间法律》一书的作者,22 微软反垄断案的仲裁员，以及“网络空间法律”的领先专家，指出，由于所有关于“自由软件”的言论，我们常常对开发者的权利和责任产生有偏见的看法。传统的矩阵看起来如表 1 所示。

从代码本身的视角来看，该矩阵是准确的。正如我们将看到的，GPL 确保代码将永远是自由的。然而，从开发者的角度来看，GPL 实际上施加了重要的限制。假设您是一名嵌入式系统开发者，并且您想采用 GPL 许可的软件，对其进行修改，并将其整合到您公司的产品中。如果该产品要出售（“分发”），您必须公开所有结果代码——包括您的修改。现在，GPL 不会影响可能与修改后的代码交互的其他应用程序，这就是为什么它在大多数桌面或服务器应用程序中实际上不会造成问题的原因。但在嵌入式领域（我最熟悉的领域），OEM 通常花费数十万美元来修改和定制操作系统内核本身或调整各种设备驱动程序。 GPL 限制了这些 OEM 执行他们想做的事情的能力，在大多数情况下，他们想做的事情是保守代码秘密。他们在开发方面投入了大量资金，并且他们宁愿不与竞争对手分享这些开发成果。

因此，从开发者的选择角度来看，矩阵实际上应该如表 2 所示。

自由及其约束

简而言之，促进最大代码自由的与促进最大开发者自由的并不相同。当信息最自由时，开发者可能受到最大的约束。

我现在可以听到 Linux 社区的呐喊了，所以请允许我承认他们主要担心的事：如果允许那些讨厌的公司拿走代码而不分享他们的修改，开源软件开发将会受到破坏。开源模式的前提是世界各地的开发者都在努力改进软件。如果开发者拿走他们的玩具回家，这种模式就行不通了。

从理论上讲，这很有道理。然而，在实践中，出现了一种更为复杂的情况。首先，许多 OEM 确实会分享他们的 BSD 许可的代码——有些是因为他们想成为好公民，另一些则是因为他们希望他们的代码能够被其他人不断更新和改进。他们可能只是不想立即这样做。像 Wasabi 这样的公司已被客户告知，实际上，要等待六个月，然后再发布所有内容，其理论是六个月足以领先于任何竞争对手。

其次，随着嵌入式和非嵌入式 Linux 公司努力寻找商业模式，Linux 本身正在碎片化。 BSD 许可证的最大担忧应该是“代码分支”：一些开发者会分拆出他们自己的 BSD 版本，社区会分崩离析。这在某种程度上发生了；今天至少有四种 BSD 风味正在使用。但是 Linux，与 BSD 不同，严格来说仅指 Linux 内核，并且有数十个版本的 Linux 具有不同的 TCP 堆栈、模块等。此外，在这里我们谈到了 GPL 最棘手的部分，虽然“衍生作品”（一个标准的版权术语）被要求采用 GPL 许可，但与 GPL 许可软件分离或“仅仅聚合”（一个 GPL 术语）的作品则不是。为了以某种方式从 Linux 赚钱，一些 Linux 公司创建了在内核启动后加载的大型模块，因此——他们说——不受 GPL 的约束。

GPL 豁免？

本文的其余大部分内容试图确定这是否属实，但请注意，从一开始，整个企业就与 GPL 许可的开源软件的理论前提背道而驰：我们都在这里从事同一个项目。要么 Linux 公司的添加是微不足道的，在这种情况下，他们的客户受到了不公平的待遇；要么它们是重要的，在这种情况下，他们并没有真正以公平的方式玩开源游戏。他们正在寻找漏洞。

我不会花太多时间在 SCO 最近提起的诉讼上，该诉讼声称 Linux 本身包含 Unix 代码（这是 SCO 的知识产权）的片段，因此所有 Linux 用户都需要从 SCO 购买许可证。这些主张已在媒体上广泛讨论，并且并没有真正解决开发者的问题：“好的，我有这段代码，我已经完成了这项工作——我的责任是什么？” 该诉讼与公司有关，公司现在有证据表明，如果涉及的资金足够多，Linux 的性质将招致贪婪的人代表他们提起诉讼；这也是对 BSD 的良好宣传，BSD 在 10 年前解决了其与 Unix 相关的问题。但仅此而已。

为了更充分地理解 GPL 的使用，查看使用场景并了解开发者在每种场景中的义务是有用的。我将再次关注熟悉的领域，即嵌入式领域。

假设您通过将其移植到新的硬件架构或改进 Linux 内核来修改 Linux 内核。然后，生成的软件被嵌入到商业设备中。简单的答案：生成的代码必须根据 GPL 发布。

通常，硬件驱动程序是内核的一部分，因此它们也必须根据 GPL 发布。然而，为了保护专有硬件驱动程序，TiVo 等著名的 Linux 用户已将其构建为内核启动后加载的可加载模块。他们对这些模块保密。 TiVo 的 Jim Barton 在的上一期中表示，“专有模块的使用...是 Linux 在嵌入式系统中使用的关键。”23

专有模块

但是专有模块是否合规呢？

这取决于您问谁。与 FSF 相关的人员表示否——但话又说回来，FSF 实际上并不拥有 Linux 内核的版权，因此它没有资格提起诉讼。嵌入式 Linux 行业的传统观点是 Linus Torvalds 曾表示专有模块是没问题的，但他实际上说的话更为微妙。24 根据 Torvalds 的说法，如果驱动程序是 Linux 内核的衍生作品（稍后会详细介绍），则无论何时启动，它都受 GPL 的约束。但是，他对“衍生作品”的定义比美国版权法25 更严格，因此他说，如果一个可加载模块最初是为不同的操作系统编写的，然后只是移植到 Linux 而没有进行重大重写，则它不受 GPL 的约束。由于 Torvalds 拥有版权——并且由于无论如何他不像 FSF 那样好诉讼或受意识形态驱动——专有模块可能是没问题的，不是因为它们超出了 GPL 的条款，而是因为 GPL 的主要执行者就 Linux 内核而言，到目前为止，他选择不起诉。

衍生作品

在没有法庭案例的情况下——GPL 从未在法庭上进行过检验——像我这样的律师只能提供理论，而不是事实。但在我看来，GPL 最合理的解释似乎是，依赖于程序（例如 Linux 内核）功能的设备驱动程序，其工作是让程序操作特定设备，是版权法下的“衍生作品”，而不是 GPL 下的“仅仅聚合”。 Torvalds 可能有更严格的定义，但我的解释是基于版权法，而不是基于我自己的世界观。

美国版权法下的典型“衍生作品”是翻译或录音。26 例如，您录制的 Phish 演唱会磁带是演唱会本身的衍生作品，因此 Phish 拥有其版权，即使您制作了磁带。但是，《版权法》补充说，“由编辑修订、注释、详细说明或其他修改组成的作品，作为一个整体，代表了原创的作者作品，是‘衍生作品’。”27 也就是说，即使“详细说明”和“注释”是原创的作者作品，它们也是原始产品的衍生作品。

请注意，《版权法》并不关心衍生作品是否是原始作品的“一部分”。您的 Phish 演唱会磁带当然是在演唱会结束后很久才“加载”的——也就是说，当您将其放入汽车音响时——但它仍然是衍生作品。另一方面，仅仅提及另一部作品是不够的。还记得最近关于《飘都飘了》的法庭案例吗,28 这是从奴隶的角度对玛格丽特·米切尔的《飘》29 的重述？该重述的作者爱丽丝·兰德尔胜诉，因为法院裁定它实际上是一部全新的作品，而不仅仅是详细说明或注释。但对于仅仅扩展程序的功能或使其能够操作新硬件的设备驱动程序或其他可加载模块来说，情况真的是这样吗？

根据我在版权法方面的经验，我认为设备驱动程序，无论何时何地加载，不仅是操作系统内核的衍生作品，而且可能是它们“详细说明”的其他模块的衍生作品。但事实是，我们真的不知道，双方都有合理的论点。有些人认为，GPL 作为一个整体甚至不可执行；当然，也发生过一些公司只是无视他们在 GPL 下的责任，保守代码秘密，并且不告诉任何人。我认为 FSF 正确地称之为盗窃：通过不遵守 GPL，这些人正在盗窃他们根据 GPL 获得的代码。归根结底，不幸的现实是，开发者在继续进行任何与 GPL 相关的开发之前，应咨询其公司的法律部门，因为具体要求可能因个案而异。

应该清楚的是，在提出这些担忧时，我们仍然与前面提到的 FUD 相去甚远。在 GNU/Linux 操作系统之上运行的应用程序显然不是它的衍生作品；存储在上面的数据也不是。只有在创建基于或修改 Linux 内核或其他 GPL 许可软件的作品时，这些问题才会出现。

终止

开发者要记住的一个重要事实是，根据 GPL 的条款，任何违规行为的后果都是终止许可证——没有其他可用的补救措施。这意味着，如果您分发了本应向公众发布的软件，那么您就是在非法分发该软件。 FSF、Linus Torvalds 和所有其他版权所有者都拥有您正在使用的“自由”软件的版权——正如理查德·斯托尔曼所说，它不是“免费”的，就像免费啤酒一样。30 因此，如果您在没有许可证的情况下分发他们的软件，因为您的 GPL 因您的违规行为而终止，您可能会受到禁令救济（即，法院命令停止销售带有该软件的产品）、补偿性损害赔偿——甚至惩罚性损害赔偿。

人们倾向于认为 Linux 和其他开源软件是免费且无主的，但事实并非如此。它归创建它的人所有——并且允许您根据许可证的条款使用和分发它。

宽松 GPL

我们还应该注意到 LGPL（宽松 GPL，以前是库 GPL，但后来更改了名称，因为 FSF 认为它被库过度使用了）。在某种程度上，LGPL 的存在本身就证明了一些 Linux 反对者喜欢声称的东西：由于《版权法》对“衍生作品”的定义，GPL 可以说是“病毒式”的，并且可以“感染”除直接受其管辖的软件包之外的其他应用程序。 LGPL 的创建者（包括——完全披露——Wasabi 的董事会主席 David Henkel-Wallace）担心的原因是，使用动态链接库的应用程序可能被视为“衍生作品”，从而被 GPL 许可证“感染”。因此，LGPL 排除了 GPL 的要求，因为它适用于使用库的应用程序。它明确指出，与库一起使用的应用程序“不是库的衍生作品，因此不属于本许可证的范围”。

虽然 LGPL 的构建相当狭隘，但 FSF 认为它被过度使用了，并且一直在努力让库受 GPL 管辖。（GNU 网站解释说，通过对越来越多的 GNU 库进行 GPL 许可，它希望为自由软件用户提供比专有用户更多的优势。）因此，开发者需要密切关注他们正在使用哪些库以及哪些许可证。

事实上，关于 LGPL 最有趣的一点可能是它对 GPL 的说明：FSF 非常清楚美国版权法下的“衍生作品”是什么，并且一些专有 Linux 商店的回避策略非常非常不稳定。如果一个对 Linux 整体成功怀有敌意的政党试图对世界上的 TiVo 执行 GPL——好吧，让我们只说他们的胜算会比 SCO 更大。

当然，使用 BSD 许可证及其类型的许可证，就不会出现上述任何问题。如果您想保留某些东西的专有性，您可以做到。就这样。

这里的真正问题是，人们试图以与 FSF 的意识形态意图直接相反的方式使用 FSF 的创造物。这将导致麻烦，并且已经发生了。 TiVo 可能看起来像一家硬件公司，但正如 Barton 在前面提到的文章中写道,31 其大部分 IP（知识产权）实际上都在其软件中。一家专有软件公司在使用“自由软件基金会”的许可证时遇到法律问题，这有什么奇怪的吗？

法律要素

以我的经验，通常发生的情况是，开发者继续他们的业务，并尽量不让法律介入。法律部门，就其本身而言，通常不了解开源许可证的要求以及违反这些要求的潜在后果——特别是大型公司的法律部门，对于这些公司而言，软件开发可能只是一个小小的副业。结果是一种幸福的无知。如果律师们知道他们将要涉足什么，他们和公司工程师都会非常不高兴。但现在的情况是，开发者尽量不担心法律，而律师们又不够了解情况，不足以担心开发者。

就像针对最低共同分母的党派政治广告一样，微软等公司的广泛抨击吓坏了管理层——即使它们在许多开发者看来是胡说八道。

BSD 还是 GPL？

我自己的、无可否认带有偏见的经验——为数十家将 BSD 嵌入其产品的 OEM 起草合同，以及广泛使用 GPL——是 BSD 许可证比 GPL 更适合许多商业应用程序，尤其是在嵌入式领域。例如，Wasabi 创建了一套基于 NetBSD 的存储产品，没有任何嵌入式 Linux 工作中常见的那些不确定性或寻找漏洞的行为。因为它让开发者可以随意处理代码，所以在这种情况下，BSD 许可证对业务更有利。

现在，这对一般的开源开发是更好还是更坏呢？我不确定。在 Wasabi，我们定期将代码贡献回 NetBSD 项目，并且我们还通过其他方式支持 NetBSD——从我自己的法律工作到资助我们的开发者从事特定于 NetBSD 的项目。我们发现，我们的 OEM 客户希望保密的特定于硬件的定制和优化，恰恰是那些对整个 NetBSD 最不感兴趣的部分。并非总是如此——但大多数时候是这样。

我也广泛使用 GPL 许可的软件，并且由于我以前的经验，我已成为比大多数软件开发者更专横的总法律顾问。由于 Wasabi 和 NetBSD 项目都发生过“GPL 蔓延”的情况，因为越来越多的代码落入许可证的范围，我现在建议（甚至坚持）所有参与修改和分发 GPL 许可软件的公司在开发开始之前以及在代码发布给公众或在产品中分发之前获得法律审查。

您可能会问，“GPL 的目的是为律师提供工作吗？” 不，只是现在看起来是这样——目前是这样。

案例研究：Apache 许可证 2.0 和 GPL

最近，关于新的 Apache 许可证 2.0 和 GPL（GNU 通用公共许可证）之间据称不兼容的问题，一场风波正在酝酿之中。争议围绕 Apache 许可证的专利许可条款，通过该条款，每位 Apache 贡献者都授予用户使用任何属于该许可证范围内的专利软件的许可——作为交换，用户同意不提起任何与专利相关的诉讼。一个重要的点（至少对于争议而言）是，Apache 许可证会在任何违反此限制的情况下终止。 GPL 也有类似的条款，但没有终止条款。

这个小小的差异导致 FSF（自由软件基金会）宣布 Apache 许可证与 GPL“不兼容”，因为 GPL 的基本原则之一是，根据 GPL 分发的软件不能受到进一步的限制。正如 Apache.org 网站所声明的那样，很难想象这种差异真正重要的场景，特别是考虑到 GPL 自身的终止条款。然而，“进一步的限制”就是进一步的限制，FSF 不建议使用 Apache 许可证——GPL 许可的软件也不能受其约束地分发。

这场争议表明，有时，软件开发者在使用不同的开源许可证时需要像律师一样思考。据推测，没有人希望事情会变成这样。但许可证撰写者是一群党派人士，GPL 不允许偏离其条款。许可人当心。

资源

Apache 软件基金会

https://apache.ac.cn

Apache 许可证 v2.0 和 GPL 兼容性

https://apache.ac.cn/licenses/GPL-compatibility.html

GNU 项目

https://gnu.ac.cn/

参考文献

1. 有关 GPL 的更多信息，请访问 GNU 网站； https://gnu.ac.cn/。

2. 参见参考文献 1。

3. 参见：http://en.wikipedia.org/wiki/FUD； http://info.astrian.net/jargon/terms/f/FUD.html。

4. Smith, C. S. 担心被微软控制，中国支持 Linux 系统。《纽约时报》，2000 年 7 月 7 日； http://www.nytimes.com/library/tech/00/07/biztech/articles/08soft.html。

5. Artistic License：参见 https://perldotcom.perl5.cn/pub/a/language/misc/Artistic.html。

6. GNU 宽松通用公共许可证：参见 http://gnu.org/copyleft/lesser.html。

7. IBM 公共许可证：参见 https://open-source.org.cn/licenses/ibmpl.php； http://www-124.ibm.com/developerworks/oss/CPLv1.0.htm。

8. Mozilla 公共许可证：参见 http://www.mozilla.org/MPL/MPL-1.1.html； https://open-source.org.cn/licenses/mozilla1.0.php。

9. Open Software License：参见 https://open-source.org.cn/licenses/osl-1.1.txt。

10. Sun Public License：参见 http://www.netbeans.org/about/legal/license.html。

11. Academic Free License：参见 https://open-source.org.cn/licenses/academic.php。

12. Apache Software License：参见 https://apache.ac.cn/LICENSE.txt。

13. 参见参考文献 5。

14. Attribution Assurance License：参见 https://open-source.org.cn/licenses/attribution.php。

15. BSD License：参见 https://open-source.org.cn/licenses/bsd-license.php。

16. Sun Industry Standards Source License：参见 http://www.openoffice.org/licenses/sissl_license.html。

17. University of Illinois/NCSA Open Source License：参见 http://uilib-oai.sourceforge.net/license.html。

18. Vovida Software License：参见 http://www.vovida.org/About/license.html。

19. W3C Software Notice and License：参见 http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231。

20. Zope Public License：参见 http://cmf.zope.org/download/CMF-1.2beta2/LICENSE.txt。

21. Shared Source：参见 http://www.microsoft.com/resources/sharedsource/default.mspx。

22. Lessig, L. 《代码和其他网络空间法律》。 Basic Books，纽约：NY，2000 年。

23. Barton, J. “从服务器机房到起居室。” 1,5 (2003 年 7 月/8 月)，20-32 页。

24. Linus Torvalds 电子邮件：参见 http://lkml.org/lkml/2003/12/3/228。

25. 美国版权法：参见 http://www.copyright.gov/title17/92chap1.html。

26. 美国版权法，第 103 条，版权的主题：汇编作品和衍生作品：参见 http://www.copyright.gov/title17/92chap1.html#103。

27. 参见参考文献 26。

28. Randall, A. 《飘都飘了》。 Houghton Mifflin，波士顿：MA，2001 年。

29. Mitchell, M. 《飘》。 Macmillan，纽约：NY，1936 年。

30. Williams, S. 《自由自在》。 O’Reilly，塞瓦斯托波尔，CA，2002 年； http://www.oreilly.com/openbook/freedom/ch09.html。

31. 参见参考文献 23。

喜欢还是讨厌？让我们知道

[email protected] 或 www.acmqueue.com/forums

JAY MICHAELSON 于 2000 年共同创立了 Wasabi Systems，这是一家基于 BSD 的软件公司，也是 iSCSI 存储软件工具的领先供应商。 Michaelson 目前担任该公司的副总裁兼总法律顾问，是技术领域知识产权问题的著名专家。他拥有耶鲁法学院的法学博士学位（在那里他参加了劳伦斯·莱西格的著作《代码》中不朽的网络空间法律课程），他的作品已发表在《耶鲁法律杂志》、《杜克法律评论》和其他法律期刊上。他于 1981 年用 Basic 语言编写了他的第一个程序。它不受 GPL 的约束。

最初发表于 Queue 第 2 卷，第 3 期—
在数字图书馆中评论本文

更多相关文章

Amanda Casari, Julia Ferraioli, Juniper Lovato - 超越代码仓库
关于开源的大量现有研究选择研究软件仓库而不是生态系统。开源仓库通常指的是版本控制系统中记录的工件，偶尔包括围绕仓库本身的交互。开源生态系统指的是仓库、社区、他们的交互、激励、行为规范和文化的集合。开源的分散性质使得对生态系统进行整体分析成为一项艰巨的任务，社区和身份以有机和不断发展的方式交叉。尽管存在这些复杂性，但对软件安全和供应链日益严格的审查使得在进行关于开源的研究时，采取基于生态系统的方法至关重要。

Guenever Aldrich, Danny Tsang, Jason McKenney - 为那些还不理解的项目经理提供的三部和声
本文研究了系统采购工具箱中的三种工具，这些工具可以加速开发和采购，同时降低程序风险：OSS、开放标准和 Agile/Scrum 软件开发流程都是国防部采购项目管理工具箱的强大补充。

Jessie Frazelle - 开源固件
开源固件可以通过使固件的行为更加可见且不太可能造成危害，从而帮助将计算带到一个更安全的地方。本文的目标是让读者感到有能力向可以帮助推动这一变革的供应商提出更多要求。

Marshall Kirk McKusick, George V. Neville-Neil - FreeBSD 5.2 中的线程调度
繁忙的系统每秒会做出数千个调度决策，因此做出调度决策的速度对于系统的整体性能至关重要。本文——摘自即将出版的书籍《FreeBSD 操作系统设计与实现》——使用开源 FreeBSD 系统为例，帮助我们理解线程调度。最初的 FreeBSD 调度器是在 20 世纪 80 年代为大型单处理器系统设计的。尽管它在今天的环境中仍然运行良好，但新的 ULE 调度器是专门为优化多处理器和多线程环境而设计的。本文首先研究了最初的 FreeBSD 调度器，然后描述了新的 ULE 调度器。