컴퓨터 프로그램 보호론/자유·오픈소스소프트웨어의 발전

리차드스톨만과 자유소프트웨어운동

+/-

1980년대에 들어 PC가 널리 보급되기 시작하면서 이전에는 하드웨어의 부속물로만 간주되던 소프트웨어가 거대한 부가가치산업으로 발전하기 시작하였다. 이러한 흐름과 함께 지적재산권 및 라이센스계약을 통하여 소프트웨어의 사용, 복제, 배포, 수정에 일정한 제한을 가하려는 움직임이 나타나게 된다. 소프트웨어를 둘러싼 이러한 일련의 흐름에 반대하고 소프트웨어의 자유로운 사용, 공유, 수정에 대한 기존의 권리를 지키기 위하여 리차드 스톨만은 자유소프트웨어재단(Free Software Foundation: 이하 'FSF')을 설립하고 자유소프트웨어(Free Software) 운동을 전개하게 된다.

자유소프트웨어는 이용자들이 소프트웨어를 실행, 복제, 배포, 연구, 변경 및 개선할 수 있는 ‘자유’에 관심을 갖는다. 첫째, 어떠한 목적으로든 프로그램을 실행할 수 있는 자유, 둘째, 프로그램이 어떻게 작동하는지를 연구하고 그들의 필요에 맞게 수정할 수 있는 자유. 이를 위해서는 소스코드에 접근할 수 있어야 함이 선행조건이다. 셋째, 주변의 이웃들을 돕기 위해서 복제 및 배포할 수 있는 자유. 넷째, 공동체 전체의 이익을 위해 프로그램을 개선한 후 이를 공중에 공개할 수 있는 자유.

이와 같은 자유를 보증하기 위해 리차드스톨만은 GPL을 만들고, Emacs, gcc, gdb 등 GNU 프로젝트의 주요 결과물들을 GPL로 배포하였다.

상용기업의 참여와 오픈소스소프트웨어

+/-

1990년대 들어서면서 인터넷과 더불어 GPL(General Public License)로 배포된 리눅스가 널리 보급되기 시작하였고, MS의 익스플로러에 밀려 어려움을 겪고 있던 Netscape사가 웹브라우저의 소스코드를 공개하는 결정을 내렸으며, IBM, Sun 등이 자유소프트웨어에 대한 지원을 시작하였다. 한편 자유소프트웨어의 ‘자유Free'라는 단어가 한편으로 ’무료‘라는 의미를 가진다는 점, 엄격한 GPL조항 때문에 소프트웨어기업들이 참여를 꺼려한다는 점 등을 이유로 1998년 Open Source Initiative(이하 ’OSI‘)가 만들어졌다. OSI는 오픈소스소프트웨어로 인정받을 수 있는 9가지 ‘라이센스 조건’을 정의하고, 각각의 소프트웨어에 대한 라이센스를 분석하여 오픈소스소프트웨어라이센스에 해당하는지 여부에 대한 인증을 하고 있다. 주요 내용을 살펴보면, 소프트웨어에 대한 배포 및 수정의 자유를 인정해야 하며 소스 코드를 제공할 수 있어야 할 것, 그리고 어떤 사람이나 그룹 또는 이용분야에 대한 차별이 없어야 한다는 조건 등을 두고 있다. 최근에는 아시아와 유럽을 중심으로 각국 정부에서 미국 중심의 소프트웨어 산업을 극복하고 자국의 소프트웨어 기술 수준 향상 및 산업을 성장시키기 위해 오픈소스소프트웨어에 대한 지원정책을 내놓고 있다.

자유·오픈소스소프트웨어의 특징

+/-

소프트웨어는 비배제성의 특성을 지니고 있기 때문에 무임승차의 문제가 발생하고, 그 결과 지적재산권에 의한 보호가 없다면 이윤을 추구하는 기업들은 소프트웨어 개발에 투자를 하지 않을 것이라는 결론에 도달했었다. 하지만 오픈소스소프트웨어의 비약적인 발전은 이와 같은 ‘이윤’의 동기로서 설명하기가 어려우며, 그와 같은 동기가 있다고 하더라도 사유소프트웨어의 경우보다 약하다.

해커사회에 대한 인류학자로 평가받고 있던 에릭 레이몬드는 오픈소스공동체의 중요한 특성을 ‘기부문화(gift culture)’로 파악하면서, 개인들이 이러한 공동체에 참여하고 있는 동기를 利他主義(altruism)와 相互主義(reciprocity)에서 찾고 있다. 하지만 일련의 경제학자들은 이를 부수적인 요소로 파악하면서, 신호효과(Signaling Effect)를 가장 중요한 동기로 파악하고 있다. 이 때 ‘신호효과’란 어떤 개발자가 중요한 결함 또는 문제를 해결하거나, 성능이 뛰어난 소프트웨어를 개발할 경우, 다른 개발자들이나 사용자들에게 자신의 능력을 알릴 수 있음을 의미한다. 그 결과 향후 높은 보수를 보장하는 좋은 직장을 구하는 등 금전적 이익을 취할 수 있기 때문에 개발자들이 오픈소스공동체에 참여하게 된다는 것이다.

한편 초기의 오픈소스소프트웨어운동과는 달리 현재는 IBM, HP, RedHat, Ximian 등 기업들이 적극적으로 지원하고 있는데, 신호효과만으로는 이들 기업들의 지원동기를 설명하긴 어렵다. 이에 대해 기업들간 약간의 차이가 존재하긴 하지만, 대체적으로 오픈소스소프트웨어와 보완재관계에 있는 하드웨어(IBM, Sony, Nokia 등), 소프트웨어(MySQL AB, IBM, Ximian 등) 및 서비스(RedHat 등)를 판매하기 위한 것으로 설명가능하며, 소프트웨어 개발부문의 효율성 때문에 지원하고 있다는 지적도 있다.

신호효과 또는 보완재판매를 위해 소프트웨어를 개발한다는 사실은 소프트웨어에 대한 지적재산권 보호의 필요성을 약화시킨다. 즉 소프트웨어가 비배제성을 지니고 있음에도 불구하고 자발적 참여에 의해 소프트웨어 생산의 문제가 해결된다는 것이다. 하지만 사유소프트웨어회사가 새로운 제품을 개발함에 따라 얻게 되는 이익과 비교할 때, 오픈소스소프트웨어개발자들이 신제품개발을 통해 얻게 되는 인센티브는 상대적으로 적다. 따라서 매우 혁신적인 신제품의 개발은 오픈소스소프트웨어보다는 사유소프트웨어에 의해 이루어질 가능성이 높다는 지적도 있다.

오픈소스소프트웨어는 운영체제, 서버응용소프트웨어 등 전문가들의 수요가 많은 전문가시장(expert market)을 중심으로 발전해 온 반면, 사유소프트웨어들은 최종소비자용의 응용프로그램분야, 즉 소비자시장(consumer market)에서 많이 개발되었다. 사유소프트웨어회사들은 자사 제품의 잠재적인 수요에 민감하다. 수요가 많은 제품일수록 가치가 높기 때문이다. 따라서 시장조사를 통해 소비자들의 요구사항을 조사하고 이를 제품에 반영하기 위해 노력한다. 소비자시장에 내놓을 소프트웨어를 개발하기 위해서는 소비자들의 기호나 성향을 세밀하게 분석할 필요가 있다. 예를 들어 회계프로그램이나 게임프로그램 등을 개발하기 위해서는 IT 전문가뿐만 아니라 회계 또는 게임에 관한 전문가와의 협력이 필요하다.

사유소프트웨어회사들과는 달리 오픈소스소프트웨어개발자들은 일반적으로 그러한 활동에 참여하려는 경우가 드물다. 오픈소스소프트웨어의 경우 이용자들이 대부분 전문가들이며, 이들은 직접 자신들의 요구사항에 맞게 소프트웨어를 수정할 능력을 가지고 있다. 그 결과 오픈소스개발자들은 이용자들의 요구사항에 덜 민감하게 반응한다. 또한 대규모의 수요가 곧바로 이익으로 연결되지 않기 때문에, 굳이 대규모시장이 있는 제품을 개발할 인센티브를 갖지 않는다. 이에 따라 오픈소스소프트웨어는 운영체계, 파일서버, 웹서버, 메일서버, 개발툴 등 뛰어난 기술이 요구되는 분야에서 유용한 것으로 나타난 반면, 기술보다는 사용의 편리성을 중요시하는 일반 소비자들을 위한 제품부분에서는 상대적으로 미약하였다. 하지만 오픈소스 제품들은 사유소프트웨어개발자들에게는 계속해서 경쟁상의 압력으로 작용할 것으로 보이며, 특히 오픈소스소프트웨어의 생산방법이 기술적 전문가들에게 유용하기 때문에 그러한 압력은 계속해서 지속될 것으로 보인다.

사유소프트웨어는 소스코드를 공개하지 않고 바이너리코드만 배포하기 때문에, 소비자들은 소프트웨어의 버그를 수정하거나 자신들의 특수한 목적에 맞게 개량하는 것이 불가능하다. 반면 오픈소스소프트웨어는 공개된 소스코드를 통해 사용자들이 쉽게 수정할 수 있으며, 개량된 제품을 개발할 수 있다. 또한 이론적으로 오픈소스는 사유소프트웨어보다 ‘프라이버시’보호에 유리하다. 이는 소스코드가 공개되어 있기 때문에 이용자들을 감시할 수 있는 ‘스파이’ 프로그램을 삽입하기 어렵기 때문이다. 하지만 현실적으로 사유소프트웨어회사들이 그러한 행위를 하고 있다는 증거가 있기 전까지는 이론상의 장점으로만 볼 수 있을 뿐이다. 나아가 오픈소스소프트웨어는 대부분 무료로 사용할 수 있기 때문에 소위 ‘정보격차’를 해소하는데 도움이 될 수 있다.

반면 오픈소스의 단점으로는 금전적인 이익을 얻기가 어렵다는 점, 그에 따라 소비자의 기호나 성향을 고려하기가 어렵다는 점, 이용자들이 자유롭게 수정하는 것이 가능하기 때문에 소프트웨어의 ‘분기(fragmentation)’가 일어나 상호 호환되지 않는 프로그램이 개발될 수 있다는 점 등이 지적되고 있다.