开源软件许可证类型完整指南 2020

admin 2022年4月2日08:35:49评论1,054 views字数 13410阅读44分42秒阅读模式

译者注:

这篇文章的原文是WhiteSource的“The complete guide for open source licenses

2020”。对于开源许可证的概念和内容,我以前也不懂,看了这篇文章后,才大致明白了一些,希望能对大家有所帮助。

copyleft以前都翻译成通用公共许可证,可能是指初期,和GNU GPLgeneral public license)直接相关,所以就称之为通用公共许可证。但最新的一些文章中,开始翻译成著佐权。本文主要是从软件安全的角度来介绍几种许可证,觉得著佐权更容易记和理解,就统一翻译成著佐权了。

 

什么是开源软件许可证?

从法律的角度来看,认为软件是一种艺术,和绘画,诗歌或电影剧本类似。也就是说,即使你和整个世界分享自己的艺术,那也不意味着任何人都能随意下载并按他自己的喜好使用。相反,他们有法律义务得到拥有软件版权的作者的许可。

开源软件许可证,是一个在作者和使用者之间有法律效应和约束力的合同,声明软件可以用于某些条件下的商业应用中。软件许可证就是把软件组件变成开源组件,允许开发人员使用这个软件只要他们遵守许可证中写明的特定条款和条件。

每个开源许可证都有说明,用户被允许使用这个软件组件做什么,使用时的义务,以及根据条款和条件,他们不能做什么。这也许听起来简单,但有超过200种开源许可证,复杂性和要求都不一样,取决于每个开发人员和组织自己的选择,哪个组件和他们的策略及当前的软件最兼容,保证他们能一直遵守合规。

开源许可证类型:著佐权许可证(Copyleft)与宽松许可证(Permissive

开源许可证被分成两个主要的类型:著佐权许可证和宽松许可证。这种分法基于许可证对用户的要求和限制。

版权是在没有版权所有者允许的情况下,限制使用、修改和分享创造性作品权利的法律。当一个作者在著佐权许可证下发布了一个程序,他或她对作品的版权做了一个声明,其他人只要遵守义务对等原则,有权使用、修改、共享这个作品。简而言之,如果他们正在使用这类开源许可证下的组件,那么他们也必须使他们的代码对其他人开放使用。

开源软件宽松许可协议,是一个非著佐权许可证,保证使用、修改和再发布的自由,允许专有的衍生作品。宽松许可证,被亲切地称之为没有任何限制,对于其他人如何使用开源组件,加以最小的限制。意味着这种类型的许可证允许很大程度的自由,去使用、修改和再发布开源代码,允许在专有的衍生作品中使用,在未来的义务方面几乎不要求任何回报。

需要注意的是,没有好的或坏的许可证,也没有哪个许可证优于另外一个,任何人都能够生成一个符合他们自己意愿的开源许可证,这也是有如此之多许可证的原因。

开源软件许可证类型完整指南 2020

这使选择开源许可证成了一件复杂的事情,特别对我们这些不了解相关法律的人,为了帮助缩小决策范围,弄懂这些知识,OSI Open Source Initiative)把最适合商业使用的所有许可证放到一个名单里面,名单包括80多个最常见的开源许可证。

2019年,排名前十的开源许可证

我们的研究团队搜集了WhiteSource数据库中的信息,包括超过四百万个开源包,1.3亿个开源文件,涵盖200种编程语言。把2019年和前些年做对比,分析哪些是最常用的许可证。结果表明宽松许可协议的使用持续增加,而著佐权许可证,特别是GPL家族,持续下降

开源软件许可证类型完整指南 2020

2019年开源许可证占比情况

宽松许可证持续增长,成为趋势

2018年来的趋势看,宽松许可证下的开源软件还在持续增长。MITApache 2.0 许可证再一次占据了我们前十名最受欢迎许可证名单的前两位,和去年相比,占有率都上升了一个百分点。

宽松开源许可证对其他人如何使用开源组件,加以最小的限制。这种类型的许可证允许很大的自由度,去使用、修改、再发布开源组件,允许在专有的衍生作品中使用,几乎不要求任何回报。

