Debian的一般決議（General Resolution）

　　我之前有去訂閱Debian的公告信，今天早上看到Debian寄來的一般決議，今天就來看看這個一般決議再講什麼。我會整理一下這一次提案的選項（選項我會放上英文。並且要注意，這是經過我的詮釋，主要是作為懶人包，將長篇大論做個摘要，如果你追求更加客觀的摘要，你或許可以用AI做摘要）和大要在講什麼，最後附上投票方式。（此次投票選項、提案的原文在這裡：General Resolution: LLM usage in Debian） 

提案一：修改社群契約來禁止LLM去貢獻Debian（Ban LLM contributions from Debian via Social Contract） 

　　這一個提案聽起來很激進，但是不是如標題那樣的激進，我們來看看。 

• 限制範圍
  禁止間接、直接使用AI到Debian的原始碼倉庫、Debian官方計劃所開發的程式（包含但不限於網頁、軟體）、貢獻者添加的文件和翻譯、官方交流。但是，上游開發的專案和補丁、AI套件是例外的。 
• 反對理由 
1. 版權：AI是否有版權是一個有爭議的問題，且用來訓練AI的那些原始碼、程式碼的版權也是有爭議的，這部分有違DFSG政策。 
2. 品質：因為LLM受到的訓練的品質不一，並且目前看來主要是將資料庫的程式碼進行拼裝，Debian作為一個通用操作系統，不應該因此而增加「it works on my machine」的可能性。 
3. 社群：因為Debian是一個社群驅動的專案，如果開放LLM，可能讓很多人短時間提交大量LLM生成的原始碼，這會讓核心的審核者、維護者工作量爆表，也因為門檻的降低，讓一些新的貢獻者可能比較不熟悉Debian的細節流程，進一步惡化Debian的開發品質，到後面可能還是得由幹練的開發者去debug。而且，在當前活躍開發者、志工的數量下滑的趨勢下，實在不是一個好選擇。 
4. 道德：因為LLM目前的訓練來源是來自於網路爬取，而這一個過程是無視分發協議，而且為了因應LLM爬取而加入人機認證也是一種浪費資源，當前LLM背後的公司消耗了不少網路基建的措施。 
• 潛在問題
  暫時還有具體的強制執行措施，但對於未來的社區取得共識抱持正向態度。 
• 我的點評
  　　首先是關於「潛在問題」，這裡大方承認暫時沒有具體、良好的強制措施，但決定訴諸於社群，這和前面的反對理由相當呼應，強調Debian是一個社群驅動的專案，若要貢獻，應該要花費時間、精力去溝通、協調來達到社區協作的效果。不過，我認為在社區協作上，用不用LLM的關聯性不大。
  　　那麼，這個提案XJD就會翻盤這個理由嗎？答案是，不會。這裡提到一個很現實的問題，就是人力和版權。先說人力，前陣子有人使用LLM找到Linux內大量的漏洞（有人還因此說Linux不安全，被眾多網友懟到不行，我也是上前懟的其中一個，促使我寫了這一篇文章），而後來發現這些漏洞絕大多數都不是那麼緊急的，但因為大量的漏洞回報、沒有足夠的緩解方案被提供的情況下，導致兵荒馬亂的情況發生。另一個是版權，我這裡從開源的原始碼被拿去訓練的角度出發，我們知道「自由不等於免費」（請看這篇關於「自由不等於免費」一節），而最能夠體現這個議題的反面教材就是微軟旗下的Copilot拿GitHub的原始碼訓練，但微軟並沒有因此而遵守開源協議的做法（就例如用了GPL協議的原始碼修改自己的LLM的架構，但沒有公開LLM，又或者是，別的開發者使用自動補全，但是是修改自GPL協議的原始碼，那麼這個使用自動補全的人在不知情的情況下違背了GPL，這也是違反了版權）。

  

  從微軟的VSCode下方的說明就可以知道，截取時間2026,15,Aug

  
  　　關於自動補全，我還想說的是我的隱憂。如果很多開發者用了自動補全而不自覺的違背了GPL協議，我怕這會讓GPL協議被架空，更糟一點使得專有軟體的聯盟掠奪自由軟體、開源世界的資產；又或是這些開源的開發者為了避免被爬取而限制到這些原始碼的流通，我想這也違背了自由軟體、開源軟體的初衷。 

