软件开发中的开源协议详解!

简介: 软件开发中的开源协议详解!

开源不等于免费!为了加速我们的开发,我们会使用开源的软件和源码; 为避免商业风险,需要在使用时了解第三方如软件协议,版本,和已知CVE风险等;本文旨在从开源软件再发布过程使用权限的角度入手,总结各个常见开源协议的异同,方便理解。


大部分人都希望作品能够被多数人分享查阅。这样不仅提高自己业界的知名度,同时也方便了需要的人为开源做出了贡献。但是代码一旦被贴出来,任何人都可以看到并获取,之后发生的事情你就无法控制了。


所以为了公开分享你的代码,同时又让你对代码保留一定权利,在作品中声明一个许可协议是非常有必要的。有协议和没声明协议的裸代码是有非常重要区别的,一般作品当中没声明协议的默认为Copy right的,也就是版权保留。此种情况表明他人没有任何授权,不得复制分发修改使用等等。有了协议的声明,在未来你的维权上面会方便很多,让你的作品在分享的同时保留了自身的一些权利。


License是软件的授权许可,里面详尽表述了你获得代码后拥有的权利,可以对别人的作品进行何种操作,何种操作又是被禁止的。


软件协议可分为开源和商业


对于商业协议,或者叫法律声明、许可协议,每个软件会有自己的一套行文,由软件作者或专门律师撰写。因为涉及到以后侵权打官司这种事情,这种商业条款的行文是非常严谨而讲究的,读起来很晦涩难懂。


对于开源协议,要知道开源不等于免费,也不等于没有约束。虽然相对商业协议要更加简明,但对于很多人来说还是像在看天书一样。


协议列表


首先一共有哪些公开的协议: https://opensource.org/licenses/alphabetical


常用协议


最流行的六种----GPL、BSD、MIT、Mozilla、Apache和LGPL。


乌克兰程序员Paul Bagwell,画了一张分析图,说明应该怎么选择,只用两分钟,你就能搞清楚这六种许可证之间的最大区别。 下面是阮一峰中文翻译版本:image.png1. Apache 许可协议


Apache许可证(Apache License),是一个在Apache软件基金会发布的自由软件许可证,最初为Apache http服务器而撰写。Apache许可证要求被授权者保留版权和放弃权利的申明,但它不是一个反版权的许可证。


此许可证最新版本为“版本2”,于2004年1月发布。 Apache许可证在Apache社区内外被广泛使用。Apache基金会下属所有项目都使用Apache许可证,许多非Apache基金会项目也使用了Apache许可证:据统计,截至2008年4月,在sourceforge上有超过3000个项目使用了Apache许可证。


Apache 许可协议, 2.0 版本, 授予了用户大量的权利。这些权利可以应用于拷贝权,也可以用于专利权。因为很多许可协议只能适用于拷贝权,不适用于专利权,所以这个灵活性就成了让有专利的开发者们选择许可协议时的一个显著参考因素 (要想明白两者之间的不同,请参考 How Stuff Works 上的这篇文章 )。


下面是关于 Apache 许可协议所允许的事项的详细说明:


•   权利永恒


一旦被授权,权利永久不失。


•   权利无疆界。


在一个国家里被授权,形同于在所有国家被授权。例如,你在美国,但许可权最初在印度被授予,你同样可以使用这个被授权的程序。


•   授权无需付费和支付酬劳。


你既不需要在使用之前支付任何的费用,也无需在每次使用时支付任何的费用,或者其它类似情况。


•   权利不排他。


使用这种许可协议下的软件时,不妨碍你使用其它软件。


•   权利不可变更。


权利一旦授予,不可剥夺。也就是说,你在使用这个软件的过程中,你无需担心这种情况:当你开发出了令人羡慕的基于这种授权软件的衍生产品时,有人突然跳出来对你说,抱歉,你将不再被允许使用这个程序。


(在这个协议里有个条款声明:如果你控告别人在这个许可协议下的产品有侵犯专利的行为,那你的授权将会自动终止,但这只是适用于有专利权的作品。只要你不搞有专利作品的诉讼,你永远无需担心这种问题。)


•   对再分发的作品还有个特殊要求,总的就是说要给予这些程序的作者和许可协议的维护者适当的名誉。


2. MIT 许可协议


MIT 协议应该是在流行的开源协议中最简短的、使用最广泛的一种协议。它的条款非常的宽松,而且跟其它协议相比更自由。 MIT 协议是目前最少限制的协议。


它基本上就是任何人可以对这个协议下的软件的做任何的事情,只要你能认可这个协议。这种协议最基本的条款 ( the information that it is provided without warranty, which comprises the final paragraph)如下:


特此授权,任何人都可免费获得这个软件以及相关文档(the Software)的拷贝,可以无限制的使用这个软件,包括无限制的权利去使用、复制、修改、合并、发布、附加从属协议,以及/或者出售软件的拷贝, 同时,为了让软件的提供者有权利做到这些,下面的条件必须遵守:


上面的拷贝权声明和许可声明必须包含在所有的这个软件拷贝里和实际分署部分里。


这也就是说:


 •   你可以随意使用,复制,修改这个软件。没有人能够阻止你在任何工程里使用它,你可以复制任意次数、以任何形式,或按你的愿望修改它。   •   你可以向外免费发放,或出售。你可以随意的分发它,没有任何限制。   •   唯一的限制是你必须接受协议条款。


3. BSD 许可协议


BSD 协议有很多分支,它们都代表了一种宽松的自由软件协议,相对其它协议,例如GPL,来说,它们对软件的传播给予了更少的限制。


在这种协议的各种版本中,有两个版本格外的重要: 新 BSD 协议/修订版 BSD 协议和简化 BSD 协议/FreeBSD 协议。这两类协议都实现的对 GPL 兼容的自由软件协议,而且被 Open Source Initiative 认可为开源软件协议。


新 BSD 协议(3-clause license)无任何限制的允许你以任何目的二次分发这种软件,唯一的要求是必须保留拷贝权的声明和协议里的软件权利放弃条款。这种协议还有一个限制,未经许可不得使用这个作品的所有曾经捐助者的署名。 新 BSD 协议和简化 BSD 协议的最主要的区别是后者删除了署名条款。


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


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


 •   如果再发布的产品中包含源代码,则在源代码中必须带有原来代码中的BSD协议。


 •   如果再发布的只是二进制类库/软件,则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。


 •   不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。


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


4. GPL许可协议


我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代 码做为闭源的商业软件发布和销售。


这也就是为什么我们能用免费的各种linux,包括商业公司的linux和linux上各种各样的由个人,组织,以及商 业软件公司开发的免费软件了。


GPL协议的主要内容是只要在一个软件中使用(”使用”指类库引用,修改后的代码或者衍生代码)GPL 协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题, 还可以享受免费的优势。


由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议,对于使用GPL协议的开源代码,商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。


其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。


5. LGPL许可协议


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


但是如果修改LGPL协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因 此LGPL协议的开源 代码很适合作为第三方类库被商业软件引用,但不适合希望以LGPL协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用。


GPL/LGPL都保障原作者的知识产权,避免有人利用开源代码复制并开发类似的产品。


6. 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条有专门的一款是关于对源代码修改进行描述的规定,就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。


小结


GPL协议、LGPL协议与BSD协议的法律区别。


简而言之,GPL协议就是一个开放源代码协议,软件的初始开发者使用了GPL协议并公开软件的源程序后,后续使用该软件源程序开发软件者亦应当根据GPL协议把自己编写的源程序进行公开。GPL协议要求的关键在于开放源程序,但并不排斥软件作者向用户收费。


虽然如此,很多大公司对GPL协议还是又爱又恨,爱的是这个协议项下的软件历经众多程序员千锤百炼的修改,已经非常成熟完善,恨的是必须开放自己后续的源程序,导致竞争对手也可以根据自己修改的源程序开发竞争产品。


正因大公司对GPL协议在商业上存在顾虑,因此,另两种协议被采用的更多,第一种是LGPL(亦称GPL V2)协议,可以翻译为更宽松的GPL协议。与GPL协议的区别为,后者如果只是对LGPL软件的程序库的程序进行调用而不是包含其源代码时,相关的源程序无需开源。


调用和包含的区别类似在互联网网网页上对他人网页内容的引用:如果把他人的内容全部或部分复制到自己的网页上,就类似包含,如果只是贴一个他人网页的网址链接而不引用内容,就类似调用。有了这个协议,很多大公司就可以把很多自己后续开发内容的源程序隐藏起来。


第二种是BSD协议(类似的还有MIT协议)。BSD协议鼓励软件的作者公开自己后续开发的源代码,但不强求。在BSD协议项下开发的软件,原始的源程序是开放源代码的,但使用者修改以后,可以自行选择发布源程序或者二进制程序(即目标程序),当然,使用者有义务把自己原来使用的源程序与BSD协议在软件对外发布时一并发布。因为比较灵活,所以BSD深受大公司的欢迎。


近期热文推荐:


1.600+ 道 Java面试题及答案整理(2021最新版)


2.终于靠开源项目弄到 IntelliJ IDEA 激活码了,真香!


3.阿里 Mock 工具正式开源,干掉市面上所有 Mock 工具!


