Add Korean translations of bsdl-gpl, explaining-bsd, and contributing
articles. Also set the doc.langcode entity to doc.langcode.ko. PR: 205908 Submitted by: Hoyoung Kim <trig4800@gmail.com>
This commit is contained in:
Warren Block
parent
85439b5c27
commit
74a19dc131
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=48033
10 changed files with 5652 additions and 563 deletions
|
|
@ -4,6 +4,8 @@
|
|||
|
||||
SUBDIR =
|
||||
SUBDIR+= bsdl-gpl
|
||||
SUBDIR+= contributing
|
||||
SUBDIR+= explaining-bsd
|
||||
|
||||
DOC_PREFIX?= ${.CURDIR}/../..
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
|
|
|
|||
|
|
@ -1,573 +1,219 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN"
|
||||
"http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd">
|
||||
<!--
|
||||
The FreeBSD Korean Documentation Project
|
||||
|
||||
$FreeBSD$
|
||||
Original Revision: r43184
|
||||
-->
|
||||
|
||||
<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="ko">
|
||||
|
||||
<info>
|
||||
<title>오픈 소스 프로젝트에 BSD 형식의 라이선스를 사용해야 하는
|
||||
이유</title>
|
||||
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN" "http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd">
|
||||
<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="ko_KR">
|
||||
|
||||
<info><title>오픈 소스 프로젝트에 BSD 형식의 라이선스를 사용해야 하는 이유</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<personname>
|
||||
<firstname>Bruce</firstname>
|
||||
<surname>Montague</surname>
|
||||
</personname>
|
||||
<affiliation>
|
||||
<address><email>brucem@alumni.cse.ucsc.edu</email></address>
|
||||
</affiliation>
|
||||
</author>
|
||||
<author><personname><firstname>Bruce</firstname><surname>Montague</surname></personname><affiliation> <address><email>brucem@alumni.cse.ucsc.edu</email>
|
||||
</address> </affiliation></author>
|
||||
</authorgroup>
|
||||
|
||||
<legalnotice xml:id="trademarks" role="trademarks">
|
||||
&tm-attrib.freebsd;
|
||||
&tm-attrib.intel;
|
||||
&tm-attrib.general;
|
||||
<para>FreeBSD는 FreeBSD 재단의 등록 상표입니다.</para>
|
||||
<para>Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, 그리고 Xeon은 미국 및 그 이외의 국가에서 Intel Corporation 혹은 그 자회사의 상표 또는 등록 상표입니다.</para>
|
||||
<para>생산자 및 판매자들이 그들의 제품을 구별하기 위해 사용하는 많은 표기들은 상표권으로 보호받습니다. 이 문서에 그런 표기들이 나타날 때, FreeBSD 프로젝트는 그러한 상표권에 대해 알고 있기 때문에, 해당 표기 뒤에 <quote>™</quote> 또는 <quote>®</quote> 기호를 사용합니다.</para>
|
||||
</legalnotice>
|
||||
|
||||
<pubdate>$FreeBSD$</pubdate>
|
||||
<pubdate xml:lang="en">$FreeBSD$</pubdate>
|
||||
|
||||
<releaseinfo>$FreeBSD$</releaseinfo>
|
||||
<releaseinfo xml:lang="en">$FreeBSD$</releaseinfo>
|
||||
</info>
|
||||
|
||||
<sect1 xml:id="intro">
|
||||
<title>개요</title>
|
||||
|
||||
<para>이 문서는 소프트웨어와 데이터에 BSD 형식의 라이선스를
|
||||
사용해야 하는 이유를 설명합니다; 구체적으로 이 문서는 GPL 대신
|
||||
BSD 형식의 라이선스를 사용할 것을 권장합니다. 이 문서는 또한
|
||||
BSD와 GPL 오픈 소스 라이선스에 대한 소개 및 간단한 요약이기도
|
||||
합니다.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="history">
|
||||
<title>오픈 소스의 아주 간략한 역사</title>
|
||||
|
||||
<para><quote>오픈 소스</quote>라는 용어가 사용되기 오래 전에,
|
||||
소프트웨어는 프로그래머들의 자발적인 공동체에 의해 개발되고
|
||||
자유롭게 주고받아졌습니다. 1950년대 초반을 시작으로, <link
|
||||
xlink:href="http://www.share.org">SHARE</link>와 <link
|
||||
xlink:href="http://www.decus.org">DECUS</link>와 같은 단체들은
|
||||
컴퓨터 하드웨어 회사들이 자사의 제품에 동봉한 소프트웨어의
|
||||
상당수를 개발했습니다. 그 당시 컴퓨터 회사들은 주로 하드웨어
|
||||
사업을 하고 있었습니다; 소프트웨어의 비용을 낮추고 더 많은
|
||||
프로그램들을 사용 가능하도록 제공하는 것은 곧 하드웨어 회사들의
|
||||
경쟁력이 되었습니다.</para>
|
||||
|
||||
<para>이러한 방침은 1960년대에 바뀌었습니다. 1965년에 ADR은
|
||||
하드웨어 제조사와는 독립적으로 라이선스된 최초의 소프트웨어
|
||||
제품을 개발했습니다. ADR은 IBM의 고객들에 의해 개발된 무료 IBM
|
||||
패키지와 경쟁하고 있었습니다. ADR은 1968년에 그들의
|
||||
소프트웨어에 대한 특허를 출원했습니다. 그들의 프로그램이
|
||||
(불법으로) 공유되는 것을 막기 위해, 그들은 그들의 프로그램을
|
||||
(사용하기 위해서는 비용을 지불해야 하는) 임대 형식의 장비에서만
|
||||
제공했습니다. 그럼으로써 ADR은 소프트웨어에 대한 소유권을
|
||||
얻었고, 소프트웨어의 재판매와 재사용을 하지 못하도록 통제할 수
|
||||
있었습니다.</para>
|
||||
|
||||
<para>1969년에 미국 법무부는 IBM이 그들의 하드웨어에 무료
|
||||
소프트웨어를 동봉하여 시장을 독점하려 한 것에 대해 벌금을
|
||||
부과했습니다. 이 소송의 결과로, IBM은 더 이상 그들의 제품에
|
||||
소프트웨어를 동봉하지 않았습니다; 즉, 소프트웨어는 하드웨어와는
|
||||
독립적인 제품이 되었습니다.</para>
|
||||
|
||||
<para>1968년에 Informatics는 최초로 상용 killer-app을 발표하고
|
||||
소프트웨어 제품, 소프트웨어 회사, 그리고 많은 이윤에 대한 개념을
|
||||
빠르게 정착시켜 나갔습니다. Informatics는 현재 컴퓨터 산업의
|
||||
표준과도 같은 영구 라이선스를 개발했습니다. 이 라이선스는
|
||||
소프트웨어의 소유에 대한 권리가 소비자에게 주어지지 않는다는
|
||||
특징이 있습니다.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="unix-license">
|
||||
<title>BSD 라이선스의 관점에서 바라본 유닉스</title>
|
||||
|
||||
<para>원본 유닉스 구현을 소유하고 있던 AT&T는 반독점법에 의해
|
||||
공식적으로 규제를 받고 있었습니다; 그 회사는 합법적으로
|
||||
소프트웨어 제품을 판매할 수 없었습니다. 그러나 학술 기관에 저장
|
||||
매체의 비용만을 받고 소프트웨어를 제공하는 것은
|
||||
가능했습니다.</para>
|
||||
|
||||
<para>OS conference에서 유닉스를 사용 가능하다고 발표한 이후에,
|
||||
대학교들은 그것을 빠르게 채택했습니다. 유닉스는 대단히 저렴한
|
||||
16비트 컴퓨터인 PDP-11에서 작동했고, 시스템 프로그래밍에
|
||||
명백하게 유리한 고급 언어로 작성되어 있었습니다. 이는 대단히
|
||||
유용한 특징이었습니다. DEC PDP-11은 소비자들이 그들만의 운영
|
||||
체제를 작성(그 당시에는 꽤나 보편적인 일이었습니다)하기 쉽도록
|
||||
하드웨어 인터페이스를 공개하고 있었습니다. DEC의 창립자인 Ken
|
||||
Olsen이 했던 말은 유명합니다, <quote>당신이 좋은 하드웨어를
|
||||
가지고 있다면 소프트웨어는 하늘이 내려 준다</quote>.</para>
|
||||
|
||||
<para>유닉스의 개발자인 Ken Thompson은 1975년에 그의 모교인
|
||||
캘리포니아 버클리 대학교(UCB)로 돌아왔고, 커널을 한줄씩
|
||||
가르쳤습니다. 이는 궁극적으로 BSD(Berkeley Standard
|
||||
Distribution)라는 시스템으로 발전했습니다. UCB는 유닉스를
|
||||
32비트로 변환시켰고, 가상 메모리와 TCP/IP 스택(인터넷의 핵심
|
||||
기술)을 구현했습니다. UCB는 BSD를 <quote>BSD
|
||||
라이선스</quote>라고 알려지게 된 규정에 따라 저장 매체의 비용만
|
||||
받고 누구에게나 제공했습니다. 소비자들은 AT&T에서 유닉스를
|
||||
구입했고 UCB에서 BSD 테이프(당시의 저장 매체)를
|
||||
주문했습니다.</para>
|
||||
|
||||
<para>1980년대 중반에 정부의 ATT에 대한 독점 소송은 ATT가 회사의
|
||||
사업부를 분할하는 것으로 끝났습니다. ATT는 여전히 유닉스를
|
||||
소유하고 있었고 이제는 판매도 할 수 있었습니다. ATT는 공격적인
|
||||
라이선스 정책을 추진했으며 오늘날의 주요한 상용 유닉스들은 ATT
|
||||
기반이 되었습니다.</para>
|
||||
|
||||
<para>1990년대 초반에 ATT는 BSD에 관련된 라이선스의 위반으로 UCB에
|
||||
소송을 제기했습니다. UCB는 ATT가 자사의 제품에 BSD의 향상된
|
||||
기능을 아무런 승인이나 대가 지불 없이 포함시킨 것을 발견했고,
|
||||
주로 ATT와 UCB 사이의 기나긴 소송 사건이 잇따라 발생했습니다.
|
||||
이 기간 동안 UCB의 프로그래머들 중 일부는 BSD에 포함된 ATT
|
||||
코드를 모두 다시 작성하는 작업에 착수했습니다. 이 작업의 결과로
|
||||
bsd 4.4-lite라고 불리는 시스템이 만들어졌습니다 (이것은 완전한
|
||||
시스템이 아니었기 때문에 lite라는 표현이 사용되었습니다; 이는
|
||||
6개의 핵심적인 ATT 파일이 빠졌기 때문입니다).</para>
|
||||
|
||||
<para>얼마 후에, Dr. Dobbs의 잡지에 BSD 파생의 386 PC 버전
|
||||
유닉스를 설명하는 긴 글이 수록되었습니다. 이것은 4.4 lite에
|
||||
결손된 6개의 파일들을 BSD 라이선스의 것으로 대체한
|
||||
버전이었습니다. 386BSD라고 이름지어진 이 시스템은 전 UCB
|
||||
프로그래머인 William Jolitz에 의한 것이었습니다. 이것은 오늘날
|
||||
사용되는 PC 호환 BSD들의 기본적인 바탕이 되었습니다.</para>
|
||||
|
||||
<para>1990년대 중반에, Novell이 ATT의 유닉스에 대한 권리를
|
||||
인수했고 (그 당시 비밀이었던) 협정에 의해 소송은 종료되었습니다.
|
||||
UCB는 곧 BSD에 대한 지원을 종료했습니다.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="current-bsdl">
|
||||
<title>FreeBSD 라이선스와 BSD 라이선스의 현재 상황</title>
|
||||
|
||||
<para>지난 몇 년동안 FreeBSD에 적용되어 온 소위 <link
|
||||
xlink:href="http://www.opensource.org/licenses/bsd-license.php">new
|
||||
BSD license</link>는 여러분이 프로그램 또는 그 소스를 가지고
|
||||
무엇이든지 해도 되지만, 아무런 보증도 되지 않으며 저작자 중
|
||||
아무도 책임지지 않음(즉, 여러분은 아무도 고소할 수 없습니다)을
|
||||
나타내는 사실상 하나의 선언입니다. 이 new BSD license는 제품의
|
||||
상용화를 장려하고 있습니다. 어떤 BSD 코드라도 여러분의 코드의
|
||||
사용 가능성 또는 여러분의 미래의 행동에 아무런 제약을 받지 않고
|
||||
판매되거나 상용 제품에 포함될 수 있습니다.</para>
|
||||
|
||||
<para>new BSD 라이선스를 <quote>공공재</quote>와 혼동하지
|
||||
마십시오. 공공재에 속한 대상 역시 모두가 무료로 사용할 수
|
||||
있지만, 그것은 소유자가 없습니다</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="origins-gpl">
|
||||
<title>GPL의 기원</title>
|
||||
|
||||
<para>1980년대 말과 1990년대 초에 유닉스의 미래가 혼란스러웠을
|
||||
동안, 또 다른 주요 라이선스인 GPL이 개발의 결실을
|
||||
맺었습니다.</para>
|
||||
|
||||
<para>Emacs의 개발자인 Richard Stallman이 MIT의 스태프 멤버였을
|
||||
때, 그의 연구실은 시스템을 직접 개발하는 방식에서 상용 제품을
|
||||
사용하는 방식으로 바꾸었습니다. Stallman은 그가 합법적으로
|
||||
시스템을 개선할 수 없다는 사실을 알고 화가 났습니다.
|
||||
(Stallman의 동료들 대다수는 MIT에서 개발하고 라이선스한
|
||||
소프트웨어를 기반으로 하는 두 회사를 창업하기 위해 떠났습니다;
|
||||
이 소프트웨어의 소스 코드에 대한 관점에서 의견의 불일치가 있었던
|
||||
것으로 보입니다). Stallman은 상용 소프트웨어 라이선스에 대한
|
||||
대안을 마련했고 이를 GPL, "GNU Public License"라고
|
||||
이름지었습니다. 그는 또한 <link
|
||||
xlink:href="http://www.fsf.org">Free Software Foundation</link>
|
||||
(FSF)라고 불리는 비영리 단체를 만들었는데, 이는 상용 라이선스에
|
||||
종속적이지 않으면서 관련 소프트웨어를 포함하는 완전한 운영 체제
|
||||
개발을 목표로 했습니다. 이 시스템은 "GNU is Not Unix"라는 뜻의
|
||||
GNU라고 불렸습니다.</para>
|
||||
|
||||
<para>GPL은 표준적인 상용 라이선스의 정반대 역할을 하도록
|
||||
디자인되었습니다. 이 관점에서, GPL 프로그램에 어떤 수정이라도
|
||||
가하면 (사용자에게 소스 코드를 제공하도록 요구하는 방식으로) GPL
|
||||
커뮤니티에 환원해야 하고 GPL 코드를 사용하거나 링크한 프로그램은
|
||||
모두 GPL 라이선스를 사용해야 합니다. GPL은 소프트웨어가 상용
|
||||
제품이 되는 것을 막도록 의도하고 있습니다. GPL 본문의 마지막
|
||||
문단은 다음과 같이 말하고 있습니다:</para>
|
||||
|
||||
<para><quote>General Public License는 여러분의 프로그램을 상용
|
||||
프로그램에 포함시키는 것을 허용하지 않습니다.</quote>[1]</para>
|
||||
|
||||
<para><link
|
||||
xlink:href="http://www.opensource.org/licenses/gpl-license.php">GPL</link>는
|
||||
복잡한 라이선스이기 때문에 GPL을 사용하는 데에는 몇 가지 원칙이
|
||||
있습니다:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>여러분은 소프트웨어를 배포하고, 지원하고, 관련된 문서에
|
||||
대해 필요한 요금을 원하는 만큼 책정할 수 있지만, 소프트웨어
|
||||
그 자체를 판매할 수는 없습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>프로그램을 컴파일하는 데 GPL 코드가 필요하다면, 그
|
||||
프로그램은 GPL을 따라야 합니다. GPL 라이브러리에 정적으로
|
||||
링크된 프로그램도 GPL을 따라야 합니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>GPL은 GPL 소프트웨어 및 연관된 모든 개발품을 사람들이
|
||||
자유롭게 사용할 수 있도록 라이선스할 것을 요구하고
|
||||
있습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>단순히 소프트웨어들을 한데 모아 놓는 것은, 예를 들어
|
||||
여러 프로그램들이 하나의 디스크에 저장되는 경우, GPL
|
||||
프로그램을 비 GPL 프로그램에 포함시키는 것으로 간주되지
|
||||
않습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>프로그램의 출력 결과는 파생 작업으로 간주되지 않습니다.
|
||||
이는 gcc 컴파일러를 법적 문제 없이 상용 환경에 사용할 수
|
||||
있도록 해 줍니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>리눅스 커널이 GPL이기 때문에, 리눅스 커널에 정적으로
|
||||
링크된 코드는 모두 GPL을 따라야 합니다. 동적으로 링크되고
|
||||
로드할 수 있는 커널 모듈을 통해 이 요구사항을 우회할 수
|
||||
있습니다. 이 허용은 회사로 하여금 바이너리 드라이버를
|
||||
배포할 수 있도록 해 주지만, 특정한 버전의 리눅스 커널에서만
|
||||
동작하게 된다는 단점도 있습니다.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>이 복잡성 때문에, 오늘날 리눅스 및 그와 연관된
|
||||
소프트웨어에서는 GPL의 법적 효력이 무시되고 있습니다. 이에 대한
|
||||
장기적인 결과는 불분명합니다.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="origins-lgpl">
|
||||
<title>리눅스와 LGPL의 기원</title>
|
||||
|
||||
<para>상용 유닉스 전쟁이 벌어지는 동안, 리눅스 커널은 PC 유닉스의
|
||||
클론으로 개발되었습니다. Linus Torvalds는 리눅스의 탄생에 대한
|
||||
공로를 GNU C 컴파일러 및 그에 연관된 GNU 도구들에 돌리고
|
||||
있습니다. 그는 리눅스 커널을 GPL로 만들었습니다.</para>
|
||||
|
||||
<para>GPL은 GPL 코드에 정적으로 링크된 모든 코드 역시 GPL을
|
||||
따르도록 요구하고 있다는 사실을 기억해 주십시오. 즉 해당
|
||||
프로그램의 소스 코드가 사용자에게 제공되어야 합니다. 그러나
|
||||
동적 링크는 GPL 위반으로 간주되지 않습니다. 리눅스에서 상용
|
||||
프로그램을 사용하는 경우가 점점 더 많아졌습니다. 이러한
|
||||
프로그램들은 대체로 시스템 라이브러리와 링크되어야 합니다. 이
|
||||
결과로 <link
|
||||
xlink:href="http://www.opensource.org/licenses/lgpl-license.php">LGPL</link>
|
||||
("Library", 나중에 "Lesser"로 다시 명명된, GPL)라고 하는 GPL의
|
||||
수정판이 나타났습니다. LGPL은 상용 코드를 GNU C 라이브러리인
|
||||
glibc와 링크하는 것을 허용합니다. 여러분은 LGPL 라이브러리와
|
||||
동적으로 링크된 코드를 공개해야 할 의무는 없습니다.</para>
|
||||
|
||||
<para>만약 여러분이 임베디드 시스템에서 흔히 요구되는 것처럼
|
||||
프로그램과 glibc를 정적으로 링크하고자 한다면, 해당 프로그램을
|
||||
사유 재산으로 유지할 수는 없습니다. 즉, 소스 코드는 반드시
|
||||
공개되어야 합니다. GPL과 LGPL 모두 해당 코드를 직접 수정한 것은
|
||||
공개하도록 요구하고 있습니다.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="orphaning">
|
||||
<title>오픈 소스 라이선스와 방치 문제</title>
|
||||
|
||||
<para>사유 소프트웨어와 연관된 중요한 문제들 중 하나는
|
||||
<quote>방치</quote>(orphaning)이라고 알려져 있습니다. 이는
|
||||
하나의 이는 하나의 사업 실패나 제품 전략 변경이 피라미드 형태로
|
||||
이에 종속된 많은 시스템과 회사들을 그들이 대처할 수 있는 범위
|
||||
너머의 이유로 망하게 할 때 일어납니다. 수십 년에 걸친 경험은
|
||||
잠깐 성공한 소프트웨어 공급자가 그 소프트웨어를 언제까지나 사용
|
||||
가능하게 해 주지는 않을 것이라는 사실을 보여 주었습니다. 이는
|
||||
현재의 시장 조건과 전략이 빠르게 변화할 수 있기
|
||||
때문입니다.</para>
|
||||
|
||||
<para>GPL은 사유 지적 재산과의 링크를 막음으로써 방치 현상을
|
||||
방지하고자 하고 있습니다.</para>
|
||||
|
||||
<para>BSD 라이선스는 중소기업에게 아무런 법적 의무 또는 비용 없이
|
||||
소프트웨어를 맡겨 놓는 것과 같은 기능을 합니다. 만약 BSD
|
||||
라이선스 프로그램의 개발이 중단되면, 회사는 그에 종속적인
|
||||
프로그램을 단순히 사유 재산을 넘겨받듯 계속 사용할 수 있습니다.
|
||||
보다 나은 상황은 BSD 라이선스의 코드가 비공식 협회에 의해
|
||||
유지되는 것입니다. 이러면 개발 과정이 하나의 회사 또는 제품
|
||||
라인의 생존에 종속적이지 않게 됩니다. 개발 팀이 지속적으로
|
||||
이어지는 것은 단순히 소스 코드를 얻을 수 있는가의 여부보다 훨씬
|
||||
더 중요합니다.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="license-cannot">
|
||||
<title>라이선스가 할 수 없는 일</title>
|
||||
|
||||
<para>어떠한 라이선스도 미래의 소프트웨어 사용 가능성을 보장해
|
||||
주지는 않습니다. 저작권자가 언제든지 저작권의 내용을 바꿀 수
|
||||
있지만, BSD 커뮤니티에서 그러한 시도가 있다면 단순히 소스 코드를
|
||||
fork하게 됩니다.</para>
|
||||
|
||||
<para>GPL은 라이선스를 무효로 하는 것을 명시적으로 금지하고
|
||||
있습니다. 그런데 그것이 실제로 일어났습니다. 회사(Mattel)가
|
||||
GPL 저작권을 인수(cphack)하고, 저작권 전체를 무효화시킨 뒤,
|
||||
법정에 가서, 승소한 경우[2]입니다. 즉, 그들은 합법적으로 해당
|
||||
배포본 전체와 모든 파생물에 대한 저작권을 무효화시켰습니다. 더
|
||||
크고 널리 퍼져 있는 배포폰에 대해서도 이런 일이 일어날 수
|
||||
있는지는 알 수 없습니다; 뿐만 아니라 특정 소프트웨어가 진짜
|
||||
GPL인지에 대한 혼란이 있기도 합니다.</para>
|
||||
|
||||
<para>다른 예시로는, Red Hat이 FSF 컴파일러 또구들의 개발을 인수한
|
||||
기술 회사인 Cygnus를 인수한 경우가 있습니다. Cygnus는 그들이
|
||||
GNU 소프트웨어에 대한 지원을 판매하는 사업 모델을 개발했기
|
||||
때문에 이렇게 할 수 있었습니다. 이는 그들로 하여금 50여 명의
|
||||
엔지니어들을 고용하고 많은 수정을 할 수 있는 우세함을 통해
|
||||
프로그램의 개발 방향을 원하는 대로 할 수 있게 하였습니다.
|
||||
Donald Rosenberg가 언급하기를 "GPL과 같은 라이선스를 사용하는
|
||||
프로젝트들은 누군가 더 나은 코드를 만들어 원 소유자에 비해
|
||||
빠르게 일을 해나가는 방법을 프로젝트를 손에 넣을지도 모른다는
|
||||
지속적인 위협 속에서 살아간다." [3]</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="gpl-advantages">
|
||||
<title>GPL의 장단점</title>
|
||||
|
||||
<para>GPL을 사용하는 흔한 이유 중 하나는 gcc 컴파일러를 수정하거나
|
||||
확장할 때입니다. 이것은 모든 소프트웨어의 비용이 비싼 데 비해
|
||||
결과로 만들어진 컴파일러를 다른 사람이 사용할 가능성이 거의 없는
|
||||
CPU를 개발할 때 특히 적합합니다.</para>
|
||||
|
||||
<para>GPL은 CD를 판매하는 작은 회사들에게도 매력적일 수 있습니다.
|
||||
이윤을 충분히 남기면서도 사용자에게 비싸지 않은 제품을 제공할 수
|
||||
있습니다. GPL은 또한 GPL 지적 재산에 대한 문서 등의 다양한 기술
|
||||
지원을 제공하는 회사들에게도 매력적입니다.</para>
|
||||
|
||||
<para>GPL의 잘 알려지지 않고 의도적이지도 않은 사용은 대기업들이
|
||||
소프트웨어 회사들의 가치를 싸게 평가하는 데 좋다는 것입니다.
|
||||
다시 말해, GPL은 잠재적으로 전체의 경제적 이익을 저해하고
|
||||
독과점에 기여하는 마케팅 무기에 적합합니다.</para>
|
||||
|
||||
<para>GPL은 소프트웨어를 상업화하고 이윤을 창출하고자 하는
|
||||
사람들에게는 현실적인 문제가 될 수 있습니다. 예를 들어, GPL은
|
||||
대학원생이 자신의 연구 결과를 상업화하기 위해 회사를 차리는 것을
|
||||
어렵게 하거나, 해당 학생이 연구 결과를 상업화해줄 것으로
|
||||
기대하는 회사에 입사하는 것을 어렵게 합니다.</para>
|
||||
|
||||
<para>여러 소프트웨어 표준들의 정적 링크 구현을 사용해야 하는
|
||||
사람들에게 GPL은 좋지 못한 라이선스인데, 이는 상용으로 구현된
|
||||
표준의 사용을 막기 때문입니다. 그래서 GPL은 GPL 표준을 사용해야
|
||||
빌드할 수 있는 프로그램의 수를 최소화하고 있습니다. GPL은
|
||||
하나의 상용 제품이 표준이 되는 방식을 막으려는 의도를 가지고
|
||||
있습니다. (리눅스 애플리케이션에는 적용되지 않는데, 이는
|
||||
그것들이 정적 링크 대신 trap-based API를 사용하기
|
||||
때문입니다.)</para>
|
||||
|
||||
<para>GPL은 프로그래머들이 프로그램의 발전에 기여하고, 이들의
|
||||
배포와 지원으로 경쟁하도록 하는 것을 시도하고 있습니다. 이
|
||||
상황은 필요한 많은 코어 시스템 표준에는 현실적이지 않은데, 이는
|
||||
이러한 시스템이 기존의 비 GPL 라이선스 표준으로 상용화되거나
|
||||
그러한 표준과 결합되는 환경에 적용될 수 있기 때문입니다. 실시간
|
||||
시스템들은 대개 정적으로 링크되기 때문에, 많은 임베디드 시스템
|
||||
회사들에게 GPL과 LGPL은 단연코 잠재적 문제점으로
|
||||
여겨집니다.</para>
|
||||
|
||||
<para>GPL은 연구 및 개발 단계에서, 수요에 관계없이, 노력을
|
||||
유지시키기 위한 시도입니다. 이는 더 널리 배포하는 데 알 수 없는
|
||||
비용이 드는 연구자 및 개발자들에게 최대한의 혜택을
|
||||
제공합니다.</para>
|
||||
|
||||
<para>GPL은 연구 결과가 상용 제품으로 변모하는 것을 막기 위해
|
||||
고안되었습니다. 이는 고전적인 기술이 마침내 다다르게 되는
|
||||
종착역과 같으며 이렇게 상용화되는 것을 막는 것은 일반적으로
|
||||
어렵습니다; GPL은 그러한 과정을 봉쇄하도록
|
||||
만들어졌습니다.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="bsd-advantages">
|
||||
<title>BSD의 장점</title>
|
||||
|
||||
<para>BSD 형식의 라이선스는 장기간의 연구 또는 다음과 같은 개발
|
||||
환경이 필요한 프로젝트에 이상적입니다:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>거의 비용이 들지 않는 경우</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>오랜 기간 동안 발전할 경우</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>누구나 법적 제약 없이 최종 결과물을 상용화하는
|
||||
것을 허용하고자 할 경우</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>마지막 조건은 가장 지배적인 조항인데, 이는 Apache 프로젝트가
|
||||
그들의 라이선스에 중점을 둔 사항이기도 합니다:</para>
|
||||
|
||||
<para><quote>This type of license is ideal for promoting the use
|
||||
of a reference body of code that implements a protocol for
|
||||
common service. This is another reason why we choose it for the
|
||||
Apache group - many of us wanted to see HTTP survive and become
|
||||
a true multiparty standard, and would not have minded in the
|
||||
slightest if Microsoft or Netscape choose to incorporate our
|
||||
HTTP engine or any other component of our code into their
|
||||
products, if it helped further the goal of keeping HTTP
|
||||
common... All this means that, strategically speaking, the
|
||||
project needs to maintain sufficient momentum, and that
|
||||
participants realize greater value by contributing their code to
|
||||
the project, even code that would have had value if kept
|
||||
proprietary.</quote></para>
|
||||
|
||||
<para>개발자들은 BSD 라이선스를 선호하는 경향이 있는데, 이는
|
||||
그들이 코드를 다룸에 있어 법적 분쟁으로부터 벗어나 그들이 하고
|
||||
싶은 대로 하도록 허락하기 때문입니다. 반면, 시스템을
|
||||
개발하기보다 주로 사용할 것으로 예상되는 사람들, 혹은 다른
|
||||
사람들이 코드를 개선해 주기를 기대하는 사람들, 혹은 (국가
|
||||
공무원과 같이) 시스템 작업으로 생계를 유지하지는 않는 사람들의
|
||||
경우 GPL을 선호하는데, 이는 다른 사람이 개발한 코드를 자신잉
|
||||
사용할 수 있고 그들의 상관이 저작권을 가지고 있는 일을 막을 수도
|
||||
있으며 결과적으로 잠재적으로 소프트웨어를 "무용지물"로 만들거나
|
||||
방치하지 않도록 할 수 있기 때문입니다. 만약 여러분이 경쟁자로
|
||||
하여금 여러분을 돕도록 강제하고 싶다면, GPL은 매력적인 선택지가
|
||||
될 것입니다.</para>
|
||||
|
||||
<para>BSD 라이선스는 단순한 선물인 것은 아닙니다. <quote>왜
|
||||
우리는 우리의 경쟁자를 돕거나 그들이 우리가 만든 결과물을 훔쳐
|
||||
가도록 내버려 두어야 하나요?</quote>라는 질문은 BSD 라이선스에
|
||||
관련된 질문에서 자주 볼 수 있습니다. BSD 라이선스 하에서, 만약
|
||||
어떤 회사가 제품 시장을 독점하고 다른 이들이 이를 전략적이었다고
|
||||
여길 경우, 다른 회사들은 최소한의 노력만으로 시장 경쟁과
|
||||
공정성을 증대시킬 경쟁 BSD 파생본에 기여하는 작은 협회를 만들 수
|
||||
있습니다. 이는 각 회사들로 하여금 이것이 제공하는 이점으로부터
|
||||
이윤을 창출할 수 있을 것이라는 믿음을 주고, 경제적 유연성과
|
||||
효율성에도 기여할 수 있습니다. 회원들이 더 빠르고 쉽게 이에
|
||||
협력할수록, 더욱 성공적일 것입니다. BSD 라이선스는 그러한
|
||||
행동을 가능하게 해 주면서도 가장 덜 복잡한
|
||||
라이선스입니다.</para>
|
||||
|
||||
<para>완전하고 경쟁력 있는 오픈 소스 시스템을 단지 저장 매체의
|
||||
가격만으로 널리 쓸 수 있게 한다는 GPL의 핵심적인 효과는 합리적인
|
||||
목표입니다. BSD 형식의 라이선스는, 협회 창설을 통한 개인의
|
||||
연합을 통해, 기술 개발 과정에 대한 경제적 기대를 저버리지 않고
|
||||
이 목표를 달성할 수 있습니다.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="recommendations">
|
||||
<title>BSD 라이선스를 사용하면 좋은 경우</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>BSD 라이선스는 연구 결과를 널리 배포하고 경제적 이윤을
|
||||
창출할 수 있도록 하는 데 적합합니다. 그것으로서, NSF, ONR
|
||||
그리고 DARPA와 같은 연구 개발 기관은 자금을 투자받은
|
||||
프로젝트의 초기 단계 연구를 위해 소프트웨어, 데이터, 결과,
|
||||
그리고 오픈 하드웨어에 BSD 형식의 라이선스를 적용할 것을
|
||||
장려해야 합니다. 그들은 또한 오픈 소스 시스템 구현과
|
||||
진행중인 오픈 소스 프로젝트를 기반으로 표준을 정할 것을
|
||||
장려해야 합니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>정부 정책은 비용과 연구 결과를 실무에 적용할 때의
|
||||
어려움을 최소화해야 합니다. 가능하다면, 연구 결과를
|
||||
상용화에 친화적인 BSD 형식의 라이선스로 사용 가능하게 할
|
||||
것을 요구해야 합니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>많은 경우에, 저작권 또는 특허에 의해 상용 대학
|
||||
라이선스에 종속되는 것보다 BSD 형식 라이선스의 형식을 취하는
|
||||
것이 장기적으로 보았을 때 대학의 연구 목표에 더 근접합니다.
|
||||
대학 입장에서는 장기적으로 보았을 때 연구 결과를 공개하고,
|
||||
경제적으로 성공한 졸업생들에 의해 기부받는 것이 금전적으로
|
||||
더 이득이 되는 실제적인 사례들이 존재합니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>회사들은 사실상의 표준을 만든느 것이 마케팅 기술의
|
||||
핵심이 된다는 것을 오랜 경험에 걸쳐 알아왔습니다. 만약
|
||||
회사가 시스템을 발전시키는 데 독특한 강점이 있다면, BSD
|
||||
라이선스는 이 역할을 잘 수행합니다. 라이선스는 회사의 전문
|
||||
기술 덕분에 그들이 통제할 수 있으면서도 많은 사람들에게
|
||||
법적인 관점에서 매력적입니다. 다른 사람들을 방해하거나
|
||||
그들의 것을 빼앗고자 할 목적으로 그러한 표준을 만드는 경우
|
||||
GPL은 적절한 선택이 될 수 있습니다. 그러나 GPL은 상용으로
|
||||
적용 가능한 표준을 지향하지 않고 방해합니다. 그러한 GPL
|
||||
suite를 사용하는 것은 지속적으로 상용화와 법률 상의 문제를
|
||||
발생시킵니다. GPL 표준과 그렇지 않은 것을 함께 활용하는
|
||||
것은 대개 가능하지 않습니다. 진정한 기술 표준은 기술적이지
|
||||
않은 이유 때문에 다른 표준을 배제할 것을 강제해서는 안
|
||||
됩니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>다른 회사들의 상용 제품의 핵심이 될 수 있는 표준을
|
||||
개발하고 장려하는 데 관심이 있는 회사는 GPL에 대해 조심해야
|
||||
합니다. 사용된 라이선스에 관계없이, 결과가 되는
|
||||
소프트웨어는 기술적인 변화의 대부분과 시스템의 상태를 가장
|
||||
잘 아는 사람들에게 맡겨질 것입니다. GPL은 단지 결과에
|
||||
추가적인 법적 제약을 가할 뿐입니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>오픈 소스 코드를 개발하는 큰 회사는 오픈 소스를 옹호하는
|
||||
프로그래머를 조심해야 하는데, 이는 그들이 다른 곳으로 이직할
|
||||
경우에도 여전히 그 소프트웨어를 사용할 수 있기 때문입니다.
|
||||
일부 회사들은, 특히 해당 소프트웨어가 핵심 전략에 직접적으로
|
||||
연관되어 있지 않을 때, 이러한 행동을 직원들의 특권으로써
|
||||
장려합니다. 이는 사실 직접적인 비용 손실 없이 잠재적인 기회
|
||||
비용만을 잃는 퇴직 혜택입니다. 직원을 회사 외부를 위해
|
||||
일하도록 장려하는 것은 종종 회사가 손해 없이 제공할 수 있는
|
||||
간단한 혜택이 되기도 합니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>소프트웨어가 방치될 것이 걱정되는 작은 개발 회사는,
|
||||
가능하다면 BSD 라이선스를 사용하는 것을 고려해볼 필요가
|
||||
있습니다. 회사들은 그 규모에 관계없이 BSD 형식 오픈 소스
|
||||
프로젝트를 구성함으로써 법적인, 그리고 구조적인 간접 비용을
|
||||
최소화하는 상호간의 이익을 도모할 수 있습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>비영리단체들은 가능하다면 오픈 소스 프로젝트에 참여해야
|
||||
합니다. 서로 다른 라이선스의 코드를 함께 사용하는 것과 같은
|
||||
소프트웨어상의 문제를 최소화하기 위해, BSD 형식의 라이선스가
|
||||
장려되어야 합니다. 소프트웨어 개발과 밀접하게 관련있는
|
||||
비영리단체는 GPL을 더욱 경계해야 할 것입니다. 법률을
|
||||
적용하는 일이 많은 비용을 요구하는 일부 지역에서는, GPL에
|
||||
비해 단순한 BSD 라이선스가 고려해볼 만한 이점이 될
|
||||
것입니다.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="conclusion">
|
||||
<title>맺음말</title>
|
||||
|
||||
<para>오픈 소스 코드의 상용화를 막기 위해 만들어진 GPL과는 달리,
|
||||
BSD 라이선스는 미래의 행동에 최소한의 제약만을 가합니다. 이는
|
||||
프로젝트나 회사의 필요에 따라 BSD 코드를 오픈 소스로 유지하거나
|
||||
상용 솔루션에 사용될 수 있도록 허락합니다. 다시 말해서, BSD
|
||||
라이선스는 개발 과정에서 법적인 시한 폭탄이 되지
|
||||
않습니다.</para>
|
||||
|
||||
<para>더불어 BSD 라이선스는, GPL이나 LGPL 라이선스와는 달리 복잡한
|
||||
법적 의무가 주어지지 않기 때문에, 개발자와 회사가 라이선스 위반
|
||||
여부에 대해 걱정하는 대신 좋은 코드를 작성하고 홍보하는 데
|
||||
집중할 수 있도록 해 줍니다.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="addenda">
|
||||
<title>Addenda</title>
|
||||
|
||||
<programlisting>[1] http://www.gnu.org/licenses/gpl.html
|
||||
<sect1 xml:id="intro">
|
||||
<title>개요</title>
|
||||
|
||||
<para>이 문서는 소프트웨어와 데이터에 BSD 형식의 라이선스를 사용해야 하는 이유를 설명합니다; 구체적으로 이 문서는 GPL 대신 BSD 형식의 라이선스를 사용할 것을 권장합니다. 이 문서는 또한 BSD와 GPL 오픈 소스 라이선스에 대한 소개 및 간단한 요약이기도 합니다.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="history">
|
||||
<title>오픈 소스의 아주 간략한 역사</title>
|
||||
|
||||
<para><quote>오픈 소스</quote>라는 용어가 사용되기 오래 전에, 소프트웨어는 프로그래머들의 자발적인 공동체에 의해 개발되고 자유롭게 주고받아졌습니다. 1950년대 초반을 시작으로, <link xlink:href="http://www.share.org">SHARE</link>와 <link xlink:href="http://www.decus.org">DECUS</link>와 같은 단체들은 컴퓨터 하드웨어 회사들이 자사의 제품에 동봉한 소프트웨어의 상당수를 개발했습니다. 그 당시 컴퓨터 회사들은 주로 하드웨어 사업을 하고 있었습니다; 소프트웨어의 비용을 낮추고 더 많은 프로그램들을 사용 가능하도록 제공하는 것은 곧 하드웨어 회사들의 경쟁력이 되었습니다.</para>
|
||||
|
||||
<para>이러한 방침은 1960년대에 바뀌었습니다. 1965년에 ADR은 하드웨어 제조사와는 독립적으로 라이선스된 최초의 소프트웨어 제품을 개발했습니다. ADR은 IBM의 고객들에 의해 개발된 무료 IBM 패키지와 경쟁하고 있었습니다. ADR은 1968년에 그들의 소프트웨어에 대한 특허를 출원했습니다. 그들의 프로그램이 (불법으로) 공유되는 것을 막기 위해, 그들은 그들의 프로그램을 (사용하기 위해서는 비용을 지불해야 하는) 임대 형식의 장비에서만 제공했습니다. 그럼으로써 ADR은 소프트웨어에 대한 소유권을 얻었고, 소프트웨어의 재판매와 재사용을 하지 못하도록 통제할 수 있었습니다.</para>
|
||||
|
||||
<para>1969년에 미국 법무부는 IBM이 그들의 하드웨어에 무료 소프트웨어를 동봉하여 시장을 독점하려 한 것에 대해 벌금을 부과했습니다. 이 소송의 결과로, IBM은 더 이상 그들의 제품에 소프트웨어를 동봉하지 않았습니다; 즉, 소프트웨어는 하드웨어와는 독립적인 제품이 되었습니다.</para>
|
||||
|
||||
<para>1968년에 Informatics는 최초로 상용 killer-app을 발표하고 소프트웨어 제품, 소프트웨어 회사, 그리고 많은 이윤에 대한 개념을 빠르게 정착시켜 나갔습니다. Informatics는 현재 컴퓨터 산업의 표준과도 같은 영구 라이선스를 개발했습니다. 이 라이선스는 소프트웨어의 소유에 대한 권리가 소비자에게 주어지지 않는다는 특징이 있습니다.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="unix-license">
|
||||
<title>BSD 라이선스의 관점에서 바라본 유닉스</title>
|
||||
|
||||
<para>원본 유닉스 구현을 소유하고 있던 AT&T는 반독점법에 의해 공식적으로 규제를 받고 있었습니다; 그 회사는 합법적으로 소프트웨어 제품을 판매할 수 없었습니다. 그러나 학술 기관에 저장 매체의 비용만을 받고 소프트웨어를 제공하는 것은 가능했습니다.</para>
|
||||
|
||||
<para>OS conference에서 유닉스를 사용 가능하다고 발표한 이후에, 대학교들은 그것을 빠르게 채택했습니다. 유닉스는 대단히 저렴한 16비트 컴퓨터인 PDP-11에서 작동했고, 시스템 프로그래밍에 명백하게 유리한 고급 언어로 작성되어 있었습니다. 이는 대단히 유용한 특징이었습니다. DEC PDP-11은 소비자들이 그들만의 운영체제를 작성(그 당시에는 꽤나 보편적인 일이었습니다)하기 쉽도록 하드웨어 인터페이스를 공개하고 있었습니다. DEC의 창립자인 Ken Olsen이 했던 말은 유명합니다, <quote>당신이 좋은 하드웨어를 가지고 있다면 소프트웨어는 하늘이 내려 준다</quote>.</para>
|
||||
|
||||
<para>유닉스의 개발자인 Ken Thompson은 1975년에 그의 모교인 캘리포니아 버클리 대학교(UCB)로 돌아왔고, 커널을 한줄씩 가르쳤습니다. 이는 궁극적으로 BSD(Berkeley Standard Distribution)라는 시스템으로 발전했습니다. UCB는 유닉스를 32비트로 변환시켰고, 가상 메모리와 TCP/IP 스택(인터넷의 핵심 기술)을 구현했습니다. UCB는 BSD를 <quote>BSD 라이선스</quote>라고 알려지게 된 규정에 따라 저장 매체의 비용만 받고 누구에게나 제공했습니다. 소비자들은 AT&T에서 유닉스를 구입했고 UCB에서 BSD 테이프(당시의 저장 매체)를 주문했습니다.</para>
|
||||
|
||||
<para>1980년대 중반에 정부의 ATT에 대한 독점 소송은 ATT가 회사의 사업부를 분할하는 것으로 끝났습니다. ATT는 여전히 유닉스를 소유하고 있었고 이제는 판매도 할 수 있었습니다. ATT는 공격적인 라이선스 정책을 추진했으며 오늘날의 주요한 상용 유닉스들은 ATT 기반이 되었습니다.</para>
|
||||
|
||||
<para>1990년대 초반에 ATT는 BSD에 관련된 라이선스의 위반으로 UCB에 소송을 제기했습니다. UCB는 ATT가 자사의 제품에 BSD의 향상된 기능을 아무런 승인이나 대가 지불 없이 포함시킨 것을 발견했고, 주로 ATT와 UCB 사이의 기나긴 소송 사건이 잇따라 발생했습니다. 이 기간 동안 UCB의 프로그래머들 중 일부는 BSD에 포함된 ATT 코드를 모두 다시 작성하는 작업에 착수했습니다. 이 작업의 결과로 bsd 4.4-lite라고 불리는 시스템이 만들어졌습니다 (이것은 완전한 시스템이 아니었기 때문에 lite라는 표현이 사용되었습니다; 이는 6개의 핵심적인 ATT 파일이 빠졌기 때문입니다).</para>
|
||||
|
||||
<para>얼마 후에, Dr. Dobbs의 잡지에 BSD 파생의 386 PC 버전 유닉스를 설명하는 긴 글이 수록되었습니다. 이것은 4.4 lite에 결손된 6개의 파일들을 BSD 라이선스의 것으로 대체한 버전이었습니다. 386BSD라고 이름지어진 이 시스템은 전 UCB 프로그래머인 William Jolitz에 의한 것이었습니다. 이것은 오늘날 사용되는 PC 호환 BSD들의 기본적인 바탕이 되었습니다.</para>
|
||||
|
||||
<para>1990년대 중반에, Novell이 ATT의 유닉스에 대한 권리를 인수했고 (그 당시 비밀이었던) 협정에 의해 소송은 종료되었습니다. UCB는 곧 BSD에 대한 지원을 종료했습니다.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="current-bsdl">
|
||||
<title>FreeBSD 라이선스와 BSD 라이선스의 현재 상황</title>
|
||||
|
||||
<para>지난 몇 년동안 FreeBSD에 적용되어 온 소위 <link xlink:href="http://www.opensource.org/licenses/bsd-license.php">new BSD license</link>는 여러분이 프로그램 또는 그 소스를 가지고 무엇이든지 해도 되지만, 아무런 보증도 되지 않으며 저작자 중 아무도 책임지지 않음(즉, 여러분은 아무도 고소할 수 없습니다)을 나타내는 사실상 하나의 선언입니다. 이 new BSD license는 제품의 상용화를 장려하고 있습니다. 어떤 BSD 코드라도 여러분의 코드의 사용 가능성 또는 여러분의 미래의 행동에 아무런 제약을 받지 않고 판매되거나 상용 제품에 포함될 수 있습니다.</para>
|
||||
|
||||
<para>new BSD 라이선스를 <quote>공공재</quote>와 혼동하지 마십시오. 공공재에 속한 대상 역시 모두가 무료로 사용할 수 있지만, 그것은 소유자가 없습니다.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="origins-gpl">
|
||||
<title>GPL의 기원</title>
|
||||
|
||||
<para>1980년대 말과 1990년대 초에 유닉스의 미래가 혼란스러웠을 동안, 또 다른 주요 라이선스인 GPL이 개발의 결실을 맺었습니다.</para>
|
||||
|
||||
<para>Emacs의 개발자인 Richard Stallman이 MIT의 스태프 멤버였을 때, 그의 연구실은 시스템을 직접 개발하는 방식에서 상용 제품을 사용하는 방식으로 바꾸었습니다. Stallman은 그가 합법적으로 시스템을 개선할 수 없다는 사실을 알고 화가 났습니다. (Stallman의 동료들 대다수는 MIT에서 개발하고 라이선스한 소프트웨어를 기반으로 하는 두 회사를 창업하기 위해 떠났습니다; 이 소프트웨어의 소스 코드에 대한 관점에서 의견의 불일치가 있었던 것으로 보입니다). Stallman은 상용 소프트웨어 라이선스에 대한 대안을 마련했고 이를 GPL, "GNU Public License"라고 이름지었습니다. 그는 또한 <link xlink:href="http://www.fsf.org">Free Software Foundation</link> (FSF)라고 불리는 비영리 단체를 만들었는데, 이는 상용 라이선스에 종속적이지 않으면서 관련 소프트웨어를 포함하는 완전한 운영 체제 개발을 목표로 했습니다. 이 시스템은 "GNU is Not Unix"라는 뜻의 GNU라고 불렸습니다.</para>
|
||||
|
||||
<para>GPL은 표준적인 상용 라이선스의 정반대 역할을 하도록 디자인되었습니다. 이 관점에서, GPL 프로그램에 어떤 수정이라도 가하면 (사용자에게 소스 코드를 제공하도록 요구하는 방식으로) GPL 커뮤니티에 환원해야 하고 GPL 코드를 사용하거나 링크한 프로그램은 모두 GPL 라이선스를 사용해야 합니다. GPL은 소프트웨어가 상용 제품이 되는 것을 막도록 의도하고 있습니다. GPL 본문의 마지막 문단은 다음과 같이 말하고 있습니다:</para>
|
||||
|
||||
<para><quote>General Public License는 여러분의 프로그램을 상용 프로그램에 포함시키는 것을 허용하지 않습니다.</quote>[1]</para>
|
||||
|
||||
<para><link xlink:href="http://www.opensource.org/licenses/gpl-license.php">GPL</link>는 복잡한 라이선스이기 때문에 GPL을 사용하는 데에는 몇 가지 원칙이 있습니다:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para>여러분은 소프트웨어를 배포하고, 지원하고, 관련된 문서에 대해 필요한 요금을 원하는 만큼 책정할 수 있지만, 소프트웨어 그 자체를 판매할 수는 없습니다.</para></listitem>
|
||||
|
||||
<listitem><para>프로그램을 컴파일하는 데 GPL 코드가 필요하다면, 그 프로그램은 GPL을 따라야 합니다. GPL 라이브러리에 정적으로 링크된 프로그램도 GPL을 따라야 합니다.</para></listitem>
|
||||
|
||||
<listitem><para>GPL은 GPL 소프트웨어 및 연관된 모든 개발품을 누구든지 자유롭게 사용할 수 있도록 라이선스할 것을 요구하고 있습니다.</para></listitem>
|
||||
|
||||
<listitem><para>단순히 소프트웨어들을 한데 모아 놓는 것은, 예를 들어 여러 프로그램들이 하나의 디스크에 저장되는 경우, GPL 프로그램을 비 GPL 프로그램에 포함시키는 것으로 간주되지 않습니다.</para></listitem>
|
||||
|
||||
<listitem><para>프로그램의 출력 결과는 파생 작업으로 간주되지 않습니다. 이는 gcc 컴파일러를 법적 문제 없이 상용 환경에 사용할 수 있도록 해 줍니다.</para></listitem>
|
||||
|
||||
<listitem><para>리눅스 커널이 GPL이기 때문에, 리눅스 커널에 정적으로 링크된 코드는 모두 GPL을 따라야 합니다. 동적으로 링크되고 로드할 수 있는 커널 모듈을 통해 이 요구사항을 우회할 수 있습니다. 이 허용은 회사로 하여금 바이너리 드라이버를 배포할 수 있도록 해 주지만, 특정한 버전의 리눅스 커널에서만 동작하게 된다는 단점도 있습니다.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>이 복잡성 때문에, 오늘날 리눅스 및 그와 연관된 소프트웨어에서는 GPL의 법적 효력이 무시되고 있습니다. 이에 대한 장기적인 결과는 불분명합니다.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="origins-lgpl">
|
||||
<title>리눅스와 LGPL의 기원</title>
|
||||
|
||||
<para>상용 유닉스 전쟁이 벌어지는 동안, 리눅스 커널은 PC 유닉스의 클론으로 개발되었습니다. Linus Torvalds는 리눅스의 탄생에 대한 공로를 GNU C 컴파일러 및 그에 연관된 GNU 도구들에 돌리고 있습니다. 그는 리눅스 커널을 GPL로 만들었습니다.</para>
|
||||
|
||||
<para>GPL은 GPL 코드에 정적으로 링크된 모든 코드 역시 GPL을 따르도록 요구하고 있다는 사실을 기억해 주십시오. 즉 해당 프로그램의 소스 코드가 사용자에게 제공되어야 합니다. 그러나 동적 링크는 GPL 위반으로 간주되지 않습니다. 리눅스에서 상용 프로그램을 사용하는 경우가 점점 더 많아졌습니다. 이러한 프로그램들은 대체로 시스템 라이브러리와 링크되어야 합니다. 이 결과로 <link xlink:href="http://www.opensource.org/licenses/lgpl-license.php">LGPL</link> ("Library", 나중에 "Lesser"로 다시 명명된, GPL)라고 하는 GPL의 수정판이 나타났습니다. LGPL은 상용 코드를 GNU C 라이브러리인 glibc와 링크하는 것을 허용합니다. 여러분은 LGPL 라이브러리와 동적으로 링크된 코드를 공개해야 할 의무는 없습니다.</para>
|
||||
|
||||
<para>만약 여러분이 임베디드 시스템에서 흔히 요구되는 것처럼 프로그램과 glibc를 정적으로 링크하고자 한다면, 해당 프로그램을 사유 재산으로 유지할 수는 없습니다. 즉, 소스 코드는 반드시 공개되어야 합니다. GPL과 LGPL 모두 해당 코드를 직접 수정한 것은 공개하도록 요구하고 있습니다.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="orphaning">
|
||||
<title>오픈 소스 라이선스와 방치 문제</title>
|
||||
|
||||
<para>사유 소프트웨어와 연관된 중요한 문제들 중 하나는 <quote>방치</quote>(orphaning)이라고 알려져 있습니다. 이는 하나의 이는 하나의 사업 실패나 제품 전략 변경이 피라미드 형태로 이에 종속된 많은 시스템과 회사들을 그들이 대처할 수 있는 범위 너머의 이유로 망하게 할 때 일어납니다. 수십 년에 걸친 경험은 잠깐 성공한 소프트웨어 공급자가 그 소프트웨어를 언제까지나 사용 가능하게 해 주지는 않을 것이라는 사실을 보여 주었습니다. 이는 현재의 시장 조건과 전략이 빠르게 변화할 수 있기 때문입니다.</para>
|
||||
|
||||
<para>GPL은 사유 지적 재산과의 링크를 막음으로써 방치 현상을 방지하고자 하고 있습니다.</para>
|
||||
|
||||
<para>BSD 라이선스는 중소기업에게 아무런 법적 의무 또는 비용 없이 소프트웨어를 맡겨 놓는 것과 같은 기능을 합니다. 만약 BSD 라이선스 프로그램의 개발이 중단되면, 회사는 그에 종속적인 프로그램을 단순히 사유 재산을 넘겨받듯 계속 사용할 수 있습니다. 보다 나은 상황은 BSD 라이선스의 코드가 비공식 협회에 의해 유지되는 것입니다. 이러면 개발 과정이 하나의 회사 또는 제품 라인의 생존에 종속적이지 않게 됩니다. 개발 팀이 지속적으로 이어지는 것은 단순히 소스 코드를 얻을 수 있는가의 여부보다 훨씬 더 중요합니다.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="license-cannot">
|
||||
<title>라이선스가 할 수 없는 일</title>
|
||||
|
||||
<para>어떠한 라이선스도 미래의 소프트웨어 사용 가능성을 보장해 주지는 않습니다. 저작권자가 언제든지 저작권의 내용을 바꿀 수 있지만, BSD 커뮤니티에서 그러한 시도가 있다면 단순히 소스 코드를 fork하게 됩니다.</para>
|
||||
|
||||
<para>GPL은 라이선스를 무효로 하는 것을 명시적으로 금지하고 있습니다. 그런데 그것이 실제로 일어났습니다. 회사(Mattel)가 GPL 저작권을 인수(cphack)하고, 저작권 전체를 무효화시킨 뒤, 법정에 가서, 승소한 경우[2]입니다. 즉, 그들은 합법적으로 해당 배포본 전체와 모든 파생물에 대한 저작권을 무효화시켰습니다. 더 크고 널리 퍼져 있는 배포폰에 대해서도 이런 일이 일어날 수 있는지는 알 수 없습니다; 뿐만 아니라 특정 소프트웨어가 진짜 GPL인지에 대한 혼란이 있기도 합니다.</para>
|
||||
|
||||
<para>다른 예시로는, Red Hat이 FSF 컴파일러 또구들의 개발을 인수한 기술 회사인 Cygnus를 인수한 경우가 있습니다. Cygnus는 그들이 GNU 소프트웨어에 대한 지원을 판매하는 사업 모델을 개발했기 때문에 이렇게 할 수 있었습니다. 이는 그들로 하여금 50여 명의 엔지니어들을 고용하고 많은 수정을 할 수 있는 우세함을 통해 프로그램의 개발 방향을 원하는 대로 할 수 있게 하였습니다. Donald Rosenberg가 언급하기를 "GPL과 같은 라이선스를 사용하는 프로젝트들은 누군가 더 나은 코드를 만들어 원 소유자에 비해 빠르게 일을 해나가는 방법을 프로젝트를 손에 넣을지도 모른다는 지속적인 위협 속에서 살아간다." [3]</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="gpl-advantages">
|
||||
<title>GPL의 장단점</title>
|
||||
|
||||
<para>GPL을 사용하는 흔한 이유 중 하나는 gcc 컴파일러를 수정하거나 확장할 때입니다. 이것은 모든 소프트웨어의 비용이 비싼 데 비해 결과로 만들어진 컴파일러를 다른 사람이 사용할 가능성이 거의 없는 CPU를 개발할 때 특히 적합합니다.</para>
|
||||
|
||||
<para>GPL은 CD를 판매하는 작은 회사들에게도 매력적일 수 있습니다. 이윤을 충분히 남기면서도 사용자에게 비싸지 않은 제품을 제공할 수 있습니다. GPL은 또한 GPL 지적 재산에 대한 문서 등의 다양한 기술 지원을 제공하는 회사들에게도 매력적입니다.</para>
|
||||
|
||||
<para>GPL의 잘 알려지지 않고 의도적이지도 않은 사용은 대기업들이 소프트웨어 회사들의 가치를 싸게 평가하는 데 좋다는 것입니다. 다시 말해, GPL은 잠재적으로 전체의 경제적 이익을 저해하고 독과점에 기여하는 마케팅 무기에 적합합니다.</para>
|
||||
|
||||
<para>GPL은 소프트웨어를 상업화하고 이윤을 창출하고자 하는 사람들에게는 현실적인 문제가 될 수 있습니다. 예를 들어, GPL은 대학원생이 자신의 연구 결과를 상업화하기 위해 회사를 차리는 것을 어렵게 하거나, 해당 학생이 연구 결과를 상업화해줄 것으로 기대하는 회사에 입사하는 것을 어렵게 합니다.</para>
|
||||
|
||||
<para>여러 소프트웨어 표준들의 정적 링크 구현을 사용해야 하는 사람들에게 GPL은 좋지 못한 라이선스인데, 이는 상용으로 구현된 표준의 사용을 막기 때문입니다. 그래서 GPL은 GPL 표준을 사용해야 빌드할 수 있는 프로그램의 수를 최소화하고 있습니다. GPL은 하나의 상용 제품이 표준이 되는 방식을 막으려는 의도를 가지고 있습니다. (리눅스 애플리케이션에는 적용되지 않는데, 이는 그것들이 정적 링크 대신 trap-based API를 사용하기 때문입니다.)</para>
|
||||
|
||||
<para>GPL은 프로그래머들이 프로그램의 발전에 기여하고, 이들의 배포와 지원으로 경쟁하도록 하는 것을 시도하고 있습니다. 이 상황은 필요한 많은 코어 시스템 표준에는 현실적이지 않은데, 이는 이러한 시스템이 기존의 비 GPL 라이선스 표준으로 상용화되거나 그러한 표준과 결합되는 환경에 적용될 수 있기 때문입니다. 실시간 시스템들은 대개 정적으로 링크되기 때문에, 많은 임베디드 시스템 회사들에게 GPL과 LGPL은 단연코 잠재적 문제점으로 여겨집니다.</para>
|
||||
|
||||
<para>GPL은 연구 및 개발 단계에서, 수요에 관계없이, 노력을 유지시키기 위한 시도입니다. 이는 더 널리 배포하는 데 알 수 없는 비용이 드는 연구자 및 개발자들에게 최대한의 혜택을 제공합니다.</para>
|
||||
|
||||
<para>GPL은 연구 결과가 상용 제품으로 변모하는 것을 막기 위해 고안되었습니다. 이는 고전적인 기술이 마침내 다다르게 되는 종착역과 같으며 이렇게 상용화되는 것을 막는 것은 일반적으로 어렵습니다; GPL은 그러한 과정을 봉쇄하도록 만들어졌습니다.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="bsd-advantages">
|
||||
<title>BSD의 장점</title>
|
||||
|
||||
<para>BSD 형식의 라이선스는 장기간의 연구 또는 다음과 같은 개발 환경이 필요한 프로젝트에 이상적입니다:</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para>거의 비용이 들지 않는 경우</para></listitem>
|
||||
<listitem><para>오랜 기간 동안 발전할 경우</para></listitem>
|
||||
<listitem><para>누구나 법적 제약 없이 최종 결과물을 상용화하는 것을 허용하고자 할 경우</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>마지막 조건은 가장 지배적인 조항인데, 이는 Apache 프로젝트가 그들의 라이선스에 중점을 둔 사항이기도 합니다:</para>
|
||||
|
||||
<para><quote>This type of license is ideal for promoting the use of a reference body of code that implements a protocol for common service. This is another reason why we choose it for the Apache group - many of us wanted to see HTTP survive and become a true multiparty standard, and would not have minded in the slightest if Microsoft or Netscape choose to incorporate our HTTP engine or any other component of our code into their products, if it helped further the goal of keeping HTTP common... All this means that, strategically speaking, the project needs to maintain sufficient momentum, and that participants realize greater value by contributing their code to the project, even code that would have had value if kept proprietary.</quote></para>
|
||||
|
||||
<para>개발자들은 BSD 라이선스를 선호하는 경향이 있는데, 이는 그들이 코드를 다룸에 있어 법적 분쟁으로부터 벗어나 그들이 하고 싶은 대로 하도록 허락하기 때문입니다. 반면, 시스템을 개발하기보다 주로 사용할 것으로 예상되는 사람들, 혹은 다른 사람들이 코드를 개선해 주기를 기대하는 사람들, 혹은 (국가 공무원과 같이) 시스템 작업으로 생계를 유지하지는 않는 사람들의 경우 GPL을 선호하는데, 이는 다른 사람이 개발한 코드를 자신이 사용할 수 있고 그들의 상관이 저작권을 가지고 있는 일을 막을 수도 있으며 결과적으로 잠재적으로 소프트웨어를 "무용지물"로 만들거나 방치하지 않도록 할 수 있기 때문입니다. 만약 여러분이 경쟁자로 하여금 여러분을 돕도록 강제하고 싶다면, GPL은 매력적인 선택지가 될 것입니다.</para>
|
||||
|
||||
<para>BSD 라이선스는 단순한 선물인 것은 아닙니다. <quote>왜 우리는 우리의 경쟁자를 돕거나 그들이 우리가 만든 결과물을 훔쳐 가도록 내버려 두어야 하나요?</quote>라는 질문은 BSD 라이선스에 관련된 질문에서 자주 볼 수 있습니다. BSD 라이선스 하에서, 만약 어떤 회사가 제품 시장을 독점하고 다른 이들이 이를 전략적이었다고 여길 경우, 다른 회사들은 최소한의 노력만으로 시장 경쟁과 공정성을 증대시킬 경쟁 BSD 파생본에 기여하는 작은 협회를 만들 수 있습니다. 이는 각 회사들로 하여금 이것이 제공하는 이점으로부터 이윤을 창출할 수 있을 것이라는 믿음을 주고, 경제적 유연성과 효율성에도 기여할 수 있습니다. 회원들이 더 빠르고 쉽게 이에 협력할수록, 더욱 성공적일 것입니다. BSD 라이선스는 그러한 행동을 가능하게 해 주면서도 가장 덜 복잡한 라이선스입니다.</para>
|
||||
|
||||
<para>완전하고 경쟁력 있는 오픈 소스 시스템을 단지 저장 매체의 가격만으로 널리 쓸 수 있게 한다는 GPL의 핵심적인 효과는 합리적인 목표입니다. BSD 형식의 라이선스는, 협회 창설을 통한 개인의 연합을 통해, 기술 개발 과정에 대한 경제적 기대를 저버리지 않고 이 목표를 달성할 수 있습니다.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="recommendations">
|
||||
<title>BSD 라이선스를 사용하면 좋은 경우</title>
|
||||
|
||||
<itemizedlist>
|
||||
|
||||
<listitem><para>BSD 라이선스는 연구 결과를 널리 배포하고 경제적 이윤을 창출할 수 있도록 하는 데 적합합니다. 그것으로서, NSF, ONR 그리고 DARPA와 같은 연구 개발 기관은 자금을 투자받은 프로젝트의 초기 단계 연구를 위해 소프트웨어, 데이터, 결과, 그리고 오픈 하드웨어에 BSD 형식의 라이선스를 적용할 것을 장려해야 합니다. 그들은 또한 오픈 소스 시스템 구현과 진행중인 오픈 소스 프로젝트를 기반으로 표준을 정할 것을 장려해야 합니다.</para></listitem>
|
||||
|
||||
<listitem><para>정부 정책은 비용과 연구 결과를 실무에 적용할 때의 어려움을 최소화해야 합니다. 가능하다면, 연구 결과를 상용화에 친화적인 BSD 형식의 라이선스로 사용 가능하게 할 것을 요구해야 합니다.</para></listitem>
|
||||
|
||||
<listitem><para>많은 경우에, 저작권 또는 특허에 의해 상용 대학 라이선스에 종속되는 것보다 BSD 형식 라이선스의 형식을 취하는 것이 장기적으로 보았을 때 대학의 연구 목표에 더 근접합니다. 대학 입장에서는 장기적으로 보았을 때 연구 결과를 공개하고, 경제적으로 성공한 졸업생들에 의해 기부받는 것이 금전적으로 더 이득이 되는 실제적인 사례들이 존재합니다.</para></listitem>
|
||||
|
||||
<listitem><para>회사들은 사실상의 표준을 만드는 것이 마케팅 기술의 핵심이 된다는 것을 오랜 경험에 걸쳐 알아왔습니다. 만약 회사가 시스템을 발전시키는 데 독특한 강점이 있다면, BSD 라이선스는 이 역할을 잘 수행합니다. 라이선스는 회사의 전문 기술 덕분에 그들이 통제할 수 있으면서도 많은 사람들에게 법적인 관점에서 매력적입니다. 다른 사람들을 방해하거나 그들의 것을 빼앗고자 할 목적으로 그러한 표준을 만드는 경우 GPL은 적절한 선택이 될 수 있습니다. 그러나 GPL은 상용으로 적용 가능한 표준을 지향하지 않고 방해합니다. 그러한 GPL suite를 사용하는 것은 지속적으로 상용화와 법률 상의 문제를 발생시킵니다. GPL 표준과 그렇지 않은 것을 함께 활용하는 것은 대개 가능하지 않습니다. 진정한 기술 표준은 기술적이지 않은 이유 때문에 다른 표준을 배제할 것을 강제해서는 안 됩니다.</para></listitem>
|
||||
|
||||
<listitem><para>다른 회사들의 상용 제품의 핵심이 될 수 있는 표준을 개발하고 장려하는 데 관심이 있는 회사는 GPL에 대해 조심해야 합니다. 사용된 라이선스에 관계없이, 결과가 되는 소프트웨어는 기술적인 변화의 대부분과 시스템의 상태를 가장 잘 아는 사람들에게 맡겨질 것입니다. GPL은 단지 결과에 추가적인 법적 제약을 가할 뿐입니다.</para></listitem>
|
||||
|
||||
<listitem><para>오픈 소스 코드를 개발하는 큰 회사는 오픈 소스를 옹호하는 프로그래머를 조심해야 하는데, 이는 그들이 다른 곳으로 이직할 경우에도 여전히 그 소프트웨어를 사용할 수 있기 때문입니다. 일부 회사들은, 특히 해당 소프트웨어가 핵심 전략에 직접적으로 연관되어 있지 않을 때, 이러한 행동을 직원들의 특권으로써 장려합니다. 이는 사실 직접적인 비용 손실 없이 잠재적인 기회 비용만을 잃는 퇴직 혜택입니다. 직원을 회사 외부를 위해 일하도록 장려하는 것은 종종 회사가 손해 없이 제공할 수 있는 간단한 혜택이 되기도 합니다.</para></listitem>
|
||||
|
||||
<listitem><para>소프트웨어가 방치될 것이 걱정되는 작은 개발 회사는, 가능하다면 BSD 라이선스를 사용하는 것을 고려해볼 필요가 있습니다. 회사들은 그 규모에 관계없이 BSD 형식 오픈 소스 프로젝트를 구성함으로써 법적인, 그리고 구조적인 간접 비용을 최소화하는 상호간의 이익을 도모할 수 있습니다.</para></listitem>
|
||||
|
||||
<listitem><para>비영리단체들은 가능하다면 오픈 소스 프로젝트에 참여해야 합니다. 서로 다른 라이선스의 코드를 함께 사용하는 것과 같은 소프트웨어상의 문제를 최소화하기 위해, BSD 형식의 라이선스가 장려되어야 합니다. 소프트웨어 개발과 밀접하게 관련있는 비영리단체는 GPL을 더욱 경계해야 할 것입니다. 법률을 적용하는 일이 많은 비용을 요구하는 일부 지역에서는, GPL에 비해 단순한 BSD 라이선스가 고려해볼 만한 이점이 될 것입니다.</para></listitem>
|
||||
|
||||
</itemizedlist>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="conclusion">
|
||||
<title>맺음말</title>
|
||||
|
||||
<para>오픈 소스 코드의 상용화를 막기 위해 만들어진 GPL과는 달리, BSD 라이선스는 미래의 행동에 최소한의 제약만을 가합니다. 이는 프로젝트나 회사의 필요에 따라 BSD 코드를 오픈 소스로 유지하거나 상용 솔루션에 사용될 수 있도록 허락합니다. 다시 말해서, BSD 라이선스는 개발 과정에서 법적인 시한 폭탄이 되지 않습니다.</para>
|
||||
|
||||
<para>더불어 BSD 라이선스는, GPL이나 LGPL 라이선스와는 달리 복잡한 법적 의무가 주어지지 않기 때문에, 개발자와 회사가 라이선스 위반 여부에 대해 걱정하는 대신 좋은 코드를 작성하고 홍보하는 데 집중할 수 있도록 해 줍니다.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="addenda">
|
||||
<title>추가 정보</title>
|
||||
|
||||
<programlisting>
|
||||
[1] http://www.gnu.org/licenses/gpl.html
|
||||
|
||||
[2] http://archives.cnn.com/2000/TECH/computing/03/28/cyberpatrol.mirrors/
|
||||
|
||||
|
|
@ -578,6 +224,8 @@
|
|||
http://www.oreilly.com/catalog/opensources/book/brian.html
|
||||
|
||||
This whitepaper is a condensation of an original work available at
|
||||
http://alumni.cse.ucsc.edu/~brucem/open_source_license.htm</programlisting>
|
||||
</sect1>
|
||||
</article>
|
||||
http://alumni.cse.ucsc.edu/~brucem/open_source_license.htm
|
||||
|
||||
</programlisting>
|
||||
|
||||
</sect1></article>
|
||||
|
|
|
|||
1116
ko_KR.UTF-8/articles/bsdl-gpl/ko_KR.po
Normal file
1116
ko_KR.UTF-8/articles/bsdl-gpl/ko_KR.po
Normal file
File diff suppressed because it is too large
Load diff
20
ko_KR.UTF-8/articles/contributing/Makefile
Normal file
20
ko_KR.UTF-8/articles/contributing/Makefile
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
# The FreeBSD Korean Documentation Project
|
||||
#
|
||||
# $FreeBSD$
|
||||
#
|
||||
# Article: Contributing to FreeBSD
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html
|
||||
WITH_ARTICLE_TOC?= YES
|
||||
|
||||
INSTALL_COMPRESSED?=gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= article.xml
|
||||
|
||||
URL_RELPREFIX?= ../../../..
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
660
ko_KR.UTF-8/articles/contributing/article.xml
Normal file
660
ko_KR.UTF-8/articles/contributing/article.xml
Normal file
|
|
@ -0,0 +1,660 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN" "http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd">
|
||||
<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="ko_KR">
|
||||
<info><title>FreeBSD에 기여하기</title>
|
||||
|
||||
|
||||
<abstract>
|
||||
<para>이 글은 개인이나 단체가 FreeBSD 프로젝트에 기여할 수 있는 여러 가지 방법들을 소개합니다.</para>
|
||||
</abstract>
|
||||
|
||||
<authorgroup>
|
||||
<author><personname><firstname>Jordan</firstname><surname>Hubbard</surname></personname></author>
|
||||
<author><personname><firstname>Sam</firstname><surname>Lawrance</surname></personname></author>
|
||||
<author><personname><firstname>Mark</firstname><surname>Linimon</surname></personname></author>
|
||||
</authorgroup>
|
||||
|
||||
<legalnotice xml:id="trademarks" role="trademarks">
|
||||
<para>FreeBSD는 FreeBSD 재단의 등록 상표입니다.</para>
|
||||
<para>IEEE, POSIX, 그리고 802는 미국에서 Institute of Electrical and Electronic Engineers, Inc.의 등록 상표입니다.</para>
|
||||
<para>생산자 및 판매자들이 그들의 제품을 구별하기 위해 사용하는 많은 표기들은 상표권으로 보호받습니다. 이 문서에 그런 표기들이 나타날 때, FreeBSD 프로젝트는 그러한 상표권에 대해 알고 있기 때문에, 해당 표기 뒤에 <quote>™</quote> 또는 <quote>®</quote> 기호를 사용합니다.</para>
|
||||
</legalnotice>
|
||||
|
||||
<pubdate xml:lang="en">$FreeBSD$</pubdate>
|
||||
|
||||
<releaseinfo xml:lang="en">$FreeBSD$</releaseinfo>
|
||||
</info>
|
||||
|
||||
<indexterm><primary>contributing</primary></indexterm>
|
||||
|
||||
<para>그러니까 FreeBSD에 기여하고 싶으시다는 말씀이군요? 훌륭합니다! FreeBSD는 살아남기 위해 그 사용자들의 기여에 <emphasis>의존하고</emphasis> 있습니다. 여러분의 기여는 단순히 고맙게 받아들여질 뿐만 아니라, FreeBSD의 지속적인 성장에 필수적이기도 합니다.</para>
|
||||
|
||||
<para>FreeBSD는 다양한 연령층과 기술적 전문 지식을 가진 전 세계의 기여자들에 의해 개발되고 있는데, 기여자들의 규모는 크고 또 계속 늘어나고 있습니다. 일거리는 이 사람들이 할 수 있는 일보다 항상 더 많이 존재하고, 더 많은 도움은 언제나 감사하게 받아들여지고 있습니다.</para>
|
||||
|
||||
<para>자원봉사자로서, 여러분은 여러분이 하고 싶은 일에만 참여하면 됩니다. 그러나, 우리는 여러분이 FreeBSD 커뮤니티의 다른 멤버들이 여러분에게 어떤 일을 할 것을 원하고 있는지 미리 알아볼 것을 부탁드립니다. 여러분은 봉사에 참여하기로 마음먹기 전에 이에 대해 고려해 보고 싶으실 수도 있겠군요.</para>
|
||||
|
||||
<para>FreeBSD 프로젝트는 단순히 커널 또는 몇몇의 유틸리티들만이 아니라, 운영체제 환경 전체를 책임지고 있습니다. 그렇기 때문에, 우리의 <filename>TODO</filename> 목록은 다양한 분야의 일거리들을 수록하고 있습니다: 문서화 작업, 베타 테스트와 프리젠테이션에서부터 시스템 인스톨러 그리고 아주 특화된 종류의 커널 개발에 이르기까지 등등. 어떤 분야에 어떤 수준의 기술을 가지고 있더라도, 거의 확실하게 프로젝트에 도움을 줄 수 있을 것입니다.</para>
|
||||
|
||||
<para>FreeBSD에 관련된 사업을 하고 있는 기업들도 우리에게 연락할 것이 권장됩니다. 여러분의 제품이 동작하게 할 특별한 확장이 필요한가요? 너무 특이하지만 않다면, 우리는 여러분의 요청을 받아들일 것입니다. 부가 가치 제품으로 작업하고 있나요? 우리에게 알려 주세요! 우리는 부분적으로 협력할 수 있을지도 모릅니다. 자유 소프트웨어 세계는 소프트웨어가 어떻게 개발되고, 판매되고, 또 유지되는지에 대한 기존의 많은 전제들에 도전하고 있고, 우리는 최소한 여러분에게 또 다른 관점을 제시하고 싶습니다.</para>
|
||||
|
||||
<sect1 xml:id="contrib-what">
|
||||
<title>어떤 도움이 필요한가요?</title>
|
||||
|
||||
<para>아래에 제시된 작업 및 보조 프로젝트들의 목록은 여러 <filename>TODO</filename> 항목들과 사용자 요청들을 나타내고 있습니다.</para>
|
||||
|
||||
<sect2 xml:id="non-programmer-tasks">
|
||||
<title>비-프로그래머를 위한 진행 작업들</title>
|
||||
|
||||
<para>FreeBSD에 관여하는 사람들 중에는 프로그래머가 아닌 사람들도 많습니다. 프로젝트에는 문서 작성자, 웹 디자이너, 기타 도움을 주는 사람들도 포함되어 있습니다. 이들이 기여하는 데에는 시간 투자와 배우려는 의지만 있으면 됩니다.</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>FAQ와 Handbook을 주기적으로 읽어 보세요. 만약 무언가가 어색하게 설명되어 있거나, 너무 오래 되었거나 심지어 완전히 잘못되어 있다면, 우리에게 알려 주세요. 직접 고친 내용을 보내 주신다면 더욱 좋습니다(DocBook은 배우기 어렵지 않습니다만, 그냥 ASCII 형식으로 보내 주셔도 괜찮습니다).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>FreeBSD 문서를 여러분의 모국어로 번역하는 것을 도와 주세요. 만약 문서가 이미 여러분의 언어로 존재한다면, 다른 문서를 추가적으로 번역하거나 번역본이 최신 상태인지를 점검해 보는 것도 좋습니다. 먼저 FreeBSD Documentation Project Primer의 <link xlink:href="@@URL_RELPREFIX@@/doc/ko_KR.UTF-8/books/fdp-primer/translations.html">Translation FAQ</link>를 살펴 보세요. 여러분은 모든 FreeBSD 문서를 다 번역하는 데 헌신할 필요는 없습니다 — 자원봉사자로서, 여러분은 원하는 만큼 많은 또는 적은 양을 번역할 수 있습니다. 한번 누군가가 번역을 시작하면, 다른 사람들은 거의 항상 그 노력에 동참합니다. 만약 여러분이 문서의 일부만을 번역할 시간 또는 노력밖에 없다면, 설치 과정 부분을 번역해 주세요.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-questions">FreeBSD general questions mailing list</link>를 종종 (또는 심지어 정기적으로) 읽어 주세요. 여러분의 전문 지식을 나누고 사람들이 문제를 해결하도록 도와 주는 일은 대단히 만족스러울 수 있습니다; 여러분은 심지어 종종 스스로 새로운 것을 배울 수도 있습니다! 이 포럼들은 할 일들의 아이디어의 원천이 되기도 합니다.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="ongoing-programmer-tasks">
|
||||
<title>프로그래머를 위한 진행 작업들</title>
|
||||
|
||||
<para>여기에 수록된 일들 대다수는 상당한 시간 투자 또는 FreeBSD 커널에 대한 깊이 있는 지식, 심지어 둘 다를 요구합니다. 그러나, <quote>심심풀이 해커</quote>들을 위한 유용한 작업들도 많이 있습니다.</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>만약 여러분이 FreeBSD-CURRENT를 돌리고 있고 인터넷 연결이 괜찮다면, 하루에 한 번씩 전체 릴리즈를 빌드하는 <systemitem class="fqdomainname">current.FreeBSD.org</systemitem>이 있습니다—종종 최신 릴리즈를 설치해 보고 과정에서 오류가 발생하면 제보해 주세요.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-bugs">FreeBSD problem reports mailing list</link>를 읽어 보세요. 여러분이 조언을 해줄 수 있거나 패치를 테스트해볼 수 있는 문제들이 있을 수 있습니다. 또는 심지어 그것들 중 하나를 스스로 고쳐볼 수도 있겠지요.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>만약 여러분이 -CURRENT에서는 고쳐졌지만 상당한 시간이 지난 후(대체로 약 2주 정도)에도 -STABLE에 반영되지 않은 버그를 알고 있다면, 커미터에게 예의 바른 알림을 보내 주세요.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>contributed software를 소스 트리의 <filename>src/contrib</filename>으로 옮겨 주세요.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><filename>src/contrib</filename>의 소스 코드를 최신 상태로 유지시켜 주세요.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>추가적 경고 표시를 활성화한 뒤 소스 트리 (또는 그 일부) 빌드를 해 보고 경고가 나타나는 내용을 수정해 주세요.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><function>gets()</function>을 사용하거나 <filename>malloc.h</filename>을 include하는 등 deprecate된 방법을 사용하는 포트가 있으면 경고를 수정해 주세요.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>여러분이 FreeBSD에 맞도록 패치한 ports에 기여했다면, 그 패치를 원 저자에게 보내 주세요 (이렇게 하면 그들이 다음 버전을 출시할 때 여러분이 할 일이 훨씬 간편해질 것입니다).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><trademark class="registered">POSIX</trademark>와 같은 공식 표준들을 살펴 보세요. 그리고 FreeBSD가 그러한 표준이 요구하는 조건에 충족되는지 확인해 보세요. 만약 그렇지 못하다면, 특히 표준의 사소하거나 불분명한 부분에서의 경우에, 그에 대한 PR을 보내 주세요. 가능하다면, 어떻게 고치는지를 찾아서 PR에 패치를 포함시켜 주세요. 만약 표준이 잘못되었다고 생각된다면, 해당 표준을 관리하는 단체에 문의해 보세요.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>이 목록에 추가할 다른 일들을 제안해 주세요!</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>PR 데이터베이스로 할 것들</title>
|
||||
|
||||
<indexterm><primary>problem reports database</primary></indexterm>
|
||||
|
||||
<para><link xlink:href="https://bugs.FreeBSD.org/search/">FreeBSD PR list</link>는 FreeBSD 사용자에 의해 제출된 모든 문제점 보고와 개선 사항 요청을 담고 있습니다. PR 데이터베이스는 프로그래머 작업과 비-프로그래머 작업을 모두 포함합니다. PR들을 살펴보고, 흥미로운 것이 있는지 살펴 보세요. 이들 중 일부는 매우 간단해서 누군가 살펴보고 PR에 포함된 수정 사항이 제대로 되어 있는지만 확인하면 됩니다. 다른 것들은 더 복잡하거나, 심지어는 수정 사항이 아예 포함되지 않아 있을 수도 있습니다.</para>
|
||||
|
||||
<para>다른 누군가가 맡고 있지 않은 PR부터 시작하세요. 만약 다른 누군가가 PR을 맡고 있는데 여러분이 해결할 수 있는 것처럼 보인다면, 맡고 있는 사람에게 이메일을 보내서 여러분이 작업해도 좋은지 요청해 보세요—그들은 이미 테스트받을 준비가 되어 있는 패치를 가지고 있거나, 여러분과 의논할 만한 아이디어를 가지고 있을 수도 있습니다.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>진행중인 포트 작업들</title>
|
||||
|
||||
<para>포트 컬렉션은 끝없이 진행되고 있는 작업입니다. 우리는 사용자들에게 사용하기 쉽고, 최신 상태로 유지되며, 높은 품질의 제3자 소프트웨어 저장소를 제공하고 싶어합니다. 우리는 이 목표를 달성하기 위해 약간의 시간과 노력을 투자해 도와줄 사람들이 필요합니다.</para>
|
||||
|
||||
<para>누구나 참여할 수 있고, 참여하는 방법은 여러 가지가 있습니다. 포트에 기여하는 것은 프로젝트에 무언가를 <quote>되돌려 주는</quote> 것을 돕는 훌륭한 방법입니다. 여러분이 책임감 있는 역할을 찾고 있든지, 아니면 비 오는 날 할 만한 재미난 일거리를 찾고 있든지 간에, 우리는 여러분이 도와 준다면 무척이나 기쁠 것입니다!</para>
|
||||
|
||||
<para>포트 트리를 최신 상태로 유지하고 잘 동작할 수 있도록 유지하기 위해 할 수 있는 여러 쉬운 방법들이 있습니다:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>멋지거나 유용한 소프트웨어를 찾아 <link xlink:href="@@URL_RELPREFIX@@/doc/ko_KR.UTF-8/books/porters-handbook">포트를 만들어</link> 주세요.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>관리자가 없는 포트들이 많이 있습니다. 관리자가 되어 <link linkend="adopt-port">포트를 관리</link>해 주세요.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>만약 여러분이 포트를 만들었거나 관리하기로 마음먹었다면, <link linkend="maintain-port">관리자로서 무엇을 해야 하는지</link>에 대해 알아 보세요.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>좀더 빠르게 끝낼 수 있는 일을 찾고 있다면 <link linkend="fix-broken">버그 또는 작동하지 않는 포트를 수정해</link> 주세요.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Ideas 페이지에 있는 항목 중 하나를 선택하세요</title>
|
||||
|
||||
<para>FreeBSD 프로젝트에 기여하고 싶어하는 사람들은 <link xlink:href="http://wiki.freebsd.org/IdeaPage">자원봉사자를 위한 FreeBSD 계획과 아이디어 목록</link>을 살펴볼 수 있습니다. 이 목록은 정기적으로 갱신되며 프로그래머 작업과 비-프로그래머 작업에 대한 항목들이 설명과 함께 제시되어 있습니다.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="contrib-how">
|
||||
<title>어떻게 기여할 수 있나요</title>
|
||||
|
||||
<para>시스템에 기여하는 방법은 대개 다음의 5가지 중 한 가지 또는 그 이상에 해당됩니다:</para>
|
||||
|
||||
<sect2 xml:id="contrib-general">
|
||||
<title>버그 보고와 일반적 조언</title>
|
||||
|
||||
<para><emphasis>일반적인</emphasis> 기술적 관심사에 대한 아이디어나 제안은 <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-hackers">FreeBSD technical discussions mailing list</link>에 메일을 보내야 합니다. 마찬가지로, 그러한 내용에 관심이 있는 (그리고 <emphasis>수많은</emphasis> 메일들을 견뎌낼 인내심이 있는) 사람들은 <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-hackers">FreeBSD technical discussions mailing list</link>를 구독하면 됩니다. 이와 더불어 다른 메일링 리스트에 대한 더 많은 정보는 <link xlink:href="@URL_RELPREFIX@@/doc/ko_KR.UTF-8/books/handbook/eresources.html#ERESOURCES-MAIL">The FreeBSD Handbook</link>에서 찾아볼 수 있습니다.</para>
|
||||
|
||||
<para>만일 여러분이 버그를 찾아냈거나 특별한 수정을 제출하고자 한다면, <link xlink:href="https://bugs.FreeBSD.org/submit/">bug submission form</link>을 이용해 주세요. bug report의 각 항목을 완성하기 위해 노력해 주세요. 패치의 크기가 65KB를 넘지 않는다면, report에 직접 패치를 첨부해 주세요. 패치가 소스 트리에 적용되기에 적합하다면 report의 synopsys 부분에 <literal>[PATCH]</literal>를 적어 주세요. 패치를 첨부할 때, 복사-붙여넣기를 이용하면 탭이 공백(space)으로 바뀌어 적용이 불가능해기지 때문에 복사-붙여넣기 방식으로 첨부하면 <emphasis>안 됩니다</emphasis>. 패치가 20KB보다 훨씬 크다면, 업로드하기 전에 (<citerefentry><refentrytitle>gzip</refentrytitle><manvolnum>1</manvolnum></citerefentry>이나 <citerefentry><refentrytitle>bzip2</refentrytitle><manvolnum>1</manvolnum></citerefentry> 등을 이용하여) 압축하는 것을 고려해 보세요.</para>
|
||||
|
||||
<para>report를 제출한 이후에, 여러분은 tracking number가 있는 확인 메일을 받을 겁니다. 이 문제에 대한 상세한 사항을 업데이트할 수 있도록 tracking number를 보관해 두세요.</para>
|
||||
|
||||
<para>좋은 problem report를 작성하기 위해서는 <link xlink:href="@@URL_RELPREFIX@@/doc/ko_KR.UTF-8/articles/problem-reports/article.html">이 article</link>을 참고하세요.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>문서 수정하기</title>
|
||||
|
||||
<indexterm><primary>documentation submissions</primary></indexterm>
|
||||
|
||||
<para>문서의 편집은 <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-doc">FreeBSD documentation project mailing list</link>에 의해 관리됩니다. 전체적인 방법에 대해서는 <link xlink:href="@@URL_RELPREFIX@@/doc/ko_KR.UTF-8/books/fdp-primer/index.html">FreeBSD Documentation Project Primer</link>를 참고해 주세요. 다른 버그 리포트와 같은 방법을 사용해서 제출 및 편집(사소한 것이라도 환영합니다!) 내용을 보내 주세요.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>기존 소스 코드 수정하기</title>
|
||||
|
||||
<indexterm><primary>FreeBSD-CURRENT</primary></indexterm>
|
||||
|
||||
<para>기존의 소스 코드에 무언가를 추가하거나 수정하는 것은 까다로운 작업이며 여러분이 FreeBSD 개발의 최신 상태로부터 얼마나 멀리 떨어져 있느냐에 따라 크게 영향을 받습니다. 시스템에 대해 활동적으로 작업하는 개발자들의 여러 편의를 위해 만들어진 <quote>FreeBSD-CURRENT</quote>라는 특별한 on-going 릴리즈가 있습니다. FreeBSD-CURRENT를 설치하고 사용하는 방법에 대한 정보는 <link xlink:href="@@URL_RELPREFIX@@/doc/ko_KR.UTF-8/books/handbook/current-stable.html">The FreeBSD Handbook</link>에서 찾아볼 수 있습니다.</para>
|
||||
|
||||
<para>오래된 소스로 작업하는 것은 불행히도 여러분의 수정이 종종 이미 필요없게 되거나 FreeBSD에 적용되기에 어려울 수도 있다는 것을 의미합니다. 시스템의 최신 상태에 대한 논의가 이루어지는 <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-announce">FreeBSD announcements mailing list</link>와 <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-current">FreeBSD-CURRENT mailing list</link> 리스트를 구독하면, 이러한 가능성을 최소화할 수 있습니다.</para>
|
||||
|
||||
<para>Assuming that you can manage to secure fairly up-to-date sources to base your changes on, the next step is to produce a set of diffs to send to the FreeBSD maintainers. 이는 <citerefentry><refentrytitle>diff</refentrytitle><manvolnum>1</manvolnum></citerefentry> 명령어를 이용하여 이루어집니다.</para>
|
||||
|
||||
<para>패치를 제출하는 데 선호되는 <citerefentry><refentrytitle>diff</refentrytitle><manvolnum>1</manvolnum></citerefentry> 형식은 <command>diff -u</command>에 의해 생성되, 하나로 통합된 출력입니다.</para>
|
||||
|
||||
<indexterm><primary><command>diff</command></primary></indexterm>
|
||||
|
||||
<screen><prompt>%</prompt> <userinput>diff -u oldfile newfile</userinput></screen>
|
||||
|
||||
<para>또는</para>
|
||||
|
||||
<screen><prompt>%</prompt> <userinput>diff -u -r -N olddir newdir</userinput></screen>
|
||||
|
||||
<para>는 주어진 소스 파일 또는 디렉토리에 대해 하나로 통합된 diff를 생성할 것입니다.</para>
|
||||
|
||||
<para><citerefentry><refentrytitle>diff</refentrytitle><manvolnum>1</manvolnum></citerefentry>에 더 많은 정보가 있습니다.</para>
|
||||
|
||||
<para>여러분이 diff 파일을 만들었다면 (그리고 <citerefentry><refentrytitle>patch</refentrytitle><manvolnum>1</manvolnum></citerefentry> 명령어로 확인했다면), FreeBSD에 반영하기 위해 버그 리포트의 형식으로 제출해야 합니다. diff를 그냥 <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-hackers">FreeBSD technical discussions mailing list</link>에 보내지 <emphasis>마세요</emphasis>! 그것들은 잊혀질지도 모릅니다. 우리는 여러분의 제출을 무척이나 감사히 여기고 있습니다만 (이것은 자원봉사에 의해 이루어집니다!); 우리는 바쁘기 때문에, 때때로 바로 작업에 착수할 수 없을 수도 있습니다. 그것은 우리가 할 때까지 PR 데이터베이스에 남아 있을 것입니다. 제출할 때 리포트의 synopsis에 <literal>[PATCH]</literal>을 포함시켜서 패치라는 것을 알려 주세요.</para>
|
||||
|
||||
<para>적합하다고 생각되는 경우에 (예를 들어 새 파일을 추가했거나, 기존의 파일을 삭제했거나, 파일의 이름을 바꾼 경우), 그 바꾼 내용을 <command>tar</command> 파일로 첨부해 주세요. <citerefentry><refentrytitle>shar</refentrytitle><manvolnum>1</manvolnum></citerefentry>으로 생성된 아카이브도 괜찮습니다.</para>
|
||||
|
||||
<para>만약 여러분의 수정이 잠재적으로 민감할 수 있는 사항을 포함하고 있다면, 예를 들어 배포와 관련된 라이선스 문제에 대해 확신이 없는 경우라면, 버그 리포트로 제출하는 대신 코어 팀 <email>core@FreeBSD.org</email>에 직접 보내 주세요. 코어 팀 <email>core@FreeBSD.org</email>은 FreeBSD에 대해 관한 많은 일을 매일 하는 사람들의 작은 모임입니다. 이들은 <emphasis>매우 바쁘기</emphasis> 때문에, 꼭 필요한 경우에만 메일을 보내 주세요.</para>
|
||||
|
||||
<para>코딩 스타일에 대해서는 <citerefentry><refentrytitle>intro</refentrytitle><manvolnum>9</manvolnum></citerefentry>와 <citerefentry><refentrytitle>style</refentrytitle><manvolnum>9</manvolnum></citerefentry>를 참조해 주세요. 여러분이 코드를 제출하기 전에 이 정보에 대해 최소한 알고 있었다면 우리는 감사할 것입니다.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>새로운 코드 또는 주요한 부가가치 패키지들</title>
|
||||
|
||||
<para>큰 규모의 작업에서 상당한 기여를 하는 경우에, 혹은 FreeBSD에 새롭고 중요한 기능을 추가하는 경우에, 수정한 내용을 다른 사람이 액세스할 수 있도록 tar 파일 형식으로 보내거나 웹/FTP 사이트에 업로드하는 것은 거의 언제나 필요합니다. 만약 여러분이 액세스할 수 있는 웹 또는 FTP 사이트가 없다면, 적절한 FreeBSD 메일링 리스트에 여러분의 수정사항을 호스팅해줄 것을 요청하세요.</para>
|
||||
|
||||
<para>많은 양의 코드에 대해 작업할 때, 저작권에 대한 민감한 주제 역시 언제나 나타납니다. FreeBSD는 BSD 또는 ISC 형식의 오픈 소스 라이선스를 선호합니다. GPLv2와 같은 카피레프트 라이센스 역시 종종 허용됩니다. 전체적인 목록은 <link xlink:href="@@URL_RELPREFIX@@/internal/software-license.html">코어 팀 라이선스 정책</link> 페이지에서 찾아볼 수 있습니다.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>금전 또는 하드웨어</title>
|
||||
|
||||
<para>우리는 FreeBSD 프로젝트를 발전시키기 위한 기부를 받는 것을 매우 기쁘게 여기고 있으며, 우리와 같이 자원봉사 노력을 할 때에, 약간의 기부도 많은 일을 해낼 수 있습니다! 우리는 일반적으로 필요한 장비를 직접 구입할 여유가 없기 때문에, 지원 가능한 장비를 확대하기 위해 하드웨어를 기부받는 것 역시 매우 중요합니다.</para>
|
||||
|
||||
<sect3 xml:id="donations">
|
||||
<title>재단에 기부하기</title>
|
||||
|
||||
<para>FreeBSD 재단은 FreeBSD 프로젝트의 목표를 발전시키기 위해 설립된 비영리, 비과세의 단체입니다. 501(c)3의 회원으로서, FreeBSD 재단은 Colorado 주 소득세뿐만 아니라 미국 연방 소득세도 면제받습니다. 비과세 단체에 기부하는 것은 종종 과세 대상인 연방 소득으로부터 공제받을 수 있습니다.</para>
|
||||
|
||||
<para>기부하기 위해서는 다음의 주소로 수표를 보내 주시면 됩니다: <address>
|
||||
The FreeBSD Foundation
|
||||
<street>P.O. Box 20247</street>,
|
||||
<city>Boulder</city>,
|
||||
<state>CO</state> <postcode>80308</postcode>
|
||||
<country>USA</country>
|
||||
</address></para>
|
||||
|
||||
<para>FreeBSD 재단은 이제 Paypal을 통한 온라인 기부도 받고 있습니다. 기부하기 위해서는, 재단 <link xlink:href="http://www.freebsdfoundation.org">웹 사이트</link>를 방문해 주세요.</para>
|
||||
|
||||
<para>FreeBSD 재단에 대한 더 많은 정보는 <link xlink:href="http://people.FreeBSD.org/~jdp/foundation/announcement.html">The FreeBSD Foundation -- an Introduction</link>에서 찾아볼 수 있습니다. 이메일로 재단에 연락하려면, <email>bod@FreeBSDFoundation.org</email>을 이용하세요.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>하드웨어 기부하기</title>
|
||||
|
||||
<indexterm><primary>donations</primary></indexterm>
|
||||
|
||||
<para>FreeBSD 프로젝트는 유용하게 사용될 수 있는 하드웨어의 기부를 기쁘게 받아들이고 있습니다. 만일 여러분이 하드웨어 기부에 관심이 있다면, <link xlink:href="@@URL_RELPREFIX@@/donation/">Donations Liaison Office</link>에 연락해 주세요.</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="ports-contributing">
|
||||
<title>포트에 기여하기</title>
|
||||
|
||||
<sect2 xml:id="adopt-port">
|
||||
<title>관리되지 않는 포트를 책임지기</title>
|
||||
|
||||
<sect3>
|
||||
<title>관리되지 않는 포트 선택하기</title>
|
||||
|
||||
<para>관리되지 않는 포트를 책임지는 것은 참여하기에 좋은 방법입니다. 관리되지 않는 포트는 누군가가 자원봉사로 작업할 때에만 업데이트되고 고쳐집니다. 관리되지 않는 포트는 많이 있습니다. 여러분이 정기적으로 사용하는 포트를 책임지는 것부터 시작해 보면 좋을 것입니다.</para>
|
||||
|
||||
<para>관리되지 않는 포트는 그 <varname>MAINTAINER</varname>이 <literal>ports@FreeBSD.org</literal>로 설정되어 있습니다. 관리되지 않는 포트와 그것들의 현재 문제점 및 problem reports에 대한 목록은 <link xlink:href="http://portsmon.FreeBSD.org/portsconcordanceformaintainer.py?maintainer=ports%40FreeBSD.org">Ports Monitoring System</link>에서 찾아볼 수 있습니다.</para>
|
||||
|
||||
<para>어떤 포트는 그 의존성 관계 때문에 다른 많은 포트에 영향을 미칠 수 있습니다. 일반적으로, 우리는 사람들이 그러한 포트를 관리하기 전에 약간의 경험을 해볼 것을 원합니다.</para>
|
||||
|
||||
<para><filename>INDEX</filename>라고 이름붙여진 포트의 마스터 인덱스를 살펴보면 포트의 의존성 관계를 파악할 수 있습니다. (파일의 이름은 FreeBSD의 릴리즈에 따라 다를 수 있습니다; 예를 들어, <filename>INDEX-8</filename>.) 일부 포트는 기본 <filename>INDEX</filename> 빌드에는 포함되지 않는 부가적인 의존성 관계를 가지고 있습니다. 우리는 여러분이 다른 포트의 <filename>Makefile</filename>을 살펴봄으로써 이러한 포트를 찾아낼 수 있기를 기대합니다.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>포트를 책임지는 방법</title>
|
||||
|
||||
<para>우선 <link linkend="maintain-port">관리자로서의 책임</link>에 대해 명확히 이해해야 합니다. 또 <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/porters-handbook">Porter's Handbook</link>을 읽어 보세요. <emphasis>여러분이 편안하게 다룰 수 있을 범위를 넘어서서 무리할 필요는 없습니다.</emphasis></para>
|
||||
|
||||
<para>여러분은 원한다면 관리되지 않는 포트의 관리 권한을 언제든지 요청할 수 있습니다. 그냥 <varname>MAINTAINER</varname>을 여러분의 이메일 주소로 설정하고 해당 내용을 PR(Problem Report)로 보내 주세요. 포트에 빌드 에러가 있거나 업데이트가 필요하다면, 같은 PR에 그러한 수정 내용을 포함해도 좋습니다. 많은 커미터들은 FreeBSD에 남긴 흔적이 없는 누군가에게 관리 권한을 부여하고 싶어하지 않기 때문에, 이는 도움이 되는 행동일 것입니다. 빌드 오류를 고치거나 포트를 업데이트하는 PR을 제출하는 것은 이러한 흔적을 남기는 가장 좋은 방법입니다.</para>
|
||||
|
||||
<para>여러분의 PR을 <literal>ports</literal> 카테고리와 <literal>change-request</literal> 클래스로 설정한 뒤 제출해 주세요. 커미터가 여러분의 PR을 검토하고, 수정 사항을 커밋하고, 마침내 PR을 종료시킬 것입니다. 이 과정은 종종 시간이 걸릴 수도 있습니다(커미터들 역시 자원봉사자들입니다 :).</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="maintain-port">
|
||||
<title>포트 관리자를 위한 도전 과제</title>
|
||||
|
||||
<para>이 항목은 포트가 관리되어야 하는 이유 및 포트 관리자의 책임에 대해 설명해줄 것입니다.</para>
|
||||
|
||||
<sect3 xml:id="why-maintenance">
|
||||
<title>포트의 관리가 필요한 이유</title>
|
||||
|
||||
<para>포트를 만드는 일은 일회성 작업입니다. 포트가 최신 상태인지, 그리고 빌드 및 실행이 문제없이 되는지를 확인하는 일은 지속적인 관리 노력이 필요합니다. 관리자는 그들의 시간 중 일부를 이 목표를 달성하는 데 투자하는 사람들입니다.</para>
|
||||
|
||||
<para>포트에 관리가 필요한 가장 주요한 이유는 FreeBSD 커뮤니티에 최신의 많은 3rd party 소프트웨어를 제공하기 위함입니다. 추가적인 목표는 각각의 포트들이 지속적으로 개선되어도 계속 포트 컬렉션 프레임워크 안에서 동작할 수 있도록 유지시키기 위함입니다.</para>
|
||||
|
||||
<para>관리자로서, 여러분은 다음의 도전 과제들을 담당할 필요가 있습니다:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>새로운 소프트웨어 버전 및 업데이트.</title>
|
||||
|
||||
<para>포팅된 소프트웨어에 대해서는 언제든지 새로운 버전과 업데이트가 있을 수 있고, 최신의 소프트웨어를 제공하기 위해서 이들은 포트 컬렉션에 포함될 필요가 있습니다.</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>종속된 포트가 수정되었을 경우.</title>
|
||||
|
||||
<para>여러분의 포트에 종속된 포트가 크게 수정되었을 경우, 여러분의 포트 역시 올바르게 동작하기 위해 업데이트되어야 할 수 있습니다.</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>종속된 포트에 영향을 미치는 수정 사항들.</title>
|
||||
|
||||
<para>만일 여러분이 관리하는 포트에 다른 포트가 의존하고 있다면, 여러분은 여러분의 포트를 수정하기 위해 다른 관리자들과 공동 작업을 해야 할 수도 있습니다.</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>다른 사용자, 관리자 및 개발자와의 소통.</title>
|
||||
|
||||
<para>관리자로서의 역할 중 하나는 지원자의 역할입니다. 일반적인 지원을 제공해야 할 필요는 없습니다 (여러분이 그렇게 한다면 우리는 환영할 것입니다). 여러분이 제공해야 하는 것은 FreeBSD 환경에서 여러분의 포트에 나타나는 특정한 문제들의 해결에 도움을 주는 것입니다.</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>버그 추적하기.</title>
|
||||
|
||||
<para>포트는 FreeBSD 환경에서 특정하게 나타나는 버그의 영향을 받을 수도 있습니다. 여러분은 그러한 버그들이 제보되었을 때 조사하고, 찾아내고, 이들을 고쳐야 합니다. 포트 컬렉션에 넣기 전에 포트를 전체적으로 테스트해보는 것은 더욱 좋습니다.</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>포트의 기반 및 정책의 수정</title>
|
||||
|
||||
<para>때때로 포트와 패키지를 빌드하는 데 사용되는 시스템이 업데이트되거나 그 기반에 영향을 미치는 새로운 제안이 나오기도 합니다. 여러분은 여러분의 포트가 영향을 받아 업데이트를 필요로 하게 될 경우를 위해 이러한 변화에 대해 알고 있어야 합니다.</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>베이스 시스템의 수정.</title>
|
||||
|
||||
<para>FreeBSD는 지속적으로 개발되고 있습니다. 소프트웨어, 라이브러리, 커널 또는 심지어 정책이 바뀌면 포트 역시 자연스럽게 수정이 필요해질 수 있습니다.</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>관리자로서의 책임</title>
|
||||
|
||||
<sect4>
|
||||
<title>여러분의 포트를 최신 상태로 유지하세요</title>
|
||||
|
||||
<para>이 항목은 여러분의 포트를 최신 상태로 유지시키기 위한 과정을 설명하고 있습니다.</para>
|
||||
|
||||
<para>이것은 개괄적인 내용입니다. 포트를 업그레이드하는 것에 대한 더 자세한 정보는 <link xlink:href="@@URL_RELPREFIX@@/doc/ko_KR.UTF-8/books/porters-handbook"> Porter's Handbook</link>에서 찾아볼 수 있습니다.</para>
|
||||
|
||||
<procedure>
|
||||
<step>
|
||||
<title>업데이트 지켜보기</title>
|
||||
|
||||
<para>소프트웨어의 새로운 버전, 업데이트 그리고 보안 수정 사항을 위해 upstream vendor를 주시하세요. 이를 위해서 announcement 메일링 리스트 또는 뉴스 웹 페이지가 도움이 될 것입니다. 사용자들이 종종 여러분에게 연락해서 여러분의 포트가 언제 업데이트될 것인지에 대해 문의할 수 있습니다. 만약 여러분이 다른 이유로 바쁘거나 지금 업데이트할 수 없는 어떤 이유가 있다면, 그들에게 업데이트 제출을 도와줄 수 있는지 요청해 보세요.</para>
|
||||
|
||||
<para>여러분은 또한 <literal>FreeBSD Ports Version Check</literal>로부터 여러분의 포트에 대한 새 버전의 distfile이 사용 가능하다는 자동 이메일을 받을 수도 있습니다. 그 시스템에 대한 (앞으로의 이메일을 그만 받는 방법을 포함한) 더 많은 정보는 해당 메시지에 제공될 것입니다.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>수정 사항을 적용시키기</title>
|
||||
|
||||
<para>변경 사항이 사용 가능해지면, 포트에 적용시켜 주세요. 원본 포트와 업데이트된 포트 사이의 패치를 생성할 수 있어야 할 것입니다.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>검토 및 테스트하기</title>
|
||||
|
||||
<para>여러분의 수정 사항 전체를 검토하고 테스트해보세요:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>가능한 많은 플랫폼과 아키텍처에서 여러분의 포트를 빌드, 설치 그리고 테스트해보세요. 하나의 브랜치 혹은 플랫폼에서 잘 작동하던 포트가 다른 곳에서 실패하는 것은 드문 일이 아닙니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>여러분의 포트의 의존성 관계가 완전한지 점검해 주세요. 권장되는 방법은 여러분의 포트를 <application>tinderbox</application>로 설치해 보는 것입니다. 더 자세한 정보를 위해서는 <link linkend="resources">resources</link>를 참조해 주세요.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>패킹 리스트가 최신 상태인지 확인하세요. 이는 새로운 파일 및 디렉토리를 추가하는 일과 사용되지 않는 내용을 제거하는 일을 포함합니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><citerefentry vendor="ports"><refentrytitle>portlint</refentrytitle><manvolnum>1</manvolnum></citerefentry>를 이용하여 여러분의 포트를 검토하세요. <application>portlint</application>를 사용하는 방법에 대한 중요한 사항을 위해서는 <link linkend="resources">resources</link>를 참조하세요.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>여러분의 포트에 대한 수정 사항이 다른 포트를 고장내는 일이 있을지에 대해 고려해 주세요. 만약 그럴 가능성이 있는 경우에는, 해당 포트의 관리자와 수정 내용을 조율해 주세요. 이는 여러분의 업데이트가 shared library의 버전에 수정을 가하는 경우에 특히 중요합니다; 이 경우, 적어도, 종속된 포트는 <varname>PORTREVISION</varname> bump를 얻어서 <application>portmaster</application> 또는 <citerefentry vendor="ports"><refentrytitle>portupgrade</refentrytitle><manvolnum>1</manvolnum></citerefentry>와 같은 자동화된 도구에 의해 자동으로 업데이트될 수 있도록 할 필요가 있습니다.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>수정 내용 제출하기</title>
|
||||
|
||||
<para>수정 사항에 대한 설명 및 원본과 수정본 사이의 변경 내역을 포함한 패치를 담은 PR을 통해 여러분의 업데이트를 보내 주세요. 좋은 PR을 작성하는 방법에 대한 내용은 <link xlink:href="@@URL_RELPREFIX@@/doc/ko_KR.UTF-8/articles/problem-reports">Writing FreeBSD Problem Reports</link>를 참조해 주세요.</para>
|
||||
|
||||
<note>
|
||||
<para>포트 전체에 대한 <citerefentry><refentrytitle>shar</refentrytitle><manvolnum>1</manvolnum></citerefentry> 아카이브를 제출하지는 말아 주세요; 그 대신에, <citerefentry><refentrytitle>diff</refentrytitle><manvolnum>1</manvolnum></citerefentry> <literal>-ruN</literal>를 사용해 주세요. 이렇게 하면, 정확히 무엇이 수정되었는지 커미터들이 훨씬 쉽게 파악할 수 있습니다. Porter's Handbook에 있는 <link xlink:href="@@URL_RELPREFIX@@/doc/ko_KR.UTF-8/books/porters-handbook/port-upgrading.html">Upgrading</link> 항목에서 더 많은 정보를 찾아볼 수 있습니다.</para>
|
||||
</note>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>기다리기</title>
|
||||
|
||||
<para>때가 되면 커미터가 여러분의 PR을 담당할 것입니다. 이는 몇 분, 또는 몇 주가 소요될 수 있습니다 — 그러므로 그동안 기다려 주세요.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>피드백하기</title>
|
||||
|
||||
<para>만약 커미터가 여러분의 수정 사항에서 문제점을 찾아내면, 그들은 대체로 여러분에게 다시 알려줄 것입니다. 신속한 답변은 여러분의 PR이 빨리 커밋되는 데 도움이 되고, 어떤 문제를 해결하고자 할 때 대화의 흐름을 유지하는 데에도 좋습니다.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>그리고 마지막으로</title>
|
||||
|
||||
<para>여러분의 수정 사항이 커밋되고 여러분의 포트가 업데이트될 것입니다. 그런 다음 PR은 커미터에 의해 닫힐 것입니다. 그것으로 끝입니다!</para>
|
||||
</step>
|
||||
</procedure>
|
||||
</sect4>
|
||||
|
||||
<sect4>
|
||||
<title>여러분의 포트가 지속적으로 올바르게 빌드되는지를 확인해 주세요</title>
|
||||
|
||||
<para>이 항목은 포트가 올바르게 빌드되지 못하도록 하는 문제를 찾아내고 고치는 방법에 대한 것입니다.</para>
|
||||
|
||||
<para>FreeBSD는 포트 컬렉션이 <literal>-STABLE</literal> 가지에서 동작하는 것만을 보장합니다. FreeBSD는 포트 컬렉션이 <literal>-STABLE</literal> 가지에서 동작하는 것만을 보장합니다.</para>
|
||||
|
||||
<para>FreeBSD 설치본의 대부분은 (<literal>i386</literal> 아키텍처라고 불리는) PC-호환 기종에서 동작하기 때문에, 우리는 여러분이 포트를 그 아키텍처에서 동작하도록 작업할 것을 기대합니다. 포트가 <literal>amd64</literal> 아키텍처에서 네이티브로 동작한다면 더욱 좋습니다. 만약 여러분이 이러한 기종을 가지고 있지 않다면 얼마든지 도움을 요청해도 괜찮습니다.</para>
|
||||
|
||||
<note>
|
||||
<para><literal>x86</literal> 이외의 장치에서의 빌드 실패에 대한 대부분의 이유는 프로그램 작성자가, 예를 들어, 포인터를 <literal>int</literal>로 가정했거나, 또는 상대적으로 오래된 <application>gcc</application> 컴파일러가 사용된 경우입니다. 점점 더 많은 프로그램 작성자들은 이러한 가정을 제거하기 위해 그들의 코드에 대해 재작업을 하고 있습니다 — 그러나 작성자가 그들의 코드를 적극적으로 유지보수하지 않는다면, 여러분은 스스로 이 일을 해야 할 수도 있습니다.</para>
|
||||
</note>
|
||||
|
||||
<para>여러분의 포트가 성공적으로 빌드될 수 있도록 하기 위해 여러분은 다음의 작업을 해야 합니다:</para>
|
||||
|
||||
<procedure>
|
||||
<step>
|
||||
<title>빌드 실패 주시하기</title>
|
||||
|
||||
<para>빌드에 실패하거나 오래된 포트가 있는지 살펴보기 위해 <literal>pkg-fallout@FreeBSD.org</literal>와 <link xlink:href="http://portscout.FreeBSD.org">distfiles scanner</link>로부터의 메일을 확인해 주세요.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>정보 모으기</title>
|
||||
|
||||
<para>여러분이 문제점을 인식하면, 그것을 고치는 데 도움이 되는 정보를 모으세요. 여러분이 문제점을 인식하면, 그것을 고치는 데 도움이 되는 정보를 모으세요. 만약 그러한 빌드 실패가 사용자에 의해 여러분에게 보고되었다면, 문제점을 진단하는 데 도움이 될 수 있는 다음과 같은 정보를 요청하세요:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>빌드 로그</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>포트를 빌드하는 데 사용되는 명령어 및 옵션들 (<filename>/etc/make.conf</filename>에 세팅된 옵션들을 포함)</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><citerefentry><refentrytitle>pkg_info</refentrytitle><manvolnum>1</manvolnum></citerefentry>를 통해 보여지는, 그들의 시스템에 설치된 패키지들의 목록</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><citerefentry><refentrytitle>uname</refentrytitle><manvolnum>1</manvolnum></citerefentry><command> -a</command>을 통해 보여지는, 그들의 현재 FreeBSD의 버전</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>그들의 포트 컬렉션이 마지막으로 업데이트된 때</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>그들의 포트 트리와 <filename>INDEX</filename>가 마지막으로 업데이트된 때</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>문제점을 조사하고 해결책을 찾아보기</title>
|
||||
|
||||
<para>불행히도 이를 위한 간단한 프로세스는 없습니다. 그렇지만, 기억하세요: 뭔가 잘 안 풀린다면, 도움을 요청하세요! <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports">FreeBSD 포트 메일링 리스트</link>는 시작하기에 좋은 곳이고, 상부의 개발자들은 대개 대단히 잘 도와줍니다.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>수정 내용 제출하기</title>
|
||||
|
||||
<para>포트를 업데이트할 때와 마찬가지로, 여러분은 이제 수정 사항을 적용하고, 검토하고 테스트하고, PR로 수정 사항을 제출하고, 필요하다면 피드백을 제공해야 합니다.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>상부의 저자에게 패치 보내주기</title>
|
||||
|
||||
<para>특정한 경우에, 여러분은 포트가 FreeBSD에서 동작하도록 하기 위해 패치를 만들어야 합니다. 일부 (그러나 모두는 아닌) 상부의 작성자들은 다음 릴리즈에 그러한 패치를 그들의 코드에 반영할 것입니다. 그렇게 되면, 이는 다른 BSD 기반 시스템 사용자들에게 도움이 될 뿐만 아니라 중복된 작업을 할 노력을 절약해줄 수도 있습니다. 적용 가능한 패치를 작성자에게 보내 주는 호의를 베푸는 것을 고려해 보세요.</para>
|
||||
</step>
|
||||
</procedure>
|
||||
</sect4>
|
||||
|
||||
<sect4>
|
||||
|
||||
<title>여러분의 포트에 관련된 버그 보고와 PR을 살펴 보세요</title>
|
||||
|
||||
<para>이 항목은 버그를 찾아내고 고치는 방법에 대한 것입니다.</para>
|
||||
|
||||
<para>FreeBSD에 특정한 버그는 일반적으로 FreeBSD에는 적용되지 않는 빌드 및 런타임 환경을 가정하기 때문에 일어납니다. 여러분이 이런 유형의 문제를 마주하게 될 가능성은 낮지만, 이것은 더 미묘한 문제이며 찾아내기 어려울 수 있습니다.</para>
|
||||
|
||||
<para>여러분의 포트가 의도한 대로 계속 동작하도록 하기 위해 여러분은 다음의 작업들을 해야 합니다:</para>
|
||||
|
||||
<procedure>
|
||||
<step>
|
||||
<title>버그 보고에 응답하기</title>
|
||||
|
||||
<para>버그는 <link xlink:href="https://bugs.FreeBSD.org/search/">Problem Report database</link>를 통한 이메일로 여러분에게 보고될 것입니다. 버그는 또한 사용자들에 의해 여러분에게 직접적으로 보고될 수도 있습니다.</para>
|
||||
|
||||
<para>여러분은 PR 및 다른 보고에 대해 14일 이내로 응답해야 합니다만, 그렇게 오래 걸리지는 않도록 노력해 주세요. 단지 여러분이 해당 PR에 대해 작업하기까지 시간이 더 필요하다는 답장만이라도, 가능한 한 빨리 응답할 수 있도록 노력해 주세요.</para>
|
||||
|
||||
<para>만약 여러분이 14일이 지나도록 응답하지 않았다면, 다른 커미터는 <literal>maintainer-timeout</literal>을 통해 여러분이 응답하지 않은 PR로부터 커밋할 수 있습니다.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>정보 모으기</title>
|
||||
|
||||
<para>만약 버그를 보고한 사람이 수정 사항을 제공하지 않았다면, 여러분은 그 수정을 하기 위한 정보를 모을 필요가 있습니다.</para>
|
||||
|
||||
<para>만약 버그를 재현할 수 있다면, 여러분은 필요한 정보의 대부분을 스스로 모을 수 있습니다. 그렇지 않다면, 버그를 보고한 사람에게 다음과 같은 정보들을 모아줄 것을 요청하세요:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>그들의 행동에 대한 자세한 설명, 예상했던 프로그램의 행동과 실제 행동</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>버그를 발생시키기 위해 입력했던 데이터의 복사본</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>그들의 빌드 및 실행 환경에 대한 정보 — 예를 들어, 설치된 패키지들의 목록과 <citerefentry><refentrytitle>env</refentrytitle><manvolnum>1</manvolnum></citerefentry>의 출력값</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Core dumps</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Stack traces</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>잘못된 보고를 배제하기</title>
|
||||
|
||||
<para>일부 버그 제보는 잘못되었을 수도 있습니다. 예를 들어, 사용자가 단순히 프로그램을 잘못 사용했을 수 있습니다; 또는 그들이 설치한 패키지가 오래되었고 업데이트를 필요로 하는 경우일 수도 있습니다. 종종 제보된 버그는 FreeBSD에 국한되는 것이 아닐 수도 있습니다. 이 경우에는 upstream 개발자에게 버그를 제보해 주세요. 만약 여러분이 고칠 수 있을 만한 버그라면, 다음 upstream 릴리즈가 배포되기 전에 여러분이 직접 포트를 패치해서 수정 사항을 적용시켜도 됩니다.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>해결책을 찾아보기</title>
|
||||
|
||||
<para>빌드 오류와 마주쳤다면, 여러분은 문제점에 대한 해결 방안을 찾아볼 필요가 있을 것입니다. 다시 한 번 강조하겠습니다, 뭔가 잘 안 풀린다면 도움을 요청하세요!</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
<title>수정 사항을 제출하거나 승인하기</title>
|
||||
|
||||
<para>포트를 업데이트할 때와 마찬가지로, 여러분은 이제 수정 사항을 적용시키고, 검토 및 테스트를 수행하고, 그 내용을 PR로 제출(또는 해당 문제점에 대해 이미 존재하는 PR에 follow-up을 제출)해야 합니다. 다른 사용자가 이미 PR로 변경 사항을 제출했다면, 여러분은 그 변경 사항에 대한 승인 여부를 말하는 follow-up을 보낼 수도 있습니다.</para>
|
||||
</step>
|
||||
</procedure>
|
||||
</sect4>
|
||||
|
||||
<sect4>
|
||||
<title>지원을 제공해 주세요</title>
|
||||
|
||||
<para>관리자로서의 역할 중 하나는 지원을 제공하는 것입니다 — 이는 소프트웨어 자체에 대한 일반적인 지원이 아니라 — 포트 그리고 FreeBSD에 특정한 특이 사항과 문제점에 대한 지원을 의미합니다. 사용자들은 질문, 제안, 문제점 그리고 패치에 대해서 여러분에게 연락할 수 있습니다. 대부분의 경우 그러한 연락들은 FreeBSD에 특정한 내용들일 것입니다.</para>
|
||||
|
||||
<para>종종 여러분은 외교적 수완을 발휘해서, 일반적인 지원을 찾는 사람들에게 적절한 리소스를 알려 주어야 합니다. 이보다는 덜 자주 있는 일이지만, 여러분은 <literal>RPM</literal>이 왜 최신 상태가 아닌지 또는 소프트웨어를 아무개 리눅스에서 어떻게 실행시키는지에 대해 묻는 사람과 마주칠 수도 있습니다. 그들에게 여러분의 포트가 최신 상태임을 알리고(물론, 그럴 경우에만요!), 그들에게 FreeBSD를 사용해볼 것을 권하는 기회를 잡아 보세요.</para>
|
||||
|
||||
<para>종종 사용자와 개발자들은 여러분을 (여러분의 시간을 귀중히 여기는) 바쁜 사람으로 여기고 여러분을 위해 약간의 일을 해줄 수도 있습니다. 예를 들어, 그들은 다음과 같은 일들을 해줄 수도 있습니다:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>여러분의 포트를 업데이트하는 PR을 제출하거나 패치를 보내주는 일,</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>조사하고 아마도 PR에 고친 내용을 제공하는 일, 또는</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>아니면 여러분의 포트에 대한 수정 사항을 제출하는 일.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>이러한 경우에 여러분의 주요 의무는 적절한 때에 응답하는 것입니다. 다시 한번 강조합니다, 관리자의 무응답에 대한 제한 시간은 14일입니다. 이 기간이 지마면 수정 사항은 미승인 상태(unapproved)로 커밋될 것입니다. 그들은 여러분을 위해 이 일을 하는 수고를 했습니다; 그러므로 최소한 신속하게 답변할 수 있도록 노력해 주세요. 그리고 나서 가급적 빨리 이를 검토하고, 승인하고, 그들과 함께 수정 사항을 다듬거나 이에 대해 논의해 주세요.</para>
|
||||
|
||||
<para>만약 여러분이 그들의 기여에 감사를 표한다면 (물론 그래야 합니다만) 앞으로 그들이 여러분을 위해 더 많은 일을 해줄 수도 있을 것입니다 :-).</para>
|
||||
</sect4>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="fix-broken">
|
||||
<title>고장난 포트를 찾아내고 고치기</title>
|
||||
|
||||
<para>관심이 필요한 포트를 찾아보기에 정말 좋은 두 개의 장소가 있습니다.</para>
|
||||
|
||||
<para>여러분은 해결되지 않은 PR들을 찾아보기 위해 Problem Report 데이터베이스의 <link xlink:href="http://bugs.freebsd.org/search">웹 인터페이스</link>를 사용할 수 있습니다. 포트 PR의 대부분은 업데이트이지만, 요약된 내용을 조금만 훑어보면 여러분은 흥미로운 일거리를 찾을 수 있을 것입니다 (<literal>sw-bug</literal> 클래스는 시작하기에 좋은 장소입니다).</para>
|
||||
|
||||
<para>다른 장소는 <link xlink:href="http://portsmon.FreeBSD.org/">FreeBSD Ports Monitoring System</link>입니다. 빌드 오류가 있고 관리되지 않는 포트와 <varname>BROKEN</varname>이라고 표시된 포트에 특히 유의해서 살펴 보세요. 이미 관리되고 있는 포트에 대한 수정 사항을 제출하는 것도 괜찮지만, 관리자가 이미 같은 문제에 대해 작업하고 있는지 물어 보아야 한다는 것을 기억해 주세요.</para>
|
||||
|
||||
<para>여러분이 버그나 문제점을 발견했다면, 정보를 모으고, 분석한 뒤 고쳐 보세요! 이미 PR이 존재한다면, 같이 협력하세요. 그렇지 않다면 새로운 PR을 생성하세요. 여러분의 수정 사항은 검토되고 나서, 만약 모든 것이 괜찮다면, 커밋될 것입니다.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="mortal-coil">
|
||||
<title>그만두어야 할 때</title>
|
||||
|
||||
<para>여러분의 흥미와 상황이 변함에 따라, 여러분은 여러분의 포트에 대한 일부 (또는 모든) 기여를 계속할 시간이 없을 수도 있습니다. 괜찮습니다! 만약 여러분이 더이상 포트를 사용하지 않거나 투자할 시간이 없거나 관리자로서의 흥미를 잃었다면 우리에게 알려 주세요. 그러면 우리는 일을 진행하면서 여러분의 답변을 기다리지 않고 포트의 문제들에 다른 사람들이 작업하도록 허락할 수 있습니다. 기억하세요, FreeBSD는 자원봉사자들에 의한 프로젝트입니다, 그러므로 포트를 관리하는 일이 이제 재미없다면, 다른 누군가에게 넘겨줄 때입니다!</para>
|
||||
|
||||
<para>어느 경우에든지, 여러분이 일정 기간동안 여러분의 포트를 활동적으로 관리하지 않았다면 포트 관리 팀(<literal>portmgr</literal>)은 여러분의 관리 권한을 초기화시킬 권한을 가지고 있습니다. (현재, 이 기간은 3개월로 정해져 있습니다.) 이것은, 이 기간동안 해결되지 않은 문제나 미루어진 업데이트가 있다는 것을 의미합니다.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="resources">
|
||||
<title>포트 관리자와 기여자를 위한 자료</title>
|
||||
|
||||
<para><link xlink:href="@@URL_RELPREFIX@@/doc/ko_KR.UTF-8/books/porters-handbook">Porter's Handbook</link>은 포트 시스템을 여행하는 히치하이커를 위한 안내서입니다. 곁에 두고 자주 살펴 보세요!</para>
|
||||
|
||||
<para><link xlink:href="@@URL_RELPREFIX@@/doc/ko_KR.UTF-8/articles/problem-reports">Writing FreeBSD Problem Reports</link>은 훌륭한 PR을 작성하고 제출하는 방법에 대해서 설명합니다. 2005년에는 11000개 이상의 포트 PR이 제출되었습니다! 이 글을 따라하는 것은 여러분의 PR을 다루는 데 필요한 시간을 절약해 준다는 점에서 큰 도움이 됩니다.</para>
|
||||
|
||||
<para><link xlink:href="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query"> Problem Report database</link>.</para>
|
||||
|
||||
<para><link xlink:href="http://portsmon.FreeBSD.org/">FreeBSD Ports Monitoring System</link>은 빌드 에러 또는 problem report와 같이 포트에 대한 상호 참조 정보를 보여줄 수 있습니다. 여러분이 관리자라면 이러한 정보를 여러분의 포트의 빌드 상태를 확인하는 데 사용할 수 있습니다. contributor로서 여러분은 제대로 동작하지 않고 관리되지 않아서 고쳐질 필요가 있는 포트를 찾아보는 데 사용할 수 있습니다.</para>
|
||||
|
||||
<para><link xlink:href="http://portscout.FreeBSD.org">FreeBSD Ports distfile scanner</link>는 distfiles를 다운로드할 수 없는 포트를 보여줍니다. 여러분은 이를 여러분의 포트를 확인해 보거나 <varname>MASTER_SITES</varname>이 업데이트될 필요가 있는 포트를 찾아보는 데 사용할 수 있습니다.</para>
|
||||
|
||||
<para><package>ports-mgmt/poudriere</package>는 포트의 설치, 패키징, 그리고 제거까지의 전 과정을 전체적으로 테스트해볼 수 있는 방법입니다. 관련된 문서는 <link xlink:href="https://fossil.etoilebsd.net/poudriere/">poudriere home page</link>에서 찾아볼 수 있습니다.</para>
|
||||
|
||||
<para><citerefentry vendor="ports"><refentrytitle>portlint</refentrytitle><manvolnum>1</manvolnum></citerefentry>는 여러분의 포트가 많은 중요한 외형적 그리고 기능적 지침을 준수하고 있는지를 검증하는 데 사용되는 애플리케이션입니다. <application>portlint</application>는 단순한 휴리스틱 애플리케이션이기 때문에, 여러분은 이를 <emphasis>지침서의 역할로만</emphasis> 사용해야 합니다. 만약 <application>portlint</application>가 합리적이지 않아 보이는 수정을 제안한다면, <link xlink:href="@@URL_RELPREFIX@@/doc/ko_KR.UTF-8/books/porters-handbook">Porter's Handbook</link>를 참고하거나 도움을 요청하세요.</para>
|
||||
|
||||
<para><link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports">FreeBSD ports mailing list</link>는 포트와 관련된 일반적인 논의가 이루어지는 곳입니다. 여기는 도움을 요청하기에 좋은 장소입니다. 여러분은 <link xlink:href="http://lists.freebsd.org/mailman/listinfo">구독하거나, 리스트 아카이브를 읽어보고 검색해볼 수 있습니다</link>. <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-ports-bugs">FreeBSD ports bugs mailing list</link>와 <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/cvs-ports">FreeBSD CVS ports commit list</link>의 아카이브를 읽어보는 것도 흥미로울 수 있습니다.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<index/>
|
||||
</article>
|
||||
2199
ko_KR.UTF-8/articles/contributing/ko_KR.po
Normal file
2199
ko_KR.UTF-8/articles/contributing/ko_KR.po
Normal file
File diff suppressed because it is too large
Load diff
22
ko_KR.UTF-8/articles/explaining-bsd/Makefile
Normal file
22
ko_KR.UTF-8/articles/explaining-bsd/Makefile
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
# The FreeBSD Korean Documentation Project
|
||||
#
|
||||
# $FreeBSD$
|
||||
#
|
||||
# Article: Explaining BSD
|
||||
|
||||
MAINTAINER=grog@FreeBSD.org
|
||||
|
||||
DOC?= article
|
||||
|
||||
FORMATS?= html
|
||||
WITH_ARTICLE_TOC?= YES
|
||||
|
||||
INSTALL_COMPRESSED?= gz
|
||||
INSTALL_ONLY_COMPRESSED?=
|
||||
|
||||
SRCS= article.xml
|
||||
|
||||
URL_RELPREFIX?= ../../../..
|
||||
DOC_PREFIX?= ${.CURDIR}/../../..
|
||||
|
||||
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
|
||||
286
ko_KR.UTF-8/articles/explaining-bsd/article.xml
Normal file
286
ko_KR.UTF-8/articles/explaining-bsd/article.xml
Normal file
|
|
@ -0,0 +1,286 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN" "http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd">
|
||||
<!-- $FreeBSD$ -->
|
||||
<!-- The FreeBSD Documentation Project -->
|
||||
<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="ko_KR">
|
||||
<info><title>BSD에 대한 설명</title>
|
||||
|
||||
|
||||
<author><personname><firstname>Greg</firstname><surname>Lehey</surname></personname><affiliation> <address><email>grog@FreeBSD.org</email></address> </affiliation></author>
|
||||
|
||||
<legalnotice xml:id="trademarks" role="trademarks">
|
||||
<para>FreeBSD는 FreeBSD 재단의 등록 상표입니다.</para>
|
||||
<para>AMD, AMD Athlon, AMD Opteron, AMD Phenom, AMD Sempron, AMD Turion, Athlon, Élan, Opteron, 그리고 PCnet은 Advanced Micro Devices, Inc.의 상표입니다.</para>
|
||||
<para>Apple, AirPort, FireWire, iMac, iPhone, iPad, Mac, Macintosh, Mac OS, Quicktime, 그리고 TrueType은 미국 및 그 이외의 국가에서 등록된, Apple Inc.의 상표입니다.</para>
|
||||
<para>Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, 그리고 Xeon은 미국 및 그 이외의 국가에서 Intel Corporation 혹은 그 자회사의 상표 또는 등록 상표입니다.</para>
|
||||
<para>Linux는 Linus Torvalds의 등록 상표입니다.</para>
|
||||
<para>Motif, OSF/1, 그리고 UNIX는 미국 및 그 이외의 국가에서 The Open Group의 등록 상표입니다. IT DialTone과 The Open Group은 미국 및 그 이외의 국가에서 The Open Group의 상표입니다.</para>
|
||||
<para>SPARC, SPARC64, 그리고 UltraSPARC는 미국 및 그 이외의 국가에서 SPARC International, Inc의 상표입니다. SPARC International, Inc는 SPARC 상표 모두를 소유하고 있으며 라이선스 협약 하에 계약자는 이 상표들의 적절한 사용을 허가받습니다.</para>
|
||||
<para>Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, Netra, OpenJDK, Solaris, StarOffice, SunOS 그리고 VirtualBox는 미국 및 그 이외의 국가에서 Sun Microsystems, Inc.의 상표 또는 등록 상표입니다.</para>
|
||||
<para>UNIX는 미국 및 그 이외의 국가들에서 등록된 The Open Group의 등록 상표입니다.</para>
|
||||
<para>생산자 및 판매자들이 그들의 제품을 구별하기 위해 사용하는 많은 표기들은 상표권으로 보호받습니다. 이 문서에 그런 표기들이 나타날 때, FreeBSD 프로젝트는 그러한 상표권에 대해 알고 있기 때문에, 해당 표기 뒤에 <quote>™</quote> 또는 <quote>®</quote> 기호를 사용합니다.</para>
|
||||
</legalnotice>
|
||||
|
||||
<pubdate xml:lang="en">$FreeBSD$</pubdate>
|
||||
|
||||
<releaseinfo xml:lang="en">$FreeBSD$</releaseinfo>
|
||||
|
||||
<abstract>
|
||||
<para>오픈 소스의 세계에서, <quote>리눅스</quote>라는 단어는 <quote>운영체제</quote>라는 단어와 거의 동의어입니다. 하지만 리눅스만이 유일한 오픈 소스 <trademark class="registered">UNIX</trademark> 운영체제인 것은 아닙니다. <link xlink:href="http://www.leb.net/hzo/ioscount/data/r.9904.txt">Internet Operating System Counter</link>에 따르면, 1999년 4월을 기준으로 네트워크에 연결된 전세계의 컴퓨터들 중 31.3%가 리눅스를 구동시켰습니다. 14.6%는 BSD <trademark class="registered">UNIX</trademark>를 구동시켰습니다. <link xlink:href="http://www.yahoo.com/">Yahoo!</link>와 같은 세계 최대 규모의 웹 관리 중 일부는 BSD를 통해 이루어집니다. 1999년을 기준으로 세계에서 가장 활발한 FTP 서버(지금은 중단되었습니다)였던 <link xlink:href="ftp://ftp.cdrom.com/">ftp.cdrom.com</link>는 하루 1.4 TB의 데이터를 전송하기 위해 BSD를 사용했었습니다. 이것이 틈새 시장이 아닌 것은 분명합니다: BSD는 잘 유지되어 온 비밀입니다.</para>
|
||||
|
||||
<para>무엇이 비밀이라는 뜻일까요? 왜 BSD는 잘 알려져 있지 않을까요? 이 보고서는 이러한 의문과 다른 몇몇의 질문에 대한 것입니다.</para>
|
||||
|
||||
<para>이 보고서 전반에 걸쳐, BSD와 리눅스의 차이점은 <emphasis>이렇게</emphasis> 표기될 것입니다.</para>
|
||||
</abstract>
|
||||
</info>
|
||||
|
||||
<sect1 xml:id="what-is-bsd">
|
||||
<title>BSD는 무엇일까요?</title>
|
||||
|
||||
<para>BSD는 <quote>Berkeley Software Distribution</quote>을 나타냅니다. 이는 AT&T의 Research <trademark class="registered">UNIX</trademark> 운영체제의 확장판이었던, University of California, Berkeley의 소스 코드 배포판의 이름입니다. 몇몇 오픈 소스 운영체제들은 4.4BSD-Lite라고 알려진 이 소스 코드 릴리즈에 기반을 두고 있습니다. 게다가, 그 운영체제들은 GNU 프로젝트를 비롯한 다른 오픈 소스 프로젝트들로부터 가져온 많은 패키지들도 포함합니다. 전체적인 운영체제는 다음으로 구성되어 있습니다:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>프로세스 스케줄링, 메모리 관리, 대칭형 다중 처리 (SMP), 장치 드라이버 등을 제어하는 BSD 커널.</para>
|
||||
|
||||
<para><emphasis>리눅스 커널과는 다르게, 서로 다른 기능을 가진 몇몇의 BSD 커널들이 존재합니다.</emphasis></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>시스템의 기반 API인 C 라이브러리.</para>
|
||||
|
||||
<para><emphasis>BSD C 라이브러리는 GNU 프로젝트가 아니라 Berkeley의 코드를 기반으로 합니다.</emphasis></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>쉘, 파일 유틸리티, 컴파일러, 링커와 같은 유틸리티들.</para>
|
||||
|
||||
<para><emphasis>이들 중 일부는 GNU 프로젝트로부터 가져왔고, 다른 일부는 그렇지 않습니다.</emphasis></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>그래픽 디스플레이를 제어하는 X Window 시스템.</para>
|
||||
|
||||
<para>대다수의 BSD에서 사용하는 X Window 시스템은 <link xlink:href="http://www.X.org/">X.Org project</link>에 의해 관리됩니다. FreeBSD는 사용자가 <application>Gnome</application>, <application>KDE</application>, 또는 <application>Xfce</application>와 같은 데스크탑 환경 및 <application>Openbox</application>, <application>Fluxbox</application>, 또는 <application>Awesome</application>과 같은 가벼운 window manager를 선택해서 사용하는 것을 허용합니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>여러 다른 프로그램과 유틸리티들.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="what-a-real-unix">
|
||||
<title>진짜 <trademark class="registered">UNIX</trademark>라고요?</title>
|
||||
|
||||
<para>BSD 운영체제는 클론이 아니라, AT&T의 Research <trademark class="registered">UNIX</trademark> 운영체제(이는 현대의 <trademark class="registered">UNIX</trademark> System V의 조상이기도 합니다)의 오픈 소스 파생본입니다. 여러분은 이 사실에 놀랄지도 모릅니다. AT&T는 그 코드를 오픈 소스로 공개한 적이 없는데 어떻게 그런 일이 일어날 수 있었을까요?</para>
|
||||
|
||||
<para>AT&T <trademark class="registered">UNIX</trademark>가 오픈 소스가 아니라는 것과, 상표권의 관점에서 BSD가 엄밀히는 <trademark class="registered">UNIX</trademark>가 <emphasis>아니라는</emphasis> 것은 사실입니다. 하지만 한편으로는, AT&T는 캘리포니아에 있는 University of California, Berkeley에 속한 Computer Sciences Research Group (CSRG) 등의 다른 프로젝트로부터 소스를 가져와 사용했습니다. 1976년부터, CSRG는 <emphasis>Berkeley Software Distribution</emphasis> 또는 <emphasis>BSD</emphasis>라고 불린 그들의 소프트웨어 테이프를 배포하기 시작했습니다.</para>
|
||||
|
||||
<para>최초의 BSD 릴리즈는 대체로 사용자 프로그램들로 구성되어 있었지만, 그 구성은 Defense Advanced Research Projects Agency(DARPA)가 그들의 네트워크인 ARPANET에서 사용하는 통신 프로토콜을 개선하기 위해 CSRG와 계약을 맺은 이후 극적으로 변화했습니다. 새로운 프로토콜들은 <emphasis>Internet Protocols</emphasis>라고 알려졌으며, 가장 중요한 프로토콜들인 <emphasis>TCP/IP</emphasis>의 구성 요소가 되었습니다. 그 프로토콜의 구현이 최초로 널리 배포된 것은 1982년에 4.2BSD에 포함된 것이었습니다.</para>
|
||||
|
||||
<para>1980년대에, 많은 수의 새로운 워크스테이션 회사들이 갑자기 나타났습니다. 대다수는 그들만의 운영체제를 개발하는 것보다 <trademark class="registered">UNIX</trademark>를 라이선스받는 것을 선호했습니다. 특히 Sun Microsystems는 <trademark class="registered">UNIX</trademark>를 라이선스받아서 <trademark>SunOS</trademark>라고 불리는, 4.2BSD의 한 버전을 만들었습니다. AT&T가 <trademark class="registered">UNIX</trademark>를 상업적으로 판매하도록 허가받았을 때, 그들은 System III라고 불리는 구현을 바닥부터 시작했고, 이는 곧 System V로 발전했습니다. System V 코드는 네트워킹을 포함하지 않았기 때문에, 모든 구현은 TCP/IP 소프트웨어 및 <emphasis>csh</emphasis> 쉘이나 <emphasis>vi</emphasis> 에디터와 같은 추가적인 BSD 소프트웨어들을 포함했습니다. 이러한 기능 향상은 일괄적으로 <emphasis>Berkeley Extensions</emphasis>로 알려졌습니다.</para>
|
||||
|
||||
<para>BSD 테이프는 AT&T 소스 코드를 포함했기 때문에 <trademark class="registered">UNIX</trademark> 소스 라이선스가 필요했습니다. 1990년에, CSRG의 재정은 바닥나고 있었고, 폐쇄를 앞두고 있었습니다. 모임의 일부 회원들은 오픈 소스였던 BSD 코드를 AT&T의 상업 코드 없이 릴리즈하기로 결정했습니다. 이는 마침내 <emphasis>Net/2</emphasis>라고 알려진 <emphasis>Networking Tape 2</emphasis>가 되었습니다. Net/2는 완전한 운영체제가 아니었습니다: 커널 코드의 약 20% 정도가 부족했습니다. CSRG 회원의 한 명이었던 William F. Jolitz는 부족했던 코드를 작성했고 1992년 초에 <emphasis>386BSD</emphasis>라는 이름으로 배포했습니다. 같은 시기에, 전 CSRG 회원들로 구성된 모임이 <link xlink:href="http://www.bsdi.com/">Berkeley Software Design Inc.</link>라는 상업 회사를 조직했고, 386BSD와 같은 코드 기반을 가지는 운영체제 <link xlink:href="http://www.bsdi.com/">BSD/386</link>의 베타 버전을 릴리즈했습니다. 이 운영체제의 이름은 나중에 BSD/OS로 바뀌었습니다.</para>
|
||||
|
||||
<para>386BSD는 안정적인 운영체제가 되지는 못했습니다. 그 대신, 1993년에 그로부터 두 개의 다른 프로젝트가 파생되었습니다: <link xlink:href="http://www.NetBSD.org/">NetBSD</link>와 <link xlink:href="@@URL_RELPREFIX@@/index.html">FreeBSD</link>가 그것입니다. 두 프로젝트는 386BSD의 개선을 기다리는 인내심의 차이에서 갈라졌습니다: NetBSD의 사람들은 새해 일찍 작업에 착수했고, FreeBSD의 첫 버전은 연말까지 준비되지 않았습니다. 한편, 둘의 코드베이스는 다시 합쳐지기 어려울 정도로 크게 갈라졌습니다. 게다가, 각 프로젝트는 서로 다른 목표를 가지고 있었습니다(이에 대해서는 나중에 다룰 것입니다). 1996년에, NetBSD로부터 <link xlink:href="http://www.OpenBSD.org/">OpenBSD</link>가 갈라져 나왔고, 2003년에는 FreeBSD로부터 <link xlink:href="http://www.dragonflybsd.org/">DragonFlyBSD</link>가 갈라져 나왔습니다.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="why-is-bsd-not-better-known">
|
||||
<title>왜 BSD는 잘 알려지지 않았을까요?</title>
|
||||
|
||||
<para>여러 이유들로 인해, BSD는 상대적으로 덜 알려져 있습니다:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>BSD 개발자들은 대개 홍보하는 일보다 코드를 개선하는 일에 더 관심이 많습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>리눅스 인기의 많은 부분은 언론 또는 리눅스 서비스를 제공하는 회사 등 리눅스 프로젝트 외부의 요인에 의한 것입니다. 최근까지, 오픈 소스 BSD는 그러한 후원자들이 없었습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>BSD 개발자들은 리눅스 개발자들보다 더 숙련된 경향이 있고, 시스템을 사용하기 쉽게 만드는 데에는 상대적으로 덜 관심있어합니다. 초보자들은 리눅스를 좀더 편안해하는 경향이 있습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>1992년에, AT&T는 BSD/386의 공급자인 <link xlink:href="http://www.bsdi.com/">BSDI</link>를 고소했는데, 해당 제품이 AT&T가 저작권을 가지고 있는 코드를 포함하고 있다는 것이 그 이유였습니다. 1994년에 그 소송은 타협을 보기로 합의하는 것으로 일단락되었지만, 그 소송의 유령은 사람들을 계속 괴롭혔습니다. 2000년 3월에 들어 웹에 게시된 글은 해당 소송 사건이 <quote>최근에 해결되었다</quote>고 주장했습니다.</para>
|
||||
|
||||
<para>소송에서 분명해진 한 가지 요소는 바로 이름입니다: 1980년대에, BSD는 <quote>BSD <trademark class="registered">UNIX</trademark></quote>라고 알려져 있었습니다. BSD에서 AT&T 코드의 마지막 흔적까지 제거했기 때문에, 그것은 <trademark class="registered">UNIX</trademark>라는 이름에 대한 권리 역시 잃었습니다. 그렇기 때문에 여러분은 책 제목 등에서 <quote>4.3BSD <trademark class="registered">UNIX</trademark> 운영체제</quote> 그리고 <quote>4.4BSD 운영체제</quote>와 같은 표현을 찾아볼 수 있을 것입니다.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="comparing-bsd-and-linux">
|
||||
<title>BSD와 리눅스의 대조</title>
|
||||
|
||||
<para>그래서, 예를 들어, Debian 리눅스와 FreeBSD의 실제적인 차이점은 무엇일까요? 일반적인 사용자들에게, 차이점은 놀랄 만큼 적습니다: 둘 모두 <trademark class="registered">UNIX</trademark> 계열 운영체제입니다. 둘 모두 비영리 프로젝트에 의해 개발됩니다(이는 물론 다른 많은 리눅스 배포판에는 적용되지 않는 사실입니다). 아래 항목에서, 우리는 BSD를 살펴 보고 리눅스와 대조해볼 것입니다. 설명은 BSD 설치본의 약 80%를 차지하는 FreeBSD를 기준으로 작성되었지만, NetBSD, OpenBSD 및 DragonFlyBSD에도 차이는 거의 없습니다.</para>
|
||||
|
||||
<sect2>
|
||||
<title>누가 BSD를 소유하고 있나요?</title>
|
||||
|
||||
<para>BSD는 개인 또는 하나의 회사에 의해 소유되지 않습니다. BSD는 전문적인 기술을 가지고 있는 전세계의 헌신적인 기여자들로 이루어진 커뮤니티에 의해 개발되고 배포됩니다. BSD의 일부 구성 요소는 그들 고유의 오픈 소스 프로젝트에 속해 있고 다른 프로젝트 관리자들에 의해 개발됩니다.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>BSD는 어떻게 개발되고 업데이트되나요?</title>
|
||||
|
||||
<para>BSD 커널은 다음의 오픈 소스 개발 모델에 따라 개발되고 업데이트됩니다. 각 프로젝트는 <link xlink:href="https://subversion.apache.org/">Subversion</link> (SVN)을 통한 공개 <emphasis>소스 트리</emphasis>를 유지합니다. 여기에는 문서 및 다른 부가적인 파일들을 포함한 프로젝트의 모든 소스 파일들이 포함되어 있습니다. SVN은 사용자들이 시스템의 원하는 버전을 <quote>check out</quote> (다시 말하면, 복사본을 추출)하는 것을 허용합니다.</para>
|
||||
|
||||
<para>전세계의 많은 개발자들이 BSD의 개선에 기여하고 있습니다. 이들은 세 가지 분류로 나뉘어질 수 있습니다:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><firstterm>공헌자</firstterm>들은 코드 또는 문서를 작성합니다. 이들은 소스 트리에 직접 커밋(코드를 추가)하는 것은 허용되지 않습니다. 그들의 코드를 시스템에 포함시키기 위해서는, 먼저 <emphasis>커미터</emphasis>로 알려진, 등록된 개발자에 의해 검토받아야 합니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><firstterm>커미터</firstterm>들은 소스 트리에 쓰기 권한을 가진 개발자입니다. 커미터가 되기 위해서, 개인은 그들이 활동하고 있는 영역에 대한 능력을 보여 주어야 합니다.</para>
|
||||
|
||||
<para>소스 트리에 수정 사항을 커밋하기 전에 허가를 받아야 하는지는 커미터 개인의 재량입니다. 일반적으로, 숙련된 커미터는 명백해 보이는 수정에 대해서는 다른 사람과 의견을 조율하지 않고 커밋할 수 있습니다. 예를 들어, documentation project 커미터는 오타나 문법 오류 등을 수정할 때 검토받을 필요가 없습니다. 한편, 많은 부분을 또는 복잡하게 수정하는 개발자는 커밋하기 전에 그들의 수정을 제출해서 검토받아야 합니다. 극단적인 경우에, Principal Architect와 같은 권한을 가진 코어 팀 구성원이 수정한 내용을 트리에서 제거할 것(<firstterm>backing out</firstterm>이라고 부릅니다)을 요청할 수도 있습니다. 모든 커미터들은 각각의 커밋에 대한 메일을 받게 되므로, 비밀리에 커밋하는 것은 불가능합니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><firstterm>코어 팀</firstterm>. FreeBSD와 NetBSD는 각각 프로젝트를 관리하는 코어 팀을 가지고 있습니다. 코어 팀은 프로젝트의 진행 도중에 만들어졌고, 그들의 역할은 항상 잘 정의되어 있지는 않습니다. 코어 팀 구성원이 되기 위해서 개발자일 필요는 없지만, 그런 경우가 일반적입니다. 코어 팀에 대한 규칙은 프로젝트마다 다르지만, 일반적으로 그들은 프로젝트의 진행 방향에 대해 다른 이들보다 큰 영향력이 있습니다.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>아래 정리된 내용은 리눅스와 여러 방면에서의 차이점을 나타냅니다:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>한 사람이 시스템의 구성 요소를 통제하지는 않습니다. 실제로는, Principal Architect가 코드를 back out할 것을 요구할 수 있기 때문에 이 차이점이 과대평가되기도 합니다. 심지어 리눅스 프로젝트에서도 여러 사람들이 수정할 권한이 있습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>한편, 중앙 저장소는 <emphasis>하나인데</emphasis>, 이 곳은 전체 운영체제의 시스템 소스를 이전 버전까지 포함하여 모두 찾아볼 수 있는 통합된 장소입니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>BSD 프로젝트는 단지 커널만이 아니라 <quote>운영체제</quote> 전체를 관리합니다. 이 차이점은 아주 약간의 의미만 있습니다: BSD도 리눅스도 애플리케이션 없이는 유용하지 않습니다. BSD에서 사용되는 애플리케이션들은 리눅스에서 사용되는 애플리케이션과 같은 경우가 많습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>하나의 공식 SVN 소스 트리를 관리하는 결과로, BSD의 개발은 명확하게 이루어지고 있으며, 릴리즈 넘버 혹은 날짜를 통해 시스템의 어떤 버전에라도 접근할 수 있습니다. SVN은 또한 시스템의 증분 업데이트를 지원합니다: 예를 들어, FreeBSD 저장소는 하루에 약 100회 업데이트됩니다. 이러한 수정 사항의 대부분은 작은 것들입니다.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>BSD 릴리즈</title>
|
||||
|
||||
<para>FreeBSD, NetBSD 그리고 OpenBSD는 시스템을 세 가지 다른 <quote>릴리즈</quote>의 형식으로 제공합니다. 리눅스와 같이, 릴리즈들은 1.4.1 또는 3.5와 같은 번호를 부여받습니다. 더불어, 버전 번호는 시스템의 목적을 나타내는 접미사를 가지고 있습니다.</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>개발자 버전의 시스템은 <firstterm>CURRENT</firstterm>이라고 불립니다. FreeBSD는 FreeBSD 5.0-CURRENT와 같은 형태로 CURRENT에 숫자를 할당합니다. NetBSD는 약간 다른 작명법을 사용하여 내부 인터페이스에 변화를 나타내는 한 글자의 접미사를 붙입니다. 예를 들어 NetBSD 1.4.3G와 같습니다. OpenBSD는 숫자를 할당하지 않습니다(<quote>OpenBSD-current</quote>). 시스템의 새로운 개발은 모두 이 가지로 들어갑니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>일 년에 두 번에서 네 번 정도의 적당한 간격으로, 각 프로젝트는 CD-ROM 또는 FTP 무료 다운로드 형식으로 제공되는 <firstterm>RELEASE</firstterm> 버전 시스템을 제공합니다. 예를 들어 OpenBSD 2.6-RELEASE 또는 NetBSD 1.4-RELEASE와 같습니다. RELEASE 버전은 일반적인 버전의 시스템으로 최종 사용자를 위한 것입니다. NetBSD는 세 번째 자리수와 함께 <emphasis>patch release</emphasis>들을 제공합니다. 예를 들어 NetBSD 1.4.2와 같습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>REALEASE 버전에서 버그가 발견되면, 그것들은 고쳐지고, 고쳐진 내용은 SVN 트리에 반영됩니다. FreeBSD의 경우, 그 결과적인 버전은 <firstterm>STABLE</firstterm> 버전이라고 부르고, NetBSD와 OpenBSD의 경우 계속 RELEASE 버전이라고 부릅니다. CURRENT 가지에서 일정 기간 테스트된 이후에 작은 새 기능들이 이 가지에 추가될 수도 있습니다.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para><emphasis>대조적으로, 리눅스는 두 개의 코드 트리를 별도로 관리하고 있습니다: stable 버전과 development 버전이 그것들입니다. stable 버전은 2.0, 2.2, 2.4와 같이 짝수의 minor 버전 숫자를 가지고 있습니다. development 버전은 2.1, 2.3, 2.5와 같이 홀수의 minor 버전 숫자를 가지고 있습니다. 각각의 경우에, 이 숫자 다음에는 정확한 릴리즈를 지칭하는 자릿수가 더 따라옵니다. 더불어, 각 공급자는 그들 고유의 사용자 프로그램 및 유틸리티를 추가하기 때문에, 배포판의 이름 역시 중요합니다. 각 배포판 공급자는 배포판에 대한 버전 숫자도 할당하기 때문에, 전체적인 묘사는 <quote>TurboLinux 6.0 with kernel 2.2.14</quote>와 같이 됩니다.</emphasis></para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>BSD에는 어떤 종류가 있나요?</title>
|
||||
|
||||
<para>수많은 종류의 리눅스 배포판들과는 대조적으로, 오픈 소스 BSD에는 오직 네 가지 주요한 버전만이 있습니다. 각 BSD 프로젝트는 고유한 소스 트리와 커널을 유지합니다. 그러나 실제로는, userland 코드는 리눅스의 경우에서보다 차이가 적습니다.</para>
|
||||
|
||||
<para>각 프로젝트의 목표를 분류하기는 어렵습니다: 차이는 매우 주관적입니다. 기본적으로,</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>FreeBSD는 높은 성능 그리고 end user가 손쉽게 사용하는 것을 추구하며, 웹 컨텐츠 제공자들이 선호합니다. FreeBSD는 <link xlink:href="@@URL_RELPREFIX@@/platforms/">다양한 플랫폼</link>에서 작동될 수 있으며 다른 프로젝트에 비해 현저히 많은 사용자를 가지고 있습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>NetBSD는 이식성을 최우선으로 하여 개발되고 있습니다: <quote>of course it runs NetBSD</quote>. NetBSD는 palmtop에서부터 대형 서버에서까지 구동될 수 있으며, 심지어는 NASA의 space mission에도 사용되었습니다. 오래된 비 <trademark class="registered">Intel</trademark> 하드웨어를 구동시킬 때 특히 좋은 선택입니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>OpenBSD는 보안과 코드 품질을 최우선으로 하여 개발되고 있습니다: OpenBSD는 오픈 소스와 엄격한 코드 검사를 통해 명백히 correct한 시스템을 만듭니다. 이를 통해 은행, 증권 거래소 및 US 정부 기관 등과 같이 보안이 중시되는 곳에서 사용될 수 있도록 합니다. NetBSD와 마찬가지로, 이는 다양한 플랫폼에서 구동될 수 있습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>DragonFlyBSD는 single-node UP 시스템에서부터 대규모 클러스터 시스템에 이르기까지의 환경에서 높은 성능과 확장성을 추구합니다. DragonFlyBSD는 몇몇의 장기적인 기술 목표들을 가지고 있지만, 핵심은 이해하고 유지하고 개발하기 쉬운 대칭형 다중 처리(SMP) 기반을 제공하는 것에 있습니다.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>이와 더불어 오픈 소스가 아닌 두 개의 BSD <trademark class="registered">UNIX</trademark> 운영체제들도 있습니다. BSD/OS와 Apple의 <trademark class="registered">Mac OS</trademark> X가 그것들입니다:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>BSD/OS는 가장 오래된 4.4BSD 파생본입니다. 이것의 소스 코드는 상대적으로 낮은 가격에 얻을 수 있었지만, 오픈 소스는 아니었습니다. 이것은 FreeBSD와 여러 방면에서 유사합니다. BSDi가 Wind River Systems에 의해 인수된 지 2년 후, BSD/OS는 독립적인 제품으로 살아남는 데에는 실패했습니다. 소스 코드 및 지원은 Wind River에서 여전히 제공했지만, 모든 새로운 개발은 VxWorks 임베디드 운영체제에 집중되었습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><link xlink:href="http://www.apple.com/macosx/server/"><trademark class="registered">Mac OS</trademark> X</link>는 <trademark class="registered">Apple</trademark>의 <trademark class="registered">Mac</trademark>을 위한 운영체제의 최신 버전입니다. 이 운영체제의 BSD 코어인 <link xlink:href="http://developer.apple.com/darwin/">Darwin</link>은 x86 및 PPC 컴퓨터를 위한 완전한 기능의 오픈 소스 운영체제로 사용이 가능합니다. 그러나 Aqua/Quartz 그래픽 시스템 및 <trademark class="registered">Mac OS</trademark> X의 다른 많은 상용 부분은 클로즈드 소스로 남아 있습니다. 몇몇 Darwin 개발자들은 FreeBSD의 committer이기도 합니다.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>BSD 라이선스는 GNU Public license와 어떻게 다른가요?</title>
|
||||
|
||||
<para>리눅스는 closed 소스 소프트웨어를 제거하도록 디자인된 <link xlink:href="http://www.fsf.org/copyleft/gpl.html">GNU General Public License</link>(GPL)에 따라 배포됩니다. 특히, GPL의 파생물은 모두 사용자가 소스 코드를 요청하면 이를 제공해야 합니다. 이와는 대조적으로, <link xlink:href="http://www.opensource.org/licenses/bsd-license.html">BSD 라이선스</link>는 제약 사항이 적습니다: 바이너리만 배포하는 것이 허용됩니다. 이는 임베디드 애플리케이션을 개발할 때 특히 매력적인 선택입니다.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>알아야 할 다른 무언가가 있나요?</title>
|
||||
|
||||
<para>BSD에서 사용 가능한 애플리케이션의 수가 리눅스의 경우보다 적기 때문에, BSD 개발자들은 리눅스 프로그램을 BSD에서 구동할 수 있도록 해 주는 리눅스 호환성 패키지를 만들었습니다. 이 패키지는 리눅스 시스템 콜을 올바르게 수행하기 위한 커널 수정과, C 라이브러리와 같은 리눅스 호환성 파일들을 포함하고 있습니다. 같은 장비에서 리눅스를 설치해서 리눅스 애플리케이션을 구동할 때와 BSD를 설치해서 리눅스 애플리케이션을 구동할 때 실행 속도는 눈에 띄지 않을 정도로 차이가 작습니다.</para>
|
||||
|
||||
<para>BSD의 <quote>all from one supplier</quote> 환경은 리눅스에서 종종 문제가 되기도 하는 업그레이드를 훨씬 쉽게 할 수 있다는 것을 의미합니다. BSD는 라이브러리 버전을 업그레이드할 때 이전 라이브러리 버전에 대한 호환성 모듈을 제공하기 때문에, 몇년 전의 바이너리를 문제없이 실행하는 것이 가능합니다.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>BSD와 리눅스 중에 무엇을 사용해야 하나요?</title>
|
||||
|
||||
<para>실제로 이건 무슨 뜻일까요? 누가 BSD를 사용해야 하고, 누가 리눅스를 사용해야 할까요?</para>
|
||||
|
||||
<para>이는 대답하기 대단히 어려운 질문입니다. 여기에 약간의 조언이 있습니다:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><quote>망가지지 않았다면, 고치지 마라</quote>: 만일 여러분이 오픈 소스 운영체제를 사용하고 있고, 이에 대해 만족하고 있다면, 아마 굳이 그걸 바꾸어야 할 이유는 없을 겁니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>BSD 시스템, 특히 FreeBSD는 리눅스보다 월등히 높은 성능을 발휘할 수 있습니다. 하지만 항상 그런 것은 아닙니다. 대개의 경우에, 성능 차이는 없거나 아주 작습니다. 일부 경우에는, 리눅스가 FreeBSD보다 더 나은 성능을 발휘할 수도 있습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>일반적으로, BSD 시스템은 보다 성숙한 코드 베이스를 가지고 있기 때문에, 그 안정성이 더 잘 알려져 있습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>BSD 프로젝트는 문서의 품질과 완성도로 잘 알려져 있습니다. 다양한 문서 프로젝트들은 시스템의 모든 방면을 다루는 문서를 다양한 언어로 꾸준히 갱신하는 것을 목표로 하고 있습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>BSD 라이선스는 GPL보다 매력적인 선택일 수 있습니다.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>리눅스는 BSD 바이너리를 실행할 수 없는 반면, BSD는 대부분의 리눅스 바이너리를 실행할 수 있습니다. 많은 BSD 구현들은 다른 <trademark class="registered">UNIX</trademark> 계열 시스템의 바이너리 또한 실행할 수 있습니다. 결과적으로, 다른 시스템에서 BSD로 마이그레이션하는 것은 리눅스로 하는 것보다 수월할 수 있습니다.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>누가 BSD에 대한 지원, 서비스, 그리고 교육을 제공하나요?</title>
|
||||
|
||||
<para>BSDi / <link xlink:href="http://www.freebsdmall.com">FreeBSD Mall, Inc.</link>는 거의 10년 동안 FreeBSD에 대한 지원 계약을 제공해 오고 있습니다.</para>
|
||||
|
||||
<para>더불어, 각 프로젝트는 고용에 대한 상담의 목록을 가지고 있습니다: <link xlink:href="@@URL_RELPREFIX@@/commercial/consult_bycat.html">FreeBSD</link>, <link xlink:href="http://www.netbsd.org/gallery/consultants.html">NetBSD</link>, 그리고 <link xlink:href="http://www.openbsd.org/support.html">OpenBSD</link>.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</article>
|
||||
1136
ko_KR.UTF-8/articles/explaining-bsd/ko_KR.po
Normal file
1136
ko_KR.UTF-8/articles/explaining-bsd/ko_KR.po
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -14,7 +14,7 @@
|
|||
|
||||
<!ENTITY doc.html.charset "utf-8">
|
||||
|
||||
<!ENTITY doc.langcode.en "ko_KR.UTF-8">
|
||||
<!ENTITY doc.langcode.ko "ko_KR.UTF-8">
|
||||
<!ENTITY doc.langcode "&doc.langcode.ko;">
|
||||
|
||||
<!-- PUBLIC "-//FreeBSD//ENTITIES FreeBSD L10N Entities//EN" -->
|
||||
|
|
|
|||
Loading…
Reference in a new issue