- 保留简略的版权声明即可，无需投入过多资源维护。
版权声明(Copyright Notice)在源代码中的应用并不一致且维护不善，结果导致它无法成为良好的信息来源。那是否应该投入更多资源来维护版权声明呢?答案是不需要。
版权声明是单行字符串，通常包括单词“版权”(或某些替代词，如 ©)、名称(通常是个人或公司)和年份。
在本文中，我不关注许可证或许可证声明(有时可能包括版权声明)。我关于版权声明维护的资源投入应该保持低优先级的建议不适用于许可证信息。许可证信息应清晰呈现并保持准确。如果你邀请其他人使用你的软件并对其进行操作，请通过提供并维护清晰的许可证信息来明确其授予的权限。
再说回版权声明：它们的法律意义是什么呢?如果你认为版权声明符合法律要求或至少提供了重要的法律权益，请三思。此类声明在开源软件中的法律意义是如此之小，以至于人们可以轻易地找到超出其法律意义的实际做法。
尽管此类声明可能看起来很重要，但它们在当今源代码中的存在很大程度上是过去美国版权法的残余影响。曾经有一段时间，如果未在已出版的材料中包含版权声明，依据美国版权法，版权人可能会完全丧失权利;当美国最终加入《伯尔尼公约》并成为缔约国时，情况发生了变化(美国于 1988 年 11 月 16 日加入该条约，并于 1989 年 3 月 1 日在美国生效)。
如果开源软件中的此类声明要想具备实效，则一个项目可以采用能够以更少的投入来维护并且仍然获得一些实用价值的约定，不必为了满足美国对“版权声明”的法定要求而去维护版权声明。
由于美国版权法一直是推动版权声明使用的重要因素，因此我将在此进行更深入的探讨。美国版权局发布了名为《通函-3号-版权声明》的指导文件，包括：
“在 1989 年 3 月 1 日之前首次出版的所有作品都必须放置版权声明，但下面讨论的某些情况例外。如果省略了该声明或在使用该声明时出现了错误，则通常该作品在美国将失去版权保护。版权声明对于 1989 年 3 月 1 日或之后出版的作品、未出版的作品和外国作品是可选的;但是，将版权声明包括在你的作品中将享有法律权益。”
上面我加粗强调的那句话清楚地表明，在 1988 年的美国，版权声明就非常重要。但是，当美国与其他许多国家一起加入《伯尔尼公约》时，美国法律对版权声明的关键作用被消除了。公约规定：“享有和行使这些权利不需经过任何手续……”
麻省理工学院的软件项目(The X Window System)和加州大学伯克利分校的软件项目(Berkeley Software Distribution)中诞生了早期的开源许可证文本，彼时严格的“放置版权声明否则丧失权利”要求仍然有效(或至少在为这些许可证文本做出贡献的人们心中是明确的)。诞生于这种时机的结果是，许可证文本中仍存在有关复制版权声明的明确描述。
随着基于早期文本的许可证的继续广泛使用，大多数开源软件开发人员已经看到，版权声明似乎在许可证中显得很重要。但是这些文本是在考虑较早的法律制度的情况下创建的。现在，距《伯尔尼公约》(大多数其他国家已经接受)的“无需手续性要求”规定首次适用于美国的时间已经过去 30 年了。要了解《伯尔尼公约》的通过程度，请参阅管理该公约的世界知识产权组织维护的缔约方清单。
你可能想知道上面引用中提到的那些“法律权益”具体指什么，答案在 3 号通函的末尾：
尽管对于未出版的作品、外国作品或于1989年3月1日或之后出版的作品，版权声明是可选的，但使用版权声明具有以下好处：
- 版权声明使潜在用户意识到该作品拥有版权。
- 对于已发表的作品，版权声明可能会阻止版权侵权诉讼中的被告试图减轻其基于无辜侵权辩护的损害赔偿或禁令救济的责任。
- 版权声明标识了在首次发布作品时版权所有者的权利，供寻求使用该作品的许可方使用。
- 版权声明标识首次出版的年份，对于匿名作品、假名作品或出租作品而言，可用于确定版权保护期限。
- 版权声明可能会通过标识版权所有者并设定版权期限来防止其成为孤儿作品。
上面就是所谓的那些“法律权益”。
我引用了美国版权局第 3 号通函，因为与基本法规相比，它对要求的措辞更具可读性。美国联邦一级的成文法被编入所谓的《美国法典》，该法典被组织为一组“卷”(Title)。第 17 卷是版权。版权声明的详细信息位于该卷的第 401-406 部分。可以从 17 USC 401 开始。在版权声明中需包含三个要素描述的有关法规要求，请参见 17 USC 401(b)。如果要查看“疏忽对无辜侵权者的影响”的详细信息，请参见 17 USC 405(b)。
为了提供更准确的信息，为什么不清理代码库中的版权声明?尴尬的是，17 USC 506(c)(欺诈性版权声明)、17 USC 506(d)(欺诈性删除版权声明)和 17 USC 1202(a)(虚假版权管理信息)提供了一些不利因素(即使仅限于不良意图)。由于价值较低且存在一定风险(如果在进行更改时出错)，因此难怪没有更多资源用于维护版权声明。
有些人和一些公司强调将详细的版权声明放入根据开源许可证提供的代码中。其他人则没有。随着开源项目的发展，某些贡献中可能包含版权声明，而其他贡献则没有。即使文件的内容与原始版本相比发生了很大的变化，文件也可以包含原始版权声明，而不包含其他版权声明。或者以后的贡献者可以向以前没有版权声明的文件中添加一个版权声明。那作为版权声明要素的“该作品的首次出版年份”呢?这意味着什么?不同的人有不同的做法。已更新?那其他贡献提交之后呢?
至于从挖掘版权声明数据中得出结论，要谨慎。期望值不要那么高。
那开源项目应该怎么做呢?
请提供并维护清晰、准确的许可证信息。
对于版权声明来说，很难证明为维护版权声明的详细信息而进行的投入是合理的。但是有些人可能希望会出现版权声明。至于“软件的起源”，也许仅仅参考项目本身而不是尝试捕获更细粒度的内容可能会更有用和更准确。公开年份?手动维护源文件中的麻烦程度导致其不大值得;源管理工具以较低的资源成本提供了更准确的信息。
有关实用方法的更多详细信息，我建议你将注意力集中在对版权声明实践的重新思考上，可以参考 Steve Winslow 于 2020 年 1 月 10 日发布的《开源软件项目中的版权声明》。
作者简介：Scott Peterson 是红帽公司(Red Hat)法律团队成员。很久以前，一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议，这个致命的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。
译者简介：薛亮，集慧智佳知识产权咨询公司互联网事业部总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。
