리처드 스톨만과 자유 소프트웨어: 코드를 바꾼 아이디어들

왜 리처드 스톨만이 여전히 중요한가

소프트웨어는 단순한 기술 산물이 아니라 권한의 집합이기도 합니다. 누가 소프트웨어를 실행할 수 있고, 복사하고, 친구와 공유하고, 버그를 고치거나 그 위에 새로운 것을 만들 수 있는가? 이런 질문들은 코드 자체보다 라이선스에 의해 더 많이 결정됩니다. 소프트웨어가 업무, 소통, 연구의 핵심이 되면서 “무엇을 할 수 있는가”에 관한 규칙이 기능만큼이나 혁신을 형성하기 시작했습니다.

리처드 스톨만(보통 "RMS"로 불림)이 중요한 이유는 그 규칙들을 무시할 수 없게 만들었기 때문입니다. 1980년대 초, 그는 한 변화를 목격했습니다: 점점 더 많은 프로그램이 소스 코드 없이 배포되었고, 사용자들은 점점 누군가의 조건대로만 소프트웨어를 사용할 수 있다고 들었습니다. 스톨만은 이것을 단순한 불편으로 보지 않고 사용자와 개발자의 자유 상실로 규정했고, 그 자유를 지키기 위한 명확한 원칙과 법적 도구를 제안하며 대응했습니다.

이 글의 범위

이 글은 스톨만의 아이디어와 그 실질적 결과물들—자유 소프트웨어 정의, GNU 프로젝트, 카피레프트, GNU 일반 공중 사용 허가서(GPL)—그리고 이들이 현대 오픈소스 생태계와 소프트웨어 라이선스 규범을 어떻게 바꿨는지에 초점을 맞춥니다.

전기는 아니며, 커널 컴파일이나 저장소 관리 같은 기술적 심층 분석도 아닙니다. 프로그래밍 배경이 없어도 따라올 수 있게 썼습니다.

균형 있고 접근 가능한 관점

스톨만은 영향력이 큰 동시에 논쟁적입니다. 여기서는 사실 기반과 가독성을 유지하려고 합니다: 그가 주장한 바, 어떤 법적 장치가 나왔는지, 기업과 개발자가 어떻게 적응했는지, 그리고 오늘날에도 계속되는 논쟁의 지점은 어디인지—그렇게 하면 그의 작업이 일상적인 소프트웨어 선택에 왜 영향을 미치는지 알 수 있습니다.

“자유 소프트웨어”가 실제로 의미하는 것

"자유 소프트웨어"는 자유라는 단어 때문에 오해되기 쉽습니다. 스톨만은 자유를 사용자가 소프트웨어를 통제할 수 있는 능력으로 의미했습니다.

프로그램이 가격이 0원이라도(무료) 그것을 검사하거나 변경하거나 공유할 수 없다면, 스톨만이 신경 쓴 의미에서는 비자유입니다.

네 가지 필수적 자유

자유 소프트웨어는 네 가지 기본 권한으로 정의됩니다:

• 자유 0: 어떤 목적으로든 프로그램을 실행할 권리.
• 자유 1: 프로그램이 어떻게 동작하는지 공부하고 원하는 대로 변경할 권리.
• 자유 2: 복사본을 재배포하여 다른 사람을 도울 권리.
• 자유 3: 수정한 버전을 배포하여 커뮤니티가 혜택을 보도록 할 권리.

이 자유들은 사용자의 주체성을 뜻합니다: 단순한 도구의 소비자가 아니라 검증하고, 적응하고, 개선할 수 있는 참여자가 되는 것입니다.

소스 코드 접근은 양보할 수 없는 이유

자유 1과 3은 소스 코드—사람이 읽을 수 있는 지시문—없는 상태에서는 불가능합니다. 소스가 없으면 소프트웨어는 밀폐된 가전제품처럼 됩니다: 사용할 수는 있지만 무엇을 하는지 알 수 없고, 고장이 나면 고칠 수 없으며, 새로운 필요에 맞게 조정할 수도 없습니다.

소스 코드 접근은 신뢰에도 중요합니다. 독립적인 검토(프라이버시, 보안, 공정성)를 가능하게 하고 원저자가 지원을 중단해도 유지관리할 수 있게 만듭니다.

간단한 비유: 레시피 vs 밀봉된 음식

레스토랑 식사를 생각해보세요.

• 독점 소프트웨어는 밀봉된, 즉석 조리된 요리를 사는 것과 같습니다: 먹을 수는 있지만 재료를 알 수 없고 레시피를 바꿀 수 없으며 복사본을 공유할 수 없습니다.
• 자유 소프트웨어는 레시피를 얻는 것과 같습니다: 집에서 요리할 수 있고, 만드는 법을 배우고, 알레르기에 맞게 조정하고, 개선한 레시피를 친구와 공유할 수 있습니다.

핵심은 이것입니다: 자유 소프트웨어는 사용자가 자신의 컴퓨팅을 통제하는 데 필요한 자유에 관한 것입니다.

스톨만이 반응했던 문제

"소프트웨어 라이선스"가 널리 논쟁거리 되기 전에는 많은 프로그래밍 문화—특히 대학과 연구소—가 한 가정을 바탕으로 돌아갔습니다: 도구를 개선할 수 있으면 그 개선을 공유했습니다. 소스 코드는 소프트웨어와 함께 이동했고, 사람들은 서로의 코드를 읽으며 배우고 수정은 비공식적 협업으로 퍼졌습니다.

공유 관습에서 봉인된 소프트웨어로의 전환

소프트웨어가 제품으로서의 가치가 커지자 그 문화는 변하기 시작했습니다. 회사들(심지어 일부 기관도)은 소스 코드를 경쟁 우위로 취급했습니다. 배포는 "공유 금지" 조건과 함께 이루어졌고, 코드가 프로그램에 포함되어 배포되는 경우가 줄어들었으며 비밀유지계약이 일상이 되었습니다. 공동으로 문제를 해결하던 개발자들에게 이 변화는 단순한 불편이 아니라 커뮤니티 문제 해결을 법적으로 위험하게 만드는 규칙 변화처럼 느껴졌습니다.

프린터 이야기(예시로서)

가장 많이 회자되는 기원담 중 하나는 MIT AI 연구실의 프린터 이야기입니다. 스톨만은 새 프린터가 바이너리 형태로만 배포된 소프트웨어와 함께 왔고 소스가 제공되지 않았다고 묘사했습니다. 실용적인 문제는 사소했습니다: 연구실은 잼 알림이나 작업 라우팅 같은 기능을 처리하려고 프로그램을 수정하고 싶었습니다. 옛날 해커 규범에서는 누군가가 코드를 패치하고 수정본을 공유했을 것입니다. 여기서는 그럴 수 없었죠—소스를 볼 수도, 바꿀 수도 없었으니까요.

이 사건 하나가 전 세계적 운동을 만들었다고 보기는 어렵습니다. 다만 더 넓은 추세의 명확하고 공감 가능한 사례였고, 사람들이 의존하던 도구들이 사용자에게 의해 고쳐질 수 없게 되는 흐름을 드러냈습니다.

왜 이것이 새로운 라이선스 아이디어로 이어졌나

스톨만에게 핵심 문제는 단지 기술적 접근성만이 아니라 협력할 자유의 상실이었습니다. 프로그램을 어떻게 동작하는지 공부할 수 없다면 그것을 통제할 수 없습니다. 개선을 공유할 수 없다면 커뮤니티는 분열되고 모두가 사적으로 문제를 다시 발명해야 합니다.

이 동기는 이후의 라이선스 혁신을 형성했습니다. 스톨만은 선의나 비공식적 규범에 의존하는 대신 소프트웨어가 상업적 가치가 생겼을 때도 협력이 철회되지 않도록 권리를 보존하는 규칙을 원했습니다.

GNU 프로젝트: 자유 운영체제 만들기

스톨만의 큰 실천은 단순한 선언이 아니라 실용적인 엔지니어링 노력이었습니다. 1983년 그는 GNU 프로젝트를 발표했고, 야심찬 목표를 세웠습니다: 누구나 사용하고, 공부하고, 수정하고, 공유할 수 있는 완전한 운영체제를 구축하되 Unix와 호환되게 만들어 익숙한 프로그램과 워크플로를 실행할 수 있게 하자는 것이었습니다.

단일 도구가 아닌 전체 시스템

운영체제는 한 프로그램이 아닙니다—전체 스택입니다. GNU는 일상적으로 컴퓨터를 유용하게 만드는 데 필요한 모든 요소를 만들기로 했습니다. 예를 들면:

• 컴파일러(가장 유명한 것은 GCC)—개발자가 코드를 실행 파일로 변환하도록
• 핵심 커맨드라인 유틸리티(파일 복사, 텍스트 검색, 프로세스 관리 등)
• 라이브러리와 개발 도구—더 많은 소프트웨어를 빌드하도록 지원
• 셸과 편집기—실제 작업을 하는 데 필요한 도구

평범하게 말하자면: GNU는 배관, 배선, 스위치 등 컴퓨터를 쓸 수 있게 하는 모든 기반을 구축했습니다.

GNU + Linux: 대부분의 사람들이 접한 방식

1990년대 초 GNU는 사용자 공간(userland)의 큰 부분을 만들었지만 한 가지 핵심 요소, 커널(하드웨어와 시스템 자원을 직접 관리하는 부분)이 늦어졌습니다. 1991년 리눅스가 등장했을 때 그 빈틈을 메꿨습니다.

그래서 오늘날 많은 인기 있는 시스템은 GNU 구성 요소와 리눅스 커널을 결합한 형태로 제공되며, 이를 흔히 "GNU/Linux"라고 부릅니다.

인프라가 이상만큼 중요했다

GNU는 자유 소프트웨어 아이디어를 실현 가능한 형태로 만들었습니다. 철학은 왜 자유가 중요한지를 설명했고, GNU는 자유를 실제로 가능하게 하고 반복 가능하며 확장 가능한 도구를 제공했습니다.

쉬운 말로 풀어쓴 카피레프트

카피레프트는 소프트웨어를 처음 배포했을 때뿐만 아니라 이후 버전에서도 자유를 유지하도록 설계된 라이선스 전략입니다. 카피레프트 코드(수령자는 사용, 공부, 수정, 공유가 가능)는 수정본을 재배포할 때 동일한 자유를 다른 사람들에게도 전하도록 요구합니다.

저작권에 기대는 법적 도구

카피레프트는 ‘저작권 반대’처럼 들리지만 실제로는 저작권법에 기반합니다. 저작권자가 자신의 권리를 이용해 라이선스에 조건을 달아 허가를 설정하는 방식입니다: "복사하고 수정할 수 있지만, 재배포할 때는 같은 라이선스를 유지해야 한다." 저작권이 없다면 이러한 조건을 강제할 법적 수단이 없습니다.

“동일조건 공유(share alike)” 아이디어와 간단한 예

코드를 따라가는 규칙으로 생각해보세요:

• 포크: 카피레프트 프로젝트를 포크해 기능을 추가하고 포크를 공개하면, 소스 코드를 공개하고 같은 라이선스를 유지해야 합니다.
• 재배포: 프로그램을 제품에 포함시켜 고객에게 배포하면 돈을 받을 수 있지만, 소스와 동일한 권리를 수령자에게 제공해야 합니다.

목표는 스톨만이 우려했던 패턴을 막는 것입니다: 커뮤니티 작업을 누군가가 가져가 개선한 뒤 그 개선을 잠가 버리는 행위입니다.

카피레프트 vs 관대 허용 라이선스

MIT나 BSD 같은 관대 허용 라이선스는 수정본을 폐쇄적 라이선스로 재배포하는 것을 허용하는 경향이 있습니다. 반면 카피레프트(GPL 등)는 광범위한 사용과 수정을 허용하지만 재배포되는 파생작이 동일한 카피레프트 조건을 유지하도록 요구해 자유가 하류로도 보존되게 합니다.

GNU GPL이 라이선스를 바꾼 방식

GNU GPL은 ‘공유’를 친절한 제스처가 아니라 강제 가능한 규칙으로 바꿨습니다. GPL 이전에는 소스 코드를 받아 개선하고 그 개선을 폐쇄적으로 배포할 수 있었습니다. GPL은 그 역학을 뒤집어 재배포에 조건을 붙여 사용자 권리를 보호했습니다.

GPL이 제공하는 것과 요구하는 것

실무적으로 GPL은 사용자가 어떤 목적이든 프로그램을 실행하고 소스를 읽고 수정하며 원본이나 수정본을 공유할 권리를 줍니다.

그리고 당신이 GPL 소프트웨어를 재배포하면(특히 제품으로서) 동일한 자유를 전달해야 합니다. 일반적으로 이것은 다음을 의미합니다:

• 소스 코드 제공(또는 소스 입수 방법 제공)
• 라이선스 전문 포함 및 저작권 표기 보존
• 수정사항을 포함한 파생작을 GPL로 라이선스하여 하위 사용자가 배제되지 않도록 함

소스 배포 의무(언제 적용되는가)

GPL의 의무는 주로 소프트웨어를 타인에게 배포할 때 발동합니다—바이너리를 배송하거나 장치에 소프트웨어를 탑재해 판매하거나 고객에게 복사본을 제공하는 경우 등. 개인적 내부 용도로만 수정하고 배포하지 않는다면 일반적으로 소스를 공개할 필요는 없습니다.

‘파생작’의 실용적 의미

법리적 이론이 필요하진 않습니다: GPL 코드를 링크해 애플리케이션에 통합하면 결합된 결과물은 보통 파생작으로 간주되어 GPL로 배포해야 합니다. 단순히 GPL 프로그램을 실행하거나 표준 인터페이스로 별도 프로세스와 통신하는 경우는 대개 다르게 취급됩니다.

GPL 변형: v2, v3, LGPL

GPLv2는 고전적인 널리 쓰이는 버전이고, GPLv3는 특허 거래와 티보화에 대한 보호를 추가했습니다. LGPL은 라이브러리용으로 설계되어, 특정 조건 하에서 사유 프로그램이 라이브러리를 링크할 수 있도록 허용합니다(라이브러리 자체는 자유롭게 유지).

개발자가 자유 라이선스 하에서 가지는 권리와 책임

자유 라이선스(특히 GNU GPL)는 단순히 공유를 허용하는 수준을 넘어서 사용자가 소프트웨어를 공부하고 수정하고 재배포할 권리를 강력하게 보호합니다. 개발자 입장에서는 자신의 개선이 닫힌 제품으로 흡수되어 커뮤니티가 그 혜택을 누릴 수 없게 되는 것을 막을 수 있습니다.

얻는 권리들

GPL 하에서는 당신이:

• 자유롭게 실험: 소스를 읽고 변경하고 수정본을 실행할 수 있습니다.
• 작업을 공유: 원본이나 수정본을 배포할 수 있습니다.
• 다른 사람의 개선을 기반으로 구축: 수령자들이 동일한 자유를 갖기 때문입니다.

이 때문에 GPL은 종종 “강제 가능한 상호호혜”라고 불립니다. 누군가 GPL 적용 소프트웨어(또는 파생작)를 배포하면 하위 사용자에게 같은 제한을 추가할 수 없습니다.

떠맡는 책임들

이 권리들은 당신이 소프트웨어를 배포할 때 다음과 같은 의무와 함께 옵니다:

• 저작권 및 라이선스 표기를 보존할 것
• GPL이 요구할 때 대응 소스(corresponding source)를 제공하거나 제공 방법을 명시할 것
• 라이선스를 유지해 수령자가 자신의 권리를 알게 할 것

이 의무들은 함정이 아니라 협업이 일방적 추출로 변하는 것을 막는 메커니즘입니다.

실무적 주의: 컴플라이언스

팀은 라이선스 준수를 릴리스 위생처럼 다루어야 합니다. 다음을 추적하세요:

• 배포하는 오픈소스 구성 요소와 그 버전·라이선스
• 소스를 제공하는 위치(또는 서면 제공 방식)
• 수행한 수정사항들

간단한 소프트웨어 구성 목록(SBOM)과 릴리스 체크리스트는 법률 문제에 휘말리기 전에 대부분의 문제를 예방합니다.

자유 소프트웨어와 오픈소스: 가치의 분기점

코드 수준에서는 “자유 소프트웨어”와 “오픈소스”가 많은 동일한 프로젝트를 가리키는 경우가 많습니다. 차이는 주로 왜 공유가 중요한지에 대한 관점 차이입니다.

다른 우선순위: 자유 vs 채택

자유 소프트웨어 운동(리처드 스톨만과 자유 소프트웨어 재단과 연관)은 소프트웨어 자유를 윤리적 문제로 봅니다: 사용자는 소프트웨어를 실행하고, 공부하고, 변경하고, 공유할 권리를 가져야 한다는 주장입니다. 목표는 단지 더 나은 엔지니어링이 아니라 사용자 자율성 보호입니다.

오픈소스 접근법은 실용적 결과에 초점을 맞춥니다: 더 나은 협업, 빠른 반복, 버그 감소, 투명성을 통한 보안 향상 등. 오픈소스는 이런 방식의 우수성을 강조하며 도덕적 스탠스를 요구하진 않습니다.

왜 “오픈소스”가 널리 받아들여졌나

1998년 오픈소스 이니셔티브(OSI)는 비즈니스 친화적으로 보이게 하기 위해 “오픈소스”라는 용어를 대중화했습니다. “자유 소프트웨어”는 종종 ‘무상’으로 오해되었고, 일부 기업은 권리와 윤리를 전면에 내세우는 메시지에 부담을 느꼈습니다. “오픈소스”는 조직이 이 방식을 채택하면서도 이념적으로 보이지 않게 설명하는 길을 열었습니다.

동일한 라이선스, 다른 서사

많은 오픈소스 프로젝트가 GNU GPL이나 다른 카피레프트 라이선스를 사용하는 반면, 다른 프로젝트는 MIT나 Apache 같은 관대 허용 라이선스를 고릅니다. 법적 문구는 동일할 수 있지만 기여자, 사용자, 고객에게 들려주는 이야기는 달라집니다. 한 메시지는 “이건 당신의 자유를 보호합니다”이고, 다른 메시지는 “이 방식이 마찰을 줄이고 품질을 개선합니다”입니다.

간단한 의사결정 가이드

팀의 우선순위가 하류 사용자가 동일한 자유를 유지하게 하는 것이라면 자유 소프트웨어 관점을 택하고 카피레프트를 고려하세요.

채택을 극대화하는 것이 목표라면 오픈소스 관점과 관대 허용 라이선스가 더 맞을 수 있습니다.

광범위한 협업을 원하면서 개선이 되돌아오길 바란다면 접근성을 위해 오픈소스 언어를 사용하되 결과로서 카피레프트 라이선스를 선택할 수도 있습니다.

비즈니스 모델과 실무 인센티브

자유 소프트웨어가 “누구도 돈을 못 번다”는 뜻은 아닙니다. 사용자가 코드 실행·검토·수정·재배포 권한을 가지는 것이고, 많은 회사가 안정성·책임성·시간 절약 같은 조직이 실제로 비용을 지불하는 것들에 대해 돈을 받으며 건강한 수익을 창출합니다.

기업들이 FOSS로 돈 버는 방식

일부 검증된 모델:

• 지원 및 서비스: 유료 헬프데스크, SLA, 교육, 감사, 맞춤 기능, 마이그레이션 작업
• 호스팅 및 관리형 제공: 편의성·확장성·백업·규정 준수를 제공하는 호스티드 버전 판매
• 이중 라이선싱: 동일 소프트웨어를 자유 라이선스(대개 카피레프트)와 유료 상업 라이선스로 병행 제공
• 오픈 코어(주의 필요): 진정한 무료 기반을 유지하면서 유료 독점 확장 기능을 판매. 작동할 수 있지만 무료 부분이 고의로 제한된 것처럼 느껴지면 커뮤니티 신뢰가 훼손될 수 있음

현대적 변형으로는 Koder.ai 같은 플랫폼들이 빠르게 애플리케이션을 생성·운영하도록 하면서 소스 코드 내보내기를 지원하는 경우입니다. 빠른 반복과 코드 소유권 보장이 결합되면 소프트웨어 자유의 가치—검사하고 변경하고 필요할 때 이동할 수 있는 능력—와 자연스럽게 어울립니다.

관대 허용 vs 카피레프트가 전략에 미치는 영향

라이선스 선택은 누가 가치를 창출하는지를 형성합니다:

• 관대 허용(MIT/Apache): 대규모 벤더도 포함해 타인이 당신의 코드를 사유 제품에 재사용하기 쉬워 채택을 늘리지만 독점적 수익화 가능성은 줄어들 수 있음
• 카피레프트(GPL 등): 하류 재배포자가 수정사항을 공유하도록 요구해 폐쇄적 포크를 억제하고 서비스, 인증 배포판, 이중 라이선싱 같은 비즈니스 모델을 지원할 수 있음

“상업적”과 “자유 소프트웨어”는 반대 개념이 아니다

