GitHub 一代：开源许可证已成过去时
高度放任只是开源许可证授权模式变革的过渡阶段，最终我们将进入一个全新的时期：无许可证模式。
多年以来，开源软件正在从主张“copyleft”的GNU GPL（通用公共许可证授权）等开源授权模式向更加开放灵活的Apache风格的授权模式转移。这场变革的主导者是话语权不断提升的开发者，典型的如GitHub一族，正在推动开源软件走向无授权时代。
无许可证时代的放纵
在自由软件和开源软件的青铜时代，copyleft许可证授权模式占据绝对的主导地位。但是近些年来，一些高度开放的许可证授权方式如BSD和MIT的势头正在上升，Remonk分析师Donnie Berkholz给出了一个分析图表清晰地描绘了这种趋势：
高度放任只是开源许可证授权模式变革的过渡阶段，最终我们将进入一个全新的时期：无许可证模式。正如自由软件倡导者Glyn Moody所言：“向更加开放的许可证模式的范型转移只有一个逻辑结果：允许做一切事情。”
GitHub许可证的黑洞
正 如软件自由法律中心高级职员顾问Aaron Williamson在今年的LInux协作峰会上所说的，GitHub上的绝大多数项目都没有附加任何许可证条款。众所周知，GitHub是当今开源软 件的集散地，但是其中只有14.9%的代码库（169万中的21.9万）在顶级目录中包含了许可证授权条款。
换而言之，GitHub上的大多数代码即不是开源软件，也不是私有软件，或者别的什么软件，它们仅仅是代码而已。
新一代开发者就像论坛发帖一样在GitHub上传代码，对于这些开发者来说，授权许可和管理都是马后炮，代码才是一切。至于原因，Gartner和Forrester两大市场分析机构的研究结论达成了一致：因为开发者需要灵活性。更少的授权许可要求意味着更多的灵活性。
授权是否还有必要？
去许可证化的趋势并非没有问题，Outercurve基金会的董事Stephen Walli在推文中指出GitHub为代表的混乱的，缺乏治理和授权模式的代码分享将导致“软件变成疾病”。
虽 然GitHub一代并不在意，不过一旦他们的项目吸引了买家或者收购者，你们源代码的“纯洁性”问题就将立刻付出水面。根据Black Duck的研究，开源的合规性（Open-Source Compliance）在公司收购与合并中受到的关注程度正在不断上升。（如下图）
显然，GitHub一代的“无许可证主义”并未完全失控，Berkholz在分析大量GitHub项目后发现，随着软件项目的成长，开发团队将开始着手肃清许可证问题，这往往是因为他们获得了企业客户，或者团队中增加了专业开发者等。”
最终，GitHub的“恣意妄为的无许可证文化”的疯狂，其实有助于开发和验证早期的开源项目，而这些项目最终依然会过渡到Apache风格的授权模式。
参考内容：开源许可证的种类与选择（以下内容摘自百度百科）
开 源软件的许可证比较繁多和复杂，对于我们来说，经常遇到的开源许可证大多是GPL和BSD两种，此外还有 Adobe经常使用的MPL许可证。简单来说，GPL许可证具有相当强的传染性，如果你想要把一份采用GPL许可证的代码经过修改后再次发布二进制版本， 那么你同时也必须再次开放其源代码。而BSD许可证则相对宽松许多，它允许对源代码的修改后再次发布时仅包含许可证而不必再次开放源代码，且可以将修改后 的版本专为商业用途（如微软的产品中引入了BSD网络部分的源码，修改后则作为专有软件出售）。
1. 从开源软件开发的角度来看，若只是利用开源程序包作为工具来生产与其分离的作品，那么绝大多数开源许可证都是可以的
2. 如果将软件用于商业性发行且不愿意发行自己所修改的源码，那么可以选择BSD许可证，它能使修改保持专有
3. 若希望源码总是自由的，GPL许可证及LGPL许可证是最佳选择（Icebird注：这里不推荐采用LGPL许可证，LGPL许可证有很大的漏 洞，divX从开源突然转为专有就是一例，从此以后，开源软件的参与者都对LGPL许可证的源码报有相当的戒心，如果希望在开源版本之外能够有一个你自己 开发的更强大的商用版本出售，建议采用BSD，这样你自行对其的修改就不必再次公开了）
4. 若想在与其它人共享代码时提供相应的保护，可以选择MPL许可证，该许可证可通过将软件(和任何对它的修改)分为受保护部分和贡献部分，在完全开放的 GPL许可证和封闭的BSD许可证之间架起一座巧妙的桥梁。
来自IT经理网