LGPL 라이센스는 느슨한 일반 공용 라이센스 (LESSER GENERAL PUBLIC LICENSE) 의 약어로 라이브러리 일반 공용 라이센스 (LIBRARY GENERAL PUBLIC LICENSE) 라고도 하며 중국어는 "비교적 느슨한 공용 라이센스" 또는 "공용 라이브러리 라이센스" 로 번역됩니다 본 사용권은 프리랜서 소프트웨어 재단 및 본 사용권을 사용하기로 결정한 기타 소프트웨어 작성자가 특별히 설계한 소프트웨어 패키지 (예: 라이브러리) 에 적용됩니다. LGPL 라이센스는 자유 소프트웨어 연합의 GNU 오픈 소스 소프트웨어 라이센스이기도 합니다. 일부 라이브러리를 포함한 대부분의 GNU 소프트웨어는 원본 GPL 라이센스로 보호됩니다. LGPL 라이센스는 특별히 설계된 라이브러리에 적용되며, 원래의 일반 공용 라이센스와는 달리 라이센스 사용자에게 보다 느슨한 권리를 부여하여 "더 느슨한 공용 라이센스" 라고 합니다. 특정 라이브러리에서 사용하면 자유 프로그램이 이러한 라이브러리에 연결할 수 있습니다. 프로그램이 라이브러리에 연결되어 있을 때 정적 링크든 라이브러리를 사용하든 이 둘의 결합은 조합 작품으로, 원본 라이브러리의 파생물이라고 합리적으로 말할 수 있습니다. 따라서 초기 범용 공용 라이센스는 전체 조합이 자유 표준을 충족하는 경우에만 링크를 허용합니다. 좀 더 느슨한 범용 공용 라이센스를 통해 다른 프로그램 코드를 보다 느슨한 표준으로 본 라이브러리에 연결할 수 있습니다. 예를 들어, 경우에 따라 특정 라이브러리를 최대한 광범위하게 사용하도록 장려하여 실용적인 표준으로 만들 수 있는 특별한 필요성이 있을 수 있습니다. 이 목표를 달성하기 위해서는 비자유 프로그램이 이 라이브러리를 사용할 수 있도록 허용해야 한다. 프리랜서와 널리 사용되는 프리랜서 라이브러리가 같은 일을 하는 것은 흔한 상황이다. 이 경우 이 프리랜서 라이브러리 사용을 프리랜서 소프트웨어로 제한하면 큰 이점이 없으므로 LGPL 라이센스를 사용합니다. 다른 경우에는 자유프로그램이 특정 라이브러리를 사용할 수 있도록 허용하면 더 많은 사람들이 대부분의 자유 소프트웨어를 사용할 수 있습니다. 예를 들어, 자유프로그램이 GNU C 라이브러리를 사용할 수 있도록 허용하면 더 많은 사람들이 전체 GNU 운영 체제와 그 변종 GNU/Linux 운영 체제를 사용할 수 있습니다. LGPL 라이센스는 사용자에 대한 자유 보호가 적지만 이 라이브러리에 연결된 프로그램의 사용자가 자유로울 수 있도록 하며 라이브러리의 수정된 버전이 있는 프로그램을 실행하는 데 필요한 방법이 필요합니다.

MPL 라이센스

MPL 은 Mozilla Public License 의 약어로 1998 로 시작하는 넷스케이프 Mozilla 팀이 오픈 소스 소프트웨어 프로젝트를 위해 설계한 소프트웨어 라이센스입니다. MPL 라이센스가 나타나는 가장 중요한 이유는 GPL 라이센스가 소스 코드에 대한 개발자의 요구와 소스 코드 사용에서 얻은 이익의 균형을 잘 맞추지 못한다는 것입니다. 유명한 GPL 라이센스 및 BSD 라이센스에 비해 MPL 은 OSIA 가 인정한 오픈 소스 소프트웨어 라이센스이기 때문에 권리와 의무의 여러 측면에서 동일합니다. 그러나 MPL 에 비해 몇 가지 중요한 차이점이 있습니다. ◆ MPL 은 MPL 라이센스로 발급된 소스 코드의 수정을 MPL 라이센스로 재라이센스하여 다른 사람이 MPL 조항에 따라 소스 코드를 즐길 수 있도록 해야 합니다. 그러나 MPL 라이센스에서' 배포' 는' 소스 코드에 의해 배포된 파일' 로 정의됩니다. 즉, MPL 을 통해 기업은 기존 소스 코드를 기반으로 인터페이스를 추가할 수 있습니다. 인터페이스 프로그램의 소스 코드가 MPL 라이센스로 외부라이센싱되는 것 외에도 소스 코드 라이브러리의 소스 코드는 MPL 라이센스 없이 외부라이센싱을 강제할 수 있습니다. 이것들은 모두 자신의 상용 소프트웨어 개발을 위해 다른 사람의 소스 코드를 참고하는 공백을 남겼다. ◆MPL 라이센스 제 3 조 제 7 항은 정식 사용자가 MPL 라이센스를 통해 얻은 소스 코드를 다른 유형의 자체 코드와 혼합하여 자체 소프트웨어 프로그램을 얻을 수 있도록 합니다. ◆ 소프트웨어 특허에 대한 태도에 대해 MPL license 는 GPL license 처럼 소프트웨어 특허에 대한 반대를 분명히 밝히지 않았지만, 소스 코드 공급자가 이미 특허로 보호되는 소스 코드를 제공할 수 없도록 명시적으로 요구하고 있습니다 (특허권자가 아닌 경우 서면으로 이러한 소스 코드를 대중에게 무료로 허가하는 경우). 오픈 소스 라이센스로 허가한 후 이러한 소스 코드와 관련된 특허를 신청할 수 없습니다. ◆ 소스 코드의 정의 MPL (version 1. 1) 라이센스의 소스 코드는 다음과 같이 정의됩니다 MPL 라이센스 제 3 조는 소스 코드 수정을 설명하는 특별한 규정이 있습니다. 즉, 모든 재발행자에게 소스 코드 프로그램의 수정 시기와 방법을 설명하는 특별한 파일이 있어야 합니다.

BSD 라이센스

BSD 라이센스는 원래 UC 버클리에서 출판된 다양한 4.4BSD/4.4BSD-Lite 버전 (BSD 는 Berkly Software Distribution 의 줄임말) 에 사용되었으며 이후 점차 사용되고 있습니다. 1979 년 캘리포니아 대학 버클리 분교에서 오픈 소스 코드의 선구자로 꼽히는 BSD Unix 를 발표했습니다. BSD Unix 로 개발된 BSD 라이센스입니다. BSD 라이센스는 현재 Apache 및 BSD 운영 체제와 같은 오픈 소스 소프트웨어에 의해 채택되고 있습니다. GPL 라이센스 및 MPL 라이센스의 엄격함에 비해 BSD 라이센스는 훨씬 느슨합니다. 원래 라이센스만 첨부하면 됩니다. 하지만 흥미로운 점은 모든 추가 개발자가 자신의 저작권 자료를 위에 올려야 한다는 것입니다. 따라서 BSD 라이센스를 받아 배포할 수 있는 소프트웨어는 프로그램보다 더 많은 공간을 차지할 수 있습니다.

QPL 라이센스

QPL 은 노르웨이 조직에서 만든 Qt 공공 라이센스의 약어입니다. QPL 라이센스의 기본 요구 사항은 소스 코드를 획득하고, 소스 코드를 수정하고, 수정 사항을 원본 코드에서 분리하는 것입니다. 수정은 저자의 뜻에 따라 새 버전으로 결합할 수 있다. 이진 코드는 원본 코드와 이름이 같을 수 있습니다. 이는 동적 링크 라이브러리에 특히 중요합니다. 누구나 오류를 수정할 수 있습니다. 이는 시스템 게시자에게 매우 중요합니다. 수정된 소프트웨어는 QPL 라이센스의 기본 요구 사항을 충족하는 오픈 소스 소프트웨어 라이센스에 따라 배포할 수 있습니다.

QNCL 라이센스

QNCL 라이센스는 Qt 비상업용 라이센스의 약어이며 QPL 라이센스의 "형제 버전" 입니다. GPL 라이센스와 LGPL 라이센스의 관계와 마찬가지로 QNCL 라이센스는 QPL 라이센스보다 더 엄격합니다. 수정 및 배포와 관련하여 QNCL 라이센스는 QPL 라이센스와 동일하지만 소프트웨어의 범위 또는 연결이라는 점이 다릅니다. QNCL 라이센스는 "QNCL 라이센스에 따라 해당 소프트웨어의 기능 개발 프로그램을 사용하거나 프로그램의 일부 또는 다른 소프트웨어의 일부를 재사용할 수 있는 포털을 제공하는 경우 해당 애플리케이션의 사용은 QNCL 라이센스에 따라 소프트웨어를 사용하는 동작으로 간주되며 QNCL 라이센스의 적용을 받아야 합니다." 라고 규정하고 있습니다. QNCL 라이센스는 GPL 라이센스와 마찬가지로 이 라이센스에서 획득한 오픈 소스 소프트웨어가 다른 비시스템 라이브러리 기능 관련 소프트웨어와 함께 배포되는 것을 완전히 금지하므로 QNCL 라이센스는 QPL 라이센스보다 더 엄격합니다.

일반 라이센스

일반 라이센스의 전체 이름은 일반 공용 라이센스입니다. OSIA 오픈 소스 소프트웨어 라이센스 인증 기준을 충족한 후, 일반 라이센스에는 ◆ 특허 라이센스 정의 등 몇 가지 자세한 조항이 있습니다. 일반 오픈 소스 소프트웨어에는 수정권, 복사권 등 저작권을 대중에게 허가하는 명시적인 소스 코드 저작권 소유자가 있지만 서명권은 보류하고 있습니다. 이에 따라 공동허가는 소스 코드에 특허권이 포함되어 있는 경우 소스 코드 특허권자가 복제 및 사용에 대한 독점적 권리를 대중에게 허가한다는 점도 명시하고 있다. ◆ 소스 코드와 수정된 소스 코드는 본 라이센스에 구속되지 않는 다른 유형의 코드와 결합하여 신제품으로 배포할 수 있습니다. 단, 본 라이센스에 의해 획득한 소스 코드와 수정된 소스 코드를 본 라이센스의 요구 사항에 따라 배포할 수 있습니다. ◆ 특허 침해 소송의 발생을 포함한 허가 해지 상황을 상세히 설명했다. 본 라이센스에 따라 소스 코드를 사용하는 사용자가 얻은 소스 코드를 상업적 용도에 적용할 경우 해당 소스 코드 프로그램의 상업적 사용으로 인한 침해 소송에 대한 전적인 책임을 져야 한다는 독립 책임의 원칙을 명확히 했습니다. 이 규정은 상당히 특수하며, 대부분의 오픈 소스 소프트웨어 라이센스는 그렇게 할 필요가 없다.

Ibm 공용 라이센스

IBM 라이센스의 전체 이름은 IBM 공용 라이센스입니다. OSIA 오픈 소스 소프트웨어 라이센스 인증 기준을 충족하는 경우 IBM 라이센스에는 ◆ 명시적 특허 라이센스도 있습니다. 일반 오픈 소스 소프트웨어는 소스 코드의 저작권 소유자가 자신의 수정권, 복사권 등 저작권을 대중에게 허가하지만 서명권은 유보한다고 분명히 밝혔다. 이에 따라 IBM 라이센스는 소스 코드에 특허권이 포함되어 있는 경우 소스 코드 특허권자가 복제 및 사용하는 독점 권리를 대중에게 허가한다고 명시합니다. ◆ 라이센스 요구 사항에 따라 소스 코드, 특허 침해 소송 등을 배포하고 사용하지 않는 등 라이센스의 종료를 자세히 설명합니다. 일반 라이센스와 마찬가지로 IBM 라이센스도 독립 책임 원칙을 명확히 합니다. 즉, 라이센스에 따라 소스 코드를 사용하는 사용자가 얻은 소스 코드를 상업적 용도에 적용할 경우 상용 응용 프로그램에서 소스 코드 프로그램을 사용하여 발생하는 침해 소송에 대한 전적인 책임을 져야 합니다.

Jabber 라이센스

Jabber 라이센스의 전체 이름은 Jabber 오픈 소스 라이센스이며 미국 Jabber, Inc. 에서 제공합니다. Jabber 라이센스는 소스 코드 복사 및 배포에서 기본적으로 다른 라이센스와 다르지 않지만, 배울 만한 몇 가지 세부 사항이 있습니다. ◆ 본 라이센스를 통해 얻은 소스 코드 및 수정된 소스 코드는 본 라이센스에 구속되지 않은 다른 유형의 코드와 결합하여 신제품으로 배포할 수 있습니다. 본 라이센스를 통해 획득한 소스 코드와 수정된 소스 코드는 본 라이센스 요구 사항과 유사하고 OSI 인증을 준수하는 다른 오픈 소스 소프트웨어 라이센스로 배포할 수 있습니다. ◆ 소스 코드를 공개 사용 가능 상태로 두는 데 걸리는 시간은 최소한 12 개월이어야 합니다. ◆ 법적 권리에 대한 제 3 자의 진술. 사용자가 본 라이센스를 통해 얻은 소스 코드와 어플리케이션 인터페이스에서 지적 재산권을 보유하고 있는 경우 소스 코드를 발행할 때 지적 재산권 청구의 세부 사항을 설명하는 "합법적" 이라는 별도의 성명을 발표해야 합니다. 소스 코드 수신자에게 자신이 획득한 지적 재산권을 알리고 소스 코드 수신자에게 지적 재산권 권리자에게 연락하는 방법을 알려야 합니다. ◆ 라이센스 요구 사항에 따라 소스 코드 및 특허 침해 소송을 발행하고 사용하지 않는 등 라이센스의 종료를 자세히 설명합니다.

프로토콜 비교

BSD 오픈 소스 프로토콜

BSD 오픈 소스 프로토콜은 사용자에게 큰 자유도를 제공하는 프로토콜입니다. 기본적으로 사용자는 "원하는 대로" 하고 소스 코드를 자유롭게 사용 및 수정할 수 있으며 수정된 코드를 오픈 소스 또는 독점 소프트웨어로 재배포할 수 있습니다. 그러나 BSD 프로토콜을 사용하여 코드를 발행할 때 "원하는 대로" 하거나 BSD 프로토콜 코드를 기반으로 자체 제품을 개발하려면 세 가지 조건이 충족되어야 합니다. ◆ 재배포된 제품에 소스 코드가 포함된 경우 소스 코드에는 원본 코드의 BSD 프로토콜이 포함되어야 합니다. ◆ 바이너리 클래스 라이브러리/소프트웨어만 재배포하는 경우 클래스 라이브러리/소프트웨어의 문서 및 저작권 고지에 원본 코드에 BSD 프로토콜을 포함해야 합니다. ◆ 오픈 소스 코드 작성자/기관의 이름과 원본 제품의 이름을 사용하여 마케팅해서는 안 됩니다. BSD 코드는 코드 즐거움을 장려하지만 코드 작성자의 저작권을 존중해야 합니다. BSD 는 사용자가 코드를 수정 및 재배포할 수 있고 사용자가 BSD 코드에서 상용 소프트웨어 배포 및 판매를 사용하거나 개발할 수 있도록 하기 때문에 비즈니스 통합에 친숙한 프로토콜입니다. 많은 회사와 기업은 오픈 소스 제품을 선택할 때 BSD 프로토콜을 선호합니다. 이러한 타사 코드를 완전히 제어하고 필요한 경우 수정하거나 다시 개발할 수 있기 때문입니다.

매사추세츠 공과대학 (massa Chu-setts institute of technology)

MIT 는 BSD 만큼 광범위한 라이센스 계약이며, 저자는 다른 제한 없이 저작권만 보유하려고 합니다. 즉, 바이너리 또는 소스 코드로 배포되는지 여부에 관계없이 원본 라이센스 계약의 선언을 배포에 포함시켜야 합니다. MIT agreement (일명 MIT license) 는 원래 MIT 에서 개발한 것입니다. 정식 회원의 권리: 1. 정식 사용자는 소프트웨어와 그 사본을 사용, 복사, 수정, 병합, 배포, 배포, 재라이센스 및 판매할 권리가 있습니다. 2. 정식 사용자는 프로그램의 필요에 따라 라이센스 조항을 적절한 내용으로 수정할 수 있습니다. 정식 사용자의 의무: 소프트웨어 및 소프트웨어의 모든 사본에는 저작권 고지와 라이센스 고지가 포함되어야 합니다.

GNU GPL

우리가 잘 아는 리눅스는 GPL 을 채택했다. GPL 프로토콜은 BSD, Apache Licence 및 코드 재사용을 장려하는 기타 라이센스와는 매우 다릅니다. GPL 의 출발점은 코드의 오픈 소스/무료 사용 및 참조/수정/파생 코드의 오픈 소스/무료 사용이지만 수정 및 파생 코드는 폐쇄 소스 상용 소프트웨어로 배포 및 판매할 수 없습니다. 그래서 우리는 상업 회사의 Linux 와 개인, 조직, 상용 소프트웨어 회사가 Linux 에서 개발한 다양한 무료 소프트웨어를 포함하여 다양한 무료 Linux 를 사용할 수 있습니다. GPL 프로토콜의 주요 내용은 하나의 소프트웨어에서 GPL 프로토콜 제품 ("사용" 은 클래스 라이브러리 참조, 수정된 코드 또는 파생 코드를 의미함) 을 사용할 때마다 오픈 소스와 무료 모두 GPL 프로토콜을 사용해야 한다는 것입니다. 이것은 소위 "전염성" 입니다. GPL 프로토콜 제품은 단일 제품으로 사용할 수 있으며 문제 없이 무료 혜택을 누릴 수 있습니다. GPL 은 GPL 클래스 라이브러리를 사용하는 소프트웨어 제품에 GPL 프로토콜을 사용해야 하기 때문에 GPL 프로토콜을 사용하는 오픈 소스 코드, 상용 소프트웨어 또는 코드에 대한 기밀 요구 사항이 있는 부서에는 통합/채택을 클래스 라이브러리 및 2 차 개발의 기초로 사용할 수 없습니다. 재배포와 같은 기타 세부 사항은 BSD/Apache 와 유사한 GPL 프로토콜이 필요합니다.

총 LGPL

LGPL 은 주로 클래스 라이브러리 사용을 위해 설계된 GPL 오픈 소스 프로토콜입니다. GPL 요구 사항과 달리 GPL 클래스 라이브러리를 사용/수정/파생하는 모든 소프트웨어는 GPL 프로토콜을 사용해야 합니다. LGPL 을 사용하면 상용 소프트웨어가 오픈 소스 상용 소프트웨어의 코드 없이 클래스 라이브러리를 통해 LGPL 클래스 라이브러리를 참조 (링크) 할 수 있습니다. 이를 통해 LGPL 프로토콜을 사용하는 오픈 소스 코드를 상용 소프트웨어에서 클래스 라이브러리로 참조하고 출판하고 판매할 수 있습니다. 그러나 LGPL 프로토콜의 코드를 수정하거나 파생하는 경우 수정 섹션과 관련된 모든 수정 코드, 추가 코드 및 파생 코드는 LGPL 프로토콜을 사용해야 합니다. 이 때문에 LGPL 프로토콜의 오픈 소스 코드는 상용 소프트웨어에 의해 타사 클래스 라이브러리로 참조되기에는 적합하지만 LGPL 프로토콜 코드를 기반으로 수정 및 파생을 통해 2 차 개발을 수행하려는 상용 소프트웨어에는 적합하지 않습니다. GPL/LGPL 은 원작자의 지적 재산권을 보호하고 오픈 소스 코드를 사용하여 유사한 제품을 복제하고 개발하는 것을 방지합니다.

아파치 라이센스 2.0

Apache Licence 는 유명한 비영리 오픈 소스 단체인 Apache 가 채택한 협정이다. BSD 와 마찬가지로 이 계약은 소스 작성자의 저작권을 누리고 존중하도록 권장하며, 코드를 수정하여 공개 소스 또는 상용 소프트웨어로 배포할 수 있도록 합니다. 충족되어야 할 조건은 BSD 와 비슷하다. ◆ 코드 사용자에게 Apache 허가를 줘야 한다. ◆ 코드를 수정하는 경우 수정 파일에서 설명해야 한다. ◆ 확장 코드 (수정된 코드 및 소스 코드에서 파생된 코드) 에는 원저자가 원코드에서 요구하는 계약, 상표, 특허 선언 등의 설명이 포함되어야 합니다. ◆ 재배포된 제품에 알림 파일이 포함되어 있는 경우 알림 파일에 Apache 라이센스가 있어야 합니다. 알림에 자신의 라이센스를 추가할 수 있지만 Apache 라이센스에 대한 변경 사항으로 표시할 수는 없습니다. 아파치 라이센스도 상업적으로 우호적인 허가이다. 필요에 따라 코드를 수정하여 오픈 소스 또는 상용 제품으로 게시/판매할 수도 있습니다.