一般而言，律师处理软件版权纠纷，需要依赖委托人的工程人员和专家的协助，而不必识别涉案软件，专业软件工程师进行事实判断，律师仅进行法律判断。
但在办案过程中，我常常感受到律师与软件工程师在思维方式和关注点上存在巨大差异。比如客户的工程师只能告诉你某段代码是卷积神经网络的参数配置，但并不懂版权法中的“有限表达”是什么，也没有提醒律师。律师拿到工程师的判决书后，与对方源代码进行比对，发现确实一致，但并不知道卷积神经网络在配置参数时，连变量名都有其固定的国际通用表达方式，从而错失了“有限表达”这一有力的辩护点。
信息在每次传输过程中必然会衰减，如果律师本身能掌握一些软件工程方面的知识，是不是能大大提高办案效率呢？
笔者近期办理一件软件版权纠纷案件，在办理过程中，产生了一些思考。
案件背景
A公司开发了一款应用软件X，后A公司一名工程师离职跳槽至B公司软件反编译工具，B公司随后推出了一款与软件X功能相似的软件Y。A公司发现软件Y与软件X功能高度相似，于是使用一款名为“Z”的开源反编译软件对软件Y进行反编译，并将反编译结果与软件X源代码进行比对，发现相似度高达90%以上，遂向法院起诉，要求B公司承担侵权责任。
本案是典型的软件著作权纠纷案件，此类案件通常需要对双方源代码进行比对，并按照目前司法实践中普遍认可的“实质性相似+接触”原则判断是否侵权。但本案中，由于B公司不愿将Y软件的源代码提交给竞争对手A公司进行比对，因此，上述“反编译”结果能否作为判断软件源代码是否构成实质性相似的依据，值得商榷。
考虑到大多数读者的专业背景，我们首先对一些概念做一下简单的解释。
源代码是指程序员编写软件时产生的代码；主要是高级语言编写的，可读性较高，代码不能被计算机直接运行；
机器码是指用二进制机器语言编写的、机器能够理解、计算机能够直接运行的程序代码；
编译是指把用高级语言（比如大学学的C++）编写的源代码“翻译”成计算机可以理解的二进制“机器语言”的过程。我们日常使用的.exe文件就是编译后的程序。
反编译是编译的逆过程，是将机器语言“翻译”回编写它的高级语言的过程。
一旦涉及到翻译，就需要考虑非唯一对应的问题。即同一种高级语言，使用不同的编译器，可能会编译成不同的机器语言；而同一种机器语言，使用不同的反编译器，也可能产生不同的反编译结果。
版权法之所以强调“源代码”比对软件反编译工具，是因为源代码是体现作者“独创性”的依据。但从上述概念可以看出，反编译的结果并不等同于源代码，而是机器码翻译的结果。如果反编译结果与源代码不同，那么将其作为相似度比对的依据是没有根据的。
因此反编译器能否从机器码还原出源代码是本案的关键。
我看了A公司使用的“Z”反编译器的文档，文档中提到软件中包含“模式匹配API”，提供了一系列对代码段进行模式匹配的方法。通过接口的描述，我很好奇该软件的反编译功能是否也是采用模式匹配的方式实现的？即相同功能的机器码会被反编译成固定的源代码模式。如果是这样，只要软件功能类似，使用该软件反编译的结果肯定也类似，而这并不能证明二者的源代码实质上类似。
熟能生巧
当然，我缺乏专业的编译或反编译原理知识，没法做出判断。所以我决定自己尝试一下。我简单写了以下两段代码：
源代码 1
源代码2
上面两段代码分别利用了 if...else... 结构和 switch 结构，实现了同样的功能，即根据变量i分别输出A、B、C三个字母。但实现方法却完全不同。
笔者随后利用上述软件进行了反编译，结果如下：
反编译结果1
反编译结果2
可以看出，反编译结果2不仅彻底改变了源代码的表达方式，甚至直接反编译成了与源代码1高度相似的结构。
根据版权法“保护思想的表达，不保护思想本身”的基本原则，软件的功能属于思想的范畴，而实现功能的表达方式则是版权保护的范畴。然而，两段功能相同但实现方式完全不同的代码经过反编译软件反编译后，会得到高度相似的反编译结果。
通过以上实验，至少可以得出以下两个结论：
1.反编译后得到的结果与源代码并不相同，不能作为相似度比对的依据；
2、功能相同的不同代码，反编译结果高度相似，因此反编译结果实质性相似并不代表源代码实质性相似。
综上所述，反编译结果不一定能作为软件源代码相似度比对的依据。
