通过和在开源许可中确保开放性

对于初次接触开源的人来说，当应用 OSI 批准的许可证时，开源定义的范围或国际开源社区期望的标准可能并不清楚。我们在此帮助澄清一些问题。

当今商业领域的一些最大力量——面向消费者的公司如谷歌和 Facebook，面向企业的公司如 Salesforce 和 SUSE，科技行业以外的公司如宝马、第一资本和 Zalando，甚至第一代科技公司如微软和 IBM——都越来越依赖开源软件。包括欧盟、法国、印度、英国、美国和许多其他国家在内的政府也发现了开源软件和开发模式的好处。这些组织使用的软件和基础设施的成功协作开发，是通过以新的方式使用其知识产权来创造安全空间实现的……以确保一个共同创造的环境，其中软件的四个基本自由得到保障。

根据 OSI 批准的开源许可证分发的软件为企业和政府提供了很多好处：既作为消费者，也作为贡献者。通过开源许可保护的软件自由，利用了分布式同行评审和过程透明化的力量，通过更快的创新、更高的质量、更好的可靠性、更低的成本和最终消除供应商锁定来推动经济发展。开源模式还促进了安全性的提高；因为公共视野中的代码将受到极其严格的审查，问题会被发现和修复，而不是保密直到被不应该发现的人发现。最后但并非最不重要的一点是，这是一种小公司可以聚集在一起，创新并在击败现有参与者方面有良好机会的方式。参与开源项目和社区可以将开放标准构建为实际软件，而不是纸质文档。对于公司和个人来说，这是一种围绕共同需求在产品上进行协作的方式，而这些需求是任何一方都无法单独实现的，或者本身并不构成关键的业务差异化因素。

政府也认识到开源的价值，它既是一种为他们服务的公众提供价值的技术解决方案，也是一种将纳税人投资回报给他们所代表的社会的发展方法。

2007 年欧盟委员会的一项研究提出，“开源是信息通信技术竞争力的关键”，然而，“尽管 FLOSS [自由/开源软件] 为欧洲提供了充足的机会，但它受到某些政策圈子中越来越多支持监管的举动的威胁，这些监管旨在保护创意产业的旧商业模式，使开发新的商业模式变得更加困难。” [1]

自 1998 年成立以来，开源促进会 (OSI) 成功地将版权许可作为软件自由的具体表达形式加以解决。但是，开源软件许可证的初衷始终是超越版权，为开发者和用户在多个知识产权类别中提供权利许可和权利保护，无论是明确的还是隐含的。OSI 从未批准过任何不包含自由制作、使用和销售软件的强大权利的许可证，正如 OSI 的关键原则所要求的那样。

开源包括专利以及版权

一个开源项目和参与的实践社区一直期望，如果一个项目是“开源的”，那么他们将获得与以前和现在的参与者相关的所有必要权利，而无需进一步行动即可获得许可。这种期望在开源定义 (OSD) 中得到保证，“附加到程序的权利必须适用于所有重新分发程序的人，而无需这些方执行额外的许可证” [2]。

OSI 长期以来一直解释说，不受限制的许可对于保护开源软件固有的软件自由以及依赖于不受限制的使用、修改和（再）分发的实践社区至关重要。OSI 就多个威胁开源软件的问题发布了多项公开评论和推荐政策，包括：开放标准 [3, 4]、数字版权管理 [5]、FRAND [6] 和软件专利 [7]。

OSI 和开源社区一直将专利许可（作为标准实施的先决条件）视为已批准的开源许可证的固有组成部分，而无需任何单独的许可授权。即使是零费用许可也可能存在问题，因为它仍然可能需要在采用和使用软件之前获得专利持有人的（非货币）许可，这与开源的对立。专利许可在定义上是双边的——许可方和被许可方之间的一次性协议。开源社区在定义上是多边的，其中单个许可证为所有被许可人提供一致性。任何包含针对特定用户的单独专利许可的方法都将破坏多参与者的开源模式，与 OSD 冲突，因此永远不能被解释为符合任何 OSI 批准的开源许可证或“开源软件”标签。

需要明确的是，当然，参与开源项目的决定完全是自愿的。公司可以选择不参与，因此不许可其版权和专利。但是，如果他们参与开源，那么他们必须遵守这些开源许可的基本要求。

对开源软件主张专利会阻碍真正的协作

不受限制的协作对于开源软件社区中真正的开发至关重要，它从根本上取决于参与的平等和行为的透明度。像 Apache、OpenStack、Cloud Foundry 和许多其他组织竭尽全力确保透明和平等，并制定了排除那些试图破坏这两者的人参与的规则。从协作开发和分发的角度来看，贡献者对其开源软件主张专利与开源方法是背道而驰的。

因此，开源许可条款可以防止专利侵犯，并使试图侵犯者处于不利地位。这种知识产权的使用远非一种牺牲，可以说是技术行业的动力源泉，它允许初创公司和老牌公司都能够迅速站在早期巨人的肩膀上并交付创新。Web 服务器、智能手机、业务自动化、云计算和共享经济——仅举几个例子——都源于 OSI 批准的开源许可证的使用，并且如果没有它，可能永远不会发生。

开源是一个明确定义的术语

