GPL VS AGPL VS SSPL [開放原始碼 / 開源 協議 的 比較]
GPL
VS AGPL VS SSPL [開放原始碼 / 開源 協議 的 比較]
GPL和AGPLv3的區別
GPL：GNU通用公共許可證（GNU
General Public License）
AGPL：The
GNU Affero General Public License
GPL
v3協議，意味着修改和使用其代碼都需要開源，但是這是建立在軟件分發的基礎上，如果使用代碼作為服務提供，而不分發軟件，則不需要開源。這實際上是GPL協議本身的缺陷。
AGPL
v3協議，也就是說，除非獲得商業授權，否則無論以何種方式修改或者使用代碼，都需要開源。
SSPL 和 AGPL 協議有什么區別？
SSPL 搆建於 AGPL 的精神之上，但明確了將開源軟件作為服務提供的條件。
SSPL 保留了開源社區在 AGPL 下使用 MongoDB 所有擁有的相同權利：使用、審查、修改和重新發布軟件的自由。
唯一實質性的變化，就是加了一個明確的條件，即任何試圖將 MongoDB 作為服務加以利用的組織，都必須開放用於提供此類服務的軟件的源代碼。
10 thoughts on “GPL VS AGPL VS SSPL [開放原始碼 / 開源 協議 的 比較]”
各授權協議介紹 – https://medium.com/getamis/%E9%96%8B%E6%94%BE%E6%BA%90%E7%A2%BC%E6%8E%88%E6%AC%8A%E6%A6%82%E8%A7%80-%E4%B8%8B-eeda7ce13f1e
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 授權
以 MPL 授權的源碼修改後也必須要使用相同授權釋出
衍生作品只需要開源自 MPL 授權修改的檔案，其他部分不需開源
專利授權方面允許製造、使用、販售等多種權利
被授權人展開專利訴訟時將會被撤銷該 MPL 授權軟體賦予他的權利
明確說明授權不處理商標權
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 授權
以 LGPL 授權的源碼修改後也必須要使用相同授權釋出
衍生作品若是採用動態連結則不需要一併開源，靜態連結則需開源
專利授權方面允許製造、使用、販售等多種權利
被授權人展開專利訴訟時將會被撤銷該 LGPL 授權軟體賦予他的權利
GPL 3.0 授權
https://opensource.org/licenses/GPL-3.0
GPL 比起前面的授權都要更加嚴格。無論是靜態或動態連結到 GPL 授權專案時，都需要相同以 GPL 授權釋出，至於其他特性則與 LGPL 3.0 相同。
重點規則：
散佈時要附上 GPL 3.0 授權
以 GPL 授權的源碼修改後也必須要使用相同授權釋出
衍生作品需要以 GPL 授權釋出，無論是靜態或是動態連結
專利授權方面允許製造、使用、販售等多種權利
被授權人展開專利訴訟時將會被撤銷該 GPL 授權軟體賦予他的權利
另外舊版的 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 授權
以 AGPL 授權的源碼修改後也必須要使用相同授權釋出，即使沒有散佈軟體，只要有人「使用」軟體就就需要以 AGPL 開源
衍生作品需要以 AGPL 授權釋出，無論是靜態或是動態連結
專利授權方面允許製造、使用、販售等多種權利
被授權人展開專利訴訟時將會被撤銷該 AGPL 授權軟體賦予他的權利
修改使用 開放源碼是否要公開源碼的規定 –
https://medium.com/getamis/%E9%96%8B%E6%94%BE%E6%BA%90%E7%A2%BC%E6%8E%88%E6%AC%8A%E6%A6%82%E8%A7%80-%E4%B8%8A-45309a387c64
當修改了一個開放源碼軟體時，不同的授權會有不同的規定。這些授權可以分成兩類：
需要開源：AGPL, GPL, LGPL, MPL
不需要開源：MIT, BSD, Apache
另外這些開源授權，大多都規定開源的時機在於當你「散佈」了該軟體時需要一併散佈源碼，但是如果你是架設網站讓使用者透過瀏覽器連上網站，這時候你並沒有「散佈」產品給使用者，而是使用者透過瀏覽器連結上該網站。當這種情形時，絕大部分的授權都不會要求你開放源碼，除了 AGPL 是針對這種狀況規定，如果你修改的軟體源自於 AGPL 授權的軟體，即使沒有散佈給使用者依然需要採用 AGPL 釋出源碼。
重點整理：
如果你修改自 AGPL, GPL, LGPL, MPL 授權軟體，散佈產品時也需要一併開放源碼
如果你修改自 MIT, BSD, Apache 授權軟體，你可以決定是否要開源
如果你的產品是個雲端服務，使用者僅是透過瀏覽器來使用你的產品時，因為沒有「散佈」行為，所以以上授權除了 AGPL/ SSPL以外都不需要開放源碼
從 Redhat 到 GitHub，開源軟體為什麼開始火了？[開源要如何賺錢]
資料來源:https://buzzorange.com/techorange/2019/01/16/open-sources-rule/?utm_source=TOLINEING_0116&utm_medium=opensourcesrule
從完全免費，走向「免費增值」的付費制度
免費增值的概念是，你基本上可以免費使用它，如果要在生產過程中大規模使用，則需要付費。
~~~~~~~~
開源軟體的三代發展史：開源、開放核心、SaaS
第一代開源：軟體免費，服務付費
開源項目誕生的起初並不是為了商業化，而是為了打破閉源軟體公司的壟斷。 微軟、甲骨文、SAP 等公司從軟體銷售中獲取高額的利潤。當時的頂級開發者並不認同這種模式。
因此，他們從操作系統和數據庫開始，協作編寫軟體，讓每個人都不僅可以看到軟體程式碼，甚至還可以對它進行改進。
該軟體最初由開發人員創建，這意味著一開始它對用戶並不方便和友好。
但它具有高性能、健壯性和靈活性的特點。這些優點逐漸滲透到軟體世界中。
第二代開源：部分軟體免費，想用全部請付錢。
第二代開源軟體公司的代表是 Cloudera 和 Hortonworks，這些軟體公司在開源項目和業務上和第一代有根本上的不同。
第三代開源：在雲端使用開源軟體
但是，第二代開源業務的商業模式也存在缺陷。
首先，沒有一家公司對軟體擁有「道德權威」，因此競爭者通過提供越來越多的免費軟體來爭奪利潤。
第二，這些公司經常阻礙軟體的發展，試圖讓自己與眾不同。
雲提供商能夠使用開源軟體來創建相同軟體庫的 SaaS 業務。亞馬遜的 EMR 就是一個很好的例子。
從某種意義上來說，這些是開放核心 / 雲服務混合企業，他們有多種途徑來賺錢。通過提供 SaaS 形式的產品，這些企業可以將開源軟體和商業軟體結合在一起，這樣客戶就不必再擔心他們應該獲得哪一個許可。
Elastic Cloud，Confluent Cloud 和 MongoDB 等公司就是這種第三代產品的例子。這種轉變的意義是，開源軟體公司現在有機會成為軟體基礎設施的主導商業模式 。
OPEN 授權 協議 比較
公開原始碼 授權 協議 比較
GPL 漏洞破解
編譯程式只要公開MAKEFILE
使用執行檔 只要公開 呼叫 SHELL
如果使用Qt來開發商業軟件，是否需要付費？
https://zh-hant.hotbak.net/key/pyqt%E5%95%86%E6%A5%AD%E6%8E%88%E6%AC%8A.html
Qt有三種授權方式：GPL協議、LGPL協議以及商業授權。其中GPL協議、LGPL協議是開源社區中廣泛使用的兩種協議。作為法律條文，最精確的闡述是該條文本身，任何讀者都可能是不全面、不準確，下面僅從Qt用戶的角度介紹這兩種協議。最後，將討論如何在這3種協議中進行選擇。關於GPL、LGPL協議的官方文本以及詳細的解讀，請參http://www.gnu.org/licenses/。
1.GPL（General Public License）協議並不是為了保護軟件作者的利益，而是為了鼓勵軟件開發者相互共享各自的成果。該協議允許軟件的用戶享有以下權利：能夠得到軟件的源代碼；修改軟件，或者將軟件的一部分用在用戶自己開發的軟件中；能夠發行軟件的複本，用戶和原作者均可收費，即使一個軟件的用戶通常並不是該軟件的作者。同時，該協議要求用戶履行以下義務：一旦該用戶所開發的一個軟件用到了其他GPL軟件，新開發的軟件也必須遵循GPL協議，也就是說，新軟件的用戶也享有上述權利，這要求新軟件的開發者在發布該軟件時也必鬚髮布源代碼。對於GPL協議下的軟件，由於軟件的用戶也有權以收費或者免費的方式發布該軟件，該軟件的原作者實際上不能指望通過出售該軟件本身贏利。然而，由於原作者對該軟件最熟悉，能夠提供強有力的技術支持，他們可以通過技術支持的方式獲利，比如Redhat公司。
2.LGPL（Lesser GPL）協議一般適用於類庫。該協議允許類庫的用戶享有以下權利：如果用戶沒有修改類庫，而且是以動態鏈接的方式使用類庫，用戶在發布自己開發的軟件時，可以不發布源碼。但是，如果用戶修改了受LGPL協議保護的類庫，或者在自己開發的軟件中使用了類庫中的源代碼，則新開發的軟件也必須遵循LGPL協議，也就是說，在發布新軟件時，必鬚髮布類庫中被修改的源代碼、新軟件中相關部分的源代碼。
3.Qt的商業授權方式允許Qt用戶享有以下權利：能夠對Qt進行任意的修改，以滿足特定的需求，比如使Qt能夠運行在某種智能手機平台上。用戶可以不公布這些修改；能夠在至多兩個工作日內，答覆用戶任何類型的技術問題，不限制問題的總數量。關於這種授權方式的細節，可參見http://www.digia.com/。
GPL或者LGPL授權的Qt是免費的，而商業授權的Qt則要求用戶支付一定的費用。對於Qt用戶，如果他希望對開源社區做貢獻，可以選擇GPL授權方式，但他在發布自己的軟件時必須附上源代碼。如果他在開發中不需要修改Qt庫，也不需要任何技術支持，可以選擇LGPL授權方式。如果他需要修改Qt庫或者需要良好的技術支持，應該選擇商業授權方式。
資策會官網 解釋 (可商用) 開放原始碼 / 開源 協議 的 比較
https://wfh.iii.org.tw/%E5%90%84%E6%8E%88%E6%AC%8A%E6%A2%9D%E6%AC%BE%E4%B9%8B%E7%B0%A1%E4%BB%8Bmit-bsd%E9%A1%9E/
MIT/BSD類
BSD License
BSD License全名為「Berkeley Software Distribution License」，目前OSI認證名為BSD License共有四種：
0-clause BSD License
又稱 Free Public License 1.0.0或經SPDX-軟體套件授權資料交換標準（Software Package Data Exchange）縮寫為「0BSD」，條款內容簡單敘明授權之利用方式及免責聲明，然使用上並不要求相關聲明亦在保留之列。
1-clause BSD License
SPDX縮寫為BSD-1-Clause，條款內容為簡單的著作權及免責聲明，並要求以源碼形式散布該軟體時，需保留原定式的著作權及免責聲明。
2-Clause BSD License
又稱Simplified BSD License或FreeBSD License，SPDX縮寫為BSD-2-Clause。條款內容除了BSD-1-Clause之內容外，更要求以二進位碼（Binary Code）形式散布該軟體時，亦需依定式保留該著作權及免責聲明。
3-Clause BSD License
又稱New BSD License或Modified BSD License，SPDX縮寫為BSD-3-Clause。條款內容除了BSD-2-Clause之內容外，新增除經書面許可外，禁止以著作權人或貢獻者之名義促銷衍生產品。
MIT License
MIT License之名源自麻省理工學院（Massachusetts Institute of Technology, MIT）。本條款內容列示授權之利用樣態、著作權及免責聲明，並要求所有此軟體之副本均應保留該著作權及免責聲明；一般來說，多數的開源授權研究者皆同意，MIT License的授權條款內容幾與BSD-3-Clause等價，僅述事模式有些許差異。
ISC License
ISC License是由網路系統協會（Internet Systems Consortium, ISC）所發布。條款內容簡單敘明授權之利用方式、著作權及免責聲明，並要求該軟體之副本均應附上著作權及免責聲明；0BSD是依據ISC License來再做精簡，略去了相關聲明的要求而幾乎沒有義務性拘束。
Apache License 2.0
SPDX縮寫為Apache-2.0，是由Apache 軟體基金會（Apache Software Foundation, ASF）所撰擬。本條款相較於其他BSD/MIT類型條款，規範內容在法律用字上更為嚴謹。除了著作權的授權以外，該授權條款亦明文授權開發者就該軟體主動貢獻所含之專利權，而本條款同樣也包含免責聲明，且要求散布時亦應提供此授權條款。而若有修改該軟體，並不限定必須再採Apache-2.0來發布修改軟體，但新使用的條款不得與原Apache-2.0律定的義務性要求產生衝突，除此之外，Apache-2.0與其他BSD/MIT類最大的差異在於，要求修改者之後再發 布修改軟體時，有修改更動的檔案必須註記它的被修改狀態。
資策會 精簡說明 常見開源軟體授權條款對照表
https://wfh.iii.org.tw/%e5%b8%b8%e8%a6%8b%e9%96%8b%e6%ba%90%e8%bb%9f%e9%ab%94%e6%8e%88%e6%ac%8a%e6%a2%9d%e6%ac%be%e5%b0%8d%e7%85%a7%e8%a1%a8/
資策會 精簡說明 GPL的各授權條款之簡介
https://wfh.iii.org.tw/%E5%90%84%E6%8E%88%E6%AC%8A%E6%A2%9D%E6%AC%BE%E4%B9%8B%E7%B0%A1%E4%BB%8Bgpl%E9%A1%9E/
GPL類
GNU General Public License version 2
SPDX縮寫為GPL-2.0或GNU Project簡稱其為GPLv2，此條款為目前開源軟體中最常使用的授權條款之一，並因Linux Kernel及許多重要專案採用而極具影響力。在條款前言處即彰顯了GPL-2.0著佐權（Copyleft）的精神，並體現在其強烈的授權拘束性及強制衍生著作亦須開源的效力上。當使用者在使用以GPL-2.0授權的軟體時，如有取用或修改該軟體的程式碼而產生衍生著作，該衍生著作也被要求發布或再提供給他人時，須以GPL-2.0授權，並依此條款提供修改後之軟體源碼。
GNU General Public License version 3
SPDX縮寫為GPL-3.0，此授權條款是在2007年作為GPL-2.0更新版本所發布，更新理由主要是為了因應GPL-2.0授權條款發布年份較遠，而就後續網際網路應用、P2P散布等延伸情境無法充份對應處理的問題。依照國內開源授權研究者林誠夏引用Richard Stallman之說法，GPL-3.0處理了GPL-2.0以下問題：「軟體專利問題、增加與其他自由軟體的相容性、明確定義源碼的提供範圍、降低數位權利管理機制的可能影響。此外，GPL-3.0第7條設定了額外條款，賦予散布者在散布時可以自由選擇額外授權條款的內容，相較於GPL-2.0提供了散布者更高的使用彈性。」然而，就基礎的授權規則來論，GPL-3.0與GPL-2.0架構是相同的，皆扣緊衍生著作亦須開源的效力，以及要求衍生著作再發布時，須採用與原軟體完全一致的授權條款來提供。
GNU Lesser General Public License version 2.1
SPDX縮寫為LGPL-2.1，是專門適用於函式庫（Library）授權使用之授權條款。LGPL-2.1最大的特點在於放寬GPL-2.0授權條款的限制，如果只是在自撰軟體中，參考或少量引用LGPL-2.1的互動介面程式碼，其後單純引用或呼叫LGPL-2.1授權函式庫依其功能提供資訊，該自撰軟體並不會必然受到LGPL-2.1強制開源要求的拘束。但若自撰程式與LGPL-2.1授權函式庫的結合關係過於緊密，例如兩者整合為一個結合程式，甚至成為一個單一執行檔，則該結合程式就必須一體適用LGPL-2.1的授權規則，也就是說類同GPL-2.0，衍生著作亦須開源，並且衍生著作再發布時，須採用LGPL-2.1授權條款來提供。
GNU Lesser General Public License version 3
SPDX縮寫為LGPL-3.0，為LGPL-2.1近年的更新版本， LGPL-3.0與LGPL-2.1的授權架構是相同的，但法律文字建構的方式，是以GPL-3.0為基礎文本，再添附針對函式庫利用模式特性的額外條款，整體方為LGPL-3.0的授權條款全文。故與LGPL-2.1相較，LGPL-3.0就軟體專利、網際網路散布及應用做出處理，但同時保持其他自撰軟體參考或少量引用LGPL-3.0互動介面程式碼，做出授權拘束上放寬的處理。
GNU Affero General Public License version 3
SPDX縮寫為AGPL-3.0，簡要來說AGPL-3.0為GPL-3.0的孿生條款，較GPL-3.0延後幾個月發布，其基礎內容與GPL-3.0完全一致，然在第13條做出差異區隔，主要是認定何謂「軟體散布」的標準不同。依照AGPL-3.0規定，當基於該授權軟體建置的專案或平台，透過雲端模式提供服務時，雖然服務使用者並沒有取得專案的程式碼，亦即並沒有構成傳統上軟體散布的定義，而不會啟動GPL-3.0、GPL-2.0要求散布者必須提供源碼的義務，但依循AGPL-3.0授權條款第13條的要求，服務的提供者仍必須就此「遠端提供電腦網路互動」的機制，義務性地應使用者需求，提供AGPL-3.0軟體及其衍生程式於此專案裡相對應的源碼。對於支持軟體自由（Software Freedom）理念的人士，會將AGPL-3.0視為GPL系列條款的補充協議，用以彌補GPL授權條款無法因應網路及雲端服務公司（例如Google、Facebook）興起後，所生分享開源軟體相關源碼的漏洞；然對於一般僅是規劃將開源軟體作為部份商用方案的公司而言，AGPL-3.0對雲端服務後續授權利用的模式影響極大，故於政策未明前，原則上會先區隔避免使用。