中國 GPL 訴訟第一案：關於 GPL 問題的探討

2019 年 11 月初，數字天堂（北京）網路技術有限公司（下稱：數字天堂）訴柚子（北京）科技有限公司、柚子（北京）移動技術有限公司（下稱：兩柚子）侵犯計算機軟體著作權糾紛案，由北京高級人民法院二審作出終審判決。筆者曾密切關注該案，終審判決生效前，囿於關聯代理關係的利益衝突，不便多談。現將本案相關若干問題梳理成文，願與各位探討之。

本案之所以受關注，是因為本次計算機軟體著作權侵權案涉及開源軟體和 GPL 許可證，本案的判決對未來開源軟體訴訟實踐有重要意義。本案一審法院對 GPL 相關條款作了闡述，二審法院迴避了 GPL 問題。本文，筆者基於本案事實和法院判決做些思考，分享給大家討論。本文將僅對涉及開源軟體及 GPL 許可證的內容進行論述，其他法律問題不作探討。

案情簡介

為節省篇幅，以下對案情進行摘要和總結，詳細案情可見一審鏈接和二審鏈接。

經過一審和二審對事實的調查和確認，兩柚子認可：

1. 數字天堂是 HBuilder 軟體的著作權人；
2. 數字天堂擁有 HBuilder 軟體中的代碼輸入法功能插件、真機運行功能插件、邊改邊看功能插件源代碼著作權；
3. 兩柚子的 APICloud 軟體中對應插件源代碼部分與涉案的三個插件具有同一性。

基於此，針對本著作權侵權控訴，兩柚子抗辯理由只有 GPL 開源許可協議這一個突破口。而二審中對涉案代碼量、侵權產品數量的認定，以及基於此對賠償額的認定，只是量的維度問題。

開源許可證是法律文件

一審法院雖未明確 GPL 許可證的法律效力，但在論述涉案三個插件是否受 GPL 協議限制時，默認了 GPL 許可證具有法律約束力。這一點雖然是意料之中，但畢竟開源理念和大部分開源協議來源於國外，且應用於開源社區特定人群，這一認定給未來涉及開源軟體的訴訟消除了部分不確定性。為了強調協議內容，下文涉及 GPL 許可證的除特指許可證本身外，都以 GPL 協議指代。

法院雖然默認了 GPL 協議具有約束力，即類似於協議或合同的法律效果，但並未進一步將 GPL 協議條款基於我國著作權法進行解釋。社區內關於 GPL 協議的解釋，特別是關於 GPL 傳染性的解釋是基於美國版權法，其能否為國內法院認可，依然存在不確定性。

隨著開源理念的深入以及開源軟體在世界範圍內的普及，本案作為中國 GPL 第一案，對未來開源軟體相關的訴訟意義重大。稍有遺憾的是，兩審法院並未就開源軟體以及 GPL 協議的關鍵問題進行闡述。當然，也不可能期待 GPL 問題通過一次訴訟案件完全解決，未來還需要更多的法律、學術、技術等人士貢獻智慧。

關於一審認定的思考

既然法院確認了 GPL 協議的法律約束力，那麼對 GPL 協議的解釋要麼採取社區通說解釋，要麼基於我國著作權法作獨立解釋。否則很容易出現矛盾或模糊，以至於增加企業開源實踐中的法律不確定性。

關於 GPL 協議約束力範圍（傳染性），一審法院以涉案的三個插件可以獨立運行，分別存放在三個獨立的文件夾中且三個獨立文件夾中無 GPL 許可證，據此認為涉案三個插件不屬於 GPL 協議中所指應被開源的衍生產品或修改版本。

GPL 許可證中有關的原文如下：

The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".)——GPL 3.0

To 「modify」 a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a 「modified version」 of the earlier work or a work 「based on」 the earlier work.

A 「covered work」 means either the unmodified Program or a work based on the Program.——GPL 2.0

