最为方便是 license 创建方式：当你在 GitHub 上你创建新的 repository 的时候，你可以直接选择一些比较好的 license：
license
以下是转载资料：如何为你的代码选择一个开源协议
随着你项目做得多了代码写得多了，你会发现编码过程中会不时用到其他人的成果，一个项目下来多少会引入一些优秀的库，别人放在公网上开源的 DLL，以及一些算法等等。细心的你会注意到即使只是一小段代码，优秀的作者都在最开始会简单地附上一段关于许可的声明，或者说是协议比如"Licensed under the MIT license"，并且一些博客也会标明"此文章发表在 CC 协议下"。而如果我们 Copy 了别人的代码或者文字同时没注意这些的话，在国外法律意识特别强的环境下，我们的作品会因触犯别人的权益而违法。因为好多开源协议最低要求是使用者需要保留原作者对代码的声明，不声不响地就拿来用了必然导致恶果。所以开源不等于免费，开源也不等于没有约束。
何为 License？
License 是软件的授权许可，里面详尽表述了你获得代码后拥有的权利，可以对别人的作品进行何种操作，何种操作又是被禁止的。软件协议可分为开源和商业。当然本文要讨论的当然是开源协议。
对于商业协议，或者叫法律声明、许可协议，每个软件会有自己的一套行文，由软件作者或专门律师撰写。这是什么惊为天人的东西嘛还得请专门的律师。因为涉及到以后侵权打官司这种事情，这种商业条款的行文是非常严谨而讲究的，记得以前看到句调侃的话：'如果法律文件不写得那么生涩难懂，律师们就没饭吃了'，就是说任何文字一旦上升到法律的层次，不要说你接受完了九年义务教育，就是考了个专八也会觉得英语白学了，直接的法律协议什么的那不是给常人看的。而至于法律条款缘何会晦涩难懂，这个偏题有点偏远了，可以查看这里了解。
所以对于大多数人来说，不用自己花大把时间去写许可协议，选择一份广为流传的开源协议是个不错的选择，如果你的作品是开源的话，这样省时又省心。
选择一分协议的好处
你的作品如果不是定性为全商业性质，可以考虑选择一份流行度比较高的开源协议。具体来说的话，你肯定希望作品能够被多数人分享查阅吧，不但提高自己业界的知名度，同时也方便了需要的人为开源做出了贡献。换句话说，你不分享出来的话你的作品的意义何在呢（当然，自己捣腾的私人东西还是自己保留吧）？可是一旦你把你的代码贴出来，这就表示任何人都可以看到并获取，之后发生的事情你无法控制，有的人或许稍微修改一下放进自己的代码中，有的把你的软件改个名字拿去贩卖，有的甚至会拿去把作者名字改为自己然后拿去找工作什么的，而不会有人知道这个作品的原作者，背后辛勤付出了的人。所以为了公开分享你的代码，同时又让你对代码保留一定权利，在作品中声明一个许可协议是非常有必要的，这是很多新人所忽略的问题，同时很多人在使用别人的劳动成果时也会忽视协议的存在，这样不好。所以你会看到我的博客里面时不时会给出连接指向来源页面，同时文末也会列出所有参考过的文章。我相信我做到了这点，别人在转载我的文章的时候，也可以做到这点，这样营造出来的氛围一定会非常和谐，互相尊重/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中定义的无担保权利。 |
非代码类作品的协议
上面各协议只是针对软件或代码作品，如果你的作品不是代码，比如视频，音乐，图片，文章等，共享于公众之前，也最好声明一下协议以保证自己的权益不被侵犯。针对非代码的数字作品的协议，最通用的莫过于Creative Commons(也是你经常在别人博客下面可以看到的CC协议)协议。所以现在你见到博客园别人文章下面的签名就不会感到陌生了。
无协议
你没有义务也没人非要你必需在自己的代码作品里面加上一个开源协议。但一如上文所讨论过的优点，如果你想把代码分享出来，最好还是选择一个适合的开源协议，这样别人用着放心。
网友评论