“상업적”은 판매 방식을 설명하고, “자유 소프트웨어”는 사용자의 권리를 설명합니다. 회사는 자유 소프트웨어를 팔고, 지원 비용을 청구하면서 소프트웨어 자유를 존중할 수 있습니다.

지속가능성 체크리스트

제품 채택·투자를 하기 전에 물어보세요:

• 활발한 커뮤니티가 있는가(이슈, 릴리스, 리뷰)?
• 거버넌스는 명확한가(누가 결정하는가)?
• 자금 조달은 보이는가(스폰서, 기업 후원, 재단)?
• 유지관리자 부담은 지속 가능한가(버스 팩터, 번아웃 신호)?
• 보안 관행은 문서화되어 있는가(패치 주기, 권고)?

GPL과 FOSS에 대한 흔한 오해

GPL과 FOSS는 자주 논의되지만 몇몇 반복되는 신화가 현황을 흐립니다—특히 제품을 안전하게 출시하려는 팀에게 문제가 됩니다.

“GPL은 퍼블릭 도메인”이라는 오해

그렇지 않습니다. 퍼블릭 도메인은 저작권자가 없는 상태로 누구든지 아무 제약 없이 작품을 이용할 수 있는 경우입니다.

GNU GPL은 ‘조건 없는 자유’의 반대입니다. 저작권자가 광범위한 사용·수정·공유 권한을 부여하지만, GPL 조건(특히 바이너리 재배포 시 소스 공개)을 따를 것을 요구합니다.

“오픈소스면 항상 안전하다”라는 오해

코드를 공개하면 보안에 도움이 될 수 있지만 보장을 해주진 않습니다. 오픈소스 프로젝트라 해도:

• 유지되지 않을 수 있고,
• 제대로 검토되지 않을 수 있으며,
• 오랫동안 취약성이 방치될 수 있습니다.

보안은 활성화된 유지관리, 감사, 책임 있는 취약점 공개, 운영 관행에서 옵니다—라이선스 라벨만으로 보장되지 않습니다.

“바이러스성 라이선스”라는 주장

사람들은 종종 GPL을 ‘바이러스성’이라고 부르며 무작위로 모든 것에 퍼진다고 말합니다. 이는 편향된 은유입니다.

대개 의미하는 바는 카피레프트: GPL 코드의 파생작을 배포하면 해당 소스도 GPL로 제공해야 한다는 요구입니다. 이 요구는 의도적입니다: 하류 사용자들의 자유를 보존하려는 것입니다. ‘감염’이 아니라, 수용하거나 다른 코드를 사용해 회피할 수 있는 조건입니다.

“내 앱이나 서비스에 GPL 코드를 써도 되나요?”(개략적)

경험적 규칙: 의무는 주로 배포에 발동합니다.

• 내부 사용: 회사 내부에서 GPL 소프트웨어를 사용하는 것은 보통 변경사항 공개를 요구하지 않습니다.
• 앱/장치 배송: GPL 라이선스된 프로그램(또는 파생물)을 배포하면 일반적으로 소스와 라이선스 고지를 제공해야 합니다.
• SaaS/웹 서비스: 서버에서 GPL 소프트웨어를 실행하는 것은 보통 사용자에게 소스 공개를 강제하지 않습니다(이 공백을 메우기 위해 AGPL이 등장했습니다).

중요할 때는 코드 결합 방식과 배포 방식을 기반으로 정확히 판단해야 합니다—단순한 추측에 의존하지 마세요.

비판, 논쟁, 계속되는 토론들

리처드 스톨만은 논쟁적인 인물입니다. 그 점을 인정하면서도 그와 연관된 아이디어와 라이선스가 남긴 지속적 영향을 논의할 수 있습니다.

유용한 출발점은 두 가지 대화를 분리하는 것입니다: (1) 스톨만 개인과 커뮤니티 구성원으로서의 논쟁, (2) 자유 소프트웨어 원칙, GNU 프로젝트, GNU GPL이 소프트웨어 라이선스와 개발자 권리에 미친 측정 가능한 영향. 두 번째 논의는 사람들이 스톨만 개인을 어떻게 평가하든지 라이선스 텍스트, 프로젝트 역사, 채택 패턴 같은 1차 자료로 논의할 수 있습니다.

거버넌스와 “누가 결정하는가?”

