- 무단 재배포 및 복제, 링크 금지합니다.-

해당 글 내용을 부분 발췌하여 저작자의 생각과 의도를 왜곡시키는 경우에는 법적인 책임을 지게 됩니다.

기업의 환경은 매우 다양하고 CaseByCase에 따라 달라질 수 있기 때문에 저작권법 전문 변호사의

자문을 받아 최종 결정하셔야 합니다. AGPL 라이센스에 대한 기본 상담이 필요하시면 자문은 해드릴수 있습니다.

 

안녕하세요?  운영자 주종면입니다.

아직도 오픈소스를 무료라고 생각하는 사용자가 많은 것이 현실입니다.

MongoDB를 무료로 사용할 수 있는 경우는 개인이든 기업이든 관련 MongoDB GPL-3.0 소프트웨어를

개인 용도 또는 회사 내부용으로 만(외부로 서비스를 수행하는 경우 해당되지 않음) 사용하는 경우 해당되며

독점 소프트웨어로 개발된 시스템(자체 개발 또는 외주 용역에 의해 개발된 프로그램이 오픈소스가 아닌경우)과

통합하여 배포하시게 되면 반드시 소스를 공개하셔야 합니다.

(Open Source로 개발된 소프트웨어와 통합되는 경우에는 예외 사항 인정 : 아래 Apache-2.0 라이센스 참조) 

만약, MongoDB GPL-3.0을 기반한 독점 소프프웨어의 소스 공개를 원치 않을 때는 MongoDB inc와 별도의

상업용 라이센스 계약이 요구됩니다.(듀얼 라이센스 제공)

* 듀얼 라이선스 ( http://www.olis.or.kr/ossw/license/open_source_guide.pdf  참조) 

일부 오픈소스SW는 상업용 라이선스와 오픈소스SW 라이선스(GPL, BSD 등) 또는 오픈소스SW 라이선스들을 조합하여 해당 프로그램을 배포하는 경우가 있다. 이를 주로 듀얼 라이선스(dual license)라고 하며, 이런 경우는 주로 오픈소스SW를 상업적 목적으로 이용할 뿐 만 아니라 오픈소스 커뮤니티와의 협력을 위한 경우가 대부분이다. 하나 이상의 라이선스가 있는 오픈소스SW를 이용할 경우, 이용자는 사용 목적에 가장 잘 부합하는 라이선스 하에 배포되는 소스코드를 선택할 수 있다. 대표적인 사례로는 MySQL, Trolltech의 Qt 라이브러리 등이 있다. MySQL을 예로 들어 듀얼 라이선싱 모델에 대해서 좀 더 살펴보면 다음과 같다. MySQL은 개발에 있어서는 소스코드가 공개된 GPL 라이선스를 이용하고 있으나 자신이 개발한 프로그램을 공개하지 않기를 원하는 기업이나 개인에게는 이들이 개발한 소스코드를 공개하지 않아도 되는 상업용 라이선스를 주는 듀얼 라이선싱 모델을 취하고 있다. 이러한 개발방식을 통해 MySQL AB사는 전세계의 수많은 오픈소스SW 사용자나 개발자들의 도움을 받아 MySQL의 품질이나 신뢰성, 인지도 등을 높이고 이를 통해 MySQL의 시장점유율을 확대하고 있다.
이렇게 만들어진 MySQL 서버 및 부가제품들은 많은 오픈소스SW 사용자들에 의해서 프로그램 을 검증받았을 뿐 아니라 높은 시장점유율을 보이고 있기 때문에 MySQL을 이용을 상업적으로 이용하려는 요구는 점점 많아지게 되고 이것은 MySQL AB사의 수익으로 연결되게 된다. 현재 이러한 듀얼 라이선스 모델은 오픈소스SW를 이용한 비즈니스 모델의 대표적인 예로 자리를 잡았으며, 많은 오픈소스SW기업들이 이러한 유형의 수익 모델을 이용하고 있다.

 

* MongoDB Commercial License (www.mongodb.com/products/mongodb-enterprise-advanced)

MongoDB는 2가지 라이센스 정책을 가지고 있습니다.

기본적으로 GPL-3.0 (GNU 자유소프트웨어 재단에 의해 협약된 라이센스)을 따르며 필요에 따라 Commercial License를 제공하는 듀얼 라이센스를 제공하고 있습니다.

GPL-3.0 라이센스는 기본적으로 MongoDB의 모든 소스와 바이너러리의 사용 및 수정, 복제, 배포 등을 허용합니다.

그리고, 개작된 2차 저작물의 소스  공개 의무도 있습니다. 하지만, 대부분 개발되는 2차 저작물의 경우에 Apache-2.0 라이센스로 개발되는데 이 라이센스는 소스 공개 의무가 없기 때문에 GPL-3.0 라이센스인 MongoDB는 Apache-2.0 드라이브로 개발되는 클라이언트 애플리케이션의 경우에 한해 예외 사항을 두어 소스 공개 의무를 두지 않습니다. 그렇지만, 다른 3rd Party 드라이버로 개발되는 경우에는 소스 공개의무가 있습니다.

GPL-3,0인 MongoDB는 개인 용도 또는 회사 내부 용으로 만(외부로 서비스를 수행하는 경우 해당되지 않음) 사용하는 경우 무료로 사용할 수 있는 라이센스 제품입니다. 만약에, 상업적 용도(OEM)로 사용하거나, GPL 용도로 사용하지만 기술 지원이 요구되는 경우, 소스 공개 의무가 있지만 공개할 수 없는 경우에는 MongoDB에서 제공하는 Commercial License를 취득하실 수 있으며 지속적인 MongoDB의 기술 지원을 받게 되며 소스 공개 의무도 없어지게 됩니다. 본인의 프로젝트 환경에 맞는 적절한 라이센스 선택이 요구됩니다. 

다음은 상업적 용도의 대표적인 경우들입니다.

MongoDB를 통합하여 개발한 독점 소프트웨어를 고객에게 판매하였고 그 독점 소프트웨어를 고객 소유의 장비에 설치한 경우

고객이 보유한 장비에 MongoDB를 설치해야만 사용할 수 있는 독점 소프트웨어를 판매하는 경우

MongoDB가 설치되어 있는 하드웨어 시스템을 고객에게 팔아서 고객의 회사에 설치하여 운영하는 경우 MongoDB와 통합하여 개발한 독점 소프트웨어(오픈소스가 아닌 경우)를 네트워크 서버를 이용하여 유료 웹 서비스 하는 경우

* OEM (original equipment manufacturer)

판매 회사가 제품 생산 회사에 의뢰하여 반제품 또는 완제품을 납품받아 판매하는 경우 판매 회사가 요구하는 제품 상표로 제품을 출고하도록 하는 제조 및 생산. 어떤 제품이 상표에 나타난 회사와는 별도로 생산 납품한 원천 생산자가 있다는 의미로서 브랜드를 중요시하는 판매 회사와 생산에 전념할 수 있는 제조 회사의 역할 분담이 장점이다.   

----------------------------------------------------------------------------------------------------------- 

다음은 미국 자유소프트웨어감시단에서 운영하고 있는 GPL 라이센스 케이스별 질문 내용에 대한 모음 내용이 잘 정되된 자료가 있어 링크하오니 참조해 주십시오.

http://www.gnu.org/licenses/gpl-faq.html#GPLAndNonfreeOnSameMachine   <-- 번역본 주요 질문/답변

 

** GPL-3.0 사용자들이 잘못 알고 있는 사례 중에 가장 대표적인 내용은 GPL에서 제공하는 Source Code를

   수정하지 않고 바이너러리 코드 만 사용하면 본인들이 개발한 독점 소프트웨어의 소스 공개없이 공짜로 사용

    할 수  있다고 생각하는 점입니다. 이것은 GPL 라이센스에 대해 잘못 알고 있는 대표적인 사례입니다.

    GPL과 링크되어 개발되는 모든 애플리케이션은 GPL 라이센스가 되어야 하며 소스 전체를 반드시 공개해야

   합니다. 이와 관련된 gnu.org 관련 글은 다음과 같습니다.

 

Q. GPL 모듈에 제가 만든 모듈을 추가했을 경우에, 제가 만든 모듈에 대한 라이선스로 GPL을 사용해야만 합니까?

A. GPL은 결합된 프로그램 전체가 GPL로 공표될 것을 요구합니다. 따라서 여러분이 만든 모듈의 라이선스는 GPL이 되어야  합니다. 그러나 여러분이 만든 코드를 사용하는데 따른 보다 많은 허가 사항을 추가할 수는 있습니다. 만약 원하다면, GPL과  호환되는 보다 유연한 라이선스를 사용할 수 있습니다.

 

Q. 코드를 GPL 프로그램과 링크시켜야만 제가 만들고자 하는 독점 프로그램을 만들 수 있습니다. 이것은 제가 만든 프로그램이  GPL 프로그램이 되어야 한다는 것을 의미합니까?

A. 그렇습니다

Q. GPL은 개작된 버전의 소스 코드를 공중(公衆, 불특정 다수)에게 공개하도록 요구하고 있습니까?

A. GPL은 개작된 버전 각각이 모두 공표되도록 규정하고 있지 않습니다. 만약 여러분이 GPL 프로그램을 개작한 뒤에 개인적인  목적으로 사용하고 있다면 개작된 소스 코드를 공개하지 않아도 무방합니다. 이것은 개인뿐 아니라 단체나 법인, 기업에 대해서도 마찬가지입니다. 이 경우 해당 단체나 법인, 기업은 개작한 프로그램을 외부로 공표하지 않고 오직 내부적으로만 사용해야 합니다. 그러나 만약 어떠한 방식으로든지 개작된 버전을 공표하고 있다면, 사용자들이 개작된 버전의 소스 코드를 GPL에 따라 이용할 수 있도록 해야만 합니다.  따라서 GPL은 개작한 프로그램을 GPL이 규정한 방식에 따라서 공표할 수 있는 허가를 제공하는 것이며, 개작한 버전을 공표하느냐 마느냐는 여러분 자신의 선택에 달려 있습니다.

 

Q. GPL 소프트웨어를 독점 시스템 안에 통합시키고 싶습니다. 가능합니까?

A. GPL 소프트웨어는 독점 시스템 안에 통합될 수 없습니다. GPL의 목적은 모든 사람들에게 프로그램에 대한 학습과 개작, 복제와 재배포의 자유를 부여하기 위한 것입니다. 만약 GPL 프로그램을 자유 소프트웨어 시스템이 아닌 곳에 통합시킨다면, 그것은 GPL 소프트웨어를 자유 소프트웨어가 아닌 것으로 만드는 결과가 됩니다.

GPL 프로그램이 통합된 시스템은, GPL 프로그램이 확장된 것이라고 할 수 있습니다. GPL은 GPL 프로그램을 확장한 버전을 공표할 때 그 라이선스로 GPL을 사용해야 한다고 규정하고 있습니다. 여기에는 두가지 이유가 있습니다. 첫번째는 소프트웨어를 취득한 사용자로 하여금 그들이 가질 수 있는 자유를 알게 하려는 것이고, 두번째는 그들이 만든 개선점들을 공동체로 환원하도록 격려하기 위한 것입니다. 

그러나 많은 경우에 있어서, GPL 소프트웨어를 독점 시스템과 함께 배포할 수 있습니다. 이것이 가능하기 위해서는 GPL

프로그램과 그렇지 않은 프로그램들이 서로 결합되어 하나의 프로그램으로 작동하는 형태가 아니라 서로 독립적으로 실행되 거나 통신하는 형태가 되어야만 합니다.

 

 

 

 

 

    <생략> 

 

** 다음은 mongoDB.org에 있는 Apache 라이센스 관련 글입니다.(http://www.mongodb.org/about/licensing/)

"To make the above practical, we promise that your client application which uses the database is a separate work. To facilitate this, the mongodb.org supported drivers (the part you link with your application) are released under Apache license, which is copyleft free."

 

Apache-2.0 라이센스인 Drivers와 Link하여 Client용 Application을 개발하는 경우 MongoDB의 AGPL-3.0 라이센스와

상충되기 때문에 이 문제를 해결하기 위해 MongoDB는 Client Application을 Copyleft free로 규정하고 있으며 Client 프로그램의 소스를 공개하지 않아도 된다고 합니다.

GPL 3.0 라이센스와  결합되는 Apache-2.0 라이센스의 드라이브를 이용한 Client 애플리케이션의 소스를 공개할 의무가 없어진것 입니다. 하지만, Apache-2.0 라이센스를 사용하지 않은 3rd Party 드라이브와의 연동 시에는 필요에 따라 소스 공개 의무는 반드시 필요합니다. 또한, Apache-2.0 드라이브와의 연동으로 Client Application의 소스 공개 의무가 없다는 것이며 MongoDB와 결합된 소프트웨어는 반드시 Open Source이어야 하고 GPL-3.0에 대한 나머지 의무 사항은 지켜야 합니다. 또한, 3rd Party 드라이브나 직접 개발한 서버용 라이브러리(모듈)를 통해 MongoDB와 연동되고, Client Application과 연동된다면 이 경우에는 모든 소스를 공개해야 합니다. (잘 설명한 사이트가 있어 소개합니다 : http://cafe.naver.com/osslicense/25)  

다음은 이와 관련된 gnu.org 글 입니다.

두개의 라이선스가 호환(compatible) 된다는 말은 무슨 뜻입니까?

두개의 프로그램이나 핵심 부분들을 결합해서 보다 큰 저작물을 만들기 위해서는 두개의 프로그램을 사용하는데 따른 승인을 얻을 필요가 있습니다. 만약 두개의 프로그램에 대한 각각의 라이선스가 이러한 형태를 허용한다면 이들은 서로 호환되는 것입니다. 그러나 두개의 라이선스를 동시에 만족시킬 방법이 없다면, 이들은 서로 호환되지 않는 것입니다.

특정한 라이선스들은 프로그램 간의 결합이 이루어 지는 방식이 호환성 여부에 영향을 미칠 수 있습니다. 예를 들면, 두개의 모듈이 서로 링크되는 것은 허용하지만 이들을 하나의 모듈로 병합하는 것은 허용하지 않을 수도 있습니다.

 

* 라이센스의 양립성 ( http://www.olis.or.kr/ossw/license/open_source_guide.pdf  참조)

오픈소스SW 라이선스의 양립성 문제는 주로 GPL 조건의 엄격성 때문에 나타난다. GPL 3.0의 초안에서는 이러한 양립성 문제를 해결하기 위해 이용자들이 추가적인 제한∙허용 조건을 선택할 수 있도록 폭넓게 규정했었다. 예를 들어 특허보복조항의 포함여부, 네트워크서버 형태로 이용하는 경우 소스코드를 제공하게 할 것인지의 여부 등을 개별적으로 선택할 수 있도록 하였다. 그러나 GNU∙리눅스 배포판 업체들은 오픈소스SW 라이선스들의 증가와 그에 따른 양립성 문제는 인정하지만, 추가적인 제한 및 허용 규정에 의해 수많은 프로그램들이 서로 다른 GPL 조건들을 가질 경우, 라이선싱과 관련된 문제들이 더욱 복잡하게 될 것이라고 주장하였다. 이러한 비판을 어느 정도 수용하여 GPL 3.0에서는 특허보복조항을 제10조에 포함시키고, 네트워크 서버 형태의 이용과 관련해서는 제14조를 별도로 만드는 등 보다 단순화하였다. 또한 이러한 조치를 통해 GPL 3.0은 아파치 라이선스 2.0과 양립가능하며, 네트워크서버 형태로 이용하는 경우에도 소스코드를 제공하도록 요구하는 Affero GPL 3.0과도 양립가능하게 되었다.

 

* Apache License ( http://www.olis.or.kr/ossw/license/open_source_guide.pdf  참조) 

아파치 라이선스(Apache License)는 아파치 웹서버를 포함한 아파치 재단(ASF: Apache Software Foundation)의 모든 SW에 적용되는 라이선스로 BSD 라이선스와 비슷하여 소스코드 공개 등의 의무가 발생하지 않는다. 다만“Apache”라는 이름에 대한 상표권을 침해하지 않아야 한다는 조항이 명시적으로 들어가 있고, 특허권에 관한 내용이 포함되어 BSD 라이선스보다는 좀 더 법적으로 완결된 내용을 담고 있다. 특히 아파치 라이선스 2.0에서 특허에 관한 조항이 삽입되어 GPL 2.0으로 배포되는 코드와 결합하는 것이 어렵다는 문제가 었었는데, GPL 3.0에서는 이 문제를 해결하여 아파치 라이선스로 배포되는 코드가 GPL 3.0으로 배포되는 코드와 결합하는 것이 가능해졌다.

 

* GPL-3.0으로 구축된 웹 서비스의 경우에도 개발된 상업용 독점소프트웨어의 소스는 공개되어야 합니다.

  예를들어, MongoDB에 데이터를 저장하고 있는 게임 서비스, 웹 서비스 모두 해당됩니다.

  하지만, 앞서 설명했던것 처럼, 그것이 Apache-2.0 드라이브와 연동된 경우 예외 사항을 두어 소스 공개의

  무는 없게 됩니다. GPL-2.0과 GPL-3.0의 차이점 중에 하나는 Network Server를 통해 서비스하는

   경우 소 프트웨어의 소스 공개 여부에 대한 규정인데 MySQL의 경우 GPL-2.0이기 때문에 이 경우 소스 공개

   의무가 없었지만 GPL-3.0의 경우에는 반드시 소스 공개 의무가 있습니다.

  다음은 GPL-3.0 전문의 13번 내용입니다.

13. Remote Network Interaction; Use with the GNU General Public License.

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.

 

* 영문 주요 질문/답변 (http://www.gnu.org/licenses/gpl-faq.en.html)

Q.  I downloaded just the binary from the net.

     If I distribute copies, do I have to get the source and distribute that too? (#UnchangedJustBinary)

A.  Yes. The general rule is, if you distribute binaries, you must distribute the complete corresponding source code too. The exception for the case where you received a written offer for source code is quite limited.

 

Q. Can I release a modified version of a GPL-covered program in binary form only? (#ModifiedJustBinary)

A. No. The whole point of the GPL is that all modified versions must be free software—which means,

    in particular, that the source code of the modified version is available to the users.

 

Q.  If I use a piece of software that has been obtained under the GNU GPL, am I allowed to modify the original code into  a  new program, then distribute and sell that new program commercially? (#GPLCommercially)

    Thus, for instance, you must make the source code available to the users of the program as described in the GPL, and  they must be allowed to redistribute and modify it as described in the GPL.

    These requirements are the condition for including the GPL-covered code you received in a program of your own.

 

Q.   Can I link a GPL program with a proprietary system library? (#SystemLibraryException)

A. Both versions of the GPL have an exception to their copyleft, commonly called the system library exception. If the GPL- incompatible libraries you want to use meet the criteria for a system library, then you don't have to do anything special to use them; the requirement to distribute source code for the whole program does not include those libraries, even if you distribute a linked executable containing them.

    The criteria for what counts as a "system library" vary between different versions of the GPL. GPLv3 explicitly defines  "System Libraries" in section 1, to exclude it from the definition of "Corresponding Source." GPLv2 deals with this issue slightly differently, near the end of section 3.

 

감사합니다.