读开源项目成功之道03开源许可证

1. 自由度

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

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

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

• 1.4.1. 这样做你可以让整个社群有机会从你的更改中受益
  
• 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
3.12. SugarCRM最初在自己的SugarCRM公共许可证下提供其社群版，后来转向AGPL v3，最后转向完全专有的产品
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. 代码在项目许可证下仍然可用
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！