結合 GPL 協議條款和 GNU 官網對於 GPL 傳染性的解釋，一審法院這一認定是值得商榷的，就像你不能認為總部在西城的 A 公司與其在昌平擁有獨立辦公場所的分公司 B 是完全獨立的，這需要從 A 和 B 之間的財務、人事、業務等是否獨立為基礎判斷。

同理，GPL 模塊 A 與模塊 B 之間是否獨立，絕對不能以A和B是否位於獨立的文件夾中來判斷，還是需要從 A 和 B 之間的功能關係、通信關係、調用關係、依賴關係等來判斷。

插件相對於主程序是否獨立，需要看：

1. 插件的使命，是否為該主程序而存在；
2. 插件與主程序的交互方式，如管道、隊列、函數調用；
3. 交換消息的密切性 （ intimate communication ） ；
4. 是否有例外聲明等。

一審法院在確定賠償額的時候又一次指出三個涉案插件是三個獨立軟體作品。一審法院從審判認定到賠償衡量是一致的。這裡，兩柚子並沒有就涉案三個插件的獨立性進行抗辯，而這一點對 GPL 是否構成傳染非常關鍵，在一審中被告代理律師對 GPL 許可證條款的理解也存在局限。

關於二審認定的思考

首先，二審中兩柚子再次提出司法鑒定來否定涉案三個插件獨立性，可能是準備利用GPL傳染性中關於獨立作品的認定來抗辯。不過，法院認為二審訴訟中再次提出第三次鑒定申請，有違司法程序公正和司法程序效率，即二審法院基於程序公正的角度考量不予准許。同時，二審法院認為兩柚子提出的新的司法鑒定申請內容與本案待證事實之間無直接關聯性，這一點是值得商榷的，因為 GPL 中作品是否獨立直接影響作品是否受GPL約束，進而直接影響本案關於侵權的認定。二審法院的否決理由，直接迴避了可能對 GPL 傳染性問題的討論。

其次，二審法院認定數字天堂現有證據不足以證明涉案三個插件可以獨立於 HBuilder 開發工具軟體中的其他程序獨立運行，但針對不獨立的插件卻沒有進一步討論這種不獨立是否能夠進行 GPL 開源抗辯。也就是說，一審法院基於作品的獨立認定 GPL 抗辯無效，二審法院採取了一審對 GPL 抗辯的意見，但卻否定了作品的獨立性這一前提。

是否為獨立作品的認定直接決定作品是否屬於 衍生作品 （ derivative work ） 或 修改作品 （ modified version ） ，進而直接影響是否受 GPL 約束。

當然，我們可以這樣解讀二審法院對於作品獨立的認定，即 GPL 許可證里所說的作品的獨立性，和一審、二審法院判決賠償額對插件獨立的認定是不同維度/層次，這是說的通的。但仔細閱讀一審判決可知，法院在否決 GPL 抗辯中和賠償額判定中對獨立的認定是一致的，二審認可了一審對 GPL 抗辯部分的認定，卻否決了賠償額中對獨立作品的認定，本身前後有矛盾嫌疑。

筆者認為，如果按照上述：GPL 傳染性中獨立性判定和對侵權作品數量中獨立性判定是不同維度的獨立性判定的假設，至少二審中需要重新認定 GPL 傳染性的問題，從而將兩個維度的獨立性認定區分開來。

關於兩柚子訴求理由的思考

兩柚子在二審中再次申請司法鑒定：

1. 涉案三個插件是否可以脫離 Eclipse 主體軟體在 Windows 環境中獨立運行；
2. 將涉案三個插件源代碼編譯為插件以驗證插件能否在 Eclipse 主體軟體中獨立運行；
3. 任意刪除 Hbuilder 軟體目錄下的一個或多個以「org．eclipse」、「org．apache」、「com．aptana」為前綴的文件或目錄 JAR 文件以驗證涉案三個插件能否正常運行……