根据这一年的数据,67%的开源组件使用宽松许可证。由去年的64%增加了三个百分点。前十名最受欢迎的开源许可证中,33%是著佐权许可协议,而去年占36%2012年是59%。数据显示,开发人员和组织继续青睐宽松许可证。

开源软件许可证类型完整指南 2020

        这可以从持续提高的开源软件使用率来解释。开源软件已经变成主流,开源社区也被商业软件社区拥抱和支持。随着像微软和谷歌这样的公司变成主要开源项目的支持者,开源领域早期,占统治地位的我们他们的心态已经远去,由于这种普遍合作兴趣的提高,鼓励开源软件的使用,宽松许可证赢得了比赛。

作为回报,用户也在选择具有更少附加限制许可证的组件,看起来宽松许可证开源组件给他们提供了一个简单的方案,帮助法律部门最小化开源许可证合规带来的挑战。

MIT 开源许可证:仍居首位

MIT许可证保持常用许可证名单首位的位置,为27%。这毫不奇怪,自从2015年以来,在GitHub上就是这个趋势。Ben Balter,律师,开源开发者,也是GitHub高级产品经理,解释说之所以开发人员选择MIT,是因为它简单精要,告诉下游用户,他们不能做什么,它包括一个版权(作者)声明,拒绝承担隐性的担保(买方要注意),这是一个为开发人员优化的许可证,你不需要一个法律学位来理解它,应用很简单 

开源软件许可证类型完整指南 2020

        根据GitHubchoosealicense.com网站,MIT许可证让人们用自己的代码,做任何想做的事,只要他们把归属权还给您,不要求你付责任。两年之前,Facebook 非常公开地使用MIT许可证协议替换了有争议的React 许可证。

        其他常见的使用MIT许可证的开源项目是Angular.jsRails.NET Core

Apache 2.0 许可证,继续占据主导地位

两年之前,当我们汇总2017年的数据时,宽松许可证Apache 2.0取代了著佐权许可协议的GPL 3.0,一跃成为前十最常用开源许可证名单第二名。今年,继续保持上升态势,提高了一个百分点,以23%占据第二名位置。

根据GitHubchoosealicense.com网站,Apache 2.0的主要条件要求保留版权和许可证声明,明确提供授予专利权,允许修改有许可证的作品,更大的作品可以根据不同的条款,无需源代码的情况下,再次发布。Apache 是好多受欢迎的开源项目使用的许可证,包括K8sSwiftPDF.js

开源软件许可证类型完整指南 2020

著佐权许可证缓慢下降

GPLv3GPLv2在今年都再次受到打击,GPLv3仍然是第三的位置,和2018年的16%相比,实际占比降低了3个百分点,为13%GPLv2保持在第四的位置,和2018年一样,占比为10%

今年,GPLv3GPLv2,及GPLv2.1,都位于前十名的位置,总共占有28%。整个GNU GPL家族的受欢迎度都有明显下降。我们预计在将来,这种趋势会持续下去。

开源软件许可证类型完整指南 2020

GPL是开源软件革命初期的开拓者,是著佐权许可证或病毒许可证(指许可方式像病毒)的主要例子。当用户使用GPL许可证下的组件时,他们必须发布源代码,以及修改和发行整个代码的权利。不仅如此,他们还要求,也必须使用同一个GPL许可证来发布新的代码。

回到采用开源软件的早期,GPL许可证就给考虑采用开源软件或加入开源社区的企业,出了一个大难题,许多公司尝试选择双许可证的方法,来消除GPL许可证和商业需求之间的鸿沟。

自从那之后,开源代码数量快速增加,数据表明GNU GPL被很多逐渐占据开源社区中心位置的商业实体所抛弃。随着开源软件许可证的大量增加,用户正在选择更宽松许可协议,有更少的要求和限制。

2020年的开源许可证:未来会怎样?

虽然他们没有入选我们2019年开源许可证的前十名,甚至前20名的名单,但在过去的这一年,我们在社区持续听到关于开源许可证方法的讨论。Mongo DBRedis等领先开源项目在许可证上的改变,提醒我们,随着开源软件使用的增加,组织正在摸索拥抱开源社区的同时更新他们的商业模式,以保持领先。

正如Michael DeHaan,大受欢迎的Ansible创始人,所指出的那样,开源开发者和开源使用者也许要求一个新的开源许可证方案,保证社区能够持续进化。

