開源軟體許可出毛病了？

人們在使用常規軟體許可時產生的實踐和期望，也許會讓他們在面對開源軟體時感到沮喪。「請給我看下許可證」這種簡單的要求，可能得不到令人滿意的答覆。儘管有的時候這種答覆非常簡單，但開源軟體的許可信息通常更為複雜，達不到常規軟體許可所設定的那種期望。

這是怎麼回事兒呢？開源軟體許可是否出毛病了？然而並沒有。許可條款類型以及軟體開發方式的差異，都會導致軟體許可信息的傳送方式不同。律師便利性和開發人員便利性之間的折衷是造成這種狀況的部分原因。

如果只是說開源軟體可以「協作」開發，那還沒有弄清楚開源開發活動與常規許可軟體之間可能存在的差別程度。儘管有像常規許可軟體一樣由一個人或一個固定的小團體來維護的開源項目，但是在開源項目上的協作可能會在廣泛的潛在貢獻者之間進行。例如，根據 GitHub 的「2019 年 Octoverse 報告」 ，有超過 35 萬人對前 1000 個項目做出了貢獻。但是，開源軟體開發與常規許可軟體開發的不同之處不僅僅是貢獻者數量。除了被發現對該開源項目擁有某些共同興趣，為開源項目做出貢獻的人們之間可能沒有任何聯繫。人們的參與情況可能會隨著時間的推移而變化。原始開發人員可能會離開，留下其他人繼續進行項目開發。所有這一切都可能在沒有規劃或總體治理組織的情況下發生。

除了遵循規範性的治理規則，開源協作活動還是輕量級的，而且可以比常規許可軟體更加靈敏地響應。有關開源許可信息的實踐與這種協作開發方式相適應。

1. 針對二進位文件以及源代碼，開源許可中的條款通過提供所需的許可權（包括複製、修改和分發）促進了協作開發。事實證明， 「開源定義」 （ Open Source Definition ） （OSD）有助於將注意力集中在滿足其要求的許可上。
2. 開源軟體的許可信息嵌入在源代碼中。當獲得源代碼時，就會接收到相應的許可信息。想像一下每年以百萬計的貢獻規模，單獨的許可管理是否完全可行呢？同樣，通過將許可信息嵌入源代碼中，可以反映與許可相關的詳細信息，而這些細節在某些單獨管理的許可流程中不可行。例如，將許可信息嵌入源代碼，使得指示哪些許可條款適用於軟體的哪些部分變得切實可行。

為了說明開源許可實踐所能實現的效果，請考慮以下示例性軟體項目：

該項目始於 5 年前；到目前為止，已有 50 位貢獻者做出了貢獻；通過改編其他項目中的部分軟體，增加了一些功能；原始代碼的開發者在三年後離開；幾家商業企業已經在其內部或一部分產品中依賴該軟體；如果考慮到其他軟體和計算機世界方面相關的變化，則該軟體未來可能還會有 5-10 年的發展。

在開源項目中現有和常用的表示許可信息的方法，很容易適應這樣一個項目的過程。沒有預先規劃，貢獻者可以從項目中來來去去；項目的各個部分遵循不同的許可條款；如果與其他公司的合作破裂，商業企業可以繼續以很少的管理開銷成本分擔軟體維護工作，同時保持完全獨立開發其軟體分支的能力。

相反，傳統的軟體許可方法將如何支持這種開發呢？甚至這樣的合作有可能發生嗎？我們是否將擁有一個完整的許可基礎結構來跟蹤數千個「主軟體開發和分發協議」的適用性？我們是否要通過讓某些公司控制一切來簡化許可？

讓我們回到「是什麼許可？」這個問題。我談論開源開發特徵的目的，是說明存在重要的影響開源許可信息如何表示的非法律因素。開源軟體中許可信息的表示形式通常不符合常規軟體許可的期望。但是，存在差異並不代表系統出毛病了。相反，對於支持過去二十年中已被證明有效的大規模協作開發這種軟體構建方法來說，差異的作用非常強大。

開源許可信息是什麼樣的呢？

通常，人們會考慮每個「軟體組件」的許可條款。軟體組件可能作為應用程序對用戶可見，或者對於用戶來說可能不那麼明顯，例如與大型程序結合使用時可提供某些功能的庫。

對於許多軟體組件而言，許可很簡單：組件中的所有軟體適用數十種最常見的開源許可證中的一種。除了最常見的許可證之外，還有很多文本有所變動的不經常使用的許可證。但是，在「開源定義」的指導下，開源許可條款中的許可權和限制仍保持在一定範圍內。

如果要進行將開源軟體集成到其他軟體中的軟體開發，那麼你需要了解適用於所集成軟體的所有 「左版」 （ Copyleft ） 條款（例如著名的 GPL 系列許可證）。

由於從我對開源軟體開發方式的討論中揭示的顯而易見的原因，許可信息可能比單個許可證更為複雜。

1. 儘管一個軟體組件可能有一個主要的「項目許可」，但可能有一部分軟體遵循其他許可證。這可能會導致在源代碼的各個部分中出現不同的許可聲明。
2. 一些項目的做法是在每個源文件中放置版權聲明。其他項目主要依靠放置包含許可文本的一個或多個文件。
3. 版權聲明指示誰可能是該軟體部分的版權擁有者（但是，鑒於版權聲明實踐的多樣性，該指示的作用可能微不足道）。
4. 用來構建軟體組件的源代碼可以包括未反映在所得組件中的軟體，例如與測試或構建相關的文件。這對於使用無 GPL 規則（項目中可能包含遵循 GPL 許可證的文件，但用於生成可執行程序的文件不得包含遵循GPL許可證的文件）的人可能很重要。

因為許多細節都與某些許可信息涉及的軟體部分有關，這種細粒度的許可信息在源代碼中最有效地進行了傳達。在最詳細的級別上，源代碼即許可證。當許可信息在源代碼中時，可以用與源代碼相同的方式（例如在版本控制系統中）來維護該許可信息，並且該信息固有地可用於獲得源代碼的任何人。

從源代碼中提取許可信息並創建許可條款概要似乎很簡單。但是，對於一個人或一個公司來說足夠了的摘要，可能對於另一個人或公司是不足的。不同的人可能關注不同的許可信息細節。一些人可能想確切地知道該軟體的哪些組件遵循「左版」條款。其他人可能並不關心所有組件的許可條款概要。還有的人可能需要包括每個不同的版權聲明在內的所有許可聲明。

你想查看哪些許可信息的細節呢？在軟體開發中有大量的工具可以使用。掃描、提取和報告現有許可信息的工具是持續開發的活躍主題。現在，「是什麼許可？」可能會改寫為「向我顯示許可信息報告」，該報告可能包括一系列程度不同的詳細信息，具體取決於對請求報告的人的重要性。在最詳細的級別上，源代碼即許可證。

因為軟體可以採用不同的方式構建出來，常規軟體許可和開源軟體許可分別適用於不同的領域。兩者之間可能存在差異，對於這一點要做好準備。

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

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

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