作者丨Kate Downing
译者丨明知山
策划丨刘燕
每一个常见的开源许可，如BSD、MIT、Apache和GPL，至少都要求在重新分发代码时标明代码的著作权归属。只要求标明著作权归属的许可被称为“permissive”许可，需要额外提供源代码的许可被称为“copyleft”许可。
有一些许可对著作权归属有非常明确的规定，要求只能出现在特定的地方，比如启动画面，甚至是广告当中，但大多数常见的许可证都没有这么做，大多数开源基金会和公司实体都有政策禁止使用这些许可，它们基本上被遗弃了。今天，业界一致认为，在产品附带的文档中包含开源著作权归属文件就足够了。
不过，随着时间的推移，文档的性质发生了变化。随着包管理器的出现和产品使用的开发库数量的爆炸式增长，重要的产品都有超过数万页的开源著作权归属文件（VMware vSphere产品组合中有一份开源著作权归属声明，总共15385页，为了把它输出成PDF格式，我的MacBook Air死了两次机，所以我有机会统计了一下页数）。
由于许可对著作权的可读性形式没有太明确的规定，而且为了让所有人都能访问，通常以普通文本或其他通用的格式提供，因此这些文档不太容易阅读。而且由于一般开源许可对著作权归属的描述都是轻描淡写，著作权归属文件通常不包含对特定包的描述、它们如何在产品中使用、它们用于产品的哪一部分，或者它们与产品的集成程度如何。通常，包是按字母顺序排列的，即使是一个很小的JavaScript函数，也会得到和框架一样的重视程度。著作权归属文件包含了版权信息，但不包含项目/公司标识或联系信息。
一款产品只使用少量开源包，著作权归属说明可以很容易被塞进产品的“关于”页面，让大多数用户都可以看到，这样的时代已经一去不复返了。由于依赖项的传递性，著作权归属清单变得越来越长。另外，一个开源包现在更有可能包含其他开源子组件，这些子组件也都有自己的许可和版权信息，这种膨胀在多个维度上同时发生。
遵循合规性现在变得更具挑战性，因为它不仅涉及到处理整个项目的版权和许可，还涉及到子组件的版权和许可。有些项目在一个文档中就提供了所有这些信息，但大多数项目没有。大多数项目的次级许可分散在源代码中，而不是集中在LICENSE、NOTICE或COPYING等文件中。
例如，Apache基金会的项目可能会注意到某些子组件处于特定的许可之下，但它们不会在NOTICE文件中重新加入这些版权和许可信息——它们通过分发子组件源代码的方式来遵循合规性。
要找到这些信息，要么需要进行繁琐的手动查找，要么需要使用复杂的扫描工具，但通常仍然需要进行手动检查和校正，而且这两种方式都不是百分百准确。（首先，找到一个项目的所有许可信息并不是件容易的事。一些许可信息位于文件的头部，但有时也会隐藏在文件的中间，而这样的文件可能有一本书那么长。其次，人们对究竟需要复制哪些版权信息并没有达成一致。是否必须复制完全相同的版权和许可信息？如果两份信息之间唯一的区别是版权年份该怎么处理？如果还有其他作者呢？如果内容基本相似，但使用了略微不同的措辞该怎么处理？另外，有些项目在每个文件中都加入了版权信息，有些则将它们放在同一个地方。如果项目中的每一个文件都有版权信息，那么扫描工具和人工都将很难找出唯一的版权和许可信息。）因此，许多公司选择只提供项目的主许可，对于次级许可，他们选择了冒险。
为了遵循开源许可的著作权合规性，下游的用户同样会传递整个项目的源代码，而不是将乏味的著作权文档放在一起。有些人确实会这么做，特别是在容器场景中，他们在容器中传递开源产品的源代码，而不是找到著作权信息并重新打印在文档中，因为这样做要简单得多，也干净得多。但是，在产品体积大小受限的情况下（比如在移动设备上），以及在源代码难以阅读和使用的情况下（比如在冰箱内置的小屏幕上），将大量源代码与产品捆绑在一起就比较困难了。
公司经常应要求提供源代码，或单独在网站上提供源代码，以满足copyleft合规性。但是，从技术上讲，如果将著作权归属信息从产品中分离出来会违反许多许可协议，因此大多数公司会尽量避免这么做。
然而，只有通过传递源代码才能真正实现完美的合规性这一事实似乎违背了制定许可协议的初衷。如果只有通过传递源代码才能遵循合规性，那么这个许可就不再是真正permissive的了。许多开发者为他们的代码选择了permissive许可，因为他们希望自己的代码尽可能被广泛地使用，而且特别不想强迫用户接受额外的与源代码相关的限制条件。他们当中有许多人并没有过多地考虑是否选择permissive许可或者是否将他们的代码贡献给公共领域，因为permissive许可非常常见，并且已经使用了很长时间。
相反，在2009年Creative Commons发布CC0 1.0 Universal之前，向公共领域贡献代码是一个棘手的命题。CC0 1.0 Universal为开发者提供了合适的工具包，让他们可以向公共领域奉献代码，即使在不承认公共领域概念的国家也可以保护贡献者的意图。如果越来越多的开发者知道permissive许可现在变得更像是copyleft许可，那么许多人很可能会选择将他们的代码开放给公共领域，而不是放在permissive许可之下。因为著作权归属深埋在文档中，无论如何都没有人会去阅读，本质上只是增加了下游用户的开销。
从历史上看，permissive许可在法律强制执行层面的情况并不多见。法律强制执行实际上一直集中在GPL许可家族上，尽管其中一些强制执行的主张显然与分发者未能正确标明GPL代码所有者属性这一事实有关。在很大程度上，这是因为上游选择permissive许可的人更关心他们的代码是否可以被广泛传播，而不是确保下游用户保持代码“开放”（因为对于这种情况，他们可以选择copyleft许可）。
长期以来，人们一直猜测这种情况可能会发生改变，我们可能会看到一些“著作权归属喷子”，著作权所有者也会开始强制执行permissive许可。尽管这种情况还没有发生，但我们已经看到Copilot在向用户提供输出时未能正确归属开源著作权而导致了一场法律纠纷。
一方面，有些人可能会认为著作权归属要求是合理的，也是公司应该负担的开销，特别是如果他们想要阻扰Copilot的话。但我觉得其他一些人会认为这并不是他们真正想要的，特别是因为这些开销也会落到个人和非营利性开源维护者头上（没有人可以豁免遵循第三方开源许可）。随着联邦层面出于安全性目的而不断推动产品维护适当的材料清单，我们已经看到越来越多的公司转向了上游项目维护者，要求更好、更易于理解的代码来源信息。他们可能也会在著作权归属问题上犯难。
将高质量的代码发布到网络上，并从中获得回报，这种愿望是可以理解的。许多开发者非常关心自己的声誉，他们为开源做贡献，至少在一定程度上是为了向其他开发者和潜在雇主表明，他们掌握了有用的技能。当然，在非营利性基金会甚至是企业赞助下运作的大型项目也需要维护自己品牌。但是，我们也很难说传统的开源著作权归属合规性要求会给开发者带来什么。
现在，关于开源项目伟大之处的信号主要来自于GitHub上的Star数、fork数量、技术博客、Hacker News网站等等。我从未听说过有人在浩如烟海的项目中仅仅因为看到某个项目的著作权归属文件而检出这个项目。
开发者可以用更好的方法来建立自己的声誉和品牌。将联系信息包含在项目中（可以放在license.txt文件或头部注释中）可能就足够了，因为很少有人会有意或主动从这些代码中删除这些信息。
需要注意的是，下游用户希望能够轻松地找到有用的开源项目，虽然在项目中加入著作权归属文件既麻烦又耗时，但他们仍然想要知道软件的起源——他们想知道同样的开发者还开发了其他什么东西，他们想要代码的更新版本，他们想要知道如果代码出现了安全问题应该找谁，他们还想要知道如果要招人时该招谁，甚至如果要收购公司的话该收购哪家。
某些公司也开始在全球范围内跟踪开源项目的使用情况，并报告哪些项目被使用得较为广泛，谁在使用，这些信息给予了开发者声誉，并将下游用户指向了那些有用的项目。包管理器也可以自动跟踪这类数据并将其公开。不管怎么说，这个问题早就该通过非法律手段来解决了。
https://katedowninglaw.com/2022/11/28/is-open-source-attribution-dead/