[완료] GPL 관련 질문
글쓴이: cute_yoyo / 작성시간: 목, 2009/12/24 - 1:45오후
안녕하십니까.
이번에 GPL 라이센스를 가지는 DLL 을 하나 사용하고자 합니다.
프로그램 전체 구성이 다음과 같습니다.
EXE 2 개 (A.exe 와 B.exe 라고 칭하겠습니다)
자체 개발한 DLL 20 여개
GPL 라이센스를 가지는 DLL 1 개 (GPL.dll 이라고 칭하겠습니다)
A.exe 는 GPL.dll 을 링크하여 익스포트된 함수를 사용하고 있습니다.
B.exe 는 GPL.dll 을 링크하여 쓰고 있지 않습니다.
각 DLL 들은 GPL.dll 을 링크하여 쓰고 있지 않습니다.
A.exe 가 GPL.dll 을 통해서 얻은 결과값을 다른 DLL 들에게 값을 넘겨주는 형태입니다.
여기서 소스 공개를 어디까지 해야 하는지 문의 드립니다.
조사하다보니 GPL 은 EXE 단위로 소스를 공개해야 하는 걸로 들었습니다.
즉, A.exe 와 GPL.dll 만 소스를 공개하면 되는지요. (GPL.dll 의 소스는 약간 수정되었습니다)
Forums:
A.exe/GPL.dll 소스 및
A.exe/GPL.dll 소스 및 A.exe와 링크한 DLL들 전부의 소스가 공개 대상입니다.
라이브러리로 뺀다고 회피할 수 있다면 참 회피하기 간단하겠죠.
제일 간단한 것은
제일 간단한 것은 A.exe를 GPL로 하시고, A.exe와 GPL.dll 을 같이 공개/배포 하시는 것이 편하실 듯 싶습니다. 그리고 A.exe package는 B.exe와 DLL들이 있는 패키지에 의존성을 가지면 해결이 되겠죠. 전체를 하나의 패키지로 묶으실 경우 B.exe와 다른 DLL들의 라이센스까지 꼬일 위험이 있으니, 분리를 하시는 것이 편하실 겁니다.
재문의 드립니다.
답글 주신 두분 감사드립니다.
김정균님께 재문의 드립니다.
의존성을 가지면 해결이 된다는 말씀이 어려워서요.
제가 이해한게 맞는지 봐 주세요.
A.exe 와 GPL.dll 을 하나의 설치 파일로 만들어서 배포 (패키지 A 라고 하겠습니다)
B.exe 와 20 개의 DLL 들은 다른 설치 파일로 배포 (패키지 B 라고 하겠습니다)
그렇다면 A.exe 는 패키지 B 가 설치될때까지 GPL.dll 관련 이외에는 아무 작업도 못하게 되니깐
A.exe 를 플러그인 형태(dll 들이 존재하면 동적으로 로드하고 없으면 해당 기능은 사용을 못하게 하는 형태)로 만들면 된다는 말씀이신지요.
plugin 형태로
plugin 형태로 만들어도 상관은 없을 듯 싶습니다. windows pacaking은 제가 잘 모르므로.. 알아서 하셔야 할 것 같고, RPM의 경우 패키지에 의존성을 걸 수 있습니다. 즉 예를 들어 a package를 설치 하려고 하는데 b package가 없으면 의존성 에러를 발생을 시키게 됩니다. 그리고 yum 같은 것들은 a를 설치 할 때 이 의존성을 이용하여 b까지 설치를 해 줍니다. windows에서의 패키징이 어떨지는 모르겠지만.. 최후의 순간에는.. b를 설치 하고, a의 기능을 이용할 때 a를 자동 설치해 주거나 또는 a를 설치하라는 문구를 보낼 수도 있겠죠.
명확한 것은 패키지가 분리가 되어 있느냐 안되느냐와, a가 b가 없이도 순수하게 작동이 가능하느냐의 여부가 가장 중요합니다. a가 b가 없어도 gpl관련 기능만은 작동이 가능하다면 어필을 해 볼 수 있으니까요. (하지만 중요한 것은 b가 없이 a가 아무런 작동이 안된다면.. 이 경우에는 a와 b를 하나의 패키지로 여길 수 있게 됩니다. GPL이 이게 무서운 거죠. ^^)
그렇게 해도 안
그렇게 해도 안 됩니다. 플러그인이고 아니고 의존성이 있고 없고 간에 20 여 개 DLL 모두 GPL 공개 대상입니다.
어디까지 파생물이냐 (derived works) 문제는 언제나 논란의 대상이었지만, 널리 사용되는 FSF의 해석대로라면 분명한 선이 한 address space에 들어가는 링크 유무입니다.
http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
.
(삭제)
안되는걸로 압니다.
GPL 은 정적(LIB), 동적(DLL) 형태의 링크가 발생할 경우 소스 공개 해야 합니다.
EXE 안에 포함하던지... DLL로 만들던지...
어떤 형식이든 관련된 모든 소스코드가 공개되어야 합니다.
LGPL 이라면 DLL 로 분리함으로써 회피할 수 있습니다.
참고로 제 경우는
별도의 실행 파일로 나누어 각각의 프로세스가 되도록 나누고
데이터를 IPC(Inter Process Communication)으로 전송하여 회피한적은 있습니다.
물론 종류에 따라 제한적인 방법이죠.
위에서 언급
위에서 언급 하신대로라면 B는 GPL을 link를 하지 않기 때문에 분리가 가능할 것 같은데요. B가 GPL dll을 link를 한다면 문제이겠지만, GPL dll을 link하는 것은 A 뿐이기 때문에 상관 없을 듯 싶습니다만..
plugin은 문제가 있을지 모르겠지만 명학하게 binary가 분리가 된다면 상관 없을 것 같습니다. A가 GPL이 아닌 library를 dynamic link한다고 해서 해당 dll이 GPL이 되어야 하는 것은 아닌 것으로 저는 판단 했습니다만.. 만약 그렇지 않다면 상용 OS상에서는 GPL program을 구동할 수 조자 없어야 하니까요.
상용 OS 상에서의 GPL
상용 OS 상에서의 GPL 프로그램이 허용되는 이유는, GPL에 "os major component"에 대한 예외 조항이 들어있기 때문입니다.
흠.. 그렇다면.. my
흠.. 그렇다면..
my source + BSD library + GPL library를 사용할 경우, BSD library의 license도 GPL이 되어야 한다는 얘기인가요? 아니면 BSD library는 코드 공개만 하면 의무를 다했기 때문에 문제가 안되는 것인가요? (BSD library는 내가 만든 경우가 아닐 경우 입니다.)
그리고, 이 경우라면 my source + 상용 library + GPL library의 조합은 사용할 수 없다는 얘기가 되는 것인가요? 그렇다면 제가 GPL을 잘못 이해하는 것이 되겠군요. 라이센스는 참 어렵군요 :-)
그리고 궁금한 점 하나.. 커널 모듈은.. 분명히 GPL 코드의 symbol을 사용하는데, 이 경우 non GPL이 가능한 경우는 linux kernel에 예외 조항이 있기 때문인가요? (linux kernel 이 GPL이라는 것만 알고 있었지 예외 조항이 있는지에 대해서는 찾아본 적이 없군요. 찾아보기 귀찮아서 여쭈어 봅니다. ^^)
BSD lib + GPL lib -
BSD lib + GPL lib - 오리지널 BSDL이 아닌 2/3 clauses BSDL이라면, GPL보다 추가 제한이 없으므로 전체를 GPL 조건으로 배포하는데 문제가 없습니다.
Proprietary lib + GPL lib - 못 하죠.
커널 모듈 - GPLv2에 예외조항 없습니다. 커널 모듈도 원칙적으로 GPL인데 open/close/read/write 등 표준적인 인터페이스만 쓰면 파생물로 볼 수 없는거 아닌가 대체로 인정하는 non-GPL 모듈들이 있죠. (애매한 영역.) 조금 더 명확히 하기 위해 GPL 모듈이 아니면 특정 심볼을 억세스 못 하게 만들었고요.
혹시나 해서...
혹시나 해서... cwryu님이 말씀하신 게 맞지만 혹시 제 3자가 읽어볼 때 오해의 소지가 있을까 해서 노파심에 씁니다.
'전체를 GPL 조건으로 배포' 라고 말씀하셨을 때 '전체'란 부분은 BSD library가 아닌 새로이 개발된 부분을 말씀하시는 거죠? 원래의 BSD library 부분은 -당연한 이야기지만- 배포할때 GPL로 바꿔서 배포할 수 있는게 아닙니다. BSD license 는 유지해야 합니다. GPL로의 re-licensing 은 불가능합니다.
----
Let's shut up and code.
----
Let's shut up and code.
답변 감사드립니다.
답변 주신 분들 감사드립니다.
GPL 관련 문서와 적어주신 내용들을 참조해서
다음과 같이 변경하고자 합니다.
A.exe + B.exe + 20 여개 자체 개발 DLL
위에 것을 패키지로 하나 묶고
GPL.dll 을 사용자가 공개자료실에서 다운로드하도록 프로그램상에 링크를 제공할 예정입니다.
즉 GPL.dll 을 찾을 수 없으면 링크를 제공하고 , 만약 존재한다면 해당 GPL.dll 내부 함수를 호출하는 메뉴를 보여줄 것입니다.
이건 좀 가능하겠지요?
그리고 혹시 GPL.dll 을 공개자료실이 아닌 자체 서버에서 제공하는 것은 무리겠지요?
그게 안 된다고 답변
그게 안 된다고 답변 드렸습니다. 별도 패키지로 배포해도 동적 링크가 되는 A.exe와 DLL 전부 GPL로 릴리스해야 합니다.
이건 사실 관계의 문제이지 이게 좋다 나쁘다, 누구의 의견이 어떻다의 문제가 아닙니다. 마음에 드는 답변을 선택하지 마시고, GPL과 GPL FAQ를 읽어 보세요.
답변 감사드립니다.
답변 감사드립니다.
그러니까 2006 년도 정도에 이미 누군가가 GPL.dll 을 패키지로 묶어서 배포해 놓은 상태고요.
(예를 들어서 동영상 통합 코덱 같이...영상 코덱은 아닙니다만...)
이걸 쓰려고 하는데 문제가 될까요? 그렇다면 통합 코덱팩을 사용하는 플레이어들도 문제가 있다는 이야긴데...
다시 한번 조언 바랍니다.
네, 그 코덱을 직접
네, 그 코덱을 직접 사용하는 동영상 플레이어들은 문제 있습니다.
별도 배포된 코덱을 DirectShow 필터로만 설치해서 작동한다면, 플레이어는 무슨 코덱이 있는지 없는지 상관없이 동작하고 결합은 사용자 컴퓨터에서만 일어나고 링크된 형태로 배포되지 않으므로 문제가 없습니다. 하지만 DLL 파일의 심볼을 직접 호출하는 일부 동영상 플레이어들은 (KMPlayer 등) 문제가 되고 이슈가 되고 있습니다. GPL인 XviD같은 경우만 봐도 링크했다가 문제가 되는 경우가 계속 발생합니다.
그렇군요.
자세히 답변 주셔서 감사드립니다.
회의를 거쳐야 겠지만 아무래도 자체 개발하는 쪽으로 선회를 해야 할 듯 싶네요.
다시한번 답변 주신 분들께 감사드립니다.
(업데이트) Xvid FAQ에
(업데이트) Xvid FAQ에 따르면 vfw 인터페이스만 사용한 경우에도 combined work로 Xvid 기능을 호출한다면 GPL로 배포해야 한다고 말하는군요..
http://www.xvid.org/FAQ.42.0.html
댓글 달기