眾所周知，互聯網公司傾盡心血研發的計算機軟件（計算機軟件是指計算機程序及其有關文檔。盡管不符合法律定義，但為方便讀者理解，以下筆者將計算機軟件統稱為“源代碼”）是互聯網企業的核心競爭力，“源代碼”一旦泄露或將對企業造成毀滅性地打擊。近一段時間來，筆者陸續處理了幾起互聯網公司“源代碼”泄露的案件，在處理案件的過程中對企業的“源代碼”保護有了更深刻的理解。接下來，筆者將對“源代碼”保護的思考寫成系列文章，分別為：“源代碼”的商業秘密屬性篇、泄露風險篇、侵權篇及合規設計篇，系列文章將陸續在公眾號推送。
本篇為系列文章第五篇：“源代碼”保護的合規設計
一、互聯網企業須做好保密措施
根據《“源代碼”保護的那些事兒（一）：“源代碼”屬于商業秘密？》一文所述，“源代碼”是一種技術信息，屬于商業信息，且具有秘密性（不為公眾所知悉）、商業性（具有商業價值）和保密性（權利人采取保密措施）的“三性”特征，符合法律上界定的“商業秘密”。內部員工如盜取“源代碼”或非法修改“源代碼”，重則涉嫌構成侵犯著作權罪或侵犯商業秘密罪，輕則承擔民事責任。
筆者認為互聯網企業應做到保密措施，大抵可從如下幾個措施入手：（一）和程序員簽訂保密協議或者在合同中約定保密義務的；（二）通過章程、培訓、規章制度、書面告知等方式，對能夠接觸、獲取“源代碼”的員工、前員工、供應商、客戶、來訪者等提出保密要求的；（三）對涉密的機房、辦公場所等生產經營場所限制來訪者或者進行區分管理的;（四）以標記、分類、隔離、加密、封存、限制能夠接觸或者獲取的人員范圍等方式，對“源代碼”及其載體進行區分和管理的；（五）對能夠接觸、獲取“源代碼”的計算機設備、電子設備、網絡設備、存儲設備、軟件等，采取禁止或者限制使用、訪問、存儲、復制等措施的；（六）要求離職員工登記、返還、清除、銷毀其接觸或者獲取的“源代碼”及其載體并繼續承擔保密義務等。
二、慎用馬甲包買量
根據《“源代碼”保護的那些事兒（二）：“源代碼”泄露的類型分析》一文所述，市面上協助互聯網企業上架應用商店的技術公司，需要使用互聯網公司的代碼，以使用“代碼混淆”或者“代碼修改”等技術手段騙過應用商店的審核，才能幫忙互聯網企業成功上架馬甲包。在這過程中或將涉嫌“源代碼”泄露風險。
因此筆者建議，互聯網公司如無必要，慎用馬甲包買量。如需要馬甲包買量，也要注意保護“源代碼”的安全，最好的方式是提供目標代碼給對方或者對“源代碼”做技術保護后，確定無任何風險后再提供代碼給對方。
三、申請軟著做例外交存或封存
根據《“源代碼”保護的那些事兒（二）：“源代碼”泄露的類型分析》一文所述，《計算機軟件著作權登記辦法》第9條規定：“申請軟件著作權登記的，應當向中國版權保護中心提交以下材料：……（二）軟件的鑒別材料……”，第10條規定：“軟件的鑒別材料包括程序和文檔的鑒別材料。程序和文檔的鑒別材料應當由源程序和任何一種文檔前、后各連續3０頁組成。整個程序和文檔不到６０頁的，應當提交整個源程序和文檔。除特定情況外，程序每頁不少于５０行，文檔每頁不少于３０行。”如果互聯網企業研發“源代碼”后向版權保護中心申請軟件著作權登記時出現鑒別材料泄露的情形，將可能導致互聯網企業的“源代碼”因為公眾所知悉而不再符合秘密性（不為公眾所知悉）的特征，進而使得“源代碼”喪失商業價值。
根據《計算機軟件著作權登記辦法》第12條規定：“申請軟件著作權登記的，可以選擇以下方式之一對鑒別材料作例外交存：（一）源程序的前、后各連續的3０頁，其中的機密部分用黑色寬斜線覆蓋，但覆蓋部分不得超過交存源程序的5０％；（二）源程序連續的前１０頁，加上源程序的任何部分的連續的５０頁；（三）目標程序的前、后各連續的3０頁，加上源程序的任何部分的連續的２０頁。文檔作例外交存的，參照前款規定處理。”第13條規定：“軟件著作權登記時，申請人可以申請將源程序、文檔或者樣品進行封存。除申請人或者司法機關外，任何人不得啟封。”因此，筆者建議今后在委托中介申請著作權登記時，可連帶委托中介機構幫忙做例外交存或者封存的工作，以盡最大可能性降低“源代碼”泄露的風險。
四、合作研發須審慎起草協議
根據《“源代碼”保護的那些事兒（二）：“源代碼”泄露的類型分析》一文所述，由于有些互聯網企業本身沒有足夠多的技術人員進行“源代碼”的研發，或者出于資源互補的考慮，互聯網企業之間會進行“源代碼”的合作開發。在合同研發的過程中，互聯網企業會在協議里約定“合作研發的知識產權歸雙方共同所有”。由于協議未對“知識產權”的定義進行界定，也沒有對共有一方是否有權許可第三方使用“源代碼”的問題作出規定，導致實務中出現較多糾紛。
因此，筆者建議合作研發“源代碼”時，須重視協議的起草，特別是知識產權條款的起草。筆者認為對于該類知識產權的條款內容，可以起草為：“本合同履行過程中形成的各類成果的知識產權歸雙方所有，包括但不限于著作權、專利權、商標權等，雙方均有權使用。任何一方均有權自行決定其使用方式，且使用收益歸各自所有，無須向對方支付收益分成或費用”
五、做好“源代碼”的技術保護措施，必要時提起刑事控告
根據《“源代碼”保護的那些事兒（二）：“源代碼”泄露的類型分析》和《“源代碼”保護的那些事兒（三）：“源代碼”被動泄露的訴訟策略分析》文章所述，“源代碼”被動泄露的方式包括第三方通過非法入侵的形式，進行“源代碼”的竊取和在“源代碼”中植入附加程序。當出現該類情形時，實踐中互聯網企業多數采用侵犯著作權罪的刑事控告手段。
因此，筆者建議互聯網企業研發出“源代碼”后，應做好“源代碼”的技術保護，例如可以采取“exe.”和“dll.”的DRM技術；序列號保護技術；CSS內容加擾系統或Denuvo技術。當出現“源代碼”遭受外部攻擊導致失竊時，應第一時間選擇報案，采取刑事控告的手段處理該類糾紛。
六、慎選開源的代碼，仔細研讀開源許可證
根據《“源代碼”保護的那些事兒（四）：“源代碼”對外侵權的潛在風險》一文所述，互聯網企業的程序員所使用的代碼如果是開源代碼，需要受到開源代碼所附帶的開源許可證的約束。市面上最常見的開源許可證主要有MIT許可證、BSD許可證、Apache許可證、GPL許可證、Mozilla許可證和LGPL許可證，不同的許可證有不同的約束要求，且開源許可證的法律效力已被美國法院正面認可，中國法院也從側面認可了開源許可證的法律效力。因此，如果互聯網企業的程序員使用了GPL許可證、Mozilla許可證或LGPL許可證進行二次開源，開源后選擇閉源并采取保密措施進行保護，則違反了開源許可證的要求，有侵權的潛在風險。
因此，筆者建議互聯網企業研發的“源代碼”應盡可能少使用強制開源的開源軟件，如確實需要使用開源軟件，在使用開源軟件前，應仔細研讀該款開源軟件的開源許可證，確認該類開源許可證屬于哪種類型，盡量少使用或者不使用GPL許可證、Mozilla許可證或LGPL許可證的開源許可證。
