注：文末有留言区。

传统意义上的法学研究是以学科内部的知识体系为基础，进而产生不同门类并各自独立发展的。而在当前法律行业实务中，却显现一种法学与其他专门学科相互融合、交叉的奇特趋势，形成了以“法学学科之外的门类”为参考依据的新型分类方式，例如：专注于计算机技术、互联网行业的网络法学；深耕传媒行业、文娱产业的娱乐法学；由了解音乐基本理论及其产业现状的群体汇集而成的“音乐法学”等……

这种趋势的形成，很大程度上应归结于法律单一学科在面对其他专业领域问题时的“无力感”。具体而言，此种无力感主要来源于法教义学论证中司法三段论的事实认定部分（法律解释领域也偶有出现）。

传统的法学学者接受的系统性教育自始至终着眼于本学科知识体系的构建，但极少有额外精力应付具体法律问题涉及的其它专业知识。然而，法的适用不是简单形式逻辑的机械化运行。判断某一事实行为所生法律意义的基本流程，即法律涵摄，①不仅要求学者和法律工作者对“作为大前提的法律条文”具备体系化的理解，②且同时要求他们对于“作为小前提的分析对象”构建准确的认知，只有同时满足上述两项要件，才能将该事实行为的本质与某一法律条文的全部事实构成要件正确联系起来并一一对应，从而完成正确的演绎推理；最终，使得一件稀松平常的“生活事实”转化为影响当事人权利义务关系变动的“法律事实”。

因此，若法律工作者对于跨学科的前沿性问题缺乏基本认知，则意味着他们将在处理法律问题时，因特定领域专门知识的匮乏，而难以理解某一事物的本质内涵。小前提的瑕疵将三段论式的推理引向错误的方向，形成错误的结论。其实际危害不能一概而论——对于学者而言，易酿成充满常识性错误的跨学科研究成果；对提供法律服务的律师来说，可能对客户的利益造成损害；而对于行政机关、司法机关而言，也将导致错误的法律推理，严重影响行政执法和司法判决的正当性。

具体到细小的例子，其实可从笔者此前诸多领域的文章中寻到千丝万缕的痕迹。

在著作权法领域，人工智能写作机器的可版权性问题，离不开对于所谓“人工智能”技术的全面认识。一个法律工作者，永远无法通过阅读几篇吹捧”人工智能“的营销号文章，便轻易得以展开相关法律问题研究。在许多引用量极高的论文中，一些学者直言不讳地表达了对“AI”智能化程度的赞美，然而他们却可能很难理解，现存的诸多机器学习的本质，依旧系高等数学、统计学的运用，从未产生过真正的“智能”——行业内人士常称：“有多少人工，就有多少智能”。这种认知偏差，可能导致可版权性问题研究朝着错误的方向一去不复返。例如，学者经常将机器学习算法改进而产生的极其表面的智能，与人的智力创造相媲美，然而实际上两者截然不同。

在行政法、刑法领域，笔者此前关注的“侵入计算机信息系统的工具”、“国际出入口信道”等概念问题则更加重要——稍有不慎，便使得一些行政处罚条款和罪名异化成“口袋条款”，酿成行政法、刑法规制的泛滥。此处尚不赘述。

而引起本文写作意图的主要动力，系来源于前些天对上学期知识产权案例研习课问题的回顾——字库可否构成计算机程序。在论文检索中，笔者寻到了一篇非常有价值的文章，标题为《汉字字库的计算机软件著作权属性》（作者：石必胜；单位：北京高级人民法院知识产权庭）。
此前，我曾看过许多法学学者的研究，他们或赞成将字库认定为计算机软件，或批判性地认为字库不符合计算机软件的构成要件，但具体的论证多是法律概念的翻来覆去的折腾，少有对“字库”本身性质的观察和解构。而石必胜文则不然，其对于字库文件的结构作了系统性分析。

