科普文：开源协议【代码侵权：MIT、Apache 2.0、GNU GPL、GNU LGPL、BSD、Mozilla Public License (MPL)等】

概叙

LGPL许可证

LGPL许可证是LESSER GENERAL PUBLIC LICENSE的简写（开源协议别名LGPL许可证），也叫LIBRARY GENERAL PUBLIC LICENSE，中文译为“较宽松公共许可证”或者“函数库公共许可证”。该许可证适用于一些由自由软件基金会与其它决定使用此许可证的软件作者所特殊设计的软件包─比如函数库（即Library）。

代码侵权

开源协议是开源软件的法律框架，定义了如何使用、修改和分发开源代码。不同的开源协议有不同的条款和限制，选择合适的开源协议对项目的成功和合规性至关重要。

商业秘密侵权_浙01民终11274号-CSDN博客

换句话说，作为一个java码农，你在互联网上下载了一个jar，并在配置了你们的项目中，那么你们是否侵权？是否有法律风险？你的项目卖钱了，那么你这是否构成代码侵权？你和你的雇佣企业如何担责另外说，这里不展开。

科普文：Java基础系列之【新版JDK的Java许可NFTC：不定时的甲骨文炸弹】_oracle nftc-CSDN博客

甲骨文认为谷歌侵犯了甲骨文的版权，因为谷歌将 37 个 Java API 复制到了Android 中，而 Java 代码总共有 286 万行代码，占 0.4%。谷歌回应称，API 就像字母表或语法。它们是用来创建程序的基本元素。

现在，美国最高法院终于得出了程序员一直都知道的结论：API 不能严格享有版权，可以合理使用。

讽刺的是，在上世纪 90 年代，甲骨文和 Sun 公司都认为软件API 不应受版权保护。

此次终审判决书的主笔是 82 岁的大法官斯蒂芬·布雷耶（Stephen Breyer）。

Breyer 此前在 2020 年10 月的听证会上表示，“一开始，你不必在打字机上安装 QWERTY 键。但如果你现在让别人拥有它的版权，他们就会控制所有的打字机，这真的和版权没有任何关系。”

总的来说，需要谨慎：

如果你下载该软件，自己使用，因为是免费软件，因而不属于侵权行为；

如果你自己编写的软件，也不会存在侵权行为；

可是你利用人家的软件编写你的软件的话，则可能属于使用人家软件的行为，自己使用仍然没有问题，如果销售了的话则不属于免费使用的范围了，所以是否侵权，关键看你的软件如何使用人家免费软件的。

怎么才算代码侵权？

《计算机软件保护条例》第三十条软件的复制品持有人不知道也没有合理理由应当知道该软件是侵权复制品的，不承担赔偿责任；但是，应当停止使用、销毁该侵权复制品。如果停止使用并销毁该侵权复制品将给复制品使用人造成重大损失的，复制品使用人可以在向软件著作权人支付合理费用后继续使用。

代码侵权主要是指未经许可使用、复制、修改或分发他人的代码，侵犯了代码原创者的知识产权

。

具体来说，代码侵权可能涉及以下几个方面：

一、未经授权复制或使用代码

直接复制：如果你直接复制了他人的代码，并在自己的项目中使用，而未经过原作者的许可，这就构成了侵权。
衍生作品：如果你基于他人的代码进行了修改或扩展，但并未获得原作者的授权，同样可能构成侵权。

二、未经授权分发代码

将他人的代码作为自己项目的一部分进行分发，而未经过原作者的许可，是侵权行为。
即使是在开源项目中，也需要遵守该项目的许可证要求。如果未按照许可证规定进行分发，也可能构成侵权。

三、侵犯署名权：如果你使用了他人的代码，但未在适当的地方注明原作者或来源，可能侵犯了原作者的署名权。

四、违反开源协议：许多开源项目都有特定的许可证和协议，规定了如何使用该代码。如果你违反了这些协议，例如，将仅供个人使用的代码用于商业目的，或者在不允许的情况下修改了代码，都可能构成侵权。

在判断代码是否侵权时，需要考虑多个因素，包括代码的来源、使用方式、分发方式以及是否遵守了相关的开源协议等。如果你不确定自己的行为是否构成侵权，建议咨询专业的法律顾问。

此外，从法律依据上来看，《中华人民共和国著作权法》对著作权提供了明确的保护。根据该法第五十二条的规定，未经著作权人许可，以任何方式使用其作品（包括代码）都可能构成侵权。因此，在使用他人的代码时，务必确保已经获得了适当的授权，并遵守相关的法律和协议。

常见开源协议比较

‌常见的开源协议包括MIT协议、Apache 2.0协议、GNU GPL、GNU LGPL、BSD协议和Mozilla Public License (MPL)。

区别

‌MIT协议‌：允许自由使用、修改和分发代码，不要求衍生作品开源。风险较低，几乎没有限制‌。
‌Apache 2.0协议‌：同样允许自由使用、修改和分发代码，但要求修改后的文件必须注明修改内容，并提供专利授权。适用于涉及专利的项目，风险较低，但需注意专利条款‌。
‌GNU GPL‌：允许自由使用、修改和分发代码，但要求任何使用GPL代码的衍生作品也必须使用GPL协议。风险较高，因为衍生作品必须开源‌。
‌GNU LGPL‌：与GPL类似，但适用于库文件。修改库文件时必须公开修改内容，但衍生作品可以闭源。适用于开源库项目，风险中等‌。
‌BSD协议‌：允许自由使用、修改和分发代码，衍生作品可以闭源。风险较低，几乎没有限制‌。
‌Mozilla Public License (MPL)‌：允许自由使用、修改和分发代码，修改后的文件必须开源。风险中等，介于GPL和MIT之间‌。

