现在我们了解了如何使用GPL，合规成本可能不仅仅是一个版权问题。

甚至在Christoph Hellwig（由软件自由保护协会支持）开始他的适合为了强制执行他对VMWare的版权主张，公司律师以及他们的高管客户对GPL特别是版权许可和一般的版权许可感到非常恐惧。 

这是因为担心软件开发人员可能无意中影响公司估值，并通过日常开发工作邀请股东采取行动。律师们知道，GPL的互惠条款在多个司法管辖区的法院得到了支持。虽然有许多细微差别，但这些术语概括为“如果用于创建您发布的软件的代码的任何部分是根据GPL授权给您的，那么每一个其中一部分必须根据GPL提供。”由于GPL许可版权的条件是每个接收者都可以自由请求完整的相应源代码，然后修改和/或分发它，这可能意味着失去对公司产品每个部分的控制。这些是真正的关切。

对于嵌入开源代码的硬件供应商来说，违反GPL意味着失去版权许可证，可能需要刷新或销毁整个设备仓库。至少，这可能意味着在问题得到解决时停止发货。

对于软件供应商来说，依赖商业机密和供应商锁定实现盈利的策略可能会因违反GPL而受到严重破坏。由于风投贷款的资金不仅根据收入进行调整，而且还利用客户锁定程度来确定估值乘数，这可能是一场灾难。虽然一家拥有大规模所有权锁定的公司可能会被风投以十倍于其收入的价格估值，但一家基于公共代码的纯服务业务可能只会以两倍于其收益的价格估值。难怪VMWare如此积极地反击。

当然，在VMWare的案件中，违反GPL的指控是一个战略决策，而不是一个意外。但对于我们其他人来说，公司法律顾问对非avvy CEO的建议导致了对GPL的极端风险规避。围绕着这一点，一个完整的行业如雨后春笋般涌现，被一些人戏称为“合规行业综合体”。一方面，像Black Duck和Palamida这样的公司提供咨询和工具来根除GPLed代码。另一方面，Linux基金会和软件自由保护协会等实体发布了符合GPL的操作指南。

这都增加了开发费用，也避免了GPL作为许可证。但这一行动实际上可能对工程副总裁没有帮助。虽然对互惠条款的关注是有效的，但这并不是唯一值得遵守的许可要求。即使是简单的所谓“许可”许可也需要遵守——只是不考虑互惠。它们通常包括归属要求，这可能会成为产品团队的主要合规挑战。

例如，BSD许可证在第2条中规定：

二进制形式的重新分发必须在分发时提供的文档和/或其他材料中复制上述版权声明、此条件列表和以下免责声明。

一旦您使用了BSD许可源的任何部分，您就必须在程序中包含其版权所有者的详细信息。随着使用的源数量的增加，确保满足其使用的许可证的所有不同属性要求的挑战也随之增加。由于BDS/MIT/ISC许可证及其类似文本的细微变化，每个属性都复制了文本；这份清单通常涵盖很多页。维护它是产品工程的一大难题。

在Apache许可证的常见情况下，情况甚至更加复杂。它要求维护包含属性列表的NOTICE文件，但也要求在代码中插入“文件更改”指示器，甚至在没有其他贡献者协议的情况下，对上游贡献应用默认许可条款（包括专利许可）。所有这些需求都需要跟踪。

因此，假设谴责GPL可以解决所有问题，这是一个严重的错误。这就是为什么我不喜欢对非版权许可使用术语“许可”。所有开源许可证都是许可的，因为它们授予您使用、改进和共享受版权保护的材料的自由。然而，这种自由取决于对许可条款的遵守，称许可为“许可”掩盖了这一现实。

您的一些业务职能部门可能会强调许可证中互惠要求的重要性（有充分的理由），但产品工程团队必须尊重全部的专利和开源成分的要求。这种合规负担不一定通过避免GPL来最小化。事实上，丰富的资源和GPL合规指南可能使其成为最小的问题。

仅仅因为“顺从-行业情结”想要你害怕互惠，这并不意味着你应该这么做。每个案件都需要了解其本身的优点。谁知道呢？就你而言，接受GPL可能是成本最低的选择。

（通过以下方式实现Patreon赞助商。也许你应该成为一名？）