常见开源许可协议（共享协议）的比较与浅析

关于开源与许可协议

• 开源，其实并不仅仅是适用于对某种软件生产过程的描述，准确的定义参照维基百科 ：开放源代码描述了一种在产品的出品和开发中提供最终源材料的做法。也就是说存在开源的硬件甚至别的产品。不过我们还是主要针对“代码”来讨论下面的各种协议。
• 许可协议是一种作者或者生产过程参与者出让自己产品或工作的部分权利的授权方式，往往具有法律效益，通过指定或应用一种许可协议可以方便的处理这种授权时的各项事宜并且规避。

常见的开源协议（按英文首字母排列）

一、Apache协议

Apache协议有三个版本V1.0，V1.1和V2.0，V2.0是现在通行的版本。

授权与要求

Apache协议允许对该协议下发布的代码进行再修改，再发布，需要遵循下列要求：

• （再）发布代码时必须附带Apache协议，也就是要给代码的使用者一份协议。和BSD协议类似；
• 需要在被修改的代码中说明对代码的修改；
• 衍生代码中需对原作者的专利、协议及商标按要求进行说明。
• 可以增加自己的许可说明，但是不能对Apache的内容进行覆盖，产生冲突，并且不能忘了附带上Apache协议（参见第一条）。

特点

apache协议最大的的特点在于定义了专利许可，在使用经Apache协议授权的代码或者别的内容时，可以不把自己修改或再发布的内容开源。这一点使得本协议在商业领域应用十分广泛。

另外，Apache协议还具有这些特点：

• 永久授权并且授权不可撤消，被授权之后就不用担心被撤销而不能使用曾经被授权的内容；
• 授权是免费的，并且没有版税；
• 任何人都可得到授权，无排他性。

举例

Google的Android系统就使用了Apache协议，可以看阮一峰的文章 ，以及另一篇 。

二、BSD协议

授权与要求

使用BSD授权的代码可以自由使用这些代码，包括修改、再分发等，需要满足一下要求：

• 使用并修改、再发布BSD授权的源代码时，新的代码需要附带BSD协议，这点与Apache协议类似；
• 使用了BSD授权的代码后，再发布的不是源代码而是二进制档，也同样需要附带BSD协议并说明；
• 不能使用原作者的商标、名称等用于宣传和市场推广。（简单BSD协议对这一点不作要求）

特点

BSD协议的精髓在于几乎“完全自由”，使用BSD的源代码时可以非常随意。在尊重原作者著作权的前提下，BSD极大地鼓励了代码共享，因此BSD协议也是商业友好的。BSD协议同时也兼容GPL协议，这使得它在开源界也非常受欢迎。使用BSD许可协议发布的软件属于自由软件（比开源更自由）。

举例

BSD软件 均采用此协议发布。中科麒麟 因为疑似使用了FreeBSD的源代码而产生了不小的争议 。其实如果真的用了，遵循BSD协议又有什么难度呢?

三、GPL （不说GPL协议，因为L是License，就是协议）

授权与要求

• 权利：GPL 保证开发者的权利的同时为使用者提供了的复制，分发，修改的权利，你可以对该授权下的代码复制、分发、修改以及用以盈利。
• 要求：源代码再分发时候需要附带该协议，并且只要在软件中使用GPL了协议的产品，则本软件必须也采用GPL协议，即开源并免费。

特点

GPL在开源界应用非常广泛。一个词就可以概括GPL的最大特征：传染性，就是所谓的Copyleft。这点从其要求就可以看出，在自己的软件中使用了GPL的代码并发 布就相当于卖身开源^o^。因而可以看出，GPL就是一个完全属于开源的协议。

举例

很多开源软件如Linux和GCC采用此协议发布。

四、LGPL

授权与要求

LGPL与GPL有些类似，不同之处在于，商业软件可以引用LGPL发布的库而并不开放自己产品的源代码，但如果想修改并使用LGPL下的代码的就必须同时开放自己的源代码。在商业应用上，LGPL既保证了代码被更广泛的利用，同时也很好地保护了作者的权利。使用LGPL的软件可以向GPL转换。

举例

LGPL的典型例子是Openoffice.org。

五、MIT 许可协议

特点与要求

