본문으로 이동

소프트웨어 사용권

한울위키, 우리 모두의 백과사전.
파일:Software Categories expanded.svg
FSF와 그들의 자유 소프트웨어의 정의에 따른 다양한 라이선스 하의 소프트웨어 도표: 왼쪽은 "자유 소프트웨어", 오른쪽은 "사유 소프트웨어"이다. 양쪽 모두에 걸쳐 있으며(따라서 대체로 직교하는) "무료 다운로드"(프리웨어)가 있다.

소프트웨어 사용권(software license)은 소프트웨어의 사용이나 재배포를 규율하는 법적 도구이다.

1970년대 이후 미국에서 소프트웨어 저작권이 인정되기 시작했다. 저작권이 인정됨에도 불구하고 대부분의 기업은 소프트웨어 복제본을 판매하기보다 라이선스를 판매하는 것을 선호하는데, 이는 재배포에 대해 더 엄격한 조건을 강제할 수 있기 때문이다. 구매자 중 라이선스의 어느 부분이라도 읽는 사람은 거의 없으며, 초기에는 슈링크랩 계약 형태였으나 현재는 클릭랩이나 브라우즈랩 형태로 가장 흔하게 접하게 된다. 이러한 종류의 라이선스에 대한 집행 가능성은 논란의 대상이며 일부 관할권에서는 제한된다. 서비스 수준 협약서(SLA)는 소프트웨어 라이선스의 또 다른 유형으로, 판매자가 구매자에게 일정 수준의 서비스를 제공하기로 동의하며, 흔히 금전적 벌칙이 수반된다.

카피레프트는 2차적저작물이 원본 라이선스의 조건에 따라 라이선스되도록 규정하는 라이선스 유형이다. 카피레프트 라이선스는 자유 및 오픈 소스 라이선스이다. 서버 사이드 퍼블릭 라이선스 등 4가지 자유를 옹호하지 않는 라이선스를[1] "카피레프트"로 설명하려는 시도가 있었으나, 이는 용어의 남용으로 널리 거부되고 있다. 다른 유형의 자유 라이선스에는 이러한 요구 사항이 없다. 허용적 라이선스의 경우 일반적으로 저작자 표시가 유일한 요구 사항이며, 퍼블릭 도메인 동등 라이선스에는 아무런 제한이 없다. 오픈 소스 라이선스의 확산은 라이선스 호환성 문제를 복잡하게 만들었지만, 모든 라이선스는 동일한 라이선스 하에 재배포 및 2차적저작물 허용, 소스 코드에 대한 제한 없는 접근, 다양한 용도 간의 차별 금지(특히 상업적 이용 허용)라는 특징을 공유한다.

자유 및 오픈 비자유
퍼블릭 도메인[2] 및 동등 라이선스 허용적 라이선스[3][4] 카피레프트[3][4] 비상업용 라이선스[5] 사유 라이선스[6] 영업 비밀[7] 소스 입수 가능
설명 저작권 보호 포기 라이선스 재부여 권한을 포함한 사용권 부여(사유화, 라이선스 호환성 허용) 사용권 부여, 사유화 금지 비상업적 용도로만 권리 부여 전통적인 저작권 행사; 권리 부여 필요 없음 공개된 정보 없음 사용권을 부여하나 특정 사례로 제한하며, 자유 소프트웨어나 카피레프트가 아님
주요 소프트웨어 라이선스 PD, CC0[8] MIT, Apache, MPL, BSD GPL, AGPL JRL[9] 사유 소프트웨어 SSPL

소프트웨어 저작권

파일:Icons8 flat search.svg 이 부분의 본문은 소프트웨어 저작권입니다.

컴퓨터 프로그램의 소스 코드(또는 목적 파일 형태의 컴파일된 바이너리)[10]는 소유자에게 코드 복제에 대한 독점적 권리를 부여하는 저작권법에 의해 보호된다. 기초가 되는 아이디어나 알고리즘은 저작권법으로 보호되지 않지만, 흔히 영업 비밀로 취급되어 기밀유지 협약과 같은 방법으로 은닉된다.[11] 소프트웨어 저작권은 1970년대 중반부터 인정되었으며, 코드를 작성한 직원이나 계약자가 아닌 소프트웨어를 제작한 회사에 귀속된다.[2]

마크 웨빙크(Mark Webbink)에 따른 저작권 맥락에서의 소프트웨어 라이선스 및 부여된 권리.[12] 프리웨어 및 서브라이선스 권한 포함.
부여된 권리 퍼블릭 도메인 및 동등물 허용적 FOSS 라이선스 (예: BSD) 카피레프트 FOSS 라이선스 (예: GPL) 프리웨어 / 셰어웨어 / 프리미엄 사유 라이선스 영업 비밀
저작권 유지 아니요 예 예 예 예 예
실행권 예 예 예 예 예 아니요
표시권 예 예 예 예 예 아니요
복제권 예 예 예 종종 아니요 저작권 침해에 대해 소유자가 가장 많이 소송을 제기함
수정권 예 예 예 아니요 아니요 아니요
배포권 예 예, 동일 라이선스 하에 예, 동일 라이선스 하에 종종 아니요 아니요
서브라이선스 권한 예 예 아니요 아니요 아니요 아니요
대표적 소프트웨어 SQLite, ImageJ 아파치 웹 서버, ToyBox 리눅스 커널, 김프, OBS IrfanView, 윈앰프 윈도우, 대다수의 상업용 비디오 게임 및 그 DRM, 스포티파이, XSplit, TIDAL 서버 측
클라우드 컴퓨팅 프로그램 및 서비스,
포렌식 애플리케이션 및 기타 기업용 작업.

사유 소프트웨어 라이선스

섬네일을 만드는 중 오류 발생:
1995년 매크로미디어에서 발행한 짧은 서면 형식의 베타 테스트 소프트웨어 라이선스

소프트웨어를 판매하기보다 라이선스를 부여하는 경향은 소프트웨어 저작권 보호의 존재와 범위가 명확해지기 전 시기부터 시작되었다. 이러한 라이선스는 법원에서 소프트웨어 저작권이 인정된 이후에도 계속 사용되었으며, 저작권법에 비해 기업에 추가적인 보호를 제공하는 것으로 간주된다.[13] 미국 연방법에 따르면 기업은 판매 대상을 제한할 수 있지만 구매자가 제품을 재판매하는 것을 막을 수는 없다. 소프트웨어 라이선스 계약은 보통 재판매를 금지하여 기업이 수익을 극대화할 수 있도록 한다.[14]

전통적으로 소프트웨어는 사용자가 이해하거나 수정할 수 없지만[10] 다운로드하여 실행할 수 있는 바이너리 목적 파일 형태로 배포되었다. 사용자는 특정 버전의 소프트웨어를 사용하기 위해 영구 라이선스를 구입했다.[15] 응용 소프트웨어 분야에서 2023년 기준2023년 기준 과반의 시장 점유율을 차지하는[16] 서비스형 소프트웨어(SaaS) 판매자들은 영구 라이선스를 거의 제공하지 않는다.[17] SaaS 라이선스는 보통 일시적이며 사용량당 지불 방식이나 구독 기반으로 요금이 부과되지만,[18] 프리미엄과 같은 다른 수익 모델도 사용된다.[19] 고객 입장에서 일시적 라이선스의 장점은 영구 라이선스에 비해 초기 비용 절감, 유연성 증대, 전체적인 비용 감소 등이 있다.[15] 어떤 경우에는 전통적인 소프트웨어 판매자가 요구하는 가파른 일시불 비용이 중소기업이 감당하기 어려웠으나, 사용량당 지불 SaaS 모델은 소프트웨어를 저렴하게 이용할 수 있게 해준다.[20]

소프트웨어 사용권 동의 (EULA)

파일:Icons8 flat search.svg 이 부분의 본문은 소프트웨어 사용권 동의입니다.

초기에 소프트웨어 사용권 동의(EULA)는 제품을 감싸는 슈링크랩 포장(참조: 슈링크랩 계약)이나 종이 위에 인쇄되었다. 라이선스에는 흔히 고객이 지정된 기간 내에 제품을 반품하지 않으면 동의한 것으로 간주한다는 규정이 포함되었다.[21] 최근에는 사용자의 클릭이나 지속적인 브라우징을 동의의 표시로 간주하는 클릭랩 또는 브라우즈랩 형태로 EULA를 가장 흔하게 볼 수 있다. 물리적 제약이 사라지면서 그 길이는 늘어났다.[22] 대부분의 EULA는 읽고 이해하기는 매우 어렵지만, 읽지 않고도 라이선스 조건에 동의하기는 쉽게 설계되어 왔다.[13][21] 접근이 얼마나 쉬운가와 상관없이, 라이선스 계약의 어느 부분이라도 읽는 소비자는 거의 없다.[23][24] 대부분은 조건에 이의가 없을 것이라고 가정하거나 소프트웨어를 설치하는 동안 동의하는 것을 거의 인지하지 못한다.[25] 기업들은 소비자들의 부주의를 이용하여 EULA에 조항을 삽입한다.[26]

사유 소프트웨어는 보통 복제와 재사용을 금지하고 구매자가 한 대의 컴퓨터에서만 소프트웨어를 사용하도록 제한하는 엄격한 라이선스 하에 제공된다.[6][27] 소스 코드가 공개되는 경우는 거의 없다. 파생 소프트웨어 제작 및 역공학은 대개 명시적으로 금지된다.[27] 많은 EULA가 판매자가 사용자에 대한 정보를 수집하고 이를 제한 없이 사용하는 것을 허용한다.[28] 일부 EULA는 비디오 게임의 가상 세계에서의 창의적 창작물과 같이 해당 소프트웨어를 사용하여 만든 2차적저작물에 대해 사용자가 저작권을 행사하는 능력을 제한하기도 한다.[29][30]

대부분은 제품으로 인해 발생한 피해에 대한 어떠한 책임을 부인하며,[31] 구매자가 구제책을 찾기 위해 법원 시스템에 접근하는 것을 방해한다.[32] 또한, 많은 EULA는 판매자가 언제든지 조건을 변경할 수 있도록 허용하며, 고객은 환불 없이 동의하거나 제품 사용을 중단하는 것 중에서 선택해야 한다.[33] EULA에서 판매자가 모호한 여러 이유로, 혹은 아무런 이유 없이 일방적으로 계약을 해지할 수 있도록 하는 것은 흔한 일이다.[34]

거의 항상 소프트웨어 사용을 위한 협상 불가능한 조건으로서 수용 아니면 거절(take-it-or-leave-it) 방식으로 제공되는 EULA는,[35] 양 당사자가 조건을 완전히 이해하고 자발적으로 동의하는 전형적인 계약과는 매우 거리가 멀다.[36] 이러한 계약이 어느 정도까지 구속력이 있는 것으로 간주될 수 있는지에 대해 상당한 논쟁이 있어 왔다. 1996년 이전 미국에서는 클릭랩이나 브라우즈랩 라이선스가 구속력이 있는 것으로 간주되지 않았으나, 그 이후에는 종종 인정되어 왔다.[37][22] 유럽 연합에서 시행되는 새로운 디지털 콘텐츠 지침(New Digital Content Directive)에 따르면, EULA는 합리적인 소비자 기대를 위반하지 않는 범위 내에서만 집행 가능하다. 디지털 콘텐츠의 복제 및 소유권 이전 제한에 관해서는 기대치와 EULA 내용 사이의 격차가 특히 크다.[38] 많은 EULA에는 관할권에 따라 집행 불가능할 가능성이 높은 규정들이 포함되어 있다. 소프트웨어 판매자들은 사용자들이 법적 시스템을 통해 이의를 제기하는 경우가 거의 없기 때문에 이러한 집행 불가능한 조항들을 계약서에 유지한다.[39]

서비스 수준 협약서 (SLA)

파일:Icons8 flat search.svg 이 부분의 본문은 서비스 수준 협약서입니다.

서비스 수준 협약서는 흔히 전사적 소프트웨어에 사용되며, 소프트웨어 성능이나 고객이 제기한 문제에 대한 응답 시간과 같은 서비스 수준을 보장한다. 많은 경우 서비스가 합의된 표준에 미치지 못할 경우 금전적 벌칙을 규정한다.[40] SLA는 종종 가용성, 신뢰성, 가격, 보안과 같은 측면을 측정 가능한 지표를 사용하여 다룬다.[41] 클라우드 컴퓨팅에서는 서로 다른 회사에서 관리할 수 있는 다양한 컴퓨팅 서비스가 사용되기 때문에 다계층(Multi-tier) SLA가 일반적이다.[42] 클라우드 컴퓨팅의 SLA는 2024년 기준2024년 기준 활발히 연구되는 분야이다.[43]

자유 및 오픈 소스 소프트웨어 라이선스

파일:Icons8 flat search.svg 이 부분의 본문은 자유 소프트웨어 라이선스 및 오픈 소스 사용권입니다.

1980년대 오픈 소스 운동 이전에는 거의 모든 소프트웨어가 사유였으며 소스 코드를 공개하지 않았다.[44] 오픈 소스 라이선싱은 개방성을 극대화하고 소프트웨어 사용, 보급, 후속 혁신에 대한 장벽을 최소화하는 것을 목표로 한다.[5]

오픈 소스 라이선스는 다음과 같은 몇 가지 주요 특징을 공유한다:[45]

  • 자유로운 재배포: 누구나 저작권자의 허가나 대가 없이 무료 또는 유료로 소프트웨어를 재배포할 수 있다.[45]
  • 소스 코드에 대한 무제한적이고 공개적인 접근[45]—오픈 소스라는 용어가 지칭하는 바이다.[46]
  • 사용자는 소프트웨어를 수정하고 자유 소프트웨어와 동일한 조건 하에, 또는 일부 경우에는 다른 라이선스 하에 2차적저작물을 출시할 수 있다.[45]
  • 상업적 이용을 포함하여 다양한 용도 간의 차별 금지.[45][9][5]

오픈 소스 이니셔티브는 자사의 오픈 소스 정의를 준수하는 새로운 오픈 소스 라이선스를 심사하고 승인한다.[45]

오픈 소스 라이선스의 유형

원형 차트는 가장 흔히 사용되는 오픈 소스 라이선스로 아파치 30%, MIT 26%, GPL 18%, BSD 8%, LGPL 3%, MPL 2%, 그리고 나머지 13%는 각각 1% 미만의 시장 점유율을 가진 라이선스임을 보여준다.
2022년 기준 가장 인기 있는 오픈 소스 라이선스는 아파치 라이선스(허용적), MIT 허가서(허용적), 그리고 GPL(카피레프트)이다.
  • 소프트웨어가 퍼블릭 도메인에 있는 경우, 소유자의 저작권은 소멸되었으며 누구나 저작권 제한 없이 저작물을 사용할 수 있다.[2]
  • 비제한적 라이선스(허용적 라이선스)는 2차적저작물의 라이선스에 대한 제한 없이 저작물의 자유로운 재사용을 허용한다.[4] 이들 중 다수는 원저작자의 표시를 요구한다.[47] 최초의 오픈 소스 라이선스는 과학적 협력을 촉진하기 위해 고안된 비제한적 라이선스인 BSD(Berkeley Software Distribution)였으며, 1978년 캘리포니아 대학교 버클리의 이름을 따서 명명되었다.[48]
  • 카피레프트 라이선스("동일조건변경허락")는[47] 소프트웨어와 함께 소스 코드를 배포할 것을 요구하며, 소스 코드가 유사한 라이선스 하에 제공될 것을 요구한다.[49][50] 카피레프트는 자유 소프트웨어로 간주되면서도 재사용이 제한될 수 있는 최대치를 나타낸다.[51] GNU 일반 공중 사용 허가서(GPL)와 같은 강력한 카피레프트 라이선스는 사유 소프트웨어에서의 재사용을 허용하지 않는 반면, 관련 라이선스인 GNU 약소 일반 공중 사용 허가서(LGPL)와 같은 약한 카피레프트는 일부 상황에서 재사용을 허용한다.[4] 카피레프트 라이선스는 개발자들에게 자신의 기여가 다른 이들에게 불공정한 이익을 주지 않도록 보장하는 방법으로 인식된다.[4][52] 카피레프트를 선택하는 또 다른 동기는 2차적저작물에 대한 요구 사항을 통해 오픈 소스를 촉진하는 것이다.[47] 리처드 스톨먼은 "카피레프트의 핵심 아이디어는 저작권법을 이용하되, 이를 일반적인 목적과는 반대되는 목적을 위해 뒤집는 것이다. 즉, 소프트웨어를 사유화하는 수단 대신 [저작권을] 소프트웨어를 자유롭게 유지하는 수단으로 만드는 것"이라고 밝혔다.[53]

