GNU and the AI reimplementations

Salvatore Sanfilippo

GNU 与 AI 重实现

原文由 Salvatore Sanfilippo 发布,订阅该博客

忘记过去的人注定要重蹈覆辙。这句话我从来不太喜欢,而如今围绕 AI 重写软件项目所发生的一切,恰恰暴露了这种说法的局限性。许多人正在抗议用 AI 重写现有项目的正当性。但这些人中有相当一部分,早在 90 年代就已入行:他们亲历了理查德·斯托曼及其追随者为 GNU 项目重实现 UNIX 用户态的那段历史的尾声(这段历程始于 80 年代)。而如今反对 AI 重写的同一批人,当年却为 GNU 项目的举动欢呼——在我看来,这种欢呼是正当的,我当时也欢呼过。

斯托曼不仅仅是编程天才,他也是那种具有跨学科广阔视野的人,此外他还深谙版权的细微之处。他要求其他程序员以一种特定的方式重实现 UNIX 用户态。这种方式要让每个工具与原版相比都具备独特性、可辨识度。或更快,或功能更丰富,或更易于脚本化;这些特质服务于两个不同的目标:让 GNU Hurd 变得更好,同时提供一层抵御诉讼的保护。如果有人指控 GNU 的实现不仅仅复制了思想和行为(这是合法的),而是复制了“受保护的表达”(也就是逐字逐句的源代码),那么这些新增的功能以及对特定设计方向的有意推动,就能提供一个法官能够理解的反驳论据。

他还要求始终只重实现行为本身,避免去看具体的实现,而是依据规范和通过手动运行工具所实测出的真实行为。即便如此,公平地说,参与 GNU 项目的许多人很可能接触过或能够接触到 UNIX 的源代码。

当 Linus 重实现 UNIX、编写 Linux 内核时,情况则要复杂一些,多了一层间接性。他只是作为用户接触过 UNIX,但据说并未接触过 UNIX 的源代码。另一方面,他大量接触过 Minix 的源代码(Minix 是 UNIX 的一种实现,但采用了微内核),以及介绍该实现的书籍。而反过来,Tanenbaum 编写 Minix 时,本身也是在大量接触过 UNIX 源代码之后才动手的。因此,SCO(在与 IBM 的诉讼期间)很难主张 Linux 包含了任何受保护的表达。然而,当 Linus 以 Minix 为灵感时,他不仅对一个在知晓 UNIX 代码的情况下实现出来的东西(Minix)非常熟悉,而且(更有意思的是)Minix 当时的许可证是受限的,直到 2000 年才开源。即便在这种情况下,Tanenbaum 抗议的也是架构问题(在那场著名的论战中),而非版权侵权。因此,我们可以合理推断,Tanenbaum 认为重写是正当的,即便 Linus 接触过 Minix(而他自己编写 Minix 时也遵循了类似的过程)。

版权法到底是怎么说的

要把这一切放在正确的语境中,我们来看看版权真正的边界:法律规定你不得复制“受保护的表达”。就软件而言,受保护的表达就是原封不动的代码,包括相同的结构、变量、函数、实现特定功能的具体机制,除非它们是已知算法(标准的快速排序或二分查找即便实现得非常相似,也不构成侵权)。问题在于当程序的业务逻辑与原始实现几乎逐行完全吻合时。除此之外,复制就是合法的,也无需遵守原有许可证,只要能相当清楚地看出代码虽然在做类似的事情,但并非直接复制粘贴,也非机械地翻译成另一种语言,或仅仅为了看起来有点不一样而做表面修饰(注意:这恰恰是法院会试图识别的那种恶意伎俩)。我感觉每一位阅读此文的合格程序员都完全清楚什么是*重实现*,以及它看起来是什么样子。不可避免会有相似之处,但代码显然不是抄来的。如果法律框架是这样,为什么人们还在意无尘室实现?说到底,这只是在诉讼发生时的一种优化,它能让你在法庭上更容易获胜,但如果接触某个程序的原始源代码仅仅是为了了解其思想和行为,那是没问题的。此外,我们今天都很高兴能拥有 Linux 和 GNU 用户态,以及许多遵循类似路径的其他开源项目。我认为规则无论在我们认同其结果时,还是不认同时,都应该一视同仁地适用。

AI 登场

因此,重实现一直都是可行的。现在发生变化的是,完成它的速度和成本被极其大幅地压低了。过去,你得雇佣开发者,或是自己怀有足够的热情去亲手打造一个重实现,出于商业抱负,或是想与世界分享。

现在,你可以启动一个编程智能体,用两种方式推进:先把实现转化为规范,然后在新会话中让智能体去重实现,并可强制要求特定的品质,例如:让它更快,或让实现变得极其易于理解和跟进(这是让最终实现与原版大相径庭的一个好技巧,毕竟大量代码似乎正是朝着相反的目标设计的),或更模块化,或解决原始实现中某个根本性的缺陷:所有这些提示都会让大幅偏离原始设计变得简单得多。以这种方式使用大语言模型时,它并不会产出过去所见内容的复制品,但即便如此,最后你仍可以用智能体仔细检查是否存在任何侵权之处,如有,就用全新的代码替换掉相关部分。

