현재 위치

홈 ›› Forums ›› 이슈 ›› 토론, 토의

GPL의 적용 범위는 어디까지인가?

lsj0713의 이미지
글쓴이: lsj0713 / 작성시간: 일, 2003/06/29 - 9:59오전

얼마전 P모 사이트에서 어떤분과 토론을 하게 된 적이 있었습니다. 그분의 말로는 gcc로 컴파일을 하게 되면 GPL 라이센스를 따라야 된다는 것이었습니다. 그 말을 듣고 곰곰히 생각해보니, 참으로 골때리는 문제가 아닐 수가 없었습니다.

만약 어떤 회사가 자신들이 만든 상용 프로그램의 리눅스용 버젼을 컴파일하기 위해 gcc로 자신들의 프로그램을 컴파일한다면, 그것만으로도 그 프로그램을 GPL로 공개해야 된다는 얘기 아니겠습니까? 또한, gcc 만 사용하는 것은 아무런 문제가 없다고 하더라도 모듈이나 디바이스 드라이버 등과 연관지어 생각을 한다면 굉장히 골치아픈 일이 아닐 수 없습니다.

LGPL의 경우에도 동적 링크는 상관없지만 정적 링크일 경우에는 GPL을 따라야 한다는 얘기도 어디선가 들은 일이 있습니다. 이렇듯 GPL에 관련된 여러가지 사항들이 굉장히 까다롭기에, 토론을 통해서 관련사항에 대해 좀 더 자세히 알고자 합니다.

물론 저는 GPL이 더 많이 보급되길 원하고, GPL이 더더욱 널리 퍼지길 원하는 FSF의 입장을 이해합니다. 그러나 제가 만약 회사에 취직하여 리눅스용 상용 프로그램을 개발해야 한다면 이것은 아주 골때리는 문제가 아닐 수 없습니다.

이런 법적인 문제에 대해서 많은 분들의 고견을 듣고 싶습니다. 또한 관련 링크자료에 대한 링크도... :-)

ps. 뭣하러 GPL 소프트웨어와 독점 소프트웨어를 굳이 연결하려 하느냐 하는 글은 지양해주시길 부탁드립니다. 실무에 종사하는 많은 사람들과 기업들이 이러한 연결을 실제적으로 필요로 합니다. 여기서는 그것이 옳다 그르다 같은 문제보다는, 법적인 문제와 어느 선까지 허용이 되느냐와 같은 실질적인 문제에 대해 토론했으면 좋겠습니다.

ps2. 위의 "얼마전 P모 사이트에서 어떤분과 토론을 하게 된 적이 있었습니다. 그분의 말로는 gcc로 컴파일을 하게 되면 GPL 라이센스를 따라야 된다는 것이었습니다. "라는 문장에서, '그분'께서는 그런 말을 하신 적이 없고, 전적으로 저의 오해에서 비롯된 일임을 밝혀둡니다. 그분께는 이자리를 빌어 사과드립니다.

그러나 어쨌거나, 이 토론 주제는 제가 평소에 궁금하게 생각하고 있기에 올린 것임을 밝혀둡니다. 토론이 진행되는 데에 영향을 끼치지 않기를 바랍니다.

Forums: 
토론, 토의
afsadfsaf의 이미지

글쓴이: afsadfsaf / 작성시간: 일, 2003/06/29 - 10:36오전

음 왜 GCC로 컴파일하면 GPL을 따라야하죠?
GCC가 컴파일할때 라이브러리 코드를 실행파일에 합치는거때문인가.. -_-

그렇다면 만약 NetHack으로 세이브한 파일이 있다면,
그 세이브파일을 무조건 공개해야 하나요?

........

L-System

lsj0713의 이미지

글쓴이: lsj0713 / 작성시간: 일, 2003/06/29 - 10:58오전

yubgipenguin wrote:
음 왜 GCC로 컴파일하면 GPL을 따라야하죠?
GCC가 컴파일할때 라이브러리 코드를 실행파일에 합치는거때문인가.. -_-

그런 주장을 펼치는 사람들의 주장에 따르면 그렇습니다. 제 생각에는 포함되는 라이브러리가 GPL이라면 맞는 소리고, LGPL이면 틀릴 것 같습니다만 법적인 지식이 없는지라 뭐라 속단할 수가 없군요.

yubgipenguin wrote:
그렇다면 만약 NetHack으로 세이브한 파일이 있다면,
그 세이브파일을 무조건 공개해야 하나요?

........

NetHack의 경우하고는 다른데, NetHack의 세이브 파일에는 NetHack의 실행 코드가 포함되지 않기 때문이죠. GIMP로 만든 그래픽 파일의 저작권을 GPL로 할 필요가 없는 것과 같은 이유입니다.

ohhara의 이미지

글쓴이: ohhara / 작성시간: 일, 2003/06/29 - 12:20오후

GPL은 GPL인 툴을 사용해서 나온 결과물까지 GPL을 적용해야 된다는 강제규정은 없습니다.

그렇게 되면 compiler만 문제가 걸리는 것이 아니라 흔히들 많이 사용하는 bison이나 flex를 이용해 만든 파서는 물론이고 심지어는 vim을 사용해서 만든 문서도 GPL이 되어야 합니다.

하지만 binary level에서 link가 된다면 dynamic link라고 할지라도 GPL을 따라야 합니다. LGPL인 경우에는 dynamic link를 했을 경우에는 GPL을 따르지 않아도 된다는 예외를 인정해 줍니다.

하지만 위의 것도 잘 보면 알 수 있겠지만 dynamic link에만 한정됩니다. 즉 static link를 했을 경우에는 GPL을 적용해야만 합니다. 이것이 특별한 문제를 일으키지 않는다고 생각하는 분도 있을 수 있는데 embedded software를 개발하는 개발자입장에서는 상당히 심각한 문제를 일으킬 수도 있습니다. embedded os는 dynamic link는 지원하지 않고 static link만을 지원하는 경우가 대부분이기 때문입니다. 한 예로 SDL은 LGPL을 따르는데 이로 인해 embedded os에서 SDL을 사용하는 것이 쉽지 않습니다. ( linux를 쓴다면 문제가 없겠지만. :) )

저런 복잡한 문제들로 인해 회사에서 일하게 되면 GPL코드들은 안보고 BSD License인 소스코드들을 많이 뒤져보게 됩니다. zlib이나 png decoder나 freebsd kernel이라던가... :)

Taeho Oh ( ohhara@postech.edu ) http://ohhara.sarang.net
Postech ( Pohang University of Science and Technology ) http://www.postech.edu
Alticast Corp. http://www.alticast.com

Risty의 이미지

글쓴이: Risty / 작성시간: 일, 2003/06/29 - 1:18오후

그럼 바이너리 링크라는 말이 실행 코드만을 한정하는 것인가요?

약간 다른 질문이기는 한데, 예를 들어서 저작 도구를 이용해서 만든 데이터를 이용해서 돌아가는 게임이 있다고 합시다. 그 때 게임 엔진과 저작도구는 GPL 라이선스를 따른다면, 이렇게 해서 나오는 게임은 독점권이 인정될 수 있나요? 게임의 실행 코드야 GPL이니 자유롭게 복제될 수 있겠지만, 데이터를 포함하는 게임 자체는 저작자의 허가가 있어야 복제가 가능한지, 아니면 GPL을 따르기 때문에 무조건 자유롭게 복제가 가능한지 이것이 참 궁금하더군요. 데이터가 없이 실행 코드만으로는 작동하지 않을테니, 한마디로 데이터만을 파는 것이 가능한가 궁금합니다.

물론 GPL로 된 저작물을 유료로 팔 수 있는가 아닌가의 질문은 아닙니다. GPL+GPL을 따르지 않는 데이터의 형태에 대한 이야기입니다.

espereto의 이미지

글쓴이: espereto / 작성시간: 일, 2003/06/29 - 4:57오후

Quote:
얼마전 P모 사이트에서 어떤분과 토론을 하게 된 적이 있었습니다. 그분의 말로는 gcc로 컴파일을 하게 되면 GPL 라이센스를 따라야 된다는 것이었습니다.

GCC로 컴파일하건 말건 상관없이, GPL을 따라야 한다고 강제되지는 않습니다.

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

몇 가지 예를 인용하겠습니다.

