如何定義開源軟體&套件?3分鐘快速搞懂第三方套件的授權模式!
現在許多人經常使用第三方套件,就是所謂的開源軟體及開源套件,指的是其原始碼可以被公眾檢視、修改與發佈的程式。但你瞭解定義開源軟體及套件,需具備10大要件嗎?本文就也一次快速透過3分鐘,帶你搞懂第三方套件的授權模式,瞭解用戶及開發者可以如何使用、修改、發布及共享軟體喔!
定義開源軟體需具備的10大要件
開放源碼促進會(Open Source Initiative,縮寫:OSI)以兼顧軟體的商業應用及程式源碼自由流通為目的,定義開源軟體必須具備下述要件:
1. 允許自由散布。
2. 包含程式源碼的自由流通。
3. 授權條款允許改作及衍生程式的產生。
4. 需保持原作者程式源碼的完整性(Integrity)。
5. 授權條款對任何個人或群體均應一視同仁,不得有差別待遇。
6. 授權條款不得對特定領域或活動的應用有差別待遇。
7. 授權條款所賦予的權利自動適用到每一位程式的收受者。
8. 授權條款所賦予的權利不得專屬於特定產品。
9. 授權條款不得對隨同散布的其他軟體做出限制(例如規定必須同為開放源碼軟體)。
10. 授權的管道必須保持技術中立性,不限制特定方式或平台才能取得。
依據上述對於開源軟體的定義,以及基於著作權法第 5 條第 1 項第 10 款:「本法所稱著作,例示包括電腦程式著作。」規範,制訂出多種情境、特性、規範的開源軟體授權條款。可以依據是否具有 Copyleft 特性,大致分為以下兩大類。
Copyleft Licenses
著作權(Copyright)給予著作權人專有利用著作的權利;Copyleft 則表達相反的思維,因故Copyleft 是一種嚴格的開源授權條款。它允許使用者使用、修改和分發軟體,但是有一個重要的條件:任何基於該軟體的衍生作品在分發時,也必須使用相同的或兼容的授權條款。這種要求確保衍生作品和原始軟體一樣保持開源,並強制分享改進。最經典且常見的Copyleft授權為GNU General Public License (GPL)。
非Copyleft Licenses (或可稱 Permissive Licenses)
由於開源軟體授權模式的核心價值是強調對程式不間斷的改作自由,因此有部份的開源軟體專案的推動者,認為完整的改作自由,亦應當包括改作之後,改作人得另行更改授權模式的自由。因此,其授權條款允許使用者自由地使用、修改和重新分發軟體,無論是在原始形式還是修改後的版本,甚至可以將開源軟體與封閉源碼(私有軟體)混合。這類授權條款通常只要求保留版權聲明和免責聲明,其中最典型的授權條款為MIT授權。
因此,在使用開源軟體時,除了其所提供的功能以及便利性之外,也需要進一步確認其所依循和使用的授權條款是屬於哪一種類型的授權,並了解其受條款所規範的項目,例如其修改物與衍生程式是否有實質散布、是否須遵循相同授權、是否也須完整公開程式源碼。
常見的9種授權類型&建議
授權名稱 | 簡稱 | 授權說明 | 強制公開程式碼 DevOps | 商用、企業內使用 | 一般建議 |
MIT License | MIT | MIT授權條款是一種極為寬鬆的開源授權,允許開發者幾乎無限制地對軟體進行使用、複製、修改、合併、出版發行、再授權或銷售。使用者只需要在所有複製或重要部分的程式碼中,保留版著作權權聲明(Copyright)和許可聲明(License)即可,因此更容易與傳統的軟體銷售模式相結合。 | no | 允許 | 此授權僅需要在使用處或重要處,註明該段程式碼版權和聲明,不須公開完整程式碼;且條款內容可依照著作權人的需要修改。 |
GNU General Public License | GNU GPL | GNU通用公共授權條款是一個廣泛使用的自由軟體授權,該授權條款保證終端使用者的自由,強制要求衍生作品也必須使用相同的授權條款發布。這就是所謂的“copyleft”條款,也是最常見的,這種授權模式保護了軟體的自由和開源特性,亦為開源的核心價值。 | yes | 允許,但必須同樣以GPL授權公開源碼。 | 此授權必須完全公開你專案的程式碼,並且也必須使用GNU General Public License的授權條款。 |
Lesser General Public License | LGPL | LGPL是GPL的一個衍生版本,原先稱為Library GPL。LGPL授權條款允許開發者將自行開發的程式與LGPL許可的程式做整合,,也就是允許被使用於閉源軟體中(私有開發); 其唯一條件是,若修改了LGPL的開源部分,則必須公開修改後的開源源碼。 | 部分強制,須公開修改後的凾式庫(Library)源碼。 | 允許 | 此授權主要針對在修改LGPL授權的開源凾式庫(Library)時,必須公開修改後的凾式庫源碼,未修改的部份則可以不用公開。可以將其用於自行開發之不公開源碼的商業應用中。 |
Apache License | Apache 2.0 | Apache 2.0授權條款是一種寬鬆的開源授權,允許開發者自由使用、修改和分發軟件,但它要求對修改過的檔案進行標記,並且在發佈的作品中包含原來的版權、商標、專利聲明(Copyright)以及一份Apache條款(License)。 | no | 允許 | 此授權允許商業使用,不過必須包含著作權聲明內容(Copyright)、Apache 條款(License)以外,還要特別標示出修改過的地方,但不需要公開修改的程式碼。特別的是,Apache License 2.0提供了專利訴訟保護,作為商用軟體使用條款更有保障。 |
BSD License | BSD License | BSD授權條款是一個非常寬鬆的授權,允許開發者幾乎無限制地使用源碼,只要保留原始的版權聲明和免責聲明即可。此授權分為二條款(2-Clause)和三條款(3-Clause)的版本,目前市面上以 為主,主要增加了一條「禁止使用作者或軟體名稱,用於本軟體衍生產品的認可或促銷活動」的條款。 | no | 允許,但3-clause 禁止使用作者或軟體名稱作為衍生產品命名和銷售宣傳。 | 此授權基本上唯一的規定就是必須把原本程式碼的 BSD 條款的著作權聲明內容(Copyright)留著。可以商業化,但3-Clause版本不得使用原專案作者的名聲,來作為後續散佈程式進行廣告或背書的規定。 |
Mozilla Public License | MPL 2.0 | MPL授權條款是一種中間程度限制的開源授權條款,只要求開發者針對修改過的檔案,必須以相同的授權條款發布與分享;但不要求整個產品都必須使用相同的授權條款,因此也不需要完整公開程式碼。這使得MPL更加靈活,允許將MPL程式與其他類型的程式結合發佈。 | 部分強制,須公開修改後的MPL程式但不包含完整專案。 | 允許 | 此授權不需要整個專案都使用相同的授權條款,只有在引用或使用處有進行修改的部分必須公開,其他部分程式碼不需要套用此授權,亦不需要公開。 |
GNU Affero General Public License | AGPL | AGPL是GPL的一個變型,專門用於網絡服務或網絡應用程式。而與另一個衍生版本LGPL不同的是,若使用AGPL授權條款的程式,用於網路服務或提供他人使用時,是必須提供專案的完整原始碼。 | 依使用情況,用於網路服務或提供他人使用時,則必須公開源碼。 | 商用必須公開源碼。私有環境(公司內部)使用不須公開源碼。 | 此授權針對專案有使用AGPL授權的程式,且也同樣用於提供網路服務或他人使用時,則必須完全公開專案程式碼。 |
Eclipse Public License | EPL 1.0 | EPL授權條款主要用於Eclipse的軟體專案,經 OSI 認可的最新版本為 EPL-1.0。該授權條款允許任何人自由使用、修改和發布EPL授權的軟體,除修改後的源碼也必須在EPL之下,其修改後的衍生物或執行檔,則允許使用不與EPL衝突的授權條款即可。 | 部分強制,須公開修改後的EPL程式但不包含完整專案。 | 商用必須公開修改後的EPL源碼。私有環境(公司內部)使用不須公開。 | 此授權規定當以源碼格式提供時,必須以 EPL-1.0 授權條款的方式來提供;而若以目的碼(Objective Code)格式提供時,也就是執行檔,則不限定必然要使用 EPL-1.0 的授權,只須能與其相容即可。因此,更適用於外掛(Plugin)或擴充(Extension)。 |
Common Development and Distribution License | CDDL | CDDL授權條款,類似於MPL的授權條款,主要用於某些Java平台相關的項目中,如OpenSolaris、GlassFish等,允許在特定條件下使用和發布。 | 部分強制,須公開修改後的CDDL程式但不包含完整專案。 | 商用必須公開修改後的CDDL源碼。私有環境(公司內部)使用不須公開。 | 此授權不需要整個專案都使用相同的授權條款,只有在有修改到原始CDDL的部分需要公開;其他部分程式碼不需要套用此授權,亦不需要公開。 |
開發者應該根據自己的需求、專案的性質,以及對於版權和專利的考量,來選擇合適的授權條款。只要在商業化運用的過程中遵守個別授權條款的規定,所有的自由開源軟體專案皆可被用來進行商業化運用,當然,這也包括內嵌到商業產品之中進行販售。然而,在販售相關產品的同時,必須遵守自由開源軟體授權條款的義務性規定。
若您所開發的專案,考慮到將來的商業規劃,則GPL和AGPL授權的第三方套件則可能並不適用於您的專案,因為這兩項授權條款皆要求其所有衍生物,都必須完整公開專案源碼。但如若開發者希望其他人和組織,能夠盡可能自由地使用、修改和發布專案,傾開源社群之力優化程式或是推動進步,則可以選擇MIT或BSD授權條款。由此可知,選擇適當的開源授權條款,對於確保專案著作權和符合法律規定至關重要。
延伸閱讀:
【2024最新】公司企業的3款最佳Devops工具,成功案例一次看!
如何確保做好企業資訊安全?這4大DDoS防護方法,推薦學起來!
參考資料
http://www.opensource.org/licenses
資訊工業策進會科技法律研究所 《採用自由開源軟體之法制指引》