(2) GPL과 다른 라이센스들, 변화하는 현실과의 충돌

우리 나라에서 프로그램을 GPL 하에 두고 개발하다보면 필연적으로 만나게 되는 몇가지 문제점들이 있다. 가장 기본적으로는 대한민국에서 GPL을 어디까지 인정해 주느냐에 따른 GPL의 효용성에 대한 의문부터 시작되지만 이 이야기는 긴 주제이니 언젠가 다음에 다루어 보기로 하고, 좀 더 간단한 이야기들을 해 보겠다.

GPL의 최대 장점은 라이센스가 '오픈소스 공동체의 전체적인 발전'을 염두에 두고 있다는 점이다. 한 명의 프로그래머가 할 수 있는 일들은 제한되어 있다. 큰 규모의 조직이 아닌 한 프로그램을 빠른 시간 안에 효율적으로 발전시키기는 쉬운 일이 아니다. GPL은 적은 사람들에 의하여 태어난 프로그램이 어떻게 자신의 생명력을 가지고 집단에 의해 발전할 수 있는가에 대한 하나의 방법을 제시해주고 있다. GPL 프로그램의 DNA는 언제나 공개되어야 하며, 그 DNA가 약간이라도 스며든 프로그램의 DNA또한 완전히 공표되어야 한다.

FSF는 그러한 피드백 구조를 만들기 위한 방법으로 강제성을 택하였다. 여기서 GPL의 몇가지 문제점이 생긴다. 여러 문제점들이 이야기되지만 이러한 문제점들의 가장 아래에는 가장 간단한 이유가 자리하고 있다. GPL은 개인의 창조적 역량을 끄집어 내어 집단과 결합하기에는 최상이지만, 큰 집단이 (특히 영리 목적의) 선택하기에는 유리하지 않은 라이센스이다. 개인의 경우 코딩 자체 또는 기여에서 오는 만족으로 보상효과가 일어난다. 그러나 '투자대비 수익' 으로 모든 것을 계산하는 영리 단체의 경우 법적 강제성을 가지는 GPL은 큰 아킬레스건이 될 수 있다.

기업이 GPL을 꺼리는 이유는 크게 두가지로 정리할 수 있다. 하나는 자사의 프로그램을 GPL로 공개할 경우 발생하며, 다른 하나는 GPL 프로그램의 소스를 자사의 프로그램에 도입할 때 발생한다. 전자의 경우 경쟁사에게 개발 기술을 공개하는 결과를 낳을 수 있고 후자의 경우 이후 모든 프로그램이 GPL 하에서 배포되어야 하는 결과를 가져온다. 그렇지만 공개되어 있는 GPL 프로그램들을 가져다 쓸 경우 많은 개발 경비를 줄일 수 있다는 면에서 많은 기업들은 '암암리에' GPL 프로그램의 소스를 가져다 사용한다. C&P 문화가 팽배한 국내의 경우 GPL에 대한 이해도가 부족한 상황에서 이러한 경우가 빈번하게 발생하고 있는 형편이다. (전문용어로 '안습' 이다)

이제는 완전히 다른 이야기를 해보자. KLDP 10주년 기념 컨퍼런스에서 권순선님은 오픈소스 라이센스에 대한 세션을 발표하였다. 발표의 내용을 정리하면 -

* GPL 의 경우 관련 소스를 포함한 모든 소스가 공개되어야 한다.
* GPL 프로그램에 바인딩되는 프로그램의 경우 독립적인 작동, 또는 통신이 가장 간단한 단계에서의 호출로 이루어지지 않는 한 역시 GPL을 따라야 한다.
* LGPL의 경우 라이브러리 사용시 호출 프로그램이 GPL일 필요는 없다.
* GPL / LGPL 양자 모두의 경우 사용자에게 최종적으로 전달되는 결과물이 프로그램이 아닌 프로그램이 만들어낸 데이터일 경우 원 프로그램 소스를 제공할 의무는 없다.

이러한 점은 네트워크를 통하여 서비스하는 업체에게 굉장히 유리한 조건들을 제시한다. 실제로 구글을 위시한 여러 포탈들에서는 내부적으로 GPL을 포함한 오픈소스를 사용하고 있지만, 그 결과만이 웹페이지 형태로 제공될 경우 소스를 제공하고 있지는 않다.

그런데 이전부터 가지고 있던 몇가지 의문이 있었다.

1. 사용자에게 전해지는 것이 데이터 이상일 경우, 예를 들어 GPL 상에서 제작된 자바스크립트가 사용자에게 전달되어 웹 브라우저에서 해석되면 그것은 GPL에서의 데이터 제공인가, 아니면 프로그램 제공인가? 이 경우 GPL 기반의 AJAX 라이브러리를 사용하는 대부분의 경우 포탈들은 데이터와 함께 프로그램을 제공하고 있는 것인가? 그렇지 않다면 데이터만을 제공하고 있는 것인가.

2,. 이제는 개발하는 입장에서 생각해보자. 내가 개발하는 프로그램이 GPL을 따를 경우, 공개되어 있는 라이브러리를 프로그램 내에 삽입하고 싶은데 그 라이브러리들이 GPL이 아닐 경우에는 어떻게 되는가? GPL 라이센스 프로그램에 GPL 라이센스 프로그램이나 라이브러리를 더하는 것에는 문제가 없지만 MIT나 apache, 또는 BSD 라이센스의 프로그램이나 라이브러리를 더할 경우에는 어떠한 일이 발생하는가?

1번의 경우부터 살펴보자. 이 경우에는 명확한 답이 나와있지 않은 상태이다. 정확히 지적하자면 굉장히 다양한 논쟁의 소지를 가지고 있기 때문에 답이 나오기가 어렵다. 자바스크립트는 실행되기 위해 사용자의 브라우저로 전해진다. 동시에, 자바스크립트는 컴파일 과정을 거치지 않은 이름 그대로 '스크립트' 이기 때문에 소스가 사용자에게 전달되었다고 해석해도 무방하다. 그렇다면 파일의 형태로 링크를 걸어놓은 경우는? 그 경우에도 소스는 분명히 브라우저로 전송되었고, 특별히 경로를 감추지 않는 한 웹페이지 소스를 따라가서 소스 파일을 다운로드 할 수 있다. 압축이나 복호화를 거친 경우는? 별다른 일이 없으면 역으로 풀어내기가 어렵지 않다. 그렇다면 자바스크립트가 다운로드된 상태에서 이미 모든 소스가 전달되었다고 보아도 되는가?

AJAX는 이름이 의미하듯 비동기로 서버와 상호작용한다. 그러면 서버쪽의 소스도 제공해야 하는 것인가? 하지만 서버가 보내주는 것은 말 그대로 '데이터'일 뿐이다. 이 문제는 'AJAX 프레임워크'의 범위를 어떻게 정의하는가에 따라 다른 답이 나올 수 있다. 그래서 정확한 해답을 내기 어렵다. 차후 논쟁의 여지가 생길 수 있는 부분이다.

2번의 경우를 보면, GPL은 GPL 라이센스 아래로 다른 프로그램이 들어오는 것을 특별히 제한하고 있지는 않다. 그렇지만 GPL 코드의 일부가 되면 그 코드는 이전의 라이센스와 상관없이 GPL의 적용을 받게 된다. 여기서 문제가 생기는데, 일반적인 라이센스는 GPL과 상호공존하기가 어렵다. 큰 고려사항 없이 GPL 아래로 들어올 수 있는 코드들은 거의 free코드라고 할 수 있는 MIT 라이센스와 apache라이센스의 일부 뿐이다. 나머지는 쉽게 GPL화 될 수 없다. 일반적인 라이센스는 코드 배포 권리와 코드 수정에 배타적이기 때문이다.

위의 두가지 문제를 생각하고 있다가 KLDP 10주년 기념 컨퍼런스의 오픈소스 라이센스 섹션에서 순선님게 질문을 드렸었다. 그 결과 어느정도 라이센스 문제에 대한 정리가 되었다.

구체적으로 처한 상황은 이렇다. 여러 사람들과 함께 태터툴즈를 개발하고 있다. (언젠가 태터툴즈의 개발과 구성, 개발진들의 의사소통 등에 대하여 설명할 기회가 있을 것이다) 그런데 이번에 편의를 위하여 관리자 화면에 AJAX를 끼워넣을 일이 생겼다. moderation group에서는 직접 라이브러리를 구현하는 것 보다는 널리 사용되는 라이브러리를 사용하는 것이 낫다고 판단하였고 (GPL의 장점이다), 관련하여 라이브러리를 찾던 중이었다.

라이브러리를 선택하는데 있어 다양한 문제들이 있지만, 직접적인 문제는 GPL로 배포되는 태터툴즈의 하위 시스템으로 다른 라이브러리를 끼워 넣었을 경우 그 라이브러리의 라이센스와 태터툴즈의 GPL이 충돌하지 않는가 하는 점이었다. 위와 같은 고민들을 했어야 했고, 고민 끝에 대략의 답을 찾은 듯 싶다.

서비스의 기반이 웹으로 옮겨감에 따라 지금까지와는 전혀 다른 측면에서 GPL 라이센스에 대한 수많은 충돌들이 발생할 것이다. 이러한 경우 어떻게 대처해야 하는가? 미리부터 생각해 보아야 할 일이다.

(궁금하신 분들을 위해 결과만 이야기하자면, 태터툴즈 개발의 요건 중 하나인 'CSS와 자바스크립트를 끈 환경에서도 돌아가야 한다' 는 점 때문에 자바스크립트와 소스를 분리하기 용이하고 multi-form문과 잘 들러붙는 dojo 라이브러리를 선택하게 되었다.)