谈谈主流开源技术证书

原创已于 2025-11-03 16:48:47 修改 · 744 阅读

CC 4.0 BY-SA版权

文章标签：

于 2025-11-03 16:44:33 首次发布

这里所谓的主流就是指github上面创建仓库时，提供的lic。当然也可以自行上传其他证书，也是可以生效的。

代价是开源的证书

GPL v3：对于具备这个证书的源码进行修改需要开源

AGPL v3：同上，修补了上面证书的SaaS部署漏洞(自行查阅)

非主流SSPL证书：关于该开源代码的提供服务的代码也需要开源，强化了AGPL，属于商业条例，所以不是主流开源证书

MIT：通常是在软件的“关于”页面、文档或者一个LICENSE文件中，写明“本产品包含了XXX项目（遵循MIT许可证）”并附上其许可证原文

Apache 2.0：在MIT基础上额外要求如果修改了文件，需要清晰地声明修改之处。

3-Clause BSD：在MIT基础上额外要求不要宣传，比如“本软件是基于清华大学顶尖的开源程序制作的”

Strings：来自微软官方的Sysinternals套件。它可以提取二进制文件中的可读文本字符串。

Dependencies：一个现代化的开源工具，用来替代旧的Dependency Walker，可以查看一个.exe或.dll依赖哪些其他的.dll文件。

带有专利条款的lic (如Apache 2.0, GPLv3，AGPL v3)

你修改了代码：当你向项目贡献你的修改时，许可证的专利授权条款就被触发了。你已经自动地将与你修改相关的专利，免费授权给了社区里的每一个人。
你再去申请专利：你可以去申请，甚至可能申请成功。
你用专利告别人：当你试图用这个专利去起诉社区里的任何一个使用者时，会发生两件事： a. 对方会拿出许可证，说：“根据Apache 2.0许可证，你已经给了我专利授权，所以你的起诉无效。” b. 许可证的“专利报复条款”会触发，你将立刻失去从这个项目获得的所有其他人的专利授权，让你自己也暴露在风险之下。
结论：在这种情况下，许可证已经提前把你的“武器”给缴了。这就成为了一个所有人都可以免费使用的假专利。

具备专利条款BUG的lic

没有明确专利条款的旧许可证 (如MIT, BSD, GPLv2)

开源社区（尤其是像自由软件基金会FSF和软件自由保护协会SFC这样的组织）处理违规通常遵循一个“合规优先，诉讼最后”的原则。

初始阶段：私下沟通与教育
- 通常，版权所有者或其代表会先给违规公司发送一封友好的邮件或信函，指出他们发现的违规问题，并解释如何才能做到合规。
- 目标：解决问题，而不是惩罚。很多公司（尤其是小公司）违规是出于无知，而非恶意。
- 结果：绝大多数（超过90%）的违规案件都在这个阶段得到解决。 公司会选择补救措施，比如：
  a. 完全合规：按照GPL要求，公开其软件的完整源代码。
  b. 停止分发：立即停止销售和分发该产品。
  c. 替换组件：从软件中移除GPL代码，用其他许可证兼容的或自研的代码替换，然后重新发布。
升级阶段：法律警告
- 如果公司忽视初次沟通或拒绝合作，将会收到更正式的法律警告信，明确指出他们的行为构成版权侵犯，并设定一个最后期限来纠正。

许可证自动终止 (Automatic License Termination)：这是GPL最厉害的一点。一旦你违反了GPL的任何条款，你使用该软件的许可证将自动、立即终止。 从那一刻起，你每一次分发该软件的行为，都是赤裸裸的版权侵犯。
禁令 (Injunction)：法院可以发布禁令，强制该公司立即停止所有分发和销售行为。对于一个靠此软件盈利的公司来说，这是致命的打击。
强制合规：法院也可以判决公司必须履行GPL的义务，即公开其源代码。