關於這三個補充鑒定事項，首先，筆者認為兩柚子或者其律師在開源上做足了工作，但其中依然存在問題。首先，插件獨立於 Eclipse 主程序，並不一定需要插件可以脫離 Eclipse 主程序在 Windows 中獨立運行。插件的獨立性在於：插件有明確的功能，可用於特定的主程序，但不依賴於特定的主程序。最後，主程序脫離插件，應當且必須可以獨立運行，並且不損失主程序本身的所有功能。

再看訴訟本身

基於以上認識，我們再回頭看看案件本身。首先說明，因本案需要進行多處技術鑒定，筆者無法也沒有精力一一取證，僅僅基於幾個假設，再捋一下 GPL 相關的問題。筆者認為，關於本案 GPL 傳染性的認定需要從 3 個方面來看：

1. Eclipse 主程本身；
2. 基於 Eclipse 主程序的 GPL 插件；
3. 涉案插件與主程序，以及涉案插件與上述 GPL 插件的關係。

為方便讀者理解，引用數字天堂代理律所對一審結果評述的一張圖。

（1）從 Eclipse 主程序看

APICloud 和 HBuilder 都是基於主程序 Eclipse 平台，包含第三方開源插件+各自自研插件組成的集成開發環境 IDE。

首先，主程序 Eclipse 是採用 EPL（Eclipse Public License）許可證公開，EPL 與 GPL 不兼容。即便是 2017 年 8 月發布的 EPL-2.0 版本雖然添加了次級許可證選項，但其與 GPL 依然是不兼容的。因此，HBuilder 作為下游產品，其對 Eclipse 的包裝分發不能變更 Eclipse 許可證。

其次，針對插件來說，無非是拓展 Eclipse 某一特定的功能，任何非 Eclipse 本身的第三方插件，可以說對於 Eclipse 主程序來說都是非必須的。其第三方公司開發的 Eclipse 主程序的插件，按照 EPL 傳染性的規定，一般不視為 EPL 的衍生作品，不受 EPL 約束。

最後，需要強調的是 EPL 雖然是弱 Copyleft 許可證，但其依然是類似於 GPL 的具有「傳染性」的許可證，其在給予用戶更大使用方便的同時，對自身軟體的 Copyleft 保護依然很強。因此，下游軟體開發者在處理 EPL 軟體和 GPL 軟體時，需要認真對待它們的兼容性問題。

（2）從 Aptana 插件看

Aptana 在 2006 年推出時，以 EPL 1.0 發布，並於 2017 年 9 月 21 日修改為 GPL3.0 和 APL（Aptana Public License ）雙許可。APL 不是開源/自由軟體許可證，可以認為是商業許可，但對於非分發的內部使用是免費的。

Aptana 作為主程序 Eclipse 的插件，由於 EPL 和 GPL 不兼容，Aptana 中的 GPL 插件要和以 EPL 許可的 Eclipse 主程序連接，必須在 GPL 許可證里作例外聲明。毫無疑問，筆者在 Aptana 官網找到了例外聲明，即關於獨立作品的 GPL 傳染性例外聲明，以及聚合程序的 GPL 傳染性例外聲明。部分內容如下：

GPL Section 7 Exception

……which are conveyed to you by Appcelerator, Inc. and licensed under one or more of the licenses identified in the Excepted License List below (each an "Excepted License"), as long as:

1. you obey the GPL in all respects for the Program and the modified version, except for Excepted Works which are identifiable sections of the modified version, which are not derived from the Program, and which can reasonably be considered independent and separate works in themselves,
2. all Excepted Works which are identifiable sections of the modified version, which are not derived from the Program, and which can reasonably be considered independent and separate works in themselves,
3. are distributed subject to the Excepted License under which they were originally licensed, and
4. are not themselves modified from the form in which they are conveyed to you by Appcelerator, and
5. the object code or executable form of those sections are accompanied by the complete corresponding machine-readable source code for those sections, on the same medium as the corresponding object code or executable forms of those sections, and are licensed under the applicable Excepted License as the corresponding object code or executable forms of those sections, and
6. any works which are aggregated with the Program, or with a modified version on a volume of a storage or distribution medium in accordance with the GPL, are aggregates (as defined in Section 5 of the GPL) which can reasonably be considered independent and separate works in themselves and which are not modified versions of either the Program, a modified version, or an Excepted Work.

