宽松许可和著佐权并非反义词
将“宽松许可”用作“著佐权”的反义词，或将“限制性”用作其同义词，是一种无益的框架。请改为描述许可证互惠性。
一些开源许可证实施了理查德·斯托曼发明的一个巧妙的技巧，作为版权许可的条件，任何创建衍生版本的人都必须同意以与原始版本相同的方式许可新版本。这个概念被戏称为“著佐权”，许多开源许可证都实施了这个技巧。
在最强的形式中，“著佐权”思想可以对所有其他编译在一起以形成最终二进制可执行程序的代码的许可施加条件。遵守此要求可以防止使用拒绝最终用户软件自由的商业模式；因此，许多商业软件开发人员避免使用最强的著佐权许可形式。
存在不太严格的著佐权形式。像 MPL（Mozilla 公共许可证）这样的许可证仅要求修改后的单个文件以与原始文件相同的许可证许可，并且不将该要求扩展到用于构建可执行文件的其他文件。Eclipse 公共许可证 (EPL) 具有由源代码分发触发的著佐权条款。这些范围受限的变体都被描述为“弱著佐权”。
在与客户讨论这些许可方法时，我经常发现“强著佐权”和“弱著佐权”这些术语会导致误解。特别是，开发人员可能会错误地将适用于一种“弱”许可证的合规步骤应用于另一种许可证下的代码，认为所有此类许可证都是相同的。因此，我更喜欢使用不同的术语。
用“互惠许可”代替“著佐权”
首先，我尝试解决由巧妙且通常不熟悉的术语“著佐权”引入的挑战。开源运动中某些派别对著佐权的妖魔化——他们甚至可能错误地将此类许可证称为“限制性”——使其看起来比实际情况更成问题。相反，我解释说，所涉及的社区具有基于互惠行为的规范，并期望那些使用其代码的人与他人分享他们所获得的相同的创新自由。
主要的许可律师埃本·莫格伦（现代 GPL 的主要共同创建者）解释说，开源许可证体现了使用它们的社区的规范。它们在许多方面是“社区的宪法”，因此体现互惠规范是理所当然的。我将许可证的这一方面称为“互惠许可”，以努力承认使用著佐权来表达社区对互惠的期望。我发现这个术语减少了混淆。
用描述互惠范围代替“强”或“弱”著佐权。
其次，我发现术语“强”和“弱”没有被很好地理解，定义也不明确。对开发人员真正重要的是相关社区期望的互惠范围。这并不总是意味着向项目贡献代码；例如，GPL 仅要求开发人员在有限的时间内，针对每个版本，提供以与原始版本相同的条款提供代码。但互惠确实意味着必须保持一致的许可。
这个概念在 LGPL 的情况下对我的客户有所帮助。该许可证通常被描述为“弱著佐权”许可证，因为它允许将生成的二进制文件与非 GPL 许可的作品组合（与 GPL 本身不同）。但是“弱”的分类没有帮助，因为它在不同的上下文中意味着不同的事物。
例如，LGPL 与 MPL 的“弱”程度不同。来自 LGPL 项目的代码本身在项目级别上是完全互惠许可的。从它借用的用于其他用途的任何代码以及项目本身的其他用途都应根据相同的 LGPL 完全许可。在项目本身中，LGPL 就像 GPL 代码一样是“强著佐权”，但生成的执行文件不一定具有“强著佐权”要求——在许多用途中，它实际上是非互惠的。
我更喜欢根据预期互惠的范围和性质对互惠许可证进行分类。像 GPL 和 EUPL 这样的许可证将预期互惠的范围设置为包括创建生成的项目二进制文件所需的任何代码，因此我将这些描述为“项目范围互惠许可证”。这种分类对于 LGPLv3 很有帮助，LGPLv3 是一种项目范围互惠许可证，但有一个例外限制了项目的边界。
像 MPL 这样的许可证将预期互惠的范围设置为项目中的单个源文件，而不是整个项目。如果您更改了项目中某个文件的内容，或在新代码库中重用了项目文件中代码，则生成的文件必须以与原始文件相同的方式许可，但对组合在一起以创建新可执行文件的其他文件没有要求。我将这些称为“文件范围互惠许可证”。
用“非互惠”代替“宽松许可”
第三，像 MIT、BSD 和 Apache 许可证这样的许可证有时被描述为“宽松许可”。用这个词来区分任何开源许可证都是不好的。所有开源许可证主要都是宽松许可，因为它们允许无条件使用，这与专有许可证不同。与互惠许可证一样，所涉及的社区具有不同的期望，并将这些期望体现在他们的许可证中。虽然它们可能不包含互惠性，但它们可能仍然包含繁琐的条款。
例如，所谓的“宽松许可”可能仍然包括关于署名的具体操作，或者授予广泛的专利许可。它们也可能未能包含任何关于专利的条款，从而造成风险。这些属性也可能影响客户可以使用的商业模式，只是方式与互惠许可证不同。因此，我发现将它们描述为“非互惠许可证”更有帮助，以便将分类清楚地限制在许可证的互惠特性上。
在实践中，我发现这三个术语——项目范围互惠、文件范围互惠和非互惠——突出了对开发人员最重要的内容，并避免了无意中混淆问题。我建议使用它们来代替“宽松许可”和“弱/强著佐权”或“限制性”。
（本文的较短版本最初于 2013 年 11 月 发表在 InfoWorld 上）
本文最初发表在 “Meshed Insights” 上，并由 Patreon 赞助人促成。