OpenAI與微軟之ChatGPT AI自動生成引爆 - 工程師

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本身是難以駕馭的黑盒子，其新產生的內容有可能與原生素材類似，此時最好加上人類自己的觀點，才較能稍舒緩著作侵權之疑義。

--