上週，中國開源軟件推進聯盟（China OSS Promotion Union, COPU，註一）發布了「COPU 開源通用許可協議 V.1.0（以下簡稱「COPU-1.0」，註二）」的草稿，整份授權條款由簡體中文撰寫而成，為全球第一份中文的自由開源授權條款，因此本期的法律專欄將對 COPU-1.0 草稿做一個概要的介紹。不過由於中國大陸的用語跟台灣有所不同，為了避免辭彙轉換過程無法精確表達原簡體中文的詞意，因此本文在涉及說明 COPU-1.0 草稿內容時，將優先採用草稿中的用語，還請讀者自行參照本文末所附的辭彙對照表，來了解 COPU-1.0 草稿中辭彙相對於台灣的一般用詞（註三）。

【草擬背景與目的】

根據中國開源軟件推進聯盟官方的新聞稿（註四），由於中國當地社群對於既有的自由開源授權條款大多不了解，許多專案並不知道該如何選擇授權條款，而即使選擇了，可能也不是那麼切合該專案的狀況，導致在後來的運用上產生了一些問題；此外，目前常見的自由開源授權條款均是以英文撰寫而成，這對於中國大陸的社群成員來說並不容易了解，同時在商業運用上也發生過，因為企業審核英文授權條款的時間較長，而導致自由開源專案與企業的合作時程必須推延二個月的狀況。鑑於這些問題，因此中國開源軟件推進聯盟與北大法學院專家合作，制訂出 COPU-1.0 的草稿，一方面協議採用中文撰寫，解決英文所造成的隔閡問題，另外一方面，目前公開草稿內容、徵求當地社群成員意見，期望透過這樣的互動，來提升中國大陸社群對於智慧財產相關議題的關注。

由於期望這份協議未來可以被中國當地的專案加以採用，因此中國開源軟件推進聯盟之後將會發布條款的解釋文件，以輔助社群成員了解其中的內容。不過是否會發布英文版本以及申請開放源碼促進會（Open Source Initiative，OSI，註五）的認証，官方新聞稿僅透露會加以「考慮」，因此關於這兩點還有待觀察後續的發展。

【幾近於無的 copyleft 特性】

COPU-1.0 草稿是一份具有非常低度 copyleft 特性（註六）的條款，主要是因為 COPU-1.0 允許使用者為衍生軟件選擇授權內容的自由，所以極端弱化了 copyleft 的特性。相關的規定詳細說明如下（註七）：

1、使用者散布未經過修改的被許可軟件時，必須提供全部的源程序，提供的方法 COPU-1.0 規定有三種，使用者可以從其中擇一為之。

2、當被許可軟件被加以修改、增加或刪除之後，就會產生衍生軟件，不過 COPU-1.0 並沒有強制規定衍生軟件一定要繼續採用 COPU-1.0，而是將這樣的選擇權利交在使用者手上，使用者可以選擇繼續採用 COPU-1.0 散布，但是也可以自由採用其他的授權內容（註八）。不過很特別的是，依照 COPU-1.0 的規定，只要是沒有被修改、增加的部份，單獨來說都是「被許可軟件」，並不會構成衍生軟件的一部份，因此被許可軟件跟衍生軟件是兩個分開的、彼此獨立的部份。舉例來說：最原始釋出的被許可軟件中有 A、B、C、D 四個部份，其中 A、C 被使用者修改後成為了衍生軟件，而 B、D 仍然是被許可軟件，即使 A、C 在運作上可能與 B、D 關係密切，但是 COPU-1.0 將其區分為衍生軟件跟被許可軟件，並分別適用不同的義務規定；這樣相同的修改情況，但若軟體是採用 GPL-2.0 釋出，極有可能因為 A、B、C、D 四個部份在運作上的關係密切，因此這四部份被視為一個整體看待，這一個整體是一個完整的衍生程式，無法切割，進而讓 A、B、C、D 四個部份都必須繼續採用 GPL-2.0 來授權。將被許可軟件與衍生軟件如此獨立區分，是 COPU-1.0 草稿非常特別的規定。

3、另外，COPU-1.0 明確規定兩種利用狀況不會產生衍生軟件，也因此在這兩種情況下，提供源程序的義務並不適用：

(a) 若使用者增加到軟件中的特定部份，是該使用者單獨的獨立作品，那麼這個獨立作品就不是衍生軟件，也因此，這個獨立作品完全不會受到 COPU-1.0 所拘束，使用者在散布時，並沒有提供源程序的義務；

