오픈 소스: 자유, 책임, 그리고 선택

이 생각이 미치는 범위는 프로그래밍 세계에 그치지 않습니다. 누가 기술을 쥐고 있는지, 지식이 어떻게 공유되는지, 개선이 다른 사람에게도 도움이 되는지, 상황이 바뀌었을 때 어떤 선택지가 남는지와 곧바로 이어집니다.

오픈 소스는 모든 것이 무료라는 약속도, 소프트웨어를 유지하는 데 품이 들지 않는다는 약속도 아닙니다. 의도적으로 지키는 것은 특정한 자유입니다. 그 덕분에 누군가 만든 것을 통째로 믿는 대신, 이미 있는 작업 위에 쌓아 올릴 수 있습니다.

그 중요성을 이해하는 가장 빠른 길은 오픈 소스가 무엇인지, 어떻게 발전해 왔는지, 어떤 책임을 함께 가져오는지, 그리고 왜 지금도 많은 사람이 자기 작업을 공개하는지를 아는 것입니다.

소스 코드는 사람이 읽을 수 있는 형태로 쓰인 소프트웨어입니다. 개발자가 프로그래밍 언어로 적은 지시이며, 기계가 실행하는 형태로 바뀌기 전의 모습입니다. 소스 코드에 손이 닿는지 여부가 ‘쓰기만 하는 소프트웨어’와 ‘들여다볼 수 있는 소프트웨어’를 가릅니다. 읽을 수 있는 형태가 없으면 동작을 관찰하는 것 말고는 할 수 있는 일이 없습니다. 읽을 수 있는 형태가 있으면 왜 그렇게 동작하는지, 네트워크로 무엇을 보내는지, 버그가 어디에 있는지, 변경을 어디에 넣어야 하는지를 직접, 또는 맡긴 사람을 통해 확인할 수 있습니다.

오픈 소스는 소프트웨어를 만드는 방식을 설명하는 말도, 우연히 코드가 보이는 상태를 가리키는 말도 아닙니다. 라이선스가 소프트웨어에 부여하는 허락의 조합이며, 그 허락이 갖춰야 할 내용에는 널리 쓰이는 정의가 있습니다.

Open Source Initiative는 그 정의를 관리하고, 어떤 라이선스를 오픈 소스로 볼지를 판단하는 기준으로 사용합니다. 정의가 요구하는 내용은 예를 들어 다음과 같습니다. 소프트웨어를 자유롭게 다시 배포할 수 있어야 합니다. 소스 코드는 실제로 수정하는 프로그래머가 쓰는 형태로 제공되어야 합니다. 수정본과 파생 저작물을 만들어 배포할 수 있어야 합니다. 누가 쓰고 무엇에 쓰는지를 라이선스가 제한해서는 안 됩니다. 그리고 특정 기술이나 인터페이스 방식에 의존하는 부분이 없어야 합니다. 이 정의는 Debian의 지침을 바탕으로 정리되었고, 그래서 ‘오픈 소스’는 느낌이 좋은 말이 아니라 뜻이 정해진 말로 기능합니다.

같은 단어가 두 가지 뜻으로 쓰여 혼동이 생깁니다. 자유 소프트웨어의 ‘자유’는 구속이 없다는 뜻의 자유입니다. 가격이 0이라는 뜻이 아닙니다. 우연히 둘이 겹치는 경우는 있습니다. Apache-2.0은 대가를 요구하지 않으므로 오픈 소스 소프트웨어 상당수는 무료로도 구할 수 있습니다. 그러나 둘은 다른 이야기입니다.

오픈 소스 소프트웨어를 돌리는 데는 시간과 기술과 비용이 듭니다. 호스팅을 준비하고, 업데이트를 적용하고, 보안 문제에 대응하고, 사용자의 질문에 답할 사람이 필요합니다. 라이선스가 요구하지 않는 것은 대가이고, 실제로 필요한 것은 일입니다. 이 둘을 나누어 두면 소프트웨어 선택을 눈을 뜬 상태로 할 수 있습니다.

Apache-2.0이나 MIT 같은 허용적 라이선스는 조건을 가볍게 두고 허락을 줍니다. 소프트웨어를 쓰고, 고치고, 다시 배포할 수 있으며 유료 서비스 안에 넣을 수도 있습니다. 조건은 받은 저작권 표시와 출처 표시를 남기는 것입니다.

GNU GPL 같은 카피레프트 라이선스는 같은 자유를 주되 배포에 조건을 더합니다. 복제본을 배포할 때, 또는 수정본을 배포할 때 그로부터 나온 결과물도 같은 성격의 라이선스를 따라야 합니다. 이렇게 해서 자유가 다음 사용자에게서 사라지지 않게 합니다.

이것은 느슨함과 엄격함의 차이가 아니라, 만든 사람이 무엇을 지키고 싶은지의 차이입니다. 둘 다 오픈 소스 라이선스로 인정받으며, 둘 다 의무를 ‘배포’에 연결합니다. 혼자 쓰는 경우에는 의무가 생기지 않습니다.

라이선스가 주는 것은 허락이고, 능력이 아닙니다. 다른 사업자로 사이트를 옮길 수 있다고 해도 저장소에 접근할 수 있고, 어떤 설정이 쓰이는지 알고, 배포 절차를 이해하지 못한다면 실제로는 옮기지 못합니다.

파일 복제본은 도메인과 호스팅 계정과 빌드 설정이 다른 사람 명의로 되어 있으면 거의 쓸모가 없습니다. 그래서 ‘옮길 수 있습니다’라는 설명은 믿을 것이 아니라 확인할 것입니다. Foundation은 이 둘을 나누어 다룹니다. 허락은 라이선스가 영구히 부여하고, 실제 능력은 저장소와 설정과 자산과 운영 매뉴얼의 구성이 지킵니다.

소프트웨어를 나누는 일은 인터넷보다 오래된 관행입니다. 1950년대와 1960년대에 소프트웨어는 연구 현장과 대형 컴퓨터 주변에서 자랐고, 사용자들은 사용자 모임을 통해 코드를 주고받았습니다. 당시 소프트웨어는 흔히 하드웨어에 딸린 것으로 여겨졌고 독립된 상품이 아니었습니다.

상황은 소프트웨어가 하드웨어와 따로 판매되기 시작하고 사용자가 소스 코드를 받을 기회가 줄어들면서 바뀌었습니다. 1970년대 말에서 1980년대에 걸쳐 프로그램이 저작권으로 보호되는 저작물이라는 점이 제도적으로도 분명해졌고, 소프트웨어는 라이선스 계약에 따라 배포되는 것이 일반적이 되었습니다. 1976년 빌 게이츠가 당시 취미 사용자용 BASIC의 복제에 대해 공개 서한을 낸 것은, 당연하게 여겨지던 공유가 허락 없는 복제로 취급되기 시작했음을 보여 주는 이른 예입니다.

그 뒤에도 공유는 가능했지만 먼저 허락을 받아야 했습니다. 오늘의 오픈 소스는 그 상황에 대한 답입니다. 과거로 돌아가자는 운동이 아니라, 나눌 자유를 합법적이고 믿을 수 있는 형태로 만드는 방법입니다.

1983년 리처드 스톨먼은 GNU 프로젝트를 발표했습니다. 자유롭게 쓰고 살펴보고 고치고 배포할 수 있는 완전한 운영 체제를 만들자는 시도였습니다. 1985년에는 Free Software Foundation을 세우고 GNU 선언문을 썼습니다. 그 문서는 이유를 기술이 아니라 사용자의 자유 문제로 설명합니다.

이 프로젝트는 편집기 Emacs, 컴파일러 GCC, 디버거, 라이브러리, 명령줄 도구 등 지금도 쓰이는 부품을 만들어 냈습니다. 그러나 영향이 가장 큰 것은 라이선스였습니다. 1989년에 첫 판이, 1991년에 제2판이 나온 GNU General Public License는 저작권을 이용해 자유를 보장합니다. 누구나 쓰고 고칠 수 있습니다. 다만 배포하는 수정본은 같은 라이선스를 따라야 합니다. 이 생각을 카피레프트라고 부르며, 자유를 호소에서 법적 조건으로 바꾸었습니다.

1990년대 초까지 빠져 있던 것은 커널, 즉 하드웨어를 제어하는 핵심 부분이었습니다. 그 빈자리를 다른 사람의 작업이 채우게 됩니다.

1991년 리누스 토르발스는 취미로 쓴 커널을 공개하고 다른 사람에게 의견과 개선을 요청했습니다. 이미 있던 GNU 도구와 결합하면서 그것은 완전한 시스템이 됩니다. GNU/Linux라고 부르는 것입니다.

중요한 것은 결과만이 아니라 진행 방식이었습니다. 개발은 인터넷 위에서 공개적으로 이루어졌습니다. 변경은 메일링 리스트로 보내지고 공개된 자리에서 논의되었으며, 받아들일지 여부도 공개적으로 결정되었습니다. 이 방식은 이후 일상의 도구에도 자리를 잡습니다. 버전 관리 시스템 Git은 2005년에 커널 개발을 관리하기 위해 만들어졌습니다.

이 방법으로 본격적인 기반을 만들 수 있다는 것은 쓰이는 모습으로 증명되었습니다. Linux 계열 시스템은 세계 서버의 상당 부분을 움직이고, 휴대전화의 기반이 되었으며, 개인 컴퓨터에서도 쓰입니다. 수정과 재배포의 자유가 있기 때문에 그 작업은 처음 시작한 사람이 없어져도 살펴보고, 조정하고, 이어 갈 수 있습니다.

1998년 1월 Netscape는 브라우저 Navigator의 코드를 공개하겠다고 발표했고, 그해 3월에 코드가 공개되었습니다. Mozilla 프로젝트의 시작입니다. 이 사건은 기업의 관심을 공개형 개발로 돌렸습니다.

같은 해 2월, 자유 소프트웨어에 오래 관여해 온 사람들이 캘리포니아 팔로알토에 모였습니다. 그 자리에서 새 이름인 ‘오픈 소스(open source)’가 선택되었습니다. 같은 가치를 무료라는 오해 없이 전달하기 위해서였습니다. 함께 Open Source Initiative가 세워졌고, 그 정의는 1997년부터 있던 Debian 지침을 바탕으로 정리되었습니다.

왜 새 이름이 필요했을까요. 공개형 개발에는 윤리 논쟁에 관심이 없는 기업도 판단할 수 있는 실용적인 장점이 있습니다. 1998년에 필요했던 것은 그 점을 전하는 일이었습니다.

자유 소프트웨어와 오픈 소스는 흔히 같은 것으로 여겨집니다. 일상의 실무에서는 실제로 거의 같습니다. 둘 다 같은 라이선스를 쓰고, 둘 다 쓰고 고치고 배포할 수 있는 소프트웨어를 만듭니다. 차이는 무게를 어디에 두는지에 있습니다.

자유 소프트웨어의 전통에서 사용자의 자유는 그 자체가 목적이고 윤리 문제로 다루어집니다. 오픈 소스 쪽은 공개형 개발이 더 나은 소프트웨어를 만들고 신뢰하기 쉽다는 실용성에 무게를 두고, 직장에서도 받아들이기 쉬운 말로 이 이름을 씁니다. Apache-2.0은 어느 쪽 입장에서도 인정되며 GNU GPL도 마찬가지입니다.

이 차이는 입장을 가진 사람에게는 실제의 문제입니다. 양쪽 모두에서 영향력 있는 글이 나왔습니다. 다만 소프트웨어를 쓰는 쪽에서 기억할 것은 논쟁이 아니라 실무의 결과입니다. 무엇을 할 수 있고 무엇을 할 수 없는지는 이름이 아니라 그 소프트웨어에 붙은 라이선스가 정합니다.

오픈 소스 프로젝트는 대개 작고 개인적인 사건에서 시작합니다. 누군가 문제에 부딪히고, 그 자리에서 해결책을 쓰고, 같은 문제를 겪는 사람이 더 있다는 것을 알게 됩니다. 배우기 위해서, 자기 일이 쓸모 있기를 바라서, 같은 분야의 사람에게 자기 작업이 인정받아서라는 이유도 자주 나옵니다.

조직의 경우 이유는 더 실무적입니다. 여러 주체가 쓰는 라이브러리는 각 회사가 다시 만드는 것보다 함께 유지하는 편이 비용이 적습니다. 좋은 인재를 끌어들이기 위해서, 자신들이 기대는 표준의 방향에 영향을 주기 위해서, 또는 공적 자금으로 만든 소프트웨어는 누구나 쓸 수 있는 형태여야 하기 때문이라는 이유도 있습니다.

더 넓은 이유도 있습니다. 일부 기반은 한 회사에만 의존하면 건강하지 않습니다. 코드와 라이선스를 공개해 두면 상황이 바뀌어도 그 작업을 다른 사람이 이어 갈 수 있습니다.

처음에 코드를 쓰는 시간은 전체 작업의 아주 일부입니다. 시간의 대부분은 버그 신고를 읽고, 사용자의 질문에 답하고, 의존성을 갱신하고, 보안 문제에 대응하고, 문서를 다시 쓰고, 릴리스를 준비하고, 갱신으로 기존 사용 방식이 깨지지 않게 하는 데 쓰입니다.

