명의신탁이란? 부동산법률

부동산 명의신탁이란 실제 소유자가 아닌 타인의 명의만 빌려서 부동산을 소유하는 것이다. 이때 실질적인 소유자를 신탁자라고 하고, 명의만 제공한 사람을 수탁자라고 한다.

명의신탁 자체가 원칙적으로 무효인 것은 아니다. 민법이란 원칙적으로 당사자들이 의욕한 바대로 계약을 맺을 수 있다. 다만 부동산 실권리자명의 등기에 관한 법률이 시행되면서 부동산 명의신탁은 무효가 되는 경우가 대부분이다.

수탁자가 신탁자의 허락없이 신탁 받은 부동산을 처분해버리는 경우가 많다. 이러한 경우 형사적으로 횡령이란 배임죄가 성립하는지가 문제된다. 이번에는 형사적인 문제는 다루지 않고 민사관계만을 설명하기로 한다.

부동산 실권리자명의 등기에 관한 법률

흔히 부동산실명법, 줄여서 부실법이라고 부르는 부동산 실권리자명의 등기에 관한 법률은 1995년 3월 30일 제정되어 1995년 7월 1일부터 시행되는 민법의 특별법이다. 부실법 제정 전까지는 부동산 명의신탁을 규율하는 특별한 법령이 없었기 때문에 대법원의 판례에 따라 부동산 명의신탁의 법률관계가 규율되어 왔다.

부실법은 명의신탁약정을 원칙적으로 무효로 한다. 또한 명의신탁약정에 따라 이루어진 등기도 원칙적으로 무효이다. 다만, 종중과 부부 사이 등 몇 가지 특수한 경우에 예외를 두어 명의신탁을 인정한다.

부실법에 의해 무효가 되지 않는 명의신탁은 종전의 판례 이론에 따라 그대로 규율된다. 또한 부실법은 그 법 이름에서 알 수 있는 것처럼 부동산에 관해서만 적용된다. 부동산이 아닌 재산, 가령 자동차나 건설기계 따위는 명의신탁이 허용된다.

2자간 명의신탁

명의신탁에는 크게 3가지가 있다. 그 중 2자간 명의신탁의 경우를 보자.

A라는 사람이 자기 명의로 소유하고 있던 부동산을 소유하고 있다. A는 B와 명의신탁 약정을 맺고 B에게 부동산의 명의를 넘겨준다. 이러한 방식을 2자간 명의신탁 혹은 등기명의신탁이라고 부른다. 

부실법에 의해 예외로 인정되는 경우가 아니라면, 일반적으로 2자간 명의신탁은 무효이다. "실제로는 A가 부동산을 소유하면서 등기 명의만 B 앞으로 해두자"라고 A와 B가 약정하였더라고 이러한 계약은 효력이 없다.

명의신탁약정만 해두고 아직 소유권이전등기를 하지 않은 상황을 가정하자. B가 A를 상대로 명의신탁약정에 기한 소유권이전등기청구 소송을 제기한다면 패소할 것이다. 명의신탁약정은 무효이기 때문이다.

이미 소유권이전등기가 이루어진 경우라면 어떨까? 등기부 상에는 소유자가 B로 등재되어 있다. 하지만 명의신탁약정에 따른 등기는 무효이기 때문에 B는 소유권을 취득할 수 없다. 진정한 소유자는 A이다. 부동산의 소유자인 A은 자신의 부동산이 다른 사람의 명의로 되어 있다면 등기말소를 청구할 수 있다. A가 B를 상대로 등기말소청구소송을 제기한다면 승소할 수 있다.

3자간 명의신탁

3자간 명의신탁이란 A가 부동산을 매수하면서 그 명의를 B앞으로 해두는 것이다. 원래 소유자가 C라고 하면, A가 C로부터 부동산을 매수하기로 한 후 등기는 B앞으로 해달라고 하는 형태이다.

3자간 명의신탁에서 A와 C사이의 부동산 매매계약이 무효인 것은 아니다. 하지만 A와 B사이의 명의신탁약정은 부실법에 따라 무효이다. 또한 C에서 B로 이전된 등기 역시 무효이다.

이미 등기가 이전되어 등기부상에 B가 소유자로 등재되어 있다고 하더라도 B는 진정한 소유자가 아니다. 무효인 등기이므로 말소되어야 할 등기이기 때문이다. B의 등기가 무효라면 소유자는 여전히 C이다. A는 자신의 명의로 등기를 한 적이 없기 때문에 부동산을 취득할 수 없다. 부동산의 소유권 이전은 등기가 이루어져야 완료되기 때문이다.

C가 B를 상대로 등기말소청구소송을 제기한다면 승소한다. A는 부동산의 소유자는 아니지만 여전히 C를 상대로 소유권이전등기를 청구할 수 있는 매수인이다. A와 C사이의 매매계약 자체는 유효하기 때문이다.

