AGPL 授權 與 閉源開源混合的問題

[Ted Chen]

大家好，

小弟目前正在準備一個 g0v 的獎助金提案，而提案的產品授權在下不知道要怎麼訂定，不知道是否適合在這裡跟大家請教意見。

我的狀況是:

我實際上已經有一個正在進行中的閉源且商業運轉中的網站系統。而在下有意把原網站系統的部分功能切割出來重新規劃及開發。

所以也就是網站的前後台系統中，會有一部分是閉源的，一部分是開源的。

而依照我目前對開源授權的了解，似乎我的狀況我會比較偏好使用 AGPL v3 授權

但是像我這樣的情形，會不會使得我也需要將我自己原本閉源的系統開源出來呢?

我的 g0v 提案在這裡:

https://grants.g0v.tw/projects/5c232d5994bbb4001bb9ab3e

系統架構圖在這裡:

https://docs.google.com/document/d/1fWEOtAc9W4ckHJ35T0zR6JLbWyjYtEwdc_ySqfLK0Nc/edit

我所謂的開源閉源會混在一起的是在 【影片搜尋前後端】這部分。

而搜尋引擎和分詞器這塊，因為不是我主要的商業核心，所以目前可能採取 GPLv3 授權，這塊應該比較沒有問題。

Ted Chen

[Rex Tsai]

可以參照 MongoDB 授權模式[1]，軟體元件跟 API 界面切割清楚便可獨立授權。
這個軟體架構的確比較適合使用 AGPL 發布。

[1] 授權流言終結者#4：MongoDB 授權的分析與探討（雙重授權模式 2.0）
https://www.openfoundry.org/enterprise-application/8687 (cache
https://webcache.googleusercontent.com/search?q=cache:2oLV4P4FnSEJ:https://www.openfoundry.org/enterprise-application/8687+&cd=3&hl=zh-TW&ct=clnk&gl=tw
)
Cheers
-Rex

> --
> 這是 Google 網上論壇針對「[ocf] 一般討論」群組發送的訂閱通知郵件。
> 如要取消訂閱這個群組並停止接收來自這個群組的郵件，請傳送電子郵件到 ocf-general...@googlegroups.com。
> 如需更多選項，請前往：https://groups.google.com/d/optout。

[Ted Chen]

蔡先生，

可能我的問題描述的不是很正確。

我的意思是，拿您提的 MongoDB 為例。

如果我自己的系統就是例中的  AGPLV3 MongoDB(裡面有 ABCDE 功能) 這一整塊。

而我打算把這裏面的 AB 這部分切割除來參加 g0v 的提案。  而我自己完整運作的商業系統是 ABCDE

這樣我需不需要把自己不打算開源的 CDE 這些功能 也開源呢?

Ted Chen

Ted Chen <shapab...@gmail.com> 於 2019年1月11日 週五 下午1:47寫道：

蔡先生，

很感謝您的回覆，我先仔細研讀您提供的文件看看。

Ted

Rex Tsai <rex.c...@gmail.com> 於 2019年1月11日 週五 下午1:02寫道：

[Rex Tsai]

我以為你的系統 ABCDE 中，其中 AB 是類似 MongoDB 的獨立元件。CDE 是透過 API 使用 AB 的組件。

依照您的好鄰居系統架構，我認為是可行的。
A 分詞器
B 搜尋引擎
C 影片搜尋平台
D 影片詮釋資料模組
E 爬蟲器

只要 AB 透過軟體架構上的抽象化隔離，就可以各自使用不同授權。

Regards
-Rex

[Ted Chen]

蔡先生，

其實我擔心的是單純 【C 影片搜尋平台 】，這塊。

口語上來解釋我的顧慮是，

如果我有一個【C 影片搜尋平台 】(內含 123456功能)，這平台裡面我 AGPL 開源了一部分的功能(1, 2, 3)，我可以因為我是那開源部分(1, 2, 3)的所有權人，

所以我自行決定不去遵守 AGPL (也就是不開源 4, 5, 6 這部分的功能) 嗎?

以實例來說，我的【C 影片搜尋平台 】開源的是

1. 搜尋頁面

2. 眾包評鑑頁面

3. 簡易的影片撥放頁面

而我專業版的【C 影片搜尋平台 】會額外包含

4. 更精緻的撥放頁面

5. 根據使用者偏好的推薦影片頁面

6. 詞彙測試頁面。

我顧慮的是  上面的 4, 5, 6 是不是會被自己的 1, 2, 3 因為 AGPL 開源了，所以也需要開源，不可閉源?

Ted 

Rex Tsai <rex.c...@gmail.com> 於 2019年1月11日 週五 下午3:57寫道：

[Rex Tsai]

是的，技術解決方式是您可以模組化進階功能。

Ted Chen <shapab...@gmail.com> 於 2019年1月11日 週五 16:58寫道：

[Bob Chao]

另一路想法：

1. 在剛開源的時候每行程式的權利基本上都還完全是你們的，既然這樣就沒有什麼「授權條款」的問題

2. 接受外部人士貢獻的時候需要請他們簽貢獻條款，對你們公司做特別授權並且同時對外以 AGPL 授權那類。只有簽署相關條款的人發的 patch 才 merge 進來用到線上。

但是弄模組化或許是直接一點

~Bob

Rex Tsai <rex.c...@gmail.com> 於 2019年1月11日 週五 下午5:22寫道：

--

Po-chiang Chao  (:BobChao)
Mozillian and Creative Commoner, Taiwan
http://twitter.com/bobchao

[Ted Chen]

Bob,

很感謝您建議了另外一種解法，這個解法我反而覺得在初期似乎也比較好執行。

因為我們目前討論的那個基本上是有頁面的、應用程式層級的原始碼，我想所謂的模組化應該不是把那一些開源的掛在不同的 URL 就好了吧？

比如 

Http://mysite/basic

Http://Mysite/premium 

還是這樣的 URL 區分就可算模組化？

Ted

Bob Chao <bob...@gmail.com> 於 2019年1月11日 週五 下午6:18寫道：

[Ted Chen]

Bob, Rex,

我在重新 review 我的系統設計圖時，好像突然領悟到你們說的技術上，模組化可行這件事情了。

例如，如下圖，

比如我的部分系統前後台的程式碼採用 AGPL,   如果我怕太感染到我所有的 code, 我就另外抽出來比如 影片詮釋資料模組(也就是Data Access Layer)，這部分採用例如 GPL 授權。  這樣就能避免我其他不適合公開的原始碼，最後因為有接受到其他外部來的原始碼，而逼得自己需要公開了。

這樣理解對不對呢?

Ted Chen <shapab...@gmail.com> 於 2019年1月11日 週五 下午7:02寫道：

[LUCIEN C.H. LIN]

Ted、Rex，Bob好，

經基金會那邊告知才知道這邊有討論串，那我一併將經驗分享節錄如下，分享一下處理相關事務的經驗！

不過是這樣，OCF 協助 g0v 補助專案來處理金流，但 OCF 不直接涉入 g0v 專案的運作，所以採用 AGPL-3.0 做為補助專案申請，哪些開源的部份要公開或提交給 g0v 獎助金專案，可能還是需要 g0v 獎助金專案法律顧問 Isabella Hu 的確認。但就開源授權的管理和處理，我就個人身份，提供一些實務上協助過的處理意見。

大致是：

1、如果我猜的沒錯，Ted 預定使用 AGPL-3.0，是因為其高度的授權拘束性，希望其他人拿了程式源碼去用後，也必須把自己改作的部份再提供出來？

2、然而有些部份您本身是不希望採開放源碼處理的。

3、AGPL-3.0 的基本框架是，一個統合軟體作品(as a whole)，各部份不能切割使用時，或副元件大部份的功能都必須依賴主元件，並且開發上也必須亦步亦趨參考主元件時，該副元件視為主元件的一部份，所以若主元件是 AGPL-3.0，則副元件也必須得是 AGPL-3.0。

4、然而當主元件、副元件的作者都是同一個人的時候，當然「自己不會告自己」，所以這個爭議當主元件及副元件作者歸一時，現實上就不會存在，但是會容易引發誤會，因為主元件開源出去，若別人改了就要開源，原作者自己再做副元件，為何不用開源，雖然可以一次一次的說明，但畢竟容易產生誤會，所以我的個人建議是盡量不要讓它太複雜。

5、實務上另一個處理方式，就是主元件是一個類似 MongoDB 這樣資料庫、函式庫(database / library)的作品，其提供 Well defined API，來供其他應用程式存取，並且 API 部份，會採寬鬆的開源授權釋出，例如過往 MongoDB 在 API/driver 的部份，就採 Apache-2.0 來提供，由此來和其他開發者表示：

(1) 改到 AGPL-3.0 的部份，就要照 AGPL-3.0。

(2) 但如果擔心 AGPL-3.0 的擴散範圍被過度解釋，則可以去看那些原作者提供的，採 MIT 或 Apache-2.0 提供的 API，如果只是抄這些 API 的必要函式來寫應用程式，最後 bundle 在一起使用，那解釋上這些個別的應用程式，或呼叫介面，並不是 AGPL-3.0 授權的衍生作品，從而就沒有 AGPL-3.0 授權擴散的爭議。

這樣的實作，您可參考 RedHat 近年力推的專案 ansible 作者群的解釋：https://github.com/ansible/ansible/issues/8864

大意是外圍的社群開放者提報問題，詢問使用 ansible 部份源碼來寫 inventory plugin，會不會讓這個 plugin 被 GPL-3.0 拘束？

ansible 開發團隊的簡要回覆是：

(1) 不一定，但用到就要變 GPL-3.0，這不是本團隊的解釋態度。

(2) 一般來說重製了本來檔案裡的源代碼到另外的 plugin，可能會啟動 GPL-3.0 授權拘束。

(3) 但如果這個 inventory plugin 從頭到尾都是由社群朋友自己寫，那團隊的態度是，該 inventory plugin 可以由撰寫者自行決定授權。

(4) 在一些 Interface 的溝通資訊，ansible 是採 permissive license 來提供，若是僅取用這個部份，就更沒有問題。(the shared code that gets mixed into modules you write is explicitly BSD)

(5) 進一步的指示可以閱：http://docs.ansible.com/ansible/latest/dev_guide/developing_inventory.html

(6) 其實 Linux Kernel 從去年開始，部份有 API 特性的檔案，作者們也有的主動標上 BSD、MIT 這類寬鬆的授權了，就是要消弭類似的爭議。

大致如上，簡單來說：

1、g0v 補助專案可能會和您確認您要開源的範圍，該範圍視為一個獨立作品。

2、當開源的範圍確定之後，建議您另行採 MIT/BSD/Apache-2.0的授權主動提供一些 API 的說明或檔案。

3、一般來說，API 聯動的雙方，可以被視為獨立的不同元件，這樣您主程式採 AGPL-3.0，以及操作介面要另採非開源的方式，在解釋上可以成立，也比較不會產生使用者的誤會。

以上一些經驗供參。

20190115 15:30 Lucien