定义：

开源软件（OSS）是一种商业软件，只需同意遵守附带的 OSS 许可证即可获得全部所有权，无需立即进行第三方验证。同意 OSS 许可证允许个人、公司或政府实体根据需要尽可能频繁和广泛地复制、分发和运行 OSS 应用程序，以获取其人类可读的源代码，并根据不同的发布要求license to license，以扩展或扩展 OSS 应用程序。OSS 的付款是间接的，在大多数情况下，包括同意以应用程序修复和扩展的形式与维护应用程序的社区分享价值。

关键词：

FOSS、自由开源软件、开源软件、OSS

MITRE SE 角色和期望：

MITRE 系统工程师 (SE) 应了解将开源软件 (OSS) 和相关支持流程应用于大型系统的构建和系统系统的潜在好处、风险和限制。为了确保遵守要求选择和使用适用商业软件而不是新开发的联邦法规，他们应该了解 OSS 功能如何以及在何处应用于系统集成、最终用户支持和可配置性。他们应该了解 OSS 在采购成本、长期支持、可扩展性、适应性、安全性和面对不断变化的需求时的弹性方面与其他形式的商业软件相比如何。SE 应该特别了解 OSS 在工程和流程级别的安全属性，以及这些属性与其他类型的商业和政府软件的比较。他们应该了解主要 OSS 包的认证状态，以及认证在 OSS 的分布式所有权模型中是如何工作的。他们应该了解如何与 OSS 支持社区成功且富有成效地进行互动，这些支持社区使用基于易货的经济，其中以软件修复和应用程序功能扩展而不是费用的方式进行支付。

背景

在系统工程的软件工程领域和工程信息密集型企业中，很少有主题比开源软件更容易引起更强烈的反应。这种反应主要源于基于社区的 OSS 所有权模型，在该模型中，任何同意遵循相关 OSS 许可证的人都将获得与任何其他用户相同的所有权。这种工程变更权威的分散违反了软件工程最古老和最根深蒂固的假设之一：只有当软件是使用控制良好、以权威为中心的顶级软件开发时，高质量、高可靠性、可信赖的软件才有可能-向下发展过程。OSS 不仅放弃了对集中式开发机构的需求，而且通过将开发过程的控制权交给编码人员松散的协作，从而颠覆了这一概念。因为在软件工程中，编码人员通常被视为最不可能理解需求并且最有可能违反旨在确保系统完整性、质量、可维护性和安全性的规则的参与者，因此将变更控制权交给编码人员的过程也就不足为奇了。往往被不信任地看待。

然而，这种观点正在改变。第一个原因是人们越来越认识到，正如计划市场经济在鼓励创新和有效利用资源方面无法与自由市场经济竞争一样，对大型软件开发工作的严格集中管理比鼓励本地创新和适应。 OSS 鼓励这种本地创新，而且使本地创新的人类可读结果易于用于任何所需级别的检查和分析。

另一个原因是务实的。 OSS 的使用在私人和政府系统中都很普遍，并且已经使用了很多年 [1]。最初使 Internet 成为可能的通信软件 (TCP/IP) 是 OSS，许多提供有用数据的早期服务器系统也是如此。微软是众多广泛使用开源软件来构建和扩展其产品线的商业公司之一。Internet Explorer 是一个著名的 Microsoft 实用程序示例，它主要基于 OSS。基本上所有现代 Apple 产品，从 Mac 到 iPod 和 iPhone，都建立在 OSS 之上，顶部有一层薄薄的定制软件。谷歌是另一个在内部和商业产品中大量使用 OSS 的行业领导者。苹果和谷歌也是很好的例子，说明如何有效地使用 OSS 可以使成本高昂的设计人员不专注于维护旧代码，而是专注于开发全新的功能，从而实现更多更快的创新。最后，当今公开市场上销售的几乎所有网络设备和定制硬件盒大多或完全使用 OSS 构建。OSS 因其低成本、易于扩展、灵活适应新环境、广泛的可用功能以及经过现场验证的可靠性而受到设备供应商的欢迎。

