오픈소스 라이선스

오픈소스 비즈니스 컨설팅
둘러보기로 가기 검색하러 가기

많은 사람들이 오픈소스는 무료로 제공되는 소프트웨어로 알고 있다. 그러나 오픈소스도 일반 상용 소프트웨어처럼 라이선스를 가지고 있고 이에 따른 법적 책임이 따른다. 오픈소스를 확산하고 개인과 기업이 올바르게 사용할 수 있도록 오픈소스 라이선스와 그에 따른 여러가지 제약 및 준수 사항을 정리한다.

소프트웨어의 법적 책임

소프트웨어는 다음과 같이 저작권, 특허권, 상표권, 영업비밀 등의 지적재산권에 의해 보호받고 있다. 다음과 같은 지적재산권에 의해 권리자는 소프트웨어에 대한 배타적인 권리를 가지게 되며, 원칙적으로 권리자만이 소프트웨어를 사용/복제/배포/수정할 수 있다.

저작권

저작권(copyright)은 문학/학술 또는 예술의 범위에 속하는 창작물(저작물)의 창작에 의하여 그 창작물에 대하여 창작자(저작자)가 취득하는 권리로서 창작물의 아이디어를 보호하는 것이 아니라 그 표현(expression)의 결과물을 보호하는 것이다. 저작권은 권리의 발생에 있어 등록과 같은 요건이 필요하지 않고 창작과 동시에 권리가 발생한다(무방식주의). 따라서 어떤 프로그래머가 특정 SW를 개발하게 되면 컴퓨터프로그램저작권이 자동적으로 발생하며, 그 권리는 프로그래머 또는 그가 속한 회사에 부여된다. 저작권이 있는 저작물의 경우 누구도 원 저작자나 저작권자의 허가가 없이는 해당 저작물을 사용/복제/배포/수정할 수 없다.

  • 공표권 : 저작자는 그의 저작물을 공표하거나 공표하지 아니할 것을 결정할 권리를 가진다.
  • 성명표시권 : 저작자는 저작물의 원본이나 그 복제물에 또는 저작물의 공표 매체에 그의 실명 또는 이명을 표시할 권리를 가진다.
  • 동일성유지권 : 저작자는 그의 저작물의 내용·형식 및 제호의 동일성을 유지할 권리를 가진다.
  • 복제권 : 저작자는 그의 저작물을 복제할 권리를 가진다.
  • 공연권 : 저작자는 그의 저작물을 공연할 권리를 가진다.
  • 공중송신권 : 저작자는 그의 저작물을 공중송신할 권리를 가진다.
  • 전시권 : 저작자는 미술저작물등의 원본이나 그 복제물을 전시할 권리를 가진다.
  • 배포권 : 저작자는 저작물의 원본이나 그 복제물을 배포할 권리를 가진다.
  • 대여권 : 저작자는 판매용 음반을 영리를 목적으로 대여할 권리를 가진다.
  • 2차적저작물작성권 : 저작자는 그의 저작물을 원저작물로 하는 2차적저작물을 작성하여 이용할 권리를 가진다.
  • 저 작재산권은 이 관에 특별한 규정이 있는 경우를 제외하고는 저작자의 생존하는 동안과 사망 후 50년간 존속한다.
  • 다만, 저작자가 사망 후 40년이 경과하고 50년이 되기 전에 공표된 저작물의 저작재산권은 공표된 때부터 10년간 존속한다.
  • 공동저작물의 저작재산권은 맨 마지막으로 사망한 저작자의 사망 후 50년간 존속한다.
  • 무명 또는 널리 알려지지 아니한 이명이 표시된 저작물의 저작재산권은 공표된 때부터 50년간 존속한다.
  • 업무상저작물의 저작재산권은 공표한 때부터 50년간 존속한다.
  • 영상저작물 및 프로그램의 저작재산권은 공표한 때부터 50년간 존속한다.
  • 컴퓨터프로그램 보호법(1986년)에서 프로그램저작권
  • 공표권 : 프로그램저작자는 그 프로그램을 공표하거나 공표하지 아니할 것을 결정할 권리를 가진다.
  • 성명표시권 : 프로그램저작자는 프로그램이나 그 복제물 또는 프로그램의 공표를 함에 있어서 실명 또는 이명을 표시할 권리를 가진다.
  • 동일성 유지권 : 프로그램저작자는 다음 각호에 해당하는 경우를 제외하고는 그의 프로그램의 제호·내용 및 형식의 동일성을 유지할 권리를 가진다.
  1. 특정한 컴퓨터외에는 사용할 수 없는 프로그램을 다른 컴퓨터에 사용할 수 있도록 하기 위하여 필요한 범위안에서의 변경
  2. 프로그램을 특정한 컴퓨터에 보다 효과적으로 사용할 수 있도록 하기 위하여 필요한 범위안에서의 변경
  3. 프로그램의 성질 또는 그 사용목적에 비추어 부득이하다고 인정되는 범위안에서의 변경
  • 프로그램저작권의 보호기간
  • 프로그램이 공표된 다음 연도부터 50년간 존속한다.
  • 창작 후 50년이내에 공표되지 아니한 경우에는 창작된 다음 연도부터 50년간 존속한다.
  • 정부 지원 정책
  • 저작권에 문제가 있는 SW는 행정업무용 SW에 선정됐더라도 선정이 취소되고, 저작권 침해 사실이 밝여진 때에는 해당 제품은 물론이고 동일 업체 모두 5년간 행정업무용 SW로 선정되는 것이 사실상 불가능하다
  • 참고 문헌
  • copyleft
  • copyright와는 정반대의 개념
  • 저작물에 대한 권리를 모든 사람이 공유할 수 있도록 한다.
  • 그 저작물을 이용한 자유로운 창작이나 배포가 허용된다는 의미
  • 누군가 자신이 수정한 작업을 배포할 때 이 또한 라이선스 해야 한다는 조건

특허권

특허권(patent)은 발명에 관하여 발생하는 독점적/배타적 지배권으로 법에 정해진 절차에 의해 출원을 하여야 하며, 심사를 통해 부여되는 권리이다. 특허기술을 사용하기 위해서는 반드시 특허권자의 허락을 얻어야만 한다. 특허권자는 자신이 허락하지 않은 사람이 해당 특허를 활용한 제품을 만들거나, 사용하거나, 판매하는 것을 막을 수 있다. 특허는 무엇인가 유용하게 하는 방식(method)이므로 특허받은 방식을 구현하는 소프트웨어라면 프로그래밍 언어가 다르거나 소스코드가 다르더라도 해당 특허권자의 명시적인 허락을 받아야 하며 이는 오픈소스 뿐만 아니라 상용 소프트웨어에도 마찬가지이다.

  • 특허권의 존속기간
  • 특허권의 존속기간은 제87조제1항의 규정에 의한 특허권의 설정등록이 있는 날부터 특허출원일후 20년이 되는 날까지로 한다. <개정 1997.4.10, 2001.2.3>
  • 정당한 권리자의 특허출원에 대하여 제34조 및 제35조의 규정에 의하여 특허된 경우에는 제1항의 특허권의 존속기간은 무권리자의 특허출원일의 다음날부터 기산한다.<개정 1995.12.29>
  • 참고 문헌

상표권

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

  • 상표권의 존속기간
  • 상표권의 존속기간은 상표권의 설정등록이 있는 날부터 10년으로 한다.
  • 상표권의 존속기간은 상표권의 존속기간갱신등록출원에 의하여 10년간씩 갱신할 수 있다. <개정 1993.12.10, 1997.8.22>
  • 참고 문헌

영업비밀

영업비밀(trade secret)이란 공연히 알려져 있지 아니하고 독립된 경제적 가치를 지니는 것으로서 상당한 노력에 의하여 비밀로 유지되는 생산 방법, 판매 방법, 기타 영업 활동에 유용한 비밀유지의무가 있음에도 다른 사람에게 이를 누출하는 경우 처벌받게 된다. 공개되지 않은 SW의 경우 영업비밀로서 보호를 받을 수 있으며, 공개된 SW라 하더라도 아이디어에 대한 부분은 영업비밀로 보호를 받을 수 있는 가능성이 있다. 단, 영업비밀로서의 소프트웨어 보호는 널리 공개되어 유통되는 경우에는 보호받기가 어렵고, 이를 알지 못하고 사용한 제3자에게 법적으로 문제를 삼을 수 없는 한계가 있다.

  • 영업비밀의 존속기간
  • 무기한
  • 참고 문헌

기타

  • 정보 공유 및 국가 개입 관련 법적 근거
세계인권선언 제17조
사람은 누구를 막론하고 단독으로 또는 다른 사람과 공동하여
재산을 소유할 권리를 가진다.
사람은 누구를 막론하고 자의로 재산을 박탈당하여서는 안된다. 

헌법 제10조
모든 국민은 인간으로서의 존엄과 가치를 가지며, 행복을 추구할 권리를 가진다.
국가는 개인이 가지는 불가침의 기본적 인권을 확인하고 이를 보장할 의무를 진다.

헌법 제22조
① 모든 국민은 학문과 예술의 자유를 가진다.
② 저작자·발명가·과학기술자와 예술가의 권리는 법률로써 보호한다.

헌법 제23조
① 모든 국민의 재산권은 보장된다. 그 내용과 한계는 법률로 정한다.
② 재산권의 행사는 공공복리에 적합하도록 하여야 한다.
③ 공공필요에 의한 재산권의 수용·사용 또는 제한 및 그에 대한 보상은 
   법률로써 하되, 정당한 보상을 지급하여야 한다.

헌법 제37조
① 국민의 자유와 권리는 헌법에 열거되지 아니한 이유로 경시되지 아니한다.
② 국민의 모든 자유와 권리는 국가안전보장·질서유지 또는 공공복리를 위하여
   필요한 경우에 한하여 법률로써 제한할 수 있으며, 제한하는 경우에도 
   자유와 권리의 본질적인 내용을 침해할 수 없다.


오픈소스 라이선스 개요

라이선스와 오픈소스

  • 라이선스의 의의
소프트웨어는 지적재산권에 의해 자신이 만든 소프트웨어를 다른 사람이 사용하지 못하게 하고 자신만이 사용할 수 있는 권리를 가지게 되며, 원칙적으로 이러한 권리자만이 소프트웨어를 사용/복제/배포/수정할 수 있다. 하지만 다양한 필요에 의해 이들 권리자가 다른 사람에게 일정한 내용을 조건으로 하여 특정 행위를 할 수 있는 권한을 부여할 필요가 있는데, 이와 같은 권한을 보통 '라이선스(license, 사용허가권)'라고 한다.
  • 라이선스 종류
