Emacs 사용자는 아니지만, 핵심 개발 도구를 저품질 AI 생성물과 그 추종자들로부터 지키겠다는 단호한 선언을 보니 든든함

앞으로의 GNU 정책이 역사적으로 지켜 온 높은 윤리적 기준을 Emacs에도 유지하지 못할 수 있다는 우려는 왜 생긴 것인가? GNU가 결국 대부분 비자유 모델인 LLM(Large Language Model)을 자사 소프트웨어에 허용하려는 것인가?

충분히 타당한 질문임. 여기서는 올바른 대응이 매우 명확하고 쉬운데도 GNU가 아직 실행하지 않았다는 사실부터 첫 번째 위험 신호로 보임
다른 GNU 프로젝트에서도 윤리적 행동에 기반한 정책에 상당한 반발이 있으며, GNU 프로젝트 중 지도부를 가장 신뢰하는 Guix조차 아직 대응 방안을 논의하고 있음: https://codeberg.org/guix/guix-consensus-documents/pulls/13
GNU는 역사적으로 다른 모든 요소를 희생하면서까지 라이선스와 저작권에만 근시안적으로 집중해 왔음. LLM 지지자들이 라이선스상 문제가 없다는 논리를 만들면, GNU가 그 너머에 있는 수많은 문제를 더는 논의하지 않을까 우려됨
물론 GNU가 올바른 결정을 내려 이 모든 준비가 불필요해질 수도 있으며, 그것이 우리가 바라는 최선의 결과임

그럴 가능성은 낮아 보임. FSF(Free Software Foundation) 관계자들에게 들은 바로는 이 사안을 매우 신중하게 다루고 있음
GNU 철학에서 LLM은 적어도 명시적으로는 윤리 문제가 아니며, 많은 자유 소프트웨어 개발자는 별개로 윤리적 이유에서 LLM에 반대함. 더 직접적인 우려는 LLM 생성 코드가 저작권 보호를 받지 못해 카피레프트(Copyleft)를 무효화할 수 있다는 데 있음
이미 너무 많은 프로젝트가 LLM을 받아들이는 모습을 봤으므로, 실제로 벌어지기 전에 대비할 필요가 있음

rsync가 LLM을 적극 도입했다고 하지만, 최근에는 LLM 특유의 흔적 때문에 rsync 기여가 거절됐다는 내용을 읽지 않았나?

다른 프로젝트와 혼동한 것 같음. 최근 게시물에서는 그런 내용을 찾지 못했지만, rsync가 LLM을 사용했다는 사실은 확인했음

Emacs는 GNU가 결정을 내릴 때까지 LLM 생성 기여를 받지 않고 있으므로, 이 선언은 다소 앞서 나간 태도로 보임

해당 페이지도 그 사실을 전제로 작성됐으며, 세 번째 문단쯤에서 직접 다루고 있음

LLM은 이전에는 개선하기 어려웠던 영역에서 Emacs를 발전시킬 수 있음. 이미 많은 작업이 필요했던 매우 복잡한 버그와 추상화 계층을 개선한 전례도 있음

이 움직임의 동기는 전적으로 윤리에 있음
‘논의하지 않는 사항’ 절에서 밝히듯, LLM이 주장만큼 효과적인지는 논점이 아님. 핵심은 LLM 사용이 사용자 권한 강화를 지향하는 원칙 있는 소프트웨어 운동의 일부가 될 수 있느냐는 것임