政府利益和使用

2009 年 10 月 16 日，美国国防部 (DoD) 发布了关于使用开源软件 (OSS) [2, 3] 的更新政策。该政策强调并解释了 OSS 作为一种商业软件形式的法律地位，这意味着它符合美国法律 (10 USC 2377)，即购买商业项目的优先权。在审查降低成本和提高国防部系统质量的商业选项时，不包括对 OSS 选项的评估可能会无意中违反该法律。白宫开发者网站 [4] 将软件开发者引导至 GitHub 上的白宫项目（分布式开源开发）[5] 和Drupal（开源博客）网站 [6, 7]。

最佳实践和经验教训

• 阅读并理解美国国防部关于免费和开源软件 (FOSS) [8] 的网页。美国国防部花费数年时间创建了三份文件，分析和阐述了 OSS 在 DoD 系统中的作用。该网站涉及 DoD 对开源的政策、关于开源的联邦角色和法律地位的常见问题，以及早在 2003 年就 OSS 对 DoD 的广泛流行和重要性的调查。该网页是通用编写的，适用于其他联邦部门和机构几乎没有变化。与 DoD 合作的 MITRE 系统软件工程师尤其应该确保他们已经查看了 2009 年 10 月 16 日在站点上发布的 DoD 政策声明。
  
• 支持 OSS 的社区越大，长期支持成本的降低就越多。这种经验法则是 OSS 在构建大型系统时如何提供显着成本和能力优势的核心。值得注意的是，它与修改代码本身的能力无关，事实上很容易被一个对修改 OSS 源代码感兴趣的不成熟的项目严重破坏。由于 OSS 支持像一个联盟一样工作，当联盟规模尽可能大时，它对单个成员的成本收益最高。如果 OSS 支持社区足够大，可以将特定 OSS 功能方面的世界级专家包括在内，这些成本收益会进一步增加，因为这些成员通常可以在更广泛的支持所需的一小部分时间内解决难题。
  
• 避免激增 OSS 许可证。 OSS 许可证已经太多了。无论组织创建自己独特的 OSS 许可证多么诱人，每个许可证只会进一步混淆必须处理它的开发人员、律师和项目经理，并且还倾向于细分可用于支持此类新许可证的开发人员池。四种主要的许可证类型通常就足够了：
  

• GNU1 通用公共许可证 (GPL)：这个流行的许可证要求使用 GPL 源代码制作的任何新源代码本身必须以 GPL 许可；也就是说，它必须回馈给创建第一个源代码的 OSS 社区。尽管此功能使 GPL 引起争议，但它也非常擅长稳定系统或网络的深层基础设施，因为它消除了任意更改它的任何利润动机。Linux 内核部分是使用 GPL 许可证创建的，它展示了 GPL 的另一个特性：可以使用 GPL 组件的标准接口，而无需使用 GPL 的软件。
  
• GNU Lesser General Public License (LGPL)：这是 GPL 的一个变体，它允许 GPL 组件作为“库组件”嵌入到非 GPL 代码中。它在喜欢 GPL 模型但不想阻止企业使用或购买其软件组件的小公司中很受欢迎。
  
• Berkeley Software Distribution (BSD)/Apache：这些宽容的许可证允许公司“捕获”源代码的副本，并将这些副本以及他们对它们所做的任何更改视为专有。Apple 已利用 BSD 许可证的这一特性来创建其当前的 Mac 个人计算机、iPod 和 iPhone 产品线。由于单独维护大量源代码的成本很高，大多数 BSD/Apache 许可证的参与者继续在社区模式下支持他们的 OSS 产品。对于系统工程师来说，BSD 和 Apache 许可证应被视为确保参与大型系统系统工作的小型企业将有强烈的成本激励来适应 BSD 或 Apache 许可证下提供的 OSS 功能的工具。例如，为 Internet 通信软件 (TCP/IP) 的初始版本选择类似 BSD 的许可模型有助于使具有独特网络的数十家小型和大型企业接受代码并启动第一个工作 Internet。
  
