# [開源教]教我正確選擇軟體授權
## 演講影片
{%youtube raHdvb8y_-Q %}
{%youtube Q0z32UMiqTA %}

## 筆記區
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 有拘束性，在開發階段就需要區分清楚，判讀才可以有所區隔。
授權條款間彼此無法相容並存


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
> 求本日簡報供參，資料太多需要時間學習消化
> 簡報在共筆最上面ㄛ