diff options
Diffstat (limited to 'documentation/content/ko/articles/bsdl-gpl/_index.adoc')
| -rw-r--r-- | documentation/content/ko/articles/bsdl-gpl/_index.adoc | 171 |
1 files changed, 84 insertions, 87 deletions
diff --git a/documentation/content/ko/articles/bsdl-gpl/_index.adoc b/documentation/content/ko/articles/bsdl-gpl/_index.adoc index 22f21f229f..514ea4c42f 100644 --- a/documentation/content/ko/articles/bsdl-gpl/_index.adoc +++ b/documentation/content/ko/articles/bsdl-gpl/_index.adoc @@ -1,12 +1,15 @@ --- -title: 오픈 소스 프로젝트에 BSD 형식의 라이선스를 사용해야 하는 이유 authors: - - author: Bruce Montague + - + author: 'Bruce Montague' email: brucem@alumni.cse.ucsc.edu +description: '오픈소스 프로젝트에 BSD 스타일 라이선스를 사용해야 하는 이유' +tags: ["bsdl", "gpl", "FreeBSD License"] +title: '오픈소스 프로젝트에 BSD 스타일 라이선스를 사용해야 하는 이유' trademarks: ["freebsd", "intel", "general"] --- -= 오픈 소스 프로젝트에 BSD 형식의 라이선스를 사용해야 하는 이유 += 오픈소스 프로젝트에 BSD 스타일 라이선스를 사용해야 하는 이유 :doctype: article :toc: macro :toclevels: 1 @@ -42,167 +45,161 @@ endif::[] toc::[] [[intro]] -== 개요 +== 소개 -이 문서는 소프트웨어와 데이터에 BSD 형식의 라이선스를 사용해야 하는 이유를 설명합니다; 구체적으로 이 문서는 GPL 대신 BSD 형식의 라이선스를 사용할 것을 권장합니다. 이 문서는 또한 BSD와 GPL 오픈 소스 라이선스에 대한 소개 및 간단한 요약이기도 합니다. +이 문서는 소프트웨어와 데이터에 BSD 스타일 라이선스를 사용하는 사례를 제시하며, 특히 GPL 대신 BSD 스타일 라이선스를 사용할 것을 권장합니다. 이 문서는 BSD와 GPL 오픈 소스 라이선스 소개 및 요약으로 생각하셔도 됩니다. [[history]] -== 오픈 소스의 아주 간략한 역사 +== 아주 간략한 오픈소스 역사 -"오픈 소스"라는 용어가 사용되기 오래 전에, 소프트웨어는 프로그래머들의 자발적인 공동체에 의해 개발되고 자유롭게 주고받아졌습니다. 1950년대 초반을 시작으로, http://www.share.org[SHARE]와 http://www.decus.org[DECUS]와 같은 단체들은 컴퓨터 하드웨어 회사들이 자사의 제품에 동봉한 소프트웨어의 상당수를 개발했습니다. 그 당시 컴퓨터 회사들은 주로 하드웨어 사업을 하고 있었습니다; 소프트웨어의 비용을 낮추고 더 많은 프로그램들을 사용 가능하도록 제공하는 것은 곧 하드웨어 회사들의 경쟁력이 되었습니다. +“오픈 소스”라는 용어가 사용되기 훨씬 전부터 소프트웨어는 프로그래머들의 느슨한 연합에 의해 개발되고 자유롭게 교환되었습니다. 1950년대 초부터 http://www.share.org[SHARE] 및 http://www.decus.org[DECUS]와 같은 조직이 컴퓨터 하드웨어 회사가 하드웨어 제품에 번들로 제공하는 소프트웨어의 대부분을 개발했습니다. 당시 컴퓨터 회사들은 하드웨어를 주축으로 사업을 하고 있었기 때문에 소프트웨어 비용을 절감하고 더 많은 프로그램을 사용할 수 있게 하면 컴퓨터 회사의 경쟁력이 높아졌습니다. -이러한 방침은 1960년대에 바뀌었습니다. 1965년에 ADR은 하드웨어 제조사와는 독립적으로 라이선스된 최초의 소프트웨어 제품을 개발했습니다. ADR은 IBM의 고객들에 의해 개발된 무료 IBM 패키지와 경쟁하고 있었습니다. ADR은 1968년에 그들의 소프트웨어에 대한 특허를 출원했습니다. 그들의 프로그램이 (불법으로) 공유되는 것을 막기 위해, 그들은 그들의 프로그램을 (사용하기 위해서는 비용을 지불해야 하는) 임대 형식의 장비에서만 제공했습니다. 그럼으로써 ADR은 소프트웨어에 대한 소유권을 얻었고, 소프트웨어의 재판매와 재사용을 하지 못하도록 통제할 수 있었습니다. +이 모델은 1960년대에 바뀌었습니다. 1965년 ADR은 하드웨어 회사로부터 독립하여 최초의 라이선스 소프트웨어 제품을 개발했습니다. ADR은 원래 IBM 고객이 개발한 무료 IBM 패키지와 경쟁하고 있었습니다. ADR은 1968년 소프트웨어 특허를 획득했습니다. 프로그램의 공유를 막기 위해 제품 수명 기간 동안 요금을 나눠내는 장비 리스 방식으로 제품을 제공했습니다. 따라서 ADR은 소유권을 유지하고 재판매 및 재사용을 통제할 수 있었습니다. -1969년에 미국 법무부는 IBM이 그들의 하드웨어에 무료 소프트웨어를 동봉하여 시장을 독점하려 한 것에 대해 벌금을 부과했습니다. 이 소송의 결과로, IBM은 더 이상 그들의 제품에 소프트웨어를 동봉하지 않았습니다; 즉, 소프트웨어는 하드웨어와는 독립적인 제품이 되었습니다. +1969년 미국 법무부는 IBM이 무료 소프트웨어를 IBM 하드웨어에 번들로 제공함으로써 비즈니스를 파괴했다는 혐의로 IBM을 기소했습니다. 이 소송의 결과로 IBM은 소프트웨어를 번들에서 분리하였고, 소프트웨어가 하드웨어와 분리된 독립적인 제품이 되었습니다. -1968년에 Informatics는 최초로 상용 killer-app을 발표하고 소프트웨어 제품, 소프트웨어 회사, 그리고 많은 이윤에 대한 개념을 빠르게 정착시켜 나갔습니다. Informatics는 현재 컴퓨터 산업의 표준과도 같은 영구 라이선스를 개발했습니다. 이 라이선스는 소프트웨어의 소유에 대한 권리가 소비자에게 주어지지 않는다는 특징이 있습니다. +1968년 인포매틱스(Informatics)는 최초의 상용 킬러 앱을 출시하여 소프트웨어 제품, 소프트웨어 회사, 매우 높은 수익률이라는 개념을 빠르게 정립했습니다. 인포매틱스는 현재 컴퓨터 업계에서 표준이 된 영구 라이선스를 개발했는데, 이 라이선스는 소유권이 고객에게 이전되지 않습니다. [[unix-license]] -== BSD 라이선스의 관점에서 바라본 유닉스 +== BSD 라이선스 관점에서 본 유닉스 -원본 유닉스 구현을 소유하고 있던 AT&T는 반독점법에 의해 공식적으로 규제를 받고 있었습니다; 그 회사는 합법적으로 소프트웨어 제품을 판매할 수 없었습니다. 그러나 학술 기관에 저장 매체의 비용만을 받고 소프트웨어를 제공하는 것은 가능했습니다. +최초의 유닉스 구현을 소유한 AT&T는 미국의 반독점법에 묶여 공공 규제를 받는 독점기업이었기 때문에 법적으로 소프트웨어 시장에 제품을 판매할 수 없었습니다. 하지만 학술 기관에는 미디어 가격(순수한 패키지 가격)을 받고 제공할 수 있었습니다. -OS conference에서 유닉스를 사용 가능하다고 발표한 이후에, 대학교들은 그것을 빠르게 채택했습니다. 유닉스는 대단히 저렴한 16비트 컴퓨터인 PDP-11에서 작동했고, 시스템 프로그래밍에 명백하게 유리한 고급 언어로 작성되어 있었습니다. 이는 대단히 유용한 특징이었습니다. DEC PDP-11은 소비자들이 그들만의 운영체제를 작성(그 당시에는 꽤나 보편적인 일이었습니다)하기 쉽도록 하드웨어 인터페이스를 공개하고 있었습니다. DEC의 창립자인 Ken Olsen이 했던 말은 유명합니다, "당신이 좋은 하드웨어를 가지고 있다면 소프트웨어는 하늘이 내려 준다". +한 OS 컨퍼런스에서 유닉스를 공적으로 사용할 수 있다는 사실이 알려지면서 많은 대학들은 빠르게 유닉스를 도입했습니다. 유닉스가 매우 저렴한 16비트 컴퓨터인 PDP-11에서 실행되고 시스템 프로그래밍에 매우 적합한 고급 언어로 코딩되어 있었다는 점이 큰 도움이 되었습니다. DEC PDP-11은 고객이 자체 OS를 쉽게 작성할 수 있도록 설계된 개방형 하드웨어 인터페이스를 갖추고 있었는데, 당시에는 이러한 인터페이스가 일반적이었습니다. “좋은 하드웨어가 있으면 소프트웨어는 하늘에서 내려온다”는 DEC 창립자 켄 올슨(Ken Olsen)의 유명한 명언이 있습니다. -유닉스의 개발자인 Ken Thompson은 1975년에 그의 모교인 캘리포니아 버클리 대학교(UCB)로 돌아왔고, 커널을 한줄씩 가르쳤습니다. 이는 궁극적으로 BSD(Berkeley Standard Distribution)라는 시스템으로 발전했습니다. UCB는 유닉스를 32비트로 변환시켰고, 가상 메모리와 TCP/IP 스택(인터넷의 핵심 기술)을 구현했습니다. UCB는 BSD를 "BSD 라이선스"라고 알려지게 된 규정에 따라 저장 매체의 비용만 받고 누구에게나 제공했습니다. 소비자들은 AT&T에서 유닉스를 구입했고 UCB에서 BSD 테이프(당시의 저장 매체)를 주문했습니다. +유닉스의 창시자 켄 톰슨(Ken Thompson)은 1975년 모교인 캘리포니아 버클리 대학교(UCB)로 돌아와 커널을 한 줄 한 줄 가르쳤습니다. 그 결과 BSD(버클리 표준 배포판)로 알려진 진화하는 시스템이 탄생했습니다. UCB는 유닉스를 32비트로 변환하고, 가상 메모리를 추가하고, 인터넷의 기본이 되는 TCP/IP 스택 버전을 구현했습니다. UCB는 “BSD 라이선스”라는 이름으로 미디어 비용으로 BSD를 사용할 수 있게 했습니다. 과거에 AT&T에서 유닉스를 구입한 고객들은 이제 UCB에서 BSD 테이프를 주문하게 되었습니다. -1980년대 중반에 정부의 ATT에 대한 독점 소송은 ATT가 회사의 사업부를 분할하는 것으로 끝났습니다. ATT는 여전히 유닉스를 소유하고 있었고 이제는 판매도 할 수 있었습니다. ATT는 공격적인 라이선스 정책을 추진했으며 오늘날의 주요한 상용 유닉스들은 ATT 기반이 되었습니다. +1980년대 중반, AT&T에 대한 정부의 반독점 소송으로 인해 AT&T가 해체되었습니다. AT&T는 여전히 유닉스를 소유하고 있었으며 이제 이를 판매할 수 있게 되었습니다. AT&T는 공격적인 라이선스 확보에 나섰고, 당시 대부분의 상용 유닉스는 AT&T에서 파생된 제품이 되었습니다. -1990년대 초반에 ATT는 BSD에 관련된 라이선스의 위반으로 UCB에 소송을 제기했습니다. UCB는 ATT가 자사의 제품에 BSD의 향상된 기능을 아무런 승인이나 대가 지불 없이 포함시킨 것을 발견했고, 주로 ATT와 UCB 사이의 기나긴 소송 사건이 잇따라 발생했습니다. 이 기간 동안 UCB의 프로그래머들 중 일부는 BSD에 포함된 ATT 코드를 모두 다시 작성하는 작업에 착수했습니다. 이 작업의 결과로 bsd 4.4-lite라고 불리는 시스템이 만들어졌습니다 (이것은 완전한 시스템이 아니었기 때문에 lite라는 표현이 사용되었습니다; 이는 6개의 핵심적인 ATT 파일이 빠졌기 때문입니다). +1990년대 초, AT&T는 BSD와 관련된 라이선스 위반으로 UCB를 고소했습니다. 이 과정에서 UCB는 AT&T가 BSD로 인한 많은 개선 사항을 승인이나 대가 없이 AT&T의 제품에 통합했다는 사실을 발견했고, AT&T와 UCB 간의 오랜 법정 소송이 이어졌습니다. 이 기간 동안 일부 UCB 프로그래머들은 BSD와 관련된 모든 AT&T 코드를 다시 작성하는 프로젝트에 착수했습니다. 이 프로젝트는 BSD 4.4-lite라는 시스템을 탄생시켰습니다(라이트라고 명명한 것은 6개의 주요 AT&T 파일이 부족해 완전한 시스템이 아니었기 때문입니다). -얼마 후에, Dr. Dobbs의 잡지에 BSD 파생의 386 PC 버전 유닉스를 설명하는 긴 글이 수록되었습니다. 이것은 4.4 lite에 결손된 6개의 파일들을 BSD 라이선스의 것으로 대체한 버전이었습니다. 386BSD라고 이름지어진 이 시스템은 전 UCB 프로그래머인 William Jolitz에 의한 것이었습니다. 이것은 오늘날 사용되는 PC 호환 BSD들의 기본적인 바탕이 되었습니다. +조금 후에 닥터 돕스(Dr. Dobbs) 잡지에 실린 긴 기사 시리즈에서는 누락된 6개의 4.4 라이트 파일에 대한 BSD 라이선스 대체 파일과 함께 BSD 파생 386 PC 버전의 유닉스에 대해 설명했습니다. 386BSD로 명명된 이 시스템은 전직 UCB 프로그래머 윌리엄 졸리츠(William Jolitz)가 만든 것입니다. 이 시스템은 현재 사용 중인 모든 PC BSD의 기반이 되었습니다. -1990년대 중반에, Novell이 ATT의 유닉스에 대한 권리를 인수했고 (그 당시 비밀이었던) 협정에 의해 소송은 종료되었습니다. UCB는 곧 BSD에 대한 지원을 종료했습니다. +1990년대 중반, 노벨(Novell)은 AT&T의 유닉스 권리를 인수했고, 소송을 종료하기로 (당시엔 비밀리에) 합의가 이루어졌습니다. UCB는 곧 BSD에 대한 지원을 종료했습니다. [[current-bsdl]] -== FreeBSD 라이선스와 BSD 라이선스의 현재 상황 +== FreeBSD의 현황과 BSD 라이선스 -지난 몇 년동안 FreeBSD에 적용되어 온 소위 http://www.opensource.org/licenses/bsd-license.php[new BSD license]는 여러분이 프로그램 또는 그 소스를 가지고 무엇이든지 해도 되지만, 아무런 보증도 되지 않으며 저작자 중 아무도 책임지지 않음(즉, 여러분은 아무도 고소할 수 없습니다)을 나타내는 사실상 하나의 선언입니다. 이 new BSD license는 제품의 상용화를 장려하고 있습니다. 어떤 BSD 코드라도 여러분의 코드의 사용 가능성 또는 여러분의 미래의 행동에 아무런 제약을 받지 않고 판매되거나 상용 제품에 포함될 수 있습니다. +지난 몇 년 동안 FreeBSD에 적용된 소위 http://www.opensource.org/licenses/bsd-license.php[new BSD license]는 사실상 프로그램이나 그 소스로 무엇이든 할 수 있지만, 그 어떤 보증도 없고, 어떤 저작자도 책임을 지지 않는다는 선언입니다(기본적으로 누구에게도 소송을 제기할 수 없습니다). 이 새로운 BSD 라이선스는 제품 상용화를 장려하기 위한 것입니다. 모든 BSD 코드는 코드의 가용성이나 향후 행위에 대한 제한 없이 판매되거나 독점 제품에 포함될 수 있습니다. -new BSD 라이선스를 "공공재"와 혼동하지 마십시오. 공공재에 속한 대상 역시 모두가 무료로 사용할 수 있지만, 그것은 소유자가 없습니다. +새로운 BSD 라이선스를 “퍼블릭 도메인”과 혼동하지 마세요. 퍼블릭 도메인의 항목도 누구나 무료로 사용할 수 있지만 소유자가 없습니다. [[origins-gpl]] -== GPL의 기원 +== GPL의 유래 -1980년대 말과 1990년대 초에 유닉스의 미래가 혼란스러웠을 동안, 또 다른 주요 라이선스인 GPL이 개발의 결실을 맺었습니다. +1980년대 말과 1990년대 초, 유닉스의 미래가 매우 혼란스러웠을 때 라이선스를 중요하게 고려한 GPL이 나타났습니다. -Emacs의 개발자인 Richard Stallman이 MIT의 스태프 멤버였을 때, 그의 연구실은 시스템을 직접 개발하는 방식에서 상용 제품을 사용하는 방식으로 바꾸었습니다. Stallman은 그가 합법적으로 시스템을 개선할 수 없다는 사실을 알고 화가 났습니다. (Stallman의 동료들 대다수는 MIT에서 개발하고 라이선스한 소프트웨어를 기반으로 하는 두 회사를 창업하기 위해 떠났습니다; 이 소프트웨어의 소스 코드에 대한 관점에서 의견의 불일치가 있었던 것으로 보입니다). Stallman은 상용 소프트웨어 라이선스에 대한 대안을 마련했고 이를 GPL, "GNU Public License"라고 이름지었습니다. 그는 또한 http://www.fsf.org[Free Software Foundation] (FSF)라고 불리는 비영리 단체를 만들었는데, 이는 상용 라이선스에 종속적이지 않으면서 관련 소프트웨어를 포함하는 완전한 운영 체제 개발을 목표로 했습니다. 이 시스템은 "GNU is Not Unix"라는 뜻의 GNU라고 불렸습니다. +Emacs의 개발자인 리처드 스톨먼(Richard Stallman)은 MIT에서 연구실을 자체 개발 시스템에서 독점 시스템으로 전환할 당시 직원으로 근무하고 있었습니다. 스톨만은 시스템에 사소한 개선 사항을 법적으로 추가할 수 없다는 사실을 알게 되자 화가 났습니다. (스톨만의 동료들 중 다수는 MIT에서 개발하고 MIT가 라이선스를 부여한 소프트웨어를 기반으로 한 두 개의 회사를 설립하기 위해 회사를 떠났는데, 이 소프트웨어의 소스 코드에 대한 접근 권한에 대해 이견이 있었던 것으로 보입니다). 스톨만은 상용 소프트웨어 라이선스에 대한 대안을 고안해냈고 이를 GPL, 즉 “GNU 공중 라이선스”라고 불렀습니다. 또한 그는 비영리 재단인 http://www.fsf.org[자유 소프트웨어 재단](FSF)을 설립하여 모든 관련 소프트웨어를 포함한 전체 운영 체제를 독점 라이선스의 적용을 받지 않는 것으로 개발하고자 했습니다. 이 시스템은 “GNU는 유닉스가 아니다”라는 뜻에서 GNU라고 불렀습니다. -GPL은 표준적인 상용 라이선스의 정반대 역할을 하도록 디자인되었습니다. 이 관점에서, GPL 프로그램에 어떤 수정이라도 가하면 (사용자에게 소스 코드를 제공하도록 요구하는 방식으로) GPL 커뮤니티에 환원해야 하고 GPL 코드를 사용하거나 링크한 프로그램은 모두 GPL 라이선스를 사용해야 합니다. GPL은 소프트웨어가 상용 제품이 되는 것을 막도록 의도하고 있습니다. GPL 본문의 마지막 문단은 다음과 같이 말하고 있습니다: +GPL은 표준 독점 라이선스와 반대되는 개념으로 설계되었습니다. 이를 위해 GPL 프로그램을 수정할 경우 해당 프로그램의 소스를 사용자가 원하면 접근할 수 있도록 GPL 커뮤니티에 환원해야 했고, GPL 코드를 사용하거나 링크하는 모든 프로그램은 GPL에 따라 사용해야 했습니다. GPL은 소프트웨어가 독점적인 소유물이 되는 것을 막기 위한 것입니다. GPL의 마지막 단락에 명시되어 있듯이: -"General Public License는 여러분의 프로그램을 상용 프로그램에 포함시키는 것을 허용하지 않습니다."[1] +“본 일반 공중 사용 허가서는 귀하의 프로그램을 독점 프로그램에 통합하는 것을 허용하지 않습니다.”<<one>> -http://www.opensource.org/licenses/gpl-license.php[GPL]는 복잡한 라이선스이기 때문에 GPL을 사용하는 데에는 몇 가지 원칙이 있습니다: +http://www.opensource.org/licenses/gpl-license.php[GPL]은 복잡한 라이선스이므로 GPL을 사용할 때 지켜야 할 몇 가지 규칙이 있습니다: -* 여러분은 소프트웨어를 배포하고, 지원하고, 관련된 문서에 대해 필요한 요금을 원하는 만큼 책정할 수 있지만, 소프트웨어 그 자체를 판매할 수는 없습니다. -* 프로그램을 컴파일하는 데 GPL 코드가 필요하다면, 그 프로그램은 GPL을 따라야 합니다. GPL 라이브러리에 정적으로 링크된 프로그램도 GPL을 따라야 합니다. -* GPL은 GPL 소프트웨어 및 연관된 모든 개발품을 누구든지 자유롭게 사용할 수 있도록 라이선스할 것을 요구하고 있습니다. -* 단순히 소프트웨어들을 한데 모아 놓는 것은, 예를 들어 여러 프로그램들이 하나의 디스크에 저장되는 경우, GPL 프로그램을 비 GPL 프로그램에 포함시키는 것으로 간주되지 않습니다. -* 프로그램의 출력 결과는 파생 작업으로 간주되지 않습니다. 이는 gcc 컴파일러를 법적 문제 없이 상용 환경에 사용할 수 있도록 해 줍니다. -* 리눅스 커널이 GPL이기 때문에, 리눅스 커널에 정적으로 링크된 코드는 모두 GPL을 따라야 합니다. 동적으로 링크되고 로드할 수 있는 커널 모듈을 통해 이 요구사항을 우회할 수 있습니다. 이 허용은 회사로 하여금 바이너리 드라이버를 배포할 수 있도록 해 주지만, 특정한 버전의 리눅스 커널에서만 동작하게 된다는 단점도 있습니다. +* 소프트웨어 배포, 지원 또는 문서화 비용은 얼마든지 청구할 수 있지만 소프트웨어 자체는 판매할 수 없습니다. +* 일반적인 원칙상, 프로그램을 컴파일하는 데 GPL 소스가 필요한 경우 해당 프로그램은 반드시 GPL에 따라야 합니다. 또한 GPL 라이브러리에 정적으로 링크하려면 프로그램은 GPL을 따라야 합니다. +* GPL에 따르면 GPL 소프트웨어와 관련된 모든 특허는 모든 사람이 자유롭게 사용할 수 있도록 라이선스가 부여되어야 합니다. +* 여러 프로그램을 하나의 디스크에 넣을 때처럼 단순히 소프트웨어를 한데 모으는 것은 GPL이 아닌 프로그램에 GPL이 적용된 프로그램을 포함하는 것으로 간주하지 않습니다. +* 프로그램의 결과물은 2차적 저작물로 간주되지 않습니다. 따라서 gcc 컴파일러는 법적 문제 없이 상업적 환경에서 사용할 수 있습니다. +* Linux 커널은 GPL에 따라 사용되므로 Linux 커널과 정적으로 링크된 모든 코드는 GPL을 준수해야 합니다. 로드 가능한 커널 모듈을 동적으로 링크하면 이 요구 사항을 우회할 수 있습니다. 이를 통해 기업은 바이너리 드라이버를 배포할 수 있지만 특정 버전의 Linux 커널에서만 작동한다는 단점이 있습니다. -이 복잡성 때문에, 오늘날 리눅스 및 그와 연관된 소프트웨어에서는 GPL의 법적 효력이 무시되고 있습니다. 이에 대한 장기적인 결과는 불분명합니다. +부분적으로는 그 복잡성으로 인해 오늘날 전 세계 많은 지역에서 리눅스 및 관련 소프트웨어와 관련된 GPL 적법성이 무시되고 있습니다. 이로 인한 장기적인 파급 효과는 불분명합니다. [[origins-lgpl]] == 리눅스와 LGPL의 기원 -상용 유닉스 전쟁이 벌어지는 동안, 리눅스 커널은 PC 유닉스의 클론으로 개발되었습니다. Linus Torvalds는 리눅스의 탄생에 대한 공로를 GNU C 컴파일러 및 그에 연관된 GNU 도구들에 돌리고 있습니다. 그는 리눅스 커널을 GPL로 만들었습니다. +상업용 유닉스 전쟁이 치열하게 벌어지는 동안 리눅스 커널은 PC 유닉스 클론으로 개발되었습니다. 리누스 토발즈(Linus Torvalds)는 리눅스가 존재할 수 있었던 이유로 GNU C 컴파일러와 관련 GNU 도구의 존재를 꼽습니다. 그는 리눅스 커널을 GPL로 배포했습니다. -GPL은 GPL 코드에 정적으로 링크된 모든 코드 역시 GPL을 따르도록 요구하고 있다는 사실을 기억해 주십시오. 즉 해당 프로그램의 소스 코드가 사용자에게 제공되어야 합니다. 그러나 동적 링크는 GPL 위반으로 간주되지 않습니다. 리눅스에서 상용 프로그램을 사용하는 경우가 점점 더 많아졌습니다. 이러한 프로그램들은 대체로 시스템 라이브러리와 링크되어야 합니다. 이 결과로 http://www.opensource.org/licenses/lgpl-license.php[LGPL] ("Library", 나중에 "Lesser"로 다시 명명된, GPL)라고 하는 GPL의 수정판이 나타났습니다. LGPL은 상용 코드를 GNU C 라이브러리인 glibc와 링크하는 것을 허용합니다. 여러분은 LGPL 라이브러리와 동적으로 링크된 코드를 공개해야 할 의무는 없습니다. +GPL은 GPL에 따라, 어떤 코드에 정적으로 링크하는 모든 것도 GPL에 따를 것을 요구한다는 사실을 기억하세요. 따라서 이 코드의 소스는 프로그램 사용자가 사용할 수 있도록 제공되어야 합니다. 그러나 동적 링크는 GPL 위반으로 간주되지 않습니다. 독점 애플리케이션을 Linux에 설치하라는 압력이 압도적으로 커졌습니다. 이러한 애플리케이션은 종종 시스템 라이브러리와 링크해야 합니다. 그 결과 http://www.opensource.org/licenses/lgpl-license.php[LGPL](“라이브러리”, 이후 “Lesser”, GPL로 이름이 변경됨)라는 수정된 버전의 GPL이 탄생했습니다. LGPL은 독점 코드를 GNU C 라이브러리인 glibc에 링크할 수 있도록 허용합니다. LGPL이 적용된 라이브러리에 동적으로 링크된 소스 코드를 공개할 필요는 없습니다. -만약 여러분이 임베디드 시스템에서 흔히 요구되는 것처럼 프로그램과 glibc를 정적으로 링크하고자 한다면, 해당 프로그램을 사유 재산으로 유지할 수는 없습니다. 즉, 소스 코드는 반드시 공개되어야 합니다. GPL과 LGPL 모두 해당 코드를 직접 수정한 것은 공개하도록 요구하고 있습니다. +임베디드 시스템에서 자주 요구되는 것처럼 애플리케이션을 glibc와 정적으로 링크하는 경우 애플리케이션을 독점적으로 유지할 수 없으므로 소스를 공개해야 합니다. GPL과 LGPL 모두, 라이선스의 관리를 받는 코드를 수정할 경우 이를 공개하도록 요구합니다. [[orphaning]] == 오픈 소스 라이선스와 방치 문제 -사유 소프트웨어와 연관된 중요한 문제들 중 하나는 "방치"(orphaning)이라고 알려져 있습니다. 이는 하나의 이는 하나의 사업 실패나 제품 전략 변경이 피라미드 형태로 이에 종속된 많은 시스템과 회사들을 그들이 대처할 수 있는 범위 너머의 이유로 망하게 할 때 일어납니다. 수십 년에 걸친 경험은 잠깐 성공한 소프트웨어 공급자가 그 소프트웨어를 언제까지나 사용 가능하게 해 주지는 않을 것이라는 사실을 보여 주었습니다. 이는 현재의 시장 조건과 전략이 빠르게 변화할 수 있기 때문입니다. +독점 소프트웨어와 관련된 심각한 문제 중 하나는 ‘방치(Orphaning)’로 알려져 있습니다. 이는 어떤 사업의 실패 또는 제품 전략의 변경이 그에 의존하는 시스템의 거대한 피라미드에 영향을 미치는 것을 말하며, 이로인해 기업이 완전히 통제력을 상실하여 발생할 수도 있습니다. 수십 년간의 경험에 따르면 현재의 시장 상황과 전략은 언제든 급변할 수 있기 때문에 소프트웨어 공급업체의 일시적인 규모나 성공이 해당 소프트웨어의 지속적인 사용을 보장하지 않습니다. -GPL은 사유 지적 재산과의 링크를 막음으로써 방치 현상을 방지하고자 하고 있습니다. +GPL은 독점 지적 재산권과의 연결 고리를 끊어 방치화를 방지하고자 합니다. -BSD 라이선스는 중소기업에게 아무런 법적 의무 또는 비용 없이 소프트웨어를 맡겨 놓는 것과 같은 기능을 합니다. 만약 BSD 라이선스 프로그램의 개발이 중단되면, 회사는 그에 종속적인 프로그램을 단순히 사유 재산을 넘겨받듯 계속 사용할 수 있습니다. 보다 나은 상황은 BSD 라이선스의 코드가 비공식 협회에 의해 유지되는 것입니다. 이러면 개발 과정이 하나의 회사 또는 제품 라인의 생존에 종속적이지 않게 됩니다. 개발 팀이 지속적으로 이어지는 것은 단순히 소스 코드를 얻을 수 있는가의 여부보다 훨씬 더 중요합니다. +BSD 라이선스는 소규모 회사에게 법적 복잡성이나 비용 없이 상용기업에 의해 성능을 보장받는 소프트웨어와 동등한 효과를 제공합니다. 만약 BSD 라이선스를 받은 프로그램이 방치 된다면, 다른 회사가 그 프로그램에 의존하고 있는 프로그램을 독점적인 방식으로 인수할 수 있습니다. 개발 프로세스가 단일 회사나 제품 라인의 생존에 의존하지 않기 때문에, 소규모 비공식 컨소시엄에 의해 BSD 코드베이스가 유지되는 경우 더 나은 상황이 발생합니다. 소스 코드의 단순한 물리적 가용성보다 개발 팀이 정신적으로 그 영역에 있을 때의 생존 가능성이 훨씬 더 중요합니다. [[license-cannot]] -== 라이선스가 할 수 없는 일 +== 라이선스로 할 수 없는 일 -어떠한 라이선스도 미래의 소프트웨어 사용 가능성을 보장해 주지는 않습니다. 저작권자가 언제든지 저작권의 내용을 바꿀 수 있지만, BSD 커뮤니티에서 그러한 시도가 있다면 단순히 소스 코드를 fork하게 됩니다. +어떤 라이선스도 미래의 소프트웨어 가용성을 보장할 수는 없습니다. 저작권자는 전통적으로 언제든지 저작권 조건을 변경할 수 있지만, BSD 커뮤니티에서는 그러한 시도가 단순히 소스를 포크하게 만든다고 가정하고 있습니다. -GPL은 라이선스를 무효로 하는 것을 명시적으로 금지하고 있습니다. 그런데 그것이 실제로 일어났습니다. 회사(Mattel)가 GPL 저작권을 인수(cphack)하고, 저작권 전체를 무효화시킨 뒤, 법정에 가서, 승소한 경우[2]입니다. 즉, 그들은 합법적으로 해당 배포본 전체와 모든 파생물에 대한 저작권을 무효화시켰습니다. 더 크고 널리 퍼져 있는 배포폰에 대해서도 이런 일이 일어날 수 있는지는 알 수 없습니다; 뿐만 아니라 특정 소프트웨어가 진짜 GPL인지에 대한 혼란이 있기도 합니다. +GPL은 라이선스 취소를 명시적으로 허용하지 않습니다. 그러나 한 회사(Mattel)가 GPL 저작권(cphack)을 구입한 후 저작권 전체를 취소하고 법정 소송을 제기하여 승소한 사례가 있습니다<<two>>. 즉, 해당 저작권에 기반한 배포판과 2차 저작물 전체를 합법적으로 취소한 것입니다. 더 크고 분산된 배포판에서도 이런 일이 일어날 수 있을지는 아직 미지수이며, 해당 소프트웨어가 실제로 GPL에 따라 배포되었는지에 대해서도 약간의 혼란이 있습니다. -다른 예시로는, Red Hat이 FSF 컴파일러 또구들의 개발을 인수한 기술 회사인 Cygnus를 인수한 경우가 있습니다. Cygnus는 그들이 GNU 소프트웨어에 대한 지원을 판매하는 사업 모델을 개발했기 때문에 이렇게 할 수 있었습니다. 이는 그들로 하여금 50여 명의 엔지니어들을 고용하고 많은 수정을 할 수 있는 우세함을 통해 프로그램의 개발 방향을 원하는 대로 할 수 있게 하였습니다. Donald Rosenberg가 언급하기를 "GPL과 같은 라이선스를 사용하는 프로젝트들은 누군가 더 나은 코드를 만들어 원 소유자에 비해 빠르게 일을 해나가는 방법을 프로젝트를 손에 넣을지도 모른다는 지속적인 위협 속에서 살아간다." [3] +또 다른 예로, 레드햇(Red Hat)은 FSF 컴파일러 도구 개발을 맡았던 엔지니어링 회사인 시그너스(Cygnus)를 인수했습니다. 시그너스를 인수할 수 있었던 이유는 이 회사가 GNU 소프트웨어에 대한 지원을 상품으로 판매하는 비즈니스 모델을 개발했기 때문입니다. 이를 통해 약 50명의 엔지니어를 고용할 수 있었고, 수정 사항을 주도적으로 제안하여 프로그램의 방향을 변경할 수 있었습니다. 도널드 로젠버그(Donald Rosenberg)는 “GPL과 같은 라이선스를 사용하는 프로젝트는… 누군가 더 나은 버전의 코드를 만들어서 기존 소유자보다 더 빨리 프로젝트를 장악할 수 있다는 끊임없는 위협에 시달리고 있다”고 말합니다. <<three>> [[gpl-advantages]] -== GPL의 장단점 +== GPL의 장점과 단점 -GPL을 사용하는 흔한 이유 중 하나는 gcc 컴파일러를 수정하거나 확장할 때입니다. 이것은 모든 소프트웨어의 비용이 비싼 데 비해 결과로 만들어진 컴파일러를 다른 사람이 사용할 가능성이 거의 없는 CPU를 개발할 때 특히 적합합니다. +GPL을 사용하는 일반적인 경우는 gcc 컴파일러를 수정하거나 확장할 때입니다. 이는 특히 모든 소프트웨어 비용이 오버헤드로 간주될 가능성이 높은 환경에서, 일회성으로 특수한 CPU로 작업할 때와 같이 아주 적은 수의 사람만이 변경된 컴파일러를 사용하는 상황에 적합합니다. -GPL은 CD를 판매하는 작은 회사들에게도 매력적일 수 있습니다. 이윤을 충분히 남기면서도 사용자에게 비싸지 않은 제품을 제공할 수 있습니다. GPL은 또한 GPL 지적 재산에 대한 문서 등의 다양한 기술 지원을 제공하는 회사들에게도 매력적입니다. +GPL은 최종 사용자에게 매우 저렴한 제품을 제공하는 “박리다매” 환경에서 CD를 판매하는 소규모 회사와 같은 곳에 매력적입니다. 또한 GPL이 적용된 지적 재산권 세계에서 문서를 포함한 다양한 형태의 기술 지원을 제공함으로써 생존을 기대하는 기업에게도 매력적입니다. -GPL의 잘 알려지지 않고 의도적이지도 않은 사용은 대기업들이 소프트웨어 회사들의 가치를 싸게 평가하는 데 좋다는 것입니다. 다시 말해, GPL은 잠재적으로 전체의 경제적 이익을 저해하고 독과점에 기여하는 마케팅 무기에 적합합니다. +GPL을 따라 충분히 공개하지 않거나 의도치 않게 GPL을 사용하는 것은 소프트웨어 회사를 약화시키려는 대기업에 매우 유리합니다. 즉, GPL은 마케팅 무기로 사용하기에 적합하여 전반적인 경제적 이익을 감소시키고 독과점 행위에 기여할 수 있습니다. -GPL은 소프트웨어를 상업화하고 이윤을 창출하고자 하는 사람들에게는 현실적인 문제가 될 수 있습니다. 예를 들어, GPL은 대학원생이 자신의 연구 결과를 상업화하기 위해 회사를 차리는 것을 어렵게 하거나, 해당 학생이 연구 결과를 상업화해줄 것으로 기대하는 회사에 입사하는 것을 어렵게 합니다. +GPL은 소프트웨어를 상업화하여 수익을 창출하고자 하는 사람들에게 실질적인 문제를 야기할 수 있습니다. 예를 들어, 대학원생이 자신의 연구 결과를 상용화하기 위해 직접 회사를 설립하거나, 유망한 연구 프로젝트의 상용화를 전제로 회사에 입사하는 데 GPL은 어려움을 가중시킬 수 있습니다. -여러 소프트웨어 표준들의 정적 링크 구현을 사용해야 하는 사람들에게 GPL은 좋지 못한 라이선스인데, 이는 상용으로 구현된 표준의 사용을 막기 때문입니다. 그래서 GPL은 GPL 표준을 사용해야 빌드할 수 있는 프로그램의 수를 최소화하고 있습니다. GPL은 하나의 상용 제품이 표준이 되는 방식을 막으려는 의도를 가지고 있습니다. (리눅스 애플리케이션에는 적용되지 않는데, 이는 그것들이 정적 링크 대신 trap-based API를 사용하기 때문입니다.) +여러 소프트웨어 표준의 정적연결로 구현되는 작업을 하는 사람들에게 GPL은 표준의 독점적 구현을 사용할 수 없기 때문에 좋지 않은 라이선스인 경우가 많습니다. 따라서 GPL은 GPL 표준을 사용하여 만들 수 있는 프로그램의 수를 줄이는 결과를 낳았습니다. GPL은 독점적 제품을 개발하는 표준 메커니즘을 제공하지 않기 때문입니다. (Linux 애플리케이션은 정적으로 링크하지 않고 트랩 기반 API를 사용하기 때문에 적용되지 않습니다.) -GPL은 프로그래머들이 프로그램의 발전에 기여하고, 이들의 배포와 지원으로 경쟁하도록 하는 것을 시도하고 있습니다. 이 상황은 필요한 많은 코어 시스템 표준에는 현실적이지 않은데, 이는 이러한 시스템이 기존의 비 GPL 라이선스 표준으로 상용화되거나 그러한 표준과 결합되는 환경에 적용될 수 있기 때문입니다. 실시간 시스템들은 대개 정적으로 링크되기 때문에, 많은 임베디드 시스템 회사들에게 GPL과 LGPL은 단연코 잠재적 문제점으로 여겨집니다. +GPL은 프로그래머들이 진화하는 프로그램 모음에 기여한 후, 이 모음 배포 및 지원에 경쟁하도록 만듭니다. 이러한 상황은 상업적 커스터마이징이나 기존(non-GPL) 라이선스에 따른 레거시 표준과의 통합이 필요한 매우 다양한 환경에 적용될 수 있는, 많은 필수 핵심 시스템 표준에 대해서는 비현실적입니다. 실시간 시스템은 정적으로 연결되는 경우가 많기 때문에 많은 임베디드 시스템 회사에서는 GPL과 LGPL을 잠재적인 문제로 간주하고 있습니다. -GPL은 연구 및 개발 단계에서, 수요에 관계없이, 노력을 유지시키기 위한 시도입니다. 이는 더 널리 배포하는 데 알 수 없는 비용이 드는 연구자 및 개발자들에게 최대한의 혜택을 제공합니다. +GPL은 수요에 관계없이 연구 및 개발 단계 노력의 가치를 유지하려고 합니다. 이를 통해 연구자와 개발자에게는 혜택을 극대화하고, 더 많은 배포를 통해 혜택을 받을 수 있는 사람들에게는 알 수 없는 비용을 요구합니다. -GPL은 연구 결과가 상용 제품으로 변모하는 것을 막기 위해 고안되었습니다. 이는 고전적인 기술이 마침내 다다르게 되는 종착역과 같으며 이렇게 상용화되는 것을 막는 것은 일반적으로 어렵습니다; GPL은 그러한 과정을 봉쇄하도록 만들어졌습니다. +GPL은 연구 결과가 독점적인 제품으로 전환되는 것을 막기 위해 고안되었습니다. 하지만 이 단계는 전통적인 기술 이전 파이프라인의 마지막 단계로 간주되는 경우가 많으며 이런 과정은 일반적으로 최상의 상황에서도 충분히 어려운 일인데, GPL은 이를 아예 불가능하게 만들었다고 받아들여지고 있습니다. [[bsd-advantages]] == BSD의 장점 -BSD 형식의 라이선스는 장기간의 연구 또는 다음과 같은 개발 환경이 필요한 프로젝트에 이상적입니다: +BSD 스타일 라이선스는 장기간의 연구 또는 개발 환경이 필요한 기타 프로젝트에 적합한 선택입니다: -* 거의 비용이 들지 않는 경우 -* 오랜 기간 동안 발전할 경우 -* 누구나 법적 제약 없이 최종 결과물을 상용화하는 것을 허용하고자 할 경우 +* 거의 비용이 없습니다 +* 오랜 기간에 걸쳐 계속 개선될 수 있습니다 +* 누구나 법적 문제를 최소화하면서 최종 결과물을 상용화할 수 있습니다. -마지막 조건은 가장 지배적인 조항인데, 이는 Apache 프로젝트가 그들의 라이선스에 중점을 둔 사항이기도 합니다: +아파치 프로젝트가 라이선스를 결정할 때와 마찬가지로 이 최종 고려사항이 가장 중요한 부분이 될 수 있습니다: -"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." +“이러한 유형의 라이선스는 공통 서비스를 위한 프로토콜을 구현하는 참조 코드의 사용을 촉진하는 데 이상적입니다. 우리 중 다수는 HTTP가 살아남아 진정한 멀티파티 표준이 되기를 원하며, HTTP의 공용화라는 목표를 달성하는 데 도움이 된다면 Microsoft나 Netscape가 HTTP 엔진이나 우리 코드의 다른 구성 요소를 자사 제품에 통합하는 데 조금도 신경 쓰지 않을 것입니다. 이 모든 것은 전략적으로 볼 때 프로젝트가 계속 충분한 추진력을 유지해야 하며, 참여자들이 자신의 코드를 프로젝트에 기여함으로써 더 큰 가치를 실현할 수 있으며, 심지어 독점적으로 유지되었다면 가치가 있었을 코드도 마찬가지라는 것을 의미합니다.” -개발자들은 BSD 라이선스를 선호하는 경향이 있는데, 이는 그들이 코드를 다룸에 있어 법적 분쟁으로부터 벗어나 그들이 하고 싶은 대로 하도록 허락하기 때문입니다. 반면, 시스템을 개발하기보다 주로 사용할 것으로 예상되는 사람들, 혹은 다른 사람들이 코드를 개선해 주기를 기대하는 사람들, 혹은 (국가 공무원과 같이) 시스템 작업으로 생계를 유지하지는 않는 사람들의 경우 GPL을 선호하는데, 이는 다른 사람이 개발한 코드를 자신이 사용할 수 있고 그들의 상관이 저작권을 가지고 있는 일을 막을 수도 있으며 결과적으로 잠재적으로 소프트웨어를 "무용지물"로 만들거나 방치하지 않도록 할 수 있기 때문입니다. 만약 여러분이 경쟁자로 하여금 여러분을 돕도록 강제하고 싶다면, GPL은 매력적인 선택지가 될 것입니다. +개발자들은 법적인 문제를 피할 수 있고 코드에 대해 원하는 모든 것을 할 수 있다는 점에서 BSD 라이선스가 매력적이라고 생각하는 경향이 있습니다. 반면, 시스템을 프로그래밍하기보다는 주로 시스템을 사용하거나 다른 사람이 코드를 발전시키기를 기대하거나 시스템과 관련된 업무로 생계를 유지하지 않는 사람들(예: 공무원)은 다른 사람이 개발한 코드를 강제로 공개하고 고용주가 저작권을 보유하지 못하게 하여 소프트웨어를 “묻어버리거나” 방치되게 할 수 있는 GPL이 매력적이라고 생각합니다. 경쟁업체의 도움을 받고 싶다면 GPL이 매력적입니다. -BSD 라이선스는 단순한 선물인 것은 아닙니다. "왜 우리는 우리의 경쟁자를 돕거나 그들이 우리가 만든 결과물을 훔쳐 가도록 내버려 두어야 하나요?"라는 질문은 BSD 라이선스에 관련된 질문에서 자주 볼 수 있습니다. BSD 라이선스 하에서, 만약 어떤 회사가 제품 시장을 독점하고 다른 이들이 이를 전략적이었다고 여길 경우, 다른 회사들은 최소한의 노력만으로 시장 경쟁과 공정성을 증대시킬 경쟁 BSD 파생본에 기여하는 작은 협회를 만들 수 있습니다. 이는 각 회사들로 하여금 이것이 제공하는 이점으로부터 이윤을 창출할 수 있을 것이라는 믿음을 주고, 경제적 유연성과 효율성에도 기여할 수 있습니다. 회원들이 더 빠르고 쉽게 이에 협력할수록, 더욱 성공적일 것입니다. BSD 라이선스는 그러한 행동을 가능하게 해 주면서도 가장 덜 복잡한 라이선스입니다. +BSD 라이선스는 단순한 선물이 아닙니다. “왜 우리가 경쟁사를 도와주거나 경쟁사가 우리의 작업을 훔치도록 내버려둬야 하는가?”라는 질문은 BSD 라이선스와 관련하여 자주 제기됩니다. BSD 라이선스 하에서, 한 회사가 다른 회사가 전략적으로 간주하는 제품의 틈새 시장을 장악하게 되면, 다른 회사들은 최소한의 노력으로 시장 경쟁과 공정성을 높이는 경쟁적 BSD 프로젝트에 기여함으로써 동등성을 회복하는 것을 목표로 하는 미니 컨소시엄을 구성할 수 있습니다. 이를 통해 각 회사는 경제적 유연성과 효율성에 기여하면서 자신이 제공할 수 있는 이점을 통해 이익을 얻을 수 있다고 믿습니다. 협력하는 구성원들이 이를 더 빠르고 쉽게 수행할 수 있을수록 더 큰 성공을 거둘 수 있습니다. BSD 라이선스는 본질적으로 이러한 행동을 가능하게 하는 최소한도의 복잡성을 가진 라이선스입니다. -완전하고 경쟁력 있는 오픈 소스 시스템을 단지 저장 매체의 가격만으로 널리 쓸 수 있게 한다는 GPL의 핵심적인 효과는 합리적인 목표입니다. BSD 형식의 라이선스는, 협회 창설을 통한 개인의 연합을 통해, 기술 개발 과정에 대한 경제적 기대를 저버리지 않고 이 목표를 달성할 수 있습니다. +완전하고 경쟁력 있는 오픈 소스 시스템을 미디어 비용(배포 비용)으로 널리 사용할 수 있도록 하는 것은 GPL의 핵심 효과이며, 이는 합리적인 목표입니다. BSD 스타일의 라이선스는 개인들로 구성된 임시 컨소시엄과 함께 기술 이전 파이프라인의 배포-종료 단계에 구축된 경제적 예상을 파괴하지 않으면서도 이러한 목표를 달성할 수 있습니다. [[recommendations]] -== BSD 라이선스를 사용하면 좋은 경우 +== BSD 라이선스 사용에 대한 구체적 권장사항 -* BSD 라이선스는 연구 결과를 널리 배포하고 경제적 이윤을 창출할 수 있도록 하는 데 적합합니다. 그것으로서, NSF, ONR 그리고 DARPA와 같은 연구 개발 기관은 자금을 투자받은 프로젝트의 초기 단계 연구를 위해 소프트웨어, 데이터, 결과, 그리고 오픈 하드웨어에 BSD 형식의 라이선스를 적용할 것을 장려해야 합니다. 그들은 또한 오픈 소스 시스템 구현과 진행중인 오픈 소스 프로젝트를 기반으로 표준을 정할 것을 장려해야 합니다. -* 정부 정책은 비용과 연구 결과를 실무에 적용할 때의 어려움을 최소화해야 합니다. 가능하다면, 연구 결과를 상용화에 친화적인 BSD 형식의 라이선스로 사용 가능하게 할 것을 요구해야 합니다. -* 많은 경우에, 저작권 또는 특허에 의해 상용 대학 라이선스에 종속되는 것보다 BSD 형식 라이선스의 형식을 취하는 것이 장기적으로 보았을 때 대학의 연구 목표에 더 근접합니다. 대학 입장에서는 장기적으로 보았을 때 연구 결과를 공개하고, 경제적으로 성공한 졸업생들에 의해 기부받는 것이 금전적으로 더 이득이 되는 실제적인 사례들이 존재합니다. -* 회사들은 사실상의 표준을 만드는 것이 마케팅 기술의 핵심이 된다는 것을 오랜 경험에 걸쳐 알아왔습니다. 만약 회사가 시스템을 발전시키는 데 독특한 강점이 있다면, BSD 라이선스는 이 역할을 잘 수행합니다. 라이선스는 회사의 전문 기술 덕분에 그들이 통제할 수 있으면서도 많은 사람들에게 법적인 관점에서 매력적입니다. 다른 사람들을 방해하거나 그들의 것을 빼앗고자 할 목적으로 그러한 표준을 만드는 경우 GPL은 적절한 선택이 될 수 있습니다. 그러나 GPL은 상용으로 적용 가능한 표준을 지향하지 않고 방해합니다. 그러한 GPL suite를 사용하는 것은 지속적으로 상용화와 법률 상의 문제를 발생시킵니다. GPL 표준과 그렇지 않은 것을 함께 활용하는 것은 대개 가능하지 않습니다. 진정한 기술 표준은 기술적이지 않은 이유 때문에 다른 표준을 배제할 것을 강제해서는 안 됩니다. -* 다른 회사들의 상용 제품의 핵심이 될 수 있는 표준을 개발하고 장려하는 데 관심이 있는 회사는 GPL에 대해 조심해야 합니다. 사용된 라이선스에 관계없이, 결과가 되는 소프트웨어는 기술적인 변화의 대부분과 시스템의 상태를 가장 잘 아는 사람들에게 맡겨질 것입니다. GPL은 단지 결과에 추가적인 법적 제약을 가할 뿐입니다. -* 오픈 소스 코드를 개발하는 큰 회사는 오픈 소스를 옹호하는 프로그래머를 조심해야 하는데, 이는 그들이 다른 곳으로 이직할 경우에도 여전히 그 소프트웨어를 사용할 수 있기 때문입니다. 일부 회사들은, 특히 해당 소프트웨어가 핵심 전략에 직접적으로 연관되어 있지 않을 때, 이러한 행동을 직원들의 특권으로써 장려합니다. 이는 사실 직접적인 비용 손실 없이 잠재적인 기회 비용만을 잃는 퇴직 혜택입니다. 직원을 회사 외부를 위해 일하도록 장려하는 것은 종종 회사가 손해 없이 제공할 수 있는 간단한 혜택이 되기도 합니다. -* 소프트웨어가 방치될 것이 걱정되는 작은 개발 회사는, 가능하다면 BSD 라이선스를 사용하는 것을 고려해볼 필요가 있습니다. 회사들은 그 규모에 관계없이 BSD 형식 오픈 소스 프로젝트를 구성함으로써 법적인, 그리고 구조적인 간접 비용을 최소화하는 상호간의 이익을 도모할 수 있습니다. -* 비영리단체들은 가능하다면 오픈 소스 프로젝트에 참여해야 합니다. 서로 다른 라이선스의 코드를 함께 사용하는 것과 같은 소프트웨어상의 문제를 최소화하기 위해, BSD 형식의 라이선스가 장려되어야 합니다. 소프트웨어 개발과 밀접하게 관련있는 비영리단체는 GPL을 더욱 경계해야 할 것입니다. 법률을 적용하는 일이 많은 비용을 요구하는 일부 지역에서는, GPL에 비해 단순한 BSD 라이선스가 고려해볼 만한 이점이 될 것입니다. +* BSD 라이선스는 연구 결과를 널리 배포하고 경제에 가장 큰 혜택을 줄 수 있는 방식으로 이전하는 데 바람직합니다. 따라서 NSF, ONR, DARPA와 같은 연구자금 지원 기관은 자금 지원 연구 프로젝트의 초기 단계에서 소프트웨어, 데이터, 결과물, 개방형 하드웨어에 BSD 스타일의 라이선스를 채택하도록 장려해야 합니다. 또한 구현된 오픈 소스 시스템과 진행 중인 오픈 소스 프로젝트를 중심으로 표준을 형성하도록 장려해야 합니다. +* 정부 정책은 연구에서 배포로 이동하는 데 드는 비용과 어려움을 최소화해야 합니다. 가능한 경우, 지원금은 상업화 친화적인 BSD 스타일의 라이선스에 따라 결과를 사용할 수 있도록 요구해야 합니다. +* 많은 경우, BSD 스타일 라이선스의 장기적인 결과는 연구 결과가 저작권이나 특허로 보호되고 대학의 독점적인 라이선스를 따를 때보다 대학의 연구 헌장에 명시된 목표를 더 정확하게 반영합니다. 연구 결과를 공개하고 상업적으로 성공한 동문들의 기부에 호소함으로써 대학이 장기적으로 재정적으로 더 나은 보상을 받는다는 일화가 존재합니다. +* 기업들은 사실상의 표준을 만드는 것이 중요한 마케팅 기법이라는 것을 오랫동안 인식해 왔습니다. 기업이 시스템을 발전시키는 데 있어 남들과 차별되는 이점을 가지고 있다면 BSD 라이선스는 이러한 특징에 잘 부합됩니다. 이 라이선스는 법적으로 더 많은 사람들에게 매력적으로 다가갈 수 있으며, 회사가 가진 전문성을 통해 회사의 통제권을 보장할 수 있습니다. 만약 누군가가 기술 표준을 훼손하거나 다른 표준을 채택하려고 할 때, GPL은 그러한 행동에 이용할 수 있는 적합한 수단이 될 수 있습니다. 그러나 GPL은 상업적으로 적용 가능한 표준이 아닌 제품군을 장려하기 때문에 장기적으론 해당 표준의 개선에 불이익을 줍니다. 이러한 제품군을 사용하면 상업화 및 법적 문제가 지속적으로 제기됩니다. 또한 어떤 표준은 GPL을 따르고 어떤 표준은 그렇지 않은 경우 표준을 혼합하는 것이 불가능할 수도 있습니다. 진정한 기술 표준은 비기술적인 이유로 다른 표준을 배제하도록 요구해서는 안 됩니다. +* 다른 회사의 상용 제품의 핵심이 될 수 있는 진화하는 표준을 홍보하는 데 관심이 있는 기업은 GPL을 주의해야 합니다. 어떤 라이선스를 사용하든, 결과물인 소프트웨어는 일반적으로 엔지니어링 변경의 대부분을 실제로 수행하고 시스템 상태를 가장 잘 이해하는 사람에게 귀속됩니다. GPL은 결과물에 법적 마찰을 더할 뿐입니다. +* 오픈 소스 코드를 개발하는 대기업은 직원이 이직을 하더라도 그 소프트웨어를 계속 사용할 수 있기 때문에 프로그래머들이 오픈 소스를 높이 평가한다는 사실을 인지해야 합니다. 일부 기업에서는 특히 관련된 소프트웨어가 직접적으로 전략적이지 않은 경우 이러한 행동을 고용 특전으로 장려하기도 합니다. 이는 사실상 잠재적인 기회 비용 손실은 있지만 직접적인 비용은 들지 않는 선급 퇴직금과 같습니다. 직원들이 회사 밖에서 동료들의 찬사를 받기 위해 일하도록 장려하는 것은 때때로 회사에게 있어선 거의 단점이 없는 값싼 이동식 혜택을 제공할 수 있습니다(역자 주: 원문에서 “cheap portable benefit”이라고 표현한 것은, 아무래도 회사가 직원을 타 회사에서 데려 왔을때 단순히 그 직원이 개발한 소프트웨어를 마음대로 쓸 수 있다는 뜻 보다는, 향후 그 소프트웨어가 업그레이드 될 때의 이득과 직원의 기술력까지 완전히 다 얻을 수 있다는 의미로 쓰인 것 같습니다). +* 방치되기 쉬운 소프트웨어 프로젝트를 가진 소규모 회사는 가능하면 BSD 라이선스를 사용해야 합니다. 회사의 규모가 어떻든 모든 회사는 진정한 BSD 스타일의 오픈 소스 프로젝트 형태의 프로젝트를 통해 최소한의 법적 및 조직 오버헤드를 유지할 수 있어 서로에게 이득이 되므로 이런 방법에 대해 진지한 고려를 해야 합니다. +* 비영리 단체는 가능하면 오픈소스 프로젝트에 참여해야 합니다. 서로 다른 라이선스 하의 코드 혼용과 같은 소프트웨어 엔지니어링 문제를 최소화하려면 BSD 스타일의 라이선스를 권장해야 합니다. 특히 개발도상국과 교류하는 비영리 단체의 경우 GPL을 주의 깊게 살펴야 합니다. 법 적용에 많은 비용이 드는 일부 지역에서는 GPL에 비해 새로운 BSD 라이선스의 단순성이 상당한 이점이 될 수 있습니다. [[conclusion]] -== 맺음말 +== 결론 -오픈 소스 코드의 상용화를 막기 위해 만들어진 GPL과는 달리, BSD 라이선스는 미래의 행동에 최소한의 제약만을 가합니다. 이는 프로젝트나 회사의 필요에 따라 BSD 코드를 오픈 소스로 유지하거나 상용 솔루션에 사용될 수 있도록 허락합니다. 다시 말해서, BSD 라이선스는 개발 과정에서 법적인 시한 폭탄이 되지 않습니다. +오픈 소스 코드의 독점적인 상업화를 방지하기 위해 고안된 GPL과 달리, BSD 라이선스는 향후 행위에 대해 최소한의 제한을 두고 있습니다. 따라서 프로젝트나 회사의 필요에 따라 BSD 코드를 오픈소스로 유지하거나 상용 솔루션에 통합할 수 있습니다. 다시 말해, BSD 라이선스는 개발 과정의 어느 시점에서도 법적 시한폭탄이 되지 않습니다. -더불어 BSD 라이선스는, GPL이나 LGPL 라이선스와는 달리 복잡한 법적 의무가 주어지지 않기 때문에, 개발자와 회사가 라이선스 위반 여부에 대해 걱정하는 대신 좋은 코드를 작성하고 홍보하는 데 집중할 수 있도록 해 줍니다. +또한, BSD 라이선스는 GPL이나 LGPL 라이선스처럼 법적 복잡성을 수반하지 않기 때문에, 개발자와 회사는 라이선스 위반 여부를 걱정할 필요 없이 좋은 코드를 만들고 홍보하는 데 시간을 할애할 수 있습니다. [[addenda]] -== 추가 정보 +[bibliography] +== 참고 문헌 -[.programlisting] -.... +* [[[one,1]]] http://www.gnu.org/licenses/gpl.html -[1] http://www.gnu.org/licenses/gpl.html +* [[[two,2]]] http://archives.cnn.com/2000/TECH/computing/03/28/cyberpatrol.mirrors/ -[2] http://archives.cnn.com/2000/TECH/computing/03/28/cyberpatrol.mirrors/ +* [[[three,3]]] Open Source: the Unauthorized White Papers, Donald K. Rosenberg, IDG Books, 2000. Quotes are from page 114, "Effects of the GNU GPL". -[3] Open Source: the Unauthorized White Papers, Donald K. Rosenberg, IDG Books, - 2000. Quotes are from page 114, ``Effects of the GNU GPL''. +* [[[four,4]]] In the "What License to Use?" section of http://www.oreilly.com/catalog/opensources/book/brian.html -[4] In the "What License to Use?" section of - 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 -.... +이 백서는 http://alumni.cse.ucsc.edu/~brucem/open_source_license.htm에서 제공되는 원본 저작물을 요약한 것입니다 |