랜덤여신의 폐인모드

다음 문서는 리눅스 커널 개발자로 활동하고 있는 그렉 크로아-하트만(Greg Kroah-Hartman)이 2006년에 OLS(오타와 리눅스 심포지엄)에서 연설한 OLS 2006 키노트를 번역한 것입니다.

내용이 길어서 두 부분으로 나누었습니다. 현재 글은 2번째입니다.

---

사람들이 저에게 묻는 두 번째 질문은 소스 코드를 커널에 넣어야 할 때, '음, 우리 코드는 비공개로 유지하고 싶은데요. 상용이거든요.'라고 말하는 것입니다.

그럼, 여기에 이 문제에 대해 간단한 답변이 있습니다.


바로 그것입니다. 아주 간단하죠. 저는 이 주제에 대해 수 년 동안 수많은 지적재산권 변호사와 대화를 나누는 불행을 겪었습니다. 그리고 저와 대화한 변호사는 누구나, 오늘날 소스 코드를 공개하지 않고 리눅스 커널 모듈을 만드는 방법은 없다는 데 동의했습니다. 그것은 파생 작업(derivative works)과 링킹(linking) 등등 재미난 것들 때문에 GPL을 위반합니다. 다시 말하는데, 아주 간단합니다.

어떤 변호사도 공개된 장소에서 이 이야기를 하지는 않을 것입니다. 변호사가 이와 같은 진술을 공개적으로 하는 것은 금지되어 있기 때문이죠. 그러나 여러분이 변호사를 고용하고 의뢰인-변호사 상황에서 말한다면, 이 문제에 대해 조언을 얻을 수 있을 것입니다.

저는 변호사가 아니고, 될 생각도 없으므로, 제발 이 문제에 대해 다른 것을 묻지는 마세요. 라이선스 문제에 대해 법적 질문이 있다면, 변호사에게 말하세요. 절대로 linux-kernel 같은 공개된 메일링 리스트로 가져오지 마세요. 프로그래머만 있단 말입니다. 공개된 장소에서 프로그래머에게 법적 판단을 구하는 것은, 우리에게 의사 진찰을 요구하는 것과 마찬가지입니다. 전혀 말이 되지 않아요.

그러나 만약 어느 날 갑자기 리눅스 커널 개발자들이 클로즈드 소스 모듈을 커널에 포함시킨다는 결정을 내리면 어떤 일이 벌어질까요? 시간이 흐르면서 커널의 동작 방식과 진화 방식에 어떠한 영향을 줄까요?

아잔 반 드 벤(Arjan van de Ven)은 이것이 현실이 되었을 때 어떤 일이 벌어질지를 정확히 말해주는 훌륭한 사고 실험을 했습니다:


linux-kernel 아카이브에서 쉽게 찾을 수 있는 그의 글은 이렇게 설명합니다. 노벨과 레드햇 같은 대형 배포판만 쏟아져 나오는 모든 새로운 하드웨어를 지원할 수 있을 것입니다. 그러나 천천히 침체할 것입니다. 다른 클로즈드 소스 드라이버를 망가뜨릴 수 있는 그 어떤 것도 고칠 수 없기 때문입니다. 따라서 여러분이 둘 이상의 클로즈드 소스 모듈을 로드한다면, 여러분의 시스템을 지원하는 것은 거의 불가능할 것입니다. 심지어 오늘날에도, 여러분이 둘 이상의 클로즈드 소스 모듈을 시스템에 로드하려고 시도하면 이 현상을 쉽게 볼 수 있습니다. 무언가 잘못되어도, 여러분의 문제를 지원하고 싶어하는 회사는 없을 것입니다.

이 글은 계속하여, 젠투와 데비안 같은 커뮤니티 기반 배포판은 천천히 고립되고, 어떠한 새로운 하드웨어 플랫폼에서도 동작하지 않게 되며, 어떤 사용자도 더 이상 사용할 수 없게 되면서 말라 죽게 된다는 것을 보여줍니다. 그리고 마침내, 단지 수 년이 지난 후, 모든 커널 프로젝트 자체가 정지 상태에 빠지고, 어떠한 것도 혁신하거나 바꿀 수 없을 것입니다.

