[번역] GPL v3, the Q&A: 2부 - 개발자

wariua의 이미지

Luis Villa씨가 작성한 GPL v3, the Q&A: part 2- developers를 제멋대로 번역해 봤습니다.


Q: 속편 치고 구리지 않은 게 있었던가요?

A: 대부 II와 스타워즈 II(난 V편이라고 부르지 않아요.)는 구리지 않았죠. 난 Coppola씨가 아니지만, 아마 Lucas씨보다는 나을 걸요. 어떨지 한번 보죠.

Q: 난 개발자고, 지금 내 코드는 GPL v2를 쓰고 있어요. v3로 올리는 게 좋을까요?

A: 아마도요. 업그레이드를 당연하고 의무적이게 하는, 모든 개발자를 위한 어떤 거대한 이익이 라이선스에 포함돼 있지는 않아요. 하지만 편리한 FLOSS 프로젝트를 하고 싶어 하는 거의 모든 이들을 위한 작은 이익들이 포함돼 있기는 해요. 특히 모든 개발자들은 (아직 불완전하지만) 개선된 특허 보호, APL 라이선스 코드를 자신의 코드에 그대로 가져다 쓸 수 있다는 사실, 미국 저작권 체계 밖에서 더 강력한 보호를 제공해 주는 국제화된 법률적 용어의 가치를 알아둘 필요가 있어요.

더불어 자신의 코드가 TiVo-ization 되는 것, 혹은 자신의 코드가 DRM 시스템에서 쓰이는 것에 반대하는 개발자라면 새 라이선스의 관련 부분이 마음에 들 거예요. 어제 언급한 것처럼, 그 부분은 완벽하지는 않겠지만 당신 코드의 사용자가 언제나 코드에 접근하고 코드를 변경할 수 있는 권리를 가지도록 보장하는 데 있어서 큰 진전을 이룬 거예요. 이전 라이선스에서 반드시 분명했다고 할 수 없는 점이죠.

Q: 분명 부정적인 면도 있겠죠.

A: 당연하죠. 라이선스를 지금 도입한다면 최첨단에 서게 되는 거예요, 그로 인한 모든 결과를 감수하면서 말이죠. 사람들에게 라이선스에 대해서 몇 번이고 설명해야 할 거고, 왜 그걸 선택했는지 등을 설명해야 될 거예요. 별로 재밌는 일이 아닐 테고, 프로젝트의 공헌자들 가운데 일부를 잃을 수도 있어요. 잘못 선택한 것이 될 가능성이 (작기는 하지만) 존재하고, 라이선스에 어떤 결함이 있을 가능성도 있어요. 그렇게 되지 않을 것 같기는 하지만[1], 불가능한 일만은 아니예요. 라이선스가 나온 지 꽤 되기 전에 전환한다는 건 그런 위험을 지게 되는 거죠.

그리고 GPL v2와의 호환성을 잃게 돼요. v2 '또는 이후 버전'이라고 돼 있지 않은 거대한 기반 어디에서도 코드를 그대로 가져다 쓸 수 (그리고 그 반대로 할 수) 없게 되는 거죠. 어떤 식으로 개발을 하는가에 따라서 이게 상당히 부정적인 면이 될 수도 있고 그렇지 않을 수도 있을 거예요. 하지만 분명히 알고 있어야 할 내용이예요. (이 점에 대해선 이후의 글에서 좀 더...) 마찬가지로, 어떤 프로그램이 당신 프로그램을 링크하거나 혹은 당신의 코드를 공유하고 있는데 그 프로그램들이 라이선스를 바꿀 준비가 안 됐다면, 라이선스를 바꾸는 게 어려워질 수 있겠죠. GPL v2 프로그램은 GPL v3 프로그램을 링크할 수 없으니까요.[2]

마지막으로, DRM 및 임베딩/TiVo-ization 내용에 대한 게 있어요. 당신 프로젝트가 임베디드 장치나 멀티미디어 장치에서 중요하게 쓰이고 있다면 v3에 대해서 얘기하려고 할 때 당신 파트너가 상당히 신경질을 낼 수도 있어요. 당신이 자유주의자 내지는 실용주의자의 개발자 중심적 관점을 가지고 있는 경우에도 그런 새로운 제약에 개인적으로 반대할 수 있겠죠. 그런 이유들로 여러 프로젝트에서 이 라이선스를 피할 수 있을 거예요.

Q: Novell을 어떻게든 물먹이고 싶습니다. v3로 바꿔야 할까요?

A: Novell에게 뭔가 복수를 할 방법을 찾고 있는 거라면 이 라이선스를 가지고는 할 수 없어요. 내일 좀 더 쓰겠지만 한 마디로 하자면, 할 수 없어요. 만약 그래서였다면 라이선스를 선택하는 이유로 그리 아름다운 건 아니네요. 운이 좋다면 GPL은 (그리고 GPL로 된 당신의 코드는) 현재 Novell의 주도권보다 오래 갈 것이고, 어쩌면 Novell이라는 회사보다 오래 갈 거예요. Novell이 고의적으로 이전 라이선스의 의도를 기만한 것이냐의 여부가 아니라, 당신과 당신의 코드, 그리고 당신의 사용자를 보호하기 위해 어떤 게 올바른가를 기준으로 결정하세요. (그와 관련해 한마디 하자면, 이 라이선스는 적어도 미래의 어떤 Novell 같은 상황에서는 당신을 보호해 줄 거예요. 그러니 Novell이 한 게 나쁜 거라고 생각한다면 업그레이드를 하고 싶을 수 있겠네요.)

Q: 커널쪽 사람들은 이전 초안을 보고 아주 악을 썼죠. 라이선스가 그들의 비판에 얼마나 답해준 거죠? 라이선스가 받아들여지는 데 영향을 주게 될까요?

A: DRM 및 임베딩 라이선스의 이전 초안들은 모범으로 삼을 만큼 명확하지는 않았어요. Linus와 그 친구들의 비판에 따라서 최종 초안은 훨씬 더 단순명료해졌죠. 지금의 DRM 조항은 효과적인(effective) DRM 장치라고 주장할 수 없다고만 선언하고 있어요. 반면 이전에는 실질적으로 그런 장치의 구축 자체를 막으려고 했었죠. 마찬가지로, 지금의 임베딩 조항은 소프트웨어를 재설치 하는 데 충분한 정보를 요구하는 것이라고 분명하게 말하고 있어요. (그 정보가 어떤 형태가 되었건 말이죠.) 이전 버전은 상당히 애매해서 개발자의 GPG 키 같은 것들이 드러나야 된다고 (잘못) 읽을 수 있었죠.

하지만 그렇게 분명해진 것들이 수용에 실제로 도움이 될지는 확실치 않아요. 분명 첫 번째 초안 때 상당했던 FUD(역자주: fear, uncertainty and doubt)의 가능성을 줄여주겠죠. 그래서 사람들의 결정이 이 조항에 달린 경우에도, 적어도 잘못된 표현으로 인한 잘못된 문제 제기가 아닌 올바른 문제 제기가 이뤄지게 되기는 하겠죠. 하지만 그 조항들은 여전히 뚜렷한 현실적 이득을 돌려주는 것 없이 개발자에게 부담을 주고 그들을 제약하고 있어요. 실용주의적인 개발자의 결론이 '우리에게 이득을 주면 당신의 라이선스를 사용하겠다'는 거라면, 그 조항들이 분명해진 건 상황을 좀 더 분명하게 해 줄 수는 있겠지만 그 상황을 상당하게 바꾸지는 못하는 거죠.

Q: 좋은 점도 있고 안 좋은 점도 있는데... 어쩌면 될까요?

A: 아쉽게도 단순하게 맞고 틀리는 대답 같은 건 없어요. 모든 프로젝트는 현실적인 비용과 이익, 그리고 정치-철학적 태도에 따라 자체적으로 판단을 해야 해요. 기여자들로부터 확실한 특허 라이선스를 얻고 싶거나 사용자의 통제에 대해 철학적으로 특별히 관심이 있는 프로젝트라면 아마 어떤 방향으로 기울겠죠. 그리고 모바일 영역과 관련해 고민을 하고 있거나 저작권과 관련한 상황이 특별히 혼란스런 프로젝트라면 아마 다른 쪽으로 기울 테구요.

Q: 그런 말은 전혀 도움이 안 돼요. 아직 마음을 정할 수가 없어요. GPL v2나 다른 자유 소프트웨어 라이선스와의 듀얼 라이선싱을 생각해 봐야 할까요?

A: 듀얼 라이선싱은 양날의 칼이에요. 한편으로는 사용자에게 좀 더 큰 유연성과 선택 기회를 주고 기여자와 사용자에게 불확실성을 줄여 주죠. 다른 한편으로는 사용자에게 좀 더 큰 유연성과 선택 기회를 주죠--그리고 그 사용자에는 나쁜 이들도 포함돼 있구요. 말하자면 당신 코드는 가장 약한 라이선스 하에서만큼만 보호를 받는 거예요. 그러니 당신 코드를 GPL v2와 GPL v3 모두로 릴리스 한다면 별로 얻을 수 있는 게 없어요. 특허나 DRM에 당신을 팔아먹을 다음 사람은 '음, 난 v2에 따라서 쓰고 있는 것뿐이야'라고 말하면 그만이니까요. v3의 완전한 보호를 얻고 싶으면 v3만으로 라이선스를 하거나 v3에 더 제약이 있는 (아마도 독점적) 라이선스를 더해서 사용해야 해요.

그리하여 듀얼 라이선싱의 주된 장점은 다른 사람들이 자신이 선택한 라이선스에 따라서 당신의 코드를 재사용할 수 있다는 것뿐이에요. 작은 이득은 아니죠. GPL 2와 3 모두로 돼 있는 플랫폼에서 개발된 프로그램들이 필요한 GPL 라이선스의 플랫폼 프로젝트의 경우에 특히 유용하겠죠. 하지만 대단하기까지 한 것 역시 아니죠.

Q: '혹은 이후의(or later)'란 표현은 어떻게 하죠? 이 라이선스에 이렇게 논란이 있는 걸 보면 FSF가 GPL v4에서 올바른 결정을 내릴 거라고 신뢰하지 못할 수도 있는 거 아녜요?

A: FSF에서는 당신 코드를 'v3 또는 이후 임의 버전의 GPL' 하에 라이선싱 하기를 권장해요. GPL v2에서와 마찬가지로 말이죠. 이는 두 가지 의미가 있어요. 긍적적인 면으로는, 라이선스에 문제가 발견됐는데 사람들이 당신에게 연락을 할 수 없는 경우에 그들이 문제가 덜한 새로운 라이선스 하에서 당신의 코드를 계속 사용할 수 있다는 게 돼요. 이는 논란의 여지는 있지만 Novell과 v2 및 v3의 특허 조항과 관련해 일어날 일이기도 하죠. 문제가 발견되었고, 'v2 또는 이후'로 코드를 남겨두고 세상을 이미 뜬 이들은 여전히 자기 코드가 다른 사람들에게 유용하도록 해줄 수 있는 거죠.

부정적인 측면으로, 당신이 FSF를 신뢰해야 한다는 뜻이 되기도 해요. 난 신뢰해요. 당신이 시간을 내서 네 가지 자유(역자주: "자유 소프트웨어란 무엇인가?" 참고)를 읽어봤다면 이 라이선스에는 그들이 20년간 선언해 왔던 것에서 어긋나는 게 전혀 없단 걸 분명하게 알 수 있을 거예요. 하지만 그러한 사용자의 자유를 적극적으로 보호하는 게 당신의 취향이 아니라면--분명 모두의 취향은 아니죠--GPL v4와 관련해 FSF를 신뢰하고 싶지 않을 수도 있고, 따라서 '혹은 이후의' 표현이 당신 코드에는 적절하지 않을 수도 있을 거예요.[3]

다시 말하자면, 이건 위험과 보상, 신뢰와 관련된 꽤나 개인적인 결정이에요. 난 개인적으로 FSF가 꽤 예측 가능하다고 생각하기에 내 작업물을 '혹은 이후의' 문구로 라이선싱 하지만, 모두가 그렇지는 않다는 것도 분명한 거죠.

Q: 라이선스를 바꾸기로 결정했다고 치면, 그게 어떤 식으로 이뤄지는 거죠?

A: FSF와 SFLC가 라이선스 변경 방식에 대한 권고를 내놓을 거예요. 이 글을 쓰고 있는 시점에서 내가 권장하는 건 그들의 권고를 기다리라는 거예요. 그들은 전문가이고, 이런 실질적 세부 사항들에 대해서 내가 지금 하고 있는 것보다 훨씬 많은 생각들을 해왔을 테니까요.

Q: 저작권과 관련한 상황이 특별히 혼란스런 프로젝트라는 말을 했는데, 무슨 뜻이죠?

A: 예를 들자면 커널이 그렇죠. 알다시피 커널의 많은 부분이 v2만으로 라이선스가 되어 있고, 또한 기여자들 중 다수가 AWOL(역자주: absent without official leave; 버려둠, 방기)해 버렸거나 고인이 되기도 했죠. (내가 아는 한) 그러한 규모의 프로젝트 가운데 라이선스 변경을 시도했던 건 하나(Mozilla)뿐이는데, 코드 대부분의 저작권 소유자가 유일(Mozilla/Netscape)했음에도 불구하고 시간이 오래 걸렸어요. 커널의 경우는 충분히 더 걸릴 수 있죠. 단일한 저작권 소유자가 있는 것도 아니고, 코드도 몇 배는 더 많으니까요. 따라서 커널의 라이선스를 바꾸는 것에 대한 논의는, 특히 단기적으로는, 현실적인 것일 수가 없어요. 실용주의적으로 그 일부를 듀얼 라이선싱 하는 것 정도가 기대할 수 있는 최선일 거예요.

커널뿐만이 아니에요. (GNOME 같은) 대형 프로젝트 다수가 저작권 양도를 하지 않고 있고, 따라서 라이선스를 바꾸려는 시도는 오랜 시간이 걸릴 것이고, 저자에게 연락을 할 수 없는 이전 코드를 재작성 하는 작업까지 필요할 수도 있어요. 이런 것들이 이 라이선스의 영향을 충분히 제한할 수 있어요. 새로운 프로젝트는 v3로 옮겨가지만 오래된 프로젝트에게는 v2가 현실적으로 가능한 라이선스로 남는 거죠. 어떻게 될지 한번 지켜보죠.

Q: 개발자들를 위한 마무리를 해주자면?

A: 라이선스의 장점들이 굉장한 건 아니지만 현실적인 것이고, 내 추측으로는 몇 년 내에 지금의 v2처럼 신규 자유 소프트웨어 프로젝트 대부분의 기본 라이선스가 될 것 같아요. 지금은 그 기차에 타지 않겠다고 선택했다면 그것도 좋은 선택이에요. 다만 라이선스를 이해하고서 올바른 근거로 그렇게 하는 것이어야겠죠. (어느 쪽이든 간에) 단순 반사 같은 결정을 내린다면 후회하게 될 거예요.


주석:

  1. 아주 숙련된 법률가 다수와 꽤 많은 수의 상식 있는 해커들이 이 라이선스를 검사해 봤어요. 그리고 최악의 경우에도 v2에서와 같은 권리와 보호를 얻을 수 있구요.
  2. 현재의 FAQ에서는 v2 프로그램이 LGPL v3에도 링크를 할 수 없다고 암시하고 있지만, 그게 해결될 거라고 지난 주에 SFLC가 우리 위원회에 얘기했어요.
  3. FSF를 싫어하게 될 수도 있겠지만 그들은 더 제약적인 라이선스만을 만들어 낼 거라는 걸 말해 둘 필요도 있을 것 같네요. 즉 '맘대로, 즐겁게, 코드에 하고 싶은 대로 아무 거나 하시라'고 하는 자유주의적 GPL 4를 만날 가능성은 전혀 없어요. 그 말인즉, GPL 4가 '모든 사람은 그 코드를 사용하기 전에 RMS에게 경의를 표해야 한다'라고 명시하고 당신이 '또는 이후의' 문구를 사용했다면, 최악의 경우 그들이 당신 코드를 가져다가 자기네들끼리 가지고 놀 수 있다는 게 되죠. 더 적은 제약이 시장이라는 이데아에서 성공한다는 걸 정말고 믿고 있다고 하면 '또는 이후의' 때문에 잃을 게 없겠죠. 수많은 해커들은 FSF가 뭘 하든 간에 정말로 끌리는 이유가 있을 때에만 새 라이선스로 옮겨갈 테니까요.

« 1부 - 라이선스
» 3부 - 회사

댓글

envia의 이미지

수고하셨습니다! 고마운 마음으로 읽고 있습니다.

주석 3번 마지막 문장은 "정말로 끌리는 이유가 있을 때에만 새 라이선스로 옮겨갈 테니까요" 정도로 옮기는 것이 더 자연스러울 것 같습니다. 그렇게 하면 FSF가 이상한 일을 하더라도 해커들이 옮겨가지 않을 테니, '또는 이후에'라는 표현을 써도 별 문제 없을 것이라는 문장이 됩니다.

----

It is essential, if man is not to be compelled to have recourse, as a last resort, to rebellion against tyranny and oppression, that human rights should be protected by the rule of law.
[Universal Declaration of Human Rights]

----

It is essential, if man is not to be compelled to have recourse, as a last resort, to rebellion against tyranny and oppression, that human rights should be protected by the rule of law.
[Universal Declaration of Human Rights]

권순선의 이미지

수고하셨습니다! 마지막 부분의 "저작권 지정"은 "저작권 양도"로 표현하는 것이 좀더 명확하지 않을까 합니다. :-)

wariua의 이미지

좋은 의견 감사합니다. KLDP Wiki에 올리기에는 글의 성격이 살짝 맞지 않는 것 같아서 kldp.org에서 쓰고 있는데, 이럴 때는 위키의 공동 작업 방식이 다시 그리워지네요. 다른 번역상의 실수나 잘못된 점들도 언제든지 지적해 주세요~

역시나 뭔가를 해야 배우는 것 같습니다. 이번 작업을 하면서도 GPL이며 관련 내용들에 대해서 많이 배우네요. 사용자에게 GPL이 가지는 의미와 개발자에게 GPL이 가지는 의미에 대해서도 다시 생각해 보게 되구요.

그런데 GPL v3의 한국어 번역은 아직 나오지 않은 걸까요?
----
$PWD `date`

$PWD `date`

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.