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

　　如果你想允许任何人在任何时候对这个软件做任何事情，那么使用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许可(允许软件被包含在尽可能多的地方)在那个时候是不能并存的。

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

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