提案二：視情況允許AI協作來貢獻Debian（Allow AI-Assisted Contributions with conditions） 

　　容許我插個題外話，文中出現「vouching」這一個詞（動詞是「vouch」），在CEFR歸類為B2 Level，在單子數是沒有收錄的，在三民的《進階單子字彙力 4501~6000》將延伸字——voucher——歸類在Level 5。我發現Oxford Learner's Dictonary歸類在進階單子，要購買或是下載進階單子字典才可以看（讓我這三年老粉瞬間跳槽去劍橋字典）。我覺得這個字用的還蠻有深度的。 

*Accountability*: Contributors assume full responsibility for their
    contributions, including vouching for the technical merit, security,
    license compliance, and utility of their submissions. The contributor
    remains solely accountable for the entirety of these contributions.
    Contributors should fully understand the proposed changes and be
    prepared to justify them. 

　　這一個提議的內容主要是針對實際使用LLM得要有可回溯性，大致需要符合： 

1. 來源要符合這些原始碼的分發協議。 
2. 使用前要追溯版權。 
3. 生成的程式碼得要有負責人出來面對。 
4. 對於重大的開發，應該要完全地標示出哪些部分使用了什麼工具。 
5. 在發佈大量LLM協助生成的原始碼之前，開發者要確認好自己的動機、參考好開發手冊，並且負起責任。 
6. 貢獻者應該小心將不應該公開的資料透過不信任的LLM散播出去的風險。 

　　來到我的點評，我覺得這一個選項沒有上一個那麼說服我（我目前是一個一個看、一個一個寫，所以我還沒看後面的選項的提議內容）。先說說不可行的地方，我覺得這一個不可行的地方比提案一的「潛在問題」還要多。先說說追溯分發協議使其符合Debian分發，我覺得這個在實行過程中很難做得落實，以我的經驗來說，我使用Google的AI Mode來檢索一些資料，上面都有標示引用的來源，但是點進去卻沒有引用到的內容（我搜尋理查斯托曼和印表機的故事，結果引用的網頁只是淡淡帶過，但Gemini卻鉅細靡遺的講述），你想想，自己吸收了其他的資料要怎麼分辨出哪些資料是來自哪裡（這就像是問你這個生字你第一次是在哪裡看到、哪一個教科書的教材看到的）？ 

　　關於標示好使用LLM的部分，如果你這個專案是一次開發，那麼這還好說，又或是你這個貢獻者只有一個人或少少幾個人（這就會像是寫論文要寫參考文獻那樣，就有相對成熟的流程、道德規範），但現在Debian是一個廣大社群維護的，如果我修改了LLM生成的原始碼（甚至改到不成原樣），那還算是LLM有參與的工具嗎？這會不會就和LLM的引用一樣，LLM搞不定的引用問題只是換成人為的引用問題（具體來說，A用了LLM開發，並且都標注好，那麼B將A的原始碼引用、二次開發，同樣貢獻回Debian，那麼引用好要標示為LLM之類的嗎？如果不標示，那麼A還需要花精力去標示嗎？）。 

　　我原本在看完選項後，覺得提案二似乎還不錯，但目前看下來，如果在執行層面要是嚴謹執行的話，我覺得大概相當於禁止LLM的效果吧？這一個提案的說明內容我覺得可以再提出一些具體的執行層面，或許會更好（就例如，要視什麼情況做什麼裁決？誰來裁決？）。 

提案三：在可行的範圍內儘量拒絕LLM，並且更新行為準則（Reject LLMs as far as practical, update Code of Conduct） 

　　這裡先是點出LLM的缺點： 

• 削弱（undermining）自由軟體社區的建造 
• 環境破壞 
• 因惡意爬取網頁導致網頁服務癱瘓 
• 散播惡意訊息（generation and promulgation of bullshit） 
• 破壞經濟、電腦市場 
• 其他…… 