소프트웨어 외의 분야에서는, 타인이 자신의 저작물로부터 과도하게 이익을 얻는 것을 막고자 하는 일부 예술가들 사이에서 비상업적 전용 크리에이티브 커먼즈 라이선스가 인기를 얻었다.[52] 그러나 비상업적 용도로만 제공되는 소프트웨어는 오픈 소스로 간주되지 않는다.[9] 썬 마이크로시스템즈의 비상업적 전용 Java Research License는 오픈 소스 커뮤니티에서 거부되었으며, 2006년 이 회사는 자바의 대부분을 GPL 하에 출시했다.[9]

호환성

파일:Icons8 flat search.svg 라이선스 호환성 문서를 참고하십시오.
파일:GPL-Compatible.svg
일부 오픈 소스 소프트웨어 라이선스 간의 호환성 도표

1989년 이후[44] 소프트웨어를 위한 다양한 오픈 소스 사용권이 만들어졌다.[54] 라이선스 범람으로 인해 오픈 소스 소프트웨어 라이선스를 선택하는 것은 점점 더 어려워지고 있으며,[55][56] 이들 중 다수는 사소한 차이만 있을 뿐이다.[57] 많은 라이선스가 서로 호환되지 않아 자유 소프트웨어 운동의 목표를 저해한다.[58] 번역 문제, 라이선스 조건의 모호함, 특정 관할권의 법률과 일부 라이선스의 불일치 등이 문제를 더욱 복잡하게 만든다.[59]

오픈 소스 모듈을 다운로드하는 것은 빠르고 쉽지만, 라이선스 조건을 준수하는 것은 더 어려울 수 있다.[60] 소프트웨어 의존성의 양 때문에 복잡한 프로젝트를 수행하는 엔지니어들은 오픈 소스 구성 요소의 라이선스 조건을 준수하도록 돕는 소프트웨어 라이선스 관리 소프트웨어에 의존해야 하는 경우가 많다.[61] 많은 오픈 소스 소프트웨어 파일이 라이선스를 명확하게 명시하지 않아 준수의 어려움을 가중시킨다.[60] 코드 베이스를 결합할 때 별도의 구성 요소에 대해 원래의 라이선스를 유지하고, 더 큰 저작물을 호환되는 라이선스 하에 출시할 수 있다.[62] 이러한 호환성은 종종 단방향이다. 퍼블릭 도메인 콘텐츠는 저작권 주장이 없으므로 어디서든 사용할 수 있지만, 거의 모든 조건 하에서 획득한 코드를 퍼블릭 도메인으로 포기할 수는 없다. 허용적 라이선스는 카피레프트 저작물 내에서 사용될 수 있지만, 카피레프트 자료를 허용적 라이선스 하에 출시할 수는 없다. 일부 약한 카피레프트 라이선스는 GPL 하에서 사용될 수 있으며 이를 GPL 호환이라고 한다. GPL 소프트웨어는 GPL 또는 AGPL 하에서만 사용될 수 있다.[63]

집행 가능성

파일:Icons8 flat search.svg 오픈 소스 라이선스 소송 문서에 이 부분의 추가 정보가 있습니다.

