OSCHINA

作者 | 李維朝，江蘇瑞途律師事務所合伙人

引言

GPL許可證（General Public License）是應用最廣泛的開源許可證，作為互惠型許可證，以其強“傳染性”而著稱。

軟件著作權人以GPL許可證分發軟件，該軟件就以GPL許可證對任何人進行許可，成為我們常說的GPL程序。

使用人一旦將GPL程序與其自己開發的代碼合并并分發了軟件，如果沒有采取技術隔離措施，使用人開發的那部分代碼連同GPL程序一起就要以GPL許可證進行許可，遵守GPL許可證規定的義務。對“傳染性”是什么卻有不同的理解。

一、什么是“傳染性”

GPL V2第2條：你發布或出版的軟件作品（包括程序的全部或一部分，也包括由程序的全部或部分演繹而成的作品）整體上必須受本許可協議條款的約束，并允許第三方免費使用。這些要求適用于修改后作品的整體。

GPL V3第5條：你必須在本許可證下將整個作品作為一個整體，授權給持有副本的任何人。因此本許可證與根據第7條而附加的任何條款一起，將適用于整個作品及其所有部分，無論它們是如何打包的。本許可證不允許以任何其他方式許可該作品，但不會使您單獨收到的許可無效。

“傳染性”規定見于GPL V2第2條和GPL V3第5條，核心意思是如果你分發的軟件（稱為目標軟件）包括你自己開發的程序以及GPL程序，你自己開發的程序與GPL程序作為整體成為GPL程序的演繹作品，目標軟件整體上受到GPL許可證的約束，應當以GPL許可證進行許可。

當然，GPL許可證也給了例外豁免，即，如果你自己開發的程序與GPL程序在技術上采取了隔離措施，使得你自己開發的程序與GPL程序不再成為一個整體軟件，而是相互獨立的兩個軟件，那么，你自己開發的程序與GPL程序就不會作為整體認定為GPL程序的演繹作品，就不會受到GPL許可證的約束。

二、對“傳染性”的誤解

“傳染性”這個詞非常容易讓人理解GPL許可證的強著佐權特點，但同時也非常容易讓人誤解，以為GPL程序就像病毒一樣“傳染”，就像病毒在人與人之間的傳播，一個感染病毒的人將病毒傳染給另一個人或者一群人，使得人類整體感染病毒。

對軟件略有了解的人都知道，一個軟件由若干個代碼文件組成，代碼文件之間存在各種軟件技術上的關聯，例如鏈接（link）。

有人就提出如果目標軟件中包括受GPL許可證約束的A文件，就要考慮A文件與其他文件之間的關系，如果A文件與F文件不存在關聯，那么A文件不會“傳染”F文件；A文件與B文件、D文件、H文件存在關聯，所以A文件把B文件、D文件、H文件“傳染”成GPL程序，再由B文件、D文件、H文件“傳染”目標軟件的其他文件，直至把各個文件都“傳染”。

圖1-這樣理解對嗎

這種理解顯然是錯誤的。GPL許可證并不關心目標軟件中的各個文件本身的許可證，而是關心目標軟件整體的許可證，只對整體許可證產生影響。

三、“傳染性”的本質

正如我們談論GPL等開源協議時常用的一個詞“許可證”，GPL最關心的是目標軟件應該怎樣對使用人進行許可，以GPL進行許可，還是其他。

仍以圖1為例，你自己開發的代碼包括文件B-I，各文件之間不存在技術隔離措施，當你自己開發的代碼鏈接文件A，而文件A適用GPL許可證，并且你自己開發的代碼與文件A不存在技術隔離措施，那么，你自己開發的代碼與文件A構成一個整體，該整體軟件受GPL許可證的約束。

至于你自己開發的代碼要以什么許可證單獨對外許可，采用GPL以外的其他開源許可證，還是商業許可證，這對結果沒有影響，GPL許可證只約束目標軟件這一整體軟件。

如果你在分發目標軟件之后，又想對外進行商業許可，那么你完全可以重寫文件A，形成與文件A相同功能的文件J，再將文件B-I與文件J鏈接起來形成一個新的整體軟件，并以商業許可的方式對外發布。

也就是說，你自己開發的代碼與受GPL許可證約束的文件A合并之后，文件A并不會把GPL“傳染”給你自己開發的代碼。