(b) 第二種則是規定單純調用的狀況，並不會讓其他的軟件模組成為衍生程式：一個軟件模組若是為了調用被許可軟件，而包含了被許可軟件的部份調用信息時，這個軟件模組將不會因此而成為衍生軟件；反之，若被許可軟件為了調用一個軟件模組，而包含了該軟件模組的部份調用信息，也不會讓這一個軟件模組成為衍生程式。不過若是被許可軟件與軟件模組被編譯成為靜態調用狀態的話，這時候整個被編譯出來的程序仍然被認定為衍生軟件，未來散布的時候，使用者必須提供所有的源程序給第三方。

上述第 1、2 與 3 (a) 點的內容與 MPL-1.1 的架構規定非常類似，但是相對來說，MPL-1.1 清楚地點出獨立性的判斷基礎在於檔案，也就是當一個檔案被增加到 MPL-1.1 程式中的時候，若是這個檔案並沒有包含任何 MPL-1.1 程式碼的話，這就是一個獨立的檔案，不會受到 MPL-1.1 所拘束，散布時可採用其他的條款授權，但是 COPU-1.0 對於何謂「獨立作品」，或其背後所蘊含的獨立性，並沒有更進一步的說明或闡釋，讓這部份規定留下疑義。另外，第 3 (b) 點的內容則與 LGPL-2.1 相近，因為 LGPL-2.1 是一份針對函式庫所制定的授權條款，因此一個程式單純連結利用 LGPL-2.1 函式庫的話，並不會讓這個程式也成為 LGPL-2.1 的衍生程式，不過若該程式與函式庫一起形成一個可執行檔的話，這整個可執行檔仍然必須受到 LGPL-2.1 所拘束，因此可以看得出來，COPU-1.0 草稿在這部份的規定是與 LGPL-1.1 非常相近（註九）。

MPL-1.1 與 LGPL-2.1 皆是 copyleft 授權條款，其所具有的 copyleft 特性雖然不如 GPL、AGPL 這些條款般強烈，但是基本上其衍生軟體都必須受到原條款所拘束，使用者無法為其自由選擇授權條款。與這兩份條款架構與內容近似的 COPU-1.0 照理也應該具有一定程度的 copyleft 特性，但是因為 COPU-1.0 允許使用者為衍生軟件自由選擇授權內容，讓 COPU-1.0 的 copyleft 特性大幅度地減弱，幾近於無 。

【其他主要內容】

除了上述極端被弱化的 copyleft 特性之外，COPU-1.0 草稿中其他主要的內容還包括了：

1、專利授權。

若是被許可軟件與衍生軟件中應用到許可人所擁有的專利技術，則此項專利技術也授權給予使用者來應用，只要依照 COPU-1.0 的規定來利用軟件，使用者就可以無償地連帶利用許可軟件中的專利技術。

2、顯名義務。

如同其他自由開源授權條款一樣，COPU-1.0 草稿也規定使用者不可刪除、修改許可軟件中的各項權利管理信息、署名信息與源程序中的注釋，除非使用者修改或刪減了源程序，為了配合這些修改、刪減，才可以相對應地刪除或修改署名信息或相關的注釋。此外，若使用者透過網路提供許可軟件的應用服務時，其雖然不需要將源程序提供給予服務使用者，但卻有義務在提供軟件應用服務的網站上或者是軟件的介面中，標示其使用了被許可軟件，而這項雲端應用時的標示義務，也及於衍生軟件。

3、文件與注釋保存義務。

對於被許可軟件所附隨的文件，以及在撰寫軟件過程中一併寫入源程序中的注釋，COPU-1.0 均相當重要這些文件資訊的保存。對於附隨的文件，COPU-1.0 規定使用者在散布軟件的時候，都必須要與源程序一併散布出來，不過若是在取得被許可軟件時，並沒有收到任何附隨文件的話，那麼使用者自然就沒有散布文件的義務。而對於源程序中的注釋，如同上述第 2 點所提到過的，除非源程序經過修改或刪除，否則使用者是不得擅自修改任或刪除任何注釋的內容。

4、提供 COPU-1.0 協議內容的義務。

如同 GPL、MPL 等條款，COPU-1.0 草稿也規定使用者在提供被許可軟件的同時，也必須要提供 COPU-1.0 協議的內容，不過對於透過什麼樣的方式來提供，COPU-1.0 草稿並沒有更細部的規定，因此解釋上，使用者可以自行決定提供的方式，例如提供 COPU-1.0 協議內容所在的網頁網址，也應該是合於規定的。

