구글 뉴스에 뜬 오늘자 신문을 긁어 보았다.
"복지ㆍ노동"
오늘날 아래아는 "복지·노동"처럼 가운뎃점의 폭이 작은 게 마음에 안 드는 분들을 위한 대체품.
(모음 "ㅣ"를 세로줄 대신 쓰는 경우도 심심치 않게 볼 수 있다.)
2008년 12월 27일 토요일
2008년 11월 5일 수요일
hunspell 한글 검사 실험 - proof of concept
개요는 생략.
hunspell 프로그램이 한글 단어의 edit distance를 계산할 수 있으려면 내부 처리는 모두 첫가끝 코드로 바꿔야 한다. 프로그램을 바꾸기는 어려우니 첫가끝 코드로 변환하고 복원하는 간단한 필터 작성. 만만한게 파이썬에 들어 있는 unicodedata.normalize.
그리고 hunspell의 언어 추가에 필요한 두 가지 데이터, 사전과 affix 파일을 작성한다.
완전한 사전 데이터가 있을 리가 없고... 일단 마구 생각나는 단어 "가방", "발", "컴퓨터"를 입력해 본다. 이 파일은 hunspell에서 직접 읽어들이기 때문에 첫가끝으로 변환해야 하는데.. 앞에서 작성한 필터로 변환한다.
AFF 파일 작성, 욕심은 자제하고 조사 규칙만 입력한다. 원래는 용언의 어간과 어미를 넣어보려고 했으나.. proof of concept으로 명사 + 조사의 형태의 규칙만 만들어 본다. 받침이 있고 없고에 따라 달라지기 때문에 모음과 자음 목록을 첫가끝으로 입력해야 하는데, 좀 성가시므로 gucharmap을 이용했다.
그리고 테스트를 위해 커맨드라인을 첫가끝으로 변환해서 hunspell에 처리한 다음 다시 음절로 바꾸는 스크립트 작성.
몇 번의 시행착오 끝에 hunspell을 이용한 초보적인 한글 맞춤법 검사 동작!
실제 활용할 수 있을 정도로 끌어올리기에는 할 일이 많다. 다른 프로그램과 연동을 고려하면 첫가끝 변환 코드는 실행 파일에 내장해야 한다. 또 우리말 형태론에 맞게 주의깊게 접두어/접미어 규칙이 작성되어야 한다. (복잡한 용어 어미 변화도 가능해 보인다.) 단어별로 특성이 기술된 단어 사전을 축적하는 게 가장 시간이 오래 걸리는 일이다.
하지만 hunspell로 처리할 수 있다는 건 확인할 수 있었다. 오픈오피스와 파이어폭스 사용자의 피드백을 이용할 수도 있다는 점에서 별도의 프로그램을 작성하는 것보다는 더 가능성 있는 방향으로 보인다.
hunspell 프로그램이 한글 단어의 edit distance를 계산할 수 있으려면 내부 처리는 모두 첫가끝 코드로 바꿔야 한다. 프로그램을 바꾸기는 어려우니 첫가끝 코드로 변환하고 복원하는 간단한 필터 작성. 만만한게 파이썬에 들어 있는 unicodedata.normalize.
#!/usr/bin/env python
import unicodedata
import sys
while True:
line = sys.stdin.readline()
if not line:
break
line = unicodedata.normalize('NFC', line.decode("UTF-8")).encode("UTF-8")
sys.stdout.write(line)
#!/usr/bin/env python
import unicodedata
import sys
while True:
line = sys.stdin.readline()
if not line:
break
line = unicodedata.normalize('NFD', line.decode("UTF-8")).encode("UTF-8")
sys.stdout.write(line)
그리고 hunspell의 언어 추가에 필요한 두 가지 데이터, 사전과 affix 파일을 작성한다.
완전한 사전 데이터가 있을 리가 없고... 일단 마구 생각나는 단어 "가방", "발", "컴퓨터"를 입력해 본다. 이 파일은 hunspell에서 직접 읽어들이기 때문에 첫가끝으로 변환해야 하는데.. 앞에서 작성한 필터로 변환한다.
3
가방/JS
발/JS
컴퓨터/JS
AFF 파일 작성, 욕심은 자제하고 조사 규칙만 입력한다. 원래는 용언의 어간과 어미를 넣어보려고 했으나.. proof of concept으로 명사 + 조사의 형태의 규칙만 만들어 본다. 받침이 있고 없고에 따라 달라지기 때문에 모음과 자음 목록을 첫가끝으로 입력해야 하는데, 좀 성가시므로 gucharmap을 이용했다.
SET UTF-8
LANG ko_KR
FLAG long
TRY ᄀᄁᄂᄃᄄᄅᄆᄇᄈᄉᄊᄋᄌᄍᄎᄏᄐᄑ하ᅢᅣᅤᅥᅦᅧᅨᅩᅪᅫᅬᅭᅮᅯᅰᅱᅲᅳᅴᅵᆨᆩᆪᆫᆬᆭᆮᆯᆰᆱᆲᆳᆴᆵᆶᆷᆸᆹᆺᆻᆼᆽᆾᆿᇀᇁᇂ
WORDCHARS ᄀᄁᄂᄃᄄᄅᄆᄇᄈᄉᄊᄋᄌᄍᄎᄏᄐᄑ하ᅢᅣᅤᅥᅦᅧᅨᅩᅪᅫᅬᅭᅮᅯᅰᅱᅲᅳᅴᅵᆨᆩᆪᆫᆬᆭᆮᆯᆰᆱᆲᆳᆴᆵᆶᆷᆸᆹᆺᆻᆼᆽᆾᆿᇀᇁᇂ
# 조사
SFX JS Y 9
SFX JS 0 에 .
SFX JS 0 가 [ᅡᅢᅣᅤᅥᅦᅧᅨᅩᅪᅫᅬᅭᅮᅯᅰᅱᅲᅳᅴᅵ]
SFX JS 0 이 [ᆨᆩᆪᆫᆬᆭᆮᆯᆰᆱᆲᆳᆴᆵᆶᆷᆸᆹᆺᆻᆼᆽᆾᆿᇀᇁᇂ]
SFX JS 0 를 [ᅡᅢᅣᅤᅥᅦᅧᅨᅩᅪᅫᅬᅭᅮᅯᅰᅱᅲᅳᅴᅵ]
SFX JS 0 을 [ᆨᆩᆪᆫᆬᆭᆮᆯᆰᆱᆲᆳᆴᆵᆶᆷᆸᆹᆺᆻᆼᆽᆾᆿᇀᇁᇂ]
SFX JS 0 는 [ᅡᅢᅣᅤᅥᅦᅧᅨᅩᅪᅫᅬᅭᅮᅯᅰᅱᅲᅳᅴᅵ]
SFX JS 0 은 [ᆨᆩᆪᆫᆬᆭᆮᆯᆰᆱᆲᆳᆴᆵᆶᆷᆸᆹᆺᆻᆼᆽᆾᆿᇀᇁᇂ]
SFX JS 0 로 [ᅡᅢᅣᅤᅥᅦᅧᅨᅩᅪᅫᅬᅭᅮᅯᅰᅱᅲᅳᅴᅵᆯ]
SFX JS 0 으로 [ᆨᆩᆪᆫᆬᆭᆮᆰᆱᆲᆳᆴᆵᆶᆷᆸᆹᆺᆻᆼᆽᆾᆿᇀᇁᇂ]
그리고 테스트를 위해 커맨드라인을 첫가끝으로 변환해서 hunspell에 처리한 다음 다시 음절로 바꾸는 스크립트 작성.
#!/bin/sh
echo $* | ./syl2jamo.py | hunspell -d ko_KR | ./jamo2syl.py
몇 번의 시행착오 끝에 hunspell을 이용한 초보적인 한글 맞춤법 검사 동작!
duncan:~/hacks/hunspell$ ./test.sh 가방
Hunspell 1.2.6
*
duncan:~/hacks/hunspell$ ./test.sh 가방이
Hunspell 1.2.6
+ 가방
duncan:~/hacks/hunspell$ ./test.sh 가뱅
Hunspell 1.2.6
& 가뱅 1 0: 가방
duncan:~/hacks/hunspell$ ./test.sh 따방
Hunspell 1.2.6
& 따방 1 0: 가방
duncan:~/hacks/hunspell$ ./test.sh 컴퓨터가
Hunspell 1.2.6
+ 컴퓨터
duncan:~/hacks/hunspell$ ./test.sh 컴퓨터이
Hunspell 1.2.6
& 컴퓨터이 2 0: 컴퓨터에, 컴퓨터
duncan:~/hacks/hunspell$ ./test.sh 컴퓨방
Hunspell 1.2.6
& 컴퓨방 2 0: 컴퓨터, 가방
duncan:~/hacks/hunspell$ ./test.sh 발로
Hunspell 1.2.6
+ 발
duncan:~/hacks/hunspell$ ./test.sh 발으로
Hunspell 1.2.6
& 발으로 3 0: 가방으로, 발로, 발
실제 활용할 수 있을 정도로 끌어올리기에는 할 일이 많다. 다른 프로그램과 연동을 고려하면 첫가끝 변환 코드는 실행 파일에 내장해야 한다. 또 우리말 형태론에 맞게 주의깊게 접두어/접미어 규칙이 작성되어야 한다. (복잡한 용어 어미 변화도 가능해 보인다.) 단어별로 특성이 기술된 단어 사전을 축적하는 게 가장 시간이 오래 걸리는 일이다.
하지만 hunspell로 처리할 수 있다는 건 확인할 수 있었다. 오픈오피스와 파이어폭스 사용자의 피드백을 이용할 수도 있다는 점에서 별도의 프로그램을 작성하는 것보다는 더 가능성 있는 방향으로 보인다.
2008년 11월 3일 월요일
안드로이드폰 G1의 티보이제이션
구글 그룹스에서 Q&A 중의 구글 관계자의 말에 따르면,
이 말은 즉슨, 커널 및 시스템 프로그램들의 소스코드는 오픈되어 있으나 그 소스코드를 바꾸더라도 T-Mobile이나 HTC가 가지고 있는 디지털 키로 서명하지 않는 한 실제 장비에는 돌릴 수 없다는 뜻이다. 전형적인 티보이제이션이다. G1은 기대와는 달리 오픈 플랫폼이 아니다.
구글 혹은 T-모바일쪽의 이러한 결정이 사악하느냐 (be evil) 아니냐를 떠나서, 컴파일해 봤자 실제 장비에서 돌릴 수 없는 소스코드라면, 안드로이드의 소스 코드를 오픈한 게 과연 무슨 의미가 있는 걸까? 휴대폰 개발사에 소속되어 개발용 폰을 받지 않는 한, 안드로이드의 시스템 코드 개발자들은 안드로이드 SDK에 들어 있는 에뮬레이터의 한계에 갇힐 수밖에 없다.
The G1 is aimed at end users, not system developers. For user security reasons the G1 will only accept properly signed system images. I'm not sure, in this case, who 'owns' the key, whether it is the carrier or the manufacturer, but one or both of them handle insuring system images are signed.
G1은 일반 사용자용 제품이지 시스템 개발자가 사용하는 게 아니예요. 보안때문에 G1에서는 올바르게 서명한 시스템 이미지만 받아들입니다. 이 경우에는 누가 그 키를 "소유"하는지, 즉 통신사인지 제조사인지 확신하지 못하겠군요. 어쨌든 이 둘 중의 하나 혹은 둘 모두에서 시스템 이미지의 서명을 관리합니다.
Cheers,
Justin
Android Team @ Google
이 말은 즉슨, 커널 및 시스템 프로그램들의 소스코드는 오픈되어 있으나 그 소스코드를 바꾸더라도 T-Mobile이나 HTC가 가지고 있는 디지털 키로 서명하지 않는 한 실제 장비에는 돌릴 수 없다는 뜻이다. 전형적인 티보이제이션이다. G1은 기대와는 달리 오픈 플랫폼이 아니다.
구글 혹은 T-모바일쪽의 이러한 결정이 사악하느냐 (be evil) 아니냐를 떠나서, 컴파일해 봤자 실제 장비에서 돌릴 수 없는 소스코드라면, 안드로이드의 소스 코드를 오픈한 게 과연 무슨 의미가 있는 걸까? 휴대폰 개발사에 소속되어 개발용 폰을 받지 않는 한, 안드로이드의 시스템 코드 개발자들은 안드로이드 SDK에 들어 있는 에뮬레이터의 한계에 갇힐 수밖에 없다.
2008년 9월 5일 금요일
크롬에 액티브엑스라니
"액티브X와 공존 모색"…구글, 웹브라우저 시장 '초강수'
액티브엑스를 정확히 어떻게 돌리겠다고 한국의 웹 환경을 위해 액티브엑스를 지원한다는 발언을 한 건지 모르겠는데.. 어떻게 만들던 간에 32비트 x86 MS Windows 전용이 되는 걸 피할 수 없다.
지금 MS 전용 브라우저를 만들어서 MS를 넘어서 보겠다는 얘기를 하고 있는 건가? ("`크롬`은 MS 잡을 대항마" 에릭 슈미트 구글 CEO, FT와 인터뷰서 도전 시인) 아니면 악성코드의 매개체였던 기술을 구현해서 MORE SECURE한 ("Google on Google Chrome" comic book) 브라우저를 만들어내겠다는 건가?
아마도 크롬의 소스가 공개된 걸 국정원이 발견하면 보안용으로 못 쓰게 만들 것 같은데 (리눅스 보안 제품 국정원 차별 논란), 그러면 한국을 위해 closed source로 만들 지도?
액티브엑스를 정확히 어떻게 돌리겠다고 한국의 웹 환경을 위해 액티브엑스를 지원한다는 발언을 한 건지 모르겠는데.. 어떻게 만들던 간에 32비트 x86 MS Windows 전용이 되는 걸 피할 수 없다.
지금 MS 전용 브라우저를 만들어서 MS를 넘어서 보겠다는 얘기를 하고 있는 건가? ("`크롬`은 MS 잡을 대항마" 에릭 슈미트 구글 CEO, FT와 인터뷰서 도전 시인) 아니면 악성코드의 매개체였던 기술을 구현해서 MORE SECURE한 ("Google on Google Chrome" comic book) 브라우저를 만들어내겠다는 건가?
아마도 크롬의 소스가 공개된 걸 국정원이 발견하면 보안용으로 못 쓰게 만들 것 같은데 (리눅스 보안 제품 국정원 차별 논란), 그러면 한국을 위해 closed source로 만들 지도?
2008년 8월 31일 일요일
지역화 관련 코드 표준들
ISO 639 - 언어 코드. 2글자의 알파벳 코드. 한국어는 KO. (KR이 아니다.)
ISO 639-2 - ISO 639와 마찬가지로 언어코드이지만 3글자 코드이다. 한국어는 KOR이다. tut(Altaic), ine(Indo-European)처럼 특정 언어가 아닌 언어군을 가리키는 코드까지 포함되어 있고, tlh(Klingon, 스타트렉의 외계인이 쓰는 언어)같은 인공어도 들어 있고, 고대와 현대의 언어를 구분해 놓는 등 좀 의문이 드는 코드가 다수 들어 있다. 가장 문제라고 할 수 있는 부분이, terminology use와 bibliography use에 사용하는 코드를 별도로 구분해 놓아 23개의 언어에 대해서 T 코드와 B 코드가 다르다. (독일어의 경우 T 코드는 deu, B 코드는 ger.) B 코드는 당시의 도서관 시스템들이 기존에 분류 기준으로 사용하고 있는 코드를 그대로 수용한 결과이다. 마이크로소프트가 OS에 사용하는 언어 코드가 3글자라서 ISO 639-2가 아닌가 오해하곤 하지만 MS가 임의로 만든 코드이다.
ISO 639-3 - 또 다른 언어 코드. 역시 3글자 코드이고 639-2보다 훨씬 더 확장되었다. 한국어는 마찬가지로 KOR. 하지만 문제의 B/T 코드 구분은 없어지고 T 코드만 사용한다, 언어군을 가리키는 코드도 없어졌다. (클링온은 남아 있음.)
ISO 3166 - 국가 코드. 주권국이 아닌 식민지, 자치 지역, 남극같은 곳에도 코드가 있기도 하다. alpha-2 코드는 대한민국이 KR. (KO가 아니다.) 국가 체제는 어느날 갑자기 분리독립을 하거나 통일/병합되거나 개명하거나 하는 식으로 바뀔 수 있는 것이라 끊임없이 개정되어 왔다.
ISO 3166 alpha-3 - ISO 3166의 subset으로 3글자 코드이고 대한민국은 KOR. 국가 대표 선수들의 이름표도 그렇고, 유닉스/리눅스 L10N에 관련된 사람이 아니라면 2글자 코드보다는 3글자 코드를 일상생활에서 더 많이 볼 수 있다.
ISO 3166 numeric - ISO 3166의 subset으로 3글자의 숫자 코드이다. 대한민국은 410.
ISO 3166-2 - 국가 코드가 아니라 세부 지역 코드이다. ISO 3166 코드 뒤에 세부 지역 코드를 대시로 연결한다. 알파벳이나 혹은 숫자 1글자에서 3글자 사이의 코드로 표기한다. 미국의 주 따위가 대표적으로 미국은 US-TX(텍사스)처럼 우편 약자를 사용한다. 한국에 해당하는 코드는 ISO 3166-2:KR subset에 정의되어 있는데 광역 자치단체별로 구분되어 있고 세부 지역코드는 숫자를 사용한다. 서울은 KR-11, 대전은 KR-30. 이 부분도 각 지역의 행정 체계의 변화에 따라 끊임없이 개정된다.
ISO 15924 - 문자 (script) 코드. 4글자의 알파벳 혹은 숫자 코드이다. 라틴 문자는 통틀어서 Latn이고 한자는 공통으로 Hani가 있는 반면에 중국어 간체는 Hans 번체는 Hant로 구분되어 있다. 한글은 문자코드는 Hang, 숫자코드는 286이다. Hang의 alias로 Kore/287도 있다.
ISO 4217 - 화폐 코드. 흔히 국제 환율 얘기할 때도 많이 쓰는 코드이다. 원화는 KRW.
RFC 4646 - HTML/XML에 사용하는 언어 표기 방법. xml:lang 따위가 대표적이다. ISO 639, ISO 15924, ISO 3166 문자 코드를 순서대로 대시 기호로 연결한다. ISO 639는 소문자, ISO 3166은 대문자로 쓰고, ISO 15924는 첫 글자만 대문자로 쓴다. ISO 639 뒤의 코드를 생략할 수 있고, 중간의 ISO 15924 코드만 생략할 수도 있다. 즉 한국어라면 "ko", "ko-KR", "ko-Hang-KR", "kor", "kor-KOR", "kor-Hang-KOR" 따위로 쓸 수 있다.
2008년 7월 5일 토요일
우분투 런치패드 번역의 BSD 라이센스 전환의 문제
최근 우분투 런치패드는 런치패드에 들어 있는 번역문에 대해 BSD 라이센스로 확인하는 작업을 하고 있다. 일정은 없지만 동의하지 않은 번역문은 런치패드 시스템에서 지워질 예정이다.
이러한 조치는 런치패드의 번역문들이 라이센스를 명확히 하지 않는다는 비판과 더불어, 번역문을 여러 프로그램 사이에 공유할 때 생기는 라이센스 문제에 대한 해결책으로 보인다. (예를 들어 GPL 프로그램의 번역문을 LGPL 프로그램에 사용하는 경우처럼.)
하지만 왜 하필 BSD이며, 왜 BSD가 아니면 시스템에서 지운다는 걸까?
첫째로 과연 GPL 소프트웨어의 번역을 BSD로 하는 게 가능한 것인가 의문을 갖게한다. 원문은 GPL 라이센스로 배포되는 프로그램의 소스코드에서 xgettext 프로그램을 통해 추출한 것이고 번역문은 파생 작업이라고밖에 할 수 없다. GPL 코드에서 추출한 템플릿을 번역한 번역문의 라이센스를 BSD로 한다는 게 가능한 것일까?
또 실제적으로 런치패드의 온라인 번역 시스템이 훌륭하긴 하지만 여전히 훨씬 더 많은 번역문들이 이 시스템 밖에서 만들어져서 런치패드 시스템으로 import되고 있다. 런치패드에 들어 있는 번역문의 대다수는 런치패드에서 시작한 번역문이 아니라 외부에서 import한 번역문을 보완한 정도이고 이렇게 GPL 번역문을 고쳐서 만들어진 결과물을 BSD 라이센스라고 할 수는 없다. 이러한 모든 번역을 지우고 런치패드 내부에서 scratch부터 시작할 것인지?
그리고 GPL은 GPL의 가치가 있다. 나는 내가 번역한 번역문이 해당 소프트웨어의 라이센스를 따르게 할 뿐, 일부러 번역문에 BSD 라이센스를 사용할 생각은 전혀 없다. GPL의 파생작업에 대한 라이센스 조항을 좋아하든 싫어하든 이 GPL 조항은 자유소프트웨어 발전에 대단히 큰 역할을 했다. 런치패드 시스템에서 사용하려고, 호환성때문에 GPL이었을 때의 장점을 버리고 BSD를 택한다는 건 받아들이기 힘들다.
몇몇 언어의 그놈/데비안/KDE 번역 팀들은 런치패드 시스템의 편리함때문에 공식적인 번역 도구로 사용하고 있다. (한국어 번역팀은 아님.) 런치패드의 이러한 조치는 이 팀들이 계속 런치패드에서 작업해야 하는지 고민하게 만들었다. 번역문 사이의 호환성이 문제라면 좀 수고를 하더라도 라이센스 호환성 문제를 처리하도록 시스템을 구현할 수도 있지 않을까? 왜 BSD로 통일해야 하며 그게 아니면 시스템에서 지워야 할까? 이러한 결정은 지금까지 훌륭히 번역 작업을 해 온 런치패드의 발목을 잡게 될 것이다.
이러한 조치는 런치패드의 번역문들이 라이센스를 명확히 하지 않는다는 비판과 더불어, 번역문을 여러 프로그램 사이에 공유할 때 생기는 라이센스 문제에 대한 해결책으로 보인다. (예를 들어 GPL 프로그램의 번역문을 LGPL 프로그램에 사용하는 경우처럼.)
하지만 왜 하필 BSD이며, 왜 BSD가 아니면 시스템에서 지운다는 걸까?
첫째로 과연 GPL 소프트웨어의 번역을 BSD로 하는 게 가능한 것인가 의문을 갖게한다. 원문은 GPL 라이센스로 배포되는 프로그램의 소스코드에서 xgettext 프로그램을 통해 추출한 것이고 번역문은 파생 작업이라고밖에 할 수 없다. GPL 코드에서 추출한 템플릿을 번역한 번역문의 라이센스를 BSD로 한다는 게 가능한 것일까?
또 실제적으로 런치패드의 온라인 번역 시스템이 훌륭하긴 하지만 여전히 훨씬 더 많은 번역문들이 이 시스템 밖에서 만들어져서 런치패드 시스템으로 import되고 있다. 런치패드에 들어 있는 번역문의 대다수는 런치패드에서 시작한 번역문이 아니라 외부에서 import한 번역문을 보완한 정도이고 이렇게 GPL 번역문을 고쳐서 만들어진 결과물을 BSD 라이센스라고 할 수는 없다. 이러한 모든 번역을 지우고 런치패드 내부에서 scratch부터 시작할 것인지?
그리고 GPL은 GPL의 가치가 있다. 나는 내가 번역한 번역문이 해당 소프트웨어의 라이센스를 따르게 할 뿐, 일부러 번역문에 BSD 라이센스를 사용할 생각은 전혀 없다. GPL의 파생작업에 대한 라이센스 조항을 좋아하든 싫어하든 이 GPL 조항은 자유소프트웨어 발전에 대단히 큰 역할을 했다. 런치패드 시스템에서 사용하려고, 호환성때문에 GPL이었을 때의 장점을 버리고 BSD를 택한다는 건 받아들이기 힘들다.
몇몇 언어의 그놈/데비안/KDE 번역 팀들은 런치패드 시스템의 편리함때문에 공식적인 번역 도구로 사용하고 있다. (한국어 번역팀은 아님.) 런치패드의 이러한 조치는 이 팀들이 계속 런치패드에서 작업해야 하는지 고민하게 만들었다. 번역문 사이의 호환성이 문제라면 좀 수고를 하더라도 라이센스 호환성 문제를 처리하도록 시스템을 구현할 수도 있지 않을까? 왜 BSD로 통일해야 하며 그게 아니면 시스템에서 지워야 할까? 이러한 결정은 지금까지 훌륭히 번역 작업을 해 온 런치패드의 발목을 잡게 될 것이다.
2008년 7월 2일 수요일
전자정부를 통한 증명 문서의 인터넷 출력
2008년 현재 대한민국전자정부의 기능을 이용해 인터넷으로 발급할 수 있는 문서는 주민등록등본, 공시지가확인서, 등기부등본, 소득증명 등 수십종에 이른다. 수년 전에 연말정산때문에 이 기능을 처음 이용해 봤을 때 어떻게 내 프린터에서 공공문서를 인쇄하는 게 가능한 건가 몹시 의심스러웠다. 근본적으로 이렇게 출력된 문서가 올바르다고 보장할 방법이 없기 때문이다. 등기부등본과 같이 서류의 목적이 열람용일 경우에는 문제가 되지 않지만, 일부 증명 용도의 서류도 인터넷으로 발급할 수 있다.
연말정산을 위해 내 프린터에서 주민등록등본을 출력했을 때, 발급자인 정부나 수신자인 국세청은 정말 위변조된 문서가 아니라고 안심할 수 있을까? 국세청은 그 문서 내용을 그대로 믿고 그 종이에 쓰여 있는 가족관계에 따라 내 세금공제를 처리해도 되는 걸까?
실제로 이 서비스는 논란이 많았고, 2005년에 위조 가능성이 제기되어 일시적으로 중지되기도 했고, 업데이트될 때마다 프린터가 지원에서 빠지기도 하고 가상머신에서 이용이 금지되기도 하고 이용자들의 불평이 쏟아졌다.
종이가 증명서가 되려면
"등본"이라는 말은 말 그대로 있는 보관되어 있는 서류와 동일한 문서를 뜻한다. 주민등록이 전산화 되기 전에는 그 주민등록 문서가 보관되어 있는 동사무소에서 신청을 하면 동사무소 직원이 서류 창고에서 해당 문서를 찾아서 복사한 다음 동사무소 직인을 찍어서 발급해 주었고 그게 "등본"이었다. 직인은 실제 문서와 동일하다는 보증이었다. 내 프린터로 인쇄하더라도 주민등록등본이 실제 정부 전산망에 기재된 내용과 동일하다는 걸 보장할 수 있는 걸까?
말많은 키보드 보안 기능과 마찬가지로 전자정부 사이트는 이렇게 인쇄한 문서가 올바르다는 보장을 클라이언트 컨트롤을 통해 하고 있다. 액티브엑스 컨트롤로 가능한 프린터의 종류를 제한하고 있다. 프린터에 보안 기능이 있어야 이용할 수 있다고 말하는 사람들이 있지만, 실제 지원하는 프린터들을 보면 보안 기능같은 건 본적이 없는 프린터들도 사용할 수 있는 걸 보면 프린터의 기능과는 상관이 없다. (시중에 나와 있는 일부 프린터에서 구현하고 있는 보안 기능은 전자정부 웹사이트가 인쇄된 문서를 인증할 수 있는 종류의 인증용 보안 기능이 아니라, 인쇄 데이터 전송의 암호화, 인쇄 작업별로 암호 지정과 같은 보안이다.)
이러한 클라이언트 컨트롤 접근 방법때문에 윈도우즈 외에 다른 OS를 지원하지 않는다거나, 시스템 의존적인 버그가 나타나거나, 개발 비용이 높아진다거나 하는 부작용이 나타난 건 물론이다.
내 프린터에서 인쇄한 종이를 증명서로 만드는 방법같은 건 없다. 왜냐하면 컴퓨터는 사용자의 것이지 전자정부 웹사이트가 마음대로 해라 마라 할 수 있는 게 아니기 때문이다. 프린터에 보낼 이미지 데이터는 결국 컴퓨터의 어딘가에서 로우 데이터로 흘러다니게 마련이고 내부에서 나름대로 암호화하고 하더라도 결국 프린터로 그 데이터를 보내야 한다. 전자정부 사이트는 일단 이용자가 소유한 컴퓨터를 서비스 제공자 마음대로 조작할 수 없다는 걸 인정해야 한다. 이 사실을 인정하지 못하고 사용자에게 배포하는 클라이언트 소프트웨어를 조작하는 방법으로 문제를 해결하려고 하면 상황이 지금과 같이 복잡해 진다.
대안 - 종이가 아닌 데이터를 증명용으로 쓰자!
인쇄한 종이 그 자체가 증명 자격을 가지지 않도록 해야 한다.
단 출력한 내용이 사실 여부를 조회할 수 있도록 하는 티켓 역할을 하도록 만들 수는 있을 것이다. 예를 들어, 회사의 복지제도를 이용하기 위해 내 가족관계가 이러하다는 걸 증명하려면 주민등록초본이 필요할 것이고, 초본의 역할은 제 3자에게 나의 가족관계를 증명하는 것이다. 지금의 초본은 출력한 서류 그 자체가 증명 자격을 갖도록 되어 있지만, 이제 그런 공식적인 증명 자격을 없애고 전자정부에 가족관계를 조회할 수 있는 one-time pass 역할만 하게 만드는 것이다. 그러면 서류의 목적도 달성할 수 있고 사용자의 프린터를 컨트롤할 필요도 없다.
현재도인터넷에서 출력한 문서는 고유번호와 바코드가 기재되어 있고 진위여부를 확인할 수 있다. 기술적으로는 아무런 문제가 없다. 단지 출력한 서류 그 자체가 증명 서류가 아니고 one-time pass일 뿐이라는 걸 인정하면서 기존의 업무체계가 동작할 수 있느냐가 관건이다.
연말정산을 위해 내 프린터에서 주민등록등본을 출력했을 때, 발급자인 정부나 수신자인 국세청은 정말 위변조된 문서가 아니라고 안심할 수 있을까? 국세청은 그 문서 내용을 그대로 믿고 그 종이에 쓰여 있는 가족관계에 따라 내 세금공제를 처리해도 되는 걸까?
실제로 이 서비스는 논란이 많았고, 2005년에 위조 가능성이 제기되어 일시적으로 중지되기도 했고, 업데이트될 때마다 프린터가 지원에서 빠지기도 하고 가상머신에서 이용이 금지되기도 하고 이용자들의 불평이 쏟아졌다.
종이가 증명서가 되려면
"등본"이라는 말은 말 그대로 있는 보관되어 있는 서류와 동일한 문서를 뜻한다. 주민등록이 전산화 되기 전에는 그 주민등록 문서가 보관되어 있는 동사무소에서 신청을 하면 동사무소 직원이 서류 창고에서 해당 문서를 찾아서 복사한 다음 동사무소 직인을 찍어서 발급해 주었고 그게 "등본"이었다. 직인은 실제 문서와 동일하다는 보증이었다. 내 프린터로 인쇄하더라도 주민등록등본이 실제 정부 전산망에 기재된 내용과 동일하다는 걸 보장할 수 있는 걸까?
말많은 키보드 보안 기능과 마찬가지로 전자정부 사이트는 이렇게 인쇄한 문서가 올바르다는 보장을 클라이언트 컨트롤을 통해 하고 있다. 액티브엑스 컨트롤로 가능한 프린터의 종류를 제한하고 있다. 프린터에 보안 기능이 있어야 이용할 수 있다고 말하는 사람들이 있지만, 실제 지원하는 프린터들을 보면 보안 기능같은 건 본적이 없는 프린터들도 사용할 수 있는 걸 보면 프린터의 기능과는 상관이 없다. (시중에 나와 있는 일부 프린터에서 구현하고 있는 보안 기능은 전자정부 웹사이트가 인쇄된 문서를 인증할 수 있는 종류의 인증용 보안 기능이 아니라, 인쇄 데이터 전송의 암호화, 인쇄 작업별로 암호 지정과 같은 보안이다.)
이러한 클라이언트 컨트롤 접근 방법때문에 윈도우즈 외에 다른 OS를 지원하지 않는다거나, 시스템 의존적인 버그가 나타나거나, 개발 비용이 높아진다거나 하는 부작용이 나타난 건 물론이다.
내 프린터에서 인쇄한 종이를 증명서로 만드는 방법같은 건 없다. 왜냐하면 컴퓨터는 사용자의 것이지 전자정부 웹사이트가 마음대로 해라 마라 할 수 있는 게 아니기 때문이다. 프린터에 보낼 이미지 데이터는 결국 컴퓨터의 어딘가에서 로우 데이터로 흘러다니게 마련이고 내부에서 나름대로 암호화하고 하더라도 결국 프린터로 그 데이터를 보내야 한다. 전자정부 사이트는 일단 이용자가 소유한 컴퓨터를 서비스 제공자 마음대로 조작할 수 없다는 걸 인정해야 한다. 이 사실을 인정하지 못하고 사용자에게 배포하는 클라이언트 소프트웨어를 조작하는 방법으로 문제를 해결하려고 하면 상황이 지금과 같이 복잡해 진다.
대안 - 종이가 아닌 데이터를 증명용으로 쓰자!
인쇄한 종이 그 자체가 증명 자격을 가지지 않도록 해야 한다.
단 출력한 내용이 사실 여부를 조회할 수 있도록 하는 티켓 역할을 하도록 만들 수는 있을 것이다. 예를 들어, 회사의 복지제도를 이용하기 위해 내 가족관계가 이러하다는 걸 증명하려면 주민등록초본이 필요할 것이고, 초본의 역할은 제 3자에게 나의 가족관계를 증명하는 것이다. 지금의 초본은 출력한 서류 그 자체가 증명 자격을 갖도록 되어 있지만, 이제 그런 공식적인 증명 자격을 없애고 전자정부에 가족관계를 조회할 수 있는 one-time pass 역할만 하게 만드는 것이다. 그러면 서류의 목적도 달성할 수 있고 사용자의 프린터를 컨트롤할 필요도 없다.
현재도인터넷에서 출력한 문서는 고유번호와 바코드가 기재되어 있고 진위여부를 확인할 수 있다. 기술적으로는 아무런 문제가 없다. 단지 출력한 서류 그 자체가 증명 서류가 아니고 one-time pass일 뿐이라는 걸 인정하면서 기존의 업무체계가 동작할 수 있느냐가 관건이다.
2008년 6월 12일 목요일
2008년 6월 10일 청와대 홈페이지
며칠 더 유지됐었다면 아마 구글에서 피싱 사이트로 분류할 수도 있었을 텐데.
index.jpg 파일은 청와대 사이트를 캡쳐해 놓은 그림이다.
사이트 폭주가 발생하면 무언가 대응을 하긴 해야 한다. 효율 개선, 용량 늘이기, 악의적인 연결을 차단하기, 다른 방법이 없다면 임시 폐쇄를 결정할 수도 있는 일이다. 하지만 조금이라도 의식이 박혀 있다면 이렇게 가짜 이미지를 뿌리는 짓은 하지 않는다.
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ko" lang="ko"><head><title>청와대에 오신 것을 환영합니다.</title>
<meta http-equiv="content-type" content="text/html; charset=euc-kr"></head><body>
<img src="index.jpg" border="0" height="934" width="1259">
</body></html>
index.jpg 파일은 청와대 사이트를 캡쳐해 놓은 그림이다.
사이트 폭주가 발생하면 무언가 대응을 하긴 해야 한다. 효율 개선, 용량 늘이기, 악의적인 연결을 차단하기, 다른 방법이 없다면 임시 폐쇄를 결정할 수도 있는 일이다. 하지만 조금이라도 의식이 박혀 있다면 이렇게 가짜 이미지를 뿌리는 짓은 하지 않는다.
2008년 5월 29일 목요일
2008년 5월 23일 금요일
OSS 정책 - 리눅스용 키보드 보안
말많던 리눅스용 보안 프로그램이 최근부터 소프트웨어진흥원의 oss.or.kr 사이트를 통해 배포되고 있다. 백신 프로그램과 키보드 보안으로 구성되어 있다.
http://data.oss.or.kr/sw/view.html?sort=name&num=990&page=1
이 프로그램은 정말 사연이 많다. 약 3년전에 소프트웨어진흥원은 공개소프트웨어 진흥 사업의 하나로 우체국 인터넷 뱅킹의 리눅스 운영체제 지원을 추진했다. 하지만 추진 과정에서 국정원이 발목을 잡았다. 보안적합성 평가에서 MS 윈도우즈와 똑같은 기준을 요구했기 때문이다. (관련 기사) 소프트웨어 진흥원은 국정원의 평가에 대해 이의를 제기하지 않고 그 기준을 따르기로 하고 개발하기로 했고 (관련 기사) 2년이 지난 지금에서야 인증이 완료된 프로그램이 지금 배포하는 이 프로그램이다.
소프트웨어진흥원은 국정원의 가이드라인에 대해 부당함을 말하고 정면 대응했어야 했다. 그러기는 커녕 오히려 소프트웨어진흥원 관계자가 국정원의 어긋난 보안평가를 기초로 "리눅스 보안이 문제가 있다"라고 인정하면서 지금과 같은 핀트가 어긋난 프로그램을 개발한 일은 잘못된 정책이었다.
프로그램을 다운로드해 보면, 파일이 zip으로 압축되어 있고 문서가 MS-Word 형식으로 되어 있다는 것부터가 심상치 않다. 이 프로그램을 실제로 돌려 보기는 매우 어렵다. 일단 소스코드가 공개되어 있지 않고 커널 모듈도 들어 있기 때문에 특정 커널 버전이 아니면 동작하지 않는다. 한소프트리눅스 2006에서만 동작하는데 이 한소프트리눅스 2006 버전은 릴리즈한지 2년이 되는 다음달에 지원이 끊길 예정이다. 국정원이 인증하는데 2년을 끌었다는 걸 입증이라도 하듯, 모든 소프트웨어가 2년전 기준으로 되어 있다.
이 프로그램에 포함된 백신의 경우 V3 엔진의 포팅인데, 여기서 검색하는 바이러스와 웜은 리눅스에서는 전파되지 않는 것들이다. 백신이 하는 일이 윈도우용 파일에 있는 바이러스와 웜을 찾아내는 정도인데, 이 프로그램이 있어야 인터넷 뱅킹을 인증한다는 게 앞뒤가 맞는 걸까.
키보드 보안은 커널 모듈과 Firefox 확장 기능으로 구성되어 있는데, 브라우저를 root 권한으로 실행해야 한다고 한다. root 권한으로 소스를 알 수 없는 소프트웨어를 설치해서 브라우저를 root 권한으로 실행하는 게, 이런 소프트웨어 없이 인터넷 뱅킹을 사용하는 것보다 더 안전한 걸까?
소스 코드를 공개하지 않는 이유는 국정원의 보안 지침이 그렇기 때문이라고 하는데, 덕분에 특정 배포판의 특정 커널 버전이 아니면 사용이 불가능한 소프트웨어가 되었다. 이 소스코드 비공개 지침도 이해하기 힘들다. 스티브잡스가 DRM에 대해 한 얘기에서처럼 그 방법을 비밀로 하면서 그 비밀에 의존하는 보안은 언젠가 비밀이 밝혀질 것이고 수명이 오래 가지 못한다.
현재 이 프로그램의 형태로 볼 때 이대로는 절대로 널리 사용할 수 없어 보인다. 이걸 쓰기 위해 한소프트리눅스 구버전을 설치해서 쓰지는 않을 것이다. 인력을 투입해서 여러 OS를 고려해서 빌드하는 수고를 한다고 해도 향후에 커널 업그레이드에 따위에 발생하는 불편함은 남아 있을 것이다. 국정원이 소스 비공개 원칙을 포기할 것 같지도 않고 말이다. 과연 가까운 시일내에 리눅스에서 인터넷 뱅킹을 쓸 수 있을지 모르겠다.
http://data.oss.or.kr/sw/view.html?sort=name&num=990&page=1
이 프로그램은 정말 사연이 많다. 약 3년전에 소프트웨어진흥원은 공개소프트웨어 진흥 사업의 하나로 우체국 인터넷 뱅킹의 리눅스 운영체제 지원을 추진했다. 하지만 추진 과정에서 국정원이 발목을 잡았다. 보안적합성 평가에서 MS 윈도우즈와 똑같은 기준을 요구했기 때문이다. (관련 기사) 소프트웨어 진흥원은 국정원의 평가에 대해 이의를 제기하지 않고 그 기준을 따르기로 하고 개발하기로 했고 (관련 기사) 2년이 지난 지금에서야 인증이 완료된 프로그램이 지금 배포하는 이 프로그램이다.
소프트웨어진흥원은 국정원의 가이드라인에 대해 부당함을 말하고 정면 대응했어야 했다. 그러기는 커녕 오히려 소프트웨어진흥원 관계자가 국정원의 어긋난 보안평가를 기초로 "리눅스 보안이 문제가 있다"라고 인정하면서 지금과 같은 핀트가 어긋난 프로그램을 개발한 일은 잘못된 정책이었다.
프로그램을 다운로드해 보면, 파일이 zip으로 압축되어 있고 문서가 MS-Word 형식으로 되어 있다는 것부터가 심상치 않다. 이 프로그램을 실제로 돌려 보기는 매우 어렵다. 일단 소스코드가 공개되어 있지 않고 커널 모듈도 들어 있기 때문에 특정 커널 버전이 아니면 동작하지 않는다. 한소프트리눅스 2006에서만 동작하는데 이 한소프트리눅스 2006 버전은 릴리즈한지 2년이 되는 다음달에 지원이 끊길 예정이다. 국정원이 인증하는데 2년을 끌었다는 걸 입증이라도 하듯, 모든 소프트웨어가 2년전 기준으로 되어 있다.
이 프로그램에 포함된 백신의 경우 V3 엔진의 포팅인데, 여기서 검색하는 바이러스와 웜은 리눅스에서는 전파되지 않는 것들이다. 백신이 하는 일이 윈도우용 파일에 있는 바이러스와 웜을 찾아내는 정도인데, 이 프로그램이 있어야 인터넷 뱅킹을 인증한다는 게 앞뒤가 맞는 걸까.
키보드 보안은 커널 모듈과 Firefox 확장 기능으로 구성되어 있는데, 브라우저를 root 권한으로 실행해야 한다고 한다. root 권한으로 소스를 알 수 없는 소프트웨어를 설치해서 브라우저를 root 권한으로 실행하는 게, 이런 소프트웨어 없이 인터넷 뱅킹을 사용하는 것보다 더 안전한 걸까?
소스 코드를 공개하지 않는 이유는 국정원의 보안 지침이 그렇기 때문이라고 하는데, 덕분에 특정 배포판의 특정 커널 버전이 아니면 사용이 불가능한 소프트웨어가 되었다. 이 소스코드 비공개 지침도 이해하기 힘들다. 스티브잡스가 DRM에 대해 한 얘기에서처럼 그 방법을 비밀로 하면서 그 비밀에 의존하는 보안은 언젠가 비밀이 밝혀질 것이고 수명이 오래 가지 못한다.
현재 이 프로그램의 형태로 볼 때 이대로는 절대로 널리 사용할 수 없어 보인다. 이걸 쓰기 위해 한소프트리눅스 구버전을 설치해서 쓰지는 않을 것이다. 인력을 투입해서 여러 OS를 고려해서 빌드하는 수고를 한다고 해도 향후에 커널 업그레이드에 따위에 발생하는 불편함은 남아 있을 것이다. 국정원이 소스 비공개 원칙을 포기할 것 같지도 않고 말이다. 과연 가까운 시일내에 리눅스에서 인터넷 뱅킹을 쓸 수 있을지 모르겠다.
2008년 4월 26일 토요일
KMPlayer - 정말 GPL 위반 맞을까?
먼저 하고 싶은 말은, IANAL (I Am Not A Lawyer). 지금 하는 말은 내 지식, 경험, 공개된 문서에 기반한 판단일 뿐 것일 뿐 법률적인 전문적 판단은 아니다. 하지만 사실에 기반해서 말하는 건 자신할 수 있다.
GPL 위반 논란이 있을 때마다 사람들은 쉽게 초점을 벗어나곤 한다. GPL을 위반했느냐 아니냐는 사실 여부를 판단하는 문제이다. 이 문제는 GPL이 허용하는 것과 허용하지 않는 것이 무엇인데, 당사자와 해당 소프트웨어가 어떻게 했는지 사실 관계를 확인하면 되는 것이다. 이 소프트웨어를 좋아하든 싫어하든, 실수로 그랬든 악의적으로 그랬든, GPL을 좋아하든 싫어하든, 개발자들이 어떤 노력을 했든, 결과적으로 공익에 좋은 영향을 미쳤든 악영향을 미쳤든 간에 라이센스 위반 여부와는 상관이 없다. 라이센스라고 해도 애매한 부분은 항상 있지만, 애매한 부분 역시 라이센스의 내용과 사실 관계에 의해서 판단할 문제이지 좋아하느냐 싫어하느냐 등 외적인 문제로 판단할 문제가 아니다.
1. MPC 코드 사용: 모르겠다
KMPlayer의 GPL 위반에 대해 가장 많이 논란이 된 부분은 MPC의 코드를 베껴오지 않았냐는 논란이었다.
이 논란에서는 좀 재미있는 점이, KMPlayer 개발자가 몹시 위험한 사실을 시인했다. "코드를 참고해서 델파이 코드를 작성했다"라고 말한 것이다. C++ 코드를 보고 델파이 코드를 작성했다면 그게 개작일까, 아닐까? 답은 그럴 수도 있고 아닐 수도 있다. 그때그때 다르고 뭐라고 말할 수 없다. 사용하는 프로그래밍 언어가 무엇인지는 중요하지 않다. 프로그래밍 언어가 다르다는 주장은, 소스 코드를 그대로 복사/붙여넣기하지는 않았다는 정도 이상의 근거가 되지 못한다.
논란의 구실을 제공하기 때문에 보통 소프트웨어를 개발할 때는 애초에 이런 애매한 상황을 만들지 않으려고 노력한다. 라이센스 논란이 있는 소프트웨어를 다시 작성할 경우에는, 라이센스 문제가 있는 어떤 코드를 한번 읽었다면 그 사람은 같은 기능을 하는 코드를 작성하지 못하게 한다. 리버스 엔지니어링이 필요한 소프트웨어의 경우 리버스 엔지니어링을 하면 그 결과를 말로 설명하는 문서로 만들고 그 문서만 보고 다른 사람이 구현한다.
2. GPL/LGPL 바이너리의 포함: 위반
이건 너무 명백하다. 위반이다.
kmp.zip에 GPL 및 LGPL 소프트웨어를 함께 배포하고 있으며 이들 소프트웨어에 대한 저작권 고지가 빠져 있다. (앞의 MPC 코드 논란 이후 GPL 전문은 포함하고 있다.) 그리고 소스코드 배포방법중 하나도 지키지 않고 있다.
맨 위 디렉토리에 눈에 보이는 것만 열거해도 GNU iconv - LGPL, xvid - GPL, liba52 - GPL, libdts - GPL, libfaac - GPL, libfaad - GPL, libmad - GPL, libmpeg2 - GPL이다. BSD-like 라이센스로 배포되는 theora/vorbis 라이브러리 역시 copyright notice는 유지해야 하는데 빠져 있다.
KMPlayer가 GPL 위반이 아니라고 말했던 어떤 글에서는, "KMP에 사용되는 외부 라이브러리는 소스 코드에 수정을 가하거나 변경하지 않았고, CVS 버전의 소스를 컴파일하거나 바이너리 버전을 가져다 사용했다"라고 했지만, GPL 소프트웨어를 수정했든 그대로 가져다가 사용했든 GPL version 2의 section 3에 제시된 방법으로 소스코드를 제공해야 한다는 사실은 변함이 없다.
3. 링크 호환성 문제: 아마도 위반
위의 라이브러리들이 GPL이라면 이것들과 링크한 건 괜찮을까? GPL 버전 2 section 2에 보면,
KMPlayer는 이들 DLL이 없이도 독립적으로 동작하므로 "separate and independent"라고 주장할 수도 있지 않을까? 역시 앞의 글을 보면 "KMP는 외부 라이브러리에 종속성을 가지지 않는다"라면서, DLL 없이 실행 파일인 KMPlayer.exe 파일만을 떼어놓고 실행해도 동작한다고 말한다. DLL은 부가 기능일 뿐이다.
하지만 이 DLL이 어느정도 종속되느냐, 부가기능이냐 핵심기능이냐의 문제도 링크가 호환되느냐의 여부와는 별로 관계가 없다. 이 KMPlayer.exe 파일은 이들 GPL 라이브러리의 DLL과 링크가 되어 있고 DLL의 함수들을 레퍼런스하고 있다. KMPlayer가 이 라이브러리들을 사용하는 정확한 메커니즘은 알 수 없지만 FSF의 GPL FAQ에 따르면, 단순히 플러그인이라도 링크한 그 라이센스가 GPL이면 문제가 된다. 논란의 여지는 있지만. 적어도 지금까지의 사례를 보면 (NextStep의 Objective C 사건 등) 링크한 소프트웨어는 개작으로 생각하고 GPL을 따르는 쪽으로 진행되어 왔다. 그래서 위반이라고 보인다.
결론: 위반 맞다
부디 GPL 소프트웨어를 개발에 사용하는 사람들은 라이센스 전문과 GPL FAQ를 읽어 보고 사용했으면 좋겠다.
애매한 부분을 빼면 위반이 악의적이거나 고의적이라고 보이지는 않는다. 하지만 앞의 2번째 사안인 GPL/LGPL 바이너리의 포함처럼 명백한 위반이 몇년간 방치된 일은 이해하기 힘들다. KMPlayer가 판도라에 매각된 후에 개발자의 글에는, "...우리나라에서는 아직 오픈 소스에 대해서 사람들의 의식이 장착되지 않았습니다"라는 말이 있다. 의식이 장착되지 않다니, 대체 누구부터 의식이 장착되지 않은 것인가?
이제 KMPlayer도 기업이 만들게 되었으니 문제점을 명백하게 짚고 넘어가길 바란다.
GPL 위반 논란이 있을 때마다 사람들은 쉽게 초점을 벗어나곤 한다. GPL을 위반했느냐 아니냐는 사실 여부를 판단하는 문제이다. 이 문제는 GPL이 허용하는 것과 허용하지 않는 것이 무엇인데, 당사자와 해당 소프트웨어가 어떻게 했는지 사실 관계를 확인하면 되는 것이다. 이 소프트웨어를 좋아하든 싫어하든, 실수로 그랬든 악의적으로 그랬든, GPL을 좋아하든 싫어하든, 개발자들이 어떤 노력을 했든, 결과적으로 공익에 좋은 영향을 미쳤든 악영향을 미쳤든 간에 라이센스 위반 여부와는 상관이 없다. 라이센스라고 해도 애매한 부분은 항상 있지만, 애매한 부분 역시 라이센스의 내용과 사실 관계에 의해서 판단할 문제이지 좋아하느냐 싫어하느냐 등 외적인 문제로 판단할 문제가 아니다.
1. MPC 코드 사용: 모르겠다
KMPlayer의 GPL 위반에 대해 가장 많이 논란이 된 부분은 MPC의 코드를 베껴오지 않았냐는 논란이었다.
이 논란에서는 좀 재미있는 점이, KMPlayer 개발자가 몹시 위험한 사실을 시인했다. "코드를 참고해서 델파이 코드를 작성했다"라고 말한 것이다. C++ 코드를 보고 델파이 코드를 작성했다면 그게 개작일까, 아닐까? 답은 그럴 수도 있고 아닐 수도 있다. 그때그때 다르고 뭐라고 말할 수 없다. 사용하는 프로그래밍 언어가 무엇인지는 중요하지 않다. 프로그래밍 언어가 다르다는 주장은, 소스 코드를 그대로 복사/붙여넣기하지는 않았다는 정도 이상의 근거가 되지 못한다.
논란의 구실을 제공하기 때문에 보통 소프트웨어를 개발할 때는 애초에 이런 애매한 상황을 만들지 않으려고 노력한다. 라이센스 논란이 있는 소프트웨어를 다시 작성할 경우에는, 라이센스 문제가 있는 어떤 코드를 한번 읽었다면 그 사람은 같은 기능을 하는 코드를 작성하지 못하게 한다. 리버스 엔지니어링이 필요한 소프트웨어의 경우 리버스 엔지니어링을 하면 그 결과를 말로 설명하는 문서로 만들고 그 문서만 보고 다른 사람이 구현한다.
2. GPL/LGPL 바이너리의 포함: 위반
이건 너무 명백하다. 위반이다.
kmp.zip에 GPL 및 LGPL 소프트웨어를 함께 배포하고 있으며 이들 소프트웨어에 대한 저작권 고지가 빠져 있다. (앞의 MPC 코드 논란 이후 GPL 전문은 포함하고 있다.) 그리고 소스코드 배포방법중 하나도 지키지 않고 있다.
맨 위 디렉토리에 눈에 보이는 것만 열거해도 GNU iconv - LGPL, xvid - GPL, liba52 - GPL, libdts - GPL, libfaac - GPL, libfaad - GPL, libmad - GPL, libmpeg2 - GPL이다. BSD-like 라이센스로 배포되는 theora/vorbis 라이브러리 역시 copyright notice는 유지해야 하는데 빠져 있다.
KMPlayer가 GPL 위반이 아니라고 말했던 어떤 글에서는, "KMP에 사용되는 외부 라이브러리는 소스 코드에 수정을 가하거나 변경하지 않았고, CVS 버전의 소스를 컴파일하거나 바이너리 버전을 가져다 사용했다"라고 했지만, GPL 소프트웨어를 수정했든 그대로 가져다가 사용했든 GPL version 2의 section 3에 제시된 방법으로 소스코드를 제공해야 한다는 사실은 변함이 없다.
3. 링크 호환성 문제: 아마도 위반
위의 라이브러리들이 GPL이라면 이것들과 링크한 건 괜찮을까? GPL 버전 2 section 2에 보면,
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. ...
KMPlayer는 이들 DLL이 없이도 독립적으로 동작하므로 "separate and independent"라고 주장할 수도 있지 않을까? 역시 앞의 글을 보면 "KMP는 외부 라이브러리에 종속성을 가지지 않는다"라면서, DLL 없이 실행 파일인 KMPlayer.exe 파일만을 떼어놓고 실행해도 동작한다고 말한다. DLL은 부가 기능일 뿐이다.
하지만 이 DLL이 어느정도 종속되느냐, 부가기능이냐 핵심기능이냐의 문제도 링크가 호환되느냐의 여부와는 별로 관계가 없다. 이 KMPlayer.exe 파일은 이들 GPL 라이브러리의 DLL과 링크가 되어 있고 DLL의 함수들을 레퍼런스하고 있다. KMPlayer가 이 라이브러리들을 사용하는 정확한 메커니즘은 알 수 없지만 FSF의 GPL FAQ에 따르면, 단순히 플러그인이라도 링크한 그 라이센스가 GPL이면 문제가 된다. 논란의 여지는 있지만. 적어도 지금까지의 사례를 보면 (NextStep의 Objective C 사건 등) 링크한 소프트웨어는 개작으로 생각하고 GPL을 따르는 쪽으로 진행되어 왔다. 그래서 위반이라고 보인다.
결론: 위반 맞다
부디 GPL 소프트웨어를 개발에 사용하는 사람들은 라이센스 전문과 GPL FAQ를 읽어 보고 사용했으면 좋겠다.
애매한 부분을 빼면 위반이 악의적이거나 고의적이라고 보이지는 않는다. 하지만 앞의 2번째 사안인 GPL/LGPL 바이너리의 포함처럼 명백한 위반이 몇년간 방치된 일은 이해하기 힘들다. KMPlayer가 판도라에 매각된 후에 개발자의 글에는, "...우리나라에서는 아직 오픈 소스에 대해서 사람들의 의식이 장착되지 않았습니다"라는 말이 있다. 의식이 장착되지 않다니, 대체 누구부터 의식이 장착되지 않은 것인가?
이제 KMPlayer도 기업이 만들게 되었으니 문제점을 명백하게 짚고 넘어가길 바란다.
2008년 4월 18일 금요일
GPL 버전2 3항(소스코드 공개 방법)의 불편함
GPL 버전2는 1991년에 개정됐습니다. 잠깐 기억을 되돌려봐도 당시에 인터넷이라는 건 미국 정부기관, 연구소, 대학들에서만 이용할 수 있는 장치였지 보편적인 장치가 아니었습니다. (국내에는 연결된 기관이 KAIST정도밖에 없었겠죠.) 가장 보편적으로 소스코드를 전달할 수 있는 매체는 물리적인 저장장치를 우편으로 전달하는 것이었습니다.
GPL 버전2의 3항은 그래서 이런 모습이 되어 버렸습니다. 3항은 a), b), c) 중 한 가지 방법으로 오브젝트에 대한 소스코드를 전달하도록 되어 있는데 a)는 함께 전달하는 것이고, b)는 3년간 소스코드를 물리적으로 전달한다고 보장하는 문서를 제공하는 것, c)는 비상업적인 용도에 한해 앞의 b)의 내용을 그대로 forward할 수 있다는 것입니다. 오브젝트 코드를 배포하지 않으면 아주 간단해 지지만, 배포한다면 소스코드를 같이 전달하거나 3년간 물리적인 소스코드 전달을 보장해야 합니다.
이 점은 오브젝트 코드를 배포해야 하는 업체들에게는 곤혹스러운데요. 제품과 함께 CD같은 미디어를 배포한다면 끼워넣으면 되지만, 제품에 따로 소스코드를 넣을 만한 여지가 없으면 물리적인 소스코드 전달을 보장해야 하는 번거로움이 있습니다. (물론 일반 리눅스 바이너리 CD를 판매하는 업체들도, 공식적으로 연락을 하고 우편요금을 지불하면 실제로 소스코드가 담긴 CD를 보내준다고 합니다. 물론 인터넷으로 받으면 되기 때문에 이게 되는지 일부러 실험하고 싶은 사람이 아니라면 일부러 요청할 필요가 없지만요.)
GPL 버전3은 이 부분이 보강되어 있습니다. 오브젝트와 같은 자격으로 접근할 수 있는 위치에 소스코드를 제공하는 것으로 (즉 URL을 쓰는 것으로) 조건을 만족할 수 있습니다. GPL 버전 2에선 이게 안 되고, 버전3에서만 됩니다. 시대의 변화를 반영한 이 부분은 매우 긍정적입니다. 오히려 버전3이 비지니스 프렌드리하지 않을까요.
문제는 리눅스 커널도 그렇고, BusyBox도 그렇고 "or (at your option) later version" 문구가 붙어 있지 않은 "GPL v2 only" 소프트웨어가 꽤 있어서 GPL v2는 쉽게 사라지지 않을 거고, 여전히 3년간 물리적인 매체를 통해 전달하는 보장을 해야 됩니다.
(업데이트)
참고 글: The GPL Has No (Networked) Future
GPL 버전2의 3항은 그래서 이런 모습이 되어 버렸습니다. 3항은 a), b), c) 중 한 가지 방법으로 오브젝트에 대한 소스코드를 전달하도록 되어 있는데 a)는 함께 전달하는 것이고, b)는 3년간 소스코드를 물리적으로 전달한다고 보장하는 문서를 제공하는 것, c)는 비상업적인 용도에 한해 앞의 b)의 내용을 그대로 forward할 수 있다는 것입니다. 오브젝트 코드를 배포하지 않으면 아주 간단해 지지만, 배포한다면 소스코드를 같이 전달하거나 3년간 물리적인 소스코드 전달을 보장해야 합니다.
이 점은 오브젝트 코드를 배포해야 하는 업체들에게는 곤혹스러운데요. 제품과 함께 CD같은 미디어를 배포한다면 끼워넣으면 되지만, 제품에 따로 소스코드를 넣을 만한 여지가 없으면 물리적인 소스코드 전달을 보장해야 하는 번거로움이 있습니다. (물론 일반 리눅스 바이너리 CD를 판매하는 업체들도, 공식적으로 연락을 하고 우편요금을 지불하면 실제로 소스코드가 담긴 CD를 보내준다고 합니다. 물론 인터넷으로 받으면 되기 때문에 이게 되는지 일부러 실험하고 싶은 사람이 아니라면 일부러 요청할 필요가 없지만요.)
GPL 버전3은 이 부분이 보강되어 있습니다. 오브젝트와 같은 자격으로 접근할 수 있는 위치에 소스코드를 제공하는 것으로 (즉 URL을 쓰는 것으로) 조건을 만족할 수 있습니다. GPL 버전 2에선 이게 안 되고, 버전3에서만 됩니다. 시대의 변화를 반영한 이 부분은 매우 긍정적입니다. 오히려 버전3이 비지니스 프렌드리하지 않을까요.
문제는 리눅스 커널도 그렇고, BusyBox도 그렇고 "or (at your option) later version" 문구가 붙어 있지 않은 "GPL v2 only" 소프트웨어가 꽤 있어서 GPL v2는 쉽게 사라지지 않을 거고, 여전히 3년간 물리적인 매체를 통해 전달하는 보장을 해야 됩니다.
(업데이트)
참고 글: The GPL Has No (Networked) Future
2008년 4월 10일 목요일
ipTIME의 GPL 위반
주식회사 이에프엠 네트웍스의 인터넷 공유기 ipTIME이 작년 7월 제시한 timeline과는 달리 계속해서 GPL을 위반하고 있습니다. 현재 라이센스 문제를 논의하는 구글그룹을 만들었고 ipTIME 문제를 정리하고 있습니다. 그룹에 가입해서 논의에 도움을 주세요.
http://groups.google.com/group/foss-legal-kr/web/efm-networks-iptime
저도 수년간 장비 업계에 있었고 앞으로도 그럴 가능성이 있기에, 이런 흐름이 만연되어 있는 부끄러운 모습을 계속 보고 넘길 수만은 없습니다.
더구나 ipTIME은 라이센스를 잘 몰랐다거나 실수였다거나 그런 것도 아니고, "대기업의 GPL 관련 위반은 영업비밀 유지며 당사와 같이 미약한 중소기업에만 이와 같은 규칙이 엄격하게 적용되어서는 불합리하다"라고, 알면서도 고의적으로 라이센스를 위반하고 있는 모습을 보이고 있습니다.
좀 더 진행되면 나중에 다른 위반 사례에 대해서도 해결을 시도해 보고자 합니다. 너무 많아서 한숨이 나옵니다만 분위기가 조성되면 알아서 지켜지겠지요.
http://groups.google.com/group/foss-legal-kr/web/efm-networks-iptime
저도 수년간 장비 업계에 있었고 앞으로도 그럴 가능성이 있기에, 이런 흐름이 만연되어 있는 부끄러운 모습을 계속 보고 넘길 수만은 없습니다.
더구나 ipTIME은 라이센스를 잘 몰랐다거나 실수였다거나 그런 것도 아니고, "대기업의 GPL 관련 위반은 영업비밀 유지며 당사와 같이 미약한 중소기업에만 이와 같은 규칙이 엄격하게 적용되어서는 불합리하다"라고, 알면서도 고의적으로 라이센스를 위반하고 있는 모습을 보이고 있습니다.
좀 더 진행되면 나중에 다른 위반 사례에 대해서도 해결을 시도해 보고자 합니다. 너무 많아서 한숨이 나옵니다만 분위기가 조성되면 알아서 지켜지겠지요.
2008년 3월 22일 토요일
그놈 2.22 gnome-font-viewer
2.22에서 특히 바뀐 점
원문은 팬그램(pangram)으로 유명한 The quick brown fox jumps over the lazy dog 문장이다. 그놈 2.20 이전에는 MS 윈도우즈가 했던 것처럼 "무궁화꽃이 피었습니다"라고 했었다. 그런데 알고 보니까 MS는 "무궁화꽃이 활짝 피었습니다"라고 쓰고 있었는데 "활짝"을 빼먹었다는 것... 약간 실망(?)을 하고 바꾸는 김에 다른 대안이 없을까 하다가 마침 "스폰지" TV 프로그램에서 팬그램에 대해 소개를 하다가 한글 자모별로 한번씩 사용한 이 팬그램 문장이 나오길래 쓰게 되었다. (무궁화꽃이 피었습니다 놀이가 일본 전래 놀이인 건 둘째치고라도... 요즘 애들은 길에서 많이 놀질 않아서 그래서인지 잘 알지도 못하는 것 같다.)
원문은 팬그램(pangram)으로 유명한 The quick brown fox jumps over the lazy dog 문장이다. 그놈 2.20 이전에는 MS 윈도우즈가 했던 것처럼 "무궁화꽃이 피었습니다"라고 했었다. 그런데 알고 보니까 MS는 "무궁화꽃이 활짝 피었습니다"라고 쓰고 있었는데 "활짝"을 빼먹었다는 것... 약간 실망(?)을 하고 바꾸는 김에 다른 대안이 없을까 하다가 마침 "스폰지" TV 프로그램에서 팬그램에 대해 소개를 하다가 한글 자모별로 한번씩 사용한 이 팬그램 문장이 나오길래 쓰게 되었다. (무궁화꽃이 피었습니다 놀이가 일본 전래 놀이인 건 둘째치고라도... 요즘 애들은 길에서 많이 놀질 않아서 그래서인지 잘 알지도 못하는 것 같다.)
2008년 2월 25일 월요일
네이트온 패키지
얼마간의 고민 끝에 pidgin-nateon을 패키징해서 데비안 메인에 업로드했다.
http://packages.debian.org/sid/pidgin-nateon
현재 리눅스에서 쓸 수 있는 네이트온 클라이언트는 세 가지가 있다. 공식 네이트온 (knateon), pidgin 플러그인, 그리고 자바로 만든 자테온. 그런데 세 프로젝트들 모두 패키징을 검토해 보았으나 모두 빌드 구조나 릴리즈 방식 따위가 부족한 점이 많아서 아쉽다.
http://packages.debian.org/sid/pidgin-nateon
현재 리눅스에서 쓸 수 있는 네이트온 클라이언트는 세 가지가 있다. 공식 네이트온 (knateon), pidgin 플러그인, 그리고 자바로 만든 자테온. 그런데 세 프로젝트들 모두 패키징을 검토해 보았으나 모두 빌드 구조나 릴리즈 방식 따위가 부족한 점이 많아서 아쉽다.
2008년 2월 19일 화요일
여행자를 위한 데비안 미러 사이트
여행을 다녀서 빠른 데비안 미러 설정에 그때그때 고민된다면 이제 cdn.debian.net을 사용하면 된다.
카이스트 네트워크 뒤집히는 일이 많다는 거야 학교 다닐 때에도 많이 겪은 일이긴 하지만, 현재 카이스트 미러는 주5일제라는 우스개소리를 할 정도로 너무 사고가 많다. 이제 제발 휴일에 죽어버리는 일 좀 그만 일어났으면...
$ host cdn.debian.netgeoip 결과에 따라 가까이 있는 미러값을 리턴해 준다. 위의 값은 ftp.kr.debian.org로 되어 있는 카이스트 미러.
cdn.debian.net is an alias for deb.cdn.araki.net.
deb.cdn.araki.net has address 143.248.234.110
$
카이스트 네트워크 뒤집히는 일이 많다는 거야 학교 다닐 때에도 많이 겪은 일이긴 하지만, 현재 카이스트 미러는 주5일제라는 우스개소리를 할 정도로 너무 사고가 많다. 이제 제발 휴일에 죽어버리는 일 좀 그만 일어났으면...
2008년 2월 4일 월요일
dpkg 1.10.25 (2004년)
dpkg (1.10.25) unstable; urgency=low
The "你他媽的天下所有的人都該死" Release.
This release is to correct the mangled Simplified Chinese translation
included in 1.10.24 caused by rebellion of the translator's mail client.
* Updated Translations (Christian Perrier):
- Dutch (Bart Cornelis). Closes: #278700.
- Polish (Bartosz Fenski). Closes: #280406.
- Simplified Chinese (Tchaikov, Carlos Liu). Closes: #278676.
-- Scott James Remnant <scott@ netsplit.com> Thu, 11 Nov 2004 20:06:57 +0000
2008년 2월 3일 일요일
데비안 패키지의 VCS 사용
오래됐지만, 예전에 썼던 것처럼 모든 패키지를 소스 컨트롤에 올렸다.
그와 함께 한국어 관련 패키지들을 l10n-korean 프로젝트의 git repository에 올려놓았다. (l10n-korean/*.git 페이지) 희망사항은 한국어 관련 패키지들의 공동 관리 체제로 가는 것인데.. 충분히 참여할 사람이 있을 지는 아직 미지수이다. (의향이 있으면 alioth의 l10n-korean 프로젝트에 신청하시길.)
이제 debcheckout으로 패키지의 소스 컨트롤 시스템에서 직접 받아올 수 있다는 거!
그와 함께 한국어 관련 패키지들을 l10n-korean 프로젝트의 git repository에 올려놓았다. (l10n-korean/*.git 페이지) 희망사항은 한국어 관련 패키지들의 공동 관리 체제로 가는 것인데.. 충분히 참여할 사람이 있을 지는 아직 미지수이다. (의향이 있으면 alioth의 l10n-korean 프로젝트에 신청하시길.)
이제 debcheckout으로 패키지의 소스 컨트롤 시스템에서 직접 받아올 수 있다는 거!
duncan:~/debian/l10n-korean/tmp$ debcheckout libhangul
declared git repository at git://git.debian.org/git/l10n-korean/libhangul.git
git clone git://git.debian.org/git/l10n-korean/libhangul.git libhangul ...
Initialized empty Git repository in /home/cwryu/debian/l10n-korean/tmp/libhangul/.git/
remote: Generating pack...
remote: Done counting 156 objects.
remote: Deltifying 156 objects...
remote:
Indexing 156 objects...
remote: Total 156 (delta 70), reused 50 (delta 9)
100% (156/156) done
Resolving 70 deltas...
100% (70/70) done
duncan:~/debian/l10n-korean/tmp$ ls libhangul/
AUTHORS Makefile.in compat configure* hangul/ test/
COPYING NEWS compile* configure.ac install-sh*
ChangeLog README config.guess* data/ libhangul.pc.in
INSTALL aclocal.m4 config.h.in debian/ ltmain.sh
Makefile.am bindings/ config.sub* depcomp* missing*
2008년 1월 18일 금요일
OSS 정책 보기 - 공개SW 유지보수 가이드라인 시행
기사 - 공개SW 유지보수 첫해부터 유료화 (디지털타임즈)
그동안 관련 업체들의 불만으로 지적했던 것이 유지보수 비용을 소프트웨어 패키지 가격의 일정 퍼센트로 계산하는 관행때문이었다. OSS라는 이유로 소프트웨어 가격이 0에 가깝게 책정되면서 유지보수 비용도 0가 된다면 곤란하기 짝이 없다. 그래서 공급업체들은 무리하게 가격이 높은 레드햇을 공급하거나 번들로 불필요하게 독점 소프트웨어를 공급하거나 하드웨어 공급을 통해 매출과 이익을 올리는 편법을 사용해 왔다.
새로 도입된 정책을 환영한다. 오히려 지금에서야 가이드라인이 나온 건 너무 시간을 오래 끌었다는 느낌이다. 꾸준히 공공사업에 참여하는 업체들의 불만이 터져나왔고 몇 년 전부터 마련하려고 했던 사항이기 때문이다. (기사 2004년 - 공개SW 유지보수체계 만든다 (전자신문), 기사 2006년 - 개발 SW 유지보수 비용 현실화 빠르면 내년부터)
(이것 말고도 몇년 씩 끌고 있는 정책이 정보통신부의 폐지때문에 사라지는 건 아닐지 좀 걱정도 된다..)
그동안 관련 업체들의 불만으로 지적했던 것이 유지보수 비용을 소프트웨어 패키지 가격의 일정 퍼센트로 계산하는 관행때문이었다. OSS라는 이유로 소프트웨어 가격이 0에 가깝게 책정되면서 유지보수 비용도 0가 된다면 곤란하기 짝이 없다. 그래서 공급업체들은 무리하게 가격이 높은 레드햇을 공급하거나 번들로 불필요하게 독점 소프트웨어를 공급하거나 하드웨어 공급을 통해 매출과 이익을 올리는 편법을 사용해 왔다.
새로 도입된 정책을 환영한다. 오히려 지금에서야 가이드라인이 나온 건 너무 시간을 오래 끌었다는 느낌이다. 꾸준히 공공사업에 참여하는 업체들의 불만이 터져나왔고 몇 년 전부터 마련하려고 했던 사항이기 때문이다. (기사 2004년 - 공개SW 유지보수체계 만든다 (전자신문), 기사 2006년 - 개발 SW 유지보수 비용 현실화 빠르면 내년부터)
(이것 말고도 몇년 씩 끌고 있는 정책이 정보통신부의 폐지때문에 사라지는 건 아닐지 좀 걱정도 된다..)
2008년 1월 12일 토요일
OSS 정책 - 부요, 필요할까
지난 글들에 이어,
과거에 마이크로소프트웨어 기사 및 각종 인터뷰를 통해 말한 바에 따르면, 부요의 입안자들은 국내 OSS 산업이 활성화되지 않는 원인을 "(1) 많은 소프트웨어 중에서 선택이 어려움", "(2) 기술지원 부재", "(3) 외국 업체 선호"라고 분석했고. 그래서 배포판 표준이 필요하다고 주장하고 있다. 일반 소비자나 기업도 이런 분석을 믿지 않았을 것은 물론이고, 분석안을 내 놓은 정책 입안자들도 사실이라고 생각하지 않았을 것이다. 아마도 "배포판"이라는 결론을 내린 다음에 그럴듯한 원인을 짜깁기했겠지만, 정말로 이런 분석을 했다면 배포판을 만들진 않았을 것이다.
산업 육성 정책
한국 정부는 과거부터 어떤 산업을 육성하려고 한정된 기업들에게 직간접적으로 자금을 지원하고, 제도의 정비를 통해 시장 분위기를 조성하고 보호 장벽을 만들어서 한동안 어느 정도의 수요를 보장하는 정책을 사용했다. 얼핏 듣기에는 부질없어 보이지만 정부는 매우 능숙하게 그런 경제 정책을 해 왔고 실제로 꽤 많은 성공을 거두었다. 철강, 조선, 가전, 자동차, 반도체, 휴대전화 모두 그렇게 정부 주도로 시장을 만들어 내고 보호된 시장 내에서 기업을 키워내는 방법을 사용했다. 요즘에는 과거만큼 약빨이 잘 먹히지 않는 것 같지만.
부요라는 정책도 이 전통적인 국가 주도의 산업 육성 전략에서 벗어나지 않는다. 정부 주도로 하나의 틀을 만들고 (리눅스 표준), 그 틀 안에서 국내 업체를 직간접적으로 지원하고 (표준 배포판 제작 업체), 어느 정도의 수요를 일부러 보장해서 (공공기관의 리눅스 전환 등) 업체들이 성장하는 기반을 만드는 것이다.
부요는 그런 면에서 아직 정책이 완성되지 않았다. "부요"의 표면에 보이는 표준 제정과 업체 지원까지는 진행되었지만, 부차적으로 기업들을 살찌우는데 필요한 "어느 정도의 수요를 일부러 보장"하는 일이 아직 진행되지 않았기 때문이다. (소프트웨어진흥원의 공공기관/교육기관의 공개 소프트웨어 전환 사업과 관련이 있다.) 그래서 성급한 부정적인 평가도 경계해야 겠지만, 현재 하는 것처럼 언론을 통해 자화자찬식으로 정책을 평가하는 것도 곤란하다. 그래서 부요가 수년을 끌어왔음에도 불구하고, 부요에 대한 문제 제기는 미래에 어떻게 될 것인가에 대한 걱정이 된다. 첫째로 정말 이런 산업 육성 정책이 정보 산업에 효과가 있을 것인가라는 의문을 제기하고 싶고, 둘째로 이 정책때문에 오히려 성장의 방향이 왜곡되지 않을까 하는 걱정이 앞선다.
이미 개방된 시장에 장벽 쌓기
이러한 방식의 기획성 산업육성 정책은 리눅스 배포판에 적용되기 힘들다고 생각한다.
리눅스 배포판은 이미 다른 어떠한 시장보다도 개방되어 있다. APT와 YUM같은 업데이트 프로그램으로 무장한 리눅스 배포판 사용자들은, 한국을 포함한, 전세계에서 만든 소프트웨어를 매일같이 다운로드하고 있다. 단지 소프트웨어를 받아보는 것뿐만 아니라 의견을 보내기도 하고, 반대로 의견을 받아서 소프트웨어를 만들기도 하고 계속해서 교류하고 있다. "외산 리눅스"라는 말을 붙이는 게 어색할 정도로 국경의 의미가 무색하고 유통의 제약도 없다. (만드리바는 어느나라 제품이고 수세는 어느나라 제품인지 기억도 희미하다.) 그래서 어떤 기업이든 리눅스 배포판을 만든다면 지구상의 거의 모든 배포판과 같은 위치에서 평가받을 수밖에 없다. 기업용으로 기술지원이라든지 교육같은 이슈가 있긴 하지만, 그것 역시 국내의 리셀러나 서비스 전문 회사와 같은 위치에서 경쟁할 수밖에 없다.
부요는 이러한 개방된 시장에 철지난 폐쇄적 배포판 정책을 들고 나왔다. 여타 산업 육성 정책이 그랬던 것처럼 이들 부요 배포판 기업을 지원함으로써 경쟁력이 생길까? 그렇지 않다고 생각한다. 다른 분야와는 다르게 리눅스 배포판에 관련해 쌓을 수 있는 장벽은 공공시장뿐이고, 다른 개인/기업 분야의 배포판은 여전히 레드햇, 노벨수세와 같은 기준에서 경쟁해야 한다.
공공 시장의 폐쇄화에 대한 우려
그럼에도 불구하고 필요성을 인정하는 사람도 있고, 군침을 흘리고 있는 기업도 있는 이유는 공공시장 때문이다.공공 시장의 리눅스를 위한 기준을 마련해야 하기 때문에 부요의 필요성을 인정하는 사람이 많고, 또 한국 정부의 지출은 지금도 큰 편이지만, 앞으로 성장할 가능성이 매우 높다. (정부 지출은 GDP의 20% 정도로 다른 국가와 비교해보면 아직 낮은 수치이고, 그 중에서 정보통신 관련 지출 비중은 갈수록 늘고 있다.)
먼저 공공 시장의 기준에 관해서.. 그게 부요 표준이 됐든, FHS가 됐든 어떤 기준이 필요하다는 데는 동의한다. 만약 부요가 단순한 표준과 인증으로 구성되었다면 공공기관의 기준으로서 부요에 대해 박수를 보내겠다. 하지만 실제 부요는 전에 말한 것처럼 표준인지 소프트웨어인지 딱 잘라서 말하기 어려운 국내 기업 밀어주기 정책으로, 부요 인증을 받는 게 쉬운 일이 아니다. 정말 공공 시장의 기준이 되려는 게 목적이라면 장벽을 낮춰서, 표준도 좀 더 단순 명확하게 하고 인증도 LSB처럼 저렴한 비용으로 단순하고 명확한 검사를 통해 인증할 수 있어야 한다.
또 공공 시장에 부요의 수요가 보장된다면 국내 기업 입장에선 꽤 괜찮겠지만, 일반 시장의 현실과 다른 왜곡된 시장을 만들어낼 수 있다. 민간 시장과는 다르게 유별난 공공 기관의 아래아한글 수요를 생각해 보면 알 수 있다. 부요를 계속해서 업데이트하면서 리눅스 배포판의 트렌드에서 벗어나지 않게 유지될 수 있을까?
인위적인 시장은 그만
최근 그놈 데스크탑은 같은 2.x 버전이면서도 수많은 인터페이스가 바뀌었다. 한국어 번역도 나 혹은 다른 번역자가 내부적으로 기준을 바꾼 것도 있고 우연히 바뀐 것도 있다. 그런데 최근에 릴리스한 그놈 데스크탑과 부요 데스크탑 2.0 표준을 비교해 보면... 최신 그놈 데스크탑을 채용하면 죄다 부요 표준에서 어긋난다! 인터페이스도 많이 바뀌었고 번역에서 사용하는 용어도 많이 바뀌었다. 자유로운 생각에서 개발하는 소프트웨어를 가지고 기준을 만들고 재단하기 위해 그놈 인터페이스를 보면서 문서로 받아적은 결과이다. 부요를 표준으로 유지하기 위해 매번 그놈이 릴리스할 때마다 재빠르게 표준을 개정하기라도 할 것인가, 아니면 코드나 번역을 옛날 버전으로 일부러 되돌리기라도 할 것인가?
정부주도의 산업육성 정책은 한 시장을 키울 수도 있지만, 가만히 두면 빠르든 느리든 잘 발전할 시장을 망가뜨리기도 하고 발목을 잡기도 한다. 앞에서 예를 든 그놈 데스크탑의 인터페이스 변화는 작은 부분이다. "공개SW" 지원 정책을 쓰려면 장벽을 낮추고 불공정한 제도를 개선하는 데 앞장서야지, 부요와 같은 방법으로 소프트웨어 자체를 제도적으로 만드려고 해서는 곤란하다고 생각한다.
비행기 조종 실습생들은 창백해진 손으로 조정관을 꼭 움켜쥘 때가 많다. 교관들은 손에서 힘을 빼라고 가르친다. 과잉조정은 과소소정에 못지 않게 위험한 것이다. 오는날 소련 등 여러 나라의 위기가 보여주는 바와 같이 국민과 경제를 과잉통제하고자 하는 국가는 결국은 국가가 추구하는 질서 자체를 파괴하게 된다. 간섭을 적게 하는 국가가 가장 많은 것을 성취하고 그 과정에서 자신의 권력을 고양시키게 될 것이다. - 앨빈토플러, 권력이동(1992) 중에서
과거에 마이크로소프트웨어 기사 및 각종 인터뷰를 통해 말한 바에 따르면, 부요의 입안자들은 국내 OSS 산업이 활성화되지 않는 원인을 "(1) 많은 소프트웨어 중에서 선택이 어려움", "(2) 기술지원 부재", "(3) 외국 업체 선호"라고 분석했고. 그래서 배포판 표준이 필요하다고 주장하고 있다. 일반 소비자나 기업도 이런 분석을 믿지 않았을 것은 물론이고, 분석안을 내 놓은 정책 입안자들도 사실이라고 생각하지 않았을 것이다. 아마도 "배포판"이라는 결론을 내린 다음에 그럴듯한 원인을 짜깁기했겠지만, 정말로 이런 분석을 했다면 배포판을 만들진 않았을 것이다.
산업 육성 정책
한국 정부는 과거부터 어떤 산업을 육성하려고 한정된 기업들에게 직간접적으로 자금을 지원하고, 제도의 정비를 통해 시장 분위기를 조성하고 보호 장벽을 만들어서 한동안 어느 정도의 수요를 보장하는 정책을 사용했다. 얼핏 듣기에는 부질없어 보이지만 정부는 매우 능숙하게 그런 경제 정책을 해 왔고 실제로 꽤 많은 성공을 거두었다. 철강, 조선, 가전, 자동차, 반도체, 휴대전화 모두 그렇게 정부 주도로 시장을 만들어 내고 보호된 시장 내에서 기업을 키워내는 방법을 사용했다. 요즘에는 과거만큼 약빨이 잘 먹히지 않는 것 같지만.
부요라는 정책도 이 전통적인 국가 주도의 산업 육성 전략에서 벗어나지 않는다. 정부 주도로 하나의 틀을 만들고 (리눅스 표준), 그 틀 안에서 국내 업체를 직간접적으로 지원하고 (표준 배포판 제작 업체), 어느 정도의 수요를 일부러 보장해서 (공공기관의 리눅스 전환 등) 업체들이 성장하는 기반을 만드는 것이다.
부요는 그런 면에서 아직 정책이 완성되지 않았다. "부요"의 표면에 보이는 표준 제정과 업체 지원까지는 진행되었지만, 부차적으로 기업들을 살찌우는데 필요한 "어느 정도의 수요를 일부러 보장"하는 일이 아직 진행되지 않았기 때문이다. (소프트웨어진흥원의 공공기관/교육기관의 공개 소프트웨어 전환 사업과 관련이 있다.) 그래서 성급한 부정적인 평가도 경계해야 겠지만, 현재 하는 것처럼 언론을 통해 자화자찬식으로 정책을 평가하는 것도 곤란하다. 그래서 부요가 수년을 끌어왔음에도 불구하고, 부요에 대한 문제 제기는 미래에 어떻게 될 것인가에 대한 걱정이 된다. 첫째로 정말 이런 산업 육성 정책이 정보 산업에 효과가 있을 것인가라는 의문을 제기하고 싶고, 둘째로 이 정책때문에 오히려 성장의 방향이 왜곡되지 않을까 하는 걱정이 앞선다.
이미 개방된 시장에 장벽 쌓기
이러한 방식의 기획성 산업육성 정책은 리눅스 배포판에 적용되기 힘들다고 생각한다.
리눅스 배포판은 이미 다른 어떠한 시장보다도 개방되어 있다. APT와 YUM같은 업데이트 프로그램으로 무장한 리눅스 배포판 사용자들은, 한국을 포함한, 전세계에서 만든 소프트웨어를 매일같이 다운로드하고 있다. 단지 소프트웨어를 받아보는 것뿐만 아니라 의견을 보내기도 하고, 반대로 의견을 받아서 소프트웨어를 만들기도 하고 계속해서 교류하고 있다. "외산 리눅스"라는 말을 붙이는 게 어색할 정도로 국경의 의미가 무색하고 유통의 제약도 없다. (만드리바는 어느나라 제품이고 수세는 어느나라 제품인지 기억도 희미하다.) 그래서 어떤 기업이든 리눅스 배포판을 만든다면 지구상의 거의 모든 배포판과 같은 위치에서 평가받을 수밖에 없다. 기업용으로 기술지원이라든지 교육같은 이슈가 있긴 하지만, 그것 역시 국내의 리셀러나 서비스 전문 회사와 같은 위치에서 경쟁할 수밖에 없다.
부요는 이러한 개방된 시장에 철지난 폐쇄적 배포판 정책을 들고 나왔다. 여타 산업 육성 정책이 그랬던 것처럼 이들 부요 배포판 기업을 지원함으로써 경쟁력이 생길까? 그렇지 않다고 생각한다. 다른 분야와는 다르게 리눅스 배포판에 관련해 쌓을 수 있는 장벽은 공공시장뿐이고, 다른 개인/기업 분야의 배포판은 여전히 레드햇, 노벨수세와 같은 기준에서 경쟁해야 한다.
공공 시장의 폐쇄화에 대한 우려
그럼에도 불구하고 필요성을 인정하는 사람도 있고, 군침을 흘리고 있는 기업도 있는 이유는 공공시장 때문이다.공공 시장의 리눅스를 위한 기준을 마련해야 하기 때문에 부요의 필요성을 인정하는 사람이 많고, 또 한국 정부의 지출은 지금도 큰 편이지만, 앞으로 성장할 가능성이 매우 높다. (정부 지출은 GDP의 20% 정도로 다른 국가와 비교해보면 아직 낮은 수치이고, 그 중에서 정보통신 관련 지출 비중은 갈수록 늘고 있다.)
먼저 공공 시장의 기준에 관해서.. 그게 부요 표준이 됐든, FHS가 됐든 어떤 기준이 필요하다는 데는 동의한다. 만약 부요가 단순한 표준과 인증으로 구성되었다면 공공기관의 기준으로서 부요에 대해 박수를 보내겠다. 하지만 실제 부요는 전에 말한 것처럼 표준인지 소프트웨어인지 딱 잘라서 말하기 어려운 국내 기업 밀어주기 정책으로, 부요 인증을 받는 게 쉬운 일이 아니다. 정말 공공 시장의 기준이 되려는 게 목적이라면 장벽을 낮춰서, 표준도 좀 더 단순 명확하게 하고 인증도 LSB처럼 저렴한 비용으로 단순하고 명확한 검사를 통해 인증할 수 있어야 한다.
또 공공 시장에 부요의 수요가 보장된다면 국내 기업 입장에선 꽤 괜찮겠지만, 일반 시장의 현실과 다른 왜곡된 시장을 만들어낼 수 있다. 민간 시장과는 다르게 유별난 공공 기관의 아래아한글 수요를 생각해 보면 알 수 있다. 부요를 계속해서 업데이트하면서 리눅스 배포판의 트렌드에서 벗어나지 않게 유지될 수 있을까?
인위적인 시장은 그만
최근 그놈 데스크탑은 같은 2.x 버전이면서도 수많은 인터페이스가 바뀌었다. 한국어 번역도 나 혹은 다른 번역자가 내부적으로 기준을 바꾼 것도 있고 우연히 바뀐 것도 있다. 그런데 최근에 릴리스한 그놈 데스크탑과 부요 데스크탑 2.0 표준을 비교해 보면... 최신 그놈 데스크탑을 채용하면 죄다 부요 표준에서 어긋난다! 인터페이스도 많이 바뀌었고 번역에서 사용하는 용어도 많이 바뀌었다. 자유로운 생각에서 개발하는 소프트웨어를 가지고 기준을 만들고 재단하기 위해 그놈 인터페이스를 보면서 문서로 받아적은 결과이다. 부요를 표준으로 유지하기 위해 매번 그놈이 릴리스할 때마다 재빠르게 표준을 개정하기라도 할 것인가, 아니면 코드나 번역을 옛날 버전으로 일부러 되돌리기라도 할 것인가?
정부주도의 산업육성 정책은 한 시장을 키울 수도 있지만, 가만히 두면 빠르든 느리든 잘 발전할 시장을 망가뜨리기도 하고 발목을 잡기도 한다. 앞에서 예를 든 그놈 데스크탑의 인터페이스 변화는 작은 부분이다. "공개SW" 지원 정책을 쓰려면 장벽을 낮추고 불공정한 제도를 개선하는 데 앞장서야지, 부요와 같은 방법으로 소프트웨어 자체를 제도적으로 만드려고 해서는 곤란하다고 생각한다.
2008년 1월 2일 수요일
맘대로 예언 2008 (?)
연시를 맞아 수많은 올해 예언 시리즈가 나오는 바, FL/OSS 세계에 대해 올해 벌어질 일들에 대해 써 보려고 한다. OOXML, DRM, GPLv3 적용 등등 FL/OSS 분야의 큰 뉴스거리가 될 만한 이야기는 이런 예언을 보면 될 것이고, 기술 분야에 대한 광범위한 예언은 이런 예언을 봐도 될 것이지만... 국내의 이야기나 직접 관계있고 당장 생각나는 이야기들을 모아본다.
생각나는 대로 뽑아 봤기 때문에 결론은 내리지 않고 문제만 제기하는 것으로 대신하려고 한다.
그놈이 그놈?
언제나처럼 그놈 데스크탑이 3월과 9월에 릴리스될 것이다. (너무 뻔한 얘기?) 그놈 데스크탑 L10N의 과제에서 말했던 도움말 번역 부분은 2007년에 일단 시작을 했다는 것만으로 만족해야 겠지만, 2008년은 한국어 L10N에 관해서도 더더욱 많은 문서와, 충실한 번역과, 나은 품질의 번역이 들어갈 것이다. 어느정도나 "더"일지는 참여자들이 얼마나 더 많이, 더 적극적으로 하느냐에 달려 있다. :)
새로운 글꼴?
한편 작년에 뉴스로 나왔던, 2008년 6월까지 개발할 것이라고 하는 NHN의 글꼴이 (계속 진행중이라면) 기대된다. 부디 사악하지 않은 라이선스로 자유롭게 배포/수정할 수 있기를..
지역화 개발
맞춤법검사, 사전 구축, TTS 등 손쓰기 어려운 한국어 관련 신규 개발 이슈 중에서 어느 하나라도 진전이 있지 않을까? (품사태깅 기능은 KPC에서 필요한데...)
리눅스 탑재 장난감들, 한국에 출시될까?
Asus EEE PC - 수입가격과 국내 수요가 문제.
구글 안드로이드 탑재 휴대전화 - 국내 제조업체중 하나가 만들 건 분명해 보이는데, 국내 출시는 미지수.
Nokia N800/N810 - 이건 몇년 됐고 2008년도 안 될 것 같지만 희망사항으로 일단 적어놓고...
리눅스 탑재 WiFi/VoIP 전화기들 - 이것도 희망사항.
오픈웹 vs 금결원 소송의 결과와 그 이후?
오픈웹과 금결원 소송은 작년 초에도 2007년에 어느정도 결론이 나올 거라고 생각했는데 2008년으로 넘어왔다. 합의가 안 될거라고 어느정도 예상했다. 공공기관은 소송의 피고가 되었을 때 합의해서 생긴 손해를 담당자가 책임진다고 생각하고 패소해서 생긴 손해를 조직 전체가 감수한다고 생각해서인지, 지는 입장에서는 최종 소송까지 가는 선택을 하는 게 보통이다. 금결원 소송이 결론이 나면 다른 기관을 상대로도 진행이 될까?
이제 리눅스에서 웹질을 할 만해 질까?
2000년대초에 비하면 나아졌지만, 플래시 비디오인 척 하는 activex 사이트가 (uccc, 판도라tv) 등장하질 않나, 플래시가 만능이라고 플래시로 이상하게 만들어서 문제를 일으키는 사이트가 (MBC) 등장하질 않나, 어떻게 한 건지 몰라도 리눅스용 플래시에서만 잘 죽게 만든 플래시 비디오 사이트가 (엠엔캐스트) 등장하기도 하고 시련은 끊기지 않았다. 하지만 언터처블이라고 생각했던 전자정부가 2007년 초에 표준준수 원칙을 공표했고 제한적이나마 ia32 리눅스를 지원하기 시작하는 걸 보면 새로운 시련이 닥치더라도 영원히 가는 시련은 없을 것이고 만족스러운 속도는 아니겠지만 조금씩이나마 개선될 것 같은 생각이 든다. 2008년에는 그놈 애플리케이션과 최근의 웹 서비스들과의 연동 문제를 개선하는 데도 참여하고 싶다.
GPL 위반 기업은 언제까지?
GPL 위반에 대해 무감각했던 한국 기업들은 올해에는 얼마나 솔직해 질 수 있을까? (1, 2, ...) 오래전도 아니고 2년 전에, 바로 한국에서, 꽤 유명한 리눅스 기반 휴대용 게임기인 GP2X를 만든 (주)게임파크홀딩스는 "GPL을 위반했다"는 정도가 아니라 "GPL을 이해하지 못한다"는 비아냥을 받은 적이 있다. 우여곡절 끝에 게임파크는 제대로 개발포럼에 소스코드와 SDK를 릴리스했고 GP2X는 지금도 매니아들에게 꽤 괜찮은 홈브루 게임기로 판매되고 있다. 이제 GPL 이슈를 생각도 안 하거나 고의로 무시하는 기업들은 정신 차려야 할 일이다..
"공개SW" 정책은 어떻게?
"open source"라는 말이 "free software"가 듣기에 불편해서 새로 만든 용어임에도 불구하고, 오픈소스라는 말조차도 듣기 불편했는지 한국 정부가 새로 만든 물타기용 용어, "공개SW". 공개SW 활성화 정책 중에서도 실행 과정에서 가시밭길을 걸어왔으면서 부풀리기도 힘들 정도로 성적이 초라했던 (하지만 실행되면 효과는 클 것 같은) "공공기관의 공개SW 도입"이 2008년에는 얼마나 실행될 수 있을까? 아니면 새 정부 들어서 이 쪽 정책이 방향이 완전히 바뀔 가능성은?
한편 지금까지의 정책은 너무 쉬운 방법의 단기적인 예산 집행에 급급했던 게 아쉬웠다. 아쉬웠던 제도적 개선도 이루어졌으면 한다.
북한이 눈에 뜨일까?
6자회담에서 북한의 테러지원국 해제 문제가 순탄치 못하더니 결국 2008년으로 넘어왔다. 갑자기 왠 외교 문제냐 하겠지만 FL/OSS 세계에 마치 북한이 존재하지 않는 것처럼 보이는 이유는, 다른 이유도 있지만 미국의 테러지원국 지정때문에 미국 및 미국과 관련 조약을 맺은 (한국을 비롯한) 국가에서 소프트웨어를 수출하는 게 불법이기 때문이기도 했다. 조금씩 들려오는 말들을 보면, 북쪽은 리눅스 관련 개발도 하고 배포판까지 만들어 쓰고 있다. 폐쇄성과 낮은 컴퓨터/인터넷 보급때문에 (그리고 아마도 남쪽보다도 참여의 문화가 부족할 것이므로) 녹록치 않겠지만, 제도적인 장벽이 사라지면 조금씩 업스트림에 북한이 모습을 드러낼 수 있을까?
생각나는 대로 뽑아 봤기 때문에 결론은 내리지 않고 문제만 제기하는 것으로 대신하려고 한다.
그놈이 그놈?
언제나처럼 그놈 데스크탑이 3월과 9월에 릴리스될 것이다. (너무 뻔한 얘기?) 그놈 데스크탑 L10N의 과제에서 말했던 도움말 번역 부분은 2007년에 일단 시작을 했다는 것만으로 만족해야 겠지만, 2008년은 한국어 L10N에 관해서도 더더욱 많은 문서와, 충실한 번역과, 나은 품질의 번역이 들어갈 것이다. 어느정도나 "더"일지는 참여자들이 얼마나 더 많이, 더 적극적으로 하느냐에 달려 있다. :)
새로운 글꼴?
한편 작년에 뉴스로 나왔던, 2008년 6월까지 개발할 것이라고 하는 NHN의 글꼴이 (계속 진행중이라면) 기대된다. 부디 사악하지 않은 라이선스로 자유롭게 배포/수정할 수 있기를..
지역화 개발
맞춤법검사, 사전 구축, TTS 등 손쓰기 어려운 한국어 관련 신규 개발 이슈 중에서 어느 하나라도 진전이 있지 않을까? (품사태깅 기능은 KPC에서 필요한데...)
리눅스 탑재 장난감들, 한국에 출시될까?
Asus EEE PC - 수입가격과 국내 수요가 문제.
구글 안드로이드 탑재 휴대전화 - 국내 제조업체중 하나가 만들 건 분명해 보이는데, 국내 출시는 미지수.
Nokia N800/N810 - 이건 몇년 됐고 2008년도 안 될 것 같지만 희망사항으로 일단 적어놓고...
리눅스 탑재 WiFi/VoIP 전화기들 - 이것도 희망사항.
오픈웹 vs 금결원 소송의 결과와 그 이후?
오픈웹과 금결원 소송은 작년 초에도 2007년에 어느정도 결론이 나올 거라고 생각했는데 2008년으로 넘어왔다. 합의가 안 될거라고 어느정도 예상했다. 공공기관은 소송의 피고가 되었을 때 합의해서 생긴 손해를 담당자가 책임진다고 생각하고 패소해서 생긴 손해를 조직 전체가 감수한다고 생각해서인지, 지는 입장에서는 최종 소송까지 가는 선택을 하는 게 보통이다. 금결원 소송이 결론이 나면 다른 기관을 상대로도 진행이 될까?
이제 리눅스에서 웹질을 할 만해 질까?
2000년대초에 비하면 나아졌지만, 플래시 비디오인 척 하는 activex 사이트가 (uccc, 판도라tv) 등장하질 않나, 플래시가 만능이라고 플래시로 이상하게 만들어서 문제를 일으키는 사이트가 (MBC) 등장하질 않나, 어떻게 한 건지 몰라도 리눅스용 플래시에서만 잘 죽게 만든 플래시 비디오 사이트가 (엠엔캐스트) 등장하기도 하고 시련은 끊기지 않았다. 하지만 언터처블이라고 생각했던 전자정부가 2007년 초에 표준준수 원칙을 공표했고 제한적이나마 ia32 리눅스를 지원하기 시작하는 걸 보면 새로운 시련이 닥치더라도 영원히 가는 시련은 없을 것이고 만족스러운 속도는 아니겠지만 조금씩이나마 개선될 것 같은 생각이 든다. 2008년에는 그놈 애플리케이션과 최근의 웹 서비스들과의 연동 문제를 개선하는 데도 참여하고 싶다.
GPL 위반 기업은 언제까지?
GPL 위반에 대해 무감각했던 한국 기업들은 올해에는 얼마나 솔직해 질 수 있을까? (1, 2, ...) 오래전도 아니고 2년 전에, 바로 한국에서, 꽤 유명한 리눅스 기반 휴대용 게임기인 GP2X를 만든 (주)게임파크홀딩스는 "GPL을 위반했다"는 정도가 아니라 "GPL을 이해하지 못한다"는 비아냥을 받은 적이 있다. 우여곡절 끝에 게임파크는 제대로 개발포럼에 소스코드와 SDK를 릴리스했고 GP2X는 지금도 매니아들에게 꽤 괜찮은 홈브루 게임기로 판매되고 있다. 이제 GPL 이슈를 생각도 안 하거나 고의로 무시하는 기업들은 정신 차려야 할 일이다..
"공개SW" 정책은 어떻게?
"open source"라는 말이 "free software"가 듣기에 불편해서 새로 만든 용어임에도 불구하고, 오픈소스라는 말조차도 듣기 불편했는지 한국 정부가 새로 만든 물타기용 용어, "공개SW". 공개SW 활성화 정책 중에서도 실행 과정에서 가시밭길을 걸어왔으면서 부풀리기도 힘들 정도로 성적이 초라했던 (하지만 실행되면 효과는 클 것 같은) "공공기관의 공개SW 도입"이 2008년에는 얼마나 실행될 수 있을까? 아니면 새 정부 들어서 이 쪽 정책이 방향이 완전히 바뀔 가능성은?
한편 지금까지의 정책은 너무 쉬운 방법의 단기적인 예산 집행에 급급했던 게 아쉬웠다. 아쉬웠던 제도적 개선도 이루어졌으면 한다.
북한이 눈에 뜨일까?
6자회담에서 북한의 테러지원국 해제 문제가 순탄치 못하더니 결국 2008년으로 넘어왔다. 갑자기 왠 외교 문제냐 하겠지만 FL/OSS 세계에 마치 북한이 존재하지 않는 것처럼 보이는 이유는, 다른 이유도 있지만 미국의 테러지원국 지정때문에 미국 및 미국과 관련 조약을 맺은 (한국을 비롯한) 국가에서 소프트웨어를 수출하는 게 불법이기 때문이기도 했다. 조금씩 들려오는 말들을 보면, 북쪽은 리눅스 관련 개발도 하고 배포판까지 만들어 쓰고 있다. 폐쇄성과 낮은 컴퓨터/인터넷 보급때문에 (그리고 아마도 남쪽보다도 참여의 문화가 부족할 것이므로) 녹록치 않겠지만, 제도적인 장벽이 사라지면 조금씩 업스트림에 북한이 모습을 드러낼 수 있을까?
피드 구독하기:
글 (Atom)