跳轉到內容

FOSS 許可證/如何使原始碼免費或開放

Add links
來自華夏公益教科書

根據現行法律規範，軟體受版權法保護。因此，FOSS 運動 開發了許多不同的 FOSS 許可證，使軟體開發人員能夠輕鬆宣告他們授予其使用者版權法專屬於他們的某些權利。FOSS 許可證也作為 FOSS 開發者社群之間的協議。

FOSS 許可證有很多，它們的特徵各不相同。在本入門手冊的後面部分，我們將重點關注三大許可證：GNU GPL、LGPL 和 BSD 許可證。它們不僅代表了三種截然不同的 FOSS 許可風格，而且也是應用最廣泛的許可證。[1] 表 1 幫助我們快速瞭解一般情況。[2]

表 1
被許可人/許可的義務 原始作品 衍生作品
原則上，重新發布是否應該提供原始碼？ 在沒有原始碼的情況下重新發布時，原始碼的單獨分發者是否可以收取高於實際傳輸成本的費用？ 在附帶原始碼的情況下重新發布時，分發者是否可以收取高於實際傳輸成本的費用？ 可再許可？ 衍生作品應採用與原始作品相同的許可證 原始碼是否需要公開？ 是否需要附上原始作品的版權宣告？ 是否需要提供文件？
GNU GPL v 2 是 否 是 否 是，Copyleft 是 是 是
LGPL v 2.1 是 否 是 否 基於庫的作品
是，Copyleft 是 是 是
將“使用庫的作品”與庫連結的可執行檔案
否 否 是 是
BSD 許可證 否 是 是 否 否 否 是 否
藝術許可證 是 （始終重新分發原始碼） 否 否 否 否 否 否
MIT 許可證 否 是 是 是 否 否 是 否
Apache 許可證 v 1.1 否 是 是 否 否 否 是 否
Apache 許可證 v 2.0 否 是 是 否 否 否 是 否
Mozilla 公共許可證 v 1.1 是 （始終重新分發原始碼） 是 是 是，MPL 中描述的附加權利可以包含在附加文件中 是 是 是
Zlib/libpng 許可證 否 是 是 否 否 否 否 否
QPL 是 否 是 否 QPL 要求所有修改必須以與原始作品分離的形式存在，例如修補程式（不允許人們直接修改原始作品），並使用類似於其他許可證規範衍生作品的條款來規範修補程式。Qt 公開
否 是 是 否
通用公共許可證 v 1 是 否 是 是 否 是 是 否
學術自由許可證 v 2.1 否 是 是 是 否 是 是 否
PHP 許可證 v 3.0 否 是 是 否 否 否 是 否
開放軟體許可證 v 2.1 否 是 是 是 是 是 是 是
Zope 公共許可證 v 2.0 否 是 是 否 否 否 是 是
Python 軟體基金會許可證 v 2.1.1 否 是 是 否 否 否 是 是

表 1 中列出的 FOSS 許可證 具有以下共同特徵

  • 原始作品的原始碼是公開的。
  • 允許複製原始作品。
  • 允許分發原始作品。所有分發都應附帶版權宣告。
  • 許可授予是非排他性的、全球性的、免版稅的，適用於所有目的。
  • 不提供保證。

但是，這些 FOSS 許可證 在如何行使這些權利方面彼此不同。例如，雖然始終要求作者提供訪問原始碼的途徑，但重新發布者是否也需要提供此類訪問途徑，則因許可證而異。例如，在重新發布 BSD 許可的程式時，不需要提供原始碼。

即使對於要求重新發布者提供原始碼的許可證，對重新發布者可以收取的分發費也有不同的規定。GNU GPL 和 LGPL 對何時可以收取高於實際傳輸費的費用特別詳細。這是因為 GNU GPL 和 LGPL 為重新發布者提供了多種方法來分發程式，無論是否附帶原始碼，同時確保重新發布仍然是自由軟體。個人可以以任何她想要的價錢出售自由軟體，因為市場會幫助將價格保持在合理範圍內。但如果一個軟體包在沒有原始碼的情況下出售，那麼為原始碼本身分發收取的費用不能超過實際傳輸成本。