MIT许可协议是本文所列最宽松的一种开源协议，MIT协议与BSD也比较类似，但约束更少，授权更宽。

使用MIT协议时被授权人有权利使用、复制、修改、合并、出版发行、散布、再授权及贩售软件及软件的副本。被授权人可根据程序的需要修改许可协议为适当的内容。而需要履行的义务仅仅是在软件和软件的所有副本中都必须包含版权声明和许可声明。（via 维基百科 ）

知识共享协议（Creative Commons，CC）

知识共享，也译作“创作共用”，是一个非盈利性的组织名称，也是授权协议的名称。其宗旨在于可以共享著作等并使其更好地流通和完善。

协议的使用范围

在版权保护范围的作品例如学术、文学、美术、音乐、电影等都适合使用这种协议，而对于软件作品，CC也有与GPL进行结合的方案，也就是CC可以兼容GPL。

分类及要求

四个选项

使用者可以将以下四个的选项进行组合、搭配，构成六种不同的核心协议。

1. 署名 ： 您允许他人对自己享有著作权的作品及演绎作品进行复制、发行、展览、表演、放映、广播或通过信息网络向公众传播，但在这些过程中对方必须保留您对原作品的署名。
2. 非商业性使用 ：您允许他人对您享有著作权的作品及演绎作品进行复制、发行、展览、表演、放映、广播或通过信息网络向公众传播，但仅限于非商业性目的。
3. 禁止演绎 ：您允许他人对您的作品原封不动地进行复制、发行、展览、表演、放映、广播或通过信息网络向公众传播，但不得进行演绎创作。
4. 相同方式共享 ：只有在他人对演绎作品使用与您的原作品相同的许可协议的情况下，您才允许他人发行其演绎作品。

• 其中许可协议协议不能同时包含“相同方式共享”和“禁止演绎”许可要素，“相同方式共享”要素仅适用于演绎作品。

六种核心协议

1. 署名－非商业使用-禁止演绎 (by-nc-nd)： 这种协议允许作品重新传播，但不能作为商业用途且不能修改，其限制在六中协议中最为严格。常被称为“免费广告”许可，
2. 署名-非商业性使用-相同方式共享 (by-nc-sa)： 只要不将作品用于商业，并在再次共享时使用同样的共享方式（本协议）且注明原作者，就可以使用这种协议下的作品并做出自己修改、节选，而且可以再次发布。
3. 署名-非商业性使用 (by-nc)： 与上一条相比没有多大差别，只是不需要以同样协议进行共享。
4. 署名-禁止演绎 (by-nd)： 只要完整使用此协议下的作品不做修改并且保留原作者署名，他人就可该作品进行再传播，并没有商业或非商业的限制。
5. 署名-相同方式共享 (by-sa)： 他人可以在商业或非商业目的下使用此协议下的作品，包括再次传播、修改、节选等，但必须使用本协议进行共享，而且要注明原作者。
6. 署名 (by)： 只需要注明原作者，他人就可以任意使用此协议下的作品，不限制商业与否，演绎与否，也不限制比须以某种形式共享。

举例

本站原创内容采用均采用署名-非商业性使用-相同方式共享 (by-nc-sa) 的CC协议发布。

维基百科注明其文字在知识共享 署名-相同方式共享协议 下提供。

公有领域（Public Domain）

作品的原作者或所有者的专有权利到期而作品进入公共领域，任何人都可以自由出版与使用这些作品，但任何人都不“拥有”这些作品。其并不存在协议与授权的问题，这里只是列出来与这些开源协议做一个对比。公有领域也可以归入CC的范畴。

最终用户许可协议EULA

特点

这并不是开源（共享）协议，在这里仅作对比阐述，EULA是大多数私有软件采用的最终用户授权方式，这种授权方式规定用户可以如何而不可以如何。如果你希望使用这种软件产品，则必须接受，不容有任何商议的余地；如果不同意只能不使用该产品，若是购买所得，可以向经销商商议退款、退货。这种霸道的方式引来了众多用户的不满和一些人的调侃 。

比较

与各种开源协议比较，EULA并不对代码进行授权，而GPL等开源协议不仅包含对最终用户授权的说明，更是对源代码授权的描述。

本文少量文字直接来源于维基百科或CC中国官网。