자유 및 오픈 소스 소프트웨어 라이선스는 2000년대 중반부터 민사 법원에서 성공적으로 집행되어 왔다.[64] 법원은 소프트웨어를 배포하는 것이 라이선스 조건의 수락을 의미한다고 판단했다.[65] 그러나 개발자들은 대개 소송 없이 준수를 이끌어낸다. 커뮤니티의 반발 가능성과 같은 사회적 압력만으로도 충분한 경우가 많다.[66] 정지명령 서신은 특히 독일에서 기업들이 다시 규정을 준수하도록 만드는 일반적인 방법이다.[67]

FOSS 커뮤니티 내에서 오랫동안 논의되어 온 주제는 오픈 소스 라이선스가 "순수 라이선스"(bare license)인지 아니면 계약인지 여부이다.[68] 순수 라이선스는 지식 재산권법에 의해 제한되는 행위가 허용되는 일련의 조건이다.[64] 자유 소프트웨어 재단(FSF)이 옹호하는 순수 라이선스 해석에 따르면, 저작권자는 저작권 침해로 사건을 법정에 제기한다.[64] 계약 해석에 따르면, 관련 당사자는 채무불이행(계약 위반)으로 사건을 법정에 제기할 수 있다.[69] 미국과 프랑스 법원은 두 가지 해석 모두에 따라 사건을 심리한 바 있다.[70]

가치

기업의 90% 이상이 사유 소프트웨어의 구성 요소로 오픈 소스 소프트웨어를 사용한다.[71] 오픈 소스 소프트웨어를 사용하거나 기존 오픈 소스 소프트웨어를 개선하기 위해 오픈 소스 프로젝트에 참여하기로 하는 결정은 대개 실용적인 비즈니스 결정이다.[72][73] 사유 소프트웨어가 오픈 소스 대안과 직접 경쟁할 때, 그 경쟁이 사유 제품의 가격과 품질에 미치는 영향에 대해서는 상충되는 연구 결과가 존재한다.[74]

수십 년 동안 일부 기업은 기업 사용자를 위해 오픈 소스 소프트웨어 제품을 서비스하는 것을 비즈니스 모델로 삼아왔다. 이러한 기업들은 오픈 소스 소프트웨어 제품을 관리하며 라이선스나 사용료를 청구하는 대신 개선, 통합 및 기타 서비스에 대해 요금을 부과한다.[75] 오픈 소스 구성 요소를 기반으로 한 서비스형 소프트웨어(SaaS) 제품이 점점 더 흔해지고 있다.[76]

오픈 소스 소프트웨어는 투명성을 높이고 과학적 결과의 검증과 수용을 돕기 때문에 과학적 응용 분야에서 선호된다.[57]

같이 보기

