【IT168 评论】我最近在几场讨论中涉及到一个问题，那就是“选择哪一种开源或者自由的软件许可证是适合我的项目的?”。面对数量庞杂且增长迅速的许可证类型，我有我的一些方法。我先声明我不是一个律师，这不是一个关于法律上的建议。你应该根据你的需要和你所能承受的风险能力去确定这些选择和建议。

　　很明显，我们做选择之前必须考虑这个许可证是否已经被 美国的Open Source Initiative协会(OSI)所认可。 OSI协会在90年代发布了一系列软件许可被认为是“开源性质”的开源定义条文( Open Source Definition)。任何人都可以向OSI协会提交许可证并就许可做讨论分析。如果该许可符合OSD的定义条文，这个许可将被列入到开源软件许可证名单( the canonical list)。

　　然而，这看起来仅仅只是一个开始。最近我发现一个被叫做“Clear BSD License”的许可证，它试图明确地说专利是不用考虑的。它且包括(New BSD 和 Simplified BSD )都没有出现在OSI的列表中。因此，这些许可是不值得考虑的。发明新的许可类型作为已有许可类型的小衍生，这种尝试并不是什么特别有益的创新，它将会造成大量关于法律方面的问题。现今存在着一个广泛的，被OSI所审核过的许可集合。 这些许可覆盖着数百万行的软件代码，涉及到数十亿美元的产销。还没有被OSI核准的许可类型是什么，这真是一个很难被描述清楚的问题。

　　在考虑开源许可类型的时候，有几条准绳是可以参考的：

　　• 关于软件的修改以及衍生版本的开发，有哪些尊重性与互惠性的原则说明?

　　• 关于专利授权与诉讼方面的规定是哪些?

　　• 关于这些许可声明上的条款，是由哪些法律管辖机构行使司法管辖权的?

　　互惠的问题都是和“copyleft”相关的，即是否使用或不使用 附加在 修改过的和衍生的源代码 许可证上的软件的源代码，以及 那 些修改和衍生的源代码 是否需要发布的问题。

　　一个极端的例子是哪些没有“著佐权(copyleft)”需求的许可证，这些许可证几乎允许任何人以任何方式去使用软件，它们远远超出了版权(copyright)概念所需求的范围。New BSD License(Modified BSD License), Simplified BSD License(FreeBSD License), MIT License, Apache 2.0 和 Microsoft Permissive License 这些许可都属于这一范畴。

　　有些类型的许可是维护著佐权(copyleft)概念的，它所围绕的是软件本身。除了提供软件的使用外，在大型软件中项目中，这些软件的许可还包含各种差异化的内容(例如：包含封闭性和专有性)。这类许可包括Eclipse Public License, Newer Mozilla Public License 2.0 和 Microsoft Reciprocal License。

　　另外的一些著佐权(copyleft)的范围属于强著佐权(Strong copyleft)许可。软件的自由被自由软件基金会(Free Software Foundation)依照一个软件用户所必须拥有的某些自由来定义。强著佐权(Strong copyleft)支持软件的自由。当这些软件在工程中使用或者传播的时候，很多开发者支持软件的自由，用于证明这种支持的是GPL许可簇(GPL2.0, GPL3.0, 和 Affero GPL3.0)，它们作为一种能确保强著佐权(Strong copyleft)和更强的许可证附件(strongest license attachment)的方式而存在。

　　当软件刚开始在网络上传播的时候，软件专利并非显得十分重要，所以软件的许可也不并未提及。在90年代末，软件专利开始普及，并且更多的企业法律团队参与到许可证条文的编写当中，因为他们有更多的机会参与到开源软件开发和开源基金的项目当中。 Apache 2.0 许可证， Mozilla 公共许可证 2.0， Eclipse 公共许可证，GPL许可证和微软许可证就可以充分显示这点。每一个许可证都会明确地声明该许可的专利。每一个许可证都会不同程度的包含专利诉讼条文。

　　在较强的控制手段中，不得不提到法定管辖，因为在一些许可中明确的提到了它，并且它也是一些人的顾虑所在。仅因为这个原因，法定管辖可以说是一个强力控制手段。(在MPL(Mozilla公共许可， 是一个备受争议的早期协议)升级到2.0版本所做的调整中，特地试图去处理管辖权的问题。)

　　在license的选择方面还有一些其他的考虑方面：

　　• 是否存在雷同的project?

　　• license, foundation/corporate/commercial的关联关系

