如何為您的作品選擇授權條款

人們經常詢問我們，對於他們自己的專案，我們推薦使用哪種授權條款。我們之前已經公開撰寫過關於這個主題的文章，但相關資訊分散在不同的文章、常見問題解答和授權條款評論中。本文將所有這些資訊收集到單一來源，以便人們更容易遵循和參考。

這些建議適用於旨在執行實際工作的作品。這些作品包括軟體、文件和其他一些東西。藝術作品和表達觀點的作品是不同的議題；GNU 計劃對於它們應該如何發布沒有一般立場，除了它們都應該在不使用非自由軟體的情況下可用（特別是不使用 DRM）。但是，您可能希望對於與特定程式一起使用的藝術作品遵循這些建議。

這些建議適用於授權您創作的作品——無論是對現有作品的修改，還是新的原創作品。它們不處理在不同授權條款下組合現有材料的問題。如果您正在尋找這方面的幫助，請查看我們的 GPL 常見問題解答。

在您了解我們在此處推薦的內容後，如果您需要建議，可以寫信至<licensing@gnu.org>。請注意，授權團隊可能需要幾週的時間才能回覆您；如果您一個月內沒有收到回覆，請再次寫信。

貢獻到現有專案

當您貢獻到現有專案時，您通常應該以與原始作品相同的授權條款發布您修改後的版本。與專案維護者合作是很好的，而為您的修改使用不同的授權條款通常會使這種合作非常困難。您應該僅在有充分理由證明其合理性的情況下才這樣做。

在某些情況下，使用不同的授權條款是合理的，例如當您對非著作權保護授權條款下的作品進行重大修改時。如果您建立的版本比原始版本更有用，那麼對您的作品進行著作權保護是值得的，原因與我們通常推薦著作權保護的所有原因相同。如果您處於這種情況，請遵循以下關於授權新專案的建議。

如果您因任何原因選擇以不同的授權條款發布您的貢獻，您必須確保原始授權條款允許在您選擇的授權條款下使用該材料。為了誠實起見，請明確指出作品的哪些部分在哪些授權條款下。

軟體

我們為不同的專案推薦不同的授權條款，主要取決於軟體的用途。一般來說，我們建議使用最強的著作權保護授權條款，但不要干擾該用途。我們的文章「什麼是著作權保護？」更詳細地解釋了著作權保護的概念，以及為什麼它通常是最佳的授權策略。

對於大多數程式，我們建議您為您的專案使用最新版本的GNU 通用公共授權條款 (GPL)。其強大的著作權保護適用於所有類型的軟體，並包含許多對使用者自由的保護。為了允許將來的授權條款升級，請指定「版本 3 或任何更新的版本」，以便您的程式與將來可能在後續 GPL 版本下發布的程式碼授權條款相容。

以下是關於如何根據 GNU GPL 發布程式的更多建議。

現在來看例外情況，在這些情況下，最好使用其他授權條款而不是 GNU GPL。

小型程式

對於大多數小型程式來說，使用著作權保護是不值得麻煩的。我們使用 300 行作為我們的基準：當一個軟體套件的原始碼短於此時，著作權保護帶來的好處通常太小，不足以證明確保授權條款副本始終隨附軟體的不便性是合理的。

對於這些程式，我們推薦Apache License 2.0。這是一種弱、鬆散、「容易被推翻」（非著作權保護）的軟體授權條款，其中包含防止貢獻者和發行者因專利侵權而起訴的條款。這並不能使軟體免受專利威脅（沒有軟體授權條款可以做到這一點），但它可以防止專利持有人設置「誘餌和轉換」策略，即他們以自由條款發布軟體，然後要求接收者同意專利授權中的非自由條款。

在弱（容易被推翻）的授權條款中，Apache 2.0 是最好的；因此，如果您要使用弱授權條款，無論出於何種原因，我們都建議使用該授權條款。

函式庫

對於函式庫，我們區分三種情況。

一些函式庫實作了與受限資料格式競爭的自由資料格式，例如 Ogg Vorbis（與 MP3 音訊競爭）和 WebM（與 MPEG-4 影片競爭）。自由格式的成功需要允許許多專有應用程式程式連結到程式碼中以處理該格式。例如，我們希望非自由媒體播放器，尤其是設備，包含 Ogg Vorbis 和 MP3 的程式碼。

在這些特殊情況下，如果您旨在說服專有應用程式開發人員使用函式庫來處理自由格式，您需要透過在弱授權條款（例如Apache License 2.0）下授權函式庫來簡化此操作。