A가 C에 대해서 가지는 소유권이전등기청구권을 보존하기 위하여 C의 B에 대한 말소등기청구권을 대위행사할 수도 있다. A가 C를 대신하여 B를 상대로 말소등기청구를 하는 것이다. A는 B의 등기를 말소시킨 후 다시 C에게 소유권이전등기청구를 하여 자기 앞으로 등기를 했을 때 비로소 부동산의 소유자가 될 수 있다.

계약명의신탁

계약명의신탁은 부동산의 실제 권리자가 아예 수탁자의 뒤로 숨는다는 점에서 앞의 두 경우와는 다르다.

A는 C로부터 부동산을 매수하려고 한다. 하지만 거래의 전면에 등장할 수 없는 어떤 사정이 있어 B와 명의신탁약정을 맺고 B명의로 부동산을 매수한다. B는 A의 부탁을 받고 C에게 가서 자신의 명의로 부동산을 매수한다. 물론 매입대금은 A가 제공한 돈이다.

이때 A와 B사이의 명의신탁약정은 역시 무효이다. 다만 문제되는 것은 C에서 B로 넘어간 등기의 효력이 어떤가 하는 점이다.

만약 이 경우에도 등기를 무효로 만들면 C 입장에서는 여간 난처한 것이 아니다. B에게 등기를 넘겨주고 거래가 완전히 종결되었다고 생각했는데, 나중에 원치 않은 소송에 휘말리게 되어 골머리를 썩히게 될 수도 있다. 따라서 부실법인 이러한 경우 예외를 인정한다.

부동산 실권리자명의 등기에 관한 법률
제4조 (명의신탁약정의 효력) ① 명의신탁약정은 무효로 한다.
②명의신탁약정에 따라 행하여진 등기에 의한 부동산에 관한 물권변동은 무효로 한다. 다만, 부동산에 관한 물권을 취득하기 위한 계약에서 명의수탁자가 그 일방당사자가 되고 그 타방당사자는 명의신탁약정이 있다는 사실을 알지 못한 경우에는 그러하지 아니하다.

부실법 제4조 제2항 단서에 따라 C가 부동산의 실제 매수자가 A라는 사실을 몰랐다면 등기는 유효하다. 따라서 B는 소유권을 취득한다. 하지만 A와 B사이의 명의신탁약정은 여전히 무효이기 때문에 A는 B에게 소유권이전등기청구를 할 수 없다. B가 A의 허락 없이 부동산을 다른 사람에게 팔아버려도 상관없다. B 자신의 재산이기 때문이다.

A는 C를 대위하여서 B에게 등기말소나 소유권이전을 청구할 수도 없다. 이 경우 A는 부동산의 매수대금으로 B에게 지급한 돈을 되돌려달라고 청구하는 방법밖에 없다. 명의신탁약정이 무효이기 때문에 매수대금으로 지급한 돈은 아무런 계약관계 없이 지급한 부당이득이 되기 때문이다.

만약 C가 실제로는 A가 부동산의 매수인이라는 점을 알았다면 상황은 달라진다. 이 경우는 3자간 명의신탁과 마찬가지로 C에서 B로 넘어간 등기를 무효가 된다. 3자간 명의신탁과 다른 점은 A가 C를 대위하여 B의 등기를 말소하고 A 앞으로 소유권이전등기를 청구할 수 없다는 점이다. A와 C는 서로 아무런 계약관계가 없기 때문이다. A가 C와 다시 새로운 매매계약을 맺는다면 모를까 서로 아무런 계약이 없는데 소유권이전등기청구를 할 수는 없다.

C가 명의신탁 사실을 안 경우, A와 B사이의 명의신탁약정이 무효이므로 A는 B에게 부당이득으로 매수대금을 돌려달라고 청구할 수 있다. 또한 B는 C에게 매수대금을 돌려달라고 청구할 수 있다. B와 C사이의 매매계약은 무효이기 때문이다. 부실법에는 매매 계약을 무효로 한다는 규정이 없지만, 등기를 무효로 한다는 규정이 있기 때문에 B와 C 사이의 매매계약은 애초에 목적을 달성할 수 없는 계약으로 되어 무효가 된다. 결국 A는 B를 대위하여 C에게 부당이득반환청구를 할 수 있다.

수탁자가 신탁재산을 처분한 경우

수탁자가 신탁재산을 처분한 경우는 매수인은 언제나 부동산을 유효하게 취득한다. 부실법 제4조 제3항은 부실법에 따른 명의신탁약정의 무효나 등기의 무효는 제3자에게 대항할 수 없도록 하고 있기 때문이다. 등기부의 기재를 확인하고 등기부상의 소유자가 진정한 소유자라고 믿고 부동산을 매수하였다면 등기부상의 소유자가 실제로는 명의수탁자였더라고 소유권을 유효하게 취득하게 된다.

수탁자 측에서는 만일 등기가 무효라서 자신의 소유가 아닌 부동산을 매도하는 경우가 될 수도 있다. 이 경우 원래의 진정한 소유자에게 손해를 배상해주어야 할 책임이 있다.

소프트웨어 보증 IT법률

소프트웨어 보증

벤더가 제품을 판매하는 경우, 통상 그 제품이 어떤 작동을 한다는 점을 약속합니다. 예를 들어, 전구는 빛을 낼 것이고, 자동차는 주행을 할 수 있습니다. 이러한 약속은 제품 브로셔를 통해서와 같이 묵시적으로도 이루어질 수 있고, 상세한 기술 사양 설명을 통해서와 같이 명시적으로 이루어질 수도 있습니다. 우리가 물건을 사면, 그 물건이 약속된 대로 작동할 것이라는 점에 대해 정당한 기대를 가집니다.

보증은 벤더가 판매한 물건이 하자가 없다는 점, 즉 약속된 기능을 제공할 것이는 점과, 만일 그렇지 않을 경우 그 하자를 어떻게 치유해줄 것인지에 관한 공식적인 약속입니다.

만일 서버나 컴퓨터의 하드웨어를 구입한다면, 보증은 통상 그 물건이 기술 사양에 따라 작동하며, 제조 결함이 없다는 점을 보장합니다. 보증 계약은 제품이 약속과 달리 작동하지 않을 경우 회사가 물건을 어떻게 고쳐줄 것인지, 얼마나 빨리 고쳐줄 것인지를 규정합니다. 이는 통상 "서비스 레벨"과 결합한 "보증 서비스"로 나타납니다. 예를 들어, 벤더는 48시간 안에 부품을 1대1로 교환해 줄 것이라고 정하기도 합니다. 보증 계약에서 보증이 제공되지 않는 범위나 보증을 무효화할 수 있는 경우를 정하기도 합니다. 예를 들면, 정당한 권한 없이 기계를 개조하면 보증을 받을 수 없습니다. 보증 계약에서 제품이 작동하지 않을 때 벤더 측의 책임을 제한하는 조항을 포함할 수도 있습니다. 예를 들어, 서버가 작동하지 않는 경우 그로 인해 손실한 데이터로 인한 손해까지는 벤더가 책임을 지지 않는다는 조항이 있을 수 있습니다.

소프트웨어를 구입하는 경우라면 이야기가 약간 달라집니다. 하드웨어와 달리, 소프트웨어는 "as-is" 조건에 따라 보증 없이 판매되기도 합니다. 소프트웨어가 약속한 대로 작동하리라는 점을 벤더 측이 보장하지 않는다는 뜻입니다. 소프트웨어에 대한 보증이 존재하지 않을 수 있습니다. 물론 소프트웨어가 담긴 매체에 대한 보증이 있는 경우는 있지만, 소프트웨어 자체에 대한 보증은 아닙니다.(가령 소프트웨어가 저장된 CD가 손상되어 있다면 교환은 가능합니다.) 상용 완제품 소프트웨어(off-the-shelf 소프트웨어 혹은 shrink-wrap 소프트웨어)의 경우 종종 "as-is" 조건에 따라 판매됩니다.

반면, 기업용 소프트웨어나 주문 개발된 소프트웨어는 제한된 보증을 수반하여 판매되는 경향이 있습니다. 하지만 이러한 소프트웨어 보증도 제한적입니다. 해당 프로그램이 전혀 결점 없이 설명서 그대로 정확하게 작동한다는 점을 보장하지는 않기 때문입니다. 이는 결점(버그)이 전혀 없는 소프트웨어를 만드는 것이 거의 불가능한 까닭입니다. 소프트웨어가 약속대로 작동한다는 보장은 없지만, 벤더들은 소프트웨어의 결점을 제거하기 위해 통상 아래에서 설명하는 방식 중 몇 가지를 제공합니다.

1. 오류 보고. 벤더 측은 고객에게 전화번호나 혹은 문제점을 보고할 수 있는 방법을 제공합니다. 이러한 창구는 문제점을 받아들이기만 하며, 통상 그 문제점을 수정해주거나 다른 지원을 제공하지는 않습니다.

2. 업데이트. 보증 계약에서 벤더가 소프트웨어의 결함을 고치기 위해 버그 픽스와 패치를 만들 것이라는 점을 설명하기도 합니다. 하지만 그러한 버그 픽스나 패치가 만들어질 것이라는 점, 혹은 결함이 발견된 후 일정한 기간 안에 만들어질 것이라는 점을 보장하지는 않습니다. 달리 말해, 벤더 측의 자유재량 혹은 최선의 노력에 따라 버그 픽스나 패치를 만들 것이라는 뜻입니다. 이러한 패치는 약간의 기능 향상을 포함하거나 오퍼레이팅 시스템이나 다른 소프트웨어의 업데이트에 맞추어서 이루어지기도 합니다. 고객은 각자 패치나 업데이트를 설치해야 하며, 벤더 측에서 그들이 배포한 업데이트를 설치하거나 관리해주는 서비스는 제공하지 않는 것이 보통입니다.

