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

要得知特定的授權條款是否自由，請見我們的授權條款頁面與自由軟體的定義。

前言

人們經常要求我們建議他們的專案使用什麼授權條款。我們之前已對類似的議題公開發表過意見，但是資訊分佈在不同的文章、FAQ 與授權評論中。這篇文章蒐集了所有資訊到單一篇文章中，讓人們更容易追蹤與引用。

這些建議適用於設計用來進行實用性質的作品。包含了軟體、文件與其他東西。藝術作品與陳述觀點的作品是不同的議題；GNU 專案並沒有對它們應該如何發行有一般性的立場，只認為它們應該在沒有「非自由軟體」的情況下也要可以使用（特別是在無 DRM 的情況下）。不過，對於與某個程式一起使用的藝術作品，你可能會想要遵循以下的建議。

這些建議適用於對你建立的作品進行授權（不管是對既有作品的修改，或是新的原創作品都一樣）。它們無法解決混合已有不同授權條款作品的問題。如果你正在尋求這方面的協助，請檢查我們的 GPL FAQ。

讀完我們的建議後，如果你想要其他的建議，你可以寫信到<[email protected]>。請注意，授權條款的團隊可能需要幾週的時間才能回覆你，如果你沒有在一個月內收到回應，請再寫一封電子郵件。

貢獻給既有的專案

當你為既有的專案提供協助時，你應該使用與原始作品相同的授權條款發行你的修改。與專案的維護者合作是很好的選擇，而使用不同的授權條款則通常會讓合作變困難。要選擇不同的授權應該要有充份的理由。

當你對非「著作傳」式授權條款的作品進行重大變更時，使用不同的授權條款可能會是一個好選擇。特別是你的版本可能比原始版本更有用時，此時就非常值得讓你的作品「著作傳化」，正如我們通常建議著作傳的理由那樣。如果你遇到這種情況，請按照以下對新專案進行授權的建議。

如果你選擇以不同的授權條款發行你的貢獻，不管是什麼理由，你都必須確保原始的授權條款允許使用你所選授權條款下的素材。誠實起見，請明確指示作品的哪個部份適用哪個授權條款。

軟體

我們建議不同的專案使用不同的授權條款，主要取決於軟體的用途。一般來說，我們建議使用不會干擾用途的最強著作傳授權條款。我們的文章《著作傳是什麼？》對著作傳的概念有更詳細的解釋，以及為什麼它通常會是最佳的授權條款方案。

對於大多數的程式來說，我們建議你使用最新版的 GNU 通用公眾授權（GNU General Public License, GPL）。它嚴格的著作傳特性適用於各種軟體，並包含了各種對使用者自由的保護。如果要讓軟體授權未來可以升級至 GPL 的未來版本，請指明「第三版或任何後續版本」，如此一來，您的程式就能在未來與後續的 GPL 版本授權的程式碼授權相容。

這裡是關於如何以 GNU GPL 發行軟體的更多建議。

再來是例外，以下情況最好是用其他授權條款而非 GNU GPL。

小程式

在大多數的小程式中使用著作傳式的授權並不值得。我們使用 300 行程式碼作為基準點：當軟體的原始碼比這個短，著作傳式授權提供的好處跟「授權條款的副本必須與軟體一起提供」的麻煩相較，顯得有些不划算。

對這些程式來說，我們建議使用 Apache 授權條款 2.0。這是一個寬鬆、放任的、「聽從」式（非著作傳）軟體授權條款，其中包含了避免貢獻者與散布者因專利侵權而遭遇訴訟的條款。這無法讓軟體免除專利的威脅（從法律上軟體授權沒辦法辦到），但它確實避免了專利持有者「上鉤後掉包」的作法，也就是先以自由授權條款發行軟體，但接著要求對方同意專利授權條款中的非自由條款。

在寬鬆的（聽從式）授權條款之中，Apache 2.0 是最佳選擇。所以假如您要使用寬鬆的授權條款，無論出於什麼原因，我們都建議使用這個授權條款。

函式庫

對於函式庫來說，我們區分了三種狀況。

某些函式庫實作了和限制型資料格式競爭的自由資料格式，例如 Ogg Vorbis（與 MP3 音訊競爭）以及 WebM（與 MPEG-4 視訊競爭）。自由格式的成功，有賴於讓更多專有應用程式連結對應的程式碼來處理該格式。舉例來說，我們曾希望非自由的媒體播放器，特別是應用程式，除了 MP3 以外也能納入 Ogg Vorbis 的程式碼。

在這類特殊情況下，如果你打算說服專有應用程式開發者使用自由格式的函式庫，就需要讓函式庫採用寬鬆的授權才會讓事情變得簡單，例如用 Apache Licence 2.0。