　　以下是他們的主張和訴求 

1. LLM不應該做出任何我們會依賴的軟體 
2. 不應該取代人類寫原始碼這件事 
3. 要求所有Debian的貢獻者不應該使用LLM 
4. 決策者（decision-makers）應該要儘量不鼓勵使用LLM。實際上的判斷可能會帶來一些不適的妥協。 
5. 要求所有人（甚至不是Debian社區的一分子）都應該避免使用LLM，強調自由軟體、開源社區都應該抵制LLM。 
6. 在Debian社區的所有交流都必須由人類獨自完成，不應依賴LLM協作。 
7. 紀律團隊應該要從嚴允許可用LLM的例外。 
8. 有用到LLM的必須要標示出來。 
9. 獨立專案、維護者可以撤除使用LLM的貢獻者，而「維護者、獨立專案撤除使用LLM的貢獻者」這一行為是必須被尊敬的。 
10. 違反上述要求者，應被視為違反行為準則，並且要快速得到處分。 

　　來說說我的點評，老實說，我覺得這個提案的內容十分激進，比第一個提案還要激進。先從英文用字遣詞來看，使用「promulgation of bullshit」，顯得很用力反對，我覺得在正式的提案內容，看到這個用語不得不說會先嚇一跳（畢竟是正式場合），我大概就知道這個提案者的態度很強硬、激進。 

　　我覺得這一個提案有著很大的問題，是我不會想放入考慮選項的（一和三，我覺得高下力判），這裡先是要求「禁用LLM」要加入行為準則規範，來讓Debian社群一起遵守，這部分我沒有太多意見，但全文都沒有提到「社群共同決議」這一個精神，比較像是「立好準則，全權交由紀律委員會裁定」。另一個有爭議的是，這裡強調，除了Debian內部，Debian以外的開發者都應該一起抵制LLM（怎感覺像是允許Debian成為一個不尊重上游、其他使用LLM專案社區），並且「撤除使用LLM的貢獻者」是一定被尊敬的（原文：Individual projects and maintainers may ban LLM contributions completely. Such bans (including by upstream projects) must be respected.  ），這部分看下來，我覺得這會是沒有討論空間的，有可能會破壞「Debian社區驅動」的這一特色（大概就鼓吹獨裁的感覺）。這我也好奇，假如支持提案三或是強烈反對提案三的人要是不少的話，會不會有第二個Devuan？ 

提案四：針對特別的工作允許AI貢獻（Accept AI contributions for Debian specific work） 

　　這一個提案認為使用AI協作是一個不可逆的趨勢，而是提出一系列準則規範「專為Debian相關的專案（例如Debian開發的軟體、網頁……）」，對於Debian以外的專案（例如上游專案）則不受限制。要求如下： 

1. 所有使用AI生成的原始碼、協作的部分都應遵守DFSG。 
2. 提交者應該獨自對提交內容負責人（就例如提供相關貢獻者的GPG以便聯絡、對於提交內容要有足夠的了解、確實做好提交工作） 
3. 詳細註明AI參與的部分（例如提交訊息、變更日誌……） 
4. 對於輕量協作（例如自動補全）之類開發者不易注意到自己在使用LLM的部分，選擇相信開發者會自行評估何時適用這些規範。當這類事情有爭議，則標記有爭議處。 
5. 若會需要處理一些敏感資料，則應該使用離線模型的LLM。 

　　我覺得這一個提案比提案二好了一些。首先是沒有像提案二那樣針對「重大開發應儘量標註」，而是對於專門開發給Debian的專案有了一種普遍性的規範；而且也提到「自動補全（這是我沒想到的）」難以追溯的問題，這部分是交給開發者自行衡量，社群選擇儘量信任這些開發者可以有自覺，我雖然是很想直接拒絕使用含有AI的自動補全，但這裡就提到一個問題，以前的自動補全也是會用到一些資料來練習，而這一次指示加上了AI，若直接排除，那麼為何以前的做法似乎就不受爭議？因此這裡選擇信任開發者大概是一種權宜之計，我是相對贊同的，但提案二和提案四對於追溯和如何衡量遵守DFSG可能還是有討論空間（我覺得要不訂定允許/不允許哪些類型的自動補全，就例如我們要求「業務邏輯」、「邏輯結構」的自動補全要注解，但是語法（補全一個簡單的迴圈結構）的自動補全就不追究。而離線模型相對從寬認定？）。其次是對於負起責任的開發者規範有了較為具體的說法，像是要求要有開發者的GPG簽名。 

