ecmp协议,各类开源协议简介

 2023-09-23 阅读 12 评论 0

摘要:在使用开源代码时,常常要考虑这些代码能否闭源应用到公司的产品上,国内的对这方面的意识较弱,很多开源代码拿来就是用了,从不关心版权等问题,但是如果产品要发布到海外,那么对于开源代码的选择就非常重要了,应该选择那些可以

在使用开源代码时,常常要考虑这些代码能否闭源应用到公司的产品上,国内的对这方面的意识较弱,很多开源代码拿来就是用了,从不关心版权等问题,但是如果产品要发布到海外,那么对于开源代码的选择就非常重要了,应该选择那些可以闭源的开源项目,否则就是侵权。

在使用免费开源软件的时候,我们要注意这么几点:

  1. 要搞清楚对方的授权协议是什么,授权范围和未来的风险在哪里
  2. 要明确未来商业化,或者用于其它用途时,是否会带来不必要的麻烦和纠纷
  3. 要明确自己的商业模式,与相关授权是否存在可能的冲突和隐患

两个相关案例

Jacobsen VS Katzer:开源协议是一种著作权协议

2006年,Bob Jacobsen 起诉 Matt Katzer ,称后者的软件没有遵守开源协议,标明源代码的出处和作者,要求法院认定这是侵犯著作权行为。当时的旧金山联邦地区法院驳回了这个请求,认为这只是“违反契约”(a breach of the licensing agreement),而不是“侵犯著作权”(copyright infringement)。

Bob Jacobsen 不服判决,继续上诉。于2008年,在联邦上诉法院成功翻案。法官认定,即使采用放弃著作权的开源协议,依然可以发生侵犯著作权的侵权行为。(判决词、详细报道)

Artifex VS Hancom:开源协议是具备强制执行力的合同

ecmp协议。Hancom 公司自 2013 年起在其字处理软件中整合了开源 PDF 解释器 Ghostscript。Ghostscript 采用了两种许可证,GNU AGPL 以及一个付费的商业授权许可证。如果 Hancom 不想付费,那么需要开源其软件。事实是 Hanom 公司在集成 Ghostscript 到他们的产品中去的时候,没有付费也未将修改代码开源出来。

2016 年,Ghostscript 的开发者 Artifex 向加州北区法院起诉了 Hancom,指控其滥用 GPL 和侵犯了自己的版权,要求 Hancom 停止侵权和支付合理的许可费。Hancom 递交动议要求驳回诉讼,理由是它没有签署任何合同,而许可证不是合同。今年4月,法官 Jacqueline Scott Corley 拒绝了动议,裁定如果用户没有获得商业许可证,在下载软件的时候则默认同意 GPL ,GPL 是自我传播的,即使没有“签署合同”,当选择开源路线时,它就会被认定为具备强制执行力的合同。(详细报道)

如何选择开源

世界上的开源许可,大概有上百种。我们最常用到的开源协议有6种,都是OSI批准协议,也是大多数公司会用到的协议 – GPL、LGPL、BSD、Apache、Mozilla、MIT

网上有一张图总结了这六种协议(作者:阮一峰)
licenses

稍微总结下:

  1. 如果你在商业公司上班,最好不要使用GPL协议的开源软件,因为它具有“传染性”,并且强制开源,只要引入的某个模块是GPL的,它会一直扩展到最上层知道整个项目都强制GPL开源。
  2. 用BSD、Apache或者MIT的开源项目则一般不会有问题,只需要开源项目本身的安全性或者健壮性等其他需求满足公司要求即可。
  3. 另外要说明一下的是,有协议和没声明协议的裸代码是有非常重要区别的,一般作品当中没声明协议的默认为Copy right的,也就是版权保留。此种情况表明他人没有任何授权,不得复制分发修改使用等等。所以如果要开源自己的代码,最好也是选择这些著名的开源协议。

github开源协议?那么我们接下来就分别分析这些协议的说明、允许项及禁止项

GPLv3

此协议是应用最为广泛的开源协议,拥有较强的版权自由要求,也赋予和保证了开源项目开发者广泛的权利。基本上,它允许用户合法复制,分发和修改软件,但衍生代码的分发需开源并且也要遵守此协议。此协议有许多变种,不同变种的要求略有不同。

  • 要求

    • 修改后的源码也需要公开
    • 版权及协议也要于此协议一致
    • 修改后,需要在相应的文件做说明
  • 允许
    商用,分发,修改,专利授权,私用

  • 禁止
    禁止因使用等造成影响责任承担、也就是说免责申明
    静止在软件分发传播过程中附加上原来没有的协议条款等

