OT: Debian erlaubt KI-Beiträge ohne Kennzeichnungspflicht

[jim_os]

Heise News dazu: https://www.heise.de/news/Debian-erlaubt-KI-Beitraege-ohne-Kennzeichnungspflicht-11435420.html

Ich hoffe mal das das nicht die Büchse der Pandora öffnet und ich frage mich auch wie man dann das

​

"Konkret sollen Entwickler die KI-Ausgaben verstehen, prüfen, testen und bei Bedarf überarbeiten, bevor sie sie übernehmen. Ein ungeprüftes Hochladen generierter Inhalte widerspreche den etablierten Entwicklungspraktiken des Projekts. Somit formuliert Debian keine neue Prüfungspflicht, sondern betont lediglich, was ohnehin bei jeder Einreichung gilt: Der Absender muss für deren Qualität und Herkunft einstehen."​

wirklich sicherstellen will. Wenn ich z.B. im Smarthome Bereich sehe wie viele User sich da jetzt dank KIs zum Entwickler berufen fühlen und irgendetwas, was quasi kompl. von einer KI stammt und was sie in Gänze ganz sicher nicht vollständig verstehen, oder gar auf verschiedene Aspekte hin überpüfen, auf die User loslassen, dann schwant mir da Böses. Aber nun gut, man wird sehen ....

VG Jim

 

[Bu66as]

Ehrlich gesagt ändert das bei Debian doch wenig, mit dem DCO lag die Verantwortung schon immer beim Einreicher. Ungeprüft zusammenkopierten Kram gab's auch vorher schon, halt von Stack Overflow statt vom LLM. Was real schützt ist der Review- und Sponsoring-Prozess, und den hat Debian ja. Das Szenario das du beschreibst ist eher das Ein-Mann-Repo auf GitHub, wo genau diese zweite Instanz fehlt, und da hilft keine Policy von irgendeinem Projekt.

Und eine Kennzeichnungspflicht hätte daran vermutlich auch nix geändert. Wer den Output ungeprüft reinkippt, setzt das Häkchen halt auch nicht. Bleibt am Ende an den Maintainern hängen, wie vorher auch, nur mit mehr Volumen im Eingang.

 

[ThoSo]

Da brauchst nicht all zu weit zu gehen, hier ein schönes Beispiel für..

M

Thread 'Wasserdichtes System für kleine Multi Teant Anwendung'

Aug 6, 2026

Hoi

Im Moment wurstle ich im non-commerce Bereicht mit zwei ESXi rum. Die Server haben je einen durchgereichten HBA an napp-it (Solarish), da liegen die VMs und "Backups" drauf. Dazu 10 Gbit Anbindung, zwei 10 Gbit Firewalls mit je drei X540, 5 Switches, sowas. Grosssteil Uralthardware, die Firewalls sind Haswell, die ESXi Broadwell-E mit 256 GB Ram und 22 Core CPU, Backupserver Broadwell-E mit 128 GB und 16 Core CPU. Alles DC Hardware, inkl. dem Storage. Habe auch die meisten Teile auf Ersatz, falls was abraucht.

Nun bin ich eine Multi Teant Anwendung am bauen. Da habe ich mir eine...

• MarroniJohny
• Replies: 52
• Forum: Proxmox VE (Deutsch/German)

 

[Johannes S]

Ich sehe ( und das als bekennender KI-Luddit!) auch nicht so das Problem. Im Grunde sagt Debian, dass „aber die ki sagt, das passt so“ keine erlaubte Ausrede ist Bullshit abzuliefern

OpenBSD hatte ja das Vergnügen mit einen Vibecoder, der versuchte einen vibegecodeten Treiber für ext3/4 Dateisysteme beizusteuern . Da er außer „KI sagt alles ok“ die Einwände („Wie sollen wir diese Menge Code vernünftig reviewen, wenn sie nicht in unseren Codestyle ist?“, „woher weißt du, dass die ki keinen GPL-lizenzierten Code ( den darf man ohne ok des urautoren nicht unter bsd-Lizenz veröffentlichen) verwendet hat?“) nicht wirklich entkräften konnte, blieb es halt beim Versuch.

Bei Debian oder dem Linux-Kernel würde ich bei einen vergleichbaren Fall ähnliches erwarten.

 

[Bu66as]

Der Lizenz-Punkt von @Johannes S ist eigentlich der spannendere, das Codestyle-Argument erledigt sich ja mit genug Nachdruck im Review. Beim DCO unterschreibst du nicht nur "ich steh dafür grade", sondern auch dass du das Recht hast, den Code unter der Lizenz einzureichen. Und genau das kann bei LLM-Output ernsthaft niemand zusichern, weil keiner weiß was da im Training drin war. Praktisch geprüft wird das aber ohnehin nicht, weder bei KI-Code noch bei handgetipptem der verdächtig nach einem GPL-Projekt riecht. Auffliegen tut sowas erst wenn jemand den Code wiedererkennt, und das war vor den LLMs genauso. Das ist kein neues Problem, nur eins das jetzt öfter vorkommt.

 

[Johannes S]

Beim DCO unterschreibst du nicht nur "ich steh dafür grade", sondern auch dass du das Recht hast, den Code unter der Lizenz einzureichen. Und genau das kann bei LLM-Output ernsthaft niemand zusichern, weil keiner weiß was da im Training drin war. Praktisch geprüft wird das aber ohnehin nicht, weder bei KI-Code noch bei handgetipptem der verdächtig nach einem GPL-Projekt riecht.

Du hast "Das Geschäftsmodell der AI-Codeassistenten beruht auf systematischen Verstoßen gegen Urheberrecht und opensource-Lizenzen" sehr umständlich ausgedrückt
Weil auch wenn das Problem nicht grundsätzlich neu ist, erreicht es so doch eine neue Qualität.

 

[Johannes S]

Was tatsächlich ein Problem werden könnte, wenn der Reviewprozess dann auch nur noch durch KI-Tools stattfindet. Ich vertraue aber der Debian-Community und Entwicklern zu dann bei Fehlentwicklungen gegenzusteuern. Weil: Für mich ist logisch, dass die neue Policy zwar den Einsatz von KI erlaubt, aber unter die Verantwortung des Entwicklers stellt. Sprich rein technisch könnte man zwar auch das Reviewen komplett an die KI outsourcen und wäre damit im Rahmen des Beschlußes, aber es entspricht klar nicht den dahinter stehenden Intentionen. Sollte das tatsächlich zu Problemen führen, bin ich aber zuversichtlich, dass es bei Debian genug "toxische Ludditen" (1) und "Neckbeards" (1) gibt, die dann die Mistforken auspacken

(1) Um Missverständnisse zu vermeiden: Ich will tatsächlich toxisches Diskussionsverhalten und "1990 unter richtigen Unix gab es das noch nicht"-Gatekeeping nicht verteidigen oder schönreden und halte CodeOfConducts für eine gute Sache. Mir ist aber aufgefallen, dass zunehmend (nicht nur von KI-Jüngern) jede Art von Kritik als "toxisch" oder "Gatekeeping" abgebügelt wird. Das kann es ja nun auch nicht sein.

 

[HBerger]

Also wegen Debian würde ich mir da keine Sorgen machen. Klar ist KI auch hier "mit Problemen behaftet", aber wenn es irgendwo kracht wegen KI, dann wo ganz anders und mit viel dramatischeren Folgen.

dass „aber die ki sagt, das passt so“ keine erlaubte Ausrede ist Bullshit abzuliefern

Das auch die einzige Möglichkeit, und überall Praxis (hoffe ich).

Was ich in der Industrie sehe was da abgeht, ist viel schlimmer. Den Managern hat man doch ins G... ge...
in unserem Bereich wird überall entlassen, und nicht wieder aufgestockt. Der Arbeits- / Leistungs- Umfang steigt, die Komplexität auch, überall. Und das Allheilmittel dafür ist KI.

Was tatsächlich ein Problem werden könnte, wenn der Reviewprozess dann auch nur noch durch KI-Tools stattfindet.

Ist IMHO schon mehr Praxis als man es gern haben wollte. Es werden die passenden Tools angeboten, aka auch zur Pflicht gemacht. Die KI macht auch ihren Job meist sehr gut. So Sachen wie "aber hier ist die Doku nicht ganz mehr ganz korrekt" schafft vertrauen.
Problem ist aber, das das Zeugs zum reviewen immer mehr wird, die nicht KI's die am SW Prozess beteiligt sind, werden immer weniger, un die werden überflutet. Und KI generiertes Zeugs zu reviewen, (was man selbst meist gar nicht generieren lassen hat) ist nun auch nicht grade der Traum eines Entwicklers ....
Meist sind die Strukturen auch so, das derjenige der das Zeug generieren lässt, das zwar reviewen sollte, dahinter aber nochmal eine Instanz kommt, auf die man sich dann gern verlässt.