GNU GPL에 관한 질문

jhoonk의 이미지

안녕하세요.

회사에서 Linux를 가지고 PMP를 개발한다고 가정하겠습니다.
다른 모든 모듈,드라이버,애플리케이션은 GPL로 개발을
했는데 한개의 라이브러리만 다른 회사의 모듈을 사온것이라
GPL이 아닌 closed license로 개발을 하였습니다.

물론 그 회사의 라이브러리는 kernel의 system호출만을사용하고
GNU library중에선 LGPL인 것들을 다이내믹링크로만 사용
하였기 때문에 GPL로 걸리지 않는다고 가정합니다.

이럴경우 이 제품을 출시할때 이 모든 것을 펌웨어로 만들어
한꺼번에 NOR(또는 HDD)에 구워 출시한다면 GPL에
저촉됩니까?
이럴경우 다른 모든 소스는 FTP나 CD등을 통해 요청이
있을경우 공개되며 그 한 라이브러리만 바이너리형태로
소비자에게 제공됩니다.

이런 케이스가 GPL에 위배되는지 궁금합니다.

질문할 곳이 마땅치않아 자유게시판에하였습니다.
감사합니다.

ez8의 이미지

위배가 되는 것 같습니다.

자세한 건

http://www.gnu.org/licenses/gpl-faq.ko.html#MoneyGuzzlerInc

espereto의 이미지

위배되지 않는 것 같은데요...

GPL, LGPL을 위배하지 않는 상태에서 NOR 나 HDD로 구웠다는 이유로 위배되는 건 아닐 것 같은데, 다른 이유때문에 위배된다면 모를까......

다만, 그 closed license의 라이브러리를 사용하는 어플리케이션이, 다른 GPL 라이브러리와 링크가 된다면 문제가 될 것 같습니다.

closed license의 라이브러리를 사용하는 어플리케이션이, GPL 라이센스일 경우에는 "예외 조항"으로 closed license인 해당 라이브러리의 링크가 가능하다라는 내용을 두면 될 것 같습니다만... 다른 GPL 라이브러리들과 링크된다면(시스템 콜이 아닌) 위배될 소지가 있어 보입니다.

......

PS) GPL.. 어려워요. ㅜ.ㅜ

Tony의 이미지

이크 당연히 위배됩니다. GPL은 '배포' 순간에 문제가 생기는데 하드웨어로 패키징되어 배포되면 그 순간 원하는 이에게 모든 소스가 공개되어야 합니다.
저런 내부 사정이 있다면 당연히 GPL이 아닌 다른방법을 찾으셔야 합니다.

체스맨의 이미지

개발자 Q&A 에 맞는 질문일 것 같네요.

요는,
(1) 돈주고 구입한 독점 라이센스 모듈은 GPL 위반이 아니다.
(2) 돈주고 구입한 독점 라이센스 모듈 빼고는 나머지 모두 소스가 제공된다.

이것이지요? 이것이라면, GPL 위반이 아닙니다.

Orion Project : http://orionids.org

Prentice의 이미지

ez8님의 링크에 나와 있는 내용처럼, GPL 코드와 GPL이 아닌 라이브러리의 링크는 문제가 있는 듯 합니다.

espereto님이 말씀하셨듯, 단순히 같은 매체에 있다고 GPL 위반이 발생하지는 않습니다. 그런데 jhoonk님께서 GPL app과 링크가 된다고 말씀하셨으므로 GPL 위반이 맞겠죠.

Tony님 말씀은 사실이긴 하지만, 원래 GPL에 어긋나기 때문에 배포 시 문제가 된다는 쪽으로 이해하시는 편이 낫지 않을까 생각합니다.

체스맨님 말씀은 잘 이해가 가지 않습니다. GPL 애플리케이션과 클로스드 소스 라이브러리의 혼합 금지의 문제가 아닌가요..?

체스맨의 이미지

이런 문제 아닌가요?

Quote:

독점 + GPL = GPL

이게 안되나요? 독점 소프트웨어를 GPL 로 공개할 의무는
없는 것이고, GPL 을 호출한 부분을 GPL 로 모두 공개하겠다는데
GPL 위배가 되는지 모르겠네요. - 위배가 된다면 위배 조항을
알려주세요. 읽어봐야 될 것 같습니다...

Quote:

독점 + GPL = 독점

이런 식이면 문제가 되겠지만요...

덧붙여보자면, cygwin 경우와 비슷하지 않나요?

Quote:

윈도커널(독점) + gcc (GPL) = GPL

단, 질문하신 분께서 소스를 공개하실 때는 그 소스가 반드시
GPL이어야 하구요...

Orion Project : http://orionids.org

codebank의 이미지

제가 알고 있는 사항은 다음과 같습니다.

GPL을 호출하는 부분은 공개되는 것이 맞습니다. 다만 호출하는 부분을 다시 호출
하는 부분은 공개되지 않고 개발자가 정한 라이센스에 속할 수 있습니다.

즉, 상대방에서 원본을 요구하면 회사내에서 GPL을 호출하는 부분까지는 소스를
공개해야하지만 그외에는 바이너리로 제공하든 소스공개를 하지 않든간에 회사쪽
라이센스를 따를 수 있다고 알고 있습니다.

위 내용은 제가 GPL2가 아닌 GPL을 읽으면서 알아낸 내용이지만 지금도 똑같이
적용이 되는지는 모르겠네요.