라이선스 방법은 소프트웨어 벤더가 소프트웨어 판매를 통해 수익을 실현하는 방법을 의미하며 영구 라이선스(Perpetual License)와 기간 라이선스(Subscription License)의 두 가지 방법이 있다.
  • 오픈소스 라이선스
오픈소스 라이선스란 오픈소스 개발자와 이용자간에 사용 방법 및 조건의 범위를 명시한 계약을 말한다. 따라서 오픈소스를 이용하기 위해서는 오픈소스 개발자가 만들어놓은 사용 방법 및 조건의 범위에 따라 해당 소프트웨어를 사용해야 하며, 이를 위반할 경우에는 라이선스를 위반함과 동시에 저작권 침해로 인해서 이에 대한 처벌을 받게 된다.
대표적인 라이선스로는 GPL(General Public License), LGPL(Lesser General Public License), BSD(Berkeley Software Distribution), MPL(Mozilla Public License) 등의 라이선스가 있으며, 이런 오픈소스 라이선스는 기본적으로 사용자의 자유로운 사용/수정/배포를 보장하고 있다.
  • 오픈소스 라이선스의 일반적인 보장
기본적으로 오픈소스SW 라이선스는 다음과 같이 사용자의 자유로운 사용/복제/배포/수정을 보장하고 있다.
  • 라이선스를 받은자는 해당 오픈소스를 자유롭게 사용할 수 있다.
  • 라이선스를 받은자는 해당 오픈소스를 자유롭게 복제할 수 있으며, 일정한 조건하에 재배포할 수 있다.
  • 라이선스를 받은자는 해당 오픈소스를 자유롭게 수정하여 사용할 수 있으며, 일정한 조건하에 수정된 내용을 재배포할 수 있다.
  • 라이선스를 받은자는 해당 오픈소스의 소스코드를 자유롭게 획득하고 접근할 수 있다.


오픈소스 라이선스의 준수 사항

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

  • 공통적 준수 사항
  • 저작권 관련 문구 유지
저작권이란 표현된 결과물에 대해 발생하는 권리이며 저작물의 창작과 함께 자동적으로 부여 된다. 소프트웨어의 경우는 소스코드에 프로그램의 이름과 개발자, 버전, 연락처 등을 포함하고 있는 경우가 많으며 이러한 것들은 성명표시권, 동일성 유지권 등의 저작인격권으로 보호를 받는다.
오픈소스의 경우 거의 대부분의 프로그램 소스코드 상단에 개발자 정보와 연락처 등이 기록되어 있으며 이러한 정보는 저작권의 보호를 받기 때문에 개발자 정보를 임의로 수정하거나 삭제하여서는 안된다. 특히 GPL 등 수정된 결과물을 다시 공개하도록 규정하고 있는 '상호주의(reciprocal)' 라이선스들의 경우 만약 소스코드 상에 개발자 정보가 수정/삭제된 채로 외부에 소스코드를 공개하였다가 그 사실이 밝혀질 경우 저작권 침해문제가 발생할 수 있으므로 주의 하여야 한다. 저작권 관련 문구 유지는 쉽게 판단이 가능한 사항이므로 항상 준수하여야 한다.
  • 제품명 중복 방지
소프트웨어의 제품명은 상표권에 의해 보호받는다. 따라서 오픈소스의 경우에도 이와 동일한 이름을 제품명이나 서비스명으로 사용하면 상표권 침해의 문제가 생기게 된다. 특히 유명한 오픈소스일수록 해당 오픈소스의 이름이 상표로서 등록되어 있는 경우가 많기 때문에(예: 리눅스) 더욱 조심하여야 한다. 다만 이러한 제품명 및 서비스명에 대한 결정이 개발자들에 의해 이루어지는 경우는 많지 않으므로 역시 상식적인 수준에서 판단하면 될 것이다.
  • 서로 다른 라이선스의 조합
소프트웨어를 작성하고자 할 경우 기존에 만들어진 코드를 재사용하거나 결합하는 경우가 많은데, 이러한 경우 결합되는 각 코드의 라이선스가 서로 상충되는 경우가 있다. 예컨대 MPL 조건의 A코드와 GPL 조건의 B코드를 결합하여 'A+B'라는 프로그램을 만들어 배포하고자 하는 경우, MPL은 'A+B'의 A부분을 공개하고 MPL로 배포할 것을 요구하는 반면, GPL은 'A+B' 전체를 공개하고 GPL로 배포할 것을 요구하기 때문에 'A+B' 프로그램을 배포하는 것은 불가능하게 된다. 이러한 문제를 가르켜 라이선스의 양립성(Compatibility) 문제라고 한다. 따라서 서로 다른 라이선스로 배포된 오픈소스를 결합하는 경우 반드시 두개의 라이선스가 서로 호환되는지를 확인하여야 한다.
  • 선택적 준수 사항 (라이선스마다 다름)
  • 사용 여부 명시
