特稿 | 软件生存周期视角下的开发合同纠纷疑难问题初探

本文主要探讨了计算机软件开发合同中诉争软件是否符合合同约定系列问题的法律适用。
作者 | 猫鼠游戏 

导言

       

互联网时代下的信息化3.0（智能化）正在不断丰富着企业信息化的内涵；[1]而企业信息化软件不仅能够实现企业的销售或服务与用户需求间更扁平地对接，还可以进一步提升研发及生产过程的智能化、实时化。在人力成本上涨、提高创新力竞争加剧的双重压力之下，信息化软件及相应专业化服务对于企业的价值将更加凸显。

因此，伴随着企业信息化软件咨询及实施开发服务的普及，相应法律问题的争议，尤其是计算机软件开发合同（下称“开发合同”）纠纷，也在逐年呈现出上升趋势。仅以威科先行法律信息库对于北京、上海两地开发合同纠纷相关裁判文书的统计来看，在2017年、2018年及2019年三年中，结案数量分别为350、587、772件。[2]

本文尝试以瀑布式软件生存周期为视角，[3]针对软件开发企业（下称“开发方”）与需求企业（下称“需方”）关于标的软件是否符开发合同约定，从以下几个方面探讨常见纠纷的法律问题：

1. 软件需求确认的法律性质
   
2. 软件需求的合同解释及变更管理

   
   

3. 验收通过的法律效果以及默示软件验收的法律适用

软件需求确认——开发合同成立
（一）软件需求确认的法律意义：合同成立标准与瑕疵担保标准
软件需求是传统的瀑布式软件生存周期的起点，而软件需求的确认则是开发合同成立的最低标准。软件需求确认一般在开发方主导下，按照“需求引出——需求分析——需求规格说明——需求确认——实际考虑”的过程，与后续软件开发工程相衔接。如下图所示：[4]

经过上述过程，需方与开发方的软件需求确认即意味着开发合同的成立。根据合同法基本原理和参照最高人民法院关于适用《中华人民共和国合同法》若干问题的解释（二）关于合同成立的最低标准，[5]双方在标的软件开发的需求上达成一致，为后续设计、构造、测试、上线、维护确立了基本范围；而且也使得该开发合同在给付内容上，既可与其他软件开发合同进行区分，也可与软件行业其他业务类型合同进行区分，明确双方最主要的权利义务关系，进而为双方提供最基本的法律保障。
被确定的软件需求可以分为“功能需求”与“非功能需求”：前者描述了软件应当执行的功能，从优先级来讲，功能需求对于满足软件整体目标具有重要意义；后者是约束解决方案的需求，由于非功能需求满意度不能分配到某一离散部件，所以其作用域往往针对全局范围，并强烈地影响软件体系结构和许多部件设计。[6]
这样的软件需求分类对于标的软件的瑕疵担保责任判断具有积极意义。一般而言，被确定的软件需求同样是软件测试的标准，设计测试（或称符合性测试、正确性测试）用来检验软件是否实现了功能需求的规格说明，而性能测试、可靠性测试等则可以用来检验软件是否实现了非功能性需求。[7]因此，标的软件是否可以通过前述两种测试，可以作为标的软件瑕疵担保责任判断的重要依据。
（二）未达到开发合同成立标准时开发方的履行救济

如上所述，软件需求确认是开发合同成立的最低标准之一，但是并不意味着实践中所有开发合同的订立与履行在时间上存在着常规的先后顺序。如果双方以往即具备合作经验或一定的合作基础，开发方也可以在正式合同尚处于磋商阶段便着手“干活”，以节约开发的时间成本。不过，事与愿违的是，在书面合同签字盖章之前，双方的合作便可能因各种意外而搁浅。
那么开发方在此情况下的人天投入成本，是否可以向需方索赔呢？本文认为，开发方的请求权存在着缔约过失责任和违约责任竞合的情况，具体如下。
1. 开发合同的缔约过失
开发方在合同因故未能签订情况下的索赔可以依据缔约过失责任请求权。
缔约过失责任的适用范围横跨合同不成立、合同未生效、合同有效、合同无效的各种情形。[8]《中华人民共和国合同法》（下称《合同法》）第四十二条涵盖了前三种情形，第五十八条则涵盖合同自始无效或撤销后无效的情形；根据《中华人民共和国民法总则》（下称《民法总则》）第一百五十七条的关于“确定不发生效力”的规定，同样可以将合同不成立情形纳入缔约过失责任的适用范围。[9]
本文认为，在开发方不能证明需方于磋商过程中具有明显过错或做出了不诚信行为的情况下，开发方不能请求需方承担缔约过失请求权下的损害赔偿责任。该请求权的构成要件有四，包括：
1）先合同义务的违反或类似的不诚信行为
2）需方的过错
3）开发方的损害后果以及
4）损失与需方行为的因果关系。
在双方均属于正常商务谈判的磋商过程中，哪怕需方曾主动要求开发方尽快进场进行需求调研，此种行为也并非违背诚实信用原则的行为，亦难以推定需方在主观上存在着伺机侵占开发方商业秘密的恶意，或贸然要求需方投入人力物力的过失。[10]
有观点认为，面对裁判者可能的“别人已经投了钱你方该不该赔”的诘问，若开发方的投入确与未能订立合同的合作有关，则需方应当对此予以赔偿。这种观点恰好忽视了缔约过失责任的本质特征——诚然，该制度意在保护相对人的合理信赖，但损害赔偿的前提亦包括行为人对于诚实信用原则的违反，[11]在不能证明需方在合作过程中具有不诚信行为或任何过错的情况下，不能要求需方承担缔约过失责任项下的损害赔偿。[12]
2. 事实上的咨询合同
本文认为，若开发方依据违约责任向需方索赔依据的是违约责任，则应当适用《合同法》第三十六条事实合同的规则。但是开发方将很难证明，其为软件开发所做的需求调研或者技术方案起草属于开发合同的主要义务，原因如上所述，在软件需求确认之前，开发合同的给付内容尚未确定；而将开发合同磋商过程中的需求调研或者技术方案起草等内容，解释为技术咨询服务的给付内容更为合理，[13]也更易于保护开发方的权益。
需要注意的是，《合同法》第三十六条除了强调开发方的给付内容为主要义务外，还强调需方对于该内容应当“接受”。仅从文义来看，“接受”并不表明债权人对于给付内容的单纯受领，与软件成果的验收类似，“接受”应当仍包含着对于咨询内容的认可。[14]若依此解释结果，则开发方提供的需求调研或者技术方案起草等咨询服务，在未获得需方认可的情况下，亦难以获得或难以完全获得相应报酬或投入的补偿。

二、软件需求再确认——开发合同的解除、解释与变更
司法实践中，诉争软件是否满足合同约定是绝大多数开发合同纠纷的主要争点。[15]需方主张不满足合同约定时，常以软件不能达到合同目的为由主张解除；而开发方对是否满足合同约定的否认或抗辩，主要是强调技术问题不属于合同约定的开发范围，而解决这个问题的前提是，双方是否清楚、准确地在合同订立时确认了需求，还是在合同履行过程中就开发新功能又达成了合意。
（一）不符合合同目的的履行——法定解除

合同目的是软件开发的最低标准，同时也是最核心的标准，通常表现为双方在所约定标的软件的主要功能需求。
若此部分功能未能满足需方的要求，即便并非软件设计、测试或上线后的技术问题，而是合同约定范围内之外运营维护阶段的附随义务，只要未能满足合同目的，即存在着法定解除权的适用空间；[16]同理，即便软件并未全部满足合同目的，但只要软件主体功能实现，则不存在法定解除权的适用空间。[17]
（二）不符合一般约定的履行——合同解释

