辛小秋：前面各位老師都講了很多關于開源的事情，這里就不重復了，重點講一下關于開源許可證。

我們認為開源許可證和閉源或商業許可證的原理是一樣的，都是一種授權協議，它其實是商業許可證的簡化版，只是為了讓項目開放傳播，就形成這樣一個開源許可證。

到昨天為止，開源促進會上公布被它認可的開源許可證有82個，但是其中要求非常繁雜，每個許可證都有自己的特點，要求不一樣。

如圖，開源許可證分傳染性和開放性。如何區分？一個分支，修改代碼之后是否允許它再做閉源？如果Yes，進入到右邊，如果是No，就進入左邊傳染性許可證。

常用許可證，包括MIT、BSD、Apache、LGPL等等，這些只是簡單我們區分許可證區別的點，后來經過研究，大概有20多項的分別，以后有機會再和大家進行分享。

如圖，GPL網站上為了讓用戶區分GPL系列，包括LGPL之間的兼容性，而做了一張表。橫坐標是想使用GPL2.0或3.0來做開源項目，縱坐標把以前其他開源項目的代碼放到這個項目里，是否和這個項目兼容，就這么一個圖。我們想用GPL2.0開源，用GPL3.0代碼放進去，是否可以？答案是No，也就是說GPL2.0和3.0本身就是不兼容的。

如圖，使用外部鏈接庫放到這個項目里是否被允許。

如圖，用一張更簡單的圖解釋一下各種不同的許可證的兼容性。

舉例，有一個項目是用GPL2.0開源，里面放了一些MIT/BSD/A Apache 2.0/LGPL2.1等許可證的代碼放到GPL2.0里去，是否兼容？用這個圖可以一目了然看清楚，LGPL2.1有直接的路徑到達GPL2.0，說明這兩個許可證是兼容的。BSD/MIT有間接的路徑到達GBL2.0，說明這些許可證也是兼容的。Apache 2.0，不管是直接的路徑還是間接路徑，都不可能到達GPL2.0，就是說GPL2.0和Apache 2.0是不兼容的。用GPL2.0開源之后，原先Apache2.0開源過項目的代碼是不允許放到這個項目里來的，這就是許可證的兼容性。

開源帶來的風險。

分兩類：

1.合規性風險。

又分傳染性、兼容性和其他類型風險。所謂合規性風險，總結來說就是當一個用戶在使用開源代碼或用一個許可證去開源的時候，違反了這個許可證的規定，也就是說不合規的使用造成了這樣的風險，就叫合規性風險。造成比較嚴重的后果是別人要求你停止侵權，產品可能被召回；別人要求你必須開放項目源代碼；在你的商業軟件里使用GPL2.0，自由軟件基金會就有權要求你整個項目代碼宣布開源。

在2003年，思科收購了Linksys，它使用底層的驅動是GPL2.0的代碼，思科也沒有在意這個事情，2003年3月完成了對它的收購，此后一年里經受了自由軟件基金會的窮追猛打，告訴他必須要開放路由器的全部代碼。最后思科頂不住這種壓力，為了自己的聲譽，完全開放了路由器產品線，造成了這個產業鏈上其他競爭對手與它的差距瞬間消失，這對于它來說是一個巨大的損失。

2.安全性風險。

目前美國網站上公布的12萬種安全漏洞，2/3來自于開源軟件，而且多數開源許可證也不承諾為它自己項目安全性負責，這就是為什么用戶引入開源軟件的同時會被動引入安全漏洞的原因。

我們國內信通院、發改委這些年一直加強開源工作。

開源治理，工具先行。

開源治理分五個要素：制度、流程、人員、培訓、工具。我們認為合適的工具是開源治理的一個前提。我們認為發現問題，尤其是發現存量代碼和將來增量代碼里開源軟件使用軌跡，里面的許可證信息和安全漏洞信息是我們解決問題的前提。

開源代碼掃描檢測工具的應用場景。

掃描工具里目前有四種應用場景，最重要的應用場景是企業內部代碼檢測需求，因為企業內部分兩種：

1.企業內部有開源的需求，在開源之前，一般的企業都會看一下我們自己需要開源的這部分代碼是否有合規性的風險。因為一旦被別人發現這個開放代碼里有這樣傳染性的許可證或者有兼容性的問題，等于把自己的小辮子放給別人，讓別人去揪，這是非常危險的。對自己商業閉源的代碼，同樣對于大公司來說也有規避合規性風險的要求。

2.目前政府部門監管政策造成的，國家項目里對自主知識產權的要求越來越嚴，以前要求開源的成分不能超過50%，現在不能超過30%，還不能用GPL傳染性許可證的要求。還有重點領域，金融領域、航空領域，每年國家都有特殊的文件，要求一些領域加強風險的防控等等。

3.國際合作里，國內公司生產的產品要出口到歐美，對方合作伙伴要求我們出示一個掃描報告，證明你的軟件沒有這方面合規性或安全性問題，將來一旦出了問題，人家拿這個報告要問責。