각주

  1. ↑ “Open Token Compensation License”. 《Open Token Compensation License homepage》. 2025년 3월 26일에 확인함. 
  2. ↑ 가 나 다 O'Regan 2022, 403쪽.
  3. ↑ 가 나 “Licenses”. 《Open Source Initiative》. 2022년 9월 16일. 2024년 5월 12일에 확인함. 
  4. ↑ 가 나 다 라 마 Sen, Subramaniam & Nelson 2008, 212쪽.
  5. ↑ 가 나 다 Morin et al. 2012, Free and Open Source Software (FOSS) Licensing.
  6. ↑ 가 나 O'Regan 2022, 394쪽.
  7. ↑ O'Regan 2022, 396쪽.
  8. ↑ Fagundes & Perzanowski 2020, 524쪽.
  9. ↑ 가 나 다 라 Davila 2015, 6쪽.
  10. ↑ 가 나 Boyle 2003, 45쪽.
  11. ↑ O'Regan 2022, 394–396쪽.
  12. ↑ Larry Troan (2005). “Open Source from a Proprietary Perspective” (PDF). 《RedHat Summit 2006 내슈빌》. redhat.com. 10쪽. 2014년 1월 22일에 원본 문서 (PDF)에서 보존된 문서. 2015년 12월 29일에 확인함. 
  13. ↑ 가 나 Terasaki 2013, 469쪽.
  14. ↑ Terasaki 2013, 469–470쪽.
  15. ↑ 가 나 Clohessy et al. 2020, 40–41쪽.
  16. ↑ Watt 2023, 4쪽.
  17. ↑ Dempsey & Kelliher 2018, 48쪽.
  18. ↑ Dempsey & Kelliher 2018, 48, 57쪽.
  19. ↑ Dempsey & Kelliher 2018, 61–63쪽.
  20. ↑ Dempsey & Kelliher 2018, 2쪽.
  21. ↑ 가 나 Corbett 2019, 455쪽.
  22. ↑ 가 나 Kim 2016, 12, 21쪽.
  23. ↑ Bakos et al. 2014, 1쪽.
  24. ↑ Ben-Shahar & Schneider 2014, 68쪽.
  25. ↑ Terasaki 2013, 485–486쪽.
  26. ↑ Corbett 2019, 456–457쪽.
  27. ↑ 가 나 Morin et al. 2012, Proprietary Licensing.
  28. ↑ Carpenter 2023, 485–486쪽.
  29. ↑ Ahuja 2016, 381쪽.
  30. ↑ Corbett 2019, 456쪽.
  31. ↑ Carpenter 2023, 480–481쪽.
  32. ↑ Carpenter 2023, 481–482쪽.
  33. ↑ Carpenter 2023, 485쪽.
  34. ↑ Carpenter 2023, 482–483쪽.
  35. ↑ Carpenter 2023, 478쪽.
  36. ↑ Corbett 2019, 460쪽.
  37. ↑ Terasaki 2013, 471쪽.
  38. ↑ Oprysk & Sein 2020, 620–621쪽.
  39. ↑ Corbett 2019, 461쪽.
  40. ↑ O'Regan 2022, 151, 219, 224, 405쪽.
  41. ↑ Qazi et al. 2024, Performance evaluation parameters.
  42. ↑ Rana & Ziegler 2010, 188쪽.
  43. ↑ Qazi et al. 2024, Conclusion.
  44. ↑ 가 나 Bernelin 2020, 96쪽.
  45. ↑ 가 나 다 라 마 바 Sen, Subramaniam & Nelson 2008, 209쪽.
  46. ↑ Morin et al. 2012, Open Source versus Closed Source.
  47. ↑ 가 나 다 Morin et al. 2012, Permissive versus Copyleft.
  48. ↑ Smith 2022, § 3.2.1.1.
  49. ↑ Sen, Subramaniam & Nelson 2008, 211–212쪽.
  50. ↑ St. Laurent 2004, 38–39쪽.
  51. ↑ Davila 2015, 5쪽.
  52. ↑ 가 나 Davila 2015, 5–6쪽.
  53. ↑ Joy 2022, 990–992쪽.
  54. ↑ Sen, Subramaniam & Nelson 2008, 208쪽.
  55. ↑ Alamoudi et al. 2020, 537쪽.
  56. ↑ Bernelin 2020, 94쪽.
  57. ↑ 가 나 Morin et al. 2012, Compatibility, Proliferation, Fragmentation, and Directionality.
  58. ↑ Bernelin 2020, 98쪽.
  59. ↑ Bernelin 2020, 100, 102쪽.
  60. ↑ 가 나 Ombredanne 2020, 105쪽.
  61. ↑ Ombredanne 2020, 106쪽.
  62. ↑ St. Laurent 2004, 159–163쪽.
  63. ↑ Smith 2022, § 3.3.
  64. ↑ 가 나 다 Smith 2022, § 3.4.1.
  65. ↑ Smith 2022, 106쪽.
  66. ↑ St. Laurent 2004, 158–159쪽.
  67. ↑ Ballhausen 2022, 127쪽.
  68. ↑ Walden 2022, § 1.1.
  69. ↑ Smith 2022, § 3.4.2.
  70. ↑ Smith 2022, § 3.4.
  71. ↑ Butler et al. 2022, 1쪽.
  72. ↑ Butler et al. 2022, 11152쪽.
  73. ↑ Davila 2015, 7쪽.
  74. ↑ Zhou & Choudhary 2022, 731쪽.
  75. ↑ August et al. 2021, 1–2쪽.
  76. ↑ August et al. 2021, 1쪽.

외부 링크

원본 주소 "https://www.hanul.wiki/w/index.php?title=소프트웨어_사용권&oldid=69798"