28년 경력 개발자가 MIT를 버리고 EUPL을 선택한 이유

28년 경력 개발자가 MIT를 버리고 EUPL을 선택한 이유

AI 뉴스 썸네일

728x90

MIT 라이선스는 npm 생태계의 기본값처럼 자리 잡았어요. 짧고 단순하고, 법적 부담도 거의 없죠. 그런데 28년 동안 소프트웨어를 공개해 온 개발자 한 명이 그 기본값을 깨고 EUPL-1.2로 갈아탔어요. 단순한 취향 변화가 아니라, 오픈소스가 누구를 위해 존재해야 하는지에 대한 물음이 이번 전환의 출발점이에요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
라이선스 전환	MIT·LGPLv2를 쓰던 개발자가 EUPL-1.2로 기본 라이선스 변경	허용적 라이선스에 대한 회의가 커지는 흐름의 사례
EUPL의 특징	배포 방식과 무관하게 상호적 라이선스를 요구하는 강한 카피레프트	SaaS로 카피레프트를 우회하는 구조를 막는 설계
실무 영향	회사 코드에 넣기 전에 라이선스 검토부터 해야 해요	AGPL처럼 도입 전 검토가 필요한 라이선스가 하나 더 늘었어요

1. LGPLv2와 MIT를 거쳐 EUPL로 옮긴 28년

글쓴이인 핀란드의 개발자 헨리 베르기우스(Henri Bergius)는 자신의 라이선스 선택을 세 시기로 정리해요. 1990년대 웹 프레임워크 Midgard에는 약한 카피레프트인 LGPLv2를 썼어요. 당시엔 쓸 만한 자유 소프트웨어 라이선스 자체가 많지 않았죠. 2011년 무렵 JavaScript 작업을 본격화하면서 MIT로 넘어갔어요. npm 패키지 생태계가 선호하는 "원하는 대로 쓰되, 나를 고소하지는 말라"는 방식이 서로 맞아떨어졌거든요. 2

그리고 올해, 기본 라이선스를 EUPL-1.2로 바꿨어요. EUPL은 유럽연합이 만들고 공개한 OSI 승인 자유 소프트웨어 라이선스예요. 앞선 두 선택과 가장 크게 다른 점은 강한 카피레프트라는 거예요. 소프트웨어를 어떤 방식으로 배포하든 상호적 라이선스 적용을 요구해서, 서비스 형태로만 제공하면 의무를 피할 수 있는 이른바 SaaS 허점을 막아요. 2

전환의 이유는 비용이 아니라 배분이에요

베르기우스는 동기를 솔직하게 밝혀요. 오픈소스 진영이 자유소프트웨어 진영과의 논쟁에서 이기긴 했지만, 사용자와 개발자에게 돌아온 이익은 적었다는 판단이에요. 그 노력이 대기업의 개발 비용을 낮추고 억만장자를 조만장자로 만드는 데 기여했다는 비판도 함께요. 기업이 개발자가 정한 조건으로 소프트웨어를 쓰고 싶지 않다면, 직접 비용을 들여 자체 소프트웨어를 만들면 된다는 태도예요. 2

덧붙인 장점도 흥미로워요. EUPL은 법적 효력이 있는 23개 언어 공식 번역을 제공해요. 대부분의 소프트웨어가 실리콘밸리 밖의 더 넓은 세계에서 만들어지고 쓰이는 상황에서, 영어 원문만 있는 라이선스보다 신뢰하기 좋다는 논리예요. 2

이미 적용된 프로젝트들

새 라이선스는 이미 실제 프로젝트에 적용됐어요. Reticulum 메시 네트워킹 프로토콜의 JavaScript 구현체인 reticulum-js, Reticulum 기반 탈중앙화 인가 시스템인 dacar, 재생에너지로 운항하는 보트용 예측 시스템인 signalk-energy-predictor, InReach 위성 문자 메시지로 블로그 글을 올리고 기상 데이터를 내려받는 도구까지 EUPL로 공개됐어요. NoFlo 개발 환경의 새 버전도 EUPL로 개발 중이에요. 단 외부 기여가 많이 쌓인 기존 NoFlo 프로젝트 자체는 MIT를 유지해요. 기여자 동의 없이 단순히 라이선스를 바꿀 수 없으니까요. 2

왜 중요한가요

이 글은 한 개발자의 취향 이야기로 끝나지 않아요. 오픈소스의 지속가능성 문제가 라이선스 선택으로 현실화하는 사례거든요. 실제로 이 소식이 공유된 Lobste.rs와 GeekNews 토론에서도 같은 결론에 도달한 개발자들이 여럿 보였어요. 어떤 이는 2년 전부터 AGPL을 선택했고, 어떤 이는 최근 프로젝트에 GPL 3를 적용했어요. "노출을 대가로 한 무급 노동은 함정"이라는 표현도 나왔죠. 1

다만 반대 시각도 분명해요. MIT를 선택하는 건 사용자를 위해서가 아니라 스스로를 위해서라는 입장, 그리고 허용적 라이선스로 공유되는 공통 자산 자체가 가치라는 입장이에요. 어느 쪽이 맞다는 문제가 아니라, 라이선스는 "누가 어떤 조건으로 내 코드를 쓰게 할 것인가"라는 정책 결정이라는 점이 이 논쟁의 핵심이에요. 1

도입 전에 알아둘 점

EUPL을 회사 코드에 넣기 전에 검토할 부분이 있어요. 커뮤니티 토론에 따르면 EUPL은 FAQ 기준으로 배포 시 같은 라이선스 유지를 요구하는 약한 카피레프트에 가깝고, 라이브러리나 도구로 만든 결과물까지 파생 저작물로 보지는 않아요. 유럽법은 상호 운용 목적으로 독립 저작물을 연결하는 것을 라이선스 변경 없이 허용하거든요. 1

한편 EUPL의 호환성 조항은 늘 논쟁을 일으켜요. EUPL 저작물과 호환 라이선스 저작물을 결합한 파생물은 해당 호환 라이선스로 배포할 수 있어요. FSF는 이 조항으로 카피레프트가 약한 라이선스로 재라이선스될 길이 생긴다고 보지만, EU 측은 라이선스 변경만이 목적이면 저작권 침해라고 명시해요. 해석이 갈리는 부분이라서, 도입 전에 이 조항을 직접 확인해 보는 편이 안전해요. 1

개발자 개인에게도 쓸모 있는 교훈이 하나 있어요. 기여자가 여러 명인 기존 프로젝트는 라이선스를 함부로 바꿀 수 없어요. 베르기우스가 NoFlo는 MIT를 유지하고 새로 작성하는 개발 환경에만 EUPL을 적용한 이유예요. 새 프로젝트를 시작할 때 라이선스를 고르는 게 사실상 되돌리기 어려운 결정이라는 뜻이기도 해요. 2

참고 자료

1. 내 소프트웨어의 기본 라이선스를 MIT에서 EUPL로 바꿨다 — GeekNews
2. I changed my license — bergie.iki.fi (Henri Bergius 블로그)
3. European Union Public Licence (EUPL) 공식 페이지 — Interoperable Europe (유럽연합)
4. EUPL FAQ — Interoperable Europe (유럽연합)