Hi tiramisu1025，

我想您的疑問可以整理為右列兩個問題：一、與GPL一同運作的其他元件，是否在再散布時得一併得以GPL授權，連帶提供程式源碼出來？二、修改MIT、BSD這些permissive license授權的自由開源軟體，是否在再散布時可以不用提供修改後的程式源碼？

下面是我對這個問題的了解。

一、與GPL一同運作的其他元件，是否在再散布時得一併得以GPL授權，連帶提供程式源碼出來？

原則上是，例外時不是。所謂原則上是，指的是這些元件在運作上與GPL程式緊密結合直接溝通，所以在程式互動關係上會被視為GPL元件的衍生著作，這種狀況之下，整個衍生著作一體(as a whole)在再散布時都是要照GPL授權規則來走的；而例外的狀況，例如該軟體專案是以動態連結或是其他更疏離的方式呼叫其他非GPL授權的元件，那麼如果能說明這些非GPL授權的元件並非衍生著作不可切割的一部份，則這些元件便例外的具有獨立性，而可以用自己的授權方式來進行散布。

進一步的相關資訊，可以參閱拙著「GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍」：https://www.openfoundry.org/tw/legal-column-list/8446-the-license-inheritance-bounds-of-gnu-gpl-01

二、修改MIT、BSD這些permissive license授權的自由開源軟體，是否在再散布時可以不用提供修改後的程式源碼？

可以，但是前提是，該元件不能再以MIT、BSD這樣的授權方式來宣告！

BSD、MIT這類permissive license確實並沒有要求後手修改程式後，一定得延用BSD或是MIT的授權方式來散布。然而，如果後手在散布時仍然宣告修改元件為BSD或是MIT授權的，那麼依照BSD、MIT授權條款，就必須要提供後手程式源碼！所以如果修改BSD或是MIT元件之後，不欲再提供程式源碼，則應該是在授權聲明中註明：本元件修改自MIT授權元件III專案，其原著作人為XXX，原專案網址為https://yyy.xxx.net/，經修改之後改以ZZZ授權方式僅釋出目的碼。(This file is modified from III project attributed to MR. XXX and originally released under MIT license on https://yyy.xxx.net/. The modified version is released under ZZZ license in binary form only.)

例如本討論串附圖所示，微軟的WIN7也取用MIT授權的元件，其保留了這些元件的原始著作權聲明，但再散布時是將程式碼融入整個元件中，並非延續以MIT的授權方式來散布修改後的程式碼。如果有清楚的述明這點，則修改BSD、MIT元件之後的散布行為，就可以不用提供修改後的程式源碼。



所以，綜合來說，您的例子裡，如果vendor提供的自由軟體元件裡，原本MIT、BSD等非GPL元件並非與GPL元件密切運作，並且也註明修改之後不會再採MIT、BSD的授權方式散布，則這些元件是不用提供程式源碼的，但是！如果「非密切運作」與「明示以其他授權方式代換MIT、BSD授權方式」這兩點要件都沒有成立的話，那其實照授權規則vendor是需要將這些元件的程式源碼提供出來給您的。

大致的資訊是如此，如後續再有疑問，歡迎接續討論！



敬祝 順心健康、事事如意

20120909 2155 LUCIEN C.H. LIN