您好，我們公司最近寫了一個Java library，長官考慮要將它Open Source，主要的需求如下

• Open之後，仍希望用戶可以持續回饋給我們，而不是自己拿去enhance，卻不跟我們說


• 考慮使用Dual License，假如用戶欲將之商業用途，不想open，此時我們打算跟用戶收取一定費用


• 如用戶需要我們提供服務，也是會另外收取一定費用

在貴網站爬了文之後，發現使用GPL v3或是LGPL v3，似乎是比較符合長官需求的
但我們的library使用了兩個Apache License 2.0 授權的軟體元件(是我們主要功能的一部分)
所以我的問題如下...

1. 就此討論中得知，GPL和Apache授權並不相容，所以除了要將它們全部重寫之外，唯一的方法是不是只剩下跟此兩個軟體元件的copyright owner要求重新授權？


2. 還是說除了GPL類型之相關授權之外，您還有其它建議可以提供的呢？


3. 假如最終我們授權的部分確定了，之後需要跑什麼流程嗎(both opensource and commercial)？

我是第一次來到貴討論區發問，如有什麼不週到的地方請跟我說，謝謝您

Hi takeshi_miao，

首先、非常感謝您在論壇中詢問這個問題，這才讓我發現之前回覆子標題的筆誤！

在原討論串「https://www.openfoundry.org/tw/forum?func=view&catid=8&id=700#705」之中，回文的子標題寫「三、Apache-2.0的授權方式為何不相容於GPL-3.0的授權方式？」，但實際上這句話因為筆誤將GPL-2.0，錯打成GPL-3.0（標題後的討論內容是正確的），應該改為「三、Apache-2.0的授權方式為何不相容於GPL-2.0的授權方式？」

所以我將修改內容加到原討論串裡：更正！原文為筆誤typo，Apache-2.0的授權方式是不相容於GPL-2.0，但只要能適用GPL-3.0第7條的額外添附條款-Additional Terms，則Apache2.0與GPL-3.0是相容的！

希望不會造成其他讀者的誤解。

----

那麼、以下接續回覆您提出的三個問題：


問題一、就此討論中得知，GPL和Apache授權並不相容，所以除了要將它們全部重寫之外，唯一的方法是不是只剩下跟此兩個軟體元件的copyright owner要求重新授權？

Apache-2.0與GPL-3.0的授權方式是相容的！所以在您的這個案例上，可以逕使用GPL-3.0、或是LGPL-3.0的授權方式，來釋出貴公司所撰寫的Java Library即可。

問題二、還是說除了GPL類型之相關授權之外，您還有其它建議可以提供的呢？

如果是讓使用者可以持續回饋(feedback)，又打算用Open Source併合商業授權的雙重模式，那麼「GPL+商業授權（例如MySQL）」或是「LGPL+商業授權（例如QT）」確實是一般最常見到的雙重授權模式，我個人的看法是、如果貴公司所撰寫出來的這個Java Library已經成為一定程度的規模經濟了，那麼可以採行「GPL-3.0+商業授權」的方式（例如Sencha這個專案的Framework與Library），而如果貴公司的Java Library還在推廣階段，則可以採行「LGPL3.0+商業授權的方式」，後者的方式因為採用LGPL-3.0，故單純呼叫此Library來存取數據，並不一定會開啟LGPL-3.0函式庫的授權拘束性，從而也可以達到愈多人使用的推廣效果。（前例的Sencha Project，在推廣初期也是使用LGPL的方式來釋出其函式庫，待成就一定商業規模後，才在新版本改採GPL的方式來釋出其程式碼。）

問題三、假如最終我們授權的部分確定了，之後需要跑什麼流程嗎(both opensource and commercial)？

有幾個重點的流程建議：

(1) 在這個Java Library每個重要檔案的檔頭，都加上其簡要的授權聲明資訊，商業版本的就加上商業版本的授權資訊，Open Source的版本就加上Open Source版本的授權資訊，例如：

A、商業授權版本：XXX Java Library, 2012 © YYY Corp. All rights reserved.

B、Open Source授權版本1：XXX Java Library, 2012 © YYY Corp. Distributed under GNU Lesser General Public License v3.0 at www.YYY.com/xxx-project

C、Open Source授權版本2：XXX Java Library, 2012 © YYY Corp. Distributed under GNU General Public License v3.0 at www.YYY.com/xxx-project

(2) 如果是Open Source的版本，並用GPL-3.0或是LGPL-3.0來對外釋出時，必須將GPL-3.0或LGPL-3.0授權條款的全文檔案，放在該專案程式的根目錄下，建議將此檔案命名為legal或是license，以純文字的格式來儲存即可。

(3) 設立專案網頁「https://www.YYY.com/xxx-project」，並建立雙重授權的說明頁面「https://www.YYY.com/xxx-project/license」，右列Sencha專案的連結便就是一個參考範例：https://www.sencha.com/products/extjs/license/

約略是這樣，若是後續有衍生的相關疑問及問題，再請您隨時提出來討論！



敬祝 順心健康、事事如意

20111212 1630 LUCIEN C.H. LIN

非常感謝您的回覆，解除了我們不少疑惑，也更確定了方向！
但跟同事討論後，又多了幾個問題想再跟您請教，如下

1. 出於好奇想再跟您確認一下，我們的Java Library除了使用Apache License的元件之外，剩下的都是我們自己的實作了，仔細一想，我們的情況又似乎跟之前的網友的提問不大一樣(Apache + GPL merge to one product)；假如我們採行的是GPL/LGPL v2的話，仍然會遇到我所提問的 「必須要重寫Apache元件或是跟Copyright Owner要求重授權」的情境，是嗎？

2. 延伸上題...

2.1 如果是的話，可否再跟您確認其概念為何？
Apache License 2.0不是允許可以作重授權的動作嗎？假如我們先把使用到的兩個Apache License的軟體元件進行重授權至GPL/LGPL v2，merge進我們的library，再將我們自己的Java Library授權為GPL/LGPL v2，這樣問題是出在哪裡呢？

2.2 (重授權 == sublicense == relicense) 我這樣理解對嗎？

3. 我有去過貴網站提供的授權精靈和授權條款比較表　觀察到以下訊息

授權精靈
授權他人使用程式中的專利 -> N -> GPL & LGPL

授權條款比較表
您願意將程式所包含的專利授權出來嗎？ -> 否 -> GPL & LGPL

3.1 這兩個工具應該都是針對GPL/LGPL v2的版本是嗎？

3.2 表示為"否"，應該是"未定義"，而不是"禁止"的意思，是嗎？

3.3 假設我們的Java Library要申請專利...

3.3.1 在GPL/LGPL v2版本之下，我的理解是...因為是"未定義"，所以在GPL授權之下，後手不會受到專利的限制；然而，假如後手是用在商業用途的話，就必須來跟我們談商業授權，是嗎？

3.3.2 在GPL/LGPL v3版本之下，有明定專利授權條款，我的理解是...情境仍跟上題一樣，只是對於GPL授權的後手而言，在法律上就更有保障(不會受專利侵犯訴訟)了是嗎？


再次感謝您的幫助~
P.S. 在台灣能有這種類型的網站幫助我們真的是太棒了！我自己一向都拿來用，還從來沒考慮過相關license issue，所以問了不少笨問題，還請見諒

Hi takeshi,

不要客氣，只是有時候工作上排定的事務忙的時候，會稍遲才能回覆您的問題，這點還請見諒。

以下依您提出來的相關問題做一個簡要的回覆。

1、新編撰的Java Library大抵是自己重新寫就，但其中內含兩個Apache-2.0授權的重要元件、且此兩元件為函式庫的主要功能之一，而這樣的狀況、如果想將Java Library裡自行撰寫的部份採用GPL-2.0或LGPL-2.0授權釋出，需不需要將其中內含的Apache-2.0授權元件重新撰寫，或是洽詢其著作權利人重新授權，來與Library裡GPL-2.0、LGPL-2.0授權的部份取得授權相容性？

簡答：看狀況來定，就授權理論的方面、最好的作法還是將Apache-2.0授權的部份同步改授權，但是實務上也有很多直接保留Apache-2.0授權狀態的例子！

(1)如果自行撰寫的部份採用GPL-2.0或LGPL-2.0授權，但是與此二Apache-2.0元件之間的互動存取關係是一般所謂「動態連結（Dynamic Link）」的關係，則原則上兩種授權狀態是可以併存在一個專案裡的，因為這種狀態下、一個專案裡分別以GPL-2.0與Apache-2.0授權的元件，可以被視為獨立而分開運作（Separate and Independent）的程式。

(2)如果自行撰寫的部份採用GPL-2.0或LGPL-2.0授權，但是與此二Apache-2.0元件之間的互動存取關係是一般所謂「靜態連結（Static Link）」的關係，則原則上兩種授權狀態是不可以併存在一個專案裡的，因為這種狀態下，一個專案裡雖概念上有以GPL-2.0與Apache-2.0分開授權的兩部份，但由於運作上這些程式碼密不可分，所以會整個被解釋為核心元件的「衍生著作」，而再因為GPL-2.0授權的部份會有授權拘束的外擴性（Copyleft），則理論上此時整個專案的散布者、應將Apache-2.0元件的部份，透過重新撰寫或是另取得授權的方式，將其改為GPL-2.0或LGPL-2.0的授權元件，然而在許多不具營利性的社群專案，很多的專案開發者其實是逕予保留原來Apache-2.0的授權狀態，這是因為Apache-2.0授權的元件，本身必然也在散布上可取得元件的程式源碼，所以雖然沒有完全依照理論將其轉為GPL-2.0授權，但不容易引發太大的授權爭議，但是、如果是商業性的散布，則有時候便會看到GPL-2.0元件部份的撰寫者提出抗議的例子。

2、「再授權(sublicense)」與一般口語所說的「重新授權(relicense)」是同一件事嗎？還是兩者之間有什麼差別？

簡答：「再授權(sublicense)」與「重新授權(relicense)」不是同一個概念。前者、sublicense是一個法律詞彙，代表「被授權人轉以授權人的地位，將某個他從別人身上取得的權利，轉授權給其他的被授權人。」後者、relicense是一個口語詞彙，代表某個東西之前被授權過，但可能以改變對象的方式授權給其他人，或是以改變內容的方式，重新授權給同一個人。

(1)sublicense的內涵有兩個重點：

A、轉授原作者的權利給其他人

sublicensor轉授來自original licensor的權利給其他的licensee，例如A程式本來是作者甲以Apache-2.0授權釋出的，甲將這個A程式以Apache-2.0的方式散布給乙，而由於Apache-2.0允許sublicense，所以乙「可以用自己的名義」將這個A程式，或是修改A程式之後衍生的B程式，以GPL-3.0的方式「轉授權」給丙

B、轉授權的範圍不超過原作者本來的授權範圍

「sub-」這個字首在英文的字義裡有「附屬、次級」的意思，從這邊我們可以了解到，sublicensor轉授權給其他人的權力範圍，不會比他直接從original licensor那邊得到的權利還大；這也就是為什麼、如果一個C程式，原作者甲以MIT授權的方式釋出給乙，乙可以依「sublicense」的方式將原C程式、及衍生後的D程式，轉以Apache-2.0的授權方式釋出給丙，而丙也可以依「sublicense」的方式將D程式衍生後的E程式，轉以GPL-3.0的授權方式再釋出給丁，這個再授權的模型、在條款別方面是：MIT→Apache-2.0→GPL-3.0，那可不可以將Apache-2.0的元件「再授權」之後以MIT釋出呢？這是沒有辦法的，因為「再授權」的範圍，不能去大於「原始授權」的範圍，所以比喻來說，MIT授權方式裡的義務性要件可能有「Ⅰ、Ⅱ」兩款，所以這隻程式可以被再授權為Apache-2.0，因為Apache-2.0的義務性要求可能有「Ⅰ、Ⅱ、Ⅲ、Ⅳ」，恰恰涵蓋了原來MIT中的「Ⅰ與Ⅱ」，而之後的GPL-3.0的授權義務性要求有「Ⅰ、Ⅱ、Ⅲ、Ⅳ、Ⅴ、Ⅵ」，也可以涵蓋Apache-2.0中的「Ⅰ、Ⅱ、Ⅲ、Ⅳ」，所以說、為什麼Apache-2.0授權的元件不能被轉授權為GPL-3.0呢？這是因為Apache-2.0的義務性要求有「Ⅰ、Ⅱ、Ⅲ、Ⅳ」，但自由軟體基金會認為GPL-2.0的義務性要求只有「Ⅰ、Ⅱ、Ⅲ、Ⅴ、Ⅵ」，此處少了原本在Apache-2.0條款裡的「Ⅳ」要件，才會造成Apache-2.0的元件，在自由軟體基金會的解釋下，不能逕自「再授權」為GPL-2.0（但可以被散布者逕行再授權為GPL-3.0）。

(2)relicense的內涵也有兩個重點：

A、重新授權給不同的對象、或是重新授權給同一個對象但不同的授權內容

比方說、A程式本來是由甲以MIT的授權方式散布給乙，而丙知道乙有這隻程式，但乙並不願意散布給丙，那麼甲知道之後、可能口頭和丙說，那我再授權（re-license）一次給你好了！而或者、A程式本來是由甲以GPL-3.0的方式散布給乙，但乙認為以GPL-3.0的方式並不適合他商業利用，所以向甲詢問其他的授權方式，此時甲如果同意的話，可能便會「relicense」重新選擇MIT或是Apache-2.0的方式，再次授權這隻程式給乙。

B、再次授權會是一個全新的授權關係、全新的授權內容

relicense就是一個全新的授權關係，所以在對象上可以和原來的授權關係不同，在範圍上也可以大於或是等於或是小於原來的授權範圍。

3、如果透過Apache-2.0授權條款裡的「再授權(sublicense)」機制，不是可以將Apache-2.0的授權元件轉為其他的自由軟體授權方式嗎？那麼若是將原本Apache-2.0授權的元件，改為GPL-2.0授權的元件，便應該可以和其他以GPL-2.0或LGPL-2.0授權的Java Library直接相容？

簡答：依照上述「轉授權範圍不得超過原授權範圍」的原則，其實Apache-2.0的授權元件是沒有辦法被sublicense為GPL-2.0或LGPL-2.0授權的元件的，但是可以sublicense為GPL-3.0或LGPL-3.0授權的元件，所以走這個處理方式，應該就是將此二個Apache-2.0授權的元件，sublicense為GPL-3.0或LGPL-3.0的授權方式，再和以GPL-3.0或LGPL-3.0授權的Java Library直接相容。

4、目前License Wizard在GPL的部份，是不是只有處理到GPL-2.0的授權內容，而不及於GPL-3.0之後的版本？而其中「授權他人使用程式中的專利」這個子題，如果選否、是不是指的就是「未定義」，而不是「禁止」的意思？

簡答：是、目前OSSF製作的License Wizard，不論是2.3或是3.3版，精靈的指引內容都是以GPL-2.0與LGPL-2.0為範本，而還沒有拓展到GPL-3.0與LGPL-3.0上；而「授權他人使用程式中的專利」這句話，如果選否，可「同時解釋為未定義、但同時也代表禁止」的意思。

關於「授權他人使用程式中的專利」如果選否，解釋上為何同時代表「未定義與禁止」的意思？這部份我稍作解釋，因為智慧財產權的領域裡，原則上是「未經明示授權的部份均推定為未授權」，所以說若是一個自由軟體授權條款中，沒有明定的專利授權條款，那就代表此一程式的著作權人，就算一併將其專利權寫進程式裡，那麼依據自由軟體授權條款使用這隻程式的其他人，也只是在「著作權」的方面得到合法授權，但專利權的部份還是沒有得到授權！所以說若是該自由開源軟體授權條款中沒有專利條款，那麼依法律的預設，原作者就是沒有要將專利權利一併散布出去給他人使用。所以當初在設計這個License Wizard時，所著眼的其實是「授權他人使用程式中的專利」選「是」的對象，這些選「是」的條款、就是在條款內明定一併將著作權與專利權合併公眾釋出的條款。

而附帶一提，GPL-2.0/LGPL-2.0有沒有明示的專利授權條款，這部份是有爭議的，Richard Stallman本人認為透過「解釋」，GPL-2.0與LGPL-2.0是有專利授權的規定的，但很多人持不同看法，這部份進一步的資訊，可以參照我與葛冬梅小姐合撰的專文「GPL2 第 7 條淺評」：www.openfoundry.org/tw/legal-column-list/894-gpl2-7-，這篇文章是肯定GPL-2.0可以透過解釋、得到有專利授權條款的結論，不過畢竟還是具有爭議性，故我們在設計License Wizard時，還是將GPL-2.0/LGPL-2.0的部份，定義為沒有專利授權的條款類別，以避免產生使用者誤認的狀況。

5、如果Jave Library要申請專利，那麼其所選用GPL的版本是2.0或是3.0會不會專利授權金能否收取的差異？

簡答：是的、會有很大的差異。GPL-2.0沒有大家共認「明定的」專利授權條款，所以也有一派的看法是，如果該GPL-2.0程式帶有專利，那麼使用者即使以GPL-2.0的授權規則來商業使用這些程式碼，仍然要與其專利權人洽談專利授權費用；然而、GPL-3.0預設規定是，若散布程式者將其專利權寫進該程式，則收後程式的後手一併從其手上得到了專利授權，只要後手運用此一程式的商業模式，不去逾越GPL-3.0的相關規定，則其便不需再向這些將專利寫進程式的散布者，再次洽談專利權的授權費用。

這部份的相關問題其實頗為複雜，進一部的相關資訊，亦可參照我在本年度11月撰寫的專文「備位啟動的自由開源專案軟體專利」：www.openfoundry.org/tw/legal-column-list/8498-standby-software-patent-free-and-open-source

希望上述的這些資訊對您有所幫助！



20111216 1800 LUCIEN C.H. LIN

Dear C.H.

我收到您的回覆了
您的回覆和所附的參考文章「備位啟動的自由開源專案軟體專利」，對我的幫助相當大
我想我有充足的資訊，可以著手進行相關事項了

感謝您~ (當然如果之後遇到問題，我還是會來叨擾您啦 )