从去年看到的关于开源许可证的头条消息,还有根据我们的研究,有一件事可以确定,开发者和商业组织都在选择能够使他们开发的产品在开源生态系统中茁壮成长的开源组件。社区正在尽最大的努力来保证开源能够很容易使用和遵循,这取决于组织能否坚持自己的目标,确保他们了解正在使用的那些开源许可证,符合他们的要求。

头部开源许可证介绍

MIT 许可证

(这篇文章没有介绍MIT 许可证,可能是因为它太简单了吧。从百度上找了资料补充一下)

MIT许可证之名源自麻省理工学院Massachusetts Institute of Technology, MIT),又称“X条款X License)或“X11条款X11 License)。

MIT内容与条款3伯克利许可证3-clause BSD license)内容颇为近似,但是赋予软件被授权人更大的权利与更少的限制。

被授权人权利

被授权人有权利使用、复制、修改、合并、出版发行、再授权及出售软件及软件的副本。

被授权人可根据程序的需要修改授权条款为适当的内容。

被授权人义务

在软件和软件的所有副本中都必须包含版权声明和许可声明。

其他重要特性

MIT的内容可依照程序著作权者的需求更改内容。此亦为MITBSDThe BSD license, 3-clause BSD license)本质上不同处。

MIT条款可与其他授权条款并存。另外,MIT条款也是自由软件基金会FSF)所认可的自由软件授权条款,与GPL兼容。


GNU 通用公共许可证General Public LicenseGPL

       GNU GPL曾经是最受欢迎的开源许可证。Richard Stallman 创建了这个许可证,防止GNU软件被私有化,这是他提出“著佐权许可证”概念的具体实现。

        既然GPL是一个著佐权许可证,任何基于GPL组件编写的代码必须作为开源软件发布。结果是任何使用GPL开源组件的项目(不管在代码中所占的比例),被要求发布整个源代码,以及修改和发行整个源代码的权利。

      下边是关于GPL 最常见问题的回答:

1. GPL 条款和条件是什么?

      当你在软件中使用GPL 组件时,你的整个软件都被认定是一个基于GPL许可证的作品,因此,你无法拥有对于软件的专利和版权。不仅如此,你有义务发布一个版权声明,免责声明,完整的GPL声明,GPL副本。

       不允许你更改许可证,或引入其他条款和条件,你有互惠义务,意味着你有义务发布源代码,及所有修改和发行整个代码的权利。

2. GPL是强制执行的吗?

        GPL是强制执行的,因为它本质上是一个版权许可证。GPL软件的版权所有者能够在软件发行作品或衍生作品时,选择实施GPL。例如,FSFFSF,自由软件基金会,给GNU提供资金支持)拥有GNU系统许多部分的版权,如GNU Complier Collection,作为版权所有者,如果发生软件版权侵权,它可以强制执行GPL 版权要求。

3. GPLv2GPLv3之间的区别是什么?

        关于基于一个作品,构建了另一个作品’”的概念,常常有些混乱,这样触发了GPL互惠义务。FSF试图在GPLv3中增加更多条款,关于何时触发互惠义务。FSF甚至写了一个新的GPL 许可证,叫Affero 许可,解决一个被称之为“ASP 漏洞” 的特定混淆。

       FSF也想改善GPLv3和其他许可证的兼容性。把两个代码结合成一个更大的作品,两个程序都要允许才行。如果这样的权利能够得到两个程序许可证的同意,他们就是兼容的。通过使GPLv3更加兼容,FSF扩展了开发选项。

       两个版本间的第三个区别,是GPLv3用来尝试提高全球使用率。在GPLv3中,用来描述许可证权利的语言进行了修改,保证国际法会把它解释为这是FSF的意图,不像在GPLv2中使用的语言,认为是以美国为中心的。GPLv3也允许开发者增加本地免责声明,帮助提高在美国之外的使用。