• 无许可证（政府代码）：这是政府雇员开发的代码的法律要求状态。虽然通过允许任何人使用它来近似 BSD 或 Apache 许可证，但如果个人或公司选择“按原样”对整个作品进行版权保护而不承认其政府来源，则会引起相当大的混乱。
  

• 不要假设所涉及的律师会理解 OSS 许可证。对软件不甚了解的律师，更具体地说，不熟悉软件如何从可读源代码转换为可执行机器代码的律师，即使阅读 GPL 许可和 LGPL 许可，也很难理解，更不用说理解它们了。BSD 和 Apache 许可证避免了软件结构的细节，并且更容易让律师理解。通常，律师偏爱 BSD 和 Apache 仅出于这个原因：他们了解它们。这种不幸的情况正在慢慢改善，但在 GPL 和 LGPL 的情况下，程序员仍然经常比负责评估其含义的律师更了解这些许可证的含义和含义。社会企业应该意识到这种可能的脱节，如果可能的话，请律师参考相关文件，例如 DoD FOSS 网站 [3] 上的常见问题解答 (FAQ)。
  
• 使用 OSS 稳定共享基础设施。此处的基础设施是指建立网络和数据共享等基本功能的大型系统或系统系统的软件组件。正如所有系统基础设施项目中最成功的互联网项目的历史所证明的那样，使用 OSS 来鼓励共享基本能力可以成为一个强大的工具，以促进更复杂且经常出乎意料的新能力的出现。基础设施。OSS 还可以通过消除公司任意更改功能或将客户锁定到独特功能集的利润激励来帮助稳定大型系统。最后，由于基础设施通常是最不具有创新性的代码，因此使用 OSS 可以释放智力资源来进行更具创新性的新设计工作。
  
• 使用 OSS 帮助将昂贵的资源集中在创新上。从大型系统中分解出“已解决”的问题并将其移入 OSS 的最终结果如图 1 中的金字塔状结构所示。该图的主要概念是通过分解出稳定、变化相对缓慢且良好的能力在 OSS 社区的支持下，组织可以从支持角色中拉出急需的设计师和编码人员。他们可以将他们调到更具创新性的职位，专注于组织最关键的需求，通常利用 OSS 的许多原型设计和探索性功能（见下两个条目）。
  

Figure 1. The I-4 Architecture Pyramid

• 鼓励使用 OSS 联络职位。 OSS 联络员是技术熟练的程序员，其任务是跟踪、参与和使用相关的 OSS 应用程序套件。经验丰富的 OSS 联络员既有助于确保组织的需求得到其支持社区的理解和支持，又能就 OSS 功能的组合是否以及如何满足或支持已确定的系统级需求提供快速可用的内部建议。OSS 联络职位在标准软件工程职位描述方面是非标准的，但它们提供了最有效的方法之一，以确保广泛的需求最终不会被不恰当地转化为长期的软件开发项目，充其量是仅复制通过 OSS 已经可用的功能。
  
• 了解 OSS 在探索性原型设计方面的优势。由于 OSS 成为强大的探索性原型工具的许多相同原因，它还提供了一种强大的方法来处理典型的大型和复杂系统工程问题的集成问题。OSS 包括专门设计的包和语言，用于帮助在不同且经常出乎意料的数据和通信协议类型之间进行转换。对于大型复杂系统，此类支持翻译的 OSS 工具最重要的优势之一是它们可用于帮助模拟此类系统的较旧和过时组件所期望的输入和交互。由于更改此类旧组件通常既昂贵又具有高风险，因此能够为旧系统构建此类“软”接口，同时在系统的其余部分中保持当前协议和标准，对于最大限度地降低整体风险水平非常有价值到项目。
  
