一、開源協議下的軟件源代碼類侵犯商業秘密罪案件
如果軟件代碼是開源的,那肯定不能主張為商業秘密,這個沒有爭議,但是如果這些代碼是在開源協議的基礎上做出來的衍生作品,這個時候還能不能主張為商業秘密呢?
我們來說一起無罪案件,某科技有限公司、法定代表人A和研發工程師B被指控侵犯商業秘密罪,A原本是被害企業的員工,在工作期間完成了系統軟件,這套軟件代碼設置了GPL的開源協議聲明,后來,被害企業又根據老代碼迭代了更新為2.0版本,部分程序源代碼是原封不動照搬了老代碼,被害企業認為A違約使用了自己的2.0版本的軟件代碼,為此,對A等人提起了刑事控告。這起案件,檢察院最終作出了全案不起訴的決定。因為被害企業沒有遵循開源協議,反而將代碼主張為商業秘密,最終被認定衍生作品無秘密性,對其主張不予支持。
在涉及開源協議的侵犯商業秘密罪案件當中,我們首先要了解的是涉及到哪種開源協議,開源協議的傳染性及要求是什么?另外,就是開源協議在我國的法律效力怎么樣。
一般每一個開源軟件都會附有一個許可證,許可證以格式文本形式的授權許可協議來體現,許可證規定了軟件使用者的權利和義務,使用者只有同意遵守這個許可證才能合法使用開源軟件,或者使用這個開源軟件,就視為同意接受許可證,目前公認的許可證約有70種。不同的許可證依據不同許可協議條款,對使用者要求承擔的義務也不同,比如GPL許可證就對使用者的限制相對嚴格,如果將附有GPL許可證的開源軟件中的源代碼進行了修改或衍生,對于修改代碼和衍生代碼,使用者也必須將其以GPL許可證的方式作為開源軟件發布,而不得將其作為閉源的商業軟件來發布或者銷售。
所以,在上面案件中,基于被害企業所主張的代碼是在GPL協議上所衍生的2.0版本,可以認為這樣的代碼屬于輕易獲取,不具有秘密性。
二、軟件源代碼類侵犯商業秘密罪案件,如何看待非公知性
非公知性是判斷某個技術能否成為商業秘密的一個重要因素,在軟件代碼類侵犯商業秘密罪案件中,代碼可以分為源代碼、目標代碼及可執行代碼,在判斷代碼的非公知性問題上,目標代碼和可執行代碼的非公知性認定會相對復雜,由于目標代碼在軟件公開發售時,用戶可以直接獲取的,這部分代碼通常被認為已經公開,不再具有非公知性。但是,目標代碼的公開并不當然導致源代碼喪失非公知性,我們應當根據反編譯的難易度來判斷相應源代碼是否容易獲得,由于目標代碼的非可讀性,以及編程語言的復雜性,反編譯工作基本不可能僅僅通過觀察來完成。
不同編程語言的反編譯難度不同,對于一些可還原度較高的編程語言,若事先沒有進行加密或混淆技術處理,則很容易通過反編譯獲取對應源代碼,這就會影響其非公知性認定。所以,在軟件源代碼非公知性認定中,需要考慮編程語言對反編譯難度的影響,以及權利人是否采取加密或混淆等保護措施。
在瀏覽器/服務器架構下,對軟件源代碼非公知性的認定也會產生顯著的影響。在這樣的架構下,源代碼通常可以分為前端代碼和后端代碼,兩者的展現方式、所用技術和功能分工均有所不同,與用戶界面相關的“顯示類”源代碼,無需編譯直接通過瀏覽器端運行,而涉及業務邏輯的“核心類”源代碼,則編譯成目標代碼后在服務器端實現。在此類框架下,用戶可以在瀏覽器界面獲取"顯示類"源代碼,這部分運行于瀏覽器端的源代碼已經公開,不再具有非公知性,但服務器端的核心源代碼仍處于保密狀態,并未喪失非公知性。所以,通常來說,運行于瀏覽器端的各種源代碼具有公知性,但服務器端的核心源代碼仍處于保密狀態,并未喪失非公知性。
![]()
三、軟件代碼類侵犯商業秘密罪案件,如何鑒定?
隨著開源軟件普及,以及第三方代碼被廣泛使用,在軟件代碼類的商業秘密鑒定中,如何正確處理這些非原創代碼,成為了一個非常重要的問題。
對于開源代碼的識別,司法鑒定通常通過這樣的方法:首先,通過源代碼的協議聲明判斷源代碼來自于開源軟件。一般情況下,開源軟件的源代碼文件頭都會有開源軟件遵循的協議聲明,如果是簡單、機械地引用這些代碼,司法鑒定人員是可以通過協議聲明辨識他的來源和版權情況的。另外,我們可以利用商業或非商業開源源代碼的搜索引擎系統去分析。
但是,如果程序開發人員在使用開源軟件時將相關聲明信息予以刪除,或者僅僅使用了開源代碼當中一個片段,這個時候,司法鑒定人員就很難發現了。所以,鑒定人在利用開源代碼進行商業秘密鑒定的過程中,一定要對開源代碼的相關內容進行詳細閱讀和分析,特別對其中含有的信息特殊性進行了解和觀察。
另一方面,開源許可的傳染性條款對閉源代碼的非公知性認定也有影響。開源許可證的傳染性條款是指,基于該開源軟件創作的后續作品的部分或全部都應當同樣進行開源。現在,經常出現這樣的一種情況,部分用戶在修改開源代碼,或者與自寫的代碼相結合后,將它封裝成閉源軟件產品進行發售,并且要將它主張為商業秘密。但是,按照傳染性條款的規定,開發者需要公開后期開發的源代碼,這部分商業秘密將隨著代碼的公開,就會喪失秘密性。
那么怎么樣去判斷后續開發出來的代碼有沒有被開源許可證所傳染呢?我們需要考察整體代碼對開源代碼的引用情況,對于有明顯實質從屬特征的程序,例如母子程序,那母程序也必然會受子程序的傳染;對于沒有明顯實質從屬特征的程序之間,應判斷兩者是否相對獨立。如果是屬于未被傳染的源代碼,應認為其可以具備獨立的非公知性。另外,根據開源許可證的不同,對靜態鏈接與動態鏈接是否能認定為衍生作品,也會有所差異。
例如,GPL、AGPL許可證下則具有強傳染性,靜態鏈接及動態鏈接均有可能被認定為衍生作品;LGP、MPL、EPL許可證下則是弱傳染性,靜態鏈接通常被認定為衍生作品,動態鏈接可能不被認定;MIT、BSD則屬于寬松型的許可證,具有較低的傳染性,通常不強制衍生作品采取相同的許可證。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.