본문으로 이동

카피레프트

위키백과, 우리 모두의 백과사전.
(카피 레프트에서 넘어옴)
Capital letter C flipped around its vertical axis, surrounded by a single line forming a circle.
카피레프트 기호

카피레프트(영어: copyleft) 또는 저좌권(著佐權)은 저작권이 있는 저작물의 복사본에 대해 일정한 자유를 부여하면서, 그와 동일한 권리가 2차적저작물에도 유지되어야 한다는 요구 조건을 포함하는 법적 기법이다. 이러한 의미에서 자유란 저작물을 어떠한 목적으로든 사용할 수 있는 것, 그리고 비용 발생 여부와 관계없이 저작물을 수정, 복제, 공유 및 재배포할 수 있는 능력을 의미한다. 카피레프트를 구현하는 면허는 소프트웨어부터 문서, 예술, 과학적 발견에 이르기까지 다양한 저작물의 저작권 조건을 유지하는 데 사용될 수 있다. 유사한 접근 방식이 특허의 일부에도 적용되었다.[1]

카피레프트 소프트웨어 사용권은 (퍼미시브 라이선스와는 대조적으로) 보호적이거나 상호적이라고 간주된다.[2] 이들은 소프트웨어를 복제하고 수정하는 데 필요한 정보를 소프트웨어 수령자에게 제공할 것을 요구한다. 이러한 정보는 대개 라이선스 조항의 사본을 포함하고 코드 작성자를 명시하는 소스 코드 파일의 형태를 띤다. 카피레프트 라이선스는 저작물의 작성자가 사용자에게 부여한 권리가 해당 저작물(또는 수정된 버전)이 재배포될 때 동일하게 유지되도록 설계되었다.

대표적인 카피레프트 라이선스로는 리처드 스톨먼이 작성하고 광범위하게 사용된 최초의 소프트웨어 카피레프트 라이선스인 GNU 일반 공중 사용 허가서(GPL), 모질라 공용 허가서, 프리 아트 라이선스, 그리고 크리에이티브 커먼즈의 동일조건변경허락 조건이 있으며, 마지막 두 가지는 학술적이거나 예술적인 성격의 문서나 그림과 같은 비소프트웨어 저작물을 대상으로 한다.[3] 위키백과는 크리에이티브 커먼즈 저작자표시-동일조건변경허락 라이선스에 따라 카피레프트를 적용하고 있다.[4]

역사

[편집]

리첸 왕의 인텔 8080용 팔로알토 타이니 베이직(Tiny BASIC)은 1976년 5월 닥터 돕스 저널에 등장했다. 이 목록은 제목, 저자 이름, 날짜로 시작하지만 "@COPYLEFT ALL WRONGS RESERVED"라는 문구도 포함하고 있다.[3][5]

카피레프트라는 개념은 1985년 리처드 스톨먼의 GNU 선언문에서 다음과 같이 기술되었다.[6]

GNU는 퍼블릭 도메인이 아니다. 모든 사람은 GNU를 수정하고 재배포할 수 있지만, 어떤 배포자도 추가적인 재배포를 제한할 수 없다. 다시 말해, 독점적인 수정은 허용되지 않는다. 나는 GNU의 모든 버전이 자유롭게 유지되기를 바란다.

스톨먼의 동기는 몇 년 전 그가 리스프 인터프리터를 작업했을 때였다. 심볼릭스는 그 리스프 인터프리터를 사용하게 해달라고 요청했고, 스톨먼은 자신의 작업물을 퍼블릭 도메인 버전으로 제공하기로 동의했다. 심볼릭스는 리스프 인터프리터를 확장하고 개선했으나, 스톨먼이 심볼릭스가 개선한 인터프리터에 접근하려 했을 때 심볼릭스는 이를 거부했다. 이에 스톨먼은 1984년 소프트웨어 사재기(software hoarding)라고 명명한 사유 소프트웨어의 행태와 문화를 근절하기 위해 작업에 착수했다. 스톨먼이 사유 소프트웨어를 다룬 것이 이번이 처음은 아니었으나, 그는 이 사건을 "전환점"으로 간주했다. 그는 온라인상의 소프트웨어는 원본의 손실 없이 복사될 수 있다고 주장하며 소프트웨어 공유를 정당화했다. 소프트웨어는 손상되거나 닳지 않고 여러 번 사용될 수 있기 때문이다.[7][8]

스톨먼은 단기적으로 현행 저작권법과 그로 인해 영속되는 폐단을 없애는 것이 비현실적이라고 판단하여, 기존 법률 체계 내에서 일하기로 결심했다. 1985년,[9] 그는 자신의 저작권 라이선스인 '이맥스 일반 공중 사용 허가서(Emacs General Public License)'를 만들었는데,[10] 이것이 최초의 카피레프트 라이선스였다. 이는 이후 GNU 일반 공중 사용 허가서로 발전하여 현재 가장 인기 있는 자유 소프트웨어 라이선스 중 하나가 되었다. 최초로 저작권 보유자가 프로그램의 원본에 어떤 후속 수정이 이루어지든 상관없이 사용자에게 최대의 권리가 영구적으로 이전되도록 조치를 취한 것이다. 이 초기 GPL은 일반 대중에게 권리를 부여한 것이 아니라 이미 프로그램을 받은 사람들에게만 권리를 부여했지만, 당시 현행법 하에서 할 수 있는 최선이었다.

당시에는 이 새로운 라이선스에 카피레프트라는 명칭이 붙지 않았다.[11] 리처드 스톨먼은 "카피레프트"라는 용어는 1984년이나 1985년에 돈 홉킨스가 보낸 편지에서 유래했다고 밝혔는데, 그 편지에는 "Copyleft – All Rights Reversed"라고 적혀 있었다. 이는 일반적인 저작권 포기 문구인 "All rights reserved"를 이용한 언어유희이다.[11]

프랑스에서는 2000년 "Copyleft Attitude"라는 제목으로 일련의 모임이 열려 프리 아트 라이선스(FAL)가 탄생했다.[12] 이 라이선스는 베른 협약의 구속을 받는 모든 관할 구역에서 이론적으로 유효하며, 스톨먼의 자유 소프트웨어 재단에서도 권장한다.[13] 그 직후, 미국에서 별개의 무관한 이니셔티브를 통해 크리에이티브 커먼즈 라이선스가 나왔으며, 2001년부터 퍼미시브(BY) 및 카피레프트(BY-SA) 변형으로 제공되어 미국 법에 더 구체적으로 맞추어졌다.

원칙

[편집]

자유

[편집]

저작권법이 소프트웨어 작성자에게 저작물의 복제, 배포 및 수정에 대한 통제권을 부여한다면, 카피레프트의 목표는 저작물의 모든 사용자에게 이러한 모든 활동을 수행할 자유를 주는 것이다. 자유 소프트웨어의 정의는 소프트웨어 사용의 "네 가지 핵심 자유"를 나열한다:[7][14]

  • 어떤 목적으로든 원하는 대로 프로그램을 실행할 자유 (자유 0).
  • 프로그램이 어떻게 작동하는지 연구하고, 원하는 대로 컴퓨팅을 수행하도록 변경할 자유 (자유 1). 이를 위해 소스 코드에 대한 접근이 전제되어야 한다.
  • 다른 사람을 도울 수 있도록 복사본을 재배포할 자유 (자유 2).
  • 수정된 버전을 다른 사람에게 배포할 자유 (자유 3). 이를 통해 전체 커뮤니티가 사용자의 변경 사항으로부터 혜택을 받을 기회를 줄 수 있다. 이를 위해 소스 코드에 대한 접근이 전제되어야 한다.

유사한 조건이 별도의 정의인 오픈 소스의 정의에도 존재하며, 여기에도 비슷한 자유가 포함되어 있다. 대부분의 카피레프트 라이선스는 자유 소프트웨어의 정의와 오픈 소스의 정의를 모두 만족한다.[7] 저작물의 시청자와 사용자에게 복제, 개작 또는 배포할 수 있는 자유와 허가를 보장함으로써, 카피레프트 라이선스는 이러한 자유를 제한하는 다른 유형의 저작권 라이선스와 구별된다.

상호성

[편집]

저작물을 저작권 주장이 없는 퍼블릭 도메인으로 완전히 방치하는 대신, 카피레프트는 작성자가 저작물 사용에 대한 제한을 가할 수 있도록 한다. 카피레프트가 부과하는 주요 제한 사항 중 하나는 파생 저작물 또한 호환되는 카피레프트 라이선스 하에 공개되어야 한다는 점이다.[7]

이는 다른 사람의 이전 작업으로부터 누구나 자유롭게 혜택을 받을 수 있지만, 그 작업에 대한 수정 사항도 다른 모든 사람에게 혜택을 주어야 하며 따라서 유사한 조건으로 공개되어야 한다는 카피레프트의 근본 원칙 때문이다. 이러한 이유로 카피레프트 라이선스는 상호적 라이선스로도 알려져 있다. 카피레프트 라이선스 저작물을 수정하는 사람은 원작자가 소프트웨어에 카피레프트를 적용한 행동에 대해 자신들이 만든 파생물도 카피레프트 라이선스를 적용함으로써 보답할 것으로 기대된다. 이러한 요구 사항 때문에 카피레프트 라이선스는 자기 영속적인 조항으로 인해 "바이러스성(viral)"이라고 묘사되기도 한다.[15]

복제에 대한 제한 외에도 카피레프트 라이선스는 다른 가능한 장애물을 다룬다. 권리가 나중에 취소될 수 없음을 보장하며, 저작물과 그 파생물이 추가 수정이 가능한 형태로 제공될 것을 요구한다. 소프트웨어의 경우, 이는 파생 저작물의 소스 코드가 소프트웨어 자체와 함께 제공되어야 함을 의미한다.[7]

경제적 유인

[편집]

카피레프트 저작물을 작업하는 데 따르는 경제적 유인은 다양할 수 있다. 저작권법은 원래 작성자에게 경제적 이익을 장려함으로써 진보를 촉진하려는 의도로 만들어졌다. 카피레프트를 선택할 때 작성자는 동료들로부터의 인정과 같은 보완적인 이익을 추구할 수 있다.

컴퓨터 프로그래밍 세계에서 카피레프트 라이선스가 적용된 컴퓨터 프로그램은 종종 개발자가 느낀 필요를 충족하기 위해 만들어진다. 이러한 프로그램은 후속 사용자가 수정된 버전을 자유롭게 사용할 수 있도록 보장하기 위해 단순히 카피레프트 라이선스로 공개되는 경우가 많다. 이는 특히 사유화, 즉 자유 소프트웨어를 재사용하고 추가적인 제한을 덧붙이는 행위를 방지하고자 하는 작성자에게 해당된다. 엘라스틱[16]과 같은 일부 기업은 상업적 기업이 자사 제품을 사용한 뒤 독점 라이선스 하에 판매하는 것을 방지하는 것도 유인이 된다고 생각한다.

더 나아가, 프로그래밍의 오픈 소스 문화는 개인의 기여에 의해 사회적 힘이 결정되는 선물 경제로 묘사되어 왔다.[17] 수준 높은 오픈 소스 카피레프트 라이선스 소프트웨어를 만들거나 기여하는 것은 기여자가 귀중한 경험을 얻게 하여 향후 경력 기회로 이어질 수 있다.[18]

카피레프트 소프트웨어는 개별 작성자를 넘어 경제적 효과를 미친다. 수준 높은 카피레프트 소프트웨어의 존재는 사유 소프트웨어 개발자가 자유 소프트웨어와 경쟁하기 위해 자사 소프트웨어의 품질을 높이도록 강제할 수 있다.[19] 이는 또한 사유 소프트웨어가 지배하는 영역에서 독점을 방지하는 효과가 있을 수 있다. 그러나 사유 소프트웨어와의 경쟁이 카피레프트를 포기하는 이유가 되기도 한다. 자유 소프트웨어 재단은 자유 데이터 형식을 구현하는 라이브러리처럼 확고한 사유 형식과 경쟁하는 특별한 상황에서, "사유 애플리케이션 개발자가 자유 형식을 위해 라이브러리를 사용하도록 설득하려면, 라이선스를 느슨하게 설정하여 사용하기 쉽게 만들어야 할 것"이라고 권장한다.[20].

적용

[편집]

카피레프트를 사용하는 일반적인 관행은 저작물의 복제 조건을 라이선스로 명문화하는 것이다. 그러한 라이선스는 일반적으로 카피레프트의 모든 조항과 원칙을 라이선스 조건 내에 포함한다. 여기에는 저작물을 사용, 연구, 복제 및 공유하고, 저작물을 수정하며, 비용 발생 여부와 관계없이 원본 또는 수정된 버전을 배포할 자유가 포함된다.[21][22]

