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라고 해서 특정 기관이나 특정 필드에서 쓰도록 설계된 라이선스를 그 외의 분야에서 가져다 쓰는 것도 바람직하지 않고 말이다. 대부분의 사람들이 동의하는 많이 쓰는 라이선스를 쓰는 것이 바람직하다고 할 것이다.

행정용 "한국형 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"가 가진 영어 의미의 중의성이나 "자유"라는 단어가 주는 불편함을 완화시키기 위해 만든 말이다. 하지만 이 말조차 불편해 하면 무엇을 할 수 있을까.

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

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

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

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

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

 
 

"오픈소스 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 살리려면 '커미터' 육성“…어떻게?")

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

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

저는 모구아 프로젝트가 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의 무지개빛 구상에 충분히 나아간 걸까요?

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

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

안드로이드폰 G1의 티보이제이션

구글 그룹스에서 Q&A 중의 구글 관계자의 말에 따르면,

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 (?)

연시를 맞아 수많은 올해 예언 시리즈가 나오는 바, 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 세계에 마치 북한이 존재하지 않는 것처럼 보이는 이유는, 다른 이유도 있지만 미국의 테러지원국 지정때문에 미국 및 미국과 관련 조약을 맺은 (한국을 비롯한) 국가에서 소프트웨어를 수출하는 게 불법이기 때문이기도 했다. 조금씩 들려오는 말들을 보면, 북쪽은 리눅스 관련 개발도 하고 배포판까지 만들어 쓰고 있다. 폐쇄성과 낮은 컴퓨터/인터넷 보급때문에 (그리고 아마도 남쪽보다도 참여의 문화가 부족할 것이므로) 녹록치 않겠지만, 제도적인 장벽이 사라지면 조금씩 업스트림에 북한이 모습을 드러낼 수 있을까?

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

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

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

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

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

배포판 중심 메세지 번역의 폐해 - 커뮤니케이션 부재

과거에도 그랬듯이, 배포판 중심의 메세지 번역은 보통 그 배포판 안에서만 사용되고 그 안에서 수명을 다한다.

우분투의 런치패드/로제타는 온라인 메세지 번역 시스템으로 기술적으로는 내가 생각했던 이상적인 모습이지만, 배포판 중심의 번역 운영은 (한국이든 세계 어디든) 커뮤니케이션의 문제를 가질 수밖에 없다. 예전에 런치패드/로제타에 의해 한국어 번역이 시작되었을 때 내가 우려했던 것처럼 업스트림과 따로 노는 현상이 벌어지곤 한다.

간단히 예를 들어 우분투 feisty의 한국어 번역 중에서 KDE 관련 프로그램은 로제타에서 많은 부분이 번역되어 있다.  많은 부분이 비슷한 모습을 보이지만, 꽤 많이 번역된 일부분을 보면,

그럼 KDE upstream의 한국어 통계를 들어가서 이 부분이 업스트림에 어떻게 되어 있는 지 확인해 보자.  위에 나온 kdebase를 비교해 보면 다음과 같다.  거의 반영이 되어 있지 않다.

그럼 보너스로 또 한 가지 비교해 보자.  한소프트리눅스는 어떨까?  한소프트리눅스 오픈 프로젝트에서 kde-i18n 패키지의 src.rpm 파일을 받아서 확인해 보았다.

zeus:~/tmp/kdebase/kde-i18n-ko-3.5.6/messages/kdebase$ for X in kcm*po; do msgfmt --stat $X -o /dev/null; done
번역된 메시지 70개.
번역된 메시지 47개.
번역된 메시지 68개.
번역된 메시지 121개.
번역된 메시지 21개.
번역된 메시지 8개.
번역된 메시지 67개.
번역된 메시지 34개.
번역된 메시지 180개.
...

어라?  -_-  완벽한데 대체 무슨 일이 벌어진 것일까?  과연 누가 이걸 번역했는지 알아보기 위해 PO 파일의 Last-Translator: 엔트리를 찾아보았다.

zeus:~/tmp/kdebase/kde-i18n-ko-3.5.6/messages/kdebase$ grep Last-Translator: kcm*po
kcmaccess.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmaccessibility.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmarts.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmbackground.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmbell.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcgi.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcolors.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcomponentchooser.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcrypto.po:"Last-Translator: root <root@localhost.localdomain>\n"
...

다름 아닌 한소프트리눅스 측에서 자체 번역한 결과물이다.  (위의 결과로 알 수 있는 사실, 번역자는 루트 계정으로 KBabel을 이용해 번역한다.)  이것이 한소프트리눅스 광고에 등장하곤 하는 "전문 번역팀을 통해 자연스럽지 못했던 한글 번역부분을 말끔히 개선하였습니다"의 실체인가?

"위와 같은 꼴"을 보고 절대 잘 한다는 소리는 절대 못하겠지만, 어제 오늘의 일이 아니고 이제는 적어도 이해는 할 수 있다.  FOSDEM 2007의 비디오 중에서 리눅스 커널에 관한 세션을 보면 이런 얘기가 있다 -- "임베디드 분야의 리눅스 커널의 발전이 더딘 이유는 피드백이 없기 때문인데, 칩 메이커를 제외하고 완제품을 만드는 제조업체들은 제품의 개발기간도 짧은 데다가 스펙이 한정되어 있고 소프트웨어 업데이트도 거의 없기 때문에 피드백의 현실적인 필요가 적다".  배포판 업체들도 마찬가지이다.  번역에 관한한 충분한 맨파워를 동원할 수 있다면 (우분투와 한소프트리눅스는 그 방법을 다르게 취한 것 같지만) 업스트림 피드백으로 얻을 건 별로 많지 않다.  런치패드/로제타의 자발적인 참여자들도 자기들의 번역 결과물이 자기가 사용하는 OS에 반영되는 것만으로도 상당히 만족하고, 또 다른 업스트림에 반영하는 건 런치패드/로제타보다 진입장벽이 높기 때문에 부담스러워하는 것도 같다.

이 상황을 어떻게 해결해야 하나.  업스트림에 번역을 반영하는 장벽을 낮추는 게 한 가지 방법이지만, 어떻게 쉽게 컨트롤할 수 없는 부분이다. 적어도 내가 상당부분을 컨트롤하고 있는 그놈 / 데비안 번역은 가능할 것도 같은데, 앞으로 생각할 부분이다..

메세지 번역에서 흔히 발생하는 문제와 해결

보안용 장비를 만들 시절에, 회사에서 번역 업체를 많이 이용했었다.  이 번역업체는 세계 곳곳의 각 언어권마다 지사를 두고 있는데 각 지사마다 네티이브 번역자가 있는 동시에 그 지역의 번역 의뢰자를 상대로 영업을 한다.  번역 의뢰가 들어오면 원문을 각 세계 지사에 보내서 네이티브들이 번역을 하게 만든 다음 번역한 결과물을 모아서 의뢰자에게 돌려준다. 이런 식으로 동작하는 번역 전문 회사가 꽤 많이 있고, 이 방식으로 꽤 괜찮은 품질의 번역을 빠르게 만들어 낼 수 있다. 보통 제품을 릴리스할 때마다 백여개 내외의 메세지가 독일어, 프랑스어, 이탈리아어, 스페인어, 일본어로 5개국 번역이 되었는데 (정확하진 않지만) 60-70여만원정도가 필요했다.  (그러면 GNOME 2.18의 한국어 메세지는 35000여개가 되므로 이 계산법에 따르면 수억의 가치가 있다고 할 수 있다. ^^)

그 번역 업체는 IT 전문 번역을 표방했고 상당히 많은 경험이 있는 것으로 보였다.  하지만, 번역이라는 건 그렇게 뚝딱 할 수 있는 게 아니다. 번역이라는 작업은 한계가 있다.

1. 번역자가 CCTV 시스템에 대한 지식이 부족했다.  예를 들어 전통적인 보안 시스템에서 NC/NO는 Normally Close, Normally Open으로 보안용 센서의 종류를 나타내는 말로 "붙은" 상태가 정상인가 "떨어진" 상태가 정상인가를 나타내는 말이다.  (예를 들어 출입문에 부착하는 접점 센서는 닫혔을 때 즉 붙은 상태가 정상이고 문을 열면 떨어지면서 센서가 activate된다.) 하지만 많은 번역자가 NC를 (유행이 한참 지난 용어인) Network Computer라고 번역하기 십상이었고 NO를 Number의 약자로 번역하기 십상이었다.

2. 꽤 오랜 기간동안 제품을 업데이트하다 보니 번역을 하면서 일관성이 맞지 않는 부분이 많이 발생했다.  의뢰인인 우리쪽 입장에서는 사실 누가 번역했는지는 알 수도 없고 신경도 안 쓰는데, 같은 용어를 여기저기서 다르게 사용한다든지 말투가 달라진다든지 하는 일이 그 언어를 전혀 모르는데도 뻔히 알 수 있을 정도로 자주 발생했다.

3. 번역 업체와는 상관없지만 번역한 결과를 적용할 때마다 언제나 화면 크기의 부족에 시달렸다.  작은 NTSC/PAL TV 화면의 크기에 맞춰야 하는 입장에서는 난감하기 짝이 없었다.  화면상의 각종 컨트롤의 크기를 dynamic하게 만들고 복잡한 클리핑과 스크롤 기능으로 보완해 보려고 했지만 결국 한계가 있었고, 특히 이탈리아어와 스페인어의 경우 점(.)으로 단어를 줄여쓴 (Abracatabra라면 Abra. 식으로) 신조어 레이블이 화면의 많은 부분을 차지하게 되었다.

옛날 얘기는 여기까지 하고 현재로 돌아와서, 위의 현상은 오픈소스 소프트웨어의 메세지 번역에도 똑같이 적용된다.  얼마전에 그놈 2.18이 릴리스되었지만, 여전히 (1) 메세지의 일부는 해당 프로그램의 기능에 대해 잘 이해하지 못한 부분때문에 오역이 있고, (2) 업데이트하면서 가끔 말투와 용어를 다르게 쓰기도 하며, (3) UI의 문제때문에 번역해 놓은 모양이 아주 보기 나쁜 경우가 많이 있다.  이와 같은 실수는 번역자의 실력과 경험에 따라 달라지겠지만 여전히 발생한다.

이와 같은 문제를 100% 없애기는 쉽지 않다.  실제로 마이크로소프트가 공개한 마이크로소프트가 릴리스하는 번역문도 하나하나 살펴보면 어색한 번역문도 있고 오역이라고 생각되는 번역문도 꽤 있으며 시간이 지나면서 다른 용어를 사용하는 부분도 꽤 보인다. 하지만 그 번역문 중에서도 자주 사용하는 마이크로소프트의 대부분의 번역문은 아주 매끄러운데, 이는 다름 아니라 엄청난 사용성 테스트의 결과물이다.  역시 피드백을 많이 받아서 계속해서 다듬어 나가면 잘 번역했다는 소리를 들을 수 있다는 얘기이다. 하지만 역시 보안 장비를 만들 때나 그놈 메세지를 번역할 때나 자기 스스로 깨닫고 고치는 것 외에 외부에서 피드백을 받기는 쉽지 않은 일이다. 그놈 메세지는 특히, 심심풀이 작업때문에 일부러 프로그램 테스트를 심각하게 할 수는 없는 노릇이다.

그래서 앞으로 그놈 및 내가 참여하는 번역은 번역자들의 (특히 류모씨의) 부담을 줄이면서도 좀 더 많은 참여와 피드백을 받고 번역을 다듬을 수 있는 방법을 찾아 보려고 한다. 어떤 게 될 지는 나도 아직 잘 모르겠으므로 다음 시간에...

FOSDEM의 자바 프리젠테이션 중 몇 마디

FOSDEM 비디오 중에서 썬의 "Liberating Java" 프리젠테이션을 보다가 맨 앞에 소프트웨어 특허에 관해서 이야기하다가 나온 이야기:

특허를 출원하는 이유는, 미국 사람들이 총을 구입하는 이유와 비슷합니다.  미국 사람들이 총을 구입하는 이유는, 미국 사람들이 총을 구입하기 때문입니다.  미국 소프트웨어 회사들이 특허를 출원하는 이유도, 미국 소프트웨어 회사들이 특허를 출원하기 때문입니다.

공감 100%.  지금까지 경험한 회사가 비교적 작은 회사였기 때문이었을까?  지금까지 회사에서 특허에 관한 교육이나 특허에 관한 이야기가 나올 때마다 항상 처음에 소개하면서 듣는 이야기는, "특허가 없으면 특허 분쟁이 발생했을 때 X된다"였다.

(이 비디오에는 그 외에도 자바 이슈에 관심있는 사람이라면 재미있는 내용이 많다)

어색한 메세지 번역을 피하는 팁 몇가지

문장 부호를 똑같이 붙이려고 하지 말아라.
- 우리말에서는 문장에 세미콜론을 쓰지 않는다.
- 원문에 쉼표가 있다고 번역문에 쉼표를 넣을 필요는 없다.  우리말로는 쉼표를 쓰지 않아도 문장이 명확한 경우가 많다.
- 영어에서는 흔히 문장 끝에 괄호를 열고 괄호를 닫은 다음 마침표를 찍는다.  하지만 우리말에서는 그렇게 쓰지 않는다.

영어 문장의 처음에 쓰인 대소문자를 그대로 따라할 필요는 없다.
- 영어에서는 첫 단어가 소문자로 쓰는 단어일 경우에도 (프로그램 이름 따위) 대문자로 만들어서 쓴다.  그대로 쓰지 않도록 신경 쓴다.

관계사가 줄줄이 붙은 문장을 한문장으로 번역하려고 순서를 여기저기 뒤집지 않는다.
- 어느정도 같은 말을 반복하더라도 여러 문장으로 쓰는 편이 낫다.  한 문장으로 쓰려고 하다가는 오히려 말 순서가 바뀌어서 핵심단어가 뒤에 가는 등 의미가 불명확해질 수가 있다.

Debian/Ubuntu 사용자는 popular-contest를 써 주세요

프로그래밍을 모르는, 혹은 프로그래밍하기 귀찮은 (...) 사용자가 프리소프트웨어 프로젝트에 기여할 만한 일은 여러가지가 있습니다..  하지만 그 여러가지도 (버그리포트, 번역, 문서, 커뮤니티, ...) 생소한 대부분의 사람들에게는 귀찮기 짝이 없죠.  그래서 이 글을 끝까지 다 보기 전에 끝낼 수 있는, 별로 귀찮지 않은 한 가지 간단한 방법을 떠올렸습니다.  개인정보를 팔 통계 작업에 참여해 주시면 상당한 도움이 됩니다.

데비안/우분투 사용자라면 popularity-contest를 설치하시고, 혹시 이미 설치되어 있다면dpkg-reconfigure 명령으로 이 기능을 사용하도록 설정하십시오.  개인정보를 파는 건 농담이고, popular-contest가 보내는 하드웨어 정보는 무슨 아키텍쳐를 사용하느냐 정도뿐이고 (사실 lspci -v 결과같은 것 좀 수집해 봤으면 좋겠는데), 시스템에 무슨 꾸러미(패키지)가 깔려 있나의 정보만 보냅니다. 

명시적으로 설정해야만 정보를 보내기 때문에 (당연히 사용자의 명백한 동의가 있어야 되겠죠) 전체 사용자 규모에 비하면 현재 2만명 정도의 통계는 별로 충분한 숫자가 아닙니다.  위에 스크린샷에 쓰여있는 것처럼 CD 만들 때 우선순위를 결정하는 용도에도 쓰이고, 부족한 점을 개선하는 데에도 중요한 자료가 됩니다.  예를 들어 http://popcon.debian.org/unknown/by_vote 여기를 보면 데비안에 없는 아마도 non-free인 꾸러미를 뭘 깔았냐를 볼 수 있고 데비안에 무엇을 개선해야 하는지 참고 자료가 됩니다.  (멀티미디어 툴들, JDK, skype, opera, ...)

데비안의 경우에는 http://popcon.debian.org, 우분투의 경우에는 http://popcon.ubuntu.com 사이트에서 정보를 볼 수 있습니다.

BSD 사용자라면 BSDstats 프로젝트에 참여할 수 있습니다.  (http://openlook.org/blog/1116)

리눅스에 여성 참여를 장려하는 하우투

오늘 컨퍼런스에서 민망한 사진이 프리젠테이션에 노출된 사고에 대한 블로그 글을 읽으면서 HOWTO Encourage Women in Linux 문서도 끝까지 읽게 되었는데..  여러가지 생각해 볼 기회가 많았다.  하우투 강력 추천!

이 중에서 특히 리눅스를 기피하는 이유를 인용하면:

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.

(대충 의역) 리눅스 개발은 프로그래밍의 다른 분야보다도 더 충돌이 심하고 험합니다. 어떤 경우 코드를 작성해서 얻는 보상이라곤 어떤 지위를 갖거나 상대방로부터 허락받는 것일 뿐일 수도 있습니다.  심지어는 그 "보상"이라는 게 비난에 가까운 플레임일 수도 있고 더 나쁜 경우는 아예 아무런 반응이 없을 수도 있습니다. 여성들은 사회화되면서 다른 사람과 충돌을 피하고 조화롭게 지내도록 훈련받습니다.  또 그런 충돌을 시작할 만한 자신감이 부족합니다.  그래서 리눅스와  일반적인 오픈소스 분야는 다른 분야의 컴퓨팅보다도 훨씬 더 여성의 참여가 어렵고 참여를 계속하기도 어렵습니다.

간단하게는 IRC에서 여성에게 남자친구에 대해 질문을 한다던지, 생각없이 내뱉는 말이나 여러가지 가정들이 여성에게는 그 커뮤니티를 기피하는 원인이 된다. 

지난 12월 3일에 있었던 오픈소스 뛰어들기 행사에서는 특이하게도 참석자에 대해 여성 쿼터제가 있었지만, 결과적으로 15명이었던 쿼터 수를 줄이고 했지만 실제 참석 인원은 그에 미치지 못했다.  혹시 기피 요인들이 있었을까?  (물론 의도한 건 아니지만)  여성 강사가 없다든지, 주제나 형식이 부담스러웠을 수도 있고, 새로운 사람이 들어가기 어려웠었을 수도 있었을 것이다.

WoC 2006: 기대와 걱정

몇년간 "공개소프트웨어 진흥정책"의 교육분야에 집행된 예산은 제도적인 문제때문에, 대학의 연구비 정도로 소비될 수밖에 없었다.  이른바 눈 먼 돈이라서 기간과 금액에 비해서 터무니없이 쉬운 주제라던지, 오픈소스와 관계없는 주제에 연구비를 집행한 경우가 많았다. 그리고 실제 프로젝트 진행이 "오픈소스럽지 않게" 공개/피드백/지속적인 관리가 되지 않았고 보고서와 함께 종료되었다.  사업의 목적이 인력 양성이긴 하지만 지금까지와 같은 방식으로는 그 목적을 달성하기 어렵다고 보인다.  그저 대학 연구실을 조금 풍족하게 하는 정도의 효과밖에 없었다.

이번에 열릴 Winter of Code는 기대를 갖게 한다.  적어도 개인에게 보상이 지급되고 좀 더 제대로 된 심사를 거칠 수 있을 것 같다.  (역으로 별로 많은 보상금이 아니기 때문에 엉터리 주제가 더 적을지도?)   하지만 괜히 높은 눈높이와 기대때문에 WoC 2006에 대해 걱정스러운 의견을 말해 보자면...

첫쨰로 프로젝트의 범위가 너무 제한되고 편향될 수가 있다.

학생이 프로젝트를 제안할 수 있다지만..  일단 기업은 기업이 필요해서 제안한 프로젝트를 우선 선정할 수밖에 없을 것이다.  커뮤니티의 경우에도 학생이 제안한 프로젝트를 수용할 만한 오픈소스 개발 커뮤니티가 마땅히 없고, 제안받은 프로젝트에 대해 멘토를 선정하고 검토하기에도 사람이 별로 없을 것 같고, 있다고 해도 준비시간이 많이 부족하다.  (게다가 SoC와는 달리 단체에 대한 지원이 없다.  SoC도 500 USD밖에 안 되긴 하지만..)  결국 학생이 제안한 프로젝트보다는 기업이 필요로 하는 프로젝트를 학생이 수행하는 방향으로 흘러가지 않을까?  실제 수행되는 프로젝트는 현재 제안되어 있는 프로젝트에서 크게 벗어나지 않을 것으로 보인다.

게다가 현재까지 올라온 프로젝트들은 웹 서비스 관련 소프트웨어에 너무 편향되어 있다 (게다가 평범한 학생들의 실력으로는 기간내에 끝내기 어려운 난이도로 보인다.  심지어 WoC 소개 문구에도 "만들어낸 결과물은 실제 서비스에 적용되는 기회를 얻게 되며..."라고 쓰여 있다.  사실 웹은 중립적이라서..  프로젝트를 오픈소스 세계(?)에서 해 보려는 생각이 없는 학생도 얼마든지 상금을 타기 위해 참가할 수 있는 것 아닐까.

둘째로 취지에 맞게 참가 학생이 오픈소스에 참가할 수 있는 기회가 될 지 걱정이다.

학생이 2개월이 좀 넘는 기간에 익힐 수 있는 기술적인 내용은 어차피 한정되어 있다.  SoC가 학생들에게 주는 가장 큰 영향은 프로젝트를 하는 과정에 있다고 생각하고 기술적인 것보다 훨씬 큰 부분이다.  그냥 프로젝트를 제안하고 멘토와 메일만 교환하면서 마감에 맞춰 끝내기만 하는 게 아니라, 기존에 진행중인 프로젝트에 참여해서 계속해서 공개적인 커뮤니케이션을 하고 중간에 결과를 내놓아서 피드백을 받고 하는 과정이 더 중요하다.  그리고 그 과정 자체가 상당히 재미있기 때문에 의욕을 불러일으킨다!  (SoC에서도 참가자가 그런 과정을 무시해서 안 좋은 평가를 받는 경우가 있었지만..) 

하지만 애초에 국내에서 그런 커뮤니케이션의 재미를 느낄 만큼 활발하고 규모있는 개발 커뮤니티가 전무하기 때문에 (물론 행사 기획의 문제가 아니라 현실의 문제라서 딱히 해결책도 없지만) 그 분위기를 느낄 기회가 없을 걸로 보인다.  게다가 앞에서 얘기한 것처럼 기업이 제안한 프로젝트 중심으로 흘러갈 것 같아서 더욱 오픈소스같지 않게 진행될 것만 같다.   멘토의 진행 방식에 따라 얼마든지 달라질 수 있는 부분이긴 하지만 걱정스럽다.


첫 술에 배부를 순 없겠지만, 이 행사에 기대하는 사람이 많은 만큼 더 바람직한 방향으로 진행되었으면 좋겠다.  어떤 사람들은 미숙한 학생들보단 지식을 갖춘 개발자에게 실질적 성과를 달성하도록 하는 게 낫지 않느냐고도 하지만, 나는 미숙하고 성과가 없더라도 학생들을 대상으로 하는 일이 중요하다고 생각한다.   동서를 막론하고 오픈소스 개발자가 탄생하기에 좋은 사람, 환경, 시간적 여유를 갖춘 곳이 바로 대학이지만, 국내 대학들은 담당 교육자들이 경험했던 환경이 그래서인지 취업위주의 교육이라서 그런지 PC 환경 위주로 편향되어 있다.  (그렇지 않다고 생각했던 모교에서도 그 멋진 엑스터미널들이 사라지지고 윈도우 PC가 차지했다는 이야기를 들어서 몹시 서운. )  정책적인 이유든 오픈소스의 실질적인 수요가 있는 경우든 학교에 피드백을 줘서 지속적으로 개발자가 나오게 만들 필요는 있다.