오픈소스의 저작권, 그리고 상용 SW 개발자가 반드시 지켜야 할 사항

최근의 이슈에서 알 수 있듯이, 소스코드의 복제와 저작권 침해는 상당히 예민한 주제입니다. 오픈 소스는 그 개념이 쉬운 듯 하면서도, 법적으로 그다지 간단치 않은 면이 많기 때문에 정확한 이해가 필요합니다.
 
그런데 상업적인 소프트웨어를 개발하는 대한민국의 대다수 S/W 개발자 (회사에 근무하는 대부분이 이에 해당합니다)들은 이러한 내용에 대해 자세히 파악하고 있지 못 하는 경우가 많습니다.
 
이번에는 저작권의 시작과 주요 오픈소스 라이선스의 특징, 개발자들이 지켜야 할 것들에 대하여 이야기를 해 볼까 합니다.

 
소프트웨어 저작권의 시작
컴퓨터의 초창기 시절, 사용자가 곧 개발자인 시절이 있었습니다. 컴퓨터 애호가들은 서로가 작성한 코드를 펀치 테이프로 작성하여 나누던 시절입니다. 이 때 소프트웨어의 상품성에 눈을 뜨고 소프트웨어는 돈을 주고 사용해야 한다는 사람이 나타납니다. 그가 바로 빌 게이츠입니다.
 
1976년 빌 게이츠는 친구 폴 앨런과 MITS Altair 8800을 위한 베이식 인터프리터를 만들었고, MITS를 통해 판매하였습니다. 그리고 이 소프트웨어는 동호인들에게 매우 인기가 높았죠.
 
하지만 곧 자신들의 소프트웨어가 복제되어 무상 배포되고 있는 것을 알게 되었고, 빌은 이에 분노하여 유명한 “Open Letter to Hobbyists”를 MITS 뉴스레터를 통해 공개합니다. 이 사건은 소프트웨어의 유료화라는 개념이 등장한 계기로 알려져 있습니다.
 
이에 대해 많은 동호인들은 반감을 표시하거나, 말도 안 되는 소리 등으로 치부하기도 했습니다만 빌은 꿈쩍도 하지 않았죠. 개인용 컴퓨터 시장이 성숙하고 프로 개발자들이 등장함에 따라, 결국 소프트웨어는 돈을 주고 사야 하는 것의 지위를 차지하게 됩니다.

 
[그림 1 : 빌 게이츠의 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 라이선스를 위반하였다는 것이죠. 


[그림 3 : CISCO의 자회사인 LinkSys의 iPhone]

리눅스를 채택한 제품으로 일부 모듈에 대한 소스 공개가 진행되지 않았다는 이유로 소송을 당한 것인데, 사실 이러한 일은 빙산의 일각일 수 있습니다.
 
그 동안 이러한 라이선스와 오픈 소스에 대한 정확한 이해 없이 마구잡이로 사용한 경우가 많기 때문입니다.

그렇다면 개발자와 개발 조직은 어떻게 해야 할까요? 특히 상업성을 가진 대다수의 소프트웨어 회사의 경우 어떻게 해야 하는 걸까요?
 
당연한 이야기지만 공개 되어 있는 소스를 사용하기 전에 반드시 해당 소스의 라이선스 유형을 확인해야 합니다. OSI에 기술되어 있는 라이선스 외에도 매우 많은 종류의 라이선스가 존재합니다. 사실 소스 작성자가 요구하는 것이 곧 라이선스라고 할 수 있는 것이니까요.
 
그리고 개발자들은 주로 사용되는 라이선스들과 그 개념에 대해 충분히 이해하여야 합니다. GPL, LGPL 등의 라이선스가 걸린 소스를 활용하면 어떠한 결과가 오는지에 대해 분명히 알고 있어야 합니다. 개발 편의를 위해 사용하였지만, 회사에 막대한 피해를 끼칠 수도 있기 때문입니다.
 
그리고 개발 조직의 경우 반드시 오픈 소스 사용에 대한 지침을 마련하여야 합니다. 그 지침의 내용이야 조직의 성격 및 사정에 따라 달라 질 수 있는 것이지만, 명백하게 지침을 설정하고 그를 내부 개발자들에게 준수토록 하는 것이 매우 중요합니다.
 
국내에서도 법적 이슈에 민감한 일부 대기업들을 중심으로 오픈 소스 사용에 대한 지침을 만들고, 적용하는 사례가 늘고 있습니다.
 
마치며
오픈 소스는 상업 소프트웨어 개발자에게는 양날의 칼과 같습니다. 잘 이용하면 생산성 및 품질을 높일 수 있습니다. 하지만 반대로 약간의 방심 또는 안이함이 자신의 소프트웨어를 소송의 대상이 되게 할 수도 있습니다.
 
이러한 사태를 막기 위해서는 각각의 개발자는 물론, 조직 전체의 노력이 필수적입니다. 정확한 이해와 판단으로 현명하게 개발하시기를 진심으로 바랍니다.
스마트플레이스의 글을 편리하게 구독하세요. 한RSS 추가 구글추가
크리에이티브 커먼즈 라이센스
Creative Commons License이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

트랙백 (0) | 덧글 (12)
트랙백 주소: http://www.smartplace.kr/trackback_post_99.aspx
스마트플레이스의 트랙백은 스팸방지를 위해 관리자 승인 후 등록됩니다.

dkdk 2007-02-07 09:16:26     답글 삭제
덧붙여보면 GPL이 상업적인 사용을 제한한다는 부분은 오해의 소지가 많습니다. 오히려 GPL은 상업적인 사용을 환영하고 있습니다. 간단히 줄여보면, GPL 라이센스를 따르는 오픈소스 코드는 마음대로 가져다 써도 상관없고 여기다 수정을 가해도 상관없습니다. 단, 이 소프트웨어를 "배포"할 경우에만 그 소프트웨어의 소스코드를 공개하기만 하면 됩니다. 즉, 자사의 소스코드를 공개해서는 안되는 경우에만 GPL 오픈소스 코드를 가져쓰는 것을 피하면 되는 것이죠. 국내 업계의 가장 큰 문제는 오픈소스 코드는 공짜라는 오해의 소지가 많은 인식이며 오픈소스를 잘 아는 업체들도 들키지 않으면 그만(?)이라는 생각을 갖고 있는 경우가 많은 것 같습니다. 이러한 사용자들의 행태는 오픈소스 개발자들의 의욕을 떨어뜨린다는 점에서 심각하게 생각해 보아야 합니다. 상용 프로그램의 저작권을 존중해 주는 것의 일부 만큼이라도 오픈소스 소프트웨어의 저작권을 존중해 주는 사회적 분위기의 형성이 필요합니다.
앤디 2007-02-07 10:45:48     삭제
원칙적으로는 맞는 말씀입니다만 배포할 경우에 소스코드를 공개해야 한다는 점이 상용 소프트웨어 업체에게는 문제가 됩니다. 국내에서 이루어지는 대다수의 SI 프로젝트를 생각해 보죠. 거의 모든 계약서에 산출물에 대한 독점적 권리가 기술되고 있습니다. 일반 패키지 S/W 역시 마찬가지 문제가 있습니다. 자사의 특허가 적용된 제품이라도 GPL이 적용되는 순간 해당 특허를 포기해야 하는 상황이 발생합니다. 이러한 문제 때문에 상용 S/W 업계는 GPL이 적용 된 오픈 소스의 사용을 조심해야 하는 것이죠. 물론 말씀하신대로 들키지 않으면 그만이라는 마인드는 분명히 문제가 있습니다. 정말 써야겠다면 분명하게 GPL을 따르던가, 그럴 수 없다면 쓰지 말던가 하는 엄격한 원칙을 지켜야 합니다. 오픈소스의 저작권 역시 분명히 법의 보호를 받는 것이니까요. 피드백 감사합니다. ^^

curlychoi 2007-02-07 11:25:14     답글 삭제
단 GPL을 따르는 소스를 이용하여 무언가를 개발한다면, 개발된 소프트웨어 역시 GPL 라이선스를 따라야 하며, 소스가 공개 되어야 합니다. 그리고 소프트웨어 자체에 대한 비용을 청구할 수 없으며, 단지 배포를 위한 패키징 비용 정도만 청구가 가능합니다. --------------------- 소프트웨어 자체에 대한 비용을 청구할 수 있는 것으로 알고 있습니다.
앤디 2007-02-07 12:01:09     삭제
소프트웨어 자체에 대한 비용이라는 개념이 중요합니다. http://www.gnu.org/philosophy/selling.html 를 보시면 판매에 대한 GNU의 답변이 있습니다만, 자세히 내용을 살펴 보면 배포와 관련 서비스를 제공하는 것에 대한 비용임을 알 수 있습니다. 즉 배포 비용을 비싸게 청구하는 것도 "자유"이며, 한 명이 구매하면 다른 사람은 복사해서 사용하는 것 역시 "자유"롭습니다. GPL은 "자유"의 제한을 두는 것을 막기 위한 것이기 때문이죠. 일반적으로 소프트웨어를 구매한다고 하는 것은 소프트웨어의 사용권을 구매하는 것이기 때문에, 사실상 이러한 비용은 GPL 하에서는 청구할 수 없는 비용입니다. GPL 하에서는 하나의 카피를 구매한 후, 수십 명이 복사해 사용하는 것 역시 적법한 행동이기 때문이죠. 피드백 감사합니다.
curlychoi 2007-02-07 12:31:13     삭제
제가 잘못알고 있었군요. 감사합니다. ^^

iHWAN 2007-02-07 13:41:59     답글 삭제
그동안 두리뭉실하게 알던걸 정리해주셨군요. 감사합니다. ^^
앤디 2007-02-07 22:14:58     삭제
도움이 되었다니 저도 기분이 좋군요. 감사합니다. ^^

sok 2007-02-07 13:58:36     답글 삭제
인텔 부분에 오해의 소지가 있습니다. 제가 아는한, 소스를 "봤고 개발중에 참조했다는" 이유만으로 저작권 침해가 되지는 않습니다.(저작권 말고 다른 권리라면 모르겠습니다만) 개발된 프로그램이 원소스를 베꼈거나(즉 실질적으로 유사하거나) 아니면 원소스를 개작한 2차적저작물일 때 침해가 됩니다. 물론 별개의 저작물인지 아닌지 여부를 판단하기는 쉽지 않겠지만요. 이런 논의는 오픈소스 전반에 적용이 됩니다. 소스를 분석해서 저작권을 피해가는 방법으로 "독자적" 저작물을 만드는게 가능한거죠. 프리소프트웨어가 저작권 개념에 전적으로 의존하고 있는데, 그 토대는 의외로 허술할지도 모릅니다. 다음글도 참고하세요. http://nomos.tistory.com/15
앤디 2007-02-07 16:59:27     삭제
물론 오픈 된 소스를 "보았다"라는 것 자체가 저작권 침해는 아닙니다만, 고소인이 나름의 판단(리버스 엔지니어링 및 여러 방법으로)을 거쳐 소송을 걸 경우, 그에 대한 디펜스를 준비할 필요가 있다는 뜻입니다. 말씀하신대로 별개의 저작물인지 아닌지 여부를 판단하기가 힘들기 때문에, 거꾸로 말하면 복제하지 않았어도 그 내용을 증명하기 쉽지 않을 수 있는 것이죠. 이렇게 될 경우 소송을 당한 기업 입장에서 금전적, 시간적 낭비가 일어나게 됩니다. 이 점을 악용하면, 단순히 상대방의 제품 출시를 지연시키기 위해서 사용할 수도 있는 것이죠. 이러한 사태를 막기 위해, 첨예한 경쟁이 일어나고 있는 분야에서는 개발 작업 전체를 문서로 기록하고 비디오로 레코딩하는 등의 준비를 통해 경쟁자의 저작권을 침해하지 않았다는 증거를 만드는 경우가 종종 있습니다. 그에 대한 설명을 한 것인데, 제 필력이 모자라다 보니 오해가 생겼군요. 좀 더 명확하게 이해 될 수 있게 기술하도록 노력해 보겠습니다. ^^;

질문입니다 2007-02-07 17:49:12     답글 삭제
최근 법원의 넥슨에 대한 베끼기 행동에 관한 판결문을 본 적이 있습니다
그 판결문에는 공공의 지적 자산 수준으로 베낀정도면 저작권을 행사할 권리가 없다는 듯한 그런 판결을 내렸습니다

만약 공공의 지적 자산 수준의 내용으로만 소프트웨어가 나온다면
그들은 저작권을 어떻게 생각하는지 궁금하네요
앤디 2007-02-07 22:28:35     삭제
소스 공개와는 조금 다른 문제이고, 게임의 시스템과 룩&필의 문제이군요. 사실 이러한 부분은 판단을 내리기 상당히 힘든 문제이긴 합니다. 공공의 지적 자산이란 표현이 참 애매하죠. 하드 블럭과 소프트 블럭에 대해 그런 방식을 적용한 게임은 예전부터 있었으니, 그 방식 자체는 표절이 아니라는 뜻의 판결인데.. 그보다 더 심각하게 느껴지는 표현은 "봄버맨과 같은 게임에서 게임의 전개방식과 플레이 필드 및 아이템의 구성, 게임의 재미를 위한 각종 설정 등을 배열하고 선택하는 데 저작자의 개성있는 표현의 여지가 크다고 볼 수 없다" 라는 부분이군요. 이러한 상상력과 창조력을 깡그리 무시하는 판결이 내려진 것이 슬플 뿐입니다. 법의 판단 기준에 대한 문제니 함부로 뭐라 말하기는 힘들지만 말이죠.
바비 2007-02-08 03:24:00     삭제
관련기사: http://news.naver.com/news/read.php?mode=LSD&office_id=034&article_id=0000344344&section_id=102&menu_id=102

1980년대부터 봄버맨 게임을 해온 사람으로서, 국내 법원의 판결에 동의할 수 없습니다. 허드슨의 봄버맨은 아주 독창적인 게임이며 유사 게임이 거의 없습니다. 그것을 인정하지 않았다는 점은, 중국 법원이 한국 게임의 중국 카피본에 대해 손을 들어주는 것과 동일하다고 생각합니다.

심히 안타까운 일입니다.

이름 비밀번호
홈페이지
덧글
비밀글
RSS 피드
전체글한RSS 추가 구글추가
스마트가젯북스타일
Demo Day