1. 오픈소스 소개

오픈소스란?

오픈소스(Open Source)는 소프트웨어 혹은 하드웨어의 제작자의 권리를 지키면서 원시 코드를 누구나 열람할수 있도록 한 소프트웨어 혹은 오픈소스 라이선스에 준하는 모든 통칭을 말합니다. 보통 소스가 공개된 소프트웨어를 오픈소스 소프트웨어 라고 하며, 소프트웨어 말고도 개발 과정이나 설계도가 공개되는 경우 하드웨어에도 오픈소스 모델이 적용 가능하며, 글꼴과 같은 데이터에도 오픈소스 개발 모델이 적용되는 경우가 있습니다.

대부분의 오픈소스 소프트웨어는 무료로 사용 가능하기 때문에 프리웨어랑 헷갈리는 경우가 많으나, 프리웨어는 무료로 사용가능한 프로그램이고, 오픈소스 소프트웨어는 소스코드가 공개된 프로그램이기 때문에 다른 개념이라고 볼 수 있습니다. 개발자 입장에서 보면 프리웨어 프로그램을 사용했을때 버그를 발견하거나 새로운 아이디어가 떠올랐다고 해도 소스코드를 모르니깐 수정할수도 없고 프로그램에 적용시킬 수도 없습니다. 하지만 오픈소스SW는 소스가 공개되어 있기 때문에 다른 사람이 이어 받아서 새로 개선해 나가면서 개발됩니다.

오픈소스의 장점

• 오픈소스는 웹상에서 무료로 다운로드및 소스 코드 수정, 재배포가 가능합니다. 따라서 초기 개발을 시작하기 위한 비용이 적게 요구됩니다.
• 오픈소스 커뮤니티는 보통 최신 기술 정보 및 문제점과 해결책을 공유하는 형태로 자유롭게 운영되기 때문에 독점 프로그램에 비해 기술 발전 속도가 빠릅니다.
• 오픈소스는 주로 오픈포맷 또는 표준화 프로토콜을 사용하기 때문에 서로 다른 소프트웨어간 상호 연동성이 보장되는 장점이 있습니다. 오픈소스를 사용하면 상용 프로그램들간의 비호환성을 해결할 수 있습니다.
• 오픈소스의 개발 과정을 볼 때, 전세계에 있는 수많은 우수한 개발자들이 참여하기 때문에 페쇄적으로 개발되는 독점 프로그램에 비해 비교적 안정적입니다.

오픈소스의 단점

• 대부분 사용자들이 Windows 기반의 GUI(Graphical User Interface)를 갖고 있는 어플리케이션에 익숙해져 있어서 Linux 기반의 어플리케이션이 부족합니다. 또한 Linux 기반으로 개발된 어플리케이션들은 Windows 기반의 어플리케이션과 호환되지 않습니다.
• 상용 프로그램에 비해 오픈소스는 체계적인 문서를 가지고 있지 않습니다. 개발하는 과정에서 문서가 없을 경우에 시간이 걸릴 수도 있습니다.
• 오픈소스는 영리를 목적으로 하는 회사에서 개발되는 것이 아니라서 자발적인 참여를 바탕으로 자유롭게 개발됩니다. 그렇기 때문에 독점 프로그램에서 볼 수 있는 로드맵과는 달리 불확실합니다.
• 오픈소스에 기업이 보유한 특허 및 소스코드를 포함시킬 경우 오픈소스 라이선스는 일반적으로 RF 라이선스를 가지고 있습니다. 따라서 RF 라이선스를 원치 않을 경우에는 해당 오픈소스를 사용할수 없습니다. 따라서 오픈소스를 활용하여 특허를 구현하거나 기존 소스 코드를 포함하고자 할 경우에는 반드시 라이선스에 대한 입장을 밝혀야 합니다.

자유 소프트웨어

