Tumblr로

http://changwoo-hacks.tumblr.com/

OOXML, OWPML 모두 공공문서 포맷으로 부적절

'전자문서 산업을 위한 학술 토론회' 관련 기사:

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20140725153903

OOXML은 ISO/IEC 29500 표준으로 MS 오피스의 포맷이고 (docx, pptx 등), OWPML은 KS X 6101 표준으로 한컴오피스2014부터 hwpx라는 이름으로 (아직은 시험적인) 포함된 포맷이다.

이 학술 토론회에서는 업체 사람들이 서로 자기 업체의 포맷을 가지고 자기 포맷이 더 개방적이고 표준으로 바람직한 공공문서 포맷이라고 주장하고 있으나, 사실 OOXML이든 OWPML이든 공공 문서 포맷이 되기에는 마찬가지 문제를 가지고 있다.

OOXML

OOXML의 문제는 이미 과거 표준화 과정에서부터 충분히 알려진 바 있다.

마이크로소프트 측은 6000 페이지의 문서로 구성된 표준을 급행으로 검토할 시간도 주어지지 않은 채 진행하면서, 그 전에 기존에 표준 결정 기구에 가입하지 않은 개발도상국가에 입회비를 지원한 스캔들이 있었다. 이들 개발도상국가가 표준안에 찬성표를 던진 것은 물론이다. (대한민국은 최종적으로 반대에 투표했다.)

http://www.zdnet.co.kr/column/column_view.asp?artice_id=00000039161482

기술적으로도 알려진 것만 해도 그렇다. OOXML은 기존의 바이너리 오피스 포맷을 가지고 XML을 컨테이너로 이용한 것 뿐이다. 이러면 XML 파서로 읽을 수 있을 뿐 기존 오피스 포맷과 다를 게 없다. 대표적인 예로 드는 useWord97LineBreaks attribute는 "Word97방식으로 렌더링하라"라고 지정되어 있고 그 Word97 방식이 무엇인지 설명하지 않는다.

http://msdn.microsoft.com/en-us/library/documentformat.openxml.wordprocessing.useword97linebreakrules%28v=office.14%29.aspx

OOXML은 마이크로소프트 사의 역사적인 이진 형식을 주의 깊게, 하나도 빠뜨림 없이, 꼼꼼하게 XML 형식으로 복사한 결과물일 뿐이다.

XML 은 새 문서 형식을 정의하는 강력하고 풍부한 도구지만, 프로젝트 범위를 잘못 정하는 실수까지 무마해 주는 만병통치약은 아니다. '참고할 문서가 없는 대형 독점 렌더링 라이브러리를 사용한다'는 플래그를 문서 형식에 넣는다면, 플래그를 문서 없는 이진 문자열 내 비트 하나로 명세하든 세 쪽짜리 <>으로 명세하든 상관이 없다. 이 명세는 어디까지나 독점이며, 단순히 XML로 감싸는 방법만으로는 렌더링이 불가능하다.

IBM Developer Works, "OOXML 무엇이 그리 대단한가 " 중에서, http://moonistar.tistory.com/m/post/16

OWPML

이 글을 쓰기 시작한 이유가 바로 이 포맷 때문이다. 올해 초에 직접 KS X 6101 표준 문서를 구입해서 한컴오피스 2014 체험판의 HWPX 결과물과 같이 검토해 봤기 때문이다.

바이너리 MS 오피스 포맷을 XML로 옮긴 게 OOXML이라면, 바이너리 HWP 포맷을 XML로 옮긴 게 바로 OWPML이다. 이것 뿐이다. XML의 파일 하나하나는 HWP에 있던 Compound Document의 스트림 하나하나에 대응하고, XML 태그 하나하나는 HWP에 있던 레코드 정보에 대응하고, XML 속성(attribute)은 레코드의 바이너리 데이터에 해당한다. IP over XML 같은 만우절 장난이라면 몰라도, 이런 포맷을 만드는 게 무슨 의미가 있는 걸까?

KS X 6101 역시 OOXML 포맷과 같은 오류를 저지르고 있다. 무엇무엇이 있다라는 설명만 하고 실제 어떻게 구현되는지 제대로 설명하지 않아 사실상 한글과컴퓨터의 구현만이 알 수 있게 되어 있다. 예를 들어 표준 7.1에 보면 XMLTemplate/ 이라는 폴더에 대해 언급했으면서 표준 문서 다른 어디에도 여기에 대한 설명이 없다.

또 한 가지 예를 들면 표준 문서 "8.2.4 호환성 정보"를 보면 "compatibleDocument" 태그가 있다.

<compatibleDocument  targetProgram="MS_WORD">...

이런 식으로 쓰면 붙이면 MS-Word 방식으로 렌더링한다. 앞의 OOXML에 있던 useWord97LineBreaks 속성이 생각나는 부분이다. 이 MS-Word 방식이 무엇인지는 알 길이 없다. 원래 HWP 포맷에도 마찬가지의 호환성 문서 정보가 있는데 이 정보까지 OWPML에 그대로 구현해 놓은 것이다. 한컴오피스에서 MS-Word 문서가 상당히 잘 변환되는 비밀이 여기 있다. HWP 포맷에 MS-Word 호환 모드가 있고 한컴오피스에 MS-Word와 비슷한 렌더링 방식을 구현해 놓은 것이다. 이런 것까지 표준에 포함하면 표준 구현은 한컴오피스가 한 것처럼 MS-Word 렌더링 방식까지 따라해야 한단 말인가?

이런 문제점을 지적해야 할 표준 심의 과정도 문제였다. KS X 6101:2011 문서의 해설에 기록되어 있는 표준 제정 과정의 7가지 심의 의견 중에서 문제를 지적한 의견이 6가지인데, (1) 표준 제목 수정 (2) 오타 수정 (3) HWP 약자 설명 추가 (4) ODF, OOXML 상호운용성 추가 (5) ODF, OOXML 인용 추가 (6) 수식, 화학식 누락. 이 중에서 (1)(2)(3)(5)은 단순 수정이고, (4)는 이 표준에서 해당하지 않는다고 조치했고, (6)에서 수식이 추가 된 게 그나마 유일하게 의미 있는 문제점 수정 사항이었다. 한글과컴퓨터에서도 최근 한컴오피스2014에서 처음 구현했으니 검증될 기회도 없었다.

OOXML과 마찬가지로 똑같은 포맷을 XML로 감싼다고 해서 구현할 수 있는 건 아니다. 검토했던 결과를 다음 페이지에 기록해 놓았다.

https://docs.google.com/spreadsheet/ccc?key=0AjxIVzS0OjQTdEc5V1dhLWJwenhSTEpPWGNMdy12NUE&usp=sharing

기록한 것과 같이 OWPML은 표준에도 오류가 있는데, 이 포맷을 최초로 구현한 한컴오피스 2014의 HWPX 포맷에서도 표준에 없거나 표준과 다르게 사용하고 있다.

ODF 뿐이다

아무리 OOXML과 OWPML이 표준으로 인정받았더라도, 의도적이든 아니든 사실상 특정 업체 독점적이 될 수밖에 없도록 기술된 포맷은 공공문서의 포맷이 되면 안 된다. 현재 나와 있는 해법은 ODF 뿐이다. ODF는 다들 좋아하는 그 표준을 국제/국내 모두 오래전에 획득했다.

물론 같은 학술 대회에서 다음과 같이 한컴 측이 주장한 것과 같이 ODF도 구현별로 차이가 나는 것도 사실이다.

또 국제표준이 만능이 아니라고 반박했다. 그는 “MS 오피스도 환경에 따라 레이아웃이 깨지는 경우가 많고, ODF도 오픈오피스, 심포니, MS 오피스 등 구현회사마다 조금씩 차이가 있다”고 말했다.

http://www.ddaily.co.kr/news/article.html?no=120789

하지만 구현 과정에서 조금 차이가 난 것과, 아예 기본적인 명세부터가 제대로 독립적으로 구현하기 힘든 것과는 천지 차이이다. (게다가 오픈오피스는 오픈소스이고, 심포니는 오픈오피스 기반으로 개발된 것이다. MS 오피스의 ODF 지원 기능은 외부에서 만든 플러그인이 더 낫다고 할 정도로 완성도가 낮아서 생긴 일이다.  http://en.wikipedia.org/wiki/OpenDocument_software#Microsoft_Office_2007_SP2_support_controversy )

ODF를 사용하도록 규칙을 제정하고, 공공에서 사용하는 한컴오피스에 대해 기본 포맷을 ODF로 저장하도록 하는 게 처음 한 걸음이 될 것이다. 문제가 되는 HWP 문서 생산을 멈춘 다음 과거 HWP 문서의 변환도 고민하자.

OSI approved 라이선스가 인정받지 못하는 케이스

최근의 오픈프론티어 오픈소스 라이선스 세미나에서 발표했던 사례,

http://www.slideshare.net/changwoo/20140715-37005257


예외적인 케이스에 대한 이야기는 보통 재미있다. 지금까지 갖고 있던 생각이 고정관념이 아니었나 한번 쯤 가다듬는 기회가 되기 때문일 것이다. 재미있는 케이스를 찾다 보면 지나치게 예외적인 이야기에 치중할 수도 있는데, 이 경우는 한번 OSI-approved 라이선스의 예외적인 경우를 지적해 보고 싶었다.

예로 들었던 예외는 NASA Open Source Agreement(NOSA)라는 라이선스이다. NASA(미항공우주국)는 유일무이한 일을 하는 기관이니만큼 다른 곳에서 보기 힘든 상당히 흥미로운 소프트웨어를 공개하고 있다.

http://ti.arc.nasa.gov/opensource/

여기 사용되는 라이선스가 이 NOSA 라이선스이다. 예외로 들었던 이유는 이 라이선스는 OSI approved 라이선스이지만, FSF나 데비안은 거절했기 때문이다.

http://www.gnu.org/licenses/license-list.html#NASA

문제되는 조항은 이 부분인데

G. Each Contributor represents that that its Modification is believed
to be Contributor's original creation and does not violate any
existing agreements, regulations, statutes or rules, and further that
Contributor has sufficient rights to grant the rights conveyed by this
Agreement.

문제되는 부분이 "original creation"으로, 수정을 할 때는 수정한 부분이 자기의 독자적인 창작물이어야 한다는 것이다. 다른 소프트웨어에서 (같은 NOSA 라이선스라고 해도) 붙여 넣는 것도 안 되고, 이 코드를 다른 소프트웨어에 붙여 넣는 것도 안 된다. 수정하는 방식을 이런 식으로 제한하는 일이 수정을 보장하는 것으로 볼 수 있을까? 수정하는 방식에 제한을 두면 가혹하다고 생각하지만, 어떻게든 수정을 보장하고 있으니까 오픈소스 아니냐고 하면 그럴듯하기도 하다. (GPL이나 다른 많은 라이선스는 수정한 부분의 라이선스를 제약하고 있지 않은가?)

OSI에서 허용했는데도 불구하고 FSF나 데비안에서 이 라이선스를 거절한 이유를 정해진 규정이나 원칙에서 찾기는 힘들다. 데비안이 거절한 것은 더 흥미롭다. Bruce Perens가 오픈소스정의(Open Source Definition)를 만들 때 데비안 자유소프트웨어 가이드라인(DFSG)을 가져다 만들었으니 OSI나 데비안이나 기본 원칙은 다르지 않다. 즉 이 결정은 오픈소스정의와는 상관없는 부분이라는 뜻이다.

오픈소스의 기준이 Open Source Initiative가 정한 것이므로, OSI approved면 오케이라는 생각은 대부분 맞겠지만, 이런 경우가 있으므로 절대적인 기준으로 삼기는 힘들 것이다. OSI approved라고 해서 특정 기관이나 특정 필드에서 쓰도록 설계된 라이선스를 그 외의 분야에서 가져다 쓰는 것도 바람직하지 않고 말이다. 대부분의 사람들이 동의하는 많이 쓰는 라이선스를 쓰는 것이 바람직하다고 할 것이다.

freshmeat이 망한 이유

Bad Voltage 팟캐스트 1x19 에피소드 중에서 freecode(freshmeat)와 관련된 얘기,

http://www.badvoltage.org/2014/06/26/1x19/ (33:20부터)

리눅스 배포판 개발과 사용에 있어서 생각할 만한 게 많은 것 같아서 해당 부분을 대략 번역한다.

<Jeremy> 며칠 전에 freecode, 과거에 freshmeat였던 사이트가 고정 웹사이트로 변했어요. 여러분이 옛날 freshmeat을 얼마나 쓰셨는지 모르겠지만, 제 생각에는 엄청나게 유명했던 곳이었어요. (모두 공감) 그런 점에서 몇 가지 의문이 드는데요. 진짜 이유가 무엇이라고 생각하시나요? 오늘날 리눅스 소프트웨어에 무슨 일이 일어난 걸까요? 앱스토어같은 것 때문일까요, 그냥 패키지가 잘 동작하기 (just work) 때문일까요. 무슨 일 때문에 이렇게 된 것일까요.

<Stuart> 그건 이제 아무도 GIMP 0.1 alpha를 다운로드하지 않기 때문이죠. (모두 웃음)

<Jeremy> 한 가지 지적할 점은 그 당시는 다른 어떤 사이트보다도 freshmeat이 소프트웨어의 최신 내용을 담고 있었어요. 심지어 메인테이너들이 자기 홈페이지보다 더 freshmeat에 먼저 발표하곤 했죠.

<Bryan> 네 그 점이 핵심이예요. 그 당시에는 신선(fresh)한 내용이었죠. 그런데 이제는 신선한 내용이 아니니까 아무도 신경쓰지 않게 됐죠.

<Jono> 그냥 고기(meat)죠. (웃음)

<모두> 네 오래된 고기(old meat)예요.

<Stuart> 네 바로 그 부분이에요. 재미있는 부분이 Jeremy가 말한 그대로예요. 10-15년 전에는 모든 소프트웨어 메인테이너들이 freshmeat를 썼어요. freshmeat이 유일한 수단이었죠. 하지만 더 이상 아니에요? 왜일까요?

<Bryan> 제 생각에 큰 부분은, 당시에는 패키지 관리는 새로운 개념이었어요. RPM 패키지 관리는 얼마 안 됐고 데비안은 패키지 관리가 당시에도 있었지만 데비안을 모두가 쓰지는 않았죠. 그래서 기준이 freshmeat로 가서 tarball을 다운로드한 다음에 빌드하는 거였어요. "./configure; make; make install"하는 거죠. 또, 제가 기억하기에는 freshmeat에 등재되는 게 일종의 훈장 같이 취급됐어요. "우와 freshmeat에 올라간 소프트웨어라니 멋지다"라고요. ("맞아요 맞아")

<Bryan> 그런데 그 일부분을 배포판들이 대체했어요. 또 소프트웨어를 직접 다운로드해서 설치하는 방식은 사용하지 않죠. 폰이나 데스크톱에서도 더 이상 그렇게 하지 않아요.

<Bryan> 또 한 가지 제 느낌에는, freshmeat을 소유한 회사에 대해서 잘은 모르지만 sourceforge도 인수했죠? 제 생각에 이건 리소스 낭비였어요. 이제 아무도 freshmeat을 신경쓰지 않아요.

<Jono> 저는 이게 리눅스만의 이슈가 아니라고 생각해요. 당시에는 맥의 경우에도 versiontracker라는 기본적으로 freshmeat과 똑같은 일을 하는 사이트가 있었어요. 당시에도 거기 가면 각종 업데이트된 정보가 들어 있었죠. 모든 맥 유저가 그 사이트를 봤어요. 윈도우 사이트도 마찬가지로 있었고요. 하지만 지금은 비슷한 일을 하는 오만가지 경쟁자들이 나타났고 중앙 집중적인 한 사이트가 이제 없어요. 어떤 사이트를 가도 최신 업데이트된 내용을 담고 있다고 확신할 수 없게 됐죠. 그러니 아무 것도 사용하지 않게 된 거고요. (...)

<Stuart> 네 같은 비극이 일어난 것 같네요. freshmeat 1개 사이트만 있을 때는 이 사이트에 모두 있는데,  누군가 "야 freshmeat같은 사이트를 만들면 돈을 벌 것 같아" 하면서 사이트가 2개 3개가 되면서 모든 사이트의 가치가 제로가 되고 더 이상 이용하지 않게 되는 거죠.

<Jono> 일반적으로는 동의해요. 다른 얘기를 하면 이제 데비안 패키지 저장소도 있고, 우분투도 있고 페도라도 있어요. freshmeat은 상당히 리눅스에 치우쳐져 있잖아요? 당시에는 크로스 플랫폼 이었어요. 모든 소프트웨어가 어떤 배포판에도 돌아갔죠. 직접 컴파일하니까요.

<Stuart> 정확히 말해서 크로스 리눅스겠죠?

<Jono> 아 미안해요. 네 크로스-리눅스배포판이죠. 그런데 점점 자기 소프트웨어를 데비안, 우분투 또는 페도라에서 컴파일하겠다라고 말하고 다른 배포판은 신경쓰지 않겠다라고 말하는 게 허용되는 분위기예요.

<Stuart> 거기에 대해서 일부 이유를 말하면, 우분투와 페도라가 상당히 달라요. 당시에는 예를 들어 슬랙웨어와 데비안은 별로 다르지 않았어요. 각종 설정 옵션이 다르기도 하고 네트워크 파일 방식이 다르고 그런건 있지만 기본적으로 어떤 배포판을 쓰든 같은 사용자 경험을 공유했죠. 분화되지도 않았는데, 이유 중 하나는 당시에는 달라져야 한다는 요구 사항이 별로 없었어요. 그럴 시간도 없고요.

<Jeremy> Jono의 의견에 동의해요. freshmeat은 "configure; make; make install"시대의 산물이죠. 한 가지 더 문제를 말씀드리면 제가 과거에 freshmeat 이용을 중지한 건 사이트를 개편하면서 부터에요. 사이트의 대부분의 기능을 없애 버렸죠. 당시에 제가 이용했던 건 trove 였는데.. trove는 잘 관리되고 있고, 예를 들어 파이썬으로 작성된 BSD 라이선스의 메일 클라이언트를 찾는 건 trove 계층에서 쉽게 찾을 수 있었어요. 그런데 freshmeat 사이트가 개편되면서 그 데이터를 통째로 잃어버렸죠. 그리면서 소프트웨어 센터, 패키지 관리 따위가 쓸만한 수준으로 좋아졌고요. 어쨌든 사이트를 개편한 게 큰 역할을 했어요.

<Stuart> 네 옛날에 "fm"이라는 freshmeat의 trove를 이용해 검색하고 결과를 출력하는 프로그램을 작성했던 기억이 있네요. 사이트가 개편되면서 동작을 안 했고요.

<Jono> 사이트 관리가 문제였던 것도 맞아요. 그리고 주인이 많이 바뀌었어요. 기억이 가물가물한데 slashdot과 합병했죠? ("네") 그리고 ("geeknet으로 갔다가, 그 다음엔 다시 sourceforge랑 합병하고.,."). 하고 싶은 말은 사이트의 자산이 회사를 거쳐가면서 이익이 되는 slashdot과 geeknet에 자원이 집중됐을거예요.

(...) 개인적으로 이제 저는 소프트웨어를 컴파일하는데 신경 쓰지 않아요. 여러분이 KDE에 기여하는 사람이라면 아마 KDE 컴파일에 신경 쓰겠지만 파이어폭스나 커널을 빌드하지는 않을 거예요.

<Bryan> 제 생각에 freshmeat이 이제는 의미가 없더라도, 고정 페이지로 남겨두고 최소한 과거 컨텐츠를 볼 수 있다는 건 괜찮은 것 같아요.

<Jeremy> 실제로 ESR이 다른 이름으로 freshmeat을 되살리려고 하는 거 알아요?

<Bryan> 진짜요?

<Jeremy> VA의 이사회 멤버라서 slashdot과 freshmeat을 인수하라고 설득한다는데요. 그래서 사이트를 다시 시작한다고요. ESR이 말하는 건 사람들이 다운로드하지 않는다고 해도, 패키징하는 사람은 패키징할 걸 어디서 찾아야 하지 않느냐는 거예요.

<Bryan> 음, 사실 중요한 부분이긴 해요. 알게 뭐예요. ESR이 그러고 싶다는데.

<Jono> 하하. 제가 배포판 작업을 하면서 한 가지 배운 게 있는데요. 배포판에서는, 항상 패키징할 게 있어요.

<Stuart> 아이고 ESR이 말하려고 하는 건 잘 알겠어요. ESR이 당시에는 유명한 사람이었고요. 그 당시의 방식을 좋아할 수도 있죠. 근데 지금 15년 전 웹사이트를 살리려고 하고 있어요. 오래 된 건 그냥 넘어가지.

<Bryan> 이봐요. 저는 아직도 BBS를 돌리고 있어요. 오래된 건 멋져. (웃음)

(2014.7.13 업데이트)

의미 있게 생각했던 이유는, 마치 "Video killed the radio star"와 같은 얘기를 듣는 것 같아서였다. 리눅스 배포판이 freshmeat을 죽였다. 딱히 내가 라디오 스타의 팬은 아니고, 오히려 죽이는데 일조했던 입장이지만.

사실 상업 운영체제에서 최근에서야 시작한 온라인 소프트웨어 배포 및 업데이트 시스템은 데비안이나 리눅스 배포판에서 먼저 생겨났다. 상업 운영체제에서 최근에 가능했던 이유는 독점적인 정책을 가진 운영체제나 디바이스를 가진 큰 회사가 등장했고 대규모 IT 인프라를 구축할 수 있었기 때문인데, 리눅스 배포판에서는 역설적으로 소스코드가 있으며 수정과 배포가 자유로웠기 때문에 얼마든지 일관성 있는 패키지를 노력만 하면 만들어 낼 수 있었고, 세계 곳곳의 미러사이트에 복사를 해 놓을 수 있었다. 결제나 사용자 정보를 신경 쓰지 않아도 됐고 말이다. 데비안에서는 패키지 업데이트 시스템인 APT가 1998년에 만들어졌고, 그 전에도 dselect라는 프로그램에 FTP나 HTTP를 통해 패키지 업데이트를 할 수 있었다. 그래서였는지 나는 당시에도 FTP 사이트에서 패키지 자동 업데이트를 했지 freshmeat에서 확인한 소프트웨어를 다운로드해서 설치하는 일은 별로 없었던 것 같다.

이 후 직접 데비안 개발자가 되고, 패키징을 하면서 날이 갈수록 더 배포판의 영향력은 커짐을 느꼈다. 상업적인 배포 시스템처럼 프로모션을 하는 건 아니지만, 배포판은 항상 앞에 나서서 소프트웨어를 선택하는 일을 했다. xfree86의 라이선스 변경에 반발한 리눅스 배포판들이 xorg를 선택한 결과 지금 xfree86은 홈페이지만 남아 있을 뿐이고, LibreOffice를 선택한 결과 Apache OpenOffice보다 (커밋 수로 보든 개발자 수로 보든) 몇 배 더 개발이 빠르게 진행되고 있다. 배포판이 기본으로 선택한 데스크톱 환경이 사용자가 급증하는 모습을 보이기도 했다. 처음 데비안 프로젝트는 데비안 홈페이지에 써 있는 것처럼 "Universal OS"를 만들려는 목적이었겠지만, 이제는 사용자의 선택에 영향을 미치는 소프트웨어 배포 채널이 되어 버렸다.

행정용 "한국형 OS 개발"에 대해

2014년 3월 25일 기사: 정부, 공개 SW기반 한국형 OS 개발 나선다

과거에도 부요의 문제점에 대해 언급했었지만 ([1] [2]) 간단히 평하면,

• 탈 윈도우나 오픈소스 기반 OS 사용이라는 기본적인 방향 자체는 환영할 만한 일이라고 생각한다. 하지만 과거에 실패했던 일들을 되새길 필요가 있다. 
• 과거 부요의 개발과 배포 방식을 왜곡시킨 장본인이었던 ETRI 주도의 절차는 배제해야 한다. "기술이전"을 통해 수익을 올려야 하는 ETRI의 폐쇄적인 개발 모델은 동작하는 오픈소스 개발 방식이 아니다. 이미 부요는 10년전 실패한 역사이다. 활용할 가치가 있는 것도 남아있지 않을 뿐더러, 오히려 과거의 방식 때문에 왜곡될 가능성이 높다. 부디 바닥부터 시작한다는 마음으로 시작해야 한다.
• (업데이트) 구체적으로 당시 ETRI 부요 배포판의 문제는 업체 입장에서 일단 실속도 없으면서 굉장히 조건이 까다로웠다는 점이다. 마지막 부요 3.0의 경우가 이런 식이었다. 약 5년전 중소기업 기준 1억7500만원의 착수금과 매출 2.7%의 런타임 로열티가 사업자의 입장에서는 그렇게 비싼 건 아닐 수도 있지만, 배포판 커스터마이즈 정도와 (분쟁이 일어난다면 실효성이 있는지 논란의 여지가 굉장히 많은) 소프트웨어 특허 몇개가 그만한 가치를 할까? (미안한 얘기지만 부요 기반으로 배포판을 만들었던 회사는 "표준리눅스"라는 겉포장에 넘어간 호구 고객이었다.) 게다가 리눅스에서 소프트웨어 특허에 배포 제한이라니 이게 대체 무슨 분위기 파악 못하는 얘기인가? GPL에 특허에 대해 royalty free 조건이 있다는 걸 ETRI에서는 알기나 하는 걸까?
• 업체 미팅과 간담회로 폐쇄적으로 진행되는 개발이 아니라 누구나 소스코드를 볼 수 있고 누구나 의견을 제시할 수 있는 공개적인 개발이 이루어져야 한다.
• 현 정부 임기를 고려한 것인지는 모르겠으나, 3년이라는 시간은 너무 짧다. 독일 뮌헨이 부럽다면 뮌헨처럼 10년 이상 진행하고 그 이후로도 계속 진행한다는 마음가짐을 갖고 있어야 한다. 장기적으로 지속적인 투자가 필요한 문제이지, 단기적으로 많은 투자를 하면 눈먼 돈만 많이 쓸 뿐이다.
• 오픈소스는 원래 전세계가 같이 만들고 같이 쓰는 것이다. 한국형, 독자, OS주권, 경쟁력같은 말은 이제 안 먹힌다는 걸 깨달을 때가 됐다. 개발을 진행한다면 리눅스 기반 행정용 OS 개발이 아니라 리눅스 데스크톱 환경을 국내 행정용 목적에 맞게 발전시킬 수 있어야 한다.
• 그런 면에서 정부부터가 오픈소스의 적극적인 생산자가 되어야 한다. 개발 과정을 통해 만들어낸 결과물이 배포판 패키징으로 끝나지 않고 업스트림에 올라갈 수 있도록 해야 한다. 그렇게 하면 아마 (탈윈도우나 OS 개발은 실패할지 모르겠지만) 오픈소스 데스크톱 발전에는 조금이라도 기여했다고 역사에 남을 것이다.

"공개소프트웨어"는 "오픈소스"가 아니다

2000년 초중반, 대한민국 정부가 오픈소스를 정책에서 여러가지로 고려하기 시작하면서 정부 주도하에 새로운 용어를 만들어냈다.  바로 "공개소프트웨어"이다. 엉뚱하게도 "Open Source"의 번역이다라고 주장했는데, 처음 그럴 때는 저러다 말겠지 싶었다. 하지만 십수년이 지난 지금까지 안 먹히는 용어를 밀어붙이는 걸 보면 해도해도 너무한다 싶다.

2014년 1월에 개정된 미래창조과학부 고시 "정보통신,방송 연구개발 관리규정"을 보면 아예 용어부터 공개소프트웨어라고 적어놓았다.

40. "공개소프트웨어"라 함은 "오픈소스 소프트웨어" 또는 "오픈 소스" 등 그 명칭과 상관없이 소프트웨어의 저작권자가 해당 소스코드를 공중에 공개하여 이를 사용, 복제, 수정, 배포할 수 있는 권한을 부여한 소프트웨어를 말한다.

41. "공개소프트웨어 라이선스"라 함은 공개소프트웨어 저작권자가 자신의 공개소프트웨어의 사용, 복제, 수정, 배포와 관련하여 허용되는 권한 범위를 명시한 이용허락조건을 말한다.

42. "공개소프트웨어 개발방식"이라 함은 소프트웨어의 소스코드를 공개하고 소프트웨어를 개발 및 유지 관리하는 전 과정에 최초 개발한 자 외에도 누구나 자유롭게 참여할 수 있도록 하는 개발방식을 말한다.

         

아마 정부 말고는 이렇게 오픈소스를 공개소프트웨어라고 부르는 사람은 없을 것이다. 또는 정부 정책에 동조하는 (또는 동조하지 않더라도 눈먼 돈에 관심이 있는) 기업들도 이 용어를 사용한다. 과거 리눅스 관련 회사들의 모임인 리눅스협의회가 전신인 "공개SW협회"가 대표적인 예이다.


"공개소프트웨어"는 옛날부터 하늘소 "이야기"나 안랩 설립 전의 "V3"와 같이 그냥 공짜로 배포하는 (하지만 소스 코드도 없고 명확한 제한 조건이 있었던) 소프트웨어를 가리키는 용어였다. 이 용어를 오픈소스를 가리키는 말로 사용하는 건 오픈소스의 의미를 왜곡하는 것이다.


진짜 문제는, 전세계가 같이 만들어 나가고 같이 쓰는 오픈소스의 의미를 공무원들이 불편해하고 있다. 각종 정책에서도 기업 위주로 혜택을 주고, 엉뚱하게 특허나 상용화를 강조하는 모습을 보면 그렇다. (사실 15년동안 데비안 개발자였지만 데비안으로 산업화를 어떻게 하냐 물어보면 할 말이 없다.) 정부가 바라보는 오픈소스는 기업화된 모습이지 그걸 만들어낸 해커 문화와 공동체 의식은 안중에 없는 것 같다. 기업화된 오픈소스의 모습도 지금의 현실이고, 좋다 나쁘다 가치 평가를 할 수 있는 것은 아니다. 하지만 어떤 오픈소스도 기업만으로는 동작하지 않는다.

애초에 "Open Source"라는 용어는 "Free Software"가 가진 영어 의미의 중의성이나 "자유"라는 단어가 주는 불편함을 완화시키기 위해 만든 말이다. 하지만 이 말조차 불편해 하면 무엇을 할 수 있을까.

정말 오픈소스의 활성화를 생각한다면 현실과 동떨어지고 왜곡된 용어부터 바로잡아야 할 것이다.

공인인증서, 보안이 중요하다면 이렇게 불편하지도 않았다

흔히 공인인증서가 NPKI 폴더에서 파일로 복사할 수 있는 것에 대해 공인인증서의 보안 문제를 비판하곤 하지만, 그에 대한 대안으로 (김기창 교수 주장처럼) 브라우저나 OS에 있는 인증서 저장 기능을 제시하는 건 올바른 대안 제시가 아니라고 생각한다. (물론 그렇게 하는 게 좋다. 하지만 그 점은 보안 때문이 아니라 편의성이나 OS 공통 인터페이스 사용이라는 문제에서 접근해야 할 것이다.) 얼마나 어려운가 차이는 있겠지만 결국 복사되는 건 마찬가지이기 때문이다. 아니 애초에 데이터 형태로 키를 만들어서 거기에 집어 넣는 것부터가 복사가 아니던가?

인증서를 공인했든 공인하지 않았든 컴퓨터에 들어 있는 한 모든 인증서는 같은 비판에 직면하게 될 것이다. 인증서의 복사를 근본적으로 막는 방법은 스마트카드나 TPM과 같이 인증서 자체를 하드웨어에서 읽지 못하게 만드는 것 뿐이다. 하지만 그게 우리가 원하는 미래인지는 모르겠다. 발급에 일정 비용이 반드시 필요하고 온라인에서 발급하는 건 불가능해질테니까.

애초에 인증서를 온라인에서 발급하는 것도 문제이다. 특히 재발급의 경우는 그렇다.지금까지 발생했던 온라인 금융 해킹에서 공인인증서 시스템을 우회했던 방법은 모두 개인정보를 취득한 다음 인증서를 재발급한 경우 아니던가? 하지만 마찬가지로 인증서의 오프라인 발급이 우리가 바라는 미래인지는 의문이다. 인증서를 잃어버리는 일은 너무도 흔하게 발생하니까 비용은 말할 수 없이 증가할 것이다.

그러면 공인인증서 시스템의 포인트를 어디로 잡을 수 있는 걸까? 저울질을 해 보자. 공인인증서 및 관련되어 설치해야 하는 액티브엑스의 불편함으로 인한 비용은 보안을 생각하면 감수할 만한 것이고, 인증서 복사를 근본적으로 막는 방법이나 인증서 허위 재발급을 막는 비용은 보안 위험을 감수하고서라도 감수할 수 없는 비용인가? 이 두 가지 저울질의 차이점은 후자의 경우 비용이 금융기관의 부담으로 돌아온다는 것이다. 오프라인 창구 업무가 말도 안 되게 늘어날 것이고 전에 없던 하드웨어 원가도 들어간다.

보안 회사들 역시 상식적이라면 문제에 대한 대응 방법으로 하드웨어 토큰 사용이나 재발급을 막는 걸 주장했을 것이다. 단지 금융 회사들은 직접적인 비용 부담 때문에 받아들이지 못했을 것이다. 그래서 대안은 사용자 컴퓨터에 백신과 방화벽을 설치하는 것과 같이 컴퓨터 보안을 강화하는 장치를 잔뜩 추가한 것이다. 그나마 PC에서는 하드웨어 토큰을 사용할 수도 있는데 스마트폰에서는 그것도 안 된다. 스마트폰에서 동작하는 백신 앱도 아주 제한된 일밖에 하지 못하고 심리적인 안정을 줄 뿐이다. (이제부터 안심할 수 없게 됐다면 죄송.)

부디 기본으로 돌아갔으면 좋겠다. 진짜 보안을 고려했다면 애초에 이 정도로 불편해지지도 않았을 것이다.

리눅스에서 왜 유튜브 제목의 초중종성이 분리되는가

리눅스에서 몇몇 유튜브 영상을 보면 제목이 요상하게 초/중/종성이 분리되어 있는 걸 볼 수 있다.

마침 이 NHN NEXT 페이지가 매우 인상적인데, 리눅스에서는 "NHN NEXT 2014학년도 2차 모집 안내동영상_서류제출안내" 영상의 제목이 끝의 "류제출안내"만 "ㄹㅠㅈㅔㅊㅜㄹㅇㅏㄴㄴㅐ"와 같이 보인다.

http://www.youtube.com/user/NHNNEXT

아마도 이 영상을 올리신 분은, 맥에서 "류제출안내"를 파일이름에서 복사해서 붙여넣기 하셨을 것이다.

근본 원인: 맥 오에스의 파일시스템

문제의 시작은 맥 오에스 파일시스템이 내부적으로 유니코드 인코딩을 NFD로 (참고: 유니코드 정규화) 사용하기 때문이다. 맥 오에스의 이 정책은 한글 뿐만 아니라 독일어 umlaut나 프랑스어 cedilla 같은 각종 액센트도 마찬가지로 적용된다. 한글의 경우 NFD는 한글 음절 코드가 U+1100의 한글 자모 코드로 변환되어 초중종성 코드로 나뉘게 된다.

이 문제는 유튜브 외에 여러 곳에서도 드러난다. 네트워크 파일시스템에서 한글 파일이름의 인코딩을 바꿔서 저장한다거나, 배포한 압축 파일의 파일이름도 초중종성이 분리되어 있거나, SVN으로 받은 한글 파일이름을 맥 방식으로 바꿔서 커밋한다든지, 구글 드라이브를 맥에서 싱크하니까 모든 한글 파일이름의 초중성을 분리한다든지 따위의 해프닝이다.

애플의 이러한 정책은 기술적 취지는 이해할 수 있다. 유니코드에서 같은 내용을 여러가지 방법으로 표현할 수 있는 문제가 있기 때문에, 전부 NFD로 바꾸면 한 가지 방법으로 전부 커버할 수 있으면서 유일성을 보장할 수 있다. 하지만 파일 이름이 파일 이름이 아닌 곳에서 드러난다는 건 문제이다. NFD가 틀린 인코딩은 아니다. 하지만 맞다 틀리다의 문제가 아니라, 일반적으로 많이 쓰이는 인코딩을 사용하는 게 상식적이지 않을까.

나눔 글꼴의 기능 미비

이 경우에도 결국 한 음절로 표시하면 되지 않느냐라고 물을 수 있는데, 리눅스의 글꼴이 그런 기능을 지원하면 가능하다. 하지만 현재 대부분 리눅스 배포판에서 사용하고 있는 나눔 글꼴에는 그런 기능이 들어 있지 않다. 이런 나눔글꼴 수정도 작업 중인 게 있으니 앞으로는 이런 기능의 글꼴이 일반적이 될 수도 있지 않을까.

Pango의 버그

윈도우나 맥용 글꼴이라고 해서 한글 자모 코드를 잘 지원하는 건 아니다. 그러면 왜 리눅스에서 유독 분리되어 보일까. 보통 현대 음절의 경우는 글꼴을 사용하기 전에 렌더링 엔진이 조합해 주기 때문이다. 별다른 기능이 아니기 때문에, gtk에서 사용하는 렌더러인 pango의 한글 렌더러를 처음 작성할 때부터 들어 있었는데 무슨 이유에서인가 망가져 있다. 다음 버그로 보고된 상태.

https://bugzilla.gnome.org/show_bug.cgi?id=705727

구글이 좀 고쳐주지

사실 가장 쉬운 해결 방법은 유튜브에서 자동으로 바로잡아 주는 것. 굳이 사용자가 올린 형태를 유지할 필요도 없을 것 같고, 어차피 내부적으로 검색도 하려면 변환하는 게 큰 문제는 아닐 것이다. 실제로 dropbox같은 경우 처리를 해 주는지 맥과 다른 OS 사이에서 한글 파일이름 공유에 문제가 없다.  하지만 구글에 뭐 고쳐달라고 요청한다고 고쳐주는 것 만큼 어려운 건 없으니...



위의 넷 중에 어떤 방법이든 바로잡으면 제대로 동작한다.

새 hwp 리스트

libhwp 그룹스마저 폭파됐기 때문에, HWP 그룹스를 새로 만듭니다. 앞으로 어떻게 될지는 모르겠지만 언제나처럼 가볍게 시작합니다.

https://groups.google.com/forum/#!forum/hwp-foss


libhwp 리스트 복구에 대해

제 메일에 있는 내용은 다음에 mbox 포맷으로 올려놨습니다.

https://sites.google.com/site/libhwprestored/home

- 제가 가입한 2010년 10월 22일부터 메일은 다 있지만 그 전에는 없습니다. 거의 만들어지자 마자 제가 가입했기 때문에 누락된 메일은 몇 개 안 될 겁니다. 누락된 부분도 혹시 메일로 보관 중이시거나 찾을 수 있으신 분은 알려 주세요.

- 가공해서 보기 좋은 모양으로 웹에 올려 놓는 것도 과제입니다. 아이디어 있으면 주세요.


2013년 12월 21일 업데이트: 아카이브 완성. 지난 토론 내용, 또는 지난 플레임을 보고 싶으시면:

https://googledrive.com/host/0BzxIVzS0OjQTSEpScE5lcmRhajA/threads.html

libhwp woes

libhwp 개발자께서 github 계정을 삭제하셨습니다. 하필이면 제가 evince-hwp에 데비안 패키징과 관련된 이슈를 문의했을 때, 굉장히 신경질적으로 반응하시면서 프로젝트를 삭제하겠다고 선언하셨는데요.

그 분의 선택을 존중합니다. 그리고 최근에 보기 싫은 일 https://plus.google.com/+ChangwooRyu/posts/h7eq6KqhYMW 때문에 기분이 안 좋은 것도 십분 이해합니다. 하지만 저와 해당 이슈에 대한 반응은 이해할 수 없었습니다. 패키징을 위해 업스트림 저자와 의견을 교환하고 하는 일은 일상적인 일이고, 이슈도 대단치 않은 빌드 변경이었습니다. 이슈 내용이나 이런 피드백 활동 자체가 마음에 안 드신다면 어쩔 수 없지만, 이슈 내용에 대해서 불만을 터뜨리는 것도 아니고 지금까지 프로젝트 관련된 각종 불만이나 개인 사정까지 이슈 페이지에서 폭발하는 건 상식적으로 이해가 가지 않았습니다.

다음에 어떤 일을 하시든 부디 마음을 가볍게 갖고 하셨으면 좋겠습니다.

관련 프로젝트도 현재 접근할 수 없는데 다행히 최근 커밋까지 받았기 때문에 제 clone에 푸시해 놨습니다. 데비안 패키징도 계속됩니다.

https://github.com/changwoo/libhwp
https://github.com/changwoo/evince-hwp

NIPA "유망 공개SW 프로젝트 목록" 중에서

공개SW 가이드/보고서 - [2013] 유망 공개SW 프로젝트 목록(오픈프론티어)

http://www.oss.kr/oss_notice/oss_repository12/103649

• 한국 사람이 운영하는 프로젝트가 이상하게 많다.
• nodejs 관련 프로젝트도 전체에서 비중이 높다
• "3년간 커밋 수 증가"라는 기준을 통해 커뮤니티 성장성을 평가하려고 시도한 것 같은데 올바른 평가 기준이 되지 못한다. 대략 20%를 넘어서면 성장성이 높다고 평가하는 것 같은데, 숫자가 편차가 지나치게 큰 데다 이렇게 평가한 성장성과 "뜨는 프로젝트"와는 거리가 멀다. 
• 수없이 많은 프로젝트 중에 186개의 프로젝트를 리스트업하는 게 의미가 있는지 의문이다. "오픈 프론티어" 사업의 평가 기준으로 삼으려는 생각인지 모르겠으나, 제대로 된 오픈소스 개발자라면 스스로 과제를 선정하고 중요성을 어필하고 그걸 제3자가 검토하는 과정을 통해 평가돼야 하지, 현실을 제대로 반영하기 힘든 제한된 리스트를 통해 중요성이 과대 또는 과소 평가돼서는 안 될 것이다. 

 
 

삼성 exFAT 드라이버 유출과 공개 사건에 대해

삼성의 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 라이선스를 안 붙이게 우회하기도 쉽지 않고, 그 과정에서 법적 논란이 있음을 쉽게 인식할 수 있는데 악의적으로 감췄을 것 같지도 않다.

- 삼성의 오픈 소스 정책이 무엇이든, 감출 수 있으면 감추는 게 기본 방침이라고 하더라도, 이번 부분은 감출 수 없고 공개했어야 하는 부분을 감춰 버렸던 것은 명백하다. 오픈소스 관리에 놓친 부분이 생긴 건 사실이다.

사운드그래프 아이몬 리모콘 드라이버의 기억

최근 머지된 리눅스 드라이버 중에 하나가 리모콘 드라이버가 있다. 기존에 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 대신 저가형 대안으로 꽤 쓰이는 걸 보면 내가 조금은 기여하지 않았나 싶다. 사운드그래프가 좀 더 협조적이었으면 더 좋은 기억으로 남았을텐데.

virtualbox와 키보드보안

virtualbox에서 돌아가는 윈도우에서 뱅킹 플러그인을 깔면서 virtualbox가 죽는 현상은 많이 보았을 겁니다. 하지만 키보드 보안 제작한 개발자가 일부러 가상머신을 사용하면 무용지물이니 엿먹이려고 죽이는 건 아닙니다. 모든 일에 사람의 의도가 있다면 참 얼마나 설명하기 편하겠냐마는.

PC의 PS/2 키보드의 하드웨어는 수십년전 PC 초창기의 8042 칩셋이 하는 일과 별로 다르지 않습니다. 단지 지금은 메인보드 칩셋에 원칩으로 올라가 있지요. 키보드 보안 플러그인은 암호화라는 이유로 키 시퀀스에 쓰레기 정보를 넣게 되는데 그 과정에서 이 칩셋의 주소를 직접 접근합니다. (USB 키보드가 많이 퍼진 지금에 이게 무슨 의미가 있는지 싶지만.) 문제는 이 키보드 보안 플러그인은 오늘날의 주요 OS가 전혀 사용하지 않는 하드웨어 주소에 접근한다는 것이지요. 그러므로 가상 머신에서 생각하지 못한 코너 케이스가 발생합니다. 정확히 잡으려면 제대로 디버깅을 해 봐야 겠지만 virtualbox 소스에서 src/VBox/Devices/Input/DevPS2.cpp

vmware는 뭔가 이런 주소에 접근하는 것 마저 하드웨어와 똑같이 동작하도록, 최소한 문제는 없도록 작성된 모양입니다.

"오픈소스 SW 개발 지원 사업" 개인 지원에 대해

http://www.dt.co.kr/contents.html?article_no=2013032002011160600006
("정부 오픈소스 SW 개발 지원, 기업 중심서 개인으로 확대")

http://www.nipa.kr/biz/noticeView.it?bizId=00039&boardId=noti&boardNo=43&menuNo=18&page=1

기존에 기업이나 대학 연구실만 배불리고 실질적인 성과가 없는 문제를 인식하고 해결하려는 NIPA의 노력은 인정할 만 하지만, 여전히 개인이 지원하기는 무리가 있다.

일단 절대적으로 액수가 작다. 개인이 5천만원이라고 써 있지만 세부 항목을 들여다 보면 인건비가 월 150만원으로 제한되어 있다. 또 개인이 지원하려면 다른 직업이 없거나 직업이 있으면 대표이사 승인이 필요하다. 1년 예산이라면 5천만원 중에 나머지를 다른  비용 따위로 소모해야 하는데 개인이 하는 프로젝트에서 인건비만큼의 액수를 다른 비용에 소모할 일이 있을지 의문이다. 특별히 장비나 비용이 필요한 종류의 프로젝트로 지나치게 제한되거나, 아니면 필요없는 비용을 무분별하게 소모하게 되지 않을까. 이런 과제는 인건비 90%로 예산을 짜도 되는 일이었다.

또한 이 구조로는 대형 프로젝트에 적극적으로 참여하는 사람보다는 개인이 거의 혼자 운영하는 독립 프로젝트만 요건에 부합하게 된다. 과거의 KIPA에서 NIPA로 이어지는 오픈소스 지원 프로그램의 결과를 되짚어보면 과제를 위해 잠깐 만들어졌다가 방치되는 초보적인 sf.net / github 프로젝트만 양산하게 될 가능성이 높다.

해법을 어떻게 찾아야 할까. 사업이 공공 과제의 형식을 가지고 있는 한 문제는 해결하기 힘들어 보인다. 세금으로 조성한 자금의 사용 내역을 철저히 남기는 건 중요한 일이지만, 개개인이 만족시키기 힘든 조건과 절차 때문에 지원이 필요한 전문가보다는 과제 전문가들이 이 자금을 가져가게 된다. 또 공공과제처럼 제안서에 쓴대로 오랜 기간 동안에 하는 일과 참여 인원이 고정되어 있는 방식은 바람직한 오픈소스 운영 방식도 아니다.

이러한 프로젝트를 직접 진행하는 조직을 주도적으로 만들고 그 조직이 개발자를 직접 고용하는 우산 역할을 하는 게 가능한 방법이다. 하지만 이렇게 프로젝트를 직접 진행하게 되면, 책임 소재를 유난히 따지는 공공의 특성상 실패할 때 책임도 직접 지게 되어 실현되기는 어려워 보인다. 또 실현이 되더라도 제대로 필요한 프로젝트를 진행하고 개발자를 채용하고 유지할 수 있을지도 의문이고 말이다.


곁다리지만, 만약 공공이 주도하는 프로젝트의 주제가 마땅치 않다면, 다음 기고글에서 언급된 것처럼 전자정부프레임워크를 비롯한 공공정보화 사업이 공공 주도 프로젝트의 좋은 주제가 될 수 있을 것이다.

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20121127155952("공개SW 살리려면 '커미터' 육성“…어떻게?")

이스트소프트 리눅스용 unegg에 대해

리눅스용 unegg 소스코드가 제작년부터 배포되고 있습니다. ( http://www.altools.co.kr/Product/ALZip_Intro.aspx )

하지만 받아보시면 예상하신 것과 같이, 또는 리눅스용 소스 코드에 어울리지 않게 제약이 붙어 있습니다. 첫째는 비상업적 목적으로만 사용과 배포가 허락된다는 것, 또 하나는 코드의 수정이 금지되어 있다는 점입니다. 특히  "EGG 패키지에 포함된 압축 알고리즘은 수정할 수 없으며 EGG 포맷 및 압축 알고리즘을 개발하는 목적으로는 사용할 수 없습니다." 이렇게 포맷 구현할 수 없다고 강조되어 있습니다. 문서에 보면 리틀 엔디안에서만 동작한다는 언급도 있습니다.

이스트소프트에서 새로 만든 EGG 포맷은 포맷을 공개했다고 알려진 포맷입니다.  ( http://www.altools.co.kr/Product/alzip_egg.aspx ) 하지만 공개된 이 포맷 문서 역시 같은 라이선스로 배포됩니다. 비상업적으로 사용할 수 있고, 포맷을 구현하는데 사용할 수 없는 라이선스인 것이죠. 포맷 구현을 안 할 거면 대체 이 문서를 왜 본다고 생각하는 걸까요?

사실 리눅스에서 alz까지는 잘 지원하는 편이었습니다. 호환 프로그램인 unalz가 거의 모든 배포판에 들어가 있었고, file-roller와 연동하는 기능이 들어가서 (https://bugzilla.gnome.org/show_bug.cgi?id=521324) 그놈 데스크톱에서는 노틸러스(파일)에서 누르면 바로 보이고 풀 수 있었죠. 이스트소프트의 힘을 빌리지 않고 아마추어들의 힘만으로 만든 노력의 산물이었습니다. 하지만 기본적으로 큰 잇점이 없는 새로운 EGG 포맷을 원하지도 않고 압축을 푸는 일에 위와 같은 라이선스 제약이 있는데 배포판이나 데스크톱 통합에 노력을 기울이기는 어렵습니다. 배포판에 들어가기도 힘들겠지요.

리눅스용 unegg, 정말 아쉬울 때만 받아서 컴파일해 사용하시고, 웬만하면 egg가 아닌 자료를 구하시고 egg를 쓰지 말라고 주위에 알리시기를 바랍니다.

열광하는 것과 열광해야 하는 것

아직도 과거의 "모구아" 프로젝트에 대해 말하는 사람이 있습니다. 처음 얘기될 때는 리눅스 데스크톱에 희망을 갖다 줄 수 있었던 것처럼 믿는 사람이 정말 많았습니다. 어쩌면 지금도 일말의 기대를 갖고 있는 분들이 있는지 모릅니다.

저는 모구아 프로젝트가 kldp.net을 떠나기 직전에 mogua 프로젝트의 CVS 덤프를 받았었고 그 파일을 공개합니다. 4clause BSD 라이선스이므로, 배포하는데 문제가 없습니다. 당시에 대단한 기대를 하셨던 분들, 심지어는 지금도 그런 생각을 하시는 분이 있는데 모구아는 전형적인 베이퍼웨어였습니다. 이 덤프 파일을 보고 실상을 깨닫는 기회가 되길 바랍니다.

http://dl.dropbox.com/u/11189107/mogua-cvsroot.tar.gz

이 것이 몇년간 진행했던 코드의 실체입니다. ming-w32에서 가져 온 win32 헤더 파일과 인터페이스 정의가 대부분이고, 추가한 것은 x86 lock, kernel.dll 인터페이스 약간, heap 구현 약간, 유니코드 변환 약간이 전부입니다. 이것이 윈도우 호환 데스크톱 OS의 무지개빛 구상에 충분히 나아간 걸까요?

특정인을 비난하고자 하는 게 아니라 실체가 없는 프로젝트를 응원했던 모습을 돌아보자는 것입니다. 정치든 소프트웨어든 우리는 어느날 갑자기 영웅이 나타나서, 어떻게 하는지는 잘 모르겠지만, 우리의 가려운 점을 멋지게 긁어주고 모든 것을 해결해 주기를 바랍니다. 하지만 그런 일은 있지도 않고 가능하지도 않습니다. 실행 능력이 없는 막연한 이미지와 아이디어는 아무런 가치가 없습니다.

앞으로도 오픈소스 데스크톱 환경을 응원하시려면, 사람들이 듣기 좋은 얘기로 급진적인 이상을 제시하는 프로젝트 보다는, 그들의 생각을 코드로 증명하고 있는 쪽을 응원하기를 바랍니다.

리눅스용 nateon 유감 - 데비안에서 패키지 삭제

Qt3 라이브러리 제거 계획과 더불어 리눅스용 공식 nateon이 데비안 아카이브의 unstable/testing에서 삭제되었다.

이 프로그램 역시 3년이 넘었고 Qt 버전4가 맨 처음 나온 게 2005년이었는데 어디서부터 문제의 가닥을 잡아야 할까. 2007년 9월 KLDP.NET 사이트에 입주한 "nateon" 프로젝트는 특이한 정책을 취했다. "참여하고 싶습니다"라고 말 한마디만 하면 프로젝트에 가입되었다. 한 줄도 커밋하지 않은 개발자, 패키징을 한 번 했다가 사라져서 다시 나타나지 않는 패키지 관리자가 수두룩했다. 치열한 토론을 거친 코드가 아니면 적용도 안 되는 까칠스러운 프로젝트만 접해 본 내게는 생소한 환경이었다.

개발 커뮤니티를 개방적으로 잘 활용하는 것은 좋지만, 눈에 보이는 개발자의 대부분이 뜨내기라는 현실은 파악할 필요가 있다. 그리고 활동적으로 보이는 사람도 누구든, 언제든 떠나갈 수 있다. 믿을 개발자는 결국 자기 자신밖에 없다. (!)

QT4/KDE4 이슈는 이 정책과 관계가 있다. 2007년 11월 프로젝트 관리자는 결정적인 실수를 범한다. QT4/KDE4 포팅에 대해서 커뮤니티 분에게 PM을 맡기자고 한 것이다. 개발자 커뮤니티를 잘 활용하자는 욕심인데 사실 여기까지는 나쁘지 않았다. 언젠가 커뮤니티에게 주도권을 넘겨 주는게 바람직하다. 문제는 그 다음이다.

다시, 오픈소스 프로젝트에서는 "누구든, 언제든 떠나갈 수 있다.믿을 개발자는 결국 자기 자신밖에 없다." 몇 달간 진행이 없을 때 부터 판단을 내렸어야 했다. 의욕만 넘치고 일을 하지 못하는 건 그 사람의 잘못도 아니고 누구의 잘못도 아니다. 그 헛된 의욕을 잘라내지 못하고 기대를 하는 사람의 책임이다. 더 시간이 지났을 때 냉정해 질 필요가 있었다. 이건 개인의 능력이나 성실성 문제가 아니라, 이미 이 프로젝트에 대한 관심이 떠난 상태였다.

Qt4/KDE4 개발

2009년 7월 12일 

포팅은 전혀 시작도 안 한 상태인데, 1년 반이 지난 것으로 볼 때 segfault 님이 이제 와서 하실 생각은 없는 것 같은데요.
특별히 누구를 탓하려는 생각은 없는데요. 오픈소스 프로젝트에서 누군가가 "내가 하겠습니다"라고 자원한다고 해서 그 사람이 그대로 할 거라고 믿고 있으면 곤란합니다.

2009년 11월 1일 

또 다시 몇 달이 흘렀는데요. 이제 2년으로 접어듭니다. 냉정하게 진행될 가능성이 있는지 다시 평가해야 된다고 생각합니다.
하다 못해 svn branch에 진행이 되고 있다는 흔적이라도 있으면 모르겠습니다. 아무 것도 없고 아무 계획도 없는데 어떻게 믿고 기다릴 수 있다는 건지 모르겠습니다. 앞으로 몇 달이 더 흘러도 진행될 것 같지 않습니다.
공개적으로 다른 분을 찾아 보시던가, 아니면 계획 없다고 선언하는 것도 한 가지 방법입니다. :>

그리고 그 전에 2008년 11월 개발 커뮤니티는 한번 흔들린다. 인증 메커니즘이 알려진데 대해 불편해 했던 SK  커뮤니케이션즈 내부에서 이 부분을 바이너리로 빼자는 제안을 한 것이다. (kldp.net 사이트가 nforge로 옮긴 후 메일링 리스트 서비스가 중단되어 이제 접근할 수 없다.)

거기에 대해 2008년 11월 15일 내가 메일링 리스트에 썼던 글,

안녕하세요. 

지금 네이트온의 보안강화와 관련된 메일을 읽었습니다. SK 커뮤니케이션즈 측에서 이런 결정을 한 데 대해 정말 실망스럽고, 가능하다면 재고해 주기를 바랍니다. 

첫째 바이너리로 만드는 것은 프로토콜을 숨길 수 없고 보안 강화에 별 도움이 되지 않습니다. 알아내는 데 좀 오래 걸리고 수고가 더 들긴 하겠지만 패킷 캡쳐이든 리버스엔지니어링이든 언젠가는 알아냅니다. 게다가 눈가리고 아웅 식으로 svn 기록만 들춰봐도 나오는 현재의 패스워드 생성 방식도 바이너리로 감춰보자라는 건 정말 쓸모없는 일입니다. 정말 보안이 걱정되는 거라면 SSL이든 디지털 사인이든 "진짜 보안"을 사용해야 할 일이지, 그 방법 자체를 비밀로 하는 가짜 보안은 오래 가지 못 합니다. 

그리고 더 심각한 부분은... 소스가 비공개가 되면 이 프로젝트의 라이센스 정책이 변한다는 말이 됩니다. 소스가 없는 프로그램은 더 이상 GPL이 아니고 당연히 오픈소스도 아닙니다. 파이프로 읽어들인다면 GPL 호환성 논란까지는 피해갈 수 있을 지 몰라도 독점 프로그램이 없으면 동작하지 않는, 사실상 독점 프로그램이 된 것과 마찬가지입니다. 

어쨌든 만약 말씀하신 대로 서버 프로토콜이 바뀐다면, 그리고 기존 클라이언트에서 더 이상 로그인할 수 없고 독점 프로그램의 바이너리를 사용해야 한다면, 제가 업로드한 deb 패키지는 제 스스로 데비안 아카이브에서 삭제 요청을 하겠습니다. 제 기분대로 그렇게 하려는 게 아니라 소스가 없는 프로그램이나 거기에 의존하는 프로그램은 데비안에 들어갈 수 없습니다. non-free나 contrib에 들어갈 수는 있겠지만 빌드머신에서 빌드를 못하는 제한된 프로그램을 관리할 생각은 없구요. (지금은 13개 아키텍쳐로 빌드되어 있습니다. 아무리 열심히 빌드를 하셔도 s390 바이너리같은 것까지 만드실 수는 없겠지요. http://buildd.debian.org/build.php?arch=&pkg=nateon ) 

그리고 kldp.net에는 오픈소스가 아닌 프로젝트는 입주할 수 없습니다. 만약 이 프로젝트가 비공개 정책으로 간다면 먼저 kldp.net부터 떠나야 하지 않을 까요.

다행히 그 이후 버전은 바이너리를 사용하지 않고 SSL을 사용하도록 바뀌었다.

무엇 때문이라고 해야 할까? 개발 커뮤니티에 대한 지나친 신뢰? 관련자들의 불분명한 입장 표명? SK 커뮤니케이션즈 회사와 개발 커뮤니티 사이의 불투명한 의사 결정 구조? 정말 프로젝트에서 발생할 수 있는 온갖 실수들이 묘하게 엮여서 삐걱거린 프로젝트가 아닐 수 없다.

데비안 패키지 삭제로 이제 신경 쓸 일이 별로 없을 테니, 앞으로 어떻게 진행될지 모르겠지만.. 어떻게 되든 프로젝트에 참여했던 사람들, 프로젝트를 지켜본 사람들 모두가 오픈소스 프로젝트에 대한 (특히 기업이 끼어 있는 프로젝트에 대한) 좋은 교훈을 얻을 수 있었으면 좋겠다.

한국어/조선어, 언어의 명칭

링크: 우분투 Japanese UI에 잘못된 번역이 있네요

좀 뒷북이지만...  일단 일본이나 중국에서 朝鮮語라고 칭하는 건 북조선을 가리키기 때문이 아니라 조선 시대부터 오랫동안 그렇게 불러 왔기 때문일 것이다. 중국이 오늘날도 서울의 도시 이름을 100년 전의 명칭이자 속국의 의미가 들어 있는 한성(漢成, 漢나라의 마을)이라고 칭하는 것처럼 진짜 모욕적인 용어도 있지만, 적어도 조선어는 차별적이거나 모욕적인 의미를 가진 용어는 아니다. 글쎄, 그런데 꼭 나라 이름과 언어 이름을 맞춰야 되나? 외국어에서 어떻게 쓰는 것까지 신경 쓰면서 살아야 되나?

서양 사람들이 부르는 Korea나 Korean이라는 이름 역시 올바른 명칭은 아니다. 심지어 조선 시대에 조정에서는 서양에서 온 공문에 수신자가 Korea라고 써 있다고 반송한 적도 있다고 한다. 고려는 자기들이 멸망시킨 패배자들의 이름이니까. 지금은 남북한 모두 자국어 공식 명칭은 대한민국/조선민주주의인민공화국으로 완전히 다른데도 공식 영문 명칭은 마찬가지로 Korea라고 하고 있으니 아이러니하다. 아예 통일되면 거기에 맞춰 국호를 꼬레아라고 하는 게 무난할 것 같다고 말하는 학자들도 있으니...

사람이 교류하는 단위, 같은 언어가 통용되거나 분화하는 과정이 국가와 관계가 있으니, 국가와 언어는 밀접하게 관계되어 있기는 하다. 하지만 꼭 그렇게 일대일 대응이 되지도 않는다. 페르시아라는 이름을 사용한 제국이 사라진 지가 천 년도 더 지났고 수많은 국가가 생겨나고 없어졌지만 아직도 그 지역의 공식 언어는 페르시아어이다. 쿠데타가 일어나든 분리독립을 하든 나라 이름이 바뀔 때마다 거기에 맞춰 전세계 어학 교과서의 제목을 그 나라 이름에 맞춰 줘야 하는 지는 의문이다.

KMPlayer FFMPEG의 Hall of Shame에 등록

FFMPEG 프로젝트에서는 Hall of Shame이라는 이름으로 GPL/LGPL 위반자 목록을 정리해 놓는데..  GOM플레이어에 이어 KMPlayer도 새로 등록되었다.

FFMPEG에서 문제 삼는 이유는, 전에도 내가 썼던 글 (KMPlayer - 정말 GPL 위반 맞을까?) 중에서 명백하게 위반한 부분, 배포할 때 GPL/LGPL 바이너리 코덱을 소스 없이 배포한 사실 때문이다.

해결하자고 마음 먹는다면 (그리고 다른 의심스러운 부분이 위반이 아니라고 자신할 수 있다면) 이 부분은 사실 너무 쉽게 해결할 수 있다. 해당 소스를 묶어서 같이 배포하면 되는 일이다. 이 소스 코드를 고쳤든 안 고쳤든 GPL/LGPL에 따르면 소스 코드를 배포해야 한다는 사실은 변함이 없다.

(업데이트) 해당 이슈 트래커 항목을 보면 GPL 심볼을 레퍼런스하는 부분도 지적하고 있다. 역시 전에 썼던 이야기 중에서 아마도 위반일 거라고 했던 부분.