關於衍生作品的條款差異很大。雖然訪問原始作品的原始碼是必需的，但訪問衍生作品的原始碼可能不是必需的。即使 FOSS 許可證要求衍生作品的原始碼公開，它也可能不要求它們在與原始作品完全相同的許可證下許可。例如，雖然 GPL 許可的程式的衍生作品也必須在 GNU GPL 下獲得許可，但 BSD 許可的程式的衍生作品不必在 BSD 許可證下獲得許可。事實上，BSD 許可的程式的衍生作品甚至不必與原始碼一起分發。

FOSS 許可證在是否允許將 FOSS 程式與專有程式組合方面也有所不同。當將不同的程式組合成一個更大的專案時，不可避免的是，這個更大的專案，雖然包含了所有或部分組合程式的原始碼，但變成了所有組合程式的衍生作品。例如，專案 ABC 與 GPL 許可的程式 A、BSD 程式 B 和專有程式 C 相結合，幷包含來自所有三個程式的原始碼。作為程式 B 的衍生作品，專案 ABC 不需要在 BSD 許可證下獲得許可，甚至不需要公開其原始碼。但是，作為程式 A 的衍生作品，專案 ABC 需要在 GNU GPL 下獲得許可。

因此，開發人員別無選擇，只能在 GNU GPL 下許可整個專案 ABC，或者找到程式 A 的替代方案，特別是如果她希望將其作為專有軟體專案。

這就是為什麼專有公司認為 GNU GPL 具有所謂的“病毒”效應，並且被認為對專有軟體開發模式不友好。但 GNU GPL 的設計是為了服務於自由軟體社群的利益，而不是專有商業部門的利益。FSF 還設計了 LGPL，以鼓勵在專有軟體專案中更多地使用自由庫。

以下是三種典型的 FOSS 許可證 - GNU GPL、LGPL 和 BSD - 的進一步解釋。

GNU 通用公共許可證

[編輯 | 編輯原始碼]

GNU GPL 是經典的 自由軟體許可證。它也是所有 FOSS 許可證中最知名和使用最廣泛的。GNU GPL 是為了實現 自由軟體運動 定義的自由而開發的。它不僅僅是一個許可證，也是該運動背後基本理念的表達。

版權共享

[編輯 | 編輯原始碼]
理念
GNU GPL 保證自由的方式也被稱為“版權共享”。傳統的專有模式說“版權所有，保留所有權利”，而 GNU GPL 則說“版權共享，所有權利反轉”。版權共享不僅是關於在版權持有人釋出時使原始作品免費，而且是關於在進一步分發和修改時保持其免費。雖然建立僅供內部使用衍生作品沒有限制，但在將其分發給公眾時，會應用版權共享以確保衍生作品與原始作品一樣免費。
工作原理
版權共享防止 自由軟體 變成 專有軟體。它利用版權法來實現與其通常目的完全相反的目的。版權共享許可證不是私有化軟體的手段，而是將授予作者的權利反轉以保持軟體免費。[3]

與 公共領域 中每個人都可以自由利用的作品不同，GPL 受許可的作品或版權共享作品受版權保護。GPL 受許可作品的作者不會放棄其作為版權持有人的權利，但會以不同於傳統版權持有人的方式行使這些權利。

如果想要使軟體免費的作者只是放棄他們作為版權持有人的權利並將他們的作品釋出到公共領域，這將使作品面臨被私有化和再次封閉的風險。相反，為了保持他們的作品及其衍生作品的自由，作者必須申明他們的權利，並以授予他們的獨佔權利，他們包括版權共享條款以規範其他人使用其作品的方式。透過在 GNU GPL 下許可他們的作品，作者允許使用者擁有 自由軟體運動 規定的權利。

