삼성 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 커뮤니케이션즈 회사와 개발 커뮤니티 사이의 불투명한 의사 결정 구조? 정말 프로젝트에서 발생할 수 있는 온갖 실수들이 묘하게 엮여서 삐걱거린 프로젝트가 아닐 수 없다.

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