If the above conditions are not met, then the Program may only be copied, modified, distributed or used under the terms and conditions of the GPL or another valid licensing option from Appcelerator, Inc. Terms used but not defined in the foregoing paragraph have the meanings given in the GPL

從以上 GPL 例外中可以看出，Aptana 只是部分限定了「衍生作品」解釋，也就是運行採用 GPL 許可證的 Aptana 與像 Eclipse 這樣獨立的程序交互不會發生傳染，僅此而已。而如果修改 Aptana，將其他程序併入 Aptana Studio，或者將 Aptana 與其他程序進行整合的作品依然受到 GPL 協議約束。簡單的說，加入 GPL 例外的 GPL 程序依然是 GPL 程序，這一點必須強調。關於這一點，Aptana 官網還專門有問題解答：

Can I add EPL'd plugins to Aptana Studio package and redistribute it?
No. You can only redistribute the unmodified binary versions of the EPL'd plugins that are part of Aptana Studio when distributing any of the GPL'd code. Adding any files to Aptana Studio package creates a derivative work, and since all derivative works need to be made GPL'd, you will not be able to add EPL'd (or any other license) plugins without contacting us for a commercial license.

What if I want to make changes to some of Aptana Studio's EPL'd plugins?
You are free to make changes to any of Aptana Studio EPL'd code under the terms of the EPL. To get those redistributed as part of Aptana Studio, we encourage you to contribute those back to Aptana so that we may evaluate your changes for inclusion back into the product.

Can I take unmodified Aptana Studio binaries and combine them with an Eclipse distribution?
No. Combining our GPL'd licensed code with any other product requires that the entire product be GPL'd, and therefore you cannot include any Eclipse distribution.

數字天堂認為，其 HBuilder 是包含 Eclipse 平台框架和眾多插件的聚合體軟體包，但其基於 Eclipse 開發且打包了 Aptana 中的 GPL 插件。從 GPL 協議對獨立程序和聚合程序的規定來看，HBuilder 不被感染很難成立。一旦這種潛在傳染可能性成立，數字天堂的 HBuilder 發行版就不滿足合規性，其內部 EPL 和 GPL 軟體不兼容。直白的說，就是整個發行版都可能受到 GPL 的約束。同時，這對於 Eclipse 是不可接受的，哪怕 EPL 是弱 Copyleft 許可證。這些問題，多是對 EPL 和 GPL 的 Copyleft 性質認識不到位導致。

（3）涉案插件與主程序及 Aptana 插件的關係

其實，以上兩步分析一旦得出受 GPL 約束的結論，就不需要下面的分析了。為了完整，同時供未來類似案例參考，簡單介紹。

進一步分析 Aptana 與數字天堂的涉案三個插件之間的關係，若涉案三個插件與 Aptana 有調用、通信、依賴關係，那麼涉案三個插件必然會被 GPL 傳染，也即是受 GPL 約束。

從以上三步的分析可見，在 GPL 傳染性判斷時，是否為獨立作品是非常關鍵的。這也是我在前面法院判決部分要強調一審法院對獨立的認定雖未必符合 GPL 本身解釋，但至少前後一致。而二審法院對作品獨立的認定甚至前後矛盾。

當然，筆者沒太多精力去調查技術細節，點到為止，有興趣的讀者可以進行深入研究。

以上分析，是基於 Eclipse 作為中立主程序（即 Eclipse 主程序著作權人非訴訟參與人），GPL 插件與非 GPL 插件判定的情況，換一種場景以上判斷完全或者大部分不成立。關於開源軟體和 GPL 的問題還有很多需要注意的，限於篇幅不再進一步說明，對本案或對開源感興趣的朋友可以找我單獨討論。

付欽偉，集慧智佳高級諮詢師、專利代理人，擅長專利分析布局、FTO 調查與風險應對、專利信息應用、開源軟體風險與合規指導。

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive