成全在线观看免费完整的,成全影视大全免费追剧大全,成全视频高清免费播放电视剧好剧,成全在线观看免费完整,成全在线观看高清全集,成全动漫视频在线观看完整版动画

開源軟件促進了軟件智力成果的共享，越來越多的企業將開源軟件（代碼）直接或再開發后用于商業用途。免費自由使用開源軟件給企業帶來便利的同時，也要求企業履行開源許可協議項下的義務。如未能履行開源軟件協議項下義務將使企業面臨巨大的法律風險。下文將對GPL開源軟件項目法律合規業務中需要重點關注的幾個問題進行分析。

企業需要明確自身使用的GPL開源軟件適用的開源協議版本。例如后文提及的最高院審理的開源協議案件，適用的開源協議為GPL第三版本，其中對于“聚合體”軟件有特有的論述，從而能夠成為法院認定的依據。

需要注意的是，雖然同為GPL開源協議，其三個版本均為共存、獨立有效狀態，而非法律修訂的新舊替代關系。因此，確定GPL開源協議的版本為GPL開源軟件合規業務需要關注的首要問題。

如果GPL開源軟件系通過開源社區進行下載，那么開源社區通常會標注該開源軟件適用的GPL開源協議的版本號。如果并非從規范的開源社區下載，由于開源協議通常會要求在分發復制件時原封不動地附上開源協議的文本。因此在開源代碼的文本中，也能夠找到對應的開源協議版本。

對商業企業來說，商業軟件的開發者下載GPL開源代碼之后，通常都會將GPL開源代碼或修改后的開源代碼和其他自研軟件代碼整合進企業自己的商業軟件之中，并一同分發和使用。因此商業企業需要審查評估其自研軟件與GPL開源軟件之間的關系，即GPL開源軟件／基于開源軟件的衍生作品與其他自研軟件作品是否互相為獨立的軟件。如果GPL開源軟件和自研軟件屬于獨立軟件，則自研軟件并不會被GPL協議所傳染；如果GPL開源軟件和自研軟件不屬于獨立軟件，則自研軟件會被GPL協議所傳染。

如何判斷軟件獨立性需要結合技術與法律，下文將從就自由軟件基金會對軟件獨立性問題的解答、開源軟件實例和我國的司法判例進行介紹。

1、自由軟件基金會對軟件獨立性問題的解答

根據自由軟件基金會發布的GPL相關問題的解答，“聚合體”包含有多個獨立的程序，并在同一個CD-ROM或其他媒體上發行。GPL.v3允許開發者制作并發布一個聚合體，即使其中其他軟件的許可證不是自由許可證或不是GPL兼容的許可證也可以。唯一的條件是聚合體的許可證不能禁止用戶行使每個獨立程序的許可證允許的權利。區分軟件究竟是兩個獨立的程序，還是一個程序的兩個部分的合理的標準既依賴于通信的機制（exec、pipes、rpc、共享地址空間的函數調用，等等），也依賴于通信的語義（交換了什么樣的信息），具體判斷的工作則應交由法院完成[1]。

2、“OpenHarmony”開源項目中對開源軟件獨立性的說明

近期，華為公司自行研發的“OpenHarmony”開源項目也公開了相應的軟件結構和代碼說明，其中就有開發者針對軟件獨立性的特別說明。舉例而言，“OpenHarmony”中包含一個名為“third_party_mtd_utils”的開源軟件，該軟件適用GPL.v2，“OpenHarmony”的開發者對該開源軟件進行了如下說明：“third_party_mtd_utils用于編譯生成jffs2文件系統鏡像的打包工具，該工具用于打包jffs2格式的rootfs和userfs鏡像，代碼不會編譯打包到kernel_liteos_a內核中，故kernel_liteos_a內核不受GPL影響”；又例如，“OpenHarmony”開源項目中有一名為“vendor_hisi_hi35xx_thirdparty_uboot_src”的開源軟件，開發者對其的說明是：“uboot是作為獨立進程，不會導致boot外的軟件受到GPL許可證的影響”[2]。由此可見，華為公司在開發“OpenHarmony”開源項目時，已經注意到開源義務，從而在軟件的結構上，維持開源軟件的獨立性，從而規避開源軟件的傳染性。

3、我國司法實踐中對軟件獨立性的認定思路

（1）柚子（北京）移動技術有限公司與數字天堂（北京）網絡技術有限公司侵害計算機軟件著作權糾紛案

該案的原告數字天堂公司主張被告柚子公司侵犯了原告的軟件著作權，被告柚子公司主張原告的涉案軟件中使用了GPL開源代碼，對應的GPL協議的版本為第三版。一審法院審理認為，因原告主張被告使用的是涉案軟件中的三個插件，而該三個插件屬于獨立的軟件作品，因此，需要判斷的是該三個插件是否是受GPL協議限制。一審庭審中，被告認可該三個插件均處于獨立的文件夾中，該文件夾中并無GPL開源協議文件。據此，一審法院認為：“涉案三個插件的文件夾中并無GPL開源協議文件，而涉案軟件的根目錄下亦不存在GPL開源協議文件的情況下，盡管涉案軟件其他文件夾中包含GPL開源協議文件，但該協議對于涉案三個插件并無拘束力，涉案三個插件并不屬于該協議中所指應被開源的衍生產品或修訂版本，被告柚子公司認為原告數字天堂公司軟件為開源軟件的相關抗辯理由不能成立。被訴行為構成對著作權人復制權、改編權及信息網絡傳播權的侵犯”[3]。

