• 保留簡略的版權聲明即可，無需投入過多資源維護。

版權聲明(Copyright Notice)在源代碼中的應用并不一致且維護不善，結果導致它無法成為良好的信息來源。那是否應該投入更多資源來維護版權聲明呢?答案是不需要。

版權聲明是單行字符串，通常包括單詞“版權”(或某些替代詞，如 ©)、名稱(通常是個人或公司)和年份。

[[380484]]

在本文中，我不關注許可證或許可證聲明(有時可能包括版權聲明)。我關于版權聲明維護的資源投入應該保持低優先級的建議不適用于許可證信息。許可證信息應清晰呈現并保持準確。如果你邀請其他人使用你的軟件并對其進行操作，請通過提供并維護清晰的許可證信息來明確其授予的權限。

再說回版權聲明：它們的法律意義是什么呢?如果你認為版權聲明符合法律要求或至少提供了重要的法律權益，請三思。此類聲明在開源軟件中的法律意義是如此之小，以至于人們可以輕易地找到超出其法律意義的實際做法。

盡管此類聲明可能看起來很重要，但它們在當今源代碼中的存在很大程度上是過去美國版權法的殘余影響。曾經有一段時間，如果未在已出版的材料中包含版權聲明，依據美國版權法，版權人可能會完全喪失權利;當美國最終加入《伯爾尼公約》并成為締約國時，情況發生了變化(美國于 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 分析、開源軟件知識產權風險分析，致力于為互聯網企業、高科技公司提供知識產權咨詢服務。