GPL에 독점 소프트웨어를 GPL 라이브러리와 연결할 수있는 허점이 있습니까?

가상의 시나리오를 살펴 보자.

X 회사는 독점 라이브러리 (B)와 동적으로 연결되는 독점 프로그램 (A)을 작성합니다. 회사 Y는 GPL에 따라 라이센스가 부여 된 대체 라이브러리 (C)를 사용하려고하므로 A와 C에 동적으로 링크하고 A가 사용하는 API 호출을 C가 사용하는 API 호출로 변환하는 랩퍼 라이브러리 (D)를 작성합니다.

D는 C와 함께 사용하고 C의 API 호출을 사용하기 때문에 C의 파생 작업이므로 GPL *의 조건에 따라 배포해야합니다. 결과적으로 A와 D의 결합 된 작업은 GPL의 조건에 따라 배포되어야합니다. 이는 회사 Y가 A의 소스 코드를 가지고 있지 않은 경우 불가능합니다. 즉, 회사 Y가 D를 자체적으로 배포하는 한 , 문제 없습니다. 그러나 회사 Y의 조치에 관계없이 회사 X는 B가 없어도 A를 배포하여 GPL을 위반하지 않습니다. D가 존재한다고해서 A가 갑자기 C의 파생 작업 (D를 통해)으로 라이센스를 받아야한다는 의미는 아닙니다. GPL도 마찬가지입니다.

이제이 허점은 다음과 같습니다 , D의 자체 버전을 쓰는 별도로 배포, 대신 B의 D를 사용하는 최종 사용자 이야기에서 회사 X를 중지 아무것도 A를 실행하는 경우 그것은 회사가 할 수있는 것 같다 래퍼 모듈을 사용하여 GPL 라이브러리에서 독점 프로그램을 격리하고 해당 모듈을 별도로 배포하는 한 GPL을 위반하지 않고 GPL 라이브러리를 사용하도록 독점 프로그램을 설계합니다.

내 추리에 맞습니까? 이것이 GPL의 허점입니까?

* D는 A의 파생물이지만이 시나리오의 목적 상 X 회사는 D의 작성을 명시 적으로 승인하고 GPL에 따라 라이센스를 부여 할 수 있습니다.

IANAL, 그러나 GPL의 한계 내에서 허용되는 것에 대한 나의 의견은 다음과 같습니다.

• 결합 된 저작물 "A-B"를 공개적으로 배포 : 벌금, 모든 독점 라이센스하에 수행 가능

• C에 대한 래퍼 lib D를 Y로 작성하십시오. 좋습니다. 이것은 A가 GPL 아래에 있어야 함을 의미하지 않습니다.

• Y로 내부적으로 결합 된 제품 "A-D-C"를 사용하십시오. 또한, GPL은 조합이 대중에게 배포되지 않는 한 소스 A를 열 필요가 없습니다.

• 결합 된 저작물 "A-D-C"를 공개적으로 배포 : A는 공개 소스이어야하고 GPL에 포함되어야합니다 (그리고 X 또는 Y가이 조합을 배포했는지 여부는 중요하지 않습니다. 또한 Y가 원하는 경우 이것은 물론 X의 A에 대한 배포 라이센스가 필요합니다)

흥미로운 질문 은 D & C를 GPL 하에서 오픈 소스로 별도로 배포 할 수 있고 A & B (또는 B없이 A 만)는 독점 라이센스로 배포되고 최종 사용자가 B를 D & C로 스스로 대체한다는 것입니다.

여기에서 A를 libs D & C에 종속되게하는 "AB"의 최종 수정은 최종 사용자 배포 후에 수행됩니다 . 따라서 최종 수정은 최종 사용자가 내부적으로 만 수행한다고 주장 할 수 있습니다. 그리고 이것은 실제로 GPL을 위반하지 않고도 가능해 보입니다. A가 독점 라이센스하에 있고 CPL이 GPL하에있는 "AC & D"의 조합입니다.

물론 변호사 나 판사는 다른 의견을 가지고있을 수도 있습니다. 최종 답변을 얻으려면 누군가가 그것을 시도하고 두 번째 사람이 그를 고소 할 때까지 기다려야한다고 생각합니다.

나는 대부분의 시스템에서 처음부터 "A"를 디자인하지 않고 그러한 별자리를 만드는 것이 어려울 것이므로 B 또는 C와 완벽하게 작동합니다.이 경우 A라는 의심에 빠질 수 있습니다. 어떻게 든 C에서 파생되었습니다.

편집 : 이것에 대해 잠시 생각하면 비슷한 상황이 생겼습니다. 폐쇄 소스 응용 프로그램을 위해 GPL 라이센스 플러그인 작성 및 배포. 예를 들어 Photoshop을 예로 들어 보겠습니다. 타사 공급 업체의 GPL 플러그인이 있기 때문에 누군가 Adobe를 오픈 소스 Photoshop에 강제로 적용하려고한다고 생각하지 않습니다. 여기에는 잘 정의 된 인터페이스가 있으므로 "래퍼 라이브러리"도 필요하지 않습니다. 그러나 Photoshop이 GPL 타사 플러그인에서 핵심 기능 중 일부를 통합하면 상황이 바뀔까요? 그런 경우에는 라인을 그릴 위치를 결정하는 것이 실제로 어려울 수 있다고 생각합니다.이 시점에서 폐쇄 소스 제품은 GPL 라이브러리를 기반으로하는 작업입니다.

EDIT2 : 예를 들어 비상업적 용도의 GPL 라이센스 및 이와 같은 상업적 용도의 독점 라이센스를 갖춘 이중 라이센스 라이브러리가 있습니다.. 따라서 "루프 홀 (loophole)"은 이러한 lib를 기반으로 제품을 개발 (상업용 버전을 사용하여 GPL이 제품에 적용되지 않음)하고 lib없이 공개 소스로 제품을 제공하고 사용자는 GPL 버전을 직접 설치하여 설치합니다. 그러한 경우, lib 공급 업체가 라이센스 위반에 대해 귀하를 성공적으로 고소 할 가능성이 높다고 생각합니다 (물론 그의 lib를 지불하지 않으면). 번거로울만한 가치가 있습니까? 아마 아닙니다. 특히 링크 된 예제에서 가격은 제품을 판매하는 빈도에 의존하지 않고 개발 중에 lib를 사용하는 개발자 수에 따라 다르므로 lib도 구매해야합니다.

마지막으로, 이러한 법적 위험 때문에 폐쇄 소스 제품 내에서 오픈 소스 라이브러리를 사용하려는 경우 가능하면 GPL 라이브러리를 피하고이 "루프 홀"을 사용하려고하지 않습니다. 연결 예외가있는 LGPL 또는 GPL은 훨씬 안전하거나 모든 종류의 비 바이러스 OS 라이센스입니다.

실제 예는 최종 사용자가 스스로 설치해야하는 Linux 용 독점 그래픽 드라이버입니다. 독점 드라이버의 제작자에게있어 최종 사용자가 결합 된 작업 물을 배포하는 경우 최종 사용자 (완료 할 수 없음)에 대한 법적 의무가 있지만 드라이버 작성자에게는 법적 의무가 없습니다.

또 다른 대답은 "프로그램이 라이브러리에 의존하기 때문에 여전히 파생 작업"이라고 주장하지만 라이브러리가 없기 때문에 프로그램이 실제로 작동하지 않으면 파생되지 않습니다.

그러나 결국 "루프 홀 (loopholes)"에 의존한다면, 당신의 접근 방식이 처음에는 옳지 않다는 것을 고려해야합니다.

연결은 GPL에 의한 파생 상품을 정의합니다. 이 특정 상황은 LGPL이 처리하도록 설계된 것입니다. 라이브러리를 GPL로 릴리스하고 적용 라이센스의 명시 적 한계로 링크를 정의하려는 경우 또는 GPL 코드에 대해 링크하고 싶지만 자체적으로 요구하는 경우 작업은 비 GPL 라이센스 자체로 배포됩니다.

최종 사용자가 연결 (GPL 라이브러리에 연결할 수있는 비 GPL 소스에서 자체 코드 작성)을 수행하려는 경우 최종 사용자는 최종 제품이 무엇이든 GPL 버전을 효과적으로 만들지 못합니다 . 프로젝트 소유자가 아니기 때문에 프로젝트의 GPL이 아닌 부분의 라이센스를 변경할 수 없습니다. 이것은 일반적으로 최종 사용자가 어떤 형태로든 배포하는 것을 금지하지만 사용을 금지하지는 않습니다.

즉, 프로젝트가 소스에서 빌드되어야하고 그 방식으로 만 배포되어야하는 경우 링크 된 라이브러리가 어떤 라이센스를 가지고 있는지는 관계가 없습니다. 이는 전적으로 GPL 개발자가 아닌 것입니다. 즉, 자신의 라이센스 조건에 명시하지 않는 한 소스 전용 배포판이 libc에 대해 IBM 컴파일러에서 빌드 된 glibc VS에 대해 gcc에서 빌드 될 것임을 어떻게 알 수 있습니까? 이 법은 시행 할 수없는 법적 조건에 대한 공정한 사용과 금지로 빠르게 이어집니다 (환상은 최근 몇 차례 법으로 작성되지 않았습니다).

나는 변호사가 아니지만 프로그램이 라이브러리에 의존하기 때문에 정확하지 않다고 말할 수있는 한 그것은 여전히 ​​중요한 작업입니다. 평등과 같은 방식이 비유적인 일입니다. 최소한 라이브러리에 정의 된 API를 기반으로합니다.