Linux Kernel과 제품 경쟁력의 아이러니

권순선의 이미지

Linux를 가지고 제품을 개발할 경우 제품의 경쟁력을 확보하고 경쟁사 제품과의 차별성을 가져가기 위해서 새로운 기능을 추가하거나 기존 기능을 향상시키기 위해 소스를 수정하는 것이 필수적입니다. 그런데 문제는 Linux Kernel이 GPL이다 보니 경쟁사가 해당 제품을 구입하고 제품에 적용된 Linux Kernel의 소스코드를 요구할 경우 GPL에 의거하여 제조사는 소스코드를 제공할 의무가 발생한다는 것입니다. 물론 제조사는 그 소스코드가 경쟁사에 넘어가는 것은 원하지 않겠지요.

다행히도(?) Linux Kernel에서는 Module Interface가 있어 공개하고 싶지 않은 기능을 Kernel Module로 개발하는 것이 '일반적인' 관례인데 Kernel Module의 라이센스가 GPL이어야만 하는지, GPL이 아니어도 되는지에 대해서 명확한 결정이 내려져 있지 않은 상황이라 애매한 경우가 많이 발생합니다.

그리고 특히 Embedded 제품에서는 Kernel Module로 빼낼 경우 성능이나 응답성이 나빠지는 경우가 발생할 수 있기 때문에 Kernel Module을 사용하지 않기를 원하는 경우가 대부분입니다.

Linux가 적용된 제품을 개발할 때 Linux Kernel의 소프트웨어 경쟁력과 차별화 요소는 어떻게 확보할 수 있을까요? Linux가 좀더 많은 제품에 널리 사용되기 위해서는 해당 제품의 차별성/경쟁력을 확보할 수 있어야만 사업이 이루어집니다. 혹 이런 사항에 대해서 고민해 보신 분 계신가요?

댓글

1day1의 이미지

GPL 코드를 공개 시점을 시간차를 두고 할 수는 없는 것인가요?
ver1.0 을 ver2.0 출시 시점에서 공개한다거나 하는 것처럼요. (아니면 ver1.0 출시이후 6개월후에,1년후에 같은 방식이나..)

F/OSS 가 함께하길.. (F/OSS서포터즈,F/OSS서포터즈그룹)

F/OSS 가 함께하길..

sangwoo의 이미지

배포하는 시점에서 GPL의 효력이 발생하기 때문에, 최소한 제품을 내놓고, 누군가가 그 제품을 구입한 다음부터는 공개가 이루어져야 한다고 봅니다.

----
Let's shut up and code.

----
Let's shut up and code.

sangwoo의 이미지

Linux 커널은 이런 문제점(?)이 있기 때문에, 많은 임베디드 회사에서 GPL이 아닌 공개 운영체제의 커널을 쓰는 거죠. 많은 회사는 아닐지도 모르겠네요. :-)
그게 아니면 Linksys 처럼 펌웨어를 공개하는 수 밖에는 별 방법이 없지 않나요?

----
Let's shut up and code.

----
Let's shut up and code.

dalgarak의 이미지

일반 사용자 Application의 측면에서 바라봤을때, 차별성 확보에 대해서는... 얼마전에 gettext를 사용하여 손쉬운 Native Language support를 소프트웨어의 차별성으로 둘 수 있구나- 하는 생각을 한적이 있습니다.
(물론 대단히 미미한 것이긴 하지만, 영업자의 입장으로- 고객에게 지역화를 위해 투자하는 시간과 비용이 줄어든다는 것을 통해 메리트를 느끼게 할 수 있다고 생각합니다.)

논외의 이야기를 잠깐 하자면, 개발자의 입장에서는 무수한 GPL 소프트웨어상에서 상용 프로그램을 개발한다는 것이 막대한 부담감으로 다가오기 쉽상인것 같습니다. 이점도 상당히 많습니다만 :-)

간단한 예를 들자면 Gtk+ 의 GtkTreeView에서 현재 선택된 텍스트 셀을(정확하게는 1 row에 들어가는 여러 Column중의 한 column의 선택을 표시하는 것입니다.) 다른 색상으로 표시하는 코드가 필요할 때, 이를 구현하려면 GtkCellRendererText의 셀 렌더링 담당 함수인 gtk_cell_renderer_text_renderer()및 GtkCellRendererText 클래스의 많은 부분을 Overriding 해줘야 합니다. Gtk+ 자체야 LGPL이므로 몇가지 사용상 주의만 한다면 상용 소프트웨어를 위해 사용할 수 있겠지만, 문제는 새 코드의 구현 방법이나 스타일 등 많은 부분에서 공통된 형식을 가질 수 밖에 없다는 것입니다. 실제로 이러한 셀 렌더러의 재구현은 GtkTreeView를 사용하는 많은 GPL 소프트웨어에서 "이미" 구현되어 있으므로, 이러한 문제는 더 크게 대두될 수도 있다고 생각합니다. 물론 다르게 구현하려고 한다면 깔끔하진 않더라도 현재 선택된 셀 위젯의 배경을 다시 그려주는 방식등이 많겠습니다만, 방법론적인 측면에서 접근은 특별히 언급하지 않겠습니다.