依稀记得课上老师曾要求我们打开Windows系统的Font文件夹，亲自看看所谓“字库”文件的真实面目，以及安装字库文件的流程（打开某一.ttf文件，出现Opentype窗口，进行安装操作）。老师的目的在于，使得我们认清：要研究TrueType字体是否构成计算机程序，则必须认清“ttf格式”文件内部隐含的结构和代码；从而判断其实质是否符合《计算机软件保护条例》第三条第一项的定义：
计算机程序，是指为了得到某种结果而可以由计算机等具有信息处理能力的装置执行的代码化指令序列，或者可以被自动转换成代码化指令序列的符号化指令序列或者符号化语句序列。
TrueType字体分为字形轮廓数据和提示语言（hinting）。前者保存于.ttf文件的GlyphTable数据块中，其记录了所有字的轮廓信息；该数据块由轮廓线（Contour）构成，每个Contour以二次贝塞尔（bézier）片段形式表达。
而后者称为“提示指令”，该部分规定了一种精确定义字形轮廓光栅化方法的数据（或指令），以调整不同尺寸、不同分辨率导致的字体轮廓扭曲（根据一些技术资料，这种扭曲似乎与二次贝塞尔曲线运算的四舍五入误差息息相关？）。

单字显示控制指令序列与全局显示控制指令有密切的关系。因此要分析单字显示控制指令序列的独创性，首先要搞清楚全局显示控制指令的内容及表达。下面以方正倩体字库的全局显示控制指令的十六进制代码序列为例分析其内容和表达。全局控制指令由FPGM (font program)表、CVT (control value table)表、REP (controlvalue progran)表组成。

石必胜. 汉字字库的计算机软件著作权属性[J]. 电子知识产权, 2013(Z1):112-119.


学界产生争议的关键，就在于这个Font hinting部分。FPGM (font program)表、CVT (control value table)表和REP (controlvalue progran)表究竟是一段经由其他程序调用的数据库？还是其本身即一段代码化指令序列，使计算机执行任务并得到结果？


这又要引入TrueType光栅格化程序的概念。

根据微软官方技术文件，TrueType光栅器和TrueType字体（.ttf文件）似乎系计算机程序（主程序）和程序调用的数据关系。因为显而易见，TrueType光栅器是一个已经内置于Windows系统的底层程序，其在读取.ttf文件信息后（包括轮廓描述和提示信息），经过一系列代码的运行，将前述数据转换为模拟信号投射于屏幕上。

王迁老师因此认为，TrueType字体本身只是一种数据库，而非软件作品，因为其本身没有代码化的指令序列。但我个人认为，这种简单解读或许尚未考虑hinting的本质——其究竟为静态数据，还是可以运行的代码呢？
一般而言，学者会作一个形象的比喻，将.ttf文件和光栅器的关系，比喻成.doc文件和Microsoft Word程序的关系。但这种刻板印象早该被打破了，不知读者是否还记得笔者在此前关于一篇游戏连续画面可版权性的文章中，提及了游戏引擎和游戏软件的关系。虽然游戏引擎如同一个代码编辑器，然而引擎本身已经是可供计算机执行的一系列代码化指令的集合，因此，用游戏引擎编写游戏的过程，是用一个程序编辑一个程序的过程，用引擎软件打开一个游戏文件，是用一个程序打开另一个程序。
这个例子非常关键！由计算机程序调用的文件一定是一段静态的数据吗？可能不一定。计算机程序也可以调用另一个代码化指令，将该该指令纳入程序的运行过程中，表面上，程序似乎只是打开了一个“并非程序”的文件，但实际上，代码又何尝不能打开另一段代码并在运行过程中将其“占为己有”呢？

因此，这个问题非常值得被继续探讨和研究。
而问题的关键，就在于如何理解hinting信息的性质。（当然，关于OpenType在其中发挥的作用，尚须继续研究）

而很有意思的是，大一和大二时期笔者曾沉迷于研究windows系统在低分辨率（1080P）条件下，字体轮廓模糊的问题。当时我喜爱折腾Mactype软件，对于字体形成的原理做了浅显的探究，并得知了hinting这么一个概念，并于知乎关注了一位叫作“Belleve”的字体界大佬。
而在这则回答下，Belleve好像暗示，TrueType文件似乎真的包含一定的代码化指令？？至少我看到了熟悉的IF语句哈哈哈。

不知不觉，我又发现了一个具有“广阔”研究价值的领域，搞不好毕业论文就是它了！（也不知道毕业论文可否自选题材）。

这篇文章是我在复习知产时的小想法、小心思；对于计算机软件作品的构成要件有了更深的认识，因此本文留作纪念。


本篇文章来源于本人微信公众号: 不能使用该名称

最后修改：2022 年 05 月 01 日
© 允许规范转载
如果觉得我的文章对你有用，请随意赞赏