이것은 정말 으스스한 이야기이지만, 훌륭합니다. 이 주제에 대해 흥미가 있으신 분은 한번 봐보세요.

그러나 모든 클로즈드 소스 모듈 문제에는 또 하나의 관점이 있습니다. 제가 정말로 말하고 싶은 것이고, 대부분의 사람이 무시하는 것입니다. 다음과 같습니다:


기억하세요. 누구도 어떤 사람에게 리눅스를 사용하라고 강요하지 않습니다. 만일 여러분이 리눅스 커널 모듈을 만들고 싶지 않다면, 할 필요가 없습니다. 그러나 만일 여러분의 고객이 그것을 요구한다면, 그리고 여러분이 하기로 결정했다면, 커널의 규칙에 따라 경기를 해야 합니다. 간단합니다.

그리고 커널의 규칙은 GPL입니다. 그것은 간단한 라이선스이며, 표준적인 저작권 소유 문제에 대한 것입니다. 그리고 많은 변호사는 GPL을 이해합니다.

어떤 회사가 '자사의 지적 재산을 보호해야 한다'고 말할 때, 그것은 좋습니다. 저와 다른 모든 커널 개발자는 그것에 반대하지 않습니다. 그러나 같은 이유로, 여러분도 커널 개발자의 지적 저작권을 존중해야 합니다. 우리는 우리의 코드를 GPL로 공개했습니다. GPL은 이 코드를 사용할 때 여러분의 권리가 정확히 어떻게 되는지, 분명한 형태로 나타냅니다. 여러분이 다른 코드를 우리 코드의 몸통에 링크하는 경우, (배포할 때) 여러분의 코드 또한 같은 라이선스로 공개할 의무가 있습니다.

여러분이 리눅스 커널 코드를 받고, 그 헤더 파일을 여러분의 코드와 링크하거나 빌드할 때, 우리 코드의 명문화된 라이선스에 따르지 않는다면, 여러분은 어떠한 이유에서 여러분의 코드가 커널의 나머지 전부보다 훨씬 더 중요하다고 말하고 있는 것입니다. 짧게 말하면, 여러분은 지금까지 코드를 공개한 모든 커널 개발자를 모욕하고 있는 것입니다.

따라서 기억하세요. 각각의 기업이 커널보다 더 중요하지는 않습니다. 커널 개발 커뮤니티가 없었다면, 기업이 사용하는 커널 자체가 존재하지 않았을 것입니다. 앤드류 모튼(Andrew Morton)은 2년 전에 이 자리에 서서 클로즈드 소스 모듈을 제작하는 회사들을 '거머리'라고 불렀습니다. 완전히 동의합니다. 그들의 행동은 완전히 비윤리적입니다. 몇몇 회사는 그들의 클로즈드 소스 코드를 재배포하는 방법을 규정하는 법적 라이선스를 회피하려고, 일반 사용자(end user)에게 빌드와 링크를 강요합니다. 만일 일반 사용자가 자신이 빌드한 모듈을 다른 사람에게 줄 경우, GPL을 위반하게 될 텐데도 말입니다. 이러한 기업은 명백하게 비윤리적이고 나쁩니다.

다행히도 사람들은 이것을 깨닫기 시작하고 있고, 대형 배포판은 더 이상 이러한 일을 허용하지 않습니다. 다음은 노벨이 올해 초에 내놓은 공식 성명입니다.


이것은 수세(SuSE) 10.1, 그리고 SLES와 SLED 10이 어떠한 클로즈드 소스 커널 모듈도 포함하지 않을 것이라는 뜻입니다. 아주 좋은 일입니다.

레드햇 또한 그들의 커널 패키지에 이와 비슷한 텍스트를 포함하고 있습니다. 하지만 아직 공식 성명을 내놓지는 않았습니다.

네, 울적한 이야기는 여기까지. 기업이 자사의 코드를 커널 트리에 넣을 필요를 깨달은 후, 곧바로 한 가지 큰 문제에 부딪칩니다.


