软件开发合同纠纷的律师随笔141102

软件开发合同纠纷的律师随笔
吴国平北京市隆安律师事务所
笔者曾经承办多起软件开发合同纠纷，部分案件由法院判决，部分案件在仲裁委员会仲裁结案。

笔者发现仲裁委员会在认定软件纠纷案件时的思路与法院存在一定差异，这种差异的原因来自仲裁员特定的软件或电子行业背景，正是这种背景使得仲裁员对于软件开发合同中争议问题的把握更为准确，最终认定的事实也更容易被当事人所接收。

当然，法院法官在审理此类案件时对于法律规则的适用掌握更为严格，此为法院审理软件开发合同纠纷的特点。

综合来讲，软件开发合同纠纷涉及多种编程语言和开发工具，相应的专业问题比起一般的合同纠纷更为复杂，案件审理中只有熟悉软件行业的特点和相关处理流程才能对争议的问题作出准确的判断，这无疑对承办律师和法官都提出了很高的要求。

以下，根据笔者的案例对于软件开发合同纠纷的特点简述如下：
一、开发周期技术上无法准确预测
根据国外的一项统计数据，受调查的软件项目进度平均延期222%，根据笔者与中国软件企业管理人员及程序员的沟通，对于软件开发延期的原因，企业管理人员认为项目经理早期计划不充分是最主要的原因，其次是应急预案制定不足；而程序员则认为客户需求变更和技术复杂程度是最主要的原因。

以上两者的差异来源于企业管理人员大多不懂软件，对于程序员也缺少了解。

企业管理人员为了在有竞争对手的商业谈判争取订单，有时候不得不承诺减少开发周期，同时也是因为竞争的原因，软件开发成本限制参与项目的程序员数量和技术水准，而以上的结果是项目经理所最不愿意看到的。

因此，从某种程度上来讲，软件开发合同前期的商务谈判过程决定了软件开发的成败，有些软件开发失败的真正原因恰恰是对于软件开发一无所知的客户。

客观存在的物体具有我们可以感知的属性，例如正在建造的房屋，但是对于软件来讲，开发中问题都存在于代码之中，无论开发经验多么丰富的程序员，他都无法准确预测开发过程中可能的问题。

尽管软件行业存在很多评估工作量的理论和方法，例如中国某知名企业的开发规范中是这样表述的：“停工和节假日不安排工作；不考虑加班；考虑测试中发现问题的返工时间；考虑客户需求的稳定性；考虑各项活动的交接和信息的传递时间；考虑风险对活动的影响；考虑项目的效率因素，在正常估算的工期内增加20～40％的余量”。

由以上开发规范中的考量因素可以看到，很多因素是无法准确量化的，同时评估工作仍需考虑团队的凝聚力问题，因此技术上准确地确定开发周期是很难实现的，最终还是靠开发团队的历史数据和经验来粗略估算。

基于以上的原因，项目经理应当在软件早期的商务谈判中向企业的管理人员充分说明开发周期的复杂性以争取宽裕的开发时间；对于企业管理人员来讲，应当在商务谈判中与律师协商，妥善安排有关开发周期的合同约定，例如开发合同中软件开发的各个阶段的时间限制应当只作为合同描述内容作为参考使用，而不能作为确定合同违约行为的依据，这样可以帮助软件开发人员在总开发周期内对分项时间进行调整。

如确因客观原因造成无法按照预期完
成软件开发（笔者案例中曾有核心程序员离职造成开发延期），则软件公司应当及时向客户进行通报，提出延期请求并以备忘录、补充协议等形式对双方的合意进行书面确认。

尽管大多数软件开发合同对于延期交付有罚金作为违约责任，但是开发过程中与客户协商延期的效果还是要远远好于开发周期后协商延期。

二、准确掌握软件需求的困难
因为客户与软件开发人员分属不同的行业，行业背景和特定专业知识的限制使得双方对于需求清单中文字表述的内容可能会存在理解的偏差，这种偏差如果只是涉及软件底层功能的部分调整还有可能及时弥补，但是如果涉及整个软件模块或架构的调整，可能给软件开发工作造成致命的影响。

笔者承办的一起案例中，软件需求说明书中表述的具体需求为“监控界面可以实现多路监控”，程序员设计的实现路径是在同一个计算机上同时打开两个浏览器界面，以上两个界面可以分别显示两组不同的视频内容，程序员认为以上方式即为需求说明书中所说的“实现多路监控”。

但是在软件进行验收时，客户提出“多路监控”是指在同一个浏览器的监视界面同时显示两组视频内容，至此双方对于软件需求的理解产生歧义。

因为以上软件的功能调整涉及数据服务器以及嵌入的视频功能模块的调整而无法在短期内完成，最终致使软件无法按期交付并引发诉讼。

如果单纯以法律规则来判断以上案例中的争议，需要确定哪一方的理解更符合“多路监控”所表述的内容，《中华人民共和国合同法》第62条对合同约定不明的各种情况做出了相应的规定，但是遗憾的是无法简单套用62条的规定来确定以上争议，因此法院退而去其次，采用“第一时间”的标准来确定程序员理解的“多路监控”方式是否实质违反客户的需求本意，即客户发现程序员展现此功能时，客户是否“第一时间”提出异议，如果答案是肯定的，则可以认定程序员对于软件需求的理解不符合客户的要求。

细致分析法院以上思路，我们不难发现，法院在确定软件需求时是以客户的意愿作为判断依据的，但是对于在合同附件中双方均认可的软件需求清单来讲，脱离具体的文字表述去推断客户的具体需求明显是对开发人员不公，因为需求清单中文字表述的内容是软件开发人员确定需求最直接的来源和依据，至此，问题又回到了法律规则无法确认的“多路监控”的文本解释上面。

