開源許可證及其檢測工具研究

何東杰 宋 昊 王 琪 匡翔宇 劉為懷 蔣丹妮(中國銀聯電子支付研究院電子商務與電子支付國家工程實驗室 上海 00)(復旦大學計算機科學技術學院 上海 00433)

0 引 言

隨著開源軟件的不斷發展和完善,其地位也日益重要,很多中小型公司都使用開源軟件，并將其產品提供到開源社區，以求從其他貢獻者中獲益，從而加速產品的完善、接受和普及。開源許可證伴隨著開源軟件而產生，開源許可證提供了軟件的原作者對于開源軟件使用的許可授權，從而使得任何人都能夠自由地使用開源軟件。

但是，開源許可證的組織也強調對于有開源許可證的軟件要謹慎使用，避免產生法律問題。然而一些中小型的公司或者經驗不足的工程師往往忽略了這些開源許可證的重要性，對開源軟件進行簡單包裝后便進行商業化使用或銷售[1]，違反了開源許可證中的條款，為企業帶來了法律上的問題。

因此，對現今主流的許可證條款進行研究，然后基于研究結果，給予軟件開發者開源許可證中存在的法律風險及限制和許可證兼容性的提示，讓開發者在軟件開發之前將上述問題解決，具有重要的應用價值。但是，現今主流的檢測工具僅僅只能檢測開源軟件中的許可證名稱、數量等，并不能基于許可證的條款給出許可證的兼容性和法律風險的分析結果[5]。

針對上述問題，本文對現今主流的許可證的條款和許可證的法律效益進行了研究，將不同類型的法律風險和許可證的兼容性問題進行分類分析，基于研究設計并開發了開源軟件許可證的檢測工具FINDLICENSE。

FINDLICENSE能夠從許可證兼容、開源發布軟件、商業化發布軟件、商業化服務提供等不同使用角度能夠給出開源軟件使用的風險提示，為開源軟件的合法使用提供了重要的參考依據，使得企業在使用開源軟件之前就能避免法律風險。

1 開源許可證及其檢測工具

1.1 開源許可證及其權益

軟件許可證是一種具有法律性質的合同或指導，目的在規范受著作權保護的軟件的使用或散布行為。通常的授權方式會允許用戶來使用單一或多份該軟件的副本，因為若無授權而徑自使用該軟件，將違反著作權法給予該軟件開發者的專屬保護。效用上來說，軟件授權是軟件開發者與其用戶之間的一份合約，用來保證在匹配授權范圍的情況下，用戶將不會受到控告。

開源許可證是軟件許可證的一種特殊形式，其授權一般是針對軟件的開放源代碼，而不同于商業軟件的運行文件，其允許用戶在承認軟件原作的著作權的基礎上對軟件源代碼的使用、修改、私用等權益，以保證開源軟件能夠合法地被廣大軟件開發者自由使用和共享。

開源許可證的一般格式如圖1所示。

XXXLicenseCopyright(c)[year][fullname]PermissionisherebyxxxTheabovecopyrightnoticeandthispermissionnoticeshallbeincludedinxxxxxx．………

圖1 開源許可證的一般格式

開源軟件的許可證的種類比較繁多和復雜，常用的有六個：AGPL、GPL、LGPL、BSD、Apache、MIT，表1列出了GITHUB上排名前十的許可證的使用比例。

表1 許可證使用情況排名表

在法律上，一般采用知識產權法對軟件進行保護，與軟件相關的知識產權包括著作權、專利權、商標權、商業秘密權、反不正當競爭權。開源軟件許可證的在法律上通常被認為是合同，一般都遵照《合同法》進行判別，即遵照合同本身聲明的權益進行判別。

在現今主流的開源許可證中，聲明的條款涉及軟件權益的主要包括商業用途、分發、修改、專利授權、私用、公開源碼、放置許可協議與版權信息、使用網絡分發、使用相同協議、聲明變更、承擔責任、使用商標等12項。

1.2 開源許可證使用方法及檢測工具

若要在項目中使用某種開源許可證，一般有三種使用方法：在“LICENSE”文件使用、在源代碼注釋中使用、在readme文件中使用。

使用“LICENSE”文件，需要在項目的根目錄下創建一個“LICENSE”的文件，表明整個項目置于此許可證的聲明下；使用注釋的形式聲明在源代碼中，表明僅此代碼文件置于此許可證的聲明下；在readme文件中放置許可證的全文條款，表明readme文件中聲明的整個軟件置于此許可證的聲明下。

因此，若要檢測開源許可證，可以根據“LICENSE”文件、源代碼注釋中、readme文件中等查看軟件許可證，但是這種方法過于浪費人力，而現在網絡上有提供許多自動化工具來檢測許可證。The Binary Analysis Tool可用于審計開源軟件的內容，其中包括了許可證的內容；FOSSology可以用于許可證和版權檢測；The Open Source License Checker可以用于檢查和分析來自開源包的許可證信息；Spago4Q是一款免費開源軟件質量平臺，可以檢測出項目中的許可證；Apache Rat是一個發布的審計工具，專注于軟件許可證，告知你使用準確性，以提升許可證使用的效率。

但是，一般的許可證檢測工具的結果都是羅列出項目中許可證的種類、數量以及許可證所在的目錄信息，并不能檢測出許可證之間的兼容性問題和法律風險問題。

2 開源許可證的法律風險分析

主流開源許可證中，聲明的條款主要包括商業用途、分發、修改、專利授權、私用、公開源碼、放置許可協議與版權信息、使用網絡分發、使用相同協議、聲明變更、承擔責任、使用商標等12項。

根據開源許可證的法律依據和效用，參考不同開源許可證的條款，在使用開源軟件時，為避免產生法律問題，主要需要考慮以下幾方面的問題：

? 開源要求

? 修改聲明

? 專利允許

? 許可證兼容

? 商標使用

? 網絡分發

根據以上六方面的問題分析，我們將開源許可證的法律風險分為六個方面：商業化風險、許可證兼容風險、專利侵權風險、產權歸屬風險、商標使用風險、服務提供風險。

2.1 商業化風險

商業化風險，是指開源許可證要求開源軟件的任何衍生作品都要開源發布，因此使用此類許可證下的軟件進行商業版本發布都必須開源，這與商業化的利益要求不符，會導致商業化風險。

不同許可證的要求大致分為三類：不強制開源；作為庫引用不強制開源；強制開源。表2中開源一列列出了常見許可證的分類。其中，強制開源的許可證多是一些較為嚴格的許可證。如GPL、LGPL、EPL和MPL等，發布軟件時必須提供源代碼；作為庫引用不強制開源的許可證，僅僅只有LGPL的不同版本，在商業化上有實際價值，但只能作為庫來引用，不能直接使用任何源代碼；不強制開源的許可證，包含了BSD、Apache、MIT等常見許可證。這類許可證是比較寬松的許可證，在其他方面往往也限制較少，對商業使用來說，這些許可證是比較友好的。

表2 常見開源許可證條款聲明情況表

續表2

對于強制開源的許可證，使用時要慎重，因為違反開源許可證被起訴已經有許多成功的判例。如2007年2月，Skype被起訴違反了GPLv2許可協議，自由軟件基金會(FSF)稱，Skype是基于Linux的WSKP100 WiFi VoIP電話，而 Skype并未基于GPL協議提供其Linux產品的源代碼。德國一審法庭調查后認定事實確鑿，宣判Skype違反了協議規定。

2.2 許可證兼容風險

許可證兼容風險，是指開源軟件引用了其他多個開源軟件，而這些引用的開源軟件可能是不同的許可證，此時開源軟件本身的許可證和引用的開源軟件的許可證可能會存在兼容性問題。這其中包含了兩方面的問題：第一，開源軟件本身的許可證與引用的開源軟件的許可證相同權益的條款是否有沖突以及最終的許可證應該如何放置；第二，開源軟件本身的許可證是否允許引用使用了其他許可證下軟件。

開源軟件協議從使用限制強弱上來看，可以分為三大類：放任型、弱保護型、強保護型。一般來說，強限制協議可以向下兼容弱限制協議，這意味著軟件最終許可證取決于強限制協議。但限制條件完全對立的兩個協議則無法兼容。圖2說明了常見開源軟件協議之間的條款兼容性情況。

圖2 常見開源軟件協議條款兼容性指示圖

箭頭從A框到B框代表，A框和B框中的協議是兼容的，即兩種開源軟件可以組合使用，且最終License取決于B框中協議。而如果兩個框之間沒有單向的箭頭貫通，即意味著兩個框中的協議不兼容，即兩種開源軟件不可以組合使用。

舉例說明，如MIT->BSD->Apache->LGPLv3->GPLv3.0是單向通路，通路上的任意兩個及以上的開源軟件都可組合使用，軟件最終License取決于通路上箭頭最末端GPLv3.0協議。MPL<-BSD->Apache是一個雙向鏈路，鏈路兩端的MPL和Apache協議是不兼容的，無法組合使用。

對于開源軟件本身的許可證是否允許引用其他許可證下的軟件可以由表2中使用相同協議條款判別。其中，有相同許可證要求的許可證在分發軟件時，必須使用相同的許可證發布。無相同許可證要求且不強制開源的許可證，可以設置任何類型的許可證，且不會存在法律問題。

2.3 專利侵權風險

專利侵權風險，是指開源軟件的衍生作品申請了專利，而許可證條款不承認衍生作品申請專利或者衍生作品申請的專利歸原作者所有，這種情況也將產生嚴重的法律問題。

常見的開源許可證對于專利的要求如表2中的專利一列所示。由表2可知，許可證的專利授權有三種情況：明確專利授權，許可證允許貢獻者進行專利申請；不提供專利授權，許可中明確聲明它不授予貢獻者專利授權；未明確，許可證中沒有提到專利許可。

明確授予專利許可權的許可證包括表2專利一列中列出的12 種許可證，這些許可證可以申請專利，并且在專利法保護之下。但是，有一部分許可證同樣要求開源，這部分許可證申請專利也無太大作用。四個許可證明確表示不提供專利授權，對于不承認專利的許可證不可申請衍生作品的專利，不然會產生侵權問題，所以應盡量避免選擇此類許可證；未明確專利授予問題的許可證，包括GPL2.0、LGPL2.1和MIT許可證等，在合同法范圍內未聲明權益，可以認為承認衍生作品的專利權，所以可以對衍生作品申請專利。值得注意的是，對于衍生作品專利的申請，只能針對自己修改的部分，不能包含原作品部分。另外，部分開源許可證要求衍生作品中對原作品的任何修改或添加都要進行聲明，否則不承認衍生作品的專利權。

著名的Robert一案可以看出這一條款的重要性。Robert Jacobsen研發出了名為“解碼博”的軟件，放置在SourceForge供其他人無償下載。KAM開發了名為“解碼指揮官”的軟件。在開發過程中，下載了Robert的軟件套件，并將其中的定義文檔和其他部分程序納入到了“解碼指揮官”的軟件之中，向美國政府申請了一項專利。之后由于糾紛，Robert一紙訴狀將KAM送上了法庭。最終，上訴到美國聯邦法院，判決KAM侵犯版權，理由是“開源協議”是一種著作權協議，違反協議就是侵權行為。

2.4 版權歸屬風險

版權歸屬風險，是指開源許可證明確聲明了基于原作品的衍生作品的修改部分必須進行明確聲明，才能承認其具有對修改部分的版權，而如果未對此部分進行聲明便進行了商業使用，會產生版權歸屬不明的情況，由此可能會產生法律問題。

表2修改聲明一列列出了常見許可證的修改聲明要求。為防止產生法律問題，對于使用了明確要求聲明修改的開源許可證的軟件，在進行商業化時，必須對修改部分進行聲明，以明確版權歸屬。

“綠壩- 花季護航”用于不良圖像過濾的主要文件cximage.dll、CImage.dll、xcore.dll和 Xcv.dll均來自OpenCV。OpenCV采用的是BSD許可證，當商業軟件使用BSD許可證的開源程序時，需要在軟件版權信息中加上BSD許可證聲明，以及自己變更部分的聲明，綠壩并未在其軟件中加入這一聲明。2010年初，美國加州Cybersitter軟件公司向當地法院提起訴訟，稱“綠壩- 花季護航”軟件抄襲了該公司的近三千行代碼，要求索賠22億美元。

2.5 商標使用風險

商標使用風險，是指如果開源軟件的衍生作品使用并申請了商標權，但原開源軟件的許可證條款聲明了不承認商標權，這將會導致衍生產品的商標不合法，不具有法律擔保性。

常見的開源許可證對于商標的使用條款有兩種：一種是明確不承認使用商標，另一種是沒有條款針對商標進行聲明。常見許可證對于商標使用的聲明情況如表2商標一列所示。

其中，明確不提供商標使用的許可證有11種。但是，值得注意的是，這些不承認商標權的許可證，有6種是不要求使用相同許可證的。因此，只要在衍生作品中不使用原來的許可證，就可以使用商標，其他的不承認商標權的許可證則不能使用商標。對于許可證條款中沒有明確商標使用的，有16種，這些許可證下的衍生作品則可以使用商標。

2.6 服務提供風險

由于云計算的興起，使得軟件可以不通過傳統的互聯網或光盤release分發，而以“不分發軟件，為客戶在云上提供網絡服務”的模式使用軟件，這種服務模式雖不受強制開源的要求，但是受網絡分發條款限制。

服務提供風險，是指軟件在云上提供網絡服務的軟件是某些開源許可證下的軟件的衍生或者原生作品，但是這些開源許可證不允許衍生作品閉源進行云服務的提供，因此，此種使用方式會產生法律上的風險。

常見的開源許可證對于網絡分發的條款有兩種：一種是明確聲明網絡分發必須開源，另一種是沒有條款針對網絡分發進行聲明。常見許可證對于網絡分發的聲明情況如表2網絡分發開源一列所示。其中，明確聲明網絡分發必須開源的只有三種，這三種許可證即使在商業中以服務形式也無法使用，而沒有聲明網絡分發的許可證，可以閉源并以云服務的形式供商業客戶使用。

因此，對于有開源許可證的軟件，首先閱讀許可協議與版權信息條款，按照許可證要求將開源許可證放置于軟件之中；然后，參照表2和圖1，分別從開源要求、修改聲明、許可證兼容、專利允許、商標使用、網絡分發六個方面分別去衡量商業化風險、許可證兼容風險、專利侵權風險、產權歸屬風險、商標使用風險、服務提供風險，在符合許可證條款的條件下，使衍生作品避免法律糾紛和許可證兼容問題。

3 FINDLICENSE工具

基于上述分析結果，我們的工具FINDLICENSE能夠提供以下功能：查找開源軟件中包含的所有許可證和權益信息、指出開源軟件中包含的不同許可證兼容問題、給出開源發布軟件的風險提示、給出商業化發布軟件風險提示、給出作為服務提供使用軟件風險提示、給出其他權益風險提示、自定義開源許可證添加、自定義許可證風險添加等。

3.1 設計概述

