【项目实战】SBOM ，常见的开源软件协议优缺点对比（常用的开源软件协议分类）_开源协议对比

一、背景

常见的开源软件协议有GPL、MIT、BSD、Apache等，它们各有优缺点。
选择合适的开源协议需要根据具体情况进行权衡和选择。
不同的开源软件协议适用于不同的场景和需求，需要根据具体情况进行选择和判断。
如果您希望使用开源软件，可以根据您的实际需求选择适合您的开源软件协议。

不同的开源软件协议有不同的特点和限制，应根据实际情况选择使用。
在选择开源软件时，还需要注意遵循相应的许可证条款，确保合法使用和分发。

二、GPL（GNU通用公共许可证）

你开发的项目如果使用了此协议的开源项目，那么你的这个项目也得开源。
使用了 GPL 协议的开源项目，你的源码必须开源。

比如：张三开发了推荐系统[使用 GPL 协议]，李四开发的系统用到了这个推荐系统，那李四开发的这个系统也得遵循 GPL 协议也得开源出来。如果不开源，就只能等着被告了。

GPL协议要求衍生作品也必须采用GPL协议，因此对商业软件的使用有一定限制；
GPL是一种最具代表性的开源软件协议，其核心是“强制共享”。即：如果使用GPL授权的开源软件，那么在修改和分发时，必须遵守GPL的规定，将其修改后的代码同样以GPL协议发布，使得代码的开放性和共享性得以保持。

允许用户自由地使用、修改和分发开源软件，但任何以GPL为基础的衍生作品也必须保持开源，并在发布时附带相应的GPL协议。因此，使用GPL许可的开源软件往往具有较强的“传染性”。

Linux 使用 GPL 协议。

Java 与GPL协议
在2006年11月13日的JavaOne大会上，Sun公司宣布计划要把Java开源，在随后的一年多时间内，它陆续地将JDK的各个部分在GPLv2（GNU General Public License v2）协议下公开了源码，并建立了OpenJDK组织对这些源码进行独立管理。除了极少量的产权代码（Encumbered Code，这部分代码所有权不属于Sun公司，Sun本身也无权进行开源处理）外，OpenJDK几乎拥有了当时SunJDK 7的全部代码，OpenJDK的质量主管曾经表示在JDK 7中，SunJDK和OpenJDK除了代码文件头的版权注释之外，代码几乎是完全一样的，所以OpenJDK 7与SunJDK 7本质上就是同一套代码库出来的产品。

在功能上，OpenJDK和SunJDK两者非常相似，因为OpenJDK的代码库是SunJDK的基础。然而，在许可证上存在一些区别：SunJDK使用Sun公司专有的许可证，而OpenJDK使用GNU通用公共许可证（GPL）或类似的开放源代码许可证。

三、Apache许可证

如果你的项目使用了此协议的开源项目，必须要有声明，告诉别人你用了这个开源项目。
使用了 apache 协议的开源项目，你的源码可以不开源，只要给个声明就行。

Apache License, Version 2.0 是一种松散的开源软件许可协议，允许使用者自由地使用、修改和分发软件，只要遵循一些基本条件，比如必须包含原始版权声明和许可声明等。

Apache协议则更加灵活，允许商业软件使用和修改，但需要在代码中保留原作者的许可证信息和免责声明。
Apache许可证是一种面向商业应用的开源软件协议，其核心是“宽松授权”。即：使用Apache许可证授权的开源软件，可以自由修改、分发、销售，无需公开源代码，只要在软件产品中包含了Apache许可证就可以。

Android 使用 Apache协议，因此国内各大厂商的手机系统，除了鸿蒙，其他都是安卓改的，开机时都能看到 powered by Android，这就是 apache 协议的特点。只要你用安卓，你就的显示这个商标，不带这个商标，你就得吃官司。但 apache 在源码开源这一块没有限制，不像 GPL 协议。

允许用户自由地使用、修改、分发和销售开源软件，且不对衍生作品采用相同的协议做出限制。与GPL不同，Apache许可证更加灵活，可以将开源软件用于商业目的。

四、BSD许可证

MIT和BSD协议则相对宽松，允许商业软件使用和修改，但需要在代码中保留原作者的版权声明。
BSD许可证是一种面向自由软件的开源软件协议，其核心是“自由授权”。即：使用BSD许可证授权的开源软件，可以自由修改、分发、销售，甚至可以将其代码作为商业软件的一部分，只要在软件产品中包含了BSD许可证就可以。

类似于MIT和Apache许可证，允许用户自由地使用、修改、分发和销售开源软件，并不对衍生作品采用相同的协议做出限制。BSD许可证还包括对软件作者的责任限制。

五、MIT许可证

源码想咋用就咋用，基本上没什么限制(最受欢迎的协议)。

MIT和BSD协议则相对宽松，允许商业软件使用和修改，但需要在代码中保留原作者的版权声明。
MIT许可证是一种最为宽松的开源软件协议，其核心是“无限制授权”。即：使用MIT许可证授权的开源软件，可以自由修改、分发、销售，甚至可以将其代码作为商业软件的一部分，无需公开源代码，只需在软件产品中包含了MIT许可证就可以。

允许用户自由地使用、修改、分发和销售开源软件，且不对衍生作品采用相同的协议做出限制。MIT许可证与Apache许可证类似，但条款更简洁，适用于小规模或个人项目。

react 之前使用的是 Facebook BSD + patents 协议
(协议内容：如果使用 react 的同时你和 Facebook 有专利纠纷，不管谁对谁错，Facebook 都可以禁止你使用 react)。
react 现在用的是 MIT 协议。
vue、node、element ui 使用的是 MIT 协议。

MIT 协议具体内容如下：

MIT协议（The MIT License）是一种宽容的开源协议，适用于开源软件使用、修改、发布的场合。该协议发布于 1988 年，命名起源则是因为它最初被使用在麻省理工学院（MIT）的软件项目上。

MIT 协议的主要特点如下：

可以免费使用、修改、复制、合并、发布和再授权软件；

没有担保责任，软件“按原样”提供，作者不承担责任；

许可证和版权声明必须保留，可以复制到衍生产品中，但不可以使用作者或原项目的名称做市场推广。

总之，MIT 协议为开源软件的自由性和低限制做出了重要贡献，使得开源软件得到了广泛的应用和推广。

六、LGPL（GNU Lesser General Public License）

LGPL是一种针对开放源码库的开源软件协议，其核心是“保持开放性”。即：使用LGPL授权的开源软件，如果仅仅是使用该开源软件，不需要遵守LGPL的规定；但如果对其进行修改和发布，则必须开放源代码，以保持开放性，但是可以将其代码作为商业软件的一部分。

七、EPL

Eclipse Public License 2.0（以下简称“EPL”）是一种基于业务的开放源代码许可证，是由美国开源软件基金会（OSI）批准的。

EPL允许Recipients任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。

使用EPL协议，需要遵守以下规则：

当一个Contributors将源码的整体或部分再次开源发布的时候,必须继续遵循EPL开源协议来发布,而不能改用其他协议发布.除非你得到了原"源码"Owner 的授权；
EPL协议下,你可以将源码不做任何修改来商业发布.但如果你要发布修改后的源码,或者当你再发布的是Object Code的时候,你必须声明它的Source Code是可以获取的,而且要告知获取方法；
当你需要将EPL下的源码作为一部分跟其他私有的源码混和着成为一个Project发布的时候,你可以将整个Project/Product以私人的协议发布,但要声明哪一部分代码是EPL下的,而且声明那部分代码继续遵循EPL；

八、Bouncy Castle License

参考文档

https://opensource.org/licenses/