4.Spring Cloud 2020.0.0 正式发布,全新颠覆性版本!


5.《Java开发手册(嵩山版)》最新发布,速速下载!


觉得不错,别忘了随手点赞+转发哦!


image.png

相关文章
|
前端开发 UED
探索前端开发中的无障碍设计与实践
在当今数字化时代,无障碍设计已经成为前端开发中不可忽视的重要环节。本文将介绍无障碍设计的概念和原则,并结合前端开发实践,探索如何为用户提供更加包容和友好的用户体验。
401 29
|
XML 编解码 自然语言处理
不需要熟悉,但需要了解的libiconv库
但是很多老式的计算机还在使用当地的传统的字符编码方式。而一些程序,例如邮件程序和浏览器必须能在这些不同的用户编码之间作转换。其他的一些程序则内置支持Unicode,以顺利支持国际化的处理,但是仍然有在Unicode和其他的传统编码之间转换的需求。GNU的libiconv就是为这两种应用设计的编码转换库。
不需要熟悉,但需要了解的libiconv库
|
10月前
|
前端开发 Java 测试技术
语音app系统软件源码开发搭建新手启蒙篇
在移动互联网时代,语音App已成为生活和工作的重要工具。本文为新手开发者提供语音App系统软件源码开发的启蒙指南,涵盖需求分析、技术选型、界面设计、编码实现、测试部署等关键环节。通过明确需求、选择合适的技术框架、优化用户体验、严格测试及持续维护更新,帮助开发者掌握开发流程,快速搭建功能完善的语音App。
|
11月前
|
人工智能 数据处理 C#
AI Dev Gallery:微软开源 Windows AI 模型本地运行工具包和示例库,助理开发者快速集成 AI 功能
微软推出的AI Dev Gallery,为Windows开发者提供开源AI工具包和示例库,支持本地运行AI模型,提升开发效率。
730 13
|
机器学习/深度学习 人工智能 安全
并非只有AI-2025年工作技能报告
全球最大的在线学习平台Coursera发布《2025年工作技能报告》,报告基于500万企业学习者和7,000多家机构的数据分析,揭示了2025年全球劳动力所需的关键技能趋势。报告强调,随着GenAI的快速发展,相关技能的课程注册量同比增长了866%,显示出对AI能力的需求激增。
923 9
|
人工智能 Linux Docker
一文详解几种常见本地大模型个人知识库工具部署、微调及对比选型(1)
近年来,大模型在AI领域崭露头角,成为技术创新的重要驱动力。从AlphaGo的胜利到GPT系列的推出,大模型展现出了强大的语言生成、理解和多任务处理能力,预示着智能化转型的新阶段。然而,要将大模型的潜力转化为实际生产力,需要克服理论到实践的鸿沟,实现从实验室到现实世界的落地应用。阿里云去年在云栖大会上发布了一系列基于通义大模型的创新应用,标志着大模型技术开始走向大规模商业化和产业化。这些应用展示了大模型在交通、电力、金融、政务、教育等多个行业的广阔应用前景,并揭示了构建具有行业特色的“行业大模型”这一趋势,大模型知识库概念随之诞生。
156875 30
|
存储 SQL 分布式计算
Java连接阿里云MaxCompute例
要使用Java连接阿里云MaxCompute数据库,首先需在项目中添加MaxCompute JDBC驱动依赖,推荐通过Maven管理。避免在代码中直接写入AccessKey,应使用环境变量或配置文件安全存储。示例代码展示了如何注册驱动、建立连接及执行SQL查询。建议使用RAM用户提升安全性,并根据需要配置时区和公网访问权限。具体步骤和注意事项请参考阿里云官方文档。
1026 10
|
Web App开发 数据采集 开发者
如何解决ChromeDriver 126找不到chromedriver.exe问题
当使用Selenium与ChromeDriver 126时,遇到`chromedriver.exe`找不到的错误,可能是因为版本不匹配、文件路径错误或系统设置不当。解决方法包括:匹配Chrome浏览器版本下载ChromeDriver,确保文件在正确路径且有执行权限,以及调整系统设置允许执行。示例代码展示了如何设置代理IP、user-agent和cookie来运行Selenium爬虫。通过这些步骤,可以确保爬虫程序顺利运行。
1138 2
如何解决ChromeDriver 126找不到chromedriver.exe问题
|
安全
计算机硬件升级增加内存(RAM)
【8月更文挑战第5天】
1684 3
|
存储 Prometheus 运维
Prometheus监控系统中常见技术问题处理指南
本文档是Prometheus使用指南,主要针对用户在使用过程中可能遇到的技术问题提供解决方案。
1712 2