GPL 라이브러리와 비GPL 라이브러리의 결합???
글쓴이: mogi / 작성시간: 월, 2010/01/11 - 11:07오전
C라는 프로그램을 만들기 위해 A라는 GPL 라이브러리와 B라는 상용 라이브러리를 사용 하려고 합니다.
C라는 프로그램은 소스를 공개하고 GPL라이센스도 따를 수 있습니다.
하지만 B라는 라이브러기가 상용인데다 소스 공개도 되있지 않아 이부분의 소스공개는 불가능 한 상태입니다.
이런경우 B의 라이브러리소스가 공개 되지 않기때문에 C라는 프로그램이 GPL 위반이 되는지 궁금합니다.
만약 C라는 프로그램이 GPL 위반이라면 GPL위반하지 않고 개발 할 수 있는 방법을 알고 싶습니다.
Forums:
GPL
네. B 라이브러리 소스를 공개할 수 없기 때문에 GPL 위반이 됩니다. GPL을 위반하지 않고 개발하려면 A라는 GPL 라이브러리를 이용하지 않거나, B라는 상용 라이브러리를 이용하지 않는 방법이 있습니다.
어떤 이유에서 꼭 A와
어떤 이유에서 꼭 A와 B를 함께 사용해야 한다면 (동일 기능의 라이브러리가 존재 하지 않고 만들 능력도 안되거나 다른 이유에서) 개발을 포기 해야 할까요?
네
네
GPL이 소프트웨어
GPL이 소프트웨어 발전에 꼭 도움이 되는 것만은 아니네요.
어떤 면에서는 GPL이 소프트웨어 발전에 걸림 돌이 될 수도 있네요... ㅜㅠ
그게 어째서 그렇게
그게 어째서 그렇게 해석되나요? 남의 것 날로 먹겠다는 심보로밖에 안 보이는데요?
남의 것을 날로
남의 것을 날로 먹겠다는게 아니고 위에 언급했듯이 상용라이브러리 부분은 제외하고 소스를 오픈하고 GPL 라이선스를 적용 수 있습니다. 아니 적용 해야 겠죠. 상용라이브러리는 다른 업체에서 개발한 부분이라 공개를 하고 싶어도 할 수 없는 부분이구요. 상용라이브러리 부분은 능력이 안되서 개발 할 수 없어 구입해 사용하고 추후에 누군가에 의해 같은 기능의 라이브러리가 개발 된다면 상용라이브러리를 대채 할 수도 있다고 생각합니다. 그런데 GPL 라이선스 정책때문에 상용라이브러리와 결합된 GPL 프로그램을 개발 조차 못 한다면 저해 되는게 아닌가 싶은데요.
다른 업체에서
다른 업체에서 개발한 부분이 GPL 소스와 상관없이 잘돌아간다면
다른 업체에서 개발한 라이브러리를 공개할 필요가 있나요?
물론 GPL소스가 필요하다면 해당 업체의 상용 라이브러리는 소스를 공개해야만 하겠죠.
다른 업체에서
다른 업체에서 개발한 라이브러와 GPL라이브러리 모두 꼭 필요 합니다.
본프로그램은 소스를 오픈하고 GPL도 따르려고 합니다.
다른 업체에서 개발된 상용라이브러리가 문제 이죠.
바이너리 라이브러리이어서 소스를 공개할 수 없습니다.
다른 업체의
다른 업체의 라이브러리만 봐야겠지요.
그 라이브러리가 다른 GPL 라이브러리와 다르게 단독으로 작동가능한지 여부가 중요한 것 아닐까요?
안그렇다면 상용으로 어떻게 라이브러리를 팔수 있겠습니까?
구매자가 GPL 라이브러리를 사용하면 그날부로 소스 공개해야 할 판인데 말이죠.
라이브러리가
라이브러리가 단독으로 작동을 하던 다른 프로그램을 만들기위한 부속 라이브러리이던 라이브러리의 저작권은 원작자에 있기때문에 구매자가 GPL프로그램을 사용했다하더라도 GPL이 아닌 라이브러리가 GPL에 영향을 받을 필요는 없죠. 그라이브러리에는 GPL이 포함 되어 있지 않기때문에.
제가 그 말을
제가 그 말을 적은건데요? ^^;
제 말은 라이브러리가 단독작동한다는 말은 libz 처럼 혼자 쓸수 있는 라이브러리냐
libtiff 처럼 libz 와 libjpeg 가 필요한 라이브러리냐라는 것을 말합니다.
그 상업라이브러리는 어떤가요? mogi님이 만드시는 프로그램말고 라이브러리를 말합니다.
단독으로 쓸수 있는 것이죠? libz 처럼 말이죠.
그럼 공개할 필요가 없지요.
널리 사용되는 FSF의
널리 사용되는 FSF의 해석대로라면, 그 상용 라이브러리가 독립적으로 돌아가든 말든 별로 상관이 없습니다. 그 라이브러리는 결합하지 말아야 합니다. GPL에서 명시적으로 허용하고 있는 예외는 OS의 시스템 라이브러리뿐입니다.
리눅스 배포판들에서 OpenSSL 라이브러리는 GPL 프로그램/라이브러리와 절대 링크를 하지 않습니다. OpenSSL이 다른 GPL 프로그램과 무슨 관계가 있다고 안 하겠습니까? OpenSSL은 상용은 아니지만 BSD의 advertising clause라는 GPL에 없는 추가 제한이 들어 있어서 그런데, 배포가 제한된 라이브러리와 결합할 때도 마찬가지입니다.
만약 GPL 라이브러리와 제 3자의 독점 라이브러리와 결합되어 배포되는 모순되는 상황이 되면 어떻게 하느냐 이건데요. 만약 그런 상황이 벌어지고 법적인 액션이 일어난다면 그렇게 결합한 사람이 라이선스를 위반한 것이 되고, 수습하기 불가능한 상황이 되겠죠. 그렇게 쓸 수 없고, 그런 상황은 일어나지 말아야 합니다.
GPL SW를 가져다가
GPL SW를 가져다가 자사 개발에 적용하고, 라이센스까지 어겨가며 소스 공개를 하지 않는 것이
가능하다고 해도...
그게 소프트웨어 발전에 어떤 도움이 될까요?
소스를 공개하고
소스를 공개하고 GPL을 따르겠다고 했습니다. 상용 라이브러리 부분은 제외 하고요. 상용 라이브러리의 경우 저작권자체를 다른 업체에서 가지고 있기 때문에 공개 하고 싶어도 할 수 없는 부분이구요.
제가 보기엔 소스를
제가 보기엔 소스를 공개하고 GPL을 따르는 것이
소프트웨어의 발전에 공헌하는 것과는 별로 상관이 없는 것 같습니다. ;;
어떤 소프트웨어인가가 문제죠.
저는 GPL이 프로그램
저는 GPL이 프로그램 소스를 오픈 하게 한부분이 소프트 웨어발전에 상당부분 기여 했다고 보고 있습니다.
(주관적인 생각이지만)
소프트웨어는 좋은 소프트웨가 나올 수도 있는 것이고 나쁜 소프트웨어가 나올 수도 있습니다.
하지만 공개된 소스를 통하여 다른 사람들에게 아이디어를 제공해 줄 수도 있고 그 아이디어를 통하여 나쁜 소프트웨어가 좋은 방향으로 흘러 갈 수 도 있다고 봅니다. 그렇기 때문에 GPL이 소프트웨어 발전에 공헌했다고 보고 있습니다.
하지만 상용라이브러리가 포함된 GPL소프트웨어를 개발 을 막는 이유가 GPL을 소프트웨어를 독점적으로 사용할 수 없게 하기위함이라고 생각되지만 본 소프트웨어가 GPL이므로 상용으로 작성된 필요한 라이브러리는 충분히 GPL으로 새로 작성될 수 도 있다고 봅니다. 그럼 결국 독점적인 GPL 프로그램은 불가능해 지는 거죠. 그리고 상업적으로 GPL을 이용하는 업체를 통하여 더 많은 아이디어들이 오픈 소스에 유입 될 수 있다고 생각합니다.
만약 라이브러리를
만약 라이브러리를 광범위하게 허용한다면, 상업적으로 GPL 코드를 사용하는 업체들은 과연 어떤 선택을 할까요.
자기 코드를 GPL로 릴리스할까요? 아니면 감추고 싶은 부분을 죄다 라이브러리로 빼는 식으로 GPL을 회피하는 방법으로 활용할까요? (상용 라이브러리 안 쓰는 프로그램까지)
그 부분은 실력있는
그 부분은 실력있는 개발자들에 의해 충분히 호환 라이브러리가 개발 될 수 있을 것이라고 봅니다. 그리고 상업적으로 이용하는 업체들로 하여금 개발자들이 새로운 아이디어를 받아 들일 수 있다고 생각합니다.
과연 광범위한
과연 광범위한 링크를 허용했을 때 플러스 요인이 (새로운 아이디어) 마이너스 요인보다 (쉬운 GPL 회피) 많을까요? 지금 업체에서 강제적으로 공개하고 있는 코드들과, 새로 상용 라이브러리와 링크해서 얻는 코드와 한 쪽을 버리라면, 당연히 후자의 상용 라이브러리 링크하려는 쪽을 버리겠습니다. 후자가 훨씬 적은 케이스이고 전자로 인해 GPL 프로그램들이 얻고 있는 혜택이 매우 크거든요.
지금까지 GPL을 상업적으로 이용한 업체들이 죄다 숨기고 싶은 코드를 라이브러리로 빼는 (아주 쉬운) 방법을 사용했다면 GPL 코드들이 지금과 같았을 것 같지 않다고 생각할 정도입니다. RMS가 툭하면 말하는 GCC부터 C++이 없었겠죠. GCC의 C++ 프론트엔드는 처음에 기업들의 컨소시엄에서 만들었는데 오브젝트로 만들어 링크하기 등등 여러가지 방법으로 GPL 회피를 시도했지만 결국 포기했습니다.
http://www.gnu.org/philosophy/pragmatic.html
제한적인 라이브러리와 링크를 못 하는 상황이 그렇게 큰 제약은 아니라고 생각하고요. 충분히 GPL과 호환 가능한 범위 내에서 상업적 이용할 수도 있고, 또 지금까지 수 많은 업체가 상업적으로 이용해 왔고 이용하고 있습니다. 적정 수준이라고 생각.
네 득보다 실이
네 득보다 실이 많군요...
오픈 소스로 프로그램으 개발 하고 싶은데 아직 실력이 안되 어떤경우에는 기술 지원이 되는 상용 라이브러리 사용하면 편할텐데 라는 생각에서 시작된 질문 이었습니다. 섣불리 시작하기보다는 좀더 능력을 키우고 시작하는게 좋을 것 같다는 생각이 드네요. 지인 중에 이런 일에 관심 있는 사람도 없는 상태라 인맥을 키우고 조언을 구하는 것도 중요 할 것 같네요.
...
제가 알기로는, C를 C1과 C2 두 개의 프로그램으로 쪼갠 다음 C1은 A하고만, C2는 B하고만 링크하고 C1과 C2 사이는 IPC로 통신하면 아마도 가능합니다.
혹시 제가 잘못 알고 있는 거라면 곧 다른 분들이 교정해 주실 겁니다. -.-
그렇게 간단하지는
그렇게 간단하지는 않습니다. ^^ gpl 상에도 그부분이 매우 모호하게 되어 있고, 링크에 해당하느냐 안 하는냐에 대해서 기술적으로 구별되는 기준이 합의된 것은 없습니다. gpl faq를 참고해서 결정해야 할 듯... :-)
GPL에는 2차
GPL에는 2차 저작물인경우에만 소스를 공개해야 하고, 독립적인 프로그램에 대해서는 소스를 공개하지 않아도 된다고 되어있고 그 판단 기준이 모호해서 소송이 진행중인 사건도 있는 것으로 알고 있습니다. 그리고 FSF에서는 그 모호한 기준에 대한 구별을 위해서 GPL FAQ에는, 2개의 프로그램이 파이프(pipes), 소켓(sockets), command-line arguments형태의 경우 독립적인 프로그램으로 본다고 알고 있는데 혹시 제가 잘못 알고 있는건가요? 영어가 딸려 번역된 문서만 읽다보니..;;
---------- 추가 ------------
위내용에대한 FAQ 링크입니다.
http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation
최종 판단은 법원에서 한다는군요..
저도 이런 경우는
저도 이런 경우는 GPL의 문제점 같은데요
다른분들 의견은 어떤가요????
이유인즉
gpl라이센스와 상용라이센스 결합해서
상용만 빼고 공개하며 공개하신 분이 난 상용부분 구현은 능력 밖이라고 하시니
다른 사람들이 보고
이 상용라이센스 부분은 이렇게 하면 되겠군 하면서 gpl 부분으로
바꾸는게 더 GPL 마인드같은데...
아닌가요?
인생은 도박이다.
무슨의도인지 이해는 가지만요...
개발전에 미리 해당되는 GPL 라이브러리를 찾아서 개발해야죠.
상용과 결합해서 만들어 놓고 다른사람이 찾아준다는 건....
어떤 일이든 시작할때 그게 적법한가를 따지고 일을 시작해야지
저질러 놓고 땜방하는 건 도리가 아니죠...
저질러 놓은건 책임을 져야하기도 하고요
해당되는 GPL
해당되는 GPL 라이브러리가 존재 하지 않고 해당하는 라이브러리를 만들 실력도 되지 않는 다면 어떻게 하죠?
저는 차라리 GPL이 상용 라이브러리 결합에 좀더 유연해졌으면 하는 바램입니다. 상용 라이브러리를 사용하였다면 그 부분만 제외한 소스를 공개 하는 쪽으로요. 물론 이 부분이 GPL을 독점적으로 사용 할 수 있는 빌미를 제공 하는 부정적인 부분도 있겠지만 그런 부분은 실력있는 개발자들에 의해 호환 라이브러리 개발로 충분히 대처하고 해결 할 수있다고 봅니다. 저는 GPL프로젝트를 저질러 놓았다고 혼자 책임져야 한다고 생각하지 않습니다. 혼자 책임질 수 없기 때문에 누구나 참여 할 수 있는 GPL을 사용하는 것이라고 생각합니다. 책임 질 수 없는 부분은 도움을 청하는 거죠. 다만 이 도움의 손길이 언제 올지도 모르는 일이기때문에 도움의 손길이 올때까지만 이라도 상용 라이브러리를 결합하여 사용 할 수 있으면 하는 바램입니다.
인용: '해당되는 GPL
인용: '해당되는 GPL 라이브러리가 존재 하지 않고 해당하는 라이브러리를 만들 실력도 되지 않는 다면 어떻게 하죠?'
해당하는 라이브러리를 만들 실력이 있는 사람을 충분한 돈을 주고 데려오면 됩니다.
--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오해 하신듯
GPL 프로젝트를 저질러 놓았다고 혼자 책임져야 한다는게 아니고요. (책임질 일도 없죠.)
GPL + 상용 라이브러리의 결합을 했으면 그거에 대한 책임을 져야 한다는 거지요. 라이센스 위반에 대한 책임을요
그 논리대로라면
인용: 'gpl라이센스와 상용라이센스 결합해서 상용만 빼고 공개하면 ... 다른 사람들이 보고 이 상용라이센스 부분은 이렇게 하면 되겠군 하면서 gpl 부분으로 바꾸는게 더 GPL 마인드같은데... 아닌가요?'
그 논리대로라면 라이브러리의 *훌륭한* 예제 코드만 제공하면 되겠군요.
(원문이 이해하기 좀 애매해서 제가 이해한 대로 좀 축약하고 받침 하나 추가했습니다.)
--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
농담입니다..
순선님과 클론의 습격인줄 알았습니다. 옆의 foo 였나요. 시각적 효과가 대단하네요.
간단합니다.
개발하신 프로그램 C의 실행물 대신 소스코드를 배포하시면 됩니다. 여기에 GPL은 아무런 걸림돌도 되지 않습니다.
최종 사용자는 적절한 방법으로 B를 취득한 뒤, A,C와 결합하여 사용하면 됩니다. (독점 소프트웨어를 사용하는 한 이런 불편은 감수할 수 밖에 없지요..) 물론 그렇게 결합한 C의 실행물을 다시 재배포할 순 없겠습니다.
하지만 C의 소스코드라면 얼마든지 배포 가능합니다. :)