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 协商完成，但建议项目使用贡献者公约的衍生版本。