3. 환불 청구권. 보증 기간 동안 소프트웨어가 설명서처럼 작동하지 않거나, 벤더가 그 결함을 제거할 수 있는 업데이트를 배포하지 못하는 경우, 그 기간 안에는 고객이 환불을 받을 수 있는 권리를 부여합니다.

4. 보수 청구권. 소프트웨어가 설명서처럼 작동하지 않는 경우 벤더 측이 즉각 소프트웨어를 수정하거나 다른 우회적인 방법으로라도 그 소프트웨어가 제대로 작동하도록 지원을 해준다는 뜻입니다. 보수가 제공되는 방법은 통상 문제점이 얼마나 심각한지에 따라 달라집니다. 원격이나 인터넷을 통해 제공될 수도 있고, 직접 현장에서 제공될 수도 있습니다. 주말 없이 24시간 제공될 수도 있고, 근무시간에만 제공될 수도 있습니다. 이는 계약에 달린 문제입니다.

5. 개선 요구에 따른 계약 체결권(주문 개발한 소프트웨어의 경우). 소프트웨어가 사업에 적합하게 유지될 수 있도록 할 목적으로 이루어집니다. 개선에 관해서는 따로 보증이 이루어지며, 또한 개선 비용 또한 따로 정합니다.

6. 도움말. 때로 도움말이 번들로 포함되기도 합니다. 도움말은 사용자가 소프트웨어를 구성하고 사용하는데 도움을 줍니다.

오픈소스 소프트웨어 라이선스 IT법률

오픈소스 소프트웨어 라이선스

오픈소스 소프트웨어란 공공재라서 누구나 아무 제한 없이 복사하여 사용할 수 있다는 것은 잘못된 생각입니다. 오픈소스 소프트웨어의 저작자들은 소프트웨어에 대한 그들의 권리를 포기한 적이 없습니다. 상용 소프트웨어의 저작자와 마찬가지로 그들은 소프트웨어에 관한 지적재산권(저작권, 특허권 등)을 보유하고 있으며, 라이선스를 통해 다른 사람들이 그들의 소프트웨어를 이용할 수 있도록 합니다.

오픈소스 라이선스가 상용 라이선스와 다른 점은 구매자들이 첫째, 소스코드를 수정할 수 있는 자유를 가진다는 점, 둘째, 동일한 라이선스를 부착한다면 소프트웨어를 복제하고 재배포할 수 있다는 점입니다. 두번째 특성의 경우 저작권 라이선스와 특허 라이선스에서 모두 허용되어야 합니다. 라이선스 조건에 명확하게 기술되는 경우도 있고, 라이선스의 문언으로부터 그 의미를 충분히 알 수 있는 경우도 있습니다.

이러한 일반론과 별도로, 각각의 오픈소스 라이선스는 서로 상당히 다릅니다. 간단한 라이선스도 있고, 상당히 복잡한 제한과 의무를 부과하는 라이선스도 있습니다. 전염성을 가지는 라이선스도 있습니다. GNU 라이선스가 대표적입니다. 어떤 소프트웨어가 GNU 라이선스가 적용된 코드를 이용한다면, 그 소프트웨어 및 그 소프트웨어의 소스를 사용하는 장래의 모든 소프트웨어가 반드시 GNU 라이선스로 배포되어야 합니다. "특허 사용 허가 조항"을 통해 소프트웨어에 사용된 특허나 기술에 관한 권리를 포기하도록 만드는 라이선스도 있습니다. 특허의 대상이 되는 기술을 포함하였다가 특허사용료를 받을 수 있는 권리를 잃어버릴 수도 있습니다. 해당 라이선스에 따른 코드를 조금이라도 사용하면 모든 코드를 소스 코드 형태로 배포할 것을 강제하는 라이선스도 있습니다.

오픈소스 소프트웨어가 대가 없이 공짜로 제공된다는 생각도 오해입니다. 사실 소프트웨어 회사는 오픈소스 소프트웨어의 배포나 지원에 대해 요금을 받을 수도 있습니다. 이러한 회사들은 구매자를 위해 소프트웨어를 패키징하거나 기술적 지원을 제공하는 방식으로 부가가치를 제공합니다.

일 반적으로 자주 사용되는 오픈소스 라이선스의 핵심적인 내용만 기술합니다.(각 라이선스는 여러 버전이 있을 수 있으며, 각 버전은 서로 다를 수 있습니다. 오픈소스를 이용하기 위해서는 사전에 라이선스를 주의 깊게 검토하여야 합니다.)

