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

　　很明显，我们做选择之前必须考虑这个许可证是否已经被 美国的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的解决方案。

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