많은 사람에게 중요한 프로젝트가 아주 적은 수의 사람에 의해 지탱되는 일도 드물지 않습니다. 한 사람에게 의존하는 상태는 그 사람이 손을 놓으면 작업도 멈춘다는 현실의 위험입니다.

그래서 단순해 보이는 지원이 효과가 있습니다. 분명한 신고는 수정까지 걸리는 시간을 줄입니다. 다른 사용자에게 답해 주는 일은 같은 질문이 반복되는 것을 줄입니다. 자금 지원은 다른 일 사이가 아니라 정해진 시간을 이 작업에 쓸 수 있게 합니다.

오픈 소스 라이선스는 품질 보증을 함께 주지 않습니다. Apache-2.0도 다른 허용적 라이선스와 마찬가지로 소프트웨어는 있는 그대로 제공되며 어떠한 보증도 따르지 않는다고 밝힙니다. 특정 버그를 고치거나 서비스를 제공할 의무를 유지관리자에게 지우지도 않습니다.

그 대신 얻는 것은 스스로 움직일 수 있는 자유입니다. 직접 고치고, 다른 개발자에게 맡기고, 필요에 맞지 않는 부분을 바꿔 끼울 수 있습니다. Foundation도 같은 생각으로 만들어졌기에, 이 페이지는 존재하지 않는 서비스를 약속하지 않습니다.

자유에는 책임이 따릅니다. 어느 판을 쓸지, 언제 갱신할지, 백업을 어떻게 확인할지는 여러분이 정합니다. 지킬 수 없는 약속보다 분명한 선택지가 더 쓸모 있습니다.

가장 도움이 되는 것은 정확한 신고입니다. 무엇을 기대했는지, 실제로 무엇이 일어났는지, 어떻게 재현하는지, 어느 판을 쓰는지가 담겨야 합니다. 개선 제안도 떠올린 해결책만이 아니라 해결하려는 문제를 설명할 때 더 쓸모 있습니다.

문서를 고치거나 번역하는 일은 다음 독자에게 곧바로 닿습니다. 공개된 자리에서 다른 사람의 질문에 답하는 일은 같은 궁금증을 가진 사람을 돕습니다.

기술적인 작업의 경우, 변경을 받아들일지는 프로젝트의 유지관리자가 정합니다. 그것이 자기 복제본을 고칠 자유를 좁히지는 않습니다. 자신의 판을 바꿔 쓰는 일은 언제든 할 수 있습니다.

Apache-2.0은 허용적이고 기업 사이에서 널리 알려져 있으며, 여러분이 만든 것을 공개하라고 요구하지 않습니다. 전 세계에서 유효한 저작권 허락을 무상으로, 비독점적으로, 취소할 수 없는 형태로 줍니다. 받은 판에 대해 주어진 허락은 나중에 거둬들일 수 없습니다.

또한 기여자로부터의 특허 허락이 명시되어 있습니다. 짧은 허용적 라이선스는 특허에 대해 아무 말도 하지 않는 경우가 많고, Apache-2.0은 그 점을 분명히 합니다. 사용자의 독립성을 중요하게 여기는 프로젝트에는 이 명확함이 장점입니다.

조건은 적고 실무적입니다. 소프트웨어나 수정본을 배포할 때는 라이선스 사본을 함께 넣고, 고친 파일에 그 사실을 표시하고, 받은 저작권·특허·상표·출처 표시를 남깁니다.

라이선스가 주는 것은 허락입니다. 일상의 독립성은 훨씬 발에 붙은 것들에 의해 지탱됩니다. 직접 접근할 수 있는 저장소, 타입과 검증이 있는 설정, 파일로 저장된 콘텐츠, 바꿔 끼울 수 있는 자산, 누구나 읽을 수 있는 운영 매뉴얼, 그리고 Provelopment에 묻지 않아도 다른 사람이 실행할 수 있는 공개된 절차입니다.

Foundation은 이 둘이 함께 성립하도록 만들어졌습니다. 허락은 Apache-2.0이 주고, 실제 능력은 프로젝트가 작업을 어떻게 보관하고 어떻게 문서화하는지가 지탱합니다. 무엇을 누가 가지는지에 대한 자세한 내용은 소유권과 이전 페이지에서 따로 설명합니다.

어떤 라이선스도 운영 비용 자체를 없애 주지는 않습니다. 사이트에는 갱신과 점검과 동작 확인이 필요하고, 그것은 여러분 자신이나 여러분이 고른 개발자, 또는 대가를 받는 사업자가 합니다. 그것은 오픈 소스의 결점이 아니라 실제 작업의 모습입니다.