Embedded Linux를 사용하는 국내 장비 업체들이 GPL 준수를 꺼리는 까닭은?
글쓴이: whitenoise / 작성시간: 월, 2007/07/02 - 12:13오후
Embedded 기기 분야에 linux가 도입된지도 이미 오랜 시간이 지났고 다양한 분야에 걸쳐 embedded linux가 사용되는 것으로 알고 있습니다. 그럼에도 불구하고 배포시 따라오는 GPL의 의무 조항을 준수하고 있는 업체는 찾아보기가 힘든 현실입니다. 가장 기본적인 의무인 제품에 라이센스를 포함하는 것조차 하지 않고 있는 곳도 많습니다. 이처럼 장비 개발 업체들이 GPL 의무를 준수하고 있지 않은 이유는 무엇일까요?
어림잡아 추측해 본다면,
1. GPL에 대한 정확한 인식 부족
2. GPL 소프트웨어에 대한 링크로 인해 업체에서 개발한 코드도 같이 공개해야 하는 부담 때문에... (경쟁력 상실에 대한 두려움)
3. 소스 코드 공개후 사용자가 잘못 수정한 코드 및 그로 인해 손상된 기기까지도 AS 해야 한다는 부담 때문에...
4. 하고 싶긴 하지만, 정확한 방법이나 소스 코드 공개 이후 관리에 대한 지식 부족
그 외 몇가지 더 떠오르긴 하지만 어디까지나 미루어 짐작한 내용들입니다.
혹시 관련 업체에 종사하는 분들이 계시면 이에 관한 솔직한 의견을 듣고 싶습니다.
Forums:
딴 회사에서 베껴갈까봐
아 물론 OS는 말구요...
버그는, 아마 그렇게 해서라도 잡을 수 있으면 잡고 싶을듯.
하지만 베껴가기만 하고 버그를 잡아주진 않을테니 난감
기술력 잆는
기술력 잆는 회사에게 기술 공개하라고 하면 어떻게 합니까?
"있긴 있는데 못알려 준다." 그래서 공개 못하는 거죠.
+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년
+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년
대기업의 GPL 준수는?
임베디드 산업에서의 GPL 관련 자료 사용은 너무나 광범위하게 펼쳐져 있습니다. 특히 현재 공개되는 여러 하드웨어 칲셋들은 그의 구동 드라이버가 리눅스로 제공되므로 중소기업 대기업을 막론하고 GPL 관련 사용을 피해가는 길은 원천적으로 불가능하다고 생각됩니다. 최근 일부 일간지에 개제된 것 처럼 GPL의 무단 사용은 HDTV 등의 제품에 널리 사용되고 있으며 실제 대기업에서는 리눅스 기술과 관련된 전담 부서를 두어 개발을 진행하고 있으나 실제 제품에 사용된 소스 코드를 국내에 오픈한 사례를 찾아볼 수 없는 듯 합니다.
이와 같은 GPL의 준수에 관하여 중소기업에 대한 준수도 중요하겠으나 산업 전반에 더 큰 영향력을 갖고 있는 대기업 부터 솔선 수범하는 모습을 보이는 것이 맞다고 하겠습니다. 남이하면 불륜이고 내가하면 로맨, 즉 대기업은 영업 비밀이라는 것으로 보호 받고 중소기업은 GPL 위반이다라는 식으로 진행되어서는 곤란하다고 생각됩니다.
이곳에도 대기업에 근무하시며 리눅스 관련된 제품 개발을 하시는 분이 적지 않은 것으로 알고 있는데요 먼저 솔선하시어 개발 제품의 내용을 알려주시고 이에 대한 소스 오픈을 유도하시는 것은 어떨까합니다.
참 희한한 관점이군요.
남이 공개를 하든 안 하든 우선 GPL 소스를 가져다 썼으면 공개하는 게 맞습니다.
참고로 저는, iptime 공유기 4대를 쓰고 있는 고객입니다. GPL 라이센스 조항에 의하면 불특정 다수는 아니더라도 고객에게는 공개를 하도록 되어 있으니 저에게 공개할 의무는 있으십니다.
- 저는 IT 쪽이 아닌 기계/소재 관련 업체에 근무합니다.
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
http://akpil.egloos.com
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
일단
남들이 하면 하겠다 하지 말고 본인들 할 일만 하시면 됩니다.
====================어흥====================
짖지마시고 말씀을 하세요.
저 나름 대기업에
저 나름 대기업에 일하고 있는데, 이 곳에서 개발할 때 OSS 라이센스에 대한 내용을 검사합니다.
정확한 예를 들 순 없지만 (비밀이므로) 대충 돌려 말해보면,
A: 이 라이브러리를 사용하기로 했는데 오픈소스네요.
B: 살펴보니, LGPL이라서 링크하는 것은 관계없네요, 그런데 제대로 사용하려면 수정해야 하는데, 수정하면 공개해야 할텐데 어떻게 할까요?
A: (라이센스 담당하는 부서의) C에게 문의해보세요.
C: 오픈소스를 사용할 때는 주의해야 합니다. Linksys의 예와 같이 공개해버린 경우, iRiver 경우 등등... 기업 이미지가 상할 수 있기 때문에 어쩌고 저쩌고... 자세한 것은 유첨 참고...
B: 이렇게 하면 성능은 조금 떨어질 수 있지만, 외부 독립 모듈로 만들어서 LGPL을 위반하지 않고 할 수 있겠네요. 소프트웨어도 조금 수정해야 하지만, 그 정도 수정은 trivial하기 때문에 공개해도 됩니다.
A: 그렇게 합시다.
이런식으로 진행한 일이 있습니다.
그런데, 뭐 모든 부서를 다 통제할 순 없으니 완벽하다곤 할 수 없겠지만, 기본적으로 오픈소스에 대한 가이드라인은 가지고 있습니다.
회사를 대표하여
회사를 대표하여 이야기 할 때는 두번세번 그 내용과 결과를 되씹어봐야 합니다.
예를들어, 현재 문제시 되고 있는 주제에 대해서만 집중해야지 아니면 회사에 누가 될수도 있습니다.
이 문제는 GPL 관련 문제이며, GPL과 관련된 당사자들 사이의 문제이지 제 3자는 논외입니다.
만일 소스코드 비공개를 고집하려면 정식으로 라이센스 받는 길이 있습니다. 알아보세요.
저작권자와 협상만
저작권자와 협상만 잘 되면 저작권자가 본인의 소스코드에 대해서는 자유롭게 다른 조건을 부여할 수 있으므로 GPL이 아닌 다른 조건을 부여받을 수도 있습니다.
그러나 Linux Kernel과 같이 저작권자가 많기 때문에 모든이에게 동의를 얻는 것이 현실적으로 불가능한 경우가 대부분이므로 확률이 낮습니다. 더군다나 유명하고 많이 사용되는 SW일수록 더하겠지요.
먼저 이 견해가 회사
먼저 이 견해가 회사 전체 차원의 입장이라고 생각해도 되겠습니까?
"이와 같은 GPL의 준수에 관하여 중소기업에 대한 준수도 중요하겠으나 산업 전반에 더 큰 영향력을 갖고 있는 대기업 부터 솔선 수범하는 모습을 보이는 것이 맞다고 하겠습니다. 남이하면 불륜이고 내가하면 로맨, 즉 대기업은 영업 비밀이라는 것으로 보호 받고 중소기업은 GPL 위반이다라는 식으로 진행되어서는 곤란하다고 생각됩니다."
"GPL 라이센스 위반에 대한 정당화" 문제와 "대기업과 중소기업의 형평성" 문제는 전혀 관련이 없으므로 구분되어서 논의 되어야 합니다. 대기업이 GPL을 위반하고 있다는 사실은 귀사의 GPL 위반을 정당화 해 줄 수 있는 어떤 논리적 연결 고리도 없습니다. 글쓴 분의 주장은 대기업보다 중소기업이 여건이 어려우니 중소기업에 대해서 좀 더 관대한 처분을 원한다는 감정적 호소에 불과합니다. 그렇다고 대기업의 GPL 위반에 문제가 없다는 것은 결코 아닙니다. 어느 쪽이든 GPL을 위반했다면 그에 대해서 문제제기를 할 수 있습니다. 다만 어느 쪽에 문제를 제시할 것인가의 문제는 문제를 제기하는 사람의 성향에 달려 있을 뿐이고, GPL 위반 자체와는 아무 관련이 없습니다.
또한 대기업이 솔선 수범해야 할 이유도 없습니다. 다시 한 번 말씀드리지만 대기업이 GPL을 위반하는 것을 방치하자는 것이 아닙니다. 애시당초 대기업과 중소기업을 구분할 필요가 없습니다. 더 극단적으로 법무팀이 상대적으로 약할 것 같은 중소기업의 문제 부터 제기하는 것이 GPL을 옹호하고자 하는 사람에게는 더 나은 전략일 수도 있습니다. "어떻게 이렇게 조그만 회사한테 비정하게 그럴 수 있느냐?"는 문제는 솔직히 말씀드리면 제3자인 소비자의 입장에서는 고려 대상이 아닐 수도 있습니다.
제 생각에는 계속해서 GPL을 준수 하지 않을 생각이시라면, 자기 정당화를 하실 것이 아니라 무대응으로 일관하는 것이 상책이라고 봅니다. 이런 식의 비논리적인 자기 정당화는 이곳이 오픈소스 커뮤니티임을 감안할 때 반감을 살 뿐입니다. 어쩌면 이미 GPL을 준수하지 않는 대표적인 기업으로 낙인 찍혔을 수도 있습니다. 저만 해도 만약 GPL 위반에 대한 문제의 예를 들 때, IPTime 이야기부터 시작할 것 같습니다.
그리고 GPL을 피해서 임베디드 산업이 불가능 하다면, 1) 피하지 마시든지 2) 임베디드 사업을 시작하지 말았든지 해야 합니다. GPL에 종속된 코드를 사용해야 하는 산업에서 "GPL에 의한 공개 의무에 따른 비용"은 당연히 사업 계획에 들어가야 합니다. 만약 어물쩡 공개 안해도 될 것이다라고 생각하고 그 비용을 산정하지 않았다면, 사업 계획이 잘못된 것입니다. GPL을 지키면 사업을 할 수 없다는 논리가 통할 것 같으면, 상용 엔진 혹은 상용 라이브러리를 공짜로 사용하지 않으면 사업을 할 수 없으므로 무료로 사용할 수 있어야 한다는 논리도 통해야 되고, 오염물 산출이나 특허권 등등도 어겨도 된다는 논리도 통해야 합니다. GPL은 어떤 의미에서는 상용 라이센스보다도 가혹한 내용을 가진 사용권 "계약"입니다. 왜 돈으로 매개되는 계약은 그렇게 중요하게 여기면서, 돈과 관련되지 않은 계약은 적당히 어겨도 어물쩡 넘어간다고 생각하는지 이해할 수가 없습니다.
그 알고 계신다는
그 알고 계신다는 대기업의 사례를 저작권자나 GNU korea에 알려 주시는 건 어떨까요? 대기업이 아니라 대기업 할아버지가 와도 명백한 위반이라면 보호 못 받습니다.
GPL에 해당되면 그 내용을 준수해야 하는 겁니다. "이거 공개하면 곤란한데"나 "나만 잘못한 것도 아닌데 왜 나만 갖고 그러냐"는 이야기는 논란할 필요가 없습니다.
----
익명이나 오래전 글에 리플은 무조건 -1
흠 아직도 "영업비밀"
흠 아직도 "영업비밀" 에 대한 시선의 차이가 존재하는 것 같습니다.
하이온넷 판례에서 "영업비밀"을 인정한 것으로 종료가 된 것인가요?
개인적으로 하이온넷
개인적으로 하이온넷 사건에서 법원의 판결은 아주 적절했다고 생각합니다.
GPL 코드의 derivative work라고 해서 곧바로 다시 GPL이 적용되지는 않습니다.
수정해서 배포하는 사람이 다시 GPL 하에 프로그램을 배포하면 그 순간부터 다시 GPL의
적용을 받게 됩니다. GPL 원문을 다 읽어 볼 필요도 없이, 해당하는 각 단락의 첫 부분만
보아도 모든 문장이 다 “You must”로 시작하는 것을 확인할 수 있습니다.
GPL에서 강제하는 것은 “만약 코드를 수정해서 배포할 때 다시 GPL 하에 배포하지 않으면
라이선스 위반이므로 해당 소프트웨어를 사용할 권리가 없다”는 것입니다. 따라서
하이온넷에서 불법적으로 GPL 코드를 사용했다고 주장할 수는 있지만,“수정한 코드가
GPL이므로 영업비밀이 될 수 없다”는 주장은 처음부터 설득력이 없었습니다.
"만약 코드를
"만약 코드를 수정해서 배포할 때 다시 GPL 하에 배포하지 않으면 라이선스 위반이므로 해당 소프트웨어를 사용할 권리가 없다"
이미 라이센스 위반으로 해당 소프트웨어를 사용할 권리가 없는데 수정한 코드가 영업비밀인지 아닌지를 따지는것 자체가 의미가 없다고 생각합니다.
======================
BLOG : http://superkkt.com
======================
BLOG : http://superkkt.com
문제는 원 저작자가
문제는 원 저작자가 소송을 걸기 전에는 GPL에 아무런 구속력이 없다는 점입니다. 따라서
“하이온넷이 배포한 코드는 영업비밀이 아니다” 라는 판결을 받기 위해서는 하이온넷 측에서
이미 스스로 소스를 공개했거나, 아니면 원 저작자가 소송을 걸어서 “하이온넷의 이러이러한
코드는 GPL 위반이므로 코드를 공개하라”는 법원의 명령을 받아내는게 선행되어야 합니다.
그 전까지는 법원에서 소스를 영업비밀로 인정하는게 당연합니다.
물론, 저 역시 GPL 위반 코드를 영업비밀로 인정하는 것이 싫습니다. 그렇지만 논리적으로는
법원의 판결이 정확했다고 생각합니다.
문제는 원 저작자가
흠. 이건 문제가 제기되었을 때의 문제가 아닌가요? GPL 라이센스에 따르면, 행동을 취할 것을 조건으로 사용허가를 내주는 것이라 이해를 하는데요.
소송은 위반에 대한 잘잘못을 가리기 위한 행위이지, 구속력이 없다는 관점은 저로서는 이해가 안됩니다. 아니면 제가 잘못알고 있는 것이든지요 ^^;
쉽게 표현하면
쉽게 표현하면 '친고죄' 형태인 것입니다. 사용허가(license)의 주체는 저작권자(copyright holder)이고, 허가받은 사람(licensee)이 사용조건인 의무조항을 위반할 시 이에 대한 법적 제제를 요청할 수 있는 것도 저작권자입니다. GPL은 사용자가 어떤 단계를 거쳐서 프로그램을 받게 되었든지 배포자가 아닌 원저작권자(original licensor)에게서 직접 사용허가를 받기 때문에 사용상의 권리는 항상 보장됩니다. 다만 사용자가 배포자에게 의무조항 준수를 직접 강제할 수는 없습니다.
추가: 예전에 불법복제와 관련되서 친고죄 폐지에 관한 법개정안을 마련한다는 기사를 본적이 있는데 이것하고 상관이 있는지, 현재 법개정과 관련된 결과가 어떻게 되었는지 궁금하네요. 혹시 아시는 분?;;
권리를 위임받은
권리를 위임받은 FSF가 개입했을 때, 엘림넷측은 코드를 소송이 끝난 후에 공개하기로 합의했습니다. 즉 피고측 원고측 모두 GPL이 가진 구속력을 인정한 상태였습니다.
그런데 법원의 판결문을 읽어보면 영업비밀 문제는 GPL이 인정되냐 마냐와는 별개의 문제인 것처럼 표현해 놓았습니다. alee님 말씀처럼 GPL의 구속을 아직 안 받은 상태라서 그런 판결을 내린 게 아니었습니다.
----
익명이나 오래전 글에 리플은 무조건 -1
만일 FSF와 양측간의
만일 FSF와 양측간의 합의가 아닌 GPL 위반에 관한 FSF의 정식 소송이 이루어졌다면 영업 비밀의 인정 여부에 관한 실질적인 판결도 나왔을 것 같습니다만, 합의를 해버림으로써 법적으로는 합의 내용만 준수하면 되는 상황이 되버렸던게 아닌가 생각합니다. 합의사항 중에 영업 비밀이 아니라는 것을 인정하는 내용은 포함되지 않았던 거구요. 판결문에서 GPL 규칙 자체가 그 사건에 법적 구속력이 없다고 한 것은 alee님이 얘기하신대로 저작권자의 고소에 따른 공소제기가 이루어지지 않았으므로 타당한 얘기라고 봅니다.
이후 이루어진 저작권 침해금지 가처분 결정에 관한 판결은 이미 공개가 이루어져 비공지성을 상실하였음을 지적한 것이고 GPL과 직접적인 상관은 없는 것 같습니다.
GPL 소프트웨어가 영업비밀이 될 수 없다는 근거는 GPL 위반에 관한 소송이 이루어지고 그 판결의 결과가 과거의 영업비밀로 간주되던 사실을 무효화 한다는 판례가 나오면 확실해지리라 생각합니다.
하이온넷 판결이
하이온넷 판결이 gpl의 의무사항을 한국에서 지키지 아니하여도 된다는 것으로 해석될 수는 없습니다. 저도 궁금했기 때문에... 관련해서 현직 판사분과 이야기를 한 적이 있는데 그 판결은 영업비밀에 대한 판결이지 저작권에 대한 판결이 아니기 때문에 gpl이 규정하고 있는 의무사항은 유효하고, 준수하여야 한다고 들었습니다.
네, 제가 지적하고
네, 제가 지적하고 싶은 것이 바로 그것이었습니다. 위 소송과정에 GPL 위반에 관한 내용은 들어있지 않다는 거 말이죠. GPL과 영업비밀과의 관계가 드러나려면 GPL 위반에 관한 저작권 소송이 이루어져야하고 그 판결의 결과가 영업비밀의 효력을 결정하는 판례가 생겨야 한다는 말이었습니다.
저작권 소송은
저작권 소송은 고소자의 저작권을 피고소자가 침해한 사실에 대해 소송하는 것입니다. 저작권 분쟁해결 과정에서 제3자와의 관계에서 영업 비밀 여부의 판정을 할 수도 없고 합의할 수도 없습니다. 오로지 저작권 계약(라이센스)에서 강제하고 있는 사항을 이행하거나, 피해를 배상하는 것 뿐이죠. 말씀처럼 "영업비밀이 아닌 것을 인정"하는 일은 FSF가 제아무리 수백번 직접 저작권 소송을 하더라도 얻어낼 수 없습니다.
"법적 구속력이 없다"라고 한 건 영업비밀 여부는 (웃기게도) GPL의 강제사항과 independent하다라는 얘기인 것 같은데요.
----
익명이나 오래전 글에 리플은 무조건 -1
저작권 분쟁 소송
저작권 분쟁 소송 과정에 영업비밀 여부가 판정난다거나 합의한다는 얘기는 한적이 없습니다.(첫 댓글에서 내용을 붙여서 쓰는 바람에 오해의 소지가 있긴 합니다만...) 영업비밀이 아님을 인정한다는 얘기도 위 하이온넷 소송과정중에 FSF와의 합의 사항에 그런 내용이 포함되지 않았다는 사실을 지적한 것 뿐이지 저작권 분쟁 소송과 관련지어 얘기한 적이 없습니다. 제가 쓴 글의 의미가 잘못 전달된 듯 합니다.
(같은 말 계속 하게 됩니다만,) 법적 구속력이 없다고 한 것은 (제가 이해하기로는) 단지 GPL에 그렇게 적혀 있다고 자동으로 법적 구속력이 생기지 않는다는 얘기입니다. 아래에 인용한 korea.gnu.org에서 읽은 판결문 내용에는 '이 사건에 있어서' 법적 구속력이 없다고 한정지어 얘기하고 있을 따름입니다.
제가 하고 싶은 얘기는, 설명을 위해 상황을 억지로 만들어 가정해 보면, 프로그램이 유출되기 직전에 저작권자가 소송을 걸어서 GPL 위반에 관한 시정 명령이 나버렸다면 (어떠 이유에서인지) 업체에서 그 소스코드를 공개 하지 않았더라도(즉, 비공지성이 상실되지 않았더라도) 유출된 프로그램의 소스코드가 영업비밀이 아닐 수 있지 않느냐는 겁니다. 즉, GPL 위반에 관한 시정 명령에 의해 그 대상이 된 프로그램의 소스코드의 법적인 성격이 바뀌게 된다는 겁니다. 저작권 소송의 판결로 인해 이제 GPL의 의무조항이 법적 구속력을 가지게 된다는 말이었습니다. 이해 하셨습니까?
또 같은 얘긴데요.
또 같은 얘긴데요. FSF와의 엘림넷의 합의 사항이 바로 저작권 분쟁에 대한 합의입니다. 이 사안에서 FSF가 직접 당사자가 될 수 있는 일이 저작권 분쟁밖에 없습니다. 그리고 그 이루어진 합의 사항에서 영업비밀 인정 따위같은 내용은 애초에 포함될 수가 없습니다.
예를 드신 것처럼, 저작권자의 소송과 판결이 "영업비밀침해" 사전에 이루어진 경우는 또 다른 얘기구요.
"'이 사건과 무관한' 이유가 무엇이었을까?"를 저와 다르게 생각하시는 것 같은데요. 저는 재판부가 그야말로 라이센스는 무관하다, 별개의 문제라고 생각해서 그랬다고 생각합니다. 상식적으로 합의를 통해 공개하기로 했다면, 비밀이 아닌 게 맞지 않습니까? 그래도 그런 식의 판결을 한 걸 보면, 엘림넷/하이온넷 사건의 경우 FSF와 엘림넷 사이에 어떤 종류의 소송이나 합의를 했다고 하더라도 재판부의 판결이 달라졌을 것 같지 않습니다.
----
익명이나 오래전 글에 리플은 무조건 -1
합의 사항에
합의 사항에 영업비밀이 아니라는 것일 인정하는 내용이 포함될 수 있느냐 없느냐는 여부는 제가 판단하지 못하겠습니다. 제가 그 말을 적은 이유는 단지 합의 사항이 재판에 영향을 끼치지 않았음을 지적하기 위해 적었던 것입니다. 영업비밀이 아니었다라는 사실을 인정하는 내용이 (합의 내용에 포함 가능하여) 실제로 포함됬었다고 가정하면 재판에 영향을 끼쳤으리라 생각했기 때문입니다. 합의 내용을 설명하는 글에서 영업비밀로 인정하는 판결이 났을 경우 FSF가 취하는 조치에 대해 엘림넷이 감수하겠다는 답변을 받은 것을 보아 적어도 FSF에게 영업비밀 여부는 관심사였던것 같습니다.
저작권 소송 판결이 해당 프로그램 유출 이전에 이루어진 건 엘림넷 하이온넷 소송과는 다른 경우인게 맞습니다. 바로 엘림넷과 하이온넷 소송과 실제로 GPL 위반과 영업비밀의 해석이 관계를 가지는 경우는 다른 경우임을 지적하기 위해 예를 든 것입니다.
네, 맞습니다. cwryu님과 제가 다르게 해석하는 부분은 바로 판결문에서 "GPL 라이센스 규칙이 이 사건에 있어서 어떠한 법적 구속력이 있다 할 수 없다"고 한 이유입니다.
합의를 통해서 공개하기로 한 것하고 위반 사항에 대한 시정 명령에 따라 공개하는 것하고는 그 해석이 달라야 한다고 봅니다. 각각의 경우 공개를 거부했을 때 취해지는 후속 조치를 짐작해보면, 합의 불이행시에는 FSF가 정식 소송을 하게 될테고, 시정 명령 불이행시에는 절차에 따라 법집행이 이루어지리라 생각합니다. 이때 전자는 FSF가 소송에서 이기기 전이니 GPL 라이센스 규칙이 여전히 법적 구속력이 없는 경우이며, 후자의 경우 소송에서 이겨 법적 구속력을 가진 상태라 해당 프로그램의 소스코드에 대한 해석이 각각의 경우 달라질 것이라 기대합니다.
만일 cwryu님이 얘기하신대로 판결문의 의도가 GPL의 의무조항과 영업비밀 유무가 전혀 상관없다는 얘기라면, 제가 예로 들었던 저작권 소송 판결이 이루어져서 시정 명령이 난 이후에 프로그램 유출이 이루어진 경우라도 영업비밀 유출로 해석이 될텐데 전 이것이 상식적으로 옳지 않다고 생각합니다.
이제 의견의 차이가 정리가 된건가요?
제가 이 스레드를 연
제가 이 스레드를 연 까닭은 절대 GPL 위반에 대한 시정을 요구하기 위한 것이 아니었습니다. 사용자와 기업 둘다 납득할만한 방법이 있는지 일반 사용자의 입장에서 알아보고자 함이었습니다. 좀더 많은 이야기가 오고갈 수 있도록 감정적인 대응은 자제해 주시길 부탁드리겠습니다.
소스 공개로 인한
소스 공개로 인한 기술 유출에 대한 부담은 틀림없이 존재하는 것 같군요.
리눅스로 제공된 드라이버를 사용하면 공개를 원하지 않는 코드들도 반드시 GPL의 영향을 받게 되어버리나요? 즉 코드를 따로 분리해낼 수 없는 상황인건지 궁금합니다. 기술적인 배경지식이 부족해서 조금 자세한 설명을 부탁드리겠습니다.
그리고 공개를 원하지 않는 부분이 어느 정도 인지도 궁금합니다. 저수준의 드라이버 레벨인지, 제어 및 자료처리하는 알고리즘 영역인지, 사용자 UI(편의성) 부분도 포함되는지, 아니면 오픈소스의 적용은 전혀 고려하고 있지 않으며 가능하다면 독점 소프트웨어 형태의 펌웨어를 원하시는지....
배포시 따라오는
배포시 따라오는 GPL의 의무 조항을 준수하고 있는 업체는 찾아보기가 힘든 현실입니다.GPL의 의무조항을 준수하고 있는지 아닌지 판단하는 기준이 무엇인가요?
대부분 준수한다고 얘기하고 싶은게 아닙니다. 단지 의무 조항이란게
불특정 다수에게 또는 인증된 사용자에게 "웹" 혹은 인터넷의 어떤형태로 소스가 공개되어야한다고 생각하시는 분이 있을까 해서
하는 말입니다.
GPL은 소스 공개의 형태에 제약을 가하지 않고 있지않나요?
중요한건 배포시...즉 이경우엔
...제품 배포행위를 받게되는..구매자겠죠..
구매자에게만 소스 공개의 의무를 가지고 있다는 얘기이지..
그 의무의 형태가 비 구매자에게도 즉..불특정다수에게 인터넷으로 공개되어야한다던지..그런조항은
어디에도 없는거 같은데..
그래서..의무조항을 준수하고 있는지 없는지...알수 있는 방법은..
한업체의 배포를 받는 사람이 되어서.....
즉..제품을 구입한후..
소스를 보고싶다고 일일이 물어봐야지만 해당업체가 소스공개의 의무를 실천하라고( 그 구매자에게 )
확인해봐야 알 수 있는거 아닙니까?
소스코드와 관련하여
소스코드와 관련하여 다음과 같은 조항이 있습니다.
상용으로 판매된 제품이니 적어도 b)에 규정된 문서는 포함되어 있어야 하는 것이죠. 사용자가 소스코드를 구할 수 있다는 사실조차 모른다면 이야기가 안되지 않습니까?
나름 업계에 근무중인데요..
나름 업계에 근무중인데요. 사실 참 어려운 문제입니다. 저 역시 GPL 라이센스 소스를 사용하고 있습니다.
그런데 GPL 라이센스 사용된 프로그램들이 존재하긴 하는데 최대한 제품의 CORE쪽에는 가지 않도록 노력
중입니다. 개발시 전혀 사용은 않할수는 없지만 최대한 GPL에 저촉 않받는 방향으로 갈려고 노력하는데
쉽지만은 않은거 같습니다. 물론 저는 GPL에 대한 인지를 충분히 하고 있고 회사를 충분히 키울려고 노력
중이라서 지금부터 준비중입니다. 그래서 CORE 부분은 되도록 GPL 해당되는 소스를 보고 전혀 다른 방향
으로 제작해왔습니다.
그런데 일반적으로 업계 장비들을 보면 거의 100% GPL 위반되는 장비라고 해도 과언이 아닐겁니다. UI정도나
자체적으로 개발하지 내부를 보면 100% 라고 보시는게 맞습니다. 다만 그것이 동작하는데 있어서 업체마다
조금 다른 방향으로 가기 때문에 수정을 가하게 됩니다. 바로 이부분입니다. 그 수정이라는것이 업체에서는
영업비밀로 생각하고 공개를 꺼려하는 부분입니다. 지금은 대부분 업체들이 고만 고만 하니깐 GPL위반에 대해
그리 큰 문제를 제기하지 않지만 해외로 진출하기 위해서는 GPL 라이센스 부분이 반드시 선행되어져야 될것
입니다. 쉽지 않은 문제일겁니다.
저 역시 처음 개발이후에 GPL 들어내고 새로 개발한다고 한게 약 40% 정도밖에 되지는 않습니다. 다행히 CORE
부분을 들어내서 안심하는 뭐 그정도입니다. 지금은 SNORT를 들어냈는데 거의 세달가량 걸린거 같습니다. 제 자신이
개발 책임자라서 어느정도 시간이 지나면 일정 부분은 GPL로 풀 생각도 하고 있습니다. SNORT같은 경우는
당장 가져다 쓰기는 좋았어도 이것을 이용해 무엇인가 하기에는 너무 큰 문제가 있어서 아예 처음 몇번 돌려보고는
들어내는걸로 결정한 케이스였습니다. 오히려 이부분은 GPL보다는 성능에 기인했던거 같습니다.
사실 그렇게 해도
사실 그렇게 해도 라이센스 위반 될 수 있습니다. 즉,
> 그래서 CORE 부분은 되도록 GPL 해당되는 소스를 보고 전혀 다른 방향
으로 제작해왔습니다.
이미 보고 수정한 것이 되기 때문입니다.
그것을 피하기 위해서 예전에 미국에서는 두사람이 작업 하는데, 한사람은 구현물을 보고 추상화된 스펙을 작성하고, 다른 한사람은 스펙만 보고 다시 구현했었다고 하더군요.
..
난독증이신가 봅니다.
이미 보고 수정한 것이 되기 때문입니다. <--- 수정이 아니라 전혀 다른 방향으로 제작한다니깐요.
질문드립니다. :-)
라이센스는 역시 어렵군요~ :-)
모두들 익숙하지 않겠지만, 혼자 고민하는것 보다 같이 고민하는게 좋을것 같습니다.
저는 리눅스네이트온을 개발하고 있는데요.
라이센스 문제로 고민을 하고 있습니다.
GPL로 하면 좋겠지만, 소스공개는 괜찮다고 생각하는데 네이트온과같은 서비스는
서버를 사용합니다. 정상적인 사용으로 서버가 괜찮으면 상관없지만,
서버를 공격적으로 하는행위에대한 것은 GPL에서는 언급이 없으니까요.
예를들어 네이트온 P2P서버를 사용해서 파일전송 프로그램을 만든다던지...
또한, 공개된 소스를 이용해서 사업에 영향을 끼치는 행위에대한 조항도 없습니다.
생각은 잘안나지만, 사업에 영향을 끼쳐서는 안될것 같습니다.
회사차원에서 보호되어야 할 부분이 분명 있을것 같다고 생각하는데요.
듀얼라이센스도 그렇고, 혹시 이런문제 고민해 보신분 계신가요?
---
Jabber: lum0320@jabber.org
Lum7671's Weblog
네이트온에서
네이트온에서 핵심적으로 보호해야 할 자산이 무엇인가요? 클라이언트와 서버의 통신 프로토콜인가요? 아니면 그 프로토콜을 통해서 서버가 남용되는 것을 막는 것이 더 우선인가요?
후자요~
서버 남용을 방지하는거지요~
프로토콜은 이미 비공식적으로 공개되었고...
남용의 정도차이가 있겠지만,
우려하는것은 네이트온 서버 마비 등과 같은거지요.
사실, 비공식적인 프로토콜 공개로 서버 남용과 공격에 노출되있기는 하지만,
공식적으로 오픈소스로 하는것이니만큼 대책없이 GPL로 할 수는 없을것 같다는 생각입니다.
공격적인 프로그램을 만들어 공격을하면,
라이센스 문제가 아니고 사업적 법적 대응이 될 수도 있겠지만,
라이센스를 느슨하게 가도 될지도 모르겠습니다.
우선 생각되는것이 처음 시도이고 하니,
개인적으로는 회사에 유리하게 가고 차츰 변경해 가는게 안전하지 않나? 생각하고 있습니다.
---
Jabber: lum0320@jabber.org
Lum7671's Weblog
어차피 프로토콜이
어차피 프로토콜이 비공식적으로 공개되어 있다고 한다면... 클라이언트가 GPL이라고 해서 서버가 더 남용될 것이라고는 생각되지 않는데요?
서버의 남용 여부와 관련된 의사결정은... 클라이언트 소스의 라이센스와 상관 없이 클라이언트 소스를 공개해서 누구나 보고 비슷한 클라이언트를 만들 수 있도록 할 것이냐, 아니면 클라이언트 소스를 공개하지 않음으로서 비슷한 클라이언트가 제작되기 어렵게 만들 것이냐 둘 중 하나가 아닐까요?
클라이언트를 오픈소스로 한다는 것은 결국 누구나 클라이언트의 소스를 보고 수정/재배포하는 것을 허용한다는 뜻이기 때문에 서버 남용 여부와는 상관이 없을 것입니다.
:-)
사실 저는 개발만하고, 다른파트에서 법무팀과 라이센스관련일을 하고 있습니다.
저는 잘 모르지만 조언을 해주고 있고요.
어떻게 생각해보면, 이번에 공개된 리눅스네이트온의 라이센스를
아무렇게나 해도 별반 차이가 없을것 같다는 생각도 들기도 합니다.
어차피 비공식적으로 공개된것이 있는데.. 굳이 라이센스를 넣어도
작성된 코드가 어디서 가지고 온것인지 판단하기 어려울 수 있기 때문입니다.
"너꺼는 안봤다" "리버스엔지니어링해서 내가 만든거다"
하면 라이센스의 의미가 없어지는것 같네요.
그래도 생각되는것이,
프로그램만 사용되는것이 아니라, 서버를 같이 사용하는 메신저와 같은
서비스는 정말 오픈소스 라이센스에서 제한( 건전(?) 하게만 사용해라~ )될 필요가 없는지 알고 싶네요.
음... 법적대응은 ,서버다운시킨 사람을 잡아서 법적대응을 하는것, 회사로써 할일이 아니라고 봅니다.
우선 문제는 서버가 다운되는거고, 서비스에 지장이 생기고, 고객 신뢰와 매출에 영향이 있으니까요.
최선의 방어책으로 라이센스도 그것의 한 종류가 아닐까? 생각합니다. 알리는 역활을 할 수 있으니까요.
( 서버를 잘 만들어라고 할수는 없겠죠? ^^; )
답변 감사드립니다~ :-)
---
Jabber: lum0320@jabber.org
Lum7671's Weblog
맞습니다. 서버 남용
맞습니다. 서버 남용 부분은 라이센스와는 상관이 없을 것이고요.
그렇다면 회사 입장에선 네이트온 서비스의 사용자가 최대한 많이 늘어나는 것을 원할 것이니 그 측면에서 살펴보면 라이센스를 무엇으로 선택하느냐에 따라서 조금씩 달라집니다.
예를 들어 전체 코드를 GPL로 할 경우에는 해당 코드의 파생물도 모두 GPL이 되기 때문에 해당 코드를 차용해서 다른 라이센스로 (예: proprietary) 가지고 갈 수가 없겠지요. 그러나 다른 GPL 소프트웨어에는 차용이 가능하기 때문에 Gaim(현 Pidgin) 코드에 네이트온 GPL 클라이언트의 코드를 가지고 와서 섞는 것이 가능하므로 Gaim에 네이트온 지원이 좀더 쉽게 될 수도 있을 것이고요. 클라이언트 부분은 GPL로 하고 프로토콜 부분은 LGPL로 하게 되면 해당 프로토콜을 사용한 proprietary SW가 좀더 많이 생길 수 있다고 기대할 수도 있겠지요. 만약 전체를 MPL로 하게 되면 GPL 소프트웨어에 MPL 코드를 차용할 수 없으므로 Gaim에 이 코드를 그대로 copy/paste할 수가 없으니 Gaim 개발자들은 네이트온을 지원하려면 새로 개발해야 할 것이고요.... 어느 라이센스를 채택하느냐에 따라서 상당히 많은 변수들이 있습니다.
그것들을 잘 검토해서 회사에 최대한의 이익을 가져다 주는 방향으로 선택하는 것이 좋겠지요. 전략적인 관점에서 검토하기 위해서는 고려해야 할 사항들이 몇 가지 있을텐데 게시판에 주저리주저리 쓰기에는 적절하지 않네요. 일단 이 정도만~~
약간 뱀다리이긴
약간 뱀다리이긴 하지만 참고하세요. http://nateon.haz3.com/forum/ 기본적으로 동작을 하긴 하는 것 같은데, 제 시스템에선 가끔가다 pidgin이 죽게 하네요.
이미 비공식적으로
아이고.. 댓글을 엉뚱한 곳에 달았네요. 위에서 얘기중인 네이트온 리눅스 버전에 대한 댓글입니다~
이미 비공식적으로 프로토콜이 공개가 되어있기 때문에 지금이라도 그런 악의적인 사용자가 나올 가능성은 충분하겠죠. 물론 지금 개발하시는 프로그램이 공개되어서 잘 정리된 소스코드를 볼 수 있으면 그 가능성이 더 커질 문제는 있겠고요. 하지만 라이센스에서 좋은 용도로만 사용(?)하라는 내용이 있다고해서 그게 도움이 될까요? 어차피 공격하기로 마음 먹었으면 라이센스고 나발이고 신경 안쓸것 같은데요..^^
======================
BLOG : http://superkkt.com
======================
BLOG : http://superkkt.com
좋은 용도(?)라고
좋은 용도(?)라고 하는 것을 어떻게 정의하나요? 그것은 현실적으로 의미가 없는 요구사항이지요~ 그리고 오픈소스는 그 결과물이 어디에 쓰이든 그 용도를 제한하지 않습니다.
이 문제를 예전부터 고민했었습니다
제가 현재 회사에서 만든 시리즈는 리눅스 커널을 사용하고, gpl 소스 가져다가
개발했습니다. 소스수정은 없었습니다. 또 그때는 라이선스를 잘 몰랐죠.
그런데 개발하면서 알게되었고 첫번째 시리즈는 공개없이 판매되었습니다.
누구하나 달라는 사람도 없고, 이의를 제기하는 사람도 없었지요.
솔직히 얘기하면 공개하기조차 뭐하기도 했습니다. 이미 다른 곳에 있는것 가져다가
컴파일만 해서 돌리는 것들... 단 소스보면서 디버깅하니 개발하기 좋죠.
결과적으로 기술적으로 공개하기는 무척 부끄러운 수준이었습니다.
현재에 이르러...
공개를 준비하면서 개발단계부터 준비를 하고 있습니다.
커널, 디바이스 드라이버, 툴체인, 사용된 각종유틸리티들... 수정한 코드들...
단지 저희가 직접 제작하는 UI 와 기능제어 부분에 대해서는 어플리케이션과 라이브러리 부분으로
명확히 나누고, 라이브러리에는 gpl 코드와는 전혀 관계가 없는 부분들로 구성합니다.
어플리케이션도 기능별로 별도의 프로세스로 나뉘어져 구동되고 독립적으로 기능을 하게 합니다.
UI 에서 사용되는 그래픽 라이브러리는 임베디드에서 사용하는 nano-X 와 서버-클라이언트 형식으로
동작하므로 서버쪽 프로그램은 GPL 이니 소스를 공개하고 클라이언트쪽은 공개할 필요가 없게 됩니다.
아직 공개는 이루어지지 않고 있습니다만, 정식으로 판매될때는 모든 코드가 오픈될것입니다.
이렇게 진행을 하면서 어려웠던 부분은 대부분의 하드웨어 칩제조 회사들...
특히 임베디드되어 특정목적에서만 동작하도록 된 칩들을 판매하는 회사들의 경우 리눅스를 지원을 합니다
그런데 샘플칩을 받고 SDK 형태의 자료를 받으려면 몇천만원씩 들어갑니다.
드라이버는 커널에서 GPL이 아니면 링크가 되지 않는 함수들을 사용하면서도 공개는 불가하다고 합니다
그런데 그것을 지키지 않으면 판매가 불가능하겠죠?
사고 나서 공개해 버린다면 유니크한 판매라인을 갖고 있는 칩을 더이상 구매할수가 없습니다.
안팔거든요. 당연히 거기에 묶이게 됩니다.
그런 회사들이 생각외로 많습니다.
또 하나...
커널 포팅하고, 드라이버 제작했습니다.
공개하기 힘들었을때는 도둑고양이 마냥 훔쳐쓰는 감정이었습니다.
기술적으로 자신이 없었기 때문이죠.
누구나 할수 있는거 조금 삽질해서 만들었는데 보고 금방 만들면 어쩌나...
지금에 와서는 내가 만든 제품 그정도 코드 오픈해도 어차피 못따라와... 라는 생각을 합니다.
할놈은 어차피 안보고도 삽좀 푸면 할것이고, 못할놈은 보고도 못할것이기 때문입니다.
어차피 내가 먼저 만들었으니 팔면 그만이죠.
그리고 개발자분들 많으시니까 아시겠지만 남의 코드 분석해서 흉내내느니 새로 개발합니다.
저도 인터넷으로 수많은 국내외 사이트의 소스코드 다운받았습니다만...
실제로 본거 거의 없고, 개발에 도움이 된거... 글쎄요?
제품 초기부터 오픈한다는 생각을 가지고 준비하시면 어렵지 않을것 같습니다.
국내에도 수많은 임베디드 개발자들이 있습니다...
이번 계기로 인식도 바꾸고, 자신이 도움을 받은 만큼 다른사람에도 도움이 되는 그런 계기가 되었으면 합니다.
참고로... iptime 관계자분께.
억울해 하지 마십시요. 다치면 대기업이 더 크게 다칩니다.
이번 기회가 iptime 입장에서는 국내외적으로 임베디드/오픈소스 분야에서 레퍼런스가 될수도 있습니다.
회사 이름을 국내외적으로 알릴수도 있는 계기가 될수 있다는 겁니다.
먼저 매를 맞으시는게 억울하다면 저희 회사가 그런 매좀 맞아보고 싶습니다.
위기를 기회로 바꾸세요
iptime 연구소분들이 이 글타래로 오셔서 토론하시면 좋겠습니다만
회사에서 개별적인 대응은 못하게 하겠지요?
너는 누구냐?
오래 전에
오래 전에 이야기했던 일부 삼성 노트북의 AVStation NOW도 나중에 더 알고 보니, 해당 기능이 탑재된 기종의 사용설명서 맨 뒤에 소스코드를 다운받을 수 있는 사이트를 써 놨습니다. 가 보니깐 리눅스 커널 2.4와 VLC의 수정된 버전을 사용했더군요. 지금은 그 URL을 까먹었습니다.
지금의 AVStation NOW는 Windows XP Embedded를 쓴다는 소문이 사실인지, 그 소스코드 다운로드 안내에 관한 종이가 안 딸려 나오는 것 같습니다.
---- 절취선 ----
http://blog.peremen.name