开源许可证都有什么区别,一般开源项目用什么许可证?

平时代码都不加许可证,因为不是太在意,但是今天突然有老外邮件给我问我要许可证,这个项目用来干什么的无所谓,就直接告诉人家随便用了。这才意识到证书的重要性,而且对于选择怎样的证书的确很困惑,不是仅仅限于现在的项目,将来写的代码,可能也要别样的证书呢。 WIKI整理: GPL:如果有开源强迫症,是个不错的选择 MIT:如果没有特别的要求,这个比较合适
关注者
192
被浏览
16218

7 个回答

I've googled it for you. Hopefully it will help.

对于你这样的选择困难症…Github专门发布了一个网站Choosing an OSS license doesn’t need to be scary来帮助开源项目开发者。

1. 我想要一个简单宽松的许可证

建议: MIT许可证。这是一个宽松的、简明扼要的许可证,只要用户在项目副本中包含了版权声明和许可声明,他们就可以拿你的代码做任何想做的事情,你也无需承担任何责任。

使用该许可证的项目:jQuery、Rails

2. 我比较关心专利

建议: Apache许可证。这类似于MIT许可证,但它同时还包含了贡献者向用户提供专利授权相关的条款。

使用该许可证的项目:Apache、SVN和NuGet

3. 我关心项目的共享改进

建议:GPL( V2或 V3)许可证。这是一种copyleft许可证,要求修改项目代码的用户再次分发源码或二进制代码时,必须公布他的相关修改。V3版本与V2类似,但其进一步约束了在某些限制软件更改的硬件上的使用范围。

使用该许可证的项目:Linux、Git

4. 我的开源项目不是代码

建议: Creative Commons。这是一个相对宽松的版权协议。它只保留几种了权利(some rights reserved)。使用者可以明确知道所有者的权利,不容易侵犯对方的版权,作品可以得到有效传播。
作为作者,你可以选择以下1~4种权利组合:
1. 署名(Attribution,简写为BY):必须提到原作者。
2. 非商业用途(Noncommercial,简写为NC):不得用于盈利性目的。
3. 禁止演绎(No Derivative Works,简写为ND):不得修改原作品, 不得再创作。
4. 相同方式共享(Share Alike,简写为SA):允许修改原作品,但必须使用相同的许可证发布。

5. 更多选择

Licenses - ChooseALicense.com,这里提供了Apache/ GPL/ MIT/ Artistic/ Eclipse/ BSD/ LGPL/ Mozilla/ No License/ Public Domain Dedication协议的适用情形、许可内容、禁止内容,及协议全文。

6. 不使用任何许可


另外,前面答主提到的阮一峰博文”如何选择开源许可证?“亦可作为简单参考。


Part of the translation in this passage came from CSDN - Github Open Source License.

如果用到了开源代码,就应该按照协议进行开源。

根据开源协议百度百科及@刘哇勇 的博文“如何为你的代码选择选择一个开源协议”整理了一下主流开源的开源协议,以及我们改如何选择。

License是软件的授权许可,里面详尽表述了你获得代码后拥有的权利,可以对别人的作品进行何种操作,何种操作又是被禁止的。软件协议可分为开源和商业两类,对于商业协议,或者叫法律声明、许可协议,每个软件会有自己的一套行文,由软件作者或专门律师撰写,对于大多数人来说不必自己花时间和精力去写繁长的许可协议,选择一份广为流传的开源协议就是个不错的选择

世界上开源软件协议OPEN SOURCE LICENSE的种类非常之多,并且同一款协议有很多变种,协议太宽松会导致作者丧失对作品的很多权利,太严格又不便于使用者使用及作品的传播,所以开源作者要考虑自己对作品想保留哪些权利,放开哪些限制

一、主流的开源协议

1. GPL

GPL,是GNU General Public License的缩写,为GNU通用公共授权非正式的中文翻译。我们很熟悉的Linux就是采用了GPL,GPL协议和BSD, Apache License等鼓励代码重用的许可很不一样,GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux,包括商业公司的linux和linux上各种各样的由个人,组织,以及商业软件公司开发的免费软件了。

  • GPL1即最初的版本,发布于1989年一月,其目的是防止那些阻碍自由软件的行为,而这些阻碍软件开源的行为主要有两种(一种是软件发布者只发布可执行的二进制代码而不发布具体源代码,一种是软件发布者在软件许可加入限制性条款)。因此按照GPLv1,如果发布了可执行的二进制代码,就必须同时发布可读的源代码,并且在发布任何基于GPL许可的软件时,不能添加任何限制性的条款。
  • GPL2在1991年6月发布,与此同时第二个许可证程序库GNU通用公共许可证(LGPL,the Lesser General Public License)也被发布出来并且一开始就将其版本定为第2版本以表示其和GPLv2的互补性。这个版本一直延续到1999年,并分支出一个派生的LGPL版本号为2.1,并将其重命名为轻量级通用公共许可证(又称宽通用公共许可证)(Lesser General Public License)以反映其在整个GNU哲学中的位置。
  • GPL3正由斯托曼起草,由伊本·莫格林和软件自由法律中心(Software Freedom Law Center) 提供法律咨询。斯托曼在2006年2月25日自由及开源软件开发者欧洲会议的演讲上说在所有的改动中,最重要的四个是:解决软件专利问题;与其他许可证的兼容性;源代码分区和组成的定义;解决数位版权管理(DRM)问题。

GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用,修改后的代码或者衍生代码)GPL 协议的产品,则该软件产品必须也采用GPL协议,即必须也是开源和免费,这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题,还可以享受免费的优势,由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议,对于使用GPL协议的开源代码,商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。

2. BSD

BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用,修改源代码,也可以将修改后的代码作为开源或者专有软件再发布。但”为所欲为”的前提当你发布使用了BSD协议的代码,或则以BSD协议代码为基础做二次开发自己的产品时,需要满足三个条件

  • 如果再发布的产品中包含源代码,则在源代码中必须带有原来代码中的BSD协议。
  • 如果再发布的只是二进制类库/软件,则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
  • 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD 代码鼓励代码共享,但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码,也允许使用或在BSD代码上开发商业软件发布和销售,因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议,因为可以完全控制这些第三方的代码,在必要的时候可以修改或者二次开发。

3. MIT

MIT许可证之名源自麻省理工学院(Massachusetts Institute of Technology, MIT),又称“X条款”(X License)或“X11条款”(X11 License),是一份简短而宽松的协议,只提供了版权保护和声明,它授予他人复制,修改,合并,发布,分发,授权和/或销售本软件的副本的权力,被授权人可根据程序的需要修改授权条款为适当的内容。作者只想保留版权,而无任何其他了限制,也就是说必须在发行版里包含原许可协议的声明,无论以二进制发布的还是以源代码发布

4. MPL

MPL是The Mozilla Public License的简写,是1998年初Netscape的 Mozilla小组为其开源软件项目设计的软件许可证。MPL许可证出现的最重要原因就是,Netscape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益,同著名的GPL许可证和BSD许可证相比,MPL在许多权利与义务的约定方面与它们相同。(因为都是符合OSIA认定的开源软件许可证)。但是,相比而言MPL还有以下几个显著的不同之处:

  • MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来,以保证其他人可以在MPL的条款下共享源代码。但是,在MPL许可证中对“发布”的定义是“以源代码方式发布的文件”,这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口,除了接口程序的源代码以MPL许可证的形式对外许可外,源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些,就为借鉴别人的源代码用做自己商业软件开发的行为留了一个豁口。
  • MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序
  • 对软件专利的态度,MPL许可证不像GPL许可证那样明确表示反对软件专利,但是却明确要求源代码的提供者不能提供已经受专利保护的源代码(除非他本人是专利权人,并书面向公众免费许可这些源代码),也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。
  • 对源代码的定义。在MPL(1.1版本)许可证中,对源代码的定义是:“源代码指的是对作品进行修改最优先择取的形式,它包括:所有模块的所有源程序,加上有关的接口的定义,加上控制可执行作品的安装和编译的‘原本’(原文为‘Script’),或者不是与初始源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码。”
  • MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定,就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。

5. Apache License 2.0

Apache License是著名的非盈利开源组织Apache采用的协议,该协议和BSD类似,同样鼓励代码共享和尊重原作者的著作权,同样允许代码修改,再发布(作为开源或商业软件)。需要满足的条件也和BSD类似:

  • 需要给代码的用户一份Apache License。
  • 如果你修改了代码,需要再被修改的文件中说明。
  • 在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议,商标,专利声明和其他原来作者规定需要包含的说明。
  • 如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有Apache License。你可以在Notice中增加自己的许可,但不可以表现为对Apache License构成更改。

Apache License也是对商业应用友好的许可,使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。

6. LGPL

LGPL(亦称GPL V2)是GPL的一个为主要为类库使用设计的开源协议,和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL 允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。

但是如果修改LGPL协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用,但不适合希望以LGPL协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用。GPL/LGPL都保障原作者的知识产权,避免有人利用开源代码复制并开发类似的产品。

二、选择适合自己的开源协议

乌克兰程序员Paul Bagwell,画了一张分析图,介绍最流行的六种开源许可证GPL、BSD、MIT、MPL、Apache和LGPL下图为国内大牛阮一峰汉化了版本。

1. 简单宽松的协议

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

2. 有专利的需求

如果你的作品中涉及到专利相关,Apache协议也是个相对宽松与MIT类似的协议,但它简单指明了作品归属者的著作权,Apache服务器,SVN还有NuGet等是使用的Apache协议。

3. 代码分享与促进

如果你在乎作品的传播和别人的修改,希望别人也以相同的协议分享出来。GPL(V2或V3)是一种版本自由的协议(可以参照copy right来理解,后者是版本保留,那copyleft便是版权自由,或者无版权,但无版权不代表你可以不遵守软件中声明的协议)。此协议要求代码分发者或者以此代码为基础开发出来的衍生作品需要以同样的协议来发布。

4. 主流协议授权详情

看完以上信息,你是否对主流的开源协议和如何为自己的开源项目选择合适的协议有了一定的了解呢?希望当每一位开源作者的项目被侵权时都能积极维护自身的权利,也希望大家更“合法”的应用开源项目,创造一个良好的开源环境。

开源不等于免费,开源也不等于没有约束。

原文链接:如何为你的代码选择一个开源协议 - 刘哇勇 - 博客园


码云 Gitee.com
发现更多优质开源项目:最新推荐 - 码云 - 开源中国
团队流畅、高效开发:码云企业版 - 码云 - 开源中国