GNU GPL: GNU GPL 코드를 이용하거나 링크한 모든 소프트웨어는 동일하게 GNU GPL 라이선스에 따라 배포되어야 합니다. 따라서 이 라이선스는 전염성이 있습니다. 만일 누군가 GPL 라이선스가 붙은 라이브러리를 이용한다면, 해당 소프트웨어와 장래의 모든 버전은 GNU GPL 라이선스로 배포되어야 합니다. 또한 그 해당 소프트웨어를 사용하거나 링크한 또다른 제3의 소프트웨어도 역시 GNU GPL 라이선스로 배포되어야 합니다. 이 라이선스는 프로그램의 소스코드를 배포할 것을 요구하며, 일반적으로 코드에 이용된 특허권 및 저작권을 모두 사용 허가하도록 강제합니다.

GNU LGPL: GNU GPL과 비슷하지만, LGPL 라이선스가 붙은 라이브러리를 다이나믹 링크한 경우에는 해당 소프트웨어를 LGPL에 따라 배포할 필요가 없습니다. 하지만 자바와 같은 인터프리티드 언어의 경우 다이나믹 링크를 구성하는지를 판단하는 기준이 명확하지 않다는 점을 고려할 필요가 있습니다.

Apache 라이선스: 일반적으로 Apache 라이선스가 붙은 소프트웨어는 별다른 제한 없이 이용, 수정 및 재배포할 수 있습니다. 어떤 경우에는 수정한 소스의 코드를 배포할 필요가 없는 경우도 있습니다. Apache 라이선스를 이용한 소프트웨어에는 반드시 Apache 라이선스를 동일하게 명시하여야 한다는 점이 유일한 의무입니다.

상용 소프트웨어 라이선스 IT법률

상용 소프트웨어 라이선스

소프트웨어 라이선스는 구매자에게 소프트웨어를 사용할 수 있는 권리를 부여합니다. 법적으로 소프트웨어는 저작권법에 의해 보호되는 소프트웨어 개발자(소프트웨어 개발업체)의 지적재산권입니다. 소프트웨어가 특허권에 의해 보호되는 경우도 있습니다. 가령 암호화 알고리즘 같이 특허에 의해 보호되는 특수한 기술을 소프트웨어가 구현하고 있는 경우입니다.

소프트웨어의 코드는 소프트웨어 개발자의 것이므로 소프트웨어를 사용하고자 하는 이는 개발자에게 허락을 얻어야 합니다. 그렇지 않으면, 저작권이나 특허권과 같은 지적재산권의 침해로 개발자에게 제소당할 수 있습니다.

소프트웨어 라이선스는 개발자와 구매자 사이의 계약입니다. 계약의 내용은 개발자가 구매자에게 소프트웨어를 사용할 수 있는 권리를 부여하는 것입니다. 이 계약이 있기 때문에 구매자는 지적재산권의 침해로 제소당할 염려 없이 소프트웨어를 사용할 수 있습니다. 대부분의 소프트웨어 라이선스에는 구매자에게 허용되는 제한 조건을 상세하게 명시합니다. 예를 들어, 구매자가 소스코드를 역분석하는 행위를 금지하거나 소프트웨어를 다른 이에게 대여하지 못하도록 하는 조건의 라이선스가 있을 수 있습니다. 구매자에게 대한 제한의 대표적인 예들은 아래와 같습니다.

  • 사용 : 구매자가 상용 호스팅 서비스에 해당 소프트웨어를 구동하는 것을 금지할 수 있습니다.
  • 사용권자의 수/ CPU : 한정된 숫자의 최종 사용자만이 소프트웨어를 사용할 수 있다거나, 한정된 숫자의 프로세서에만 구동할 수 있다는 제한입니다.
  • 복제 : 구매자가 소프트웨어의 복사본을 만드는 것을 금지할 수 있습니다.
  • 양도 : 구매자가 라이선스를 타인에게 양도하는 것을 금지할 수 있습니다. 이 경우 구매자는 라이선스를 타인에게 판매할 수 없습니다.

소프트웨어를 사용할 수 있도록 라이선스를 받는 것이 소프트웨어의 복사본을 소유하는 것과 다릅니다. 라이선스는 단지 소프트웨어를 사용할 권리만을 부여합니다. 구매자는 소프트웨어의 지적재산권에 대해서는 아무런 권리가 없으며, 소프트웨어의 복사본을 '소유'하는 것이 아닙니다.


GPL에 따라 소스를 배포하는 방법 IT법률

GPL이 적용된 코드를 소프트웨어에 통합하는 경우 해당 소프트웨어를 GPL에 따라 배포하여야 하는 경우가 있습니다. 어느 경우까지 GPL의 강제를 받는지는 중요한 문제이지만, 개별적인 사안에 따라 법률전문가의 판단을 거쳐야 하는 문제이며, 일반론으로 다룰 내용은 아닙니다.

소프트웨어에 GPL이 적용되는 경우, GPL에 따라 소프트웨어를 배포하는 방법에는 여러가지가 있습니다. GPLv2와 GPLv3의 각 조항들은 각 옵션에 따라 배포자들에게 세부적인 사항을 요구합니다.

GPLv2와 GPLv3는 저작권법에 의해 사용이 제한된 소프트웨어를 일정 범위 내에서 사용할 수 있도록 허락하는 라이선스입니다. 이러한 라이선스에는 GPL의 요구사항을 준수하도록 조건이 부여됩니다. 응용 프로그램을 바이너리 형태로 배포하는 경우, 그 바이너리는 소스코드에서 생성되는 것입니다. 따라서 소스코드의 저작권 및 라이선스를 준수하여야 합니다. GPLv2의 제3조와 GPLv3의 제6조는 바이너리 배포에 관한 허가 조건을 규정하고 있습니다.

GPL은 여러가지 옵션을 제공며, 이러한 옵션 중 한 가지 이상을 선택할 수 있습니다. GPL의 조건들은 바이너리에 "상응하는 소스"에 적용됩니다.

첫번째 옵션은 소스와 바이너리를 함께 제공하는 것입니다. 이는 가장 쉬운 방법입니다. 단기적으로는 다른 옵션들이 더 쉬워보일 수도 있습니다. 하지만 이 옵션을 선택하는 경우 소스를 바이너리와 함께 배포하는 것으로 GPL의 의무를 다하게 되므로, 잠재적인 GPL 위반 문제로부터 벗어날 수 있습니다. 다른 옵션을 선택하는 경우 마지막으로 바이너리를 배포한 시점으로부터 상당기간 동안 GPL의 의무를 이행하여야 하는 부담을 안게 됩니다.

이 옵션은 가장 직접적인 GPL 준수 방법입니다. GPL이 적용된 소프트웨어의 바이너리 복제본이 포함된 제품을 배송하는 경우를 가정합니다. 펌웨어의 형태이든, 하드 드라이브나 CD 같은 저장매체에 담겨 있든 상관 없습니다. 여러분은 해당 제품에 바이너리에 상응하는 소스를 포함할 수 있습니다. 혹은 별로도 CD 같은 저장매체에 담긴 소스를 제품과 같이 포장해서 보낼 수도 있습니다.

GPLv2는 이러한 저장매체들을 "소프트웨어 교환에 관행적으로 사용되는 매체"라고 칭합니다. GPLv2는 초고속 인터넷이 발달하지 않았던 시점에 쓰여졌습니다. 지금은 인터넷 전송이 소프트웨어를 배포하는 주요한 방법이지만, GPLv2가 쓰여질 시점에는 그렇지 않았습니다. 지금도 지구상 대부분의 장소에서는 상황이 GPLv2가 쓰여지던 시점과 크게 다르지 않습니다. GPLv2에 따를 때, 인터넷은 "소프트웨어 교환에 관행적으로 사용되는 매체"가 아닙니다. GPLv3에서는 이 문제가 좀 더 명확하게 규정되어 있습니다. GPLv3에서는 소스가 "소프트웨어 교환에 관행적으로 사용되는 지속가능한 물리적 매체에 고정될 것"을 요구합니다. 첫번째 옵션을 선택하는 경우 바이너리 재배포자는 반드시 물리적인 매체를 이용해 소스를 제공하여야 합니다(하지만 자발적으로 인터넷을 통해 소스를 배포하는 것은 매우 유용한 방법입니다).

두번째 옵션은 바이너리와 함께 향후 소스를 제공하겠다는 제안만을 제공하는 방식입니다. 많은 배포자들이 첫번째 옵션보다 두번째 옵션을 선호합니다. 간단하기 때문입니다. 단순히 간단하다는 이유만으로 이 옵션을 선택하기보다 이 옵션을 선택할 실질적 필요가 있는지를 판단하기 바랍니다. 이 옵션은 소스의 배포 비용이 단위단 비용으로 지출될 때 선택할 가치가 있습니다. 가령 임베디드 제품의 영구저장장치의 용량이 소스까지 포함하기에는 너무 적고 제품 포장 안에 종이 매뉴얼이나 인쇄물은 포함되지만 CD는 포함되지 않는 경우, 이 옵션은 매우 경제적입니다.

하지만 이 옵션을 선택하는 경우 의무 이행 기간이 길어집니다. GPLv2에 따르면 마지막으로 바이너리를 배포한 시점부터, GPLv3에 따르면 마지막으로 바이너리 혹은 잔여 부분을 배포함 시점부터 3년간 소스 제공 의무를 집니다. 위 기산점으로부터 3년 안에 소스코드의 제공을 요청받는 경우 반드시 소스를 제공해야 하며, 이를 어기면 라이선스 위반이 됩니다. 3년이라는 시간은 때로 제품의 수명보다 더 긴 시간이 될 수도 있습니다.

