如何为你的代码选择一个开源协议

相信很多刚踏入软件这个行业的小伙伴一如当初的我，对开源软件的各种协议不甚了解被搞昏了头脑。毕竟对于一个新生程序员来说，如何写好代码才是亟待解决的问题，无暇了解这些。随着你项目做得多了代码写得多了，你会发现编码过程中会不时用到其他人的成果，一个项目下来多少会引入一些优秀的库，别人放在公网上开源的DLL，以及一些算法等等。细心的你会注意到即使只是一小段代码，优秀的作者都在最开始会简单地附上一段关于许可的声明，或者说是协议比如"Licensed under the MIT license"，并且一些博客也会标明"此文章发表在CC协议下"。而如果我们Copy了别人的代码或者文字同时没注意这些的话，在国外法律意识特别强的环境下，我们的作品会因触犯别人的权益而违法。因为好多开源协议最低要求是使用者需要保留原作者对代码的声明，不声不响地就拿来用了必然导致恶果。

所以开源不等于免费，开源也不等于没有约束。

何为License

License是软件的授权许可，里面详尽表述了你获得代码后拥有的权利，可以对别人的作品进行何种操作，何种操作又是被禁止的。软件协议可分为开源和商业。当然本文要讨论的当然是开源协议。

对于商业协议，或者叫法律声明、许可协议，每个软件会有自己的一套行文，由软件作者或专门律师撰写。这是什么惊为天人的东西嘛还得请专门的律师。因为涉及到以后侵权打官司这种事情，这种商业条款的行文是非常严谨而讲究的，记得以前看到句调侃的话：'如果法律文件不写得那么生涩难懂，律师们就没饭吃了'，就是说任何文字一旦上升到法律的层次，不要说你接受完了九年义务教育，就是考了个专八也会觉得英语白学了，直接的法律协议什么的那不是给常人看的。而至于法律条款缘何会晦涩难懂，这个偏题有点偏远了，可以查看这里了解。看累了？下面是欢乐时刻，奉上一个协议相关的Joke（笑崩！苹果iOS7升级协议条款中员工神吐槽）。

你丫知道么？这已经是46页，肯定没人读的。我敢打赌大概只有5个人点了"条款和协议"，所以我们想扯点啥就扯点啥吧。 Apple总部5楼的那个tony总是浑身一股沙丁鱼味 有人给我们寄点啥2b向的邮件，我们都得很文艺的用"i笑了"的方式回复。这是我们的工作规定 还记得当年关于Apple Studio的版权合法性争议么？想知道我们怎么摆平的？我们把披头士乐队买下来了。他们中活着的现在没事来给我们唱两曲解解闷，死了的，我们想办法像Miku的3D投影那样，设法在二次元给他们来个复活 我们餐厅永远只卖苹果东西：苹果，苹果汁，苹果煎饼，苹果棒糖。。。不想丢工作的话我们只能吃这些，而哥恰好对苹果过敏，哥现在正处于饿的神志不清乱敲键盘的节奏。 我们伪造了登月真相。其实美国人登月是2008年的事情，我们向你们洗脑它发生在1969，我们绝对有这种洗脑的本事。如果有人发现我知道的太多了，我就会被查水表，但是没关系，没人会看这页。

所以对于大多数人来说，不用自己花大把时间去写许可协议，选择一分广为流传的开源协议是个不错的选择，如果你的作品是开源的话，这样省时又省心。

选择一分协议的好处