Quote:
만약 특정한 프로그래밍 언어에 대한 인터프리터가 GPL로 공표되어 있다면 이러한 인터프리터를 사용해서 만들어진 프로그램에도 GPL과 호환되는 라이선스가 적용되어야 합니까?
인터프리터가 단순히 한 언어를 인터프리트하는 역할을 하는 경우에는 그렇지 않습니다. 인터프리터에 있어서 인터프리트된 프로그램은 단순히 데이터일 뿐입니다. GPL과 같은 자유 소프트웨어 라이선스는 저작권법에 기초하고 있기 때문에 인터프리터를 사용해서 만들어진 데이터를 제한할 수 없습니다. 어떠한 데이터에 대해서도 인터프리터를 사용할 수 있으며, 인터프리트된 데이터에 대한 어떠한 요구도 할 수 없습니다.
그러나 인터프리터가 라이브러리와 같은 요소와 바인딩되도록 확장되어 있을 경우에는, 인터프리트된 결과로 만들어진 프로그램이 바인딩을 통해서 라이브러리와 링크될 것입니다. 만약 라이브러리가 GPL로 공표된 것이었다면, 인터프리트 되어 만들어진 프로그램은 GPL과 호환되는 형태로 공표되어야 합니다. 이러한 예로 JNI와 자바 네이티브 인터페이스를 들 수 있습니다. 이러한 방법으로 접근되는 라이브러리들은 이들을 호출하는 자바 프로그램과 다이나믹하게 링크됩니다.

또하나의 일반적인 사례는 인터프리터와 이 인터프리터를 사용해서 인터프리트된 라이브러리들이 함께 제공되는 경우입니다. 예를 들면, Perl 인터프리터는 많은 종류의 Perl 모듈들과 함께 제공되고 자바 구현물에는 많은 양의 자바 클래스들이 함께 제공됩니다. 이러한 경우에는 라이브러리와 라이브러리를 호출하는 프로그램이 항상 다이나믹하게 링크되어 함께 사용됩니다.

결과적으로 GPL로 공표된 Perl 모듈이나 자바 클래스를 여러분이 만든 프로그램에 포함시키기로 결정했다면 결합된 Perl이나 자바 프로그램이 실행될 인터프리터들의 라이선스에 상관없이, 여러분의 프로그램은 GPL과 호환되는 방식으로 공표되어야만 합니다.

Quote:
GPL로 배포되는 에디터를 자유 소프트웨어가 아닌 소프트웨어를 개발하는데 사용하는 것이 가능합니까? 또한 GPL을 따르는 도구들을 이용해서 자유 소프트웨어가 아닌 코드들을 컴파일하는 것이 가능합니까?
가능합니다. 에디터와 개발 도구들에 대한 저작권은, 도구들을 이용해서 만들어진 코드에 영향을 미치지 않습니다.
몇몇 프로그램들은 기술적인 이유로 프로그램의 일부분을 출력 결과에 복사하기도 합니다. 예를 들면, Bison의 경우에는 표준 파서 프로그램을 출력 파일로 복사합니다. 이러한 경우에는 출력에 포함된 복사 부분이 최초의 라이선스를 그대로 따르게 됩니다. 프로그램의 입력으로부터 파생된 출력은 입력의 저작권 상태를 동일하게 갖습니다.

그러나 Bison은 자유 소프트웨어가 아닌 프로그램을 만드는데 사용될 수 있습니다. 이것은 Bison 출력 파일에 포함될 표준 파서 프로그램에 대한 사용을 제한없이 허용했기 때문입니다. 이러한 결정을 하게된 이유는 자유 소프트웨어가 아닌 프로그램을 만드는데 사용할 수 있는, Bison과 경쟁이 될만한 도구들이 이미 존재하고 있기 때문입니다.

Quote:
어떤 경우에, GPL 프로그램이 만든 결과물에도 GPL이 적용됩니까?
프로그램의 일부분이 결과물로 복사될 때만 가능합니다.

이 정도... 나머지 예들도 더 있지만, 분량이 많아서 ㅡ.ㅡ;

RisaPapa의 이미지

글쓴이: RisaPapa / 작성시간: 일, 2003/06/29 - 5:33오후

lsj0713 wrote:
얼마전 P모 사이트에서 어떤분과 토론을 하게 된 적이 있었습니다. 그분의 말로는 gcc로 컴파일을 하게 되면 GPL 라이센스를 따라야 된다는 것이었습니다. 그 말을 듣고 곰곰히 생각해보니, 참으로 골때리는 문제가 아닐 수가 없었습니다.

아마 제가 쓴 코멘트에 관해서 쓰신것 같은데 다시 한번 더 말씀드리겠습니다. 문장은 있는 그대로 읽고 받아 주시길 바랍니다. 저는 그런말 한 적이 없습니다.

Quote:
그런데 두세달 전에 GPL 라이센스 신봉자들로부터 엄청난 공격과 비난을 받은 적이 있습니다. 다시 말해서 파싱한 부분의 어셈블소스는 GPL 라이센스에 따라야한다는 입장과 그러므로 컴파일된 바이너리도 GPL 라이센스가 적용되어야한다는 말이었습니다. 현재 이것으로 인해서 두세달간 개발을 중지하고 이점에 대해서 새롭게 검토에 들어 갔는데 아직 결론이 나오지 않았습니다. 단지 GPL 라이센스의 GCC컴파일러를 지원하려는 것에서도 이러한 문제가 발생할 요소들이 있다는 점이 있다는 것입니다.

제가 생각하기에 이 글에대한 내용이라고 생각을 하는데 다시 한번 읽어 주시고 "그분의 말로는 gcc로 컴파일을 하게 되면 GPL 라이센스를 따라야 된다는 것이었습니다. " 라고 표현한 내용이 있는지 확인바랍니다.

lsj0713의 이미지

글쓴이: lsj0713 / 작성시간: 일, 2003/06/29 - 5:55오후

RisaPapa wrote:
lsj0713 wrote:
얼마전 P모 사이트에서 어떤분과 토론을 하게 된 적이 있었습니다. 그분의 말로는 gcc로 컴파일을 하게 되면 GPL 라이센스를 따라야 된다는 것이었습니다. 그 말을 듣고 곰곰히 생각해보니, 참으로 골때리는 문제가 아닐 수가 없었습니다.

아마 제가 쓴 코멘트에 관해서 쓰신것 같은데 다시 한번 더 말씀드리겠습니다. 문장은 있는 그대로 읽고 받아 주시길 바랍니다. 저는 그런말 한 적이 없습니다.

Quote:
그런데 두세달 전에 GPL 라이센스 신봉자들로부터 엄청난 공격과 비난을 받은 적이 있습니다. 다시 말해서 파싱한 부분의 어셈블소스는 GPL 라이센스에 따라야한다는 입장과 그러므로 컴파일된 바이너리도 GPL 라이센스가 적용되어야한다는 말이었습니다. 현재 이것으로 인해서 두세달간 개발을 중지하고 이점에 대해서 새롭게 검토에 들어 갔는데 아직 결론이 나오지 않았습니다. 단지 GPL 라이센스의 GCC컴파일러를 지원하려는 것에서도 이러한 문제가 발생할 요소들이 있다는 점이 있다는 것입니다.

제가 생각하기에 이 글에대한 내용이라고 생각을 하는데 다시 한번 읽어 주시고 "그분의 말로는 gcc로 컴파일을 하게 되면 GPL 라이센스를 따라야 된다는 것이었습니다. " 라고 표현한 내용이 있는지 확인바랍니다.

원본글의 링크를 적습니다.

http://phpschool.com/bbs2/inc_view.html?id=16662&code=phorum2&start=0&mode=&field=&operator=&period=&category_id=&s_que=

Quote:

소스를 공개하고 배포하고 안하고의 문제는 제게는 그렇게 절실한 문제는 아닙니다. GPL 라이센스에 지배를 받는가 안받는가에 대한 관점이 제게는 중요한 관건입니다. 제가 참여하여 개발하는 운영시스템도 이점에 대해서는 아주 심도깊게 토론되는 부분입니다. 그리고 진행중의 프로젝트는 BSD와 비슷한(-LIKE) 라이센스입니다. 컴파일러에서 가장 대중적이라고 하면 GCC인데 이 GCC로도 개발이 가능하도록 하는데에 이 라이센스 문제로 많이 고민을 하게됩니다. 일단은 새롭게 GCC를 개조해서 다시 만들고 이러한 라이센스 부분에서 영향력을 배제하기 위한 작업을 해야만 했기 때문에 라이브러리도 처음부터 다시 만들고 실질적으로는 C/C++구문을 파싱하는 부분만 사용을 했고 컴파일 부분은 새로은 어셈블 컴파일러를 개발해야만했습니다. 사용된 소스와 변경부분만을 GPL라이센스를 따르고 이 컴파일러로 생성된 바이너리나 나머지는 BSD와 비슷합니다.

그런데 두세달 전에 GPL 라이센스 신봉자들로부터 엄청난 공격과 비난을 받은 적이 있습니다. 다시 말해서 파싱한 부분의 어셈블소스는 GPL 라이센스에 따라야한다는 입장과 그러므로 컴파일된 바이너리도 GPL 라이센스가 적용되어야한다는 말이었습니다. 현재 이것으로 인해서 두세달간 개발을 중지하고 이점에 대해서 새롭게 검토에 들어 갔는데 아직 결론이 나오지 않았습니다. 단지 GPL 라이센스의 GCC컴파일러를 지원하려는 것에서도 이러한 문제가 발생할 요소들이 있다는 점이 있다는 것입니다.

저는 이 글을 이런 식으로 이해했습니다.

> 일단은 새롭게 GCC를 개조해서 다시 만들고 이러한 라이센스 부분에서 영향력을 배제하기 위한 작업을 해야만 했기 때문에 라이브러리도 처음부터 다시 만들고 실질적으로는 C/C++구문을 파싱하는 부분만 사용을 했고 컴파일 부분은 새로은 어셈블 컴파일러를 개발해야만했습니다.

1. gcc로 컴파일을 하면 라이센스 문제가 생길것 같다. 그래서 새로이 컴파일러를 재구성(또는 재개발?)하였다.

> 그런데 두세달 전에 GPL 라이센스 신봉자들로부터 엄청난 공격과 비난을 받은 적이 있습니다. 다시 말해서 파싱한 부분의 어셈블소스는 GPL 라이센스에 따라야한다는 입장과 그러므로 컴파일된 바이너리도 GPL 라이센스가 적용되어야한다는 말이었습니다.

2. 그러나 이렇게 새로 만든 컴파일러로 컴파일한 바이너리도 GPL 라이센스가 적용되어야 한다는 비난을 받았다.

> 현재 이것으로 인해서 두세달간 개발을 중지하고 이점에 대해서 새롭게 검토에 들어 갔는데 아직 결론이 나오지 않았습니다.

3. 그런 이유로 개발 중지

이정도면 gcc로 컴파일한 바이너리는 GPL을 적용해야 된다는 뜻으로 이해해도 무리가 없지 않습니까? 제가 글읽는 방법이 문제가 있는 것인지, 리사파파님이 아닌 제 3자가 보기에 어떤지 의견 부탁드립니다.

RisaPapa의 이미지

글쓴이: RisaPapa / 작성시간: 일, 2003/06/29 - 6:15오후

Quote:

> 일단은 새롭게 GCC를 개조해서 다시 만들고 이러한 라이센스 부분에서 영향력을 배제하기 위한 작업을 해야만 했기 때문에 라이브러리도 처음부터 다시 만들고 실질적으로는 C/C++구문을 파싱하는 부분만 사용을 했고 컴파일 부분은 새로은 어셈블 컴파일러를 개발해야만했습니다.

1. gcc로 컴파일을 하면 라이센스 문제가 생길것 같다. 그래서 새로이 컴파일러를 재구성(또는 재개발?)하였다.

이 부분은 GCC로 컴파일할 때의 crt0.o 와 libc.a 에 관한 라이센스 규정이 있고 단순히 이 규정의 지배를 받지 않기 위함입니다. 대부분의 사람들이 이 정도의 라이센스 규정이 있다는 것은 알고 있는 것으로 압니다.

Quote:

> 그런데 두세달 전에 GPL 라이센스 신봉자들로부터 엄청난 공격과 비난을 받은 적이 있습니다. 다시 말해서 파싱한 부분의 어셈블소스는 GPL 라이센스에 따라야한다는 입장과 그러므로 컴파일된 바이너리도 GPL 라이센스가 적용되어야한다는 말이었습니다.

2. 그러나 이렇게 새로 만든 컴파일러로 컴파일한 바이너리도 GPL 라이센스가 적용되어야 한다는 비난을 받았다.

이것은 타인(GPL 라이센스 신봉자)의 말과 비난을 인용한것이지 제가 그렇다고 말한 내용은 아닙니다.

Quote:

> 현재 이것으로 인해서 두세달간 개발을 중지하고 이점에 대해서 새롭게 검토에 들어 갔는데 아직 결론이 나오지 않았습니다.

3. 그런 이유로 개발 중지

이 부분에 대한 것은 아직 이러한 사례에 대한 법적 해석 문헌이 적어서 더 조사를 하고 있고 확인을 하지 않으면 현재 적용하고 있는 라이센스도 문제가 발생하기 때문에 더 조사하고 더 알아 보고 있는 것입니다.

Quote:

이정도면 gcc로 컴파일한 바이너리는 GPL을 적용해야 된다는 뜻으로 이해해도 무리가 없지 않습니까? 제가 글읽는 방법이 문제가 있는 것인지, 리사파파님이 아닌 제 3자가 보기에 어떤지 의견 부탁드립니다.

문장에서 가장 중요한것은 누가 라는 주어인데 이 부분에 관한 언급이 없습니다. "그분의 말로는" 라고 인용을 하셨는데 여기에서 누구를 말씀 하시는 것인지 알고 싶습니다. 동사에서 여러가지를 유추해서 내린 결론보다 저는 누가라는 주어가 더 관심의 대상이 되는 것입니다.

lsj0713의 이미지

글쓴이: lsj0713 / 작성시간: 일, 2003/06/29 - 6:27오후

아무래도 제가 글을 잘못 읽은 것 같습니다. 그 부분에 대해서는 사과를 드리겠습니다. 리사파파님께, 글을 잘못 이해한 것에 대해서 진심으로 사과드립니다.

그러나 어쨌거나 토론 주제는 리사파파님과는 전혀 상관 없이, 제가 평소에 궁금하게 생각하던 부분이었기에 글을 올린 것임을 밝혀둡니다.

RisaPapa의 이미지

글쓴이: RisaPapa / 작성시간: 일, 2003/06/29 - 6:38오후

lsj0713 wrote:
아무래도 제가 글을 잘못 읽은 것 같습니다. 그 부분에 대해서는 사과를 드리겠습니다. 리사파파님께, 글을 잘못 이해한 것에 대해서 진심으로 사과드립니다.

그러나 어쨌거나 토론 주제는 리사파파님과는 전혀 상관 없이, 제가 평소에 궁금하게 생각하던 부분이었기에 글을 올린 것임을 밝혀둡니다.

이런 장소에서 공공연하게 무례하게 제가 너무 논리를 내세워 다그친것이 아닌가 하고 반성하고 있습니다. 너무 논리적으로만 살아도 인생은 재미없으니까요. 아무튼 좋은 일만 계시고 훌륭한 모습으로 발전하시기를 기원합니다.

Necromancer의 이미지

글쓴이: Necromancer / 작성시간: 일, 2003/06/29 - 8:35오후

gcc 로 컴파일한 프로그램은 gcc를 이용한 결과물이죠.
이것을 막는건 GPL 조항에는 없습니다.

다만 gcc 프로그램 자체를 개작하거나 프로그램의 일부분 혹은 전부분을
다른 프로그램에 심었다면 그때 GPL이 걸리는거지요.

라이브러리에서 GPL이 문제가 되는 이유는
그 라이브러리를 쓴다는것 자체가 GPL 라이센스 코드를 프로그램에
심는 일이 되기 때문에 그런 겁니다. (라이브러리 없으면 프로그램
안돌잖아요 -_-) 이문제를 좀 완화하려고 나온게 LGPL
이고요.

yubgipenguin wrote:
음 왜 GCC로 컴파일하면 GPL을 따라야하죠?
GCC가 컴파일할때 라이브러리 코드를 실행파일에 합치는거때문인가.. -_-

그렇다면 만약 NetHack으로 세이브한 파일이 있다면,
그 세이브파일을 무조건 공개해야 하나요?

........

Written By the Black Knight of Destruction

cdpark의 이미지

글쓴이: cdpark / 작성시간: 일, 2003/06/29 - 9:37오후

흑기사 wrote:
gcc 로 컴파일한 프로그램은 gcc를 이용한 결과물이죠.
이것을 막는건 GPL 조항에는 없습니다.

inline이나 macro 등을 사용하면 GPL에 위반될 위험이 있습니다. (static link된 셈이니깐요.) GPL은 너무 강합니다. LGPL 정도로 완화되어야죠.

mastercho의 이미지

글쓴이: mastercho / 작성시간: 일, 2003/06/29 - 9:41오후

LGPL은 자세하게 뭔가요?

근데 여기 말대로라면 리눅스 gcc로는 암것도 못만들겠따 --;

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

ohhara의 이미지

글쓴이: ohhara / 작성시간: 일, 2003/06/29 - 9:56오후

cdpark wrote:
흑기사 wrote:
gcc 로 컴파일한 프로그램은 gcc를 이용한 결과물이죠.
이것을 막는건 GPL 조항에는 없습니다.

inline이나 macro 등을 사용하면 GPL에 위반될 위험이 있습니다. (static link된 셈이니깐요.) GPL은 너무 강합니다. LGPL 정도로 완화되어야죠.

LGPL은 static link를 허용하지 않습니다. 즉 LGPL정도로 완화되었다 하더라도 잘못하면 inline이나 macro로 인해 License 위반의 소지가 충분히 있습니다. 저는 개인적으로 LGPL에 static link정도 수준은 허용해 줬으면 하는 생각이 듭니다. 실제로 일부 open source project는 LGPL을 따르되 static link도 허용한다 라는 license를 볼 수 있습니다.

BSD License는 너무 약하고 GPL은 너무 강한 듯 하군요.

Taeho Oh ( ohhara@postech.edu ) http://ohhara.sarang.net
Postech ( Pohang University of Science and Technology ) http://www.postech.edu
Alticast Corp. http://www.alticast.com

cdpark의 이미지

글쓴이: cdpark / 작성시간: 월, 2003/06/30 - 3:40오전

그밖에도 공개 SW 중에 GPL과 호환되지 않는 것이 있다는 것도 문제입니다.
OpenSSL이 대표적이죠. 그래서 GNU 측에서는 따로 TLS를 만들어야 하죠.

GNU readline 대신에 BSD License인 libedit가 따로 있는 것도 마찬가지고요.

완성품인 라이브러리와의 연결이나 컴파일 도중에 붙은 macro/inline 함수 둥에 대해서 GPL이 약간은 완화되어야 한다고 봅니다. 물론 라이브러리의 연결을 위해서 LGPL이 있긴 하지만, 다른 Free SW도 LGPL이 아닌 GPL 쪽 라이브러리와 연결하는데 문제가 있으니깐요.

샘처럼의 이미지

글쓴이: 샘처럼 / 작성시간: 월, 2003/06/30 - 10:09오전

혹시 GPL, LGPL, MPL 1.0, MPL1.1, BSD를 비교하는 사이트가 있을까요? 다들 조금씩 차이는 있는 것으로 알고 있지만, 정확하게 어떤 차이가 있는지 모르겠고... 저도 궁금하여 internet을 여기 저기 찾고 다녀본 적은 있습니다만, 정확하게 명시하여 준 곳은 없더군요. 꼭 internet site가 아니더라도 어느책, 어느잡지 몇월호에 그런 내용이 있다고 알려 주셔도 무방합니다.

TIA

샘처럼 드림

seabird33의 이미지

글쓴이: seabird33 / 작성시간: 수, 2003/08/13 - 3:34오후

ohhara wrote:

LGPL은 static link를 허용하지 않습니다. 즉 LGPL정도로 완화되었다 하더라도 잘못하면 inline이나 macro로 인해 License 위반의 소지가 충분히 있습니다. 저는 개인적으로 LGPL에 static link정도 수준은 허용해 줬으면 하는 생각이 듭니다. 실제로 일부 open source project는 LGPL을 따르되 static link도 허용한다 라는 license를 볼 수 있습니다.

BSD License는 너무 약하고 GPL은 너무 강한 듯 하군요.

LGPL 제6조에서 응용프로그램의 링크와 관련해 응용프로그램의 소스를 공개할 필요가 없는 경우를 나열하고 있는데,
제2항의 경우 명백하게 dynamic link를 허용하고 있으며
제1항에서 static link를 허용하는 것으로 해석됩니다.

GPL의 경우 어느 경우도 허용하지 않고 있지만, linux kernel의 경우
토발즈가 GPL를 적용하면서 추가로 'user program에 의한 정상적인 시스템콜'을 허용하였기 때문에 리눅스 커널을 사용하는 (소스를 공개하지 않은) 상용프로그램이 가능한 것입니다. 하지만 디바이스 드라이버와 관련해서는 약간의 논쟁이 있습니다.

현재 저는 국내 특정 기업의 요청에 의해 GPL, LGPL, BSD, MPL, QPL을 중심으로 오픈소스 소프트웨어 라이센스를 비교 분석하고 있는데, 계약상 결과물을 오픈할 수 없지만, 개별적인 문의에 대해서는 상담 해드리겠습니다.

achrom의 이미지

글쓴이: achrom / 작성시간: 수, 2003/08/13 - 4:06오후

FreeDos라는 GPL을 따르는 Dos가 있습니다.
저는 FreeDos 시스템에서 부팅 디스켓을 만들었습니다.
그래서, 디스켓의 첫부분 raw data를 파일로 저장해서,
그 파일을 사용해서 FreeDos 부팅 디스켓을 만드는 프로그램을 만들었습니다.
즉, 제가 만든 프로그램은 FreeDos의 결과물을 포함하고 있습니다.
이 경우, 저는 프로그램의 소스코드등을 공개해야 하나요?
궁금합니다.^^

whitekid의 이미지

글쓴이: whitekid / 작성시간: 수, 2003/08/13 - 4:33오후

그것도 GPL로 공개해야되는건가?

MySQL도 GPL인걸로 알고있는데..

What do you want to eat?

ohhara의 이미지

글쓴이: ohhara / 작성시간: 수, 2003/08/13 - 5:12오후

seabird33 wrote:
ohhara wrote:

LGPL은 static link를 허용하지 않습니다. 즉 LGPL정도로 완화되었다 하더라도 잘못하면 inline이나 macro로 인해 License 위반의 소지가 충분히 있습니다. 저는 개인적으로 LGPL에 static link정도 수준은 허용해 줬으면 하는 생각이 듭니다. 실제로 일부 open source project는 LGPL을 따르되 static link도 허용한다 라는 license를 볼 수 있습니다.

BSD License는 너무 약하고 GPL은 너무 강한 듯 하군요.

LGPL 제6조에서 응용프로그램의 링크와 관련해 응용프로그램의 소스를 공개할 필요가 없는 경우를 나열하고 있는데,
제2항의 경우 명백하게 dynamic link를 허용하고 있으며
제1항에서 static link를 허용하는 것으로 해석됩니다.

GPL의 경우 어느 경우도 허용하지 않고 있지만, linux kernel의 경우
토발즈가 GPL를 적용하면서 추가로 'user program에 의한 정상적인 시스템콜'을 허용하였기 때문에 리눅스 커널을 사용하는 (소스를 공개하지 않은) 상용프로그램이 가능한 것입니다. 하지만 디바이스 드라이버와 관련해서는 약간의 논쟁이 있습니다.

현재 저는 국내 특정 기업의 요청에 의해 GPL, LGPL, BSD, MPL, QPL을 중심으로 오픈소스 소프트웨어 라이센스를 비교 분석하고 있는데, 계약상 결과물을 오픈할 수 없지만, 개별적인 문의에 대해서는 상담 해드리겠습니다.

다시 한번 읽어보니 제가 약간 잘못 이해하고 있던 부분이 있었습니다. LGPL로 배포되는 library를 static link를 해서 배포할 때는 LGPL로 배포되는 library를 사용자가 수정해서 다시 link할 수 있는 방법을 제공해야 된다고 하는군요. 즉 배포시에 컴파일에 필요한 header파일과 object file ( prelinked form ) 을 같이 제공해야 LGPL을 위반하지 않게 되는군요.

ps: license는 너무 어려워. T_T

Taeho Oh ( ohhara@postech.edu ) http://ohhara.sarang.net
Postech ( Pohang University of Science and Technology ) http://www.postech.edu
Alticast Corp. http://www.alticast.com

mastercho의 이미지

글쓴이: mastercho / 작성시간: 수, 2003/08/13 - 5:33오후

예를 들면 LGPL에서 STL로 짠 프로그램일 경우 STL의 static link을

어떻게 링크하는 방법을 제공해야

한다는것인지요?

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

maximus의 이미지

글쓴이: maximus / 작성시간: 수, 2003/08/20 - 12:11오전

그럼 GPL에서 plug-in 형태의 개발을 어떻게 되는건가요 ?

즉, GPL 프로그램에 plug-in 형태의 인터페이스를 만들고
이부분은 공개를 하면서

실제 사용한 plug-in은 공개를 하지 않는걸 얘기 드립니다..

또한 기존에 모듈(plug-in) 형태로 제공되는 GPL 프로그램의 경우에도..
custom 모듈을 만들어도 모두 GPL에 종속되나요 ?

역시나 위에 말한 부분들을 보고 유추하면 "그렇다 공개해야 한다" 지만..
좀 개인적으로 납득이 안가는듯해서...

=================================
:: how about a cup of tea ? ::
=================================

둘러보기