GPLv2를 따를 경우, 요청에 따른 소스의 제공에 있어서 인터넷을 통한 제공이 불가능합니다. GPLv2는 반드시 물리적인 매체를 통해 소스를 제공하도록 규정합니다. 제품의 수명이 다한 이후에도 수년간 소스코드 CD를 계속 만들어야 하는 것입니다.

GPLv2에 따를 때에도, 물리적인 매체를 통해 소스를 제공하는 것에 더하여 소스를 다운로드할 수 있는 인터넷 링크를 제공하는 것은 추천할 만합니다. 이러한 관행을 따른다면 누구나 소스를 빠르게 얻을 수 있으며, 따라서 물리적인 매체를 통한 소스 요청의 수를 감소시킬 수 있습니다.

GPLv2는 물리적인 매체를 통해 소스를 제공할 때 복사본의 비용을 청구할 수 있도록 합니다. 물리적으로 소스를 배포할 때 들어가는 비용 이상의 과금은 금지됩니다. 요금은 합리적이어야 합니다. 가능하다면 저렴한 CD 재고품과 배송 방법을 찾아야 합니다. 소스코드의 제공을 빌미로 이윤을 남기려는 시도를 한다면 오픈소스 공동체에서 상응하는 대응을 할 것입니다.

GPLv2는 누구나 소스의 제공을 요청할 수 있도록 하고 있습니다. GPLv3에서는 목적 코드를 가진 사람 누구에게나 제안이 유효하다고 하고 있습니다. GPLv2의 제3(c)조와 GPLv3의 제6(c)조는 비영리적인 재배포자들이 제안을 생략할 수 있도록 하고 있습니다. 따라서 소스를 요구할 수 있는 사람이 직접적인 고객에 한정되는 것이 아닙니다. 고객 뿐만 아니라 그들로부터 바이너리의 복사본을 받은 어느 누구로부터라도 제공의 요청이 있으면 소스를 제공해야 합니다. 많은 배포자들이 이 점을 잘 알지 못하고 직접적인 구매자에게만 소스를 제공할 의무가 있다고 생각합니다.

직접적으로 소스를 배포하지 않고 요청이 있는 경우 소스를 제공하겠다는 제안만을 제공하는 이 옵션은 일종의 특별한 이익입니다. 요청이 있는 경우 소스를 제공할 수 있는 규모와 시스템을 가졌기 때문이 이러한 옵션을 이용할 수 있는 것입니다. 따라서 GPLv2의 제3(c)조와 GPLv3의 제6(c)조는 비영리적인, 비계속적인 재배포자들은 소스의 제공을 요구 받아도 이를 면제받을 수 있도록 규정합니다.

영리적인 재배포자들은 이러한 예외를 적용받을 수 없습니다. 상업적으로 제품을 재배포하는 한 소스를 제공해달라는 제안을 거부할 수 없습니다. 라이선스의 조건은 최초 배포자인지 아닌지 상관없이 GPL이 붙은 소프트웨어를 배포하는 이라면 누구에게나 적용됩니다. 벤더 A가 임베디드 기기 안에 사용하기 위해 GPL이 붙은 소스를 이용해 소프트웨어 플랫폼을 개발했다고 가정합니다. 제조사 B는 A와 그 소프트웨어를 B의 기기에 펌웨어로 설치하도록 계약을 맺습니다. A는 그 소프트웨어를 B에게 제공하면서 소스 제공에 대한 제안을 제공합니다. 이 경우 B는 구매자들에게 소스 제공의 제안을 생략할 수 없습니다. B는 GPL이 적용된 소프트웨어를 상업적으로 배포하기 때문입니다. B는 고객들에게 소스를 제공하거나 소스를 제공하겠다는 제안을 제공하여야 합니다.

구매자가 재배포를 하는 제품일 경우 소스 제공의 제안이 좋은 선택이 아니라는 점을 알 수 있습니다. 첫번째 옵션을 선택한다면 제품에 소스 자체를 포함하면 그것으로 고객에 대한 배포는 끝이 나고, 그들이 다시 그들의 고객에게 수정 없이 그대로 배포한다면 양자 모두 소스의 제공을 끝내게 됩니다. 여러분이 소스에 대한 제공의 제안만을 포함한다면 여러분의 의무를 다할 지 모르지만, 여러분의 고객은 이러한 만족을 승계하지 않습니다.

