眾所周知，互聯網公司傾盡心血研發的計算機軟件（計算機軟件是指計算機程序及其有關文檔。盡管不符合法律定義，但為方便讀者理解，以下筆者將計算機軟件統稱為“源代碼”）是互聯網企業的核心競爭力，“源代碼”一旦泄露或將對企業造成毀滅性地打擊。近一段時間來，筆者陸續處理了幾起互聯網公司“源代碼”泄露的案件，在處理案件的過程中對企業的“源代碼”保護有了更深刻的理解。接下來，筆者將對“源代碼”保護的思考寫成系列文章，分別為：“源代碼”的商業秘密屬性篇、泄露風險篇、侵權篇及合規設計篇，系列文章將陸續在公眾號推送。
本篇為系列文章第四篇：“源代碼”研發存在對外侵權的法律風險。
在前幾篇文章中，筆者主要介紹互聯網企業自研的“源代碼”性質、泄露風險及其維權措施，給人感覺互聯網企業的“源代碼”似乎只有被侵權的風險，而無對外侵權的可能性。其實不然，互聯網企業在研發“源代碼”的過程中，也存在著對外侵權的風險。這種風險來源于互聯網企業的程序員所使用的代碼如果是開源代碼，需要受到開源代碼所附帶的開源許可證的約束。有些開源許可證要求使用該開源代碼進行二次開源的，二次開源的代碼需要對外公開，而不得閉源。一旦閉源，將違反開源許可證的規定，存在侵權的潛在風險。
一、開源運動的來龍去脈
在講解“源代碼”為何存在對外侵權的潛在風險時，筆者認為有必要向讀者介紹下開源運動的來龍去脈，以便讓讀者對侵權風險有更具體的認識。
開源運動最早起源于20世紀50年代60年代的美國，那時候計算機限于軍用和學校研究。1965年貝爾實驗室（隸屬于AT&T公司）合作開發出Unix操作系統，由于AT&T公司受限于反壟斷的壓力，于1958年和美國司法部簽訂和解協議，承諾AT&T公司不進入計算機領域，于是AT&T公司將Unix操作系統以近乎免費的形式授權各高校使用。
20世紀70年代80年代，家用電腦開始普及，計算機市場逐漸爆發，軟件也被列入著作權登記的范疇。1982年，AT&T公司被拆分為8家公司，意味著前期與商務部簽署的和解協議不再生效，AT&T公司順勢進入計算機行業，并要求各高校今后須按期付費才能使用Unix操作系統。
AT&T公司的上述行為被認為違反了“黑客精神”（自由開放的精神），以理查德·馬修·斯托曼（Richard Mattew Stallman)的先驅們，開啟了開源軟件運動。他們以重現軟件界合作互助的團結精神為名，在net.unix-wizards新聞組發表了著名的GNU宣言，目標是創建一套完全自由的操作系統，(GNU是GNU`s not unix的縮寫)。該套操作系統要遵循如下幾個原則：第一個是使用軟件的自由；第二個是開源軟件可根據使用者的需要進行修改；第三個是可重新分發拷貝，與他人分享的自由；第四個改進程序，為使他人受益而散發軟件的自由。
在理查德·馬修·斯托曼（Richard Mattew Stallman)等人的共同努力下，Linux操作系統應運而生，并對外免費開源使用。受開源運動的影響，目前有不少軟件都做了開源，但這些軟件在開源的同時，也規定程序員如果要使用這些開源軟件必須遵照該開源軟件所附的開源許可證的要求，例如修改的地方需要放置修改說明；新增代碼需要再次開源等。
二、開源許可證的類型
根據上文所述，當前有不少開源軟件在允許他人使用時要求他人遵循開源許可證上的要求。經研究，筆者總結目前市面上幾種開源許可證的類型，并對此作簡單的分析。
實際上開源許可證是由開放源代碼促進會（open source Initiative，簡稱OSI）的組織頒發的，目前市面上經過該組織認證的許可證有83種，但80%的開源軟件使用的許可證不超過10種，開源許可證的類型主要就是上圖所示的這六種。
從上圖可以看出，MIT許可證應該是六種許可證類型中最寬松的許可證了。實際上，MIT許可證也是市面上最受歡迎的許可證，有接近一般的開源軟件都采用MIT許可證。使用MIT許可證的開源軟件允許閉源，只需要滿足兩個條件：第一、必須明確指出該軟件的版權人；第二、必須包含MIT的License原文。
BSD許可證與MIT唯一的區別是它不能使用原始創作者及貢獻者的信息做二次宣傳，比如我們使用了谷歌BSD許可的開源軟件改造之后做成自己的軟件，不能使用谷歌及二次開源者進行促銷宣傳。
Apache許可證則允許永久授權他人版權和專利權，但商標權仍歸屬Apache許可證所有人。另外，根據上圖所示，Apache許可證要求程序員在每次修改及每個修改處都標注清楚修改人，修改內容和修改時間。
GPL許可證應該算是上述許可證中最嚴格的一種了。GPL許可證要求使用該軟件的必須再次開源，并且二次開源的軟件必須再使用GPL許可證，以保持開源的持續性和穩定性。此類典型的軟件即是上文提及的Linux，迫于GPL的規定，Linux的所有變種，比如Redhat，Centos，Ubuntu等都必須免費開源。
LGPL許可證跟GPL許可證類似，但該許可證屬于弱傳染性的許可證，它規定通過類庫引用的方式使用開源軟件，則我們的軟件可以不用開源，這樣的話商業軟件可以使用LGPL軟件，且不用開源自己的代碼。[1]Mozilla許可證和LGPL許可證類似，也是屬于弱傳染性的許可證。
三、開源許可證的法律效力
根據前文的分析，我們知道市面上開源軟件大抵都附有開源許可證的要求，且不同的開源許可證有不同的限制要求。實際上，該開源許可證類似于我們第一次注冊淘寶賬號時所附帶的以彈窗形式或者鏈接形式提示用戶注意閱讀的注冊協議。對于普通人來說，多數人都不會閱讀冗長乏味的電子協議，況且大部分的開源許可證都是英文協議，更加深了程序員閱讀協議的障礙。那么，該類開源許可證是否具有法律上的拘束力呢？實際上開源許可證在美國已經得到了法院的判決支持。
2008年Bob Jacobsen V. Matt Katzer 案件中[2]，鮑勃·雅各布森（Bob Jacobsen ）和其團隊開發了?個名為JMRI (Java Modell RailroadInterface) 的模型?車控制軟件，并把它放在了著名的開源軟件?站Source Forge 上供公眾免費下載。JMRI使用了Artistic 開源許可協議。該許可證允許他?自由的復制，分發和修改軟件，但必須注明原作者的名字并說明源代碼來源，將所開發的新版本軟件放在指定的開源?站上供公眾下載，以及在軟件包中說明該版本軟件與雅各布森開發的JMRI標準版之間的區別等等。之后，該項目的部分源代碼被馬特·卡澤（Matt Katzer ）與其公司KAMIND并?了其開發的產品“Decoder Commander”中，但卡澤和KAMIND并沒有遵循Artistic 許可證的條款。基于這些理由，雅各布森于2006年向舊??聯邦法院提起了訴訟，控告卡澤與KAMIND公司侵犯了其著作權。此外，他還向法院提出了臨時禁令的申請，要求法院下令禁?卡澤與KAMIND繼續發布、銷售侵害著作權的產品。
法院認為，該案的核?問題在于卡澤和KAMIND違反的條款究竟是許可的條件（condition），還是合同上的契約（covenant）。法院發現，Artistic許可所使用的表述?式清楚地表明了其條款構成復制，修改和發布該軟件的條件（如使用“provided that ”等）。同時，這些條件對于使版權所有者能夠保留從下游用戶的作品中獲益的能??關重要（通過要求修改或分發該軟件的用戶保留對源?件的引用，其他用戶就可以從“下游”的發布中了解到“上游”項目，進?參與到JMRI的改良?作中）。雖然許可?僅僅是要求被許可?遵循Artictic許可的條款（包括附上版權聲明等），?不是向被許可?收取許可使用費，這種?式有權得到同樣的法律認可。因此，在沒有版權聲明和未標注對原始?件的修改的情況下修改和分發受版權保護的材料的?為超出了Artistic許可的范圍，因此可能構成侵犯版權。
實際上，開源許可證的法律效力不僅在美國得到了法院的認可，中國“柚子（北京）移動技術有限公司等與數字天堂（北京）網絡技術有限公司侵犯著作權糾紛案”中，法院也側面認可了開源許可證GPL協議的法律效力：“根據GPL協議的相關規定，GPL協議的許可客體是在GPL協議許可下批準的受版權保護的程序以及基于該程序的衍生產品或修訂版本。對于原告涉案三個插件而言，在其所處文件夾中并無GPL開源協議文件，而HBuilder軟件的根目錄下亦不存在GPL開源協議文件的情況下，盡管HBuilder軟件其他文件夾中包含GPL開源協議文件，但該協議對于涉案三個插件并無拘束力，據此，涉案三個插件并不屬于該協議中所指應被開源的衍生產品或修訂版本，二被告認為原告軟件為開源軟件的相關抗辯理由不能成立。”
四、總結
綜上所述，互聯網企業的程序員所使用的代碼如果是開源代碼，需要受到開源代碼所附帶的開源許可證的約束。市面上最常見的開源許可證主要有MIT許可證、BSD許可證、Apache許可證、GPL許可證、Mozilla許可證和LGPL許可證，不同的許可證有不同的約束要求，且開源許可證的法律效力已被美國法院正面認可，中國法院也從側面認可了開源許可證的法律效力。因此，如果互聯網企業的程序員使用了GPL許可證、Mozilla許可證或LGPL許可證進行二次開源，開源后選擇閉源并采取保密措施進行保護，則違反了開源許可證的要求，有侵權的潛在風險。
注釋：
[1] 參見《漫談開源許可證》一文，訪問時間：2020年1月3日：
https://mp.weixin.qq.com/s/rZ5BMvot8hFJTrRYmvhTFQ。
[2] 參見顧紫翚：《影響互聯?發展的 20 個?案》
