정적 링크를 허용하는 수정 된 LGPL 라이센스가 있습니까?


21

LGPL 은 프로그램이 LGPL 라이브러리를 사용하는 경우 사용자가 다른 버전의 라이브러리와 프로그램을 다시 링크 할 수 있어야합니다.

...

d) 다음 중 하나를 수행하십시오.

0)이 라이센스의 조건에 따라 최소 해당 소스와 해당 응용 프로그램 코드를 전달하여 사용자가 응용 프로그램을 수정 된 버전의 링크 된 버전과 재결합하거나 다시 링크하여 해당 소스를 전달하기 위해 GNU GPL의 섹션 6에 지정된 방식으로 수정 된 결합 저작물.

1) 라이브러리와의 링크에 적합한 공유 라이브러리 메커니즘을 사용하십시오. 적합한 메커니즘은 (a) 사용자 컴퓨터 시스템에 이미 존재하는 라이브러리의 사본을 런타임에 사용하며 (b) 링크 된 버전과 인터페이스 호환되는 수정 된 버전의 라이브러리에서 올바르게 작동하는 것입니다.

...

그러나 경우에 따라 상당한 문제가 발생할 수 있습니다. 특히 Haskell 프로그램은 거의 항상 정적으로 컴파일됩니다. 또한 컴파일러는 모듈 간 최적화를 수행하므로 코드의 일부를 가져 와서 다른 것으로 바꿀 수 없습니다. 따라서이 조건을 만족시키기는 매우 어렵습니다. ( Haskell Wiki 에서이 링크 를 보십시오 .)

동적 연결 은 해결책이 될 수 있지만 대부분의 경우 불가능합니다. 예를 들면 다음과 같습니다.

  • 일부 플랫폼에는 동적 연결이 전혀 없을 수 있습니다.
  • 일부 언어는 동적 연결 가능성이 없습니다. 또는 모듈을 다중 플랫폼으로 만들 수 없습니다.
  • 경우에 따라 동적 연결은 중요한 최적화를 방해 할 수 있습니다. 이것이 심각한 문제는 아니지만, Haskell과 같은 언어에서는 성능 손실이 상당히 클 수 있습니다.

따라서 다시 연결할 가능성이 필요없는 표준 LGPL과 유사한 라이센스를 찾고 있습니다 (사용자에게 부여되는 약간의 자유가 제거됨을 이해합니다). 일부 프로젝트는 자체 LGPL 수정 (예 : wxWidgets)을 사용 합니다. 그러나 다소 공식적인 표준 라이센스를 사용하고 싶습니다. 어쩌면 일부 법률 전문가가 확인하고 (L) GPL 호환 가능합니다. 그런 것이 있습니까?

(또한 LGPL의 그러한 수정으로 인한 예기치 않은 결과가 있는지 알고 싶습니다.)


Haskell에서 외부 라이브러리동적으로 연결할 수 없습니까? 불편을 끼쳐 드려야합니다.
Robert Harvey

2
전체 프로젝트가 FOSS 인 경우 문제가 아닐 수 있습니다. 소스에서 그들을 포인트 및하자 그들이 그것을 밖으로 정렬! :-)
Peter Rowell

2
이 라이센스와 비 카피 레프트 라이센스를 구별 할 수있는 것은 무엇입니까?

2
@delnan LGPL에는 종종 바람직한 다른 것들이 많이 있습니다. 예를 들어, 수정 은 (L) GPL이어야하거나 티 보이 제이션을 금지 합니다.
Petr Pudlák

wxWindows 라이센스는 OSI에 의해 승인 된 경우 공식적으로 제공 됩니다 .
Joachim Sauer

답변:



12

wxwidgets 는 본질적으로 = LGPL + 정적 링크에 따라 라이센스가 부여됩니다

... 본질적으로 L-GPL (Library General Public Licence)은 바이너리 형식으로 파생 된 저작물이 사용자 자신의 용어로 배포 될 수 있다는 점을 제외하고는 예외입니다. 이 솔루션은 wxWidgets를 사용하여 GPL 소프트웨어를 생산하려는 사람들과 독점 소프트웨어를 생산하는 사람들을 만족시키는 솔루션입니다.

wxWidgets는 Abisource , Robert Roebling, Julian Smart, Markus Fleck, Karsten Ballueder, Richard Stallman의 조언을 포함하여이 결정을 이끌어 낸 공인 오픈 소스 소프트웨어 참가자입니다 . Richard는 새 라이센스가 GPL 응용 프로그램과 호환되는지 확인했습니다. 그러나 독점 응용 프로그램에는 중요한 제한이 없습니다.

wxWindows 라이센스는 Open Source Initiative에 의해 승인되었으며 여기 에서 해당 사이트의 라이센스를 찾을 수 있습니다 ...


0mq 는 명시 적 정적 링크 예외를 제외하고 LGPL에 따라 라이센스가 부여됩니다.
Trevor Powell

4

IANAL은 하나의 해결책은 LGPL이 아닌 부품에 대한 객체 파일을 제공하는 것이라고 믿었습니다. 이렇게하면 사용자가 프로그램을 다시 연결할 수 있으므로 LGPL 부분을 자유롭게 변경하여 LGPL의 요구 사항을 충족 할 수 있습니다.

다시 말해 LGPL 소스와 LGPL이 아닌 코드의 컴파일 된 객체 파일이 포함 된 소스 패키지가 있어야합니다. 분명히 바이너리를 릴리스 할 때마다 아키텍처마다 객체 파일을 제공해야하지만 이것이 큰 문제는 아니라고 생각합니다.

개발 관점에서 배포를위한 바이너리를 빌드 할 때 빌드 시스템이 소스 패키지를 동시에 빌드하도록하는 것이 가장 간단합니다.


이것이 수행 된 실제 시나리오가 있습니까?
knocte

3

Google에서 찾은 OpenScales 라이센스

OpenScales는 GNU Lesser Public License (LGPL, 여기 에서 사용 가능 ) 의 버전 3에서 릴리스 되며 정적 링크 예외 (아래 참조)와 관련된 예외가 있습니다 ...

LGPL 라이센스 텍스트 외에 LGPL 조건에 대한 예외는 OpenScales에 적용됩니다.

GNU Lesser General Public License 버전 3의 특별한 예외로, 귀하는이 라이브러리의 일부를 실행 파일에 정적으로 또는 동적으로 연결하여 최소 해당 소스를 전달하지만 라이브러리의 수정되지 않은 공개 배포 버전을 사용하는 경우 GNU Lesser General Public License의 섹션 4d0에 따라 해당 응용 프로그램 코드를 전달할 필요가 없습니다. 이 예외는 실행 파일이 GNU Lesser General Public License 또는 GNU General Public License에 의해 커버 될 수있는 다른 이유를 무효화하지 않습니다.

그것은 표준이 아니며, 그것이 존재하는지 모르겠습니다.


1

사용자 자유를 어떻게 계속 보장 하시겠습니까? "올바른"답변은 라이브러리를 동적으로로드하는 심을 정적으로 연결하는 것입니다.


예, 이것이 최선의 해결책입니다. 그러나 경우에 따라 동적 연결이 불가능합니다. 일부 언어에는 이러한 가능성이 없습니다. 또는 일부 플랫폼에는 이러한 가능성이 없습니다.
Petr Pudlák

실제로 링커는 라이브러리에 동적으로 링크 할 때 정확하게이 작업을 수행합니다.
Calmarius
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.