然而，我們必須承認，這種策略對於 Ogg Vorbis 並未成功。即使在更改著作權授權條款以允許輕鬆地將該函式庫程式碼包含在專有應用程式中之後，專有開發人員通常也沒有包含它。在授權條款選擇上做出的犧牲最終並沒有為我們贏得多少。

對於所有其他函式庫，我們建議使用某種類型的著作權保護。如果開發人員已經在使用根據非自由授權條款或鬆散的容易被推翻的授權條款發布的已建立的替代函式庫，那麼我們建議使用GNU 寬鬆通用公共授權條款 (LGPL)。

與第一種情況（函式庫實作了道德上更優越的標準）不同，這裡僅僅為了採用而採用不會實現任何特殊的目標，因此沒有理由完全避免著作權保護。但是，如果您要求使用您的函式庫的開發人員以著作權保護發布他們的整個程式，他們只會使用可用的替代方案之一，這也不會推進我們的事業。寬鬆 GPL 旨在填補這些情況之間的空白，允許專有軟體開發人員使用受保護的函式庫，但提供弱著作權保護，讓使用者可以自由地使用函式庫程式碼本身。

對於提供專用設施且不面臨根深蒂固的非著作權保護或非自由競爭的函式庫，我們建議使用普通的 GNU GPL。關於原因，請閱讀「為什麼您不應該為您的下一個函式庫使用寬鬆 GPL。」

伺服器軟體

如果其他人很可能會製作您程式的改進版本以在伺服器上運行，並且不將其版本分發給任何人，並且您擔心這會使您發布的版本處於不利地位，我們建議使用GNU Affero 通用公共授權條款 (AGPL)。AGPL 的條款幾乎與 GPL 的條款相同；唯一的實質性區別是它有一個額外的條件，以確保透過網路使用軟體的人能夠獲得其原始碼。

AGPL 的要求並未解決使用者在將其計算或資料委託給別人的伺服器時可能出現的問題。例如，它不會阻止軟體替代服務 (SaaSS) 剝奪使用者的自由——但大多數伺服器都不執行 SaaSS。有關這些問題的更多資訊，請閱讀「為什麼是 Affero GPL。」

文件

我們建議對於教學、參考手冊和其他大型文件作品使用GNU 自由文件授權條款 (GFDL)。這是一種針對教育作品的強大著作權保護授權條款，最初是為軟體手冊編寫的，並且包含專門解決在分發或修改這些作品時出現的常見問題的條款。

對於簡短的次要文件作品，例如參考卡，最好使用GNU 全許可授權條款，因為 GFDL 的副本幾乎無法放入參考卡中。不要使用 CC BY，因為它與 GFDL 不相容。

對於 man page，如果頁面很長，我們建議使用 GFDL；如果頁面很短，則建議使用GNU 全許可授權條款。

有些文件包含軟體原始碼。例如，程式語言的手冊可能包含供讀者遵循的範例。您應該根據 FDL 的條款將這些範例包含在手冊中，並在另一個適用於軟體的授權條款下發布它們。這樣做有助於在其他專案中輕鬆使用程式碼。我們建議您使用 CC0 將小段程式碼貢獻到公共領域，並在相關軟體專案使用的相同授權條款下分發較大的程式碼段。

程式的其他資料

本節討論您可能包含在軟體中的所有其他用於實際用途的作品。舉例來說，這包括圖示和其他功能性或有用的圖形、字型和地理資料。您也可以將它們用於藝術，儘管如果您不這樣做，我們也不會批評。

如果您專門為與軟體專案一起使用而建立這些作品，我們通常建議您以與軟體相同的授權條款發布您的作品。對於我們推薦的授權條款來說，這樣做沒有問題：GPLv3、LGPLv3、AGPLv3 和 GPLv2 都可以應用於任何類型的作品——而不僅僅是軟體——這些作品是可受著作權保護的，並且具有明確的首選修改形式。使用與軟體相同的授權條款將有助於發行者更容易遵守，並避免對潛在的相容性問題產生任何疑問。如果使用不同的自由授權條款可以提供一些特定的實際好處，例如與其他自由專案更好地合作，則可能是合適的。

如果您的作品不是為與特定軟體專案一起使用而建立的，或者如果使用與該專案相同的授權條款不合適，那麼我們只建議您選擇適用於您的作品的著作權保護授權條款。我們在我們的授權條款列表中列出了一些。如果沒有特別合適的授權條款，創用 CC 姓名標示-相同方式分享授權條款是一種著作權保護，可用於許多不同類型的作品。