많은 오픈소스 라이선스들은 소스코드를 자유롭게 열람하고 수정 및 재배포할 수 있는 권리를 부여하는 한편, 소프트웨어를 사용할 때 해당 오픈소스가 사용되었음을 명시적으로 표기하는 것을 의무사항으로 채택하고 있다. 이것은 마치 논문을 쓸 때 인용을 하는 것과 비슷하여, '이 SW는 오픈소스인 무엇 무엇을 사용하였습니다.'라는 식으로 사용 여부를 명확히 기술하라는 것 이다. 사용자 매뉴얼이나 기타 매뉴얼을 대체하는 매체가 있다면 그곳에 기술하면 된다.
  • 소스코드 공개
오픈소스는 라이선스에 따라서 수정하거나 추가한 부분이 있을 때 해당 부분의 소스코드도 공개하여야 한다고 명시하는 경우가 있다. 대표적인 라이선스로 GPL이 있다. 그러나 정확한 공개 범위는 각각의 라이선스에서 정하고 있는 범위와 소프트웨어를 개발하는 방법에 따라서도 달라질 수 있다.
  • 특허
특허에 대한 기본적인 내용은 만약 어떤 기술이 특허로 보호될 경우 해당 기술을 구현할 때 반드시 특허권자의 허락을 받아야 한다는 것이다. 이러한 조건은 오픈소스의 여부와 상관없이 모든 소프트웨어에 공통적으로 해당된다. 그러나 어떤 특허를 오픈소스로 구현할 경우 해당 특허의 구현 결과는 오픈소스 라이선스를 따라야만 하는 문제 등 오픈소스와 관련된 특허권의 문제는 보다 복잡하게 전개된다. 특히 최근 소프트웨어 특허가 급격히 증가하면서 이와 관련된 문제가 심각해지고 있기 때문에 새롭게 만들어지는 오픈소스 라이선스들에서는 특허 관련 조항을 포함하고 있는 경우가 많아지고 있다.


오픈소스 라이선스 주요 쟁점

  • 소스코드 공개 여부
앞에서 GPL/LGPL/BSD/MPL/아파치 라이선스 등 많이 사용되는 라이선스들을 간략히 살펴보았는데 이중에서 GPL/LGPL/MPL 등은 수정한 내용에 대한 소스코드를 공개하여야 하지만 BSD/아파치 라이선스 등은 수정하더라도 소스코드를 공개할 의무가 발생하지 않는다. GPL/LGPL/MPL 등 소스코드 공개의무가 발생하는 라이선스는 상호주의(reciprocal) 혹은 Copyleft 라이선스라고 하며, 그 결과물이 원 소프트웨어의 소스코드를 이용하였을 경우 소스코드를 공개해야 한다. 그런데 소스코드의 공개범위를 기계적으로 판단할 수 있는 방법은 없으며 라이선스마다 서로 다르게 정의하고 있으므로 잘 판단하여야 한다.
  • 특허권
GPL/LGPL/MPL/아파치 라이선스 등의 오픈소스 라이선스는 특허와 관련된 조항들을 가지고 있는데, 각각의 경우를 라이선서(Licensor)의 특허인 경우, 라이선시(Licensee)의 특허인 경우, 제3자의 특허인 경우로 구분하여 설명할 수 있다. 다만 LGPL은 특허와 관련해서는 GPL과 동일하게 규정하고 있고, BSD는 특허에 관한 규정을 두고 있지 않기 때문에 생략한다.
  • 라이선서(Licensor)의 특허인 경우 (저작권자가 특허권자인 경우)
오픈소스에 대해 저작권을 가지고 있는 주체가 특허권을 함께 가지고 있는 경우이다.
MPL과 아파치 라이선스는 라이선서가 소프트웨어를 오픈소스 라이선스로 배포하는 경우 관련 특허권의 라이선스도 무상으로 제공하는 것으로 규정하고 있다. GPL의 경우에는 명문으로 규정하고 있지 않지만 대체적으로 관련 조문(제7조 등)의 해석상 묵시적인 라이선스를 제공하는 것으로 보고 있다. GPL 3.0에서는 단순 재배포자를 제외한 개발자 및 기여자(Contributor)의 경우 자신이 기여한 부분과 관련된 특허권 라이선스를 무상으로 제공하는 것으로 규정하고 있다. 한가지 주의하여 야 할 것은 특허권 그 자체는 여전히 유효하다는 것이다. 예를 들면 특허권자가 특허받은 정렬 알고리즘을 GPL로 배포하는 리눅스에 로열티 없이 사용 가능하도록 제공한다고 할지라도 독점 라이선스인 MS 윈도우즈에는 해당 정렬 알고리즘을 사용토록 허가하면서 여전히 로열티를 받을 수 있다.
  • 라이선시(Licensee)의 특허인 경우 (이용자가 특허권자인 경우)
오픈소스SW를 사용하는 이용자가 특허권을 가지고 있는 경우이다.
MPL의 경우 이용자가 자신의 특허권을 그냥 사용하는 경우에는 아무런 문제가 없지만, 만약 이용자가 MPL로 배포된 프로그램을 사용하던 중 자신의 특허권을 근거로 소송을 제기하게 되면, 적절한 시일 내에 소송을 철회하지 않는 한 라이선스가 종료된다. 따라서 MPL로 배포된 프로그램 사용자는 그 결과 MPL로 배포된 프로그램을 더 이상 사용할 수 없거나, 그 동안 사용했던 부분에 대하여 로열티 산정을 하는 등 일정한 보복이 가해진다. 아파치 라이선스 2.0도 MPL과 비슷한 취지의 조항을 추가하였으며, GPL 3.0에서도 관련 내용이 추가되었다.
  • 제3자의 특허인 경우
특허권자와 이를 프로그램으로 구현한 주체가 다른 경우이다.
특허권자가 무상(Royalty-Free) 조건의 특허 라이선스를 허용하지 않는다면 구현자는 이 프로그램을 GPL 조건으로 배포할 수 없다(GPL 제7조). 예를 들면 甲회사가 乙회사의 특허기술을 바탕으로 A라는 프로그램을 만들었을 경우, 乙회사가 그 특허를 모든 사람에게 무상으로 허용하지 않는다면, 甲회사가 라이선스를 무료로 받았다고 할지라도 A프로그램을 GPL 조건으로 배포할 수 없다. 나아가 GPL 3.0에서는 제3자인 특허권자가 이용자들을 차별하여 라이선스를 부여하는 것을 막기 위한 조항이 삽입 되었다. MPL은 제3자의 특허인 경우에도 일단 배포는 허용하되, 'LEGAL'이라는 이름의 파일을 추가하여 어떠한 특허가 문제되고 있는지, 어떤 사람이 문제나 이의를 제기하고 있는지에 대한 사항을 자세히 기록하도록 하고 있다.
  • 라이선스의 양립성
소프트웨어를 작성하고자 할 경우 기존에 만들어진 코드를 재사용하거나 결합하는 경우가 많은데, 결합되는 각 코드의 라이선스가 상충되는 경우가 있다. 따라서 어떤 오픈소스에 다른 오픈소스를 결합할 경우 반드시 두개의 라이선스가 서로 양립하는지를 확인하여야 한다.
  • 듀얼 라이선스
일부 오픈소스는 상업용 라이선스와 오픈소스 라이선스 또는 오픈소스 라이선스들을 조합하여 해당 프로그램을 배포하는 경우가 있다. 이를 주로 듀얼 라이선스(dual license)라고 하며, 이런 경우는 주로 오픈소스를 상업적 목적으로 이용할 뿐만 아니라 오픈소스 커뮤니티와의 협력을 위한 경우가 대부분이다. 하나 이상의 라이선스가 있는 오픈소스를 이용할 경우, 이용자는 사용 목적에 가장 잘 부합하는 라이선스 하에 배포되는 소스코드를 선택할 수 있다. 대표적인 사례로는 MySQL, Trolltech의 Qt 라이브러리 등이 있다.


  • Patentleft


오픈소스 라이선스 관련 용어

대부분의 오픈소스 라이선스 문서는 영어로 되어 있어 대한민국 사람이 오픈소스를 활용하는데 있어서 법적인 어려움을 겪고 있다. 이를 한글로 번역하여 오픈소스의 사용의 편의를 돕고자 하는데 이를 위해 오픈소스 라이선스를 번역함에 있어 필요한 한글 용어를 저작권법과 컴퓨터프로그램 보호법 등 관련 법규를 참조하여 아래에 정의한다.
오픈소스 라이선스의 한글 문서는 법적인 효력이 없으므로 영문으로된 오픈소스 라이선스를 이해하는데 참고로만 하기 바라며, 비즈니스 적으로 활용하기 위해서는 법적 자문을 받아 불이익을 받는 경우가 없도록 하여야 한다.

영문 용어
한글 용어
용어 설명
works 저작물
  • 인간의 사상 또는 감정을 표현한 창작물을 말한다.
  컴퓨터프로그램저작물
  • 특정한 결과를 얻기 위하여 컴퓨터 등 정보처리능력을 가진 장치(이하 "컴퓨터등"이라 한다) 내에서 직접 또는 간접으로 사용되는 일련의 지시·명령으로 표현된 것을 말한다.
delivative works 2차적저작물
  • 원저작물을 번역·편곡·변형·각색·영상제작 그 밖의 방법으로 작성한 창작물(이하 "2차적저작물"이라 한다)은 독자적인 저작물로서 보호된다.
  편집물
  • 저작물이나 부호·문자·음·영상 그 밖의 형태의 자료(이하 "소재"라 한다)의 집합물을 말하며, 데이터베이스를 포함한다.
  편집저작물
  • 편집물로서 그 소재의 선택·배열 또는 구성에 창작성이 있는 것을 말한다.
  공동저작물
  • 2인 이상이 공동으로 창작한 저작물로서 각자의 이바지한 부분을 분리하여 이용할 수 없는 것을 말한다.
licensee 저작자
  • 저작물을 창작한 자를 말한다.
reproduction
copying 		복제
  • 인쇄·사진촬영·복사·녹음·녹화 그 밖의 방법에 의하여 유형물에 고정하거나 유형물로 다시 제작하는 것을 말하며, 건축물의 경우에는 그 건축을 위한 모형 또는 설계도서에 따라 이를 시공하는 것을 포함한다.
  • 프로그램을 유형물에 고정시켜 새로운 창작성을 더하지 아니하고 다시 제작하는 행위를 말한다.
distribution 배포
  • 저작물등의 원본 또는 그 복제물을 공중에게 대가를 받거나 받지 아니하고 양도 또는 대여하는 것을 말한다.
  • 원프로그램 또는 그 복제물을 공중에게 대가를 받거나 받지 아니하고 양도 또는 대여하는 행위를 말한다.