5、強制散布被許可軟件的義務。

在散布「衍生軟件」的同時，使用者必須要將未經修改的「被許可軟件」的源程序、附隨文件以及 COPU-1.0 協議內容也提供給予第三方。之所有會有這項規定，是因為 COPU-1.0 草稿規定被許可軟件、衍生軟件與獨立作品是彼此獨立的三個部份，在定義上並沒有互相重疊，這樣的設計讓使用者可以選擇單獨散布衍生軟件，而不散布被許可軟件。不過 COPU-1.0 草稿卻強制規定，無論衍生軟件採用什麼樣的授權條款，一旦使用者散布衍生軟件，同樣也必須將被許可軟件的源程序、附隨文件與 COPU-1.0 協議內容提供給予第三人，以增加被許可軟件的擴散度與能見度。

6、即時提供義務。

所有提供源程序、提供文件與提供 COPU-1.0 協議內容的義務，使用者都不得故意拖延，造成第三方無法即時獲得這些資料的狀況。

7、使用者失權不影響第三方所取得的合法授權。

使用者若是違反 COPU-1.0 規定時，所有原本所獲得的權利將會自動終止，但是第三方的權利並不會受到影響。

【草稿仍有許多待釐清或需要調整之處】

COPU-1.0 目前仍在草稿階段，有部份內容不清、需要被釐清或調整的地方。以下三點，是筆者認為幾項較為重要之處。

1、衍生軟件的定義不清。

GPL-2.0 所規定的衍生程式，是以一個整體運作的軟體為基本單位，MPL-1.1、MPL-2.0 則是以檔案為基本單位，此外，這些條款透過週邊文件的解說跟軟體專案的實務運作，讓使用者可以了解到，這些條款中的衍生程式是必須經過一定程度的修改之後才會產生的，僅僅只是參數的調教、或少數幾行的改變，原則上並不會產生衍生程式。

但是，COPU-1.0 草稿並沒有像上述條款的闡釋或說明，目前也還沒有釋出說明文件，因此單就草稿的文字來解讀，只要排除被許可軟件與獨立作品後，其他被修改過的部份就是衍生軟件，即使修改的幅度或品質是非常微量的。同時，對於何謂增加「部份」？何謂修改「部份」？何謂刪除「部份」？這些「部份」的基本計算單位為何，COPU-1.0 也沒有闡釋或說明，因此這個「部份」可能是個別檔案，也可能是具有特定功效的模組，甚至也可能是一個元件，未來在實際運用上，很有可能會產生使用者各自界定增加、修改、刪除與「部份」內涵的狀況，進而引發爭議。

此外，如同本文已經說明過的，COPU-1.0 草稿將衍生軟件與被許可軟件視為兩個分開、彼此獨立的部份來規定，這與現行一般自由開源授權條款中衍生程式的概念大不相同，由於筆者並不熟悉中國大陸相關的法令規定，因此這個規定在其當地法規體系下的合理性與合法性有待考究，不過由於 COPU-1.0 對於如何界定增加、修改、刪除與「部份」等概念並沒有說明或闡釋，而衍生軟件與被許可軟件分別適用的義務跟權利內容差異非常大，因此這種嚴格區分的規範方式，會讓何謂衍生軟件、何謂被許可軟件的爭議更為擴大。

2、COPU-1.0 在實質運用上的效果與 Apache-2.0 非常相近。

本文已經說明過，雖然 COPU-1.0 具有 copyleft 的形式架構，但是因為允許使用者自由為衍生軟件選擇授權內容，因此 copyleft 特性幾近於無。所以從技術上來說，只要使用者將整個被許可軟件修改過，使其整體轉變成為衍生軟件，就可以為其改用其他的條款來授權散布，甚至是不提供源碼的條款也可以，也就是說，只要將 COPU-1.0 授權的軟件稍加修改，整個軟件就可以改用其他任何的條款授權。這樣的結果雖然一方面有利於與其他自由開源軟體相容，因為使用者可以為衍生軟件採用 GPL-3.0、MPL-1.1 等等其他的條款授權，但是另外一方面，這樣的結果卻也讓 COPU-1.0 跟 Apache-2.0 這份授權條款變得非常相近，因為 COPU-1.0 草稿的內容皆可在 Apache-2.0 中找到對應的規定，只不過 Apache-2.0 的設計架構，是讓未經修改的軟體可以採用再授權方式散布，而修改過的條款則可以在遵守簡單義務的範圍內，與 COPU-1.0 允許衍生軟件可以改採其他任何條款授權的結果是幾乎是一樣的。因此筆者相當好奇，COPU-1.0 這樣的設計與規定，是否有什麼特殊的背景原因？