이것은 첫인상만큼 힘든 문제는 아닙니다. 기억하세요. 커널의 변경 비율은 커널이 발표될 때마다 패치 6000개 정도입니다. 따라서 누군가는 트리에 자신의 코드를 넣고 있는 것이지요.

그럼, 어떻게 하느냐입니다. 다행히도, 커널 개발자들은 커널 개발을 어떻게 해야 하는지를 알기 위해 필요한 모든 것을 써두고 있습니다. 모두 파일 하나에 있습니다:


커널 개발을 어떻게 해야 하는지 궁금해하는 사람이 있으면 꼭 이 파일을 가르쳐주세요. 지금까지 누군가 질문한 모든 것에 답해줍니다. 그리고 답변을 찾을 수 있는 다른 장소를 가르쳐줍니다.

이 문서는 커널이 어떻게 개발되는지, 패치는 어떻게 만드는지, 커널 트리 주변에서 어떻게 길을 찾는지, 누구에게 패치를 보내야 하는지, 다양한 커널 트리는 무엇에 대한 것인지에 대해 다룹니다. 그리고 심지어 다른 사람들이 여러분의 코드를 진지하게 받아들이게 하고 싶을 때 linux-kernel 메일링 리스트에서 말해서는 안 되는 것까지 나열합니다.

이것은 위대한 파일입니다. 그리고 만일 이 문서가 어떤 부분에서 여러분을 도와주지 않는다면, 파일 저자에게 알려주세요. 추가될 것입니다. 자신의 코드를 커널 트리에 넣는 방법에 대해 더 알고 싶어하는 관리자나 개발자가 있으면, 꼭 권해주어야 할 것입니다.

HOWTO 파일이 설명하는 것 중 하나는, 커널 개발에 대해 도움을 줄 수 있는 다양한 커뮤니티입니다. 만일 여러분이 커널 개발을 처음 한다면, 이런 프로젝트가 있습니다:


이것은 나쁜 기분을 느끼지 않고도 기본적인 질문을 할 수 있는 아주 좋은 위키, 아주 좋고 온순한 메일링 리스트입니다. 실시간으로 수많은 커널 개발자에게 질문할 수 있는 IRC 채널도 있습니다. 이제 막 시작했다면, 꼭 이곳에 가보세요. 배우기 아주 좋은 곳입니다.

만일 여러분이 커널 개발을 정말로 시작하고 싶은데, 무엇을 해야 할지 모르겠다면,


이 프로젝트가 시작하기 좋은 장소입니다. 커널 개발자가 코드 베이스에 대해 행하면 좋겠다고 생각한 여러 가지 '잡무'의 긴 목록이 있습니다. 여러분은 그 중 하나를 골라서, 패치를 만드는 방법과, 적절한 패치를 보내기 위해 여러분의 이메일 클라이어트를 설정하는 방법을 익힙니다. 그러면 커널 변경 사항(changelog)에 여러분의 이름이 실리게 됩니다.

저는 커널 개발을 시작하고 싶지만, 아직 할 만한 작업을 찾지 못한 분에게 이 프로젝트를 강력 추천합니다. 커널 트리를 찾아다니고, 이상한 것들을 고치고, 그러면서 여러분은 보통 여러분의 관심을 끌지만 다른 사람이 하고 있지 않은 무언가를 찾게 됩니다. 그리고 여러분은 커널의 일부를 천천히 차지하기 시작할 수 있습니다. 이 이상 추천할 수 없을 정도입니다.

그리고, 모든 사람이 살고 있는 거대한 메일링 리스트가 있습니다.


이 메일링 리스트는 날마다 메일을 200통 정도 받습니다. 그리고 읽으려고 시도하는 사람에게는 크게 위압적일 수 있습니다. 힌트가 있습니다. 앤드류 모튼(Andrew Morton)을 제외하면 거의 한 사람도 모든 이메일을 읽지 않습니다. 대부분은 필터를 써서 자신이 관심을 가지는 것만 읽습니다. 저는 흥미로운 댓글을 남기는 몇몇 개발자를 알아내서 그들이 답변하는 스레드만 읽는 방법을 추천합니다. 또는 흥미로워 보이는 주제를 검색하는 방법도 있습니다. 그러나 모든 것을 읽으려고 시도하지는 마세요. 그럴 경우 다른 작업을 하나도 못 하게 될 것입니다.

리눅스 커널 메일링 리스트에는 또한 다른 종류의 알려진 문제가 있습니다. 많은 사람이 이 메일링 리스트에서 개발자들의 반응이 때때로 매우 '거칠다'는 것을 발견할 수 있습니다. 코드를 올리면, 잘못된 모든 점에 대해 냉혹한 리뷰가 돌아옵니다. 보통 비평가들은 코드 자체를 비판할 뿐입니다. 그러나 많은 사람에게 비판을 받는 측에 서는 것은 매우 힘든 일이지요. 완벽하다고 생각한 것을 올렸는데, 그것이 갈기갈기 찢기는 꼴을 봐야 합니다.

이것의 큰 문제는, 커널 커뮤니티에서 코드를 리뷰하는 사람은 매우 적다는 점입니다. 코드 리뷰는 힘들고, 보람 없고, 곤란한 일입니다. 그것은 아주 짧은 시간에 여러분을 심술 궂고 무례하게 만듭니다. 저는 일주일 내내 리뷰를 한 적이 있는데, 마지막에는 이런 이메일을 쓰고 말았습니다.


코드를 리뷰하는 다른 사람들은, 이때의 저만큼 친절하지는 않습니다.

저는 공개적으로 크리스토프 헬비히(Christoph Hellwig)와 랜디 던랩(Randy Dunlap)에게 감사드리고 싶습니다. 두 분 모두 linux-kernel 메일링 리스트에서 코드를 리뷰하는 데 많은 시간을 쓰고 계십니다. 그리고 그것 때문에 크리스토프의 평판은 특히 매우 나쁩니다. 그의 리뷰를 좋아하지 않는 사람들 사이에서 나쁩니다. 그러나 다른 커널 개발자는 정말로 좋아합니다. 왜냐하면 그가 옳기 때문입니다. 만일 그가 여러분에게 무언가가 잘못되었다고 말한다면, 여러분은 고칠 필요가 있습니다. 당장 고치세요. 조언을 무시하지 마세요. 다른 모든 사람이 여러분이 말한 대로 코드를 고치는지 지켜보고 있기 때문입니다. 커널 커뮤니티에는 크리스토프 같은 사람이 더 필요합니다.

만일 모든 사람이 일주일에 몇 시간을 투자해서 메일링 리스트로 보내지는 다양한 패치를 리뷰한다면, 훌륭한 일이 될 것입니다. 여러분 자신이 좋은 개발자라고 생각되지 않더라도, 다른 사람의 코드를 읽고 질문을 던져보세요. 만일 그들이 자신의 디자인과 코드를 방어하지 못한다면, 정말로 무언가가 잘못된 것입니다.

그것은 또한 프로그래밍과 커널에 대해 더 배울 수 있는 훌륭한 방법입니다. 여러분이 악기 연주를 배울 때, 처음부터 교향곡 전체를 스스로 쓰려고 하지는 않습니다. 수 년 동안 다른 사람의 악보를 읽고, 요소를 어떻게 결합하는지, 상호 작용은 어떻게 하는지 배웁니다. 그런 후에야 자신만의 음악을 만들고, 짧은 곡조를 만들고, 그리고 나서 여러분이 원한다면, 더 큰 작품에 착수합니다. 프로그래밍도 마찬가지입니다. 다른 사람의 코드를 읽고 이해하면 많은 것을 배울 수 있습니다. 올려진 글을 공부하고, 왜 그런 방식으로 했는지 질문하고, 알아낸 문제점을 지적하세요. 이것이야말로 현재 커널에 정말로 필요한 작업입니다.

(위 인용과는 다른 이야기일지도)

