近期公司全面擁抱開源,在選擇開源協議方面遇到了一些問題,查閱了很多資料,特此總結~~
前言
對于很多剛踏入開源軟體這個行業的小伙伴來說,在編碼程序中難免會用到其他人的成果,如果你足夠細心,很容易注意到即使是一小段代碼,優秀的作者都在檔案開頭附上一段關于著作權的宣告,比如 Licensed under the MIT license,同時,一些博客也會標明”此文章采用 CC BY 4.0 CN 協議“,
如果我們拷貝了別人的代碼或文章卻沒注意著作權問題,在國外法律意識特別強的環境下(國內著作權意識也在逐步加強),那么我們的作品會因觸犯別人的權益而違法,即使是最開放的開源協議,最低要求也是保留原作者對代碼的宣告,所以開源不等于免費,也不等于沒有約束,
何為 LICENCE?
LICENCE 是軟體的授權許可,詳細說明了獲得代碼后擁有的權利,哪些操作是允許的,哪些操作是禁止的,軟體的著作權許可證可有很多方式,本文僅限于討論開源軟體協議 Open Source License,
對于大多數人來說,沒必要花大把時間去寫許可協議,選擇一種比較流行的開源協議就足夠了,省時省力,更便于自己作品的傳播,于人于己都有利,
PS:
說句題外話,很多國外開發者在尊重他人勞動成果方面做得很好,如果A的作品是因為B的作品的啟發而來,A甚至都沒有使用B任何一句代碼,但A會在他的作品里面指明是受到了B的啟發:
Inspired by XXX link: http://www.xxxx.com,
快速選擇開源協議
如果你不想了解太多,只是想要一個簡直直接的答案,下面給出的建議或許適合你,本小節關于協議地址來自于 GitHub choosealicence ,
簡單寬松的協議:
如果你只想要一個簡單點的協議不想太麻煩的話,
MIT協議相對寬松,此協議允許別人以任何方式使用你的代碼同時署名原作者,但原作者不承擔代碼使用后的風險,當然也沒有技術支持的義務,
考慮有專利的情況:
如果你的作品中涉及到專利相關,
Apache協議也是個相對寬松的協議,與MIT類似,但它指明了作者對用戶專利上的一些授權(我的理解是軟體作品中含有專利,但它授權你可以免費使用),
促進代碼分享:
如果你在乎作品的傳播和別人的修改,希望別人也以相同的協議分享出來,
GPL(V2或V3)協議要求代碼分發者或者以此代碼為基礎開發出來的衍生作品需要以同樣的協議來發布,也必須開源,因此,該協議具有”傳染性“,
烏克蘭程式員 Paul Bagwell 畫了一張分析圖,說明應該怎么選擇,只用兩分鐘,你就能搞清楚這六種開源協議之間的最大區別,

國內大神阮一峰的漢化版本:

主流開源許可協議(Open Source License)
世界上的開源許可協議(Open Source License)大概有上百種,常用的開源軟體協議大致有:
- GPL
- LGPL
- BSD
- MIT
- Mozilla
- Apache
由寬松到嚴緊排序,常用的開源協議有:
- MIT
- BSD
- Apache
- LGPL
- GPL
主要區別:
- MIT、BSD 開源協議都源自大學,體現了簡單、開放和包容的特點,
- MIT、BSD、Apache 三者都支持閉源的后續開發,
- GPL、LGPL 傳染性開源,編譯的代碼里用了這里的代碼,都必須開源,
MIT
來源于大學,MIT 開源協議是史上最為簡潔、慷慨的開源協議之一,作者只想保留著作權,而無任何其他了限制,也就是說,你必須在你的發行版里包含原許可協議的宣告,無論你是以二進制發布的還是以源代碼發布的,
特點:
- 用戶可以拿你的代碼做任何想做的事情,
- 用戶在專案副本中要包含著作權宣告和許可宣告,
- 你無需承擔任何責任,
代表作品:
- jQuery
- Rails 等,
BSD
- BSD-2-Clause
- BSD-3-Clause
BSD可證也來源于大學,與MIT差不多,也非常簡單、慷慨,
BSD開源協議是一個給于使用者很大自由的協議,基本上使用者可以”為所欲為”,可以自由的使用、修改源代碼,也可以將修改后的代碼作為開源或者專有軟體再發布,前提是當你發布使用了BSD協議的代碼,或者以BSD協議代碼為基礎開發自己的產品時,需要滿足三個條件:
- 如果再發布的產品中包含源代碼,則在源代碼中必須帶有原代碼中的BSD協議,
- 如果再發布的只是二進制類別庫/軟體,則需要在類別庫/軟體的檔案和著作權宣告中包含原來代碼中的BSD協議,
- 不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣,
BSD 開源協議鼓勵代碼共享,但需要尊重代碼作者的著作權,BSD 開源協議允許使用者修改和重新發布代碼,也允許使用或在BSD代碼上開發商業軟體發布、銷售,是對商業集成很友好的協議,因此,很多公司在選用開源產品的時候都首選BSD協議,
Apache Licence
- Apache License, Version 2.0
- Apache License, Version 1.1
- Apache License, Version 1.0
來自 Apache,類似 MIT 開源協議,但它重視專利權,
Apache Licence 是著名的非盈利開源組織 Apache 采用的協議,該協議和BSD類似,同樣鼓勵代碼共享和尊重原作者的著作權,同樣允許修改代碼、再發布(作為開源或商業軟體),需要滿足的條件也和BSD類似:
- 需要為使用代碼的用戶提供一份 Apache Licence ,
- 如果你修改了代碼,需要在被修改的檔案中說明,
- 在延伸的代碼中(修改和由源代碼衍生的代碼中)需要帶有原來代碼中的協議、商標、專利宣告和其他原作者規定需要包含的說明,
- 如果再發布的產品中包含一個
Notice檔案,則在Notice檔案中需要帶有 Apache Licence ,你可以在Notice中增加自己的許可,但不可對 Apache Licence 構成更改,
Apache Licence 也是對商業應用友好的許可,使用者也可以在需要的時候修改代碼來滿足需要并作為開源或商業產品發布/銷售,
代表作品:
- echarts
- superset
- dubbo
- spark
LGPL
LGPL(GNU LESSER GENERAL PUBLIC LICENSE)來自于自由軟體聯盟GNU,可以翻譯為更寬松的GPL協議,也屬于傳染性開源協議,
LGPL是GPL的一個主要為類別庫使用設計的開源協議,和GPL要求任何使用/修改/衍生之GPL類別庫的的軟體必須采用GPL協議不同,LGPL 允許商業軟體通過類別庫參考(link)方式使用LGPL類別庫而不需要開源商業軟體的代碼,這使得采用LGPL協議的開源代碼可以被商業軟體作為類別庫參考并發布和銷售,
但是如果修改LGPL協議的代碼或者衍生,則所有修改的代碼,涉及修改部分的額外代碼和衍生的代碼都必須采用LGPL協議,因此,LGPL協議的開源代碼很適合作為第三方類別庫被商業軟體參考,但不適合希望以LGPL協議代碼為基礎,通過修改和衍生的方式做二次開發的商業軟體采用,
GPL/LGPL都保障原作者的知識產權,避免有人利用開源代碼復制并開發類似的產品,
GPL
GPL(GNU GENERAL PUBLIC LICENSE)來源于自由軟體聯盟GNU,GPL/LGPL側重于代碼及衍生代碼的開源與免費使用,
GPL協議的主要內容是只要在一個軟體中使用(”使用”指類別庫參考,修改后的代碼或者衍生代碼)GPL 協議的產品,則該軟體產品必須也采用GPL協議,既必須也是開源和免費,這就是所謂的”傳染性”,
由于GPL嚴格要求使用了GPL類別庫的軟體產品必須使用GPL協議,對于使用GPL協議的開源代碼,商業軟體或者對代碼有保密要求的部門就不適合集成/采用作為類別庫和二次開發的基礎,
我們很熟悉的Linux就是采用了GPL,GPL協議和BSD, Apache Licence等鼓勵代碼重用的許可很不一樣,GPL的出發點是代碼的開源/免費使用/參考/修改和衍生代碼的開源/免費使用,但不允許修改后和衍生的代碼做為閉源的商業軟體發布和銷售,
其它細節和BSD/Apache等協議類似,
代表作品:
- Linux
更多開源協議對比
下方表格中出現的用詞的解釋:
- 協議和著作權資訊(License and copyright notice):在代碼中保留作者提供的協議和著作權資訊,
- 宣告變更(State Changes):在代碼中宣告對原來代碼的重大修改及變更,
- 公開原始碼(Disclose Source):代碼必需公開,
- 庫參考(Library usage):該庫可以用于商業軟體中,
- 責任承擔(Hold Liable):代碼的作者承擔代碼使用后的風險及產生的后果,如果禁止,那么作者將不會承擔責任,可以理解為免責條款,
- 商標使用(Use Trademark):可以使用作者的姓名,作品的Logo,或商標,
- 附加協議(Sublicensing):允許在軟體分發傳播程序中附加上原來沒有的協議條款等,
| 協議 | 描述 | 要求 | 允許 | 禁止 |
|---|---|---|---|---|
| Apache | 一個比較寬松且簡明地指出了專利授權的協議, | 1. \(\color{#0000FF}{協議和著作權資訊}\) 2. \(\color{#0000FF}{宣告變更}\) |
1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{專利授權}\) 5. \(\color{#00EE00}{私用}\) 6. \(\color{#00EE00}{附加協議}\) |
1. \(\color{#FF3030}{責任承擔}\)(作者免責) 2. \(\color{#FF3030}{商標使用}\) |
| GPL | 應用最廣泛的開源協議,擁有較強的著作權自由(copyleft)要求, 衍生代碼的分發需開源并且也要遵守此協議, 此協議有許多變種,不同變種的要求略有不同, |
1. \(\color{#0000FF}{公開原始碼}\) 2. \(\color{#0000FF}{協議和著作權資訊}\) 3. \(\color{#0000FF}{宣告變更}\) |
1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{專利授權}\) 5. \(\color{#00EE00}{私用}\) |
1. \(\color{#FF3030}{責任承擔}\) 2. \(\color{#FF3030}{附加協議}\) |
| MIT | 此協議寬松簡單,在適當標明來源及免責的情況下,它允許你對代碼進行任何形式的使用, | 1. \(\color{#0000FF}{協議和著作權資訊}\) | 1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{私用}\) 5. \(\color{#00EE00}{附加協議}\) |
1. \(\color{#FF3030}{責任承擔}\) |
| Artistic | Perl社區最鐘愛此協議,要求更改后的軟體不能影響原軟體的使用, | 1. \(\color{#0000FF}{協議和著作權資訊}\) 2. \(\color{#0000FF}{宣告變更}\) |
1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{私用}\) 5. \(\color{#00EE00}{附加協議}\) |
1. \(\color{#FF3030}{責任承擔}\) 2. \(\color{#FF3030}{商標使用}\) |
| BSD | 較為寬松的協議,有兩個變種BSD 2-Clause 和BSD 3-Clause,兩者都與MIT協議只存在細微差異, | 1. \(\color{#0000FF}{協議和著作權資訊}\) | 1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{私用}\) 5. \(\color{#00EE00}{附加協議}\) |
1. \(\color{#FF3030}{責任承擔}\) |
| Eclipse | 對商用非常友好的協議,可以用于軟體的商業授權,包含對專利的優雅授權,也可以對相關代碼應用商業協議, | 1. \(\color{#0000FF}{公開原始碼}\) 2. \(\color{#0000FF}{協議和著作權資訊}\) |
1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{專利授權}\) 5. \(\color{#00EE00}{私用}\) 6. \(\color{#00EE00}{附加協議}\) |
1. \(\color{#FF3030}{責任承擔}\) |
| LGPL | 主要用于一些代碼庫,衍生代碼可以以此協議發布(也可以用其他協議),但與此協議相關的代碼必需遵循此協議, | 1. \(\color{#0000FF}{公開原始碼}\) 2. \(\color{#0000FF}{庫參考}\) 3. \(\color{#0000FF}{協議和著作權資訊}\) |
1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{專利授權}\) 5. \(\color{#00EE00}{私用}\) 6. \(\color{#00EE00}{附加協議}\) |
1. \(\color{#FF3030}{責任承擔}\) |
| Mozilla | Mozilla Public License(MPL 2.0)是由Mozilla基金創建維護的,旨在較為寬松的BSD協議和更加互惠的GPL協議中找一個折衷點, | 1. \(\color{#0000FF}{公開原始碼}\) 2. \(\color{#0000FF}{協議和著作權資訊}\) |
1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{專利授權}\) 5. \(\color{#00EE00}{私用}\) 6. \(\color{#00EE00}{附加協議}\) |
1. \(\color{#FF3030}{責任承擔}\) 2. \(\color{#FF3030}{商標使用}\) |
| No license | 作者保留所有權利,不允許他人分發,復制或者創造衍生物, 當你將代碼發表在一些網站上時需要遵守該網站的協議,此協議可能包含了一些對你勞動成果的授權許可,比如將代碼發布到GitHub,那么就必須同意別人查看和fork, |
1. \(\color{#0000FF}{協議和著作權資訊}\) | 1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{私用}\) |
1. \(\color{#FF3030}{分發}\) 2. \(\color{#FF3030}{修改}\) 3. \(\color{#FF3030}{附加協議}\) |
| Public domain dedication | 在許多國家,默認著作權歸作者自動擁有,所以Unlicense協議提供了一種通用的模板, 此協議表明作者放棄著作權,將勞動成果無私貢獻出來,會喪失作品全部權利,包括在MIT/X11中定義的無擔保權利, |
1. \(\color{#0000FF}{N/A}\) | 1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{私用}\) |
1. \(\color{#FF3030}{責任承擔}\) |
參考鏈接
- https://github.com/github/choosealicense.com
- https://opensource.org/licenses
- https://www.cnblogs.com/Wayou/p/how_to_choose_a_license.html
- https://zhuanlan.zhihu.com/p/87855729
歡迎關注我的微信公眾號【MySQL資料庫技術】,
| 標題 | 網址 |
|---|---|
| GitHub | https://dbkernel.github.io |
| 知乎 | https://www.zhihu.com/people/dbkernel/posts |
| 思否(SegmentFault) | https://segmentfault.com/u/dbkernel |
| 掘金 | https://juejin.im/user/5e9d3ed251882538083fed1f/posts |
| 開源中國(oschina) | https://my.oschina.net/dbkernel |
| 博客園(cnblogs) | https://www.cnblogs.com/dbkernel |
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/295537.html
標籤:其他