被告柚子公司在二審中提出GPL協議的“傳染性”問題，被告主張涉案軟件中既然已經采用了GPL開源代碼，那么無論是否僅涉及插件，GPL的傳染性也會導致整個涉案軟件均應適用GPL協議從而成為可以供他人自由使用的開源軟件。但是二審法院依然沒有對GPL協議的文本進行研究，在二審判決中依然強調沒有在涉案軟件的根目錄中發現GPL協議文件，從而不認可被告主張的GPL協議傳染性觀點，進而否認涉案軟件已經成為開源軟件的觀點[4]。

該案為我國司法實踐中涉及GPL開源協議的第一案，但是從法院的審查嚴謹性上，似乎并不盡如人意。該案實際上已經觸及了GPL開源協議最關鍵的“傳染性”問題，就判決書中查明的案件事實來看，原告主張權利的涉案軟件的部分代碼確實是用了開源代碼，其軟件整體的確存在已經被傳染成為開源軟件的可能性。但是一、二審法院都并沒有對涉案軟件和插件的通信機制和通信語義進行審查，而是僅憑軟件目錄中沒有開源協議文本就認定了涉案軟件不受開源協議的規制，直接排除了涉案軟件整體已經被傳染稱為開源軟件的可能性。事實上，假使原告在開發涉案軟件的過程中有意沒有遵循開源協議的義務放置開源協議的文本，抑或是第三方開發的過程中，規避開源的義務而沒有放置開源協議的文本，均有可能導致該案的結果截然相反。本案作為開源協議“傳染性”的第一案，在認定是否適用“傳染性”的問題上，法院沒有結合開源協議傳染性條款相關內容和軟件技術細節進行深入審查討論，判斷依據簡單，得出結論仍有進一步商榷討論的空間。

（2）北京閃亮時尚信息技術有限公司、不亂買電子商務（北京）有限公司侵害計算機軟件著作權糾紛案

本案中，原告不亂買公司主張被告閃亮公司侵犯原告的軟件著作權。原告同樣抗辯涉案軟件已經被GPL開源協議傳染從而整體成為開源軟件。本案涉及的是GPL.v3開源協議。本案中，被告舉證證明了原告的網站的前端代碼中采用了開源代碼，如果能夠進一步證明前端代碼和后端代碼構成一個整體軟件進行分發，那么涉案軟件可能已經受到“傳染性”的影響。本案的一審法院認為，原告的網頁僅有前端代碼明確使用了開源代碼，原告主張權利的是其后端代碼。前端代碼開發主要是指前端用戶可見的操作界面如頁面布局、交互效果等頁面設計的一種實現方式，后端代碼開發則主要是指后端用戶不可見的服務端相關邏輯功能等模塊的實現，二者展示方式不同、所用技術不同、分工亦有明顯區別，屬于可獨立的程序[5]。因此一審法院認為，不亂買公司雖在其前端代碼中使用了開源代碼，但其后端代碼程序并非其前端程序的衍生品或修訂版本，故根據GPL協議的相關規定，該協議對涉案權利代碼并無拘束力。

在二審中，被告上訴稱原告的前端代碼和后端代碼存在交互且沒有進行有效隔離，不是相互獨立的，根據GPL協議的相關內容以及極強的傳染性特性，不亂買公司的前端文件和后端文件共同構成的其主張著作權的軟件，整體軟件都可以視為前端程序的修訂版本，應當遵循GPL協議向所有第三方無償開源。最高院在二審判決中認為，首先，前端代碼和后端代碼具有獨立性，“前端代碼與后端代碼是可以分別獨立打包、部署的。因此，前端代碼與后端代碼在展示方式、所用技術、功能分工等上均存在明顯不同，不能因前端代碼與后端代碼之間存在交互配合就認定二者屬于一體，原審法院認定前端代碼與后端代碼相互獨立并無不當”。其次，涉案軟件是由前端代碼和后端代碼聯合構成的“聚合體”：“根據2007年6月29日發布的GPL協議第3版第5條關于‘一個受保護程序和其它獨立程序的聯合作品，在既不是該程序的自然擴展，也不是為了生成更大的程序，且聯合作品和產生的版權未用于限制編譯用戶的訪問或超出個別程序許可的合法權利時，被稱為聚合體。包含受保護程序的聚合體并不會使本許可應用于該聚合體的其他部分’的規定，閃亮時尚公司所稱GPL協議的“傳染性”應當是指GPL協議的許可客體不僅限于受保護程序本身，還包括受保護程序的衍生程序或修訂版本，但不包括與其聯合的其他獨立程序。本案中，雖然不亂買公司認可其前端代碼中使用了GPL協議下的開源代碼，但其主張權利的是后端代碼，其后端代碼是獨立于前端代碼的其他程序，并不受GPL協議的約束，無需強制開源”[6]。

最高院的在該案中的二審判決引用了GPL.v3開源協議中對開源傳染性的例外條款。當開源代碼與軟件的中的其他獨立程序組成“聚合體”時，開源協議不會對其他程序進行傳染。最高院參考了自由軟件基金會判斷軟件獨立性的標準，考慮了通信的機制和通信的語義，得出后端代碼具有獨立性的結論。最高院的前述判斷依據更為科學合理，得出結論也更準確。

開源協議合規的落腳點必然是履行協議要求的開源義務。對于GPL開源協議項下的義務，在開源軟件合規項目中應當注意審查企業是否不折不扣地全面履行了相關開源義務。否則極有可能自動觸發著作權許可合同的解除或終止條件，隨之面臨巨大的軟件著作權侵權法律風險。

如果發生開源義務要求與企業商業軟件的保密要求之間的矛盾確實無法調和時，可以建議企業在阻斷GPL傳染性的基礎上，采用自研軟件進行替代。