이러한 자유를 부여하는 유사한 퍼미시브 라이선스와 달리, 카피레프트 라이선스는 카피레프트 라이선스가 적용된 저작물의 수정 버전 역시 이러한 자유를 보장하도록 한다. 따라서 카피레프트 라이선스에는 조건이 있다. 카피레프트 라이선스 하에 라이선스된 저작물의 수정본은 호환되는 카피레프트 체계 하에 배포되어야 하며, 배포된 수정 저작물은 해당 저작물을 수정할 수 있는 수단을 포함해야 한다. 그러나 공정 이용 하에서는 일반 저작권과 마찬가지로 카피레프트 라이선스가 대체될 수 있다. 따라서 카피레프트 라이선스가 적용된 소스를 사용하여 자신이 발명한 저작물을 만드는 사람은 공정 이용 기준을 충족한다면 다른 라이선스를 자유롭게 선택할 수 있다.[23]

카피레프트 라이선스는 조항을 강제하기 위해 관련 규칙과 법률을 창의적으로 사용한다. 예를 들어 저작권법을 사용할 때 카피레프트 하에 저작물에 기여하는 사람들은 일반적으로 저작권자 지위를 획득하거나, 양도하거나, 위임해야 한다. 카피레프트 라이선스 하에 자신의 기여에 대한 저작권을 제출함으로써, 그들은 저작물의 유일한 배포자가 될 권리를 포함하여 일반적으로 저작권에서 발생하는 일부 권리를 의도적으로 포기한다.

카피레프트 라이선스에 사용되는 일부 법률은 국가마다 다르며 국가마다 다르게 부여될 수 있다. 예를 들어, 일부 국가에서는 (표준 GNU 일반 공중 사용 허가서 방식처럼) 보증 없이 소프트웨어 제품을 판매하는 것이 허용되지만, 대부분의 유럽 국가에서는 소프트웨어 배포자가 판매된 제품에 관한 모든 보증을 면제하는 것이 허용되지 않는다. 이러한 이유로 그러한 보증의 범위는 유럽 연합 공용 허가서(EUPL)[24]나 CeCILL 라이선스[25]와 같은 대부분의 유럽 카피레프트 라이선스에 명시되어 있으며, 후자는 제한적 보증과 함께 GNU GPL 코드를 사용할 수 있게 하는 라이선스이다.

네트워크를 통해 실행될 프로젝트의 경우, GNU GPL의 변형인 GNU 아페로 일반 공중 사용 허가서(GNU AGPL)가 네트워크를 통해 소프트웨어를 사용하는 사용자에게 소스 코드를 제공하도록 보장한다.

유형 및 다른 라이선스와의 관계

[편집]
자유 비자유
퍼블릭 도메인 & 기타 대응 퍼미시브 라이선스카피레프트 (보호적 라이선스)비상업적 라이선스사유 라이선스영업 비밀
설명 모든 권리 부여재라이선스 권리를 포함한 사용권 부여 (사유화 허용, 라이선스 호환성)사용권 부여, 사유화 금지비상업적 사용에 대해서만 권리 부여. 동일조건변경허락과 결합될 수 있음.저작권의 전통적 사용; 특정 권리는 부여될 수도, 그렇지 않을 수도 있음공개된 정보 없음
소프트웨어의 경우 PD, 언라이선스, CC0BSD, MIT, ApacheGPL, AGPL, EUPLJRL, AFPL사유 소프트웨어, 공개 라이선스 없음비공개, 내부 소프트웨어
기타 창작물의 경우 PD, CC0CC BYCC BY-SA, FALCC BY-NC저작권, 공개 라이선스 없음, CC BY-ND
🄎
카피레프트 기호의 변형인 크리에이티브 커먼즈 동일조건변경허락 아이콘

카피레프트는 일부 자유 소프트웨어 라이선스의 특징이지만, 다른 자유 소프트웨어 라이선스는 라이선스 취득자에게 2차적저작물을 동일한 라이선스 하에 배포하도록 요구하지 않기 때문에 카피레프트 라이선스가 아니다. 어떤 부류의 라이선스가 더 큰 자유를 제공하는지에 대해서는 논쟁이 계속되고 있다. 이 논쟁은 자유의 정의와 누구의 자유가 더 중요한가와 같은 복잡한 문제에 달려 있다. 즉, 저작물의 잠재적 미래 수령자(사유화로부터의 자유)인가, 아니면 초기 수령자(사유화할 자유)인가의 문제이다. 그러나 현행 저작권법과 카피레프트 및 퍼미시브 라이선스의 가용성은 작성자가 자신이 발명한 저작물에 어떤 라이선스를 적용할지 선택할 수 있게 한다.

문서, 예술 및 소프트웨어와 코드를 제외한 기타 저작물의 경우, 크리에이티브 커먼즈 동일조건변경허락 라이선스 시스템과 GNU 자유 문서 사용 허가서(GFDL)는 작성자가 저작물의 특정 섹션에 제한을 적용하여 저작물 일부를 완전한 카피레프트 메커니즘에서 제외할 수 있도록 한다. GFDL의 경우, 이러한 제한에는 미래 편집자가 변경할 수 없는 불변 섹션 사용이 포함된다. GFDL의 초기 의도는 카피레프트화된 소프트웨어의 문서화를 지원하는 장치였다. 그러나 결과적으로는 모든 종류의 문서에 사용될 수 있게 되었다.

강한 카피레프트와 약한 카피레프트

[편집]

저작물을 규율하는 카피레프트 라이선스의 강도는 해당 조항이 모든 종류의 2차적저작물에 부과될 수 있는 범위에 의해 결정된다. 따라서 "약한 카피레프트"라는 용어는 모든 2차적저작물이 카피레프트 라이선스를 상속받지는 않는 라이선스를 의미한다. 2차적저작물이 상속받는지 여부는 대개 어떻게 파생되었는지에 달려 있다.

"약한 카피레프트" 라이선스는 소프트웨어 라이브러리를 다루는 데 자주 사용된다. 이는 다른 소프트웨어가 라이브러리에 링크되고, 링크하는 소프트웨어까지 동일한 조건으로 라이선스될 필요 없이 재배포될 수 있게 한다. 오직 "약한 카피레프트" 라이선스 하에 있는 소프트웨어에 대한 변경 사항만이 해당 라이선스의 카피레프트 조항의 대상이 된다. 이를 통해 모든 라이선스의 프로그램이 glibc와 같은 카피레프트 라이브러리에 대해 컴파일 및 링크되고, 라이선스 재설정 없이 재배포될 수 있다. 강한 카피레프트 대 약한 카피레프트의 구체적인 효과는 아직 법정에서 시험된 바 없다.[26] "약한" 카피레프트를 사용하는 자유 소프트웨어 라이선스로는 GNU 약소 일반 공중 사용 허가서와 모질라 공용 허가서가 있다.

GNU 일반 공중 사용 허가서는 강한 카피레프트를 구현하는 라이선스의 예이다. 더 강한 카피레프트 라이선스로는 AGPL이 있는데, 이는 서비스형 소프트웨어 사용 사례에 대해 소스 코드 공개를 요구한다.[27][28][29][30]

서비스형 소프트웨어 사용 사례도 다루는 유럽 연합 공용 허가서(EUPL)는 적절히 카피레프트적인 것을 주장한다. 즉, 원본 저작물에는 강하지만 결합된 2차적저작물에는 더 약하다. 포함된 코드가 호환되는 라이선스 하에 배포된 코드와 병합될 경우, 후자가 사용될 수 있다. EUPL에 항상 적용되는 컴퓨터 프로그램 지침에 따르면, 링크를 통해 결합이 이루어질 경우 링크된 구성 요소의 라이선스에 카피레프트 영향을 미치지 않는다.[31]

사이베이스 오픈 왓콤 퍼블릭 라이선스(Sybase Open Watcom Public License)는 카피레프트 라이선스와 유사한 소프트웨어 라이선스이지만 상업적 사용에 대한 제한이 포함되어 있으며, 개인적 사용을 포함하여 "배포(deployed)"되는 모든 버전의 소프트웨어 소스 코드를 공개할 것을 요구한다. 자유 소프트웨어 재단은 수정된 소스 코드를 많은 개인적 용도에 대해서도 공개해야 한다는 요구 사항 때문에 이를 비자유 라이선스로 간주한다.[32] 데비안 프로젝트는 상업적 사용에 대한 라이선스의 제한 및 해지 조항 등의 문제로 인해 데비안 자유 소프트웨어 지침 하에서 이를 비자유로 간주한다.[33] 반대로, 오픈 소스 이니셔티브는 이를 오픈 소스 라이선스로 승인했다.[34]

디자인 사이언스 라이선스(Design Science License, DSL)은 소프트웨어나 문서뿐만 아니라 문학, 예술 작품, 음악, 사진 및 비디오 등 모든 저작물에 적용되는 강한 카피레프트 라이선스이다. DSL은 마이클 스터츠가 GNU 스타일의 카피레프트를 비소프트웨어 저작물에 적용하는 데 관심을 가진 후 작성되었으며, 이는 나중에 자유 저작물로 불리게 되었다. 1990년대에는 음악 녹음, 시각 예술, 심지어 소설에도 사용되었다. 자유 소프트웨어 재단에 의해 GNU GPL과 호환되는 것으로 간주되지 않는다.[35]

전체 카피레프트와 부분 카피레프트

[편집]

"전체"와 "부분" 카피레프트는 또 다른 문제와 관련이 있다. 전체 카피레프트는 저작물의 모든 부분(라이선스 자체 제외)이 해당 카피레프트 라이선스의 조건 하에서만 수정 및 배포될 수 있을 때 존재한다. 반면 부분 카피레프트는 저작물의 일부를 카피레프트 조항에서 제외하여, 일부 수정본을 카피레프트 라이선스 이외의 조건으로 배포할 수 있게 하거나, 다른 방식으로 저작물에 카피레프트 원칙을 완전히 부과하지 않는 것이다. 부분 카피레프트의 예로는 일부 소프트웨어 패키지에 대해 만들어진 GPL 링크 예외와 결합된 파생물에 대한 EUPL이 있다.

동일조건변경허락

[편집]

일부 라이선스의 "동일조건변경허락(share-alike)" 조건은 원저작물과 관련하여 부여된 모든 자유가 파생 저작물에서도 정확히 동일하거나 호환되는 조건으로 부여되어야 한다는 요구 사항을 부과한다.

이는 모든 카피레프트 라이선스가 자동으로 동일조건변경허락 라이선스임을 의미하지만 그 반대는 아니다. 일부 동일조건변경허락 라이선스는 상업적 사용 금지와 같은 추가 제한을 포함하기 때문이다. 또 다른 제한은 모든 사람이 자신의 저작물을 공유하고 싶어 하지는 않는다는 점이며, 일부 동일조건변경허락 협약은 작성자가 특정 부분만 공유하고 싶더라도 저작물 전체가 공유될 것을 요구한다. 소스 코드 작성자에게 장점은 코드에 대한 모든 수정이 원작자에게 혜택을 줄 뿐만 아니라, 작성자가 인정을 받고 변경된 코드에 동일하거나 호환되는 라이선스 조건이 적용되도록 보장한다는 점이다.[36] 일부 크리에이티브 커먼즈 라이선스는 동일조건변경허락 카피레프트 라이선스의 예이다.

퍼미시브 라이선스

[편집]

퍼미시브 라이선스는 소프트웨어 사용자에게 카피레프트 라이선스와 동일한 자유를 부여하지만, 해당 소프트웨어의 수정 버전이 그 자유를 포함하도록 요구하지는 않는다. 이들은 소프트웨어를 사용, 수정 및 재배포하는 방법에 대한 최소한의 제한만을 가지므로 카피레프트 라이선스가 아니다. 이러한 유형의 라이선스 예로는 X11 라이선스, 아파치 라이선스, Expat 라이선스, 그리고 다양한 BSD 허가서가 있다.

논쟁 및 갈등

[편집]

카피레프트가 오픈 소스 이니셔티브와 자유 소프트웨어 운동 사이의 이념적 투쟁에서 분열적인 이슈가 되었다는 의견이 있다.[37] 그러나 카피레프트가 양측 모두에 의해 수용되고 제안된다는 증거가 있다:

  • OSI와 FSF 모두 각각의 승인된 라이선스 목록에 카피레프트 및 비카피레프트 라이선스를 포함하고 있다.[38][39]
  • OSI의 초기 법률 고문 로런스 로젠은 카피레프트 라이선스인 오픈 소프트웨어 라이선스(Open Software License)를 작성했다.
  • OSI의 라이선싱 방법론은 GPL을 "모범 사례" 라이선스로 인정한다.[40]
  • GNU 프로젝트의 일부 소프트웨어 프로그램은 비카피레프트 라이선스 하에 공개된다.[41]
  • 스톨먼은 특정 상황, 예를 들어 Ogg Vorbis의 라이선스 재설정 사례에서 비카피레프트 라이선스 사용을 지지했다.[42]