앞에서 언급해서 만들어진 코드를 LGPL 라이센스로 채택하여 공개하는 것으로 해결할 수도 있지만, 이 코드 마저 엄밀히 따지게 되면 GPL을 채택 해야 하는 코드가 되게 될 수도 있는 등 여러모로 애매한 상황에 발을 담그게 될 수도 있다는 생각을 합니다. 회사의 기준에서는 난감한게 많아지겠지요.

상용 Qt 라이브러리로 개발을 한다면 위와 같은 문제는 간단하게 회피할 수 있겠습니다만, 여하간 개발간 라이브러리의 사용에 있어서도 "바퀴를 다시 만들지 않고" 라이센스를 준수하는 올바른 방법으로 접근하려면 무수한 노력이 동반하는 것 같습니다.

wish의 이미지

애시당초 리누스가 리눅스 라이센스로 GPL 을 사용한 것도 자신의 소스 코드를 누군가 상업적인 용도로 사용하는 것이 두려워던 것도 한 원인이라고 합니다. 물론 자서전 보면 그렇게 깊게 생각 안한 것 같지만요 ^^ (리차드 스톨만 강연 들은 게 원인이 아닐까~ 하고 농담 비스무리하게 언급한 부분이 있죠.)

다만 GPL 의 악독함(어떤 의미에서는 그 어떤 사용 라이센스 보다 악독합니다. GPL 로 된 코드는 동적으로만 링크하려고 해도 그 링크한 소프트웨어를 GPL 라이센스 내지는 그 호환 라이센스로 공개해야 되니까요)을 많이 알고 난 이후로도 GPL 을 유지 하고 있다는 점은 어느 정도는 리눅스 소스코드에 대한 권한을 행사하고 싶다는 의지 표현이라고 생각합니다.

즉, 소스코드 자체의 수정은 제한 없이 공개 해달라는 의지 표현이고, 최소한의 타협점이 모듈로 만드는게 아닐까 합니다. 사실 리눅스는 GPL 을 따르기 때문에, 모듈을 공개 안하는 것도 좀 이상하긴 합니다만, 이건 머 리누스도 인정한 부분인 것 같고요.

그래서 저작권이라는 것의 본래 취지가 저작물에 대한 저작자의 의지를 존중한다는 점을 생각해 볼 때, 사업화가 힘들다는 이유로 그 소스 코드를 비공개 하는 것은 무리가 있다고 봅니다. 리눅스 소스 코드 수정을 이용한 차별로 수익을 낼 수 밖에 없는 업체들이 있다고 하더라도, 리누스가 공개적으로 리눅스의 라이센스를 바꾸지 않는 한은 그 기업들은 존립 기반 자체가 없습니다. 그러한 기업들이 자신들의 존립 기반을 가지려면 바꾼 소스 코드를 공개 해도 사업을 진행해 나갈 수 있거나 리눅스의 라이센스 바뀌거나 둘 중 하나라고 생각합니다. 아니라면 그 사업은 접어야겠죠. 저작권자의 의지니까요.

사실 GPL 하에 있는 소스 코드를 사업체의 존립 기반 때문에 비공개 하고 싶다고, 비공개 해 버리면 GPL 은 존재 의의를 상실합니다 ^^ BSD 나 LGPL 과 다를 바가 없어진다고 생각하구요. 사실 저런 기업들 떄문에 BSD 라이센스를 옹호하는 사람이 많은 거고 python 팀 처럼 GPL 에 묶이는 것을 극단적으로 싫어하는 사람들은 항상 있어왔구요 ^^

구구절절 길게 썼는데, 간단히 요약하자면 GPL 의 소스 코드 수정과 비공개로만 수익을 낼 수 있는 기업은 존재가 불가능하다. 만약 존재 가능하다면 GPL 은 의미가 없다. 리눅스가 그러한 기업들에게도 기회를 주고 싶다면 라이센스 자체가 바뀌어야 한다. 정도가 되겠습니다~~

수정 : 문맥이 이상한 부분을 고쳤습니다

cwryu의 이미지

모듈 인터페이스를 사용해서 생기는 performance 손해는 load/unload 부담을 빼면 전혀 없거나 극히 미미한 수준입니다. (micro optimize를 위해 아예 모듈로 사용할 수 없을 정도로 커널의 표준 인터페이스를 모조리 건너뛰도록 만들었다면 또 모르겠습니다.) 엔지니어들이 "모듈이 이렇게 구현되었겠지.."하고 넘겨짚어 생각하는 오해중의 하나일 것 같은데요.

그리고 모듈 인터페이스를 사용했다고 해도 원칙적으로는 GPL입니다. GPL이 아닐 수도 있는 경우는 리눅스 커널과는 별도로 충분히 독립적인 경우.. 논란의 여지가 있지만 GPL 조항에서는 "reasonably considered independent and separate works in themselves"의 문제이지 모듈로 따로 떼 놓는다고 피해갈 수 있는 건 아닙니다. (모든 법률 텍스트에는 애매함이 있습니다.. 애매함이 전혀 없을 수 있다면 판사, 변호사는 필요없고 모든 법률 분쟁을 매뉴얼대로 처리하면 되겠죠.)

제품의 경쟁력이 경쟁사에 대한 장벽을 만들어서 최대한 오래 시장에서 위치를 유지하는 데 있는 것도 사실이지만, 커널에 작업한 내용이 아니더라도 그런 점을 확보할 수 있는 방법은 많고 tradeoff를 고려해도 리눅스를 선택할 만한 장점이 많이 있습니다. 숨길 수 없는 걸 가지고 어떻게 숨기냐고 고민할 필요는 없을 것 같습니다. (고민하려면 "reasonably considered independent"를 고민해 봐야...)

PS. 제 경험으로는 필요없는 비밀주의가 문제더군요. 결정권자들은 공개해야 한다는 말을 들었을 때 일단 앞뒤 안 가리고 꺼림직해 하는 경우가 대부분일 겁니다. 실제 제품의 경쟁력 약화나 기술 유출과는 그다지 상관없고 얻는 이득이 더욱 큼에도 불구하고..

권순선의 이미지

특정한 조건 하에서 insmod/rmmod 시에 오랜 시간이 걸리는 경우도 있고, kernel 부팅 과정에서 module 때문에 설정이 복잡해지는 경우도 있어서(예: initrd) 가능하다면 그냥 vmlinuz 하나만 처리하면 되기를 바라는 경우가 많습니다. performance의 문제만은 아닙니다. vmlinuz따로, module따로 해 주고 신경써 주어야 할 일이 서로 다르다는 것 자체가 이슈인 것이죠.

module의 라이센스에 대해서는 사람들의 의견이 서로 다르고, 무엇보다 이에 대해 법원에서 결정된 명확한 판례가 없기 때문에 잊을만 하면 계속해서 이에 대한 논쟁이 벌어지는 것이겠지요. module의 라이센스에 대해 서로 다른 입장을 취하고 있는 쪽이 모두 나름대로의 논리를 가지고 있기 때문에 이쪽을 'grey area'라고 이야기하는 것입니다.

p.s. 제품의 SW 경쟁력이 OS 차원에서만 결정되는 것은 물론 아닙니다. 제가 이야기하는 것은 어디까지나 linux kernel에서 경쟁력을 확보하고 차별화를 이루는 것에 대한 이야기입니다.

cwryu의 이미지

"모듈이 아니면 GPL이 된다"는 맞는 말입니다 (separate in themselves) 하지만 또 한 가지 GPL을 피해갈 수 있는 요건인 "reasonably independent"라고 볼 수 있느냐는 모듈 여부로 결정되는 게 아닙니다. 해당 모듈이 리눅스와는 별도로 설계되었거나 이미 다른 용도로 구현된 것이고 리눅스가 아니더라도 큰 차이를 보이지 않는다라면 (ati, nvidia, oss) GPL이 아닐 수도 있다라고 인정하는 것 뿐입니다. 토발즈도 원칙적으로는 모듈이 GPL이지만 그러한 greay area가 있다라고 말했을 뿐이죠. 제품 설계단계부터 플랫폼이 결정되고 리눅스 모듈을 작성해 나가기 시작했다면 GPL이라고 볼 수 있을 겁니다.

애매한 게 사실이지만 모듈로 만들면 GPL 피해갈 수 있다라고 말하는 건 잘못입니다. (모듈 인터페이스의 MODULE_LICENSE()나 GPL symbol들은 해당 심볼을 사용한 모듈이 GPL이라는 걸 명확히 하고자 하는 용도이고, 그걸 사용하지 않는다고 아니라고 잘라 말할 수는 없습니다.) 법원에서 판례가 나온다고 해도 그 케이스의 해당 모듈이 얼마나 독립적이냐로 판단될 것이지 다른 모든 모듈의 GPL/non-GPL 여부가 결정되는 판례는 나오지 않을 것입니다.

jedi의 이미지

숨겨야 경쟁력이 생긴다면 GPL를 폐기해야하지 않을까요?
간단하게 접근하면 될듯합니다. 회사 입장에서 경쟁력은 목표지만 GPL은 보조일 뿐이라고 생각합니다.
GPL이 경쟁력을 저하시킨다고 생각하면서 GPL을 사용하는 멍청한 회사는 망해야죠.

+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년

+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년

han002의 이미지

국내는 소비자가 소프트웨어에 관심에 많거나 전문가가 아니면 그것이 GPL이던 아니던 상관하지않습니다.무료냐 상용이냐가 최대 관심이지..ㅡ.ㅡ

당당히 제품설명엔 리눅스 사용어쩌고 말해도 아직은 소송거는것도 아니니 공개 안 하고도 잘 살던데요..

..

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.