　　每种语言(perl,PHP,Python)的项目都有它们自己的license (Artistic License 2.0, PHP License 3.0, Python License 2.0)。如果你致力于一个与某个特定的开源语言社区关系很大的项目，你应该考虑使用该社区的license作为解决混合模块(modules)和依赖关系dependencies的解决方案。

　　随着软件知识产权相关法律的进步，以及互联网的发展为人们协同开发软件提供了巨大的空间，商业机构开始进入。我们可以发现他们在一些开源许可证下产生了一些开源方面的成就。甚至他们的法律专业团队开始参与开源许可证的修订工作，包括许可证的结构和语言规范(比如，术语和定义)。对开源见识不多的律师，可能会因此对开源许可证感到更加的舒服。

　　总而言之，如果你的主要动机是参与开源项目，那么我认为，你大致可以选择如下几种开源许可证。(在此，我仅讨论那些被广泛使用的许可证，以及那些由商业巨头或者非营利性开源组织推动的许可证。)

　　如果你想允许任何人在任何时候对这个软件做任何事情，那么使用MIT或者新版的(3-clause)BSD许可证吧。也就是说：没有CoryRight，没有谈论专利。这些许可证都来自学术界，软件专利没有被关注的那段时间。

　　如果你想允许任何人对这个软件做任何事情(也就是说没有CopyRight)，但是觉得当面临诉讼的时候，有一些关于专利和许可终止的事情需要被申明，或者你需要企业法律顾问阅读起来更舒适的一个许可证。那么可以看看Apache 2.0 License或者Microsoft Permission License。这些许可证都是为促进一个完全开放的共享环境而编写，但是更多的是在企业的角度(注意结构和语言)。并且都开始包含不同程度的内置Patent Retaliation专利。

　　译者注：对于Patent Retaliation，不能直接的翻译为“专利报复”，找不到适合的词语来描述，对其具体的解释可见相关链接。

　　如果你希望别人能够在你的软件基础上进行创建修改[可能是产品]，但要确保核心软件项目被修改了的部分依旧保持开源(比如修改了的部分必须公布出来)，你可能会想到Eclipse公共许可证(EPL)，或者新的Mozilla公共许可证2.0(MPL)或Microsoft互惠许可(MRL)。这些是从商业/企业的角度支持的“弱的”公共版权发展出来的新颖的授权方式，[注意：EPL以纽约州为其司法管辖权所在地]注意它们各自的专利声明。

　　如果你是自由软件的坚定支持者 ，或者你想要确保：你的软件源代码的在任何地方被用到而产生的衍生物 ，它能最大限度作为开源而发布，以确保软件的自由，那么你应该根据 你的需求去看看GPL2.0或GPL3.0。

　　很多人在这样或者那样的项目中，因为开源许可证的事情费尽周折，去创建了一个所谓“正确”的许可证。这是一个很有意思的两面性问题。

　　当许多公司创建开源项目时，会很担心它们的专利。当谷歌推出WebM项目时，用了一个很有意思的办法去解决这个问题，它们选择了New BSD license，但同时又创建了一个特殊的“附加知识产权授予”条款，去包含一些关于专利权的特殊诉求。

　　关于真正的知识产权法律，专利持有人可以选择授予某些人(自然人或者法人)以某些方式去使用这些专利的权利。微软使用最终用户许可协议(EULA)主要针对Windows操作系统，不同于微软，MySQL AB公司使用企业经营协议(Enterprise License Agreement)不仅拓展闭源软件业务也着手那些GPL许可的软件业务。在早期(PHP3之前)，来源于PHP的工程有一对矛盾的许可，因为GPL2.0之前的许可与早期的PHP许可(允许软件被包含在尽可能多的地方)在那个时候是不能并存的。

　　面对众多的许可选择，我不会刻意去画一个表格或者一个树。它们有如此众多的边界，又有那么多细微的差别，真的很难用某种恰当地方式去呈现出它们所折射的复杂历史和产生背景。总是有一些问题是关于“当……的时候采用什么样的解决方案?”。这些问题貌似会涉及到法律咨询方面的事宜或者可能有很强的司法敏感性。

　　同样地，冠上开源软件的许可可并不是简简单单就等于是合法使用。在开源软件的作者(们)首次发布软件之前，许可证的选择反映了在法律上关于社会契约方面的诉求。在早期的社区发展中，成员间渐渐有了正式的管理条款，宗旨声明和行为准则，这些就是第一份管理文档。