4. 你能把其他许可证和GPL混合使用吗?

        人们常常认为,GPL许可证下的代码无法和其他许可证下的代码混用。虽然存在限制,但事实上在GPLv2GPLv3中都是可能的。GPLv3使用的新语言,更清楚地证明了这一点。FSF已经明确说明,GPLv3Apache2.0 协议兼容。但是,初版BSD许可证仍有一个问题,它强加了一个GPL中没有的特别要求(程序广告的要求)。

 

  类路径例外(Classpath ExceptionGNU GPL许可证

        在某些情况,作者能够选择在类路径例外GNU GPL下发布代码。本章是关于类路径例外GNU GPL最常见问题的答案:        

1. 什么是GNU 类路径例外

        GNU GPL要求每个基于这个程序的作品,也就是每个最初程序的衍生品,或任何人引入的修改,都服从GPL,也就是说,如果你和GPL模块结合使用,它可能覆盖你最初的代码。

         类路径例外允许独立的模块链接一个GPL库,但这个模块并不是这个库的衍生品也并不基于库,生成的程序不受制于GPL。独立的模块可以是你自己的专有程序。因此,类路径例外功能允许以某种方式使用GPL许可协议下的组件,而不会危及自己知识产权的完整性。

        此外,只要符合你正在使用的模块所归属的许可证的条款和条件,生成的可执行文件能够根据你选择的许可证,复制和再发行。

       实际上,类路径例外保护你不必基于GNU许可证发布项目,如果你使用了类路径例外库链接了GPL,你可以不用必须公开你的整个源代码。

1. 我该如何链接一个GPL 类路径例外库到我的软件中

        你能够链接静态或者动态链接库,GNU GPL类路径例外允许这两种方法

2. 我必须向下游扩展类路径例外吗?

        如果你按原样使用GPL库,那你必须。但如果你使用类路径例外库修改了GPL,你可以选择是否把例外扩展你修改的库。这不是强制的。如果你不想扩展这个例外,你不用在修改的库中包含这个例外声明。

3. 谁可以应用这个类路径例外到一个库中

       只有版权所有者,常常是库的开发者,能够选择使用类路径例外GPL发布他或她的程序。

4. GNU GPL和类路径例外GPL区别是什么?

       GPLv3GPLv2的主要修订版。它引入了许可证术语的变更,详细地讨论了专利权,解决了和其他开源许可证之间的兼容性问题,不仅如此,和GPLv2一样,根据GPL条款和条件,任何GPL衍生作品都属于GPL,常常叫作GPL“互惠的本质。

类路径意外GNU GPLGNU GPL的一个特例,允许开发者链接GPL类路径例外库到不同的程序,不管他们是什么许可证,而不需要将衍生的结果受制于GPL的条款和条件。

 

  Apache 许可证

        Apache 许可证,是一个由Apache 软件基金会(ASFApache Software Foundation)发布的开源软件许可证。广受欢迎,有着强大的社区。Apache 许可证允许你自由地使用、修改、发行任何Apache 许可证产品。然而,你也需要遵循Apache许可证的条款。

       下边是关于Apache许可证最常见问题的答案:

1.  Apache许可证的条款和条件

        Apache 许可证是一个宽松开源软件许可证,因此你能够发布你修改过的Apache许可证下产品,并在任何你喜欢的许可证协议来发布他们。你可以自由地使用、修改、发行和销售在这个许可证下的产品,而不用担心使用场景:个人、组织内部、或商业用途。

        这个许可证明确授予用户可以用于版权和专利的权利,不像其他宽松许可证,只适用版权,不适用专利。所赋予的权利是永久性的、全球性的,不可撤回的,但也不是排他的。因此你可以使用在这种许可证下的作品,任何其他人都可以。如果你再发行了Apache许可证组件的软件,你必须包含许可声明的副本,提供一份清晰的Apache 许可证属性,对所有你修改的文件,增加修改声明。

        你能选择在不同的许可证下发布修改过的或衍生产品,但软件未修改部分,必须保留Apache许可证,你不能以任何方式命名你修改过的版本,表明最后的产品是由ASF生成或者认可的。

        此外,针对所有的Apache许可证下软件的修改,如果你想增加版权声明,也没有任何约束。既然Apache许可证不要求你在同一许可证下,发布被修改过的代码,你能够选择增加特定的许可证条款和条件,规范其他人如何使用、复制你修改过的代码。

2. 不同版本之间的区别

        Apache Group(后来命名为Apache软件基金会),在1995年发布了第一个许可证版本,但你很少遇到仍然有这个许可证的组件了。

        2000年,当伯克利接受了自由软件基金对其的建议,撤销了他们BSD许可证中的广告条款,形成了修改版的BSD许可证时,Apache也跟着照搬,并生成了Apache许可证1.1

       删除广告条款意味着任何Apache许可证产品的衍生作品的广告资料,不用再包括Apache许可证属性,只在文档中包含属性就可以了。

       2004年,Apache 软件基金决定更彻底地脱离伯克利模式,生成了Apache 许可证2.0版,授予专利权和定义更坚实的概念,看起来更加一致。

3. Apache 许可证2.0GNU GPL之间的区别

       GNU GPL是一个著佐权许可证。因此,使用GPL许可证组件的软件,必须发布其源代码,和所有修改及发行整个源代码的权利。Apache 许可证2.0 不强制这样的条款,不强制你发布修改过的版本。此外,你能选择使用不同的许可证发布你修改过的版本(然而,对未被修改过的代码,要求你保留Apache 许可证)。

        GPL中不包含特定的要求(这个要求指对程序做广告)。

4. Apache 许可证和GNU GPL许可证兼容吗?

       Apache许可证2.0GNU GPLv3兼容,因此你能够自由的混合在这两个许可证下的代码。然而最后生成的软件,必须使用GPLv3的许可证发布。

       但Apache许可证2.0GNU GPLv2并不兼容,存在如下限制,如果许可证起诉专利侵权,则终止授予专利权。

        以前的Apache版本很大程度上基于伯克利许可证,而且互相兼容。

5. 在Apache2.0和伯克利之间的区别

       伯克利许可证是另一个高度宽松许可证,允许你修改和按照自己的意愿选择许可证,并再发行伯克利许可证下软件。早期Apache许可证和初版伯克利(后来修改版)许可证一样,但Apache2.0把二者区分开。这两者之间关键的区别:

  • 明确授予专利权:Apache许可证2.0明确规定,当使用、修改或发行Apache许可证下的软件时,授予专利权;它也列出了撤销授予的情况。

  • 清晰定义使用概念:Apache 2.0 清晰定义它所使用的所有的条款和概念,几乎不会引起歧义。

  • 重复使用,不用改写:Apache2.0能很容易的被其他项目使用,无需对许可证文档本身做任何改写。



 微软公共许可证(Microso Public LicenseMs-PL

这是微软开发的自由和开源软件许可证,为它自己发布的开源软件项目所写。

下边是关于Ms-PL最常见问题的答案:

1. 微软公共许可证的条款和条件

        你可以自由复制和发布任何基于Ms-PL原始或者衍生作品。然而当你这样做的时候,你不能使用任何贡献者的名字、标识、或商标。当使用代码时,Ms-PL明确表示不提供任何保证或后期支持,以此来保护作者,因此在某些情况下,如果代码有问题,作者不承担任何责任。

        当你发行Ms-PL软件(或者部分软件)时,你不需要一定要发布源代码,当然你愿意也可以这么做,但你没有义务。但要求你保留软件中所有最初存在的版权、专利、商标和归属声明。此外,如果你以源代码的形式发布软件任何部分,你只能在Ms-PL下这么做,发行时包含许可证的完整副本。如果你以编译后的、或目标代码形式发布任何软件片段,你只能在和Ms-PL兼容的任何其他许可证下来这么做。

        很重要的一点是,Ms-PL条款和条件非常简短,简洁并以非常清晰的语言写成。微软想对开源社区表达得清晰和直接,有助于提高其使用率。(和伯克利许可证类似)

2. Ms-PL是否被认为是著佐权许可证?

        一个著佐权许可协议提供发行程序修改后的和衍生版本的权利,Ms-PL许可证下,对下游的接受者提供同样的权利和自由,修改和发行软件,但只能在Ms-PL下,才能发行源代码中自己的部分。当你以编译过的或目标代码的形式,发行了Ms-PL许可证下的软件,Ms-PL许可证允许这样做,但仅限于和Ms-PL兼容的许可证下。因此,当选择发行Ms-PL许可证下修改或衍生的源代码版本时,Ms-PL受著佐权许可协议影响的效果就很清晰,

       当在Ms-PL许可证下,发行修改或衍生的编译代码或目标代码版本时,同样的权利和自由不需要传递给下游的接受者,即使Ms-PL文本在这一点上并不是很清晰。Ms-PL的管理员,微软支持这种解释,并坚持一个人可以根据自己选择的条款来发行编译代码或目标代码,不应该给下游Ms-PL许可证软件授予更多权力(但可以同意较少权力),而是应该给接受者授予更多权力。

3. 微软公共许可证(Ms-PL)和微软互惠许可证(Microsoft Reciprocal LicenseLMs-RL)之间的区别

        微软互惠许可证是一种著佐权许可证,比Ms-PL更具有限制性。允许你修改和发行任何微软互惠许可证的组件,只要被修改的源文件使用微软互惠许可证。然而,你能够对软件的其他文件选择许可证,完全是你自己的工作,你可以选择任何其他的兼容许可证。

4. 微软公共许可证(Ms-PL)和GNU GPL兼容吗?

       不兼容。主要的区别是GNU GPLMs-PL更加具有限制性。例如GPL发行源代码的要求和Ms-PL的条款不一致,Ms-PL可以编译程序,不需要发行源代码。即使Ms-RL也是一个著佐权许可证,但也和GPL不兼容。

       据信,微软有意打造它的开源许可证和GPL不兼容,像许多其他的商业公司,它不喜欢这样的一个事实:如果你在这个许可证下提交一个代码,你的代码被其他人带入专有软件的黑洞中。

5. 你如何在商业项目中使用一个微软公共许可证

        BSD许可证是另一个高度宽松许可证,允许根据自己的喜好,修改和发行BSD许可证下的软件。早期Apache许可证和BSD最初的版本内容一致,但Apache 2.0 后两者就分开了,两者之间的关键区别可见下章。


伯克利软件发行(BSD

       伯克利许可证家族,也就是初版伯克利许可证和它的两个变体—修改版伯克利许可证(条款3,3-clause),简化版伯克利许可证/免费版伯克利许可证(条款2,2-clause),都属于宽松的自由软件许可证。

        下面是关于伯克利许可证常见问题的答案:

1. 伯克利许可证的条款和条件

        伯克利许可证让你以源代码或者二进制格式,自由地修改和发行软件代码,只要你保留版权公告,条件列表,免责声明的副本。

       伯克利许可证家族,也就是初版伯克利许可证和它的两个变体—修改版伯克利许可证(条款3,3-clause),简化版伯克利许可证/免费版伯克利许可证(条款2,2-clause),都属于宽松的自由软件许可证。

        初版伯克利许可证,或者称之为条款44-clause)伯克利许可证,还含有一个广告条款和不背书条款,(对这些条款的详细解释见下文)。修改版伯克利许可证或条款33-clause)伯克利许可证来自于初版伯克利许可证,但删除了广告条款。然后,免费版或条款22-clause)伯克利许可证又从条款33-clause)伯克利许可证中删除了不背书条款。

        而且,只要你符合你正在使用的模块的条款和条件,可以根据你自己的选择的许可证,复制和再发行生成的可执行文件。

        基本上,类路径例外保护你,不用在GNU 许可证下必须发布项目,如果你链接了GPL类路径例外库,保护你不必公开发布你的整个源代码。

