Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
GNU 프로젝트가 코드 호스팅 서비스의 윤리적 기준을 제시하며 GitHub와 Codeberg에 낮은 등급을 부여했습니다. 글쓴이는 이러한 엄격한 자유 소프트웨어(FOSS) 원칙이 현실 생활이나 개발 환경에서 오히려 비효율적이거나 과도한 제약으로 작용할 수 있음을 지적합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기GNU 프로젝트는 윤리적인 저장소 기준을 공개하고 여러 코드 호스팅 서비스를 평가함. 자체 서비스인 Savannah를 제외하면 추천할 만한 등급을 받은 곳은 Sourcehut뿐임.
Codeberg.org도 GitHub와 마찬가지로 F등급을 받게 됨. JavaScript가 필요하다는 점이 한 이유인데, 자유 소프트웨어인 Codeberg의 JavaScript도 GNU가 승인한 방식으로 표시되어 있지 않기 때문임. 남들에게 무엇이 잘못됐는지는 지적하면서 정작 자신의 가치와 비전에 맞는 새 소프트웨어를 만들지 못하는 듯해 실망스러움.
우연히 이 프로젝트의 메일링 리스트에 들어갔는데, Codeberg 관련 논의는 엉망이었음. 기억이 맞는다면 ‘표시가 부적절한’ JavaScript는 핵심 기능에 쓰이지도 않음.
오히려 Codeberg가 Sourcehut보다 GNU의 사명에 더 부합할 수도 있음. Sourcehut은 비공개·비자유 저장소를 허용하지만 Codeberg는 허용하지 않기 때문임. Codeberg를 추천하지 못한다면 기준을 고쳐야 한다고 봄.
JavaScript 표시 외에 다른 쟁점이 있었는지는 기억나지 않지만, 특정 라이선스를 추천하는 문구를 다듬는 식의 사소한 문제들이었음. “자유 JavaScript임을 확인했으니 LibreJS에서 허용해도 된다”는 식으로 안내하자는 합리적인 제안도 나왔지만 합의하지 못함. 이렇게 지향점이 잘 맞는 프로젝트를 서로 트집 잡는 모습이 안타까움.
Savannah가 바로 GNU의 가치에 맞춰 만든 소프트웨어 아닌가?
‘비자유 JavaScript의 광범위한 사용’ 부분을 읽으니, 코딩 밖의 일상에서도 비자유 소프트웨어를 피하기가 갈수록 어려워짐을 느낌. 쓰이는 곳이 늘수록 그것이 ‘잘못됐다’고 느끼기도 어려워짐.
예를 들어 우리 동네는 공원과 주택가 곳곳에 무료 지하 퇴비 수거함을 설치함. 하지만 잠그지 않으면 일반 쓰레기를 버리는 사람들이 있어, 온라인으로 등록한 주민이 스마트폰 앱과 블루투스로 여는 방식이 됨. 참여하려면 독점적인 비자유 앱을 반드시 써야 함.
“JavaScript의 함정을 거부하면 저장소 열람 외에는 아무것도 할 수 없다”는 구절을 보면 보편적인 해결책이 무엇인지 궁금해짐. GitHub를 피하면 친구·동료들이 있는 곳을 떠나야 하고, 스마트폰 앱을 피하면 지역 환경 활동에 참여하지 못함. 자유 소프트웨어는 옳아 보이지만 이 두 선택은 그렇지 않음.
소프트웨어가 일상에 깊이 들어올수록 무조건 피하라는 호소는 효과가 줄어드는 듯함. 단순히 Sourcehut이나 Codeberg를 쓰라는 권고보다, 소프트웨어 자유를 고려하지 않고 퇴비함을 잠그는 사회 속에서 다른 방식으로 참여할 대안이 필요함.
GitHub의 클라이언트 JavaScript가 전부 최소화되지 않은 GPL 코드라면 삶이 얼마나 나아질지 상상해 보면 도움이 됨. 답은 전혀 나아지지 않는다는 것임. 그 이유만으로 사용을 피하다 생기는 부수적인 영향까지 너무 걱정할 필요는 없어 보임.
‘피하라’는 말은 아마 자신이 무언가를 공개할 때 현명하게 선택하라는 뜻일 것임. 다른 저장소를 이용하거나 풀 리퀘스트를 보내는 상황에서는 선택지가 많지 않음.
글에 연결된 목록이 너무 오래돼 아쉬움. git과 Savannah를 홍보하고 Sourcehut을 소개하면서 Codeberg나 Heptapod는 빠져 있음. git만 다루고 Mercurial, Fossil 등도 잊고 있지만, 여전히 선택지는 있음.
FSF의 접근 방식을 바꾸기 어렵다는 건 알지만, 이런 글에 명확한 작성 날짜를 붙여 달라는 것도 무리한 요구일까? 페이지 맨 아래에 작은 글씨로 RCS 날짜가 있긴 하지만, 상단에 날짜를 표시하면 맥락을 이해하는 데 도움이 될 것임.
GitHub의 문제점을 나열하면서 Copilot은 언급조차 하지 않는 게 웃김. 다만 수정하면서 보니, 내가 왜 이런 말을 했는지 모르겠음.
타당한 비판도 있지만 JavaScript 관련 논리처럼 지나치게 사소하고 터무니없는 것도 있음. 인터넷과 사회에는 갈수록 현실과 동떨어진 연단에서 소리치는 사람이 줄어들 필요가 있음.
첫 문장부터 “GitHub는 소프트웨어가 전혀 아니다”라고 하는데, 정말 그런가? AGPL은 애초에 서비스로 실행되는 소프트웨어를 다루는 것 아닌가?
JavaScript 의존도가 낮은 사이트는 확실히 덜 취약하고 더 빨리 로드됨. ‘비자유’ 타령에 동의하는 건 아니지만, JavaScript 없이도 앱과 사이트가 동작하도록 만든 뒤 JavaScript로 개선하자는 원칙은 한때 웹 개발자 사이에서 흔했음.
이 글은 오히려 FSF의 문제점을 보여주는 듯함. Jeffrey Dahmer의 잘못을 따지면서 재활용을 하지 않았다는 점만 이야기하는 격임. 자유 소프트웨어와 GPL을 좋아하지만, FSF가 이토록 쓸모없어졌다는 사실은 여전히 놀라움.
FSF의 영향력은 계속 줄어들고 있음. 운영체제와 컴파일러, 시장과 성당을 논하던 단계를 이미 넘어섰음. 필요한 건 과거가 아니라 지금 우리가 살아가는 새로운 세계를 위한 기술·윤리적 비전임.
GitHub 계정을 삭제하고 싶지만 Nix와 Nixpkgs를 비롯해 더 많은 프로젝트가 옮겨 가야 함. 이런 문제를 지겹도록 이야기해도 개발자들이 다른 곳으로 옮길 기술력이 없는 것처럼 ‘네트워크 효과’라는 답만 돌아옴. 현실적으로는 YAML이 스파게티처럼 얽힌 CI를 무료로 쓸 수 있다는 점이 마지막 걸림돌인 경우가 많은 듯함.
GitHub의 품질 저하와 Microsoft 때문에 개인적으로 GitHub가 싫어지기 시작함. 업계 어디에나 쓰이니 사실상 사용할 수밖에 없지만, 개인 프로젝트는 Codeberg로 옮겨 잘 쓰고 있음. 특히 비공개 저장소를 허용하기 시작한 뒤로 만족스러움.
TS, LSP, VSCode, C# 오픈소스 추진 당시 Microsoft를 옹호했던 건 어리석었음. GitHub에서는 수용·확장·말살 전략으로 흘러가는 듯함.
결국 핵심은 Microsoft라고 봄.
GNU 프로젝트는 늘 그렇듯 JavaScript에 집착하다 타당한 비판까지 설득력을 잃게 만듦. HTML에 온갖 기능을 욱여넣으려던 시도를 그만둔 뒤 현대 웹 기능이 사실상 모두 JavaScript로 구현되는 상황에서, JavaScript가 나쁘다는 집착을 진지하게 받아들이기 어려움. 실행이 너무 쉽다는 것 외에는 명확한 근거도 보이지 않아, GNU가 소프트웨어 실행에 일정 수준의 복잡함을 요구하는 듯함.
나머지 비판도 타당성이 제각각임. Choose a License에 관한 내용은 무의미할 만큼 사소하지만 Copilot 비판은 적절함. 중앙화 비판도 이상함. 네트워크 효과를 빼면 GitHub 내부의 종속 요인은 별로 없고, 업적 기능은 Discourse 같은 오픈소스 소프트웨어에도 있음. GitHub의 패치 작업 흐름은 특이하지만 git의 데이터 모델을 배울 필요가 없다는 점에서 패치를 직접 제출하는 것보다 확실히 사용하기 쉬움.
Actions 비판도 부적절함. 안전하지 않은 작업 실행을 막는 것을 단점으로 꼽는 건 ‘비밀번호가 존재해서는 안 된다’는 태도와 비슷하며, 기억이 맞는다면 GNU가 실제로 그런 입장을 취한 적도 있음. 대부분의 Action은 빌드 결과나 컨테이너를 저장소에 올리거나 로컬에서도 실행할 수 있는 린터를 돌리는 정도임. 다른 실행기로 옮기는 데 길어야 오후 한나절이면 되고 로컬 빌드도 가능한데, 더 큰 문제로 받아들이기는 어려움. git이 이메일 주소를 요구하는 것 자체가 문제라고 봄. GitHub와 GitLab 모두 주소를 숨기면서 계정에 기여를 귀속시키는 기능을 제공함. 민감한 개인정보로 여길 만한 불필요한 정보를 이력에 영구히 남기는 셈이므로, GitHub가 주소를 쉽게 노출하지 않는 것은 오히려 장점임. git에서도 이메일을 선택 사항으로 만들고 기여자 표시에는 이름만 쓰는 편이 이상적임.
GitLab은 모르겠지만 GitHub는 웹 화면에서 가장 눈에 띄는 곳의 이메일을 숨기는 정도임. 저장소를 복제하면 커밋에 사용된 주소를 볼 수 있고, 복제하지 않아도 커밋 URL 뒤에 .patch 를 붙이면 커미터의 이메일이 포함된 원시 패치를 볼 수 있음.
나는 이메일 주소를 꽤 민감한 개인정보로 보는 쪽은 아니라 큰 문제로 느끼지는 않음. 더 불편한 건 주소가 오래돼 유효하지 않게 된다는 점임. git 로그를 볼 때 옛 주소를 새 주소에 대응시키는 인터페이스가 있으면 좋겠음.