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

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

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

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

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

針對二進制文件以及源代碼，開源許可中的條款通過提供所需的權限(包括復制、修改和分發)促進了協作開發。事實證明，“開源定義”(Open Source Definition)(OSD)有助于將注意力集中在滿足其要求的許可上。

開源軟件的許可信息嵌入在源代碼中。當獲得源代碼時，就會接收到相應的許可信息。想象一下每年以百萬計的貢獻規模，單獨的許可管理是否完全可行呢?同樣，通過將許可信息嵌入源代碼中，可以反映與許可相關的詳細信息，而這些細節在某些單獨管理的許可流程中不可行。例如，將許可信息嵌入源代碼，使得指示哪些許可條款適用于軟件的哪些部分變得切實可行。

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

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

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

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

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

開源許可信息是什么樣的呢?

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

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

如果要進行將開源軟件集成到其他軟件中的軟件開發，那么你需要了解適用于所集成軟件的所有“左版”(Copyleft)條款(例如著名的 GPL 系列許可證)。

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

盡管一個軟件組件可能有一個主要的“項目許可”，但可能有一部分軟件遵循其他許可證。這可能會導致在源代碼的各個部分中出現不同的許可聲明。

一些項目的做法是在每個源文件中放置版權聲明。其他項目主要依靠放置包含許可文本的一個或多個文件。

版權聲明指示誰可能是該軟件部分的版權擁有者(但是，鑒于版權聲明實踐的多樣性，該指示的作用可能微不足道)。

用來構建軟件組件的源代碼可以包括未反映在所得組件中的軟件，例如與測試或構建相關的文件。這對于使用無 GPL 規則(項目中可能包含遵循 GPL 許可證的文件，但用于生成可執行程序的文件不得包含遵循GPL許可證的文件)的人可能很重要。

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

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

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

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

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

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