좋습니다. 하지만 커널을 돕고 싶지만, 프로그래머가 아닌 경우에는 어떻게 할까요? 무엇을 할 수 있을까요? 작년에 데이브 존스(Dave Jones)는 모두에게 커널이 조각조각 나뉘고 있고, 수많은 버그가 발견되어 끝이 안 보인다고 말했습니다. 수많은 사람은 이렇게 반응했습니다:


현재, 이 말은 맞습니다. 단순한 테스트 세트가 있고, 모든 사람이 새 버전이 발표될 때마다 돌려봐서, 어떤 것도 망가지지 않았다는 것은 확신한다면, 훌륭한 일입니다. 그러나 불행히도, 우리는 아직 그런 것을 가지고 있지 않습니다. 우리가 가지고 있는 현실적인 테스트 세트는, 모든 사람이 자신의 컴퓨터에서 커널을 돌려보고, 우리에게 동작 여부를 알려주는 것 뿐입니다.

따라서, 도움을 주고 싶지만 프로그래머가 아닌 분들에게 제안합니다. 리누스의 커널 트리(역주: 리눅스 커널 소스 코드는 목적에 따라 몇 가지 '트리'로 갈라져서 개발되는데, 그 중 리누스 토발즈가 관리하는 부분. 밑에 나오는 '앤드류 모튼'의 트리와 비교하면, 신기술이 덜 반영되지만 더 안정적이다)에서 매일 나오는 스냅샷(nightly snapshots)을 자신의 컴퓨터에서 돌려보고, 무언가 고장난다면 큰 소리로 불평해주세요. 누구도 주의를 기울이지 않는다면, 다시 불평하세요. 정말로 끈질겨야 합니다. 이쪽에 버그를 신고하세요:


커널 관계자들은 저곳을 주시하고 있습니다. 가끔 그렇게 생각되지 않을 때도 있겠지만, 끈질겨야 합니다. 만일 어떤 사람이 무언가를 계속 불평한다면, 우리는 기분이 나빠져서, 문제점을 고치려고 시도하게 됩니다. 성가신 사람이 되는 것에 주저하지 마세요. 우리 커널 개발자가 계속 일치 단결하려면 성가신 사람이 더 많이 필요하기 때문입니다.

그리고 여러분이 정말로 용감하다면, 앤드류 모튼(Andrew Morton)의 -mm 커널 트리를 돌려보세요. 여기에 포함되어 있는 것은, 수많은 커널 관리자(maintainer)의 모든 개발 트리가 하나의 거대하고 불안정한 덩어리로 결합된 것입니다. 그것은 최종적으로 어떤 것을 리누스의 커널 트리에 넣을 것인지를 실험하는 장소입니다. 따라서 우리는 리누스의 트리로 가기 전에, 이 커널을 테스트하여 문제를 일찍 보고할 사람들이 필요합니다.

저는 앤드류의 커널을 중요한 데이터가 들어 있는 컴퓨터에서 돌리는 것을 추천하지 않습니다. 현명하지 않지요. 따라서 만일 여러분에게 남는 컴퓨터가 있다면, 또는 훌륭한 백업 정책을 가지고 있다면, 그의 커널을 돌려보고 문제가 있다면 우리에게 알려주세요.

그럼 마지막으로, 결론으로서 여러분이 기억해주셨으면 하는 주요 사항을 보여드립니다:













posted Sun, 23 Jul 2006 in [/linux]

---

리눅스 정복은 개발자와 사용자의 손으로 이루어지는 것이겠지요.

클로즈드 소스 리눅스 커널 모듈의 위험성에 대해 설명한 부분이 인상적이었습니다.

오역이 있으면 언제든지 신고해주세요.

Posted by 랜덤여신

이 글의 관련글

• 리눅스 커널에 대한 신화, 거짓, 그리고 진실 - 1편
• 리눅스 root 권한 획득 보안 버그 발견 - vmsplice() exploit
• 우분투 8.10 코드네임 발표 - Intrepid Ibex
• KDE 4 출시 후보(RC) 1 발표
• 우분투에서 DHCP 사용 시 DNS 서버 고정하기