오픈소스 라이선스

인터넷에 올라온 코드를 내려받아 제품에 붙이는 일은 너무 자연스러워서, 한동안은 그것이 허락을 받아야 하는 일이라는 생각 자체가 없었습니다.

공개와 허락이 다른 말이라는 데서 문제가 시작됩니다. 코드를 공개한 사람에게도 저작권은 그대로 남아 있습니다. 저작권은 만든 사람이 자기 표현을 남이 함부로 복제하지 못하게 막는 권리이고, 만든 순간에 자동으로 생겨서 따로 신청하는 절차가 없습니다. 글이나 그림이라면 헷갈릴 일이 없는데, 코드는 눈에 보이게 올라와 있어서 가져가도 된다는 인상을 줍니다. 그래서 쓰는 사람은 허락 없이 복제한 상태에 놓인 채 그 사실을 모르는 일이 잦았습니다.

허락을 받으려면 만든 사람에게 직접 묻는 수밖에 없었습니다. "이 코드 파는 제품에 써도 되나요" 하고 메일을 보내고 답을 기다립니다. 쓰려는 코드가 열 개면 열 통이고, 한 통이라도 답이 없으면 그 자리에서 멈춥니다.

오픈소스 라이선스는 그 답을 미리 적어 두는 방식입니다. 만든 사람이 "이런 조건을 지키면 누구든 써도 된다" 를 문서 한 장에 적어 코드와 함께 올려 두면, 쓰는 사람은 묻지 않고 그 문서만 읽으면 됩니다. 그래서 이 말은 우리가 가진 권리를 지키는 쪽이 아니라, 남의 것을 쓰면서 사고를 내지 않는 쪽에 속합니다.

라이선스는 저작권 위에 얹히는 허락입니다. 저작권이 모든 복제를 기본값으로 막아 두면, 그 위에 라이선스가 "이 조건을 지키는 한 복제하고 고치고 배포해도 된다" 는 예외를 얹습니다. 조건을 어기면 예외가 사라지고 처음의 금지로 돌아갑니다. 라이선스 위반이 약속을 깬 정도로 끝나지 않는 이유가 여기 있습니다.

걸리는 조건은 크게 세 가지입니다.

1. 표시 — 만든 사람의 이름과 라이선스 원문을 제품 어딘가에 남기라는 조건입니다. 가장 흔하고 지키기도 쉽습니다. 설정 화면 맨 아래에 오픈소스 고지 항목을 두고 목록을 싣는 것으로 끝납니다.
2. 공개 — 이 코드로 만든 결과물의 소스도 같은 조건으로 공개하라는 조건입니다. 셋 중 가장 무겁고, 카피레프트라고 부르는 방식이 이쪽입니다.
3. 제한 — 만든 사람의 상표를 제품 이름에 붙이지 말라거나, 이 코드를 두고 특허 소송을 걸면 허락이 끊긴다는 식의 조건입니다.

실제 라이선스는 이 셋을 섞어 쓰고, 조건의 세기로 보면 두 무리로 갈립니다. MIT·Apache 2.0·BSD 는 표시만 요구해서 파는 제품에 넣어도 우리 코드는 닫아 둔 채로 둘 수 있습니다. GPL·AGPL 은 공개까지 요구합니다. 같은 오픈소스라는 이름 아래 이 둘이 섞여 있어서, 이름표를 보지 않고 묶어 다루면 언젠가 센 쪽을 잘못 집게 됩니다.

무거운 조건도 언제 켜지는지가 정해져 있습니다. GPL 의 공개 의무는 그 코드가 들어간 프로그램을 밖으로 내보낼 때 생기고, 회사 안의 서버에서만 돌리면 켜지지 않습니다. AGPL 은 그 구멍을 막은 판이라 사용자가 인터넷으로 접속해 쓰는 것까지 내보낸 것으로 봅니다. 웹으로 파는 제품에 AGPL 코드가 한 줄 들어가면 그 제품의 소스를 요구받을 수 있다는 뜻입니다.

조건이 실제로 걸리는 자리는 세 군데입니다. 코드를 가져오는 순간, 제품을 내보내는 순간, 밖의 누군가가 제품 속을 들여다보는 순간입니다.

1. 가져올 때 — 공개된 코드가 올라와 있는 저장소 최상단에 LICENSE 라는 파일이 있습니다. 코드와 이력이 담긴 그 공간의 첫 화면에서 이름이 보이고, 이름만 확인해도 조건의 세기는 거기서 갈립니다.
2. 내보낼 때 — 표시 조건을 지키는 자리입니다. 앱이라면 설정 화면 안에, 웹이라면 푸터의 링크 뒤에 목록을 둡니다. 새 패키지를 넣을 때마다 이 화면도 같이 갱신해야 하고, 빼먹으면 조건을 어긴 상태로 제품이 나갑니다.
3. 들여다볼 때 — 기업 고객과의 계약 실무나 투자 실사에서 외부 소프트웨어 목록을 문서로 요구받습니다. 목록이 없으면 계약 막바지에 코드를 뒤지게 되고, 공개 조건이 붙은 코드가 거기서 나오면 일정이 통째로 밀립니다. 이 목록을 만들고 유지하는 일을 라이선스 준수라고 부릅니다.

손으로 세는 방식이 금방 한계에 부딪히는 이유는 숫자에 있습니다. 직접 고른 패키지가 마흔 개라도 그 마흔 개가 저마다 다른 패키지를 데려와서 최종 목록은 천 개를 넘기기 쉽고, 데려온 것까지 본 사람은 없습니다.

"이 라이브러리 라이선스 뭐예요? MIT면 그냥 넣고, GPL이면 저 부르고 시작하세요."

관대한 쪽이면 그대로 진행하고 공개 조건이 붙은 쪽이면 다른 방법을 찾자는 뜻입니다.

"이번 배포에 패키지 세 개 늘었는데 고지 화면 목록도 같이 갱신해 주세요."

표시 조건을 지키는 화면이 코드 변경을 따라가지 못하고 있다는 지적입니다.

"실사 자료로 오픈소스 목록 달라는데, 지금부터 만들면 얼마나 걸릴까요?"

평소에 목록을 관리하지 않았다는 고백이고, 이런 상태에서는 대개 며칠이 걸립니다.

페이지덱에서 태오가 문서 편집기의 표 기능을 붙이려고 라이브러리를 하나 고릅니다. 기능은 꼭 맞는데 라이선스가 AGPL 입니다. 웹으로 파는 제품이라 그 코드가 들어가면 소스를 요구받을 수 있어서, 태오는 표시 조건만 붙은 다른 라이브러리를 찾느라 2주를 더 씁니다.

반년 뒤 규원이 기업 고객과 계약을 마무리하며 오픈소스 목록을 요구받습니다. 태오가 남겨 둔 선택 기록과 고지 화면 목록이 있어서 문서는 하루 만에 나갑니다.

공개돼 있으니 공짜고 공짜니까 아무렇게나 써도 된다고 읽는 경우가 가장 흔합니다. 내려받는 데 돈이 한 푼도 들지 않으니 대가가 없다고 느끼기 쉽습니다. 다만 대가를 돈 대신 조건으로 받는 구조라서, 조건을 지키지 않으면 값을 치르지 않고 가져간 것과 같아집니다. 그대로 두면 표시 한 줄이 빠진 제품이 몇 년을 굴러다니다가, 만든 사람이 알아차리는 날 배포를 멈추게 됩니다.

회사 안에서만 쓰면 아무 조건도 안 걸린다는 말도 절반만 맞습니다. 배포하지 않으면 공개 의무가 켜지지 않는다는 설명이 반복되다 보니 사내용이라는 말이 면죄부처럼 쓰입니다. 그런데 사내용으로 만든 도구가 나중에 고객에게 열리는 일이 흔하고, 그 순간 기준이 바뀝니다. 넣을 때와 쓸 때의 기준이 어긋나면 몇 년 치 코드를 다시 훑게 됩니다.