삼성의 exFAT 드라이버 유출과 관련해, 엉뚱한 삼성 비난 또는 삼성 옹호 얘기가 있길래 실제 코드를 보고 파악할 수 있는 쟁점을 지적해 보고자 한다. 일단 사건의 개요는 넘어가고,
관련 기사 http://www.etnews.com/news/computing/solution/2817944_1476.html
유출된 코드 https://github.com/dorimanx/exfat-nofuse
공개된 코드 http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&searchValue=exfat
-
위 기사의 후반부의 특허 논란 얘기는 틀린 내용이다. 특허는 논란의 여지가 없다. 삼성과 MS는 2011년 크로스 라이선싱
계약을 맺은 상태이므로 삼성 제품에 사용하는 건 삼성의 정당한 권리. 그리고 특허 시스템을 모르는 사람들이 특허가 공개되도
괜찮으냐고 의문을 품는데, 특허는 원래 공개된 거고 특허와 소스 코드의 라이선스는 별개의 문제이다.
- 유출된 코드의
GPL 위반이 발견된 상황에서 삼성의 선택은 두 가지가 있었을 것이다. 첫 번째는 이 코드는 GPL과 별개의 작업이다라고
주장하면서 논란을 확대하는 것이고, 또 하나는 그냥 소스 코드를 공개해 버리고 논란을 종식시키는 것. 이 중에서 후자를 선택한
것은 잘 한 일이었다.
- 하지만 생각해 보면 삼성은 그렇게 선택할 수밖에 없었다. 리눅스 커널 드라이버가
GPL이냐는 떡밥은 참 전통이 깊고, 애매한 상황 아니냐고 논란이 생길 수도 있는데, 적어도 이번 사건은 지금까지 알려진 애매한
상황이 아니라 명확한 GPL 위반 상황이었다. 이 드라이버는 처음부터 리눅스를 위해 작성된 드라이버이므로 GPL v2 section 3에
정확히 걸린다. 또 유출되고 공개된 코드를 실제로 보면 기존 FAT 드라이버 코드의 많은 부분을 복사 붙여넣기 한 게 너무
명확했다. 따라서 이 드라이버는 명백한 GPL 코드의 파생물이었다. 링크가 되니 안 되니 논쟁의 문제가 아니다. 즉 애초부터 이 드라이버의 소스 코드는 삼성이 GPL로 릴리스했어야 했다. 그게 유출이라는 또 다른 불법적인 경로를 통해 들통이 난 것이다.
-
한편 많은 뉴스 기사를 보면 GPL-only symbol을 썼다고는 하는데 ("Samsung was shipping this
closed-source exFAT driver on a tablet yet they were relying upon
GPL-only symbols") 유출된 버전과 공개된 버전이 차이가 있다. 실제 공개된 드라이버에는 GPL 심볼이 사용되지
않아서 이 부분은 사실인지 의심스럽다. 유출된 코드에서는 GPL 심볼을 사용한 부분이 있으나 나중에 공개된 소스나 제품에 포함되어 있는 바이너리에는 그런 흔적이 전혀 없기 때문에, 유출된 버전이 나중에 수정되면서 추가된 부분일 가능성이 높다. 게다가 GPL 심볼을 사용하는 커널 드라이버가 GPL 라이선스를 안 붙이게 우회하기도 쉽지 않고, 그 과정에서 법적 논란이 있음을 쉽게 인식할 수 있는데 악의적으로 감췄을 것 같지도 않다.
- 삼성의 오픈 소스 정책이 무엇이든, 감출 수 있으면 감추는 게 기본 방침이라고 하더라도, 이번 부분은 감출 수 없고 공개했어야 하는 부분을 감춰 버렸던 것은 명백하다. 오픈소스 관리에 놓친 부분이 생긴 건 사실이다.
2013년 8월 28일 수요일
2013년 6월 24일 월요일
사운드그래프 아이몬 리모콘 드라이버의 기억
최근 머지된 리눅스 드라이버 중에 하나가 리모콘 드라이버가 있다. 기존에 LIRC에서 배포되었었던 드라이버가 하나씩 driver/media/rc 아래에 머지되고 있다. 그 중에 한 staging 드라이버 코드의 주석에 잠깐 내 이름이 언급된 걸 보고 생각나는 오래전 이야기.
https://github.com/torvalds/linux/blob/master/drivers/staging/media/lirc/lirc_imon.c#L640
10여년 전, 기억은 나지 않지만 무슨 바람이 불었는지 USB용 IR 리시버와 리모콘이 세트인 제품을 하나 구입했었다. 한국 회사 사운드그래프에서 만든 제품이길래 메일로 리눅스 드라이버 좀 작성해 볼테니 IR 코드랑 리시버 정보 좀 알려달라고 요청했더니 달라는 정보는 안 주고 "..,한번 봅시다 전화..."라는 답을 듣고 황당했던 기억. 답메일로 노땡큐를 날린 다음, USB 인터럽트 데이터를 덤프해 가면서 리눅스 input 드라이버를 작성. 다행히 제조사의 도움 없이 작성될 수 있을 만큼 하드웨어 인터페이스는 간단했다. 별도의 초기화가 없어도 가만히 놔두면 IR 신호를 인터럽트로 알려주는 몹시 단순한 녀석. 단순하다 못해 입력이 없을 때도 인터럽트를 시도 때도 없이 날리는 비효율적인 불량 하드웨어였다.
지금 staging에 들어 있는 lirc 드라이버는 그 때 작성한 드라이버를 보고 다른 사람이 lirc용이 낫지 않겠느냐고 메일을 보냈었고 결국 직접 리시버를 작성한 버전. 지금 생각해 보면 당시에는 USB 리시버 드라이버와 리모콘 드라이버가 합쳐진 내 코드는 방향이 잘못되었고, LIRC 드라이버가 올바른 방향이었다. 그리고 필요없어진 내 코드는 역사 속으로.
http://imonremote.cvs.sourceforge.net/viewvc/imonremote/imon-driver/imon_input.c?revision=1.1&view=markup&pathrev=MAIN
10년이 지난 지금도 이 리모콘 제품은 팔리고 있고, HTPC용 리모콘으로 많이 쓰이는 streamzap 대신 저가형 대안으로 꽤 쓰이는 걸 보면 내가 조금은 기여하지 않았나 싶다. 사운드그래프가 좀 더 협조적이었으면 더 좋은 기억으로 남았을텐데.
https://github.com/torvalds/linux/blob/master/drivers/staging/media/lirc/lirc_imon.c#L640
10여년 전, 기억은 나지 않지만 무슨 바람이 불었는지 USB용 IR 리시버와 리모콘이 세트인 제품을 하나 구입했었다. 한국 회사 사운드그래프에서 만든 제품이길래 메일로 리눅스 드라이버 좀 작성해 볼테니 IR 코드랑 리시버 정보 좀 알려달라고 요청했더니 달라는 정보는 안 주고 "..,한번 봅시다 전화..."라는 답을 듣고 황당했던 기억. 답메일로 노땡큐를 날린 다음, USB 인터럽트 데이터를 덤프해 가면서 리눅스 input 드라이버를 작성. 다행히 제조사의 도움 없이 작성될 수 있을 만큼 하드웨어 인터페이스는 간단했다. 별도의 초기화가 없어도 가만히 놔두면 IR 신호를 인터럽트로 알려주는 몹시 단순한 녀석. 단순하다 못해 입력이 없을 때도 인터럽트를 시도 때도 없이 날리는 비효율적인 불량 하드웨어였다.
지금 staging에 들어 있는 lirc 드라이버는 그 때 작성한 드라이버를 보고 다른 사람이 lirc용이 낫지 않겠느냐고 메일을 보냈었고 결국 직접 리시버를 작성한 버전. 지금 생각해 보면 당시에는 USB 리시버 드라이버와 리모콘 드라이버가 합쳐진 내 코드는 방향이 잘못되었고, LIRC 드라이버가 올바른 방향이었다. 그리고 필요없어진 내 코드는 역사 속으로.
http://imonremote.cvs.sourceforge.net/viewvc/imonremote/imon-driver/imon_input.c?revision=1.1&view=markup&pathrev=MAIN
10년이 지난 지금도 이 리모콘 제품은 팔리고 있고, HTPC용 리모콘으로 많이 쓰이는 streamzap 대신 저가형 대안으로 꽤 쓰이는 걸 보면 내가 조금은 기여하지 않았나 싶다. 사운드그래프가 좀 더 협조적이었으면 더 좋은 기억으로 남았을텐데.
2009년 1월 31일 토요일
현재 유닉스 스타일 파일시스템의 의미는
리눅스에서 많이 사용하고 있는 File Hierachy Standard 는 전통적으로 유닉스에서 사용되던 표준 파일 시스템을 명백히 표준으로 정의한 것이다. 유닉스나 리눅스 사용자라면 익숙하다 못해 친근하기까지 한 /lib, /bin, /sbin, /usr/bin, /usr/share, /usr/lib 따위의 구조는 영원히 없어지지 않는 성역이라고 생각하기 쉽지만, 이제 근본적으로 바뀔 때도 되지 않았을까? 과거의 유닉스 플랫폼의 사정이 오늘날에도 적용이 될까?
유닉스 파일 시스템의 구조는 몇 가지 목적을 가지고 만들어졌다.
정말 공유하는 사람이 있나요?
큰 목적은 "파일 시스템의 공유 가능"이다. 부팅에 필요한 파일은 컴퓨터마다 필요하지만 /usr 아래의 대부분은 공유할 수 있다. 아키텍처가 다른 컴퓨터 사이에는 일부 파일은 공유할 수 없지만 /usr/share 따위는 공유할 수 있다. 오호라! 진짜? 요즘 세상에 이렇게 공유하는 곳이 있을까?
거의 10년 전 학교의 컴퓨터 실에는 이런 식으로 설정된 몇 대의 스팍 서버가 있었다. 하지만 이러한 멋진 구조 덕분에 최악의 안정성을 자랑했다. single point of failure, 한 머신이 죽으면 그 파일 시스템을 공유하는 모든 서버가 동작 불가능이었다. 실제로 그 서버 구성의 최대 장점은 홈 디렉토리의 공유였지 /usr 따위의 공유가 아니었다. /usr의 공유는 /usr 파일 시스템의 크기가 크고, 스토리지의 가격이 비쌀 때 가치가 있지만 용량도 커지고 가격도 내려간 지금의 하드디스크에서 /usr 파일 시스템이 공유할 만큼의 가치를 지니지 않는다.
그리고, 오늘날의 실정을 여러 모로 보면 리눅스 파일 시스템에서 /usr를 공유할 수 있다는 말은 거짓말이다. /usr/include를 보면 각 아키텍처에 의존하는 값이 잔뜩 들어 있는 헤더가 가득하고, 패키징 시스템은 /usr/share와 /usr/lib 에 동시에 파일을 설치한다.
정말 /usr 파일 시스템을 읽기 전용으로 별도 파일 시스템에 마운트해서 여러 컴퓨터 사이에 같은 아키텍처인지 아닌지에 따라 /usr/share와 /usr/lib을 구분해서 공유하는 곳이 있기는 할까? 아무리 네트워크 파일 시스템을 널리 사용하는 곳도 홈 디렉토리 공유나 대용량 스토리지 구현을 위해 사용하지 "비교적 작은" 크기의 /usr 디렉토리를 읽기 전용으로 마운트하려고 사용하는 곳은 본 적이 없다. 10년 전의 그 학교 컴퓨터 실에서도 아키텍처별로 구분하지는 않았다.
과거의 잔재
한편 /usr/X11R6 및 /usr/games라는 구조가 남아 있는데 /usr/X11R6는 X11 및 CDE/XView 따위가 굉장히 커다란 소프트웨어였던 시절에나 의미있는 구분이었다. 이제 X.org 프로젝트는 이 구조를 따르지 않는다. (/usr/X11R6/bin은 /usr/bin으로 가는 심볼릭 링크이다.) /usr/games, /var/games같은 경우에는 BSD의 잔재인데 FHS 문서에 따르면:
바꿀 필요가 없으니까?
굳이 전통적으로 잘 써 왔고 각종 툴이 잘 지원하는 지금의 파일 시스템 구조를 바꿀 필요가 있을까?
일단 현재의 문제는, 소프트웨어 바이너리 패키지의 유연성이 떨어진다. 현재 조금 복잡도가 높은 리눅스 소프트웨어들은 빌드타임에 데이터가 들어 있는 디렉터리가 보통 하드 코딩되어 있다. RPM 패키지의 경우 /usr, /usr/local을 선택할 수 있는 relocatable 패키지를 만들 수 있는 기능이 있지만 이렇게 경로를 하드 코딩하는 애플리케이션들은 relocatable하게 만들기 어렵다. 현재의 파일 시스템에서는 바이너리 패키지만으로 같은 애플리케이션의 여러 버전을 동시에 설치하거나 사용자에 따라 다른 애플리케이션을 설치한다거나 하는 유연성이 없다.
애플리케이션별로 별도의 경로로 설치하면 명령어 실행 경로라든지 ($PATH), 맨페이지, 폰트처럼 한 프로그램이 사용하는 데이터를 여러 패키지에서 설치하는 경우에 문제가 생기지만, 해결 방법은 있다. 한 디렉토리 안에 파일을 몰아 넣지 않더라도 파일시스템의 기능을 통해 여러 경로의 내용들을 한 곳으로 자동으로 합치는 기능이 있다. (이름이 생각이 안 나서 검색 불가...)
유닉스 파일 시스템의 구조는 몇 가지 목적을 가지고 만들어졌다.
- 부팅과 최소한의 관리에 필요한 파일 (/), 시스템 설치 파일 (/usr), 사용자 설치 파일 (/usr/local) 구분으로 공유 가능
- 아키텍처 의존 파일과 (/usr/lib) 독립 파일을 (/usr/share) 구분해서 독립 파일을 여러 아키텍쳐 컴퓨터 사이에 네트워크로 공유 가능
- 읽기 전용 파일시스템, 시스템 설정, 데이터 파일 시스템 구분 (/usr, /etc, /var 구분)
정말 공유하는 사람이 있나요?
큰 목적은 "파일 시스템의 공유 가능"이다. 부팅에 필요한 파일은 컴퓨터마다 필요하지만 /usr 아래의 대부분은 공유할 수 있다. 아키텍처가 다른 컴퓨터 사이에는 일부 파일은 공유할 수 없지만 /usr/share 따위는 공유할 수 있다. 오호라! 진짜? 요즘 세상에 이렇게 공유하는 곳이 있을까?
거의 10년 전 학교의 컴퓨터 실에는 이런 식으로 설정된 몇 대의 스팍 서버가 있었다. 하지만 이러한 멋진 구조 덕분에 최악의 안정성을 자랑했다. single point of failure, 한 머신이 죽으면 그 파일 시스템을 공유하는 모든 서버가 동작 불가능이었다. 실제로 그 서버 구성의 최대 장점은 홈 디렉토리의 공유였지 /usr 따위의 공유가 아니었다. /usr의 공유는 /usr 파일 시스템의 크기가 크고, 스토리지의 가격이 비쌀 때 가치가 있지만 용량도 커지고 가격도 내려간 지금의 하드디스크에서 /usr 파일 시스템이 공유할 만큼의 가치를 지니지 않는다.
그리고, 오늘날의 실정을 여러 모로 보면 리눅스 파일 시스템에서 /usr를 공유할 수 있다는 말은 거짓말이다. /usr/include를 보면 각 아키텍처에 의존하는 값이 잔뜩 들어 있는 헤더가 가득하고, 패키징 시스템은 /usr/share와 /usr/lib 에 동시에 파일을 설치한다.
정말 /usr 파일 시스템을 읽기 전용으로 별도 파일 시스템에 마운트해서 여러 컴퓨터 사이에 같은 아키텍처인지 아닌지에 따라 /usr/share와 /usr/lib을 구분해서 공유하는 곳이 있기는 할까? 아무리 네트워크 파일 시스템을 널리 사용하는 곳도 홈 디렉토리 공유나 대용량 스토리지 구현을 위해 사용하지 "비교적 작은" 크기의 /usr 디렉토리를 읽기 전용으로 마운트하려고 사용하는 곳은 본 적이 없다. 10년 전의 그 학교 컴퓨터 실에서도 아키텍처별로 구분하지는 않았다.
과거의 잔재
한편 /usr/X11R6 및 /usr/games라는 구조가 남아 있는데 /usr/X11R6는 X11 및 CDE/XView 따위가 굉장히 커다란 소프트웨어였던 시절에나 의미있는 구분이었다. 이제 X.org 프로젝트는 이 구조를 따르지 않는다. (/usr/X11R6/bin은 /usr/bin으로 가는 심볼릭 링크이다.) /usr/games, /var/games같은 경우에는 BSD의 잔재인데 FHS 문서에 따르면:
The separation allows local control of backup strategies, permissions, and disk usage, as well as allowing inter-host sharing and reducing clutter in /var/lib백업 방식을 다르게 하기 위해서, 권한을 다르게 하기 위해서, 컴퓨터 사이에 점수 따위를 공유하기 위해서, /var/lib 크기를 줄이기 위해서라고 되어 있다. 이 역시 오늘날의 실정과 맞지 않는다.
바꿀 필요가 없으니까?
굳이 전통적으로 잘 써 왔고 각종 툴이 잘 지원하는 지금의 파일 시스템 구조를 바꿀 필요가 있을까?
일단 현재의 문제는, 소프트웨어 바이너리 패키지의 유연성이 떨어진다. 현재 조금 복잡도가 높은 리눅스 소프트웨어들은 빌드타임에 데이터가 들어 있는 디렉터리가 보통 하드 코딩되어 있다. RPM 패키지의 경우 /usr, /usr/local을 선택할 수 있는 relocatable 패키지를 만들 수 있는 기능이 있지만 이렇게 경로를 하드 코딩하는 애플리케이션들은 relocatable하게 만들기 어렵다. 현재의 파일 시스템에서는 바이너리 패키지만으로 같은 애플리케이션의 여러 버전을 동시에 설치하거나 사용자에 따라 다른 애플리케이션을 설치한다거나 하는 유연성이 없다.
애플리케이션별로 별도의 경로로 설치하면 명령어 실행 경로라든지 ($PATH), 맨페이지, 폰트처럼 한 프로그램이 사용하는 데이터를 여러 패키지에서 설치하는 경우에 문제가 생기지만, 해결 방법은 있다. 한 디렉토리 안에 파일을 몰아 넣지 않더라도 파일시스템의 기능을 통해 여러 경로의 내용들을 한 곳으로 자동으로 합치는 기능이 있다. (이름이 생각이 안 나서 검색 불가...)
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 세계에 마치 북한이 존재하지 않는 것처럼 보이는 이유는, 다른 이유도 있지만 미국의 테러지원국 지정때문에 미국 및 미국과 관련 조약을 맺은 (한국을 비롯한) 국가에서 소프트웨어를 수출하는 게 불법이기 때문이기도 했다. 조금씩 들려오는 말들을 보면, 북쪽은 리눅스 관련 개발도 하고 배포판까지 만들어 쓰고 있다. 폐쇄성과 낮은 컴퓨터/인터넷 보급때문에 (그리고 아마도 남쪽보다도 참여의 문화가 부족할 것이므로) 녹록치 않겠지만, 제도적인 장벽이 사라지면 조금씩 업스트림에 북한이 모습을 드러낼 수 있을까?
2007년 11월 19일 월요일
2007년 11월 3일 토요일
OSS 정책 - 부요, 그 이름과 방향
저번 부요에 관한 네거티브이야기에 이어서, 가십성이긴 하지만 부요의 이름과 그 정의에 대해 생각해 보면,
2004년인가, 2005년에 부요 프로젝트에 몇단계에 건너서 관여된 누군가와 대화를 했었다.
드라마 "주몽"이 살던, 대소왕자가 살던 그 부여! 오래전 쓰여진 KLDP 위키 페이지에도 그 흔적이 일부 남아 있다.
어쨌거나, 이름이 그렇게 변화되어 왔는데... 부요의 이름이 바뀌면서 처음에 구상했던 BONE/BOOYO의 구분이 애매해 진 것일까? 부요가 표준인지 배포판 제품인지 명확하지가 않다. 부요를 단순히 "부요 표준을 준수해 구현된 제품"이라고 정의하기에는 사람들이 하는 말이 앞뒤가 맞지 않다. TTA에 표준으로 공개된 수준의 부요 표준은 매우 대략적이고 선언적인 기준만 제시되어 있기 때문에 사실상 거의 모든 리눅스 배포판이 부요 compatible이라고 주장할 수도 있을 정도인데, 사람들은 부요의 제품성에 대해서 말하고 있다.
몇 가지 예를 들어 보면,
부요 리눅스를 서치해 봐도, 리눅스 이용자들은 부요를 리눅스 배포판 제품으로 생각하고 말한다. 업체들은 물론이고, 정부 관계자들도 부요에 대해 선전할 때도 화려한 각종 기능을 선전하는 걸 보면, 부요 표준이 아닌 부요 배포판에 대해서 말하고 있다. 하지만 정책 입안자들과 ETRI에서는 부요를 표준 플랫폼이라고 말하고 있다. 그런데 또 표준 문서만 준수한다고 부요 인증을 해 주는 것도 아니다.
무엇이 맞는 얘기일까? 정책의 애초의 목적, 진흥원, ETRI, 업체, 사용자가 모두 다른 방향을 바라보고 있는 게 아닐까?
(나중에 귀차니즘이 회복되면 부요의 다른 부분에 대해서 계속)
2004년인가, 2005년에 부요 프로젝트에 몇단계에 건너서 관여된 누군가와 대화를 했었다.
창우: "어, 영어로 Booyo인데 부요 아니었어요?"
누군가: "부여예요"
누군가: "부여예요"
드라마 "주몽"이 살던, 대소왕자가 살던 그 부여! 오래전 쓰여진 KLDP 위키 페이지에도 그 흔적이 일부 남아 있다.
너무 민족주의 코드가 들어있었기 때문이었을까? 아니면 다른 어떤 사연이 있었는지 결국 이름은 "부요"가 되었다. KDE가 맨 처음 announcement에서는 "Kool Desktop Project"였는데도 시간이 갈 수록 잊혀져서 "K Desktop Project"가 되었듯이, 부요라고 바뀐 이름은 새로운 의미로 해석되었다. 그런데 이상하게도 영문 위키피디어 페이지에만 부요의 설명이 상세하게 되어 있고 한글 페이지에는 별로 언급이 없다. 이름에 대한 설명을 보면,
- BONE:사업 코드명이며 공개SW (OSS: Open Source Software, 뼈)의 本, 골격을 의미
- BOOYO:결과물코드명이며 중국 중원의 대부여의 맥, 일본의 근간인 백제(부여의 계승)의 맥으로써 리눅스 제국 건설을 의미함
Booyo is a Korean onomatopoeia yelled at during pheasant hunting to make the birds take wing, hence meaning the new soaring of the Linux platform in Korea. The Booyo logo shows a penguin taking off the ground. A homonym of Booyo means being rich."being rich"... "부자 되세요?" 한글로 된 설명도 KLDP 게시판의 일부 댓글에서 찾을 수 있다.
정식 한글 명칭은 '부요' 입니다. '부요'는 표준 스펙으로서의 기능도 하고 해당 스펙을 준수하는 배포판 기능도 합니다.
이름의 유래는 남쪽지방의 꿩잡기 할 때 나는 소리입니다. 꿩을 잡을때 몰이꾼이 내는 소리가 부요... 뿌요.. 뭐 그렇다고 하는데 인턴인 제가 봐도 믿거나 말거나입니다. :)
어쨌거나, 이름이 그렇게 변화되어 왔는데... 부요의 이름이 바뀌면서 처음에 구상했던 BONE/BOOYO의 구분이 애매해 진 것일까? 부요가 표준인지 배포판 제품인지 명확하지가 않다. 부요를 단순히 "부요 표준을 준수해 구현된 제품"이라고 정의하기에는 사람들이 하는 말이 앞뒤가 맞지 않다. TTA에 표준으로 공개된 수준의 부요 표준은 매우 대략적이고 선언적인 기준만 제시되어 있기 때문에 사실상 거의 모든 리눅스 배포판이 부요 compatible이라고 주장할 수도 있을 정도인데, 사람들은 부요의 제품성에 대해서 말하고 있다.
몇 가지 예를 들어 보면,
- 부요는 LSB 3.1 certification을 받았다. 그러면 부요는 배포판 제품인가? (참고로 LSB는 Linux Foundation에 인증을 신청하면 제출하는 제품을 기준으로 certification을 부여한다. 부요가 LSB certification을 받았다고, 부요 인증만 하면 LSB 인증이 자동으로 되는 거 절대로 아니다.)
- 부요는 TTAS.KO-05.0037 및 TTAS.KO-05.0038로 한국정보통신기술협회(TTA)의 표준으로 등록되어 있다. 그러면 부요는 표준인가?
- 부요는 ETRI와 리눅스 배포판 업체들과의 합작품이다. 그러면 부요는 제품인가?
- 2005년 12월, TTA로부터 프로젝트 그룹의 표준화 활동 공로로 ETRI 연구원들이 표준화 공로상을 수상한바 있다. 그러면 부요는 표준인가?
- 제품 성능에 대해 말하고 있는 부요 관련 신문 기사들을 보면 역시 부요는 제품인가? ("부요 프로젝트는 돈먹는 하마?", "리눅스 플랫폼, 부요 기반 배포판 무상보급 신경전")
부요 리눅스를 서치해 봐도, 리눅스 이용자들은 부요를 리눅스 배포판 제품으로 생각하고 말한다. 업체들은 물론이고, 정부 관계자들도 부요에 대해 선전할 때도 화려한 각종 기능을 선전하는 걸 보면, 부요 표준이 아닌 부요 배포판에 대해서 말하고 있다. 하지만 정책 입안자들과 ETRI에서는 부요를 표준 플랫폼이라고 말하고 있다. 그런데 또 표준 문서만 준수한다고 부요 인증을 해 주는 것도 아니다.
무엇이 맞는 얘기일까? 정책의 애초의 목적, 진흥원, ETRI, 업체, 사용자가 모두 다른 방향을 바라보고 있는 게 아닐까?
(나중에 귀차니즘이 회복되면 부요의 다른 부분에 대해서 계속)
2007년 10월 19일 금요일
OSS 정책 - "리눅스OS `부요 2.5` 기술이전"
리눅스OS `부요 2.5` 기술이전
여유가 되면 부요 프로젝트의 문제에 대해 모두 써보겠지만... (한국형 규격이라는 어긋된 방향, 정부기관 주도의 커뮤니티가 없는 폐쇄적 진행 등등) 그 중에서도 한 가지 문제가 지금 당사자들이 하고 있는 자화자찬식 정책 평가의 문제이다. 생색내기와 과장된 보도자료는 부요 관련뿐만 아니라 모든 정부산하기관의 문제이기도 하지만, 부요가 대체 어떤 긍정적인 영향을 미쳤다는 건지 이해하기 어렵다. 현재 상황은 오직 부요를 만든 당사자들만 부요에 대해 말하고 있는 실정이다.
부요 규격이 하는 일이 레드햇/수세/우분투의 최신 기능과 (업데이트/가상화) 최신 버전을 써 넣는 것일까? 실제 현재까지 표준화된 규격을 보면 부요 규격은 리눅스 커널 옵션, LSB/FHS, 그리고 Fedora 최신판을 설명한 것에 지나지 않는다.
ETRI 공개SW솔루션연구팀 우영춘 팀장은 "부요는 그동안 수 차례의 기술이전을 통해 국내 공개SW 활성화에 매우 긍정적인 영향을 미쳤다고 본다"며 "이번에 기술이 이전되는 부요 2.5 버전은 데스크톱 SW 플랫폼의 경우 업데이트 기능이 대폭 강화됐고, 서버 SW 플랫폼은 최근 업계의 이슈가 되고 있는 가상화 기능이 포함된 것이 특징"이라고 말했다.
여유가 되면 부요 프로젝트의 문제에 대해 모두 써보겠지만... (한국형 규격이라는 어긋된 방향, 정부기관 주도의 커뮤니티가 없는 폐쇄적 진행 등등) 그 중에서도 한 가지 문제가 지금 당사자들이 하고 있는 자화자찬식 정책 평가의 문제이다. 생색내기와 과장된 보도자료는 부요 관련뿐만 아니라 모든 정부산하기관의 문제이기도 하지만, 부요가 대체 어떤 긍정적인 영향을 미쳤다는 건지 이해하기 어렵다. 현재 상황은 오직 부요를 만든 당사자들만 부요에 대해 말하고 있는 실정이다.
부요 규격이 하는 일이 레드햇/수세/우분투의 최신 기능과 (업데이트/가상화) 최신 버전을 써 넣는 것일까? 실제 현재까지 표준화된 규격을 보면 부요 규격은 리눅스 커널 옵션, LSB/FHS, 그리고 Fedora 최신판을 설명한 것에 지나지 않는다.
2007년 6월 12일 화요일
티보이제이션?
최근 GPLv3와 관련된 글들을 보면 티보이제이션(tivo-isation)이란 말이 등장한다. FSF가 만들어낸 이 말은 프로그램이 오픈소스로 배포된다고 해도, 실제적으로 수정한 걸 적용할 수 없기 때문에 무용지물이 되도록 만드는 조치를 말한다.
티보(TiVo)는 디지털 비디오 레코더 분야에서 한 획을 그은 제품이다. 테이프 VCR을 대체하는 TV를 녹화하는 장비인데, 광고를 건너뛰고 녹화하는 기능이라던지, electronic program guide를 (EPG) 활용해 방송시간 변경같은 것에 유연하게 대처한다든지, 요즘 우리나라 전자회사들이 타임머신이라는 이름으로 고가 TV에 내장하고 있는 타임쉬프트 기능 등을 실제 구현해서 시장에서 성공한 최초의 제품이다. 주체하기 힘들게 다양한 채널과 다양한 컨텐츠로 (그리고 지나치게 많은 광고로) 고민해야 하는 미국 시청자들에게 잘 어필하는 제품이다. 또 한가지 재미있는 점은 리눅스 OS 기반이라는 것. 리눅스 기반 장치가 드문 일은 아니지만 10여년전부터 지금까지 ppc 리눅스를 계속 써 왔다는 건 흥미로운 일이다.
하지만 실제로 최근 버전의 티보 하드웨어에서는 사용자가 직접 소스코드를 수정해서 티보 장치에 적용하는 건 불가능하다. 계속되는 hack에 고민하던 티보측에서는 (리눅스 소스를 감출 수는 없으니) 디지털 사인을 체크하는 장치를 달아서 제 3자가 수정한 소프트웨어는 설치하지 못하는 장치를 부착했다. 이것이 티보이제이션이다. (물론 납땜질을 통한 하드웨어적인 hack들이 나왔지만..)
티보가 이렇게 하는 이유는 보안을 위한 것이다...라고 말하기도 하지만(!), 티보 플랫폼에 대한 컨트롤을 놓지 않으려는 수단이기도 하다. 요즘은 부품 가격이 꽤 내려가서 그럴 필요가 없을 지 모르지만.. 티보를 만들 당시에만 해도 CPU, HDD, 비디오 코덱 따위를 부착한 디지털 레코더는 도저히 소비자가 가전제품으로 구입할 수 있을 정도의 원가가 나오지 않았다. 그래서 티보는 질레트 면도기, 잉크젯 프린터, playstation과 비슷하게 수익 모델을 가져갔다. 티보 기계는 원가보다 싸게 팔면서, TV 프로그램 가이드를 제공하는 서비스의 subscription fee 등을 통해 손해를 보전하는 것이다. 요즘은 부품 가격이 떨어져서 사정이 많이 달라졌지만 여전히 subscription fee가 수익의 큰 부분을 차지한다. 그런데 만약 누군가가 티보 소스 코드를 수정해서 티보의 공식 서비스가 없이도 잘 동작하도록 무료 EPG 사이트와 연결시키는 펌웨어를 만든다면 티보측으로서는 낭패일 수밖에 없다. 디지털 사인 기술을 보안 용도만으로 사용하는 게 아닌 건 분명하다.
GPLv3에 반대하는 입장인 리누스 토발즈의 주장은 소프트웨어 라이센스는 소프트웨어에 국한해야 하고 하드웨어를 컨트롤할 수는 없지 않느냐라는 것이고, 어차피 소스코드가 있으면 다른 기계에서 돌릴 수도 있지 않느냐고 한다. 하지만 티보이제이션에 반대하는 사람들 입장은 이렇게 되면 실제로 소스코드 변경이 이루어지기 힘들어서 GPL이 보장한 수정과 재배포를 사실상 무력화시키는 거라고 말한다. 특히 개정되기 전에 표현이 너무 포괄적이었던 GPLv3 draft에서는 무고한 DRM enabled media의 사용자가 GPLv3를 위반하는 모호한 상황이 벌어질 수도 있었는데, 개정을 통해서 "티보"와 같이 코드 수정을 사실상 못하게 하는 의도만을 걸러낼 수 있게 된 것 같다. (너무 포괄적으로 썼다가는 데비안의 "아카이브 키"도 GPLv3에 따르면 위반이 되는 경우가 있다... 데비안은 아카이브 키를 무시하는 방법이 있으니까 수정을 못하게 하지는 않는다.)
티보(TiVo)는 디지털 비디오 레코더 분야에서 한 획을 그은 제품이다. 테이프 VCR을 대체하는 TV를 녹화하는 장비인데, 광고를 건너뛰고 녹화하는 기능이라던지, electronic program guide를 (EPG) 활용해 방송시간 변경같은 것에 유연하게 대처한다든지, 요즘 우리나라 전자회사들이 타임머신이라는 이름으로 고가 TV에 내장하고 있는 타임쉬프트 기능 등을 실제 구현해서 시장에서 성공한 최초의 제품이다. 주체하기 힘들게 다양한 채널과 다양한 컨텐츠로 (그리고 지나치게 많은 광고로) 고민해야 하는 미국 시청자들에게 잘 어필하는 제품이다. 또 한가지 재미있는 점은 리눅스 OS 기반이라는 것. 리눅스 기반 장치가 드문 일은 아니지만 10여년전부터 지금까지 ppc 리눅스를 계속 써 왔다는 건 흥미로운 일이다.
하지만 실제로 최근 버전의 티보 하드웨어에서는 사용자가 직접 소스코드를 수정해서 티보 장치에 적용하는 건 불가능하다. 계속되는 hack에 고민하던 티보측에서는 (리눅스 소스를 감출 수는 없으니) 디지털 사인을 체크하는 장치를 달아서 제 3자가 수정한 소프트웨어는 설치하지 못하는 장치를 부착했다. 이것이 티보이제이션이다. (물론 납땜질을 통한 하드웨어적인 hack들이 나왔지만..)
티보가 이렇게 하는 이유는 보안을 위한 것이다...라고 말하기도 하지만(!), 티보 플랫폼에 대한 컨트롤을 놓지 않으려는 수단이기도 하다. 요즘은 부품 가격이 꽤 내려가서 그럴 필요가 없을 지 모르지만.. 티보를 만들 당시에만 해도 CPU, HDD, 비디오 코덱 따위를 부착한 디지털 레코더는 도저히 소비자가 가전제품으로 구입할 수 있을 정도의 원가가 나오지 않았다. 그래서 티보는 질레트 면도기, 잉크젯 프린터, playstation과 비슷하게 수익 모델을 가져갔다. 티보 기계는 원가보다 싸게 팔면서, TV 프로그램 가이드를 제공하는 서비스의 subscription fee 등을 통해 손해를 보전하는 것이다. 요즘은 부품 가격이 떨어져서 사정이 많이 달라졌지만 여전히 subscription fee가 수익의 큰 부분을 차지한다. 그런데 만약 누군가가 티보 소스 코드를 수정해서 티보의 공식 서비스가 없이도 잘 동작하도록 무료 EPG 사이트와 연결시키는 펌웨어를 만든다면 티보측으로서는 낭패일 수밖에 없다. 디지털 사인 기술을 보안 용도만으로 사용하는 게 아닌 건 분명하다.
GPLv3에 반대하는 입장인 리누스 토발즈의 주장은 소프트웨어 라이센스는 소프트웨어에 국한해야 하고 하드웨어를 컨트롤할 수는 없지 않느냐라는 것이고, 어차피 소스코드가 있으면 다른 기계에서 돌릴 수도 있지 않느냐고 한다. 하지만 티보이제이션에 반대하는 사람들 입장은 이렇게 되면 실제로 소스코드 변경이 이루어지기 힘들어서 GPL이 보장한 수정과 재배포를 사실상 무력화시키는 거라고 말한다. 특히 개정되기 전에 표현이 너무 포괄적이었던 GPLv3 draft에서는 무고한 DRM enabled media의 사용자가 GPLv3를 위반하는 모호한 상황이 벌어질 수도 있었는데, 개정을 통해서 "티보"와 같이 코드 수정을 사실상 못하게 하는 의도만을 걸러낼 수 있게 된 것 같다. (너무 포괄적으로 썼다가는 데비안의 "아카이브 키"도 GPLv3에 따르면 위반이 되는 경우가 있다... 데비안은 아카이브 키를 무시하는 방법이 있으니까 수정을 못하게 하지는 않는다.)
2007년 4월 14일 토요일
Linux x86 64 환경
데스크탑을 core2duo로 업그레이드하면서 64비트 리눅스의 세계로 빠져들었다.
사실 현재 시점에서는 64비트 데스크탑 OS는 별 메리트가 없다. 좀 더 시간이 지나서 대용량 홈 비디오 편집이라던가 그런게 일반화되거나, 엄청난 양의 데이터를 메모리에 갖고 있어야 하는 컴퓨터 게임이 나오거나 해야 상황이 달라지려나? 요즘의 기껏해야 전체 메모리가 수 GB 내외인 데다가 애플리케이션도 GB 단위의 메모리를 사용하는 애플리케이션이 없는 현재 상황에서는 메리트가 없다.
어쨌든... 새로운 세계의 도전을 핑계삼아 최근에 시도한 바로는 몇가지 걸림돌이 있었다. 문제는 과거의 ia32 바이너리들이다.
vmplayer - 의외로 그냥 까니까 동작했다. 호환 라이브러리만 (데비안/우분투의 경우 ia32-libs 및 ia32-libs-gtk) 잘 설치해서 쓰면 문제가 없다. 단 imhangul을 쓰고 있다면 imhangul도 GTK+ 호환성 라이브러리에 맞게 깔아야 해서 xim/nabi로 쓰는 게 속편하다.
enemy territory - 왜 nvidia glx가 호환성 라이브러리가 (nvidia-glx-ia32) 있는지 생각하다가 테스트해 보려고 설치해 본 것. 역시 설치하니까 아주 잘 된다. (왠지 옛날보다 많이 죽는 느낌이 드는 것 같은데 -_-)
flash - 첫 번째 걸림돌. standalone program이 아니라 다른 프로그램의 플러그인이기 때문에 골치가 아프다. Adobe에서는 64비트 포팅은 다시 빌드하거나 포인터 변수 사용 고치는 정도의 간단한 문제가 아니고 현재 작업중이라고 한다. 가장 쉽고 간단한 방법은 nspluginwrapper를 이용하는 것. 일반 플러그인을 사용하는 것보다 꽤 CPU 로드가 높아서 (그래도 쓸만하지만) 궁극적인 솔루션이라고 할 수는 없다.
Java - 이게 가장 큰 문제이다. sun java 1.4는 nspluginwrapper로 동작하지만, java5/java6는 동작하지 않는다. IBM JRE도 AMD64 버전이 없긴 마찬가지이다. blackdown java는 원래 java5/java6 버전이 없다. 이 문제는 Sun의 게으름과 무관심이 가장 큰 문제이다. 이미 JRE는 amd64로 포팅이 되어 있고 없는 부분은 plugin 인터페이스뿐이다. flash와는 달리 컴파일만 하면 해결되는 문제라는 얘기다. J2SE 소스코드를 받아서 고쳐보려다가 참고 그냥 blackdown java만 깔아 놓았다. 이래서 자바가 진작에 오픈소스가 됐어야...
브라우저 문제를 해결하는 가장 현실적인 방법은 32비트로 빌드한 웹브라우저를 사용하는 것이다. swiftfox를 사용하는 게 한 가지 방법이다.
결론적으로... 현재 새로 까는 사람들은 그냥 32비트 리눅스를 설치하기를 권장 -_- (과연 ia32는 언제까지 존속할 것인가?) 일단 현재까지의 내용만 정리해서 flash 데비안 패키지도 nswrapper 사용하도록 고쳐서 버그 보내 보고 데비안 imhangul 패키지도 ia32 호환 버전 빌드하고 할 예정.
사실 현재 시점에서는 64비트 데스크탑 OS는 별 메리트가 없다. 좀 더 시간이 지나서 대용량 홈 비디오 편집이라던가 그런게 일반화되거나, 엄청난 양의 데이터를 메모리에 갖고 있어야 하는 컴퓨터 게임이 나오거나 해야 상황이 달라지려나? 요즘의 기껏해야 전체 메모리가 수 GB 내외인 데다가 애플리케이션도 GB 단위의 메모리를 사용하는 애플리케이션이 없는 현재 상황에서는 메리트가 없다.
어쨌든... 새로운 세계의 도전을 핑계삼아 최근에 시도한 바로는 몇가지 걸림돌이 있었다. 문제는 과거의 ia32 바이너리들이다.
vmplayer - 의외로 그냥 까니까 동작했다. 호환 라이브러리만 (데비안/우분투의 경우 ia32-libs 및 ia32-libs-gtk) 잘 설치해서 쓰면 문제가 없다. 단 imhangul을 쓰고 있다면 imhangul도 GTK+ 호환성 라이브러리에 맞게 깔아야 해서 xim/nabi로 쓰는 게 속편하다.
enemy territory - 왜 nvidia glx가 호환성 라이브러리가 (nvidia-glx-ia32) 있는지 생각하다가 테스트해 보려고 설치해 본 것. 역시 설치하니까 아주 잘 된다. (왠지 옛날보다 많이 죽는 느낌이 드는 것 같은데 -_-)
flash - 첫 번째 걸림돌. standalone program이 아니라 다른 프로그램의 플러그인이기 때문에 골치가 아프다. Adobe에서는 64비트 포팅은 다시 빌드하거나 포인터 변수 사용 고치는 정도의 간단한 문제가 아니고 현재 작업중이라고 한다. 가장 쉽고 간단한 방법은 nspluginwrapper를 이용하는 것. 일반 플러그인을 사용하는 것보다 꽤 CPU 로드가 높아서 (그래도 쓸만하지만) 궁극적인 솔루션이라고 할 수는 없다.
duncan:~/tmp$ tar zxvf install_flash_player_9_linux.tar.gz
...
duncan:~/tmp$ cd install_flash_player_9_linux
duncan:~/tmp/install_flash_player_9_linux$ linux32 flashplayer-installer
...
duncan:~/tmp/install_flash_player_9_linux$ nswrapper ~/.mozilla/plugins/libflashplayer.so
Java - 이게 가장 큰 문제이다. sun java 1.4는 nspluginwrapper로 동작하지만, java5/java6는 동작하지 않는다. IBM JRE도 AMD64 버전이 없긴 마찬가지이다. blackdown java는 원래 java5/java6 버전이 없다. 이 문제는 Sun의 게으름과 무관심이 가장 큰 문제이다. 이미 JRE는 amd64로 포팅이 되어 있고 없는 부분은 plugin 인터페이스뿐이다. flash와는 달리 컴파일만 하면 해결되는 문제라는 얘기다. J2SE 소스코드를 받아서 고쳐보려다가 참고 그냥 blackdown java만 깔아 놓았다. 이래서 자바가 진작에 오픈소스가 됐어야...
브라우저 문제를 해결하는 가장 현실적인 방법은 32비트로 빌드한 웹브라우저를 사용하는 것이다. swiftfox를 사용하는 게 한 가지 방법이다.
결론적으로... 현재 새로 까는 사람들은 그냥 32비트 리눅스를 설치하기를 권장 -_- (과연 ia32는 언제까지 존속할 것인가?) 일단 현재까지의 내용만 정리해서 flash 데비안 패키지도 nswrapper 사용하도록 고쳐서 버그 보내 보고 데비안 imhangul 패키지도 ia32 호환 버전 빌드하고 할 예정.
2007년 2월 15일 목요일
클라이언트 컨트롤과 보안
액티브엑스 보안에 관한 행정 자치부의 답변 중에서 가장 문제가 되는 부분:
외국에서 보안상의 문제가 심각하지 않아서 PC에 대한 제어가 불필요한 게 아니다. 우리와 그들의 차이점은, 아무리 머리를 굴려도 PC를 "완벽히" 제어할 방법이 없다는 걸 그 사람들은 알고 있기 때문이다. (기술적으로 제어하기 어려우니 DMCA같은 법으로 제어하려고 하긴 하지만..)
보안 업체들은 분명히 불가능하다는 걸 잘 알고 있었을 텐데 왜 불가능하다고 말하지 못하고 현재와 같은 가짜 보안으로 눈가림을 한 것일까? 아니면 정부가 괜히 완벽하다고 오해한 걸까?
○ 완전한 안전성, 보안성을 확보하기 위해서는 민원인 PC에 대한 완벽한 제어, 위변조 방지 장치 등을 갖추어 놓아야 함
○ 외국에서는 이러한 보안상의 문제가 심각하지 않으므로 민원인 PC에 대한 제어 등이 필요치 않으므로 유사사례가 있을 수 없음
○ 외국에서는 이러한 보안상의 문제가 심각하지 않으므로 민원인 PC에 대한 제어 등이 필요치 않으므로 유사사례가 있을 수 없음
외국에서 보안상의 문제가 심각하지 않아서 PC에 대한 제어가 불필요한 게 아니다. 우리와 그들의 차이점은, 아무리 머리를 굴려도 PC를 "완벽히" 제어할 방법이 없다는 걸 그 사람들은 알고 있기 때문이다. (기술적으로 제어하기 어려우니 DMCA같은 법으로 제어하려고 하긴 하지만..)
보안 업체들은 분명히 불가능하다는 걸 잘 알고 있었을 텐데 왜 불가능하다고 말하지 못하고 현재와 같은 가짜 보안으로 눈가림을 한 것일까? 아니면 정부가 괜히 완벽하다고 오해한 걸까?
2006년 12월 14일 목요일
리눅스에 여성 참여를 장려하는 하우투
오늘 컨퍼런스에서 민망한 사진이 프리젠테이션에 노출된 사고에 대한 블로그 글을 읽으면서 HOWTO Encourage Women in Linux 문서도 끝까지 읽게 되었는데.. 여러가지 생각해 볼 기회가 많았다. 하우투 강력 추천!
이 중에서 특히 리눅스를 기피하는 이유를 인용하면:
지난 12월 3일에 있었던 오픈소스 뛰어들기 행사에서는 특이하게도 참석자에 대해 여성 쿼터제가 있었지만, 결과적으로 15명이었던 쿼터 수를 줄이고 했지만 실제 참석 인원은 그에 미치지 못했다. 혹시 기피 요인들이 있었을까? (물론 의도한 건 아니지만) 여성 강사가 없다든지, 주제나 형식이 부담스러웠을 수도 있고, 새로운 사람이 들어가기 어려웠었을 수도 있었을 것이다.
이 중에서 특히 리눅스를 기피하는 이유를 인용하면:
간단하게는 IRC에서 여성에게 남자친구에 대해 질문을 한다던지, 생각없이 내뱉는 말이나 여러가지 가정들이 여성에게는 그 커뮤니티를 기피하는 원인이 된다.Linux development is more competitive and fierce than most areas of programming. Often, the only reward (or the major reward) for writing code is status and the approval of your peers. Far more often, the "reward" is a scathing flame, or worse yet, no response at all. Since women are socialized to not be competitive and avoid conflict, and since they have low self-confidence to begin with, Linux and open source in general are even more difficult than most areas of computing for women to get and stay involved in.
(대충 의역) 리눅스 개발은 프로그래밍의 다른 분야보다도 더 충돌이 심하고 험합니다. 어떤 경우 코드를 작성해서 얻는 보상이라곤 어떤 지위를 갖거나 상대방로부터 허락받는 것일 뿐일 수도 있습니다. 심지어는 그 "보상"이라는 게 비난에 가까운 플레임일 수도 있고 더 나쁜 경우는 아예 아무런 반응이 없을 수도 있습니다. 여성들은 사회화되면서 다른 사람과 충돌을 피하고 조화롭게 지내도록 훈련받습니다. 또 그런 충돌을 시작할 만한 자신감이 부족합니다. 그래서 리눅스와 일반적인 오픈소스 분야는 다른 분야의 컴퓨팅보다도 훨씬 더 여성의 참여가 어렵고 참여를 계속하기도 어렵습니다.
지난 12월 3일에 있었던 오픈소스 뛰어들기 행사에서는 특이하게도 참석자에 대해 여성 쿼터제가 있었지만, 결과적으로 15명이었던 쿼터 수를 줄이고 했지만 실제 참석 인원은 그에 미치지 못했다. 혹시 기피 요인들이 있었을까? (물론 의도한 건 아니지만) 여성 강사가 없다든지, 주제나 형식이 부담스러웠을 수도 있고, 새로운 사람이 들어가기 어려웠었을 수도 있었을 것이다.
피드 구독하기:
글 (Atom)