开源协议均为什么协议?提示:商业软件不能使用GPL协议的代码,因为协议要求开源。

LGPL

其主要用于一些代码库,LGPL比起GPL它授予的权限较少,LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。因此使用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。注意是以类库的形式使用,也就是说如果修改了源代码的话则也必须使用LGPL协议贡献源码出来。

  • 要求

    • 公开使用了LGPL部分的代码,其余部分不需要公开。
    • 可以库引用的方式用于商业软件。
    • 在代码中保留作者提供的协议和版权信息
  • 允许
    商用、分发、修改、专利授权、私用、附加协议

  • 禁止
    禁止承担责任,(免责申明)

开源协议可以转换吗、提示:商业软件可以使用,但不能修改LGPL协议的代码。GPL/LGPL都保障原作者的知识产权,避免有人利用开源代码复制并开发类似的产品。采用LGPL的代码,一般情况下它本身就是一个第三方库(别忘了LGPL最早的名字就是Library GPL),这时候开发人员仅仅用到了它的功能,而没有对库本身进行任何修改,那么开发人员也不必公布自己的商业源代码。但是如果你修改了这个库的代码,那么对不起,你修改的代码必须全部开源,并且协议也是LGPL,但除了库源码之外的商业代码,仍不必公布

MIT

宽松简单且精要的一个协议。在适当标明来源及免责的情况下,它允许你对代码进行任何形式的使用,也就是原作者只想保留版权,而无任何其他了限制,而你必须在发行版里包含原许可协议的声明,无论你是以二进制发布的还是以源代码发布的。

  • 要求
    在代码中保留作者提供的协议和版权信息

  • 允许
    商用、分发、修改、私用、附加协议

  • 禁止
    禁止承担责任,(免责申明)

python开源协议,提示:商业软件可以使用,也可以修改MIT协议的代码,甚至可以出售MIT协议的代码。

BSD

BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用,修改源代码,也可以将修改后的代码作为开源或者专有软件再发布。与MIT协议只存在细微差异。差别为MIT可以使用原名称进行宣传,而BSD不可以。

  • 要求
    在代码中保留作者提供的协议和版权信息

  • 允许
    商用、分发、修改、私用、附加协议

  • 禁止
    禁止承担责任,(免责申明)

java开源协议。提示:商业软件可以使用,也可以修改使用BSD协议的代码。

Mozilla 2.0

是由Mozilla基金创建维护的。此协议旨在较为宽松的BSD协议和更加互惠的GPL协议中寻找一个折衷点,允许免费重发布、免费修改,但要求修改后的代码版权归软件的发起者。这种授权维护了商业软件的利益,它要求基于这种软件得修改无偿贡献版权给该软件。

  • 要求
    公开源代码
    在代码中保留作者提供的协议和版权信息

  • 允许
    商用、分发、修改、专利授权、私用、附加协议

  • 禁止
    禁止承担责任,(免责申明)
    禁止使用商标
    提示:商业软件可以使用,也可以修改MPL协议的代码,但修改后的代码版权归软件的发起者。

Apache License 2.0

开源代码协议、这是一个著名的非盈利开源组织Apache采用的协议,它励代码共享和尊重原作者的著作权,同时也允许代码修改,再发布(作为开源或商业软件)。

  • 要求
    在代码中保留作者提供的协议和版权信息
    如果修改了代码,则必须在被修改的文件中进行说明。

  • 允许
    商用、分发、修改、专利授权、私用、附加协议

  • 禁止
    禁止因使用等造成影响责任承担、也就是说免责申明
    不能使用相应的商标。

提示:商业软件可以使用,也可以修改使用Apache协议的代码。

参考

  • 阿里侵权事件反思 | 谈谈免费开源的知识产权话题
  • 开源许可协议了解这些就够了
  • 如何选择开源许可证?
  • 选择一个开源软件协议
  • 终于理解了什么是LGPL
  • 详细介绍 LGPL 协议

版权声明:本站所有资料均为网友推荐收集整理而来,仅供学习和研究交流使用。

原文链接:https://hbdhgg.com/3/92665.html

发表评论:

本站为非赢利网站,部分文章来源或改编自互联网及其他公众平台,主要目的在于分享信息,版权归原作者所有,内容仅供读者参考,如有侵权请联系我们删除!

Copyright © 2022 匯編語言學習筆記 Inc. 保留所有权利。

底部版权信息