近來，以人工智能、5G、云計算、物聯(lián)網(wǎng)、大數(shù)據(jù)為代表的新技術(shù)快速發(fā)展，在金融、醫(yī)療健康、交通運輸、以及制造業(yè)等諸多行業(yè)進行轉(zhuǎn)型升級，重構(gòu)業(yè)務模式、運營體系的過程中產(chǎn)生了深遠影響。傳統(tǒng)企業(yè)的價值創(chuàng)造力和可持續(xù)發(fā)展力遇到嚴重挑戰(zhàn)，已經(jīng)紛紛開始主動實施數(shù)字化轉(zhuǎn)型戰(zhàn)略，優(yōu)化完善科技創(chuàng)新體制機制，力求以科技激發(fā)傳統(tǒng)供給側(cè)輸出能力，進而推動生產(chǎn)力的提升乃至發(fā)展方式的變革。
實踐中，將傳統(tǒng)業(yè)務模式以計算機程序來表達以實現(xiàn)數(shù)字化、自動化管理成為最為常見的數(shù)字化轉(zhuǎn)型模式，而無論是大中型系統(tǒng)平臺、移動App或是辦公管理軟件，傳統(tǒng)企業(yè)的IT能力往往難以支持對一整套IT產(chǎn)品的獨立開發(fā)和運維，因此需要借助外部專業(yè)IT供應商的力量以實現(xiàn)數(shù)字化轉(zhuǎn)型。
在此場景下，考慮到IT產(chǎn)品的源代碼與企業(yè)自身的業(yè)務模式以及IT產(chǎn)品的系統(tǒng)安全緊密相連，因此很多企業(yè)在數(shù)字化轉(zhuǎn)型的同時，一方面會擔心第三方IT供應商是否會將自己定制開發(fā)的代碼原樣或稍加修改即提供給其他第三方，特別是其競爭對手，因此希望最大程度上把定制部分的源代碼掌握在自己手里；但另一方面又會對IT供應商在產(chǎn)品的故障修補、升級更新以及運維等方面存在較大的依賴，需要與供應商授予權(quán)限共享源代碼。源代碼安排始終是各類合作場景下雙方特別關(guān)注的議題。
1.源代碼vs目標代碼
源程序和目標程序，也是我們通常所說的源代碼和目標代碼。通俗地說，由人運用某種計算機語言(如C++，JAVA)所編寫的計算機程序即為源程序，這種由人在編程時敲出的代碼被稱為源代碼，而由源代碼編譯或匯編出以供機器讀取并執(zhí)行的程序為目標程序，這種由“0”和“1”的二進制機器指令組成的只有機器可讀的代碼為目標代碼，也稱為可執(zhí)行代碼(executive code)。計算機軟件保護條例中明確規(guī)定，同一計算機程序的源程序和目標程序為同一作品。
2.源代碼的重要性
由于人們無法直接理解目標代碼，只有在源代碼層面上，程序員才能夠編寫和修改程序，如果說算法是軟件的思想，源代碼則則是展示思想的具體表達方式，這也是軟件代碼在知識產(chǎn)權(quán)保護過程中主要以著作權(quán)法加以保護的原因。
對于普通的辦公軟件，目標代碼層面的許可基本上可以滿足使用方的要求。我們平時使用辦公軟件(如Office軟件)獲取的軟件許可多為目標代碼層面的許可，直接復制安裝在計算機本地由計算機讀取和運行即可。
但是，對于公司有自己要求的定制化軟件，不論是軟件自主開發(fā)場景還是外包場景，源代碼都會發(fā)揮較為基礎(chǔ)和重要的作用。這是因為在這種情況下，該等軟件常常需要根據(jù)公司實際應用場景的變化進行修改或者升級，而對軟件進行修改或者升級，如前所述則涉及對源代碼的修改。
3.軟件許可場景下的源代碼問題
軟件許可場景下，關(guān)于許可標的形式、是否涉及后續(xù)衍生研發(fā)和是否需遵守第三方開源軟件許可證的限制等涉及源代碼的主要問題，建議在協(xié)議層面予以明確。其中，在商討某些重要系統(tǒng)許可標的形式的過程中，源代碼托管亦可以作為折中方案予以考慮。
黑盒vs.白盒：在計算機軟件許可場景下，建議各方明確軟件的許可形式，究竟是“源代碼層面”（即“白盒”）許可還是“目標代碼層面”（即“黑盒”）許可。如果被許可人對軟件的需求僅涉及運行和使用，一般不涉及源代碼的交付；如果涉及到被許可人需要對軟件進行修改(如增加定制化功能模塊)、改進、升級，則軟件許可需要向被許可人交付軟件的源代碼，并授予源代碼層面的許可。
配套衍生開發(fā)：軟件許可過程中可能還需要注意的有，前期的授權(quán)與后續(xù)衍生研發(fā)的銜接。很多時候被許可人需要開發(fā)與該許可軟件配套的衍生軟硬件產(chǎn)品，則建議將該等衍生開發(fā)行為納入許可范圍中，以使得被許可人可以順利開展開發(fā)工作。此外，被許可人獲得的許可通常為不可分許可的。如果被許可人需要與他人共同開展后續(xù)的衍生開發(fā)工作，或者將后續(xù)的衍生開發(fā)工作的一部分分包出去，則建議事先明確獲取這一部分工作的分許可。
開源軟件限制：隨著開源代碼的發(fā)展，越來越多的軟件中采用了第三方開發(fā)的開源代碼。如果許可軟件中含有開源的組成部分，則開源部分可能受限于其他的許可條款和要求，因此需要由許可方將開源部分從整個許可軟件中劃分開來，單獨予以約定。一般被許可方會要求許可方披露許可軟件中的開源部分，向用戶提供開源條款訪問地址，以知悉被許可方使用開源部分時的限制性義務和合規(guī)要求。被許可方應當嚴格按照條款規(guī)定使用開源軟件，并注意跟蹤開源軟件是否會更改許可協(xié)議，否則將引發(fā)對于開源第三方的違約責任。
源代碼托管：在一些涉及較為關(guān)鍵基礎(chǔ)信息軟件或大型系統(tǒng)的許可項目中，還可能涉及源代碼托管的安排。在該等重要項目中，被許可方往往希望獲取源代碼而非目標代碼。這主要是考慮到軟件系統(tǒng)的可持續(xù)性，如果軟件許可方發(fā)生破產(chǎn)或者被收購等突發(fā)事件，其往往會影響甚至停止相關(guān)軟件的提供服務，在目標代碼層面的許可下，被許可方的項目亦將可能會因為許可方的前述突發(fā)事件而受到較大的影響。不過，鑒于源代碼的重要性，許可方也會盡可能爭取黑盒許可。為了保證軟件許可的持續(xù)性，減少突發(fā)事件對被許可方帶來的影響，同時照顧許可方防止泄露源代碼的需求，許可雙方一般可以采取源代碼托管的安排。將源代碼交與中立的第三方托管，并約定倘若發(fā)生上述突發(fā)事件，則該等托管的源代碼歸屬于或者繼續(xù)許可給公司使用，以確保軟件的正常使用，進而保證公司業(yè)務的穩(wěn)定以及可持續(xù)。
4.委外開發(fā)場景下的源代碼問題
委外開發(fā)場景下，關(guān)于產(chǎn)生的IP類型、源代碼歸屬、基準代碼的標識和第三方組件等涉及源代碼的相關(guān)常見問題，同樣亦屬于容易發(fā)生爭議的分歧點，建議提前予以明確。
層級式IP類型劃分：在計算機軟件開發(fā)場景下所涉及的IP不僅包括源代碼本身的著作權(quán)，還包括其所抽象化以后體現(xiàn)的算法和數(shù)據(jù)結(jié)構(gòu)等多方面的權(quán)利類型。在雙方談判地位相似或雙方對IP歸屬僵持不下的情況下，難以一刀切地同意委托開發(fā)的IP全部歸一方所有，雙方可能會考慮把委托開發(fā)軟件涉及的不同類型IP進行分拆，并根據(jù)雙方需求予以不同約定。比如，對于較為強勢的受托方而言，對于源代碼著作權(quán)可以轉(zhuǎn)讓給委托方，但基于上層的算法及其申請專利的權(quán)利則仍歸受托方所有，以便受托方可以繼續(xù)為其他類似客戶利用算法提供服務。
源代碼IP歸屬的行業(yè)慣例：進一步來說，此處一般涉及兩部分的源代碼IP歸屬：一部分是IT提供方在接受委托之前原有的代碼，另一部分是基于委托新定制開發(fā)的代碼。實踐中，委托人常常會單純籠統(tǒng)地在合同中一刀切地約定交付物的所有IP權(quán)利均歸屬于委托人，則該約定看似很寬泛，但是可能難以達到將軟件全部源代碼的權(quán)利歸屬于委托人的效果。在現(xiàn)實中，受托人基于履行委托協(xié)議所開發(fā)的源代碼很可能并非是軟件的全部源代碼，受托人作為專業(yè)的軟件開發(fā)者，經(jīng)常從事相關(guān)軟件的開發(fā)工作，大部分類似軟件的基準代碼(Baseline code)是在委托開發(fā)之前就已經(jīng)由受托人所擁有，在不同的開發(fā)項目中，受托人僅根據(jù)不同客戶的要求在核心源代碼的基礎(chǔ)上作出個性化的開發(fā)。在該等情況下，籠統(tǒng)的非具體化的約定則可能會使得雙方產(chǎn)生分歧，委托方以為獲得了整個軟件產(chǎn)品的全部源代碼，而受托方則僅同意為委托方定制開發(fā)的源代碼才歸委托方所有。
根據(jù)IT外包行業(yè)的慣例，對于基準代碼的權(quán)屬轉(zhuǎn)讓屬于重大的權(quán)利讓渡，這意味著不僅定制化開發(fā)部分的代碼IP，而且包括了開發(fā)方原有IP資產(chǎn)的轉(zhuǎn)讓。因此，即便雙方籠統(tǒng)地在合同中一刀切地約定交付物的所有IP權(quán)利均歸屬于委托人，如果現(xiàn)實中出現(xiàn)爭議，可能難以得到法院支持。如果確實希望轉(zhuǎn)讓整個軟件（包括基準代碼部分和定制化開發(fā)部分）的IP，建議雙方直接對軟件的源代碼具體組成部分的IP歸屬進行約定。
基準代碼的標識：雖然委托開發(fā)合同中一般會約定了基準代碼歸受托方所有，定制化部分歸委托方所有，在操作層面上，建議可以要求開發(fā)方對基準代碼及其文檔在交付時進行標識，以便明確與定制化部分進行區(qū)分。
避免“傳染性”組件：開發(fā)環(huán)境中涉及到開源組件以及第三方開發(fā)工具的使用，需要注意開源組件所使用許可證的要求，特別是應避免“傳染性”組件的使用，且對于第三方工具和軟件的事宜最好事先獲得委托方的同意。軟件中如果采用了部分具有“傳染性”的開源代碼，則可能需要將該等軟件的全部源代碼予以公開，這將可能造成公司原有的其他重要的代碼亦將公之于眾不再保密。此外，在云開發(fā)環(huán)境下，源代碼的交付很可能涉及對代碼或第三方許可的跨平臺遷移，就此，一方面建議在技術(shù)層面控制可能產(chǎn)生的額外遷移時間/費用成本，另一方面應當確保遷移中涉及到的第三方許可具有可轉(zhuǎn)讓性或可以獲取替代性的其他第三方許可。