同樣，透過在 GNU GPL 下許可，作者要求希望分發該程式的人員以及希望修改該作品並分發修改後的作品的開發人員承擔一些責任，以保持衍生作品與原始作品一樣免費。

GNU GPL 的主要條款和條件

[編輯 | 編輯原始碼]
使用者的自由
當某個程式在 GNU GPL 下獲得許可時，除了訪問原始碼的自由之外，使用者還可以自由地
  1. 執行程式（第 0 節）。
  2. 複製程式（第 1 節）。
  3. 重新分發程式，即使用於商業目的，只要保留適當的版權宣告和免責宣告（第 1 節）。只要所有接收者都能獲得 原始碼，以目的碼或可執行形式重新分發也是可能的（第 3 節）。
  4. 準備和分發程式的衍生作品，只要衍生作品也在 GNU GPL 下獲得所有第三方的許可（第 2 節）。
無擔保
雖然作品的分發可以是商業性的，但作品本身是免費許可的。因此，GPL 受許可的軟體沒有擔保（第 11、12 節）。分發者可以選擇以收費的方式提供擔保保護（第 1 節）。
直接來自作者的許可證
該作品不可再許可。當程式被重新分發時，接收者仍然從原始許可方那裡獲得許可。重新分發者不得對接收者在 GNU GPL 中授予的權利行使施加任何進一步的限制（第 6 節）。
接受和終止
透過修改或分發 GPL 受許可的程式，一個人表明他接受許可（第 5 節）。許可授予是不可撤銷的，但當被許可人違反許可時，授予的權利將自動終止。但是，從她那裡收到程式副本的人員的權利不受影響（因為他們從原始許可方那裡獲得了許可），只要他們完全遵守許可（第 4 節）。
與其他法律義務共存？
GNU GPL 不承認對接收者施加的任何矛盾條件。如果由於法院判決、專利侵權指控或任何其他原因導致無法遵守許可，那麼接收者可能根本無法重新分發該程式（第 7 節）。GPL 受許可的程式不能合併到專有程式中，也不能與專有庫連結。

完整的 GNU GPL 文字可以在 http://www.fsf.org/licenses/gpl.txt 找到。

FSF 還維護了一個關於 GNU GPL 的全面常見問題解答，可以訪問 http://www.gnu.org/licenses/gpl-faq.html。

GNU 小通用公共許可證

[編輯 | 編輯原始碼]

除了 GNU GPL 之外，FSF 還為庫提供了一個特殊的版權共享許可證。GNU 小通用公共許可證 (LGPL) 允許 LGPL 受許可的庫與專有軟體連結。

此例外是用來服務不同的情況。鼓勵在 GNU 系統上開發專有應用程式可能是一個戰略決策。[4] 對於一個其功能可能被其他專有庫所取代的自由庫，在 LGPL 而不是 GNU GPL 下發布它可以鼓勵更廣泛的使用，[5] 因此可以使更多改進成為可能。隨著更大的自由軟體使用者群，對自由軟體的總體支援也會更廣泛。[6]

但是，FSF 仍然鼓勵人們對他們的庫使用 GNU GPL 而不是 LGPL，特別是對於那些具有大量獨特功能的庫。這是因為那些有興趣利用此類 GPL 受許可的庫的人將不得不將他們的模組也釋出為 GPL 受許可的軟體，從而導致更多有用的模組和程式在自由軟體環境中可用。[7]

LGPL 的主要條款和條件

[編輯 | 編輯原始碼]

LGPL 在許多方面與 GNU GPL 相同，包括免責宣告、宣告許可證直接由作者頒發以及指定何時應用和終止許可的條款。此外，對使用者適用的其他法律義務與 GNU GPL 相同。

在使用者權利方面，LGPL 區分了使用庫時兩種不同的情況。 “基於庫的作品” 指的是庫本身或版權法下的任何衍生作品（第 0 節），而“使用庫的作品” 指的是不包含庫任何部分的衍生作品，但被設計為透過編譯或連結與庫一起工作的程式（第 5 節）。

