读开源项目成功之道03开源答应证

1. 自由度

1.1. 自由运行步伐，无论出于何种目标（自由度0）​
1.2. 自由研究步伐的工作原理并对其举行更改，以便让它按照你的意愿举行计算（自由度1）​

• 1.2.1. 访问源代码是实现这一目标的先决条件
  

1.3. 重新发布副本的自由，以便你可以帮助其他人（自由度2）​
1.4. 将修改后的版本的副本分发给其他人的自由（自由度3）

• 1.4.2. 访问源代码是实现这一目标的先决条件
  

2. 开源答应证

2.1. 一个好的软件开发者会沉迷于代码中类似的细节，如缩进、语句内的间距、括号的位置、注释和变量命名
2.2. 代码样式指南的目标是为希望扩展代码的下游用户以及未来的项目维护者节流时间，答应证和知识产权管理也是如此，它们都为干系人员节流时间，使代码更容易在项目下游使用
2.3. 旨在提供清晰同等的指导和文档，明确代码的使用方式，贡献代码的盼望和任务，以及品牌使用的规范
2.4. 开源答应证的类型很多，如果我们归纳所有的答应证，就会发现有的答应证较为宽松，有的则较为严酷（非宽松答应证，也称为copyleft）​，规定了开源代码的用户责任和限制
2.5. 开源有这些选择是一件好事，但是选择太多也会带来困惑

• 2.5.1. 所选答应证的任务
  
• 2.5.1.1. 看到许多答应证在关于如何推行任务方面的条款并不清楚
  
• 2.5.2. 一个答应证下的代码如何被另一个拥有不同答应证的项目利用或使用
  
• 2.5.2.1. 根据答应证的不同，这可能导致代码需要获取新的答应证才能符合要求
  
• 2.5.3. 答应证变体的差异以及为什么你会选择此中一种
  
• 2.5.3.1. BSD答应证系列是一个很好的例子，它有4种官方变体，还有许多衍生变体
  
• 2.5.3.2. 每种答应证都有不同的小规定来解决不同的情况
  

2.6. 宽松答应证

• 2.6.1. 宽松答应证通常是最简朴的开源答应证类型
  
• 2.6.2. 还答应用户在最小的任务下使用代码
  
• 2.6.3. 宽松答应证会只管制止对项目本身、授予的软件专利，以及任何其他保证负担责任
  
• 2.6.4. 项目或代码的作者只想让代码公开并供人们使用
  
• 2.6.5. Apache-2.0答应证属于宽松答应证类别，但为下游用户提供了更多保证
  
• 2.6.5.1. 它是项目贡献者向每个下游用户授予的答应证，在版权答应方面较为明确
  
• 2.6.5.2. 确保项目贡献者拥有的任何软件专利都被授予下游用户的答应证
  

1. >  2.6.5.2.1. 有助于解决在贡献者协议或其他文档中明确专利使用的问题

复制代码

• 2.6.5.3. 通常在开源领域中，Apache-2.0答应证变得非常受接待，因为它对企业更友好
  

2.7. 非宽松答应证或copyleft

• 2.7.1. 通常宽松答应证不会明确界说下游用户的特定责任，而非宽松答应证或copyleft则明确地设定了这些预期
  
• 2.7.2. 在这类答应证中最著名的可能是GNU通用公共答应证，Linux内核项目和许多作为开源构建的桌面应用步伐（如Blender、Inkscape、LibreOffice等）都使用了该答应证
  
• 2.7.3. copyleft的目标是确保项目中的代码以及下游所做的任何改进都保持在与项目相同的答应证下
  
• 2.7.4. 这种答应模式在Linux内核项目、GNU工具链等越来越受接待的项目中起着非常重要的作用
  
• 2.7.5. 对copyleft开源代码的担忧，可以归结为将其整合到其他专有软件中的本领
  
• 2.7.5.1. 促使产品供应商远离copyleft软件
  
• 2.7.5.2. 无论是不将其整合到他们正在构建的专有软件中，还是完全不使用它
  
• 2.7.6. Tivo
  
• 2.7.6.1. Tivo机顶盒的软件将Linux内核和GNU工具链的代码归并到所使用的软件中
  
• 2.7.6.2. 虽然Tivo遵守了GNU通用公共答应证第2版的条款，但他们的硬件中集成了数字权利管理(Digital Rights Management，DRM)，使得无法在硬件上运行修改后的代码，这被称为Tivo化
  
• 2.7.6.3. 虽然Tivo化在答应证的字面意思上是答应的，但违背了答应证的精力，它在很大程度上推动了GNU通用公共答应证第3版的出现
  
• 2.7.7. 云服务提供商使用开源软件
  
• 2.7.7.1. 该软件根本没有被分发，而是由用户在共享系统上使用，这个概念直到21世纪初才被普及
  
• 2.7.7.2. 像GNU Affero通用公共答应证和Commons Clause这样的答应证应运而生，解决了这些问题，它们要求提供在这些系统上运行的开源答应证软件
  

2.8. 对答应证违规者采取法律举措是明智的，但在绝大多数情况下，与他们联系是更好的解决方案

• 2.8.1. 依据答应证维权是项目维护者或作者应该关注的焦点，毕竟他们是直接受到影响的人
  

3. 哪种类型的答应证对项目有意义

3.1. 用户是谁？你希望用户如何使用代码？
3.2. 否需要设定将代码和开发推向上游（即项目标主要代码堆栈）的盼望？或者这已经在社群文化中了？
3.3. 你是否盼望商业使用？作为项目维护者，你对此有何感想？
3.4. 这是什么类型的项目？库？现成的应用步伐？还是框架？
3.5. 一个好的开源项目会把用户放在第一位
3.6. 库、框架和集成层，在宽松答应证下它们可以工作得更好