圖3展示了FINDLICENSE工具的整體架構。它使用python語言實現，使用FLASK作為后端，HTML作為前臺，用戶只需將待檢測軟件的源代碼壓縮包，在WEB界面上傳至后臺或者傳入源代碼托管倉庫地址進行掃描，因此是與平臺無關的。它包含了一個輸入：待檢測的開源軟件源代碼壓縮包文件或者開源軟件源代碼所在的倉庫地址。包含一項輸出：開源軟件許可證的分析報告，分析報告現在以網頁HTML的形式給出，報告包含了開源軟件許可證兼容問題、開源發布軟件風險、商業化發布軟件風險、作為服務提供使用軟件風險、其他權益風險以及文件中包含的許可證詳細的官方信息。

圖3 FINDLICENSE工具架構圖

我們的FINDLICENSE遵循模塊化設計的思路，工具包含了三個主要模塊：文件構建組件、掃描檢測組件、報告生成組件。文件構建組件負責將上傳的源代碼壓縮包解壓到指定位置或者根據倉庫地址將其下載到指定位置，然后分析文件結構和文件信息，構建文件掃描的樹狀圖。掃描檢測組件負責根據庫中許可證構建掃描的語義表，然后根據語義表進行按照文件構建組件給出的結構圖進行掃描，匹配許可證和版權信息，再根據定義的許可證沖突和風險，對掃描結果進行匹配。報告生成器根據掃描檢測組件掃描檢測的結果，結合庫中許可證的信息，以HTML格式的文件將掃描結果輸出，并返回給用戶。

許可證的規范使用方法是在“LICENSE”文件使用、在源代碼注釋中使用、在readme文件中使用，但是考慮到不規范使用的情況，FINDLICENSE是進行全文本掃描，可以掃描出開源軟件源代碼中多類型應用許可證。

3.2 實 現

文件構建組件。包含文件解壓縮器、倉庫文件下載器、文件目錄構建器。其中，文件解壓縮器實現對ZIP、RAR、GZ、BZ2等格式的文件進行解壓縮。倉庫文件下載器實現從遠程倉庫到本地的復制，目前僅支持GIT的倉庫。文件目錄構建器對于整個文件夾進行遍歷，然后構建文件夾的樹形結構，以JSON數據形式保存。

掃描檢測組件。包含了掃描調度器、文件掃描器、許可證語義構建器、沖突及風險檢測器。文件掃描器根據許可證語義構建器提供的關鍵字，對掃描調度器指定的文件進行語義匹配，匹配到對應的關鍵字之后，將關鍵字的位置及許可證或者版權的標示保存到結果中。實際掃描中，我們的問題相當于給定的長度為n的文本，和模式集合P{p1,p2,…,pm}，找到文本中的所有匹配模式的位置，而AC算法可以在O(n)時間復雜度內找到文本中的所有目標模式，而與模式集合的規模m無關，因此我們使用AC算法進行實際的文件掃描。

AC算法的算法思想如下：對于模式集合P{he，she，his，hers}，模式s(he)的非前綴子串he，實際上卻是模式(he)，(he)rs的前綴。如果目標串target[i…i+2]與模式she匹配，同時也意味著target[i+1…i+2]與he、hers這兩個模式的頭兩個字符匹配，所以此時對于target[i+3]，我們不需要從target[i]進行比較，而直接將target[i+3]與he、hers兩個模式的第3個字符比較，然后直接向后繼續執行匹配操作。

根據上述的AC算法，我們文件掃描器對每個文件中提供的關鍵字進行語義匹配，匹配到對應的關鍵字之后，將關鍵字的位置及許可證或者版權的標示保存到結果中，然后繼續掃描，直到整個文件掃描結束，最后將掃描的結果返回給給掃描調度器。

掃描調度器根據文件目錄構建器給出的文件結構，按照深度優先的策略，調度文件掃描器進行掃描，并將文件名稱和掃描的結果以字典的形式保存在字典中，供沖突及風險檢測器使用。在實際調用中，單線程的調度掃描速度過慢，因此，為加快掃描速度，我們借鑒了分布式系統中MapReduce的思路，將掃描階段進行了分解，具體執行流程如圖4所示。

圖4 文件掃描調度執行流程圖

掃描開始時，我們掃描調度器會啟動多個文件掃描器的進程，按照圖4中由最底層葉子節點開始，向上分別對不同的文件進行掃描，待所有文件掃描器的進程將所有文件掃描結束后，產生中間結果；爾后，掃描調度器會啟動多個結果合并器的進程，以文件路徑作為鍵，掃描結果作為值，將掃描結果進行合并，得到輸出。

許可證語義構建器，首先在許可證目錄中將所有許可證逐個按照內容進行切分。切分完成后，將許可證名稱和對應的切分內容按照鍵和內容的形式構建字典，待所有許可證都切分并且構建完畢之后，將字典返回給文件掃描器供實際掃描過程中使用。

沖突及風險檢測器。首先根據我們的研究結果構建了許可證風險庫和不兼容庫，實際使用中，用戶可以對這個庫進行自定義的添加、修改、刪除等操作。風險庫包含了商業化風險、專利侵權風險、產權歸屬風險、商標使用風險、服務提供風險，風險庫中包含了此種風險的名稱和其對應的許可證的鍵。兼容庫中包含了所有強許可證(即衍生作品必須使用本許可證并且要求開源)的鍵和兼容風險名稱。沖突及風險檢測器根據掃描調度器提供的字典，在庫中對風險和兼容性規則進行匹配，匹配到風險或者兼容性問題后便將許可證的鍵和風險類型保存在字典中，待所有掃描調度器提供的字典掃描完畢后，將結果的返回給報告生成器。

報告生成組件僅包含報告生成器一個組件，報告生成器使用了FLASK，將掃描的結果填充到HTML模板的指定位置，并將最終生成的報告以HTML的形式返回給客戶。

4 評 估

我們對于github前20的項目進行了測試。測試分別使用FOSSology[6]、The Open Source License Checker、Spago4Q、 Apache Rat以及我們自主開發的FINDLICENSE，我們從三方面對我們的工具進行評估：第一，掃描涵蓋結果的全面性，即許可證的檢測工具為用戶提供的結果涵蓋許可證版權信息、許可證詳細信息、許可證兼容問題、許可證法律風險四個方面的程度。第二，對于整個開源軟件許可證掃描的準確性，即許可證檢測工具是否能夠將所有的許可證都檢測出來，比率如何。第三，掃描的時間，即對于同一軟件，許可證掃描工具從用戶提交數據到生成結果所需要的時間。測試中，我們使用的系統環境及軟件版本如表3所示。

表3 測試系統環境表

4.1 掃描涵蓋結果的全面性

我們從許可證版權信息、許可證詳細信息、許可證兼容問題、許可證法律風險四個方面去衡量許可證涵蓋結果的全面性，每個方面各占25%，不同軟件許可證檢測工具結果涵蓋程度如圖5所示。

圖5 不同軟件許可證檢測工具結果涵蓋程度

圖5中，FOSSology和The Open Source License Checker(OSLC)只能夠檢測許可證版權信息和許可證詳細信息，沒有許可證兼容問題和許可證法律風險這兩個方面，所以只有50%；Spago4Q僅能夠提供許可證版權信息，所以只有25%；Apache Rat能夠提供許可證版權信息和許可證詳細信息，但對于許可證兼容問題，只能提供強許可證使用正確性提醒，所以總值75%；而我們的FINDLICENSE工具包含了許可證版權信息、許可證詳細信息、許可證兼容問題、許可證法律風險四個方面，所以涵蓋程度為100%，也是五個工具中功能和涵蓋程度最強大的。

4.2 許可證掃描的準確性

許可證掃描的準確性，我們對于gitbub上排名前20的項目源代碼分別使用FOSSology、The Open Source License Checker、Spago4Q、 Apache Rat以及我們自主開發的FINDLICENSE進行掃描，掃描結果的準確性如圖6所示。