자유 소프트웨어(Free Software)는 소프트웨어의 이용자에게 해당 소프트웨어를 실행, 복제, 배포할 수 있는 자유, 그리고 소스코드에 대한 접근을 통해서 이를 학습, 수정, 개선시킬수 있는 자유를 부여하는 소프트웨어입니다. 소스코드는 GPL 등의 라이선스를 통하거나, 혹은 드물게 퍼블릭 도메인으로 공개되기도 합니다. 통상 오픈소스 소프트웨어는 자유 소프트웨어를 포함한 넓은 의미로 사용되고 있으며, 국내에서도 자유 소프트웨어를 포함한 오픈소스 소프트웨어를 '공개소프트웨어'로 번역하여 사용하고 있습니다. 하지만 역사 및 추구하는 이념 등에서 자유소프트웨어와 오픈소스 소프트웨어는 미묘한 차이가 있습니다. 자유 소프트웨어는 기술적인 측면 그 자체보다 자유를 훨씬 중요하다고 생각합니다. 자유 소프트웨어가 "자유"라는 이념을 가지기 때문입니다.

2. 오픈소스SW 라이선스

SW 지식재산권

현재 소프트웨어는 다음과 같이 저작권, 상표권, 영업비밀 등의 지식재산권에 의해 보호받고 있습니다.

• 저작권

  저작권(copyright)은 창작물에 대하여 창작자가 취득하는 권리로서 창작의 결과물을 보호 하며, 창작과 동시에 권리가 발생합니다. 따라서 어떤 프로그래머가 특정 SW를 개발하면 컴퓨터 프로그램 저작권이 자동 발생하며, 그 권리는 프로그래머 또는 그가 속한 회사에 부여됩니다. 저작권이 있는 저작물의 경우 누구도 저작권자의 허락 없이는 해당 저작물을 쓸 수 없습니다.

• 특허권

  특허권(patent)은 발명에 관하여 발생하는 독점적/배타적 지배권으로 법에 정해진 절차에 의해 출원을 하여야 하며, 심사를 통해 부여되는 권리입니다. 특허기술을 사용하기 위해서는 반드시 특허권자의 허락을 얻어야만 합니다. 특허 받은 방식을 구현하는 SW라면 프로그래밍 언어나 소스 코드와 상관없이 특허권자의 허락을 받아야 합니다.

• 상표권

  상표권(trademark right)이란 상표권자가 지정상품에 관하여 그 등록상표를 사용할 독점적인 권리로서 일정한 절차에 따라 등록해야 효력이 발생합니다. 이러한 상표를 사용하기 위해서는 반드시 상표권자의 허락을 얻어야만 합니다. 허락받지 않고 상표를 사용할 경우 처벌을 받게 됩니다. 상표권을 취득한 SW의 경우 상표를 사용하려면 상표권자의 명시적인 허락을 받아야 합니다.

• 영업비밀

  공개되지 않는 SW의 경우 영업비밀로서 보호를 받을 수 있으며, 공개된 SW라 하더라도 아이디어에 대한 부분은 영업비밀로 보호를 받을 수 있는 가능성이 있습니다. 단, 영업비밀로서의 SW보호는 널리 공개되어 유통되는 경우에는 보호받기 어렵고, 이를 알지 못하고 사용한 제 3자에게 법적으로 문제를 삼을 수 없습니다.

오픈소스SW 라이선스

오픈소스SW 라이선스란 오픈소스SW 개발자와 이용자 간에 이용 방법 및 조건의 범위를 명시한 계약입니다. 따라서 오픈소스SW를 이용하기 위해서는 개발자가 규정한 라이선스를 지켜야 하며, 이를 위반할 경우에는 라이선스 위반 및 저작권 침해가 발생하고, 이에 대한 책임을 지게 됩니다.

이런 오픈소스SW 라이선스는 기본적으로 이용자의 자유로운 사용을 보장하고 있습니다. 오픈소스SW가 이와 같은 라이선스를 만들어서 운영하는 이유는 오픈소스SW를 이용하여 개발한 SW에 대해서도 법의 테두리 안에서 소스코드를 공개하도록 하기 위한 것입니다.

• 오픈소스SW 라이선스 분포도

오픈소스 라이선스 특징

오픈소스SW 역시 독점소프트웨어와 동일하게 저작권등에 의한 법적 보호를 받고 있으며, 이와 같은 권리에 기반하여 이용자에게 라이선스를 부여합니다. 그러나 오픈소스 라이선스는 일반적인 독점소프트웨어 라이선스와는 많는 점에서 차이가 있습니다. 기본적으로 오픈소스 라이선스는 다음과 같이 사용자의 자유로운 사용, 복제, 배포, 수정을 보장하고 있습니다. 여기서 라이선시(Licensee)는 라이선스를 받는 사람이고, 라이선서(Licencer) 는 라이선스를 부여하는 사람입니다.

• 라이선시는 해당 오픈소스SW를 자유롭게 이용할 수 있습니다.
• 라이선시는 해당 오픈소스SW를 자유롭게 복제할 수 있으며, 일전한 조건하에 재배포할 수 있습니다.
• 라이선시는 해당 오픈소스SW를 자유롭게 수정하여 이용할 수 있으며, 일정한 조건하에 수정된 내용을 재배포할 수 있습니다.
• 라이선시는 해당 오픈소스SW의 소스코드를 자유롭게 획득하고 접근할 수 있습니다.

자세한 내용은 오픈소스SW와 함께 배포되는 라이선스를 통해 알 수 있습니다. 해당 오픈소스SW에 대한 라이선스는 주로 소스코드 내부나 홈페이지 등에 명시되어 있습니다. 소스코드에서는 주로 최상위 디렉토리에 COPYING 이라는 독립된 파일에 라이선스 조항을 기록하기도 하며, 각각의 소스코드 파일 상단에 명시해 두기도 합니다.

이용자가 오픈소스SW 라이선스에서 요구하는 준수사항을 이행하지 않으면 권리자로부터 저작권법 위반(또는 계약 위반)으로 소송을 제기당할 수 있습니다. 패소할 경우, SW 배포는 불가능하며 손해 배상을 포함한 책임을 부담할 수 있습니다. 따라서 라이선스의 의무사항을 명확히 이해하고 소스코드를 사용하면 문제 발생 소지는 거의 없을 것입니다.

따라서 인터넷 상에서 자유롭게 구할 수 있는 오픈소스를 다운로드받아 개발에 적용할 때는 라이선스의 요구 사항을 반드시 확인하여야 합니다. 또한, 자체 판단이 불가능할 경우에는 외부 전문가에게 조언을 의뢰하여 개발 시작 전 해당 라이선스의 요구 사항과 오픈소스 사용 목적을 확실히 분석하여야 합니다. 이렇게 하는 것만으로도 충분히 올바르게 오픈소스를 최대한 활용 할 수 있으며, 나중에 발생할 수 있는 문제들을 사전에 차단할 수 있습니다.

오픈소스SW 라이선스의 구체적 내용

오픈소스 라이선스의 의무사항은 각각의 라이선스마다 조금씩 차이가 있지만 크게 나누어 보면 공통적으로 '저작권 관련 문구 유지', '제품명 중복 방지', '서로 다른 라이선스의 SW 조합시 조합 가능 여부 확인' 등이 있고 선택적으로는 '소스코드 공개, '특허관련 사항 준수' 등이 있습니다.

공통적 준수사항

• 저작권 관련 문구 유지

  저작권이란 표현된 결과물에 대해 발생하는 권리이며 저작물의 창작과 함께 자동적으로 부여됩니다. SW의 경우는 소스코드에 프로그램의 이름과 개발자, 버전, 연락처 등을 포함하고 있는 경우가 많으며 이러한 것들은 저작인격권으로 보호받습니다. 오픈소스SW는 거의 대부분 소스코드 상단에 개발자 정보와 연락처 등이 기록되어 있으며 개발자 정보를 임의로 수정하거나 삭제하여서는 안됩니다. 특히 GPL 등 수정된 결과물을 다시 공개하도록 규정하고 있는 '상호주의(reciprocal)' 라이선스들의 경우 저작인격권으로 보호받기 때문에 소스코드상의 개발자 정보가 수정, 삭제된 채로 외부에 공개되면 저작권 침해문제가 발생할 수 있으므로 주의해야 합니다. 저작권 관련 문구 유지는 쉽게 판단이 가능한 사항이므로 항상 준수하여야 합니다.

• 제품명 중복 방지

  SW의 제품명은 상표권으로 보호받습니다. 따라서 오픈소스SW의 경우에 이와 동일한 이름을 제품명이나 서비스명으로 사용하면 상표권 침해의 문제가 생기게 됩니다. 특히 유명한 오픈소스SW일수록 해당 오픈소스SW의 이름이 상표로 등록되어 있는 경우가 많기 때문에(예: 리눅스) 더욱 조심해야 합니다.

• 서로 다른 라이선스의 조합

  SW를 작성하고자 할 경우 기존에 만들어진 코드를 재사용하거나 결합하는 경우가 많은데, 결합되는 각 코드의 라이선스가 상호 상충되는 경우가 있습니다. 예를 들어 MPL 조건의 A코드와 GPL 조건의 B코드를 결합하여 'A+B' 라는 프로그램을 만들어 배포하고자 하는 경우, MPL은 'A+B'의 A 부분을 MPL로 배포할 것을 요구하는 반면, GPL은 'A+B' 전체를 GPL로 배포할 것을 요구하기 때문에, 'A+B' 프로그램을 배포하는 것은 불가능하게 됩니다. 이러한 문제를 가르켜 라이선스의 양립성(Compatibility) 문제라고 합니다.

  따라서 서로 다른 라이선스로 배포된 오픈소스SW를 결합하는 경우 반드시 두 개의 라이선스가 서로 호환되는지를 확인하여야 합니다. 양립성문제는 자유/오픈소스SW 진영에 심각한 문제점을 제기하였으며, 이를 해결하기 위한 노력도 다양하게 진행되고 있습니다. 예를 들어 모질라 프로젝트(Mozilla.org)에서는 프로젝트의 결과물을 MPL, GPL, LGPL의 3가지(triple) 라이선스로 배포하는 라이선스 정책을 채택하여, 라이선스의 양립성과 관련된 불확실성을 제거하고 모질라 코드를 GPL 또는 LGPL 기반의 응용프로그램에 사용할 수 있도록 하였습니다.

  Trolltech도 Qt 라이브러리에 대한 오픈소스SW 라이선스인 QPL과 GPL의 양립성 문제 를 해결하기 위하여 QPL 및 상용라이선스 이외에 GPL을 추가하는 정책을 취하고 있습니다. 한편 개정된 GPL 3.0은 Apache License 2.0과 양립가능합니다.

선택적 준수사항

• 사용 여부 명시

  많은 오픈소스 라이선스들은 소스코드를 자유롭게 열람하고 수정 및 재배포할 수 있는 권리를 부여하는 한편, SW를 사용할 때 해당 오픈소스SW가 사용되었음을 명시적으로 표기하는것을 의무사항으로 채택하고 있습니다. 이것은 마치 논문을 쓸 때 인용을 하는 것과 비슷하여, '이 SW는 오픈소스SW 인 무엇무엇을 사용하였습니다.' 라는 식으로 사용 여부를 명확히 기술하라는 것입니다. 사용자 메뉴얼이나 기타 메뉴얼을 대체하는 매체가 있다면 그곳에 기술하면 됩니다.

• 소스코드 공개

  오픈소스SW는 라이선스에 따라서 수정하거나 추가한 부분이 있을 때 해당 부분의 소스코드도 공대하여야 한다고 명시하는 경우가 있습니다. 대표적인 라이선스로 GPL이 있습니다. 그러나 정확한 공개 범위는 각각의 라이선스에서 정하고 있는 범위가 다르고, SW를 개발하는 방법에 따라서도 달라질 수 있습니다.

• 특허

  어떤 기술이 특허로 보호될 경우 해당 기술을 구현할 때 반드시 특허권자의 허락을 받아야 합니다. 이 조건은 오픈소스SW 여부와 상관없습니다. 그러나 특허 기술을 오픈소스SW로 구현할 경우 라이선스 때문에 오픈소스SW 관련 특허권 문제는 보다 복잡합니다. 특히 최근 SW특허가 급격히 증가하면서 관련 문제가 심각해지고 있기 때문에 새롭게 만들어지는 오픈소스SW 라이선스들에서는 특허 관련 조항을 포함하고 있는 경우가 많아지고 있습니다.

3. 오픈소스 개발 프로세스

기존 프로젝트 참여하기

오픈소스SW 프로젝트에서는 '공개' 라는 단어가 함축하듯이 여러 명의 개발자가 참여하는 분산 개발, 기존에 공개되어 있는 많은 소프트웨어 자원의 이용, 다양한 부류의 자원자들에 의한 소프트웨어 리뷰및 시험 과정, 기술지원 방법, 기능의 확장, 새로운 프로젝트로의 따른 가지치기 과정 등이 상용 소프트웨어와 달리 매우 중요한 의미를 가지게 됩니다.

어떤 소프트웨어를 개발하고자 하는 사름은 우선 개발하고자 하는 소프트웨어가 가져야할 기능에 대한 충분한 분석을 한 뒤, 이미 존재하는 오픈소스SW 프로젝트들 가운데 주어진 요구 사항을 만족하는것이 있는지 확인합니다. 이 과정에서 요구사항을 모두 충족하는, 또는 충족을 목표로 하는 프로젝트를 성공적으로 발견했다면, 그 사람은 아마도 발견된 프로젝트의 사용자 또는 적극적인 역할을 하는 자원자, 더 나아가 개발자로 오픈소스SW 순환 구조에 참여하게 됩니다.

부분적으로 요구 사항을 만족하는 프로젝트가 발견된 경우에도 기능 추가를 요구하고, 그 요구가 프로젝트 관리자 그룹에서 받아들여짐으로써 순환 구조에 참여가 가능합니다.

반대로, 상용 소프트웨어의 경우에는 주어진 요구사항을 만족하는 타 소프트웨어가 이미 시장에 존재하는 경우, 경쟁력 분석, 자사 관련 제품 라인업, 장기적 제품 로드맵 등을 바탕으로 한 경영적 판단을 거쳐 프로젝트의 진행 여부, 또는 해당 소프트웨어 업체와의 연합, 더 나아가서는 인수, 합병등을 결정합니다.

검색하는 단계에서 유사 프로젝트를 발견하였으나, 기존 프로젝트 관리자 그룹에서 새로운 기능 추가 요청을 받아들이지 않는 경우에는 개발자는 두가지의 선택을 할 수 있습니다. 첫 번째 선택는 검색 단계에서 요구 사앙을 만족하는 프로젝트가 없었던 경우처럼 새로운 프로젝트를 시작하는 방법입니다. 두번째 선택은 직접 기존 프로젝트에 기능을 추가하는 방법입니다. 이를 브랜칭(Branching)이라고 하며, 공개소스 소프트웨어의 경우, 원 소스를 바탕으로 수정되거나, 추가된 소스를 모두 공개한다면, 소스의 사용과 배포가 자유롭기 때문에 아무런 법률적 문제없이 이런 결정을 내릴 수 있습니다.

이런 과정으로 개발된 결과는 원래 소스에 대한 패치 형태로 원래 소스의 개정에 따라가는 형식으로 배포되거나, 원래 소스의 특정 버전을 기점으로 하는 새로운 프로젝트가 되기도 하며, 독자적인 오픈소스SW 순환 구조를 구성하기도 합니다. 프로젝트 브랜칭에는 이전 프로젝트의 결과물을 매우 확고한 프로토타입으로 사용할 수 있다는 점을 제외하고는 새로운 프로젝트의 시작에 버금가는 준비와 여러 가지 선택이 필요합니다.

새로운 프로젝트 만들기

새로운 프로젝트의 경우, 비교적 폐쇄적인 초기 개발 단계를 거쳐, 공개된 뒤에, 커뮤니티와 호흡하는 오픈소스SW 순환 구조에 들어갑니다. 일딴 오픈소스SW 순환 구조에 들어가면, 프로제트 관리자들뿐만 아니라 커뮤니티의 모든 참여자들이 공개된 소스에 접근 가능하며, 기능 추가, 버그 리포트 및 수정, 새로운 기능의 요구 등을 함으로서 지속적인 소프트웨어의 개선이 그 안에서 이루어지게 됩니다.

오픈소스를 활용하기 위해서는 독점소프트웨어와 마찬가지로 반드시 해등 오픈소스의 라이선스에 대한 준수가 필수적입니다. 하지만 오픈소스 라이선스에서 강제하고 있는 내용에 대해서 개발자 및 관리자들의 이해가 아직도 많이 부족한 것이 현실입니다. 자칫 잘못하면 라이선스 위반으로 이미 판매중인 제품을 리콜하거나, 소스코드를 공개해야 하며, 개발중인 제품을 아에 처음부터 다시 개발해야 하는 상황을 초래할 수도 있으므로 체계적인 프로세스를 수립하고 이를 담당할 관련 조직을 구축하는 것이 필요합니다.

개발이 끝난 이후에 오픈소스 라이선스관련 문제가 발견된다면 수정에 많은 시간과 비용이 소요되므로 과제 계획 단계부터 오픈소스 라이선스문제를 고려할 필요가 있습니다. 또한 개발이 진행되면서도 단계별로 준수해야할 사항들을 정의하고 반드시 체크해야만 합니다. 본 문서에서는 이러한 준수 사항에 대해 구체적으로 설명하기 위해 SW개발 프로세스를 다음과 같이 표준화하였습니다.

기획(SW Design) -> 구현(Implementation) -> 검증(Verification) -> 제품화(Production)

1. 기획(SW Design) 단계

우선 해당 과제에 오픈소스를 활용할 것인지의 여부를 판단하여야 하며, 구체적으로 어떤 프로그램을 사용할 지를 판단하여야 합니다. 오픈소스의 특정상 웹상에 여기저기 흩어져 있지만, 쉽게 오픈소스에 관한 정보를 찾을수 있는 사이트들이 따로 존재합니다. 그런 특정 사이트들은 대부분 라이선스별 오픈소스 분류 항목을 두고 있기 때문에 쉽게 해당 프로그램의 라이선스를 확인할 수 있을 것입니다.

기획 단계의 마지막으로 해당 SW부분별로 소스코드 공개가능여부를 판단하여야 합니다. GPL등 소스코드 공개 의무가 발생하는 오픈소스 소프트웨어를 사용할 경우에는 과제 결과물의 소스코드 공개가 요구되기 때문에, 경우에 따라서는 SW 구현 방법을 달리해야되기 때문입니다.

2. 구현(Implementation) 단계

자체 개발한 소스 코드를 공개해도 무방한 경우는 특별히 구현 방법에 신경 쓸 필요가 없습니다. 단, 소스코드를 공개할 경우 회사보유의 지적재산권을 포함시키지 않도록 주의할 필요가 있습니다. 그러나 소스코드 공개를 원하지 않을 경우는 사용하는 오픈소스의 라이선스 강제 사항과 활용하고자 하는 형태에 따라 다양한 경우가 발생할 수 있기 때문에, 이럴 경우는 라이선스 혹은 법률 전문가에게 의뢰하여 정확한 판단을 받아야 할 것입니다.

3. 제품화(Production) 단계

개발이 완료된 후에는 개발 결과물인 소스코드에 대해 실질적인 검증 작업이 필요합니다. 개발 계획서 그 자체로는 라이선스 이슈가 없었더라도 실제 구현 과정에서 개발자가 오픈소스 라이선스에 대한 검증없이 사용한 경우가 있을 수 있기 때문입니다. 최근에는 특정한 소스코드가 오픈소스 코드와 일치라는지를 검증하여 주는 프로그램을 활용하는 사례가 증가하고 있습니다.

4. 검증(Verification) 단계

이 단계에서는 사용된 오픈소스SW들을 라이선스별로 분류하고 각 라이선스에서 준수해야 할 사항들이 실제로 제품에 반영될 수 있도록 하여야 합니다. 앞에서 오픈소스 라이선스 의무사항은 위에 오픈소스 라이선스에 대하여 서술한것을 참조하면 됩니다.

소스코드 공개는 공개 의무가 발생하는 소스코드를 제품을 배포할 때 함께 배포한다거나(예: CD롬 등), 연락처를 기재하고 해당 연락처로 요청하게 한다거나, 혹은 별도의 웹사이트 등에 업로드하여 두고 받아 가도록 하는 등의 방법이 가능합니다.

사용 여부 명시는 해당 의무가 발생하는 소프트웨어에 대한 설명을 사용자 메뉴얼 등에 기재함으로써 이루어지는데, GPL/LGPL/MPL에서 이를 요구하고 있습니다. 이와 같은 경우 오픈소스를 사용하였음을 숨기지 않고 고객에게 그 사실을 정확히 전달할 필요가 있습니다.

참고자료

• http://www.olis.or.kr
• http://wiki.kldp.org/
• http://ko.wikipedia.org/