你的作品如果不是定性为全商业性质，可以考虑选择一分流行度比较高的开源协议。具体来说的话，你肯定希望作品能够被多数人分享查阅吧，不但提高自己业界的知名度，同时也方便了需要的人为开源做出了贡献。换句话说，你不分享出来的话你的作品的意义何在呢（当然，自己捣腾的私人东西还是自己保留吧）？可是一旦你把你的代码贴出来，这就表示任何人都可以看到并获取，之后发生的事情你无法控制，有的人或许稍微修改一下放进自己的代码中，有的把你的软件改个名字拿去贩卖，有的甚至会拿去把作者名字改为自己然后拿去找工作什么的，而不会有人知道这个作品的原作者，背后辛勤付出了的人。所以为了公开分享你的代码，同时又让你对代码保留一定权利，在作品中声明一个许可协议是非常有必要的，这是很多新人所忽略的问题，同时很多人在使用别人的劳动成果时也会忽视协议的存在，这样不好。所以你会看到我的博客里面时不时会给出连接指向来源页面，同时文末也会列出所有参考过的文章。我相信我做到了这点，别人在转载我的文章的时候，也可以做到这点，这样营造出来的氛围一定会非常和谐，互相尊重/Show
Respect。

多说一句，一个事实让你了解国外开发者在尊重他人劳动成果方面做得是如何的到位，如果A的作品是因为B的作品的启发而来，A甚至都没有使用B任何一句代码，但A会在他的作品里面指明是受到了B的启发"Inspired by XXX link :http://www.blah.com"。

当然有人会觉得，有了一分协议声明在那里，我就需要鸟你么，我拿来用了把作者名字去掉同时还要加上我的名字，你咬我？！这是后话，只是在利益很小的情况下，或者作者不知情的情况下，作者不会追究什么责任，但如果你的产品做成功了，那就不一定了。另外就是，有协议和没声明协议的裸代码是有非常重要区别的，一般作品当中没声明协议的默认为Copy right的，也就是版权保留。此种情况表明他人没有任何授权，不得复制分发修改使用等等，但一如上面所讨论的，这样的话还何来开源，何来分享呢。有了协议的声明，在未来你的维权上面会方便很多，让你的作品在分享的同时保留了自身的一些权利。

快速选择

目前流行的开源协议有很多，并且同一款协议有很多变种，比如你或许看到过' CC Attribution-NoDerivs',' CC Attribution-NonCommercial'同属CC协议（后面会有介绍）。如此纷繁的协议该如何选择？协议太宽松会导致作者丧失对作品的很多权利，太严格又不便于使用者使用及作品的传播。所以除了协议多之外，你还要考虑你对作品想保留哪些权利，放开哪些限制。

如果你不想了解太多，只是想要一个简直直接的答案，下面给出的建议或许适合你。下方关于协议的选择及表格来自GitHub choosealicence项目。

简单宽松的协议

如果你只想要一个简单点的协议不想太麻烦的话。

MIT协议相对宽松但还是抓住了要点的。此协议允许别人以任何方式使用你的代码同时署名原作者，但原作者不承担代码使用后的风险，当然也没有技术支持的义务。jQuery和Rails就是MIT协议。

考虑有专利的情况

如果你的作品中涉及到专利相关。

Apache协议也是个相对宽松与MIT类似的协议，但它简单指明了作品归属者对用户专利上的一些授权（我的理解是软件作品中含有专利，但它授权你可以免费使用）。Apache服务器，SVN还有NuGet等是使用的Apache协议。

代码分享与促进

如果你在乎作品的传播和别人的修改，希望别人也以相同的协议分享出来。

GPL（V2或V3）是一种版本自由的协议（可以参照copy
right来理解，后者是版本保留，那copyleft便是版权自由，或者无版权，但无版权不代表你可以不遵守软件中声明的协议）。此协议要求代码分发者或者以此代码为基础开发出来的衍生作品需要以同样的协议来发布。此协议的版本3与版本2相近，只是多3中加了条对于不支持修改后代码运行的硬件的限制（没太明白此句话的内涵）。

各协议授权详情

下面是更多开源协议的一个表格任君选择，总有一款是你的菜。

不过先来了解一些下方表格中出现的用词的解释：

协议和版权信息(License and copyright notice)：在代码中保留作者提供的协议和版权信息
声明变更(State Changes)：在代码中声明对原来代码的重大修改及变更
公开源码(Disclose Source)：代码必需公开。如果是基于LGPL协议 下，则只需使用的开源代码公开，不必将整个软件源码公开
库引用(Library usage)：该库可以用于商业软件中
责任承担(Hold Liable)：代码的作者承担代码使用后的风险及产生的后果
商标使用(Use Trademark)：可以使用作者的姓名，作品的Logo，或商标
附加协议(Sublicensing)：允许在软件分发传播过程中附加上原来没有的协议条款等

