diff options
Diffstat (limited to 'talermerchantdemos/blog/articles/ko/x.html')
| -rw-r--r-- | talermerchantdemos/blog/articles/ko/x.html | 194 |
1 files changed, 194 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/ko/x.html b/talermerchantdemos/blog/articles/ko/x.html new file mode 100644 index 0000000..91ddd5a --- /dev/null +++ b/talermerchantdemos/blog/articles/ko/x.html @@ -0,0 +1,194 @@ +<!--#set var="ENGLISH_PAGE" value="/philosophy/x.en.html" --> + +<!--#include virtual="/server/header.ko.html" --> +<!-- Parent-Version: 1.77 --> + +<!-- This file is automatically generated by GNUnited Nations! --> +<title>X 윈도우 시스템의 함정 - GNU 프로젝트 - 자유 소프트웨어 재단</title> +<meta http-equiv="Keywords" + content="GNU, FSF, 자유 소프트웨어 재단, 자유, 리처드 스톨먼, rms, 자유 소프트웨어 운동" /> +<meta http-equiv="Description" + content="리처들 스톨만은 자유 운영체제를 개발하기 위한 운동의 역사를 논합니다. " /> + +<!--#include virtual="/philosophy/po/x.translist" --> +<!--#include virtual="/server/banner.ko.html" --> +<div class="reduced-width"> +<h2>X 윈도우 시스템의 함정</h2> + +<address class="byline">글: 리처드 스톨먼</address> +<hr class="thin" /> +<div class="article"> +<p> +카피레프트를 사용할 것인가, 사용하지 않을 것인가? 그것은 자유 소프트웨어 공동체에서 벌어지는 주된 논쟁 중 하나입니다. 카피레프트의 +개념은 불을 끄기 위해 불을 사용하는 것처럼 우리의 코드를 자유롭게 하기 위해서 카피라이트를 사용해야 한다는 것입니다. GNU GPL은 +카피레프트 라이선스의 한가지 예가 될 수 있습니다. </p> + +<p> +일부 자유 소프트웨어 개발자들은 비 카피레프트 배포 방식을 선호합니다. XFree86과 <a +href="/philosophy/bsd.html">BSD 라이선스</a>와 같은 비 카피레프트 라이선스는 어떤 사람이 여러분의 저작물을 +다른 사람에게 제약을 가하는 용도로 활용할 지라도 배포에 제한을 두어서는 안된다는 생각에 바탕을 두고 있습니다. 비 카피레프트 라이선스가 +잘못된 것은 아니지만, 거기에는 소프트웨어를 고치고 재배포할 수 있는 자유를 적극적으로 보호할 수 있는 조건이 빠져 있습니다. 그래서 +우리에게는 카피레프트가 필요합니다.</p> + +<p> +오랜 시간동안 X 컨소시움은 카피레프트의 주된 경쟁자였습니다. 그들은 자유소프트웨어 개발자들이 그들의 프로그램에 카피레프트를 사용하는것을 +그만두도록 도덕적인 회유와 압력을 가했습니다. 거절하는 것은 좋지 않을 것이라는 이야기로 도덕적인 회유를 했으며, 카피레프트 소프트웨어는 +X 윈도우와 함께 배포될 수 없다는 그들의 규정으로 압력을 가했습니다. </p> + +<p> +왜 X 컨소시움은 이런 정책을 채택했을까요? 그것은 성공에 대한 그들의 개념과 관련이 있습니다. X 컨소시움은 인기, 특히 X 윈도우 +시스템을 사용하는 컴퓨터 기업들로부터 인기를 얻는 것을 성공이라고 정의했습니다. 이러한 정의로 인해서 컴퓨터 기업들은 상황을 주도할 수 +있는 위치에 서게 되었습니다. 그들이 원하는 무엇이든지 X 컨소시움은 그들에게 도움을 주었습니다. </p> + +<p> +일반적으로 컴퓨터 기업들은 독점 소프트웨어를 배포합니다. 그들은 자유 소프트웨어 개발자들의 작업 결과를 그들의 작업에 활용하려고 +합니다. 만약 직접적으로 이런 것을 요청한다면 대중들은 비웃을 것입니다. 그러나 X 컨소시움이 그들의 전면에 나서게 된다면, 그런 요청이 +이기적이지 않은 모습으로 보이게 될 것입니다. 그들은 “독점 소프트웨어 개발자들의 작업에 도움을 주기 위해서 우리 작업에 +동참해 달라.”며 그것이 자기 희생의 고귀한 형태라고 제안합니다. 또한 “인기를 얻기 위해 우리와 함께 +하자.”고 제안합니다.</p> + +<p> +하지만 자기 희생은 문제의 중점이 될 수 없습니다. 공동체 전체의 자유를 보호하는 카피레프트라는 방어벽을 벗어나는 것은 자기 희생보다 더 +큰 희생입니다. X 컨소시움의 요청을 받아들이는 사람들은 공동체의 미래를 X 컨소시움이 바라는 방향에 맡기는 것입니다. </p> + +<p> +이것은 잘못된 것입니다. X 컨소시움이 활동하던 마지막 해에 X 컨소시움은 자유 소프트웨어가 아닌 형태로 X11R6.4를 발표할 계획을 +세운 적이 있었습니다. 그것은 독점 소프트웨어 개발자 뿐만 아니라 자유 소프트웨어 공동체 역시 배척하겠다는 결정이었습니다. </p> + +<p> +역설적인 상황이 아닐 수 없습니다. 만약 X 컨소시움이 여러분에게 카피레프트를 사용하지 말라는 제안을 했을 때 긍정적인 답변을 한다면, +X 컨소시움은 X의 핵심 코드와 여러분이 만든 프로그램을 함께 배포할 때 사용상의 제한을 가할 수 있는 권리를 갖게 됩니다. </p> + +<p> +X 컨소시움은 이러한 계획을 실행하지 못했습니다. 그 대신 X의 개발을 오픈 그룹으로 이관하면서 해체되기는 했지만, 오픈 그룹 운영진들은 +X 컨소시움과 유사한 방침을 유지했습니다. 그들에게 영예를 주기 위해서 그들이 계획했던 제한적인 라이선스와 GNU GPL을 같이 병용해서 +X11R6.4를 발표하자고 제안했을 때, 그들은 기꺼이 그 제안에 대해 고려해 보겠다고 했습니다.(그들은 확실히 X11의 예전 배포 +규정에서 벗어나기를 원했습니다.) 그러나 그들이 이 제안에 대해서 긍정이나 부정의 대답을 하기도 전에 그것은 다른 이유로 인해서 무산되어 +가고 있었습니다. 다름아닌 XFree86 그룹이 예전의 X 컨소시움의 정책을 따라 카피레프트 소프트웨어를 받아들이지 않기로 결정한 +것입니다. +</p> + +<p> +1998년 9월에 X11R6.4는 자유 소프트웨어가 아닌 형태로 발표되었습니다. 몇 달 후 오픈 그룹은 그들의 결정에 반대하였고 +X11R6.4는 X11R6.3에서 사용된 비 카피레프트인 자유 소프트에어 라이선스로 다시 배포되었습니다. 결국 오픈 그룹이 올바른 일을 +한 것이기는 하지만 이것이 일반적인 문제점을 바꾸지는 못했습니다.</p> + +<p> +비록 X 컨소시움과 오픈 그룹이 X를 제한하려고 계획하지 않았다 하더라도, 다른 누군가가 그렇게 했을 것입니다. 비 카피레프트 +소프트웨어들은 여러가지로 위험합니다. 만약 어떤 사람이 독점적인 코드를 사용하여 중요한 기능을 추가시키기 위해 충분한 노력을 한다면 비 +자유 버전을 만들 수 있습니다. 자유로움 보다는 기술적인 특징에 의해 소프트웨어를 고르는 사용자들은 단기적인 편의성에 의해 비 자유 +버전에 쉽게 끌리게 될 수 있습니다. </p> + +<p> +X 컨소시움과 오픈 그룹은 더 이상 거절하는 것은 좋지 않을 것이라는 이야기로 도덕적인 회류를 할수 없게 되었습니다. 이로 인해 여러분은 +X와 연관된 소프트웨어에 카피레프트를 적용하는 것을 더 쉽게 결정지을 수 있게 되었습니다. </p> + +<p> +여러분이 X 서버나 Xlib, Xt와 같은 X의 핵심 부분에 대한 일을 하고 있다면 그것은 카피레프트를 사용하지 못하는 분명한 이유가 +됩니다. X.org 그룹은 그런 프로그램들을 유지하기 위해 중요한 역할을 하고 있습니다. 그리고 이러한 프로그램에 카피레프트를 적용하게 +됨으로써 얻어지는 이익은 개발이 분리(fork)되는 것에 의한 피해보다는 적을 것입니다. 따라서 X.org 그룹과 일을 하는 것이 더 +좋을 수도 있고, <code>xset</code>과 <code>xrdb</code>와 같은 X 코어에 가까운 유틸리티나 큰 개선이 +필요하지 않은 프로그램에서 카피레프트를 적용하지 않을 수도 있습니다. 적어도 우리는 X.org 그룹이 이 프로그램들을 자유 소프트웨어로 +개발할 확실한 의무를 가지고 있는 것을 알고 있습니다.</p> + +<p> +그러나 윈도우 매니저나 부가적인 라이브러리와 애플리케이션 프로그램들과 같은 X 코어의 바깥에 있는 프로그램에서는 문제가 다릅니다. 이들 +프로그램에서는 카피레프트를 사용하지 않을 이유가 없으므로 우리는 카피레프트를 적용해야 할 것입니다. </p> + +<p> +누구든지 X 배포판에 포함되어있는 규정 때문에 압력받고 있다고 느낀다면, GNU 프로젝트는 X에서 동작하는 카피레프트 패키지들을 공표하는 +일을 맡게 될 것입니다. 만약 여러분이 어떤 것에 카피레프트를 적용하기를 원하지만 X 배포판에서 빠지게 되어 인기를 얻지 못하는 것이 +두려워 진다면 우리에게 도움을 청하십시요. </p> + +<p> +동시에 인기에 너무 연연해 할 필요가 없습니다. 사업가가 여러분을 “많은 인기”로 유혹할 때, 그는 여러분에게 +여러분의 프로그램을 사용하는 것이 성공에 필수적인 것이라고 확신시키고 싶어 합니다. 믿지 마십시오. 만약에 여러분의 프로그램이 좋다면, +그것은 많은 사람들이 이용할 것입니다. 특정 사용자에 집착할 필요가 없습니다. 그리고 여러분이 그렇게 하지 않는다면 여러분은 더욱 강해질 +것입니다. 여러분은 “다른 사람이 사용하던지 사용하지 않던지, 나랑 상관없는 일이야”와 같은 반응에 의해서 표현할 +수 없는 즐거움과 자유로움을 얻을 수 있습니다. 여러분이 사업가들의 허풍에 연연하지 않고 담대하게 나갈 때, 그들은 방향을 바꾸어 +카피레프트를 받아들일 것입니다. </p> + +<p> +여러분, 자유 소프트웨어 개발자 여러분. 실수를 반복하지 맙시다. 우리가 카피레프트를 우리의 소프트웨어에 적용하지 않는다면, 미래에는 +소프트웨어를 사용하기 위해서 양심 보다는 소프트웨어와 관련된 자산을 더 많이 가진 사람의 자비심에 호소해야 합니다. 카피레프트를 +사용함으로써 우리는 우리 자신은 물론, 공동체 전체의 자유를 지킬 수 있습니다. </p> +</div> +</div> +<div class="translators-notes"> + +<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.--> + </div> +</div> + +<!-- for id="content", starts in the include above --> +<!--#include virtual="/server/footer.ko.html" --> +<div id="footer"> +<div class="unprintable"> + +<p>FSF와 GNU에 대한 문의는 <a href="mailto:gnu@gnu.org"><gnu@gnu.org></a> 앞으로 보내 +주세요. FSF에 대한 <a href="/contact/">다른 연락 방법</a>도 있습니다. 끊어진 링크나 다른 수정 사항 또는 제안은 +<a href="mailto:webmasters@gnu.org"><webmasters@gnu.org></a> 앞으로 보내 +주세요.</p> + +<p> +<!-- TRANSLATORS: Ignore the original text in this paragraph, + replace it with the translation of these two: + + We work hard and do our best to provide accurate, good quality + translations. However, we are not exempt from imperfection. + Please send your comments and general suggestions in this regard + to <a href="mailto:web-translators@gnu.org"> + + <web-translators@gnu.org></a>.</p> + + <p>For information on coordinating and submitting translations of + our web pages, see <a + href="/server/standards/README.translations.html">Translations + README</a>. --> +이 글의 다른 언어 번역문 작성이나 제출에 대한 정보는 <a +href="/server/standards/README.translations.html">번역 안내</a>를 참고해 주세요.</p> +</div> + +<!-- Regarding copyright, in general, standalone pages (as opposed to + files generated as part of manuals) on the GNU web server should + be under CC BY-ND 4.0. Please do NOT change or remove this + without talking with the webmasters or licensing team first. + Please make sure the copyright date is consistent with the + document. For web pages, it is ok to list just the latest year the + document was modified, or published. + + If you wish to list earlier years, that is ok too. + Either "2001, 2002, 2003" or "2001-2003" are ok for specifying + years, as long as each year in the range is in fact a copyrightable + year, i.e., a year in which the document was published (including + being publicly visible on the web or in a revision control system). + + There is more detail about copyright years in the GNU Maintainers + Information document, www.gnu.org/prep/maintain. --> +<p>Copyright © 1998, 1999, 2009, 2015, 2020 Richard M. Stallman</p> + +<p>이 페이지는 <a rel="license" +href="http://creativecommons.org/licenses/by-nd/4.0/deed.ko">크리에이티브 커먼스 +저작자표시-변경금지 4.0 국제 이용허락서</a>에 따라 이용할 수 있습니다.</p> + +<!--#include virtual="/server/bottom-notes.ko.html" --> +<div class="translators-credits"> + +<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.--> +<b>한국어 번역</b>: 장문수 <a +href="mailto:gravi@postech.ac.kr"><gravi@postech.ac.kr></a>, 2001년 4월 +12일, <b>번역 확인 및 교정</b>: 차지호 <a +href="mailto:dreamsyt@hananet.net"><dreamsyt@hananet.net></a>, 2001년 +5월 20일</div> + +<p class="unprintable"><!-- timestamp start --> +최종 수정일: + +$Date: 2020/10/06 08:42:13 $ + +<!-- timestamp end --> +</p> +</div> +</div> +</body> +</html> |