圖6 不同軟件許可證檢測工具檢測準確率

檢測中，我們都沒有自定義用戶庫，都是使用軟件默認庫進行掃描。從圖3可以看出，Apache Rat以及我們自主開發的FINDLICENSE掃描的準確率最高，能夠達到100%，FOSSology和The Open Source License Checker能夠達到99%以上，Spago4Q能夠達到98%以上。分析其數據差異的原因，由于我們自主研發的FINDLICENSE和Apache Rat都不僅針對庫中的許可證進行掃描，并且匹配LICENSE、COPYLEFT、COPYRIGHT等敏感字信息，所以掃描的準確率很高。而FOSSology和The Open Source License Checker的默認庫涵蓋程度很高，所以掃描的準確率也能夠達到99%以上，但是對于最新的小眾的許可證掃描就不盡理想。Spago4Q的默認庫相對來說涵蓋程度略低，達到98%左右，同樣對于最新的小眾的許可證掃描不盡理想。

4.3 掃描的時間

許可證掃描的時間，我們分別使用了三種不同大小的開源軟件：大型軟件、中型軟件、小型軟件。大型軟件我們使用了如MYSQL代碼在GB級的，中型軟件我們使用如bootstrap在MB級別的，小型軟件我們使用如jquery在KB級別的分別進行檢測，檢測結果如圖7所示。

圖7 不同軟件許可證檢測工具掃描時間圖

從圖7我們可以看出，針對小型軟件的掃描速度來看，五種軟件相差不大，最快的是Spago4Q，最慢的是OSLC，所有軟件平均時間在3 s左右。中型軟件掃描最快的是OSLC，最慢的是Spago4Q和FOSSology，Apache Rat、FINDLICENSE基本相同，居于中間位置，所有軟件平均時間是23 s左右。而對于大型軟件來說，差別相對較大，最快的OSLC，時間大約在2 min，而最慢的是FOSSology，時間大約在30 min，所有軟件平均時間在27 min左右。

分析其原因，我們總計的掃描時間=軟件啟動時間+解壓縮時間+實際掃描時間。對于小型軟件來說，OSLC因為是java語言開發的，程序啟動相對較慢，所以軟件啟動時間很長，而小型軟件的掃描時間本來就短，所以OSLC最慢，而Spago4Q最快。對于中型軟件來說，因為掃描平均時間在23 s左右，此時軟件啟動時間所占比例就很小，主要是解壓縮時間和實際掃描時間。而中型軟件文件數量不大，所以解壓縮時間也相對較短，軟件的總掃描時間取決于實際掃描時間大小，而OSLC、Apache Rat、FINDLICENSE的軟件許可證庫是從文件中直接讀取，而Spago4Q和FOSSology是從第三方數據庫工具中讀取，所以相對來說，OSLC、Apache Rat、FINDLICENSE快于Spago4Q和FOSSology。對于大型軟件來說，有三點原因：第一，因為OSLC要用戶手動將文件先解壓才能掃描，而大型軟件文件數量很龐大，解壓縮耗費時間巨大，而OSLC省去了解壓縮時間，所以最快。第二，掃描要基于許可證的庫進行匹配，而FOSSology和我們自己的工具FINDLICENSE庫相對較全，但是掃描起來也相對耗時，而OSLC、Spago4Q、Apache Rat三者庫較少，所以掃描速度相對較快。第三，我們的工具FINDLICENSE、Spago4Q、FOSSology為方便用戶使用，都是以B/S的形式為用戶提供服務，所以掃描時需要調用工具，相對直接掃描的工具，也會相對耗時。