另一种看似不那么严谨、但在现实世界中可能非常有效的方法,是直接提供源代码本身,让智能体以完全新颖的方式重实现它,既把源代码当作规范,又利用它来尽可能地驱使实现远离原代码。前沿大模型能力很强,它们甚至可以利用某样东西来明确地避免复制它,并谨慎地尝试不同的实现路径。

如果你曾尝试过上述任何一种做法,就会知道“无压缩复制”其实是一种幻觉:智能体会以一种非常“有机”的方式编写软件,会犯错,会因为只有到后来才显现的局限性而多次改变设计,会从一个很小的起点开始逐步添加功能,而且常常在这个本就混乱的过程中,我们还会用自己的提示、暗示和期望大幅引导它们的工作。许多想法之所以具有安慰性,恰恰因为它们是虚假的:“无压缩复制”就是其中之一。但即便如此,如今重写的过程变得如此简单,许多人因此感到不安。这里存在一个更根本的事实:软件的本质已经改变;在不同许可证下进行重实现,只是这种本质被永久改变的一个例证。与其去对抗自动编程的每一种表现形式,我认为不如构建一个新的心智模型,去适应它。

法律之外

我相信有组织的社会在遵守法律时才能繁荣,但我不会因为某条规则存在就盲目接受它,我会基于自己的伦理去质疑:正是这一点让个人、社会乃至法律本身得以演进。我们必须自问:版权法在伦理上是正确的吗?AI 对既有流程的加速,是否从根本上改变了流程本身?

让软件能够比大多数其他人类领域演进得快得多的一个原因,是这个学科较少受制于专利和保护(而这反过来很可能得益于软件领域围绕共享的文化)。如果版权法更加严苛,我们很可能就无法拥有今天的一切。保护个体和公司的利益,是否比人类文化的整体演进更重要?我不这么认为,而且,版权法是一个公共的竞技场:规则对所有人都一样。此外,说尽管采取了更为宽松的方式,软件仍然是最容易赚钱的领域之一,并不夸张;看起来商业层面并未因能够重实现事物而受到冲击。很可能恰恰相反:想想有多少商业是依托开源软件栈才得以实现的(并不是说开源大多由复制品构成,但它确实继承了许多关于过往系统的思想)。我认为,即便有了 AI,这些根本性的张力依然成立。重实现变得廉价,但这是我们所有人新的竞技场,仅仅以自动化的方式重做一些东西,而不在思想、工程、功能上注入任何新意,从长远看价值是有限的。真正重要的,是你创造事物的方式:它是否设计精良、是否有趣易用、是否得到维护、是否具备一定的新颖性、是否快速、是否有文档、是否有用?而且,这一次力量的失衡朝着正确的方向倾斜:大公司向来有能力砸下天文数字的资金去复制系统,以一种让用户无法抗拒的方式提供它们(例如多年免费,之后再切换模式),并把自己包装成那些并非真正由它们发明的理念的引领者。现在,小团队也能对大公司的软件系统做同样的事:当合成劳动力对许多人而言变得更便宜时,他们就能在理念上展开竞争。

我们站在巨人的肩膀上

还有一个根本性的观念,是我们所有人都需要内化的。软件是在一个持续递增的过程中被创造和演进的,每一项新创新都是建立在前人发明的基础之上。我们都很快会做出某个东西并认为我们“拥有”它,如果仅限于我们亲手写下的那段确切代码,这么说是没错的。但我们是在已有工作和思想之上构建事物,鉴于当今信息技术的发展得益于思想和行为不受版权保护这一根本范式,我们需要接受重实现是一个正当的过程。如果它们不包含任何新意,或许是一种偷懒的努力?有可能,但即便如此:它们是正当的,没有人违反任何规定。然而,如果我们想成为生态中合格的公民,在复刻某项成果时,就应该尝试同时推动它演进、发明一些新东西:比如为更低的内存占用而专门优化实现,或让它在特定场景下更有用,或减少缺陷:这就是斯托曼的方式。

就 AI 而言,我们几乎集体犯了一个错误,那就是孤立地去评判一项技术对软件和人类究竟是好是坏。AI 能在开源软件领域释放诸多益处。许多充满热情的人写开源,是因为他们讨厌日常工作,想做自己热爱的东西;或是想成为某种超越经济利益的更大事业的一部分。大量开源软件要么是在业余时间写成的,要么在人力投入上受到严格限制,或更糟——受到出资公司所施加的种种限制。如今代码正日益变得不如思想重要,开源可以被 AI 大幅加速。在合适的人手中,周末投入的四小时将带来十倍的成果(AI 编程并不适合所有人,正如优秀的编码和设计并非人人皆能)。例如,Linux 设备驱动可以通过自动反汇编某个专有二进制 blob 来实现。或者,一个原本只是勉强维持的库,也能在更合理的时间内转变为一个能够得到良好维护的项目。

在 AI 出现之前,我们已经目睹了软件的商品化:质量下降,只关注金钱,对极简和资源尊重毫无在意:只剩下一堆大多残破臃肿的东西。硬件性能越强,臃肿就越多,关切就越少。情况本来就已经很糟了。AI 会让它变得更糟,既非显而易见,也非必然,而重实现其他软件系统的能力,是那幅可能为我们的领域重新带来一些热情与理性的更大图景的一部分。

本文章由 muse-spark-1.2-contributor 进行翻译

评论