然而，我們必須承認這項策略對於 Ogg Vorbis 來說並未成功。即便更改了著作的授權條款，期望讓專有應用程式能更輕鬆納入函式庫的程式碼，結果專有開發者一般還是不會收錄。這項選擇授權條款上的犧牲，幾乎沒讓我們有什麼收穫。

至於其他類型的函式庫，我們建議採用某種程度的著作傳。如果有一些採非自由授權，或是放任聽從式授權條款的其他函式庫已經廣為開發者使用，那麼我們建議您的作品採用 GNU 寬鬆式通用公眾授權 (GNU Lesser General Public License, LGPL)。

在第一種情況下，函式庫在道德上實現了更高超的標準；而其他採用寬鬆授權的情況下，客觀來看函式庫本身的廣泛使用並沒有達到任何特殊的好處，此時也就沒有任何理由避免使用著作傳式授權條款了。不過，你如果要求使用函式庫的開發者，只因為用到函式庫就必須將整個程式以著作傳方式發行，那他們只會換用另一個函式庫，這對我們的目標也沒有幫助。LGPL 就是設計用於這類中間地帶的授權條款，允許專有軟體開發者使用這類授權的函式庫，但又提供使用者關於函式庫本身較寬鬆的著作傳。

對於提供專業用途的函式庫，而且並未面對根深蒂固的非著作傳或非自由競爭者，我們建議使用一般的 GNU GPL。至於為什麼，請閱讀《為什麼你不應該為你的下一個函式庫使用 LGPL》。

伺服器軟體

如果其他人可能會將你的程式的改進版本在伺服器上執行，而不將他們的版本散布給其他人，而且你擔心這會讓你的版本處於不利的地位，我們建議你使用 AGPL。AGPL 的條款幾乎與 GPL 相同，唯一的差別是它有一個額外的條件，那就是確保透過網路使用軟體的人也可以取得原始碼。

AGPL 的要求並未解決 使用者 將其計算或其資料，委託給他方伺服器處理時可能發生的問題。舉例來說，它無法阻止服務替代軟體 (SaaSS)拒絕使用者的自由，但大多數的伺服器並不執行 SaaSS。更多關於這些問題的詳細資訊，請參閱《為什麼要使用 AGPL》。

文件

我們建議教學文件、手冊與其他大型作品採用 GFDL 授權。它是用於教育工作的強大著作傳授權條款，一開始是為軟體手冊編寫的，包含了專門解決散布或修改這些作品時可能出現的問題的條款。

對於一些較短或次要的文件作品，例如參考卡等等，最好使用 GNU 全寬容式授權條款，因為 GFDL 的副本通常難以放入這類的卡片中。不要使用 CC-BY，因為其與 GFDL 不相容。

至於手冊頁，如果頁面很長的話，我們建議使用 GFDL，如果較短的話，請使用 GNU 全寬容式授權條款。

有一些文件包含軟體的原始碼。舉例來說，程式語言的手冊可能會包含讀者可以使用的範例。你應該使用 GFDL 的條款來將這些原始碼包含在手冊裡，另外又使用其他適當的授權條款同時也發行軟體原始碼。這樣做可以讓在其他專案中使用此段程式碼更簡單。我們建議將小段的程式碼透過 CC0 貢獻到公有領域，並使用與相關的軟體專案相同的授權條款來將大段的程式碼發行。

程式的其他資料

本節討論你可能在軟體中使用的任何其他作品。例如圖示或是其他可能有用的圖形、字型或地理資料等。你也可以對藝術作品遵從這些建議。不過，就算你不這樣做，我們也不會指責你。

如果你是為軟體專案刻意建立這些作品，我們通常會建議你以與軟體一樣的授權條款發行。使用我們建議的授權條款這麼做一般來說不會有問題：GPLv3、LGPLv3、AGPLv3 與 GPLv2 可以用於任何類型的作品，不只是軟體，只要是受版權保護且對修改有明確偏好形式的標的都可以。使用與該軟體相同的授權條款可以讓散布者更容易符合規定，而且可以避免相容性問題。有時為了其他現實考量，例如希望與其他的自由軟體專案更容易相容，那麼使用其他的自由軟體授權條款可能會比較合適。

如果你的作品並不是為了特定的軟體專案所創作的，或是它不適合使用與軟體相同的授權條款，那麼我們建議你選擇適合你的作品的著作傳式授權條款。我們在我們的授權條款清端中有列出一些建議。如果沒有適當的授權條款，創用 CC 姓名標示-相同方式分享授權條款是一個可以用於多種不同作品的著作傳式授權條款。