开源项目的版权声明已无存在必要？
版权声明

> 
> 保留简略的版权声明即可，无需投入过多资源维护。
> 
> 
> 


![](/data/attachment/album/202102/04/085612fjj2a6zj5rzhj5fq.jpg)


<ruby> 版权声明 <rp>  （ </rp> <rt>  Copyright Notice </rt> <rp>  ） </rp></ruby>在源代码中的应用并不一致且维护不善，结果导致它无法成为良好的信息来源。那是否应该投入更多资源来维护版权声明呢？答案是不需要。


版权声明是单行字符串，通常包括单词“版权”（或某些替代词，如 ©）、名称（通常是个人或公司）和年份。


在本文中，我不关注许可证或许可证声明（有时可能包括版权声明）。我关于版权声明维护的资源投入应该保持低优先级的建议不适用于许可证信息。许可证信息应清晰呈现并保持准确。如果你邀请其他人使用你的软件并对其进行操作，请通过提供并维护清晰的许可证信息来明确其授予的权限。


再说回版权声明：它们的法律意义是什么呢？如果你认为版权声明符合法律要求或至少提供了重要的法律权益，请三思。此类声明在开源软件中的法律意义是如此之小，以至于人们可以轻易地找到超出其法律意义的实际做法。


尽管此类声明可能看起来很重要，但它们在当今源代码中的存在很大程度上是过去美国版权法的残余影响。曾经有一段时间，如果未在已出版的材料中包含版权声明，依据美国版权法，版权人可能会完全丧失权利；当美国最终加入《[伯尔尼公约](https://www.wipo.int/treaties/en/ip/berne/)》并成为缔约国时，情况发生了变化（美国于 1988 年 11 月 16 日加入该条约，并于 1989 年 3 月 1 日在美国生效）。


如果开源软件中的此类声明要想具备实效，则一个项目可以采用能够以更少的投入来维护并且仍然获得一些实用价值的约定，不必为了满足美国对“版权声明”的法定要求而去维护版权声明。


由于美国版权法一直是推动版权声明使用的重要因素，因此我将在此进行更深入的探讨。美国版权局发布了名为《[通函-3号-版权声明](https://www.copyright.gov/circs/circ03.pdf)》的指导文件，包括：


*“在* *1989* *年* *3* *月* *1* *日之前首次出版的所有作品都必须放置版权声明，但下面讨论的某些情况例外。**如果省略了该声明或在使用该声明时出现了错误，则通常该作品在美国将失去版权保护。**版权声明对于* *1989* *年* *3* *月* *1* *日或之后出版的作品、未出版的作品和外国作品是可选的；但是，将版权声明包括在你的作品中将享有法律权益。”*


上面我加粗强调的那句话清楚地表明，在 1988 年的美国，版权声明就非常重要。但是，当美国与其他许多国家一起加入《伯尔尼公约》时，美国法律对版权声明的关键作用被消除了。公约规定：“享有和行使这些权利不需经过任何手续……”


麻省理工学院的软件项目（The X Window System）和加州大学伯克利分校的软件项目（Berkeley Software Distribution）中诞生了早期的开源许可证文本，彼时严格的“放置版权声明否则丧失权利”要求仍然有效（或至少在为这些许可证文本做出贡献的人们心中是明确的）。诞生于这种时机的结果是，许可证文本中仍存在有关复制版权声明的明确描述。


随着基于早期文本的许可证的继续广泛使用，大多数开源软件开发人员已经看到，版权声明似乎在许可证中显得很重要。但是这些文本是在考虑较早的法律制度的情况下创建的。现在，距《伯尔尼公约》（大多数其他国家已经接受）的“无需手续性要求”规定首次适用于美国的时间已经过去 30 年了。要了解《伯尔尼公约》的通过程度，请参阅管理该公约的世界知识产权组织维护的[缔约方清单](https://www.wipo.int/treaties/en/ShowResults.jsp?lang=en&treaty_id=15)。


你可能想知道上面引用中提到的那些“法律权益”具体指什么，答案在 3 号通函的末尾：



> 
> 尽管对于未出版的作品、外国作品或于1989年3月1日或之后出版的作品，版权声明是可选的，但使用版权声明具有以下好处：
> 
> 
> * 版权声明使潜在用户意识到该作品拥有版权。
> * 对于已发表的作品，版权声明可能会阻止版权侵权诉讼中的被告试图减轻其基于无辜侵权辩护的损害赔偿或禁令救济的责任。
> * 版权声明标识了在首次发布作品时版权所有者的权利，供寻求使用该作品的许可方使用。
> * 版权声明标识首次出版的年份，对于匿名作品、假名作品或出租作品而言，可用于确定版权保护期限。
> * 版权声明可能会通过标识版权所有者并设定版权期限来防止其成为孤儿作品。
> 
> 
> 


上面就是所谓的那些“法律权益”。


我引用了美国版权局第 3 号通函，因为与基本法规相比，它对要求的措辞更具可读性。美国联邦一级的成文法被编入所谓的《美国法典》，该法典被组织为一组<ruby> “卷” <rp>  （ </rp> <rt>  Title </rt> <rp>  ） </rp></ruby>。第 17 卷是版权。版权声明的详细信息位于该卷的第 401-406 部分。可以从 17 USC 401 开始。在版权声明中需包含三个要素描述的有关法规要求，请参见 [17 USC 401（b）](https://www.copyright.gov/title17/92chap4.html#401)。如果要查看“疏忽对无辜侵权者的影响”的详细信息，请参见 [17 USC 405（b）](https://www.copyright.gov/title17/92chap4.html#405)。


为了提供更准确的信息，为什么不清理代码库中的版权声明？尴尬的是，[17 USC 506（c）（欺诈性版权声明）](https://www.copyright.gov/title17/92chap5.html#506)、[17 USC 506（d）（欺诈性删除版权声明）](https://www.copyright.gov/title17/92chap5.html#506)和 [17 USC 1202（a）（虚假版权管理信息）](https://www.copyright.gov/title17/92chap12.html#1202)提供了一些不利因素（即使仅限于不良意图）。由于价值较低且存在一定风险（如果在进行更改时出错），因此难怪没有更多资源用于维护版权声明。


有些人和一些公司强调将详细的版权声明放入根据开源许可证提供的代码中。其他人则没有。随着开源项目的发展，某些贡献中可能包含版权声明，而其他贡献则没有。即使文件的内容与原始版本相比发生了很大的变化，文件也可以包含原始版权声明，而不包含其他版权声明。或者以后的贡献者可以向以前没有版权声明的文件中添加一个版权声明。那作为版权声明要素的“该作品的首次出版年份”呢？这意味着什么？不同的人有不同的做法。已更新？那其他贡献提交之后呢？


至于从挖掘版权声明数据中得出结论，要谨慎。期望值不要那么高。


那开源项目应该怎么做呢？


请提供并维护清晰、准确的许可证信息。


对于版权声明来说，很难证明为维护版权声明的详细信息而进行的投入是合理的。但是有些人可能希望会出现版权声明。至于“软件的起源”，也许仅仅参考项目本身而不是尝试捕获更细粒度的内容可能会更有用和更准确。公开年份？手动维护源文件中的麻烦程度导致其不大值得；源管理工具以较低的资源成本提供了更准确的信息。


有关实用方法的更多详细信息，我建议你将注意力集中在对版权声明实践的重新思考上，可以参考 Steve Winslow 于 2020 年 1 月 10 日发布的《[开源软件项目中的版权声明](https://www.linuxfoundation.org/blog/2020/01/copyright-notices-in-open-source-software-projects/)》。




---


作者简介：Scott Peterson 是红帽公司（Red Hat）法律团队成员。很久以前，一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议，这个致命的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。 


译者简介：薛亮，集慧智佳知识产权咨询公司互联网事业部总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。


![](/data/attachment/album/202102/04/085738ztovsnv2tt9t6sez.jpg)


OK
Copyright notices in source code are inconsistently applied and poorly maintained. As a result, such notices are poor sources of information. Should more resources be applied to the maintenance of copyright notices? No.

Copyright notices are one-line strings that typically include the word "Copyright" (or some substitute, like ©), a name (usually a person or company), and a year.

In this article, I am *not* focusing on licenses or license notices (which may sometimes *include* a copyright notice). My suggestion for low prioritization of investment in copyright notice maintenance does NOT apply to license information. License information should be clearly presented and maintained to be accurate. If you invite others to take and do something with your software, please make the permissions that are being given clear by presenting and maintaining clear license information.

Returning to copyright notices: What is their legal significance? If you think copyright notices satisfy a legal requirement or at least provide a significant legal benefit, think again. The legal significance of such notices in open source software is so small that one can easily find practical considerations outweighing the legal significance.


While these notices may appear important, their presence in source code today is largely a residue of the copyright law of the past. There was a time when failure to include a copyright notice in published material could result in complete loss of rights under US copyright law; that changed when the United States finally joined the many other countries that were already parties to the [Berne Convention](https://www.wipo.int/treaties/en/ip/berne/) (US accession to the treaty came on November 16, 1988, and became effective in the US on March 1, 1989).

If there is a utility in these notices in open source software, rather than maintaining copyright notices, a project could adopt conventions that, rather than seeking to meet the US statutory requirements for a "copyright notice," can be maintained with less effort and still obtain some practical value.

As US Copyright Law has been such a significant factor in driving the use of copyright notices, this is where I will dive more deeply. The US Copyright Office publishes guidance documents known as [Circulars](https://www.copyright.gov/circs/). Circular 3, [Copyright Notice](https://www.copyright.gov/circs/circ03.pdf), includes:

"Copyright notice was required for all works first published before March 1, 1989, subject to some exceptions discussed below.

If the notice was omitted or a mistake was made in using copyright notice, the work generally lost copyright protection in the United States.Copyright notice is optional for works published on or after March 1, 1989, unpublished works, and foreign works; however, there are legal benefits for including notice on your work."

The sentence I highlighted makes it clear that, in the US, copyright notices were *very* important as recently as 1988. But when the US joined the many other countries in the Berne Convention, the critical role for copyright notices under US law was eliminated by the Convention's provision that: "The enjoyment and the exercise of these rights shall not be subject to any formality…"

Software projects at MIT (The X Window System) and at the University of California, Berkeley, (Berkeley Software Distribution) led to early license texts that each had origins when the draconian notice-or-lose-it requirement was still in force (or at least fresh in the minds of those contributing to the text of these licenses). A result of that timing is that these license texts have explicit language about reproducing copyright notices.

With the continued pervasive use of licenses based on these texts, most developers of open source software have seen licenses that appear to place importance on copyright notices. But those texts were created with an earlier legal regime in mind. We are now 30 years past the time when the no-formalities-required feature of the Berne Convention (which most other countries had already embraced) was first applicable to the US. To appreciate the extent of Berne Convention adoption, see the list of [contracting parties](https://www.wipo.int/treaties/en/ShowResults.jsp?lang=en&treaty_id=15) maintained by the World Intellectual Property Organization, which administers the Berne Convention.

You might be wondering about those "legal benefits" mentioned in the quote above. The answer is at the end of Circular 3:

Although notice is optional for unpublished works, foreign works, or works published on or after March 1, 1989, using a copyright notice carries the following benefits:


- Notice makes potential users aware that copyright is claimed in the work.
- In the case of a published work, a notice may prevent a defendant in a copyright infringement action from attempting to limit his or her liability for damages or injunctive relief based on an innocent infringement defense.
- Notice identifies the copyright owner at the time the work was first published for parties seeking permission to use the work.
- Notice identifies the year of first publication, which may be used to determine the term of copyright protection in the case of an anonymous work, a pseudonymous work, or a work made for hire.
- Notice may prevent the work from becoming an orphan work by identifying the copyright owner and specifying the term of the copyright.

That's it. That's the benefit.

I have quoted from the US Copyright Office Circular 3 because it provides a slightly more readable phrasing of the requirements than in the underlying statute. The statutory law at the federal level in the United States is codified in what is known as the United States Code, which is organized as a set of "titles." Title 17 is Copyrights. The details of copyright notices are found in sections 401–406 of that title. One can start at [17 USC 401](https://www.copyright.gov/title17/92chap4.html#401). See 17 USC 401(b) for a description of the three elements that the statute requires to be present in a copyright notice. If you want to see the details of the "Effect of Omission on Innocent Infringers," see [17 USC 405](https://www.copyright.gov/title17/92chap4.html#405)(b).

To provide more accurate information, why not clean up the copyright notices in a codebase? Awkwardly, [17 USC 506](https://www.copyright.gov/title17/92chap5.html#506)(c) (Fraudulent Copyright Notice), [17 USC 506](https://www.copyright.gov/title17/92chap5.html#506)(d) (Fraudulent Removal of Copyright Notice), and [17 USC 1202](https://www.copyright.gov/title17/92chap12.html#1202)(a) (False Copyright Management Information) provide some disincentive (even if limited to bad intent). With low value and some risk (if getting it wrong when making changes), no wonder more resources are not applied to the maintenance of copyright notices.

Some people and some companies place emphasis on putting detailed notices into code that they make available under an open source license; others do not. As open source projects develop, some contributions may include notices, and others do not. A file may include an original notice and no other notices, even though its content has changed substantially from its original version. Or a later contributor might add a notice to a file that previously had none. And what about that element of copyright notices that is the "year of first publication of the work"? What does that mean? Different people have different practices. Updated? What about when other contributions are made?

As to drawing conclusions from mining copyright notice data, be cautious. Have low expectations.

What should an open source project do?

Please, present and maintain clear, accurate **license information**.

As to **copyright notices**, it is difficult to justify investing in maintaining copyright notice details. But some people may expect notices to be present. As to the "origin of the software," perhaps it would be more useful and more accurate to simply refer to the project, rather than attempt to capture something more fine-grained. Year of publication? This is unlikely to be worth the trouble to manually maintain in source files; source management tools provide more accurate information at lower resource cost.

For more details on a practical approach, I direct your attention to an excellent reconsideration of copyright notice practice: * Copyright notices in open source software projects*, by Steve Winslow, January 10, 2020.

## Comments are closed.