OpenBSD용 Vibe-Coded Ext4
Source: Hacker News
번역할 텍스트를 제공해 주시면 한국어로 번역해 드리겠습니다.
[LWN subscriber‑only content]
다수의 프로젝트가 대규모 언어 모델(LLM)로 생성된 제출물 중 어떤 것이(있는 경우) 코드 베이스에 받아들여져야 하는지에 대한 질문에 어려움을 겪고 있습니다. 이 논의는 최근 **Python chardet 모듈에 발생한 사례**처럼 LLM‑구동 재구현을 기존 코드의 copyleft 제한을 제거하는 수단으로 사용하려는 시도로 인해 더욱 혼란스러워졌습니다.
이러한 맥락에서, Linux ext4 파일시스템의 LLM‑생성 구현을 OpenBSD에 도입하려는 시도는 언제나 논란을 일으킬 것이었으며, 해당 프로젝트는 이러한 제출물에 대해 회의적인 명확한 이유를 가지고 있습니다.
논란의 기원
모든 일은 3월 17일에 Thomas de Grivel이 openbsd-tech 메일링 리스트에 ext4 구현을 게시하면서 시작되었습니다. 그는 이 구현이 완전한 읽기·쓰기 접근을 제공하고 e2fsck 파일시스템 검사기를 통과한다며, 다만 저널링은 지원하지 않는다고 밝혔습니다. 코드에는 여러 저작권 선언이 포함되어 있지만, 어떻게 작성되었는지에 대해서는 언급하지 않았습니다. 그러나 블로그 포스트에서 de Grivel은 코드의 출처에 대해 더 솔직하게 밝혔습니다:
No Linux source files were ever read to build this driver. It’s pure AI (ChatGPT and Claude‑code) and careful code reviews and error checking and building kernel and rebooting/testing from my part.
예측 가능한 우려가 이 코드에 제기되었으며, 그 중 다수는 (GPL‑라이선스) Linux 구현의 파생 제품으로 간주될 가능성과 관련되었습니다. 해당 LLM이 Linux ext4 코드와 문서를 거의 확실히 학습했을 가능성은 상황을 더 악화시켰습니다. GPL‑라이선스 코드를 OpenBSD에 도입하는 것은, 가볍게 말해 환영받지 못합니다; Christian Schulte는 라이선스 오염에 대해 우려했습니다:
I searched for documentation about that ext4 filesystem in question. I found some GPL‑licensed wiki pages. The majority of available documentation either directly or indirectly points at GPL‑licensed code. In my understanding of the issue discussed in this thread this already introduces licensing issues. Even if you would write an ext4 filesystem driver from scratch for base, you would almost always need to incorporate knowledge carrying an illiberal license.
하지만 Theo de Raadt는 구조와 알고리즘의 재구현은 저작권법에 의해 허용된다고 지적했으며, 이는 상호 운용성이 이루어지는 방식이라고 설명했습니다. 그는 이 기여를 병합하는 데 찬성한다는 의미는 아니었습니다.
Stay on top of Linux kernel development with a one‑month free trial subscription to LWN, no credit card required.
법적 회색 지대
OpenBSD 입장에서는 LLM‑생성 코드의 저작권 상태가 실제로 문제입니다. 그 이유는 아무도 그 상태가 무엇인지, 혹은 해당 코드에 저작권 자체가 존재할 수 있는지 알 수 없기 때문입니다. 저작권이 없으면 프로젝트가 코드를 재배포하기 위해 필요한 권한을 부여받을 수 없습니다. de Raadt는 다음과 같이 설명했습니다:
At present, the software community and the legal community are unwilling to accept that the product of a (commercial, hah) AI system produces is Copyrightable by the person who merely directed the AI.
And the AI, or AI companies, are not recognized as being able to do this under Copyright treaties or laws, either. Even before we get to the point that the AIs are corpus‑blenders and Copyright‑blenders.
So as of today, the Copyright system does not have a way for the output of a non‑human produced set of files to contain the grant of permissions which the OpenBSD project needs to perform combination and redistribution.
Damien Miller도 비슷한 입장을 밝혔습니다:
Who is the copyright holder in this case? It clearly draws heavily from an existing work, and it’s clear the human offering the patch didn’t do it. It’s not the AI, because only persons can own copyright. Is i
Source: …
t the set of people whose work was represented in the training corpus? Was it the set of people who wrote ext4 and whose work was in the training corpus? The company who own the AI who wrote the code? Someone else?
We don’t know. The law hasn’t caught up to the technology yet and we can’t take the risk that, when it does, it will go in a way that makes use of AI‑written code now expose us to legal risk.
이 말은 de Grivel에게 완전히 와닿지는 않았으며, 그는 머신‑생성 코드에 대한 저작권 주장을 철회하기를 거부했습니다. 그는 또한 LLM으로 할 수 있는 일들에 대해 명백히 만족해 보였습니다:
우리는 저작권 침해 없이 새로운 독창적인 방식으로 서로의 코드를 자유롭게 훔칠 수 있다 – 1 시간 만에 훔칠 수 있는 코드 양이 정말 미친 듯이 많다. Bell Labs에서 20 년이 걸리던 일이 이제는 20 시간 연속으로 할 수 있다.
대화는 한동안 이어졌지만, 결과에 대한 의심은 전혀 없었습니다; de Raadt는 다음과 같이 명확히 말했습니다:
“이렇게 의심스러운 저작권 상황에서 새로운 코드를 받아들일 가능성은 제로다.”
위에서 언급한 블로그 글에서 de Grivel은 3월 23일에 LLM‑생성 코드를 모두 제거하고 자신이 직접 작성한 코드만 남기겠다고 메모를 추가했습니다. 그러나 이 사건 이후, 그가 이후 버전을 실제로 스스로 작성했음을 다른 사람들에게 설득하는 일은 큰 난관이 될 수 있습니다. 그는 **“OpenBSD를 포크하는 것이 더 쉬울지도 모른다.”**라고 인정했습니다.
앞으로의 전망
LLM이 수천 줄의 코드를 뽑아내어 원하는 프로젝트에 제출할 수 있다고 결론짓는 사람들의 수가 빠르게 증가하고 있습니다. 말할 필요도 없이, 이들 사람들은 자신들의 이름으로 제출하는 작업의 출처를 문서화하는 데 항상 부지런하지는 않습니다. 언젠가 OpenBSD 리뷰어들의 예리한 눈조차도 모든 코드를 걸러내지 못하게 될 순간이 올 수도 있습니다.
# Repositories
All of this code is setting some worrisome potential traps for the future.
As Tyler Anderson pointed out, the price of these tools is unlikely to go down as development projects become more dependent on them. Who will maintain this code, when its original *author* does not understand it and has no personal investment in it, is unclear at best. And if there is, in fact, a potential copyright problem inherent in this code, there will have to be a lot of scrambling (or worse) when it comes to light.
Given all of that, it is unsurprising that many projects, especially those with longer time horizons, are proving reluctant to accept machine‑generated submissions.