開源軟體許可出毛病了？

對於讓開源軟體變得如此出色的協作開發來說，開源軟體許可以其不同於常規軟體許可的方式提供了諸多支援。

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

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

如果只是說開源軟體可以“協作”開發，那還沒有弄清楚開源開發活動與常規許可軟體之間可能存在的差別程度。儘管有像常規許可軟體一樣由一個人或一個固定的小團體來維護的開源專案，但是在開源專案上的協作可能會在廣泛的潛在貢獻者之間進行。例如，根據 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 中國”官方小程式來檢視