软件需求应当在开发合同中量化地陈述。这不仅是合同订立的一般要求，在软件开发后续的测试、验收等环节更具有重要且特定的作用。[18]若双方对于“业已确认”的需求产生理解不一致的地方，则需要根据《合同法》第一百二十五条的规定，按照开发合同所使用的词句、有关条款、合同的目的、交易习惯以及诚实信用原则，确定该条款的真实意思。
合同解释在学理上一般抽象地表达为文义解释、整体解释、目的解释、交易习惯解释和诚信解释等解释方法；对于开发合同而言，最为重要的是整体解释，因为该方法最符合软件需求的突现性，即强调软件需求不能由单个软件部件完成，依赖于所有软件部件之间操作的协同效果。[19]有鉴于此，开发方在需求引出、调研过程中对于需方真实意思的探究就显得尤为重要，在需求捕获与需求验证的基础上，开发方应当完整、准确地将软件需求反应在合同文本中。[20]

（三）不符合一般约定的履行——合同变更

考虑到软件开发周期的不断缩短，将软件需求视为确定性的线性过程并不实际。软件需求总是朝向某一质量或详细级别迭代前进，需方对于软件需求的理解，可能会随着软件生存周期的进行而演化。实际上，在任何软件开发过程中，原有需求都会或多或少进行更改。
对于开发方来讲，应当认识到需求变更及再确认是不可避免性的，并做好变更管理工作：确保需方所提出的变更经过了合同约定的内部评审程序和合同变更程序，尤其是明确约定或排除默示要约、承诺的效力，并做好需求追踪、影响分析和软件配置管理工作。[21]

三、作为付款条件的软件验收流程法律性质

（一）验收的两种法律效果区别

尽管开发方与需方可以自由约定交付软件与支付价款履行顺序的先后，但是先开发、后付款业已成为行业中较为常见的情况。对于很多开发方而言，区别只在于针对不同客户给予不同的信用政策。[22]因此，软件验收通过往往与相应价款支付互为对待给付。
本文认为，这种对待给付约定的法律性质，属于付款义务合同效力的“附生效条件”，即，软件符合合同约定的验收标准将同时产生两个法律效果：一是可以证明开发方交付的软件不存在质量瑕疵的法律事实，二是证明需方付款义务所附生效条件已成就的法律事实。
这两种法律效果的不同在于：在交付软件存在瑕疵的情况下，需方向开发方可以同时主张违约责任的请求权和或者瑕疵担保责任、先履行抗辩的抗辩权，但是上述请求或抗辩是否足以阻碍付款义务所附条件的成就，尚需以个案判断。
（二）验收流程的法律适用

软件交付是验收的前提，其性质不同于针对有体物上“所有权”或“占有”的物权行为，属于一种纯粹的事实行为，即在完成开发后以清偿债务为目的，向需方提供相应工作成果的给付行为。[23]但是就软件验收而言，在法律理论上尚未形成统一认识；[24]在实体法规范上也没有较为清晰的规则。[25]
本文认为，作为有偿合同的计算机软件开发合同，其纠纷处理也可以参照适用《合同法》中买卖合同标的物验收的相关规定，尤其是《最高人民法院关于审理买卖合同纠纷案件适用法律问题的解释》（下称《买卖合同解释》）关于验收的详细规定。
当然，一份较为完整的开发合同通常也会对开放方如何验收标的软件进行详尽规定。至于那些因验收流程约定不明而产生争议的情况，则仍需要首先借助合同解释规则，诉诸于国家标准或行业规范关于验收的一般规定。具体流程如图所示。[26]
（三）默示验收的法律适用
尽管存在着上述国家标准的细化，但是如果需方和开发方没有对验收流程的相关时间节点予以明确，在纠纷产生时，则涉及到软件验收行为是否可以适用民事行为中默示规则的法律适用难题。
在开发方向需方发起软件验收流程后，依照双方约定或交易习惯，需方应当在一定时间内以适当形式告知开发方验收结果；而在合理期间内，如果需方没有向开发方作出符合形式要求的验收行为，或者没有向开发方明确表示验收通过或未通过，则应当认定需方以默示形式通过验收。
1. 合理期间的认定

合理期间的认定应当考虑瀑布式软件生存生存周期管理中的“隐蔽瑕疵”技术问题。正如同不动产或动产等有体物的检验，一款软件设计之初的全部技术问题，并不能完全在测试阶段发现，对于一些较为复杂的技术问题，可能在上线、运营维护甚至版本迭代过程中才陆续浮出水面，抑或是由于原有技术问题的修正而使隐蔽的问题彻底暴露。[27]

因此，软件验收中关于隐蔽瑕疵合理期间的确定，应当依据诚实信用原则，并综合标的软件完整性级别、测试及上线时开发方对于需方的培训辅导情况、技术问题的严重程度及监测的困难程度、需方自身软件工程人员的专业程度以及其他合理因素。
2. 默示行为的认定

实践中，无论是因为标的软件技术问题客观上确实较多，抑或是开发双方因为技术问题的沟通出现了重大分歧，需方有时候对于尚在测试、或者验收过程中的软件，会进行“冷处理”：要么是对于难以沟通的技术问题干脆弃之不理，要么是无视、或者拒收需方对仍有争议的软件所提出的验收申请。因此，上述沉默、拒绝行为存在被争议解决机构单位认定为默示验收的风险。
本文认为，对于需方而言，一种可能的事后挽救方式，是根据《民法总则》第一百四十条关于意思表示作出方式排除默示验收的规定，在争议解决程序中尝试说服裁判。[28]
另外，由于软件开发阶段性支付价款的特征，需方在验收前或运维中已经发现部分技术问题，但是仍然继续支付设计、测试、上线等阶段对应价款。关于这样的付款行为是否可以视为默示验收，司法实践中存在着一种一定争议，由其是在合同中对默示验收没有明确约定的情况下，或者需方已经上线使用了一段时间甚至因此盈利的情况下。
本文认为，上述情形中的技术问题如果属于隐蔽瑕疵范畴，仍应当参照适用《买卖合同解释》和《民法总则》排除默示验收规则。如果争议解决单位坚持默示验收规则的适用，也并不意味着需方吃定了“赔了夫人又折兵”的哑巴亏：这是由于默示验收软件的法律效果——参照《合同法》第一百五十八条的规定——属于证据法上的法律推定，需方可以在争议解决的过程中提出相反证据尝试反驳该免证事实。[29]

结语

本文主要探讨了计算机软件开发合同中诉争软件是否符合合同约定系列问题的法律适用，[30]除此以外，开发方与需方在诉争软件交付瑕疵履行等问题上，同样可能产生不少争议，尤其是针对云端部署软件的履行。

回归本文主题，开发合同是软件生存周期中需方与开发方协作的基本准则，软件需求不仅是软件开发的逻辑起点，同样是开发合同从订立到履行的核心。因此，无论是判断开发合同成立的基本要素，还是在履行过程中对软件需求进行合同解释或合同变更，均需要紧扣软件需求的行业特点；软件验收通过与否将分别与瑕疵担保和付款条件生效的发生联系，而针对软件验收的默示规则适用，也需要以认定验收的意思表示特征为前提。

注释

▼

