... 授權的檔案中。 【EPL-1.0 與 GPL 條款彼此互不相容】 EPL-1.0 也是具有授權拘束性的授權條款，原程式碼本身以及衍生程式均必須適用 EPL-1.0 授權，因此 EPL-1.0 程式碼無法改適用 GPL 授權。此外，由於沒有 MPL-2.0 的特別相容預設機制，所以也無法與 GPL 程式碼結合在同一個開發專案中相容並存。雖然 EPL-1.0 規定非衍生的獨立模組可以採用非 EPL-1.0 ...

...  針對這樣的運用方式，GPL-2.0、GPL-3.0、Apache-2.0、MPL-2.0 與 EPL-1.0 等授權條款，均有明確的文字，表示使用者可以透過收取費用的方式來提供額外的保證或擔保（註三）。而這種保證或擔保費用的收取，更是自由開源軟體的客製化承包商，得以生財牟利的彈性化商業應用模式。 值得注意的是，此類保證或擔保的承諾，是由特定使用者所自行提供，因此未來若是保證或擔保事由真的發生的話，也必須由這位特定的使用者自己來承擔保證或擔保責任，原自由開源軟體的授權人或其他的使用者，並不會連帶被課予這樣的保證或擔保責任。在一些授權條款中，有著明確的文字來闡明這樣的原則。所以若是因為某特定使用者額外提供的保證或擔保承諾，而使得授權人或其他使用者遭致損失或必須負擔額外責任的話，這位特定的使用者就必須協助授權人或其他使用者，來免於負擔這些額外的責任，而在授權人或其他使用者因此受有損失的情況下，這位特定使用者還必須要加以賠償這些無辜受殃者所遭遇的損失。 ...

... sublicense 機制的條款，以在日後得以直接依條款規劃的機制處理上述問題。   【sublicense 於自由開源軟體領域的應用方式與差異】   右列幾款常見的自由開源授權條款，如：Apache-2.0、MIT、CPL-1.0、EPL-1.0、CDDL-1.0，以及 MPL-2.0（散布可執行檔格式時，註三），均有著明確容許 sublicense 的文字。所以如果使用者參與開發的是以這些授權方式進行共工的專案，授權規劃上，便可以在改作或是再行散布時，適當標註前專案與後專案之間的歷史關係，以及原創作人與創作團隊的顯名聲明之後，將後續專案轉以自己的名義向外授權。舉例來說，如果原來的自由開源軟體「AAA ...