소스 제공의 제안과 관련된 조건들은 GPLv3의 경우도 크게 다르지 않습니다. 다만 GPLv3 하에서는 일반 공공이 사용할 수 있고, 제품이나 관련 잔여 부분의 마지막 배포로부터 3년간 활성화 상태로 두는 한, 네트워크 서버를 통해서만 소스를 제공하는 방식을 취할 수 있습니다. 인터넷을 이용한 배포만으로 의무를 이행할 수 있습니다. 상업용 재배포자들은 GPLv3만 적용되는 경우 이 옵션을 더 용이하게 사용할 수 있습니다. 하지만 인터넷 기반으로 소스 제공을 하는 프로세스로 교체하기 전에 모든 소프트웨어가 GPLv3하에서 배포될 수 있는지 확인하기 바랍니다. "GPLv2 혹은 그 상위 버전(GPLv2-or-later)"하에서 라이선스 되는 경우가 많습니다. 이러한 라이선스는 GPLv3로 재배포할 수 있는 선택권을 줍니다. 하지만 유명한 프로그램들은 GPLv2로만(GPLv2-only) 라이선스된 경우가 꽤 있습니다. 후자의 경우 인터넷 기반의 소스 제공만으로는 라이선스상의 의무를 만족할 수 없습니다.

GPLv2와 GPLv3에서 소스 제공의 제안은 반드시 전자적 혹은 인쇄물 형태의 라이선스 자체의 복사본을 함께 제공해야 합니다.

상응하는 소스를 준비하고 있지 않다는 이유로 두번째 옵션을 사용하지 않기 바랍니다. 두번째 옵션이 단순히 쉽기 때문에 소스의 준비없이 이 옵션을 선택하고, 나중에 뒷처리로 소스 배포본을 만들어내는 것은 상당히 어렵습니다. GPL을 준수할 준비 없이 시장에 뛰어드는 기업이 임시방편으로 사용하도록 두번째 옵션을 만든 것이 아닙니다. 소스 제공의 제안을 해놓고 실제로 고객으로부터 요청을 받았을 받았을 때 그 요청에 응하지 못한다면 강제집행을 감수하여야 합니다.

GPLv2의 제3(c)조와 GPLv3의 제6(c)조의 예외는 오직 비영리적인 사용에만 적용됩니다. GPL이 적용된 소프트웨어를 배포하는 사업에는 적용되지 않습니다. 상위 벤더에 의해 패키지된 소프트웨어를 재배포하는 기업들은 그 벤더로부터 제안을 받았다는 이유로 제안을 생략할 수 없으며, 그들 자신의 소스 제공의 제안 혹은 상응하는 소스의 직접적인 제공을 이행하여야 합니다.

GPLv2의 옵션은 제3(c)조로 끝납니다. 하지만 GPLv2 하에서도 인터넷을 이용한 소스의 배포는 일종의 관행이었고, 일반적으로는 라이선스를 준수한 것으로 간주해 주었습니다. GPLv2에서는 인터넷에 기반한 배포를 3가지 옵션이 열거된 후 끝부분에 여담처럼 언급합니다.

GPLv2가 쓰여진 1991년도에는, 인터넷을 이용한 소프트웨어의 배포는 예외였습니다. 몇몇 FTP 사이트가 존재했지만, 일반적으로 소프트웨어는 자기테이프 혹은 CD로 보내어졌습니다. 따라서 GPLv2는 바이너리 배포가 물리적 매체를 통해 이루어진다고 가정하였습니다. 반면, GPLv3 의 제6(d)조는 역사적으로 GPLv2의 준수로 여겨져왔던 이러한 관행을 옵션으로 채택하였습니다.

GPLv3에서는 동일한 지점에서 동일한 방법으로 소스 코드를 제공함으로써 소스 제공 의무를 이행할 수 있습니다. 이 옵션을 선택할 때, 사용자들이 바이너리를 다운로드할 때 강제로 소스를 함께 다운로드하도록 할 의무를 지지는 않습니다. 바이너리에 대한 접근성과 소스에 대한 접근성을 동등하게 유지하는 한 별개의 서버를 이용할 수도 있습니다. 다만 사용자들이 바이너리를 다운로드할 때 쉽게 소스코드를 찾을 수 있도록 해야합니다.

피어-투-피어(peer-to-peer) 파일 공유는 GPLv2가 쓰여지고 난 후 생겨났고, GPLv2의 옵션 중 어떤 것과도 일치하지 않습니다. GPLv3의 제6(e)조는 소스와 바이너리를 함께 피어-투-피어 파일 공유 네트워크 상에서 배포하는 방식을 허용합니다. 오직 피어-투-피어 네트워크로만 배포한다면 이 옵션을 선택할 수 있습니다. 하지만 피어-투-피어 방식의 소스 배포는 피어-투-피어 방식이 아닌 바이너리 배포의 경우 라이선스상의 의무를 만족시키지 못합니다. 이 옵션을 선택하려면 바이너리와 소스가 애초에 똑같이 피어-투-피어 방식으로만 배포되도록 해야합니다.


--변호사 김흥주(khj348@gmail.com)

1 2 3 4 5