1. 企业信息化能够将企业的研发、生产、供应链、销售和售后服务以及过程中所伴随的现金流动等业务过程数字化及网络化，通过应用系统对业务过程进行管控及分析，支撑企业管理者作出有利于生产要素组合优化的决策，使企业资源合理配置，以使企业能适应瞬息万变的市场经济竞争环境，求得最大的经济效益。 
2. 最后访问时间2020年7月13日星期一，https://law.wkinfo.com.cn/judgment-documents/list?mode=advanced。 
3. 除此以外，有的软件开发采取原型法，以需方行业业务流程和行业原型为基础予以实施。开发方会以预先定义的流程作为未来流程的模型，并通过迭代法帮助需方熟悉标准流程以及与自身业务进行匹配。需方通过亲自测试系统流程发现差异，在满足需求下重新配置系统或通过客制化开发解决差异，再进行新一轮的测试，通过多次重复不断优化和确认流程设计和系统设置后，达到最终需方接受的测试结果，并在此基础上完成实施开发。 
4. 参见《软件工程 软件工程知识体系指南》（GB/Z 31102-2014）。 
5. 根据该司法解释第一条第一款的规定，当事人对合同是否成立存在争议，人民法院能够确定当事人名称或者姓名、标的和数量的，一般应当认定合同成立（法律另有规定或者当事人另有约定的除外）。但是在开发合同中，标的软件由于其著作权作品的性质导致无法以衡量有体物的数量单位计量，不同软件之间的区别并不在于传统合同法上的数量，而在于对于不同软件需求的满足。在参照适用买卖合同关于验收的内容时，软件作品有形载体的数量对于软件的检验毫无意义，此时，对于质量的验收与软件瑕疵担保责任责任的判断实质等同。因此，后文在谈到软件的检验与瑕疵担保问题时，将仅讨论软件测试与软件需求之间的关系。 
6. 参见《软件工程 软件工程知识体系指南》（GB/Z 31102-2014）。 
7. 功能需求的一个本质特性在于验证成品满足需求是可能的，不能验证的需求实际上只是“愿望”；对于非功能需求，为进行验证，应当先分析出能以定量形式表达需求之处。参见《软件工程 软件工程知识体系指南》（GB/Z 31102-2014）。 
8. 参见崔建远主编：《合同法》(第五版)，法律出版社2010年版，第122页；孙维飞：“《合同法》第42条（缔约过失责任）评注”，《法学家》2018年第1期。然而，在作者与部分同行交流时，却被明确告知合同不成立不属于缔约过失责任适用的范围，对此作者表示非常惊诧：首先，缔约过失责任之所以被称为“法学上的发现”并对各国立法和判例产生深远的影响，正是源于年德国法学家耶林于1861年在其主编的《耶林法学年报》第4卷所发表《缔约上过失、契约无效与不成立时之损失赔偿》一文；其次，早在12年前，最高人民法院（2008）民二终字第8号“陕西咸阳星云机械有限公司与彩虹集团电子股份有限公司缔约过失责任纠纷上诉案”即已根据《合同法》第四十二条对合同不成立时双方在磋商过程中的缔约过失责任进行裁判；再次，《全国法院民商事审判工作会议纪要》第32条则从《合同法》第五十八条适用的角度重申了缔约过失责任对于合同不成立情形的适用。 
9. 《最高人民法院关于适用〈中华人民共和国合同法〉若干问题的解释（二）》第八条以及最高人民法院关于印发《全国法院民商事审判工作会议纪要》的通知第37条，则将未经批准合同的效力明确依据是否通过批准前后的效力瑕疵划分为“未生效”和“自始无效”。 
10. 作者在工作中还碰到开发方应需方要求进场或主动要求进场的情形，此时，参照适用《中华人民共和国民法典》第一千一百七十六条关于自甘风险规定的精神更为合适——尽管我国并没有在任何法律法规中确立商事主体间“买者自负”的原则，但是商事主体为谋求交易机会而投入的成本本就应当由其自身承担，属于商事主体自甘承担市场风险的范畴。有观点认为本次民法典的修订应当将侵权编中的自甘风险规则随紧急避险等规则一并纳入总则编范围，参见王竹：《
11. 抑制违反诚实信用原则的过失行为和保护合理信赖，是缔约过失责任制度的思想根据。参见[德]卡尔•拉伦茨：“德国法上损害赔偿之归责原则”，王泽鉴译，载王泽鉴：《民法学说与判例研究》(第5册)(修订版)，中国政法大学出版社2005年版，第235页。 
12. 若裁判者仅凭向一般条款逃逸而适用公平原则，或对开发方较大投入损失的利益衡量之后作出赔偿或补偿的决断，则不在上述讨论范围之列。 
13. 根据《合同法》第三百五十六条第一款对技术咨询合同的定义，就软件开发为需方提供可行性论证、技术预测、专题技术调查等均属于技术咨询的范畴。 
14. 下文将在“验收流程与价款支付”部分对于软件成果的验收展开详细论述。 
15. 参见黎淑兰、陈惠珍、范静波：“计算机软件开发合同纠纷疑难问题研究”，载于《法律适用》2018年第21期。 
16. 参见(2017)沪民终7号民事判决书，亚力山顿贸易(上海)有限公司与探谋网络科技(上海)有限公司计算机软件开发合同纠纷上诉案。 
17. 参见(2016)沪民终170号上海辅昊实业有限公司与上海越诚软件有限公司计算机软件开发合同纠纷二审民事判决书。 
18. 例如，呼叫中心软件应增加20%的吞吐量，在运行的任一小时内，系统产生致命错误的概率应小于1.0*10^(-8)。对于吞吐量这样一个高级别需求，应当通过更多地、详细地描述予以确认。参见《软件工程 软件工程知识体系指南》（GB/Z 31102-2014）。 
19. 仍以呼叫中心的吞吐量需求为例，该需求的描述与确认则依赖于电话系统、信息系统在实际运行条件下的交互作用。 
20. 开发方可以通过用例模型，划分整个系统的功能模块，以及各个模块的业务流程；每个用例模型中，更细致地划分出多个用例，并依次进行用例描述、流程分析、角色分析等分析工作，直到需求已经描述清楚为止。参见“【需求】作者应当怎样做需求调研：迭代”，载于“软件工程之思”公众号，转引自“充满诗意的联盟”公众号。 
21. 参见(2016)沪73民初730号上海凯岸信息科技有限公司与上海麦易信息软件有限公司计算机软件开发合同纠纷一审民事判决书。 
22. 例如对于华为公司等资信状况良好或谈判地位强势的客户，开发方会同意在软件通过需方验收并向需方开具发票后两个月内收取价款。参见“赛意信息：首次公开发行股票并在创业板上市招股说明书”，第262页。 
23. 参见李永军主编：《合同法学》，高等教育出版社2011年版，第308页；黄喆：“《合同法》第261条（工作成果的交付与验收）评注”，《法学家》2020年第2期。 
24. 例如，根据民事法律行为的一般原理，与承揽合同的验收类似，至少可以对软件验收提出“意思表示说”、“准法律行为说”和“事实行为说”三种观点。参见黄喆：“《合同法》第261条（工作成果的交付与验收）评注”，《法学家》2020年第2期。 
25. 《关于审理技术合同纠纷案件适用法律若干问题的解释》为计算机软件开发合同纠纷的处理提供了法律适用指引，即首先适用《中华人民共和国著作权法》和《计算机软件保护条例》等其他法律行政法规的规定；其次，没有规定的，则应当适用《合同法》总则的规定，并可以参照《合同法》第十八章“技术合同”和该司法解释的规定。 
26. 参见《软件系统验收规范》（GB/T 28035-2011）。 
27. 正如荷兰计算机科学家狄克斯特拉的著名评论：“程序测试能用来说明存在错误，但却不能用来说明没有错误。” 
28. 当然，此处法律适用的前提是对验收行为采“意思表示说”或“准法律行为说”。遗憾的是，作者发现部分同行由于知识结构的欠缺或对于法学理论的偏见，忽视法律适用背后的逻辑，使得一些重大工作的法律问题处理，往往难以取得令客户满意的效果。 
29. 不过需要注意的是，尽管《最高人民法院关于民事诉讼证据的若干规定》并未明确此类反驳证据需要达到的证明标准，需方实质上还是将面临着非常被动的局面。 
30. 该问题的事实查明同样是司法实践中的审理难点和重点。由于此类型案件专业性较强，在计算机领域相关知识方面对法官提出了较高的要求，因而技术调查制度对保障此类型案件顺利审结发挥着重要作用。目前，我国法院经过多年探索，初步建成了以技术调查官制度为基石，以技术咨询制度、专家陪审员制度、专家辅助人制度、技术鉴定制度为重要组成部分的多元化技术事实查明机制。2014年底，《最高人民法院关于知识产权法院技术调查官参与诉讼活动若干问题的暂行规定》颁布实施；2017年，《知识产权法院技术调查官选任工作指导意见（试行）》正式施行；2019年，《最高人民法院关于技术调查官参与知识产权案件诉讼活动的若干规定》将有关规则上升为司法解释；一个月前，《最高人民法院关于知识产权民事诉讼证据的若干规定》（征求意见稿）亦明确技术调查官在证据调查、认证过程中的重要地位。 

（本文仅代表作者观点，不代表知产力立场）