propagation 발행
  • 저작물 또는 음반을 공중의 수요를 충족시키기 위하여 복제·배포하는 것을 말한다.
  • 공중의 수요에 응하기 위하여 프로그램을 복제·배포하는 행위를 말한다.
  • 저작권자의 허가를 받지 않고 어떠한 행위를 하는 경우 저작권을 위반하게 되는 모든 행위 (by GPL 3.0)
  • 하나의 컴퓨터에서 단순 실행하거나 개인적으로 복제 또는 수정하는 것은 제외
transfer 전송
  • 공중이 수신하거나 이용할 수 있도록 하기 위하여 정보통신의 방법에 의하여 프로그램을 송신하거나 이용에 제공하는 행위를 말한다.
convey 공표
  • 저작물을 공연, 공중송신 또는 전시 그 밖의 방법으로 공중에게 공개하는 경우와 저작물을 발행하는 경우를 말한다.
  • 프로그램을 발행하거나 이를 공중(공중)에게 제시하는 행위를 말한다.
  • 제3자가 복사본을 제작하거나 받을 수 있도록 가능케 해주는 모든 종류의 프로퍼게이트 행위 (by GPL 3.0)
  • 컴퓨터 네트워크를 통해 사용자와 상호작용하는 것은 컨베이가 아님
modification 개작
  • 원프로그램의 일련의 지시·명령의 전부 또는 상당부분을 이용하여 새로운 프로그램을 창작하는 행위를 말한다.
  권리관리정보
  • 다음 각목의 1에 해당하는 정보 또는 그 정보를 나타내는 숫자나 부호로서 원프로그램 또는 그 복제물에 부착되거나 그 실행 또는 전송에 수반되는 것을 말한다.
가. 프로그램저작물에 관한 정보
나. 프로그램저작물의 저작자 및 권리자를 식별하기 위한 정보
다. 프로그램저작물의 사용방법 및 조건에 관한 정보
  온라인서비스제공자
  • 다른 사람들이 정보통신망(「정보통신망이용촉진 및 정보보호 등에 관한 법률」 제2조제1항제1호의 정보통신망을 말한다. 이하 같다)을 통하여 저작물등을 복제 또는 전송할 수 있도록 하는 서비스를 제공하는 자를 말한다.
  • 다른 사람이 정보통신망(「정보통신망 이용촉진 및 정보보호 등에 관한 법률」 제2조제1항제1호의 규정에 따른 정보통신망을 말한다. 이하 같다)을 통하여 프로그램을 복제하거나 전송할 수 있도록 하는 서비스를 제공하는 자를 말한다.
  공중
  • 불특정 다수인(특정 다수인을 포함한다)을 말한다.
  인증
  • 저작물등의 이용허락 등을 위하여 정당한 권리자임을 증명하는 것을 말한다.
source code 소스 코드  
object code 목적 코드  
guarantee 보장하다  
intellectual property (rights) 지적재산(권)  


오픈소스 라이센스 분류

오픈소스 라이센스 컨설팅

오픈소스 라이선스 관리를 위한 프로세스 및 조직의 구축

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

기획(SW Design)단계

오픈소스 라이선스 관련 문제를 피하는 가장 좋은 방법은 개발 기획 시점부터 이를 고려하는 것이다. 우선 해당 과제에 오픈소스를 활용할 것인지의 여부를 판단하여야 하며, 구체적으로 어떤 프로그램을 사용할 지를 판단하여야 한다. 오픈소스의 특성상 Web 상에 여기 저기 흩어져 있지만, 쉽게 오픈소스에 관한 정보를 찾을 수 있는 곳으로는 Freshmeat.net, SourceForge.net, SDir.com, BerliOS, Bioinformatics.org 등을 들 수 있다. 이와 같은 사이트들은 대부분 라이선스별 오픈소스 분류 항목을 두고 있기 때문에 쉽게 해당 프로그램의 라이선스를 확인할 수 있을 것이다. 기획 단계의 마지막으로 해당 소프트웨어 Component별로 소스코드 공개 가능여부를 판단하여야 한다. GPL 등 소스코드 공개 의무가 발생하는 오픈소스를 사용할 경우에는 결과물의 소스코드 공개가 요구되기 때문에, 경우에 따라서는 소프트웨어 구현 방법을 달리해야하기 때문이다. 소스코드의 공개가능 여부에 대한 판단 기준으로 다음의 사항을 참조할 수 있을 것이다.

  • 유지보수
소프트웨어의 경우 하드웨어와 달리 개발 후 지속적 Upgrade 및 Debugging과 같은 유지보수 과정이 중요하다. 이러한 유지보수 과정은 상당한 Resource를 요하기 때문에 유지보수를 직접 할 것인지에 대한 고려가 필요하다. 개발한 소스코드를 오픈소스 커뮤니티에 공개하고, 이를 바탕으로 오픈소스 커뮤니티를 통한 유지보수 방법 역시 경우에 따라 아주 효율적일 수도 있을 것이다.
  • 빠른 개발
오픈소스의 개발 모델 중 가장 특징적인 것이 바로 'Release Early and Often'을 통한 'Parallel Development and Debugging'이 가능하므로 오픈소스SW는 빠른 개발 속도를 나타낸다. 이러한 모델을 Resource가 부족한 개발 과제에 적용하면 보다 효율적이고 빠른 개발이 가능할 것이다.
  • 신뢰성 확보
소프트웨어의 신뢰성 확보의 가장 좋은 방법은 다양한 사용자들이 다양한 환경에서 해당 프로그램을 사용하면서 발견되는 문제점을 신속히 수정하는 것이다. 이런 측면에서 볼 때 오픈소스 커뮤니티를 잘 활용하면 소프트웨어 신뢰성 확보에 상당한 도움을 얻을 수 있을 것이다.
  • 차별화 유지 어려움
소스코드를 공개하게 되면 그 소스코드는 경쟁사에게도 공유되는 것이기 때문에 결국 제품의 차별화 확보가 불가능하게 되는 단점이 있다.
  • 지적재산권 확보의 어려움
기업이 보유한 특허를 구현하여 소스코드를 공개하는 것은 결국 모든 사용자들에게 Royaltyfree의조건으로 특허를 공개하는 것이나 마찬가지가 된다.
  • 특허 침해 소송 제기 가능성 증가
소스코드가 공개되어 있으면 누구든 그 소스코드를 볼 수 있기 때문에 특허침해 소송 제기 가능성이 증가하게 되는 문제점이 발생할 수 있을 것이다.


구현(Implementation)단계

자체 개발한 소스코드를 공개해도 무방한 경우는 특별히 구현 방법에 신경 쓸 필요가 없다. 단, 소스코드를 공개할 경우 회사보유의 지적재산권을 포함시키지 않도록 주의할 필요가 있다. 그러나 소스코드 공개를 원하지 않을 경우는 사용하는 오픈소스의 라이선스 의무사항과 활용하고자 하는 형태(Kernel, Application, Device Driver 등)에 따라 다양한 경우가 발생할 수 있기 때문에 상당한 주의가 요구된다.

  • 라이선스 삭제 금지
프로젝트 매니저는 개발자에게 오픈소스를 사용한 경우에는 해당 라이선스를 삭제하지 않도록 해야 한다. 거의 대부분의 오픈소스의 경우에는 소스코드 시작부분에 해당 라이선스를 표시하고 있다. 이러한 라이선스는 오픈소스를 검증하는 차원에서 검색을 통해 해당 오픈소스의 사용이 적절한지 판단하기 위해서 꼭 필요하기 때문에 개발자에게 이를 꼭 주의시켜야 한다. 만약 이러한 라이선스를 따르지 않을 경우 저작권 침해로 인한 법적인 문제가 발생한다. 따라서 개발자들이 오픈소스를 사용하는 경우 해당 소프트웨어에 사용한 오픈소스의 라이선스를 반드시 추가하고 이를 삭제하지 않도록 하여야 한다.
  • 오픈소스 사용목록 작성
소프트웨어를 구현하는 단계에 있어서 오픈소스를 사용할 경우에는 오픈소스 사용목록을 작성하여 제출하도록 하여야 한다. 이렇게 함으로써 개발자에게 오픈소스를 사용하는데 있어 법적인 문제가 있음을 인식시킬 수 있으며, 향후 오픈소스 사용으로 인한 법적인 문제가 발생했을 때도 해당 목록을 통해 적극적인 대응을 할 수 있다. 특히 소프트웨어의 일부를 아웃소싱하는 경우 소프트웨어를 개발하는 업체에 대해 오픈소스 사용목록을 작성하도록 해야 나중에 이로 인한 법적인 문제가 발생시 책임문제를 명확하게 할 수 있다.
  • 오픈소스 라이선스 확인
일부 오픈소스의 경우 라이선스의 확인이 어려운 경우가 있다. 이 경우에는 다음과 같은 방법을 통해서 라이선스를 확인해야 하고 이를 소스와 오픈소스 사용목록에 추가하여야 한다.
  • 구글을 통한 방법
구글은 오픈소스 코드를 검색하는 코드서치 사이트를 운영하고 있다. 이 사이트를 이용하여 자신이 인용한 코드의 파일명이나 패키지명을 입력하면 해당 라이선스를 화면에 보여주기 때문에 자신이 사용한 프로그램의 라이선스를 쉽게 확인할 수 있다.
오픈소스의 대부분의 프로젝트가 Freshmeat이나 Sourceforge에서 이루어지고 있기 때문에 이 사이트를 통하여 검색하면 해당 오픈소스의 라이선스를 쉽게 확인할 수 있다.
  • 소스코드를 통한 방법
소스코드를 다운받아 COPYING, README, LICENSE 등의 파일에서 확인하거나 소스코드의 상위 코멘트에서 확인이 가능하다.


검증(Verification)단계

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

제품화(Production)단계

이 단계에서는 사용된 오픈소스들을 라이선스별로 분류하고 각 라이선스에서 준수해야 할 사항들이 실제로 제품에 반영될 수 있도록 하여야 한다. 앞에서 오픈소스의 라이선스 의무사항은 크게 '저작권 관련 문구 유지', '제품명 중복 방지', '서로 다른 라이선스 조합', '사용 여부 명시', '소스코드 공개', '특허' 등이 있다고 기술하였는데, 이중에서 '저작권 관련 문구 유지', '제품명 중복 방지', '특허' 등은 기획 및 구현 단계에서 확인되어야 할 사항이고, '소스코드 공개', '사용 여부 명시' 등은 제품화 단계에서 확인되어야할 사항이다.

  • 소스코드 공개 방법
