原始碼即是許可證 | Linux 中國

提要：對於開源軟體來說，其許可證資訊內嵌在原始碼中。為了降低複雜性，您可以生成不同的檢視。

您可以透過檢視原始碼找到開源軟體的許可證資訊。為了滿足不同的需求，可以生成關於該許可證資訊的不同檢視或報告。

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

什麼是許可證條款？

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

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

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

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

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

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

用檢視來概括許可證資訊

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

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

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

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

您可能會嘗試建立一個“全能”概要，從中可以建立其他較短的概要。但是以中間狀態表達許可證資訊至少有三個缺點：

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

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

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

將所有許可證資訊嵌入到原始碼樹中是最佳實踐。如果您發現原始碼樹中沒有顯示許可證資訊，請考慮透過提交錯誤報告來改進該專案，建議將該資訊新增到原始碼樹中。

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

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

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

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