协议	描述	要求	允许	禁止
Apache	一个较宽松且简明地指出了专利授权的协议。	协议和版权信息 声明变更	商用 分发 修改 专利授权 私用 附加协议	责任承担（禁止让作者承担责任，可以理解为免责） 商标使用
GPL	此协议是应用最为广泛的开源协议，拥有较强的版权自由( copyleft )要求。衍生代码的分发需开源并且也要遵守此协议。此协议有许多变种，不同变种的要求略有不同。	公开源码 协议和版权信息 声明变更	商用 分发 修改 专利授权 私用	责任承担 附加协议
MIT	宽松简单且精要的一个协议。在适当标明来源及免责的情况下，它允许你对代码进行任何形式的使用。	协议和版权信息	商用 分发 修改 私用 附加协议	责任承担
Artistic	Perl社区尤为钟爱此协议。要求更改后的软件不能影响原软件的使用。	协议和版权信息 声明变更	商用 分发 修改 私用 附加协议	责任承担 商标使用
BSD	较为宽松的协议，包含两个变种BSD 2-Clause 和BSD 3-Clause，两者都与MIT协议只存在细微差异。	协议和版权信息	商用 分发 修改 私用 附加协议	责任承担
Eclipse	对商用非常友好的一种协议，可以用于软件的商业授权。包含对专利的优雅授权，并且也可以对相关代码应用商业协议。	公开源码 协议和版权信息	商用 分发 修改 专利授权 私用 附加协议	责任承担
LGPL	主要用于一些代码库。衍生代码可以以此协议发布（言下之意你可以用其他协议），但与此协议相关的代码必需遵循此协议。	公开源码 库引用 协议和版权信息	商用 分发 修改 专利授权 私用 附加协议	责任承担
Mozilla	Mozilla Public License(MPL 2.0)是由Mozilla基金创建维护的。此协议旨在较为宽松的BSD协议和更加互惠的GPL协议中寻找一个折衷点。	公开源码 协议和版权信息	商用 分发 修改 专利授权 私用 附加协议	责任承担 商标使用
No license	你保留所有权利，不允许他人分发，复制或者创造衍生物。当你将代码发表在一些网站上时需要遵守该网站的协议，此协议可能包含了一些对你劳动成果的授权许可。比如你将代码发布到GitHub，那么你就必需同意别人可以查看和Fork你的代码。	协议和版权信息	商用 私用	分发 修改 附加协议
Public domain dedication	在许多国家，默认版权归作者自动拥有，所以Unlicense协议提供了一种通用的模板，此协议表明你放弃版权，将劳动成果无私贡献出来。你将丧失对作品的全部权利，包括在MIT/X11中定义的无担保权利。	N/A	商用 分发 修改 私用	责任承担

非代码类作品的协议

上面各协议只是针对软件或代码作品，如果你的作品不是代码，比如视频，音乐，图片，文章等，共享于公众之前，也最好声明一下协议以保证自己的权益不被侵犯。针对非代码的数字作品的协议，最通用的莫过于Creative
Commons(也是你经常在别人博客下面可以看到的CC协议)协议。所以现在你见到博客园别人文章下面的签名就不会感到陌生了。

无协议

你没有义务也没人非要你必需在自己的代码作品里面加上一个开源协议。但一如上文所讨论过的优点，如果你想把代码分享出来，最好还是选择一个适合的开源协议，这样别人用着放心。

Reference

https://github.com/github/choosealicense.com

http://choosealicense.com/

http://www.smashingmagazine.com/2011/06/14/understanding-copyright-and-licenses/


Feel free to repost but keep the link to this page please!

原文地址：http://www.cnblogs.com/Wayou/p/how_to_choose_a_license.html