소스코드의 공개 방법으로 두 가지 방법이 있다. 첫째는 제품판매 시 제품과 함께 소스코드를 제공하는 것이다. 둘째는 제품과 함께 저작권 정보만을 제공하며 여기에 소스코드에 대한 정보와 실제 소스코드는 웹사이트를 통해 공개하거나 CD-ROM 등과 같은 매체를 통하여 우편으로 전달하는 것이다. 이 중 첫 번째 방법은 소스코드 제공에 있어서 확실한 방법이 되겠지만 라이선스를 유지하고 관리하는데 있어서는 비효율적이라 할 수 있다. 따라서 일반적으로 제품의 라이선스를 제공할 수 있는 웹페이지를 운영하는 것이 체계적이고 효율적인 방법이라 하겠다.
  • 새로운 오픈소스 라이선스를 만드는 경우
제품을 상품화하면서 오픈소스로 개발은 하지만 자신의 회사에게 유리하도록 라이선스를 규정할 수가 있다. 그것은 바로 OSI에 정하는 오픈소스의 10가지 조건에 맞추어 승인을 받으면 된다.
OSI에 오픈소스 라이선스 등록절차는 다음과 같다.
  1. 다른 라이선스의 제목과 구별되는 자신만의 고유한 라이선스 이름을 만든다. 즉, 기존에 승인받은 라이선스(제목 또는 카테고리가)와 구별되도록 한다.
  2. 라이선스를 HTML과 플레인 텍스트의 두 가지 형식으로 제작하고 HTML 형식의 라이선스를 OSI 웹페이지에 올린다. 그러면 OSI에서 이미 승인한 라이선스와 같은 형식으로 변환시켜준다.
  3. 라이선스가 오픈소스의 정의규정에 부합하도록 법적인 검토(의견)를 덧붙인다. 라이선스의 각 단락들이 각 오픈소스 정의 규정과 어떻게 부합하는지에 대한 해설이 있어야 한다. 그러한 법적 검토(의견)는 공인된 변호사로부터 작성된 것이야 한다. 변호사의 법적검토가 담긴 이메일을 OSI로 보낸다
  4. 아래 설명에 따라 세 부분으로 나누어진 이메일을 라이선스-토론 메일링 리스트로 보낸다. 메일 제목에는 라이선스 제목과 함께 "승인요청(승인용):"이라고 적는다. 1) OSI에서 승인받은 라이선스 중 본인의 라이선스와 가장 유사한 라이선스를 표시하고 왜 기존의 라이선스가 본인의 필요를 만족시켜주지 못하는지에 대한 설명을 덧붙인다. 2) 본인의 라이선스의 적용을 받아 배포되는 소프트웨어는 다른 오픈소스 라이선스 하에 배포되는 소프트웨어와 어떻게 결합될 수 있는지 설명한다. 3) 본인 라이선스의 텍스트 버전을 첨부한다.
  5. mailto:license-discuss-subcribe@opensource.org 에 가입하여 라이선스 논의에 참여한다. 만약 라이선스 토론 메일링 리스트의 회의들이 라이선스가 OSI정의에 부합하지 않는다는 것을 발견한다면 그 문제를 토론을 통해 해결할 수 있다.
  6. OSI와 라이선스-메일링리스트를 구독하는 사람들 또는 다른 검토자들이 본인의 라이선스가 오픈소스 정의와 부합함이 분명하고 더 이상 특이사항이 없다는 확신이 생기면 라이선스가 승인 되었음을 공지하고 OSI 웹사이트의 오픈소스 라이선스 리스트에 등재될 것이다.


참고 문헌

인증된 오픈소스 라이선스 목록

라이선스 관련 단체

오픈소스 라이선스 관련 참고 문헌

기획 기사

  • SW저작권 분쟁, 그 해법과 대응전략 : 디지털데일리
  1. SW 저작권 분쟁, 정말 난제인가
  2. SW저작권, A부터 Z까지
  3. SW저작권 분쟁, 어떻게 해결할까
  4. 내 SW는 내가 지킨다…프로그램 등록..
  5. SW 소스코드 유출, 어떻게 막을 것인가
  6. 오픈소스, 잘 쓰면 약 잘못 쓰면 독
  7. SW융합시대의 오픈소스 이용법
  8. SW저작권 분쟁, 어떻게 예방할까

저작권 등 법률 관련 참고 문헌

논문 및 연구 발표 자료

오픈소스 관련 자료 - 1998년

오픈소스 관련 자료 - 1999년

오픈소스 관련 자료 - 2000년

오픈소스 관련 자료 - 2001년

오픈소스 관련 자료 - 2002년

오픈소스 관련 자료 - 2003년

오픈소스 관련 자료 - 2004년

오픈소스 관련 자료 - 2005년

오픈소스 관련 자료 - 2006년

오픈소스 관련 자료 - 2007년

오픈소스 관련 자료 - 2008년

기타 참고 문헌

원본 주소 "https://www.jopenbusiness.com/mediawiki/index.php?title=오픈소스_라이선스&oldid=29548"