基於庫的作品
在“使用庫的作品” 的情況下，即庫本身及其衍生作品，其條款與 GNU GPL 中的條款非常相似。
  • 使用者的自由
    1. 執行程式（第 0 節）。
    2. 複製程式（第 1 節）。
    3. 重新發布程式，即使是為了商業目的，只要保留適當的版權宣告和免責宣告（第 1 節）。 只要所有接收者都可以獲得原始碼，也可以重新發布物件程式碼或可執行檔案形式（第 4 節）。
    4. 準備並分發程式的衍生作品，前提是衍生作品也根據 LGPL 授權給所有第三方（第 2c 節）。
    此外，可以選擇將 GNU GPL 的條款應用於 LGPL 授權庫的給定副本，特別是在將部分程式碼合併到不是庫的程式中時（第 3 節）。
使用庫的作品
在“使用庫的作品” 的情況下，作品本身不受 LGPL 約束。 但當將“使用庫的作品” 與庫連結時，會建立庫的衍生作品的可執行版本，此版本受 LGPL 約束（第 5 節）。

儘管 LGPL 允許作者分發可執行檔案的物件程式碼（第 5 節）並在他們選擇的條款下對其進行許可，但也要求這些條款允許客戶修改作品以供自身使用並進行反向工程。 在分發可執行檔案時，作者可以選擇將庫一起分發，前提是庫的原始碼以類似於分發 GPL 授權 程式的方式提供，或者不將庫一起分發，而僅使用合適的共享庫機制與庫進行連結（第 6 節）。

透過建立此類別，LGPL 為 LGPL 授權庫在專有程式中的使用提供了一種方式。 完整的 LGPL 文字可以在 http://www.fsf.org/licenses/lgpl.txt 找到。

BSD 風格許可

[edit | edit source]

伯克利軟體發行版 (BSD) 許可 最初用於 伯克利軟體發行版，這是一個在加州大學伯克利分校開發的 Unix 版本。[8] 透過更改版權宣告和許可證中出現的擁有者、組織和年份的值，很容易遵循 BSD 許可模板來建立自己的許可證。 與 GNU GPL 和 LGPL 不同，BSD 風格許可不是複製許可。 BSD 許可允許人們自由分發和修改原始作品，但不要求修改後的作品與原始作品一樣自由。 BSD 風格許可證相對簡單，對軟體的使用僅有限制。

  • 使用者的自由
    1. 複製並重新發布程式，包括其原始碼或二進位制程式碼。 發行商沒有義務提供原始碼。
    2. 準備並分發衍生作品，包括其原始碼或二進位制程式碼。 作者可以自由地為衍生作品選擇 FOSS 或專有許可證。
    3. 將程式合併到專有軟體中。

原始 BSD 許可證（四條款 BSD）有一個廣告條款。 修訂後的 BSD 許可證（三條款 BSD）與 MIT 許可證 非常相似，但後者沒有“對衍生作品不予認可” 的條款。 還有兩條款 BSD，它去掉了認可條款，與 MIT 許可證最相似。[9]

多重許可

[edit | edit source]

需要注意的是，一項作品可以根據多個許可證進行授權。 許可證的選擇反映了作者希望與受版權作品的使用者之間建立的聯絡型別。 由於可能存在多種使用者，以及多種可能的聯絡方式，版權持有者有權為不同情況選擇不同型別的許可證。

以 OpenOffice 為例。 OpenOffice 根據 GNU GPL 和 Sun Industrial Standards Source License (SISSL) 進行雙重授權。 雖然 OpenOffice 明確指出鼓勵使用者使用 GNU GPL 充分參與 OpenOffice 社群，但 SISSL 作為無法使用 GNU GPL 的開發人員和公司的替代方案提供。[10] ,[11] MySQL 是另一個例子。 MySQL 提供 GNU GPL 和商業許可證。 不想在 GNU GPL 下發布其應用程式的組織可以選擇在 MySQL 商業許可證下使用 MySQL。[12]

文件怎麼樣？

[edit | edit source]