我們再把這一討論設置得更復雜一些。我們都知道，今天的軟件已經幾乎沒有完全是自己的開發的了，或多或少都會引用他人開發的代碼，大多數是以編譯好的文件庫的形式使用。

如圖2所示，在你發布的軟件中，你只開發了F，A-E都來自他人，它們的許可證各不相同，甚至有來自公有領域而沒有著作權的D，那么你發布的軟件該怎么許可呢？

GPL的“傳染性”要求我們應當以GPL許可證對外許可。當A、C-F與B之間不存在技術隔離措施，那么A-F就構成一個整體軟件，受到GPL許可證的約束。

同時，Apache、MIT、BSD許可證的條款與GPL許可證條款沒有沖突，GPL許可證對著作權人和使用人的限制是最多的，GPL許可證與Apache、MIT、BSD許可證相兼容，那么最終這個軟件就應當以GPL許可證進行許可了。

從這個意義上講，受GPL許可證約束的B“傳染”了最終發布的軟件整體。

圖2-軟件開發現狀

當然，如果你不想以GPL許可證對外進行許可，那么你應當把B移出去，在B與剩余部分之間采取技術隔離措施，避免B與剩余部分牽連成為一個整體，這樣你就可以以你想要的方式對外許可了，Apache、MIT、BSD許可證對使用人都非常寬松。

圖3-技術隔離

四、開源實踐之更換許可證

經過上述講解，我們明白了GPL“傳染性”的本質，它不會把你自己開發的代碼“傳染”成GPL，更不可能把你引用的他人開發的代碼“傳染”成GPL，它只會影響最終對外發布的軟件整體。

正是因為“傳染性”的本質，在開源實踐中，軟件版本迭代時更換許可證也不鮮見，例如Cygwin庫從2.5.2版開始，采用LGPL許可證取代GPL許可證，LGPL許可證比GPL許可證寬松，允許在動態鏈接Cygwin庫時保持其他部分代碼閉源。

需要指出的是，更換許可證不影響在此之前已經發布的版本，這些版本仍然保持原來的許可方式不變。

相反地，也有難以更換許可證的情況。以Linux內核為例，Linux內核采用GPL v2許可證，從技術和法律角度來看，Linux內核想要更換許可證實屬不易。Linux內核包括很多GPL組件，還包括很多他人貢獻的代碼，只有在移除GPL組件并取得其他貢獻者的同意之后，才有可能更換許可證。

在（2019）粵73知民初207號案件中，法院認為根據GPLV3協議條款約定和性質，只要某個軟件版本加入GPLV3協議，則無法隨意刪除GPLV3協議，該版本源代碼將永久保持開源，即使授權方刪除GPLV3協議也無回溯力，授權方只能在后續的版本中變更或刪除GPLV3協議，但并不影響此前版本繼續適用GPLV3協議的效力。

本案中，羅盒公司確認其主張的涉案軟件2017年12月30日版本與撤回GPLV3協議即2017年10月29日前的版本差別不大，因此本院認定羅盒公司主張權利的版本仍屬于適用GPLV3協議的開源軟件。

即，法院認為羅盒公司2017年12月30日版本不能更換許可協議的原因在于，該版本與之前以GPL許可證發布的版本實質相同。

很顯然法院的邏輯是錯誤的，真正的原因是，2017年12月30日版本合并有他人貢獻的代碼，而他人是基于GPL許可證來貢獻代碼的，在沒有取得貢獻者同意的情況下，羅盒公司不能獨立更換許可證。

也就是說如果你對全部的代碼享有完整的權利，在不同版本中采用不同的許可方式就沒有那么多的限制了。

五、總結

GPL“傳染性”并不是像病毒那樣傳染，而僅僅是對最終發布的整體軟件的許可證的選擇造成影響，本質上是多個許可證之間的兼容性問題，需要從多個許可證里面選擇一個能夠兼容其他許可證的許可證。

如果各個許可證之間存在沖突，不能兼容，那你就無法從這些許可證中選擇了，如果可能的話你需要創設一個新的許可證，從而把這些不兼容的許可證統一起來，如果這也做不到的話，那你就只能把某些代碼移除了。

我們要正確理解開源許可證的本質，使用開源軟件推動軟件產業的發展，為社會大發展提供效率工具。

↓分享、在看與點贊~Orz