OpenAI与微软之ChatGPT AI自动生成引爆着作侵权疑云？--开源码软体篇 https://bit.ly/415ktGA 从2022年11月底Open AI的ChatGPT横空出世以来，AIGC自动生成内容工具引领风骚，全世界的人都竞相用它来撰写各类文本；同时，也用夯到不行的Midjourney或Stable Difusion等工具以文生图；而今年3月中Open AI所发布的GPT 4也加入图像AIGC战局（输入图像和文本/输出文字）；另外，音乐自动生成也不遑多让，像Amper Music、MuseNet等；然後视频也来参一咖，如Pictory和Synthesys等在在皆可透过AI来自动生成，而其中更重要的议题，就是电脑程式码。 基本上，透过ChatGPT自动生成的内容文字，经重新整合後的内涵，只要AI调校得当，理论上是有可能和其背後参考他人的文字有所不同（此即着作权法之「概念与概念表达二分原则」）。但若将GPT用在程式码自动生成时是否亦然？甚值得关注！之所以会有这种疑问，系因人类文字的表达方式和电脑程式码，在结构上有其不同之处，因为透过不同的文字使用或排列组合，在某种程度上，确有可能转换生成出与原来撷取内容不同的文字表达，而不会构成「实质近似性」。那理论上，电脑程式码透过函数之操作是否也会相似？还是说，在转换生成的过程中，程式码本质上会有些 杆格难入之处，AI无法跨过去那个坎，而可能残留其所「曾参考」过之原程式码。 针对此点，使用ChatGPT产生文字构成侵犯他人文章之着作权，目前暂无诉讼（以美国之好讼若有早已提告），但反而是开源程式码(open source)的部分，在ChatGPT刚问世就衍生了着作侵权诉讼，Open AI、微软和GitHub等公司最近在美国就被告，其间的争执是，利用开源存储库的大量程式码来做为训练集，目的是让AI透过人类的自然语言转换自动生成程式码，然而所生成的程式码却未标示原创者之归属，会不会违反美国「数位千禧年着作权法案」(DMCA: Digital Millennium Copyright Act)，而构成开源码之侵权，因该案系全球首件开源码之着作权集体诉讼(class-action)！本文兹予以简介。 本案集体诉讼之被告 本案遭控诉的系OpenAI一项名为Codex和一项GitHub名为Copilot的产品。GitHub是家由一群开源码的爱好者於2008年创立的公司，其既定目标是支持开源研发，尤其网站github.com上托管开源源代码的主机所公开分享的程式码与技术解决方案，这些GitHub的使用者通常是软体技术的开发者，无偿地分享给大众。2018年10月底，微软以75亿美元价格收购GitHub，之後微软对GitHub的经营就拥有控制权，导致GitHub使用者渐渐离开GitHub社群。 OpenAI则系於2015年底在美国成立的AI研究公司，核心目标在实现安全的通用人工智能(artificial general intelligence，AGI)，其系由一羣科技业界领袖，包括特斯拉的Elon Musk、新创育成公司达人Sam Altman、第一个投资FB的富豪Peter Thiel和LinkedIn的总裁Reid Hoffman等人所共同创办。微软於2019年7月以200亿美元估值，向OpenAI投资10亿美元，并於2020年成为OpenAI的GPT-3 语言模型的独家被授权人。 OpenAI於2021年8月独立打造Codex产品，嗣与GitHub共同推出名为Copilot的软体工具，Codex和Copilot互为相关，Copilot底层技术即Codex，其用以驱动和支援Copilot，来运行各种程式语言之程式码编译的自动生成工作，是一种以云端为基础的工具，可经由人类输入自然语言转换为程式码，最後整合到Copilot，协助程式设计师完成函数（或函式）或逐行编程新程式码。亦即，Copilot使用OpenAI的Codex，直接从使用者的编辑介面，进行即时建议之程式码和整个功能的执行，让Copilot完全在微软的Azure云端运算平台上运作。 Codex之所以能辅助程式设计师完成程式码的编撰，主要是透过GitHub之开源码公共存储库(public repositories)中大量使用者所存储的数据来训练AI，进而自动生成各种程式语言的程式码。但这也衍生出一事件，导火线就在GitHub於2021年6月推出Copilot产品後，向使用者收取每月10美元或每年100美元的费用，这引起许多GitHub的用户不满，认为Copilot将未载明着作来源的程式码卖给Copilot使用者，使得这些程式码彷佛是由Copilot所创造的一样。 本案集体诉讼之原告 原告J. Doe 1是美国加州的居民，根据其中一项建议的授权(Suggested Licenses)，将其拥有着作权权益的授权素材(Licensed Materials)，发布到至少一个GitHub存储库，Doe 1根据以下建议的授权声明拥有着作权权益的授权素材：MIT授权和GNU通用公众授权(GNU General Public License) 3.0 版。原告 J. Doe 2是伊利诺伊州居民，根据其中一项建议的授权将所拥有着作权权益的授权素材，发布到至少一个GitHub存储库；Doe 2则根据以下建议授权发布其声称拥有着作权权益的授权素材：MIT授权、GNU通用公共授权证3.0版(GNU General Public License version 3.0)、GNU Affero通用公共授权证3.0版(GNU Affero General Public License version 3.0)、三条款BSD授权(3-Clause BSD License)和Apache授权2.0(Apache License 2.0)。由於被告遭指控的非法行为，原告等在集体诉讼期间已产生并继续受到损害。 Codex将自然语言转换为程式码的能力 Codex是一种通用编程(general-purpose programming)工具，基本上可应用於任何编程任务，如转译(transpilation)、注解程式码和重构代码(refactoring code)，经过微调用於编程的应用程式。Codex是GPT-3衍生改进而来，其训练数据包含自然语言和来自公开来源的数十亿行的开源程式码，也包括公共GitHub存储库中的代码。Codex精通Python、JavaScript、C#、Go、Perl、PHP、SQL、Ruby、Swift、和TypeScript等十几种程式语言，其应用可将注解转换成程式码、完成下一行程式码或函式、寻找实用程式库或应用程式的API呼叫、新增注解、重写程式码等可以提升工作效率等的多种功能。 Codex可透过人类输入自然语言来处理，如根据函式的注解说明而转换成可执行特定任务的程式码。Codex背後的工作原理，与所有其他深度学习的语言模型一样，都是在学习的过程中，透过捕捉程式码片段之间的统计相关性，而自动产生对应的程式码功能，但实际上其并不了解编程背後的原理。截至2023年3月底，Copilot已被导入最新的GPT-4语言模型，以支援类似ChatGPT的聊天功能，同时GPT-4不论产生文字、阅读文章或输出准确度，都较GPT-3提高至少10倍的生产力，也就是说Copilot更加进化。 Codex操作性质上之局限 在2021年关於Codex之名为「评估在程式码上训练的大型语言模型」的研究论文中，有专家认为Codex「训练样本效率不高」，这意味着Codex只是无意识地依统计概率继续生成程式码，以程式接龙方法完成指令中所提问题的解答，这对於解决反覆出现的简单问题，此种方案很有效；但是当缩小范围并尝试编写一个大型程式来解决多步骤的问题时，Codex局限性就会显而易见；而随着功能描述元件的数量增加，模型的性能呈指数级下降。这也进一步暴露，Codex对程式结构和程式码缺乏理解，「它会去推荐语法上不正确或未定义的程式码，并调用未经定义或函式库范围之外的函밊①B变数和属性」，实际上在某些情况下，即便机器学习将之前在训练集资料所「看到」之不同程式码的片段，将其拼接在一起亦无法运作，但机器学习却仍可能将该不正确的结果输出，并建议程式设计师应该要那样地编程。 另，OpenAI在该论文中亦表示，Codex的输出除了可能不正确之外，还可能包含「偏差」（misalignments，即偏离用户请求的内容）和安全漏洞问题。Codex使用人类在处理文件的内容，作为上下文来生成其输出。对於此点，如程式码包含细微的偏差，Codex却仍可能会建议表面上看起来可以执行，但实际上却不见得正确的程式码，而如果数据、参数和训练时间按比例增加，偏差仍可能会持续存在，甚至会变得加剧严重。也就是说，程式码虽可通过电脑编译器，但可能会缺乏执行效率或产生安全漏洞而不自知。不过这些该注意的细节对人类程式设计师来说，依过往所累积的经 验来处理是很平常的事，但目前的AI则不然。 由於GPT-4刚问世不久，以上被抨击的问题是否已被克服，尚待观察。但可确定的是，自然语言和程式设计在特性上本就有其不同，一般来说，自然语言在表达人类想法时本就具有相当大的弹性，但程式语言的结构不仅较为固定、严谨，需要根据程式语言的编译器或直译器而定，而且又需要考虑到电脑的执行效率与资安等复杂的问题，所以用自然语言自动生成程式语言，显然还有一段路要走。 本案争议之函数程式 本案的争点之一在於，原告指控被告有些程式码是逐字引用的 -- 当使用者向ChatGPT下一道『请协助写出「isEven(n)」程式码』这样的指令(prompt)时，Codex就输出以下的一道函数「isEven(n)」： https://imgur.com/JV9Lot6 该函数主要是透过JavaScript程式语言所编写，用以判断数字是否为偶数。举例来说，若该函数执行「console.log(isEven(50))」就会回传「true」值；若该函数执行「console.log(isEven(75))」就会回传「false」值，这是一般程式设计师都懂的电脑逻辑，不论是否有写过JavaScript的经验。然而重要关键在於，Codex去执行「console.log(isEven(-1))」时，却「认为」应该要回传「??」，事实上略懂程式语言的任何开发者，应该都知道这情况要回传「false」才对；甚至於，「??」也不是一项错误，而是供读者去填写的占位符值(placeholder value)，显然Codex作为一个纯粹的机率模型，并无法识别这种细微的差别，因此原告认为这个错误，是因为Codex无法完整理解程式码的意义所致，所以才会产生与程式码涵义无关的注解（「//」即为JavaScript的注解符号），而注解本身在所有的程式语言中是无法发挥任何作用，只是单纯地写给自己、或对其他开发者的一段解释程式码功能的文字而已，故原告指责Codex是直接抄自受到着作权保护的来源而获取程式码，却竟未遵循任何附带的授权条款。 除了注解之外，原告另认为该函数还包含了两个主要缺陷。第一、它假设变数n是个整数，若n为其他类型的资料型态，如浮点数(float point)或字串(string)，那麽执行「isEven」时就会导致错误。第二、即便n确实为一个整数，该函数也可能因为太大的整数，而触发所谓的软体「堆叠溢出」(stack overflow)的记忆体错误(memory error)。基於这些原因，有经验的程式设计师不可能写出像前述Codex那样粗糙的输出结果，原告遂指控被告这样的缺陷，当然是照抄的结果。甚者，由於Codex在接受AI训练的过程中，并未学习追踪或复制数据的来源，或是着作权的归属，所以Codex自然也不会识别出原素材之作者。 同样地，当对着Copilot下一道函数「isEven(n)」指令，并测试判断是否为偶数时，Copilot的输出结果与Codex不太相同，Copilot的输出结果如下： https://imgur.com/I8RniIF 此函数更接近人类程式设计师可能的写法，因为它正确地处理n的所有资料型态，并且对於较大的n值，也不会像Codex输出那样导致「堆叠溢出」。原告认为，事实上经过人类多次手动实验，推论出Copilot的输出与Codex一样，都源自在GitHub上既有的线上书籍Mastering JS中所出现的程式码教学范例，这些教学范例均受着作权保护，然而被告都从未向其使用者交代所有原始程式码的归属，是隶属於谁，也未提供有关其授权要求的任何资讯，所以违反DMCA法。 原告指控被告违反GNU通用公众授权条款 接着来谈一下，甚麽是GNU通用公众授权条款(GNU General Public License，GNU GPL)？大多数的开源码授权(open-source licenses)，基於「授权素材取之於公、则还之於公」的立场（吃果子拜树头），需要以某种形式来标示其归属(attribution)，包括作者归属来源(attribution of the author)、着作权声明(copyright notice)和授权副本等，以确保未来的程式设计师可归功於之前的作者，并确保其遵守所有应适用之授权条件(license terms)，因此长久以来，所有开源码之建议授权(Suggested Licenses)都包括这些要求，故GPL要求衍生作品根据同等条款获得授权的条件。 原告指控，被告非但未将其Codex和Copilot编程为带有归属、着作权声明和授权条款等这些被视为授权规范所必备的要求，还刻意从程式码中剥夺原告等人之归属与着作权声明，被告此种忽视、违反并删除数百万软体开发人员提供的授权，以隐藏原创者所着作的程式码来源，再分发给Copilot使用者，就好像它是由Copilot所原始创建的一样。从而，被告是以前所未有的规模实施「软体盗版」(software piracy)。最後，Codex彷佛变身成为自己输出这些有用且受到授权规范的素材，彻底混淆了其与这些拥有原本权利之代码素材间的角色。 本案诉讼之着作权法上争议点 如前述ChatGPT运作限制，Copilot和Codex生成的程式码片段可能在无形之中就侵犯着作权，故本案呈现之一个重要的问题，即如何以AI使用受着作权保护之素材的数据集，来训练和自动产生输出，其衍生出的法律问题，包括对公共存储库的训练是否属於合理使用？开发人员如何发现侵权生成的程式码？经过机器学习相关的模型，是否能被视为可修改的源程式码或训练数据的汇编？以及与机器学习相关的模型，是否可受着作权保护并由谁拥有权利？凡此皆待日後司法之厘清。 不过，被告大量引用（其实就是重制）他人具着作权的程式码内容，从法律角度看会不会构成着作侵权？基本上，在网路上直接大量撷取他人素材复制到数据库中，理论上已构成着作权法上之重制行为，惟此种「中间性重制」之情形，不见得就立即推论出构成违法之侵权（想想早年的搜寻引擎）。基本上，为了AI模型训练而使用数据库，并进行大量复制程式码，在美国着名之Authors Guild v. Google案例中，法官认定Google Books即使扫描了数百万本书籍的文本内容，可构成合理使用，但必须注意的是，Google Books最後呈现出来的是，可供读者去找出想要蒐寻之「有限highlight出来的相关内容」，并让读者能去找到或购买到该本书，造就社会大众公共利益(significant public benefits)，且得将credit回归给作者，因而构成「转化性之合理使用」(transformative fair use)，符合着作权法不构成侵害。准此，重点不在於中间复制之过程，反而是最後呈现出的内容，有无合理使用之空间将有所区别。 本案目前才刚刚开打，後续如何仍有待观察。不过，依一般软体程式码着作权侵害案的判断模式，首先，当然要先看究竟被告是否真的用到原告的程式码，因此通常原告必须举证被告的程式码当中，哪几段、哪几行是构成抄袭，而这就需先评估被告是否接触过原告享有着作权之程式，而且两造程式的表达内容是否构成实质相似。如果是肯定，那就要再进一步去看被告的重制，有无经明示授权、默示授权，甚至有无所谓的着作权利耗尽原则，而如都没有，就必须看被告最後一步的法宝- -可否构成着作权法中最重要的抗辩：合理使用 [1]。 美国最高法院Google v. Oracle判例 再者，根据2021年美国最高法院在Google v. Oracle案所判定，即使被告使用到原告的程式码，然依客观背景事实，仍可能有合理使用之空间。Google在创造Android编程平台时，复制Java应用程式编程介面(API: application programming interface)的部分内容。在进行合理使用的分析中，对於可化解侵权之核心判断因素：「转化性」(transformativeness)，最高法院采用了一个新的扩张观点，即认识到Google在新环境中，「重新实现」(reimplementation) Java API的重要性，以及Android平台支持第三方创造力的价值，因此，法院判定其法律上构成合理使用。尽管这可能会影响及着作权人对其衍生着作之专属权益，但最高法院就扩张合理使用之转化性诠释，仍符合着作权法之宪法目标。回到本案，被告使用他人开源码软体，只要符合授权条款本得自由取用，但如溢出范围违反授权，即丧失保护伞而需回归一般侵权判定标准，如被告未遵循归属之要件，那就要评估其AI工具，究竟是否「重新实现」公共存储库开源程式码创造力的价值，而让更多之使用大众达到公共利益，这中间的权衡就考验法官的智慧。 本案因涉及到开源程式码，其中最重要的是GNU GPL相关之通用公众授权条款，针对这部分被告是如何使用，及是否按条款的规定履行其应尽的义务，这才是重要的核心关键！到目前为止，有关开源程式码的着作权侵害案件，在美国司法实务上还并不多见，这几年相对才衍生出几件个案(Harald Welte v. Sitecom Deutschland GmbH、SCO v. IBM)，因此，针对本件AI自动生成的案例，大家都特别的关注和期待。 由於AI自动生成的程式码，是一种利用机率与统计模型来辅助程式设计师编程的工具，其背後的原理透过程式码重组、人类介入纠正和不断训练，以致最後的生成内容可能与原先网路爬虫所撷取具着作权的内容不完全一样，终至量变到发生质变而完全不同！只是受限於程式码的自动生成，不若人类自然语言表达那麽灵活有弹性，对於简单如教学示范程度的函式或程式码也许可顺利运行，只是差别可能在於程式的执行效率与资安问题，但能否执行更复杂函式或程式码的自动生成，且能顺利让电脑运作，是一项极大的挑战。 因此，目前保险的做法也许是，基於AI本身是难以驾驭的黑盒子，其新产生的内容有可能与原生素材类似，此时最好加上人类自己的观点，才较能稍舒缓着作侵权之疑义。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.36.40.35 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Tech_Job/M.1680832142.A.6A9.html