您好，

最近我們的實驗室有打算要發佈一個open source的工具，這個工具之中，連結了另外兩個open source的程式(皆以DLL的形式被連結)，被連結的程式為：

1. SPAMs 2.5 (link) - GPLv3
2. Extended WPF Toolkit Community Edition (link) - MS-PL

我們遇到的問題如下：

1. 由於SPAMs為GPLv3授權，我們工具的授權條款是否只能選擇GPLv3呢？
2. 如果我們的工具只能使用GPLv3，由於MS-PL為GPL incompatible (link)，是否不能使用Extended WPF Toolkit呢？還是說能夠照這個討論串(link)中Kosmatos的說法做呢？
3. 如果以上的問題以email不容易清楚回答的話，可以跟你們約時間做當面諮詢嗎？

麻煩你們了，非常感謝。

Hi dnaoh,

首先，真是非常抱歉，近日列入排程的外出與相關事務實在太多，一直拖遲到今日才回覆這個討論問題。

您的問題大抵是：GPL-3.0的程式與MS-PL授權的元件，依GNU Project的解釋是不具相容性(incompatible)的，那麼是不是在實際運作上只有這個鐵律能夠遵守，因為若是如此，似乎在專案開發上，只能捨棄MS-PL授權的Extended WPF Toolkit Community Edition，而不能讓它與GPL-3.0授權的SPAMs 2.5合併運用？

嗯…如果要一句話來破解這個疑慮的話，我的解讀是：若是您能夠讓此二程式摻合(commingle)後的專案運作架構，是彼此獨立而非直接相依，則有實作的可能性；若無法達到這樣的機制，則無法。

以下我重點說明：

1. MS-PL在解讀上，是比較近於BSD類般較寬鬆的permissive license，然而，它被包覆在binary格式的專案裡被使用的彈性非常大，卻有一個特點是：要求若是以程式源碼(Source Code)格式提供，便一定要延續MS-PL的授權方式來提供。((D) If you distribute any portion of the software in source code form, you may do so only under this license by including a complete copy of this license with your distribution.)


2. 而GPL-3.0要求，其他元件直接與GPL-3.0授權的程式碼融合(merge)在一起而成為一個整體(as a whole)，則日後散布必須改採GPL-3.0授權的方式來被利用，也就是說：散布了該融合專案的程式目的碼，依GPL-3.0就必須應要求來提供程式源碼，而此時提供的程式源碼，在融合狀態下也必須一併使用GPL-3.0的授權方式來提供，此時，就和前述MS-PL的授權義務性要求「以程式源碼格式提供須延續MS-PL的授權方式來提供」產生衝突！這也是為何GNU Project會將MS-PL列入GPL-3.0不相容清單的主要原因！


3. 解法不是沒有，但就是比較迂迴且目前沒有人敢說通案必然可行。其實討論串中Kosmatos已經把可能的解法「暗示」出來，但沒有把話說盡說清，畢竟這個解法要看個案的狀況，有時不是三言二語就能解釋清楚，或是符合每個人對授權應用的解釋的。簡要的說，這個所謂的解法，就是訴求摻合非融合(commingle ≠　merge)，而主張SPAMs與Extended WPF Toolkit Community Edition具有相當程度的獨立性，而如果是獨立元件的話，依GPL-2.0、GPL-3.0，其授權拘束性也不是無限制的擴散到所有相互動的元件。所以Kosmatos才會在討論串中直接講結論：1. 保持MS-PL授權元件的原始授權狀態與權利聲明，2. 不要將MS-PL授權的元件改授權為GPL-3.0授權，其實這樣的主張，就是訴求該MS-PL元件與GPL-3.0授權程式之間，是具獨立性的互動關係，而不是授權狀態必然統合在一起成為一個整體的融合關係。

關於如何主張獨立性進一步的說明，我在2011年有一篇專文是針對GPL授權程式的授權拘束與擴散範圍進行說明，分為上下二篇，雖然行文較為艱澀，但所分析與披露的資訊還算中肯，提供在此供您作個參考。

• GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍（上）：www.openfoundry.org/tw/legal-column-list/8446-the-license-inheritance-bounds-of-gnu-gpl-01


• GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍（下）：www.openfoundry.org/tw/legal-column-list/8447-the-license-inheritance-bounds-of-gnu-gpl-02

後續若有進一步的疑問，歡迎隨時提出來與我接續討論。

謝謝了，並敬祝　順心健康、事事如意！



20140729 10:50 LUCIEN C.H. LIN

Dear Lucien,

謝謝您抽空回答我的問題。

1. MS-PL在解讀上，是比較近於BSD類般較寬鬆的permissive license，然而，它被包覆在binary格式的專案裡被使用的彈性非常大，卻有一個特點是：要求若是以程式源碼(Source Code)格式提供，便一定要延續MS-PL的授權方式來提供。((D) If you distribute any portion of the software in source code form, you may do so only under this license by including a complete copy of this license with your distribution.)

不好意思，關於上面引用的這一點，我有一些細節想要再跟您確認一下。

在我的個案之中，Extended WPF Toolkit Community Edition是以binary(.dll)的方式被加入到我的工具之中(沒修改Extended WPF Toolkit的程式源碼)，所以我的工具在釋出時，不會包含Extended WPF Toolkit Community Edition的程式源碼，這是不是代表說我的工具不需要延續MS-PL呢?(換句話說可以用GPL-3釋出)

再次感謝您的回答，祝 事事順利！

Hi dnaoh,

所以依照你的表述，Extended WPF Toolkit Community Edition這隻程式本來就是獨立專案，並不是與GPL-3.0授權的SPAMs 2.5有開發承襲或參考的關係，並且直接以binary的.dll動態呼叫的方式，即可以被SPAMs 2.5引用。那多數的通說，會認為這兩個程式之間的互動方式，是屬於「彼此獨立(Independent and Separate)」形式的關係。

如果是這樣，我的建議是不需要將Extended WPF Toolkit Community Edition轉以GPL-3.0授權，因為一旦轉為GPL-3.0授權，那就是Binary以GPL-3.0散布，則後續也必須以GPL-3.0的方式，來提供你所使用Extended WPF Toolkit Community Edition版本的Source Code。（GPL-3.0的授權規則：提供了GPL-3.0授權的binary code，後續就必須向收受binary code之人，同採GPL-3.0的方式來提供Source Code。）而是直接在說明文件裡，言簡易賅的表明：該Extended WPF Toolkit Community Edition雖被包入專案裡運作，但是採.dll方式直接引用其binary form，所以該Extended WPF Toolkit Community Edition元件延續其MS-PL的授權方式來提供，視為專案裡與GPL-3.0程式互動，但僅單純呼叫功能的獨立元件。

做了這樣的聲明，原則上就是SPAMs 2.5是採GPL-3.0授權，而Extended WPF Toolkit Community Edition是採MS-PL授權，兩者的授權狀況因運作上的獨立性而不互相干涉和影響。而設若未來你散布了整個專案，需要將程式源碼提供給後手時，此時SPAMs 2.5的程式源碼，是採GPL-3.0的授權方式來提供；而Extended WPF Toolkit Community Edition，則是採用MS-PL的授權方式來提供。

這樣，可能是最簡單能解決你目前碰到困境的方式！

關於這種方式簡要的說明，我大略例示如下讓你作個參考，這些資訊可以放在程式整體專案的說明檔裡，例如readme，則可以達到合理宣示的效力：

The Extended WPF Toolkit Community Edition is applied as an independent and separate module in this project, interacted with the main component as a dynamic linked function. The license of that remains as Microsoft Public License (Ms-PL) declared by its original author at :wpftoolkit.codeplex.com/license .

希望上述的資訊對您有所幫助，如後續有其他疑問或想法，我們再接續討論。



20140729 17:25 LUCIEN C.H. LIN

Dear Lucien,

這些資訊對我的幫助非常大，非常感謝您詳細的回答！