风险

‌MIT协议‌：风险较低，几乎没有限制，但使用者可以闭源修改后的代码，无需公开修改内容‌。
‌Apache 2.0协议‌：风险较低，但需要注意专利条款，确保专利授权不会引发法律纠纷‌。
‌GNU GPL‌：风险较高，因为衍生作品必须开源。如果企业使用GPL代码开发商业软件，可能需要公开源代码‌。
‌GNU LGPL‌：风险中等，适用于库文件。如果仅动态链接LGPL库，可以闭源衍生作品‌。
‌BSD协议‌：风险较低，几乎没有限制，使用者可以闭源修改后的代码‌。

1. MIT 协议

核心条款：

- 允许任何人自由使用、修改、分发代码。
- 必须在分发时保留原始版权声明和许可声明。

风险说明：

- 风险较低，几乎没有限制。
- 使用者可以闭源修改后的代码，无需公开修改内容。

适用场景：适合希望代码被广泛使用的项目。

2. Apache 2.0 协议

核心条款：

- 允许自由使用、修改、分发代码。
- 必须保留原始版权声明和许可声明。
- 如果修改了代码，必须在文件中注明修改内容。
- 提供专利授权，使用者可以获得专利使用权。

风险说明：

- 风险较低，但需要注意专利条款。
- 如果项目涉及专利，需确保专利授权不会引发法律纠纷。

适用场景：适合涉及专利的开源项目。

3. GNU GPL（General Public License）

核心条款：

- 允许自由使用、修改、分发代码。
- 如果分发修改后的代码，必须公开源代码。
- 衍生作品也必须使用 GPL 协议。

风险说明：

- 风险较高，因为衍生作品必须开源。
- 如果企业使用 GPL 代码开发商业软件，可能需要公开源代码。

适用场景：适合希望强制开源的项目。

4. GNU LGPL（Lesser General Public License）

核心条款：

- 允许自由使用、修改、分发代码。
- 如果修改了库代码，必须公开修改内容。
- 衍生作品可以闭源，但必须允许用户替换或修改库。

风险说明：

- 风险中等，适用于库文件。
- 如果仅动态链接 LGPL 库，可以闭源衍生作品。

适用场景：适合开源库项目。

5. BSD 协议

核心条款：

- 允许自由使用、修改、分发代码。
- 必须保留原始版权声明和许可声明。
- 衍生作品可以闭源。

风险说明：

- 风险较低，几乎没有限制。
- 使用者可以闭源修改后的代码。

适用场景：适合希望代码被广泛使用的项目。

6. Mozilla Public License（MPL 2.0）

核心条款：

- 允许自由使用、修改、分发代码。
- 如果修改了文件，必须公开修改内容。
- 衍生作品可以闭源，但修改的文件必须开源。

风险说明：

- 风险中等，介于 GPL 和 MIT 之间。
- 适合需要部分开源的商业项目。

适用场景：适合商业友好的开源项目。

7. Creative Commons（CC）

核心条款：

- 主要用于非代码内容（如文档、图片、音乐）。
- 有多种变体（如 CC BY、CC BY-SA、CC BY-NC 等），条款不同。

风险说明：

- 风险取决于具体变体。
- 例如，CC BY-NC（非商业用途）禁止商业使用。

适用场景：适合非代码内容的开源项目。

8. AGPL（Affero General Public License）

核心条款：

- 类似于 GPL，但增加了网络服务条款。
- 如果通过网络提供服务，必须公开源代码。

风险说明：

- 风险较高，适用于网络服务。
- 如果企业使用 AGPL 代码提供云服务，可能需要公开源代码。

适用场景：适合网络服务类开源项目。

9. Unlicense

核心条款：

- 放弃版权，将代码放入公共领域。
- 允许任何人自由使用、修改、分发代码。

风险说明：

- 风险较低，但完全放弃版权可能导致代码被滥用。

适用场景：适合希望完全放弃版权的项目。

10. Eclipse Public License（EPL）

核心条款：

- 允许自由使用、修改、分发代码。
- 如果修改了代码，必须公开修改内容。
- 衍生作品可以闭源，但修改的部分必须开源。

风险说明：

- 风险中等，适合商业友好的开源项目。

适用场景：适合企业级开源项目。

开源协议的风险总结

1. 法律风险：

- 违反开源协议可能导致法律诉讼。
- 例如，未遵守 GPL 的开源要求可能被起诉。

2. 商业风险：

- 某些协议（如 GPL、AGPL）要求公开源代码，可能影响商业利益。
- 使用宽松协议（如 MIT、BSD）可以降低商业风险。

3. 专利风险：

- 某些协议（如 Apache 2.0）涉及专利授权，需注意专利条款。

4. 声誉风险：

- 违反开源协议可能损害企业或开发者的声誉。

项目开源，如何选择开源协议？

1. 明确目标：

- 如果希望代码被广泛使用，选择宽松协议（如 MIT、BSD）。
- 如果希望强制开源，选择严格协议（如 GPL、AGPL）。

2. 考虑商业需求：

- 如果用于商业项目，选择商业友好协议（如 Apache 2.0、MPL）。

3. 了解法律条款：

- 仔细阅读协议条款，确保合规。

4. 咨询法律专家：

- 如果不确定，建议咨询法律专家。

概叙