# [開源教]教我正確選擇軟體授權 ## 筆記區 slide:https://drive.google.com/file/d/1B4La6GRGc95TLu0IG4zowkr1or6aF_4g/view ### 開放授權 Open Licensing 1. Open 的東西才能 reuse 跟 release,達到最大的效益。 2. 106 年資訊服務採購範本加入 Open license 規定(你如果沒能力規劃:你怎麼拿到就怎麼給我,全部交出來!) 3. 開放授權並不是放棄著作權利。 4. 開源訴訟趨勢 - 個人 vs. 企業 -> 企業 vs. 企業 - 開源成為一種企業競爭模式 BSD 類:無拘無束的自由 其他類:特別的商業模式,由基金會或大型組織,Source code 像 GPL,整體使用像 BSD GPL 類:(火焰的顏色)大家都必須要一直自由,你不管怎麼使用作品,都需要接續創作者提供的開源授權方式。 ### GNU GPL 授權 (大家必須一直自由) #### GPL 1. 修改 GPL 程式產生的衍生程式,需採用 GPL 授權 (Based on) 2. 只要有就可以要: Object code, Binary Form -> Source Code, Source Form 3. 與 GPL 程式關係密切,稱為 GPL 衍生程式,所以散布時也須公開原始碼 (有 Binary 才要給) #### LGPL 1. 能用 LGPL 釋出的一定是函式庫 (Library) 2. 連結利用:如果是依照本來 Library 的界面來操作,最後散播的程式要不要公開看個人 3. 如果有修正過 Library 內容,你必須使用 LGPL 公開新的 Library #### AGPL 1. 應付 ASP (Application Service Provider) 2. AGPL-3.0,前半部與 GPL 相同僅在最後不同:把網路服務視同散佈 Binary 3. e.g. CKAM, ghostscript Q:如果我使用了某個程式,他後續更改的授權,我會受到影響嗎? A:如果你沒有使用新的版本,你就不會受到新的授權影響 ### 其他開源授權 #### BSD 類 (Permissive licenese) 1. BSD/MIT 2. 幾乎無拘無束的自由,散佈者有權力決定接續的授權方式,但是需要表述著作人的聲明。若達成此點,接下來做什麼授權皆具有合法性。 - C & D - 著作權聲明 (Copyright Notice):你必須表述我的著作權聲明 - 免責聲明 (Disclamier):也必須將免責聲明表述,壞ㄌ不能怪我 #### Apache-2.0 ():增加商業配置 1. 用十倍以上的廢話將 MIT/BSD 說明清楚 2. 明示:**商標權**未授權 3. 明示:可收費提供擔保 4. 專利授權規定 - 專利反制條款 (如果後續使用者是遵照授權合理使用,不能告專利) - 在這個領域裡面我們不喜歡談專利(若以專利提告,則專利著作人可以直接撤銷使用者權力)←這樣嗎?? #### 其他類 Sometihng-based:還是要求 Source 必須 Open,但是比 GPL 又把界線寫得更清楚 - 檔案基礎的獨立性 (檔案可以分,授權就可以分) - MPL,CDDL - 模組基礎的獨立性 (抽象的功能、模組可以分,那授權就可以分) - EPL, CPL - 最後的結果可自己決定,但是中間使用了以上授權需要告知 Copyleft licenese:往後不斷拘束,不管你怎麼改,後面都要遵守前面 ### 實戰!選一個適合的授權吧! 1. 分析授權狀態 - 妥善專案開發流程 (程式開發紀錄簿) - BLACKDUCK / 源碼掃描的商業方案 - FLEXERA / 源碼掃描及商控方案 - FOSSID / 源碼掃描及商控方案 - FOSSOLOGY / 授權資訊掃描開源方案 - BAT / 目的碼掃描開源方案 - 前三者都是將 Open source project 砍回來分析進行比對 CC SA 是可以往後擴充的,再往後可以擴充成 GPL3.0 (我覺得我漏一點東西ㄌ) #### Open source 的重點是列清單 清單 example ``` project: web:專案網址 version:版本 & 下載連結 License: SPDX:開源領域的標準標示方法,避免名稱與別稱的誤用。通常放入授權方式的簡稱簡寫, 若授權方法未在裡面看到,可能就不是開源授權(延伸功能待補) Copyright Notice: Disclamier: ``` #### 授權版本相容性(寬的可以變嚴的,嚴的不能變寬的) GPL 有拘束性,在開發階段就需要區分清楚,判讀才可以有所區隔。 授權條款間彼此無法相容並存 ![](https://i.imgur.com/bp1Zs15.jpg) 1. 水火不容:兩種授權方式若都需要衍伸作品跟從原授權方式,是要跟誰的啦 2. 蛇吞象:GPL大熔爐。較寬鬆的授權方式被嚴謹授權方式併吞。易發生於在軟體開發階段漫不經心,很多授權寫在一起分不清楚,若有法律訴訟情狀,即可能裁示通通大 Open。 3. 將所有使用到的專案都寫出來,各個授權標示清楚,誰也不吞誰,讓商業使用者自己判斷。 #### 商業公司如何區分政策? - 使用上是 內部、外部、雲端 - 來辨別是否散布/散佈程度 - 一個雲端可能突破內外部 - 定調原則 - Source Open for All : GPL 類 - Modified Source for all : 其他類 - No Source at all : BSD 類 - 必須容許例外 :::warning 改做的定義是修改,如果只是當作工具使用,視為內部使用,授權條款不影響個人使用(不影響創作者著作權利) ::: #### 使用開源發展商業服務之相關注意事項? - 內部能共享的**版控系統** - 託管平台至為重要 #### Shareware vs. Freeware S:使用至某程度之後,必須要付出費用才可繼續以商業方式使用/分享/改做。 F:可以自由修改、自由散佈,不限定使用目的。 #### 到底是不是 OpenSource - 看官方授權列表 (Licenses by Name - SPDX 有沒有簡寫 #### OpenSource 是可以被商業使用的 - 須遵守各自 OpenSource 的規範 - 列清單!哪些使用了 GPL / AGPL #### 小故事 FreeAdhoccUDF 侵權與和解 - 我全部混在一起了,不知道哪塊是哪塊 - 那你只好全部 Open la. JDK 的商業方案 - 試用方案,真的開始商業使用後要收費 Commons Clause: 附加商用禁止條款 - 認為造成混淆 - 成為 Redis Source Avaiable License (RSAL),並非 Open Source 授權 MongoBD: Server Side Public License (SSPL) 看著你的程式寫程式 vs. 程式共享 GPL2.0 與 3.0 的差別 - 因為 2.0 是 1991 年,對於網路傳播沒有太大的概念,所以認為是要燒光碟給別人 source code,後來有人用了 2.0,雖然有放在網路上,但是沒有給光碟,所以被寫信(?) - 3.0 加入了網路散播,並且加入軟體專利的條款,類似 Apache 授權,合理使用不能告侵犯專利。 - 3.0 加入針對 User product:常態性使用商品,必須公開源碼(並且要可以在原產品上使用,不能有「我有給Source 只是它不能跑R」的狀態) ### 小語錄 ``` 宗教法人法成立後就成立開源教吧,不要成立法人了! 打不過你就加入你,加不入你就買下你! 太小不告,不想要讓Open Source產生寒蟬效應,大家都不敢用 太大不告,你是面對一個足球團的律師! Source 我有給啊,只是他不能跑 ``` ### 參考 [什麼是opensource 樂高版](https://www.youtube.com/watch?v=6NhyCXJU-IQ) 行政院公共工程委員會 資訊服務採購範本 106.7.13版,第16條第3項第6款 [SPDX](https://spdx.org/) [Licenses by Name](https://opensource.org/licenses/alphabetical) ## 發問區 > [name=Rock Hua-Chao Hung]安安你好幾歲 > test > 求本日簡報供參,資料太多需要時間學習消化 > 簡報在共筆最上面ㄛ