GitHub开源协议

开源协议(有名开源许可证)很多,经过Open Source Initiative组织(OSI批准)通过批准的开源协议目前有58种,常见的开源许可证包括:MIT(MIT License),GPL(GNU General Public License v3.0),Apache-2.0(Apache Licence 2.0),BSD

  • 开源许可证即授权条款。开源软件并非完全没有限制。最基本的限制,就是开源软件强迫任何使用和修改该软件的人承认发起人的著作权和所有参与人的贡献。任何人拥有可以自由复制、修改、使用这些源代码的权利,不得设置针对任何人或团体领域的限制;不得限制开源软件的商业使用等。而许可证就是这样一个保证这些限制的法律文件

MIT(MIT

MIT是和BSD一样宽范的许可协议,作者只想保留版权,而无任何其他了限制.也就是说,你必须在你的发行版里包含原许可协议的声明,无论你是以二进制发布的还是以源代码发布的.

GPL(GNU General Public License

Linux就是采用了GPL,GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代 码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux,包括商业公司的linux和linux上各种各样的由个人,组织,以及商 业软件公司开发的免费软件了。GPL协议的主要内容是只要在一个软件中使用(”使用”指类库引用,修改后的代码或者衍生代码)GPL 协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题,还可以享受免费的优势。由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议,对于使用GPL协议的开源代码,商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。

BSD开源协议(original BSD licenseFreeBSD licenseOriginal BSD license

BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用,修改源代码,也可以将修改后的代码作为开源或者专有软件再发布。

但”为所欲为”的前提当你发布使用了BSD协议的代码,或则以BSD协议代码为基础做二次开发自己的产品时,需要满足三个条件:

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

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


Apache Licence 2.0(Apache License, Version 2.0Apache License, Version 1.1Apache License, Version 1.0

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

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

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


下方表格中出现的用词的解释:

  • 协议和版权信息(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

  • 商用
  • 分发
  • 修改
  • 私用
  • 责任承担


猜你喜欢

转载自blog.csdn.net/chinafire525/article/details/80656455
今日推荐