오픈소스 소프트웨어의 공통 프로토콜
LGPL 라이센스
LGPL 라이센스는 LESSER GENERAL PUBLIC LICENSE의 약어로, LIBRARY GENERAL PUBLIC LICENSE라고도 하며 중국어로 "Looser Public License" 또는 "기능 라이브러리"로 번역됩니다. 공개 라이센스". 이 라이선스는 자유 소프트웨어 재단과 이 라이선스를 사용하기로 결정한 기타 소프트웨어 작성자가 특별히 디자인한 일부 소프트웨어 패키지(예: 함수 라이브러리(라이브러리))에 적용됩니다. LGPL 라이센스는 Free Software Alliance GNU 오픈 소스 소프트웨어 라이센스의 한 유형이기도 합니다. 일부 기능 라이브러리를 포함한 대부분의 GNU 소프트웨어는 원래 GPL 라이센스로 보호됩니다. LGPL 라이센스는 특별히 설계된 기능 라이브러리에 적합하며 원래의 General Public License와는 매우 다릅니다. 라이센스 사용자에게 보다 편안한 권리를 부여하므로 "Leaser Public License" 인증서라고 합니다. 특정 라이브러리에서 이를 사용하여 비자유 프로그램이 해당 라이브러리와 링크되도록 허용합니다. 프로그램이 라이브러리에 연결되면 정적으로든 공유 라이브러리를 사용하든 두 가지의 조합은 원래 라이브러리의 파생물인 결합된 작업이라고 합리적으로 말할 수 있습니다. 따라서 원본 일반 공중 라이선스에서는 전체 조합이 자유 기준을 충족하는 경우에만 연결을 허용했습니다. Lesser General Public License를 사용하면 보다 완화된 표준에 따라 다른 프로그램 코드를 라이브러리에 연결할 수 있습니다. 예를 들어, 드문 경우지만 특정 라이브러리를 최대한 광범위하게 사용하도록 장려하여 사실상의 표준이 되는 특별한 요구 사항이 있을 수 있습니다. 이 목표를 달성하려면 비자유 프로그램이 라이브러리를 사용하도록 허용해야 합니다. 더 일반적인 상황은 무료 라이브러리가 널리 사용되는 비자유 라이브러리와 동일한 역할을 한다는 것입니다. 이 경우 무료 소프트웨어만 무료 라이브러리 사용을 제한하는 데에는 큰 이점이 없으므로 우리는 LGPL 라이센스를 사용합니다. 다른 경우에는 비자유 프로그램이 특정 라이브러리를 사용하도록 허용하면 더 많은 사람들이 자유 소프트웨어의 상당 부분을 사용할 수 있습니다. 예를 들어, 비자유 프로그램이 GNU C 라이브러리를 사용하도록 허용하면 더 많은 사람들이 전체 GNU 운영 체제와 그 변형인 GNU/Linux 운영 체제를 사용할 수 있게 됩니다. LGPL 라이센스는 사용자 자유에 대한 보호를 덜 제공하지만 이 라이브러리에 연결된 프로그램 사용자가 수정된 버전의 라이브러리를 사용하여 프로그램을 실행하는 데 필요한 자유와 필요한 수단을 보장합니다.
MPL 라이센스
MPL은 Mozilla Public License의 약어로, 1998년 초 Netscape의 Mozilla 팀이 오픈 소스 소프트웨어 프로젝트를 위해 설계한 소프트웨어 라이센스입니다. MPL 라이센스가 등장한 가장 중요한 이유는 Netscape가 GPL 라이센스가 소스 코드에 대한 개발자의 요구와 소스 코드를 사용하여 얻는 이점의 균형을 잘 맞추지 못한다고 믿기 때문입니다. 유명한 GPL 라이센스 및 BSD 라이센스와 비교할 때 MPL은 많은 권리와 의무에서 동일합니다(둘 다 OSIA 인정을 준수하는 오픈 소스 소프트웨어 라이센스이기 때문입니다). 그러나 이에 비해 MPL에는 다음과 같은 중요한 차이점이 있습니다. ◆ MPL에서는 MPL 라이선스에 따라 릴리스된 소스 코드에 대한 수정 사항을 MPL 라이선스에 따라 2차 라이선스를 부여하여 다른 사람이 소스 코드를 MPL 조건에 따라 공유할 수 있도록 해야 합니다. 그러나 MPL 라이선스에서 "릴리스"의 정의는 "소스 코드 형태로 릴리스된 파일"입니다. 이는 MPL을 통해 기업이 소스 코드의 소스 코드를 제외하고 기존 소스 코드 라이브러리에 인터페이스를 추가할 수 있음을 의미합니다. 인터페이스 프로그램 코드는 MPL 라이선스에 따라 라이선스가 부여되지만, 소스 코드 라이브러리의 소스 코드는 MPL 라이선스 없이 강제적으로 라이선스가 부여될 수 있습니다. 이로 인해 다른 사람의 소스 코드를 학습하고 이를 자신의 상용 소프트웨어 개발에 사용하는 행위에 공백이 생깁니다. ◆ MPL 라이선스 3조 7항은 라이선스 사용자가 MPL 라이선스를 통해 얻은 소스 코드를 다른 유형의 자체 코드와 혼합하여 자체 소프트웨어 프로그램을 얻을 수 있도록 허용합니다.
◆ 소프트웨어 특허에 대한 태도와 관련하여 MPL 라이센스는 GPL 라이센스와 같이 소프트웨어 특허에 대해 명시적으로 반대하지는 않지만, 소스 코드 제공자가 이미 특허로 보호되는 소스 코드를 제공하지 않을 것을 분명히 요구합니다. 이러한 소스 코드를 서면으로 무료로 대중에게 라이센스할 수 있으며, 오픈 소스 라이센스 형식으로 해당 소스 코드에 대한 라이센스를 부여한 후에는 해당 소스 코드와 관련된 특허를 신청할 수 없습니다. ◆ 소스 코드 정의 MPL(버전 1.1) 라이선스에서 소스 코드 정의는 다음과 같습니다. "소스 코드는 저작물을 수정하기 위해 가장 선호되는 형식을 의미하며, 여기에는 모든 모듈의 모든 소스 프로그램과 관련 인터페이스와 실행 가능한 작업의 설치 및 컴파일을 제어하는 '스크립트' 또는 원본 소스 코드와 크게 다르거나 공개 도메인에서 사용할 수 있는 소스 코드 기여자 프로그램 코드에 의해 선택된 소스 코드. ◆ MPL 라이선스 3조에는 소스코드 수정 설명에 관한 특별 조항이 있는데, 이는 모든 재배포자가 소스코드 프로그램을 수정하는 시기와 방법을 명시한 특별한 파일을 갖고 있어야 한다는 것입니다.
BSD 라이센스
BSD 라이센스는 원래 University of California, Berkeley에서 출시된 각 4.4BSD/4.4BSD-Lite 버전에 사용되었습니다(BSD는 Berkly Software Distribution의 약어입니다). , 이후 점차적으로 사용되었습니다. 1979년 캘리포니아대학교 버클리캠퍼스는 BSD 유닉스를 기반으로 개발된 오픈소스 코드의 선구자로 알려진 BSD 유닉스를 출시했다. BSD 라이센스는 이제 Apache 및 BSD 운영 체제와 같은 오픈 소스 소프트웨어에 채택되었습니다. GPL 라이선스와 MPL 라이선스의 엄격함에 비해 BSD 라이선스는 훨씬 완화되어 라이선스 원문만 첨부하면 되지만, 더 흥미로운 점은 이후의 모든 개발자에게도 저작권을 양도해야 한다는 점입니다. 거기에 데이터가 담겨 있기 때문에 BSD 라이선스로 소프트웨어를 출시할 때 작은 상황이 발생할 수 있습니다. 즉, 이러한 저작권 자료의 라이선스 공간이 프로그램보다 더 많은 공간을 차지합니다.
QPL 라이선스
QPL은 The Qt Public License의 약자로 노르웨이의 한 조직에서 만든 것입니다. QPL 라이센스의 기본 요구 사항은 소스 코드를 얻고, 소스 코드를 수정하고, 수정 사항을 원본 코드에서 분리하는 것입니다. 수정 사항은 작성자의 희망에 따라 새 버전으로 결합될 수 있습니다. 이는 동적 링크 라이브러리에 특히 중요한 원본 코드입니다. 오류는 누구나 수정할 수 있으며 이는 시스템 게시자에게 중요하며 수정된 소프트웨어는 기본 요구 사항을 충족하는 모든 오픈 소스 소프트웨어 라이선스에 따라 출시될 수 있습니다. QPL 라이센스.
QNCL 라이선스
QNCL 라이선스는 Qt Non Commercial License의 약자로 GPL 라이선스와 LGPL의 관계처럼 QPL 라이선스의 "형제 버전"입니다. 라이센스, QNCL 라이센스는 QPL 라이센스보다 더 엄격합니다. 수정 및 출시 규정 측면에서 QNCL 라이선스는 소프트웨어의 범위나 연결 측면에서 차이가 있습니다. QNCL 라이선스는 "응용 프로그램이 프로그램을 개발하고 프로그램의 일부 또는 다른 소프트웨어의 일부를 재사용하기 위해 QNCL 라이센스에 따라 소프트웨어 기능을 사용할 수 있는 권한을 제공하는 입구를 제공하는 경우 다음과 같이 규정합니다. 이는 QNCL 라이센스에 따른 소프트웨어의 사용으로 간주되며 해당 응용 프로그램은 QNCL 라이센스의 적용을 받습니다." QNCL 라이선스는 GPL 라이선스와 마찬가지로 이 라이선스에 따라 취득한 오픈소스 소프트웨어가 다른 라이선스 방식을 통해 비시스템 라이브러리 기능에 연결된 다른 소프트웨어와 함께 출시되는 것을 완전히 금지한다는 점에서 QPL 라이선스보다 더 엄격합니다. .
Common License
Common License의 정식 명칭은 Common Public License입니다. OSIA 오픈 소스 소프트웨어 라이선스 인증 표준의 전제를 충족한 후, 공통 라이선스에는 참고할 만한 몇 가지 세부 조항도 있습니다. ◆ 특허 승인이 명확해졌습니다.
일반적인 오픈소스 소프트웨어의 경우, 소스코드의 저작권자는 자신의 수정권, 복제권, 기타 저작권 권리를 대중에게 명확하게 허가하지만, 이를 바탕으로 공통 라이선스에서는 다음과 같은 사항도 명시합니다. 소스 코드에는 특허권이 포함되어 있으며, 소스 코드 특허권자는 대중에게 복사하고 사용할 수 있는 독점권을 부여합니다. ◆ 본 라이선스에 따라 획득한 소스 코드 및 수정된 소스 코드가 본 라이선스에 따라 게시될 수 있는 한, 소스 코드 및 수정된 소스 코드는 본 라이선스의 적용을 받지 않는 다른 유형의 코드와 결합되어 새로운 제품의 형태로 출시될 수 있음을 규정합니다. 이 라이센스의 요구 사항을 준수합니다. ◆ 특허 침해 소송 발생 등 라이센스가 종료되는 상황이 자세히 설명되어 있습니다. ◆ 본 라이선스에 따라 소스코드를 사용하는 사용자가 획득한 소스코드를 상업적 목적으로 적용하는 경우, 소스코드의 사용으로 인해 발생하는 모든 결과에 대해 책임을 져야 한다는 독립책임의 원칙을 명시하고 있습니다. 상업적 응용 프로그램에서 발생하는 모든 침해 소송에 대해 당사는 전적인 책임을 집니다. 이 조항은 매우 특별하며 대부분의 오픈 소스 소프트웨어 라이선스에는 이를 요구하지 않습니다.
IBM 라이센스
IBM 라이센스의 전체 이름은 IBM Public License입니다. OSIA 오픈 소스 소프트웨어 라이센스 인증 표준을 충족한다는 전제 하에 IBM 라이센스에는 다음과 같은 세부 조항도 포함되어 있습니다. ◆ 특허 허가가 명확합니다. 일반적으로 오픈 소스 소프트웨어는 소스 코드의 저작권 소유자가 자신의 수정 권한, 복제 권한 및 기타 저작권 권리를 대중에게 라이센스하지만, 이를 기반으로 IBM 라이센스는 다음과 같이 명시합니다. 소스 코드에는 특허권이 포함되어 있으며, 소스 코드 코드 특허권자는 대중에게 복사하고 사용할 수 있는 독점권을 부여합니다. ◆ 라이센스 요구사항에 맞게 소스코드를 공개 및 사용하지 않은 경우, 특허침해소송 등 라이센스가 종료되는 사유가 구체적으로 명시되어 있습니다. ◆ IBM 라이센스도 Common 라이센스와 마찬가지로 독립 책임의 원칙을 명시하고 있습니다. 즉, 본 라이센스에 따라 소스 코드를 사용하는 사용자가 상업적 목적으로 얻은 소스 코드를 사용하는 경우 나타나는 오류에 대해 책임을 진다는 것입니다. 상용 응용 프로그램의 사용으로 인해 발생하는 침해 소송에 대한 책임은 전적으로 당사에 있습니다.
Jabber 라이선스
Jabber 라이선스의 정식 명칭은 Jabber Open Source License로 미국 Jabber, Inc.에서 제공합니다. Jabber 라이센스는 소스코드 복사 및 배포 규정에 있어서 기본적으로 다른 라이센스와 동일하지만, 다음과 같은 세부 조항이 있습니다. ◆ 본 라이센스를 통해 얻은 소스코드 및 변형 소스코드는 다른 유형의 라이센스와 결합할 수 있습니다. 본 라이센스에 따라 얻은 소스 코드와 수정된 소스 코드가 본 라이센스의 요구 사항과 유사하고 이를 준수하는 다른 제품에서 사용될 수 있는 한, 본 라이센스의 적용을 받지 않는 코드를 새로운 제품의 형태로 출시합니다. OSI 인증을 받아 오픈 소스 소프트웨어 라이선스로 출시되었습니다. ◆ 소스코드를 대중에게 공개하는 데 걸리는 시간은 최소 12개월 이상이어야 한다고 명시했습니다. ◆ 제3자의 법적 권리 진술. 사용자가 본 라이센스를 통해 획득한 소스 코드 및 애플리케이션 프로그래밍 인터페이스가 한 당사자의 지적 재산권을 보유하고 있음을 발견한 경우, 소스 코드를 공개할 때 지적 재산권의 세부 사항을 명시하여 "법적"이라는 제목으로 별도의 진술을 해야 합니다. 권리 주장, 소스 코드 수신자에게 어떤 지적 재산권이 승인되었는지 알리고 소스 코드 수신자에게 지적 재산권 보유자에게 연락하는 방법을 알려줍니다. ◆ 라이센스에서 요구하는 소스 코드 공개 및 사용 실패, 특허 침해 소송 발생 등 라이센스가 종료되는 상황에 대한 세부 정보.
프로토콜 비교
BSD 오픈 소스 프로토콜
BSD 오픈 소스 프로토콜은 사용자에게 많은 자유를 제공하는 프로토콜입니다. 기본적으로 사용자는 "원하는 것은 무엇이든" 할 수 있으며 자유롭게 사용하거나, 소스 코드를 수정하거나, 수정된 코드를 오픈 소스 또는 독점 소프트웨어로 다시 출시할 수 있습니다. 하지만 "원하는 대로 한다"는 전제는 BSD 프로토콜을 사용하는 코드를 게시하거나 BSD 프로토콜 코드를 기반으로 자체 제품을 개발할 때 세 가지 조건을 충족해야 한다는 것입니다. ◆ 재발매된 제품에 소스가 포함된 경우 코드, 원본 코드의 BSD 프로토콜이 소스 코드에 포함되어야 합니다. ◆바이너리 클래스 라이브러리/소프트웨어만 재배포하는 경우 클래스 라이브러리/소프트웨어의 문서 및 저작권 설명에 있는 원본 코드에 BSD 프로토콜을 포함해야 합니다. ◆오픈소스 코드의 작성자/단체명, 원본 제품명을 마케팅 목적으로 사용하지 마십시오. BSD 코드는 코드 공유를 장려하지만 코드 작성자의 저작권은 존중되어야 합니다.
BSD는 사용자가 코드를 수정 및 재배포할 수 있도록 하고, BSD 코드를 사용하거나 이를 기반으로 개발된 상용 소프트웨어를 출시 및 판매할 수 있도록 하기 때문에 상업적 통합에 친화적인 프로토콜입니다. 많은 회사에서는 오픈 소스 제품을 선택할 때 BSD 프로토콜을 선호합니다. 왜냐하면 이러한 타사 코드를 완전히 제어할 수 있고 필요할 때 다시 수정하거나 개발할 수 있기 때문입니다.
MIT
MIT는 BSD와 동일한 광범위한 라이센스 계약으로, 저자는 다른 제한 없이 저작권만 보유하기를 원합니다. 즉, 바이너리로 배포하든 소스 코드로 배포하든 관계없이 배포판에 원래 라이센스 계약에 대한 설명을 포함해야 합니다. MIT 라이센스라고도 알려진 MIT 라이센스는 원래 MIT에서 개발되었습니다. 승인된 사람의 권리: 1. 승인된 사람은 소프트웨어 및 소프트웨어 사본을 사용, 복사, 수정, 병합, 게시, 배포, 재라이센스 부여 및 판매할 수 있는 권리가 있습니다. 2. 승인된 사람은 프로그램의 필요에 따라 승인 조건을 적절한 내용으로 수정할 수 있습니다. 라이센스 사용자의 의무: 저작권 표시와 라이센스 표시는 소프트웨어와 소프트웨어의 모든 사본에 포함되어야 합니다.
GNU GPL
우리에게 매우 친숙한 Linux는 GPL을 채택합니다. GPL 계약은 코드 재사용을 장려하는 BSD 및 Apache 라이센스와 같은 라이센스와 매우 다릅니다. GPL의 출발점은 오픈소스/코드의 자유로운 사용과 오픈소스/참조/수정/파생코드의 자유로운 사용이지만, 수정되고 파생된 코드는 비공개 소스 상용 소프트웨어로 공개 및 판매가 허용되지 않습니다. 그렇기 때문에 우리는 상업용 기업의 리눅스부터 개인, 조직, 상업용 소프트웨어 회사가 개발한 리눅스 상의 다양한 무료 소프트웨어까지 모든 종류의 무료 리눅스를 사용할 수 있습니다. GPL 계약의 주요 내용은 GPL 계약에 따른 제품이 소프트웨어에서 사용되는 한("사용"은 클래스 라이브러리 참조, 수정된 코드 또는 파생 코드를 의미함) 소프트웨어 제품도 GPL 계약을 채택해야 한다는 것입니다. 오픈 소스이고 무료여야 합니다. 이것을 "감염성"이라고 합니다. GPL 라이센스 제품을 별도의 제품으로 사용해도 문제가 없으며, 무료라는 장점도 누릴 수 있습니다. GPL은 GPL 클래스 라이브러리를 사용하는 소프트웨어 제품이 GPL 프로토콜을 사용해야 한다고 엄격히 요구하므로 GPL 프로토콜을 사용하는 오픈 소스 코드, 상용 소프트웨어 또는 코드 기밀 요구 사항이 있는 부서는 클래스 라이브러리의 기반으로 통합/채택하기에 적합하지 않습니다. 그리고 2차 개발. 재배포 시 GPL 계약을 동반해야 하는 등 기타 세부 사항은 BSD/Apache 등과 유사합니다.
GUN LGPL
LGPL은 주로 클래스 라이브러리와 함께 사용하도록 설계된 GPL의 오픈 소스 프로토콜입니다. GPL 클래스 라이브러리를 사용/수정/파생하는 모든 소프트웨어는 GPL 라이센스를 채택해야 하는 GPL과는 다릅니다. LGPL을 사용하면 상용 소프트웨어가 오픈소스 상용 소프트웨어의 코드 없이도 클래스 라이브러리 참조(링크)를 통해 LGPL 클래스 라이브러리를 사용할 수 있습니다. 이를 통해 LGPL 라이선스를 사용하는 오픈 소스 코드를 상용 소프트웨어에서 클래스 라이브러리로 참조하고 출시 및 판매할 수 있습니다. 다만, LGPL 규약의 코드나 파생물을 수정하는 경우에는 모든 수정코드, 수정된 부분이 포함된 추가코드, 파생코드 모두 LGPL 규약을 채택해야 합니다. 따라서 LGPL 프로토콜의 오픈소스 코드는 상용 소프트웨어에서 제3자 클래스 라이브러리로 참조되기에는 매우 적합하지만, LGPL 프로토콜 코드를 2차 개발을 위한 기반으로 사용하려는 상용 소프트웨어에는 적합하지 않습니다. 수정 및 파생물. GPL/LGPL은 모두 원본 작성자의 지적 재산권을 보호하고 다른 사람이 오픈 소스 코드를 사용하여 유사한 제품을 복사하고 개발하는 것을 방지합니다.
Apache 라이선스 2.0
Apache 라이선스는 잘 알려진 비영리 오픈 소스 조직인 Apache에서 채택한 프로토콜입니다. 이 계약은 BSD와 유사하며 코드 소유자가 원저작자의 저작권을 공유하고 존중하도록 권장하며 코드 수정 및 재배포(오픈 소스 또는 상용 소프트웨어)도 허용합니다. 충족해야 하는 조건은 BSD와 유사합니다. ◆코드 사용자에게 Apache 라이센스가 부여되어야 합니다. ◆코드를 수정하는 경우 수정된 파일에 명시해야 합니다. ◆확장 코드(소스 코드에서 수정 및 파생된 코드)에는 원저작자가 명시한 계약, 상표, 특허 설명 및 기타 지침이 원본 코드에 포함되어야 합니다.
◆재출시 제품에 공지사항 파일이 포함된 경우 공지사항 파일에 아파치 라이센스가 포함되어 있어야 합니다. 통지에 자신의 라이센스를 추가할 수 있지만 이것이 Apache 라이센스에 대한 변경으로 나타날 수는 없습니다. Apache 라이선스는 상용 애플리케이션에도 적합한 라이선스입니다. 사용자는 필요할 때 필요에 맞게 코드를 수정하고 오픈 소스 또는 상용 제품으로 게시/판매할 수도 있습니다.