这里所谓的主流就是指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 的关系
带有专利条款的lic (如Apache 2.0, GPLv3，AGPL v3)
-
你修改了代码 ：当你向项目贡献你的修改时，许可证的专利授权条款 就被触发了。你已经自动地将与你修改相关的专利，免费授权给了社区里的每一个人。
-
你再去申请专利：你可以去申请，甚至可能申请成功。
-
你用专利告别人 ：当你试图用这个专利去起诉社区里的任何一个使用者时，会发生两件事： a. 对方会拿出许可证 ，说："根据Apache 2.0许可证，你已经给了我专利授权，所以你的起诉无效。" b. 许可证的"专利报复条款"会触发，你将立刻失去从这个项目获得的所有其他人的专利授权，让你自己也暴露在风险之下。
-
结论：在这种情况下，许可证已经提前把你的"武器"给缴了。这就成为了一个所有人都可以免费使用的假专利。
具备专利条款BUG的lic
没有明确专利条款的旧许可证 (如MIT, BSD, GPLv2)
-
这种情况就非常危险，也就是我们之前讨论的**"专利埋伏"**。
-
你可以修改代码，贡献给社区，然后悄悄申请专利。等大家都在用的时候，你再跳出来起诉。
-
结论：这在法律上是可行的，也是开源社区最大的噩梦之一。正因为如此，新项目现在普遍推荐使用Apache 2.0或GPLv3（or AGPL v3）。
法律的终极解决方案
法律后果的流程和严重性
开源社区（尤其是像自由软件基金会FSF和软件自由保护协会SFC这样的组织）处理违规通常遵循一个"合规优先，诉讼最后"的原则。
-
初始阶段：私下沟通与教育
-
通常，版权所有者或其代表会先给违规公司发送一封友好的邮件或信函，指出他们发现的违规问题，并解释如何才能做到合规。
-
目标：解决问题，而不是惩罚。很多公司（尤其是小公司）违规是出于无知，而非恶意。
-
结果 ：绝大多数（超过90%）的违规案件都在这个阶段得到解决。 公司会选择补救措施，比如：
a. 完全合规 ：按照GPL要求，公开其软件的完整源代码。
b. 停止分发 ：立即停止销售和分发该产品。
c. 替换组件：从软件中移除GPL代码，用其他许可证兼容的或自研的代码替换，然后重新发布。
-
-
升级阶段：法律警告
- 如果公司忽视初次沟通或拒绝合作，将会收到更正式的法律警告信，明确指出他们的行为构成版权侵犯，并设定一个最后期限来纠正。
-
最终阶段：法律诉讼（最后的手段）
- 如果公司执意不遵守，版权所有者可以将其告上法庭。诉讼的法律依据不是"违反了GPL合同"，而是"在没有有效许可的情况下，非法复制和分发了受版权保护的作品"。
法庭上的可能判决
-
许可证自动终止 (Automatic License Termination) ：这是GPL最厉害的一点。一旦你违反了GPL的任何条款，你使用该软件的许可证将自动、立即终止。 从那一刻起，你每一次分发该软件的行为，都是赤裸裸的版权侵犯。
-
禁令 (Injunction) ：法院可以发布禁令，强制该公司立即停止所有分发和销售行为。对于一个靠此软件盈利的公司来说，这是致命的打击。
-
经济赔偿 (Monetary Damages)：版权所有者可以要求经济赔偿，金额可能基于违规软件带来的利润，或者是法定赔偿金。
-
强制合规：法院也可以判决公司必须履行GPL的义务，即公开其源代码。
本内容均来源于AI，作者对于前三节进行了总结，后两节几乎没有总结。以供中国的程序员novice参考！