最近我参与了一些讨论，主题都是关于“我应该为我的项目选择哪种开源或自由软件许可证？”。 这是我对目前种类繁多且不断增长的许可证的看法。 首先，我们要明确一点，我不是律师。 这不是法律建议。 根据您的需求以及您对软件风险的承受能力，您需要与您所在司法管辖区的律师确认您的法律选择。
首要且显而易见的考虑因素是该许可证是否被开源促进组织 (OSI) 批准为开源许可证。 OSI 在 1990 年代后期创建了 开源定义，作为软件许可证必须支持的一组属性，才能被视为“开源”。 任何人都可以将许可证提交给 OSI 进行辩论和讨论，如果获得批准符合 OSD，则该许可证将被添加到 规范列表 中。
虽然这似乎是一个显而易见的起点，但我最近惊讶地发现了一种名为“Clear BSD License”的许可证。 它试图明确澄清该许可证中未讨论专利。 它不在 OSI 列表中（而 New BSD 和 Simplified BSD 许可证在列表中），因此不值得考虑。 发明作为现有许可证的小型衍生品的新许可证没有帮助，并且会造成代价高昂的法律文书工作。 今天已经存在广泛的 OSI 批准的许可证集合。 这些许可证涵盖数百万行软件，涉及数十亿美元的采购。 人们很难描述一组尚未被 OSI 批准的许可证涵盖的严重情况。
在考虑开源许可证时，有几个重要的杠杆可以使用
- 对于软件、修改以及某人开发的任何衍生作品，需要多少许可证互惠性？
- 关于专利许可和诉讼的说法是什么？
- 哪个法律管辖区管辖该许可证？
互惠性问题完全是关于“著作权共享”，以及使用软件源代码是否将许可证附加到修改和衍生作品，以及是否需要发布这些修改和衍生作品的源代码。
光谱的一端是没有著作权共享要求的许可证。 这些许可证本质上允许任何人以任何方式使用该软件，而除了维护版权之外几乎不需要其他任何东西。 属于此集合的许可证包括 New 和 Simplified BSD 许可证、MIT 许可证以及 Apache 2.0 和 Microsoft Permissive 许可证。
有一组许可证围绕软件本身维护著作权共享意识，但支持在可能包含以不同方式许可（例如，封闭和专有）的软件的更大软件作品中使用该软件。 这些许可证包括 Eclipse Public License、较新的 Mozilla Public License 2.0 和 Microsoft Reciprocal License。
在著作权共享光谱的另一端是强著作权共享许可证。 软件自由 由自由软件基金会根据软件用户必须拥有的自由来定义。 强著作权共享支持软件自由。 许多开发人员支持软件自由，并通过使用 GPL 许可证系列（GPL2.0、GPL3.0 和 Affero GPL3.0）之一来展示这种支持，以此作为确保最强著作权共享和最强许可证附加的方式，当所讨论的软件用于构建和分发其他软件时。
当软件开始在早期互联网上广泛共享时，软件专利实际上并不是问题，因此早期许可证中没有提及。 到 1990 年代后期，软件专利开始兴起，公司法律团队更多地参与了开源许可证的编写，因为他们更多地参与了开源软件并围绕不断发展的项目开发开源基础。 Apache 2.0 许可证、Mozilla Public License 2.0、Eclipse Public License、较新的 GPL 许可证以及两者的 Microsoft 许可证都反映了这种语言转变。 每个许可证都明确谈到了专利许可证。 每个许可证都具有涵盖不同程度专利诉讼的语言。
我在重要的杠杆类别中提到法律管辖权，因为某些许可证明确提到了它，这对某些人来说可能是一个真正的障碍。 仅凭这个原因，我将其视为一个重要的杠杆。 （Mozilla Public License 2.0 专门尝试处理管辖权问题，作为与原始 MPL 的变更之一，因为这通常是对早期许可证的批评。）
许可证选择中的其他考虑因素包括
- 是否存在特定于项目的亲和力？
- 许可证的历史以及基金会/公司/商业参与？
“语言”项目（Perl、PHP、Python）分别有自己的许可证（Artistic License 2.0、PHP License 3.0 和 Python License 2.0）。 如果您正在从事一个与特定的开源编程语言社区紧密相关的项目，那么您应该显然考虑该社区的许可证，因为关于混合模块和依赖项的问题将相对于开源许可证得到简化。
随着软件知识产权法律的发展，互联网已成为人们协作进行软件开发的巨大空间，商业组织也参与进来。 我们已经看到创建了与特定许可证相关的开源软件基金会。 公司法律团队已参与编写开源许可证，并且这些许可证的语言和结构（例如，术语和定义）反映了这种参与。 没有太多开源许可证经验的律师可能会更放心地审查这些较新的许可证。
因此，为了总结，假设您的主要动机是共同开发和协作开源项目，在我看来，开源许可证的选择大致可以归纳如下。 （我在这里的讨论仅限于广泛使用的许可证和/或大型商业组织（拥有保守的律师）或中立的非营利性开源基金会参与创建的许可证。）
如果您想允许任何人随时随地对软件做任何事情，请使用 MIT 或新的（3 条款）BSD 许可证，即没有著作权共享，也不讨论专利。 这两个许可证都来自学术界，并且都来自软件专利不是重点的时期。
如果您想允许任何人对软件做任何事情（因此没有著作权共享），但觉得有必要谈谈专利以及在面临诉讼时终止许可证，并且/或者您想要一个公司律师更愿意阅读的许可证，那么请考虑 Apache 2.0 许可证或 Microsoft Permissive License。 这些许可证的编写目的是继续鼓励完全开放的共享环境，但编写时更侧重于公司视角（注意结构和语言），并且两者都开始涵盖专利，并在其中构建了不同（且细微差异）程度的专利报复。
如果您认为其他人应该能够在您的软件周围构建 [可能的产品]，但又希望确保对核心软件项目本身的更改保持开源（即，必须发布更改），您可能需要考虑 Eclipse Public License、较新的 Mozilla Public License 2.0 或 Microsoft Reciprocal License。 这些是从商业/公司角度开发的现代许可证，支持“弱”著作权共享。 [注意：EPL 确实将纽约州命名为管辖区。] 请注意每项许可证中的专利声明。
如果您是软件自由的坚定支持者，或者想确保如果您的软件源代码在任何地方被使用，则由此产生的衍生作品将被最大程度地发布为开源，以确保软件自由，那么您应该根据您的需求考虑 GPL2.0 或 GPL3.0。
在开源许可领域，当我看到不同的项目努力寻找为其软件创建“正确”许可的最佳方式时，我遇到了一些有趣的附加想法。
- 许多公司在创建开源项目时都担心其专利组合。 当 Google 发布 WebM 项目时，他们对这个问题采取了一种有趣的方法。 他们选择了 New BSD 许可证，然后创建了一个非常具体的“附加知识产权授予”来涵盖他们需要的专利语言。
- 知识产权法的本质是，财产所有者可以根据自己的选择以多种方式许可给尽可能多的人。 这就是为什么个人 Windows 操作系统副本的 Microsoft EULA 与企业许可协议不同，以及 MySQL AB 如何围绕封闭软件许可及其 GPL 许可的项目开发业务线的原因。 在早期（直到 PHP3），PHP 项目的软件也类似地在 GPL2.0 和早期的 PHP 许可证下获得“双重”许可，以允许该软件尽可能多地包含在尽可能多的地方，因为 GPL 与当时的 PHP 许可证不直接兼容。
我在这里特意没有尝试创建许可证选择的表格或决策树。 我认为许可证选择存在足够的边缘和细微差别，以至于在我们今天拥有的反映其丰富的需求和历史背景的许可证的情况下，它永远无法被正确地“自动化”。 总是会有一个关于“如果……情况怎么办？”的法律问题。 此类问题可能涉及法律顾问，并且可能对管辖区非常敏感。
同样，开源软件许可证不仅仅反映了一组法律选择。 在开源项目的早期阶段，当作者或作者首次发布软件时，许可证的选择反映了为项目制定的社会契约以及任何法律要求。 它是早期可能的社区的第一个治理文件，早在围绕不断发展的社区创建正式治理、使命声明和行为准则之前就发挥作用。
所有许可证的全文都可以在开源促进组织找到：https://open-source.org.cn/licenses/alphabetical
关于如何考虑各种软件许可证与 GPL 结合使用的出色信息可以在这里找到：https://gnu.ac.cn/licenses/license-list.html#SoftwareLicenses
如果您需要让律师快速了解情况，请考虑将他们指向：http://www.ifosslr.org/ifosslr
最初发布在 Outercurve 基金会博客上。 经许可转载。
8 条评论