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