治理、风险和合规 (GRC) 计划有时被视为阻碍令人兴奋的网络安全工作的官僚机构。但一个好的 GRC 计划为满足安全性和合规性目标奠定了基础。网络安全的主动方法，如果做得好，可以最大限度地减少反应性事件响应。

在网络安全的三个组成部分——人员、流程和技术——中，技术被视为“简单的按钮”，因为相对而言，它比起草具有灵活性和特异性的适当平衡的政策或管理无数的组织原则和人力更简单行为。尽管如此，尽管我们在 AWS 推广技术和自动化，但我们也明白，使用最新技术自动化一个糟糕的流程并不会使流程或结果变得更好。网络安全必须将所有三个方面与可扩展的程序化方法结合起来。为实现这一目标，有效的 GRC 计划至关重要，因为它确保在处理网络安全的艰巨任务时采取整体观点。

尽管治理、风险和合规通常被视为独立的功能，但它们之间存在共生关系。治理为满足协调和支持业务的特定要求建立了战略和护栏。风险管理将特定的控制与治理和评估的风险联系起来，并为业务领导者提供他们需要的信息来确定资源的优先级并做出风险知情的决策。合规性是对特定治理要求的控制的遵守和监控。这也是在某些行业玩游戏的“赌注”，并通过持续监控，关闭有关有效治理的反馈循环。安全架构、工程和操作都建立在 GRC 基础之上。

如果没有 GRC 计划，人们往往只关注技术和烟囱式流程。例如，假设一名安全运营员工面临四个需要研究和缓解的事件。在没有 GRC 计划的情况下，员工将无法了解事件的业务风险或合规影响，这可能导致他们优先考虑最不重要的问题。

• GRC has a symbiotic relationship

GRC 计划的广度和深度因组织而异。无论其简单性或复杂性如何，都有机会改变或扩展该程序，以采用云服务、新兴技术和其他未来创新。

以下是可帮助您完成旅程的最佳实践清单。该清单的主要内容是：以目标和能力为基础的治理，在决策中包括风险背景，以及自动化监控和响应。

治理

确定合规要求

• __ 确定所需的合规框架（例如 HIPAA 或 PCI）和合同/协议义务。
• __ 确定云或新兴技术的限制/限制。
• __ 确定要实施的要求或选择的标准（例如 NIST、ISO、COBIT、CSA、CIS 等）。

进行计划评估

• __ 根据 NIST 网络安全框架 (CSF) 或 ISO/IEC TR 27103:2018 等行业流程进行计划评估，以了解您当前配置文件的能力和成熟度。
• __ 确定所需的最终状态能力和成熟度，也称为目标配置文件。
• __ 记录资源分配的差距（人员、流程和技术）并确定其优先级。
• __ 建立云卓越中心 (CCoE) 团队。
• __ 起草并发布包含采购、DevSecOps、管理和安全的云战略。
• __ 定义和分配功能、角色和职责。

更新和发布政策、流程、程序

• __ 根据与您的业务相一致的目标和所需功能更新策略。
• __ 更新现代组织和管理技术（例如 DevSecOps 和敏捷）的流程，指定如何升级旧技术。
• __ 更新程序以集成云服务和其他新兴技术。
• __ 建立用于选择控制和监控合规性的技术治理标准。

风险管理

进行风险评估*

• __ 进行或更新组织风险评估（例如，市场、财务、声誉、法律等）。
• __ 对每个业务线（如使命、市场、产品/服务、财务等）进行或更新风险评估。
• __ 对每种资产类型进行或更新风险评估。

* 使用预先建立的威胁模型可以简化风险评估过程，包括初始和更新。

风险计划草案

• __ 实施计划以减轻、避免、转移或接受每一层、​​业务线和资产的风险（例如，业务连续性计划、运营连续性计划、系统安全计划）。
• __ 针对特定风险领域（如供应链风险、内部威胁）实施计划。

授权系统

• __ 使用 NIST 风险管理框架 (RMF) 或其他流程来授权和跟踪系统。
• __ 使用 NIST 特别出版物 800-53、ISO ISO/IEC 27002:2013 或其他控制集来选择、实施和评估基于风险的控制。
• __ 实施对控制和风险的持续监控，最大限度地采用自动化。

将风险信息纳入决策

• __ 将系统风险与业务和组织风险联系起来
• __ 自动将持续的系统风险监控和状态转换为业务和组织风险
• __ 包含“有什么风险？” （财务、网络、法律、声誉）纳入领导决策

合规

监控政策、标准和安全控制的合规性

• __ 自动化技术控制监控和报告（高级成熟度将导致 AI/ML）。
• __ 对非技术控制实施手动监控（例如定期审查访客日志）。
• __ 将合规监控与安全信息和事件管理 (SIEM) 以及其他工具联系起来。

持续自我评估

• __ 自动化应用程序安全测试和漏洞扫描。
• __ 从控制抽样、整个功能区域和渗透测试中进行定期自我评估。
• __ 对假设、观点和人工制品过于挑剔。

应对事件和风险变化

• __ 将安全操作与合规团队集成以进行响应管理。
• __ 建立标准操作程序以应对控制的意外变化。
• __ 减轻影响并重置受影响的控制；尽可能自动化。

传达事件和风险变化

• __ 为每种类型的事件建立报告树和阈值。
• __ 在报告中包括总法律顾问。
• __ 确保在需要时通知适用的监管机构。
• __ 在适当的地方自动化。

原文：https://aws.amazon.com/cn/blogs/security/scaling-a-governance-risk-and-…

本文：https://jiagoushi.pro/node/1956

概述

合规管理是监控和评估系统的持续过程，以确保它们符合行业和安全标准，以及公司和监管政策和要求。

如何管理合规性

这涉及基础架构评估，以识别由于法规、政策或标准更改、配置错误或任何其他原因而导致的不合规系统。

合规管理很重要，因为不合规可能会导致罚款、安全漏洞、认证丢失或对您的业务造成其他损害。掌握合规性变化和更新可以防止您的业务流程中断并节省资金。

要成功监控和管理企业基础架构的合规性，您需要：

• 评估：识别不合规、易受攻击或未打补丁的系统。
• 组织：按工作量、影响和问题严重性确定补救措施的优先级。
• 补救：快速轻松地修补和重新配置需要采取措施的系统。
• 报告：验证已应用更改并报告更改结果。

合规管理挑战

可能使合规管理变得困难的一些事情是：

• 不断变化的安全和合规环境：安全威胁和合规变化迅速发展，需要对新威胁和不断发展的法规做出快速响应。
• 跨多个平台的分布式环境：随着基础设施在现场和云平台上的分布越来越多，要全面了解您的环境以及可能存在的任何风险和漏洞变得更加困难。
• 大型环境和团队：大型、复杂的基础架构和团队可能会使您的环境和组织之间的协调变得复杂。事实上，系统复杂性会增加数据泄露的成本。

合规最佳实践和推荐工具

应对这些挑战的最佳方法是采用多方面的方法来监控所有环境，识别任何监管不一致，解决这些不一致并使其保持最新并符合要求，并记录这些更新。

这些最佳实践可以帮助您及时了解任何法规变化并保持您的系统合规：

• 定期系统扫描：日常监控可以帮助您在合规性问题和安全漏洞影响业务运营或导致费用或延误之前识别它们。
• 部署自动化：随着基础架构规模的增长和变化，手动管理变得更具挑战性。使用自动化可以简化常见任务、提高一致性并确保定期监控和报告，从而让您可以专注于业务的其他方面。
• 一致的补丁和补丁测试：使系统保持最新可以提高安全性、可靠性、性能和合规性。应该每月应用一次补丁以跟上重要问题的步伐，并且补丁可以自动化。应尽快应用针对严重错误和缺陷的补丁。在将补丁重新投入生产之前，请务必测试补丁系统是否被接受。
• 连接您的工具：分布式环境通常包含针对每个平台的不同管理工具。通过应用程序编程接口 (API) 集成这些工具。这允许您使用首选界面在其他工具中执行任务。使用较少数量的接口可以简化操作并提高对环境中所有系统的安全性和合规性状态的可见性。

一些可以提供帮助的工具是：

• 主动扫描：自动扫描可以确保定期监控系统并提醒您注意问题，而无需花费大量员工时间和精力。
• 可操作的洞察力：针对您的环境量身定制的信息可以帮助您更快地确定存在哪些合规性问题和安全漏洞、哪些系统受到影响以及您可以预期的潜在影响。
• 可定制的结果：定义业务环境以减少误报、管理业务风险并提供更真实的安全和合规状态视图是理想的。
• 规范的、优先的补救措施：规定的补救说明消除了自己研究行动的需要，节省了时间并降低了出错的风险。基于潜在影响和受影响系统的操作优先级可帮助您充分利用有限的修补窗口。
• 直观的报告：生成关于哪些系统已修补、哪些需要修补以及哪些不符合安全和监管策略的清晰、直观的报告可提高可审计性并帮助您更好地了解您的环境状态。

红帽的合规性和自动化

在不增加时间或成本的情况下，自动化策略可以大大提高检查系统合规性的能力。 手动合规实践更耗时，容易出现人为错误，并且更难重复或验证。

选择正确的自动化技术是在混合环境中跨数据中心和网络软件系统快速实施的关键。 红帽在这方面大放异彩，为自动化和管理提供全面的端到端软件堆栈，其中包括 Red Hat® Enterprise Linux®, Red Hat Ansible® Automation, Red Hat Satellite, Red Hat Smart Management, and Red Hat Insights.

原文：https://www.redhat.com/en/topics/management/what-is-compliance-manageme…

本文：https://jiagoushi.pro/node/1955

开发人员通常认为软件许可要求是法律部门的明确责任。由于有如此多的开源组件可用，以及许可要求的含义，每个开发人员都应该至少对这些许可是什么以及每个许可如何影响他们的软件有一个大致的了解。

考虑到项目可能遇到的下游影响，每个团队都需要审查其软件的所有许可证要求。在发布任何更新或修改的软件之前，组织需要进行一次完整的许可证合规性审核，在项目的每个阶段这样做可以避免将来出现问题。一个许可团队应该研究的是GNU Affero通用公共许可（AGPL）。

什么是AGPL？

在讨论AGPL许可证之前，了解其来源是很重要的。1988年，Richard Stallman撰写了他的通用公共许可证（GPL），旨在保护创作者在任何时候都保持软件开源的权利。GPL目前处于第三个版本（GPLv3），因为之前的文本存在一些漏洞。

作为GPLV3的一部分，自由软件基金会（FSF）提供了两种附加类型的许可证，即较小的通用公共许可证（LGPLV3）和Affelo通用公共许可证（AGPLV3）。通用公共许可证的AGPL版本旨在对所有使用该许可证的软件强制执行完全的版权保留权利。

AGPL许可证的优点和缺点是什么？

在标准GPL许可证中，互惠条款在开发者发布软件时生效。copyleft原则旨在使所有源代码可供更广泛的开源社区使用。有了AGPL，软件团队可以确保对代码库的所有更改对公众可用，即使是在服务器端应用程序上。

确定AGPL 3.0、LGPL 3.0或标准GPL 3.0是否最适合团队取决于软件的最终意图。Copyleft许可证对于希望确保所有后续更改都可供社区使用的开发人员来说非常理想，而MIT许可证等允许的许可证使他们在未来有更多的自由进行专有修改。

AGPL的一些优点包括：

• 迫使团队在项目早期考虑他们的许可理念，并按照他们的决定生活。
• 确保开源社区开发的任何代码片段都保持可用，并防止其他人重新打包和销售开源软件。

AGPL的缺点是：

• 让一些团队远离开源软件包，因为它迫使所有其他代码成为GPLed软件。
• 有些人认为这是过分的，因为任何使用AGPL的依赖包中的任何模块都会使所有其他软件受到类似的限制。
• 取消了团队在未来使软件成为专有软件的选择。

公司可以使用AGPL软件吗？

尽管任何人都可以使用AGPL V3许可证，但它在组织中并不流行。对AGPL软件的任何后续版本施加的限制使得在存在竞争性商业利益时难以采用。

大多数公司更喜欢使用许可证，允许他们自由使用开源组件，并在未来将其版本的软件转化为商业产品，而不是使用AGPL等版权许可证。

什么是版权许可证？

Copyleft许可证执行了史塔尔曼在其GNU宣言中首先支持的原则。在20世纪60年代，开发人员公开分享所有帮助他人的源代码是很常见的，这创造了一种社区和协作的感觉。到了20世纪80年代，随着组织开始对其源代码应用版权，这一趋势不再受欢迎。Copyleft与版权相反，它强制执行使用、修改和重新发布任何具有Copyleft许可证（如GPL）的源代码的权利。

能否将AGPL与封闭源代码应用程序结合使用？

AGPL V3许可证是一个强大的copyleft许可证，它在所有源于之前工作的组件上强制实施开源。它填补了服务器端的漏洞，如果软件不发布，源代码就无法提供。AGPL将用户定义为任何访问服务器端应用程序（如果该应用程序面向公众）的人。对于驻留在组织网络内的应用程序，AGPL不会触发源代码的发布。

AGPLv3许可证是否与GPLv3兼容？

将GPLv3许可证下的作品与AGPL软件相结合的用户可以保留GPLv3许可证对未修改作品的权利。GPLv3工作的任何修改版本都必须使用AGPLv3许可证。

AGPL由于其激进的开源许可，目前只在不到1%的开源项目中使用。

原文：https://snyk.io/learn/agpl-license/

本文：https://jiagoushi.pro/node/1822

每隔一段时间，社区就流行产品中的有争议的开源许可引起轩然大波会成为头条新闻，导致我们所有人争论开源许可的真正含义。去年，是 Apache 基金会禁止使用 Facebook React 有争议的专利条款的组件，这引起了轰动，促使开发人员竞选 Reddit 板。在过去的几个月里，Redis Labs 和 MongoDB 对其一些最受欢迎的开源数据库的开源许可证进行了更改，这让许多人摸不着头脑，强调需要用人类语言解释开源许可证。

内容

• 基础知识：什么是开源许可证？
• Copyleft 和 Permissive：解释了两种类型的开源许可证
• 备忘单：顶级开源许可证解释
• GNU General Public License (GPL)
• The Apache License
• Microsoft Public Licenses (Ms-PL)
• Berkeley Software Distribution (BSD)
• Common Development and Distribution License (CDDL)
• Eclipse Public License (EPL)
• MIT License
• 了解您的开源许可证，或向法官解释

基础知识：什么是开源许可证？

最简单的解释是，开源许可证是软件组件的作者和用户之间的合法且具有约束力的合同，声明该软件可以在特定条件下用于商业应用程序。 许可证是将代码变成开源组件的原因。 如果没有开源许可证，即使已在 GitHub 上公开发布，其他人也无法使用该软件组件。

每个开源许可证都说明了允许用户对软件组件执行的操作、他们的义务以及根据条款和条件他们不能执行的操作。 这听起来可能很简单，但是那里有 200 多个开源许可证，所以祝你好运，让它们井井有条。 复杂性和要求各不相同，由组织决定哪些许可证与其策略最兼容，以确保它们保持合规性。

Copyleft 和 Permissive：解释了两种类型的开源许可证

开源许可证的两大类通常需要深入解释。开源许可证可以分为两大类：copyleft 和 permissive。此划分基于许可证对用户的要求和限制。

版权是一项限制未经版权所有者许可使用、修改和分享创意作品的权利的法律。想想属于其创作者知识产权的音乐、电影等。当作者在 copyleft 许可下发布程序时，他们对作品的版权提出主张，并声明其他人有权使用、修改和共享该作品，只要维护义务的互惠性.简而言之，如果他们使用具有这种开源许可证的组件，那么他们也必须将他们的代码也开放给其他人使用。

许可型开源许可证是一种非 Copyleft 开源许可证，它保证使用、修改和重新分发的自由，同时也允许专有的衍生作品。宽松的开源许可证，被亲切地称为“Anything Goes”，对其他人如何使用开源组件的限制最小。这意味着这种类型的许可允许不同程度的自由使用、修改和重新分发开源代码，允许其在专有衍生作品中使用，并且在未来的义务方面几乎不需要任何回报。

重要的是要注意没有好或坏的许可证，并且没有一个许可证比另一个更好。任何人都可以创建适合自己的开源许可证，这就是有这么多的原因。这可能会使选择开源许可证变得复杂，特别是对于我们这些不精通法律并且从未彻底解释过开源许可证的人来说。为了帮助缩小决策范围并理解这一切，OSI 整理了一份已批准许可证的列表，其中包含 80 多个最常用的开源许可证。

在 OSI 批准列表中的数十个开源许可证中，有一些是至高无上的，并被一些最流行的开源项目使用。

GNU 通用公共许可证 (GPL)

GNU 的通用公共许可证是最流行的开源许可证。 Richard Stallman 创建了 GPL 来保护 GNU 软件不被私有化，这是他的“copyleft”概念的具体实现。

GPL 是 Copyleft 许可证。这意味着基于任何 GPL 组件编写的任何软件都必须作为开源发布。结果是任何使用任何 GPL 开源组件的软件（无论其在整个代码中的百分比如何）都需要发布其完整源代码以及修改和分发整个代码的所有权利。

关于什么构成“基于”另一部作品的作品一直存在一些混淆，这反过来又触发了 GPL 互惠义务。 FSF 试图在 GPLv3 中更清楚地说明何时触发互惠义务。 FSF 甚至编写了一个新的 GPL 许可证，即 Affero 许可证，以解决被称为“ASP 漏洞”的特定混淆。

此外，FSF 试图增加 GPLv3 与其他许可证的兼容性。要将两个代码组合成一个更大的作品，两个程序都必须允许它。如果两个程序的许可证都授予了此类权利，则它们是兼容的。通过使 GPLv3 更加兼容，FSF 扩展了开发选项。

两个版本之间的第三个区别是 GPLv3 是为了增加全球使用率而编写的。修改了 GPLv3 中用于描述许可权的语言，以确保国际法将其解释为 FSF 的意图，这与 GPLv2 中使用的语言不同，后者被认为非常以美国为中心。 GPLv3 还允许开发人员添加本地免责声明，这也有助于增加其在美国以外的使用率。

The Apache License

Apache 许可证是由 Apache 软件基金会 (ASF) 发布的开源软件许可证。这是一个流行且广泛部署的许可证，由强大的社区支持。 Apache 许可证允许您自由使用、修改和分发任何 Apache 许可产品。但是，在这样做时，您需要遵守 Apache 许可证的条款。

Apache 集团（后来更名为 Apache 软件基金会）于 1995 年发布了其许可证的第一个版本，但您很少会遇到仍然带有此许可证的组件。

2000 年，当伯克利接受自由软件基金会提出的论点并从 BSD 许可证中退出广告条款并形成修改后的 BSD 许可证时，Apache 也这样做并创建了 Apache 许可证版本 1.1。

删除广告条款意味着任何 Apache 许可产品的衍生作品的广告材料不再需要包含 Apache 许可归属。仅在文档中包含归属就可以了。

2004 年，ASF 决定更彻底地脱离 BSD 模型，并通过授予专利权并定义其使用的概念的可靠定义以使其更加连贯，产生了 Apache 许可证 2.0 版。

回答的 10 大 Apache 许可证问题

 

Microsoft 公共许可证 (Ms-PL)

Microsoft 公共许可证是 Microsoft 发布的免费和开源软件许可证，它是为其作为开源发布的项目编写的。

您可以自由复制和分发根据 Ms-PL 许可许可的任何软件的原始或衍生作品。但是，当您这样做时，您不得使用任何贡献者的名称、徽标或商标。 Ms-PL 通过明确不为使用您的代码提供任何明示保证或保证来保护作者，因此如果代码在某些情况下无法正常运行，作者不承担任何责任。

当您在 Ms-PL 下分发软件（或其部分）时，您不需要分发其源代码。如果您愿意，您可以这样做，但您没有义务这样做。但是，您需要保留软件中最初存在的所有版权、专利、商标和归属声明。

此外，如果您以源代码形式分发软件的任何部分，您只能在 Ms-PL 下执行此操作，方法是在您的分发中包含此许可证的完整副本。如果您以编译或目标代码形式分发软件的任何部分，您只能在符合 Ms-PL 的任何其他许可下这样做。

重要的是要注意，Ms-PL 条款和条件文档非常简短、简洁，并以非常连贯的语言编写。微软希望与开源社区保持非常清晰和直接的关系，这也有助于提高采用率（正如我们从 BSD 许可证中知道的那样）。

 

伯克利软件分发 (BSD)

BSD 许可证或原始 BSD 许可证及其两个变体——修改后的 BSD 许可证（3 条款）和简化的 BSD 许可证/FreeBSD 许可证（2 条款）是一系列宽松的自由软件许可证。

只要您保留版权声明、条件列表和免责声明的副本，BSD 许可证允许您以源代码或二进制格式自由修改和分发您的软件代码。

原始 BSD 许可证或 4 条款 BSD 许可证还包含广告条款和非认可条款（有关这些条款的详细说明在以下问题中提供）。修改后的 BSD 许可证或 3 条款 BSD 许可证是通过从原始 BSD 许可证中删除广告条款而形成的。此外，FreeBSD 版本或 2 条款 BSD 许可证是通过从修改后的 BSD 许可证或 3 条款 BSD 许可证中删除非认可条款而形成的。



 

通用开发和分发许可证 (CDDL)

 

CDDL 是由 Sun Microsystems 发布的开源许可证，用于替代 Sun Public License (SPL)。 Sun（现在的 Oracle）认为 CDDL 许可证是 SPL 版本 2。它的灵感来自 Mozilla 公共许可证 (MPL)。在 2004 年转而依赖 CDDL 之前，Sun 曾经在其 Sun 公共许可证 (SPL) 下发布其自由软件/开源项目。CDDL 通常被称为 MPL 的清理版本，旨在促进可重用性。

您可以自由复制和分发根据 CDDL 许可的任何软件的任何原始或衍生作品。但是，您不得删除或更改软件中包含的任何版权、专利或商标声明。您还必须保留任何许可通知或任何归属于任何贡献者或初始开发者的描述性文本。

当您以可执行形式（源代码以外的任何形式）分发您的软件时，您需要在 CDDL 下提供源代码。可执行形式可以在 CDDL 或任何与 CDDL 兼容的许可下发布。

您必须提供的源代码包括您的贡献，只要它们是对包含原始软件的文件或包含原始程序部分的新文件内容的添加、删除或修改。这意味着，如果您的添加是在不包含原始代码的单独且独立的文件中进行的，则您不必在 CDDL 下发布它。如果您愿意，您可以这样做，但您没有义务这样做。

此外，您必须在分发的任何源代码中包含一份 CDDL 副本。对于您所做的每项修改，您必须通过在修改后的文件中包含通知来将自己标识为修改者。

Eclipse 公共许可证 (EPL)

 

Eclipse 公共许可证 (EPL) 是由 Eclipse 基金会开发的开源许可证。它源自通用公共许可证 (CPL)。现在在 EPL 下可用的 Eclipse 代码库以前是在 CPL 下获得许可的。

EPL 许可证是一个 copyleft 许可证。如果您修改了 EPL 的组件并将其作为程序的一部分以源代码形式分发，则您需要在 EPL 下披露修改后的代码。如果您以目标代码形式分发此类程序，您需要声明源代码可以根据要求提供给接收者。您还需要共享请求源代码的方法。

Eclipse 基金会明确表示，在他们看来，“仅仅与 Eclipse 插件进行接口或互操作”并不能使您的代码成为插件的衍生作品。

如果您重新分发带有 EPL 组件的程序，您有义务提供完整的许可文本和版权。

如果公司在商业产品中使用他/她的组件，EPL 保护作者免受可能的诉讼或损害。它还提供专利授权。

麻省理工学院许可证（MIT)

麻省理工学院在 80 年代后期创建的 MIT 许可证是最宽松的自由软件许可证之一。基本上，您可以使用根据 MIT 许可许可的软件做任何您想做的事情——只要您添加原始 MIT 许可和版权声明的副本即可。 MIT 许可证非常简单、简短且中肯，这就是为什么它在开发人员中具有如此高的采用率，尽管有些人避免使用它，因为它没有明确授予专利权。商业组织通常更喜欢它，因为它具有“无附加条件”的性质。

了解您的开源许可证，或向法官解释

如果您已经走到了这一步，那么您就会知道开源许可证不适合胆小的人。

然而，考虑到几乎所有软件开发人员都严重依赖开源组件这一事实，了解开源许可的基础知识以及流行的开源许可之间的主要区别至关重要。

我们只希望这种解释使潜在的许可证雷区更易于导航。

原文：https://www.whitesourcesoftware.com/resources/blog/open-source-licenses…

本文：https://jiagoushi.pro/node/1961/

容器——本质上是可执行的独立软件包，包含软件运行所需的所有文件（库、系统设置、依赖项等）——在现代应用程序开发中无处不在。最近的一个云计算计算基金会（CNCF）的调查显示，有84%的组织在几年前只有23%的生产中使用容器。

与当今的许多技术领域一样，容器生态系统在很大程度上是由开源组件推动的。这些措施包括：

• Docker Hub这样的注册中心承载着成千上万的开源容器映像
• 容器编排平台（如Kubernetes）
• Docker文件（如DockerFile）
• 容器运行时（如Containerd）

然而，就像所有的东西OSS一样，在容器环境中使用开源组件有一定的许可证合规义务。这就是开源的本质——创作者免费提供创新的新技术，但需要注意的是，用户必须遵守管理许可代码/文件的某些要求。

在本博客中，我们将探讨开源容器生态系统的哪些部分具有合规义务，如何处理根据GPL v2（或类似的强copyleft许可证）许可的组件，以及许可证合规的最佳实践，等等。

容器映像和法规遵从性注意事项

如前所述，容器生态系统是由开源驱动的。但是，出于许可证合规的目的，主要关注的是容器映像。这是因为许可证合规义务是由代码的分发触发的，而容器映像通常是容器生态系统中唯一符合此标准的部分。

不过，在我们深入研究容器镜像之前，先简单介绍一下容器配方文件（这些文本文件基本上提供了关于如何构建容器镜像的说明）。您可能很少会遇到实际分发配方文件的情况，这就是为什么我们不会在本博客中详细讨论它们的原因。但如果你这么做了：请记住，配方文件有时会被不同的许可证覆盖，而不是由它们生成的镜像。例如，Dockerfile可能在MIT下获得许可，但它可能描述在Apache2.0和ISC下获得许可的镜像。

现在，回到我们帖子的主要焦点，容器镜像。容器映像在容器环境中起着不可或缺的作用——它们是包含运行所需软件的分布式包。对于上下文，容器是容器映像的运行实例，在任何给定时间都可以有多个容器映像。

术语容器映像还用于描述构成完整构建的容器映像的各个软件文件。开发团队通常会使用Docker Hub等公共注册中心上提供的开源容器映像。一个完整构建的容器映像可能包含一个开源基础映像（一个像Ubuntu这样的操作系统）、另一个开源映像（像Postgres SQL）、另一个像Logstash，等等。

如果团队使用多个许可证下的镜像构建和分发容器，他们将需要遵守其中最强的copyleft。（也就是说，如果一个镜像层在MIT许可证下，另一个GPLv3下，你需要遵守GPLv3。）

关于容器映像和许可证合规性的另一个重要注意事项是，在完全构建和装运的容器映像中，某些层可能会被遮挡。然而，您仍然需要遵守每一层的许可要求——即使是那些在运行时不可见的许可要求。考虑到不同许可证和不同文件（从不同来源获取）的数量，这可能是相当具有挑战性的。（我们稍后将在博客中讨论解决这一问题的策略。）

容器分发

开源许可要求在软件发布时生效。换句话说，如果您使用GPL许可的组件来构建仅供内部使用的开发工具，则无需担心源代码泄露。在容器的上下文中，当您允许其他人下载您的容器镜像时，分发就变得相关了。例如，Docker Hub上的任何镜像都将被分发，因此必须符合各自的许可证要求。

完整构建的容器映像的分发与任何其他软件的分发非常相似。构建的容器映像以二进制形式分发，分发方必须遵守容器映像中所有包和软件的许可要求。这可能很困难，因为容器通常包含数百个包，所有这些包都需要符合要求。

容器和Copyleft许可证

开源许可证有两种类型：permissive和copyleft。许可许可通常允许许可代码的用户有很大的灵活性（只要他们提供适当的属性），而copyleft许可则有更严格的要求。一些copyleft许可证甚至要求在用户修改（然后分发）copyleft许可证代码时披露源代码。

然而，在容器环境中满足源代码公开要求说起来容易做起来难。这种情况有几个原因：

• 镜像层可以在不同的时间合成，源代码可能已经更改
• 需要收集所有层的源代码，这可能很有挑战性
• 构建容器映像的确切规格取决于映像的配置方式。

好消息是，像FOSSA这样的容器扫描工具可以帮助团队准确理解源代码和所有镜像层的相关许可证。我们将在以下章节中更详细地讨论这一点。

注意：在容器环境中履行合规义务时，所需信息（通知文件、版权文件、变更日志等）可以嵌入容器镜像中，或者通过可能已经设置的正常属性页面向最终用户披露。

如何遵守容器许可证义务

开放源代码许可证合规性——在容器环境和其他环境中——从全面了解所涉及的许可证开始。但是，正如我们前面提到的，发现容器映像的每一层的许可证可能很困难，因为这些层在运行时会被遮挡。

这就是为什么自动化的容器扫描工具会产生如此大的影响。这些工具显示给定镜像所有层的所有许可证。

注意扫描的时间也很重要。如果您等到SDLC的后期进行许可扫描（并发现，比如，一个GPL许可的组件），您可能会被迫撤销并重建大部分容器工件。因此建议：

• 尽快扫描镜像，尤其是基础镜像
• 先扫描，然后再添加，然后再将其添加到容器中
• 此外，在将完整构建的镜像推向生产之前，将其作为CI/CD的一部分进行扫描

容器许可证合规的其他策略

• 首先，考虑将您应用到您的组织的其他领域的任何许可策略应用到容器环境中。这可能包括强版权许可的默认拒绝姿态，以及弱版权许可（如Mozilla Public License 2.0）的“黄色”标志。
• 建立一个预先批准的、私有的基本映像注册中心可能是有意义的，这些基本映像都包含在您组织的策略中，这样您就知道不会带来任何法规遵从性问题。
• 使用FOSSA这样的工具——提供容器镜像许可证扫描和管理——可以帮助企业遵守容器合规要求。

福萨（FOSSA ）的作品是：

• 提供开放源代码许可证类型的审计级清单，即使是在运行时隐藏的镜像层中
• 提供详细的元数据信息，包括许可证文本、版权信息和合规义务
• 跨公司、产品和团队应用内置的、可定制的OSS策略。这包括通过现有的工程工作流程以本机方式标记或阻止违反策略的行为

原文：https://fossa.com/blog/containers-open-source-license-compliance/

本文：https://jiagoushi.pro/node/1827

使用开源组件可节省开发人员的时间和公司资金。 换句话说，它就在这里。 下面介绍一下如何提高开源安全性。

今年的Equifax漏洞提醒人们，开源软件和组件虽然有很多好处，但对企业安全构成巨大风险，尤其是在维护不当的情况下。

今年4月，Flashpoint Intelligence的研究人员表示，犯罪分子正在对流行的开源Magento电子商务平台使用暴力密码攻击，利用受损的访问来刮取信用卡记录并安装专注于加密货币挖掘的恶意软件。

[了解如何在企业中跟踪和保护开源。 |通过注册我们的新闻通讯获取CSO的最新消息。 ]

研究人员发现至少有1000个受到攻击的Magento管理员小组，并表示自2016年以来对深度网络和黑暗网络平台的兴趣持续不减。此外，人们还对Powerfront CMS和OpenCart表现出了浓厚的兴趣。

 

多年来，开源代码越来越受欢迎，并被各种规模的公司用于所有垂直行业。

除了市场上广为人知的开源操作系统之外，企业用户还利用开源生产力软件，管理员和开发人员的工具以及用于构建自己的软件的各种代码库。甚至商业软件通常建立在开源代码的基础之上。

“我看到企业更广泛地采用开源软件，”Kudelski Security首席技术官Andrew Howard说。 “随着企业转向敏捷方法，开源变得更有价值，并且有更多可用的工具。如果你看看今天进入市场的新软件开发人员，他们接受了开放源代码技术的培训。”

开源安全优势

霍华德表示，开发人员严重依赖开源软件，公司对主要开源项目特别感兴趣，这些项目由大型团队维护。此外，还有“多视角”的安全方法。 “这是使用开源软件的主要优势 - 除了降低成本外，”他说。 “理论上你有更多的眼睛看着它。” （虽然他补充说这不适用于较小的项目或代码库。“有些软件没有任何社区，”他说。）

[准备通过PluralSight的综合在线课程成为认证信息安全系统专业人员。现在提供10天免费试用！ ]

开源代码的另一个安全优势是，如果出现问题，公司可以打开它并立即修复它。 “如果代码根据专有协议获得许可，他们通常必须等待供应商做出响应，”Synopsys公司的开源解决方案经理Mel Llaguno说。

为什么开源软件会带来安全威胁

Synopsys管理Coverity Scan，这是一项免费服务，可扫描开源代码中的缺陷。 “整体而言，开源软件的质量一直在提高，”Llaguno说。 “我们有大约7.5亿行开源代码参与我们的扫描项目，并确定了110万个缺陷 - 已经解决了650,000个缺陷。”他补充说，许多项目，特别是较小的项目，不会扫描他们的代码以寻找潜在的安全漏洞。

例如，Black Duck Software，Inc。在超过550,000个项目中跟踪超过100亿行开源代码。即使这不是一个完整的图片。 Linux基金会报告称已有310亿行代码提交给开源存储库。

谁在使用所有开源代码？每个人。根据最新的Black Duck报告，96％的商业应用中都有开源组件。普通应用程序有147个不同的开源组件 -  67％的应用程序使用具有已知漏洞的组件。

美国政府赞助了Common Vulnerability Enumeration列表和National Vulnerability Database。 2017年，超过8,000个新漏洞被添加到CVE列表中，创历史新高。

那么为什么公司使用开源软件呢？ “在普通应用程序中，超过三分之一的代码库是开源的，”Synopsys公司黑鸭安全策略师Mike Pittenger表示，“为了取代代码库的三分之一，你将不得不增加您的开发团队或开发时间减少了50％ - 我认为这些在当今世界并不可行。“

以伦敦的Skyscanner Ltd.为例，该公司是一家旅游搜索引擎。该公司曾经在.NET等专有的封闭平台上运行。 Skyscanner的安全工程师Alex Harriss表示，在过去的几年里，它已经迁移到更广泛的语言和技术，包括开源。 “这意味着我们的工程师现在能够从多个来源获取依赖关系并在几分钟内部署他们的代码，”他说。

哈里斯说，这也带来了安全挑战。他说：“我认为存在一种误导性的依赖，即作为开放源代码，这些图书馆正在接受社区安全漏洞的审查。” “实际上，情况似乎并非如此。”

他说，许多最常见的图书馆都有充分记录的漏洞。由于工程师只是从这些库中提取代码并进行部署，因此产生了可见性问题。 “我们根本不知道我们产品中的依赖数量，”他说。

需要对开源软件安全性进行更多尽职调查

Skyscanner并不孤单。根据最新的Veracode报告，只有28％的组织进行任何类型的定期分析，以找出其应用程序中内置的组件。随着开源代码的使用增长，这种风险表面也在扩大。

在开源代码中不断发现新的漏洞，许多项目没有用于查找和修复问题的机制。根据Snyk最近对开源维护者的调查，44％的人从未接受过安全审计，只有17％的人表示他们拥有高水平的安全知识。

还没有标准的方法来记录开源项目的安全性。在GitHub上的前400,000个公共存储库中，只有2.4％有安全文档。

然后，如果问题得到解决，通常无法找到并通知旧代码的所有用户。 “开源社区不知道谁在使用他们的组件，”Black Duck的Pittenger说。

根据Snyk的调查，88％的开源代码维护者在发布说明中添加了与安全相关的公告，34％的人表示他们弃用旧的不安全版本。百分之二十五的受访者表示他们根本没有努力通知用户漏洞，只有10％的人提交了CVE。

Snyk Ltd.首席执行官兼联合创始人Guy Podjarny表示，很多人都不知道CVE流程是如何运作的，或者没有时间通过​​它。“例如，在Javascript中，只有13％的漏洞我们跟踪有一个CVE编号，“他说。 “其余的只是记录为错误。”

Snyk有一个安全研究团队，通过寻找发布说明，GitHub和Apache问题跟踪系统等地方的线索，在开源库中寻找安全问题的迹象。结果发布在其漏洞数据库中，如果可能，Snyk还会将它们提交到CVE列表。

但是，获得CVE可能是一个复杂的过程，需要委员会就CVE细节达成一致，以及项目所有者的同意。 “这种方法目前的工作方式并不适用，”Podjarny说。

最后，如果发现并修补了漏洞，并且广泛宣传了补丁，那么使用该代码的企业可能不会意识到他们拥有该漏洞或者可能在查找所有实例时遇到问题。例如，今年巨大的Equifax漏洞涉及Apache Struts开源软件中的一个漏洞。这个补丁在漏洞发生前几个月就出现了，Equifax知道补丁，但仍然无法及时修复。

另一个问题是某些公司正在运行旧版本的代码，并且由于兼容性问题，合规性或其他原因而无法迁移到最新版本。根据Snyk的说法，只有16％的漏洞修复程序被反向移植到其他版本。

查找并修复

在理想的世界中，应用程序将在安全补丁可用的瞬间更新，无需任何干预。然而，在实践中，这并非总是可行的。

相反，企业需要有办法在其环境中查找所有开源代码实例，不断更新此列表，引导开发人员远离旧的，不安全的库，最后在发现新漏洞时出去部署补丁。

Skyscanner的Harriss表示，“只有当你知道它们的位置时才能从你的产品中删除易受攻击的库，并且在生命周期中越早做它就越便宜。”

许多公司求助于Snyk，Black Duck和Veracode等供应商。这也是Skyscanner所做的。 “Snyk让我们看到了哪些软件包在哪些项目中被使用，它们包含的漏洞以及它们如何被引入到我们的代码中，”Harriss说。此外，Snyk会在编写代码时立即向开发人员标记漏洞，以便在代码投入生产之前解决问题，他说。

将开源漏洞扫描集成到开发过程中对于大型企业尤为重要，因为很难跟踪所有正在使用的代码。 “我们处理的大多数公司都不知道他们拥有的应用程序的完整库存，这有点可怕，”Veracode研究副总裁Chris Eng说。

当Veracode进行漏洞扫描时，公司会上传他们的二进制代码，Veracode会根据国家漏洞数据库对其进行检查。为了帮助公司发现他们可能不知道的运行的应用程序，Veracode还可以扫描公司的外围。 “它不会发现其他没有曝光的内部应用程序，但是由于暴露，这些风险将会降低，”Eng说。

他补充说，还有一些网络工具可供公司用来查明内部运行的内容，但如果网络被细分，可能会出现盲点。公司还可以在端点设备上安装代理以跟踪正在运行的内容。 “如果你没有在任何地方安装代理，你可能仍会有一些盲点，”Eng说。 “没有一种方法可以实现这一切，这就是为什么这是一个如此困难的问题。”

对于Equifax来说，这当然是一个难题。去年十月，前首席执行官理查德史密斯告诉国会，该公司的信息安全部门进行扫描，寻找最终导致违规的Apache Struts漏洞。扫描“没有发现任何受此漏洞影响的Apache Struts版本，并且该漏洞仍然存在于Equifax Web应用程序中的时间比应有的长得多，”他说。

“你必须确保你知道环境中的每台服务器都要使用这个工具进行扫描，”Black Duck的Pittenger说道。即使扫描完整且准确，它们也会为组织带来大量的管理开销。如果没有在开发过程中内置安全检查，则必须连续运行这些扫描，并单独检查和重新检查应用程序是否存在漏洞。

开发人员不仅会在更新应用程序时将新的易受攻击的库引入其应用程序，而且在以前认为安全的旧库中会发现新的漏洞。 “软件并不像葡萄酒那样老化，”Eng说。 “它像牛奶一样老化。”

Eng表示，开发人员很少回头查看他们在旧项目中使用的库。 “我今天下载的是当前版本的任何版本，将其整合到我的应用程序中，并且再也不会考虑它，”他说。

为了说明这个话题现在有多重要，本月Synopsys公司以超过5亿美元的价格收购了Black Duck。 “我认为，这是一个很大的市场验证，”牛仔集团有限公司负责人约翰迪克森说，他对交易规模感到惊讶。 “我认为这是一个热门的空间，但我认为它不是那么热。这次收购变成了很多头。”

原文：https://www.csoonline.com/article/3157377/open-source-software-security-challenges-persist.html

本文：https://jiagoushi.pro/open-source-software-security-challenges-persist

讨论：请加入知识星球或者小红圈【首席架构师圈】

在我们关于流行开源软件（OSS）许可证的系列文章中，前一篇文章详细介绍了GNU GPL v2许可证的细节，该许可证最初由GNU项目发布。然而，2.0版并不是GNU GPL（通用公共许可证）的最新版本，也不一定是最流行的版本。这将是GNU通用公共许可证3.0版，简称GPLv3。

尽管GPLv3在2007年发布，也就是GPLv2发布16年后，但它与它的前任有很多共同之处。两者都要求用户在发布基于许可作品的任何二进制文件时包含完整许可文本的副本，并提供原始源代码，以及其他类似之处。关键的差异是试图解决和/或弥补一些人认为的2.0版的弱点或漏洞的结果。

那么，这两个版本的GNU GPL如何比较呢？为什么开发者或软件公司会选择使用GPLv3许可的代码？我们将在本指南中详细介绍这些问题。

GPLv3许可证：基础

与GPL v2一样，GPL 3是一个强大的copyleft许可证，这意味着原始代码的任何副本或修改也必须在GPL v3下发布。换句话说，你可以把GPL3的代码，添加到它或作出重大改变，然后分发你的版本。但是，您的版本也需要遵守相同的许可证要求，这意味着它也必须在GPL v3下——任何人都可以看到您修改的代码，并为自己的目的安装它。

GPLv3要求

GPL v2和GPL v3的许可条款类似。它们要求代码用户：

1. 包括完整许可证文本的副本
2. 说明对原始软件所做的所有重大更改
3. 在基于许可作品分发任何二进制文件时，请提供原始源代码
4. 包括版权声明原件的副本

此外，GPL v3规定，任何将代码作为消费者设备的一部分的人都必须包含更新和重新安装软件所需的任何安装信息。

使用许可代码

GPL v3许可证允许代码用户：

• 将代码用于商业目的：与GPL v2一样，GPL v3对软件的内部使用不施加任何条件。
• 更改代码：用户可以更改或返工代码，但如果他们以二进制形式发布这些更改/修改，他们还需要在GPL v3许可证下以源代码形式发布这些更新。
• 分发代码的副本或修改：只要这些修改也在GPLv3许可下发布，它们就可以分发给其他人。
• 放置保修：原始代码的分销商可以对许可软件提供他们自己的保修。

与它的前身一样，GPLv3不允许用户对代码进行再授权。换句话说，您不能对代码进行返工、修改或添加，然后对公众关闭这些更改。原始代码的“开源性”遵循任何更新或添加。

GPLv3与GPLv2

我们已经讨论了GPL v2和GPL v3之间的一些细微差异。现在，让我们讨论更重要的问题：专利权的授予以及与Apache License 2.0的兼容性。

专利权的授予

与流行的许可协议Apache license 2.0一样，GPL v3也包含明确的专利权授予。这到底是什么意思？这意味着原始许可代码的创建者或贡献者实质上“放弃”了他们对软件后续任何重用的专利权。通常，如果你对你创造的东西拥有专利，而有人制造、使用、销售或进口它，你可以在法庭上对他们提出质疑。如果您明确地将专利权授予其他用户，则情况并非如此，因为所有贡献者在GPLv3下授权其代码时都会这样做。

虽然GPL v2许可证确实讨论了专利权，但它更一般地讨论专利权，而且没有代码贡献者的明确授权。GPL v3通过在许可证全文中明确说明专利授予来解决这一问题。

与Apache 2.0的兼容性

假设一个开发者使用来自两个不同许可证下的两个不同OSS库的组件来构建一个软件。如果许可证是兼容的——换句话说，具有不同许可证的软件组件可以合法地一起分发——一切都很好，开发者可以在更强大的许可证条件下分发聚合的工作。如果不是，那可能会带来问题。

与GPL v2不同，GPL v3与常用的Apache许可证2.0兼容。然而，这种兼容性只有一种作用。根据Apache 2.0许可的代码可以与GPL 3许可的代码结合使用，生成的作品根据GPL 3许可。相反——将GPL 3代码合并到一个更大的作品中，然后根据Apache 2.0获得许可——是不允许的。

GPLv3用例

GPLv3和GPLv2至今仍在使用，一些OSS项目使用早期版本，另一些则采用最新版本。下面，我们将介绍开发人员和软件公司选择GPLv3许可证进行开源工作的几个原因。

对于开发者来说

研究表明，开源软件贡献者的动机更多的是希望学习和成为OSS社区的一部分，而不是经济回报。许多OSS开发者相信软件应该是免费的，每个人都可以访问，这使得GPL v2和GPL v3这样的版权许可特别有吸引力。

GPL v3可能是基于国外或面向全球受众的开发人员的更好选择，因为它包括国际化方面的改进。而且，如果开发人员计划将Apache2.0d组件合并到他们的工作中，他们必须选择GPLv3而不是GPLv2。

如果你不能决定选择哪一个，你也可以使用GPL v2或任何更高版本，目前包括GPL v2或GPLv3。

对公司来说

对于软件组织来说，这两个GPL之间的一个主要区别在于明确授予专利权。任何公司都不想提起诉讼，GPL v3中明确的专利授权提供了法律保护和安全感。

GPLv3的兼容性对于公司和开发人员来说都是一个难题。由于Apache2.0是这样一个常用的许可证，软件组织可能希望保留使用Apache2许可代码的选项。

然而，许多公司不愿在物联网或嵌入式系统中使用GPL v3代码，因为它需要“安装信息”。

GPLv3的众所周知的用途

2015年被企业OSS巨头红帽收购的IT自动化公司Ansible在GPL v3下授权其开源软件。其他著名的例子包括图像编辑器GIMP和Unix shell Bash，它们都是作为GNU项目的一部分构建的。

GPLv3的未来

最近的研究表明，虽然不像许可的项目那样受欢迎，但copyleft许可证仍被相当一部分OSS项目使用。在GPL系列许可中，GPLv3是最受欢迎的。

如果您仍然对GNU项目和/或各种GPL许可证有疑问，请访问他们的综合常见问题页面。

原文：https://fossa.com/blog/open-source-software-licenses-101-gpl-v3/

本文：https://jiagoushi.pro/node/1824

顾名思义，GNU Affero通用公共许可证（AGPL）是GNU GPL系列的一部分，它还包括LGPL许可证、GPL v2和GPL v3。所有这些开源许可证都是Richard Stallman的GNU项目的一部分，这是一个免费的开源操作系统，并伴随着软件共享和修改的理念。

与GPL一样，AGPL也是一个强大的copyleft许可证。最初的Afelo GPL是基于GPL V2并在2002发布的，而不是由Richard Stallman，而是由Henry Poole为他的软件启动，Afro，Inc.然而，Stalman的自由软件基金会发布了自己的版本，这一次基于GPL V3，在2007，保持“AFEROO”的名义作为对这一历史的点头。新版本包含了在AGPL和GNU GPL v3之间建立兼容性的措辞。如今，版本3是使用的主要版本。

AGPL主要适用于通过网络提供服务的软件，与其他强版权许可证一样，它有严格的要求。继续阅读，了解更多关于GNU AGPL、其条款和用户义务，以及在OSS社区中的受欢迎程度。

AGPL许可：概述

AGPL许可背后的想法是解决“应用程序服务提供商（ASP）漏洞”，亨利·普尔（Henry Poole）和史泰尔曼（Stallman）都认为GPL中存在这个漏洞。ASP漏洞意味着软件即服务（SaaS）提供商和主要通过网络运行的其他软件不受GPL许可证条款的约束（或可能会提出豁免）。这是因为他们并没有按照传统意义上的技术“分发”它。

为了弥补这一漏洞，GNU AGPL明确表示，网络使用被视为软件的分发。具体而言，许可证规定：

“GNU Affero通用公共许可证[…]要求网络服务器的操作员向该服务器的用户提供运行在该服务器上的修改版本的源代码。因此，在可公开访问的服务器上公开使用修改过的版本，可以让公众访问修改过的版本的源代码。”

假设你创建了一个软件程序。另一个开发人员获取并修改它，然后通过软件即服务模式向付费客户提供对该修改的访问。在GPLv3下，这种修改基本上将成为专有的，因为它不是技术上分发的。然而，在AGPL下，开发人员需要提供修改后的源代码供下载。

AGPL许可证要求

AGPL许可证基于GPL v3。它有同样的要求，加上关于通过网络远程访问的声明。

AGPL许可代码的用户必须：

• 包括一份完整的许可证文本和版权声明原件
• 说明对原始软件所做的所有重大更改
• 发布基于许可软件的任何作品时，请提供源代码
• 如果该程序被用作消费类设备的一部分，则包括更新和重新安装软件所需的任何安装信息

这些要求与GPL v3的要求相同，不同的是，当代码被修改并通过网络远程提供时，需要共享源代码。AGPL增加了一项要求：

• 如果通过网络让用户可以访问修改后的软件，则必须让这些用户可以使用源代码。

使用许可代码

AGPL许可证允许许可代码的用户：

• 将代码用于商业目的：与GPL v2和GPL v3一样，AGPL对在商业销售的软件中使用代码不施加任何条件。
• 修改代码：用户可以更改或返工代码，但如果他们以任何公开方式（包括通过服务器）发布这些更改/修改，他们必须在AGPL许可下以源代码形式发布这些更新。
• 分发代码的副本或修改/更新版本：只要这些修改也在GNU AGPL下发布，它们就可以分发给其他人。
• 地方保修：原始代码的分销商可以对许可软件提供他们自己的保修。

AGPL许可证不允许代码的再许可；也就是说，您不能对代码进行返工或添加，然后将这些更改公开。原始代码的“开源性”遵循任何更新或添加。GPL v2和GPL v3都包含此规定。

专利权

与GPLv3（但不同于GPLv2）一样，AGPL许可包括明确授予专利权。本质上，这意味着任何创建或贡献原始许可代码的人都“放弃”了他们在该许可下对软件的任何后续重用的专利权。

兼容性

AGPL在技术上与其他许可证不兼容，包括GPLv3。然而，正如GNU上解释的那样。org，开发者可以将GPLv3和AGPL下许可的独立源文件和/或模块组合到一个程序中。

AGPL许可证的使用

由于AGPL对许可代码的重用有很大的限制，开发人员在选择该许可之前，必须仔细考虑他们希望其他人如何与他们的软件交互。他们是否希望自己的代码被其他公司广泛采用？他们是否希望对代码进行任何更改，以保持其最纯粹意义上的公开性或“开源”？

GNU项目建议，任何想要构建通常在网络上运行的软件的程序员都要考虑AGPL。然而，做出这个决定确实有潜在的缺点。在选择这个特定的许可证时，开发人员基本上是确保未来的版本不能成为专有版本，这可能不会使他们的代码在商业软件企业中流行。（例如，谷歌有一项严格的政策，禁止使用AGPL许可代码。）而且，随着SaaS作为一种商业模式的日益流行，该开发人员可能正在将自己从一大片市场中剔除。

以前使用AGPL的一家知名公司是流行的NoSQL数据库程序MongoDB。2018年10月16日之前发布的所有版本均根据GNU AGPL获得许可。然而，在那之后发布的所有内容，该公司都转而使用自己的服务器端公共许可证。

AGPL许可证的未来

总的来说，AGPL并不是比较流行的开源软件许可证之一。目前，只有不到1%的开源项目使用它。不过，目前尚不清楚什么趋势可能会推动AGPL更受欢迎。其他GNU许可证仍然是开源软件生态系统的关键部分，因此AGPL不太可能很快消失。

原文：https://fossa.com/blog/open-source-software-licenses-101-agpl-license/

本文：https://jiagoushi.pro/node/1823

定义：

开源软件（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 项目（如 Linux）具有严密保护且高度自动化的代码控制过程，只允许代码进入主要构建过程经过一些世界顶级操作系统内核专家的严格审查——这种验证水平将使大多数专有代码控制和审查过程相形见绌。
    • 相反，许多使源代码与世隔绝的专有流程在多个层面上都充满了问题，人们有机会插入可能严重损害此类系统安全性的更改。底线是：安全性是一个根据每个案例的实际细节进行最佳评估的过程；无论它是使用专有方法还是 OSS 社区方法开发的，都改变了必须检查的问题。专有方法具有带来更多资金的优势，而社区方法对更多用户来说更可见。当活跃且在全球范围内，OSS 还可以吸引更有可能发现渗透企图的专家。
• 软件认证：寻找它们，支持获得它们，但永远不要依赖它们。如上所述，没有科学证据表明软件认证对软件的现场级可靠性或安全性有任何影响。尽管如此，它们在许多情况下仍然是必需的。对于 OSS，IBM 等公司帮助提供了认证。因此，SE 应该寻找相关 OSS 的认证以防万一，并查看它们与专有等效项的比较。感兴趣的项目也可以帮助 OSS 小组获得认证，例如通过小型专有公司，这些公司通常处理使用特定 OSS 组件的业务方面。最后，无论商业软件组件是否是 OSS 和是否经过认证，都不应假设网络软件系统的整体安全性已经过证明；多层安全是绝对必要的。

References and Resources

1. The MITRE Corporation, 2003, Use of Free and Open-Source Software (FOSS) in the U.S. Department of Defense.
2. Department of Defense, October 16, 2009, Clarifying Guidance Regarding Open Source Software (OSS).
3. DoD NII-CIO, DoD Open Source Software Frequently Asked Questions, accessed April 2, 2014.
4. The White House, Developers, accessed August 5, 2014. (See "Open Source" section for the official links to GitHub and Drupal.org.)
5. GitHub, The White House, accessed August 5, 2014.
6. Drupal, whitehouse, accessed August 5, 2014.
7. O'Reilly, T., October 25, 2009, "Thoughts on the Whitehouse.gov Switch to Drupal."
8. Free Software Foundation, accessed August 5, 2014.

Additional References and Resources

• Clarke, G., October 27, 2009, "US DoD snuffs open-source 'misconceptions'," The Register.
• Coopersmith, A., November 24, 2009, "Sun relicensing to current X.org license," Sun.com.
• Defense Information Systems Agency, Forge.mil, accessed August 5, 2014.
• Drupal - Open Source CMS, accessed April 2, 2014.
• GitHub - Build software better, together, accessed April 2, 2014.
• Google Groups, Military Open Source Software, accessed August 5, 2014.
• Hart, K., October 27, 2009, "Defense Department wants more open source software," The Hill.
• Microsoft Openness, accessed August 5, 2014.
• Open Source Initiative, accessed August 5, 2014.
• Ryan, J., November 25, 2009, "Sun Leaves License Behind", Linux Journal.
• SourceForge - Find, Create, and Publish Open Source software for free, accessed August 5, 2014.
• Top Ten [Linux and BSD] Distributions: An overview of today's top distributions, DistroWatch.com, accessed August 5, 2014.
• ¹ GNU (GNU's Not UNIX) is a UNIX-like operating system developed by the free software movement starting in 1984. In 1992, the almost-complete GNU system was combined with the Linux kernel, producing the GNU/Linux system. The GNU project developed many of the core programs in GNU, but it also included available free software such as the X Window System and TeX.

原文：https://www.mitre.org/publications/systems-engineering-guide/enterprise…

本文：https://jiagoushi.pro/node/1944

Sentry最近宣布创建并采用功能源代码许可证（FSL），这是一种竞业禁止的许可证，两年后可转换为Apache 2.0或MIT。与商业来源许可证（BSL）类似，但竞业禁止期较短，可变性较小，新许可证受到了社区的混合感受。

Sentry认为BSL许可证的额外使用授权对MariaDB、Redis和HashiCorp等不同实现产生了不同的意义，因此功能源许可证被宣传为“自由而不搭便车”的许可证。Sentry声称，FSL使开发者能够有更多的自由，同时防止所谓的搭便车。

Sentry开源负责人Chad Whitacre在解释是什么促使Sentry和Codecov在FSL下重新获得许可时，解释了Sentry认为BSL许可证的两个主要缺陷：

首先，默认的竞业禁止时间段是四年，这在软件世界中是一段非常长的时间。这可能会让人觉得对开源的最终改变只是一种象征性的努力。这几乎可能是100年。（…）更严重的缺陷是BSL有太多的参数：更改日期、更改许可证和额外的使用授权。

更改日期现在设置为两年，是BSL默认值的一半，之后转换为Apache（FSL-1.0-Apache-2.0）或MIT（FSL-1.0.-MIT）。错误跟踪和绩效监控平台背后的公司认为，短期提供了抵御竞争的保护，但也激励了公司继续创新。Percona的创始人、开源倡导者Peter Zaitsev对此并不信服，他评论道：

两年或三年——没关系。你得到的往往是无用的、不受支持的、充满安全漏洞的代码，几乎没有实际价值。

这不是Sentry第一次采用新的许可证，2009年改为BSD-3，稍后改为SBL。2022年收购Codecov后，今年早些时候又进行了一次有争议的许可证变更。Logz.io的技术传道者、Cloud Native Ambassador Dotan Horovits在X（前推特）上总结道：

Sentry 再次获得许可。在成为开源（BSD）11年后，他们于2019年转向非OSS商业源代码许可证（BSL/BUSL）。现在，他们提出了自己的发明：功能源代码许可证（FSL）。最终是另一个“代码可用”。

新的许可证不被承认为自由和开源软件（FOSS），但据作者称，它允许SaaS公司在保护商业利益的同时接受开源原则。Whitacre澄清：

简单地说，你可以用FSL软件做任何事情，除了通过有害的搭便车在经济上破坏它的生产者。（…）我们重视用户自由和开发者的可持续性。自由和开放源码软件（FOSS）只重视用户自由。这就是它成功的根源，也是搭便车问题的根源。

扎伊采夫再次表示不同意：

真正的开源的关键实用价值是可以选择自己做事情，也可以选择供应商。竞业禁止的源代码可用许可证与之根本不一致。

作为公司FOSS Funders承诺的一部分，Sentry最近向开源维护人员捐赠了50万美元。

当你听到“允许”这个词时，你可能会想到一些没有很多规则或限制的东西。在开放源码软件许可方面，这与现实并不遥远。（许可许可证是开放源代码许可证的两大类别之一；copyleft许可证对许可代码的使用有更严格的要求，是另一类。）

通常，许可证下的软件可以修改、复制、添加、删除等，而无需共享这些更新。开发人员可以使用许可的软件，通过更改或添加使其成为自己的软件，将其新版本保留给自己，或者如果愿意，可以共享。这是一个主要的功能，如果你想创建专有软件，你可以销售和保密的竞争对手-和主要原因之一，为什么许可证是受欢迎的。

与使用许可许可代码相关的这些自由与copyleft许可证的更严格要求形成对比，后者要求许可软件的任何衍生作品只能在同一copyleft许可证下分发。这意味着，任何修改或添加原始软件的开发人员在分发包含copyleft许可代码的二进制文件时，通常都需要共享这些更改的源代码。

在本博客中，我们将仔细了解许可许可证的所有内容，包括它们与copyleft许可证的比较、它们的使用案例、历史以及它们在开源软件社区中的角色。

许可证的历史

第一个许可证通常被认为是之前的BSD许可证，它是第一个“官方”BSD许可证（今天称为4条款BSD许可证）的前身。这种“原始BSD”许可证出现在20世纪80年代末。大约十年前，加州大学伯克利分校的计算机科学家开始研究一种基于Unix的操作系统，后来被称为BSD（伯克利软件发行版）操作系统。随着其他机构开始使用该操作系统，一些开发人员开始修改和添加源代码，然后要求将这些更改纳入下一个版本。

1989年，伯克利的Network Release 1包含了BSD许可证的最早前身，基本上表示代码可以重用或修改。毕竟，事情已经发生了。一年后，4条款BSD许可证正式发布。从那时起，3条款、2条款和0条款许可证加入了BSD家族。如今，三条款版本最受欢迎。

MIT许可证是目前使用最多的OSS许可证，与第一个BSD许可证的开发时间大致相同。然而，它的起源有点模糊。在Twitter上回答一个问题时，参与创建原始许可证的两名计算机科学家吉姆·盖蒂斯和基思·帕卡德给出了他们记忆中的体验。两人都帮助麻省理工学院开发了X Windows系统。

据Packard称，1985年X版本6发布时，他们为其添加了一个许可证。事实证明，在这个许可证下分发软件是一个巨大的挑战，这促使Getty打趣说，他们应该干脆放弃它。然而，将其公之于众是行不通的，因为那样IBM就不会使用它了。因此，他们咨询了麻省理工学院的律师，制定了一种语言，表明任何人都可以使用和修改该软件。

随后的版本包含类似的措辞，该许可证被称为X Consortium许可证。事实上，当开放源码倡议（OSI）在1999年分享其第一批经批准的OSS许可证时，它指出MIT许可证有时被称为X Consortium许可证。然而，X Consortium许可证和1998年发布的麻省理工学院许可证的“官方”版本并不是同一个许可证，而是用不同的语言表达了类似的观点。

尽管如此，现在的麻省理工学院许可证的前身似乎已经存在了近十年，而现在的版本才被编写出来。如果是真的，这将使其成为最早的开放源码软件许可证之一。

宽容许可与版权许可

开源软件许可证可以分为两类：宽容许可和版权（Copyleft ）许可。两者之间的主要区别涉及许可证合规性条件以及对代码的任何更改必须如何“公开”。

一般来说，许可证只要求用户在许可软件的任何再分配中包括两件事：原始版权声明和许可证文本的副本。Copyleft许可证也有这种情况。然而，它们还要求用户向二进制文件的所有接收者提供任何修改的源代码，并将这些修改放在同一个许可证下。因此，所有代码的重写最终都与原始代码一样“开放”。

需要注意的一点是：许可证虽然容易遵守，但并不等同于将软件放入公共领域。虽然存在与公共域等效的OSS许可证（例如BSD 0-clause许可证或Creative Commons 0），但许可证不属于这一类。一般来说，在公共领域的作品没有使用要求，而许可证确实有规定，无论多么微小。

许可使用案例

为特定软件项目选择正确的许可证取决于许多因素，例如您希望其他开发人员如何与您的代码交互，以及您对代码的更改是如何开放（双关语）的，使其成为专有/封闭源代码。

不过，在一些一般情况下，许可证可能是最合适的选择。例如，如果您：

• 希望让代码变得简单，并吸引其他人（包括大型商业企业）使用您的代码。毕竟，如果一家大牌科技公司不能保留自己的专有版本，他们可能不想修改你的软件。
• 需要你的项目与GPL许可代码兼容。例如，BSD或MIT许可证与GNU GPL许可证系列的每个成员都兼容。
• 正在社区内创建一个项目，该项目倾向于使用特定的许可证。在这种情况下，同龄人的压力是一件好事。例如，如果其他人都在使用麻省理工学院的许可证，你可能也应该这样做。
• 不想花费时间或资源来管理复杂的许可证合规性问题。有了许可证，开源用户就不必担心源代码泄露的要求

如果您仍在试图决定使用哪个许可证，本指南和其他OSS贡献者一样可以提供帮助。

宽容许可证的类型

• 与copyleft许可证（分为“强”和“弱”两种）不同，许可许可证并没有整齐地归类。然而，最受欢迎的选择各有其独特之处。例如，麻省理工学院的许可证以其简洁、灵活和易于使用而闻名。基本上，它规定用户可以对代码做任何他们想做的事情，包括复制、修改、添加、分发和销售代码，只要他们包含许可证文本和原始版权声明。
• BSD 3条款许可证在功能上与MIT许可证非常相似。另一个条件是，未经明确书面许可，BSD 3许可代码的用户不得使用项目或其贡献者的名称营销或推广其衍生作品。对于那些不希望自己的软件在没有信用的情况下被使用的OSS开发者来说，这个警告让它成为一个有吸引力的选择。但是，可以说，没有一种许可首先授予任何此类权利——这更像是商标许可，而不是版权许可。
• 在许可证生态系统中，Apache许可证2.0有点突出。它包括通常的规定，但也要求用户说明对软件的重大更改。不需要发布修改的源代码；仅包括任何修改通知就足以遵守许可条款。此外，Apache License 2.0还包括明确授予专利权和防御性终止条款，这为许可方和被许可方提供了一些法律保护。

OSS社区中的宽容许可证

许可证在OSS社区中越来越流行。超过一半的开源项目使用MIT许可证或Apache许可证2.0，大约三分之二的项目使用某种类型的许可证。

许多备受瞩目的OSS项目正在使用许可证，这增加了这些许可证受到的关注。例如，Ruby on Rails、jQuery和Angular使用MIT许可证。而Apache2.0是Kubernetes、TensorFlow和Swift的首选许可证。事实上，所有Apache基金会项目（其中一些都被广泛使用）是在Apache 2许可证下进行的。

随着使用量如此强劲而稳定的增长，许可证似乎并不是一个暂时的趋势。最有可能的是，这些许可证只会继续在OSS社区中发挥越来越大的作用。

原文：https://fossa.com/blog/all-about-permissive-licenses/

本文：https://jiagoushi.pro/node/1825

目前有数百种不同的开源软件许可证在使用，其条款从滑稽的（即Beerware许可证）到经典的（即GPL v2）。

不过，从广义上讲，OSS许可证可以分为两类：permissive和copyleft。

Copyleft许可证——本博客的主题——通常要求Copyleft许可软件的任何衍生作品在与原始软件相同的许可证下发布。换句话说，修改后的代码必须与原始代码一样“开放”。这一要求的实际后果之一是，如果OSS用户发布包含copyleft许可组件的二进制文件，他们可能会被迫以源代码的形式发布自己的更改或添加内容。

Copyleft许可证与许可证形成对比，后者往往对许可代码的使用几乎没有限制。他们也没有任何这样的代码共享要求，所以“开源”不一定会持续到衍生作品中。这是一个特性还是一个bug，取决于你如何看待它。对于专有软件的开发人员，必须谨慎使用copyleft许可证下的软件。对于自由开源软件的开发者来说，copyleft是一种确保软件仍然免费可用的方法。

在本博客中，我们将详细介绍copyleft许可证，包括它们的历史、它们与许可证的比较，以及强和弱copyleft许可证之间的区别。

版权许可证的历史

“copyleft”一词的出现与人们熟悉的“版权”一词正好相反1976年，开发者王立辰博士在他的Palo Alto Tiny BASIC编程语言的发布通知中添加了这样一段幽默的文字：“版权保留所有错误。”这句话是对微软联合创始人比尔·盖茨的挖苦。比尔·盖茨曾抱怨软件爱好者盗用该公司的Altair BASIC程序，该程序当时的售价为每流行音乐150美元。

这句话没有任何法律效力，但它很吸引人（如果我们这么说的话，也很有趣）。它还将“免费”（如免费使用、复制、修改等）软件（Tiny BASIC）与专有/版权软件（Microsoft的Altair BASIC）进行了对比。

20世纪80年代，当著名的自由软件倡导者理查德·斯泰尔曼（Richard Stallman）将这个词作为GNU项目的核心时，事情变得更加严重。根据史泰尔曼的说法，一个真正的自由软件程序将允许：

• 1.按照自己的意愿运行程序的自由
• 2.复制程序并将其分发给朋友和同事的自由
• 3.通过完全访问源代码，可以随心所欲地更改程序
• 4.发布改进版本的自由，从而帮助建立社区

Stallman在构建GNU操作系统时考虑到了上述自由以及copyleft的概念。“剩下的是什么？”第页GNU。org用以下术语解释copyleft与软件的关系：

“要复制一个程序，我们首先声明它受版权保护；然后添加分发条款，这是一项法律文书，赋予每个人使用、修改和重新分发程序代码或其衍生的任何程序的权利，但前提是分发条款不变。因此，代码和自由在法律上是不可分割的E

“专有软件开发商使用版权剥夺用户的自由；我们使用版权保障他们的自由。这就是为什么我们将名称改为“版权”，将“版权”改为“版权保留”（GNU.org，“什么是Copyleft？”）

最初的GNU通用公共许可证（GNU GPL）是Stallman在1989年为GNU操作系统和相关程序编写的，它将copyleft的概念明确化。从那时起，GNU GPL已经更新了好几次。最新版本GNU GPL v3于2007年发布。其他copyleft许可证，如Mozilla Public License 2.0和Eclipse Public License，也在OSS社区获得了吸引力。目前，开源软件中使用最多的copyleft许可证是GNU GPL v2，它已经被广泛使用了20年。

Copyleft与许可证

copyleft和permissive许可证之间的主要区别在于合规性要求以及任何代码修改的“开放”程度。通常，许可证只要求用户在重新分发许可代码时包含许可证文本的副本和原始版权声明。否则，他们可以用它做任何他们想做的事。例如，开发人员可以获取代码，对其进行修改以创建新程序，然后将该程序的代码保留给自己，使其成为专有和封闭源代码。然后，他们可以将该程序商业化销售。

另一方面，Copyleft许可证有更严格的条件。与许可证一样，它们通常要求用户包含原始版权通知和许可证文本，但它们也要求用户在与原始许可证相同的许可证下，将任何修改或衍生作品的源代码提供给二进制文件的所有接收者。

Copyleft许可使用案例

任何给定软件的最佳许可类型取决于许多因素。在为自己的OSS项目选择许可证之前，先考虑用软件实现什么，以及希望其他人如何与代码进行交互。

例如，如果您：

• 想与OSS社区分享改进吗
• 相信构建软件的协作方法
• 想把你的项目商业化吗
• 不希望你的代码被其他人专有
• 正在社区中创建一个项目，该项目倾向于使用特定的copyleft许可证

另一方面，如果您：

• 不想在许可证合规性上花费太多时间（或担心）
• 想让别人尽可能容易地使用你的代码吗
• 正在社区内创建一个项目，该项目倾向于使用特定的许可证

幸运的是，有很多资源可以帮助您为项目选择正确的许可证（例如，本指南）。另外，你可以随时询问OSS社区的其他成员。

Copyleft许可证的类型

Copyleft许可证有两种类型：强许可证和弱许可证。这种区别取决于有多少新代码或相邻代码受copyleft许可证的约束。

在像GPL这样的强版权许可下，如果你重新发布了一个包含其他人编写的GPL代码的程序，你必须使你的整个程序在GPL下可用。包括任何链接库或程序的其他组件。属于这一类别的许可证包括GPL v2和GPL v3，以及Affero GPL许可证（AGPL）。

较弱的copyleft许可证也要求用户发布其更改。然而，这一要求适用于更窄的代码集。Mozilla Public License 2.0就是一个弱copyleft许可证的例子，说明了这一原则。如果用户将MPL许可代码保存在单独的文件中，那么他们可以将其与其他和/或修改的代码结合起来，创建一个聚合工作。新添加的文件可以在不同的许可证下发布，或者保留专有（封闭源代码）。这有时被称为基于文件的copyleft。另一个例子是LGPL许可证，它主要适用于库。对库的任何更改必须在同一许可证下发布，但仅使用库的作品除外。

LGPL也有不同的要求，这取决于库与程序其余部分的集成方式。例如，您可能听说LGPL要求动态链接库。虽然对于静态链接的程序来说，遵守LGPL是可能的，但有更多的要求——因此LGPL代码的动态链接是最佳实践。

值得注意的是，copyleft许可证并不仅仅存在于开源软件中。例如，知识共享（CC）许可证是一种版权许可证，通常适用于照片、音乐等艺术作品。

OSS社区中的Copyleft许可证

目前，许可许可证是开源软件中使用最多的许可证类型，最流行的是MIT许可证和Apache许可证2.0。（不同的来源报告了不同的数字，但一般估计大约65-75%的OSS项目拥有许可证。）

但copyleft许可证在OSS生态系统中也扮演着不可或缺的角色。例如，GPL系列很可能仍然是最常用的OSS许可证之一——作为Linux内核的首选许可证，它在软件开发生态系统中占有特殊地位。

此外，copyleft许可证可以帮助公司和开发人员进一步实现“免费”软件的目的，这种软件可以共享改进并回馈开源软件社区。只要OSS贡献者继续重视这种心态，copyleft许可证就会一直存在。

原文：https://fossa.com/blog/all-about-copyleft-licenses/

本文：https://jiagoushi.pro/node/1826

与许多其他公司一样，HashiCorp放弃了开源方法，该方法使其产品开始获得源代码可用的商业源代码许可证（BSL）。

互联网时代的一个不方便的事实是，使现代世界成为可能的一切——智能手机、视频游戏机、云计算，甚至火星独创直升机——在某种程度上都是由开源软件提供动力的。

该软件通常是由来自世界各地的数十、数百甚至数千名开发人员共同构建的，通常没有报酬的期望，也很少得到公众的认可。然而，他们创建的代码已经出现在商业产品中，这些产品可以为母公司带来数百万或数十亿美元的收入。

一些人认为，创造的价值和获取的价值之间的差距是开源给世界带来的所有好处的必要和可接受的副作用：从哲学上讲，拥有人人同时拥有的免费代码的好处超过了一家互联网巨头为了自己的利益而使用这些代码的不可避免的挫败感。

但在过去几年里，一种新的视角正在深入人心，尤其是在那些将整个业务建立在构建开源软件上的公司中。虽然细节因情况而异，但结果是一样的：开源公司以保护其收入流的名义，对其代码的使用方式进行了限制。

最新的例子是关于Terraform的未来的骚动，Terraform是流行的“基础设施即代码”工具。Terraform的创建者HashiCorp最近宣布决定更换该软件的许可证。Terraform现在使用的是商业源代码许可证（BSL）v1.1，而不是Mozilla开源Mozilla公共许可证v2.0（MPL 2.0），后者自2014年开始使用，它被认为是“源代码可用”，而不是任何传统意义上的开源。作为回应，Terraform社区于周五宣布了OpenTF，这是Terraform的一个分支，源于对HashiCorp的决定的失望。

那么，在一个开源软件公司发现自己与自己的社区存在分歧的地方，我们是如何走到这一步的呢？和往常一样，答案是跟着钱走。

没有免费午餐

开源倡议的官方开源定义中所包含的开源概念非常清楚，它“不仅仅意味着访问源代码”。除其他外，“开源”还意味着允许最终用户根据自己的需求调整和修改源代码，并将其投入生产，而不侵犯任何人的版权。

事实证明，对于开源社区来说，这个元素是一把双刃剑。这意味着企业用户更有可能采用开源软件，因为根据定义，他们可以使用、调整、扩展，甚至可以使用它来构建商业产品，而无需担心许可审计或知识产权诉讼。

然而，另一方面，它为公司——尤其是亚马逊网络服务或阿里云等主要云提供商——提供了完整的许可证，可以获取开源代码，对其进行调整，并将其出售给自己的客户以换取现金。随着全球云市场日益扩大，这些基于开源的产品的目标市场只会增长，其收入也会随之增长。

对于许多从事开源项目的志愿者来说，这种动态导致了压力和倦怠的增加，因为他们没有得到任何报酬来做支持现代互联网的重要工作。一些人呼吁大公司为开源做更多的事情，提供更多的资源，尽管像GitHub Sponsors和Ko-fi这样的平台已经出现，帮助开发者众筹资金支持他们的工作。

在企业层面，类似的情绪已经慢慢但肯定地站稳了脚跟。开源的当前时刻真正开始于2018年，当时MongoDB和Redis实验室在其许可协议中添加了新的条款，限制了转售其代码的能力。其他一些公司也纷纷效仿，包括蟑螂实验室、Confluent和Sentry。值得注意的是，在这样做的过程中，Sentry创建了HashiCorp刚刚为Terraform采用的商业来源许可证（BSL）。

哲学之战

最终，围绕这些主题的讨论已经成为一场哲学之战，一方认为开源的完整性比其他任何东西都重要，另一方认为商业案例对软件的许可方式更加谨慎。

例如，最近围绕开源的最大爆炸是Red Hat决定将其旗舰Red Hat Enterprise Linux操作系统的源代码仅提供给付费客户。

此举遭到了许多人的敌意：在被IBM以340亿美元收购之前的几十年里，红帽一直被视为如何在不牺牲开源理想的情况下建立大规模业务的光辉榜样。作为回应，Red Hat将这一决定视为保护RHEL未来的必要决定，特别是为了阻止Oracle和SUSE等竞争对手使用其代码并构建自己的Linux发行版。

HashiCorp更改许可证的理由与Red Hat类似。

“还有其他供应商为了自己的商业目标，利用纯OSS模型，社区在OSS项目上工作，而没有提供实质性的贡献。我们不认为这符合开源的精神。因此，我们认为商业开源模型需要发展，生态系统才能继续提供开放、免费的软件。”HashiCorp联合创始人兼CTO Armon Dadgar在一篇博客文章中写道。

批评人士指责，上市的HashiCorp的财务表现出强劲的增长，破坏了这一举措对业务未来绝对必要的观念。

不管怎样，这仍然是一个艰难的局面，没有简单的答案：开源过去、现在、将来都是互联网经济不可或缺的一部分。但同样真实的是，使用免费软件很难赚钱。开源社区将继续在所有这些方向上推动和拉动，直到达成合适的中间立场。然而，与此同时，许可证发放的水域仍然异常动荡。

了解开发人员使用的顶级开源许可证，包括 20 个最受欢迎的开源许可证及其法律风险类别。

如果您是软件开发人员，您可能会使用开源组件和库来构建软件。您知道这些组件受不同的开源许可证管理，但您知道所有许可证详细信息吗？特别是可能带来合规挑战的技术性和有些复杂的许可条件？

在这种情况下的主要问题是开源许可证是主观的。它们的解释取决于许可软件的技术用途。因此，很难确定使用开源软件的法律风险，尤其是对于通常不是法律专家的开发人员而言。开发人员需要的是根据它们在法律合规方面带来的风险对许可证进行广泛分类。

在这里，我们根据条款和条件以及潜在的法律风险将最受欢迎的开源许可证分为三大类。

风险最高的开源许可证

以下是开发人员使用的最流行的开源许可证列表及其风险分类，如上所述。此分类只是一个指南，不应用于决定使用受每个许可证管理的开源软件。开发人员应咨询其法律/技术团队，以获取有关许可证合规性的进一步指导。

其他流行的开源许可证风险

这些许可证没有排在首位，但仍在广泛使用中。

低风险：宽容许可证

许可许可证通常没有真正的限制条件。相反，它们通常要求您在分发自己的软件时保留版权声明。这基本上意味着您可以根据需要使用和更改开源软件，只要您保持版权声明不变。此类别中的一些顶级开源许可证是 Apache 和 MIT 许可证。我们将许可许可证评为低风险许可证。

中等风险：半宽容许可证

半许可许可通常要求，如果您修改开源代码，您必须根据给定许可的条款使这些修改可用。其中一些许可证明确定义了修改是什么。例如，他们可能认为将未经修改的开源代码复制到专有代码中是一种修改。为了遵守许可义务，开发人员必须发布源代码（原始的、修改的和新添加的）。此类别中最流行的开源许可证包括 Mozilla 和 Eclipse 公共许可证。我们将半许可许可证评为中等风险许可证。

高风险：限制性许可证

一些顶级开源许可证，例如 GPL 3.0 和 AGPL，具有相当的限制性。根据您将开源软件与专有软件集成的方式，您可能会面临重大风险。在最坏的情况下，您可能需要在相同的许可下发布您的专有软件——免版税。我们将限制性许可证评为高风险许可证。

如何管理开源许可风险

Black Duck 软件组成分析使您能够发现专有软件中的开源组件及其相应的开源许可证和漏洞，以帮助减轻法律和安全风险。 Black Duck 应用最先进的扫描机制来查找您的软件中使用的最全面的开源软件（源代码和二进制文件）列表。此外，Black Duck 提供了通过基于规则的引擎对源自各种许可证和安全漏洞的操作风险进行情境化的功能。

原文：https://www.synopsys.com/blogs/software-security/top-open-source-licens…

本文

没有，但功能源代码许可证来了，它进一步搅乱了开源许可的水域

观点很久以前，当我们用穿孔卡和磁带加载软件时，所有的程序都是“自由软件”和“开源”。然后，专有软件出现了，一切都变了。但程序员们奋起反抗，开发出了第一个自由开源软件的正式定义。

如今，非开源代码是罕见的例外。但这并没有阻止那些将开源误认为是商业模式而不是开发模式的公司尝试将专有方法与“开源”代码相结合。最新的是Sentry的功能源代码许可证（FSL）。

遵循服务器端公共许可证（SSPL）<Server-Side Public License (SSPL)>、通用条款<Common Clause,>和商业源代码许可证<Business Source License>的传统，FSL<FSL >认可开源的重要性，同时嘲笑其核心，声称其方法是“没有搭便车的自由”

请

Sentry是一个面向开发者的应用程序代码监控服务，最初只是Django的一小段代码，Django是一个开源的高级Python web框架。如今，它仍然是开源代码开发中使用最多的。没有开源，Sentry 就不存在。

现在使用“源代码可用”或其他半开源许可证的公司也没有。他们都是从开源公司开始的，然后为了实现利润最大化，他们从贡献者那里免费重新许可他们获得的代码，以锁定代码。

正如开放源码倡议（OSI）董事会副主席Thierry Carrez告诉我的那样，“一些公司通过利用他们可用的开源代码来构建他们的软件，在他们的依赖关系中使用数百个开源包之前无需征得许可。他们通过公开承诺开源原则来建立自己的声誉。但为了获得更多的价值，他们后来决定放弃最初使他们成功的模式。”正是如此。

Sentry、MariaDB、Redis和HashiCorp，仅举几家前开源公司的例子，由于权利激进的贡献者许可协议（CLA），它们可以逃脱惩罚。这些是法律文件，定义了贡献者为其代码在开源项目中使用而授予的条款。虽然一些CLA，如Apache软件基金会的CLA或Linux的开发者原产地证书，只是用于保护其项目的合法权利，但其他CLA则用于获取您的代码及其版权，如MongoDB的贡献者协议。有了这些CLA，公司就可以以他们喜欢的任何方式使用和重新许可您的代码。

正如SourceHut创始人兼首席执行官德鲁·德沃（Drew Devault）在谈到Elasticsearch及其从开源到代码可用(source available)的转变时所说，“Elasticsearch属于1573位贡献者，他们保留了自己的版权，并授予Elastic不受限制地分发其作品的许可。这就是Elastic在决定Elasticearch不再是开源时利用的漏洞，他们从一开始就有意引入这个漏洞……Elastic向1573位参与者中的每一位贡献者以及所有给予Elastic信任、忠诚和赞助的人吐口水。”

现在，我们来看看Sentry，这是同一个故事，但有不同的许可证。公平地说，Sentry长期以来一直在使用源代码许可证。在该公司创建并采用FSL之前，自2018年以来一直使用BSL。如果有人还在向哨兵捐赠代码，他们必须确切地知道自己在做什么。

那么，为什么要制作新的许可证呢？Sentry开源负责人Chad Whitacre解释道：“BSL有两个主要缺陷。首先，默认的竞业禁止期是四年，这在软件界是一段很长的时间。这可能会让人觉得最终改为开源只是象征性的努力。这几乎可能是100年。对于Sentry，我们选择将其收紧到三年，但即使这样也可能太长了。”

在此期间之后，代码将引用Apache 2.0或MIT许可证。但是，这并不像听起来那么慷慨。根据FSL，您可以将其代码用于“竞争使用以外的任何目的。竞争使用是指自我们提供软件之日起，在与软件或我们使用软件提供的任何其他产品或服务竞争的商业产品或服务中使用软件。”

换句话说，您可以查找但不能运行业务的代码。有关更多信息，您可以查看Apache和MIT的FSLed版本。就我而言，两者都不是开源许可证。

Whitacre补充道，“更严重的缺陷是BSL有太多的参数：更改日期、更改许可证和额外使用授权。额外使用授权是最大的问题。这是一个巨大的空白，实际上意味着每个BSL都是不同的许可证。”

我无法反驳。每家公司的BSL都是独一无二的。这也意味着，当客户与使用BSL的公司签订合同时，他们很难确切地知道自己合法获得了什么。Sentry希望FSL能使其产品和服务对客户更有吸引力。

也许会的。但我同意Carrez的观点，他说：“发布另一个许可证变体，剥夺开发者在技术选择中的自我主权，这并不是什么新鲜事：它仍然是要剥夺整个软件生态系统的基本自由，以明确地维护对其专有软件的所有权，并允许你使用它。”。这不是开源的：它是用敞开的洗过的衣服包裹起来的专有门卫。"

随着 RELEASE.2021-05-11T23-27-41Z MinIO 已完成向 GNU Affero 通用公共许可证 v3.0 (GNU AGPL v3) 许可证的过渡，这意味着服务器、客户端和网关也将在 GNU AGPL v3 下获得许可.您可以阅读更多关于自由软件基金会和开源计划的许可的信息。客户端 SDK 将保留在 Apache v2 下，文档将移至 CC BY-SA 4.0。

我们在 18 个月前的 2019 年 10 月开始了 AGPL v3 之旅。Kubernetes 多租户运营商堆栈、管理和监控控制台、KES 加密服务、Sidekick 负载均衡器都从 AGPL v3 许可证开始。从那时起，我们将绝大多数代码置于此许可之下，并且在这一意图上保持透明，包括在我们的主页、下载页面、定价页面和合规页面上的指定。此时，任何合理的生产环境都很难避免对 AGPL 的依赖。在相同的 copyleft 许可下统一重新许可剩余的核心组件将消除由混合许可模型引起的任何歧义。转向单一许可证使我们能够简化设计和代码组织，例如，我们现在将新的管理控制台和对象浏览器嵌入到服务器二进制文件中。

几周前，MinIO 更新了文件的标题以准备此更改。当时有些人认为这是一次“无声”的更新。它不是。 MinIO 没有私人仓库——我们所做的一切都以完全透明的方式直接进入上游。许可证更改没有什么不同。

从那时起，MinIO 对所有贡献的代码进行了彻底的分析。本着透明的精神，我们将发布该分析以供社区审查。自项目开始以来，我们分析了每一个贡献，并将它们分为四组。

第一组是 AGPL v3 版本中包含的具有版权的贡献。第二组是 AGPL v3 版本中包含的非版权价值贡献。第三和第四组是随着时间的推移被重写或从代码中编辑出来的版权和非版权价值贡献。我们希望社区花时间审查我们的分析（服务器+客户端），并就任何遗漏提供建设性的反馈。

第一组贡献的源代码许可证（包括在 AGPL v3 版本中的具有版权的贡献）仍然在 Apache 许可证 2.0 下。它们被放置在自己独立的“-contrib”文件中。尽管存在一些 Apache License 2.0 代码，但 MinIO 服务器、网关和客户端的许可证现在是 AGPL v3。

展望未来，我们将使用 AGPL v3 许可证作为基础，与贡献者就版权转让协议进行接触。

强调我们的许可变更是我们对开源软件的承诺。作为开源精神的坚定信徒和社区中受人尊敬的成员，我们渴望用户、分销商和其他社区成员广泛使用和改进我们的代码。自由软件基金会的“copyleft”许可证不仅保护了程序员的自由，更重要的是，它们通过防止专有衍生品和分叉来保护所有用户的自由。 MinIO 的不懈努力是确保程序的所有用户或基于该程序的任何工作都拥有所有四项基本自由。

MinIO 对其对开源的承诺深感自豪，我们很高兴与我们的客户、合作伙伴和社区合作，继续构建地球上最好的开源对象存储。

作为一家开源公司，这对我们来说是一个激动人心的时刻。我们被广泛认为是当今市场上领先的对象存储套件——当我们五年前做出第一次承诺时，这似乎是非常有抱负的。此外，我们在 Kubernetes、可管理性和 SUBNET 方面有一个非常积极的路线图——这些领域将使个人和企业用户受益。

LEADx 开源顾问办公室 (OSCO)

此 RFD 创建了一个角色，即开源顾问办公室 (OSCO)，它充当有关开源政策的咨询和批准的联络点。 OSCO 负责平衡我们围绕开源的原则与组织风险——目标是遵守我们的开源原则，同时最大限度地降低风险。如果需要额外的律师（例如法律顾问），则由 OSCO 做出决定。这个角色远非全职工作。预计该职能将由 CTO 或同等人员执行或委派。

开源使用

根据以下常用许可许可的任何开源组件都可以自由使用，无需额外披露或获得 LEADx OSCO 的批准：

• Mozilla Public License, 1.0, 1.1 and 2.0 variants
• MIT License
• Berkeley Software Distribution (BSD), 3-clause, 2-clause and 0-clause variants
• Apache License, 1.0, 1.1 and 2.0 variants
• Common Development and Distribution License (CDDL)

此外，以下不常用许可证下的任何开源组件都可以免费使用，无需额外披露或批准：

• PostgreSQL License
• Python Software Foundation License
• Public Domain
• Artistic License
• zlib/libpng License
• PHP License
• ICU License
• Eclipse Public License

具有以下许可的组件可以免费用于内部使用（即不作为任何服务或软件产品的一部分），但只能在与 OSCO 协商后用于外部使用（服务或软件产品的一部分）：

• GNU Public License (GPL), v2 and v3
• Lesser GNU Public License (LGPL)

以下许可下的软件只能用于内部使用（即，它们不得用作任何服务或软件产品的一部分），并且使用始终需要 OSCO 的明确许可：

• Affero General Public License (AGPL)
• Server Side Public License (SSPL)
• Confluent Community License
• Redis Source Available License
• Any license bearing a Commons Clause addendum

开源贡献

我们相信回馈我们使用的项目，并寻求在适当的地方积极推动变革。

个人贡献

来自 LEADx 的任何开源贡献都必须具有完成工作的工程师（或工程师）的个人归属。 （通常，此属性将采用 git commit 的 Author 字段的形式，该字段可能与 Commit 字段不同。）任何时候都不应将一位工程师的工作冒充为另一位工程师的工作；每个工程师都有责任确保他们的同行得到适当的认可。此外，即使有归属，通常也应该让原始工程师意识到他们的工作正在被上游化。这是一种礼貌（并且可能有助于告知上游的测试或正确性）；如果无法与原始工程师合作，则不应妨碍他们提交的工作。

版权

LEADx 拥有所有开源贡献的版权，但如何归属将取决于项目的具体情况。对于具有基于文件的 copyleft 许可证（例如 MPL、CDDL）的文件，我们期望每个文件都将承担文件中材料的版权所有者。对于其他许可证，这会有所不同；项目贡献者拥有版权并不少见，并有一个单独的文件说明这些贡献者（例如 AUTHORS 或类似名称）。在此模型中，电子邮件地址必须包含作者的公司电子邮件地址（例如“@leadx.org”）。

版权声明

不同项目的版权声明机制不同，法律顾问的意见会因年份机制等而异。我们的偏好是我们修改的每个文件都带有一个版权标题，其中包括“版权”一词、最近修改的年份和我们的身份，例如：

/*

 * 版权所有 2019 LEADx, Inc.

 */

如果存在具有此类版权的现有区块，则应将我们的版权添加到其中，例如：

/*

 * 版权所有 (c) 2016、2017 Delphix。版权所有。

 * 版权所有 2016 Nexenta Systems, Inc.

 * 版权所有 2017 RackTop Systems。

 * 版权所有 2019 LEADx, Inc.

 */

如果项目在呈现版权的方式上有所不同（例如，具有年份范围，带有“（c）”符号等），这些都是可以接受的。但是，我们不允许任何没有任何 LEADx 归属的贡献。

来自第三方的贡献代码

有时我们希望将来自第三方的源代码集成到其他开源项目中。如果第三方来源尚未开源，则此活动必须与 OSCO 协同完成，OSCO 将负责确保第三方已纵容此活动并适当降低风险。

微量变化

某些更改可以被视为微不足道，并且不需要版权声明或更新。这些变化包括：

• 纯删代码
• 纠正拼写或语法
• 仅更改代码注释

一般来说，任何代码更改——无论多么小——都不应被视为微不足道。

执行

为开源项目做出贡献的一个挑战是，我们希望我们的员工能够专业地与非 LEADx 员工的人打交道。我们期望开源参与中的行为将反映我们工作场所的专业精神。如果情况并非如此——如果我们认为社区中其他人的行为违反了我们对自己行为的标准——则应该采取行动。希望举报此行为的员工应向 LEADx HR 举报。 LEADx HR 将与员工一起确定正确的行动方案，首要任务是保护员工。

贡献者许可协议

如果需要贡献者许可协议，应咨询 OSCO。大多数 CLA 是无害的，但遗憾的是需要正式的 OSCO 许可。

开源创作

当我们创建全新的软件时，我们压倒性的偏见是开源它。即使我们选择不开源新软件，也应该始终以开源的理念来创建它。这意味着应该基本上遵循这些准则。

存储库

在没有得到 OSCO 的明确许可的情况下，所有新的存储库都应该在 BitBucket 中，在“leadx”BitBucket 帐户下（即，不在个人帐户下）。

License

对于任何由 LEADx 创建的新开源软件，Apache 2.0 许可证通常应该是首选许可证。例外情况应该是任何属于较大生态系统的一部分且具有现行许可证的软件，在这种情况下，可以使用现行许可证。

安全

尤其是在我们广泛的开源配置下，在源自 LEADx 的存储库中，很容易意外泄露秘密。当然，存储库中不应该有生产密钥材料或密码，即使是私有的。我们还需要注意可能用作测试数据的生产数据。这些数据可以采取微妙的形式，例如一个签名的 Manta URL，指向其他私人数据。不幸的是，代码审查可能为时已晚，因为我们的代码审查也可以公开访问。除了非常注意之外，这里没有机械指南！

行为守则

我们历来没有为我们的存储库采用正式的行为准则，但这只是因为我们的许多开源存储库早于它们的扩散。在吸引注意力的存储库中（以使用、贡献者、问题等的形式），正式的行为准则可能是明智的。这应与 OSCO 协商完成，但建议项目使用贡献者公约的衍生版本。

原文：https://leadx.org/open-source/

本文：https://jiagoushi.pro/node/1954

漏洞并不是开源软件使用带来的唯一风险。 了解如何最好地降低许可风险，以确保您的团队在使用开源代码进行构建时满足所有法律要求。

随着数字化转型的加速，开源代码组件的使用正在爆炸式增长，这要归功于它们为应用程序开发团队提供的速度、灵活性、可扩展性和质量。但是，牺牲是扩大了攻击面，并带来了新的风险，例如增加了法律和知识产权风险。

开源软件天生就受知识产权保护，特别是版权法。一旦开发人员在其应用程序构建中使用开源软件，他们的组织就有义务满足相关许可中指定的任何条款或条件。这就是为什么许多在云迁移中走得更远的组织在保留人员或员工上拥有特定的开源法律资源。

那么为什么没有更多的企业密切关注他们的应用程序开发团队对开源组件的使用和风险缓解呢？让我们看一些场景。

我确信我的组织的开发团队没有广泛使用开源代码，开源许可证有什么大不了的？

嗯，简单地说，如果一个组织在没有满足许可证要求的情况下发布包含开源软件的应用程序，那么他们就是侵犯知识产权，需要承担法律责任。根据 Snyk 的说法，现在至少 80% 的给定应用程序是开源的。组织需要更加了解任何影子开源的使用。不仅版权所有者可以起诉该组织侵权，还有非营利组织，例如监控开源软件使用情况的软件自由保护协会，一旦发生侵权行为，就会提起诉讼。这些诉讼不仅会造成金钱损失，还会造成客户和公共关系的噩梦！

开源许可证只需要一个脚注确认，对吗？

了解您正在处理的内容非常重要，这样您的组织才能遵循最佳行为。有两种主要类型的开源许可证。许可许可遵循基本的版权概念，主要只需要归属于原始开发者，其他不多。而 Copyleft 许可（意为与版权相反）则回归到传统的软件自由概念，并将其构建到许可要求中以促进代码共享。

许可许可证由于其简单性和易用性而对两个业务更友好。因此，它们代表了大多数开源许可证也就不足为奇了，在 2020 年占 76%。常用的许可许可证是 MIT 许可证，通常因其简短而简单的性质而被选中。该许可证授予用户重新使用软件的完全权限，唯一的要求是在分发软件时必须包含许可证文本和版权声明。

Copyleft 许可证，通常是通用公共许可证 (GPL) 的版本，在商业软件应用程序代码库中使用时会产生风险，因为它可能会导致整个应用程序的知识产权出现问题。因此，许多组织将其系统中任何 GPL 许可证的相关风险级别预设为高。

最近，由于许多开源许可证的扩散，随着大型企业组织将开源代码作为商业服务发布，拦截开源的货币化，出现了一个新的类别。第三种类型称为可用源，尽管它类似于开源，但在技术上有所不同，因为需要增加限制以防止公司利用它。从本质上讲，它使作者能够出于协作目的公开共享他们的代码，但阻止它被用作商业服务。

当开发人员构建可能存在许可冲突的开源代码时，需要进行风险调查。然后，团队必须决定他们是否可以减轻对应用程序代码的责任，或者是否需要对其进行更改以删除此部分。然而，结果是增加了发布前的时间。出于这个原因，组织的法律团队通常有预先设定的开源许可指南。

没有许可证的开源软件怎么样，是免费的吗？

简而言之，没有。默认情况下，该软件受专有版权保护，未经许可，即使被称为开源，使用也是非法的。在满足条款之前，该许可证提供了在没有侵权风险的情况下使用、复制、分发或修改软件的许可。

定制的开源许可证

开发人员有时会编写自己的许可证或更改标准许可证的条款。尽管通常是出于好意，但它们会增加歧义。那里有一些非常疯狂的许可证，比如 Beerware 许可证，基本上说如果你喜欢这个软件，作为回报，你应该给作者买一杯啤酒，或者以他们的名义喝一杯。另一个是鸡舞许可证，它创建了标准 GPL 要求的替代方案，即通过分享你表演鸡舞的视频来分享你的代码。

另一个改变标准许可的例子是 JavaScript Object Notation 的 JSON 许可，它是一种流行的数据交换组件。它修改了标准的许可 MIT 许可证，增加了一个术语“软件应用于善，而不是恶”。绝对是出于好意，但许多公司选择不批准此许可证，因为“好”和“坏”这两个词被认为是可以解释的。

每家公司都必须自己决定他们的风险承受能力是什么，以及他们将允许什么样的许可证。但通常一个术语越模糊，从法律的角度来看就越令人担忧。因此，这些定制的许可证通常不受欢迎，或者公然禁止在公司开源政策中使用。

开发人员不应该知道他们使用的代码的规律吗？

开发人员不是因为他们的法律专业知识而被雇用的。他们的目标是创新、建设良好、快速建设。

重要的是要记住，开源代码是“免费”的误解由来已久，可以追溯到 1985 年，因此很难克服。最初，它被称为“自由软件”，来自推动理解和修改软件的自由的自由软件运动。

因此，开发人员可能会产生这种误解是可以理解的。他们只是想建造，这是他们所知道的，而不是围绕它的法律要求。此外，随着许多公司加大内部应用程序开发的力度，企业可能没有接受过现场培训或了解开源代码正在被使用。

许可证通常也不是直截了当的。以 JSON 为例——开发人员可能认为这很好，因为他们只是在构建商业软件，而不是恶意软件或任何“用于作恶”的东西，但很快就被驳回了。但是，律师将能够从术语的模糊性中识别风险，并适当地关联许可证的风险概况。为了帮助降低许可风险，许多组织确实让他们的开发人员接受了开源法律培训。

依赖项中的开源许可证悖论

以如今开发人员构建的速度，使用无数的代码资源，似乎几乎不可能跟上管理风险和责任的步伐。更不用说安全团队在开发管道中的低能见度了。伴随使用开源库而增加的困难是缺乏对间接依赖关系的可见性。当开发人员使用一个开源组件时会发生什么，该组件由来自其他开源代码的多个间接依赖项构建而成？这看起来有点像无穷大悖论效应，对吧？因为您不仅对直接依赖项的许可条款负责，而且对用于构建更大的开源组件的开源代码的任何间接依赖项负责。

开源许可会影响软件供应链的完整性

供应链攻击是许多 IT 团队的头等大事，其中一个重要的难题是确保其完整性。合规性是其中的关键部分，因此，Linux 基金会等组织寻求解决方案。 OpenChain 项目是作为软件供应链中开源许可证合规性的有效认证而创建的。它本质上所做的是加强整个链条并确保每个部分都可以信任并符合为获得认证而设定的合规标准。最新的 OpenChain 规范是 ISO/IEC 5230:2020，它“指定了质量开源许可证合规计划的关键要求，以便提供一个基准，在交换由开源软件组成的软件解决方案的组织之间建立信任。”

那么如何才能跟上并减轻法律风险呢？

有些程序具有具有预先填充的风险概况的许可证数据库。法律团队可以设置自动化，因此任何存在许可冲突的开源代码都会被标记出来。这些程序由包含数千个许可证和许可证系列的开源库数据库提供支持。这些程序还有助于跟踪您的组织正在使用的许可证，然后可以创建包含所有这些许可证的报告以包含在应用程序分发中。对开发人员进行开源软件法律培训也是一项重要的缓解措施，因为这有助于减少出现的冲突。

Trend Micro Cloud One – Open Source Security 由包含数千个开源库及其相关许可证的 Snyk 数据库提供支持。该解决方案弥合了开源的两种常见风险——漏洞和许可证——因此您可以从一个控制台控制和减轻所有开源风险。这为安全和运营团队带来了重要价值，以便通过进一步提高对开发人员管道功能代码库的可见性来管理开源软件使用的风险和责任。 Cloud One – 开源安全可帮助安全和法律团队在软件开发生命周期的早期识别风险，从而节省时间和成本高昂的修复程序，一旦应用程序发布并可供客户使用，这些修复程序可能会在以后发现。

原文：https://www.trendmicro.com/en_us/research/21/g/navigating-open-source-l…

本文：https://jiagoushi.pro/node/1946

当他们试图对抗将软件作为托管服务出售的云巨头的冲击时，开源公司设计了新的许可限制。

上周，Confluent 在其用于涵盖其开源数据流产品的组合中添加了一个新许可证。到目前为止，该公司一直依靠单一许可证来涵盖其开源产品 Apache 2.0，这是企业用户的最爱，因为它允许将代码合并到专有项目中。该公司还为其付费的“企业”版本使用专有许可证。

新的许可证，即 Confluent 社区许可证，将仅涵盖 Confluent 堆栈的一小部分，主要围绕 KSQL，该公司的 Apache Kafka 流式 SQL 引擎。从表面上看，新许可证与 Apache 几乎没有什么不同，但重要的补充是 KSQL 和其他涵盖的软件不能作为云服务提供。

“[Y] 你可以使用 KSQL，但是你认为它适合作为你自己的产品或服务中的一种成分，无论这些产品是作为软件还是作为 SaaS 交付的，但你不能创建 KSQL 即服务产品，”Jay Kreps Confluent 的联合创始人兼首席执行官在博客中解释道。 “我们仍将公开进行所有开发并接受拉取请求和功能建议。对于那些不是商业云提供商的人，即这些项目的 99.9999% 的用户，这不会对他们的能力增加任何有意义的限制使用该软件，同时允许我们继续大力投资于它的创建。”

问题在于，这些限制与开源计划所使用的开源定义相冲突，该组织决定哪些许可证有资格成为开源。 该限制还意味着许可证涵盖的任何代码都可能无法在任何其他开源项目中使用。

限制开源（x）即服务的问题

改变的原因集中在公共云上，公共云越来越多地为用户提供利用完全支持和集成的开源服务的能力，用户费用绕过为开源项目做出贡献的软件开发人员并直接进入银行账户 亚马逊网络服务、谷歌云平台和微软 Azure 等。 上个月在 re:Invent 2018 上，AWS 推出了 Kafka 的托管版本，这使云提供商与 Confluent 直接竞争。

Confluent 只是一系列开源公司中的最新一家，这些公司决定与他们认为来自云提供商的不公平竞争作斗争。它始于 5 月，当时 Neo4j 将 Commons Clause 添加到以前涵盖该软件的 AGPL 许可证中。 8 月，内存数据库初创公司 Redis 采取了类似举措，将其 Redis 模块的许可从 AGPL 更改为将 Apache 2.0 与 Commons Clause 相结合的许可方案。

根据其作者的说法，Commons Clause 是一个许可附录，它允许“保留原始许可的所有许可，除了‘销售’软件的能力。”但是，该例外意味着该条款有效地成为软件许可，将基础许可降低为指导状态，并将项目的性质从“开源”更改为“源可用”（该条款的作者使用的术语）。它还使代码与底层许可证不兼容。例如，Redis 模块代码不能用于其他 Apache 2.0 项目，因为 Commons Clause 限制不是 Apache 许可证的一部分。

Confluent 的新许可证解决方案也是如此。尽管它的许可证基于 Apache 2.0，但对“KSQL-as-a-service”的限制使其与 Apache 和其他开源许可证不兼容。

“两者都有‘使用领域’限制，这使得它们不仅与 ALv2 不兼容，而且使它们成为非开源许可证，”Apache 基金会的联合创始人 Jim Jagielski 告诉 Data Center Knowledge。

MongoDB 采取不同的路线

10 月，NoSQL 数据库公司 MongoDB 采取了与 Confluent 类似的策略，提出了一个新的许可证，即服务器端公共许可证 (SSPL)，以应用于其 MongoDB 社区服务器。然而，与云偷猎的其他“解决方案”不同，MongoDB 试图通过不禁止将社区服务器用作在线服务，而是说明部署许可项目必须满足的条件，从而保留项目的开源性质根据 SSPL 作为服务。

“提供公开可用的 MongoDB 即服务的公司必须开源其用于提供此类服务的软件，包括管理软件、用户界面、应用程序接口、自动化软件、监控软件、备份软件、存储软件和托管软件，所有这些都使得用户可以使用提供的源代码运行服务实例，”该公司在解释许可证的网页上表示。

从那时起，MongoDB 一直在努力将所有的 i 打点并交叉所有的 t，以试图获得新许可证的批准。 11 月下旬，该公司提交了许可证的第 2 版，旨在解决 OSI 社区在考虑第一个版本时表达的一些担忧。如果获得批准，该公司表示将在未来的产品中使用此版本。

原文：https://www.datacenterknowledge.com/open-source/confluent-creates-new-o…

本文：https://jiagoushi.pro/node/1953