"바이러스성" 라이선싱

[편집]

"바이러스성 라이선스(Viral license)"는 카피레프트 라이선스에 대한 경멸적인 명칭이다.[43][44][45][46][47] 이 명칭은 GPLv1이 발표된 후 1년 뒤인 1990년부터 거슬러 올라가는 'General Public Virus' 또는 'GNU Public Virus'(GPV)라는 용어에서 유래했다.[48][49][50] '바이러스성 라이선스'라는 명칭은 카피레프트 저작물에서 파생된 모든 저작물이 배포될 때 카피레프트 권한을 유지해야 한다는 사실을 가리킨다.

일부 BSD 허가서 지지자들은 GPL 코드의 파생 저작물에 적용되는 라이선스 요구 사항에 대한 비판으로 인해 GPL 라이선스를 경멸적으로 지칭하는 데 이 용어를 사용했다.[51][52] 예를 들어, OpenBSD 저작권 정책은 GPL 라이선스가 "소프트웨어의 상업적 사용에 일반적으로 허용될 수 없는" 조건을 부과한다고 생각하기 때문에 프로젝트에서 새로운 GPL 라이선스 코드를 사용하는 것을 허용하지 않는다.[53] 카피레프트 라이선스는 이러한 이유로 비카피레프트 라이선스보다 "더 자유롭다"고 홍보된다.[54]

마이크로소프트 부사장 크레이그 먼디는 2001년 "GPL의 이러한 바이러스성 측면은 이를 사용하는 모든 조직의 지식 재산권에 위협이 된다"고 언급했다.[55] 다른 맥락에서 마이크로소프트 CEO 스티브 발머는 GPL 하에 배포된 코드는 결과적으로 생성된 주변 코드가 GPL 호환 라이선스 하에 라이선스되어야만 사용할 수 있으므로 상업 부문에서 무용지물이라고 선언했으며, 이를 "닿는 모든 것에 지식 재산권 의미에서 스스로를 부착하는 암"이라고 묘사했다.[56]

GPL에 대한 마이크로소프트의 비판에 대응하여 여러 저명한 자유 소프트웨어 개발자와 옹호자들이 라이선스를 지지하는 공동 성명을 발표했다.[57][58] 자유 소프트웨어 재단의 준수 엔지니어 데이비드 터너에 따르면, "바이러스성 라이선스"라는 용어는 오해를 불러일으키고 카피레프트 자유 소프트웨어를 사용하는 것에 대한 두려움을 조장한다.[59] 사람이 능동적인 행동 없이 바이러스에 감염될 수 있는 반면, 라이선스 조건은 실질적인 사용이나 채택 시에 발효된다.[60] 데이비드 맥고완(David McGowan) 또한 GPL이 사유 소프트웨어를 자유 소프트웨어로 강제로 전환시킬 수 있다고 믿을 이유가 없으며, 대신 "GPL 코드와 결합하여 2차적저작물을 형성하는 프로그램을 상업적으로 배포하지 못하도록 금지하거나, 침해에 대한 손해 배상을 청구"할 수는 있다고 썼다. 기업이 "실제로 GPL 프로그램에서 코드를 복사했다면, 그러한 소송은 완전히 일반적인 저작권 주장이 될 것이며, 입장이 바뀌었더라도 대부분의 사기업은 방어했을 것"이다.[61] 리처드 스톨먼은 이러한 관점을 유추하여 다음과 같이 설명했다: "GPL의 영역은 근접성이나 접촉에 의해 퍼지지 않으며, 오직 당신의 프로그램에 GPL 적용 코드를 의도적으로 포함함으로써 퍼진다. 그것은 바이러스처럼이 아니라 접란처럼 퍼진다."[62] 유럽 연합 공용 허가서 기여자인 파트리스-에마뉘엘 슈미츠에 따르면, 유럽 법상 독립적인 프로그램 간의 바이러스성 라이선싱은 존재하지 않는다.[63]

인기 있는 카피레프트 라이선스인 GPL 라이선스는 "파이프, 소켓 및 명령줄 인수"와 같이 "두 개의 별도 프로그램 간에 일반적으로 사용되는 통신 메커니즘"을 통해 GPL 프로그램과 "단순히 결합된, 비자유 또는 GPL 비호환 프로그램"이 밀접하지 않게 상호 작용하는 것을 방해하지 않는다.[64] 결과적으로, GPL 비호환 소프트웨어 모음의 한 프로그램이 GPL 라이선스 하에 있더라도, 다른 프로그램들이 그러한 방식으로 통신하는 것은 여전히 합법일 수 있다. 이러한 통신 유형에는 동적 링크를 통한 라이브러리 또는 루틴 재사용이 포함될 수도 있고 아닐 수도 있다. 일부 논평가는 포함된다고 주장하며,[65] FSF는 포함되지 않는다고 단언하며 Java 라이브러리의 GNU 클래스패스 재구현 라이선스에 이를 허용하는 예외를 명시적으로 추가한다. 이 모호성은 GPL과 LGPL 라이선스 간의 중요한 차이점으로, LGPL 변형은 GPL 변형과 호환되지 않는 조건으로 라이선스된 저작물을 LGPL 조건 하에서 링크하거나 컴파일하는 것을 구체적으로 허용한다.[66]

기호

[편집]
© 🄯
카피레프트 기호
유니코드에서U+1F12F 🄯 COPYLEFT SYMBOL
HTML: 🄯
대체 기호: (ɔ)
다른
다른U+00A9 © COPYRIGHT SIGN

카피레프트 기호는 저작권 기호, ©의 좌우 반전 버전으로, 원 안의 반전된 C이다.[67] 유니코드의 향후 버전에 기호를 추가하려는 2016년 제안이 유니코드 기술 위원회에 의해 승인되었다.[68][69] 코드 포인트 U+1F12F 🄯 COPYLEFT SYMBOL는 유니코드 11에 추가되었다.[69][70] 카피레프트 기호는 법적 지위가 없다.[71]

2024년 기준 이 기호는 일반적으로 대부분의 현재 운영 체제의 시스템 폰트에 표준으로 제공되지만, 필요할 경우 괄호 사이의 U+2184 ↄ LATIN SMALL LETTER REVERSED C 문자인 (ɔ)로 근사할 수 있다.