事实上，我们可以从软件的开发过程来分析造成双方对需求理解不同而造成开发失败的责任，即有能力、有机会消除理解歧义的一方负有排除歧义的义务，而怠于履行义务的一方对软件开发失败负有过错，应当承担相应的赔偿责任。

软件开发合同中一般都没有非常明确的针对双方具体沟通事务的约定，软件公司在开发前期都会与客户进行反复沟通以确定需求清单的内容，但是一旦进入开发流程，开发人员有可能忽略与客户沟通软件开发的中间成果。

例如，由需求清单整理的功能需求说明书（SRS）、软件产品架构设计说明书、软件用例等文件都单纯成为开发人员之间内部沟通协调的文件，而忽略了与客户进行确认的过程。

技术上来讲，软件开发的所有工作都是以软件用例作为出发点和基本依据的，软件用例也是底层程序员了解产品功能和使用场景的依据。

与客户对软件用例进行沟通也最有可能在开发初期消除对需求理解的歧义。

综上，由开发合同中的需求清单到最终完成开发、交给客户验收的过程中，软件开发人员将中间工作成果与客户进行沟通确认的过程可以避免对需求清单理解歧义的发生。

客户对于软件开发的具体流程和细节并不熟悉，因此软件开发人员有机会通过沟通来消除软件需求理解的歧义。

因此，以上案例中，应当确定软件公司对于因理解歧义而导致开发失败负有责任。

从律师的角度来看，应当将软件开发流程中的关键节点确认作为软件开发合同约定的内容之一，沟通过程中形成的确认文件也可以成为预防纠纷的有效形式。

实践中对于软件需求还有一种情况，那就是客户在开发过程中不断提出新的功能要求。

出现这种情况的原因是多方面的，部分是因为客户自身的业务需求不确定，部分是因为在开发周期较长的项目中，客户在开发过程中了解同行业更为成熟的做法和经验，因此提出新的功能需求。

对于律师来讲，应当在软件开发协议中约定需求变更的程序和条件，例如“若需求变更影响不大，不增加费用和延长开发时间；若变更会对开发进度或工作量有较大影响的，应当延长开发时间及增加开发费用”。

但是具体实践中因为程序员缺少相关合同事务的操作经验，同时因客户方面繁琐的审批流程迟迟不能及时回复而程序开发的时间又十分紧张，使得需求控制的相关程序和文件未及时提出并确认，最终在引发纠纷时无法确定具体的责任归属。

对于项目经理来讲，应当及时与律师进行沟通解决程序问题可以有效避免此类问题的诉讼风险。

三、关于软件源代码的部分交付
为了在履行开发协议的过程中更好地保护客户的利益，国外的软件开发协议中开始出现软件源代码在开发过程中部分向客户交付的条款，也有的是通过第三方的源代码保管机构，（例如InnovaSafe和National Software Escorw,中国现在尚未发现有提供类似服务的机构，但是随着商业需求的发展，相信很快就会有这样的服务在国内出现）理论上来讲，软件开发中会产生大量的迭代版本，开发中间向客户交付的部分代码并无实质意义，但是对于开发末期已经进入调试阶段的软件代码来讲，尽管与最终代码仍有不同，但是其价值已经可以保护和持有代码的当事人一方。

这也是将软件代码的部分交付进入软件开发合同的原因之一。

实践中，还有一种情况部分交付代码的情况，客户在开发过程中为了行政审批的相关项目或者其他有关的商务合作，要求软件公司先行提供部分代码以取得中国版权中心颁发的登记证书。

按照版权中心的要求，这一部分代码约3000余行，相对于大型项目的总行数来讲，只占非常小的一部分，因此一般软件公司都会同意客户的这一请求。

笔者的一个案例正是这样的情况，因为开发延期而最终导致客户终止合同，并诉至法院要求返还预付的开发费用，鉴于客户已经通过其他公司完成了软件项目，法院认为履行原协议已无必要，双方应当终止合同。

但是因未全部完成的软件已经登记在客户的名下，在合同终止的前提下，未完成的工作成果应属软件公司所有，但是该软件登记在客户名下的事实造成软件实际所有人与登记所有人不符的情况，造成法院无法妥善解决纠纷。

以上是笔者承办软件开发合同中的几点粗浅认识，因为该类案件涉及的证据和争议事实较为复杂。

曾有一个案例，双方在开发合同中进行沟通的邮件有400多封，同时双方对于具体的技术细节有着不同的表述和认识，而案件的事实也无法直接将问题直接交由第三方鉴定机构做出结论。

在这种情况下，单纯的法律规则已经无法妥善地解决双方的争议，在法学与
计算机科学交叉的领域，需要计算机行业背景的法官和律师在此类纠纷中扮演重要的角色，同时在现有的诸如敏捷、精益等开发模式中，如能适时适度地引入法学相关的内容和视角，可以使现有的模式更为完善。

后记
笔者在刚刚接触有关计算机软件侵权和开发的案件时，曾经错误以为该类案件的法律关系单一，相关事实非常容易认定。

但是随着经办案例的逐步增加，我越来越焦虑地认识到单纯的法律规则已经无法准确界定计算机软件领域中的相关问题，幸运的是，很多程序员成为我执业过程中各个计算机领域的老师，很多也成为了很好的朋友。

同时基于个人在程序语言上的基础和后期的学习，渐渐较为深入地（相对于法学领域的人员）了解了软件行业，同时也了解法学和计算机科学在思维以及特定问题观点上的差异。

借由以上随笔希望有机会结识更多软件行业的朋友。

笔者邮箱**************。