게오르그의 멋진 GNU 세상 한국어판 - GNU 프로젝트

멋진 GNU 세상을 찾아주신 것을 환영합니다. 지난호의 마지막 부분에서 약속했듯이, 이번달에는 우리의 삶을 보다 편하게 만들어주는 프로젝트들에 대해서 소개하려 합니다.

SpamAssassin

SpamAssassin[5]은 Justin Mason이 제작한 프로그램으로 여러분에게 도착하는 이메일중 스팸들을 "제거"하도록 되어 있습니다. 아니면 최소한 procmail이나 다른 메일 리더들이 사용자가 정의한 방식으로 스팸을 다룰 수 있도록 스팸이라는 표시를 합니다.

SpamAssassin의 핵심부분은 펄로 제작되었으며 GNU 일반 공중 사용 허가서와 펄 자체의 Artistic 라이센스를 똑같이 준수합니다. 이렇게 함으로써 SpamAssassin은 "Comprehensive Perl Archive Network"(CPAN)[6]를 통해서 배포될 수 있으며 어떤 법적인 문제에 휘말리지 않고 코드를 재사용할 수 있습니다.

그런데 라이센스 논쟁이 이 프로젝트가 시작할 때 중요한 부분이 되었습니다. SpamAssassin을 제작하기 전에 Justin은 펄로 작성된 다른 메일 필터를 사용했는데 이 필터는 고정적인 규칙과 불명확한 라이센스 상황으로 인해 문제가 되었습니다.

이 프로젝트로부터 Justin은 GNUS 뉴스/메일 리더에서 사용되고 있는 "인정 점수"와 유사한 개념의 점수제에 대한 생각을 얻었습니다.

SpamAssassin은 이메일을 분석하는 많은 다른 테스트들을 통해서 동작합니다. 메일이 스펨에 자주 포함되는 문장을 포함하고 있지 않은지, 스팸들에 나타나는 형식이나 특징이 발견되는지, 지나치게 많은 느낌표와 물음표가 들어있는지, "수백만달러"에 대해 이야기하는지와 같은 것들을 HTML로 작성된 메일을 검사하는 데 사용합니다.

모든 테스트가 실행되고 나면 이메일은 점수를 획득하게 되는데 사용자가 간단한 ASCII 설정파일에 명시한 규칙에 의해 각각의 테스트가 얼마나 많은 점수를 획득하게 되는지가 결정됩니다. 만일 총점이 정해진 규정점수를 넘지 못하면 SpamAssassin은 그 메일이 스팸일 것이라고 판단합니다.

이 판단에 의거해서 SpamAssassin은 테스트 결과에 대한 표시를 헤더에 삽입합니다. 만일 사용자가 결과를 나중에 보다 쉽게 확인하기를 원한다면 스팸으로 분류된 메일의 Content-Type을 강제로 "text/plain"으로 바꿉니다. 또한 SpamAssassin은 메일의 시작부분에 보다 자세한 테스트 결과를 삽입해서 사용자가 나중에 어째서 이 메일이 스팸으로 분류되었는지를 쉽게 확인할 수 있도록 설정할 수도 있습니다.

SpamAssassin을 사용하는 데 있어서 가장 큰 잠재적 위험은 분명히 정기적으로 오는 메일이나 정상적인 메일을 스팸으로 잘못 분류하는 상황입니다. 따라서 정기적으로 스팸메일을 저장하는 폴더를 살펴서 스팸 확인이 모두 정상적으로 이루어지고 있는지 확인할 필요가 있습니다.

SpamAssassin의 감도를 낮게 설정할 수 있습니다. 물론 이렇게 하면 걸러지지 않는 스팸의 수는 늘어날 것입니다. 적절한 균형을 찾는 것이 SpamAssassin 관리자의 역할 중 까다로운 부분입니다.

스패머들이 SpamAssassin의 테스트를 피해갈 수 있는 방법을 찾아내는 것을 피하기 위해 이 프로젝트는 쉽게 확장이 가능하며 많은 다른 테스트 방법들을 추가하고 있습니다.