같이 보기

[편집]

각주

[편집]
  1. ↑ Newman, John (2011년 12월 29일). “Copyright and Open Access at the Bedside”. 《NEJM》 365 (26): 2447–2449. doi:10.1056/NEJMp1110652. PMID 22204721.
  2. ↑ Troan, Larry (2006). 《Open Source from a Proprietary Perspective》 (PDF). Red Hat Summit. Nashville: 레드햇. 2014년 1월 22일에 원본 문서 (PDF)에서 보존된 문서.
  3. 1 2 Frantsvog, Dean A. (2012). “All Rights Reversed: A Study Of Copyleft, Open-Source, And Open-Content Licensing” (PDF). 《Contemporary Issues In Education Research》 (The Clute Institute) 5 (1): 15–22. eISSN 1941-756X. ISSN 1940-5847.
  4. ↑ “Wikipedia Drops GNU in Favor of Creative Commons License”. 《PC world》. 2009년 5월 21일. 2025년 7월 4일에 확인함.
  5. ↑ Wang, Li-Chen (May 1976). “Palo Alto Tiny BASIC”. 《Dr. Dobb's Journal of Computer Calisthenics & Orthodontia》 1 (5): 12–25. 소스 코드는 다음 여섯 줄로 시작한다: 
    TINY BASIC FOR INTEL 8080
VERSION 1.0
BY LI-CHEN WANG
10 JUNE, 1976
@COPYLEFT
ALL WRONGS RESERVED
    5월호에 기재된 6월 날짜는 정확하다. 잡지는 일정이 밀려 있어 6월호와 7월호를 합쳐 발행했다.
  6. ↑ Stallman, Richard (March 1985). “The GNU Manifesto”. GNU 프로젝트. 2026년 1월 9일에 확인함.
  7. 1 2 3 4 5 Carver, Brian W. (2005년 4월 5일). “Share and Share Alike: Understanding and Enforcing Open Source and Free Software Licenses”. 《Berkeley Technology Law Journal》 20 (1): 443. doi:10.15779/Z388T19. S2CID 153900462. SSRN 1586574. 2023년 6월 27일에 확인함.
  8. ↑ Williams, Sam (March 2002). 〈7〉. 《Free as in Freedom – Richard Stallman's Crusade for Free Software》. 오라일리 미디어. ISBN 978-0-596-00287-9.
  9. ↑ Moody, Glyn (2002). 《Rebel Code》. 26쪽.
  10. ↑ “Emacs General Public License”. 2001년 7월 5일. 2008년 8월 23일에 확인함.
  11. 1 2 Stallman, Richard (2008년 1월 21일). “About the GNU Project”. 자유 소프트웨어 재단. 2017년 5월 1일에 확인함.
  12. ↑ “Free Art License – Frequently Asked Questions”. 《Copyleft Attitude》. 2021년 10월 6일에 확인함.
  13. ↑ “Licenses”. 《GNU 프로젝트》. 2021년 10월 6일에 확인함.: "우리는 예술적 또는 오락적 저작물이 반드시 자유로워야 한다는 입장은 아니지만, 만약 자유롭게 만들고 싶다면 프리 아트 라이선스를 권장한다."
  14. ↑ “What is free software?”. 《GNU》. 2019년 7월 30일. 2020년 7월 22일에 확인함.
  15. ↑ Mundie, Craig (2001년 5월 3일). “Prepared Text of Remarks by Craig Mundie, Microsoft Senior Vice President – The Commercial Software Model”. 뉴욕 대학교 스턴 스쿨 오브 비즈니스. 2005년 6월 21일에 원본 문서에서 보존된 문서. 2009년 10월 1일에 확인함.
  16. ↑ “Prime Leverage: How Amazon Wields Power in the Technology World”. 뉴욕 타임스. 2022년 1월 14일에 원본 문서에서 보존된 문서. 2022년 4월 23일에 확인함.
  17. ↑ Maher, Marcus (2000). “Open Source Software: The Success of an Alternative Intellectual Property Incentive Paradigm” (PDF). 포드햄 지식재산권, 미디어 & 엔터테인먼트 법률 저널. 2014년 5월 2일에 원본 문서 (PDF)에서 보존된 문서. 2014년 5월 1일에 확인함.
  18. ↑ Sarmah, Harshajit (2019년 9월 23일). “5 Reasons Why Contributing To Open Source Projects Helps In Landing A Job”. 《Analytics India Magazine》. 2020년 7월 22일에 확인함.
  19. ↑ Mustonen, Mikko. “Copyleft - The Economics of Linux and Other Open Source Software” (PDF). Information Economics and Policy. 2014년 5월 2일에 원본 문서 (PDF)에서 보존된 문서. 2014년 5월 1일에 확인함.
  20. ↑ “How to choose a license for your own work”. 자유 소프트웨어 재단의 라이선싱 및 준수 연구소. 2026년 4월 16일에 확인함.
  21. ↑ “What is Copyleft?”. GNU 프로젝트.
  22. ↑ “Scheibner, James – "What price freedom (of software)? A guide for Australian legal practitioners on open source licensing" [2017] PrecedentAULA 23; (2017) 139 Precedent 39”. 《classic.austlii.edu.au》. 2021년 11월 27일에 확인함.
  23. ↑ Kirk St.Amant; Brian Still (2008). 〈Examining Open Source Software Licenses through the Creative Commons Licensing Model〉. 《Handbook of Research on Open Source Software: Technological, Economic, and Social Perspectives》. Information Science Reference. 382 of 728쪽. ISBN 978-1-59140-999-1. 다음 값 잘못됨: |이름목록형식=amp (도움말)
  24. ↑ “The EUPL – European Union Public Licence”. 유럽 위원회. 2007년 1월 9일에 확인함.
  25. ↑ “Free Software Licensing Agreement CeCILL” (PDF). INRIA. 2010년 8월 8일에 원본 문서 (PDF)에서 보존된 문서. 2010년 8월 24일에 확인함.
  26. ↑ Schmitz, Patrice-Emmanuel (2015년 4월 3일). “The meaning of "Copyleft" in EUPL”. 《Interoperable Europe Portal》. 유럽 위원회. 일부 자유 소프트웨어 변호사들이 강조함에도 불구하고, 이 "강한 카피레프트"라는 개념은 판례법에 의해 인정된 적이 없다.
  27. ↑ “How to choose a license for your own work”. 《GNU 프로젝트》. 자유 소프트웨어 재단. 2015년 12월 20일. 2017년 5월 1일에 확인함.
  28. ↑ Stallman, Richard (2016년 11월 18일). “Who does that server really serve?”. 《GNU 프로젝트》. 자유 소프트웨어 재단. Server Software. 2017년 5월 1일에 확인함.
  29. ↑ “Why the Affero GPL”. 《GNU 프로젝트》. 자유 소프트웨어 재단. 2015년 5월 10일. 2017년 5월 1일에 확인함.
  30. ↑ “Various Licenses and Comments about Them”. 《GNU 프로젝트》. 자유 소프트웨어 재단. GNU Affero General Public License (AGPL) version 3. 우리는 개발자가 네트워크를 통해 일반적으로 실행될 소프트웨어에 대해 GNU AGPL 사용을 고려할 것을 권장한다.
  31. ↑ Schmitz, Patrice-Emmanuel (2015년 4월 3일). “The meaning of "Copyleft" in EUPL”. 《Interoperable Europe Portal》. 유럽 위원회. 이 때문에, 그리고 (정적 링크라 하더라도) 상호 운용성을 위해 수행되는 한, 권리자의 정당한 이익을 해치지 않고 저작물의 정상적인 이용과 충돌하지 않으므로 강한 카피레프트와 약한 카피레프트의 차이는 법적 실체가 거의 없는 것으로 보인다.
  32. ↑ “Various Licenses and Comments about Them”. 《GNU 프로젝트》. 자유 소프트웨어 재단. Sybase Open Watcom Public License version 1.0. 2026년 4월 12일에 원본 문서에서 보존된 문서. 2015년 12월 23일에 확인함. 이것은 자유 소프트웨어 라이선스가 아니다. 이 라이선스는 대상 소프트웨어를 '배포'할 때마다 소스 코드를 공개적으로 게시하도록 요구하며, '배포'는 많은 종류의 개인적 사용을 포함하도록 정의된다.
  33. ↑ Spiro, Jason; Borowski, Adam; Johnson, Ron; Ray, MJ (2006년 7월 2일). “openwatcom -- C/C++ compiler/IDE that make efficient, portable code” (메일링 리스트). 《Debian Bug report logs》 (데비안 프로젝트). 2026년 4월 18일에 확인함.
  34. ↑ “The Sybase Open Source Licence”. 오픈 소스 이니셔티브. 2026년 4월 16일에 확인함.
  35. ↑ “Various Licenses and Comments about Them”. 《GNU 프로젝트》. 자유 소프트웨어 재단. Design Science License (DSL). GNU GPL 및 GNU FDL과 호환되지 않으므로 소프트웨어나 문서에는 사용하지 마십시오.
  36. ↑ Engelfriet, Arnoud (2010). “Choosing an Open Source License”. 《IEEE Software》 (아테네 경제경영대학교) 27 (1): 48–49. Bibcode:2010ISoft..27a..48E. doi:10.1109/MS.2010.5. S2CID 36712745.
  37. ↑ Biancuzzi, Federico (2005년 6월 30일). “ESR: "We Don't Need the GPL Anymore"”. ONLamp.com. 2018년 3월 6일에 원본 문서에서 보존된 문서. 2008년 8월 23일에 확인함.
  38. ↑ Tiemann, Michael (2006년 9월 18일). “Licenses by Name”. 2008년 8월 23일에 확인함.
  39. ↑ “Various Licenses and Comments about Them”. 《GNU 프로젝트》. 자유 소프트웨어 재단.
  40. ↑ Raymond, Eric Steven (2002년 11월 9일). “Licensing HOWTO”. 2008년 8월 23일에 확인함.
  41. ↑ “What the GPLv3 Means for MS-Novell Agreement”. Yro.slashdot.org. 2007년 3월 8일. 2014년 5월 14일에 확인함.
  42. ↑ Stallman, Richard (2001년 2월 26일). “LWN.net: RMS on the Ogg Vorbis license”. 2008년 8월 23일에 확인함. [이 특별한 경우에 느슨한 (Ogg/Vorbis) 라이선스 아이디어에 대한 나의 동의는 대부분의 경우 GPL을 선호하는 것만큼이나 실용적이다. 두 경우 모두 우리가 어떻게 자유를 얻을 수 있느냐의 문제이다.]
  43. ↑ Shankland, Stephen (2001년 6월 22일). “Microsoft license spurns open source”. 《CNET》. CBS Interactive. 2012년 10월 21일에 원본 문서에서 보존된 문서. 이 용어의 선택은 나머지 내용보다 마이크로소프트의 관점에 대해 더 많은 것을 말해준다,"라고 헤이터는 말했다. "나는 이것이 경멸적이고 오해의 소지가 있는 용어라고 생각한다. 오픈 소스 소프트웨어가 어떻게든 '바이러스성'이라고 암시하는 것은 고객의 기계와 데이터에 대한 해를 마이크로소프트의 이익에 대한 해와 혼동하는 것이다.
  44. ↑ Geere, Duncan (2011년 12월 16일). “Some rights reserved: the alternatives to copyright”. 《Wired UK》. 2012년 5월 6일에 원본 문서에서 보존된 문서. 이 라이선스들은 "동일조건변경허락"이라는 경고 문구를 포함하는 경향이 있는데, 이는 바이러스성 라이선싱이라고 다소 경멸적으로 불리기도 하며, 모든 파생 저작물이 원본 콘텐츠와 동일하게 라이선스될 것을 요구한다.
  45. ↑ “Glossary”. 《a2knetwork.org》. 2009년 4월 26일에 원본 문서에서 보존된 문서. 카피레프트는 크리에이티브 커먼즈가 동일조건변경허락이라 부르는 라이선스 조건이며, 때로는 경멸적으로 "바이러스성" 라이선싱이라 불리는데, 이는 특정 라이선스 조건 하에 저작물을 받은 사람들에게 파생 저작물을 동일한 라이선스로 공개할 것을 요구한다.
  46. ↑ Greenberg, Jason; Glazer, Daniel (March 2013). “Inoculating Your Purchase – Contractual Protection from Viral Licenses in M&A Transactions” (PDF). Association of Corporate Counsel. 2016년 6월 10일에 확인함. 그러한 "카피레프트" 라이선스 모델—종종 "바이러스성" 라이선스로 경멸적으로 언급됨—은 기업의 가치에 영향을 미칠 가능성이 더 크므로 M&A 거래에서 중요한 우려를 제기한다.
  47. ↑ Philip Wood; Amy Ryburn; Allan Yeoman; Andrew Matangi; Steve Nightingale (2013년 7월 1일). “Legal update on Information and Communication Technology – July 2013”. Buddle Findlay. 2013년 9월 21일에 원본 문서에서 보존된 문서. 2016년 6월 10일에 확인함. '바이러스성' 라이선스로 더 경멸적으로 알려진 카피레프트 라이선스(가장 잘 알려진 것은 GPLv2와 그 후속인 GPLv3임)는 원본 OSS에 적용되는 조건이 원본 OSS를 사용하여 개발된 후속 소프트웨어에 상속되도록 규정한다.
  48. ↑ Vixie, Paul (2006년 3월 6일). “Re: Section 5.2 (IPR encumberance) in TAK rollover requirement draft” (메일링 리스트). 《Namedroppers》 (IETF). 2007년 9월 27일에 원본 문서에서 보존된 문서. 2007년 4월 29일에 확인함. 1994년 릭 아담스(당시 UUNET 사장)가 ISC를 설립하기 위해 나에게 수표를 건네며 "GNU 공공 바이러스 같은 쓰레기는 하지 마, 알겠나?"라고 말했다.
  49. ↑ “General Public Virus”. 《자곤 파일 2.2.1》. 1990년 12월 15일. 2026년 2월 17일에 원본 문서에서 보존된 문서. 2007년 4월 29일에 확인함.
  50. ↑ Hackvän, Stig (September 1999). “Reverse-engineering the GNU Public Virus – Is copyleft too much of a good thing?”. 《Linux World》. 2001년 1월 5일에 원본 문서에서 보존된 문서.
  51. ↑ Griffis, L. Adrian (2000년 7월 15일). “The GNU Public Virus”. 2002년 10월 12일에 원본 문서에서 보존된 문서. 2007년 4월 29일에 확인함.
  52. ↑ Buck, Joe (2000년 10월 10일). “Re: Using of parse tree externally” (메일링 리스트). 《GCC 메일링 리스트》. 2007년 4월 29일에 확인함.
  53. ↑ “OpenBSD Copyright Policy”. 2026년 4월 16일에 확인함. GNU 공중 사용 허가서와 이를 모델로 한 라이선스는 GNU 저작권 코드를 파생한 모든 저작물에 대해 소스 코드가 배포되거나 이용 가능해야 한다는 제한을 부과한다. 이는 표면적으로는 고귀한 전략처럼 보일 수 있지만, 이는 소프트웨어의 상업적 사용에 일반적으로 허용될 수 없는 조건이다.
  54. ↑ Stewart, Bill (1998년 10월 8일). “Re: propose: 'cypherpunks license' (Re: Wanted: Twofish source code)” (메일링 리스트). 《사이퍼펑크 메일링 리스트》. 2007년 5월 29일에 원본 문서에서 보존된 문서. 2007년 4월 29일에 확인함.
  55. ↑ Mundie, Craig (2001년 5월 3일). “Speech Transcript – Craig Mundie”. 뉴욕 대학교 스턴 스쿨 오브 비즈니스. 2005년 6월 21일에 원본 문서에서 보존된 문서. 2008년 8월 23일에 확인함.
  56. ↑ Newbart, Dave (2001년 6월 1일). “Microsoft CEO takes launch break with the Sun-Times”. 시카고 선타임스. 2001년 6월 15일에 원본 문서에서 보존된 문서.
  57. ↑ Perens, Bruce. 《Free Software Leaders Stand Together》 – 위키문헌 경유.
  58. ↑ MacCrisken, Jack (2001년 6월 12일). “Open source: One agnostic's view”. 《CNET》. 2025년 7월 5일에 확인함.
  59. ↑ Byfield, Bruce (2006년 8월 29일). “IT Manager's Journal: 10 Common Misunderstandings About the GPL”. 2006년 9월 18일에 원본 문서에서 보존된 문서. 2008년 8월 23일에 확인함.
  60. ↑ “The license term smorgasbord: copyleft, share-alike, reciprocal, viral, or hereditary?”. 《Luis Villa: Open Law and Strategy》. 2012년 2월 3일. 2018년 8월 22일에 확인함.
  61. ↑ McGowan, David (2005). 〈Legal Aspects of Free and Open Source Software〉. Joseph Feller; Brian Fitzgerald; Scott A. Hissam; Karim R. Lakahani (편집). 《Perspectives on Free and Open Source Software》. MIT Press. 382쪽. ISBN 978-0-262-06246-6.
  62. ↑ Poynder, Richard (2006년 3월 21일). “The Basement Interviews: Freeing the Code”. 《The Basement Interviews》. 2010년 2월 5일에 확인함.
  63. ↑ Schmitz, Patrice-Emmanuel (2015년 11월 23일). “Why viral licensing is a ghost”. 《Interoperable Europe Portal》. 유럽 위원회. 2026년 1월 22일에 확인함.
  64. ↑ “Frequently Asked Questions about the GNU Licenses”. 자유 소프트웨어 재단. 2008년 6월 24일. 2017년 5월 1일에 확인함.
  65. ↑ Raymond, Eric Steven (2002년 11월 9일). “Licensing HOWTO”. 2010년 3월 21일에 확인함.
  66. ↑ “Why you shouldn't use the Lesser GPL for your next library”. 《GNU 프로젝트》. 자유 소프트웨어 재단. 2026년 4월 11일에 원본 문서에서 보존된 문서.
  67. ↑ “The Unicode Standard, Version 15.0: Enclosed Alphanumeric Supplement” (PDF). 《unicode.org》.
  68. ↑ “Proposal to add the Copyleft Symbol to Unicode” (PDF).
  69. 1 2 “Proposed New Characters: Pipeline Table”. 《Unicode Character Proposals》. Unicode Consortium. 2017년 4월 18일에 확인함.
  70. ↑ “Announcing The Unicode Standard, Version 11.0”. 《The Unicode Blog》. 2018년 6월 6일에 확인함.
  71. ↑ Hall, G. Brent (2008). 《Open Source Approaches in Spatial Data Handling》. Springer. 29쪽. Bibcode:2008osas.book.....H. ISBN 9783540748311.

외부 링크

[편집]
원본 주소 "https://ko.wikipedia.org/w/index.php?title=카피레프트&oldid=42279685"