许可证扩散委员会报告及常见问题解答草案

页面创建于 2006 年 7 月 31 日 | 最后修改于 2023 年 1 月 25 日

本文档的目的是报告许可证扩散委员会的工作和
开源促进会（OSI）的建议
（“许可证扩散委员会”）。

许可证扩散委员会是一个咨询委员会。其章程规定“[委员会的
目的是识别并减轻或消除许可证扩散引起的问题。”（章程见附件）。
许可证扩散委员会的成员包括

许可证扩散委员会的成员包括

  • John Cowan，
  • Damien Eastwood，
  • Bryan Geurts，
  • Rishab Aiyer Ghosh（观察员），
  • Laura Majerus（主席），
  • Russ Nelson，
  • Karna Nisewaner，
  • Diane Peters，
  • Eric Raymond，
  • Sanjiva Weerawarana（观察员），
  • Cliff Schmidt，
  • McCoy Smith

本文档包含许可证扩散委员会关于其对许可证扩散定义的理解的政策声明
以及关于如何处理许可证扩散的一些建议。
以及关于如何处理许可证扩散的一些建议。

本文档还包含关于许可证分组的建议和
常见问题解答，以解释委员会为何进行分组以及委员会期望分组
将如何帮助减轻许可证扩散。

许可证扩散意味着什么？

当我们彼此交谈并倾听
开源社区的声音时，我们清楚地认识到，不同的人对“许可证扩散”一词有不同的理解。评论分为
开源社区的声音时，我们清楚地认识到，不同的人对“许可证扩散”一词有不同的理解。评论分为
三个主要群体

  1. 过多的不同许可证使许可方难以
    选择

    有些人使用“许可证扩散”来表示
    许可证数量过多，需要有人采取措施
    减少许可证数量。虽然这很棒，但 OSI 无法
    强迫任何人使用或不使用特定许可证。我们所能做的就是教育
    并敦促人们使用较小的许可证子集。此评论
    通常来自个人和小公司。

  2. 某些许可证不能很好地协同工作

    有些人使用“许可证扩散”来指代以下事实：
    某些开源许可证与其他开源许可证不能很好地互操作
    开源许可证。虽然我们可以敦促人们不要混合
    不可混合的许可证，但我们无法阻止人们这样做。此
    评论通常来自大型公司。

  3. 过多的许可证使得难以理解您在多许可证发行版中
    过多的许可证使得难以理解您在多许可证发行版中

    这与之前的评论相关，但又有所不同
    因为它没有抱怨许可证如何交互，只是抱怨
    有太多不同的单个许可证涵盖某些
    发行版，并且需要花费大量时间来阅读和理解
    所有这些许可证。此评论通常来自大型公司。

OSI 可以为解决许可证扩散做些什么

我们首先可以做的是确保那些自称为“开源”的许可证
真正符合开源定义。
2005 年，OSI 提出了三项指导原则，他们将
应用于拟议的许可证，以确定它们是否应该获得
OSI 批准。

  1. 许可证不得重复
  2. 许可证必须书写清晰、简单且易于理解
  3. 许可证必须是可重用的

我们建议通过提供
许可证向导来解决许可证选择问题，如下所述。

我们建议开展一个持续的项目，对现有的开源许可证进行分组。
这种分类的目标是帮助社区确定
哪些许可证在哪些情况下有用。

向导项目

南加州大学法学院和旧金山州立大学工程系的志愿者
目前正在开发一个基于网络的向导，以便
人们查看哪些开源许可证符合他们认为重要的标准。
这些志愿者是 Jennifer Urban 教授和
Sameer Verma 教授，以及他们的研究助理。例如，
如果用户表示拥有带有明确
专利授权的 copyleft 许可证很重要，则向导将查找
OSI 批准的许可证，并输出符合
（或几乎符合）这些标准的许可证列表。

该向导帮助新的许可方选择哪些许可证符合
他们的目标。该向导还允许许可方查找几乎
符合其目标的许可证。我们希望能够生成
符合已定义目标的现有许可证列表将减少
人们创建自己的新许可证的需求。

分组

最初，许可证扩散委员会开始将 OSI 批准的
许可证分为“推荐”、“不推荐”和“其他”层级。
然而，委员会的结论是，任何此类规范性描述
都应由 OSI 董事会决定政策问题。
因此，我们将“推荐”/“不推荐”术语更改为
更具描述性的术语，包括以下类别

  • 流行且广泛使用或具有强大
    社区的许可证
  • 特殊用途许可证
  • 与更流行的许可证冗余的许可证
  • 不可重用的许可证
  • 其他/杂项许可证

我们认为，这些更具描述性的类别将有助于
最初选择许可证的人使用更
流行的许可证之一，从而有助于减少
常用不同许可证的数量。

虽然乍一看，许可证的受欢迎程度似乎不适合对其进行分类，但流行且历史悠久的许可证具有一个重要的优势：成熟的解释传统和关于对其行为的良好预期。这对于减少混乱非常重要，并且（尤其是在英美法系国家）甚至可能影响司法解释
许可证的司法解释。

以下是分组

流行且广泛使用或具有强大
社区（9）

  • Apache 许可证 2.0
  • 新 BSD 许可证
  • GNU 通用公共许可证（GPL 版本 2）
  • GNU 库或“较宽松”通用公共许可证（LGPL 版本 2）
  • MIT 许可证
  • Mozilla 公共许可证 1.1 (MPL)
  • 通用开发和发行许可证
  • 通用公共许可证
  • Eclipse 公共许可证
特殊用途许可证 (3)
  • 教育社区许可证（特殊用途：仅
    适用于教育机构）
  • NASA（特殊用途：供
    美国联邦政府机构使用，该机构对某些问题有特殊
    担忧，例如版权保护、
    版权声明、免责声明和赔偿，
    以及法律选择）
  • 开放组测试套件（特殊用途：仅适用于
    测试或测试套件）
与更流行的许可证冗余的许可证 (9)
  • 学术自由许可证（与 Apache 2.0 冗余）
  • 署名保证许可证（与 BSD 冗余）
  • CUA 办公室公共许可证（与 MPL 1.1 冗余）
  • Eiffel 论坛许可证 V2.0（与 BSD 冗余）
  • Fair 许可证（与 BSD 冗余）
  • 历史许可声明和免责声明
    （与 BSD 冗余）
  • Lucent 公共许可证版本 1.02（与 CPL 冗余）
  • 伊利诺伊大学/NCSA 开源许可证
    （与 BSD 冗余）
  • X.Net 许可证（与 MIT 冗余）
不可重用的许可证 (24)
  • Apple 公共源代码许可证
  • Computer Associates Trusted Open Source License 1.1
  • EU DataGrid 软件许可证
  • Entessa 公共许可证
  • Frameworx 许可证
  • IBM 公共许可证
  • Motosoto 许可证
  • Naumen 公共许可证
  • Nethack 通用公共许可证
  • Nokia 开源许可证
  • OCLC Research Public License 2.0
  • PHP 许可证
  • Python 许可证（CNRI Python 许可证）
  • Python 软件基金会许可证
  • RealNetworks 公共源代码许可证 V1.0
  • 互惠公共许可证
  • Ricoh 源代码公共许可证
  • Sleepycat 许可证
  • Sun 公共许可证
  • Sybase Open Watcom Public License 1.0
  • Vovida Software License v. 1.0
  • W3C 许可证
  • wxWindows 库许可证
  • Zope 公共许可证
其他/杂项许可证 (5)
  • 自适应公共许可证
  • 艺术许可证
  • 开放软件许可证
  • Q 公共许可证
  • zlib/libpng 许可证
已取代的许可证 (4)
  • Apache 软件许可证 v1.1
  • Eiffel 1.0
  • Lucent 1.0
  • MPL 1.0
已自愿弃用的许可证 (4)
  • Intel 开源许可证
  • Jabber 开源许可证
  • MITRE 协作虚拟工作区许可证
  • Sun 行业标准源代码许可证 (SISSL)

以下是我们对各种组中许可证进行分类的标准

流行且广泛使用或具有强大
社区的许可证
我们使用从公共来源获得的统计数据来确定
哪些许可证被广泛使用。我们认为有一些
许可证虽然不是最流行的，但在
各自的社区中被广泛使用，并且这些许可证也属于该组。
特殊用途许可证
某些许可方，例如学校和美国政府，
有专门的顾虑，例如针对
政府版权的专门规则。被确定为满足
特殊需求的许可证被归入此组。
与更流行的许可证冗余的许可证
此组中的几个许可证都是优秀的许可证，并且
有自己的追随者。委员会在此
组中挣扎，但最终决定，如果要解决
许可证扩散问题，我们必须修剪许可证。因此，
被认为与现有许可证完全或部分冗余的
许可证被归入此组。
不可重用的许可证
此组中的许可证特定于其作者，并且
其他人无法重复使用。这些许可证中的许多（但并非全部）
属于虚名许可证类别。
已取代的许可证
此类别中的许可证已被较新
版本取代。
已自愿弃用的许可证
自定类别。任何人都不应在未来使用这些许可证
，尽管我们假设许可方可以选择
继续使用它们。
其他/杂项许可证
这些许可证未明确归入任何类别。