반복되는 비판 중 하나는 라이선스 자체가 아니라 거버넌스 문제입니다: 프로젝트가 결정을 어떻게 내리고, 권한은 누가 가지며, 창립자·유지관리자·사용자가 다르게 원할 때 무슨 일이 발생하는가 같은 문제들입니다. 자유 소프트웨어 커뮤니티는 다음과 같은 질문을 계속 고민해 왔습니다:

• 리더십은 어떻게 선출되거나 교체되어야 하는가?
• 재단은 회원 주도인가, 이사회 주도인가, 유지관리자 주도여야 하는가?
• 언제 유지관리자의 ‘자유’가 기여자의 필요와 충돌하는가?

라이선스는 법적 조건을 제공하지만 건전한 의사결정 체계를 자동으로 만들지는 않습니다.

포용성, 행동 규범, 커뮤니티 기준

또 다른 논쟁은 포용성과 커뮤니티 규범에 관한 것입니다: 프로젝트가 존중 있는 행동을 기대하는지, 갈등을 어떻게 처리하는지, 신참에게 얼마나 환영적인지 등. 어떤 커뮤니티는 형식적 행동 규범을 강조하고, 다른 커뮤니티는 최소한의 규칙과 비공식적 중재를 선호합니다. 어느 접근이 절대적으로 옳다고 할 수는 없지만, 트레이드오프는 분명하고 개인 공격 없이 논의할 필요가 있습니다.

논의를 사실 중심으로 유지하기

스톨만의 유산을 평가할 때는 주장들을 검증 가능한 항목으로 유지하세요: GPL이 무엇을 요구하는지, 카피레프트가 컴플라이언스 관행을 어떻게 바꿨는지, 이러한 아이디어가 이후 라이선스와 기관에 어떤 영향을 미쳤는지. 비판적이든 지지적이든 중립적이든 간결하고 정확한 표현을 목표로 하세요.

실용적 정리: 라이선스 선택과 기여

스톨만이 일상 팀에 준 가장 실용적 선물은 명확한 질문입니다: 하류 사용자가 어떤 자유를 보장받길 원하는가? 그 질문에 답하면 ‘라이선스 선택’이 감성적 결정이 아니라 실질적 결정이 됩니다.

간단한 의사결정 트리

• 타인이(경쟁자 포함) 거의 제약 없이 코드를 재사용하길 원하나요? 관대 허용 라이선스(예: MIT, Apache-2.0)를 선택하세요.
• 배포될 때 개선사항이 계속 공유되길 원하나요? 강한 카피레프트(예: GNU GPL)를 선택하세요.
• 라이브러리 수정에는 공유를 요구하되, 사유 앱이 링크하는 건 허용하고 싶나요? 약한 카피레프트(LGPL, MPL)를 고려하세요.

확실하지 않다면 목표에 따라 결정하세요: 채택(관대 허용) 대 상호호혜(카피레프트) 대 라이브러리 친화적 상호호혜(약한 카피레프트).

책임감 있게 소프트웨어를 배포하기 위한 실무 단계

1. 프로젝트당 하나의 라이선스를 선택해 README에 명확히 표기하세요.
2. 저장소 루트에 LICENSE 파일(라이선스 전문 복사)을 추가하세요.
3. 조직이 요구하는 저작권 헤더를 추가하세요.
4. 핵심 의존성(직접 및 중요한 전이적 의존성)과 그 라이선스를 문서화하세요.
5. 바이너리를 배포한다면 필요한 고지, 소스 제공(또는 제공 방식), 저작권 표기를 준비하세요.

AI 지원 개발(채팅 기반 플랫폼인 Koder.ai 포함)을 사용해 제품을 만들 때 이 체크리스트는 더 중요해집니다: 실제로는 여전히 실존하는 의존성과 산출물을 배포하며 라이선스 의무가 따릅니다. 속도가 책임을 없애지 않으므로 반복 가능한 준수 절차가 더 가치 있습니다.

가벼운 내부 컴플라이언스 절차 만들기

지루하고 반복 가능하게 만드세요:

• 빌드 과정에서 SBOM을 생성하세요.
• notices 파일 템플릿을 두고 의존성 변경 시 업데이트하세요.
• PR/릴리스에 라이선스 검토 체크포인트를 추가하세요(10분짜리 체크리스트라도 유용합니다).

더 깊은 비교는 /blog/choosing-an-open-source-license 및 /blog/gpl-vs-mit-vs-apache를 참조하세요.