GNU 自由文件許可證 (GNU FDL)

[edit | edit source]

良好的文件和手冊對於 FOSS 程式非常重要。 如果它們沒有被授權為免費/開放，人們很難充分利用相關的 FOSS 程式。

雖然 GNU GPL 主要為軟體設計的許可證，但它也可以用於非軟體作品，只要在採用許可證時明確定義了“原始碼”。[13] FSF 還提供專門為文件設計的許可證。 GNU 自由文件許可證 (GNU FDL 或 FDL) 是一種用於手冊、教科書或其他文件的複製許可證，它賦予每個人複製和重新發布文件的自由，無論是否修改，無論是商業的還是非商業的。[14]

透過將 GNU FDL 應用於文件，作者授予使用者製作作品的逐字副本、修改作品以及分發修改後的作品的權利。 由於它是一種 複製許可，因此它要求複製和分發 FDL 授權作品的修改也根據 FDL 授權。

知識共享許可證

[edit | edit source]
表 2
需要署名 允許商業用途 允許衍生作品 衍生作品應根據與原始作品相同的許可證授權
CC BY 是 是 是 否
CC BY-NC 是 否 是 否
CC BY-NC-ND 是 否 否
CC BY-NC-SA 是 否 是 是
CC BY-ND 是 是 否
CC BY-SA 是 是 是 是
CC NC • 否 否 是 否
CC NC-ND • 否 否 否
CC NC-SA • 否 否 是 是
CC ND • 否 是 否 否
CC SA • 否 是 是 是
GNU FDL 是 是 是 是

BY: 署名。 對於任何重新使用和分發，都需要註明原始作者的署名。

NC: 非商業性。 該作品不能用於商業目的。

ND: 禁止衍生作品。 該作品不能被修改或改編； 禁止基於該作品建立的衍生作品。

SA：署名-相同方式共享。只要結果作品是在與本許可證相同的許可證下授權的，就可以更改和轉換作品，並準備作品的衍生作品。

• 從 2004 年開始，知識共享在第二個版本中將“署名”要求設為預設值。因此，在第二個版本中，只有上面列出的前六個 CC 許可證仍然存在。

受 FOSS 開發的啟發，知識共享 提倡數字內容的開放，並敦促在越來越嚴格的預設規則面前，建立更合理、更靈活的版權層級。[15]

在 2002 年，知識共享公共許可證（CC 許可證）的第一個版本釋出。透過識別作者的主要關切——即是否需要署名（署名，BY），是否允許使用者進行商業用途（非商業，NC），是否允許使用者製作衍生作品（無衍生作品，ND），以及何時允許製作衍生作品，是否要求它們以與原始作品完全相同的許可證授權（相同方式共享，SA）——知識共享 開發了 11 種不同的 CC 許可證。每種許可證都代表上述四個條件的獨特組合。作者可以自由選擇這 11 種許可證中的任何一種，並決定哪一種最適合他們的需求和作品。

在 2004 年，知識共享 釋出了 CC 許可證的第二個版本。由於署名要求已得到 CC 許可證使用者的廣泛採用，署名要求已成為預設值，因此第二個版本中只有六種 CC 許可證。然而，第一個版本的 11 種許可證並沒有被取代，仍然可以使用（表 2）。[16]

CC 許可證 專為除軟體以外的所有型別的數字內容而設計，包括藝術作品、照片、音樂和文學文字。CC 許可證不涉及 FOSS 問題，因為所指作品中的思想是透明的，並且不會被編譯成無法感知的形式。一些 CC 許可證不允許修改或盈利性使用，可能不被視為“免費”。但是，CC 許可證在將自由和開放的理念傳播給更廣大公眾方面取得了成功，而這些公眾可能不熟悉 FOSS 運動促成的最新軟體發展。

腳註

[edit | edit source]
檢索自 "https://wikibook.tw/w/index.php?title=FOSS_Licensing/How_to_Make_the_Source_Free_or_Open&oldid=4227823"
華夏公益教科書