멀티 라이선스

Multi-licensing
다중 라이선스 Wikipedia 콘텐츠 프로젝트 페이지는 Wikipedia를 참조하십시오.멀티 라이선스

멀티 라이선스는 두 개 이상의 다른 계약 조건에 따라 소프트웨어를 배포하는 관행입니다.이것은, 복수의 다른 소프트웨어 라이센스 또는 라이센스 세트를 의미할 가능성이 있습니다.프리픽스는, 사용되는 라이센스의 수를 나타내기 위해서 사용할 수 있습니다.예를 들면, 2개의 다른 라이센스로 라이센스가 부여된 소프트웨어의 경우는, 듀얼 라이센스입니다.

소프트웨어가 복수 라이선스의 경우 일반적으로 수신자는 소프트웨어를 사용하거나 배포할 조건을 선택할 수 있지만 소프트웨어 패키지 또는 라이브러리에 여러 라이선스가 있다고 해서 수신자가 어느 한쪽을 자유롭게 선택할 수 있는 것은 아닙니다.경우에 따라서는, 특히 소프트웨어에 복수의 송신원이 있는 경우는, 부속의 모든 라이센스가 동시에 적용됩니다.다른 라이선스의 적용 여부는 개별적으로 [according to whom?]확인해야 합니다.디스트리뷰터는 어느 [citation needed]옵션에도 요금을 적용할 수도 있고 적용하지 않을 수도 있습니다.멀티 라이선스의 일반적인 두 가지 동기는 라이선스[1] 호환성과 시장 분리 기반의 비즈니스 [2]모델입니다.

비즈니스 모델

멀티 라이선스는 일반적으로 상용 환경에서 무료 소프트웨어 비즈니스 모델을 지원하기 위해 이루어집니다.이 시나리오에서 한 가지 옵션은 독점 소프트웨어 라이센스이며, 다른 한 가지 옵션은 이 라이센스로부터 파생된 독점 애플리케이션을 생성할 수 있는 반면, 다른 한 가지 옵션은 카피레프트 자유 소프트웨어/오픈 소스 라이센스이므로 파생된 모든 작업을 동일한 라이센스로 릴리스해야 합니다.그 후, 소프트웨어의 저작권자는 통상, 소프트웨어의 무료 버전을 거의 또는 무상으로 제공하고, 그 소프트웨어를 자신의 비즈니스에 짜넣으려고 하는 상업적인 사업체에 독점 라이센스를 판매함으로써 이익을 얻는다.이 모델은 쉐어웨어와 [3][4]비교할 수 있습니다.

대부분의 경우 소프트웨어의 라이센스 조건을 변경할 수 있는 것은 저작권자뿐이므로 멀티 라이선스는 라이선스를 취득하는 소프트웨어를 완전히 소유하고 있는 기업에 의해 주로 사용됩니다.사내외의 담당자가, 제한이 적은 라이센스를 사용해 추가의 소스 코드를 작성하면, 혼란이 생기는 일이 있습니다.공식 코드를 가진 회사는 추가 코드의 저작권자가 아니기 때문에, 그들은 법적으로 이 신작을 더 제한적으로 라이선스된 버전에 포함시키지 않을 수 있습니다.기업은 공식 코드베이스 및 소스 코드 [5]저장소에서의 작업을 수락하기 전에 외부 개발자에게 기여자 라이센스 계약에 동의하도록 요구할 수 있습니다.

멀티 라이선스는 카피레프트 자유 소프트웨어 라이선스와 비자유 소프트웨어 라이선스를 모두 사용하여 배포하겠다는 의사를 광고하는 일부 자유 소프트웨어 패키지의 저작권자에 의해 사용됩니다.후자의 라이센스는 일반적으로 사용자에게 소프트웨어를 독점 소프트웨어로서 제공하거나 카피레프트 조항 없이 제3자에게 소스 코드를 제공합니다.이 시나리오에서는 저작권 소유자는 저작권에 따라 제공되는 독점권을 행사하고 있지만 여러 라이선스를 사용하여 여러 수신자가 받는 권리와 자유를 구분합니다.

이러한 라이선스를 통해 소유자는 모든 사용자에게 무료 버전의 소프트웨어를 제공하면서 커스터마이즈 및 초기 릴리스를 제공하거나 다른 파생 버전을 생성하거나 제3자에게 독점 버전을 재배포할 수 있는 권한을 부여할 수 있습니다.패키지를 카피레프트 프리 소프트웨어로 공유하면, 프리 소프트웨어 커뮤니티의 유저나 해커로부터 기부를 받아 저작권자에게 이익이 됩니다.이러한 기여는 전용 사용자 커뮤니티의 지원, 입소문 마케팅 또는 카피레프트 라이선스에 규정된 수정이 될 수 있습니다.그러나 저작권자가 카피레프트 조항을 배제하고 독점적 재배포를 광고하는 것은 자유 소프트웨어 [6][7]사용자의 신뢰와 지원을 잃을 위험이 있습니다.

멀티 라이선스 소프트웨어의 예로는 Oracle의 NetBeans IDE, MySQL AB의 데이터베이스, Asterisk, Oracle Corporation의 Berkeley DB, Modelio, ZeroC의 Ice, Magnolia CMS, JUCE, wolfSSL [8]및 Qt Software의 Qt 개발 툴킷이 있습니다.

멀티 라이선스를 설명하기 위한 구체적인 예에 대해 설명합니다.Oracle MySQL은 다양한 에디션으로 제공됩니다.MySQL Enterprise[9] Edition은 상용 에디션이므로 구입해야 합니다.라이센스는 MySQL Enterprise Edition Subscription이라는 이름의 구독으로만 제공됩니다.MySQL Standard Edition(MySQL Standard Edition Subscription) 및 MySQL Cluster CGE(MySQL Cluster Carrier Grade Edition Subscription)에도 동일한 사항이 적용됩니다.MySQL Classic Edition 또는 MySQL Community Edition과 같은 다른 에디션은 몇 가지 제한 사항이 있지만 무료로 사용할 수 있습니다.예를 들어 MySQL Community Edition은 무료로 다운로드할 수 있는 버전으로 GPL 라이선스로 제공되며 오픈 소스 [10]개발자 커뮤니티에서 지원됩니다.

단일 벤더의 상용 오픈 소스 비즈니스 모델

싱글벤더 커머셜 오픈소스라는 용어는 2010년 Dirk Riehle에 의해 만들어졌으며,[11][12] 이후 Simon R. B. [13]Berdal과 같은 다른 학자들에 의해 더욱 대중화되었다.

Riehle에 따르면:

단일 벤더의 상업용 오픈 소스 기업은 오픈 소스 소프트웨어 프로젝트를 중심으로 비즈니스를 구축합니다.오픈 소스 소프트웨어 프로젝트는 완전히 제어되며, 일반적으로 소프트웨어를 개발하여 서드파티와 공유 제어하지 않습니다.이는 코드 및 특허 및 상표와 같은 관련 지적 재산에 대한 완전한 저작권을 소유함으로써 이루어집니다.일반적으로 무료 오픈 소스 양식은 GPL과 같은 상호 라이선스에 따라 제공되므로 채택을 촉진하지만 경쟁업체를 저지할 수 있습니다.유료 버전의 소프트웨어는 기존의 소프트웨어 벤더와 마찬가지로 상용 라이선스로 제공됩니다.이는 상용 오픈 소스의 이중 라이선스 전략이라고도 합니다.[11]

기존 오픈 소스 프로젝트와 달리 단일 [11]벤더의 상용 오픈 소스 프로젝트는 상업적으로 활용할 목적으로 정확히 한 명의 이해관계자에 의해 제어됩니다.이러한 맥락에서 오픈 소스 커뮤니티는 일반적으로 기존의 (순수한) 오픈 소스 프로젝트에 있기 때문에 핵심 기능의 개발에 덜 관여합니다.MySQL의 당시 CEO인 Mörten Mikos는 인터뷰에서 다음과 같이 말했다.

기여의 깊이는 제품과 상황에 따라 다릅니다. 데이터베이스 엔진의 핵심을 깊이 파고들수록, 배우는 데 5년이 걸리기 때문에 누군가가 기여하는 것은 더 어려워집니다. 커널 외곽에 무언가를 구축하면(그 위에 추가하는 툴이나 기능) 제품 전체를 망칠 위험이 적기 때문에 훨씬 쉬워집니다. 하지만 많은 작은 것 같은 기고에서 뭔가 대단한 것이 나올 수 있다. 그것은 경제 발전에서 마이크로 대출이 어떻게 그렇게 큰 영향을 미칠 수 있는지와 유사합니다. 각 엔트리는 미미하지만, 관련된 사람들의 수를 곱하면, 그것은 엄청나게 커집니다. 저절로 [14]탄력을 받기 시작하는데..

따라서 멀티 라이선스소프트웨어 커뮤니티에는 원칙적으로 코드 소유 회사의 직원뿐만 아니라 소프트웨어에 대한 기득권을 가진 전략적 파트너도 포함됩니다.Riehle씨가 지적했듯이, 단일 벤더 오픈 소스에서 핵심 제품 개발 작업은 거의 모두 상업 회사에 의해 수행되며,[11] 커뮤니티로부터 가끔 기부도 받습니다.

Berdal이 지적한 바와 같이 오픈 소스 커뮤니티의 거버넌스는 다음과 같은 맥락에서 중요한 비즈니스 관리 프로세스가 됩니다.따라서 다른 비즈니스 활동과 연계할 필요가 있습니다. 따라서 이중 라이선스 OSS판의 거버넌스 모델은 상업적 편중 경향을 보일 수 있다. 따라서 커뮤니티가 도발당하거나 소외되는 것을 막기 위해서는 상업적 성향과 "개방적"[13] 이익의 균형을 맞추는 것이 필수적으로 보일 수 있다.이것은 결코 쉬운 일이 아니다.SugarCRM의 사례 연구를 통해 Berdal이 입증한 바와 같이, 이 상용 오픈 소스 소프트웨어(COSS) 비즈니스 모델은 상당한 마찰점을 유발하고, 결과적으로 순수 오픈 소스 포크로 이어질 수 있습니다(Berdal, 표 3, 75페이지[13]).

마찰점 COSS/SugarCRM의 관점 반대되는 FOSS 관점
저작권 할당 이중 라이선스의 전제 조건.이 조건이 없으면 비즈니스 모델은 상업적으로 지속 가능하지 않습니다. (일부) 사적으로 가는 것에 대한 두려움 때문에 기부 의욕을 잃었습니다.자유 소프트웨어 순수주의자: "도덕적"
Sugar CE의 가치 주도 기능 보류 1) OSS 클론에 대한 선제적 경쟁 우위, 2) 상용판의 가격 차별 및 제품 차별화 범위 확대, 3) Sugar CE 사용자의 상용판 이행 인센티브 강화. "크리플웨어" / 손상품, "오픈코어"잠재적으로 독점적 사용에 대한 확신이 부족하기 때문에 기부 의욕을 잃었습니다.
"Powered by Sugar CRM" 로고 1) 공식 입장:투자된 저작물에 대한 정당한 저작자의 귀속.확인은 되지 않았지만 매우 설득력이 있습니다. 2) 브랜드 프로모션, 3) 포킹 시도를 방해하거나 불필요한 외부 코드 재사용을 억제합니다. "나쁜 소프트웨어"특히 SugarCRM 상표 정책과 결합되어 있는 경우 기본 FOSS 원칙 위반.
COSS 규격에 따라 제한되는 '폐쇄적' 거버넌스 1) 고객의 요구를 효율적으로 충족시키기 위한 관리 제어 필요.

2) 투기적: 상업적으로 유도되는 개발 과정에 방해가 될 수 있는 FOSS 매니아와 자경단원의 영향을 줄인다.

지나치게 제한적이고 절차상의 공정성이 결여되어 있습니다.공유 Sugar CE 코드 베이스에 실질적인 영향은 없습니다.오픈 소스일 필요는 없는 소규모 주변기기를 보완하기 위한 사실상의 강등.
상업적으로 제휴한 커뮤니티 구성원과 제3자 우대 SugarCRM의 제품 플랫폼에 대한 상업적 기득권을 활용하고 강화하기 위한 차별화의 합리적인 보완 접근법.이는 1) 파트너와의 역량의 공동 진화를 통해 기업의 판매 채널을 강화하고 2) 수요 주도의 모듈러 보완체(확장, 플러그인 등)의 커스터마이즈와 개발을 촉진하며 3) 제품 플랫폼의 전체적인 가치를 높이는 네트워크 효과를 유발한다. 불충분한 분배 공정성(초점 및 우선순위 측면에서)루프에 관여하지 않는 것을 인식합니다.

이러한 마찰점이 관찰된 지 불과 몇 달 후에 SugarCRM Community Edition의 새로운 포크가 발표되었습니다.

라이선스 호환성

주요 기사:라이선스 호환성

프리 소프트웨어와의 멀티 라이선스의 두 번째 용도는 라이선스 [1]호환성을 위해 라이선스가 다른 프리 소프트웨어 프로젝트의 코드를 조합하거나 사용자가 라이선스를 선택할 수 있도록 하는 것입니다.

(GPL)2.0또는 GNU약소 일반 공중 사용 허가서 후자 GPL-compatible MPL2.0으로 격상되기 전에, tri-l를 만들고 2.1[15](LGPL)예로는 모질라 애플리케이션 스위트이며 이전에 모질라 선더버드 및 모질라 파이어 폭스의 tri-licensing은 모질라 퍼블릭 라이센스 하에 1.1(MPL)사용했던 소스 코드이고, GUN제너럴 퍼블릭 라이센스 포함한다.icen불필요하게 [16]노래하다다른 예로는 GPL 또는 Artistic [17]License에 따라 듀얼 라이선스가 부여된 Perl과 명시적인 GPL 듀얼 라이선스가 포함된 Ruby가 있습니다.

독점 소프트웨어 시장 구분

멀티 라이선스는 무료가 아닌 소프트웨어의 디스트리뷰터에서도 사용되고 있습니다.때로는 시장을 분리하기 위해 독점 소프트웨어에 대해 이 작업을 수행하기도 합니다.홈 유저, 프로 유저, 아카데믹 유저 등, 고객을 복수의 카테고리로 분할하는 것으로, 저작권자는 그룹 마다 다른 가격을 설정할 수 있습니다.다만, 독자적인 소프트웨어 기업에서는, 라이센스 뿐만이 아니라, 부속의 소프트웨어와 소프트웨어의 기능에 의해서도 다른, 특정의 제품의 「홈 에디션」과 「프로패셔널 에디션」을 발매하는 것이 일반적입니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b Nikolai Bezroukov (2001). "Comparative merits of GPL, BSD and Artistic licences (Critique of Viral Nature of GPL v.2 - or In Defense of Dual Licensing Idea)". Archived from the original on December 22, 2001. Viral property stimulates proliferation of licenses and contributes to the "GPL-enforced nightmare" -- a situation when many other licenses are logically incompatible with the GPL and make life unnecessary difficult for developers working in the Linux environment (KDE is a good example here, Python is a less known example).
  2. ^ Ronacher, Armin (July 23, 2013). "Licensing in a Post Copyright World". lucumr.pocoo.org. Retrieved November 18, 2015. The AGPLv3 was a terrible success, especially among the startup community that found the perfect base license to make dual licensing with a commercial license feasible. MongoDB, RethinkDB, OpenERP, SugarCRM as well as WURFL all now utilize the AGPLv3 as a vehicle for dual commercial licensing. The AGPLv3 makes that generally easy to accomplish as the original copyright author has the rights to make a commercial license possible but nobody who receives the sourcecode itself through the APLv3 inherits that right. I am not sure if that was the intended use of the license, but that's at least what it's definitely being used for now.
  3. ^ Linux 뉴스:테크니컬 버즈:듀얼 라이선스:케익과 함께 먹는 것
  4. ^ 듀얼 라이선스 오픈 소스 비즈니스 모델 Linux
  5. ^ Digium Incorporated. "Asterisk Guidelines, The contributor license agreement". Retrieved February 10, 2009.
  6. ^ Netscape Public License - GNU 프로젝트 - Free Software Foundation (FSF)
  7. ^ Apple Public Source License(APSL)에 대한 FSF의 의견 - GNU Project - Free Software Foundation(FSF)
  8. ^ "wolfSSL Embedded SSL/TLS Library Now Supporting TLS 1.3". Retrieved January 27, 2020.
  9. ^ "My SQL Enterprise Edition". Oracle. Retrieved April 25, 2013.
  10. ^ "MySQL Community Edition". Oracle, MySQL. Retrieved April 25, 2013.
  11. ^ a b c d The Single-Vendor Commercial Open Source Business Model, November 9, 2010, retrieved December 8, 2013
  12. ^ Riehle, Dirk (March 2012). "The single-vendor commercial open source business model". Information Systems and E-Business Management. 10 (1): 5–17. doi:10.1007/s10257-010-0149-x.
  13. ^ a b c Berdal, S.R.B. (January 2013). "Peculiarities of the Commercial Open Source business model: Case study of SugarCRM". 112. Tronheim, Norway.
  14. ^ "The Oh-So-Practical Magic of Open-Source Innovation". MIT Sloan Management Review. 50 (1). October 1, 2008. Retrieved December 8, 2013.
  15. ^ Mozilla Foundation. "Mozilla Code Licensing". Retrieved September 17, 2007.
  16. ^ "MPL 2 Upgrade". Retrieved August 18, 2012.
  17. ^ The Perl Foundation. "Perl Licensing - perl.org". Retrieved September 17, 2007.

외부 링크