카피레프트

소프트웨어가 소스 코드 없이 팔리기 시작하면서 생긴 불편이 출발점입니다. 1980년대에 프로그램이 점점 실행 파일 형태로만 배포됐고, 쓰는 쪽은 눈앞의 문제를 알아도 손댈 수 없게 됐습니다.

당시 자주 나오던 장면이 이렇습니다. 연구실 프린터가 종이가 걸릴 때마다 아무 알림 없이 멈춰 있었습니다. 고칠 줄 아는 사람이 방 안에 앉아 있는데도 드라이버 소스가 없으니 할 수 있는 일이 없었고, 만든 회사에 요청하면 몇 달 뒤에 답이 오거나 오지 않았습니다. 프로그램을 샀을 뿐 고칠 권리를 산 것은 아니었기 때문입니다.

그래서 소스를 함께 공개하자는 움직임이 시작됐는데, 여기서 한 번 더 문제가 드러났습니다. 그냥 공개만 해 두면 누군가 그것을 가져다 조금 고친 뒤 소스를 닫고 팔 수 있었습니다. 공개한 쪽은 자기가 푼 자물쇠가 다시 잠기는 것을 지켜보게 됩니다. 이를 막으려고 고안된 것이 조건을 붙인 공개입니다. 저작권은 원래 복제를 막는 데 쓰이는 권리인데, 그 권리를 근거로 삼아 공개를 강제한다는 점에서 방향이 뒤집혀 있습니다. 이름이 복제 권리를 뜻하는 말의 반대말로 지어진 이유가 여기 있습니다.

저작권을 지렛대로 씁니다. 원칙적으로 남이 쓴 코드는 허락 없이 복제할 수 없고, 라이선스는 그 허락을 조건부로 내주는 문서입니다. 카피레프트 라이선스는 그 조건 자리에 소스를 함께 공개하라는 요구를 넣습니다. 순서는 네 단계입니다.

1. 공개된 코드에 카피레프트 조건이 붙어 있습니다. 대표적인 것이 GPL 계열입니다.
2. 그 코드를 가져다 우리 제품에 넣습니다. 이 시점에 라이선스 조건에 묶입니다.
3. 결과물을 밖으로 배포합니다. 고객에게 설치 파일을 주거나 앱을 내려받게 하는 행위가 여기 듭니다.
4. 배포하는 순간 조건이 발동합니다. 결과물의 소스를 요청하는 사람에게 제공해야 하고, 같은 카피레프트 조건을 그대로 붙여야 합니다.

강도는 하나가 아닙니다. 강한 쪽은 그 코드와 한 덩어리로 묶인 프로그램 전체를 대상으로 잡고, 약한 쪽은 가져다 쓴 라이브러리나 파일 자체를 고쳤을 때만 그 부분을 공개하게 합니다. 약한 쪽을 쓰면 우리가 새로 쓴 코드는 공개 대상에서 빠지므로, 같은 카피레프트라도 제품에 넣어도 되는지가 이 차이에서 갈립니다.

SaaS 형태로 파는 회사가 특히 눈여겨볼 갈래가 하나 더 있습니다. 위의 3번은 파일을 넘기는 것을 배포로 보기 때문에, 서버에서 돌리고 화면만 보여 주는 제품은 조건이 발동하지 않습니다. 이 빈틈을 메우려고 네트워크로 서비스를 제공하는 것도 배포로 보는 라이선스가 따로 나왔습니다. AGPL이 그것이고, 설치 파일을 한 번도 내보내지 않는 회사도 여기에는 걸립니다.

실무에서 이 말이 나오는 자리는 대개 하나입니다. 제품에 들어간 외부 코드 목록을 보다가 카피레프트 라이선스가 발견됐을 때입니다.

대부분은 누가 골라서 넣은 것이 아닙니다. 개발자가 직접 고른 라이브러리는 라이선스를 한 번쯤 보고 들이지만, 그 라이브러리가 다시 끌고 들어온 것들은 아무도 보지 않은 채 따라 들어옵니다. 제품 하나에 외부 코드가 수백 개씩 딸려 오니 손으로 세는 방식은 금방 한계에 부딪힙니다. 그래서 목록을 만들고 조건을 점검하는 라이선스 준수 작업을 도구로 자동화해 두는 회사가 많습니다.

발견된 뒤에 고를 수 있는 선택지는 셋입니다. 같은 기능을 하는 다른 라이브러리로 바꿔 끼우는 방법이 첫째이고, 가장 자주 쓰입니다. 둘째는 만든 쪽에서 돈을 받고 별도 조건으로 파는 상용 라이선스를 사는 것입니다. 같은 코드를 두 조건으로 내놓는 회사가 꽤 있어서, 공개가 곤란하면 계약 실무로 조건을 사는 길이 열립니다. 셋째는 그 코드를 우리 제품과 한 덩어리로 묶지 않고 따로 떨어뜨려 두는 것인데, 어디까지가 한 덩어리인지는 판단이 갈리는 영역이라 법무 검토 없이 결정하기 어렵습니다.

발견이 늦으면 선택지가 줄어듭니다. 이미 1년째 팔고 있던 기능에서 나오면 들어내고 다시 만드는 일정을 그 분기에 끼워 넣어야 합니다. 투자나 인수를 앞두고 실사를 받을 때 이 목록을 요구받는 일도 흔해서, 평소에 만들어 두지 않으면 가장 바쁜 시기에 뒤지게 됩니다.

"이 라이브러리 GPL이라 제품에는 못 넣습니다. 대체재 찾아볼게요."

라이선스 조건이 제품 판매 방식과 맞지 않아 기술 선택을 되돌리겠다는 말입니다.

"내부 도구에만 쓰는 거면 배포가 아니라서 괜찮습니다."

조건이 배포 시점에 발동하므로 사내에서만 돌리는 경우는 해당하지 않는다는 뜻입니다.

"AGPL이면 우리는 SaaS라 오히려 더 조심해야 해요."

네트워크 제공을 배포로 보는 라이선스라 설치 파일이 없어도 걸린다는 지적입니다.

페이지덱에서 이 대화가 처음 나온 것은 문서 변환 기능을 만들 때였습니다. 개발자 태오가 찾은 라이브러리가 성능이 가장 좋았는데 강한 카피레프트 조건이 붙어 있었고, 그대로 넣으면 페이지덱 서버 코드까지 공개 대상이 될 수 있었습니다.

태오는 세 가지를 비교해 대표인 규원에게 가져갔습니다. 성능이 20퍼센트 떨어지는 대체 라이브러리, 상용 조건을 사는 데 드는 연 1,800만 원, 별도 프로세스로 떼어 내는 데 드는 개발 2주입니다. 규원은 첫째를 골랐습니다. 성능 20퍼센트보다 매년 다시 판단할 일을 만들지 않는 쪽이 낫다는 이유였습니다.

카피레프트를 저작권을 포기한 상태로 읽는 경우가 가장 많습니다. 이름이 복제 권리의 반대말처럼 생겼고 코드가 공개돼 있으니 자연스러운 오해입니다. 실제로는 정반대로, 저작권이 살아 있어야만 작동하는 구조입니다. 권리자가 조건을 걸 수 있는 근거가 저작권이기 때문입니다. 포기한 것으로 알고 조건을 지키지 않으면 남는 결과는 저작권 침해입니다.

쓰기만 해도 우리 코드를 공개해야 한다고 보는 것도 흔한 오해입니다. 조건을 센 쪽으로 기억해 두는 편이 안전해 보여서 그렇게 굳습니다. 그러나 조건이 발동하는 시점은 배포입니다. 사내 분석 도구에 넣어 우리끼리만 돌리고 있으면 공개 의무가 생기지 않습니다. 이 점을 모르면 쓸 수 있는 도구를 필요 이상으로 배제하게 되고, 반대로 배포의 범위를 좁게 잡아 두면 고객사에 설치해 주는 형태를 배포가 아니라고 넘기는 사고가 납니다.