源代碼即是許可證

您可以通過查看源代碼找到開源軟體的許可證信息。為了滿足不同的需求，可以生成關於該許可證信息的不同視圖或報告。

儘管直接在源代碼中提供許可證信息並不是開源軟體的必要條件，但是這樣做的實際好處顯而易見。由於開源許可證促進了軟體的傳播，與代碼一起傳輸的許可證信息簡化了管理過程，即使代碼接收人通過間接方式獲得代碼，也可以使他隨時可以獲得許可權聲明。

什麼是許可證條款？

在源碼樹中嵌入許可證信息的價值被低估了。讓我們暫停一下，反思一下這種常見做法是多麼有用。

什麼是許可證條款呢？ 對於許多開源軟體來說，有一個簡單的答案：一個許可證文本包含整個軟體的所有許可證信息。但是開源的力量在於，它推動了其他開發者在這個起點之上進行構建，而這個過程會使許可證信息複雜化。

開源軟體可以被擴展、再利用，或者與其他軟體結合使用。與機械設備不同，不同群體之間的合作更具挑戰性，複雜軟體從許多人的工作中受益是切實可行的。開源許可證提供了促進這種開發動態的許可權。具有複雜歷史的軟體也可能具有複雜的許可證信息。

考慮下面的例子：有人寫了一個新的程序，在每個源文件中包含一個版權聲明，聲明該軟體根據 Apache 2.0 版許可證進行許可，並且在源碼樹的根目錄中包含 Apache 許可證文本。之後，添加了一個具有不同的版權聲明的文件，以及一個 BSD 2 句版許可證副本的文件。然後，添加了一個新的子目錄，其中文件具有 Apache 許可證聲明，但具有標識不同版權所有者的版權聲明。再之後，一個 MIT 許可證的副本添加到了新的子目錄中，該子目錄包含了版權聲明與 MIT 許可證文件中相同的文件，但沒有任何其他許可證指示信息。

這個例子表明，嵌入在源碼樹中的許可證信息可能很複雜而且很詳細。根目錄和/或各個子目錄中都可能有許可證文本。一些源文件可能有許可證通知；其他源文件可能不會有。也許會有版權聲明來識別各種版權所有者。但是，在不丟失信息的前提下將法律文本從代碼中分離出來似乎是不可能的。因此，源代碼即是許可證。

從源碼樹的角度來看，上面例子中對許可證信息的解釋是非常簡單的。但是，要在簡單、明確的獨立聲明中獲取許可證信息將是一件困難的事情。截取了源代碼中所有許可證信息的許可證聲明會比源代碼更短，但這將是不方便的——誰會希望得到如此高度詳細的單獨聲明？大多數用戶可能會更喜歡一個概要，雖然不完整，但其獲取的關鍵點符合自己的特定意圖和敏感性要求。

用視圖來概括許可證信息

對於「許可證條款是什麼」這個問題，用整個源碼樹副本來回答可能沒什麼用，因為它過於龐雜和分散。大多數人只想要一個概要。但這面臨一個挑戰：當許可證信息比較複雜時，人們需要不同的概要，因為他們對於什麼是重要的有不同的定義。

對於某些人來說，對以下問題回答「是」可能是足夠的：該軟體 1）是否根據一個或多個開源許可證獲得許可，2）其被組裝和許可後是否使得其分發和使用與所有這些許可證一致？ 其他人可能需要所有許可證的列表，或者他們可能想要查看哪個軟體組件對應於哪個許可證。還有一些人可能想要一個逐個組件的列表來標識任何 左版 （ copyleft ） 許可證（也許自己要做深入的左版合規研究）。 有些人可能有興趣看到所有版權聲明和軟體組件的相關列表。

單一的概要可能不會滿足所有人的利益。簡單地將概要具體化可能會減少它對一些人的效用，而對其他人則顯得不足。因此，需要將源代碼中包含的許可證信息展現為不同的 「視圖」 （ views ） 。這裡使用的「視圖」術語可以視為與在資料庫中使用它相似。或者，您也可以將「視圖」看作是 「報告」 （ reports ） 。

考慮將源代碼作為許可證有一個優勢，並且可以從中提取多個不同的視圖。

您可能會嘗試創建一個「全能」概要，從中可以創建其他較短的概要。但是以中間狀態表達許可證信息至少有三個缺點：

1. 時機：主概要的維護人員可能無法按計划進行更新。
2. 版本：主概要可能基於與您使用的軟體不同的版本。
3. 質量：您的視圖繼承了主概要的錯誤和評判性。

因此，根據需要直接從您使用的源碼樹版本生成您的首選視圖是有價值的。

有工具可以生成視圖。按需視圖的生成取決於工具。許可證信息展示的清晰（或混亂）程度會促進（或妨礙）該工具的功效。我們不需要許可證信息的特定機器編碼，但是我們應該充分利用眾多經驗來源，以既可以被人讀取，也可以被機器提取的方式來表達信息。

Jeff Kaufman 在他的文章《開源軟體許可證合規的經濟高效模型》中指出：由於源代碼包含許可證信息，因此分發源代碼是滿足某些許可證要求的有效方式。

將所有許可證信息嵌入到源碼樹中是最佳實踐。如果您發現源碼樹中沒有顯示許可證信息，請考慮通過提交錯誤報告來改進該項目，建議將該信息添加到源碼樹中。

源代碼即是許可證。從完整的記錄中，可以生成許可證信息的視圖。工具可以將許可證信息提取到各種報告中，以滿足特定需求或敏感性要求。

為了獲得這個願景的全部好處，我們還有工作要做。您對工具狀態以及許可證信息展現有什麼看法呢？

作者簡介：Scott Peterson 是紅帽公司法律團隊成員。很久以前，一位工程師就一個叫做 GPL 的奇怪文件向 Scott 徵詢法律建議，這個致命的問題讓 Scott 走上了探索包括技術標準和開源軟體在內的協同開發法律問題的糾結之路。

譯者簡介：薛亮，集慧智佳知識產權諮詢公司高級諮詢師，擅長專利檢索、專利分析、競爭對手跟蹤、FTO分析、開源軟體知識產權風險分析，致力於為互聯網企業、高科技公司提供知識產權諮詢服務。

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