2. 初版条款4伯克利许可证和修改版条款3伯克利许可证之间的区别

        初版伯克利许可证的广告条款,要求用户在所有广告资料中提到的功能或使用软件时,感谢所使用的伯克利许可证组件的原始作者。这个条款因为几个原因受到批评,也导致初版伯克利版本不兼容GNU GPL

       基本上,伯克利许可证的作者希望开发者在他们的版权声明中加入感谢。然而,由于对许可证的误解(甚至在某些情景下,处于恶意),开发者开始加入他们自己或组织名称,替换感谢声明。这导致开发者被要求列出太多的属性,在软件中使用的每个伯克利许可证组件都要照顾到。收到反馈之后,1999年,初版伯克利许可证中的广告条款被删除,从而创建了修改版的条款3伯克利许可证。

3. 修改版条款3伯克利许可证和简化版条款2伯克利许可证之间的区别?

        简化版条款2伯克利许可证进一步调整了条款3伯克利许可证,删除了非背书条款,这个条款保证用户不能使他们的软件听起来好像得到了任何开发者和组织的认可。

        也引入了一个免责声明,作者在软件中所表达的观点和看法并不是简化版伯克利许可证的观点和看法。

4. 伯克利许可证和GPL兼容吗?

        如同前面提到的,初版BSD许可证广告条款导致它和GNU GPL不兼容,条款3和条款2伯克利许可证变体和GPL兼容。

5. 修改版伯克利许可证和MIT许可证之间的区别?

        MIT是最宽松的自由软件许可证之一。基本上,在MIT 许可证下,你能对软件做想做的任何事只要你增加一个初版MIT许可证的副本和版权声明。它的简洁性也正是它在开发者中间高使用率的原因。

        如果你使用MIT许可证,你可以按原样使用。但如果你使用任何一个BSD许可证,你仍然需要修改许可证副本以适合手边的项目。此外,修改版伯克利许可证,由于它的非背书条款,可以保护你使你免于牵扯到项目中,除非你想这样。

 

  通用开发和发行许可证(CDDL

       通用开发和发行许可证,由Sun 公司发布的许可证,代替Sun公共许可证(SPL)。CDDL被认为是Sun 公共许可证的第二个版本,来自于Mozilla 公共许可证(MPL)。

       在2004年转向依赖CDDL之前,Sun公司习惯在Sun公共许可证下发布它的自由软件和开源项目。CDDL常常被认为是MPL的一个干净版本,用来推进可重用性。

       下面是关于CDDL的常见问题:

1. 通用开发和发行许可证(CDDL)的条件和条款

        在CDDL许可证下,你可以自由地复制和发行任何软件初始或衍生作品,但是你不能删除或更改软件中版权、专利或商标声明。你也必须保留任何许可证声明,以及对最初开发人员和作出贡献者所做的描述性文本。

        当你以可执行文件的形式(源代码以外的任何形式)发行你的软件,你需要在CDDL许可证下提供源代码,可执行文件格式可以在CDDL或其他CDDL兼容许可证下发布。

        对包含初版软件的文件,或者是包含部分最初程序的新文件,你所做地增加、删除、或修改,都属于你所提供的源代码中你的贡献。那意味着如果你在独立的文件中增加内容,不包括最初的代码,你就不需要在CDDL下发布,你也可以选择在CDDL下发布,但不是你的义务。

       此外,在你发行的源代码中,必须包含CDDL副本,对自己所做的每一个修改,必须标出你自己是修改者,并在修改文件中声明。

2. CDDL是著佐权许可证吗?

        CDDL被认为是一个弱的著佐权许可证。一个著佐权许可证,如GNU GPLMPL,或者Eclipse许可证,要求你给下游的用户和你接受这个程序时同样的权利。为实现这个目的,要求你在同样的许可证下,发行这个程序包括任何修改和扩展的版本。这意味着在你的代码中使用一个著佐权许可证组件,将要求你作为开源软件来发布整个程序。本质上,这意味着在最初软件所属的许可证下,发布最初版本或修改过的软件。

       CDDL,仅仅要求你发布你使用或修改的、CDDL许可证下的组件的源代码,如果你以可执行格式发行你的软件,你必须包含源代码,但这个可执行文件可在CDDL或其他CDDL兼容许可证下发布。

3. CDDL是否授予专利权?

       是的,它授予专利权。任何贡献者授予你使用他对之有贡献的专利的权利。CDDL在专利上有一个很清楚的立场,你能够使用、修改、和再发行CDDL许可证下的组件,不需要担心任何专利问题,不用担心代码贡献者也许会抓住在专利中所贡献的技术不放。如果任何人对他们有贡献的代码宣称专利权,CDDL会终止其使用权,来阻拦对开发者的专利诉讼。

4. CDDL1.0CDDL 1.1之间的差别

       CDDL 1.12005年一月早期,初稿一年之后提交的,包括了一些修正,阻止CDDL和欧洲版权法冲突,允许单个开发者在他们工作中使用CDDL

5. CDDLGNU GPL之间的区别,他们是否兼容?

        GNU GPL 要求你关联最初软件衍生出来的程序。那意味着你必须提供源代码。这被认为是一个强互惠许可。CDDL采用了一个更温和的方法。如我们看见,如果你增加的部分是独立的文件,不包括任何最初的程序,那么这些文件就不属于CDDL,意味着你不用必须发布这些文件的源代码。

       此外,在更改许可证条款和条件方面,GPL 采取一个强硬的立场,虽然GPL 3许可证下,允许某些附加条款,一般的规则是不能引入其他变更。CDDL仅仅要求提交软件源代码版本。可执行文件版本能够在你选择的任何其他许可证下发行,只要和CDDL条款兼容,可执行文件的许可证不会在程序的源代码形式上,尝试限制或改变接受者的权利。

        由于这些差异,CDDLGNU GPL 并不兼容。

 

 Eclipse 公共许可证

        Eclipse公共许可证(EPL)是一个由Eclipse 基金会开发的开源软件许可证(应用于名下的集成开发环境Eclipse上),它来自于通用公共许可证(Common Public License CPL),在其基础上删除了专利相关诉讼的限制条款。Eclipse代码库现在EPL下可用,以前使用CPL许可证。

        下面是关于EPL的一些问题和答案:

1. Eclipse 公共许可证的条款和条件

       Eclipse 公共许可证是一个著佐权许可证,如果你修改了EPL许可证下的组件,并作为你程序的一部分以源代码的形式发行,你必须在EPL许可证下披露你修改后的代码。如果你以目标代码的形式发行这个程序,你要声明,根据接受者的要求,能够提供源代码。也能够根据要求共享请求源代码的方法。

        Eclipse 基金会明确说明,根据他们的观点,与一个Eclipse 插件仅仅接口或互操作,并不会把你的代码作为此插件的衍生作品。

        如果你重新发行了一个包含EPL组件的程序,你有义务包含完整许可证文本和版权。

       保护作者,如果一个公司在商业产品中使用他们的组件,EPL免受他们可能引起的法律诉讼或损害。也提供专利授权。

2. EPL 是一个著佐权许可证吗?

        是的,EPL被认为是一个弱著佐权许可证。

        弱著佐权许可证要求你以源代码形式公开源代码,而不是二进制文件形式,因此你可以与其他人合作编译被隐藏的源代码,再根据自己选择的许可证发行生成的(合并后的)二进制文件。如果是强的著佐权许可证,如GPL家族,再发行不管是衍生作品、还是最初副本的二进制或者源代码,你有义务使用同一个许可证。

3. Eclipse 公共许可证和IBM 通用公共许可证(CPL)之间的区别

        EPL修改了CPL,删除了在初版CPL 第七部分的第一个句子,认为其过于宽泛,对Eclipse生态系统的成长没有帮助。删掉的内容解释了CPL如何处理专利报复。

4. Eclipse 公共许可证和GNU GPL之间的区别

        GNU GPL许可证家族有一个强大的著佐权许可证条款,要求用户发布软件的全部源代码,和GPL许可证下的代码所占百分比无关。而另一方面,EPL,不要求你开源整个代码,只要求在以目标代码形式发布时,包含所有修改过的EPL许可证下的组件,根据需求来提供源代码。

5. Eclipse 公共许可证和GNU GPL兼容吗?

        EPLGNU GPL不兼容。GPL要求用户发布整个软件,发布者不能对接受者行使授予的权利加以更多的限制。然而,EPL要求任何人发行作品,对包含他们所做的修改而持有的专利,授予每一个接受者一个许可证。

       因为这是对接受者的进一步限制,这样一个组合作品的发行不符合GPL的要求。

*本文的作者并不是一个律师,请不要把本文当做任何形式的法律建议,信息在原样的基础上提供,如需法律咨询,请联系您的法律顾问。

(本想做个表,列出每种许可证之间的区别,在网上发现这个图解释的很清楚,就直接用了)

 

开源软件许可证类型完整指南 2020

 



原文始发于微信公众号(安全行者老霍):开源软件许可证类型完整指南 2020

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年4月2日08:35:49
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   开源软件许可证类型完整指南 2020http://cn-sec.com/archives/568810.html

发表评论

匿名网友 填写信息