물론 SpamAssassin은 온라인-블랙리스트를 지원합니다. 표준 DNS-블랙리스트는 스팸을 구분하기 위해서 Vipul's Razor [8] 에 의해 제공되는, 알려진 주소들을 모아놓은 스팸 데이터베이스 에서 알려진 주소들과 릴레이를 허용하는 서버들을 참조합니다.

가능한 한 많은 양의 메일을 필터링하거나 많은 메일 소스들에 연결할 수 있도록 하기 위해, Craig Hughes는 "spamd" 데몬을 작성했습니다. 이 데몬은 SpamAssassin 패키지에 포함되어 있습니다.

SpamAssassin의 가장 큰 약점은 대상이 되는 기술적인 측면의 경험이 있는 사용자들의 범위가 불명확하다는 것과 아직까지 그래피컬한 사용자 환경(GUI)을 갖추지 못하고 있다는 부분입니다.

이 부분을 해결하는 것은 보다 많은 테스트를 작성하고 활용하기 위한 많은 메일 소스들을 생성하는 것만큼 의미있는 앞으로의 개발목표입니다. 현재 Milter 라이브러리와 Mail::Audit 플러그인을 통해서 Procmail, Qmail, Postfix, Sendmail 등과 함께 사용할 수 있습니다.

저는 제가 사용 가능한 해결책들을 찾는 데 실패한 후 스스로 만들기 시작한 sendmail-milter[9] 플러그인의 관리에서 벗어날 수 있기를 바랍니다. 제가 받는 모든 메일들을 SpamAssassin을 통해서 필터링할 수 있기 때문입니다. 이 프로젝트를 완벽하게 관리하기엔 제게 시간이 많이 부족합니다. 그래서 자유소프트웨어의 가장 훌륭한 전통에 의해 Michael Brown이 이 프로젝트의 관리자로 나섰습니다. 그의 회사는 이 프로젝트를 상업적 환경에서 사용하고 제공하고 있습니다.

이것은 자유소프트웨어가 기존의 "가려운 곳을 긁어주는" 기능과 회사의 상업적인 관심과 함께 모든 사용자들에게 가장 좋은 형태로 조화를 이루며 나아갈 수 있는가에 대한 훌륭한 예입니다.

스팸의 지속적인 증가가 인터넷의 기반을 위협하고 있는 현실에서, 하루에 60여통의 스팸메일을 받는 저는 SpamAssassin과 같은 프로젝트에 대해 아주 큰 지지를 보냅니다.

Voxximate

정기적으로 멋진 GNU 세상을 읽어왔다면 과학분야에서의 자유 소프트웨어의 사용에 관한 논의들에 괘 익숙할 겁니다.

결국, 길게 본다면 모든 과학분야에서 자유 소프트웨어를 사용하는 것이 합리적입니다. 자유 소프트웨어만이 다음 프로젝트에서도 계속 사용할 수 있다는 보장을 할 수 있고, 결과물이나 시험에서(passing) 출판물 형태의 산출물이 필요할 때 포함될 수 있기 때문이죠.

Andreas Neumann이 만든 Voxximate [10] 는 GNU 일반 공중 사용 허가서를 준수하여 만든 그런 자유 소프트웨어입니다.

Voxximate 는 "집에서 하는 와류(渦流) 모의실험(flow simulation made at home)" 이란 뜻으로, 유체의 흐름이나 소용돌이를 모의실험하는 프로그램입니다. 프로그램은 미리 정의된 시작점을 가지고 동작하고 명확한 단계들을 통해 소용돌이들이 서로간에 미치는 영향을 계산하고 시간에 따라 변하는 모습을 추적합니다.

이 프로젝트는 유체 역학에 대해 공부할 때 소용돌이들이 어떻게 상호작용을 하고 구조를 만드는지에 관해 관심이 있는 모든 학생들에게 아마 많은 도움이 될겁니다.

Voxximate는 자바로 만들어졌기 때문에 보통의 자바가 갖는 문제들을 가지고 있지만, 이것이 개발에 지장이 되진 않을 것입니다. 다음 단계로 Andreas는 시작점을 정의할 수 있는 그래픽 에디터와 웹에 개시할 수 있도록 그림과 애니메이션을 저장하는 기능을 추가하고 싶어합니다.

Monica

Monica [11] 는 Tila Riemer가 만든 모니터 보정 프로그램입니다. C++ 로 만들어졌으며 Fast Light Toolkit (FLTK) [12] 를 사용하고 XFree86 [13] 의 xgamma 프로그램입니다.

모니터의 감마보정이 잘못되면 근처에 위치한 색들을 구별할 수 없게 되고 색의 배합이 불만족스럽게 됩니다. 특히 그래픽 작업에 쓰이는 컴퓨터라면 사용자를 혼란스럽게 만들 수 있습니다.

Tilo Riemer는 처음에 KGamma [14] 라는 비슷한 종류의 프로젝트를 사용하려고 했으나 그에겐 없는 몇몇 KDE 라이브러리들 때문에 그것을 컴파일 하는 데 실패했습니다. 또, KGamma는 KDE에 꽤 의존하고 있어서 KDE의 많은 부분이 필요로 해 보였습니다.

그래서 2002년 1월 그는 매우 작고 빠른 Monica를 만들기 시작했습니다. Monica는 동적인 피드백이 가능한 "on-the-fly" 모드를 지원하고, 900MHz 컴퓨터에서 10-20%의 CPU 시간만을 필요로 합니다.

이 외에도 Monica는 FLTK 외에는 의존하는 것이 없고, 창 관리자나 데스트탑과 독립적으로 동작하기 위해 변경사항을 ".xinitrc"에 저장한다는 강점들이 있습니다.

최근에 발표된 1.0 버전은 Tilo가 Monica 자체에는 많은 시간을 투자하지 않을 것임을 암시합니다. 하지만 Monica를 국제화하는 데에는 노력할 것입니다.

하지만 유럽대륙에서 Public Domain에 대한 생각이 아주 문제가 없는 것은 아닙니다. 독일에서 Public Domain이란 용어에 대한 표준 법규 해석은 작가가 누군지 모르거나 작가가 70년 전에 죽은 경우에 저자나 저작권에 대한 요청이 자유롭습니다.

그래서 Tilo는 Monica 를 유사 BSD 라이선스를 준수하여 배포하기로 결정함으로써 문제를 해결했고 Monica는 자유 소프트웨어가 되었습니다.

이 이야기는 이와 같은 일이 유별난 일이 아니라, 개발자들이 라이선스에 대해 고려하지 않는 것은 쉽게 위험을 초래할 수 있음에도 그렇지 않고 있다는 것을 명확히 보여주는 것입니다. 그래서 저는 자유 소프트웨어의 법적 유지력에 관해 쉬운 소개글을 쓰려 합니다.

자유소프트웨어에 대한 법적 유지력

대부분의 사람들이 소프트웨어에서 가장 중요한 부분은 지속적인 기술유지라고 생각하고 있습니다. 왜냐하면, 그렇지 않을 경우 매우 빠르게 그 소프트웨어의 필요성 을 잃어버리게 되기 때문입니다. 일반적으로, 지속적으로 유지가 된 소프트 웨어들만이 오랜 시간 동안 사용되기 마련입니다.

이러한 기술과정은 소스코드와 법적 소유권(예를 들어, 유지를 수행할 수 있는 자유)을 관리하는 것에 영향을 받게 됩니다. 일반적으로 소유권과 사회일원의 의무를 정의하는 것은 정치적이고 법적인 문제입니다.

법이 잘 지켜지고 있고, 그렇지 않느냐 하는 것은 중요한 것이 아닙니다. 사람들이 꼭 알아야 하는 것은 기술 유지력의 필요성의 정도가 법적인 기본 성격을 띄고 있느냐 입니다.

특히 상업적인 환경 속에서는, 지속적이고 끊임없는 유지력의 확실성이 자유 소프트웨어의 발전적인 요소들 중 하나가 됩니다. 이러한 발전은 자유 소프트 웨어의 법적 유지력에 상당히 의존하게 됩니다

자유 소프트웨어에 대한 자유, 권리, 의무는 인정이 되고, 때로는 개발자의 저작권으로 소프트웨어를 보호하는 라이센스에 의해 보호가 됩니다. 자유소프트웨어는 저작권법에 절대적인 영항을 받지는 않지만 저작권법이 존재하는 한 우리는 여기에 대해서 고려해야 할 필요가 있습니다.

얼마나 많은 사람들이 그것을 직관적으로 알고 있느냐와는 관계가 없더라도, 법적체계는 항상 똑같은 것이 아니라, 언제나 변화하게 됩니다.

최근 독일의 경우, 저작권과 관련된 변화들이 그 소프트웨어를 잠재적으로 약하게 하거나 비합법화하게 할 수 있습니다. 이러한 특별한 경우에, iFrOSS[15] 유럽 자유 소프트웨어 재단[16]이 자유소프트웨어에 대한 예외사항을 소개하거나, 제안된 권리법 개정의 변경을 제안할 수 있습니다. 이 변경사항은 ifrOSS가 제안한 본래의 형태에 법적으로 그것을 만들게 되었고, 2002년 1월 25일에 통과된 법의 한 부분이 됩니다. 이 법은 곧 효력이 발생하게 될 것입니다.

유럽 자유소프트웨어 재단의 활동 중 하나는 자유소프트웨어에 대한 긍정적인 방법으로 소프트웨어들에 그러한 개발과 영향들을 주는 것들을 찾는 것입니다. 밑바탕에 매우 분명하게 법적인 ifrOSS와 같은 조직들과 관련된 기업이 없이는, 이런 활동을 하는 것은 매우 상당히 어려울 것입니다. 이 또한, 유럽 자유소프트웨어 재단이 유럽전역에 걸쳐 기업을 계발하고 강화시키려고 노력하는 이유의 하나입니다.

다른 법적인 요소들에 대한 변화에 의해, 라이센스의 개정을 요구하는 것도 가능할 것입니다. 법적인 변화나 ASP(Application Service Providing) 같은 새로운 기술적 개념은 몇몇 분야에서 자유의 보호를 피할 수 있고, 심지어는 법을 무효화하거나 라이센스의 정신을 심각하게 파괴할 수도 있습니다.

대부분의 개발자들은 그들의 소프트웨어의 자유성이 안전하게 보호될 거라고 생각하며 GNU GPL을 라이센스로 하여 그들의 소프트웨어를 내놓게 됩니다. 그렇게 하게 될 때, 자유소유트웨어를 보호하는 방향의 대부분의 중요한 단계는 이미 거치게 된 것입니다. "또는 이후의 버젼"이라는 조항을 사용함으로써, 자유소프트웨어재단은 또한 부분적으로 포괄적으로 GPL 또는 Lesser GPL 하에 라이센스를 보호와 방어, 유지를 하는 데 힘이 생기게 되는 것입니다.

때때로 라이센스를 확실하게 변경하는 것은 매우 중요한 경우가 되기도 합니다. 예를 들어, GPL의 "또는 이후의 버젼"이라는 조항이 제거될 경우가 있을 수 있습니다. 그러한 경우, 법적 권리의 핵심적인 유지를 만들지 않는 프로젝트들은 심각한 문제에 부딪히게 될 수 있습니다. 예를 들어 현재나 나중의 버전에서 GPL에 관한 조항이 삭제될 수도 있습니다.

그러한 경우에, 모든 개발자들은 여기에서 파생되는 모든 변경사항들을 동의해야만 합니다. 프로젝트들을 개발하는 개발자들의 권익과 의견이 폭넓게 반영되면 더 좋겠지만 그런일을 거의 일어나지 않을것 같습니다.

또한, 대부분의 경우에 있어서 "판권"같은 소위 "독점적 착취권 "이라 불리는 것의 소유자는 법원에서 법적으로 라이센스를 강요할 수 있는 권리가 있습니다. 그래서 법원에서 프로젝트의 권익을 표명하려고 노력할 때, 프로 젝트들은 심각한 어려움들을 겪을 수 있습니다.

