開放源碼授權概觀(下)

Yuren Ju
Yuren Ju
Jul 3, 2018 · 7 min read
在台灣的 OSDC 研討會所拍攝的照片

本文的上篇概略講解了開源授權定義與使用情境,但是不同的授權之間還是有細微的差別。本篇則針對常用的不同授權講解,由於授權數量眾多,我們會從鬆散到嚴謹程度逐一討論各種授權。

個別授權差異

MIT 授權

https://opensource.org/licenses/MIT

MIT 授權是這幾個列出來的授權當中最鬆散的一個,在權利上面規範有授予使用、重製、修改、合併、發行、散佈再授權及販售等權利,並且可以依照需求修改 MIT 授權條款內容。

而需要遵守的義務僅有要一併散佈 MIT 的授權聲明,至於衍生物開源與否並不在義務範圍內。

MIT 授權的好處在於授權本身非常簡短,同時也沒有規範太多規則,在個人專案我通常都會採用 MIT 授權的原因也在於沒有太多規則。

重點規則:

  • 散佈時要附上 MIT 授權

BSD 授權

https://opensource.org/licenses/BSD-3-Clause

BSD 授權有許多變形,我們這邊談論的是 3-clause BSD。BSD 授權散佈源碼以及執行檔,但是不若 MIT 一樣有明確列出其他所有權利。

所需要遵守的義務跟 MIT 一樣需要一併散佈 BSD 授權聲明並且不規定開源與否,不同處在於 BSD 授權內額外規定衍生作品不得利用軟體貢獻者的名字為其背書。

重點規則:

  • 散佈時要附上 BSD 授權

Apache 2.0 授權

https://opensource.org/licenses/Apache-2.0

Apache 2.0 授權基本上效力跟 BSD 授權非常類似,不同之處在於 Apache 2.0 授權在各個方面都提供非常詳實的授權說明,相比起來 BSD 授權則較為簡單。

在權利方面 Apache 授權針對著作權、專利授權以及商標權都有詳細的規定,著作權上允許製作衍生物、公開展示、公開演出、再授權和散佈。專利授權上允許製造、使用、販售等權利。商標權上明確規定 Apache 授權並無授權使用商標,相對於 MIT, BSD 授權並沒有明顯規範商標權來說,這樣清楚的說明不處理商標權比較明確。

在義務方面相同的需要附上 Apache 授權,並且在修改的檔案必須要附上修改聲明與一些細節的規定。

重點規則:

  • 散佈時要附上 Apache 2.0 授權

關於 Apache 2.0 與 BSD 的差異可以參考這篇林懿萱著作的《化簡為繁的 Apache-2.0 授權條款》。

MPL 2.0 授權

https://opensource.org/licenses/MPL-2.0

MPL 2.0 授權比起 Apache 授權更加嚴格,若採用 MPL 授權的源碼經過修改後,必須也要採用 MPL 2.0 授權釋出。但是如果不是修改 MPL 授權的檔案,而是連結(靜態與動態連結皆可)或使用 MPL 授權的檔案,則是可以採用其他授權,也就是不需一定要開放源碼。

至於專利授權上跟 Apache 授權類似允許製造、使用、販售等權利,另外也規範了若被授權人對其他貢獻者展開專利訴訟,該被授權人原本使用 MPL 授權軟體被授予的權利將會被撤銷。

重點規則:

  • 散佈時要附上 MPL 2.0 授權

LGPL 3.0 授權

https://opensource.org/licenses/LGPL-3.0

LGPL 全文是 GNU Lesser General Public License,從名稱可以得知是較鬆散的授權,不過比較的對象是 GPL,如果跟其他授權比較起來還是滿嚴格的。

首先跟 MPL 相同,如果修改了 LGPL 的源碼一律都要開源。比起 MPL 更嚴格的地方在於 MPL 授權允許你把一個 MPL 授權的專案直接放到你自己專案的目錄底下一起編譯成執行檔,但是 LGPL 授權的專案當你這麼做時會被視為 LGPL 授權的衍生作品,也需要一併以 LGPL 授權釋出。

根據 StackExchange 上面其他人的見解,LGPL 3.0 與 MPL 2.0 的差異實務上在於 LGPL 可以允許用動態連結 (Dymanic Link) 的方式將閉源專案與 LGPL 3.0 授權專案一起使用,但是如果要採用靜態連結 (Static Link) 則是會需要一併以 LGPL 3.0 授權釋出。MPL 2.0 則允許靜態連結與動態連結都不需開源。

重點規則:

  • 散佈時要附上 LGPL 3.0 授權

GPL 3.0 授權

https://opensource.org/licenses/GPL-3.0

GPL 比起前面的授權都要更加嚴格。無論是靜態或動態連結到 GPL 授權專案時,都需要相同以 GPL 授權釋出,至於其他特性則與 LGPL 3.0 相同。

重點規則:

  • 散佈時要附上 GPL 3.0 授權

另外舊版的 GPL 2 也是目前相當熱門的授權,關於版本之間的差異可以參考林誠夏的《GPL-3.0 與 GPL-2.0 的異同比較與應用分析》。

AGPL 3.0 授權

https://opensource.org/licenses/AGPL-3.0

AGPL 是這邊最嚴格的授權,以上的所有授權在「開放源碼」的時機通常都在於當你「散佈」你的產品時需要附上源碼。但是如果像是 Google 或 Facebook 這樣的雲端服務,當你瀏覽他們的網站時其實公司並沒有「散佈」他們的產品,而是你連結到他們的網站使用他們的服務。既然沒有散佈,那就不需要開源。即使使用 GPL 3.0,只要你是類似這樣的服務模式都不會需要開放源碼。

AGPL 則是對應這樣的雲端服務而誕生的授權,就算只是使用者「利用」到自 AGPL 衍生的產品,即使產品沒有散佈到使用者手上,仍需要以 AGPL 3.0 授權。

重點規則:

  • 散佈時要附上 AGPL 3.0 授權

總結

開放源碼授權真是一個龐大的課題,但是身為開發者又不得不好好的理解這些授權。不過就如同前面的 TL;DR 一樣,我自己選擇時通常有個簡單的策略來判斷專案若要開源要如何選擇專案。

你也可以了解完所有開源授權後,建立自己簡易的授權決策方針,往後要開源時就照著這個決策方針來判斷軟體要以哪個授權釋出就行了。

最後想要再次感謝自由軟體鑄造場大量的開源授權資訊,本篇文章閱讀了相當多鑄造廠發表的資料後並且整理成這篇文章。另外 2018 年 COSCUP 將會有個社群議程軌 “FOSS Compliance — Complex Made Simple” 將會探討關於開源授權的相關知識,如果你想更深入了解,可以到時也到該軌議程參與。

如果有興趣了解 AMIS 的開源專案,也可以從下面的連結前往。

getamis

Using breakthrough blockchain technology, Amis has created a standardized platform to let business create information exchange systems and make transaction data open and shareable to improve the quality of life for everyone.

Thanks to Yu-Te Lin

Yuren Ju

Written by

Yuren Ju

旅行、咖啡、科技宅

getamis

getamis

Using breakthrough blockchain technology, Amis has created a standardized platform to let business create information exchange systems and make transaction data open and shareable to improve the quality of life for everyone.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade