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