合肥知识产权律师网
作者|徐家力
一、案情简介
最近，我所代理了一起计算机软件著作权纠纷案件，案件的焦点主要集中在软件源代码的认定上。在本案中，原告以被告开发的软件侵犯其软件著作权为由将被告起诉至法院，请求法院判令被告停止侵权、赔礼道歉并赔偿相应的损失。案件审理中，原被告双方均向法庭提交了国家版权局颁发的软件著作权登记证书，法院应原告的申请，调取了被告在版权中心备案的源代码等文件，并委托鉴定机构对原被告的源代码及操作程序进行对比。
本案中，原告方成立于1995年，并于2003年在美国NASDAQ上市。原告方的主营业务集中在贸易信息及数据互动服务领域，原告自主开发的网络软件产品及相关服务，已广泛应用于国家质检系统、海关系统、全国200个多个外贸监管机构，及12万6千余家进出口企业之中，同类产品的市场占有率近90%，是中国进出口行业软件服务领域的领军企业。其核心产品为AB电子申报系统，其V5.0版本于2003年取得软件著作权登记证书，其后产品不断更新，市场上现行销售的版本为V7.6版本。
被告方成立于2008年，成立后自行开发了同原告产品竞争的同类产品SR V1.3版本，并于2009年取得软件著作权登记证书，因为原被告双方的软件均需接入国家相关部门的端口，被告方在将其产品推向市场之前必须获得相关部门的测试合格证书，如果被告方软件顺利完成测试并推入市场，则必定会影响原告方的市场份额。在被告方的软件尚在测试阶段时，原告将被告起诉至人民法院，并以被告的软件涉嫌侵权为由要求政府部门暂缓被告方软件的测试工作。
本案中的被告认为，原告的诉讼完全是恶意推迟被告的产品进入市场。但是，因为政府部门已经做出了推迟测试工作的决定，被告只好组织证据应诉。
二、案例简析
软件是一种知识密集的产品。目前大部分的软件系统都含有大量的源代码，其内部结构通常也比较复杂。软件的可读性也远远不能和文学作品相比。因此，判断两个软件是否相同或者相似，是一件专业性很强的工作。
（一）软件源代码的对比是本案诉讼中的必需程序
计算机软件著作权纠纷往往涉及编程语言源代码、程序文档及程序运行的硬件要求等计算机科学领域比较专业的问题，无论是律师还是法官，通常没有办法进行此类侵权案件的认定，因此，专业鉴定机构的选择，似乎成为所有此类案件必不可少的一个程序。
在本案中，原告在诉讼中出具的证据为V5.0版本的著作权登记证书、科委颁发的软件产品登记证书、公证的网络截图及对比文件、公证处的收费发票，其中公证书公证的内容为某博客上发布的疑似被告方软件界面的内容，针对原告方提交的证据，被告认为原告提交的证据无法证明被告存在侵权行为，因为原告提交的侵权的唯一证据与本案没有关联性，根据北京市高院《关于审理计算机软件著作权纠纷案件几个问题的意见》之规定，一般应提交如下证据：
１、 侵权的程序、文档以及与之进行对比的原告的程序、文档；
２、 被告实施侵权行为的其他证据；
３、 原告的软件与被告软件的对比情况。
但是实际原告并没有完成举证责任，原告取得的公证书与本案没有关联性，不应当作为原告主张侵权的证据。对于公证书的真实性和合法性，被告认可，但是认为公证书的内容与本案没有关联性。根据公证书的内容中表述：“火龙果的用户在其新浪博中，以被告的名义发表”，同时在原告的起诉状中也承认，其在新浪博客中发现的文件是名为火龙果的用户以被告的名义发表的，可见，原告所谓的侵权主体实际上只是不知其真实身份的“火龙果”，原告也不能证明“火龙果”与被告的对应关系，而实际上，被告从未在网络上发表过此类信息，按照常理推断，如果被告是为了推广自己的产品，作为专业的软件企业不可能采用新浪博客的手段推广产品，即使采用了新浪博客的手段，也应该留下公司详尽的资料和联系方式，而实际上“火龙果”提供的信息与常理相悖，原告取得明显与常理相悖的证据，不得不使人怀疑此项证据是否就是原告故意借火龙果的名义发表。
被告方认为原告没有尽到基本的举证责任，因此按照北京市高院的规定，法院应当直接驳回原告的诉讼请求，而不应该进入到源代码对比的程序，因为按照现有的证据，被告方同样可以出示同样的证据起诉原告，如此势必造成经济秩序的混乱，势必造成少数经营者利用法律漏斗达到非法的排挤竞争对手的目的。
本案中，原告的初步举证责任有很大的缺陷，即原告应当完成初步的举证责任，即可以初步证明被告有侵权的行为，这一观点有确切的法律依据，否则原告的诉讼请求就应当被法院驳回，此点在几次证据交换中我们一直向法官强调，但是因为同样的原因，软件著作权案件事实上属于比较新型的案件，法院在处理此类案件时会格外的慎重，查清事实成为很多法官的主要目的，因此本案的承办法官坚持要求双方提交源代码对比，法官的做法造成了源代码的对比成为此类案件必需的程序，我们认为法官仍需严格按照相关规定，要求原告完成应尽的举证义务后再进入源代码的对比程序。
（二）被告方是否有义务提交全部的源代码
在本案的审理中，法院应原告的要求调取了双方在版权保护中心备案的部分源代码和说明文档，在准备向鉴定机构提交检材时，原告申请法院要求双方提交全部的源代码进行对比，被告在初期以举证责任在原告唯有拒绝提交全部源代码，但是为了尽快配合完成鉴定工作(完整的源代码可以帮助鉴定机构尽快完成鉴定工作)，被告最终同意提交全部的源代码。
在软件著作权侵权纠纷诉讼中，比较常见的情况是原告根本不掌握被控侵权软件的源程序。有时，原告方甚至连被控侵权软件的目标程序都无从获取。现实情况是，如果仍要求原告承担上述举证责任，其结果使得原告无从维护自己的合法权益。
基于软件侵权案件的这些特点，人民法院在审理此类案件时往往将提供被控侵权软件源程序的举证责任赋予被告方。当原告的证据能够初步证明：被告方的软件与自己享有著作权的软件具有相似性。人民法院就会要求原被告双方提供自己软件的源程序，以进行比对，并根据比对结果作出判定。如果被告拒绝提供或提供源程序不符合鉴定要求而导致无法比对，则判定侵权成立，这是一种“推定侵权”的判定方法。
上述将举证责任分配给被告的审判方式在我国司法审判实践中被大量适用。如北京市一中院审理的香港万钧公司诉海威电子公司、海威计算机公司侵犯著作权案、上海市二中院审理的杭州英谱科技公司诉上海三锐公司侵犯著作权案等案件中，法院均在有证据表明双方软件相似，但被告不提供（或不能提供）软件源程序或提供的源程序不符合鉴定要求的情况下判定被告承担侵权责任。尤为值得一提的是，近年来，一些法院在有证据表明双方软件目标程序基本相同，但没有证据表明被告曾接触过原告软件的情况下，仍将提供被控侵权软件源程序的举证责任分配给被告。我们认为在法院可以调取双方备案的部分代码的情况下，法院不应该再要求被告提交全部的源代码，首先软件著作权的备案制度已经表明了部分代码可以表示全部软件特征，其次源代码作为企业的商业秘密在诉讼中可能有泄漏的风险。
（三）源代码抄袭认定的标准和方法
软件源代码侵权的认定，需要首先解决判断标准和判断方法的问题。关于判断标准，需要强调的是通行的编程语言全部为西方语言，尽管中国的软件界不乏尝试用中文编程的专业人士，但是，从计算机诞生至今，计算机自硬件到软件都是以印欧语为母语的人发明的，所以其本身就带有印欧语的语言特征，在硬件上CPU、I/O、存储器的基础结构都体现了印欧语思维状态的”焦点视角”，精确定义，分工明确等特点。计算机语言也遵照硬件的条件，使用分析式的结构方法，严格分类、专有专用，并在其发展脉络中如同他们的语言-常用字量和历史积累词库量极度膨胀。实际上，计算机硬件的发展越来越强调整体功能，计算机语言的问题日益突出。为解决这一矛盾，自六十年代以来相继有500多种计算机语言出现，按照TIOBE世界编程语言排行榜，最为常用的有JAVA.、C、C++、VB和PHP等。
在本案中，原告方程序使用的编程语言为C语言，它既具有高级语言的特点，又具有汇编语言的特点。它由美国贝尔研究所的D.M.Ritchie于1972年推出。1978后，C语言已先后被移植到大、中、小及微型机上。它可以作为工作系统设计语言，编写系统应用程序，也可以作为应用程序设计语言，编写不依赖计算机硬件的应用程序。它的应用范围广泛，具备很强的数据处理能力，不仅仅是在软件开发上，而且各类科研都需要用到C语言，适于编写系统软件，三维，二维图形和动画。具体应用比如单片机以及嵌入式系统开发。
在本案中，被告方程序使用的编程语言为C++，这个词在中国大陆的程序员圈子中通常被读做“C加加”，而西方的程序员通常读做“C plus plus”，“CPP”。 它是一种使用非常广泛的计算机编程语言。C++是一种静态数据类型检查的，支持多重编程范式的通用程序设计语言。它支持过程化程序设计、数据抽象、面向对象程序设计、制作图标等等泛型程序设计等多种程序设计风格。
1、 源代码抄袭认定的标准
对于源代码是否相同的标准，严格的探究可能会成为一个超出法学和计算机科学的问题，可能还需要哲学家的参与，即需要解决什么是相同的问题，有一点相同的两个整体是否是相同的两个整体，更或者仅有一点不同的两个整体是否是不同的整体，实践中人们对于哲学家的思维可能会怯而退步，所以开始讨论实质性相同的问题，这种思想上的变化反映了对于源代码判断标准的变化，即原始的“镜像复制”标准向“实质性相同”的变化。
镜像复制标准，即认定两种软件的所有源代码达到100%相同，才能认定两种软件之间存在侵权关系，这是一种比较刻板守旧的看法，这种标准处理早期的、原始的软件盗版是有效的，但是不能适应不断翻新的抄袭手法，对于部分抄袭、抄袭加创作的方式是无法确认侵权的，实践证明不能保护软件著作权利人的权利。
实质性相同也因此成为此类案件判断侵权的重要标准和通行的做法，但是实质性相同同样需要解决判断临界点问题，即如果达到某种标准则构成侵权，否则不能构成侵权，北京市海淀区人民法院曾经利用鉴定机构报告认定的20%相同的比例认定侵权，如果这一比例仍然为很多人接受的话，那么如果1%相同是否侵权的问题似乎又把我们拉回哲学的思维，实践中这一界限无疑是模糊不清的，需要法官依据具体的情况作出判断。
2、 源代码抄袭认定方法
抄袭者为了逃避法律法规的制裁，同时源于对行业内部检测手段的了解，往往会采用技术性的手段逃避抄袭统计，这种抄袭过程中加入不同程度的智力创作的行为使抄袭的认定增加了很大的难度，同时鉴定机构对于此类抄袭方法也提出了相应的对策，正所谓魔高一尺，道高一丈，以下为常见的逃避抄袭认定的方法：
（1）改变程序注释、变量名、函数位置;
（2）将子程序展开，嵌入至调用子程序的函数中;
（3）添加无效语句和变量;
（4）等效语句的替换;
（5）等价表达式的替换;
（6）改变循环语句或选择语句;
（7）用过程体代替过程调用语句；
（8）引入非结构化的语句；
（9）组合原来的和复制后的程序段；
（10）改变程序中独立语句的顺序。
实践中，鉴定机构对于送检的两套源代码的对比，大多是通过检测软件来完成的，检测软件运行的原理是首先不考虑程序的内部结构的情况下，选取特定的代码长度为度量单位并对所有的度量单位进行索引排序，索引后判断两组代码相同的比例。
3、源代码抄袭认定方法中的特殊因素–开源代码
作为法官与鉴定机构交流主要媒介的鉴定报告可能会遗漏重要的信息–“开源代码”，此类的遗漏可能会导致法官做出错误的判断。
“开源代码”的雏形最早于1968年由Internet的先驱ARPANET建立，虽然ARPANET的设计目的是使研究人员在合作一个项目时可以共享代码和信息，但是它也成为了对开放源代码可行性的一个展示。 1969年，贝尔实验室的研究员Ken Thompson编写了Unix的第一个版本，这是一个多用户，多任务的操作系统。在整个七十年代，Unix的代码都在免费的传播，它迅速成为了在大学和研究机构中很流行的系统。 本文中所指的“开源代码”是近几年随着网络发展而出现的源代码公开和分享，此类代码的特点是可以为所有使用者借鉴和无偿适用，在本案的审理中，因为原被告双方的产品均需要接入特定的国家机构的端口，对于端口的接入方式及特定代码已经在官方公开的网页上公布，程序编写人员也可以在交流博客中获取，对于双方均采用此类“开源代码”的，笔者认为鉴于鉴定机构鉴定报告的特殊使用目的，鉴定机构有义务将检索到的此类代码剔除，或者在鉴定报告初稿征求意见时，被告方提出相应证据证明某段的代码为“开源代码”的，鉴定机构应当将此段代码剔除。此时，鉴定机构将不仅仅考察送检的材料，同时是审查开源代码是否与送检材料重合的责任人。
另外，计算机程序的保护并非仅仅以程序代码是否相同作为判断的惟一参照。在程序代码不完全相同的情况下，如果两个程序从整体结构到序列再到各个模块的组织等方面是相同的，就可以认定为侵权。此外，用户界面的复制，即便后台的语句完全不同，但只要在屏幕显示上让外行看来跟最直接的操作界面显示一样，照样可以认定为侵权。由此可知，计算机程序侵权判断的切入点是很多的。程序源代码对比是最直接的，即便程序源代码对比不出来侵权结果，但程序的结构、序列和组织一样，或者界面一样的情况下同样可以得出侵权的结论。所以我们在看侵权是否成立的时候并不一定非要进行源程序对比，通过其它方法能够确定也是可以的。
至于赔偿问题，即软件侵权到底如何计算损害赔偿？大多数情况下是根据实际损害来计算赔偿问题。包括权利人的损失，也包括侵权人的收益，只要权利人主张的是实际损害，则必须有证据证明。在没有证据证明权利人的实际损失和侵权人的实际收益的情况下，应当按定额赔偿。就收益而言，关键在于能不能把使用包含该软件系统的设备的所有收益都视为使用软件的所得。
三、结论
计算机软件著作权纠纷案件具有高技术性、依赖于计算机的特性和表现形式的多样性，因此，要识别和判断侵权行为并不容易，其涉及到一系列的法律和技术问题，特别是原被告双方均办理著作权登记的情况下，源代码的对比成为认定侵权的关键。
从技术角度来讲，鉴定机构在认定源代码是否相同的标准和方法上无疑有诸多的问题，这种问题根源与软件技术的特殊性，即在于软件的不断更新与升级，其更新的频率很高、幅度很大，其更新速度远远超过其他技术的更新速度，鉴定人员对于法律问题的认识往往会影响其采用的鉴定技术，从而对鉴定结果产生实质性的影响。
从法律的角度来讲，法院认定计算软件著作权侵权行为成立，其思路依次为原告是否拥有该计算机软件的著作权或相关合法权利、被告的行为是否经原告授权或者是否有其他合法依据，法官对于计算机程序源代码的比较几乎全部依靠鉴定机构的意见，法官将材料提交鉴定机构后直到鉴定机构出具鉴定报告的时间段内对整个鉴定过程是没有任何参与的，有些案例中的原告因为无法取得被告的全部源代码，对于能否适用证据规则第七十五条的妨碍举证推定规则，实践中多有争议，部分法官则直接将中国版权中心备案的部分代码作为检材提交，个案中备案源代码只占总程序的小部分，因此如何科学的认定侵权需要法官与鉴定机构充分的沟通。
法律与技术层面的割裂造成了对于源代码侵权认定中的种种问题，例如软件的版本问题，法官对于不同版本软件之间的区别，以及原告在立案时以某一个登记的版本作为证据，但是在申请鉴定时又要求对比另外一个版本，此类问题与案件的具体情况有关。同时又涉及专业的软件知识。再例如对于软件著作权纠纷中源代码相同比例与是否存在“实际接触”的关系问题，在具体的审判中，往往同时涉及技术层面和法律问题。同医疗鉴定不同，法官对于此类案件鉴定结论的运用，往往不单纯是一个法律判断的问题，软件著作权案件中源代码侵权的认定无疑对法官的能力提出了更高的要求。对于此类问题的解决不可能在短时间内完成，法官软件知识的专业化是解决此类问题的方向，短期内加强法律与技术层面的沟通与交流可以有效的解决源代码侵权认定中出现的问题。律师建议在个案中法官应当对鉴定机构认定侵权的标准与方法予以明确，以便更加科学的解决源代码侵权的认定问题。