OSI 作为 OSD 的管理者，是社区公认的审查和批准许可证是否符合 OSD 的机构。全球软件开发和部署社区将软件称为“开源”，当软件以源代码形式根据 OSI 批准的 IP 许可证提供时，该许可证传达了以给定社区认为适当的方式使用、改进和共享软件的必要权利。OSD 以及 OSI 在认证许可证方面的权威性，已获得国际开源软件项目（例如 Apache 基金会、Linux 基金会、Mozilla 基金会）[8]、公司（例如 Adobe、Dell/EMC、Facebook、Github、Google、HP、IBM、微软）[9] 和世界各国政府 [10] 的认可。

还有一些实际原因导致开源软件需要符合 OSD 和 OSI 批准的许可证。从历史上看，当组织试图将某些软件或另一软件标记为“开源”但未应用 OSI 批准的开源许可证时，社区始终会做出回应 [11]，对抗冒犯性组织 [12, 13]，强调社区的共识 [14]，并要求在重新与社区规范保持一致之前进行决议 [15]。换句话说，虚假声明符合开源规范是不利于业务的。

所有 OSI 批准的许可证都共享 OSD 中定义的基本属性。特别是，“仅使用”始终是被允许的。

批准的许可证，OSI 的流程

OSI 批准流程的一个关键目标是允许那些无法获得公司法律顾问的人仍然能够自信地参与开源协作开发，以服务于他们自己对代码的使用、改进和共享。OSI 许可证审查流程确保标记为“开源”的许可证和软件符合现有的社区规范和期望。因此，所有许可证都必须经过以下描述的公开审查流程。

  • 确保批准的许可证符合开源定义
  • 确定适当的许可证扩散类别
  • 劝阻虚荣和重复的许可证
  • 确保彻底、透明和及时的审查（例如，在 60 天内）

OSI 用于许可证审查的“共识结晶”流程在社区中被广泛接受，充当信任的纽带，并为创新提前提供许可。因此，只有当公开审查达成共识并且 OSI 董事会确认该共识时，许可证才会被“批准”。

个人、公司和标准制定组织 (SDO) 不得在本流程之外主张或暗示 OSI 批准的开源许可证状态。

随时提供帮助

OSI 现任和前任董事会成员在开源软件项目和社区、许可证批准流程方面拥有数十年的经验，并且了解与许可和社区相关的多种成功和失败模式。

OSI 是一个依靠捐赠资助的盈亏平衡的 501(c)(3) 组织，员工有限，并且有一个义务董事会。尽管如此，OSI 仍愿意就开源事宜与任何组织进行沟通，并帮助确定独立的顾问。

要建立相应的关系，请联系 [email protected]

参考文献

  1. Ghosh, Rishab Aiyer. 自由/开源软件对欧盟创新和竞争力的影响, 欧盟委员会, 2007. Web. 2017年10月25日. http://flossimpact.merit.unu.edu/
  2. OSI 董事会. 开源定义. 开源促进会, 1998. Web. 2017年10月25日. https://open-source.org.cn/osd
  3. OSI 董事会. 开放标准要求. 开源促进会, 2006. Web. 2017年10月25日. https://open-source.org.cn/osr
  4. OSI 董事会. 软件开放标准要求 – 理据. 开源促进会, 2006. Web. 2017年10月25日. https://open-source.org.cn/osr-rationale
  5. OSI 董事会. 开放标准的 DRM 非侵犯原则. 开源促进会, 2016. Web. 2017年10月25日. https://open-source.org.cn/osr-drm
  6. OSI 董事会. FRAND 和开放标准. 开源促进会, 2012. Web. 2017年10月25日. https://open-source.org.cn/node/616
  7. OSI 董事会. 搜索结果. 开源促进会, 2017. Web. 2017年10月25日. https://open-source.org.cn/search/node/software%20patents
  8. OSI 董事会. OSI 附属机构列表. 开源促进会, 2017. Web. 2017年10月25日. https://open-source.org.cn/affiliates/list
  9. OSI 董事会. OSI 企业赞助商和支持. 开源促进会, 2017. Web. 2017年10月25日. https://open-source.org.cn/sponsors
  10. OSI 董事会. 国际权威和认可. 开源促进会, 2016. Web. 2017年10月25日. https://open-source.org.cn/authority#AustralianGov
  11. OSI 董事会. 对 React 的回应. 开源促进会, 2016. Web. 2017年10月25日. https://open-source.org.cn/node/862
  12. Mattmann, Chris A. RocksDB 集成. Apache 基金会, 2017. Web. 2017年10月25日. https://issues.apache.org/jira/browse/LEGAL-303?focusedCommentId=16088663
  13. Mullenweg, Matt. 关于 React 和 WordPress. MA.TT, 2017. Web. 2017年10月25日. https://ma.tt/2017/09/on-react-and-wordpress/
  14. 多人. 2016 年 12 月按主题归档. 开源促进会, 2016. Web. 2017年10月25日. https://lists.opensource.org/pipermail/license-discuss/2016-December/thread.html#19600
  15. Wolff, Adam. 重新许可 React、Jest、Flow 和 Immutable.js. Facebook 代码, 2017. Web. 2017年10月25日. https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-and-immutable-js/

图片来源
“openBlur.png”, ©开源促进会, 2017, 署名-相同方式共享 4.0 国际 (CC BY-SA 4.0), 是 “Yes We’re Open.jpg“, ©Pernillan (Own work), 2017, 通过 维基共享资源 的衍生作品（裁剪并模糊处理），并根据 署名-相同方式共享 4.0 国际 (CC BY-SA 4.0) 许可证获得许可使用。