綜合上述分析，我們的工具FINDLICENSE在掃描涵蓋結果的全面性、許可證掃描的準確性方面都居于第一位，雖然掃描的速度居于中間位置，但許可證的檢測對于實時性要求不高，所以也處于可以接受的程度，未來可以做進一步優化。同時，我們的工具可以以服務的形式部署在云服務器上，方便用戶使用。

5 結 語

本文對開源許可證進行了廣泛的研究，并針對許可證的兼容問題和法律風險，提出了商業化風險、許可證兼容風險、專利侵權風險、產權歸屬風險、商標使用風險、服務提供風險等方面的風險，為開源許可證風險檢測提供了重要的理論依據。然后，根據這個理論，設計并實現了開源許可證兼容性和合法性檢測工具FINDLICENSE。該工具能夠從許可證版權信息、許可證詳細信息、許可證兼容問題、許可證法律風險四個方面給出風險分析，使得軟件開發者在開發軟件之前就能知曉開源許可證中存在的法律風險及限制和許可證兼容性的問題，填補了開源許可證檢測工具在此方面的空白，具有重要的應用價值。之后，我們從掃描涵蓋結果的全面性、許可證掃描的準確性、掃描的速度三方面對我們開發的工具和其他開源許可證檢測工具進行了評估，測試并證明了我們的工具FINDLICENSE在掃描涵蓋結果的全面性、許可證掃描的準確性方面都居于第一位，掃描速度居于中間位置，繼而證明了我們的工具的實用價值。

隨著開源軟件的不斷發展,其地位必將超越商業軟件發揮越來越重要的價值和作用，對計算機發展也將會產生深遠的影響，希望我們的研究和工具能夠為中國開源軟件的發展盡綿薄之力。

[1] Kapitsaki G M,Charalambous G.Find your Open Source License Now![C]//2016 23rd Asia-Pacific Software Engineering Conference (APSEC),New Zealand,2016．

[2] Engelfriet A.Choosing an Open Source License[J].IEEE Software,2009,27(1):48- 49.

[3] Singh P V,Phelps C.Networks,Social Influence,and the Choice Among Competing Innovations:Insights from Open Source Software Licenses[J].Social Science Electronic Publishing,2009,24(3):539- 560.

[4] Shani G,Gunawardana A.Evaluating Recommendation Systems[M]//Recommender Systems Handbook.2011:257- 297.

[5] Yin R K.Case study research:Design and methods[M].New York:Sage publications,2013.

[6] Gobeille R.The FOSSology project[C]//Proceedings of the 2008 International Working Conference on Mining Software Repositories,MSR 2008(Co-located with ICSE),Leipzig,Germany,May 10- 11,2008.

[7] German D M,Manabe Y,Inoue K.Proceedings of the IEEE/ACM international conference on Automated software engineering,2010[C].Antwerp,2010.

[8] Kapitsaki G M,Kramer F.Open Source License Violation Check for SPDX Files[C]//International Conference on Software Reuse.Software Reuse for Dynamic Systems in the Cloud and Beyond.Springer,Cham,2015:90- 105.

[9] Obrenovic Z，Gasevic D．Open source software:all you do is put it together[J]．IEEE Software，2007，24(5):86- 95．

[10] Wu Y,Manabe Y,Kanda T,et al. A Method to Detect License Inconsistencies in Large-Scale Open Source Projects[C]//Proceedings of the 12th Working Conference on Mining Software Repositories,MSR’15.2015:324- 333.

[11] Hammouda I,Mikkonen T,Oksanen V,et al.Open source legality patterns:architectural design decisions motivated by legal concerns[C]//International Academic Mindtrek Conference:Envisioning Future Media Environments.ACM,2010:207- 214.

[12] Bhattacharya J,Suman S.Analysis of popular open source licenses and their applicability to e-governance[C]//International Conference on Theory and Practice of Electronic Governance,Icegov 2007,Macao,China,December.DBLP,2007:254- 257.

[13] Marti D.Reviews:Open source licensing:software freedom and intellectual property law[J].Linux Journal,2005,129:19.