3、未明示不可撤回。

經過三十多年的發展，自由開源授權條款具有不可撤回 (irrevocable) 的特性，幾乎已經是被各界所公認，因此在新近修訂的條款中，例如 GPL-3.0 與 MPL-2.0，皆會將這樣的特性在條款中加以明文規定，不過在 COPU-1.0 草稿中，並沒有看到類似的文字，稍有缺憾之感。

【結語】

COPU-1.0 草稿的部份規定，與目前常見自由開源授權條款有所不同，因此筆者相當期待可以看到官方發佈說明文件，來解釋這些文字規定背後的意涵，此外，也很期待可以在意見徵求程序，看到中國大陸社群成員關於這些內容的討論。不過，若暫時先將草稿內容的疑義放在一邊，筆者以為，從這次 COPU-1.0 草稿的發佈可以了解到，自由開源軟體對於全球的影響之深，即使是中國大陸也因此必須要正視相關的授權議題，甚至進而積極起草制定這份 COPU-1.0 草稿，無論目前草稿內容如何，但這種正視自由開源軟體的態度是值得令人高興的。因此筆者期待中國開源軟件推進聯盟可以早日發佈說明文件，釐清 COPU-1.0 草稿中的疑義。

----

註一：中國開源軟件推進聯盟：https://www.copu.org.cn/。

註二：COPU 開源公共許可協議 v.1.0」草稿全文請見：https://code.csdn.net/news/2819902

註三：《COPU-1.0 草稿中文辭彙對照表》

以下辭彙依照筆劃順序排列

COPU-1.0 草稿用語            ->        台灣一般用語
（繁體中文／簡體中文）
==============================================================
信息／信息                          ->        資訊
衍生軟件／衍生软件           ->        衍生軟體、衍生程式
軟件／软件                          ->        軟體
許可人／许可人                  ->        授權人、著作權人、權利人
被許可軟件／被许可软件   ->        本軟體、原軟體
軟件模塊／软件模块           ->       模組
程序／程序                          ->       程式
源程序／源程序                  ->       程式源碼、源碼、原始碼
第三方／第三方                  ->       後手
署名聲明／署名信息          ->       貢獻聲明、貢獻資訊

註四：本段以下內容皆參考該篇新聞稿之內容，網頁連結如右：COPU 開源公共許可協議的官網，https://www.copu.org.cn/node/1378。

註五：關於 OSI 以及其所維護的開放源碼定義說明，請參閱：開放源碼定義與開放源碼促進會，https://www.openfoundry.org/tw/basic-concepts/1447-2010-07-13-09-57-12。

註六：關於 copyleft 概念的介紹，請參閱：什麼是"Copyleft"？，https://www.openfoundry.org/en/faq/licenses/concepts-of-foss#k1q7。關於常見條款所蘊含 copyleft 特性的概要介紹，請參閱：自由開源軟體授權條款的三分法，https://www.openfoundry.org/tw/legal-column-list/105-2010-07-15-10-42-58。

註七：本段相關的 COUP-1.0 草稿內容請參見第 2.4 條第 1 款、第 4.3.1 條 。

註八：不過若使用者採用非 COPU-1.0 授權散布衍生軟件的話，COPU-1.0 規定第 6 條的規定仍然繼續適用於衍生軟件，第 6 條主要是規定：當使用者因為違反 COPU-1.0 而喪失權利時，這並不影響使用者授予給第三方的權利。類似的規定在 GPL-2.0、MPL-1.1、MPL-2.0 中也可以見到，但是 COPU-1.0 將這樣的規定也適用在採用非 COPU-1.0 授權的衍生軟件中，則是少見的規定。

註九：本段所提及 MPL-1.1 與 LGPL-2.1 的特性，可以進一步參閱右列文章：從封閉到開放的副產品－MPL，https://www.openfoundry.org/tw/legal-column-list/517-mpl；稍稍鬆綁的堅持－LGPL，https://www.openfoundry.org/tw/legal-column-list/519--lgpl。

----

《感謝》感謝林誠夏在本文寫作期間參與討論。