• 了解 OSS 在系统和系统集成方面的优势。由于 OSS 成为强大的探索性原型工具的许多相同原因，它还提供了一种强大的方法来处理典型的大型和复杂系统工程问题的集成问题。OSS 包括专门设计的包和语言，用于帮助在不同且经常出乎意料的数据和通信协议类型之间进行转换。对于大型复杂系统，此类支持翻译的 OSS 工具最重要的优势之一是它们可用于帮助模拟此类系统的较旧和过时组件所期望的输入和交互。由于更改此类旧组件通常既昂贵又具有高风险，因此能够为旧系统构建此类“软”接口，同时在系统的其余部分中保持当前协议和标准对于最小化整体水平非常有价值项目的风险。
  
• 像对待任何其他专有许可证一样对待 OSS 许可证。大型联邦开发项目考虑严重违反其与甲骨文、IBM 或微软等大型专有软件公司签订的许可协议是非常不寻常的。然而，具有讽刺意味的是，部分由于普遍误解 OSS 是指没有任何附加条件的“免费”软件，开发人员违反 OSS 许可证的情况令人惊讶地普遍，例如从源代码中剥离 OSS 许可证。从开发质量和长期支持的角度来看，这不仅是一个非常糟糕的想法，而且也是非法和不道德的，并且可能导致自由软件基金会 (FSF) [8] 等监督组织采取法律行动。更重要的是，它破坏了联盟式的共享和贡献模式，而这是 OSS 真正降低成本的潜力所在。系统工程师应尽其所能确保在任何给定项目中，OSS 许可证都将受到与任何其他商业许可证相同程度的尊重。
  
• 在构建大型系统时，尽量减少对新软件的需求。从历史上看，软件项目使用编写的代码行作为衡量进度进度的一种方式，这导致人们倾向于认为更多的代码是一件好事。然而，由于每行新代码都会带来可能持续数十年的长期成本和可靠性负担，因此真正的目标应该是相反的：SE 应该始终寻找方法将对新的、独特的软件的需求降至最低.通常需要代码，但它应该相对较小，功能强大，并且对正在创建的系统具有唯一性。普通文件访问或标准网络通信等常见功能不属于此类，应始终通过获取稳定、标准化良好的 OSS 或专有软件来处理。
  
• 强烈反对将 OSS 视为加速内部开发的“免费源代码”的任何观点。对于任何类型的软件，长期代码支持成本总是相形见绌。仅出于这个原因，将 OSS 视为“免费”源代码以加快短期发展目标是一种短视且坦率地说是危险的观点。一个很好的类比是：如果您的组织免费获得了 Microsoft Windows 的所有源代码，但规定从那时起您必须自己修复所有错误并进行所有增强，您会接受这个提议吗？大型 OSS 包至少与 Windows 一样复杂，因此在小型内部项目中随意采用此类源代码会产生相当于一个非常大且快速滴答作响的定时炸弹的支持成本。一个有用的三步经验法则是：首先尝试可执行文件，其次是社区支持，最后是新代码：
  

• 始终先尝试使用 OSS 的可执行版本。 OSS 往往比替代方案更具可配置性，因此第一步是咨询专家，看看是否可以通过下载“标准发布”二进制形式的 OSS 来简单地配置 OSS 应用程序以满足需求。（出于安全原因，您可能仍希望在本地下载并编译源代码。）
  
• 接下来，尝试向支持社区提交非敏感更改。如果 OSS 应用程序的某些功能绝对必须更改或扩展到源代码级别，则尝试以可以直接提交给支持该应用程序的社区的方式表达所需的更改。这种方法不仅减少了对源代码长期支持的需求，而且还有助于与支持社区建立更牢固的关系。
  
• 仅作为最后的手段，开发您自己的模块。在代码更改绝对不能公开的极少数情况下，寻找开发独立模块的方法。如果可能，请避免在此类模块中包含任何 OSS 源代码。每当更新原始 OSS 时，都必须检查和更新新模块中包含的每一行 OSS 源代码，这也会使模块的法律地位不必要地复杂化。
  

