상위 질문
타임라인
채팅
관점
오픈 소스 사용권
콘텐츠를 사용, 수정 및 공유할 수 있도록 허용하는 소프트웨어 사용권 위키백과, 무료 백과사전
Remove ads
오픈 소스 사용권(open-source license)은 콘텐츠를 사용, 수정 및 공유할 수 있도록 허용하는 소프트웨어 사용권이다. 이는 자유-오픈 소스 소프트웨어(FOSS) 개발을 촉진한다. 지식 재산권(IP) 법은 창작물의 수정 및 공유를 제한한다. 자유-오픈 소스 사용권은 이러한 기존 법적 구조를 역의 목적으로 사용한다. 이들은 수혜자에게 소프트웨어를 사용하고, 소스 코드를 검사하며, 수정하고, 수정한 내용을 배포할 권리를 양도한다. 이러한 기준은 오픈 소스의 정의에 명시되어 있다.
1980년 이후 미국은 소프트웨어를 저작권법이 적용되는 문학 작품으로 취급하기 시작했다. 리처드 스톨먼은 사유 소프트웨어의 확산에 대응하여 자유 소프트웨어 운동을 창시했다. "오픈 소스"라는 용어는 자유 소프트웨어 개발자인 브루스 페렌스와 에릭 레이먼드가 설립한 오픈 소스 이니셔티브(OSI)에서 사용했다. "오픈 소스"는 소프트웨어 자유보다는 오픈 소스 소프트웨어 개발 모델의 강점을 강조한다. 용어 뒤에 숨은 목표는 다르지만, 오픈 소스 사용권과 자유 소프트웨어 사용권은 동일한 유형의 사용권을 설명한다.[1]
오픈 소스 사용권의 두 가지 주요 범주는 퍼미시브 라이선스와 카피레프트이다. 둘 다 소프트웨어를 변경하고 배포할 수 있는 권한을 부여한다. 일반적으로 저작권 귀속을 요구하고 소프트웨어 제품 책임을 부인한다. 퍼미시브 라이선스는 학계에서 유래한다. 카피레프트 사용권은 자유 소프트웨어 운동에서 유래한다. 카피레프트 사용권은 파생 저작물이 소스 코드와 유사한 사용권으로 배포되어야 한다고 요구한다. 2000년대 중반 이후 여러 국가의 법원은 두 가지 유형의 사용권 조건을 모두 인정했다. 소프트웨어 개발자들은 저작권 침해 및 계약 위반으로 소송을 제기했다.
Remove ads
배경
요약
관점
지식 재산권(IP)은 창작물을 사유재산과 유사하게 재산으로 취급하는 법적 범주이다.[2] 법률 시스템은 IP 소유자에게 다양한 방식으로 접근을 제한할 권리를 부여한다.[3] 소유자는 자신의 재산을 판매, 임대, 증여 또는 라이선스할 수 있다.[4] 상표권, 특허, 저작권을 포함한 여러 유형의 IP 법이 소프트웨어를 포괄한다.[4]
미국을 포함한 대부분의 국가는 베른 협약에 따라 약간의 변형을 거쳐 저작권법을 제정했다.[5] 이러한 법률은 작품이 어떠한 고정된 형식으로 발표될 때마다 저작권을 부여한다.[6] 미국 저작권법에 따라 최초 발표는 창작물로 간주된다.[7] 창작자 또는 고용주는 이 원본 저작물의 저작권을 소유하며, 따라서 복사본을 만들거나, 수정된 버전을 발표하거나, 복사본을 배포하거나, 공개적으로 공연하거나, 작품을 공개적으로 전시할 독점적 권리를 가진다. 원본 저작물의 수정된 버전은 파생 저작물이다.[8] 창작자가 기존 작품을 수정할 경우, 그들은 자신의 수정에 대한 저작권을 보유한다.[9] 원본 작품이 퍼블릭 도메인에 있지 않는 한, 파생 저작물은 모든 저작권자의 허가 없이는 배포될 수 없다.[10]
1980년 미국 정부는 소프트웨어를 문학 작품으로 취급하도록 법을 개정했다. 이 시점 이후에 출시된 소프트웨어는 IP 법에 의해 제한되었다.[11] 당시 미국의 사회 운동가이자 프로그래머인 리처드 스톨먼은 MIT 컴퓨터 과학 및 인공지능 연구소에서 대학원생으로 일하고 있었다. 스톨먼은 소프트웨어 개발자들 사이에서 파편화를 목격했다. 그는 사유 소프트웨어와 폐쇄형 개발 모델의 확산을 비난했다. 이러한 추세에 반발하여 스톨먼은 자유 소프트웨어 운동을 창시했다.[12] 1980년대 내내 그는 자유 운영 체제를 만들기 위해 GNU 프로젝트를 시작하고, 자유에 대한 에세이를 쓰고, 자유 소프트웨어 재단(FSF)을 설립했으며, 여러 자유 소프트웨어 사용권을 작성했다.[13] FSF는 기존 지식 재산권 법을 원래의 제한 목적과 반대로 사용했다. 제한을 부과하는 대신, 자유 소프트웨어는 수혜자에게 명시적으로 자유를 제공했다.[14]
90년대에 "오픈 소스"라는 용어가 자유 소프트웨어의 대체 용어로 만들어졌고, 어떤 사용권이 자유-오픈 소스 소프트웨어를 포괄하는지 결정하기 위한 특정 기준이 마련되었다.[15][16] 자유 소프트웨어 커뮤니티의 두 활동적인 회원인 브루스 페렌스와 에릭 레이먼드는 오픈 소스 이니셔티브(OSI)를 설립했다.[17] 데비안에서 페렌스는 데비안 자유 소프트웨어 지침(DFSG)을 제안했다.[18] DFSG는 데비안이 저장소에 호스팅할 FOSS에 대해 더 구체적이고 객관적인 표준을 제공하기 위해 작성되었다.[19] OSI는 DFSG를 채택하고 이를 오픈 소스 정의의 기반으로 사용했다.[20] 자유 소프트웨어 재단은 경쟁하는 기준인 자유 소프트웨어의 정의를 유지하고 있다.[21] 역사적으로 이 세 조직과 그들의 기준은 사용권이 자유-오픈 소스 소프트웨어를 포괄하는지 여부를 결정하는 데 중요한 권위였다.[22] 개별 사용권 간에는 상당한 다양성이 있지만, 경쟁하는 정의들 사이에는 큰 차이가 없다.[16] 세 정의는 각각 포괄하는 소프트웨어를 받는 사람들이 해당 작업을 사용, 수정 및 재배포할 수 있어야 한다고 요구한다.[23]
에릭 레이먼드는 "자유 소프트웨어"보다 "오픈 소스"라는 용어의 지지자였다. 그는 오픈 소스를 기업에 더 매력적이고 FOSS 개발의 실질적인 이점을 더 잘 반영한다고 보았다. 레이먼드의 목표 중 하나는 기존의 해커 커뮤니티를 대규모 상업 개발자로 확장하는 것이었다.[24] 성당과 시장에서 레이먼드는 오픈 소스 개발을 야외 시장인 바자르에 비유했다.[25] 그는 윤리 외에도 개방형 모델이 사유 소프트웨어가 복제할 수 없는 이점을 제공한다고 주장했다.[26][27] 레이먼드는 피드백, 테스트, 버그 보고서에 크게 중점을 두었다.[28] 그는 소수의 비밀스러운 작업자가 이 작업을 수행하는 사유 모델과 잠재적으로 전 세계가 테스터 풀에 포함되는 리눅스 개발을 대조했다.[29] 그는 이러한 강점을 "충분한 눈이 있다면 모든 버그는 얕다"고 요약했다.[30] OSI는 선 마이크로시스템즈, IBM, 넷스케이프, 모질라, 아파치, 애플, 마이크로소프트, 노키아를 포함한 기업 개발자들에게 오픈 소스 개발을 성공적으로 가져왔다. 이들 기업은 기존 사용권으로 코드를 출시하고 OSI의 승인을 받기 위해 자체 사용권을 작성했다.[31][32]
Remove ads
유형
요약
관점
자유-오픈 소스 소프트웨어 라이선스 비교 문서를 참고하십시오.오픈 소스 사용권은 카피레프트 또는 퍼미시브 라이선스로 분류된다.[33] 카피레프트 사용권은 파생 저작물이 유사한 사용권으로 소스 코드를 포함하도록 요구한다. 퍼미시브 사용권은 그렇지 않으므로 코드를 사유 소프트웨어 내에서 사용할 수 있다. 카피레프트는 파생 저작물을 광범위하게 또는 좁게 정의하는지에 따라 강한 카피레프트와 약한 카피레프트로 더 나눌 수 있다.[34][35]
사용권은 저작권법에 중점을 두지만, 코드는 다른 형태의 IP에도 적용된다.[36] 1990년대 후반 이후 작성된 주요 오픈 소스 사용권은 특허 양도를 포함한다. 이러한 오픈 소스 특허 양도는 개발자가 보유한 특허를 포괄한다.[37] 소프트웨어 특허는 아이디어를 포괄하며, 특정 구현이 아닌 특허 청구항의 모든 구현을 포괄한다. 특허 청구항은 보유자에게 아이디어를 기반으로 한 제품을 만들거나, 사용하거나, 판매하거나, 수입하는 것을 다른 사람에게 금지할 권리를 부여한다. 특허는 창작할 권리가 아닌 배제할 권리를 부여하므로, 아이디어에 대한 특허를 가지고 있더라도 해당 발명이 다른 특허 아이디어에 의존한다면 법적으로 구현할 수 없는 경우가 있다. 따라서 오픈 소스 특허 양도는 포괄하는 특허로부터만 허가를 제공할 수 있다. 제3자가 코드에 구현된 개념을 특허받지 않았음을 보장할 수 없다.[36] 오래된 퍼미시브 사용권은 특허를 직접 언급하지 않으며, 포괄하는 자료를 사용하거나 판매할 수 있는 암묵적인 특허 양도만을 제공한다.[38] 최신 카피레프트 사용권과 2004년 아파치 라이선스는 명시적인 특허 양도와 특허 소송으로부터의 제한적인 보호를 제공한다.[39] 이러한 특허 보복 조항은 포괄하는 소프트웨어에 대해 특허 소송을 제기하는 당사자에 대한 양도를 종료함으로써 개발자를 보호한다.[39]
상표권은 자유-오픈 소스 소프트웨어에서 공유되지 않는 유일한 IP 형태이다. FOSS의 상표권은 다른 상표권과 동일하게 기능한다.[40] 상표는 제품의 고유한 출처를 식별하는 디자인이다. 제품을 구별하기 때문에, 혼동될 위험이 없는 다른 분야에서는 동일한 디자인을 사용할 수 있다.[41] 상표권 통제권을 포기하면 해당 상표권을 상실하게 된다. 따라서 오픈 소스 사용권은 상표권 사용을 자유롭게 제공하지 않는다.[42]
상표권 제한은 저작권과 중복되어 자유롭게 이용 가능한 자료에 영향을 미칠 수 있다.[43] 미국 대법원은 상표권법을 사용하여 퍼블릭 도메인 콘텐츠를 제한하는 것을 "돌연변이 저작권"이라고 묘사했다.[44] 다스타 코퍼레이션 대 트웬티스 센추리 폭스 필름 코퍼레이션 사건에서 법원은 "상표권의 오용 또는 과도한 확장을 경고"하면서도 그러한 돌연변이 저작권에 대한 확고한 결정을 내리지 않았다.[45][46] 상표권 중복은 외부 당사자가 파생 저작물에 대한 상표권을 출원할 경우 오픈 소스 및 자유 콘텐츠 프로젝트를 "적대적 인수"에 취약하게 만들 수 있다.[47] 특히 안드레이 두스킨은 SCP 재단에 기반한 파생 저작물을 만들면서 공동 창작 프로젝트인 SCP 재단에 대한 상표권을 출원했다.[48]
퍼미시브
학술 라이선스라고도 알려진 퍼미시브 라이선스는[49] 수혜자가 소스 코드를 제공할 의무 없이 소프트웨어를 사용, 수정 및 배포할 수 있도록 허용한다. 기관들은 자신들의 창작물을 대중에게 배포하기 위해 이러한 라이선스를 만들었다.[49] 퍼미시브 라이선스는 보통 짧으며, 종종 한 페이지 미만의 텍스트로 구성된다. 이들은 거의 조건을 부과하지 않는다. 대부분은 보증 부인과 저자 귀속 의무를 포함한다. 일부는 특허, 상표 및 기타 형태의 지식 재산권에 대한 명시적인 조항을 포함한다.[50]
캘리포니아 대학교 버클리는 자신들의 BSD 운영 체제를 배포하기 시작하면서 최초의 오픈 소스 라이선스를 만들었다. BSD 허가서와 이후의 변형들은 해당 소프트웨어의 수정 및 배포를 허용한다. BSD 허가서는 컴퓨터 분야에 아이디어의 학문적 자유 개념을 가져왔다. 초기 학술 소프트웨어 저자들은 묵시적인 약속에 기반하여 코드를 공유했다. 버클리는 재배포에 대한 조항과 함께 책임 및 보증에 대한 명확한 면책 조항을 통해 이러한 개념을 명시했다. 원본은 네 가지 조항을 가졌지만, 후속 버전들은 제한을 더욱 줄였다. 결과적으로 해당 소프트웨어가 2조항 또는 3조항 버전을 사용하는지 명시하는 것이 일반적이다.[51][52]
매사추세츠 공과대학교(MIT)는 BSD 원본에 기반한 학술 라이선스를 만들었다. MIT 허가서는 조건을 더 명시적으로 만들어 명확히 했다.[53] 예를 들어, MIT 라이선스는 재라이선스 권리를 설명한다.[54] 오픈 소스 개발의 강점 중 하나는 개발자들이 서로의 파생 저작물을 기반으로 구축하고 그들의 프로젝트를 집합적인 작업으로 결합할 수 있는 지속적인 과정이다. 해당 코드를 명시적으로 재라이선스 가능하게 만드는 것은 저작권 체인을 추적할 때 법적 이점을 제공한다.[53] BSD와 MIT는 모든 프로젝트에 적용될 수 있는 템플릿 라이선스이다. 이들은 많은 FOSS 프로젝트에서 널리 채택되고 사용된다.[51]
아파치 라이선스는 더 포괄적이고 명시적이다. 아파치 소프트웨어 재단은 자신들의 아파치 HTTP 서버를 위해 이를 작성했다. 2004년에 발표된 버전 2는 간단한 라이선스에 비해 법적 이점을 제공하며 유사한 권한을 부여한다.[55] BSD 및 MIT 라이선스가 암묵적인 특허 허가를 제공하는 반면,[56] 아파치 라이선스는 기여자로부터의 명시적인 허가를 포함하는 특허 관련 섹션을 포함한다.[57] 또한, 특허 보복 조항을 포함하는 몇 안 되는 퍼미시브 라이선스 중 하나이다.[58] 특허 보복 또는 특허 중지 조항은 라이선스 사용자가 해당 코드에 대한 특허 침해 소송을 제기할 경우 발효된다. 그 상황에서 특허 허가는 취소된다. 이러한 조항은 특허 트롤로부터 보호한다.[59]
카피레프트
![Thumb](#/media/파일:"Copyleft_(L)"_sticker,_from_an_envelope_mailed_from_Don_Hopkins_to_Richard_Stallman_in_1984..jpg)
카피레프트 라이선스는 소스 코드가 소프트웨어와 함께 배포되고, 소스 코드가 유사한 라이선스 아래에서 이용 가능하게 되어야 한다고 요구한다.[34][60] 퍼미시브 라이선스와 마찬가지로, 대부분의 카피레프트 라이선스는 귀속을 요구한다.[61] GPL을 포함한 대부분은 묵시적 보증을 부인한다.[62]
카피레프트는 IP 법의 제한을 일반적인 목적과 반대로 사용하여 코드가 공개 상태를 유지하도록 강제한다.[63] 이 용어와 관련 슬로건인 "모든 권리 반대"는 이전에 프린키피아 디스코르디아와 타이니 베이직에서 장난스럽게 사용되었지만, 현대적인 용법은 리처드 스톨먼이 자유 운영 체제를 만들기 위한 노력에서 시작된다. 1984년, 프로그래머 돈 홉킨스는 스톨먼에게 "Copyleft Ⓛ" 스티커가 붙은 매뉴얼을 보냈다. GNU 운영 체제를 작업 중이던 스톨먼은 이 용어를 채택했다.[64] 카피레프트 라이선스의 초기 버전은 1985년 GNU 이맥스 출시에 사용되었다.[14][65] 이 용어는 FSF의 후속 상호 라이선스, 특히 GNU 일반 공중 사용 허가서(GPL)와 연관되었다.[66]
전통적인 사유 소프트웨어 사용권은 수익 증대를 목표로 작성되었지만, 스톨먼은 사용 가능한 자유 소프트웨어의 양을 늘리기 위해 GPL을 작성했다. 그의 상호 라이선스는 사람들이 동일한 자유를 제공하는 라이선스 아래에서 파생 저작물을 출시해야 한다는 조건으로 작업을 사용, 수정 및 배포할 권리를 제공한다. 카피레프트 기반으로 구축된 소프트웨어는 소스 코드와 함께 제공되어야 하며, 소스 코드는 동일하거나 유사한 라이선스 아래에서 이용 가능해야 한다. 이는 소스 코드를 돌려주지 않고 코드를 소비하는 사유 소프트웨어로부터의 보호를 제공한다.[67][68] 리처드 스톨먼은 "카피레프트의 핵심 아이디어는 저작권법을 사용하지만, 그 본래 목적과 반대로 뒤집어 사용하는 것"이라고 말했다. "소프트웨어를 사유화하는 수단 대신, [저작권]은 소프트웨어를 자유롭게 유지하는 수단이 된다."[69] 자유 소프트웨어 사용권은 또한 오픈 소스 소프트웨어 사용권이다.[70] "자유 소프트웨어"와 "오픈 소스 소프트웨어"라는 별도의 용어는 법적 차이보다는 다른 가치를 반영한다.[71] 두 운동과 그들의 공식 정의는 해당 작업이 소스 코드와 함께 수정 및 재배포 권한을 가지고 이용 가능하게 되어야 한다고 요구한다.[16] FSF 또는 OSI 중 하나만 라이선스를 승인하는 예외적인 경우가 가끔 있지만, 인기 있는 자유 소프트웨어 라이선스에는 GPL을 포함하여 오픈 소스 라이선스도 있다.[72]
.jpg)
카피레프트 라이선스의 실질적인 이점은 상업 개발자들을 끌어들였다. 기업들은 GPL보다 더 좁은 범위의 상호 라이선스를 사용하고 작성했다.[74] 예를 들어, 넷스케이프는 모질라 프로젝트에 대해 퍼미시브 라이선스를 거부한 후 자체 카피레프트 조건을 초안했다.[32] GPL은 이 유형의 가장 인기 있는 라이선스로 남아 있지만, 다른 중요한 예시도 있다. FSF는 라이브러리를 위한 약소 일반 공중 사용 허가서(LGPL)를 만들었다. 모질라는 파이어폭스를 포함한 자신들의 릴리스에 모질라 공용 허가서(MPL)를 사용한다. IBM은 커먼 퍼블릭 라이선스(CPL)를 초안하고 나중에 이클립스 공용 허가서(EPL)를 채택했다. GPL과 다른 상호 라이선스의 차이점은 상호 조항이 적용되는 파생 저작물을 정의하는 방식이다. GPL과 이를 기반으로 한 GNU 아페로 일반 공중 사용 허가서(AGPL)는 영향을 받는 저작물을 설명하기 위해 광범위한 범위를 사용한다. AGPL은 GPL의 상호 의무를 확장하여 네트워크를 통해 제공되는 소프트웨어를 포괄한다.[74][32] 이들은 종종 기업에서 사용되는 약한 카피레프트 라이선스와 대조적으로 강한 카피레프트라고 불린다. 약한 카피레프트는 파생 저작물에 대한 더 좁고 명시적인 정의를 사용한다.[75][35] MPL은 파일 기반 정의를 사용하고, CPL과 EPL은 모듈 기반 정의를 사용하며, FSF 자체의 LGPL은 소프트웨어 라이브러리를 참조한다.[76]
호환성
라이선스 호환성은 서로 다른 라이선스가 있는 코드를 함께 배포할 수 있는 방법을 결정한다. 오픈 소스 라이선스의 목표는 작업을 자유롭게 이용 가능하게 만드는 것이지만, 이는 다른 요구 사항을 부과하는 여러 용어와 함께 작업할 때 복잡해진다.[77] 흔히 사용되지 않는 라이선스가 많고 일부 프로젝트는 자체적인 맞춤형 계약을 작성하기도 한다. 결과적으로 이는 다른 법적 측면보다 더 많은 혼란을 야기한다. 응용 프로그램 집합체를 출시할 때 각 라이선스는 개별적으로 고려될 수 있다. 그러나 소프트웨어를 결합하려고 할 때, 다른 프로젝트의 코드는 해당 프로젝트가 호환되는 이용 약관을 사용하는 경우에만 라이선스를 받을 수 있다.[78]
코드 베이스를 결합할 때, 원래 라이선스를 개별 구성 요소에 유지하고 더 큰 작업은 호환 가능한 라이선스로 출시할 수 있다.[79] 이러한 호환성은 종종 단방향이다. 퍼블릭 도메인 콘텐츠는 저작권 주장이 없으므로 어디에서나 사용할 수 있지만, 거의 모든 조건으로 획득한 코드는 퍼블릭 도메인으로 포기할 수 없다. 퍼미시브 라이선스는 카피레프트 작업 내에서 사용될 수 있지만, 카피레프트 자료는 퍼미시브 라이선스 아래에서 출시될 수 없다. 일부 약한 카피레프트 라이선스는 GPL 아래에서 사용될 수 있으며 GPL 호환이라고 한다. GPL 소프트웨어는 GPL 또는 AGPL 아래에서만 사용될 수 있다.[77] 퍼미시브 라이선스는 프로젝트의 개별 부분을 포괄할 수 있기 때문에 광범위하게 호환된다. GPL 및 아파치 라이선스를 포함한 여러 라이선스는 호환성을 향상시키기 위해 개정되었다.[80]
번역 문제, 라이선스 조건의 모호성, 일부 라이선스와 특정 관할권의 법률 간의 비호환성은 라이선스 호환성 문제를 더욱 복잡하게 만든다.[81] 오픈 소스 모듈을 다운로드하는 것은 간단하지만, 라이선스 조건을 준수하는 것은 더 어려울 수 있다.[82] 소프트웨어 종속성의 양 때문에 복잡한 프로젝트에서 작업하는 엔지니어는 오픈 소스 구성 요소의 라이선스 조건을 준수하기 위해 라이선스 관리 소프트웨어에 의존하는 경우가 많다.[83] 많은 오픈 소스 소프트웨어 파일은 라이선스를 명확하게 명시하지 않아 준수 어려움을 증가시킨다.[82]
Remove ads
집행
요약
관점
이 부분의 본문은 오픈 소스 라이선스 소송입니다.
자유-오픈 소스 소프트웨어 사용권은 2000년대 중반부터 민사 법원에서 성공적으로 집행되어 왔다.[85] 초기 소송 두 건(재커브센 대 캣저 (미국) 및 웰테 대 사이트콤 (독일))에서 피고는 오픈 소스 사용권이 무효라고 주장했다.[86][87] 사이트콤과 캣저는 각기 사용권이 강제 불가능하다고 주장했다. 미국 캘리포니아 북부 지방법원과 독일 법원은 이러한 주장을 기각했다. 그들은 사용권이 강제 불가능하다면 피고가 합법적으로 소프트웨어를 배포할 수 없었을 것이라고 판결했다.[85][84]
법원은 소프트웨어를 배포하는 것이 라이선스 조건에 대한 수락을 나타낸다고 판단했다.[88] 물리적 소프트웨어 릴리스는 슈링크랩에 배치된 고지사항으로 소비자의 동의를 얻을 수 있다. 온라인 배포는 사용자가 클릭하여 수락해야 하는 디지털 등가물인 클릭랩을 사용할 수 있다.[89] 오픈 소스 소프트웨어는 추가적인 수락 메커니즘을 가지고 있다. 저작권자의 허가 없이 법은 재배포를 금지한다.[90] 따라서 법원은 재배포를 라이선스 조건의 수락으로 간주한다. 여기에는 카피레프트 라이선스에 대한 귀속 조항 또는 소스 코드 조항이 포함될 수 있다.[91][92]
개발자들은 일반적으로 소송 없이 준수를 달성한다. 커뮤니티의 반발 가능성과 같은 사회적 압력이 종종 충분하다.[93] 정지명령 서한은 특히 독일에서 기업을 다시 준수하게 만드는 일반적인 방법이다.[94] 독일 법률 시스템에서는 표준 절차가 개발되었다. FOSS 개발자들은 기업에 정지명령 서한을 제시한다. 이 서한은 위반으로부터 준수를 회복하는 방법을 설명한다. 독일 판사는 반응이 없는 기업에 법원 명령의 정지명령을 내릴 수 있다. 이러한 첫 단계가 실패하면 민사 소송이 진행된다. 독일의 절차법은 명확하고 원고에게 유리하다.[95]
다른 법원이 라이선스의 특정 측면을 어떻게 다룰지에 대한 불확실성은 여전히 남아 있다.[96] 일반적으로 소프트웨어에 대해 무엇이 특허될 수 있고 무엇이 저작권될 수 있는지에 대한 논쟁이 있다. API(응용 프로그래밍 인터페이스)와 관련하여 유럽 사법재판소는 2012년 SAS 인스티튜트 대 월드 프로그래밍 Ltd 사건에서 "[컴퓨터 프로그램] 인터페이스의 기본 아이디어와 원칙은 저작권으로 보호되지 않는다"고 언급했다.[97] 유사한 2021년 사건에서 미국 대법원은 공정 이용에 따라 변형적 제품에서 API의 재구성을 허용했다.[98]
FOSS 커뮤니티 내에서 오랫동안 논쟁되어 온 주제는 오픈 소스 라이선스가 "단순 라이선스"인지 아니면 계약인지 여부이다.[96] 단순 라이선스는 IP 법에 의해 제한되는 행위가 허용되는 조건 집합이다.[85] FSF가 옹호하는 단순 라이선스 해석에 따르면, 사건은 저작권자가 저작권 침해로 법원에 제기한다.[85] 계약 해석에 따르면, 사건은 관련 당사자가 채무불이행으로 법원에 제기할 수 있다.[99] 미국 및 프랑스 법원은 두 해석 모두에 따라 사건을 심리했다.[100] FSF 및 소프트웨어 자유 단체와 같은 비영리 단체는 개발자 프로젝트의 권리를 보유하여 준수를 강제하는 것을 제안한다.[95]
퍼블릭 도메인 소프트웨어
저작권이 만료되면 작품은 퍼블릭 도메인에 들어가 누구나 자유롭게 이용할 수 있게 된다.[102] 일부 창작물은 저작권의 보호를 받지 않아 직접 퍼블릭 도메인에 들어간다. 컴퓨팅 초기 역사에서 이는 소프트웨어에도 적용되었다.[11] 초기 컴퓨터 소프트웨어는 종종 하드웨어와 함께 제공되었다.[103] MIT에서 처음 개발된 개척적인 비디오 게임 스페이스워!는 PDP-1 컴퓨터를 마케팅하고 테스트하는 데 사용되었다.[104]
변호사 로렌스 로젠에 따르면, 저작권법은 창작자들이 자신의 작품을 퍼블릭 도메인에 두리라는 기대를 가지고 작성되지 않았다. 따라서 지식 재산권법에는 저작권을 포기할 명확한 경로가 없다. "퍼블릭 도메인"으로 묘사되는 매우 퍼미시브한 라이선스는 법적으로는 무언가를 제공하지만 조건을 부과하지 않는 일방적인 계약으로 기능할 수 있다.[105][106]
크리에이티브 커먼즈 CC0과 같은 퍼블릭 도메인 동등 라이선스는 퍼블릭 도메인에 대한 저작권 주장을 포기하는 것과 함께 퍼미시브 라이선스를 대체제로 제공한다. 퍼블릭 도메인 포기를 인정하지 않는 관할권에서는 퍼미시브 라이선스가 발효된다.[107] 퍼블릭 도메인 포기는 단순 학술 라이선스와 한계를 공유한다. 이는 외부 당사자가 특허 또는 상표법을 통해 퍼블릭 도메인 작품을 통제하려고 시도할 가능성을 만든다.[108] 퍼블릭 도메인 포기는 어떤 유형의 라이선스와도 다르게 보증을 처리한다. MIT 라이선스와 같은 매우 퍼미시브한 라이선스조차 보증 및 책임을 부인한다. 자유 소프트웨어를 사용하는 사람은 이 면책 조항을 조건으로 수락해야 한다. 퍼블릭 도메인 콘텐츠는 모든 사람에게 이용 가능하므로 저작권 포기가 면책 조항을 부과할 수 없다.[102]
Remove ads
사유 소프트웨어에서의 사용
오픈 소스 라이선스는 다른 기업이 해당 소프트웨어를 상업화할 수 있도록 허용한다.[109] 퍼미시브 라이선스 아래에 출시된 작업은 사유 소프트웨어에 통합될 수 있다.[110] 퍼미시브 라이선스는 사유 조건을 포함한 새로운 조건의 추가를 허용한다.[111][112] 사유 소프트웨어는 아파치, BSD, MIT 라이선스 아래에 출시된 오픈 소스 코드를 크게 통합했다.[113] 오픈 코어 모델은 개발자가 핵심 소프트웨어를 오픈 소스로 출시하고, 이를 포함하는 제품을 사유 소프트웨어로 수익화하는 비즈니스 모델이다.[114] 강력한 카피레프트인 GPL은 사유 소프트웨어 내에서의 배포를 방지하도록 작성되었다.[115][116] 약한 카피레프트 라이선스는 특정 상황에서 해당 코드가 사유 소프트웨어 내에서 배포될 수 있도록 하는 파생 저작물에 대한 특정 요구 사항을 부과한다.[77]
클라우드 컴퓨팅은 자유-오픈 소스 소프트웨어에 의존하며, 대부분의 라이선스를 유발하는 배포를 피한다. 클라우드 소프트웨어는 배포되기보다는 호스팅된다.[117] 공급업체가 소프트웨어를 온라인으로 호스팅하고, 최종 사용자는 사용 중인 코드를 다운로드하거나, 접근하거나, 심지어 알 필요도 없다.[118] 카피레프트인 GNU 아페로 일반 공중 사용 허가서(AGPL)는 해당 코드가 호스팅되거나 배포될 때 발동된다.[119] 일부 개발자는 AGPL을 채택했으며, 다른 개발자는 오픈 소스 라이선스의 기능을 가진 사유 라이선스로 전환했다.[120] 예를 들어, 오픈 코어 개발자인 엘라스틱은 아파치 라이선스에서 "소스 이용 가능"한 Server Side Public License로 전환했다.[121] 소스 입수 가능 소프트웨어는 참조용 소스 코드를 함께 제공한다.[122]
2010년 이후 클라우드 모델은 중요성이 커졌다.[117] 개발자들은 오픈 소스 소프트웨어를 호스팅하여 이익을 얻으면서도 상위 프로젝트에 돈이나 코드를 기여하지 않는 클라우드 기업들을 노천 채굴에 비유하며 비판했다.[123] 클라우드 컴퓨팅 선두 기업인 아마존 웹 서비스는 라이선스를 준수하고 고객의 최선의 이익을 위해 행동한다고 밝혔다.[123][124]
Remove ads
같이 보기
- 비어웨어
- 자유-오픈 소스 소프트웨어 라이선스 비교
- 기여자 라이선스 동의
- 자유 콘텐츠 라이선스 목록
- 다중 라이선스
- 소프트웨어 구성 분석
- 자유-오픈 소스 소프트웨어 라이선스 목록
- 카피레프트 소프트웨어 라이선스 목록
- 오픈 소스 프로그래밍 언어 목록
- 퍼미시브 소프트웨어 라이선스 목록
내용주
각주
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads