OSS 정책 - "리눅스OS `부요 2.5` 기술이전"

리눅스OS `부요 2.5` 기술이전

ETRI 공개SW솔루션연구팀 우영춘 팀장은 "부요는 그동안 수 차례의 기술이전을 통해 국내 공개SW 활성화에 매우 긍정적인 영향을 미쳤다고 본다"며 "이번에 기술이 이전되는 부요 2.5 버전은 데스크톱 SW 플랫폼의 경우 업데이트 기능이 대폭 강화됐고, 서버 SW 플랫폼은 최근 업계의 이슈가 되고 있는 가상화 기능이 포함된 것이 특징"이라고 말했다.

여유가 되면 부요 프로젝트의 문제에 대해 모두 써보겠지만...  (한국형 규격이라는 어긋된 방향, 정부기관 주도의 커뮤니티가 없는 폐쇄적 진행 등등)  그 중에서도 한 가지 문제가 지금 당사자들이 하고 있는 자화자찬식 정책 평가의 문제이다. 생색내기와 과장된 보도자료는 부요 관련뿐만 아니라 모든 정부산하기관의 문제이기도 하지만, 부요가 대체 어떤 긍정적인 영향을 미쳤다는 건지 이해하기 어렵다. 현재 상황은 오직 부요를 만든 당사자들만 부요에 대해 말하고 있는 실정이다.

부요 규격이 하는 일이 레드햇/수세/우분투의 최신 기능과 (업데이트/가상화) 최신 버전을 써 넣는 것일까?  실제 현재까지 표준화된 규격을 보면 부요 규격은 리눅스 커널 옵션, LSB/FHS, 그리고 Fedora 최신판을 설명한 것에 지나지 않는다.

레드햇-노벨, 특허 침해로 피소?

레드햇-노벨, 특허 침해로 리눅스 벤더 중 최초로 피소

IP innovation이 애플을 고소했던 것과 동일한 특허로 레드햇과 노벨을 고소했다고 한다. 그 특허의 내용은 다음과 같다:

"workspaces provided by an object-based user interface that appear to share windows and other display objects."

ROTFL...

이 쉬운 단어들로 이렇게 애매하게 조합을 해 놓으면, 아마도 윈도우 시스템을 갖춘 모든 종류의 GUI가 여기에 해당할 것이다.

특허 제도의 폐해를 가장 잘 드러내 주는 대표적인 예가 바로 IP innovation과 같은 기업이다. 이러한 지적재산권 소송 전문 기업은 소프트웨어뿐만 아니라 모든 분야마다 존재한다. 그 분야에 실제로 연구개발이나 상품화를 진행하지는 않고, 오로지 지적재산권 거래와 소송을 통해 회사가 유지된다. 여러가지 이용 가능성이 높다고 생각되는 특허들을 사들여서 보유한 다음, 돈이 많다고 생각되는 기업들을 상대로 협상과 소송을 통해 매출을 올린다. 이러한 회사들은 실제로 소송의 최종 판결에서 승리할 가능성이 없더라도, 대기업을 상대로 위협을 가하면서 적당한 가격을 협상해 실질적인 수익을 올린다. (큰 기업 입장에서는 오랜 소송끝에 얻은 승리보다는 돈을 주고 협상하는 편이 더 이득일 수가 있으니까.)

그런데 노벨은 어쩔까? 특허를 전면에서 부정하기에는 찔리는 게 많을 텐데..

메일링 리스트와 Reply-To 헤더

(gnome-kr 메일링 리스트에 쓴 메일에 나오는 이슈를 재구성)

다른 분야라고 크게 다르지 않지만 컴퓨터 분야에서 수십년동안 계속되어 온 플레임^H^H^H토론들의 공통점은

• 많은 사람들이 자주 접하는 주제이다.
  
• 많은 사람들이 쉽게 이해할 수 있는 주제이다.
• 둘 다 상당한 숫자의 사용자/지지자가 있으며 살아생전에 사라질 것 같지 않다.
  
• 결국 똑같은 갑론을박만 하게 된다.

Emacs와 VI, C++과 plain C, 코딩 스타일, micro kernel과 monolithic kernel, CISC와 RISC, little endian과 big endian, ...   아마 게시판에 이중에 한 가지 주제를 장난처럼 한마디 쓰면 수많은 사람들이 전문가라도 되는 듯이 리플이 주루룩 달릴 것이다. 하지만 그 리플의 내용도 수십년전과 다르지 않다..

메일링 리스트가 발송하는 메일에 Reply-To 헤더를 붙이는 게 좋은가도 논란의 여지가 있고, 이야기를 하면 결국 똑같은 주장과 똑같은 반론이 나올 수밖에 없다.  일단 내가 읽고 있는 debian/gnome/fd.org/... 메일링 리스트들은 모두 Reply-To를 추가로 안 붙이는 정책을 쓰고 있고 거기에 동의하고 있다.  하지만, 여전히 반론도 읽어 볼 만한 가치가 있으므로~

Reply-To 반대 의견: http://www.unicom.com/pw/reply-to-harmful.html
Reply-To 찬성 의견: http://marc.merlins.org/netrants/reply-to-useful.html

CRM 스팸

요즘 스패머들의 경쟁상대는 바로 같은 스패머들. 어떻게든 읽게 하려고 별 짓을 다 하는데...  아무리 제목을 스팸처럼 안 보이도록 창의성이 떨어지고 스패머들이 서로 이용하기 때문에 나중에는 다 스팸처럼 보이게 된다. 그래서인지 오늘 받은 스팸은 아예 slashdot 제목을 활용하기 시작했다.

보낸 사람: sdalton 받는 사람: cwryu 제목: Survey Says GPLv3 Is Shunned 날짜: Wed, 26 Sep 2007 15:36:21 +0200 (22:36 KST)

CHINA VOICE HOLDING
Hot Stock in Momentum play for the week

OTC : C,HV~C
This company is nasdaq bound

...

그래도 slashdot의 꽤 최근 기사임. 자동화한 걸까?

Being Evil - 기사 링크 눌렀을 때 그 기사의 카테고리 띄우기

어제 오늘의 이야기도 아니고 포털의 운영 전략은 언제나 정보를 집중시키는 것이었다. 유저가 떠나가지 않고 계속 이용하게 만드는 것. 그래서 상단에 포털의 각종 기능을 이용할 수 있는 링크를 포함하고, 포털의 본 컨텍스트에서 벗어나려고 할 때 새 창을 띄우는 식으로 벗어나지 않게 만들고, 어떤 페이지에 들어갔을 때 연관된 페이지를 보여준다던가 하는 식의 기법을 도입했다.

하지만 상식적으로 각 사이트의 대문에서 기사 링크를 눌렀을 때 이용자의 의도는 그 기사를 보는 것인데, 그 기사가 안 뜨고 그 카테고리가 뜬다는 건 뭔가 이상하다. 원클릭을 투클릭으로 2배 비효율적으로 만들어 버렸다. 그렇게 해서 포털이 얻은 것과 잃은 것은 무엇일까?

(버그때문인 것 같은데..  다음의 경우 기사 링크를 눌렀을 때 그 기사가 카테고리 상단에 안 나올 때도 있다. 그러면 그냥 뒤로 가기 단추 눌러 버린다...)

iceweasel을 iceweasel이라 부르지 못하고...

한메일Express라는 것에 당첨되었다...라고 하는 메일이 한메일에 쌓였길래, 보려고 했더니 왠일인지 똑같다. 뭔가 이상해서 환경설정에서 Express 사용여부를 설정하면서 자세히 관찰해 보니까 뭔가 다른 페이지를 들어가려고 하다가 나가는 현상이 보였다. 그 순간에 나왔다 사라지는 한마디, "IE, Firefox 1.5, ... 이상에서만 사용할 수 있습니다."

"지금 iceweasel 무시하나요?"를 머리속에 대뇌이면서 about:config 에서 user-agent 값을 firefox로 고쳐버렸다. 그러니까 무리 없이 한메일Express로 잘 전환되었다.

그런데 머리 속을 스치고 지나가는 생각. "지금까지 티스토리의 에디터가 epiphany에서만 동작하고 iceweasel에서 동작하지 않은 원인이 설마 이것일까?" 지체없이 티스토리로 로그인, 에디터를 써 본 결과 맞았다. 얄밉게 잘 동작하는 에디터...  (epiphany에서도 찾아보니까 예전에 user-agent를 고친 설정이 남아 있었다.) 한메일은 그렇다 쳐도, 태터툴즈 에디터가 user-agent를 보고 다르게 동작할 줄은 꿈에도 몰랐다.


PS. "어쩔 수가 없이 이렇게 만들었다"라고 하기엔 iceweasel이라는 user-agent로 잘 동작한 웹용 에디터들이 너무 많다.

에볼루션 호환성과 한메일 버그들

그놈 에볼루션은 비교적 최근에 만들어진 메일 프로그램이라서 그런지 인터넷 메일의 표준에는 맞지만 현실과는 동떨어진 방식으로 동작하기도 한다. 슬프게도 한글과 관련된 부분에서 그런 모습이 많이 보인다.

예를 들어 좀 구버전의 MS-Outlook 혹은 MS-Outlook Express에는 헤더를 RFC2047 인코딩할 때 UTF-8로 인코딩하면 제대로 읽지를 못했다. 멀티바이트 인코딩은 본문 인코딩과 관계없이 대충 UTF-8로 보내는 정책을 사용했기 때문이다. 이렇게 동작하는 게 틀린 건 전혀 아니고, RFC2047을 지원하면서 UTF-8 인코딩이 지원되는 환경이므로 당연히 MS-Outlook의 잘못이고, 이 제목이 제대로 읽히도록 MS가 Outlook을 고쳐야 하는 게 맞다. 하지만 현실적으로 MS-Outlook은 사용자가 많아서 무시하기 힘든데다가 상업용 소프트웨어는 이러한 버그가 수정되려면 너무 오래 걸린다. (최근 버전에 고쳐질 때까지 2-3년은 걸린 듯)  표준을 지키는 다른 방법이 있으면서, 많이 사용하는 프로그램의 버그를 피해가는 방법이 있다면 꼭 에볼루션이 맞다고 고집할 필요는 없지 않을까? 하지만 게으른 개발자의 속성상 자기 잘못도 아닌데 귀찮게 고치기도 힘들 노릇이어서 결국 아직까지도 그렇게 동작한다. 내가 직접 본문이 EUC-KR일 때 제목이 EUC-KR 인코딩되도록 패치까지 만들었지만, 적용될 수는 없었다. (기술적인 이유도 있었다. 에볼루션의 코드의 메일 처리 라이브러리쪽에서 헤더를 독립적으로 UTF-8 인코딩해 버리는 구조였는데, 메일 설정이 넘어가도록 고치려면 상당히 귀찮은 작업이 필요하다.)

오히려 이런 문제는 MS-Outlook같은 데스크탑 프로그램보다는 각종 웹메일들에서 특히 잘 드러난다.  (아무래도 웹메일들이 데스크탑용 프로그램보다는 메일 표준을 구현한 완성도가 비교적 떨어지는 게 사실이다.)  마침 한메일이 개선사항을 모집한다고 하니 에볼루션과 한메일이 메일을 주고받을 때 생기는 버그 및 기타 리눅스 환경에서 생기는 문제를 짚어본다.

(1) Q 인코드된 제목의 디코딩

이 문제는 보고를 했는데 고객센터에서도 전달되었다고 하고, 다른 경로(?)로도 전달되었는데 우선순위가 밀렸는지 아직 버그가 남아 있는 상태이다.

위의 예에서와 같이 에볼루션에서 보내는 메일의 한글 제목은 UTF-8 인코딩하게 되는데, 그것도 Quoted Printable 인코딩이다. 그런데 에볼루션에서 메일을 이렇게 보내면,

한메일에서는 이렇게 공백이 밑줄로 나온다..

그런데 이상하게도 클릭해서 본문을 읽어보면 제대로 나와 있다.

Subject: =?UTF-8?Q?=EC=A0=9C=EB=AA=A9?=
        =?UTF-8?Q?_=ED=85=8C=EC=8A=A4=ED=8A=B8?=

"제목 테스트"라는 제목을 UTF-8 QP 인코딩하면 위와 같이 된다. RFC2047에 따르면 Quoted Printable을 디코딩할 때 밑줄(_)을 공백으로 해석해야 하는데 실수를 한 것 같다. 그런데 대체 왜? 메일 본문을 읽어보면 제대로 나오는 걸까? 메일 목록과 메일 본문의 QP 디코드 코드가 다른 걸까?


(2) 첨부파일 내용 인코딩

에볼루션이 아니라 (이제 거의 모두 UTF-8환경인) 리눅스 환경과의 호환성 문제이지만, 첨부 파일의 Content-Type의 charset 정보를 제대로 인식하지 않는다.

Content-Type의 charset 정보를 무시하고 EUC-KR로 해석하는 듯?
 

--=-ObVHrT1mp3C0HEttZi/U
Content-Disposition: attachment; filename*=UTF-8''%EC%97%90%EB%B3%BC%20%EB%A7%8C%EC%84%B8.txt
Content-Type: text/plain; name*=UTF-8''%EC%97%90%EB%B3%BC%20%EB%A7%8C%EC%84%B8.txt; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
 
=EC=97=90=EB=B3=BC =EB=A7=8C=EC=84=B8
 
 
--=-ObVHrT1mp3C0HEttZi/U--

(3) EUC-KR 페이지의 한계

다음이 많은 부분에서 UTF-8 페이지로 변환하고 있지만, 아직 한메일은 그렇지 못하다. 그래서 아무래도 해외 메일을 받는 용도로는 한계가 있을 수밖에 없다. 일본어 메일만 해도 많은 한자가 물음표 투성이가 된다.

(4) 보너스#1 - 빈 파일을 첨부하면

이 글을 쓰면서 발견한 건데...  사이즈가 0인 파일을 첨부한 다음에 첨부한 파일을 열려고 하면 오류가 발생한다.

--=-Jc22aP0z5j1kvSIVKmG+
Content-Description: =?UTF-8?Q?=EC=97=90=EB=B3=BC?=
    =?UTF-8?Q?_=EB=A7=8C=EC=84=B8=EC=97=AC?=
Content-Disposition: attachment; filename*=UTF-8''%EC%97%90%EB%B3%BC%20%EB%A7%8C%EC%84%B8.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
 
 
--=-Jc22aP0z5j1kvSIVKmG+--

(5) 보너스#2 - HTML 메일이 싫어요~

또 찾아낸 명백한 버그, 보낼때 하단에 있는 옵션을 어떻게 하든 항상 HTML 메일만 날아온다.