提案五：有責任地使用生成式AI（Responsible Use of Generative AI） 

　　這裡先是把話說在前頭：「這一個提案的立場可能會隨時間改變而不會訴諸於未來的一般決議，但倘若日後有了新的想法或是遇到重大問題而無法取得共識，則還是可以訴諸於一般決議。」這話是說，Debian對於LLM的立場不應該是單由這一次的GR而定，而是還需要日後取得共識的過程，允許立場隨著社區共識而修正。重申的立場如下： 

1. Debian對於使用生成式AI的立場是中立的，不否認帶來的壞處也肯定帶來的好處。 
2. 要求開發者要有責任地、小心地使用生成式AI，不允許盲目地使用。貢獻者被賦予測試、檢查、理解、在適當的情況下修改AI協作的結果，但不強制要求貢獻者標註使用AI的部分。 
3. 重申「無論使用AI協作與否，貢獻者都有責任為這個貢獻的原始碼負責」。 
4. 認為這一次的一般決議（GR）不是用來尋找解決「生成式AI對於法律上灰色地帶的問題」，而是認為「生成式AI所引用到的原始碼保有自己原本的版權，依照這些原本的版權去執行法律要求」，並且應該要持續依賴社群討論取得共識。 
5. 使用生成式AI不應該導致安全上、隱私上的洩露，且需符合Debian的隱私要求、安全性要求。 

　　我覺得這是一個相對有意思的一個決議，這和提案一類似，都是訴諸於社群，但這裡強調「負責任的範圍不應和使用的工具綁定」、「社區共識」、「一般決議不是用來解決法律灰色地帶、爭議」，這著實令我耳目一新，我短暫思索「我們為何要利用這一個GR來解決所有爭議？為何要一次性解決好所有爭議的部分？為何提案是提出針對爭議的解決方法而不是設立對應的討論方式來應變？」，我本來還覺得這一個提議有點像是「提議者用著自己的覺醒感到搞不懂為何有這類鬧劇」。這就和上一個自動補全所說到的一個點類似，「為何含有AI的自動補全是需要被討論的？那麼以前的自動補全就沒有爭議嗎？（這或許是為何不強制要求註記的理由吧）」，這一個一般決議應該比較像是立場表決、建立爭議的解決流程，但我覺得這一個提案有些理想，可能需要假設社區是理性的（我並不是說社區是不理性的）、社區的運作要是理性的，這在實務上真的有些理想。我覺得要是提出發生爭議要有什麼對應的機制應對，可能會更加完善（因為我看完這一個提議，並沒有肯定到目前的機制足以應對這一個爭議，不然也不會上升到一般決議了）。 

提案六：抱著警戒的態度使用生成式AI（A cautious approach to generative AI） 

　　我覺得這和提案五有些類似，我就簡單提一下和提案五不一樣的部分： 

• 不強制註記使用AI的部分，但鼓勵註記，並且認為這一個部分是一種對於貢獻者們的禮貌和尊重（讓其他貢獻者得以行使知情權，拒絕使用有生成式AI參與的專案）。 
• 不將標記使用AI的部分視為是一種形式規範 

　　這一個提案相較於提案五，較為注重在「知情權」的行使。對於生成式AI更多的是視為一種工具，但尊重不喜歡的人，讓不喜歡的人可以有權利拒絕，也認為爭議應該是尋求社區共識。我覺得這很像是最近Linus對於生成式AI的觀點，這是一個工具，工具本身是中性的，要求Linux這一個專案表達立場是有問題的，不喜歡的可以fork（隨時歡迎）。 

提案七：是人類創造Debian（Debian is created by humans） 

