오픈소스 라이선스, 복사해서 쓰기 전에 꼭 알아야 할 것

저는 예전까지 오픈소스를 내려받아 사용하는 일을 그저 편리한 개발 방법 정도로 생각했습니다. 무료로 공개된 코드라면 마음껏 가져다 써도 괜찮다고 여겼고, 프로젝트가 끝난 뒤 출처를 한 번 확인하면 충분하다고 판단했지요. 하지만 어느 날 외부에 배포할 프로그램에 포함된 구성 요소의 라이선스를 확인하다가 생각이 완전히 달라졌습니다. 무료라는 말과 아무 조건 없이 써도 된다는 말은 전혀 같지 않았습니다. 라이선스는 누군가의 호의적인 안내문이 아니라, 사용자가 지켜야 하는 권리와 의무를 적어 둔 약속에 가까웠습니다.

무료와 자유 사용은 같은 뜻이 아니었다

처음 헷갈렸던 부분은 ‘무료’라는 표현이었습니다. 인터넷에서 내려받을 수 있고 비용도 없으니 상업적인 서비스에도 자유롭게 넣어도 된다고 생각했지만, 실제로는 소스 공개, 저작권 표시, 변경 사항 안내처럼 서로 다른 조건이 붙을 수 있었습니다. 특히 회사 이름으로 배포하는 결과물이라면 개인적으로 공부할 때보다 확인할 항목이 훨씬 많아집니다. 저는 라이선스 파일을 읽지 않고 사용한 뒤, 나중에 문제가 생기면 그때 확인하면 된다고 생각했는데, 이미 배포한 파일을 다시 고치는 일은 생각보다 번거롭고 신뢰에도 영향을 줄 수 있었습니다.

제가 겪은 첫 번째 실수

몇 년 전 작은 웹 도구를 만들면서 화면에 아이콘을 넣기 위해 공개 저장소에 있던 자료를 내려받았습니다. 파일 이름만 보고 상업적으로 사용해도 되는 자료라고 판단했지만, 원본 페이지를 다시 찾아보니 아이콘마다 조건이 달랐고 일부는 저작자 표시를 요구하고 있었습니다. 저는 이미 시안을 공유한 뒤라서 사용한 파일을 하나씩 대조하고, 안내 문구를 추가하고, 조건이 맞지 않는 자료는 다른 것으로 교체해야 했습니다. 작업 자체보다 무엇을 어디에서 가져왔는지 기억해 내는 과정이 더 힘들었습니다. 그때부터 저는 내려받는 순간 주소와 라이선스 이름을 간단한 문서에 기록하기 시작했습니다.

자주 만나는 허용 범위의 차이

소프트웨어에서 자주 보이는 MIT 라이선스는 비교적 조건이 단순한 편입니다. 수정하거나 판매하는 것도 허용하지만 저작권 표시와 면책 문구를 남겨야 합니다. Apache 계열은 비슷하게 폭넓은 사용을 허용하면서 특허와 관련된 조항을 더 자세히 다룹니다. 반면 GPL 계열은 해당 코드를 포함해 배포하는 방식에 따라 변경한 부분의 소스 공개가 요구될 수 있어 훨씬 신중하게 살펴야 합니다. BSD 계열도 종류에 따라 문구가 조금씩 다릅니다. 이름만 보고 ‘이건 허용, 저건 금지’라고 외우기보다, 내가 하려는 일이 수정인지 배포인지, 유료 제공인지부터 나눠서 읽는 편이 정확했습니다.

라이선스는 코드뿐 아니라 자료에도 붙는다

저는 한동안 라이선스가 프로그램 코드에만 적용된다고 여겼습니다. 그러나 문서, 글꼴, 이미지, 음악, 아이콘, 예제 데이터에도 각각 이용 조건이 붙을 수 있었습니다. 특히 문서에 실린 예제 문장을 그대로 가져오거나, 공개된 글꼴 파일을 앱에 포함하는 경우에는 코드와 다른 종류의 조건을 확인해야 했습니다. 글꼴은 제작자 표시가 필요한지, 파일을 함께 배포할 수 있는지, 수정한 파일을 같은 이름으로 제공해도 되는지에 따라 처리 방법이 달라집니다. 저는 한 번 이미지 출처만 적으면 끝이라고 생각했다가, 원본 제작자가 요구한 표기 형식까지 다시 확인한 경험이 있습니다. 출처를 남기는 일도 대충 하는 것이 아니라 조건의 일부로 봐야 했습니다.

회사 프로젝트에서 특히 조심할 부분

개인 학습용으로 사용하는 것과 회사 제품에 넣어 고객에게 전달하는 것은 위험의 크기가 다릅니다. 회사에서는 여러 사람이 각자 다른 자료를 가져오기 때문에, 담당자가 바뀌면 사용 조건을 추적하기 어려워집니다. 제가 참여했던 프로젝트에서는 처음에 구성 요소 목록을 만들지 않아 출시 직전에 여러 패키지의 라이선스를 다시 조사해야 했습니다. 일부는 표시 문구만 추가하면 됐지만, 일부는 배포 방식과 맞지 않아 교체가 필요했습니다. 이후에는 이름, 버전, 출처, 라이선스, 수정 여부, 배포 시 필요한 문구를 표 형태로 남겼습니다. 이 기록 하나만으로도 나중에 확인하는 시간이 크게 줄었습니다.

조건을 지키기 위한 현실적인 습관

저는 새로운 자료를 사용할 때 먼저 홈페이지보다 저장소 안의 LICENSE 파일과 공식 문서를 확인합니다. 같은 이름의 구성 요소라도 버전에 따라 조건이 바뀔 수 있어서, 현재 설치된 버전과 안내 페이지의 내용을 함께 기록합니다. 배포 파일에 저작권 표시를 넣어야 한다면 별도 문서나 정보 화면에 모아 두고, 원문을 임의로 줄이지 않습니다. 애매한 문장이 있으면 검색 결과의 짧은 설명만 믿지 않고 원문을 읽거나 회사의 담당자에게 확인합니다. 법률 판단이 필요한 상황에서는 전문가의 검토가 필요하지만, 적어도 무엇을 사용했고 어떤 조건이 붙었는지 정리해 두는 일은 개발자가 직접 할 수 있었습니다.

읽어 보는 습관이 가장 큰 예방책이었다

라이선스 문서는 처음 보면 딱딱하고 비슷한 표현이 반복돼서 쉽게 미루게 됩니다. 저도 예전에는 파일 맨 위에 적힌 이름만 확인하고 넘어갔지만, 실제 문제는 그 아래의 세부 조건에서 생겼습니다. 지금은 사용 목적을 먼저 정리한 다음, 상업적 배포 가능 여부, 표시 의무, 소스 공개 의무, 변경 제한을 차례로 확인합니다. 모든 내용을 완벽하게 외우려 하기보다 사용한 흔적을 남기고, 조건이 불분명한 자료는 다른 선택지를 찾는 방식이 제게 더 잘 맞았습니다. 오픈소스는 누군가가 자유롭게 쓸 수 있도록 내놓은 소중한 자원이지만, 그 자유가 저작자의 권리까지 없앤다는 뜻은 아닙니다. 한 번의 확인과 정확한 표기가 만든 사람에 대한 최소한의 예의이며, 나중에 내가 만든 결과물을 다른 사람이 사용할 때도 지켜지길 바라는 약속이라고 생각합니다.