------------------------------
좋은 하루 되세요.

Tony의 이미지

GPL 제2조 b항에 의하면

"b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License."

이런 문장이 있습니다.

컴파일된 코드가 들어있는 제품을 판매하는 일은 'distribute or publish'에 포함됩니다.

GPL 제2조 끝부분에 보면
"These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. "

이런 두개의 문단이 있습니다.
첫 문단에 배포할때 개별 라이센스보다 GPL이 우선한다고 적혀있습니다.
두번째 문단에 부가 설명이 있는데 그렇게 하는 이유가 설명되어 있습니다.

한글 해석을 덛붙힙니다

"이러한 규정은 개별적인 저작물에 대한 저작자의 권리를 침해하거나 인정하지 않으려는 것이 아니라, 원프로그램으로부터 파생된 2차적 프로그램이나 수집 저작물의 배포를 일관적으로 규제할 수 있는 권리를 행사하기 위한 것입니다."

즉 이런 이유때문에 패키징되어 배포를 할때 GPL이 일부 포함되어 있다면 나머지 모든 부분도 다 GPL을 따라야 합니다.

체스맨의 이미지

Tony wrote:
즉 이런 이유때문에 패키징되어 배포를 할때 GPL이 일부 포함되어 있다면 나머지 모든 부분도 다 GPL을 따라야 합니다.

말씀하신 부분은 맞습니다. 그래서 다음과 같이 되는 것이죠.

Quote:
독점 + GPL = GPL

그런데, 저 독점 라이센스까지 GPL 로 해야할 의무는 없는 겁니다.
만일 저런 형태가 불가능하다면 말씀드린 cygwin 같은 소프트웨어는
존재할 수도 없었을 겁니다. 윈도 커널을 GPL 로 배포할 수는
없는 일이니까요.

예전에 Qt가 GPL 을 사용하지 않을 때에도, 이것을 이용해서 GPL
소프트웨어를 개발하지 않았었나요? 당시에는 라이센스 문제로
걸리는 것이 아니라, 차후에 오픈 소스 공동체에 미칠 영향 때문에
많은 우려가 있었던 것으로 기억하는데요...

p.s. 원래 제기된 문제에 대해 지금 무언가 서로 오해하고 있는 건 아닌가요...? 제가 애초에 썼던 문장은 이랬어야 할 것 같습니다.

Quote:
(2) 돈주고 구입한 독점 라이센스 모듈 빼고는 나머지 모두 소스가 제공되고 GPL이어야 한다.

Orion Project : http://orionids.org

Prentice의 이미지

체스맨 wrote:
Tony wrote:
즉 이런 이유때문에 패키징되어 배포를 할때 GPL이 일부 포함되어 있다면 나머지 모든 부분도 다 GPL을 따라야 합니다.

말씀하신 부분은 맞습니다.


아닙니다.

http://bbs.kldp.org/viewtopic.php?p=248129#248129

Prentice의 이미지

체스맨 wrote:
Quote:
독점 + GPL = GPL

그런데, 저 독점 라이센스까지 GPL 로 해야할 의무는 없는 겁니다.
만일 저런 형태가 불가능하다면 말씀드린 cygwin 같은 소프트웨어는
존재할 수도 없었을 겁니다. 윈도 커널을 GPL 로 배포할 수는
없는 일이니까요.


Cygwin은 윈도 커널의 소스를 사용하고 있지 않으므로 논외..가 아닌가요?

독점 라이센스의 프로그램도 GPL에 따라 소스를 공개해야할 의무가 있는데, 그 의무를 이행할 수 없으므로 GPL 위반이 되는 것입니다.

체스맨의 이미지

검은해 wrote:
체스맨 wrote:
Tony wrote:
즉 이런 이유때문에 패키징되어 배포를 할때 GPL이 일부 포함되어 있다면 나머지 모든 부분도 다 GPL을 따라야 합니다.

말씀하신 부분은 맞습니다.


아닙니다.

http://bbs.kldp.org/viewtopic.php?p=248129#248129

오해가 있는 것 같네요... 저는,
(1) 독점+GPL=GPL
(2) 독점인것을 GPL 로 할 필요는 없다.

이것을 말씀 드리는 것인데요. (2) 번이 틀린 이유를 말씀해 주신 건
아닌 것 같아서요.

Orion Project : http://orionids.org

체스맨의 이미지

검은해 wrote:
체스맨 wrote:
Quote:
독점 + GPL = GPL

그런데, 저 독점 라이센스까지 GPL 로 해야할 의무는 없는 겁니다.
만일 저런 형태가 불가능하다면 말씀드린 cygwin 같은 소프트웨어는
존재할 수도 없었을 겁니다. 윈도 커널을 GPL 로 배포할 수는
없는 일이니까요.


Cygwin은 윈도 커널의 소스를 사용하고 있지 않으므로 논외..가 아닌가요?

독점 라이센스의 프로그램도 GPL에 따라 소스를 공개해야할 의무가 있는데, 그 의무를 이행할 수 없으므로 GPL 위반이 되는 것입니다.

cygwin 은 윈도 커널을 호출합니다.

질문하신 분도 자신의 GPL 소스에서 독점 모듈의 함수를 호출할 것입니다. GPL 함수도 호출할 것이구요. 그래서 자신의 결과물은
GPL 입니다. 그러나 독점 모듈은 여전히 독점 모듈입니다.

제가 질문을 이해한 바는, 그래서 이런 경우 독점 모듈을 이용해서
GPL 소프트웨어를 만들 수 있는가 하는 것이었습니다.
제가 보기엔 하자가 없어보입니다.

아마도 제가 질문을 잘 못 이해하고 있거나, 오해가 있는 것 같습니다.

Orion Project : http://orionids.org

Tony의 이미지

"In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. "

이부분이 추가된걸 제가 몰랐었네요. GPLv1에서는 저게 허용되지않았던걸로 알고있습니다. ^^;

Prentice의 이미지

GPL을 다시 읽어보지 않아서 해당 부분이 어디인지는 모르겠지만..

http://www.gnu.org/licenses/gpl-faq.ko.html#MoneyGuzzlerInc

Quote:
GPL 프로그램을 개작한 뒤에 돈벌레 주식회사가 만든 독점 라이브러리와 링크시키고 싶습니다. 이 경우, 라이브러리의 소스 코드를 제가 배포할 수는 없지만 만약 프로그램을 개작하고자 하는 사람이 있다면 라이브러리를 직접 구입하는 형식을 취하면 될 것입니다. 그런데, GPL에서 이러한 형태를 금지하는 이유는 무엇입니까?
여기에는 두가지 이유가 있습니다.
먼저, 일반적인 이유 때문입니다. 만약 A라는 회사가 독점 파일을 만들 수 있도록 허용한다면 B라는 회사에서 그 독점 파일과 링크되는 GPL 소프트웨어를 배포하게 될 수 있는데, 이것은 GPL을 존패 가능성을 위협하기에 충분한 것입니다. 이것은 GPL 소프트웨어의 소스 코드에 대한 모든 종류의 개작과 확장을 억제하는 백지 수표나 다름없습니다.

모든 사용자들이 소스 코드에 접근할 수 있도록 하려는 것이 우리의 목표이기 때문에 우리는 그러한 형태를 허용할 경우에 나타날 결과를 막고자 합니다.

좀더 구체적으로 말한다면, 돈벌레 주식회사의 라이브러리와 링크된 프로그램은 우리가 정의하고 있는 범위 안에서 볼 때, 자유 소프트웨어가 아닙니다. 이 라이브러리는 사용자들이 프로그램을 수정하고 다시 컴파일 하기 위한 소스 코드를 모두 제공하고 있지 않기 때문입니다.

원문을 보죠.

http://www.gnu.org/licenses/gpl-faq.html#MoneyGuzzlerInc

Quote:
I'd like to modify GPL-covered programs and link them with the portability libraries from Money Guzzler Inc. I cannot distribute the source code for these libraries, so any user who wanted to change these versions would have to obtained those libraries separately. Why doesn't the GPL permit this?
There are two reasons for this.
First, a general one. If we permitted company A to make a proprietary file, and company B to distribute GPL-covered software linked with that file, the effect would be to make a hole in the GPL big enough to drive a truck through. This would be carte blanche for withholding the source code for all sorts of modifications and extensions to GPL-covered software.

Giving all users access to the source code is one of our main goals, so this consequence is definitely something we want to avoid.

More concretely, the versions of the programs linked with the Money Guzzler libraries would not really be free software as we understand the term--they would not come with full source code that enables users to change and recompile the program.

명시적으로 금지된 듯 합니다.

Prentice의 이미지

(사족입니다만..

Tony wrote:
"In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. "

이부분이 추가된걸 제가 몰랐었네요. GPLv1에서는 저게 허용되지않았던걸로 알고있습니다. ^^;

GPLv1에도 "Mere aggregation of another independent work with the Program (or its
derivative) on a volume of a storage or distribution medium does not bring
the other work under the scope of these terms."라고 나와 있습니다.)

체스맨의 이미지

검은해 wrote:

GPL 프로그램을 개작한 뒤에 돈벌레 주식회사가 만든 독점 라이브러리와 링크시키고 싶습니다.

이 부분은 저도 읽어본 적이 있는데, 경우가 다른 것 같습니다.

(1) 올려주신 글에서는, 이미 GPL인 프로그램을 개작했고
거기에 독점 라이브러리를 추가하려는 경우입니다.

(2) 질문자께서는 (제가 이해한 게 맞다면) 독점 라이브러리와
GPL 라이브러리를 호출하는 새로운 GPL 소프트웨어를
만드는 경우입니다.

첫번째는 안되는 게 맞고, 두번째는 되는 게 맞다고 봅니다.
두번째가 안되면, 독점 라이센스의 플렛폼에서는 GPL 소프트웨어를
개발할 수 없을 것 같거든요.

Orion Project : http://orionids.org

Prentice의 이미지

첫번째와 두번째가 다를 이유가 없다는 쪽에 한표 던집니다.

독점 라이브러리를 링크하지 않고, 독점 시스템의 퍼블릭 인터페이스만을 사용하여 GPL 소프트웨어를 개발할 수 있죠. Cygwin도 그렇지 않을까요? Win32용 GNU Emacs에서 Win32용 프로그램도 제작 가능합니다.

체스맨의 이미지

검은해 wrote:
첫번째와 두번째가 다를 이유가 없다는 쪽에 한표 던집니다.

독점 라이브러리를 링크하지 않고, 독점 시스템의 퍼블릭 인터페이스만을 사용하여 GPL 소프트웨어를 개발할 수 있죠. Cygwin도 그렇지 않을까요?

첫번째는 GPL 공동체에 영향을 미칩니다. 이미 GPL 로 퍼져있을
가능성이 높은 소프트웨어에 영향을 준 것이니까요.

두번째는 그렇지 않습니다. 두번째처럼 만들어진 소프트웨어는
이후 개작자의 판단하에 사용 안하면 그만입니다. GPL 측에 피해를
입히고 있는 점이 없습니다.

그리고 독점 라이브러리를 링크하는 것과 퍼블릭 인터페이스를
링크하는 게 별반 차이가 있을까요? 윈32 커널 호출을 위해서
커널의 임포트 라이브러리를 링크해야만 하는데요.

Orion Project : http://orionids.org

Prentice의 이미지

영향의 차이나 이데올로기적 측면에서의 차이는 라이센스 적용의 해석에는 불필요할 것 같습니다. 아무튼 FSF에서는 "GPL을 존패 가능성을 위협하기에 충분한" 일이라고 보고 있는 것 같은데요..

첫번째와 두번째가 무슨 이유 때문에 라이센스가 다르게 적용되고 있(?)는지 설명 부탁드립니다.

사실 저는 "퍼블릭 인터페이스를 링크한다"가 무슨 뜻인지 제대로 모릅니다. 그러나 현재 체스맨님께서 말씀하고 계신 독점 시스템에 대한 말씀은 현실과 맞지 않는 것 같습니다.

hey의 이미지

두 번째 경우라는게

체스맨 wrote:

(2) 질문자께서는 (제가 이해한 게 맞다면) 독점 라이브러리와
GPL 라이브러리를 호출하는 새로운 GPL 소프트웨어를
만드는 경우입니다.

이거죠. 만약 이게 안된다면 윈도우에서 win32 라이브러리를 사용하는 GPL 소프트웨어를 만들 수 없습니다. 그런데, 이게 만약 허용되는 행위라고 해도 윈도우 씨디에 이 새로 만든 GPL 소프트웨어를 포함해서 배포한다면 라이센스가 어떻게 되는지에 대한 근거는 아직 안나온 것 같습니다.

정리삼아.


----------------------------
May the F/OSS be with you..


Tony의 이미지

cygwin은 논의대상에서 빼야합니다.
"However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."

이런말로도 cygwin은 빠져나갈 여지가 얼마든지 있기때문에......

체스맨의 이미지

검은해 wrote:
영향의 차이나 이데올로기적 측면에서의 차이는 라이센스 적용의 해석에는 불필요할 것 같습니다. 아무튼 FSF에서는 "GPL을 존패 가능성을 위협하기에 충분한" 일이라고 보고 있는 것 같은데요..

첫번째와 두번째가 무슨 이유 때문에 라이센스가 다르게 적용되고 있(?)는지 설명 부탁드립니다.

사실 저는 "퍼블릭 인터페이스를 링크한다"가 무슨 뜻인지 제대로 모릅니다. 그러나 현재 체스맨님께서 말씀하고 계신 독점 시스템에 대한 말씀은 현실과 맞지 않는 것 같습니다.

올려주신 글과 같은 상황은 분명히 GPL 의 존폐 가능성을
위협합니다. 이미 GPL로 퍼져있는 녀석에 자기 맘대로 독점
라이센스 소프트웨어를 끼워넣는 행위니까요.

이 개작물이 퍼져나가면, 돈벌레 회사의 라이센스를 사야만 하는
어찌보면 강매가 이루어질 수 있으니, 이것은 분명히 '존폐'를
논할만큼 중대한 문제겠죠.

하지만 독점 및 GPL 을 호출하는 새로운 GPL 소프트웨어를
만들어내는 것은 다릅니다. 이미 그 새로운 GPL 소프트웨어가
배포되는 시점에서 그것이 독점 라이센스를 갖는 녀석과
링크되어있다는 것을 알고 있기 때문입니다.

cygwin 으로 설명해보면, 사용자는 cygwin 이란 놈이
윈도와 링크되어 있으므로, cygwin 을 쓰려면 윈도를
사야한다는 것을 압니다. 이미 알고 시작하기 때문에
문제가 없다는 것이죠.

Orion Project : http://orionids.org

Prentice의 이미지

"알고 있다는 지식"도 라이센스 해석의 면에서는 불필요할 것 같습니다.

Cygwin의 경우는 Tony님께서 말씀해주신 부분이 해당할 것 같습니다.

Prentice의 이미지

hey wrote:
그런데, 이게 만약 허용되는 행위라고 해도 윈도우 씨디에 이 새로 만든 GPL 소프트웨어를 포함해서 배포한다면 라이센스가 어떻게 되는지에 대한 근거는 아직 안나온 것 같습니다.

GPL 소프트웨어와 다른 소프트웨어의 같은 매체에서의 배포에 대한 얘기는 이미 나왔었습니다. (edit: 아, 설명은 드리지 않았네요. 제가 링크한 글에 나와 있습니다.)

제가 말한 경우면, 경우에 따라 각자 독립적인 라이센스의 적용이 가능하기도 합니다.

체스맨의 이미지

Cygwin 은 일례이고, 윈도상에서 작동하는 모든 GPL 소프트웨어에 해당합니다.

'알고 있다' 가 중요한 것 아닌지요?

예전에 Qt 문제가 어떠했나요? 제가 기억하기론 Qt 가 GPL 호환이
아니었을 때 그것을 사용함에 제기됐던 문제는 라이센스 위반 문제가
아니었던 것으로 아는데요...

Orion Project : http://orionids.org

Prentice의 이미지

먼저 저는 QT에 대해 아무것도 모릅니다.

Quote:
(1) 올려주신 글에서는, 이미 GPL인 프로그램을 개작했고
거기에 독점 라이브러리를 추가하려는 경우입니다.

(2) 질문자께서는 (제가 이해한 게 맞다면) 독점 라이브러리와
GPL 라이브러리를 호출하는 새로운 GPL 소프트웨어를
만드는 경우입니다.


GPL 프로그램에 독점 라이브러리를 추가하는 것은 금지되어 있다는 것은 동의하십니다.

독점 라이브러리를 호출하는 GPL 프로그램의 신규 작성이 허용(?)되는 이유가 "링크 여부와 라이센스를 알고 있다"와 무슨 관련이 있나요? 라이센스 적용의 해석과는 무관하지 않나요..?

독점 라이브러리를 링크하고 있는 신규 GPL 소프트웨어를 아시면 말씀 부탁드립니다. Cygwin 말고요..

체스맨의 이미지

독점 라이브러리를 호출하는 GPL 프로그램의 신규 작성이
허용된다는 명시적인 구문은 없는 것 같습니다.

이것은 GPL 에서 허용하고 말고할 문제가 아닐 것 같습니다.
그럼에도 불구하고 만일 이것을 허용하지 않으면, 어떻게 독점
OS 상에서 작동하는 GPL 소프트웨어를 만들 수 있는 지 설명해
주셔야 합니다.

독점 라이브러리를 링크하고 있는 '신규' GPL 소프트웨어라
하시면 딱히 생각나는 것은 없습니다.

하지만 윈도상에서 작동하는 모든 GPL 소프트웨어는
독점 라이브러리를 링크하는 GPL 소프트웨어 아닌지요?

Orion Project : http://orionids.org

Prentice의 이미지

hey wrote:
체스맨 wrote:

(2) 질문자께서는 (제가 이해한 게 맞다면) 독점 라이브러리와
GPL 라이브러리를 호출하는 새로운 GPL 소프트웨어를
만드는 경우입니다.

이거죠. 만약 이게 안된다면 윈도우에서 win32 라이브러리를 사용하는 GPL 소프트웨어를 만들 수 없습니다.


Win32 라이브러리를 사용하는 GPL 소프트웨어는 못 만들더라도,

http://www.mingw.org/mingwfaq.shtml#faq-w32api

w32api를 사용하는 GPL 소프트웨어는 만들 수 있을 것입니다.

체스맨의 이미지

검은해 wrote:
hey wrote:
체스맨 wrote:

(2) 질문자께서는 (제가 이해한 게 맞다면) 독점 라이브러리와
GPL 라이브러리를 호출하는 새로운 GPL 소프트웨어를
만드는 경우입니다.

이거죠. 만약 이게 안된다면 윈도우에서 win32 라이브러리를 사용하는 GPL 소프트웨어를 만들 수 없습니다.


Win32 라이브러리를 사용하는 GPL 소프트웨어는 못 만들더라도,

http://www.mingw.org/mingwfaq.shtml#faq-w32api

w32api를 사용하는 GPL 소프트웨어는 만들 수 있을 것입니다.

링크에 쓰여있는 것은, 헤더와 임포트라이브러리를 별도로
제작했기 때문에 이들 패키지는 라이센스 문제가 없다는 것입니다.

하지만, 결과적으로는 kernel32, user32, gdi32 와 링크하게
됩니다. 이것은 독점 라이센스의 DLL 들입니다.

저도 이야기를 하면서 미심쩍은 것이 좀 있긴 합니다...
어렵네요, 매번.

Orion Project : http://orionids.org

Prentice의 이미지

kernel32, user32, gdi32등은 Tony님께서 말씀해주신 "기본 시스템과 포함되는 부분"이므로 해당사항이 없을 것입니다. Cygwin처럼요.

저는 그러므로 질문자분께서 질문하신 내용은 GPL 위반이다에 한 표 던집니다.

happyjun의 이미지

그런데 원래 질문하신분은 GPL이 아닌 LGPL 을 물어보신 것 같습니다. LGPL의 경우 동적 링크의 경우 라이센스를 LGPL로 할 이유는 없습니다.

----------------------------------------
http://moim.at
http://mkhq.co.kr

Prentice의 이미지

happyjun wrote:
그런데 원래 질문하신분은 GPL이 아닌 LGPL 을 물어보신 것 같습니다. LGPL의 경우 동적 링크의 경우 라이센스를 LGPL로 할 이유는 없습니다.

아뇨, LGPL을 링크하는 라이브러리는 LGPL일 필요가 없어서 클로스드 소스를 사용하셨다고 하셨습니다. 그래서 GPL의 아니라 LGPL 라이브러리를 쓰셨다고도..
espereto의 이미지

http://www.gnu.org/licenses/gpl-faq.ko.html#MoneyGuzzlerInc

Quote:

링크하려고 하는 라이브러리가 GPL이 규정하는 다음과 같은 예외 조항에 해당되는 지 살펴보기 바랍니다. 만약 그렇다면 라이브러리를 사용하기 위해서 특별히 해야 할 일은 없습니다. 다시 말해서, 링크하고자 하는 라이브러리가 독점 운영체제의 주요 구성 요소로 함께 제공되고 있는 경우에는 GPL 프로그램을 링크해서 사용해도 됩니다.

그러나 특별한 예외의 하나로서 자신이 배포할 프로그램의 실행물에
컴파일러나 커널 등과 같은, 프로그램이 실행될 운영체제의 주요 구성
요소로서 (소스나 바이너리의 형태로) 운영체제와 함께 배포되는
부분들이 함께 포함되어 배포되지 않는한, 이러한 부분들에 대한 소스
코드는 배포할 소스 코드 안에 포함시키지 않아도 무방하다.

만약 이러한 경우에 해당하지 않는 라이브러리에 여러분이 만든 프로그램을 링크하고자 한다면, GPL에 덧붙여서 다음과 같은 형식의 예외 조항을 여러분이 직접 설정할 수 있습니다.
... 이하 생략 ...


이게 답이 될 것 같은데요...
그러나, 이 경우도 새로 개발하는 자유 소프트웨어인 경우에만 해당될 것 같은데, 맞나요?

그리고, closed license인 라이브러리가 어디에서 어떻게 쓰이는지는 jhoonk님께서 말씀하시지 않은 상황이어서, 위반인지 아닌지는 알 수 없을 것 같습니다.

espereto의 이미지

jhoonk wrote:

회사에서 Linux를 가지고 PMP를 개발한다고 가정하겠습니다.
다른 모든 모듈,드라이버,애플리케이션은 GPL로 개발을
했는데 한개의 라이브러리만 다른 회사의 모듈을 사온것이라
GPL이 아닌 closed license로 개발을 하였습니다.

물론 그 회사의 라이브러리는 kernel의 system호출만을사용하고
GNU library중에선 LGPL인 것들을 다이내믹링크로만 사용
하였기 때문에 GPL로 걸리지 않는다고 가정합니다.


음. 말씀하셨군요. -_-a

애플리케이션이 GPL로 된 기존의 자유 소프트웨어를 개작한 것이라면 모르겠는데, 새로 개발한 것이라면 예외조항을 두어서 위반되지 않도록 할 수 있을 것 같은데요......

hey의 이미지

음 그렇네요. 이해했습니다. 위의 제 의견은 취소합니다.


----------------------------
May the F/OSS be with you..


체스맨의 이미지

검은해 wrote:
kernel32, user32, gdi32등은 Tony님께서 말씀해주신 "기본 시스템과 포함되는 부분"이므로 해당사항이 없을 것입니다. Cygwin처럼요.

저는 그러므로 질문자분께서 질문하신 내용은 GPL 위반이다에 한 표 던집니다.

제가 생각하기에도 검은해님 말씀대로가 아니라면 어떤 식으로든
GPL 에 해를 가하는 방법이 생길 것 같아 보이긴 합니다.

그런데 '기본 시스템' 이라는 것이 참 애매한데요.
기본 시스템을 누가 정의하냐에 따라 결과가 다르겠군요.

msvcrt.dll 은 기본시스템입니까?
MS 오피스는 기본 시스템입니까?
MS 가 msvcrt 에 MS 오피스 COM 개체를 호출하는 함수를 집어넣으면, 윈도 상에서 돌아가는 모든 GPL 소프트웨어는 GPL 위반이 되는 건가요...?

Orion Project : http://orionids.org

hey의 이미지

쓰레드 가지치기 하는게 좋겠습니다 :]


----------------------------
May the F/OSS be with you..


Prentice의 이미지

체스맨 wrote:
그런데 '기본 시스템' 이라는 것이 참 애매한데요.
기본 시스템을 누가 정의하냐에 따라 결과가 다르겠군요.

msvcrt.dll 은 기본시스템입니까?
MS 오피스는 기본 시스템입니까?
MS 가 msvcrt 에 MS 오피스 COM 개체를 호출하는 함수를 집어넣으면, 윈도 상에서 돌아가는 모든 GPL 소프트웨어는 GPL 위반이 되는 건가요...?


원문을 보죠. 기본 시스템이라는 것은 제 표현이었습니다.

Quote:
[...] anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs [...]

실행파일이 동작하는 OS의 주요 요소(컴파일러, 커널 등)과 함께 통상적으로 (바이너리 형태로든 소스 형태로든) 배포되는 부분..이라고 나와 잇습니다. 이에 맞게 해석하면 되겠죠?

kernel32, user32, gdi32는 여기 해당할 것입니다.

espereto의 이미지

체스맨 wrote:
검은해 wrote:
kernel32, user32, gdi32등은 Tony님께서 말씀해주신 "기본 시스템과 포함되는 부분"이므로 해당사항이 없을 것입니다. Cygwin처럼요.

저는 그러므로 질문자분께서 질문하신 내용은 GPL 위반이다에 한 표 던집니다.

제가 생각하기에도 검은해님 말씀대로가 아니라면 어떤 식으로든
GPL 에 해를 가하는 방법이 생길 것 같아 보이긴 합니다.

그런데 '기본 시스템' 이라는 것이 참 애매한데요.
기본 시스템을 누가 정의하냐에 따라 결과가 다르겠군요.

msvcrt.dll 은 기본시스템입니까?
MS 오피스는 기본 시스템입니까?
MS 가 msvcrt 에 MS 오피스 COM 개체를 호출하는 함수를 집어넣으면, 윈도 상에서 돌아가는 모든 GPL 소프트웨어는 GPL 위반이 되는 건가요...?

제가 링크 건 글에도 나오고, 인용도 한 내용입니다만 다시 한 번 인용합니다.

Quote:

링크하려고 하는 라이브러리가 GPL이 규정하는 다음과 같은 예외 조항에 해당되는 지 살펴보기 바랍니다. 만약 그렇다면 라이브러리를 사용하기 위해서 특별히 해야 할 일은 없습니다. 다시 말해서, 링크하고자 하는 라이브러리가 독점 운영체제의 주요 구성 요소로 함께 제공되고 있는 경우에는 GPL 프로그램을 링크해서 사용해도 됩니다.

그러나 특별한 예외의 하나로서 자신이 배포할 프로그램의 실행물에
컴파일러나 커널 등과 같은, 프로그램이 실행될 운영체제의 주요 구성
요소로서 (소스나 바이너리의 형태로) 운영체제와 함께 배포되는
부분들이 함께 포함되어 배포되지 않는한, 이러한 부분들에 대한 소스
코드는 배포할 소스 코드 안에 포함시키지 않아도 무방하다.

우선은, OS와 함께 배포되는 부분들과 링크되면서, 그런 파일들을 같이 배포하지 않는 경우는 예외로 두는 듯 합니다.

체스맨의 이미지

다시 해보겠습니다.

MS office 는 기본시스템이 아닙니다.

만약에 MS 가 어떤 이유든 기본 시스템에 엑셀 COM 과 연결하여
엑셀 파일을 만드는 함수를 집어넣었습니다.

검은해님 말씀대로라면, 이경우 GPL 소프트웨어들은, 기본
시스템이 아닌 독점 라이센스인 녀석과 연결되게 됩니다. 이 경우,
윈도 상에서 작동하던 GPL 소프트웨어들은, 자기 스스로 취한 GPL 에
의해 자멸하게 되는 것인지요?

이것은 물고 늘어지려 게 아니라, 제가 확실히 이해하고 싶어서
그렇습니다. 그리고 만일 위와 같다면 MS 가 자신의 OS 에서 GPL
소프트웨어들을 없애버리는 게 아주 쉽지 않습니까?

Orion Project : http://orionids.org

체스맨의 이미지

일단 espereto 님 께서는 예외 조항에 의해 질문자께서 하시려는
의도가 가능하다고 말씀하시는 것 같습니다. 맞나요?
링크된 글로도 맞는 것 같은데요...

Orion Project : http://orionids.org

espereto의 이미지

체스맨 wrote:

일단 espereto 님 께서는 예외 조항에 의해 질문자께서 하시려는
의도가 가능하다고 말씀하시는 것 같습니다. 맞나요?
링크된 글로도 맞는 것 같은데요...

네. 맞습니다.
즉, closed license인 라이브러리와 링크된 어플리케이션이 GPL이라도, 예외조항을 두어서 GPL 위반이 되는 상황을 피해갈 수 있다고 생각했습니다. 단, 그 어플리케이션은 직접 개발한 것이어야 하고, 기존 GPL 소프트웨어를 개작하는 경우에는 어떻게 되는 지 모르겠습니다.

체스맨 wrote:
다시 해보겠습니다.

MS office 는 기본시스템이 아닙니다.

만약에 MS 가 어떤 이유든 기본 시스템에 엑셀 COM 과 연결하여
엑셀 파일을 만드는 함수를 집어넣었습니다.

검은해님 말씀대로라면, 이경우 GPL 소프트웨어들은, 기본
시스템이 아닌 독점 라이센스인 녀석과 연결되게 됩니다. 이 경우,
윈도 상에서 작동하던 GPL 소프트웨어들은, 자기 스스로 취한 GPL 에
의해 자멸하게 되는 것인지요?

이것은 물고 늘어지려 게 아니라, 제가 확실히 이해하고 싶어서
그렇습니다. 그리고 만일 위와 같다면 MS 가 자신의 OS 에서 GPL
소프트웨어들을 없애버리는 게 아주 쉽지 않습니까?

여기에 대한 제 생각은,
기본 시스템에 엑셀 COM을 연결하는 함수를 만들어 넣었다고 하더라도 그 함수를 호출하는 것은 엑셀과 링크되는 것이 아닌 기본시스템과 링크되는 것으로 봐야할 것 같습니다. 즉, 기본 시스템이 또다른 무언가와 링크되는 건 상관없을 것 같습니다. 단, 엑셀의 COM을 직접 호출하게되면 스스로 GPL 위반이 되는 경우가 될 것 같습니다. *단, 이 경우에도 예외조항을 이용하여 GPL의 특별한 예외로 두는 것으로 GPL에 위배되지 않도록 하는 것이 가능하다고 봅니다. 물론, 저작권자가 그렇게 GPL의 예외조항을 추가해야겠지만요.

* 표시된 부분이 추가된 부분입니다.

Prentice의 이미지