• 3.6.1. 其原因在于代码使用的意图，它将与专有代码混淆在一起，因此copyleft的任务将是一个主要问题
  

3.7. 对于更多的终端用户应用步伐，如桌面或Web应用步伐，一般趋势是选择copyleft

• 3.7.1. 主要是为了鼓励上游开发并使版本和发布节奏更加同等，同时也使希望构建商业模型的供应商不要太过关注销售副本，而应更多地提供支持和培训等附加服务
  

3.8. 在软件进入一个竞争猛烈的领域，且存在多个商业解决方案时，使用copyleft是有帮助的
3.9. 一旦你选择了一种答应证，要改变它就需要付出很多努力

• 3.9.1. 最大的问题在于，要改变答应证，每个为该项目作出贡献的贡献者都必须同意重新授权他们贡献的代码
  

3.10. MongoDB原来使用的是GNU Affero通用公共答应证第3版(AGPL v3)

• 3.10.1. 因为担心云服务提供商利用MongoDB赢利，而MongoDB公司却得不到任何收益，所以他们改用了新的服务器端公共答应证(Server Side Public License，SSPL)
  

3.11. Redis Labs由于对云服务提供商有一些担忧，在其开源代码中添加了Commons Clause
4. 版权和贡献签署

4.1. 当人们考虑答应证和知识产权管理时，谈话通常集中于出站答应证，也就是项目使用的答应证
4.2. 同样重要（甚至更重要）的是代码进入项目所遵照的条款，因为如果代码进入项目标答应证或条款与代码发布的答应证不兼容，那么下游用户就难以使用该代码
4.3. CLA

• 4.3.1. 签署贡献者答应协议(Contributor License Agreement，CLA)
  
• 4.3.2. CLA是由贡献者签署的法律文件，它在项目和贡献者之间就贡献者对项目所作贡献的条款和条件提供了一份协议
  
• 4.3.3. CLA可以是与个人或组织达成的协议，分别称为个人贡献者答应协议(Individual Contributor License Agreement，ICLA)或公司贡献者答应协议(Corporate Contributor License Agreement，CCLA)
  
• 4.3.4. CLA的条款常常有点零乱，除非使用尺度模板（如Apache CLA）​，否则组织每每需要法律审核才能放心地为项目作出贡献
  
• 4.3.5. 使用CLA可以解决一些开源项目答应证可能存在的不明确之处
  
• 4.3.6. 像Apache-2.0这样的答应证通常会使CLA变得多余，从而消除对CLA的需求，这是它在商业供应商驱动的开源项目中受接待的一个因素
  
• 4.3.7. 即使使用CLA，也可以使用自动化工具（如LFX EasyCLA）执行，坚持使用尺度模板可以降低摩擦
  

4.4. DCO

• 4.4.1. 开发者原创声明(Developer Certificate of Origin，DCO)
  
• 4.4.2. 在Linux内核项目中存在一种贡献由集体共有而非个体所有的文化
  
• 4.4.2.1. 它确保了技术可以公开发展，没有特定供应商能够在未征得所有贡献者同意的情况下将项目引向某个方向
  
• 4.4.2.2. 可以将该项目看作某种公共资源
  
• 4.4.3. 贡献者通过在其源代码提交消息中添加“Signed-off-by:”行来举行声明
  

5. 品牌和标记管理

5.1. 管理项目标知识产权不仅仅是代码，因为品牌、项目名称和其他资产对开源项目标成功也非常重要
5.2. 对于一个较小的项目，这可能看起来不是什么大问题，但对于一个较大的项目，则可能对其成功至关重要
5.3. 确定项目标名称

• 5.3.1. 一个项目应该先确定自己的品牌是什么
  
• 5.3.2. 这在很大程度上涉及它对用户的独特性
  
• 5.3.3. Apache HTTP Server之所以被命名为这个名称，是因为它是原始NCSA Web服务器的补丁
  

5.4. 品牌同等性

• 5.4.1. 一旦项目有了一个名字，下一步就是建立品牌
  
• 5.4.2. 保持全面的同等性
  
• 5.4.3. 标记也是如此
  
• 5.4.3.1. 应该具有相同的颜色、比例和计划元素
  
• 5.4.3.2. 看起来可能是次要的细节，但却在品牌管理中至关重要，不仅有助于减少混淆，还可以为项目塑造一个专业的、运行良好的形象
  

5.5. 掩护品牌

• 5.5.1. 掩护品牌的最佳方法就是始终保持同等性
  
• 5.5.2. 掩护品牌的下一个条理是商标注册
  
• 5.5.2.1. 商标的用途描述为“用于区分一个卖家或提供商的商品/服务与其他卖家或提供商的商品/服务，并指示商品/服务的来源。​”
  
• 5.5.2.2. 留意注册商标是一个明智的做法
  
• 5.5.2.3. 注册和维护商标的本钱可能比较高昂
  
• 5.5.3. 通常项目会寻求转向中立供应商实体（如Linux基金会、Apache软件基金会或软件自由掩护协会等）的领域，他们在管理商标方面拥有丰富的经验和专业知识
  

5.6. 让其他人使用你的品牌

• 5.6.1. 计划使用客观尺度举行管理，通常第三方将到场评估过程，以确保没有供应商私见
  
• 5.6.2. 同等性计划不会陵犯其他人使用代码的本领
  
• 5.6.2.1. 代码在项目答应证下仍然可用