中國GPL 訴訟第一案：關於GPL 問題的探討
2019 年11 月初，數字天堂（北京）網絡技術有限公司（下稱：數字天堂）訴柚子（北京）科技有限公司、柚子（北京）移動技術有限公司（下稱：兩柚子）侵犯計算機軟件著作權糾紛案，由北京高級人民法院二審作出終審判決。筆者曾密切關注該案，終審判決生效前，囿於關聯代理關係的利益衝突，不便多談。現將本案相關若干問題梳理成文，願與各位探討之。
本案之所以受關注，是因為本次計算機軟件著作權侵權案涉及開源軟件和GPL 許可證，本案的判決對未來開源軟件訴訟實踐有重要意義。本案一審法院對GPL 相關條款作了闡述，二審法院迴避了GPL 問題。本文，筆者基於本案事實和法院判決做些思考，分享給大家討論。本文將僅對涉及開源軟件及GPL 許可證的內容進行論述，其他法律問題不作探討。
案情簡介
為節省篇幅，以下對案情進行摘要和總結，詳細案情可見一審鏈接和二審鏈接。
經過一審和二審對事實的調查和確認，兩柚子認可：
- 數字天堂是HBuilder 軟件的著作權人；
- 數字天堂擁有HBuilder 軟件中的代碼輸入法功能插件、真機運行功能插件、邊改邊看功能插件源代碼著作權；
- 兩柚子的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 之間的功能關係、通信關係、調用關係、依賴關係等來判斷。
插件相對於主程序是否獨立，需要看：
- 插件的使命，是否為該主程序而存在；
- 插件與主程序的交互方式，如管道、隊列、函數調用；
- 交換消息的密切性（intimate communication）；
- 是否有例外聲明等。
一審法院在確定賠償額的時候又一次指出三個涉案插件是三個獨立軟件作品。一審法院從審判認定到賠償衡量是一致的。這裡，兩柚子並沒有就涉案三個插件的獨立性進行抗辯，而這一點對GPL 是否構成傳染非常關鍵，在一審中被告代理律師對GPL 許可證條款的理解也存在局限。
關於二審認定的思考
首先，二審中兩柚子再次提出司法鑑定來否定涉案三個插件獨立性，可能是準備利用GPL傳染性中關於獨立作品的認定來抗辯。不過，法院認為二審訴訟中再次提出第三次鑑定申請，有違司法程序公正和司法程序效率，即二審法院基於程序公正的角度考量不予准許。同時，二審法院認為兩柚子提出的新的司法鑑定申請內容與本案待證事實之間無直接關聯性，這一點是值得商榷的，因為GPL 中作品是否獨立直接影響作品是否受GPL約束，進而直接影響本案關於侵權的認定。二審法院的否決理由，直接迴避了可能對GPL 傳染性問題的討論。
其次，二審法院認定數字天堂現有證據不足以證明涉案三個插件可以獨立於HBuilder 開發工具軟件中的其他程序獨立運行，但針對不獨立的插件卻沒有進一步討論這種不獨立是否能夠進行GPL 開源抗辯。也就是說，一審法院基於作品的獨立認定GPL 抗辯無效，二審法院採取了一審對GPL 抗辯的意見，但卻否定了作品的獨立性這一前提。
是否為獨立作品的認定直接決定作品是否屬於衍生作品（derivative work）或修改作品（modified version），進而直接影響是否受GPL 約束。
當然，我們可以這樣解讀二審法院對於作品獨立的認定，即GPL許可證裡所說的作品的獨立性，和一審、二審法院判決賠償額對插件獨立的認定是不同維度/層次，這是說的通的。但仔細閱讀一審判決可知，法院在否決GPL抗辯中和賠償額判定中對獨立的認定是一致的，二審認可了一審對GPL抗辯部分的認定，卻否決了賠償額中對獨立作品的認定，本身前後有矛盾嫌疑。
筆者認為，如果按照上述：GPL 傳染性中獨立性判定和對侵權作品數量中獨立性判定是不同維度的獨立性判定的假設，至少二審中需要重新認定GPL 傳染性的問題，從而將兩個維度的獨立性認定區分開來。
關於兩柚子訴求理由的思考
兩柚子在二審中再次申請司法鑑定：
- 涉案三個插件是否可以脫離Eclipse主體軟件在Windows環境中獨立運行；
- 將涉案三個插件源代碼編譯為插件以驗證插件能否在Eclipse 主體軟件中獨立運行；
- 任意刪除Hbuilder 軟件目錄下的一個或多個以“org．eclipse”、“org．apache”、“com．aptana”為前綴的文件或目錄JAR 文件以驗證涉案三個插件能否正常運行……
關於這三個補充鑑定事項，首先，筆者認為兩柚子或者其律師在開源上做足了工作，但其中依然存在問題。首先，插件獨立於Eclipse 主程序，並不一定需要插件可以脫離Eclipse 主程序在Windows 中獨立運行。插件的獨立性在於：插件有明確的功能，可用於特定的主程序，但不依賴於特定的主程序。最後，主程序脫離插件，應當且必須可以獨立運行，並且不損失主程序本身的所有功能。
再看訴訟本身
基於以上認識，我們再回頭看看案件本身。首先說明，因本案需要進行多處技術鑑定，筆者無法也沒有精力一一取證，僅僅基於幾個假設，再捋一下GPL 相關的問題。筆者認為，關於本案GPL 傳染性的認定需要從3 個方面來看：
- Eclipse 主程本身；
- 基於Eclipse 主程序的GPL 插件；
- 涉案插件與主程序，以及涉案插件與上述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:
- 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,
- 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,
- are distributed subject to the Excepted License under which they were originally licensed, and
- are not themselves modified from the form in which they are conveyed to you by Appcelerator, and
- 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
- 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 的問題還有很多需要注意的，限於篇幅不再進一步說明，對本案或對開源感興趣的朋友可以找我單獨討論。