체스맨 wrote:
검은해님 말씀대로라면, 이경우 GPL 소프트웨어들은, 기본
시스템이 아닌 독점 라이센스인 녀석과 연결되게 됩니다.

제 말중에 그런 내용은 없는 것 같습니다.
체스맨의 이미지

생각을 좀 정리했습니다.

제가 말씀드리고 싶은 것은 이것이었습니다.

윗글들에서 '기본 시스템'을 정의한 주체는 GPL 측입니다.
만일 MS 에서 "너희들이 말하는 기본 시스템을 우리는
기본 시스템이라 보지 않는다."

라고 했다해서 윈도에서 작동하는 GPL 소프트웨어들이
기본시스템이 아닌 독점 소프트웨어와 연결되어
GPL 위반이 되어버리는 것은 아니라는 것입니다.

결국 '기본 시스템'이라 일컬어지는 것은 espereto 님 께서
말씀해주신 것처럼 '예외 조항'의 관점에서 보아야 하고,
결론적으로 예외 조항에 의해 독점 및 GPL을 호출하는 GPL
소프트웨어를 만들 수 있다는 것입니다.

물론 권장 사항은 아니겠지만, 라이센스상 하자는 없다는
것이지요. 그것을 만드는 저작권자가 결정할 일이니까요.
애초부터 이것을 말하려고 했습니다. 중간에 몇몇 실수가 있는 것은
죄송하구요, 뭐 어떤 의도가 있는 것은 아니었습니다.

Orion Project : http://orionids.org

jhoonk의 이미지

처음 질문을 했던 사람입니다.
어려운내용이군요. 답변주신 것도 잘 이해가 가지 않습니다.

질문중에 한가지를 수정하면 좀더구체적으로 예를들어보겠습니다.
PMP를 개발했고 다른 모든 부분은 GPL이라고 가정합니다.
그런데 예를들어 PDF뷰어를 넣었다고 가정하겠습니다.
그 pdfreader라는 application이 있고 pdfreader는
pdflib.a라는 lib와 libc를 다이내믹링크로 사용합니다.
pdflib.a는 커널의 시스템호출과 libc의 다이내믹링크만
이용합니다.

그리고 pdfreader와 pdflib.a는 둘다 closed소스입니다.
여기까지는 GPL위반사항이 전혀없다고 가정합니다.
둘다 GPL을 링크하지 않고 LGPL만을 링크했습니다.

이제 이 pdfreader와 pdflib.a를 제품이 출시될때 기본기능으로
함께 묶어서 판매를 할려고 합니다. 이것이 GPL위반인지가
궁금합니다.(이해를 하신분들에겐 똑같은 질문입니다)

물론 배포후 사후소스오픈에 대해서도 GNU를 모두 그대로
지킨다고 가정합니다. 단 위 두개는 역시 바이너리로만
제공합니다.

딱 결론을 내주실수있으신가요. 그렇다면 정말 감사하겠습니다
ㅠ.ㅠ

Prentice의 이미지

RTGPL. ;) GPLv2의 2조를 읽어보시고 스스로 판단하세요.

espereto의 이미지

jhoonk wrote:
처음 질문을 했던 사람입니다.
어려운내용이군요. 답변주신 것도 잘 이해가 가지 않습니다.

질문중에 한가지를 수정하면 좀더구체적으로 예를들어보겠습니다.
PMP를 개발했고 다른 모든 부분은 GPL이라고 가정합니다.
그런데 예를들어 PDF뷰어를 넣었다고 가정하겠습니다.
그 pdfreader라는 application이 있고 pdfreader는
pdflib.a라는 lib와 libc를 다이내믹링크로 사용합니다.
pdflib.a는 커널의 시스템호출과 libc의 다이내믹링크만
이용합니다.

그리고 pdfreader와 pdflib.a는 둘다 closed소스입니다.
여기까지는 GPL위반사항이 전혀없다고 가정합니다.
둘다 GPL을 링크하지 않고 LGPL만을 링크했습니다.

이제 이 pdfreader와 pdflib.a를 제품이 출시될때 기본기능으로
함께 묶어서 판매를 할려고 합니다. 이것이 GPL위반인지가
궁금합니다.(이해를 하신분들에겐 똑같은 질문입니다)

물론 배포후 사후소스오픈에 대해서도 GNU를 모두 그대로
지킨다고 가정합니다. 단 위 두개는 역시 바이너리로만
제공합니다.

딱 결론을 내주실수있으신가요. 그렇다면 정말 감사하겠습니다
ㅠ.ㅠ


이 경우에 대한 제 의견은, "문제없다"입니다. GPL인 소스나 라이브러리와 링크되지 않는 이상은 말이죠.
그러나, LGPL인 라이브러리와 링크되는 것도 주의해야 할 점이 있습니다. 정확하게 알고 있는 건지는 자신이 없습니다만, 동적인 링크인 경우 LGPL로부터 자유로울 수 있고, 정적 링크가 이루어지면 LGPL 및 GPL로부터 자유로울 수 없다고 알고 있습니다.
단, 이러한 경우 어느 정도는 "예외조항"을 이용하여 비껴갈 수 있을 거라 생각됩니다. 단, 예로 드셨던, PDF Reader의 저작권자여야 하며, 저작권자가 아니라면 예외조항을 만들어서 적용시키지 못할 수도 있습니다.