[지디넷코리아]최근의 이슈에서 알 수 있듯이, 소스코드의 복제와 저작권 침해는 상당히 예민한 주제이다. 오픈 소스는 그 개념이 쉬운 듯하면서도, 법적으로 그다지 간단치 않은 면이 많기 때문에 정확한 이해가 필요하다.

그런데 상업적인 소프트웨어를 개발하는 대한민국의 대다수 S/W 개발자 (회사에 근무하는 대부분이 이에 해당한다)들은 이러한 내용에 대해 자세히 파악하고 있지 못 하는 경우가 많다.

이번에는 저작권의 시작과 주요 오픈소스 라이선스의 특징, 개발자들이 지켜야 할 것들에 대하여 이야기를 해 볼까 한다.

소프트웨어 저작권의 시작
컴퓨터의 초창기 시절, 사용자가 곧 개발자인 시절이 있었다. 컴퓨터 애호가들은 서로가 작성한 코드를 펀치 테이프로 작성하여 나누던 시절이다. 이 때 소프트웨어의 상품성에 눈을 뜨고 소프트웨어는 돈을 주고 사용해야 한다는 사람이 나타난다. 그가 바로 빌 게이츠이다.

1976년 빌 게이츠는 친구 폴 앨런과 MITS Altair 8800을 위한 베이식 인터프리터를 만들었고, MITS를 통해 판매하였다. 그리고 이 소프트웨어는 동호인들에게 매우 인기가 높았다.

하지만 곧 자신들의 소프트웨어가 복제되어 무상 배포되고 있는 것을 알게 되었고, 빌은 이에 분노하여 유명한 “Open Letter to Hobbyists”를 MITS 뉴스레터를 통해 공개한다. 이 사건은 소프트웨어의 유료화라는 개념이 등장한 계기로 알려져 있다.

이에 대해 많은 동호인들은 반감을 표시하거나, 말도 안 되는 소리 등으로 치부하기도 했지만 빌은 꿈쩍도 하지 않았다. 개인용 컴퓨터 시장이 성숙하고 프로 개발자들이 등장함에 따라, 결국 소프트웨어는 돈을 주고 사야 하는 것의 지위를 차지하게 된다.

빌 게이츠의 Open Letter to Hobbyists

자유 소프트웨어의 등장과 GPL
그 후 대부분의 소프트웨어 개발사는 자신의 코드를 철저하게 숨기고, 소프트웨어를 상업적으로 판매하게 된다. 이러한 상업적 접근은 시장이 확대되어 감에 따라 더욱 큰 효과를 발휘하였고, 많은 유능한 인재들이 소프트웨어 개발에 참여하게 된다.

그런데 이러한 폐쇄적인 문화에 반발하는 인물이 나타난다. 그가 바로 유명한 리차드 스톨만이다. 자유 소프트웨어 재단의 대표이며 Emacs와 같은 걸출한 에디터를 개발한 사람이다. 그리고 그가 이끌던 GNU 프로젝트가 없었다면, 리눅스는 지금처럼 꽃을 피우지 못 했을 것이다.

그림 2 : 리차드 스톨만

어쨌거나 그는 1989년 첫 버전의 GNU General Public License (GPL)을 발표한다. 소프트웨어의 사용자에게 진정한 자유를 주고자 했던 노력의 산물이라 할 수 있겠다. GPL하에 배포된 소프트웨어를 개작하고, 재배포하는 모든 일이 자유이다.

단 GPL을 따르는 소스를 이용하여 무언가를 개발한다면 개발된 소프트웨어 역시 GPL 라이선스를 따라야 하며 소스가 공개 되어야 한다. 그리고 소프트웨어 자체에 대한 비용을 청구할 수 없으며, 단지 배포를 위한 패키징 비용 정도만 청구가 가능하다.

GPL은 개발자들 간의 공유 정신에 다시금 불을 붙였고, 엄청난 인기를 누리며 오픈 소스 운동의 견인차 역할을 하게 되지만 GPL의 소스 공개 원칙은 대다수 상업용 소프트웨어 개발사들이 참여하지 못하게 하는 장벽이 되기도 했다.

이러한 점 때문에 라이브러리를 위한 Lesser General Public License (LGPL)가 발표된다. 기본적으로는 동일하나 적용 범위가 라이브러리로 국한된다는 점이 가장 큰 차이이다.

즉 GPL이 적용 된 라이브러리를 상용 프로그램 개발에 사용한다면, 해당 프로그램 전체를 공개해야 한다. 하지만 LGPL이 적용 된 라이브러리를 사용하게 되면, 해당 라이브러리만 공개하면 된다. 전체 소프트웨어의 나머지 부분은 공개하지 않아도 되며, 소프트웨어의 비용을 청구할 수도 있다.

다양한 라이선스의 등장
GPL과 리눅스의 발전과 함께 진행 된 오픈 소스 운동의 결과 다양한 오픈 소스 라이선스가 생겨난다.

네오비스님의 글에서도 소개 된 바 있는 OSI (Open Source Initiative) 홈페이지에서 많은 수의 오픈 소스 라이센스를 볼 수 있으며, FSF(Free Software Foundation)의 홈페이지에서 Free Software 라이선스 목록을 볼 수 있다.

그 중에는 상업용으로 사용하여도 어떠한 제한도 없는 경우도 있으며, GPL과 같이 상업적 이용이 제한되는 경우도 있다. 주로 사용되는 라이선스의 예를 들자면 Apache Software License, MIT License, BSD License 등을 들 수 있다.

반대로 매우 엄격한 제한이 걸려 있지만, 소스만 공개되는 경우도 있다. 예를 들자면 Intel은 자사의 일부 소프트웨어 라이브러리 소스를 공개했지만, 소스를 수정하거나 상업적으로 이용하는 것은 금지하고 있다. 개발 테스트 용 정도로만 사용이 가능하고, 상업용 소프트웨어에 적용하려면 별도의 라이선스 계약이 필요한 것이다.

이러한 소스를 보고 사용하는 것은 매우 주의해야 하다. 만약에 해당 소스의 내용을 살펴 본 후, 별 내용이 없어 독자 개발하였다 하더라도, 해당 소스 코드를 사용하였다는 판단에 따라 소송의 대상이 될 수도 있기 때문이다. 이러한 경우 해당 오픈 소스를 보지 않았으며, 개발 중에 참조하지 않았다는 것을 증명해야 한다.

개발자 그리고 개발 조직이 주의해야 하는 것은?
최근 iPhone의 상표권을 주장하며 Apple을 고소한 CISCO가, GPL 위반으로 소송을 당하는 사태가 있었다. iPhone에 탑재 된 소프트웨어가 GPL 라이선스를 위반하였다는 것이다.

CISCO의 자회사인 LinkSys의 iPhone

리눅스를 채택한 제품으로 일부 모듈에 대한 소스 공개가 진행되지 않았다는 이유로 소송을 당한 것인데, 사실 이러한 일은 빙산의 일각일 수 있다.

그 동안 이러한 라이선스와 오픈 소스에 대한 정확한 이해 없이 마구잡이로 사용한 경우가 많기 때문이다.

그렇다면 개발자와 개발 조직은 어떻게 해야 할까? 특히 상업성을 가진 대다수의 소프트웨어 회사의 경우 어떻게 해야 하는 걸까?

당연한 이야기지만 공개 되어 있는 소스를 사용하기 전에 반드시 해당 소스의 라이선스 유형을 확인해야 한다. OSI에 기술되어 있는 라이선스 외에도 매우 많은 종류의 라이선스가 존재한다. 사실 소스 작성자가 요구하는 것이 곧 라이선스라고 할 수 있는 것이니까.

그리고 개발자들은 주로 사용되는 라이선스들과 그 개념에 대해 충분히 이해하여야 하다. GPL, LGPL 등의 라이선스가 걸린 소스를 활용하면 어떠한 결과가 오는지에 대해 분명히 알고 있어야 한다. 개발 편의를 위해 사용하였지만, 회사에 막대한 피해를 끼칠 수도 있기 때문이다.

그리고 개발 조직의 경우 반드시 오픈 소스 사용에 대한 지침을 마련하여야 한다. 그 지침의 내용이야 조직의 성격 및 사정에 따라 달라질 수 있는 것이지만, 명백하게 지침을 설정하고 그를 내부 개발자들에게 준수토록 하는 것이 매우 중요하다.

국내에서도 법적 이슈에 민감한 일부 대기업들을 중심으로 오픈 소스 사용에 대한 지침을 만들고, 적용하는 사례가 늘고 있다.

마치며
오픈 소스는 상업 소프트웨어 개발자에게는 양날의 칼과 같다. 잘 이용하면 생산성 및 품질을 높일 수 있다. 하지만 반대로 약간의 방심 또는 안이함이 자신의 소프트웨어를 소송의 대상이 되게 할 수도 있다.

이러한 사태를 막기 위해서는 각각의 개발자는 물론, 조직 전체의 노력이 필수적이다. 정확한 이해와 판단으로 현명하게 개발하시기를 진심으로 바란다. @

(편집자 주: 이 글은 ZDNET Korea의 전문 블로거인 스마트플레이스에 게재된 글을 옮겨 온 것입니다. 옮기는 과정에서 ZDNET Korea의 편집진이 원문의 친절한 문투를 기사 형식으로 바꾸었음을 알립니다.)