開源項目的版權聲明已無存在必要？

版權聲明 （ 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 分析、開源軟體知識產權風險分析，致力於為互聯網企業、高科技公司提供知識產權諮詢服務。

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive