BSD라이센스는 2차 저작물을 소스나 바이너리 형식으로
배포할 때 BSD License임을 표시하는 문구를 항상 표시하도록
되어야 합니다. 만일 아무렇게나 변경할 수 있다면 그건
오픈소스 라이센스라고 하기 힘들겠죠.. PS2나 PSP에 NetBSD의
라이센스가 표시되어 있는 것도 같은 이유로 보시면 되겠습니다.
우리나라 회사들 중에는 아직까지 GPL에 큰 신경을 쓰는 경우가
별로 없는 거 같습니다. 심지어 GPL 부분을 지우고 떡하니
ㅎㅈㅎ 자기들 라이센스를 껴놓은 경우도 봤구오. (상당히 큰
회사였습니다만)
개인적인 생각을 말씀드리자면, GPL이 잘 지켜지지 않는 이유는
라이센스 자체가 회사에서 사용하기에 (기술적이거나 윤리적인
문제가 아니라, 기존의 회사의 정책이라든지 경영진의 편집증
탓이 크겠지요) 약간 부적합한 면이 있기 때문이 아닐까 하는
생각은 가끔 합니다. 물론 그것이 GPL위반에 대한 변명이 될
수는 없죠. 하지만, 왜 PSP에 임베디드 리눅스 코드가 아닌
NetBSD의 코드가 사용되었는지는 생각해 볼 만한 가치가
있다고 봅니다. :)
GPL의 위반사례를 목격하셨고, 충분한 증거가 있으신 경우에는
이슈화를 시켜서 여러 사람들에게 알게 하고, 그로 인한 압력을
가하는 방법이 거의 유일하지 않을까 생각합니다. (지난번의
프루나/동키호테 건 처럼..) 아니면 FSF에 신고를 하는 방법도
있겠구요.
우리나라 현실에서 GPL, 넓게 봐서 오픈 소스와 관련된 심각한 문제 중의 하나는 이렇습니다. 우리나라에서는 오픈 소스로 소스를 공개했을때 derivative work가 외국에 비해 상대적으로 발전이 없습니다. 이렇게 되면 소스 코드 공개의 순이익이 줄어들 수 밖에 없습니다.
그러다보니 특히 기업의 입장에서는 자신이 GPL 코드를 가져다 썼더라도 소스 코드 공개로 인한 이익이 없으니 그냥 배째라 식으로 소스 코드 공개를 안하게 되는 것이고 원저자가 대부분 외국인인 점을 감안하면 소스 코드를 공개하지 않더라도 소송을 당할 위험은 상대적으로 낮을 수 밖에 없습니다.
이러다보니 제 3자들이 나서서 GPL소스인데 왜 공개안하냐고 험한 분위기를 조성할 수 밖에 없고 압박(?)에 못이겨 소스 코드를 공개하더라도 이 사람 입장에서는 소스코드 공개해봐야 얻을 이익은 여전히 없습니다.
상황이 이러니 앞으로도 국내에서 GPL 코드 도용 사례는 더 늘어날 전망입니다.
그리고 외국에서도 인터넷 공유기와 같은 제품들은 소스 코드를 공개하더라도 여기에 기반한 derivative work 발전 가능성이 낮다 보니 GPL 코드 도용 사례가 많은 편입니다. 그래도 이쪽은 상황이 많이 나은편입니다. Linksys WRT54G 제품의 경우 처음에는 GPL 코드 사용을 숨겼다가 이것이 이슈화되자 결국 여론의 압박에 못이겨 소스코드를 공개하게 되었는데요... 요즘은 Linksys가 소스코드 공개의 덕을 보고 있습니다. 사용자들 사이에서 개조 firmware들이 나오기 시작했고 무선 라우터 개조를 원하는 사람들은 이제 WRT54G를 많이 구입하게 되었습니다. 이런 incentive가 한국의 현실에서는 여전히 어렵다는 점이 GPL의 현실에 관련히 아쉬운 부분이 되겠지요.
현재로서 GPL도용 케이스를 당했을때 원저자가 대처할 수 있는 가장 효과적인 방법은 언론사를 접촉하는 방법이라고 봅니다. 한국 전역의 온라인 오프라인 매체들이 기사를 뿌려대기 시작하면 도용한 사람도 별 대책이 없을 겁니다. 원저작자의 credit 도용은 누가봐도 분노(?)할 수 있는 주제이고 헤드라인을 조금만 손질하면 금방 오늘의 best click 기사로 올라가겠지요.
"I conduct to live,
I live to compose."
--- Gustav Mahler
파일비 라고 국내에서 만든 emule클라이언트가 있습니다. 그런데 예전의 푸르나처럼 소스공개를 미루고 있네요. 게시판에 소스공개,라이센스표기의 요청을 했더니
Quote:
저희가 개발한 파일비는 GPL에 해당하는 부분과 해당되지 않는 부분이 있습니다.
GPL에 해당하지 않는 부분은 저희가 몇달에 걸쳐 독자적으로 개발한 결과물입니다.
그러므로 GPL에 해당하지 않는 부분은 제거해야 하는데 그 작업에 많은 시간이 걸립니다.
유저님의 인적사항을 자세히 적어 올려주시면 그쪽으로 메일을 보내드리겠습니다.
단, 시간이 많이 걸리므로 좀 기달리셔합니다.
이런 답변이 올라왔네요.
Quote:
GPL에 해당하지 않는 부분은 제거해야 하는데 그 작업에 많은 시간이 걸립니다.
이말도 믿을수 없지만
Quote:
유저님의 인적사항을 자세히 적어 올려주시면 그쪽으로 메일을 보내드리겠습니다.
이건 또 무슨 속셈인지 모르겠네요. :evil:
자꾸 이런일은 늘어갈테고 언젠가 정말 뉴스에 이슈가 될지도 모르겠네요.
저희가 개발한 파일비는 GPL에 해당하는 부분과 해당되지 않는 부분이 있습니다.
GPL에 해당하지 않는 부분은 저희가 몇달에 걸쳐 독자적으로 개발한 결과물입니다.
그러므로 GPL에 해당하지 않는 부분은 제거해야 하는데 그 작업에 많은 시간이 걸립니다.
유저님의 인적사항을 자세히 적어 올려주시면 그쪽으로 메일을 보내드리겠습니다.
단, 시간이 많이 걸리므로 좀 기달리셔합니다.
파일비 라고 국내에서 만든 emule클라이언트가 있습니다. 그런데 예전의 푸르나처럼 소스공개를 미루고 있네요. 게시판에 소스공개,라이센스표기의 요청을 했더니
Quote:
저희가 개발한 파일비는 GPL에 해당하는 부분과 해당되지 않는 부분이 있습니다.
GPL에 해당하지 않는 부분은 저희가 몇달에 걸쳐 독자적으로 개발한 결과물입니다.
그러므로 GPL에 해당하지 않는 부분은 제거해야 하는데 그 작업에 많은 시간이 걸립니다.
유저님의 인적사항을 자세히 적어 올려주시면 그쪽으로 메일을 보내드리겠습니다.
단, 시간이 많이 걸리므로 좀 기달리셔합니다.
이런 답변이 올라왔네요.
Quote:
GPL에 해당하지 않는 부분은 제거해야 하는데 그 작업에 많은 시간이 걸립니다.
이말도 믿을수 없지만
Quote:
유저님의 인적사항을 자세히 적어 올려주시면 그쪽으로 메일을 보내드리겠습니다.
이건 또 무슨 속셈인지 모르겠네요. :evil:
자꾸 이런일은 늘어갈테고 언젠가 정말 뉴스에 이슈가 될지도 모르겠네요.
파일비 홈페이지에 글을 남겼더니 다음과 같은 글이 붙었네요.
Quote:
저희도 GPL 라이센스에 대해 익히 알고있으며 그 원칙은 준수할 것입니 다. 다만, 지금까지 개발에만 전념하다보니 그부분을 간과한면이 있었 으나, 7월중으로 캐쉬서비스 부분을 제외한 소스부분은 공개할 예정입 니다.
라이센스를 지키기 위해서 소스코드를 공개한다니 다행이지만, 이미 위반한 사항에 대해서 "소스코드를 나중에라도 공개하겠다, 그러니까 괜찮은 거 아니냐"라고 생각하는 거 같네요. 이미 위반한 점에 대해서 어떻게 반응할지 궁금합니다.
gpl의 의무는 개작/수정한 소프트웨어를 배포하는 시점부터 발생합니다. 따라서 위에 이야기되고 있는 파일비라는 곳에서 소프트웨어를 배포하는 시점부터 사용자가 소스코드를 원할 경우 제공해 줄 수 있어야 합니다. (해당 소프트웨어가 gpl의 적용을 받는다는 것이 명확할 경우)
emule관련해서 계속적으로 이런 일이 생긴다는 것이 매우 안타깝군요. /.같은 곳에 회자된다면 그렇지 않아도 스팸메일 등으로 그다지 좋지 않은 한국의 이미지에 먹칠하기 딱 좋은 아이템입니다.
오픈소스 라이센스, 특히 gpl에 대해서 정말 제대로 된 가이드라인이 필요한 시점인 것 같습니다.
국가 기관에서 사용 중에 해당 보안 프로그램으로 인해서
문제가 발생되었을 때에(불명확한 패턴으로 탐지/대응이 안되었다와 같이)
책임을 추궁할 주체가 없다는게 문제죠.
실제로 snort같은 경우도 주옥같은 패턴들도 많지만,
일단은 다 잡고 보자 식이던가(이런 경우를 case by case로 모두 관리자가
등록하는 건 현실적으로 어렵죠. 그래서 snort를 그대로 가져다가 껍데기만
바꿔서 파는 회사들도 있겠죠....라이센스 위반이겠지만..)
혹은 불충분한 패턴인 경우도 많더군요.
그래서 발생했을 경우에 정부기관에서 사용 하기에 적합하다는
인증을 준 국정원 입장에서는 곤란하다는 거죠.
머 저도 이런 부분 때문에 엄청 짜증난 적도 있었지만,
차근차근 생각해보면 이해가 가기도 하더군요. ^^
오픈소스 코드는 문제발생시 누가 책임을 지겠습니까? 버그보고라는 것이 왜 있겠습니까? 원한다면 소스조차 바꿀 수 있습니다. (오픈소스 코드 버그리포트와 그렇지 않은 코드의 버그 리포트 비교해 보면 무슨 뜻인지 아실 겁니다. 아는 이의 경험을 빌리자면, 애플에 아무리 버그 리포트 보내봤자 무엇을 어떻게 하고 있는지 알수도 알려주지도 않고 해결할 길이 전혀 없지만 오프소스 코드인 경우 투명하게 모든 진행 상황을 알수 있으며 혹시라도 기분 나쁘게 묵살 당하면 스스로 패치해서 사용할 수 있습니다)
어떤 OS든지 설치시 "라이센스에 동의합니다" 버튼 누르기 전에 읽어보면 대부분 '소프트웨어 사용중 발생한 문제에 대해서는 책임지지 않는다'라는 부분이 나옵니다. 기반이 되는 OS가 문제 발생시 책임을 지지 않는데 보안 프로그램이 무슨 책임을 어떻게 지는지 궁금합니다(진심으로 궁금합니다) 제 생각에 컴퓨터 혹은 네트워크 보안이라는 것은 시스템을 이루는 각 계층이 모두 어느 정도의 안전성이 보장되어야 합니다. 예를들어 NIDS 프로그램이 아무리 좋더라도 그 아래단에서 타협해 버렸다면 무용지물이 되어버리는 겁니다. 보안에 있어서 100% 안전한 것은 있을 수 없고, 특정 소프트웨어 몇가지가 모든 것을 해결해주리라는 생각 자체가 잘못입니다. "보안은 프로세스이다"라고 한 보안 전문가 이야기가 생각나는 군요.
Quote:
국가 기관에서 사용 중에 해당 보안 프로그램으로 인해서
문제가 발생되었을 때에(불명확한 패턴으로 탐지/대응이 안되었다와 같이)
책임을 추궁할 주체가 없다는게 문제죠.
실제로 snort같은 경우도 주옥같은 패턴들도 많지만,
일단은 다 잡고 보자 식이던가(이런 경우를 case by case로 모두 관리자가
등록하는 건 현실적으로 어렵죠. 그래서 snort를 그대로 가져다가 껍데기만
바꿔서 파는 회사들도 있겠죠....라이센스 위반이겠지만..)
혹은 불충분한 패턴인 경우도 많더군요.
그래서 발생했을 경우에 정부기관에서 사용 하기에 적합하다는
인증을 준 국정원 입장에서는 곤란하다는 거죠.
어떤식으로 책임을 추궁하는지 정말 궁금하군요. 모든 소프트웨어는 버그 혹은 요구사항이 변하게 되어있습니다. 그런데 요구사항 변경(이를테면 최초 현존하는 공격패턴의 90% 탐지였는데, 1년후 새로운 공격패턴이 100% 증가했다)된 경우 어떤 식으로 추궁할 수 있을지 의문입니다. (아마 추가된 GPL 라이센스인 룰셋을 카피해서 전달하겠죠)
패턴에 대한 것은 주로 룰셋에 대한 것으로 아는데, 누구나 룰셋을 정의할 수 있습니다. 결국 그런 식으로 사업하는 곳들은 룰셋 장사인데, GPL이라면 그런 룰셋을 공개해서 다른 곳에서도 사용할 수 있어야 합니다. 그정도를 위에서 '문제해결'이라고 한다면 GPL 소프트웨어 사용 보안서비스 제공자 측에서 새로운 패턴 발견시 룰셋 추가하거나 재정의 하면 됩니다(물론 그 룰셋은 원래 GPL 소프트웨어 제작자 측에게 보내져서 다른 이들도 혜택을 보아야 하며, 이것이 대부분 원작자들의 의도입니다. 즉, 십시일반으로 모두가 공헌할 수 있고 모두가 사용할 수 있게 한다.)
Quote:
머 저도 이런 부분 때문에 엄청 짜증난 적도 있었지만,
차근차근 생각해보면 이해가 가기도 하더군요. ^^
잘 생각해 봐도 이해가 안가는데, 아마도 일이 잘못되었을 때 얼마나 어떻게 책임져 주는지를 잘 몰라서 인것 같습니다.
이런 시나리오는 어떤가요? 대부분 보안회사가 라이센스 위반으로 기소되어 제품에 대해 정상적인 판매 및 유지보수가 불가능해진다. 이미 기존에 제품을 사용하고 있는 고객들에 대해 이 문제는 어떻게 해결해 줄 것인가? 방화벽도 내려야 하고 IDS도 더이상 사용할 수 없다? 또 GPL에 의해 코드 공개해야 하는데, 그렇게 되면 조만간 원본 GPL 소프트웨어에 반영된다고 가정해 보면 국정원의 인증은 무엇을 인증한 것인지?
이런 점에서 오히려 원본 GPL 보안 소프트웨어가 인증을 받는 길이 있어야 합니다. 원본 소프트웨어는 대부분 프로세스 자체가 투명하고 엔진부분의 문제역시 신속히 해결되며, 룰셋도 전세계적으로 사용되고 있기 때문에 신뢰성이 더 있습니다. Counterpane의 설립자이자 보안 전문가인 Bruce Shneier(spell?)는 보안에 사용되는 암호화 알고리듬은 모두 공개되어서 안전성이 전세계 많은 암호전문가에게 수년동안 검증받은 것이 안전하고, 보안에 사용되는 툴 역시 오픈소스로 공개되고 오랜기간 검증받은 것이 안전하다고 하였습니다. 이 이야기야 말로 상식적으로 이해할 수 있고 동의할 수 있다고 봅니다.
GPL 위반했다고 판매중지 같은거 일어날 일은 없습니다. 금전적인 피해도 없었고 기껏해야 법원에서 소스코드 공개 명령이 내려지는게 고작입니다.
그거야 법 판결이 어떻게 나는가 여부에 달린 문제겠죠. 법 전문가가 아닌 사람들이 왈가왈부 할수있는 이야기는 아니라고 봅니다.
Quote:
그리고, 책임 관련하여 애플 예를 드셨는데...을 입장에서 한번도 일해본 적 없으신가보군요. 논쟁이 무의미한 듯. (그렇다고 갑 입장인 적도 없어보입니다만)
사람을 꿰뚫어 보시는 능력이라도 있으신가 보군요. 갑으로도 일해봤고 을로도 일해봤고 제품 개발 초기부터 해본적도 있고 중간에 불끄러 들어가본적도 있고 유지보수만 해본 적도 있고 갑에서 파견근무 해본 적도 있습니다. 유감이지만 능력(?) 개발에 좀더 힘쓰셔야 겠습니다. 왜 갑자기 갑/을 이야기가 나오는지 전혀 감을 못잡겠네요.
제 글의 요지를 요약하자면 "GPL을 포함한 오픈소스 보안코드도 공공기관에 쓰일 수 있어야 한다"는 것이었으며, 논쟁이라기 보다는 어떻게 원작은 무시당하고 아류작이라고 할 수 있는 것들만 인증에 자격이 주어지느냐 하는 질문에 대한 납득할만한 답을 찾는 것 뿐입니다.
그거야 원작자가 물건을 싸들고와서 인증을 받지 않으니 당연한 것 아닙니까?
계약서에 책임과 손배에 관한 항목을 기재하고 거기 싸인은 누가 하나요?
엔진부분의 문제를 신속히 해결하는 것은 누가 문서로 보장해줍니까?
그러면 자신이 라이센스 권리를 갖고 있지도 않은 소프트웨어를 수정해서 원작자 대신 인증을 받는 것은 법적으로 하자가 없다는 것이가요? 애초에 하자있는 계약에 무슨 책임이 존재할 수 있나요?
엔진부분 하자는 서비스 계약하면 해줄 수 있는 곳 많습니다. 다만 제품으로 계약할 수 없죠(라이센스가 없기 때문에). 즉, 하도급 같은 계약이 되겠죠.
Quote:
"기반이 되는 OS가 문제 발생시 책임을 지지 않는데 보안 프로그램이 무슨 책임을 어떻게 지는지 궁금합니다(진심으로 궁금합니다)"
라는 부분에서 을로 일해본(계약서를 작성해본) 경험이 없다고 판단하는 것은 무리가 아니라고 생각되는군요.
(만일 GPL을 위반하고 있는 업체라면) 그전에 GPL을 먼저 읽어보는 것이 순서라고 봅니다. 자기네가 어떤 라이센스를 갖는 소프트웨어를 이용해서 어플리케이션을 작성하고 있는지도 모르면서 작성한 계약서란 것은 십중팔구 뻔할테니까요.
Quote:
그리고 마지막으로 GPL 위반에 관한 손배 규모에 대해서는 회사에서 일하고 계신다면 법무팀이나 계약한 로펌에 한번 문의해보시기 바랍니다. 제가 위에 쓴 공개명령이 고작이라는 이야기는 이 정도의 백그라운드는 가지고 말한겁니다.
그것은 GPL의 권리를 갖고 있는 측에서 굳이 법정까지 가고싶어하지 않기 때문이지, 법적으로 고작 공개명령이 최악의 시나리오여서가 아니랍니다. 어디선가 GPL 관련 법 담당자(대학교수인가하는 사람)의 글을 읽은 적이 있는데, 본보기를 원하는 사람들이 있다더군요. 그런 사람들에게 걸리면 그리 호락호락하지 않을 겁니다. 어설프고 경험없는 법무팀이나 로펌만 믿다가 하루아침에 몽땅 날릴 수도 있으며 애초에 법적으로 하자없는 길을 선택하는 것이 최선책입니다.
상당수 얘기가 나오는게, GPL을 위반한 것이 분명한 사실인데
그쪽에서 그 사실을 무시하거나 무지하거나 묵살한다는 것이 큰 문제같군요.
현실적으로 GPL을 피해가는 법을 차라리 설명하는 것은 어떨까 하군요.
예를 들어서 커널을 고쳐서 자신의 원하는 소스를 적용하고자 할 경우 어떻게 해야 할까요? 커널은 LGPL이 아닌 GPL이라서 링크(참조)만 해도 문제가 되는?
이 경우 인터페이스 모듈을 만들어 GPL로 공개, 그 인터페이스 모듈의 저작권은 GPL이면서 자신에게도 있으므로 그 인터페이스를 통해는 새로운 독자적인 모듈을 만든다?
BSD 라이센스의 커널을 사용하면 됩니다.
여기서 얘기하는 것은 물론 리눅스에 관련된 GPL에 관련된 토의입니다. BSD클론은 논외가 되겠죠.
부연하자면 GPL 소프트웨어는 끝까지 GPL 소프트웨어 이므로, 그 라이센스를 사용할 수 없다면 더 제한없는 다른 라이센스의 비슷한 놈을 선택해야 한다는 뜻입니다. 마치 "호적에 내가 xxx의 자식으로 되어있는데, 성격차이 문제로 xxx의 자식이 아닌 것으로 하면서 xxx로부터 친자상속을 받아 내 잇속은 다 챙길 수 있는 길이 있습니까?" 하는 질문과 비슷한 것 같군요. 답은 "성격차이 없지만 친자상속 규모가 비슷한 yyy에게로 호적을 옮기세요" 입니다.
GPL 만으로는 해결할 수 없는 질문에 대해 해결책으로 BSD를 이야기 한 것이라는 말이죠.
상당수 얘기가 나오는게, GPL을 위반한 것이 분명한 사실인데
그쪽에서 그 사실을 무시하거나 무지하거나 묵살한다는 것이 큰 문제같군요.
현실적으로 GPL을 피해가는 법을 차라리 설명하는 것은 어떨까 하군요.
예를 들어서 커널을 고쳐서 자신의 원하는 소스를 적용하고자 할 경우 어떻게 해야 할까요? 커널은 LGPL이 아닌 GPL이라서 링크(참조)만 해도 문제가 되는?
이 경우 인터페이스 모듈을 만들어 GPL로 공개, 그 인터페이스 모듈의 저작권은 GPL이면서 자신에게도 있으므로 그 인터페이스를 통해는 새로운 독자적인 모듈을 만든다?
BSD 라이센스의 커널을 사용하면 됩니다.
여기서 얘기하는 것은 물론 리눅스에 관련된 GPL에 관련된 토의입니다. BSD클론은 논외가 되겠죠.
부연하자면 GPL 소프트웨어는 끝까지 GPL 소프트웨어 이므로, 그 라이센스를 사용할 수 없다면 더 제한없는 다른 라이센스의 비슷한 놈을 선택해야 한다는 뜻입니다. 마치 "호적에 내가 xxx의 자식으로 되어있는데, 성격차이 문제로 xxx의 자식이 아닌 것으로 하면서 xxx로부터 친자상속을 받아 내 잇속은 다 챙길 수 있는 길이 있습니까?" 하는 질문과 비슷한 것 같군요. 답은 "성격차이 없지만 친자상속 규모가 비슷한 yyy에게로 호적을 옮기세요" 입니다.
GPL 만으로는 해결할 수 없는 질문에 대해 해결책으로 BSD를 이야기 한 것이라는 말이죠.
예를 들어보죠.
제가 들은바로는 (관련 링크를 찾으려니 지금은 찾을 수 없군요)
gcc의 백엔드를 사용하기 위해 gcc를 고치는 대신에 별개의 프로그램을 만들어서 gcc로 *파이프*를 통해서 백앤드만 쓰는 식으로, GPL소프트웨어를 유기적으로 사용하면서 라이센스문제가 없는 소프트웨어도 충분히 만들 수 있다고 들었습니다.
위에서 그 예로 제시한것처럼, 리눅스 커널이 있어야 돌아가지만, 그 인터페이스만 공개하고, 호출되는 함수/혹은 외부 명령은 GPL과 무관한 라이센스를 가지게끔 충분히 만들 수 있다는 말을 하고싶었던 것입니다. 대체가능하고 독립적으로 모듈화한다면 GPL의 소프트웨어를 충분히 활용하면서 상업적으로 쓸 수도 있을 것이라는 얘기죠.
어디선가 읽은 글 보다는 현재 미국시장 3위 규모의 로펌을 믿겠습니다. -_-
글을 계속 보아하니 제가 GPL 위반을 조장한다고 생각하시는 것 같은데, 어느 정도 규모 있는 일을 진행하다보면 관리자로서 당연히 아래 개발자가 어떤 일을 저질렀을 경우 일어날 수 있는 경우의 수를 점검하고, 그런 차원에서 GPL 위반 역시 심도있게 살펴보고 판례 등을 참조하여 결과를 미리 예측한 것입니다.
그렇지만 어디선가 보셨다는 교수의 글에는 상당히 흥미가 가는군요. 출처를 알 수 있을까요? 내용에 따라서는 다시 생각해봐야할지도 모르겠군요. (별 것 아닐거라고 예상은 합니다만..)
규모란 것이 어떤 기준인지는 모르겠습니다만 특정 케이스를 빼고 나머지는 법정비용을 제외하면 액수 기준으로는 자동차 사고 수리비용에도 못미칩니다.
다만 소프트웨어 회사라면 주력 소프트에 GPL이 들어가있을 경우 소스코드 공개 명령으로 인해 주력상품 하나가 GPL 오픈소스가 되어 상품가치를 잃고, 관련된 노하우가 경쟁 회사에 "GPL을 위반" 하는 형태로 흡수된다는 최악의 시나리오를 상정할 수는 있습니다. 하지만 이마저도 링크시스의 예에서 볼 수 있듯 주력상품의 가치에서 GPL 감염범위가 미미하다면 응해줄까 말까는 손익보다는 기업이미지의 차원에서 접근할 문제가 됩니다. (이 경우는 공개의 임팩트 역시 미미하므로 나중에라도 공개하는 것에 큰 문제가 없습니다.)
GPL 관련 소송으로 액수를 좀 크게 받아내고 싶으시다면 특정 케이스를 노리시는게 좋겠습니다. 바로 QT나 MySQL입니다.
듀얼라이센스 정책을 사용하여 하나를 GPL화 하고 나머지 하나를 상용 라이센스로, 그리고 상용 라이센스의 가격을 적당히 높게 잡고 어느 정도 판매 실적이 있다면 이 자료를 근거로 GPL 컴포넌트=상용 라이센스의 불법 사용이라는 결과를 이끌어낼 수 있습니다. 그러면? 톡톡히 받아낼 수 있는거죠. 물론 대부분의 순수한 GPL 산물과는 거리가 먼 일입니다만.
자세한 사항은 모르지만, 만일 커널을 바꾸었다면 공개해야 합니다(물론, 정식 라이센스 받았다면 상관없습니다)
제가 알기론 보안 쪽 역시 snort, iptables, pf, nessus 등을 수정해서 사용한 것으로 아는데, pf만 제외하고 나머지는 정식 라이센스 계약이 없었다면 모두 라이센스 위반입니다.
니틱스는 모든 라이센스를 정식으로 획득한 후에, 변형개발한 제품입니다. 가격이 내려갈 수 없는 이유도 이것 때문에 발생합니다. 니틱스는 5유저 CAL 라이센스 비용이 국내에서 약 99만원 정도 합니다만, 정식라이센스 획득하지 않고 GPL로 공개하여 판매했다면 가격은 훨씬 내려갈 수 있겠죠....
만에 하나라도 니틱스가 GPL/GNU를 어겼다면 당연히 매도당해도 싸다고 생각합니다. 대문도 내려버려야 되겠죠...........
전염성(해당 라이센스를 이용한 2차저작물은, 해당 라이센스를 따라야 한다
전염성(해당 라이센스를 이용한 2차저작물은, 해당 라이센스를 따라야 한다 라는)이 없는 라이센스로도 꽤 여러 라이센스가 있습니다.
예를 들어 BSD라이센스 같은 경우가 그렇다고 알고 있습니다.
(정확한지는 모르겠네요;; )
http://www.gnu.org/licenses/license-list.html
GPL을 따르지 않을때는 FSF에서 관리가 들어갈 수 있는 것 으로 알고 있습니다.
GPL을 개발자가 따르고, 따르지 않고는
일단 개발자의 자질 문제 라고 생각하고,
라이센스 위반에 따른 문제는 일반적으로 개발자와 도용자의 합의에 따라 해결되는걸로 알고 있습니다.
BSD라이센스는 2차 저작물을 소스나 바이너리 형식으로배포할 때 BS
BSD라이센스는 2차 저작물을 소스나 바이너리 형식으로
배포할 때 BSD License임을 표시하는 문구를 항상 표시하도록
되어야 합니다. 만일 아무렇게나 변경할 수 있다면 그건
오픈소스 라이센스라고 하기 힘들겠죠.. PS2나 PSP에 NetBSD의
라이센스가 표시되어 있는 것도 같은 이유로 보시면 되겠습니다.
우리나라 회사들 중에는 아직까지 GPL에 큰 신경을 쓰는 경우가
별로 없는 거 같습니다. 심지어 GPL 부분을 지우고 떡하니
ㅎㅈㅎ 자기들 라이센스를 껴놓은 경우도 봤구오. (상당히 큰
회사였습니다만)
개인적인 생각을 말씀드리자면, GPL이 잘 지켜지지 않는 이유는
라이센스 자체가 회사에서 사용하기에 (기술적이거나 윤리적인
문제가 아니라, 기존의 회사의 정책이라든지 경영진의 편집증
탓이 크겠지요) 약간 부적합한 면이 있기 때문이 아닐까 하는
생각은 가끔 합니다. 물론 그것이 GPL위반에 대한 변명이 될
수는 없죠. 하지만, 왜 PSP에 임베디드 리눅스 코드가 아닌
NetBSD의 코드가 사용되었는지는 생각해 볼 만한 가치가
있다고 봅니다. :)
GPL의 위반사례를 목격하셨고, 충분한 증거가 있으신 경우에는
이슈화를 시켜서 여러 사람들에게 알게 하고, 그로 인한 압력을
가하는 방법이 거의 유일하지 않을까 생각합니다. (지난번의
프루나/동키호테 건 처럼..) 아니면 FSF에 신고를 하는 방법도
있겠구요.
----
Let's shut up and code.
mplayer 예를 보면 커뮤니티에서 아무리 이슈화되도 잘 해결이 되지
mplayer 예를 보면 커뮤니티에서 아무리 이슈화되도 잘 해결이 되지 않으며,
실직적으로 법적으로도 보호 받기 힘든것 같습니다.
법적으로 이겨도 개인이 감당하기에는 너무 힘든것 같습니다.
----------------------------------------
http://moim.at
http://mkhq.co.kr
저도 [b]happyjun[/b] 님 말쑴에 전적으로 동의합니다.
저도 happyjun 님 말쑴에 전적으로 동의합니다.
푸르나를 봐도 그렇고....이슈화 시켜도 피해갈려고 하면 얼마든지 피해갈 수 있는것 같습니다. 얼마전 다람쥐 메일을 수정해서 배포한 업체는 오히려 GPL어기면 신고당하는지 궁금하다고 하면서까지 여유를 부렸던 것으로 기억하고 있습니다. :(
mp3를 만드는 모 업체에서 PMP를 만드는데 GPL된 소스를 사용해서
mp3를 만드는 모 업체에서 PMP를 만드는데 GPL된 소스를 사용해서 상당히 소송에 걸려있습니다. GPL힘없다고 무시하다 큰코다칩니다.
http://www.ussg.iu.edu/hypermail/linux/kernel/0411.3/1648.html
커널메일링 리스트의 쓰레드에 대충 언급됩니다...
큰 코를 다칠 일이 있나요? 손해배상 규모는 상당히 궁금한 점이긴 하군요
큰 코를 다칠 일이 있나요? 손해배상 규모는 상당히 궁금한 점이긴 하군요.
우리나라 현실에서 GPL, 넓게 봐서 오픈 소스와 관련된 심각한 문제 중
우리나라 현실에서 GPL, 넓게 봐서 오픈 소스와 관련된 심각한 문제 중의 하나는 이렇습니다. 우리나라에서는 오픈 소스로 소스를 공개했을때 derivative work가 외국에 비해 상대적으로 발전이 없습니다. 이렇게 되면 소스 코드 공개의 순이익이 줄어들 수 밖에 없습니다.
그러다보니 특히 기업의 입장에서는 자신이 GPL 코드를 가져다 썼더라도 소스 코드 공개로 인한 이익이 없으니 그냥 배째라 식으로 소스 코드 공개를 안하게 되는 것이고 원저자가 대부분 외국인인 점을 감안하면 소스 코드를 공개하지 않더라도 소송을 당할 위험은 상대적으로 낮을 수 밖에 없습니다.
이러다보니 제 3자들이 나서서 GPL소스인데 왜 공개안하냐고 험한 분위기를 조성할 수 밖에 없고 압박(?)에 못이겨 소스 코드를 공개하더라도 이 사람 입장에서는 소스코드 공개해봐야 얻을 이익은 여전히 없습니다.
상황이 이러니 앞으로도 국내에서 GPL 코드 도용 사례는 더 늘어날 전망입니다.
그리고 외국에서도 인터넷 공유기와 같은 제품들은 소스 코드를 공개하더라도 여기에 기반한 derivative work 발전 가능성이 낮다 보니 GPL 코드 도용 사례가 많은 편입니다. 그래도 이쪽은 상황이 많이 나은편입니다. Linksys WRT54G 제품의 경우 처음에는 GPL 코드 사용을 숨겼다가 이것이 이슈화되자 결국 여론의 압박에 못이겨 소스코드를 공개하게 되었는데요... 요즘은 Linksys가 소스코드 공개의 덕을 보고 있습니다. 사용자들 사이에서 개조 firmware들이 나오기 시작했고 무선 라우터 개조를 원하는 사람들은 이제 WRT54G를 많이 구입하게 되었습니다. 이런 incentive가 한국의 현실에서는 여전히 어렵다는 점이 GPL의 현실에 관련히 아쉬운 부분이 되겠지요.
현재로서 GPL도용 케이스를 당했을때 원저자가 대처할 수 있는 가장 효과적인 방법은 언론사를 접촉하는 방법이라고 봅니다. 한국 전역의 온라인 오프라인 매체들이 기사를 뿌려대기 시작하면 도용한 사람도 별 대책이 없을 겁니다. 원저작자의 credit 도용은 누가봐도 분노(?)할 수 있는 주제이고 헤드라인을 조금만 손질하면 금방 오늘의 best click 기사로 올라가겠지요.
"I conduct to live,
I live to compose."
--- Gustav Mahler
http://www.filebee.co.kr 파일비 라고 국내에서
http://www.filebee.co.kr
파일비 라고 국내에서 만든 emule클라이언트가 있습니다. 그런데 예전의 푸르나처럼 소스공개를 미루고 있네요. 게시판에 소스공개,라이센스표기의 요청을 했더니
이런 답변이 올라왔네요.
이말도 믿을수 없지만
이건 또 무슨 속셈인지 모르겠네요. :evil:
자꾸 이런일은 늘어갈테고 언젠가 정말 뉴스에 이슈가 될지도 모르겠네요.
"불법공유 조장하는 프로그램 제작자가 자신들의 프로그램 저작권을 주장".
"불법공유 조장하는 프로그램 제작자가 자신들의 프로그램 저작권을 주장"...파문
[quote]저희가 개발한 파일비는 GPL에 해당하는 부분과 해당되지 않
파일비 개발자는 GPL에 대해서 정확한 인식이 부족한 듯 합니다.
안타깝네요...
[quote="Anonymous"]"불법공유 조장하는 프로그램 제작자가
마약도 훔치면 절도입니다.
[quote="tankgirl"]http://www.filebee.co.
파일비 홈페이지에 글을 남겼더니 다음과 같은 글이 붙었네요.
라이센스를 지키기 위해서 소스코드를 공개한다니 다행이지만, 이미 위반한 사항에 대해서 "소스코드를 나중에라도 공개하겠다, 그러니까 괜찮은 거 아니냐"라고 생각하는 거 같네요. 이미 위반한 점에 대해서 어떻게 반응할지 궁금합니다.
커널컴파일한다고 그녀를 기다리게 하지 마라.
gpl의 의무는 개작/수정한 소프트웨어를 배포하는 시점부터 발생합니다.
gpl의 의무는 개작/수정한 소프트웨어를 배포하는 시점부터 발생합니다. 따라서 위에 이야기되고 있는 파일비라는 곳에서 소프트웨어를 배포하는 시점부터 사용자가 소스코드를 원할 경우 제공해 줄 수 있어야 합니다. (해당 소프트웨어가 gpl의 적용을 받는다는 것이 명확할 경우)
emule관련해서 계속적으로 이런 일이 생긴다는 것이 매우 안타깝군요. /.같은 곳에 회자된다면 그렇지 않아도 스팸메일 등으로 그다지 좋지 않은 한국의 이미지에 먹칠하기 딱 좋은 아이템입니다.
오픈소스 라이센스, 특히 gpl에 대해서 정말 제대로 된 가이드라인이 필요한 시점인 것 같습니다.
이와 관련해서.. 비공식이더라도 국문판 GPL을 볼 수 있는 곳이 어디
이와 관련해서.. 비공식이더라도 국문판 GPL을 볼 수 있는 곳이 어디 있나요?
좀 찾아봤는데 잘 안보이는 것 같습니다.
---
없으면 만들어볼까 생각중입니다.
---
edit: 헛. 구글에서 검색해보니 바로 나오네요.
http://korea.gnu.org/people/chsong/copyleft/gpl.ko.html
이거 역시 GPL 위반 아닌가요?
니틱스 리눅스라고 하는건데요
http://www.nitixkorea.co.kr/
이 제품역시 리눅스라고 자기 자신들이 선전하고 Kernel 2.4 를 사용합니다.
근데. 자기들이 만든 특허(?)가 있고 해서 소스 공개는 하지 않는다고 합니다.
제가 이걸 구매후 소스 코드를 요청하면 소스 코드를 줘야 하는거 아닌가요?
이건 GPL 위반인가요?
Re: 이거 역시 GPL 위반 아닌가요?
자세한 사항은 모르지만, 만일 커널을 바꾸었다면 공개해야 합니다(물론, 정식 라이센스 받았다면 상관없습니다)
제가 알기론 보안 쪽 역시 snort, iptables, pf, nessus 등을 수정해서 사용한 것으로 아는데, pf만 제외하고 나머지는 정식 라이센스 계약이 없었다면 모두 라이센스 위반입니다.
웃기는 것은 정작 국정원 보안제품 인증을 받은 그런 제품들에 비해 원본들은 인증을 받을 길 조차 없어서 공공기관에서는 사용할 수 없다는 점입니다. 정말 웃기죠?
그래서 요새는 툴킷을 제공하는 업체들은 GPL 걸린 코드를 모두 걷어낸
그래서 요새는 툴킷을 제공하는 업체들은 GPL 걸린 코드를 모두 걷어낸 다음 "우리 소스는 GPL-Free 입니다. 안심하십시요." 하고 파는 경우가 많습니다.
you must know the power of dark side.
왠지 GPL이라고 하면 더 가져다 쓰는것 같습니다.사람들 인식이 바뀌
왠지 GPL이라고 하면 더 가져다 쓰는것 같습니다.
사람들 인식이 바뀌어서 제대로된 오픈소스문화가 정착했으면 좋겠습니다.
==========================================
위키를 개발하고 있습니다.
국정원 인증의 경우는 핵심이 "문제 발생시 누가 책임을 질 것이냐"죠.
국정원 인증의 경우는 핵심이 "문제 발생시 누가 책임을 질 것이냐"죠.
국가 기관에서 사용 중에 해당 보안 프로그램으로 인해서
문제가 발생되었을 때에(불명확한 패턴으로 탐지/대응이 안되었다와 같이)
책임을 추궁할 주체가 없다는게 문제죠.
실제로 snort같은 경우도 주옥같은 패턴들도 많지만,
일단은 다 잡고 보자 식이던가(이런 경우를 case by case로 모두 관리자가
등록하는 건 현실적으로 어렵죠. 그래서 snort를 그대로 가져다가 껍데기만
바꿔서 파는 회사들도 있겠죠....라이센스 위반이겠지만..)
혹은 불충분한 패턴인 경우도 많더군요.
그래서 발생했을 경우에 정부기관에서 사용 하기에 적합하다는
인증을 준 국정원 입장에서는 곤란하다는 거죠.
머 저도 이런 부분 때문에 엄청 짜증난 적도 있었지만,
차근차근 생각해보면 이해가 가기도 하더군요. ^^
[quote="zingle"]국정원 인증의 경우는 핵심이 "문제 발생시
오픈소스 코드는 문제발생시 누가 책임을 지겠습니까? 버그보고라는 것이 왜 있겠습니까? 원한다면 소스조차 바꿀 수 있습니다. (오픈소스 코드 버그리포트와 그렇지 않은 코드의 버그 리포트 비교해 보면 무슨 뜻인지 아실 겁니다. 아는 이의 경험을 빌리자면, 애플에 아무리 버그 리포트 보내봤자 무엇을 어떻게 하고 있는지 알수도 알려주지도 않고 해결할 길이 전혀 없지만 오프소스 코드인 경우 투명하게 모든 진행 상황을 알수 있으며 혹시라도 기분 나쁘게 묵살 당하면 스스로 패치해서 사용할 수 있습니다)
어떤 OS든지 설치시 "라이센스에 동의합니다" 버튼 누르기 전에 읽어보면 대부분 '소프트웨어 사용중 발생한 문제에 대해서는 책임지지 않는다'라는 부분이 나옵니다. 기반이 되는 OS가 문제 발생시 책임을 지지 않는데 보안 프로그램이 무슨 책임을 어떻게 지는지 궁금합니다(진심으로 궁금합니다) 제 생각에 컴퓨터 혹은 네트워크 보안이라는 것은 시스템을 이루는 각 계층이 모두 어느 정도의 안전성이 보장되어야 합니다. 예를들어 NIDS 프로그램이 아무리 좋더라도 그 아래단에서 타협해 버렸다면 무용지물이 되어버리는 겁니다. 보안에 있어서 100% 안전한 것은 있을 수 없고, 특정 소프트웨어 몇가지가 모든 것을 해결해주리라는 생각 자체가 잘못입니다. "보안은 프로세스이다"라고 한 보안 전문가 이야기가 생각나는 군요.
어떤식으로 책임을 추궁하는지 정말 궁금하군요. 모든 소프트웨어는 버그 혹은 요구사항이 변하게 되어있습니다. 그런데 요구사항 변경(이를테면 최초 현존하는 공격패턴의 90% 탐지였는데, 1년후 새로운 공격패턴이 100% 증가했다)된 경우 어떤 식으로 추궁할 수 있을지 의문입니다. (아마 추가된 GPL 라이센스인 룰셋을 카피해서 전달하겠죠)
패턴에 대한 것은 주로 룰셋에 대한 것으로 아는데, 누구나 룰셋을 정의할 수 있습니다. 결국 그런 식으로 사업하는 곳들은 룰셋 장사인데, GPL이라면 그런 룰셋을 공개해서 다른 곳에서도 사용할 수 있어야 합니다. 그정도를 위에서 '문제해결'이라고 한다면 GPL 소프트웨어 사용 보안서비스 제공자 측에서 새로운 패턴 발견시 룰셋 추가하거나 재정의 하면 됩니다(물론 그 룰셋은 원래 GPL 소프트웨어 제작자 측에게 보내져서 다른 이들도 혜택을 보아야 하며, 이것이 대부분 원작자들의 의도입니다. 즉, 십시일반으로 모두가 공헌할 수 있고 모두가 사용할 수 있게 한다.)
잘 생각해 봐도 이해가 안가는데, 아마도 일이 잘못되었을 때 얼마나 어떻게 책임져 주는지를 잘 몰라서 인것 같습니다.
이런 시나리오는 어떤가요? 대부분 보안회사가 라이센스 위반으로 기소되어 제품에 대해 정상적인 판매 및 유지보수가 불가능해진다. 이미 기존에 제품을 사용하고 있는 고객들에 대해 이 문제는 어떻게 해결해 줄 것인가? 방화벽도 내려야 하고 IDS도 더이상 사용할 수 없다? 또 GPL에 의해 코드 공개해야 하는데, 그렇게 되면 조만간 원본 GPL 소프트웨어에 반영된다고 가정해 보면 국정원의 인증은 무엇을 인증한 것인지?
이런 점에서 오히려 원본 GPL 보안 소프트웨어가 인증을 받는 길이 있어야 합니다. 원본 소프트웨어는 대부분 프로세스 자체가 투명하고 엔진부분의 문제역시 신속히 해결되며, 룰셋도 전세계적으로 사용되고 있기 때문에 신뢰성이 더 있습니다. Counterpane의 설립자이자 보안 전문가인 Bruce Shneier(spell?)는 보안에 사용되는 암호화 알고리듬은 모두 공개되어서 안전성이 전세계 많은 암호전문가에게 수년동안 검증받은 것이 안전하고, 보안에 사용되는 툴 역시 오픈소스로 공개되고 오랜기간 검증받은 것이 안전하다고 하였습니다. 이 이야기야 말로 상식적으로 이해할 수 있고 동의할 수 있다고 봅니다.
http://lisp.or.kr http://lisp.kldp.org - 한국 리습 사용자 모임
GPL 위반했다고 판매중지 같은거 일어날 일은 없습니다. 금전적인 피해도
GPL 위반했다고 판매중지 같은거 일어날 일은 없습니다. 금전적인 피해도 없었고 기껏해야 법원에서 소스코드 공개 명령이 내려지는게 고작입니다.
그리고, 책임 관련하여 애플 예를 드셨는데...을 입장에서 한번도 일해본 적 없으신가보군요. 논쟁이 무의미한 듯. (그렇다고 갑 입장인 적도 없어보입니다만)
[quote="Anonymous"]GPL 위반했다고 판매중지 같은거 일어
그거야 법 판결이 어떻게 나는가 여부에 달린 문제겠죠. 법 전문가가 아닌 사람들이 왈가왈부 할수있는 이야기는 아니라고 봅니다.
사람을 꿰뚫어 보시는 능력이라도 있으신가 보군요. 갑으로도 일해봤고 을로도 일해봤고 제품 개발 초기부터 해본적도 있고 중간에 불끄러 들어가본적도 있고 유지보수만 해본 적도 있고 갑에서 파견근무 해본 적도 있습니다. 유감이지만 능력(?) 개발에 좀더 힘쓰셔야 겠습니다. 왜 갑자기 갑/을 이야기가 나오는지 전혀 감을 못잡겠네요.
제 글의 요지를 요약하자면 "GPL을 포함한 오픈소스 보안코드도 공공기관에 쓰일 수 있어야 한다"는 것이었으며, 논쟁이라기 보다는 어떻게 원작은 무시당하고 아류작이라고 할 수 있는 것들만 인증에 자격이 주어지느냐 하는 질문에 대한 납득할만한 답을 찾는 것 뿐입니다.
그거야 원작자가 물건을 싸들고와서 인증을 받지 않으니 당연한 것 아닙니까
그거야 원작자가 물건을 싸들고와서 인증을 받지 않으니 당연한 것 아닙니까?
계약서에 책임과 손배에 관한 항목을 기재하고 거기 싸인은 누가 하나요?
엔진부분의 문제를 신속히 해결하는 것은 누가 문서로 보장해줍니까?
"기반이 되는 OS가 문제 발생시 책임을 지지 않는데 보안 프로그램이 무슨 책임을 어떻게 지는지 궁금합니다(진심으로 궁금합니다)"
라는 부분에서 을로 일해본(계약서를 작성해본) 경험이 없다고 판단하는 것은 무리가 아니라고 생각되는군요.
그리고 마지막으로 GPL 위반에 관한 손배 규모에 대해서는 회사에서 일하고 계신다면 법무팀이나 계약한 로펌에 한번 문의해보시기 바랍니다. 제가 위에 쓴 공개명령이 고작이라는 이야기는 이 정도의 백그라운드는 가지고 말한겁니다.
한 마디 덧붙이자면 이 곳에서 각종 라이센스를 다루는 엔지니어 자신이 라
한 마디 덧붙이자면 이 곳에서 각종 라이센스를 다루는 엔지니어 자신이 라이센스 침범관련 판결 및 영향 예측에 무지하다고 가정하는건 오히려 이상하지 않나 싶군요.
[quote="Anonymous"]그거야 원작자가 물건을 싸들고와서 인증
그러면 자신이 라이센스 권리를 갖고 있지도 않은 소프트웨어를 수정해서 원작자 대신 인증을 받는 것은 법적으로 하자가 없다는 것이가요? 애초에 하자있는 계약에 무슨 책임이 존재할 수 있나요?
엔진부분 하자는 서비스 계약하면 해줄 수 있는 곳 많습니다. 다만 제품으로 계약할 수 없죠(라이센스가 없기 때문에). 즉, 하도급 같은 계약이 되겠죠.
(만일 GPL을 위반하고 있는 업체라면) 그전에 GPL을 먼저 읽어보는 것이 순서라고 봅니다. 자기네가 어떤 라이센스를 갖는 소프트웨어를 이용해서 어플리케이션을 작성하고 있는지도 모르면서 작성한 계약서란 것은 십중팔구 뻔할테니까요.
그것은 GPL의 권리를 갖고 있는 측에서 굳이 법정까지 가고싶어하지 않기 때문이지, 법적으로 고작 공개명령이 최악의 시나리오여서가 아니랍니다. 어디선가 GPL 관련 법 담당자(대학교수인가하는 사람)의 글을 읽은 적이 있는데, 본보기를 원하는 사람들이 있다더군요. 그런 사람들에게 걸리면 그리 호락호락하지 않을 겁니다. 어설프고 경험없는 법무팀이나 로펌만 믿다가 하루아침에 몽땅 날릴 수도 있으며 애초에 법적으로 하자없는 길을 선택하는 것이 최선책입니다.
http://lisp.or.kr http://lisp.kldp.org - 한국 리습 사용자 모임
상당수 얘기가 나오는게, GPL을 위반한 것이 분명한 사실인데그쪽에서
상당수 얘기가 나오는게, GPL을 위반한 것이 분명한 사실인데
그쪽에서 그 사실을 무시하거나 무지하거나 묵살한다는 것이 큰 문제같군요.
현실적으로 GPL을 피해가는 법을 차라리 설명하는 것은 어떨까 하군요.
예를 들어서 커널을 고쳐서 자신의 원하는 소스를 적용하고자 할 경우 어떻게 해야 할까요? 커널은 LGPL이 아닌 GPL이라서 링크(참조)만 해도 문제가 되는?
이 경우 인터페이스 모듈을 만들어 GPL로 공개, 그 인터페이스 모듈의 저작권은 GPL이면서 자신에게도 있으므로 그 인터페이스를 통해는 새로운 독자적인 모듈을 만든다?
[quote="Anonymous"]상당수 얘기가 나오는게, GPL을 위반
BSD 라이센스의 커널을 사용하면 됩니다.
http://lisp.or.kr http://lisp.kldp.org - 한국 리습 사용자 모임
[quote="LispM"][quote="Anonymous"]상당수 얘기
여기서 얘기하는 것은 물론 리눅스에 관련된 GPL에 관련된 토의입니다. BSD클론은 논외가 되겠죠.
[quote="Anonymous"][quote="LispM"][quote
부연하자면 GPL 소프트웨어는 끝까지 GPL 소프트웨어 이므로, 그 라이센스를 사용할 수 없다면 더 제한없는 다른 라이센스의 비슷한 놈을 선택해야 한다는 뜻입니다. 마치 "호적에 내가 xxx의 자식으로 되어있는데, 성격차이 문제로 xxx의 자식이 아닌 것으로 하면서 xxx로부터 친자상속을 받아 내 잇속은 다 챙길 수 있는 길이 있습니까?" 하는 질문과 비슷한 것 같군요. 답은 "성격차이 없지만 친자상속 규모가 비슷한 yyy에게로 호적을 옮기세요" 입니다.
GPL 만으로는 해결할 수 없는 질문에 대해 해결책으로 BSD를 이야기 한 것이라는 말이죠.
http://lisp.or.kr http://lisp.kldp.org - 한국 리습 사용자 모임
[quote="LispM"][quote="Anonymous"][quote
예를 들어보죠.
제가 들은바로는 (관련 링크를 찾으려니 지금은 찾을 수 없군요)
gcc의 백엔드를 사용하기 위해 gcc를 고치는 대신에 별개의 프로그램을 만들어서 gcc로 *파이프*를 통해서 백앤드만 쓰는 식으로, GPL소프트웨어를 유기적으로 사용하면서 라이센스문제가 없는 소프트웨어도 충분히 만들 수 있다고 들었습니다.
위에서 그 예로 제시한것처럼, 리눅스 커널이 있어야 돌아가지만, 그 인터페이스만 공개하고, 호출되는 함수/혹은 외부 명령은 GPL과 무관한 라이센스를 가지게끔 충분히 만들 수 있다는 말을 하고싶었던 것입니다. 대체가능하고 독립적으로 모듈화한다면 GPL의 소프트웨어를 충분히 활용하면서 상업적으로 쓸 수도 있을 것이라는 얘기죠.
어디선가 읽은 글 보다는 현재 미국시장 3위 규모의 로펌을 믿겠습니다.
어디선가 읽은 글 보다는 현재 미국시장 3위 규모의 로펌을 믿겠습니다. -_-
글을 계속 보아하니 제가 GPL 위반을 조장한다고 생각하시는 것 같은데, 어느 정도 규모 있는 일을 진행하다보면 관리자로서 당연히 아래 개발자가 어떤 일을 저질렀을 경우 일어날 수 있는 경우의 수를 점검하고, 그런 차원에서 GPL 위반 역시 심도있게 살펴보고 판례 등을 참조하여 결과를 미리 예측한 것입니다.
그렇지만 어디선가 보셨다는 교수의 글에는 상당히 흥미가 가는군요. 출처를 알 수 있을까요? 내용에 따라서는 다시 생각해봐야할지도 모르겠군요. (별 것 아닐거라고 예상은 합니다만..)
상품이 잘 팔려서 때돈벌게되면 역사상 최대규모의 GPL관련 소송이 벌어질
상품이 잘 팔려서 때돈벌게되면 역사상 최대규모의 GPL관련 소송이 벌어질수도 있겠군요. 기대됩니다!!
규모란 것이 어떤 기준인지는 모르겠습니다만 특정 케이스를 빼고 나머지는
규모란 것이 어떤 기준인지는 모르겠습니다만 특정 케이스를 빼고 나머지는 법정비용을 제외하면 액수 기준으로는 자동차 사고 수리비용에도 못미칩니다.
다만 소프트웨어 회사라면 주력 소프트에 GPL이 들어가있을 경우 소스코드 공개 명령으로 인해 주력상품 하나가 GPL 오픈소스가 되어 상품가치를 잃고, 관련된 노하우가 경쟁 회사에 "GPL을 위반" 하는 형태로 흡수된다는 최악의 시나리오를 상정할 수는 있습니다. 하지만 이마저도 링크시스의 예에서 볼 수 있듯 주력상품의 가치에서 GPL 감염범위가 미미하다면 응해줄까 말까는 손익보다는 기업이미지의 차원에서 접근할 문제가 됩니다. (이 경우는 공개의 임팩트 역시 미미하므로 나중에라도 공개하는 것에 큰 문제가 없습니다.)
GPL 관련 소송으로 액수를 좀 크게 받아내고 싶으시다면 특정 케이스를 노리시는게 좋겠습니다. 바로 QT나 MySQL입니다.
듀얼라이센스 정책을 사용하여 하나를 GPL화 하고 나머지 하나를 상용 라이센스로, 그리고 상용 라이센스의 가격을 적당히 높게 잡고 어느 정도 판매 실적이 있다면 이 자료를 근거로 GPL 컴포넌트=상용 라이센스의 불법 사용이라는 결과를 이끌어낼 수 있습니다. 그러면? 톡톡히 받아낼 수 있는거죠. 물론 대부분의 순수한 GPL 산물과는 거리가 먼 일입니다만.
저 위에 니틱스 말인데요...............
니틱스는 모든 라이센스를 정식으로 획득한 후에, 변형개발한 제품입니다. 가격이 내려갈 수 없는 이유도 이것 때문에 발생합니다. 니틱스는 5유저 CAL 라이센스 비용이 국내에서 약 99만원 정도 합니다만, 정식라이센스 획득하지 않고 GPL로 공개하여 판매했다면 가격은 훨씬 내려갈 수 있겠죠....
만에 하나라도 니틱스가 GPL/GNU를 어겼다면 당연히 매도당해도 싸다고 생각합니다. 대문도 내려버려야 되겠죠...........
GPL 관련 소송 안내
현재 한국내에 진행중인 GPL 관련 소송인 엘림넷 대 하이온넷에 대한 게시판이 http://bbs.kldp.org/viewtopic.php?t=61351 에 열려있습니다.
자유소프트웨어재단(FSF)은 한국내에서의 GPL 강제를 위해 이건 소송에
직접 개입하였고, 다른 사건에 대해서도 GPL 강제가 필요하다면 소송을 통해
이를 해결해 나갈 계획입니다.
이관 관련하여, GPL 위반 사례를 알고계시면 위 게시판에 직접 게시를 해 주시면
법률 검토과정을 통해 해당기업에 대한 권고 및 소송 등으로 문제를 해결할
예정입니다.
자유소프트웨어재단 한국내 대리인 송창훈 <chsong@gnu.org>