GPL 에서 소스를 이용했다는 정도는 어느 만큼인가요?

zelon의 이미지

GPL 을 이용한 저작물은 GPL 이 되어야한다고 합니다. 하지만 그 범위가 애매하네요.

소스를 Ctrl+C, Ctrl+V 를 이용해서 복사한 경우는 당연히 적용될 것 같구요.

소스의 기본 구성을 이용한 것과, 알고리즘을 이용하는 것,

특정 역할을 하는 API를 찾지 못해서 어떤 API를 이용하는 지만 보고 원하는 API 를 찾아서 이용한 경우

그리고 제일 애매한게 그렇게 하지 않으면 동작하지 않는 코드, 즉 간단히 생각해서 listen socket 하는 과정등을 가져와서 쓰는 것조차도 GPL 에 위반일까요?

그렇다면 GPL 소스를 이용해서 공부하는 것도 상당히 조심해야할 것 같다는 생각이 문득 드는군요. 흐음... 여러분들은 어떻게 생각하십니까?

warpdory의 이미지

저로서는 조심할 게 별로 없군요. 그냥 copyright 문구에다가 GPL 이라고만 써주면 되거든요.

앨거리듬만을 따온 거라면 GPL 로 안 해도 되는 걸로 알고 있습니다. 물론, 구현 방식은 달라야겠지요.

프로그래머로 먹고 살지 않기 때문에 이렇게 속 편하게 생각할지도 모르겠지요. 프로그래머로 먹고 산다고 해도 GPL 로 살게 되리라고 생각하기 때문에 별로 심각하게 고민하지는 않습니다.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

puzzlet의 이미지

경제학적 논리에서 봤을 때..

(GPL측 진영에서 GPL이 침해받은 것을 인지하고 소송을 걸 확률) x (소송을 취하시키기 위해 GPL 측에 지급해야 할 합의금) < (GPL 라이선스를 침해했을 때 얻는 이익) 이라면 침해하는 것이 이익입니다.

반대로 GPL 측에서는 (어떤 프로젝트가 GPL을 침해했는지 알아내는 데 드는 비용) > (소송을 걸었을 때 얻는 이익) 이라면 클레임을 걸지 않고 싹 잊어버립니다. 파이트 클럽에서도 자동차 리콜에 대해 비슷한 대사가 나오는데, 이걸 경제용어로 합리적 무지(rational ignorance)라고 부릅니다.

웃자고 하는 소리입니다. :wink:

발발다빠따반반나다발딸발발다빠따따맣발발다뿌
멓터벅더떠벋떠벌더벌벌떠벌떠더법벍떠더벌벌떠

LispM의 이미지

GPL이 실제로 문제되는 경우는 상용제품 개발시 뿐이라고 생각하면 될 것 같습니다. 이 때문에 상용제품 개발시에는 라이센스 잘 살펴보고 추후 문제 안생기는 것들 위주로 사용하는 것이 보통입니다. 물론, 원작자에게 적절한 보상을 해주고 공식적인 허가를 받아 사용하면 아무 문제도 없습니다.

유사한 경험이 두어번 있었는데, 결국 해당 제품의 라이센스에 대한 비용이 너무 많이 들어서 다른 방법을 찾아낸 씁쓸한 기억이 있습니다.

http://lisp.or.kr http://lisp.kldp.org - 한국 리습 사용자 모임

zelon의 이미지

그렇다면, 웹에서 찾을 수 있는 많은 소스들에게도 비슷한 일을 붙일 수 있을 듯합니다.

꼭 gpl 이 아니더라도 다양한 라이센스의 소스들을 구할 수 있는게 현실일 겁니다. 그런 소스들을 보고 공부하고, 적당히 정리도 하고, 필요없는 부분을 제거해도, 사실 소스를 보면 결과적으로 하는 일은 같으므로 당사자는 찝찝합니다.

그런데 반대로 생각하면 남의 소스를 보지 않고 공부하는 것도 한계가 있는 것도 같고... 머리 복잡합니다. ㅠ.ㅜ

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

웃는 남자의 이미지

LispM wrote:
GPL이 실제로 문제되는 경우는 상용제품 개발시 뿐이라고 생각하면 될 것 같습니다. 이 때문에 상용제품 개발시에는 라이센스 잘 살펴보고 추후 문제 안생기는 것들 위주로 사용하는 것이 보통입니다. 물론, 원작자에게 적절한 보상을 해주고 공식적인 허가를 받아 사용하면 아무 문제도 없습니다.

유사한 경험이 두어번 있었는데, 결국 해당 제품의 라이센스에 대한 비용이 너무 많이 들어서 다른 방법을 찾아낸 씁쓸한 기억이 있습니다.

예를 들어 리눅스 커널처럼 다수의 개발자가 참여하는 형식의 오픈소스방식
프로젝트라면 이런 경우에는 원작자의 범주를 어디까지 봐야 할까요?

----------------------------------------
Nothing left after Nirvana.

sugarlessgirl의 이미지

Nemesis_cR wrote:
LispM wrote:
GPL이 실제로 문제되는 경우는 상용제품 개발시 뿐이라고 생각하면 될 것 같습니다. 이 때문에 상용제품 개발시에는 라이센스 잘 살펴보고 추후 문제 안생기는 것들 위주로 사용하는 것이 보통입니다. 물론, 원작자에게 적절한 보상을 해주고 공식적인 허가를 받아 사용하면 아무 문제도 없습니다.

유사한 경험이 두어번 있었는데, 결국 해당 제품의 라이센스에 대한 비용이 너무 많이 들어서 다른 방법을 찾아낸 씁쓸한 기억이 있습니다.

예를 들어 리눅스 커널처럼 다수의 개발자가 참여하는 형식의 오픈소스방식
프로젝트라면 이런 경우에는 원작자의 범주를 어디까지 봐야 할까요?

저도 이것이 굉장히 궁금했습니다.

FrogLamb의 이미지

eadgbe wrote:
Nemesis_cR wrote:
LispM wrote:
GPL이 실제로 문제되는 경우는 상용제품 개발시 뿐이라고 생각하면 될 것 같습니다. 이 때문에 상용제품 개발시에는 라이센스 잘 살펴보고 추후 문제 안생기는 것들 위주로 사용하는 것이 보통입니다. 물론, 원작자에게 적절한 보상을 해주고 공식적인 허가를 받아 사용하면 아무 문제도 없습니다.

유사한 경험이 두어번 있었는데, 결국 해당 제품의 라이센스에 대한 비용이 너무 많이 들어서 다른 방법을 찾아낸 씁쓸한 기억이 있습니다.

예를 들어 리눅스 커널처럼 다수의 개발자가 참여하는 형식의 오픈소스방식
프로젝트라면 이런 경우에는 원작자의 범주를 어디까지 봐야 할까요?

저도 이것이 굉장히 궁금했습니다.


그럴경우엔 짤없이 GPL적용해야 되는걸로 알고 있습니다.
원래 원작자에게 보상 후 자신들에게는 GPL이 아닌 다른 라이센스를 적용해달라 가 정확한 의미라고 생각하는데...리눅스 커널같은 경우 이럴 수 없는 상황이기때문에 달리 방법이 없는걸로 알고 있습니다만...확실하지 않네요:oops:
혹시 제가 잘못 알고 있는 거라면 지적해 주셨으면 합니다

----------------------------------------
Kwonjin Jeong

LispM의 이미지

Nemesis_cR wrote:
LispM wrote:
GPL이 실제로 문제되는 경우는 상용제품 개발시 뿐이라고 생각하면 될 것 같습니다. 이 때문에 상용제품 개발시에는 라이센스 잘 살펴보고 추후 문제 안생기는 것들 위주로 사용하는 것이 보통입니다. 물론, 원작자에게 적절한 보상을 해주고 공식적인 허가를 받아 사용하면 아무 문제도 없습니다.

유사한 경험이 두어번 있었는데, 결국 해당 제품의 라이센스에 대한 비용이 너무 많이 들어서 다른 방법을 찾아낸 씁쓸한 기억이 있습니다.

예를 들어 리눅스 커널처럼 다수의 개발자가 참여하는 형식의 오픈소스방식
프로젝트라면 이런 경우에는 원작자의 범주를 어디까지 봐야 할까요?

아래를 참고하세요.

Quote:

From COPYING of Linux kernel source:

NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.
...
Linus Torvalds

그래서 Linus를 필두로, 다른 사람이 쓴 코드는 각 원작자들에게서 따로 허락을 받아야 합니다. 커널소스 전체를 상대로 모든 원작자에게 연락하는 것 자체가 일반인이나 작은 회사에서는 불가능한 이야기겠죠.

제 개인적으로는 덜 엄격한 LGPL, FreeBSD, MIT 등의 라이센스가 진정한 의미의 자유를 부여해 준다고 생각합니다.

제 경험중 일부를 이야기 하자면, 특정 대학에 라이센스가 있던 소프트웨어를 이용하려고 했는데, 대학 당국에 이를 담당하는 부서가 없어서 실제로는 댓가를 지불하는 것 자체가 불가능한 적이 있었습니다. 어처구니 없는 일이죠.

만일 원작자와 연락이 도저히 안되는 GPL 소프트웨어를 댓가를 지불하고 사용하려고 한다고 가정해 보세요. 일찌감치 포기하는 것이 상책입니다.

http://lisp.or.kr http://lisp.kldp.org - 한국 리습 사용자 모임

offree의 이미지

LispM wrote:

....
....
그래서 Linus를 필두로, 다른 사람이 쓴 코드는 각 원작자들에게서 따로 허락을 받아야 합니다. 커널소스 전체를 상대로 모든 원작자에게 연락하는 것 자체가 일반인이나 작은 회사에서는 불가능한 이야기겠죠.

제 개인적으로는 덜 엄격한 LGPL, FreeBSD, MIT 등의 라이센스가 진정한 의미의 자유를 부여해 준다고 생각합니다.

제 경험중 일부를 이야기 하자면, 특정 대학에 라이센스가 있던 소프트웨어를 이용하려고 했는데, 대학 당국에 이를 담당하는 부서가 없어서 실제로는 댓가를 지불하는 것 자체가 불가능한 적이 있었습니다. 어처구니 없는 일이죠.

만일 원작자와 연락이 도저히 안되는 GPL 소프트웨어를 댓가를 지불하고 사용하려고 한다고 가정해 보세요. 일찌감치 포기하는 것이 상책입니다.

원작자의 허가를 받는 것도 일이겠네요. GPL 쪽에 그런것을 대행하는 것이 있으면 좋겠네요.
어느기간동안 연락이 안되는 경우 권리포기로 처리하는등 말이죠.
아예. 방법이 없을까요?

전 직접적으로 그런 관련이 없어서 그렇지만, 실제 관련이 있으면, 고민되긴 하겠습니다.

사용자가 바꾸어 나가자!!

= about me =
http://wiki.kldp.org/wiki.php/offree , DeVlog , google talk : offree at gmail.com

chunsj의 이미지

offree wrote:
LispM wrote:

....
....
그래서 Linus를 필두로, 다른 사람이 쓴 코드는 각 원작자들에게서 따로 허락을 받아야 합니다. 커널소스 전체를 상대로 모든 원작자에게 연락하는 것 자체가 일반인이나 작은 회사에서는 불가능한 이야기겠죠.

제 개인적으로는 덜 엄격한 LGPL, FreeBSD, MIT 등의 라이센스가 진정한 의미의 자유를 부여해 준다고 생각합니다.

제 경험중 일부를 이야기 하자면, 특정 대학에 라이센스가 있던 소프트웨어를 이용하려고 했는데, 대학 당국에 이를 담당하는 부서가 없어서 실제로는 댓가를 지불하는 것 자체가 불가능한 적이 있었습니다. 어처구니 없는 일이죠.

만일 원작자와 연락이 도저히 안되는 GPL 소프트웨어를 댓가를 지불하고 사용하려고 한다고 가정해 보세요. 일찌감치 포기하는 것이 상책입니다.

원작자의 허가를 받는 것도 일이겠네요. GPL 쪽에 그런것을 대행하는 것이 있으면 좋겠네요.
어느기간동안 연락이 안되는 경우 권리포기로 처리하는등 말이죠.
아예. 방법이 없을까요?

전 직접적으로 그런 관련이 없어서 그렇지만, 실제 관련이 있으면, 고민되긴 하겠습니다.

독점으로 소프트웨어가 돌아가지 못하도록 하는데 GPL의 진정한 의지가 있습니다. MIT, BSD라이센스는 할 수 없는 일들이죠. 그리고 독점 소프트웨어를 만들고 싶으시면 자체적으로 하세요. 괜히 GPL붙잠고 고민하지 마시고...

LispM의 이미지

chunsj wrote:
offree wrote:
LispM wrote:

....
....
그래서 Linus를 필두로, 다른 사람이 쓴 코드는 각 원작자들에게서 따로 허락을 받아야 합니다. 커널소스 전체를 상대로 모든 원작자에게 연락하는 것 자체가 일반인이나 작은 회사에서는 불가능한 이야기겠죠.

제 개인적으로는 덜 엄격한 LGPL, FreeBSD, MIT 등의 라이센스가 진정한 의미의 자유를 부여해 준다고 생각합니다.

제 경험중 일부를 이야기 하자면, 특정 대학에 라이센스가 있던 소프트웨어를 이용하려고 했는데, 대학 당국에 이를 담당하는 부서가 없어서 실제로는 댓가를 지불하는 것 자체가 불가능한 적이 있었습니다. 어처구니 없는 일이죠.

만일 원작자와 연락이 도저히 안되는 GPL 소프트웨어를 댓가를 지불하고 사용하려고 한다고 가정해 보세요. 일찌감치 포기하는 것이 상책입니다.

원작자의 허가를 받는 것도 일이겠네요. GPL 쪽에 그런것을 대행하는 것이 있으면 좋겠네요.
어느기간동안 연락이 안되는 경우 권리포기로 처리하는등 말이죠.
아예. 방법이 없을까요?

전 직접적으로 그런 관련이 없어서 그렇지만, 실제 관련이 있으면, 고민되긴 하겠습니다.

독점으로 소프트웨어가 돌아가지 못하도록 하는데 GPL의 진정한 의지가 있습니다. MIT, BSD라이센스는 할 수 없는 일들이죠. 그리고 독점 소프트웨어를 만들고 싶으시면 자체적으로 하세요. 괜히 GPL붙잠고 고민하지 마시고...

GPL도 대가를 지불하여 라이센스 받을 수 있으며, 이렇게 하면 합법적으로 라이센스 받아 제품 개발할 수 있습니다. 단지 작은 회사나 개인들은 그럴 여력이 안되기 때문에 오히려 거대 기업들을 위한 라이센스로 전락할 위험도 있습니다.

제가 가끔 오픈소스화 할 때 택하는 라이센스는 LGPL, MIT, BSD 등 GPL 이외의 라이센스 입니다. 누군가 자유로운 라이센스의 오픈 소스 소프트웨어를 기반 기술로 좋은 제품을 만들어서 판매한다면 그것을 막을 이유는 없다는 생각입니다.

http://lisp.or.kr http://lisp.kldp.org - 한국 리습 사용자 모임

FrogLamb의 이미지

LispM wrote:
...
...

GPL도 대가를 지불하여 라이센스 받을 수 있으며, 이렇게 하면 합법적으로 라이센스 받아 제품 개발할 수 있습니다. 단지 작은 회사나 개인들은 그럴 여력이 안되기 때문에 오히려 거대 기업들을 위한 라이센스로 전락할 위험도 있습니다.

제가 가끔 오픈소스화 할 때 택하는 라이센스는 LGPL, MIT, BSD 등 GPL 이외의 라이센스 입니다. 누군가 자유로운 라이센스의 오픈 소스 소프트웨어를 기반 기술로 좋은 제품을 만들어서 판매한다면 그것을 막을 이유는 없다는 생각입니다.


하지만...그런식일경우엔 오픈소스 커뮤니티에 대한 기여를 이끌어 낼 수 없습니다.
그렇게되면 결국 상용 소프트웨어 개발사들에게 성과물들을 모두 흡수 당하고 그냥 버려지게 되겠지요 :(

----------------------------------------
Kwonjin Jeong

LispM의 이미지

FrogLamb wrote:
LispM wrote:
...
...

GPL도 대가를 지불하여 라이센스 받을 수 있으며, 이렇게 하면 합법적으로 라이센스 받아 제품 개발할 수 있습니다. 단지 작은 회사나 개인들은 그럴 여력이 안되기 때문에 오히려 거대 기업들을 위한 라이센스로 전락할 위험도 있습니다.

제가 가끔 오픈소스화 할 때 택하는 라이센스는 LGPL, MIT, BSD 등 GPL 이외의 라이센스 입니다. 누군가 자유로운 라이센스의 오픈 소스 소프트웨어를 기반 기술로 좋은 제품을 만들어서 판매한다면 그것을 막을 이유는 없다는 생각입니다.


하지만...그런식일경우엔 오픈소스 커뮤니티에 대한 기여를 이끌어 낼 수 없습니다.
그렇게되면 결국 상용 소프트웨어 개발사들에게 성과물들을 모두 흡수 당하고 그냥 버려지게 되겠지요 :(

왜 그렇게 생각하시나요? 실제로 제가 상용제품을 만드는데 기반 기술로 사용했던 것들은 모두 GPL보다 자유로운 라이센스였고 모두 훌륭한 소프트웨어 들이었습니다. 그것들을 저나 제가 속했던 회사에서 사용하다가 생기는 문제들은 모두 피드백해서 더 나은 소프트웨어가 되었습니다. GPL 소프트웨어인 경우 상대적으로 상업적 환경에서 사용되지 않을 가능성이 크기 때문에 그런 면에서는 더 나은 소프트웨어가 되는데 시간이 더 걸릴 수 있습니다.

XEmacs, Mozilla 등은 상용 제품으로부터 오픈소스가 된 경우이고, PostgreSql, 그리고 제가 사용하는 (별로 관심이 없을 것 같아서 실제 이름은 생략합니다) 대부분의 라이브러리 혹은 라이브러리처럼 사용할 수 있는 소프트웨어들은 GPL보다 자유로운 라이센스입니다. FSF에서 왜 LGPL을 만들었겠습니까?

이미 언급했듯이 일반유저의 입장에서는 오픈 소스 소프트웨어의 라이센스는 큰 의미가 없습니다. 하지만, 소프트웨어를 개발하는 것을 업으로 하는 개인이나 작은 회사들은 GPL 같은 라이센스는 피해가야 합니다. 원래 GPL의 의도는 그렇지 않았다 하더라도, GPL 같은 라이센스는 그런 약자들보다는 거대 기업에게만 오히려 도움이 될 수 있는 '가능성'이 있다는 이야깁니다.

GPL보다 더 자유로운 라이센스로 오픈소스 코드를 만드는 것이 왜 오픈 소스 커뮤니티에 기여하는 바가 없다는 말인지 전혀 이해가 안가는 군요.

혹자는 GPL을 'poison pill' 이라고 부르기도 합니다. Poison pill은 주로 기업 인수합병에 종사하는 사람들이 '적대적 M&A'를 막기위해 고의로 인수자에게 불리한 의무를 떠넘기는 방법을 의미한답니다. 개발자 입장에서 독약을 먹을 준비를 하고 개발하는 것은 그리 즐거운 일은 아닐겁니다(최소한 저는 그렇습니다).

최근 우연히 해외 개발자들과 오픈 소스 프로젝트를 하나 하게되었는데, 라이센스 문제가 거론되자마자, GPL만 제외하고 BSD, MIT, LGPL 등등 모두 괜찮다고 한번에 결정 내렸습니다. 그들은 매우 좋은 개발 경험을 갖고 있고 라이센스에 대해서도 많은 경험이 있는 사람들인데, 단 2번의 이메일 교환으로 결정해 버리더군요. 제 기억이 맞다면 "진짜 자유로운 오픈 소스 라이센스"이면 좋다고 하면서 GPL을 바로 제외시켰습니다.

저 자신은 일반 유저로써는 오픈 소스이면 라이센스 신경안쓰고 사용하고, 상용제품이면 정식 라이센스 구입해서 쓰며, 개발에 이용하는 오픈 소스인 경우는 GPL이외의 것만 고려하며, 라이센스 안붙은 자바스크립트 같은 것을 사용할 때는 원작자에게 허락을 받습니다(연락 안되면 사용 안함). 우스운 것은 상용 개발툴인 경우 때때로 런타임 라이센스 없는 소프트웨어들이 있는데, 이런 것들을 최초 비용을 지불하고 구입(라이센스 받는 행위)하는 것이 GPL인 동등한 개발툴과 런타임 라이브러리를 이용하는 것보다 더 싸고 후에 뒤탈도 없을 가능성이 많을 경우가 있다는 점입니다. 또, 어디선가 다른 글타래에서 언급했지만, 어떤 오픈 소스 코드 소프트웨어들은 그다지 유용하지 못하고 유용한 형태로 쓰려면 별도의 상용 제품을 구입해야 하거나 고액의 컨설팅 비용이 필요한, 오픈 소스를 가장한 값비싼 소프트웨어가 되버리기도 합니다.

http://lisp.or.kr http://lisp.kldp.org - 한국 리습 사용자 모임

sangu의 이미지

LispM wrote:
FrogLamb wrote:
LispM wrote:
...
...

GPL도 대가를 지불하여 라이센스 받을 수 있으며, 이렇게 하면 합법적으로 라이센스 받아 제품 개발할 수 있습니다. 단지 작은 회사나 개인들은 그럴 여력이 안되기 때문에 오히려 거대 기업들을 위한 라이센스로 전락할 위험도 있습니다.

제가 가끔 오픈소스화 할 때 택하는 라이센스는 LGPL, MIT, BSD 등 GPL 이외의 라이센스 입니다. 누군가 자유로운 라이센스의 오픈 소스 소프트웨어를 기반 기술로 좋은 제품을 만들어서 판매한다면 그것을 막을 이유는 없다는 생각입니다.


하지만...그런식일경우엔 오픈소스 커뮤니티에 대한 기여를 이끌어 낼 수 없습니다.
그렇게되면 결국 상용 소프트웨어 개발사들에게 성과물들을 모두 흡수 당하고 그냥 버려지게 되겠지요 :(

왜 그렇게 생각하시나요? 실제로 제가 상용제품을 만드는데 기반 기술로 사용했던 것들은 모두 GPL보다 자유로운 라이센스였고 모두 훌륭한 소프트웨어 들이었습니다. 그것들을 저나 제가 속했던 회사에서 사용하다가 생기는 문제들은 모두 피드백해서 더 나은 소프트웨어가 되었습니다. GPL 소프트웨어인 경우 상대적으로 상업적 환경에서 사용되지 않을 가능성이 크기 때문에 그런 면에서는 더 나은 소프트웨어가 되는데 시간이 더 걸릴 수 있습니다.

XEmacs, Mozilla 등은 상용 제품으로부터 오픈소스가 된 경우이고, PostgreSql, 그리고 제가 사용하는 (별로 관심이 없을 것 같아서 실제 이름은 생략합니다) 대부분의 라이브러리 혹은 라이브러리처럼 사용할 수 있는 소프트웨어들은 GPL보다 자유로운 라이센스입니다. FSF에서 왜 LGPL을 만들었겠습니까?

이미 언급했듯이 일반유저의 입장에서는 오픈 소스 소프트웨어의 라이센스는 큰 의미가 없습니다. 하지만, 소프트웨어를 개발하는 것을 업으로 하는 개인이나 작은 회사들은 GPL 같은 라이센스는 피해가야 합니다. 원래 GPL의 의도는 그렇지 않았다 하더라도, GPL 같은 라이센스는 그런 약자들보다는 거대 기업에게만 오히려 도움이 될 수 있는 '가능성'이 있다는 이야깁니다.

GPL보다 더 자유로운 라이센스로 오픈소스 코드를 만드는 것이 왜 오픈 소스 커뮤니티에 기여하는 바가 없다는 말인지 전혀 이해가 안가는 군요.

혹자는 GPL을 'poison pill' 이라고 부르기도 합니다. Poison pill은 주로 기업 인수합병에 종사하는 사람들이 '적대적 M&A'를 막기위해 고의로 인수자에게 불리한 의무를 떠넘기는 방법을 의미한답니다. 개발자 입장에서 독약을 먹을 준비를 하고 개발하는 것은 그리 즐거운 일은 아닐겁니다(최소한 저는 그렇습니다).

최근 우연히 해외 개발자들과 오픈 소스 프로젝트를 하나 하게되었는데, 라이센스 문제가 거론되자마자, GPL만 제외하고 BSD, MIT, LGPL 등등 모두 괜찮다고 한번에 결정 내렸습니다. 그들은 매우 좋은 개발 경험을 갖고 있고 라이센스에 대해서도 많은 경험이 있는 사람들인데, 단 2번의 이메일 교환으로 결정해 버리더군요. 제 기억이 맞다면 "진짜 자유로운 오픈 소스 라이센스"이면 좋다고 하면서 GPL을 바로 제외시켰습니다.

저 자신은 일반 유저로써는 오픈 소스이면 라이센스 신경안쓰고 사용하고, 상용제품이면 정식 라이센스 구입해서 쓰며, 개발에 이용하는 오픈 소스인 경우는 GPL이외의 것만 고려하며, 라이센스 안붙은 자바스크립트 같은 것을 사용할 때는 원작자에게 허락을 받습니다(연락 안되면 사용 안함). 우스운 것은 상용 개발툴인 경우 때때로 런타임 라이센스 없는 소프트웨어들이 있는데, 이런 것들을 최초 비용을 지불하고 구입(라이센스 받는 행위)하는 것이 GPL인 동등한 개발툴과 런타임 라이브러리를 이용하는 것보다 더 싸고 후에 뒤탈도 없을 가능성이 많을 경우가 있다는 것입니다. 또, 어디선가 다른 글타래에서 언급했지만, 어떤 오픈 소스 코드 소프트웨어들은 그다지 유용하지 못하고 유용한 형태로 쓰려면 별도의 상용 제품을 구입해야 하는 경우도 있는, 오픈 소스를 가장한 값비싼 소프트웨어가 되버리기도 합니다.

여기서 GPL이 문제가 되는 것이 소스 공개 문제 인것 같은 되요. 소스를 공개할 수 없는 사정이라면 GPL 라이선스를 가진 소프트웨어 대신에 다른 오프 소스 라이선스를 가진 소프트웨어GPL과 동등한 개발툴과 런타임 라이브러리를 이용하는 것보다 더 싸고 후에 뒤탈도 없을 가능성이 많을 경우의 소프트웨어를 이용하시면 되는 거죠.

LispM의 이미지

sangu wrote:
LispM wrote:
FrogLamb wrote:

...
하지만...그런식일경우엔 오픈소스 커뮤니티에 대한 기여를 이끌어 낼 수 없습니다.
그렇게되면 결국 상용 소프트웨어 개발사들에게 성과물들을 모두 흡수 당하고 그냥 버려지게 되겠지요 :(

왜 그렇게 생각하시나요? 실제로 제가 상용제품을 만드는데 기반 기술로 사용했던 것들은 모두 GPL보다 자유로운 라이센스였고 모두 훌륭한 소프트웨어 들이었습니다. 그것들을 저나 제가 속했던 회사에서 사용하다가 생기는 문제들은 모두 피드백해서 더 나은 소프트웨어가 되었습니다. GPL 소프트웨어인 경우 상대적으로 상업적 환경에서 사용되지 않을 가능성이 크기 때문에 그런 면에서는 더 나은 소프트웨어가 되는데 시간이 더 걸릴 수 있습니다.
...

GPL보다 더 자유로운 라이센스로 오픈소스 코드를 만드는 것이 왜 오픈 소스 커뮤니티에 기여하는 바가 없다는 말인지 전혀 이해가 안가는 군요.
...

여기서 GPL이 문제가 되는 것이 소스 공개 문제 인것 같은 되요. 소스를 공개할 수 없는 사정이라면 GPL 라이선스를 가진 소프트웨어 대신에 다른 오프 소스 라이선스를 가진 소프트웨어GPL과 동등한 개발툴과 런타임 라이브러리를 이용하는 것보다 더 싸고 후에 뒤탈도 없을 가능성이 많을 경우의 소프트웨어를 이용하시면 되는 거죠.

당연한 이야기이긴 한데, 왜 그 이야기가 나오는 지는 모르겠습니다. 제가 너무 길게 써서 방향이 틀어진 것 같아 요점정리(?) 합니다.

위에서 'GPL이외의 오픈소스는 오픈소스 커뮤니티에 기여할 수 없다'고 해서 그렇지 않다는 것을 길게(혹은 너저분하게 혹은 알기쉽게) 보였고, 다른 한편으로는 (의도적으로, 무의식중에) 오픈소스코드 개발시 GPL이외의 라이센스를 사용할 것을 권했던 것입니다. 제가 약간 수정하려던 국산 오픈소스코드들은 GPL이라 손을 안댄 적이 있는데, 사실 이렇게 되면 모두가 손해보는 일이라고 생각합니다.

http://lisp.or.kr http://lisp.kldp.org - 한국 리습 사용자 모임

sangu의 이미지

LispM wrote:

당연한 이야기이긴 한데, 왜 그 이야기가 나오는 지는 모르겠습니다. 제가 너무 길게 써서 방향이 틀어진 것 같아 요점정리(?) 합니다.

위에서 'GPL이외의 오픈소스는 오픈소스 커뮤니티에 기여할 수 없다'고 해서 그렇지 않다는 것을 길게(혹은 너저분하게 혹은 알기쉽게) 보였고, 다른 한편으로는 (의도적으로, 무의식중에) 오픈소스코드 개발시 GPL이외의 라이센스를 사용할 것을 권했던 것입니다. 제가 약간 수정하려던 국산 오픈소스코드들은 GPL이라 손을 안댄 적이 있는데, 사실 이렇게 되면 모두가 손해보는 일이라고 생각합니다.

또 어떤 분은 GPL/LGPL이라서 소스를 수정하시는 분이 있겠죠. 사람마다 선호 하는 라이선스가 있고 그걸 가지고 좋다 나쁘다는 것이 아니라 처음 글타래을 여신 분이 GPL 저작물을 이용할때 조심할 점에 대해서 문의 한 것이고 중간에 여러가지 이야기 있어지만 대체로 만약 공개가 어렵다면 다른 오픈소스 라이선스를 가진 소프트웨어를 이용하면 된다는 것이죠.

LispM님이 GPL의 여러가지 문제점을 이야기 하셨길래 그러한 점이 있다면 그런 문제점이 없는 오픈 소스 라이선스를 가진 소프트웨어를 선택하거나 그러한 오픈소스 라이선스 하에서 소프트웨어를 공개하면 된다는 거죠.

emptysky의 이미지

sangu wrote:
LispM wrote:

당연한 이야기이긴 한데, 왜 그 이야기가 나오는 지는 모르겠습니다. 제가 너무 길게 써서 방향이 틀어진 것 같아 요점정리(?) 합니다.

위에서 'GPL이외의 오픈소스는 오픈소스 커뮤니티에 기여할 수 없다'고 해서 그렇지 않다는 것을 길게(혹은 너저분하게 혹은 알기쉽게) 보였고, 다른 한편으로는 (의도적으로, 무의식중에) 오픈소스코드 개발시 GPL이외의 라이센스를 사용할 것을 권했던 것입니다. 제가 약간 수정하려던 국산 오픈소스코드들은 GPL이라 손을 안댄 적이 있는데, 사실 이렇게 되면 모두가 손해보는 일이라고 생각합니다.

또 어떤 분은 GPL/LGPL이라서 소스를 수정하시는 분이 있겠죠. 사람마다 선호 하는 라이선스가 있고 그걸 가지고 좋다 나쁘다는 것이 아니라 처음 글타래을 여신 분이 GPL 저작물을 이용할때 조심할 점에 대해서 문의 한 것이고 중간에 여러가지 이야기 있어지만 대체로 만약 공개가 어렵다면 다른 오픈소스 라이선스를 가진 소프트웨어를 이용하면 된다는 것이죠.

LispM님이 GPL의 여러가지 문제점을 이야기 하셨길래 그러한 점이 있다면 그런 문제점이 없는 오픈 소스 라이선스를 가진 소프트웨어를 선택하거나 그러한 오픈소스 라이선스 하에서 소프트웨어를 공개하면 된다는 거죠.


실제 제가아는 어떤 회사에서는 리눅스 커널을 그대로 가져다 사용하고 있습니다.
다만 GPL 라이센스 문제때문에 변수들을 모두 바꿔 사용한다고 하더군요 :twisted:

『 아픔은.. 아픔을 달래줄 약이 무엇인지 알면서도 쓰지 못할 때 비로소 그 아픔의 깊이를 알수가 있음이다. 』
『 for return...』

wkpark의 이미지

emptysky wrote:

실제 제가아는 어떤 회사에서는 리눅스 커널을 그대로 가져다 사용하고 있습니다.
다만 GPL 라이센스 문제때문에 변수들을 모두 바꿔 사용한다고 하더군요 :twisted:

상용으로 팔지 않는다면 문제 없겠지만, 판매한다면 불법이겠군요 :?
이런 방식으로 많은 회사들이 GPL코드를 불법적으로 사용하고
약간의 정신적인 압박(?)을 받겠군요 @.@
BSD라이센스라면 홀가분한 기분으로 사용할텐데.. :)

그리고, BSD라이센스를 쓰더라도 "나 이러이러한 BSD라이센스의 소프트웨어를 가져다가 상용으로 만들었다"라고 공표하는 행동도 같이 해야 하겠죠.

온갖 참된 삶은 만남이다 --Martin Buber

offree의 이미지

wkpark wrote:

...
...

그리고, BSD라이센스를 쓰더라도 "나 이러이러한 BSD라이센스의 소프트웨어를 가져다가 상용으로 만들었다"라고 공표하는 행동도 같이 해야 하겠죠.

BSD 라이센스는 확인하지 않았는데, "BSD소프트웨어를 썼다"는 것은 공표해야 하나 봐요?

사용자가 바꾸어 나가자!!

= about me =
http://wiki.kldp.org/wiki.php/offree , DeVlog , google talk : offree at gmail.com

FrogLamb의 이미지

GPL이외의 라이센스의 오픈소스 프로젝트가 오픈소스에 도움이 되지 않는다는 말은 아니었습니다.
하지만 GPL보다 더 자유로운 라이센스를 사용한 소프트웨어를 수정하여 개선하여 팔았다고 해도 원래의 프로그램에 feedback해야 할 의무는 없어집니다

예를들어 리눅스 배포판 제조회사에서 GNU소프트웨어나 리눅스 커널의 결함을 발견하여 패치를 했는데 이를 공개하지 않는다면 어떨까요?

----------------------------------------
Kwonjin Jeong

emptysky의 이미지

wkpark wrote:
emptysky wrote:

실제 제가아는 어떤 회사에서는 리눅스 커널을 그대로 가져다 사용하고 있습니다.
다만 GPL 라이센스 문제때문에 변수들을 모두 바꿔 사용한다고 하더군요 :twisted:

상용으로 팔지 않는다면 문제 없겠지만, 판매한다면 불법이겠군요 :?
이런 방식으로 많은 회사들이 GPL코드를 불법적으로 사용하고
약간의 정신적인 압박(?)을 받겠군요 @.@
BSD라이센스라면 홀가분한 기분으로 사용할텐데.. :)

그리고, BSD라이센스를 쓰더라도 "나 이러이러한 BSD라이센스의 소프트웨어를 가져다가 상용으로 만들었다"라고 공표하는 행동도 같이 해야 하겠죠.


회사인데 당연히 상용으로 판매하겠지요 :twisted:
사실 이런 류의 변수와 코드를 수정하여 꺼리낌없이 사용하는 회사들 부지기수인걸로 알고 있습니다. ㅋㅋ

『 아픔은.. 아픔을 달래줄 약이 무엇인지 알면서도 쓰지 못할 때 비로소 그 아픔의 깊이를 알수가 있음이다. 』
『 for return...』

wkpark의 이미지

offree wrote:
wkpark wrote:

...
...

그리고, BSD라이센스를 쓰더라도 "나 이러이러한 BSD라이센스의 소프트웨어를 가져다가 상용으로 만들었다"라고 공표하는 행동도 같이 해야 하겠죠.

BSD 라이센스는 확인하지 않았는데, "BSD소프트웨어를 썼다"는 것은 공표해야 하나 봐요?

http://www.opensource.org/licenses/bsd-license.php

맨 위의 항목입니다.

Quote:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

BSD라이센스 걸린 수많은 소스를 이윤을 추구하는 회사에서 분명히 사용하는 것으로 알고 있는데 이를 제대로 알리려고 하고 지키는 회사는 드문것 같더군요.

BSD라이센스도 분명히 오픈소스 라이센스인데, 그걸 어느 어느 회사에서 썼더라고 하면 오픈소스 커뮤니티의 신뢰도 향상에 줄 수 있을 것으로 생각되는데요.

온갖 참된 삶은 만남이다 --Martin Buber

LispM의 이미지

FrogLamb wrote:
GPL이외의 라이센스의 오픈소스 프로젝트가 오픈소스에 도움이 되지 않는다는 말은 아니었습니다.
하지만 GPL보다 더 자유로운 라이센스를 사용한 소프트웨어를 수정하여 개선하여 팔았다고 해도 원래의 프로그램에 feedback해야 할 의무는 없어집니다

예를들어 리눅스 배포판 제조회사에서 GNU소프트웨어나 리눅스 커널의 결함을 발견하여 패치를 했는데 이를 공개하지 않는다면 어떨까요?

아무래도 처음부터 제가 말한 "오픈소스"를 이용한 "상용제품"에 대해 자세히 이야기 안한것이 잘못인것 같습니다.

제이야기는 특수한 이야기가 아니라 일반적인 이야기입니다(위에서 변수바꿔써서 저작권 피한다는 말도 안되는 이야기는 빼고 - 100% 저작권 위반이죠). 대개의 경우 오픈소스 소프트웨어로 제품을 만든다고 하면 계층화된(layered) 제품입니다. 기존의 오픈소스 소프트웨어를 밑에 두고 새로운 층을 만들어서 자신이 원하는 제품을 만드는 것이죠. 때문에 예로 든 것과 같은 일은 벌어지지 않습니다.

이때 라이센스 문제가 생길수 있는 곳이 새로운 층 부분입니다. GPL의 경우 소스코드 공개해야 하죠. 제대로 된 회사라고 한다면 자신들의 새로운 층 이외의 오픈소스부분은 스스로 유지보수 하려고 하지 않을 것입니다(비용이 많이 들기 때문에). 그렇지만, 자신들의 제품이 제대로 동작하게 하기 위해서 문제점을 고치거나 보고하기는 합니다(아래단의 오픈소스코드가 계속 발전시키기 위해). 특히 작은 회사라면 제한된 자원을 분산시키 말아야 하므로 바보가 아닌 이상 이런 방법을 씁니다. 회사 특히 작은 회사가 성장하고 투자 받으려면 '지적재산'을 내세우는 방법밖에 없는데, 이런 경우 소스코드 공개는 (최소한 성장이 멈출 때 까지는) 있을 수 없는 일입니다.

예를 들면, 제가 모니위키를 아랫단으로 새로운 층을 쌓아 제품을 만들어 내려고 한다고 가정합시다. 제가 지적재산으로 주장할 부분은 새로운 층 부분입니다. 하지만 이런 작업중 아랫단의 모니위키의 버그를 발견하거나 좋은 아이디어가 생긴다고 한다면 모니위키를 고치고 원작자에게 보고하겠죠(스스로 유지보수 하는 부분은 새로운 층만 해도 충분히 벅차기 때문에). 모니위키가 우연히도 GPL이라고 가정합시다(진짜 그런지는 확인 안했음). GPL은 소스코드를 공개하야 하므로, 새로운 층부분의 소스 역시 공개해야 합니다.

이와같은 예가 제가 아는 오픈 소스코드가 상업적으로 사용되는 일반적인 경우입니다. 물론 다른 예도 있겠지만 대부분은 이와 유사하게 사용되리라고 생각합니다.

http://lisp.or.kr http://lisp.kldp.org - 한국 리습 사용자 모임

ydhoney의 이미지

솔직히 순수 GPL은 부담스럽습니다.

취미로 개발하는거라면 모를까 수익사업을 GPL로 해버리면.

완전 장사 말아먹지요. -_-;

FrogLamb의 이미지

LispM wrote:
아무래도 처음부터 제가 말한 "오픈소스"를 이용한 "상용제품"에 대해 자세히 이야기 안한것이 잘못인것 같습니다.

제이야기는 특수한 이야기가 아니라 일반적인 이야기입니다(위에서 변수바꿔써서 저작권 피한다는 말도 안되는 이야기는 빼고 - 100% 저작권 위반이죠). 대개의 경우 오픈소스 소프트웨어로 제품을 만든다고 하면 계층화된(layered) 제품입니다. 기존의 오픈소스 소프트웨어를 밑에 두고 새로운 층을 만들어서 자신이 원하는 제품을 만드는 것이죠. 때문에 예로 든 것과 같은 일은 벌어지지 않습니다.

이때 라이센스 문제가 생길수 있는 곳이 새로운 층 부분입니다. GPL의 경우 소스코드 공개해야 하죠. 제대로 된 회사라고 한다면 자신들의 새로운 층 이외의 오픈소스부분은 스스로 유지보수 하려고 하지 않을 것입니다(비용이 많이 들기 때문에). 그렇지만, 자신들의 제품이 제대로 동작하게 하기 위해서 문제점을 고치거나 보고하기는 합니다(아래단의 오픈소스코드가 계속 발전시키기 위해). 특히 작은 회사라면 제한된 자원을 분산시키 말아야 하므로 바보가 아닌 이상 이런 방법을 씁니다. 회사 특히 작은 회사가 성장하고 투자 받으려면 '지적재산'을 내세우는 방법밖에 없는데, 이런 경우 소스코드 공개는 (최소한 성장이 멈출 때 까지는) 있을 수 없는 일입니다.

예를 들면, 제가 모니위키를 아랫단으로 새로운 층을 쌓아 제품을 만들어 내려고 한다고 가정합시다. 제가 지적재산으로 주장할 부분은 새로운 층 부분입니다. 하지만 이런 작업중 아랫단의 모니위키의 버그를 발견하거나 좋은 아이디어가 생긴다고 한다면 모니위키를 고치고 원작자에게 보고하겠죠(스스로 유지보수 하는 부분은 새로운 층만 해도 충분히 벅차기 때문에). 모니위키가 우연히도 GPL이라고 가정합시다(진짜 그런지는 확인 안했음). GPL은 소스코드를 공개하야 하므로, 새로운 층부분의 소스 역시 공개해야 합니다.

이와같은 예가 제가 아는 오픈 소스코드가 상업적으로 사용되는 일반적인 경우입니다. 물론 다른 예도 있겠지만 대부분은 이와 유사하게 사용되리라고 생각합니다.


아아...그런식으로 생각해 볼 수도 있겠군요...사실 제가 상용 소프트웨어를 제작해서 판매하는 입장이 아니라 그런쪽에 대해서는 깊이 생각해 보질 못했네요 :oops:
확실히 GPL은 라이센스가 만들어 질 때 고려한 유지보수 서비스 제공에 의한 수익 창출 방법 이외에는 달리 다른 수익 창출이 힘든것 같습니다. 게다가 그 수익 방법이라는게 거대 회사들이 아니면 생각하기 힘든것들이고요

그런 의미에서 질문이 있는데, GPL을 따르는 소프트웨어 또는 그 소스코드를 이용해서 짠 프로그램은 다시 GPL을 따르도록 되어있는데 이 경우에 GPL과 BSD라이센스같은 다른 라이센스를 선택적으로 적용시키게 만들면 새로 짠 프로그램의 경우 GPL의 제약을 받지 않을 수 있는건가요?

----------------------------------------
Kwonjin Jeong

Necromancer의 이미지

아래아한글의 hwp 압축방식이 gzip입니다. 다만 FSF에서 허가받아 쓴 것이라는.
요즘거는 몰라도 예전 2.5 썼을적에 매뉴얼에 그렇게 나와 있더군요.
소스 달라고 연락하면 우송료만 받고 준다고.

그래서 hwp 압축 잘 안되죠. 적어도 97 이전꺼는 압축률 1%입니다.
(미리보기 이미지 뺄경우)

Written By the Black Knight of Destruction

闖의 이미지

제가 만들고 있는 PDA 게임이 있는데요.

LGPL하의 게임을 참고했습니다.

참고한 소스도 없고 어떤 관련성도 없지만 일부그림을 그대로 가져다 썼는데요.

만약 이렇게 만든것을 상용으로 판다면 문제가 있을까요?

문제가 있다면 어떻게 해결해야 할까요?