• 避免过分随意地发布政府代码作为 OSS。负责非敏感政府现货 (GOTS) 产品的政府项目经常发现 OSS 的社区支持功能非常有吸引力，并想知道他们是否可以简单地在 OSS 许可下发布他们的 GOTS 产品，以利用成本更低、漏洞更快的优势一些 OSS 项目中的修复和改进的长期支持。这个问题的答案很简单：不。OSS 支持的宝贵属性来自已经对产品感兴趣的社区，而 OSS 的宝贵模块化和灵活性则来自于这些人多年来开发的一个社区。简单地通过更改许可证并将其发布在网站上来制作 GOTS 产品的 OSS 会将其所有缺陷暴露给任何感兴趣的黑客，但不一定会吸引支持者的兴趣，他们在任何情况下几乎肯定会对不熟悉的源代码感到困惑。替换 GOTS 应用程序的更好方法是寻找现有 OSS 工具的配置，这些工具可用于近似 GOTS 功能。然后尝试围绕该配置开始构建一个新社区，以将其构建为原始 GOTS 工具的全功能模拟或扩展。
  
• 鼓励对所有商业软件的安全性有现实的理解。如果软件以二进制代码的形式出售或发布，它在现代世界的安全状况与以人类可读源代码形式发布的软件没有什么不同。原因是现代黑客工具直接针对二进制形式的软件来尝试破解它，这使得二进制形式在某些方面优于人类可读的形式，后者的分析速度要慢得多。因此，普遍表达的担心 OSS 不能因为“源代码可用”而变得安全只是无稽之谈。
  

• 相反，许多使源代码与世隔绝的专有流程在多个层面上都充满了问题，人们有机会插入可能严重损害此类系统安全性的更改。底线是：安全性是一个根据每个案例的实际细节进行最佳评估的过程；无论它是使用专有方法还是 OSS 社区方法开发的，都改变了必须检查的问题。专有方法具有带来更多资金的优势，而社区方法对更多用户来说更可见。当活跃且在全球范围内，OSS 还可以吸引更有可能发现渗透企图的专家。
  
• OSS 总是更安全的反对论点，因为“成千上万的眼睛”在看它，这也是错误的，原因很简单：仅仅因为源代码发布在网站上并不意味着任何人都在看它。专有软件也可能被吹捧为更安全，因为它已经以一种或另一种方式“认证”。不幸的是，因为在经过科学评估的实地研究中，没有任何软件认证过程被证明可以生产出比未经认证的软件更安全或更可靠的软件，因此尚不清楚这些认证是否意味着所涉及的公司能够做到的任何事情。承担此类认证的高昂费用。认证的应用不一致，联邦台式机通常运行的系统和应用程序从未获得过认证，或者很久以前就获得过认证，以至于认证不再适用。OSS 有时被认为是不安全的，因为“任何人都可以在代码中插入更改”。尽管确实任何人都可以对自己的 OSS 源代码副本进行他们喜欢的更改，但现实情况是，大型、活跃的 OSS 项目（如 Linux）具有严密保护且高度自动化的代码控制过程，只允许代码进入主要构建过程经过一些世界顶级操作系统内核专家的严格审查——这种验证水平将使大多数专有代码控制和审查过程相形见绌。
  

• 软件认证：寻找它们，支持获得它们，但永远不要依赖它们。如上所述，没有科学证据表明软件认证对软件的现场级可靠性或安全性有任何影响。尽管如此，它们在许多情况下仍然是必需的。对于 OSS，IBM 等公司帮助提供了认证。因此，SE 应该寻找相关 OSS 的认证以防万一，并查看它们与专有等效项的比较。感兴趣的项目也可以帮助 OSS 小组获得认证，例如通过小型专有公司，这些公司通常处理使用特定 OSS 组件的业务方面。最后，无论商业软件组件是否是 OSS 和是否经过认证，都不应假设网络软件系统的整体安全性已经过证明；多层安全是绝对必要的。