　　提案認為，從生成式AI的原理來看，也是從人類生成的的內容而來，因此專注在使用AI協作的原始進入Debian而不是專注在限制開發者使用生成式AI。而限制的範圍如下： 

• Debian的套件 
• 提交到Debian的內容、信件…… 
• Debian專案的軟體、網頁服務、官方文件 

　　提案認為，貢獻者使用AI生成的內容是有風險讓使用者（或其他貢獻者）去承擔到責任（因為不止使用生成式AI的人要去承擔），這會有不對等的現象，久而久之可能會形成社區的不信任，這是要避免的。又從Debian的限制規範，Debian不限制你使用的工具而會限制進入Debian的內容，因此若是將生成式AI拿來協作（分析程式碼、判斷bugs、研究邏輯問題等）而不是AI有貢獻的行為，那麼AI協作是可允許的。我們再具體地說，貢獻者應該要試著自己生成原始碼，使用AI來協助修改、分析，而不是叫AI來生成原始碼（畢竟工具並不會自己產生一個完整的成果），如果使用AI來生成原始碼，就會發生其他貢獻者幫忙擦屁股的窘境。 

　　我覺得這是一個相當可行且成熟的做法，就類似我在學校上課，教授希望大家先寫作業再用AI批改一樣，我們至少要先要求貢獻者要具體產出，並且使用工具來協作（這裡就有列舉協作有哪些類型），指出具體的問題是AI生成（換成人類生成的爭議就比較小了）的內容還有善後問題。 

提案八：避免使用LLM：不可容忍氣候變遷（Avoid the use of LLM: climate destruction is a deal breaker） 

　　該提案認為LLM除了前面提到的爭議，還有氣候變遷的問題，並且難以理解「為何有人可以允許LLM帶來的氣候變遷的結果」，認為我們應該減少使用LLM進而減緩地球暖化的問題，強調「地球只有一個」。而在行動上，Debian應該鼓勵少用LLM、注重人類的社區協作。 

　　來到我的點評，先聲明，我是相信地球暖化（至少高中的地科課有解釋、提出具體的理由），但我覺得這一個提案有些牽強。承認了LLM既有的缺點，段落卻直接切到氣候變遷，感性呼籲「地球只有一個」而在實際做法上是鼓勵拒絕LLM，最後再重複一次LLM的缺點、強調社區驅動。但這裡我並沒有看到永續，我們可以思考怎麼樣讓LLM更加節能，而且就算Debian的貢獻者不用，AI模型的公司也不一定會大量減少資源投注（因為決策是在市場反應而不是社區立場），避免氣候問題就鼓勵禁止，我沒看見永續（至少我覺得這一個提案是期待社區永續的）。而這一個提案沒有太多獨到的見解，我覺得比較偏向是感性呼籲。 

我的立場 

　　這部分我希望讀者不要對號入座，我覺得我講講我的立場，或許方便大家來理解我前面的點評的一些觀點。 

　　我其實目前蠻支持提案七，因為生成式AI最大的問題是產出內容，倘若我們當作是工具來做分析、修改，這會是很強大的工具，在Debian的發展上我覺得是利大於弊。而在提案一、五則是很強調社區驅動，我覺得這一次的一般決議或許也是一種展現。 

　　我最反對的是提案三。你可以不使用（就像提案五那樣要方便他人行使知情權），但不應該鼓吹特定的行為，討論應該要控制在技術層面、流程、社區，而不是上升到個人行為。 

後記 

　　我在訂閱debian-devel-announce mailing list後收到這一次的投票信件，我以為這一個投票是很普遍的，殊不知在信件開頭就說「須是Debian開發者（Debian Developer, abbr. DD）」，害我白高興，想說可以更進一步理解社區決策（確實如此）。但是不代表我這兩個晚上看這些選項有些白費，至少我水到一篇文章。這也算是有趣的事情，我或許可以提早知道Debian是否會朝向我不喜歡的方向，進而做出切換發行版等等打算。同時也看，確實有些提案看起來像是來亂的，我也藉此恢復了一些高中的英文能力（也算是賺到啦）。