많은 제작자들이 프로젝트를 수행하고 있다는 것이 주어지면, 그들은 실제로 그들의 개인적인 권익들을 보호하기 위해서 함께 행동을 취하거나 팀을 구성해야만 합니다. 이것을 하기 위해서는 많은 조정과정(또는 중재)과 시간, 노력이 필요합니다. 또한, 모든 제작자들이 결국 잠재적으로 비긴 법적 논쟁을 보고 싶어하지도 않고, 보려고 하지도 않을 것입니다.

만약 모든 프로젝트들이 이러한 관계들을 알게 되고, 충분한 예방책들을 준비해 놓는다면, 아무 문제가 없을 것입니다. 또한, 법적 전문가를 둠으로써, 제작자들은 소프트웨어 자체를 개선하는 것을 후에 논의할 수 있습니다.

사용자들이 이러한 것에 상당히 매우 엄청나게 자주 관심을 가지기 때문에, 미래에 는 아마도 거의 분명하고 법적 환경이 정리가 잘 된 프로젝트들이 인기를 더 많이 얻을 것입니다.

유럽대륙 원작자 법이 미국식 권리법에 비해 매우 다른 기반을 가지고 있기 때문에 유럽 자유소프트웨어 재단은 ifrOSS에서 일하는 Axel Metzger, Carsten Schulz, Till Jaeger와 함께 "신탁 계약 동의서"에 대해 작업을 해 왔습니다. 왜냐하면, 신탁 계약 동의서라는 것은 유럽 자유소프트웨어 재단이 제작자들의 법적 전문가로써 활동하는 것을 허용하기 때문입니다.

제작자들은 그들이 다른 계약(심지어는 잠재적으로 독점적인 계약이라도) 하에 소프트웨어를 이중 계약이 가능한 "단일 신탁권"의 무한한 양을 유지하게 됩니다.

동시에, 유럽 자유소프트웨어 재단은 자유소프트웨어의 권익에 있어서 이전된 권리를 사용하거나, 자유계약하에 소프트웨어 를 발표할 수 있게 보증합니다. 그렇지 않으면 제작자에게 모든 권리가 돌아갑니다.

이 계약은 현재 마지막 내부 " 재검토상태"에 있고, 빠른 시일 안에 대중들에게 소개될 것입니다.

유럽 자유소프트웨어 재단의 회장으로서, 저는 자유소프트웨어 재단이 오랜 기간 동안 알려진만큼 신뢰도를 가지고, 이러한 시도들을 계속 추진함으로써, 이러한 임무에 매우 적합한 재단을 만들어갈 생각입니다.

그들은 GNU GPL과 Lesser GPL에 대해 최고의 지식과 경험을 가지고 있을 뿐 아니라, 자유소프트웨어의 권익을 보호하기 위한 정당화된 평가를 받을 수 있고, 세계적으로 활동할 수 있습니다. 물론, 필요한 경우 법적인 면까지도 보호를 할 수 있습니다.

이번 호를 마치며

오늘은 이것으로 충분할 것 같습니다. 자유 소프트웨어 재단의 배경이나 업무, 그리고 노력(work)에 대한 인식을 형성하기 위한 마지막 부분이 성공을 거두었길 희망합니다.

평소처럼, 아이디어나 의견, 질문과 새로운 프로젝트에 대한 많은 이메일을 보내주셨으면 합니다.

GNU 홈페이지의 메인 화면으로 돌아갑니다.

자유 소프트웨서 재단과 GNU 프로젝트에 대한 질문은 gnu@gnu.org로 보내주십시오.
그밖의 연락 방법에 대해서는 연락처 안내 부분을 참고하시기 바랍니다.

게오르그의 멋진 GNU 세상에 대한 의견은 영어 또는 독일어로 column@gnu.org 앞으로,
홈페이지 자체에 대한 질문은 webmasters@gnu.org로,
기타 질문은 gnu@gnu.org로 보내주십시오.

최근 수정일 : Fri Mar 8 16:35:35 CET 2002