비공개 소스 애플리케이션에서 GPL 라이브러리에 링크 할 수 있습니까?

모든 사람들이 중복 질문에 대해 외치기 전에, 여기 이미 몇 가지 질문이 있습니다. 그러나 아무도 그 질문에 대답하지 않습니다.

라이브러리를 수정하지 않고 GPL 라이브러리에 링크하면 소스 코드를 해제해야합니까?

이 질문 에 따르면 대답은 '그렇다'입니다.

그러나이 대답은 나에게 만족스럽지 않습니다. 대답은 기본적으로 코드를 오픈 소스로 만들지 않으면 GPL 코드를 사용할 수 없다고 말합니다.

그러나 이전의 내용이 사실이라면 어떤 개인이나 조직도 Linux에서 독점 소프트웨어를 출시 할 수 없음을 나타냅니다. 어느 것이 잘못 되었습니까? 모든 응용 프로그램이 유용한 작업을 수행하고 파일을 열고 콘솔에 쓰고 TCP 연결을 만들려면 응용 프로그램 libc이 GPL에 연결되어 있어야합니다 .

그래서 내 질문은 이것입니다 : GPL이 사이트의 모든 이전 답변에서 말했듯이 다른 GPL 프로그램에 연결되는 프로그램이 GPL 자체 여야한다고 명시하면 어떻게 독점 응용 프로그램을 작성 / 릴리스 / 판매 할 수 있습니까 리눅스에서 실행되는 것은? 위에서 설명한 것처럼 Linux에서 실행하려면 해당 응용 프로그램을 GPL 코드로 선호해야합니다.

좀 더 실용적인 예는 GPL이 아닌 응용 프로그램에서 GPL이있는 공유 라이브러리에 연결한다고 말하면 GPL이 아닌 응용 프로그램이 GPL이되어야합니다. 보다 구체적으로 GPL 라이브러리를 수정하지 않고 사용하고 해당 라이브러리를 .so또는 로 배포하면 .dll내 응용 프로그램이 오픈 소스가 필요합니까?

GPL 라이브러리에 링크 한 경우 파생 된 작업을 작성했으며 코드가 GPL이어야합니다. 이는 다른 라이센스 코드의 동적 링크를 허용하는 L GPL 코드 와 다릅니다. libc를 포함한 시스템 라이브러리는 모두 LGPL입니다.

Linux 커널 헤더 및 libgcc (컴파일러가 암시 적으로 호출 한 라이브러리)에 대한 특별 면제도 있습니다.

일반적으로 GPL 라이브러리에 링크하고 코드를 배포 한 다음 코드를 GPL로 해제 할 수 없다는 것이 맞습니다.

그러나 사람들이 Linux 라이브러리와 연결하고 비 GPL 라이센스로 제품을 릴리스하는 방식 인 시스템 라이브러리 예외 가 있습니다.

다른 라이센스는 두 라이센스가 서로 호환되는 경우입니다. 자세한 내용은 FSF 호환 라이센스 페이지 를 확인하십시오 .

마지막으로, GPL의 lib 작성자는 비상업적 또는 취미 사용과 같은 특정 예외를 만들 수 있습니다.

불행히도, 단단하고 빠른 규칙을 가질 가능성이 너무 많습니다. 귀하의 질문에 더 구체적인 내용이 없으면 귀하의 답변은 "아마도 할 수는 없지만 아마도 가능할 것입니다."

짧은 대답은 아무도 모른다는 것입니다. (이 토론은 LGPL이 아닌 GPL에 관한 것입니다.)

GPL은 다른 사람들이 다른 방식으로 해석하는 "파생 저작물"에 대한 모호한 언어를 가지고 있습니다. 정적 링크는 위반하지만 시스템 인터럽트 (예 : Linux 커널)를 통한 호출은 그렇지 않습니다. 후자는 주로 Oracle과 같은 회사가 Linux를 통해 제공되고 고소되지 않은 사실에 근거합니다. 라이센스에 대해서는 명확하지 않습니다.

동적 링크가 명확하지 않은 경우, 70/30이 위반한다고합니다. 파이프 또는 원격 프로 시저 호출 (30/70)을 사용하여 프로그램을 호출하는 것은 본질적으로 동일한 것이더라도 위반하지 않습니다. COM을 통해 또는 Java Jar를 사용하여 전화하는 것은 완전히 불분명합니다.

기본적으로 의심의 여지가 있고 변호사가 마음에 들지 않으면 GPL을 멀리하십시오.