近来，以人工智能、5G、云计算、物联网、大数据为代表的新技术快速发展，在金融、医疗健康、交通运输、以及制造业等诸多行业进行转型升级，重构业务模式、运营体系的过程中产生了深远影响。传统企业的价值创造力和可持续发展力遇到严重挑战，已经纷纷开始主动实施数字化转型战略，优化完善科技创新体制机制，力求以科技激发传统供给侧输出能力，进而推动生产力的提升乃至发展方式的变革。
实践中，将传统业务模式以计算机程序来表达以实现数字化、自动化管理成为最为常见的数字化转型模式，而无论是大中型系统平台、移动App或是办公管理软件，传统企业的IT能力往往难以支持对一整套IT产品的独立开发和运维，因此需要借助外部专业IT供应商的力量以实现数字化转型。
在此场景下，考虑到IT产品的源代码与企业自身的业务模式以及IT产品的系统安全紧密相连，因此很多企业在数字化转型的同时，一方面会担心第三方IT供应商是否会将自己定制开发的代码原样或稍加修改即提供给其他第三方，特别是其竞争对手，因此希望最大程度上把定制部分的源代码掌握在自己手里；但另一方面又会对IT供应商在产品的故障修补、升级更新以及运维等方面存在较大的依赖，需要与供应商授予权限共享源代码。源代码安排始终是各类合作场景下双方特别关注的议题。
1.源代码vs目标代码
源程序和目标程序，也是我们通常所说的源代码和目标代码。通俗地说，由人运用某种计算机语言(如C++，JAVA)所编写的计算机程序即为源程序，这种由人在编程时敲出的代码被称为源代码，而由源代码编译或汇编出以供机器读取并执行的程序为目标程序，这种由“0”和“1”的二进制机器指令组成的只有机器可读的代码为目标代码，也称为可执行代码(executive code)。计算机软件保护条例中明确规定，同一计算机程序的源程序和目标程序为同一作品。
2.源代码的重要性
由于人们无法直接理解目标代码，只有在源代码层面上，程序员才能够编写和修改程序，如果说算法是软件的思想，源代码则则是展示思想的具体表达方式，这也是软件代码在知识产权保护过程中主要以著作权法加以保护的原因。
对于普通的办公软件，目标代码层面的许可基本上可以满足使用方的要求。我们平时使用办公软件(如Office软件)获取的软件许可多为目标代码层面的许可，直接复制安装在计算机本地由计算机读取和运行即可。
但是，对于公司有自己要求的定制化软件，不论是软件自主开发场景还是外包场景，源代码都会发挥较为基础和重要的作用。这是因为在这种情况下，该等软件常常需要根据公司实际应用场景的变化进行修改或者升级，而对软件进行修改或者升级，如前所述则涉及对源代码的修改。
3.软件许可场景下的源代码问题
软件许可场景下，关于许可标的形式、是否涉及后续衍生研发和是否需遵守第三方开源软件许可证的限制等涉及源代码的主要问题，建议在协议层面予以明确。其中，在商讨某些重要系统许可标的形式的过程中，源代码托管亦可以作为折中方案予以考虑。
黑盒vs.白盒：在计算机软件许可场景下，建议各方明确软件的许可形式，究竟是“源代码层面”（即“白盒”）许可还是“目标代码层面”（即“黑盒”）许可。如果被许可人对软件的需求仅涉及运行和使用，一般不涉及源代码的交付；如果涉及到被许可人需要对软件进行修改(如增加定制化功能模块)、改进、升级，则软件许可需要向被许可人交付软件的源代码，并授予源代码层面的许可。
配套衍生开发：软件许可过程中可能还需要注意的有，前期的授权与后续衍生研发的衔接。很多时候被许可人需要开发与该许可软件配套的衍生软硬件产品，则建议将该等衍生开发行为纳入许可范围中，以使得被许可人可以顺利开展开发工作。此外，被许可人获得的许可通常为不可分许可的。如果被许可人需要与他人共同开展后续的衍生开发工作，或者将后续的衍生开发工作的一部分分包出去，则建议事先明确获取这一部分工作的分许可。
开源软件限制：随着开源代码的发展，越来越多的软件中采用了第三方开发的开源代码。如果许可软件中含有开源的组成部分，则开源部分可能受限于其他的许可条款和要求，因此需要由许可方将开源部分从整个许可软件中划分开来，单独予以约定。一般被许可方会要求许可方披露许可软件中的开源部分，向用户提供开源条款访问地址，以知悉被许可方使用开源部分时的限制性义务和合规要求。被许可方应当严格按照条款规定使用开源软件，并注意跟踪开源软件是否会更改许可协议，否则将引发对于开源第三方的违约责任。
源代码托管：在一些涉及较为关键基础信息软件或大型系统的许可项目中，还可能涉及源代码托管的安排。在该等重要项目中，被许可方往往希望获取源代码而非目标代码。这主要是考虑到软件系统的可持续性，如果软件许可方发生破产或者被收购等突发事件，其往往会影响甚至停止相关软件的提供服务，在目标代码层面的许可下，被许可方的项目亦将可能会因为许可方的前述突发事件而受到较大的影响。不过，鉴于源代码的重要性，许可方也会尽可能争取黑盒许可。为了保证软件许可的持续性，减少突发事件对被许可方带来的影响，同时照顾许可方防止泄露源代码的需求，许可双方一般可以采取源代码托管的安排。将源代码交与中立的第三方托管，并约定倘若发生上述突发事件，则该等托管的源代码归属于或者继续许可给公司使用，以确保软件的正常使用，进而保证公司业务的稳定以及可持续。
4.委外开发场景下的源代码问题
委外开发场景下，关于产生的IP类型、源代码归属、基准代码的标识和第三方组件等涉及源代码的相关常见问题，同样亦属于容易发生争议的分歧点，建议提前予以明确。
层级式IP类型划分：在计算机软件开发场景下所涉及的IP不仅包括源代码本身的著作权，还包括其所抽象化以后体现的算法和数据结构等多方面的权利类型。在双方谈判地位相似或双方对IP归属僵持不下的情况下，难以一刀切地同意委托开发的IP全部归一方所有，双方可能会考虑把委托开发软件涉及的不同类型IP进行分拆，并根据双方需求予以不同约定。比如，对于较为强势的受托方而言，对于源代码著作权可以转让给委托方，但基于上层的算法及其申请专利的权利则仍归受托方所有，以便受托方可以继续为其他类似客户利用算法提供服务。
源代码IP归属的行业惯例：进一步来说，此处一般涉及两部分的源代码IP归属：一部分是IT提供方在接受委托之前原有的代码，另一部分是基于委托新定制开发的代码。实践中，委托人常常会单纯笼统地在合同中一刀切地约定交付物的所有IP权利均归属于委托人，则该约定看似很宽泛，但是可能难以达到将软件全部源代码的权利归属于委托人的效果。在现实中，受托人基于履行委托协议所开发的源代码很可能并非是软件的全部源代码，受托人作为专业的软件开发者，经常从事相关软件的开发工作，大部分类似软件的基准代码(Baseline code)是在委托开发之前就已经由受托人所拥有，在不同的开发项目中，受托人仅根据不同客户的要求在核心源代码的基础上作出个性化的开发。在该等情况下，笼统的非具体化的约定则可能会使得双方产生分歧，委托方以为获得了整个软件产品的全部源代码，而受托方则仅同意为委托方定制开发的源代码才归委托方所有。
根据IT外包行业的惯例，对于基准代码的权属转让属于重大的权利让渡，这意味着不仅定制化开发部分的代码IP，而且包括了开发方原有IP资产的转让。因此，即便双方笼统地在合同中一刀切地约定交付物的所有IP权利均归属于委托人，如果现实中出现争议，可能难以得到法院支持。如果确实希望转让整个软件（包括基准代码部分和定制化开发部分）的IP，建议双方直接对软件的源代码具体组成部分的IP归属进行约定。
基准代码的标识：虽然委托开发合同中一般会约定了基准代码归受托方所有，定制化部分归委托方所有，在操作层面上，建议可以要求开发方对基准代码及其文档在交付时进行标识，以便明确与定制化部分进行区分。
避免“传染性”组件：开发环境中涉及到开源组件以及第三方开发工具的使用，需要注意开源组件所使用许可证的要求，特别是应避免“传染性”组件的使用，且对于第三方工具和软件的事宜最好事先获得委托方的同意。软件中如果采用了部分具有“传染性”的开源代码，则可能需要将该等软件的全部源代码予以公开，这将可能造成公司原有的其他重要的代码亦将公之于众不再保密。此外，在云开发环境下，源代码的交付很可能涉及对代码或第三方许可的跨平台迁移，就此，一方面建议在技术层面控制可能产生的额外迁移时间/费用成本，另一方面应当确保迁移中涉及到的第三方许可具有可转让性或可以获取替代性的其他第三方许可。
