GPL 정적 및 동적 연결 규칙은 해석 된 언어에 어떻게 적용됩니까?

내 이해에 따르면 GPL은 GPL이 아닌 코드에서 GPL 코드로의 정적 링크를 금지하지만 GPL이 아닌 코드에서 GPL 코드로의 동적 링크는 허용합니다. 코드가 해석 언어 (예 : Perl)로 작성 되었기 때문에 문제의 코드가 전혀 연결되지 않은 경우는 무엇입니까?

동적 연결로 간주되면 규칙을 악용하기가 너무 쉬운 것 같지만 정적으로 간주되면 GPL이 아닌 코드에서 GPL 코드를 합법적으로 참조하는 것도 불가능한 것 같습니다! 컴파일 된 언어는 최소한 정적 링크와 동적 링크를 구분하지만 모든 "링크"가 스크립트를 실행하는 경우 명시 적 라이센스없이 의도를 알 수 없습니다!

아니면이 문제에 대한 나의 이해가 잘못되어 질문을 무시할 수 있습니까? 동적 링크가 포함 된 "클래스 패스 예외"에 대해서도 들었습니다. GPL의 일부가 아니라 추가 할 수있는 것이므로 라이센스에이 예외가 포함 된 경우에만 동적 링크가 허용됩니까?

licensing gpl perl

— 에콜리스
소스

gnu.org/licenses/lgpl-java.html 을 읽었 습니까 ?

@delnan lgpl! = gpl

— Johann

softwareengineering.stackexchange.com/questions/87446/…

— Ciro Santilli 新疆改造中心法轮功六四事件

답변:

통역 언어에 관한 특정 질문에 대해서는 GPL FAQ가 매우 명확합니다 .

통역사에게 통역 된 프로그램은 단지 데이터 일뿐입니다. 저작권법에 따라 GPL과 같은 무료 소프트웨어 라이센스는 귀하가 통역사를 사용하는 데이터를 제한 할 수 없습니다. 원하는 방식으로 모든 데이터 (해석 된 프로그램)에서 실행할 수 있으며 해당 데이터를 다른 사람에게 라이센스하는 데 대한 요구 사항은 없습니다.

동적 링크와 정적 링크에 대한 일반적인 질문에 관해서는. 우선, FSF와 Stallman의 견해는 연결이 정적인지 동적인지에 관계없이 GPL은 어느 방식 으로든 감염된다는 것입니다. FSF GPL FAQ에서 :

프로그램이 플러그인을 동적으로 링크 하고 서로 함수 호출을 수행하고 데이터 구조를 공유하는 경우 단일 프로그램을 형성한다고 믿어 주 프로그램과 플러그인의 확장으로 취급해야합니다. 즉, GPL로 보호되는 플러그인과 무료 프로그램이 아닌 주 프로그램을 함께 사용하면 GPL을 위반하게됩니다.

과

[프로그램 이름] 을 다른 모듈과 정적으로 또는 동적으로 연결하면 [프로그램 이름]을 기반으로 결합 된 작업이 이루어집니다. 따라서 GNU General Public License의 이용 약관은 전체 조합을 포괄합니다.

그러나 이것은 법적 관점에서 의문의 여지가 있습니다. 실제로 동적 인 연결에 관한 법정에가는 유일한 경우 인 Galoob v. Nintendo – 항소 법원은 파생 저작물이 "저작권 저작물의 일부를 어떤 형태로 통합해야 한다 "고 판결했습니다 . 동적 연결의 경우에는 그렇지 않습니다.

어쨌든 동적 연결이 실제로 감염되는지 여부에 관계없이 해결 방법이 있습니다. 예를 들어 Nvidia에서 Linux 용 바이너리 드라이버를 제공하는 데 사용됩니다. (L) GPL 랩퍼를 작성하지만 작성자로서 특정 폐쇄 소스와 링크하기 위해 특별한 예외를 추가 할 수 있습니다. Vide FSF GPL FAQ .

— 바텍
소스

파생 저작물의 특성 중 하나는 원본 저작권 소유자의 저작물을 명확하게 분리 할 수 없다는 것입니다. Bob 's Foo()가 Joe ' s 에 정적으로 연결되어 있다면 Bar(), CALL그들 사이 의 지시 는 어느 저작권 소유자 에게 귀속되어야합니까? 그러한 상호 작용은 "유도 작업"을 구성하기에 충분할 것입니다. 그러나 Joe의 작업이 하나의 파일 내에 만 있고 Bob의 작업이 다른 파일에 완전히 남아있는 경우 동일한 디스크의 다른 디렉토리에있는 파일의 단순한 모양은 파생이 아니라 집계를 구성합니다.

— supercat

@thepaul : 파생 저작물을 구성하려면 저작물에 최소한 일부가 저작물에 포함되어야한다는 법적 우선권이 이미 있습니다. Stallman의 신념은 종종 실제 실제 법칙에 기초가 거의 없습니다.

— vartec

@thepaul : 한쪽에는 은박지 모자를 쓰고 싶어하는 사람이 주장하는 90 억 달러 회사가 사용하는 법적 관행이 있습니다. 당신은 후자가 더 신뢰할 만하다고 주장하며, 당신은 전적으로 그렇게 믿을 권리가 있습니다.

— vartec

당신은 GPL FAQ 의 잘못된 부분 이 매우 명확하다는 것을 인용합니다 . 당신이 인용 한 부분 은 프로그래밍 언어 인터프리터가 GPL로 배포되는 경우, 그 언어로 해석되도록 작성된 프로그램이 GPL 호환 라이센스에 속해야한다는 의미입니까? ! 따라서 [GPL 라이센스가있는] 통역가에게 . 관련 부분은 마지막 두 단락입니다. [...] 또 다른 유사하고 매우 일반적인 경우는 자체 해석되는 해석기를 라이브러리에 제공하는 것입니다. 예를 들어, Perl은 많은 Perl 모듈과 함께 제공됩니다 [...]

— Chris Wesseling

«통역사에게 해석되는 프로그램은 단지 데이터 일뿐입니다. 저작권법에 따라 GPL과 같은 무료 소프트웨어 라이센스는 귀하가 통역사를 사용하는 데이터를 제한 할 수 없습니다. 원하는 방식으로 모든 데이터 (해석 된 프로그램)에서 실행할 수 있으며 다른 사람에게 해당 데이터를 라이센스 할 필요가 없습니다.»이것은 GPL 인터프리터조차도 모든 라이센스에서 프로그램을 실행하는 것에 관한 것입니까? 해석 된 언어로 GPL 프로그램에서 비-리브레 플러그인을 사용하는 주제는 다루지 않습니다.

— tuxayo

참고 : 이것은 법적 질문입니다. Programmers.SE는 법률 포럼이 아니라 프로그래밍 포럼입니다. 여기 사람들은 프로그래밍에 대해 약간 알고 있지만 법에 대해서는 아무것도 모릅니다. 법적 질문을하려면 법적 포럼에서 해당 주제에 대해 실제로 알고있는 사람들이있는 곳에 문의해야합니다.

GPL은 정적 또는 동적 연결에 대해 아무 말도하지 않습니다. 심지어 연결 에 대해 전혀 말하지 않습니다 . 내가 말한 모든 변호사 또는 판사는 정적 및 동적 연결 문제는 전혀 관련이 없다고 말합니다.

저작권은 창의성에 관한 것입니다. 정적 링크와 동적 링크는 기술적 구현 세부 사항입니다. 무언가가 정적으로 또는 동적으로 연결되어 있는지의 여부는 창조적 행위가 아니더라도 저작물의 저작권 상태를 변경할 수 없습니다.

귀하의 질문에, 당신은 "통역 된 언어"에 대해 이야기합니다. 그러나 그 용어는 이해가되지 않습니다 : 해석 된 언어와 같은 것은 없습니다. 언어는 추상적 인 수학적 규칙과 제한 사항입니다. 언어는 해석되거나 컴파일되지 않습니다. 언어 는 입니다. 용어 "해석 언어는"단지없는 잘못 이있다, 비 sensical . 영어가 입력 언어 인 경우 유형 오류 일 수 있습니다.

해석과 편집은 언어가 아닌 통역사 나 컴파일러의 특성입니다. 모든 언어는 인터프리터로 구현할 수 있으며 모든 언어는 컴파일러로 구현할 수 있습니다. 대부분의 언어에는 둘 다 있습니다. 대부분의 최신 언어 구현은 단일 실행 엔진에서 둘 다 결합합니다.

예를 들어, Rubinius Ruby 구현에는 Ruby 코드를 Rubinius 바이트 코드로 컴파일하는 정적 사전 컴파일러, Rubinius 바이트 코드를 해석하는 인터프리터 및 Rubinius 바이트 코드를 LLVM으로 컴파일하는 동적 Just-In-Time 컴파일러가 포함되어 있습니다. LLVM 인프라가 네이티브 머신 코드로 컴파일되는 IR. MacRuby Ruby 구현에는 인터프리터가 전혀 포함되어 있지 않으며 Ruby 코드를 LLVM IR로 직접 컴파일 한 다음 기본 머신 코드로 컴파일합니다.

반면에 C 또는 C ++에 대한 인터프리터가 있습니다.

문제는 저작물이 다른 저작물에서 파생되는지 여부입니다. 동적으로 연결되어 여전히 파생 될 수 있으며 정적으로 연결되어 전혀 파생되지 않을 수 있습니다.

— 요 르그 W 미타 그
소스

해석 된 "중급 코드"언어는 어떻습니까? GPL의 기본 원칙 중 하나는 누구나 원래 언어 도구와 동일한 언어 도구를 갖춘 합리적인 기계에 프로그램을 적용 할 수 있어야한다는 것입니다. 누군가가 중간 코드 인터프리터에 대한 소스 코드를 실행하고 실행할 수있는 여러 중간 형태 코드와 함께 배포하는 경우 해당 중간 코드 얼룩과 관련된 정보를 공개하는 규칙은 무엇입니까? 머신 별 컴파일 된 실행 파일과 달리 중간 코드 블로 브는 완전히 이식 가능합니다.

— 슈퍼 캣

죄송합니다; stackoverflow.com에 물어 보려고했는데 태그 "gpl"을 사용할 때 대신 여기에 묻는 것이 좋습니다! 이런 종류의 토론도 여기서 금지되어 있습니까? exec ( "killall -9 변호사"); : D

— 에콜리스

그리고 그렇습니다. 저는 구현 세부 사항이 재사용의 법적 지위에 영향을 미치지 않아야한다는 것은 이해가되지 않습니다. 나는 단지 그런 구별이 있다고 생각하고 설명을 요구했다!

— ekolis

@ekolis : 그 자체로 금지되지 않았습니다. 사람들이있을 때 그것은, 그것은 (예를 들어 프로그래머 같은) 법적 문제에 대해 아무것도 모르는 사람의 법적 질문을하는 것은 좋은 생각이 아니라고 그냥 않는 대신 질문을 할 수 (변호사 일명) 법적 문제에 대해 알고는. 나는 변호사에 대해 아무것도 반대하지 않습니다. 그러나 나는 알고리즘 조언을 요구하지 않으며 프로그래머에게 법적 조언을 요구하지 않을 것입니다.

— Jörg W Mittag

IANAL : 기술적 인 세부 사항 일 수도 있지만 법적으로 중요한 방식으로 배포되는 내용을 변경하기 때문에 여전히 큰 차이가 있습니다. 정적 링크를 사용하면 GPL 규칙에 따라 GPL 외부로 배포 할 수없는 결합 된 작업을 작성하게됩니다. 동적 링크를 사용하면 ZIP 파일로 소프트웨어와 함께 라이브러리를 패키지하는 경우에도이 작업을 수행 할 수 있습니다. 그러나 동적 연결을 사용하면 라이브러리없이 배포 할 수 있으며 자체적으로 작동하지 않더라도 100 % 작업입니다. 물론 여전히 GPL 하에서 라이브러리를 제공 할 수 있습니다.

— flarn2006

이것과 IANAL 등에 얼마나 많은 진실이 있는지 전혀 모른다. 그러나 내 해석에서 중요한 것은 링크하는 라이브러리가 "이진"에 포함 된 형식인지 여부입니다 (동적 프로그래밍 언어의 경우 "이진"은 배포 된 소스 코드 일뿐입니다). 이 맥락에서 FSF의 "이진"에 대한 정의).

따라서 배포에 포함시키지 않고 코드에서 라이브러리를 참조하는 경우이를 "동적 연결"과 동등한 것으로 간주하는 반면, 라이브러리를 제품과 번들로 묶거나 라이브러리의 일부를 자신의 코드에 복사하여 붙여 넣으면 "정적 연결"시나리오가 적용됩니다. 이것은 최소한 GPL의 정신에 있습니다. 제한없이 GPL 소프트웨어를 자유롭게 사용 (실행, 검사, 참조) 할 수 있지만, 소프트웨어 에서 파생 되는 즉시 (일부 소프트웨어 를 링크 또는 복사하여) 자신의 배포 가능한 제품), 바이러스 성으로 바뀌고 소프트웨어도 GPL이어야합니다.

— tdammers
소스