오픈 소스 사용권
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
오픈 소스 사용권은 지적 재산권을 기반으로 소프트웨어의 사용, 수정, 배포를 허용하는 법적 계약이다. 1980년대 리처드 스톨만에 의해 자유 소프트웨어 운동이 시작되었고, 1990년대에는 오픈 소스라는 용어가 등장하면서 다양한 라이선스들이 개발되었다. 오픈 소스 라이선스는 라이선스 호환성, 라이선스 감염, 퍼블릭 도메인 등의 쟁점을 가지고 있으며, 아파치, BSD, GPL, MIT 등 다양한 종류가 존재한다. 오픈 소스 라이선스는 법적으로 집행될 수 있으며, 독점 소프트웨어에서도 활용될 수 있다.
지적 재산권(IP)은 창의적인 결과물을 사유 재산과 유사한 재산으로 취급하는 법적 범주이다. 법률 시스템은 IP 소유자에게 여러 가지 방법으로 접근을 제한할 권리를 부여하며, 소유자는 자신의 재산을 판매, 임대, 증여 또는 라이선스할 수 있다. 상표, 특허, 저작권을 포함한 여러 유형의 IP 법률이 소프트웨어를 다룬다.
라이선스 호환성은 서로 다른 라이선스가 적용된 코드를 함께 배포할 수 있는지를 결정한다. 오픈 소스 라이선스는 자유로운 사용을 목표로 하지만, 서로 다른 요구 사항을 부과하는 여러 용어 사용은 복잡성을 야기한다.[3] 라이선스 확산으로 인해 사용 빈도가 낮은 라이선스가 많으며, 일부 프로젝트에서는 자체 주문형 계약을 작성하여 혼란을 야기하기도 한다.[3]
2. 역사적 배경
대부분의 국가에서 베른 협약에 따라 저작권법을 제정했다. 이러한 법률은 어떠한 고정된 형식으로든 저작물이 공개될 때마다 저작권을 부여한다. 미국의 저작권법에 따르면, 최초 공개는 원저작물로 간주된다. 창작자 또는 고용주는 이 원저작물에 대한 저작권을 가지며, 따라서 복제, 수정된 버전의 배포, 복사본 배포, 공개적인 공연 또는 공개적인 전시를 할 수 있는 배타적 권한을 갖는다. 원저작물의 수정된 버전은 2차적 저작물이다. 창작자가 기존 저작물을 수정할 경우, 그들은 해당 수정본에 대한 저작권을 갖는다.
1980년 미국 정부는 소프트웨어를 문학 작품으로 취급하도록 법률을 개정했다. 이 시점 이후에 공개된 소프트웨어는 IP 법률에 의해 제한을 받았다. 당시 미국의 활동가이자 프로그래머인 리처드 스톨만은 독점 소프트웨어의 확산과 폐쇄형 개발 모델을 비난했다. 이러한 경향에 맞서기 위해 스톨만은 자유 소프트웨어 운동을 시작했다. 1980년대 내내 그는 자유 운영 체제를 만들기 위해 GNU 프로젝트를 시작했고, 자유 소프트웨어 재단(FSF)을 설립하고 여러 자유 소프트웨어 라이선스를 작성했다.
1990년대에 "오픈 소스"라는 용어는 자유 소프트웨어의 대안으로 만들어졌으며, 어떤 라이선스가 자유 및 오픈 소스 소프트웨어를 다루는지 결정하기 위한 특정 기준이 마련되었다. 브루스 페렌스와 에릭 S. 레이먼드는 오픈 소스 이니셔티브(OSI)를 설립했다. 페렌스는 데비안에서 데비안 자유 소프트웨어 지침(DFSG)을 제안했다. OSI는 DSFG를 채택하고 이를 오픈 소스 정의의 기반으로 사용했다. 자유 소프트웨어 재단은 경쟁적인 기준, 즉 자유 소프트웨어 정의를 유지한다. 이 세 조직과 그들의 기준들은 라이선스가 자유 및 오픈 소스 소프트웨어를 다루는지 여부를 결정하는 데 있어 주목할 만한 권위자였다.
에릭 S. 레이먼드는 "자유 소프트웨어"보다 "오픈 소스"라는 용어를 지지했다. 그는 오픈 소스가 기업에 더 매력적이고 FOSS 개발의 유형적 이점을 더 잘 반영한다고 보았다. 레이먼드의 목표 중 하나는 기존의 해커 커뮤니티를 확장하여 대규모 상업 개발자를 포함시키는 것이었다. 레이먼드는 ''성당과 시장''에서 오픈 소스 개발을 시장과 비교했는데, 시장은 야외 공공 시장이었다. 그는 윤리적인 문제 외에도, 오픈 모델이 독점 소프트웨어가 복제할 수 없는 장점을 제공한다고 주장했다. OSI는 Sun Microsystems, IBM, Netscape, Mozilla, 아파치, 애플사(Apple Inc.), 마이크로소프트, 노키아를 포함한 기업 개발자들에게 오픈 소스 개발을 성공적으로 가져왔다.
2. 1. 한국에서의 오픈 소스 역사
3. 오픈 소스 라이선스의 종류
집합 저작물을 출시할 때 각 라이선스를 개별적으로 고려할 수 있지만, 소프트웨어를 결합하려는 경우, 다른 프로젝트의 코드는 해당 프로젝트가 호환되는 조건으로 사용하는 경우에만 라이선스를 부여받을 수 있다.[3] 코드 베이스를 결합할 때, 별도의 구성 요소에 대해 원래 라이선스를 유지하고 더 큰 작업을 호환되는 라이선스 하에 출시할 수 있다.[3] 이러한 호환성은 종종 단방향이다. 퍼블릭 도메인 콘텐츠는 저작권 주장이 없으므로 어디에서나 사용할 수 있지만, 거의 모든 조건 하에 획득한 코드는 퍼블릭 도메인으로 이전될 수 없다. 허용적 라이선스는 카피레프트 작업 내에서 사용될 수 있지만, 카피레프트 자료는 허용적 라이선스 하에 출시될 수 없다. 약한 카피레프트 라이선스는 GPL 하에서 사용될 수 있으며 GPL 호환이라고 한다. GPL 소프트웨어는 GPL 또는 AGPL 하에서만 사용할 수 있다.[3] 허용적 라이선스는 프로젝트의 별도 부분을 포괄할 수 있으므로 광범위하게 호환된다. GPL 및 아파치 라이선스를 포함한 여러 라이선스는 호환성을 향상시키기 위해 개정되었다.[3]
번역 문제, 라이선스 조건의 모호성, 특정 관할 구역의 법률과 일부 라이선스의 비호환성은 라이선스 호환성 문제를 더욱 복잡하게 만든다.[3] 오픈 소스 모듈을 다운로드하는 것은 간단하지만, 라이선스 조건을 준수하는 것은 더 어려울 수 있다.[3] 소프트웨어 종속성의 양으로 인해, 복잡한 프로젝트에서 작업하는 엔지니어는 오픈 소스 구성 요소의 라이선스 조건을 준수하기 위해 종종 라이선스 관리 소프트웨어에 의존한다.[3] 많은 오픈 소스 소프트웨어 파일은 라이선스를 명확하게 명시하지 않아 규정 준수의 어려움을 증가시킨다.[3]
오픈 소스 소프트웨어 개발에서 자신의 소프트웨어가 부과하는 라이선스 선택과 소프트웨어가 사용하는 소스 코드의 라이선스 검증은 중요하다. 자신의 소프트웨어에 부과하는 라이선스는 해당 소프트웨어의 소스 코드에 부과하는 것이지만, 오픈 소스 소프트웨어를 위한 라이선스는 다수 존재하며, 소프트웨어 개발의 수단과 목적, 소스 코드의 이용자에게 부과해야 할 제약에 맞춰 적절한 라이선스를 선택해야 한다. 소프트웨어 소스 코드의 이용, 수정, 재배포를 허용하는 오픈 소스 소프트웨어로서의 정의 준수 외에, 광고 조항 부여, 카피레프트 조항 부여, 저작권 포기 등을 고려해야 한다. 소프트웨어 이용자의 라이선스 해석을 검증하는 노력을 줄이기 위해 (라이선스 남용을 방지하기 위해), 오픈 소스 소프트웨어는 독자적인 라이선스를 생성, 적용하는 것이 아니라 기존 라이선스에서 선택하는 것이 바람직하다.
소프트웨어가 사용하는 소스 코드의 라이선스는 모듈로 사용하는 소프트웨어의 각 개별 라이선스에 대해 검증해야 한다. 아파치 라이선스처럼 광고 조항이 포함된 경우, 광고 조항에 따라 소스 코드 리포지토리의 COPYRIGHT, LICENSE 파일에 사용하고 있는 소프트웨어의 이름을 나열해야 하거나, 소프트웨어 이용자가 반드시 열람할 수 있는 부분에 소프트웨어 이름을 표시해야 한다. GNU GPL처럼 카피레프트 조항이 포함된 경우, 카피레프트 조항에 따라 자신의 라이선스를 결정하고, 자신의 소프트웨어에서 사용하고 있는 다른 소프트웨어와의 라이선스 호환성을 검증해야 한다.
라이선스 호환성은 특히 주의해야 하며, 소프트웨어가 사용하는 소스 코드에 라이선스 호환성이 없는 경우, 해당 소스 코드 및 소프트웨어를 이용할 수 없다. 예를 들어, "GNU GPL로 소스 코드 공개가 필수인 오픈 소스 소프트웨어"와 "상업적 계약으로 소스 코드 공개가 금지된 독점 소프트웨어"를 병용하려고 할 경우, GNU GPL을 준수하면 상업적 계약에 위반되고, 상업적 계약을 준수하면 GNU GPL에 위반된다.
3. 1. 라이선스 호환성
라이선스 호환성은 서로 다른 라이선스가 적용된 코드를 함께 배포할 수 있는지를 결정한다. 오픈 소스 라이선스는 자유로운 사용을 목표로 하지만, 서로 다른 요구 사항을 부과하는 여러 용어 사용은 복잡성을 야기한다.[3] 라이선스 확산으로 인해 사용 빈도가 낮은 라이선스가 많으며, 일부 프로젝트에서는 자체 주문형 계약을 작성하여 혼란을 야기하기도 한다.[3]
집합 저작물을 출시할 때 각 라이선스를 개별적으로 고려할 수 있지만, 소프트웨어를 결합하려는 경우, 다른 프로젝트의 코드는 해당 프로젝트가 호환되는 조건으로 사용하는 경우에만 라이선스를 부여받을 수 있다.[3] 코드 베이스를 결합할 때, 별도의 구성 요소에 대해 원래 라이선스를 유지하고 더 큰 작업을 호환되는 라이선스 하에 출시할 수 있다.[3] 이러한 호환성은 종종 단방향이다. 퍼블릭 도메인 콘텐츠는 저작권 주장이 없으므로 어디에서나 사용할 수 있지만, 거의 모든 조건 하에 획득한 코드는 퍼블릭 도메인으로 이전될 수 없다. 허용적 라이선스는 카피레프트 작업 내에서 사용될 수 있지만, 카피레프트 자료는 허용적 라이선스 하에 출시될 수 없다. 약한 카피레프트 라이선스는 GPL 하에서 사용될 수 있으며 GPL 호환이라고 한다. GPL 소프트웨어는 GPL 또는 AGPL 하에서만 사용할 수 있다.[3] 허용적 라이선스는 프로젝트의 별도 부분을 포괄할 수 있으므로 광범위하게 호환된다. GPL 및 아파치 라이선스를 포함한 여러 라이선스는 호환성을 향상시키기 위해 개정되었다.[3]
번역 문제, 라이선스 조건의 모호성, 특정 관할 구역의 법률과 일부 라이선스의 비호환성은 라이선스 호환성 문제를 더욱 복잡하게 만든다.[3] 오픈 소스 모듈을 다운로드하는 것은 간단하지만, 라이선스 조건을 준수하는 것은 더 어려울 수 있다.[3] 소프트웨어 종속성의 양으로 인해, 복잡한 프로젝트에서 작업하는 엔지니어는 오픈 소스 구성 요소의 라이선스 조건을 준수하기 위해 종종 라이선스 관리 소프트웨어에 의존한다.[3] 많은 오픈 소스 소프트웨어 파일은 라이선스를 명확하게 명시하지 않아 규정 준수의 어려움을 증가시킨다.[3]
오픈 소스 소프트웨어 개발에서 자신의 소프트웨어가 부과하는 라이선스 선택과 소프트웨어가 사용하는 소스 코드의 라이선스 검증은 중요하다. 자신의 소프트웨어에 부과하는 라이선스는 해당 소프트웨어의 소스 코드에 부과하는 것이지만, 오픈 소스 소프트웨어를 위한 라이선스는 다수 존재하며, 소프트웨어 개발의 수단과 목적, 소스 코드의 이용자에게 부과해야 할 제약에 맞춰 적절한 라이선스를 선택해야 한다. 소프트웨어 소스 코드의 이용, 수정, 재배포를 허용하는 오픈 소스 소프트웨어로서의 정의 준수 외에, 광고 조항 부여, 카피레프트 조항 부여, 저작권 포기 등을 고려해야 한다. 소프트웨어 이용자의 라이선스 해석을 검증하는 노력을 줄이기 위해 (라이선스 남용을 방지하기 위해), 오픈 소스 소프트웨어는 독자적인 라이선스를 생성, 적용하는 것이 아니라 기존 라이선스에서 선택하는 것이 바람직하다.
소프트웨어가 사용하는 소스 코드의 라이선스는 모듈로 사용하는 소프트웨어의 각 개별 라이선스에 대해 검증해야 한다. Apache License처럼 광고 조항이 포함된 경우, 광고 조항에 따라 소스 코드 리포지토리의 COPYRIGHT, LICENSE 파일에 사용하고 있는 소프트웨어의 이름을 나열해야 하거나, 소프트웨어 이용자가 반드시 열람할 수 있는 부분에 소프트웨어 이름을 표시해야 한다. GNU GPL처럼 카피레프트 조항이 포함된 경우, 카피레프트 조항에 따라 자신의 라이선스를 결정하고, 자신의 소프트웨어에서 사용하고 있는 다른 소프트웨어와의 라이선스 호환성을 검증해야 한다.
라이선스 호환성은 특히 주의해야 하며, 소프트웨어가 사용하는 소스 코드에 라이선스 호환성이 없는 경우, 해당 소스 코드 및 소프트웨어를 이용할 수 없다. 예를 들어, "GNU GPL로 소스 코드 공개가 필수인 오픈 소스 소프트웨어"와 "상업적 계약으로 소스 코드 공개가 금지된 독점 소프트웨어"를 병용하려고 할 경우, GNU GPL을 준수하면 상업적 계약에 위반되고, 상업적 계약을 준수하면 GNU GPL에 위반된다.
4. 주요 오픈 소스 라이선스
오픈 소스 이니셔티브(OSI)와 자유 소프트웨어 재단(FSF)은 각각 오픈 소스 라이선스와 자유 소프트웨어 라이선스 목록을 관리하고 승인한다.[18][19][22] 페도라[11]와 데비안[12]도 자체적인 라이선스 목록을 관리하며, 이는 각 배포판에 포함된 소프트웨어에 적용된다. 자유 소프트웨어 라이선스가 사용자들의 ''프로그램''의 사용과 수정, 그리고 공유의 자유에 초점을 두는 반면에, 오픈 소스 라이선스는 ''소스 코드''의 가용성과, 수정, 공유하는 것에 초점을 둔다.[80]
2018년 2월 현재, 널리 사용되거나 유명한 커뮤니티에서 채택하고 있는 주요 오픈 소스 라이선스는 다음과 같다.[52]
| 라이선스명 | 약칭 | OSI 승인 | FSF 승인 | GPL 호환성 | 카피레프트 |
|---|---|---|---|---|---|
| Apache License 2.0 | Apache-2.0 | [19] | [53] | [53] | [53] |
| 수정 BSD 라이선스 (3조항 BSD 라이선스) | BSD-3-Clause | [19] | [54] | [54] | [54] |
| 2조항 BSD 라이선스 | BSD-2-Clause | [19] | [55] | [55] | [55] |
| GNU General Public License, version 3 | GPLv3 | [19] | [56] | [57] | [56] |
| GNU Lesser General Public License, version 3 | LGPLv3 | [19] | [58] | [58] | （weak）[58] |
| MIT 라이선스 (X11 License) | MIT | [19] | [59] | [59] | [59] |
| Mozilla Public License 2.0 | MPL-2.0 | [19] | [60] | [60] | （weak）[61] |
| Common Development and Distribution License version 1.0 | CDDL-1.0 | [19] | [62] | [62] | （weak）[63] |
| Eclipse Public License 2.0 | EPL-2.0 | [19] | [64] | [64] | （weak）[64] |
| Creative Commons Attribution 4.0 license | CC BY | [65] | [65] | [65] | |
| Creative Commons Attribution-Sharealike 4.0 license | CC BY-SA | [66] | [66] | [66] | |
| Creative Commons Zero | CC0 | [67] | [68] | [68] | [68] |
5. 오픈 소스 라이선스와 관련된 쟁점
오픈 소스 라이선스는 라이선서(저작자)가 정한 誓約(서약)에 따라 라이선시(이용자)에게 소프트웨어와 소스 코드를 자유롭게 사용할 수 있도록 허용한다. 많은 라이선스에서 저작자가 소프트웨어 및 소스 코드를 "무보증(NO WARRANTY)"이라고 선언한 誓約(서약)을 명시하고 있으며,[14], 이 외에도 라이선스마다 다른 誓約(조항, 조문)이 기록된다.
오픈 소스 라이선스는 오픈 소스 소프트웨어의 성질상, 소프트웨어 및 그 2차 저작물은 원작자도 제어하기 어려운 형태로 유통되며, 작가가 그 품질을 보증하기 어렵기 때문에 기본적인 맹세로서 "유용하다고 생각하지만 무보증이다"라고 규정하고 있다[14]。 즉, 작가는 소프트웨어가 작가 및 이용자가 예상한 대로 작동할지 여부를 보증하지 않는다. 또한, 그 작동 결과로 인해 어떠한 손해가 사용자에게 발생하더라도, 작가는 그 하자 담보 책임을 보장하지 않는다.
저작권 표시 조항은 적절한 형태로 소스 코드나 부속 문서에 포함된 저작권 표시를 유지하며, 즉 2차적 저작물을 만든 자가 스스로 0부터 만든 것처럼 위장하지 않도록 규정한다.[15] 소스 코드를 동반하지 않는 바이너리 형식만의 배포를 허용하는 라이선스에서는, 그 경우에도 부속 문서에 저작권 표시를 기재하도록 규정하는 경우도 있다.
저작권 표시는 모든 소스 코드에 기재되는 작성자 명, 소프트웨어 프로젝트 패키지 내의 COPYRIGHT 파일, 최종 사용자가 열람 가능한 애플리케이션 상의 표시 등이 있다. 소스 코드 상의 저작권 표시를 최종 사용자가 확인하는 것은 어려우며, 애플리케이션 상의 저작권 표시를 최종 사용자가 확인하는 것은 쉽다. 저작권 표시에서 어느 정도까지의 이용자가 열람 가능한 표시를 할지는 개별 라이선스에 따른다.
동등한 조건의 라이선스인 Apache-2.0와 MIT에서는, Apache-2.0는 최종 사용자에게의 저작권 표시 조항을 포함하며, MIT는 최종 사용자에게의 저작권 표시 조항을 포함하지 않는다.
==== 라이선스 범람 (License Proliferation) ====
2000년대 초반, 오픈 소스 소프트웨어 라이선스는 다수의 독자적인 라이선스가 제정되어, 매우 유사한 조항에서 일부분만 다른, 유사한 라이선스가 무분별하게 만들어지는 현상이 발생했다. 이러한 현상은 라이선스 범람이라고 불리며 비판받았다.[37] 라이선스 범람은 라이선스 제작자의 허영심을 채우는 것에 불과한 무해한 것이 아니라, 오픈 소스 소프트웨어에 부여된 라이선스의 내용을 정밀하게 검토해야 하는 사용자를 피폐하게 만드는 유해한 것이었다. 오픈 소스 이니셔티브(OSI)는 2006년에 이 문제를 해결하기 위해 라이선스 범람 문제 프로젝트(License Proliferation Project)를 시작했고,[38] 라이선스 검토를 통해 승인된 라이선스를 선정함으로써 라이선스 범람을 억제한 역사가 있다.[39] 라이선스 범람을 재발시키지 않기 위해, 오픈 소스 소프트웨어의 라이선스는 기존 오픈 소스 라이선스를 채택하는 것이 권장된다.[19][40] 라이선스 제작자는 신규 라이선스의 필요성에 대해 신중한 검토를 거쳐 제정에 이르며,[41] 라이선스를 승인하는 단체는 신규 라이선스가 기존 라이선스와 본질적인 차이가 없을 경우 승인하지 않는 결정을 내리고 있다.[42]
==== 라이선스 감염 (Viral License) ====
라이선스 계승 조항을 포함하는 오픈 소스 라이선스가 적용된 소프트웨어는 해당 계승 조항에 따라 소프트웨어의 소스 코드를 사용하고 수정했을 경우 해당 소프트웨어의 소프트웨어 라이선스를 동일한 조건으로 제한한다. 이 라이선스 제한은 소스 코드의 2차 이용, 3차 이용으로 전파되며 라이선스가 바이러스처럼 감염되므로 바이러스성 라이선스(라이선스 감염)라고 한다[43]。
바이러스성 라이선스는 2차 이용 소스 코드의 라이선스를 동일한 것으로 강제함으로써 라이선스 범람을 방지하는 효력이 있다. 한편, 2차 이용 소스 코드 및 해당 소프트웨어의 라이선스를 선택할 권리를 잃게 되며, 적용되는 라이선스의 내용에 따라 광범위한 소스 코드 공개 강제, 비영리 외 이용 금지 등 이용상의 제약이 따를 수 있다.
라이선스 감염이 일어나는 라이선스의 예로는 GPL(카피레프트 조항)와 CC BY-SA (SA 조항)가 있다. 라이선스 감염의 영향은 원본 소프트웨어 라이선스의 내용에 따라 다르지만, GNU GPL의 카피레프트 조항처럼 소스 코드 공개를 의무로 하는 경우[16], CC BY-SA의 SA 조항처럼 동일 조건의 라이선스를 강제하는 경우(소스 코드 공개를 요구하는지는 다른 조항에 따름)가 있다[44]。
==== 퍼블릭 도메인 (Public Domain) ====
퍼블릭 도메인은 저작권이 소멸되거나 저작자가 저작권을 포기한 상태를 의미한다.[25] 저작권이 만료되면 해당 저작물은 퍼블릭 도메인에 들어가 누구나 자유롭게 이용할 수 있게 된다.[45] 일부 창작물은 저작권의 적용을 받지 않고 바로 퍼블릭 도메인에 들어가는데, 초기 컴퓨터 역사에서 소프트웨어가 이에 해당되었다.[35] 초기 컴퓨터 소프트웨어는 종종 하드웨어와 함께 제공되었으며,[35] MIT에서 개발된 선구적인 비디오 게임 스페이스워!는 PDP-1 컴퓨터를 마케팅하고 테스트하는 데 사용되었다.
로렌스 로젠 변호사에 따르면 저작권법은 창작자가 자신의 작품을 퍼블릭 도메인에 두는 것을 예상하고 작성되지 않았기 때문에, 지적 재산권법에는 저작권을 포기하는 명확한 경로가 없다. 따라서 "퍼블릭 도메인"으로 설명되는 매우 허용적인 라이선스는 무언가를 제공하지만 어떠한 조건도 부과하지 않는 일방적인 계약으로 법적으로 기능할 수 있다.[32]
크리에이티브 커먼즈 CC0[26][27], Unlicense[28][29], WTFPL[30][31] 등은 퍼블릭 도메인과 동등한 조건으로 소프트웨어를 배포하는 라이선스다. 이러한 퍼블릭 도메인 상당 라이선스는 저작권 주장을 퍼블릭 도메인으로 포기하는 것과 더불어 허용적 소프트웨어 라이선스를 대체 수단으로 제공하며, 퍼블릭 도메인 포기를 허용하지 않는 관할 구역에서는 허용적 라이선스가 효력을 발휘한다.
하지만 퍼블릭 도메인 포기는 단순한 학술적 라이선스와 한계를 공유하며, 이로 인해 외부 당사자가 특허 또는 상표법을 통해 퍼블릭 도메인 저작물을 통제하려고 시도할 가능성이 생긴다. 또한, 퍼블릭 도메인 포기는 모든 유형의 라이선스와 다르게 보증을 처리한다. MIT 라이선스와 같은 매우 허용적인 라이선스조차도 보증 및 책임을 부인하며, 무료 소프트웨어를 사용하는 사람은 누구나 이 부인을 조건으로 받아들여야 한다. 퍼블릭 도메인 콘텐츠는 모든 사람이 사용할 수 있으므로 저작권 포기는 부인을 부과할 수 없다.[67]
오픈 소스 이니셔티브는 퍼블릭 도메인의 저작권 권리 포기의 불확실성 때문에 오픈 소스로 승인하지 않는 판단을 내리고 있다.[33] 자유 소프트웨어 재단은 CC0를 퍼블릭 도메인에 소프트웨어 소스 코드를 공개하는 방법으로 권장하며[34][68], 다른 라이선스도 승인하고 있다.[22]
퍼블릭 도메인에 소스 코드가 공개되어 있는 경우에는 소스 코드 및 소스 코드에서 생성되는 소프트웨어의 이용, 수정, 재배포가 가능하지만, 퍼블릭 도메인에 소프트웨어만 공개되어 있는 경우에는 예외이다. 이 경우, 소프트웨어의 권리 포기는 예상되지만, 해당 소프트웨어의 소스 코드 권리 포기는 예상할 수 없어, 소스 코드의 이용, 수정, 재배포 가능 여부는 별도로 고려해야 한다.
일본의 저작권법에서는 저작물에 대해 저작인격권이 부가된다고 간주하고 있으며, 해당 권리에는 보호 기간이 없다(즉, 영구적이다).
==== 듀얼 라이선스 (Dual License) ====
오픈 소스 라이선스는 듀얼 라이선스로 사용되는 경우가 있다. 듀얼 라이선스의 오픈 소스 소프트웨어를 이용하는 경우, 이용자는 부과된 오픈 소스 라이선스 중 하나를 선택하여 선택한 라이선스가 부과된 오픈 소스 소프트웨어로 이용한다. 오픈 소스 소프트웨어에 듀얼 라이선스를 부과하는 주요 용도는 소프트웨어를 이용한 비즈니스 모델 구축과 라이선스 호환성 문제 해결이다.
3개 이상의 종류의 라이선스에서 선택할 수 있는 것을 멀티 라이선스라고 한다.
오픈 소스 라이선스에는 저작권 표시 조항의 강약이 다른 라이선스가 있으며, 하나의 소프트웨어에 이러한 라이선스를 병용하여 비즈니스상의 이점을 누리기 위해 듀얼 라이선스를 이용한다. 저작권 표시 조항의 강약이 다른 오픈 소스 라이선스를 듀얼 라이선스로 부과한 소프트웨어에서 이용자가 저작권 표시 조항이 강한 라이선스를 선택하여 소프트웨어를 이용하는 경우, 이용자는 저작권 표시 조항에 따라 소프트웨어의 명칭과 소프트웨어의 소스 코드 배포처를 2차 이용자(최종 사용자 포함)에게 알릴 의무를 갖는다. 소프트웨어 개발자(개발원)에게는 이용자가 선의의 광고탑이 되어 소프트웨어의 명칭이나 배포처를 많은 사람들에게 알릴 기회를 얻을 수 있다. 단, 이용자가 저작권 표시 조항이 없는 라이선스를 선택하여 소프트웨어를 이용할 수도 있으므로 반드시 이용자가 광고탑이 될 수 있는 것은 아니다. 예를 들어, 저작권 표시 조항이 강한 아파치 라이선스(Apache License)와 저작권 표시 조항이 약한 MIT 라이선스의 듀얼 라이선스가 있다.
소프트웨어 라이선스에는 라이선스 호환성의 유무가 있으며, 호환성이 없는 라이선스가 부과된 소프트웨어는 병용할 수 없다. 이러한 라이선스 호환성의 과제를 회피하기 위해 듀얼 라이선스를 이용한다. 소스 코드 이용 시 동일한 소프트웨어 라이선스를 부과할 것을 요구하는 조항이 있는 라이선스가 부과된 소프트웨어와 병용하는 경우, 해당 조항에 따라 자신이 개발한 라이선스는 동일한 소프트웨어 라이선스를 부과해야 한다. 그러나 그러한 조항이 없는 라이선스가 부과된 소프트웨어와 병용하는 경우, 자신이 개발한 소프트웨어 라이선스는 다른 것을 채용할 수 있다. 이용자가 어떤 라이선스가 부과된 소프트웨어와 병용하는지, 이용자가 2차 개발하는 소프트웨어에 어떤 라이선스를 부과하는지 등, 소프트웨어 라이선스 채택 선택의 폭을 넓힌다. 예를 들어, 카피레프트 조항이 있는 GPL과 카피레프트 조항이 없는 MIT의 듀얼 라이선스가 있다.
5. 1. 라이선스 범람 (License Proliferation)
2000년대 초반, 오픈 소스 소프트웨어 라이선스는 다수의 독자적인 라이선스가 제정되어, 매우 유사한 조항에서 일부분만 다른, 유사한 라이선스가 무분별하게 만들어지는 현상이 발생했다. 이러한 현상은 라이선스 범람이라고 불리며 비판받았다.[37] 라이선스 범람은 라이선스 제작자의 허영심을 채우는 것에 불과한 무해한 것이 아니라, 오픈 소스 소프트웨어에 부여된 라이선스의 내용을 정밀하게 검토해야 하는 사용자를 피폐하게 만드는 유해한 것이었다. 오픈 소스 이니셔티브(OSI)는 2006년에 이 문제를 해결하기 위해 라이선스 범람 문제 프로젝트(License Proliferation Project)를 시작했고,[38] 라이선스 검토를 통해 승인된 라이선스를 선정함으로써 라이선스 범람을 억제한 역사가 있다.[39] 라이선스 범람을 재발시키지 않기 위해, 오픈 소스 소프트웨어의 라이선스는 기존 오픈 소스 라이선스를 채택하는 것이 권장된다.[19][40] 라이선스 제작자는 신규 라이선스의 필요성에 대해 신중한 검토를 거쳐 제정에 이르며,[41] 라이선스를 승인하는 단체는 신규 라이선스가 기존 라이선스와 본질적인 차이가 없을 경우 승인하지 않는 결정을 내리고 있다.[42]5. 2. 라이선스 감염 (Viral License)
라이선스 계승 조항을 포함하는 오픈 소스 라이선스가 적용된 소프트웨어는 해당 계승 조항에 따라 소프트웨어의 소스 코드를 사용하고 수정했을 경우 해당 소프트웨어의 소프트웨어 라이선스를 동일한 조건으로 제한한다. 이 라이선스 제한은 소스 코드의 2차 이용, 3차 이용으로 전파되며 라이선스가 바이러스처럼 감염되므로 바이러스성 라이선스(라이선스 감염)라고 한다[43]。
바이러스성 라이선스는 2차 이용 소스 코드의 라이선스를 동일한 것으로 강제함으로써 라이선스 범람을 방지하는 효력이 있다. 한편, 2차 이용 소스 코드 및 해당 소프트웨어의 라이선스를 선택할 권리를 잃게 되며, 적용되는 라이선스의 내용에 따라 광범위한 소스 코드 공개 강제, 비영리 외 이용 금지 등 이용상의 제약이 따를 수 있다.
라이선스 감염이 일어나는 라이선스의 예로는 GPL(카피레프트 조항)와 CC BY-SA (SA 조항)가 있다. 라이선스 감염의 영향은 원본 소프트웨어 라이선스의 내용에 따라 다르지만, GNU GPL의 카피레프트 조항처럼 소스 코드 공개를 의무로 하는 경우[16], CC BY-SA의 SA 조항처럼 동일 조건의 라이선스를 강제하는 경우(소스 코드 공개를 요구하는지는 다른 조항에 따름)가 있다[44]。
5. 3. 퍼블릭 도메인 (Public Domain)
퍼블릭 도메인은 저작권이 소멸되거나 저작자가 저작권을 포기한 상태를 의미한다.[25] 저작권이 만료되면 해당 저작물은 퍼블릭 도메인에 들어가 누구나 자유롭게 이용할 수 있게 된다.[45] 일부 창작물은 저작권의 적용을 받지 않고 바로 퍼블릭 도메인에 들어가는데, 초기 컴퓨터 역사에서 소프트웨어가 이에 해당되었다.[35] 초기 컴퓨터 소프트웨어는 종종 하드웨어와 함께 제공되었으며,[35] MIT에서 개발된 선구적인 비디오 게임 스페이스워!는 PDP-1 컴퓨터를 마케팅하고 테스트하는 데 사용되었다.
로렌스 로젠 변호사에 따르면 저작권법은 창작자가 자신의 작품을 퍼블릭 도메인에 두는 것을 예상하고 작성되지 않았기 때문에, 지적 재산권법에는 저작권을 포기하는 명확한 경로가 없다. 따라서 "퍼블릭 도메인"으로 설명되는 매우 허용적인 라이선스는 무언가를 제공하지만 어떠한 조건도 부과하지 않는 일방적인 계약으로 법적으로 기능할 수 있다.[32]
크리에이티브 커먼즈 CC0[26][27], Unlicense[28][29], WTFPL[30][31] 등은 퍼블릭 도메인과 동등한 조건으로 소프트웨어를 배포하는 라이선스다. 이러한 퍼블릭 도메인 상당 라이선스는 저작권 주장을 퍼블릭 도메인으로 포기하는 것과 더불어 허용적 소프트웨어 라이선스를 대체 수단으로 제공하며, 퍼블릭 도메인 포기를 허용하지 않는 관할 구역에서는 허용적 라이선스가 효력을 발휘한다.
하지만 퍼블릭 도메인 포기는 단순한 학술적 라이선스와 한계를 공유하며, 이로 인해 외부 당사자가 특허 또는 상표법을 통해 퍼블릭 도메인 저작물을 통제하려고 시도할 가능성이 생긴다. 또한, 퍼블릭 도메인 포기는 모든 유형의 라이선스와 다르게 보증을 처리한다. MIT 라이선스와 같은 매우 허용적인 라이선스조차도 보증 및 책임을 부인하며, 무료 소프트웨어를 사용하는 사람은 누구나 이 부인을 조건으로 받아들여야 한다. 퍼블릭 도메인 콘텐츠는 모든 사람이 사용할 수 있으므로 저작권 포기는 부인을 부과할 수 없다.[67]
오픈 소스 이니셔티브는 퍼블릭 도메인의 저작권 권리 포기의 불확실성 때문에 오픈 소스로 승인하지 않는 판단을 내리고 있다.[33] 자유 소프트웨어 재단은 CC0를 퍼블릭 도메인에 소프트웨어 소스 코드를 공개하는 방법으로 권장하며[34][68], 다른 라이선스도 승인하고 있다.[22]
퍼블릭 도메인에 소스 코드가 공개되어 있는 경우에는 소스 코드 및 소스 코드에서 생성되는 소프트웨어의 이용, 수정, 재배포가 가능하지만, 퍼블릭 도메인에 소프트웨어만 공개되어 있는 경우에는 예외이다. 이 경우, 소프트웨어의 권리 포기는 예상되지만, 해당 소프트웨어의 소스 코드 권리 포기는 예상할 수 없어, 소스 코드의 이용, 수정, 재배포 가능 여부는 별도로 고려해야 한다.
일본의 저작권법에서는 저작물에 대해 저작인격권이 부가된다고 간주하고 있으며, 해당 권리에는 보호 기간이 없다(즉, 영구적이다).
5. 4. 듀얼 라이선스 (Dual License)
오픈 소스 라이선스는 듀얼 라이선스로 사용되는 경우가 있다. 듀얼 라이선스의 오픈 소스 소프트웨어를 이용하는 경우, 이용자는 부과된 오픈 소스 라이선스 중 하나를 선택하여 선택한 라이선스가 부과된 오픈 소스 소프트웨어로 이용한다. 오픈 소스 소프트웨어에 듀얼 라이선스를 부과하는 주요 용도는 소프트웨어를 이용한 비즈니스 모델 구축과 라이선스 호환성 문제 해결이다.3개 이상의 종류의 라이선스에서 선택할 수 있는 것을 멀티 라이선스라고 한다.
오픈 소스 라이선스에는 저작권 표시 조항의 강약이 다른 라이선스가 있으며, 하나의 소프트웨어에 이러한 라이선스를 병용하여 비즈니스상의 이점을 누리기 위해 듀얼 라이선스를 이용한다. 저작권 표시 조항의 강약이 다른 오픈 소스 라이선스를 듀얼 라이선스로 부과한 소프트웨어에서 이용자가 저작권 표시 조항이 강한 라이선스를 선택하여 소프트웨어를 이용하는 경우, 이용자는 저작권 표시 조항에 따라 소프트웨어의 명칭과 소프트웨어의 소스 코드 배포처를 2차 이용자(최종 사용자 포함)에게 알릴 의무를 갖는다. 소프트웨어 개발자(개발원)에게는 이용자가 선의의 광고탑이 되어 소프트웨어의 명칭이나 배포처를 많은 사람들에게 알릴 기회를 얻을 수 있다. 단, 이용자가 저작권 표시 조항이 없는 라이선스를 선택하여 소프트웨어를 이용할 수도 있으므로 반드시 이용자가 광고탑이 될 수 있는 것은 아니다. 예를 들어, 저작권 표시 조항이 강한 아파치 라이선스(Apache License)와 저작권 표시 조항이 약한 MIT 라이선스의 듀얼 라이선스가 있다.
소프트웨어 라이선스에는 라이선스 호환성의 유무가 있으며, 호환성이 없는 라이선스가 부과된 소프트웨어는 병용할 수 없다. 이러한 라이선스 호환성의 과제를 회피하기 위해 듀얼 라이선스를 이용한다. 소스 코드 이용 시 동일한 소프트웨어 라이선스를 부과할 것을 요구하는 조항이 있는 라이선스가 부과된 소프트웨어와 병용하는 경우, 해당 조항에 따라 자신이 개발한 라이선스는 동일한 소프트웨어 라이선스를 부과해야 한다. 그러나 그러한 조항이 없는 라이선스가 부과된 소프트웨어와 병용하는 경우, 자신이 개발한 소프트웨어 라이선스는 다른 것을 채용할 수 있다. 이용자가 어떤 라이선스가 부과된 소프트웨어와 병용하는지, 이용자가 2차 개발하는 소프트웨어에 어떤 라이선스를 부과하는지 등, 소프트웨어 라이선스 채택 선택의 폭을 넓힌다. 예를 들어, 카피레프트 조항이 있는 GPL과 카피레프트 조항이 없는 MIT의 듀얼 라이선스가 있다.
6. 오픈 소스 라이선스의 법적 집행
자유 및 오픈 소스 소프트웨어 라이선스는 2000년대 중반부터 민사 법원에서 성공적으로 집행되어 왔다.[4][5] Jacobsen v. Katzer(미국)와 Welte v. Sitecom(독일) 등의 초기 소송에서, 피고는 오픈 소스 라이선스가 무효라고 주장했으나, 미국과 독일 법원은 모두 이러한 주장을 기각했다. 법원은 라이선스를 집행할 수 없다면 피고가 해당 소프트웨어를 합법적으로 배포할 수 없었을 것이라고 판결했다.
법원은 소프트웨어 배포가 라이선스 조항에 대한 동의를 나타낸다고 판결했다.[51] 물리적 소프트웨어는 슈링크랩을 통해, 온라인 배포는 클릭랩을 통해 동의를 얻을 수 있다. 오픈 소스 소프트웨어는 저작권 소유자의 허가 없이는 법적으로 재배포가 금지되므로, 법원은 재배포를 라이선스 조건에 대한 동의로 간주한다.
개발자는 일반적으로 소송 없이 규정 준수를 달성한다. 커뮤니티의 반발 가능성과 같은 사회적 압력이 종종 충분하며,[46][47][48] 중단 및 포기 서신은 특히 독일에서 회사들이 규정을 준수하도록 하는 일반적인 방법이다.
다양한 법원에서 라이선스의 특정 측면을 어떻게 처리할지에 대한 불확실성이 남아 있다.[49] 일반적으로 소프트웨어의 경우, 무엇을 특허할 수 있고 무엇을 저작권으로 보호할 수 있는지에 대한 논쟁이 있다. 응용 프로그래밍 인터페이스(API)와 관련하여, 유럽 사법 재판소는 2012년 ''SAS Institute'' 사건에서 "컴퓨터 프로그램 인터페이스의 기초가 되는 아이디어와 원칙은 저작권으로 보호되지 않는다"라고 언급했다. 2021년 유사한 사건에서, 미국 대법원은 공정 사용 하에서 변형적 제품에서 API의 재창조를 허용했다.[6]
오픈 소스 라이선스가 "단순 라이선스"인지 계약인지에 대한 논쟁이 FOSS 커뮤니티 내에서 오랫동안 벌어졌다. 단순 라이선스 해석에 따르면, 사건은 저작권 소유자에 의해 저작권 침해로, 계약 해석에 따르면, 사건은 관련된 당사자에 의해 계약 위반으로 법원에 제기될 수 있다. 미국과 프랑스 법원은 두 가지 해석 모두에 따라 사건을 재판했다. FSF 및 소프트웨어 자유 보존 재단과 같은 비영리 단체는 규정 준수를 강제하기 위해 개발자의 프로젝트에 대한 권리를 보유하는 것을 제안한다.
7. 독점 소프트웨어에서의 활용
오픈 소스 라이선스는 다른 기업이 해당 소프트웨어를 상업적으로 활용하는 것을 허용한다. 허용적 라이선스가 적용된 코드는 독점 소프트웨어에 통합될 수 있다. 아파치(Apache), BSD, MIT 라이선스 하에 출시된 오픈 소스 코드는 독점 소프트웨어에 광범위하게 통합되어 왔다.
오픈 코어 모델은 개발자가 핵심 코드를 오픈 소스로 공개하고, 이를 포함하는 제품을 독점 소프트웨어로 판매하여 수익을 창출하는 비즈니스 모델이다.
클라우드 컴퓨팅 환경은 자유 및 오픈 소스 소프트웨어에 의존하며, 대부분의 라이선스 발동 조건을 회피한다. 클라우드 소프트웨어는 배포되는 것이 아니라 호스팅되기 때문에, 공급업체는 소프트웨어를 온라인으로 호스팅하고 최종 사용자는 사용 중인 코드를 다운로드하거나 접근할 필요가 없다. 이러한 상황은 라이선스 발동 조건을 회피하는 경우가 있어 논란이 되고있다. 개발자들은 돈이나 코드를 상류에 기여하지 않고 오픈 소스 소프트웨어를 호스팅하여 이익을 얻는 클라우드 회사를 비판하며, 이러한 관행을 스트립 마이닝에 비유하기도 한다. 클라우드 컴퓨팅 선두주자인 아마존 웹 서비스(Amazon Web Services)는 라이선스를 준수하고 고객의 최선의 이익을 위해 행동한다고 밝혔다.
8. 한국의 오픈 소스 생태계와 과제
참조
[1]
법원판례
https://scholar.goog[...]
2003
[2]
웹사이트
Full text of GNU Emacs copying permission notice
https://www.tech-ins[...]
1985
[3]
기타
[4]
법원판례
https://scholar.goog[...]
2019-02-18
[5]
법원판례
https://www.ifross.o[...]
2004
[6]
법원판례
https://scholar.goog[...]
2021
[7]
웹사이트
Brief Definition of Open Source Licenses
http://opensource.or[...]
Open Source Initiative
2013-04-25
[8]
서적
Best Practices for commercial use of open source software
Books on Demand
[9]
웹사이트
Licenses & Standards
https://opensource.o[...]
2018-02-09
[10]
웹사이트
Various Licenses and Comments about Them
https://www.gnu.org/[...]
2018-02-09
[11]
웹사이트
Licensing:Main
http://fedoraproject[...]
2018-02-09
[12]
웹사이트
License information
https://www.debian.o[...]
2018-02-09
[13]
웹사이트
Defining Open Source Software (OSS)
http://dodcio.defens[...]
2018-02-09
[14]
웹사이트
Open Source Software: a legal guide
https://www.lawgives[...]
LawGives
2018-03-08
[15]
웹사이트
OSS Attribution Obligations
https://www.nexb.com[...]
nexB
2018-03-08
[16]
웹사이트
What is Copyleft?
https://www.gnu.org/[...]
Free Software Foundation
2018-02-09
[17]
웹사이트
Copyleft Business
http://understanding[...]
2018-02-09
[18]
웹사이트
Licenses & Standards | Open Source Initiative
https://opensource.o[...]
2018-02-08
[19]
웹사이트
Open Source Licenses by Category | Open Source Initiative
https://opensource.o[...]
2018-02-09
[20]
웹사이트
What is "Open Source" software?
https://opensource.o[...]
2018-02-09
[21]
웹사이트
The fight for freedom
https://www.linuxvoi[...]
2018-02-09
[22]
웹사이트
Various Licenses and Comments about Them
https://www.gnu.org/[...]
2018-02-09
[23]
웹사이트
Licensing:Main Overview
https://fedoraprojec[...]
2018-02-20
[24]
웹사이트
Discussion of Licensing
https://fedoraprojec[...]
2018-02-15
[25]
웹사이트
Categories of free and nonfree
https://www.gnu.org/[...]
GNU Project
2018-03-05
[26]
웹사이트
CC0
https://creativecomm[...]
Creative Commons
2018-03-02
[27]
웹사이트
Creative Commons Tools
http://www.dcc.ac.uk[...]
Digital Curation Centre
2018-03-05
[28]
웹사이트
Unlicense Yourself: Set Your Code Free
http://unlicense.org
2017-02-28
[29]
웹사이트
The Unlicense: A License for No License
https://web.archive.[...]
OStatic
2017-05-18
[30]
웹사이트
WTFPL 2.0
http://www.wtfpl.net[...]
sam.zoy.org
2011-04-01
[31]
웹사이트
OSI Board Meeting Minutes, Wednesday, March 4, 2009
http://www.opensourc[...]
Open Source Initiative
2013-04-03
[32]
웹사이트
Public Domain Is Not Open Source
https://opensource.o[...]
2018-02-25
[33]
웹사이트
Public Domain Is Not Open Source
https://opensource.o[...]
Open Source Initiative
2018-02-09
[34]
웹사이트
Using CC0 for public domain software
http://creativecommo[...]
Creative Commons
2011-05-10
[35]
웹사이트
Categories of free and nonfree
https://www.gnu.org/[...]
GNU Project
2018-03-05
[36]
웹사이트
The Free-Libre / Open Source Software (FLOSS) License Slide
http://www.dwheeler.[...]
2007-09-27
[37]
웹사이트
OSI and License Proliferation
https://fossbazaar.o[...]
2018-02-09
[38]
웹사이트
The Licence Proliferation Project
http://opensource.or[...]
2011-05-10
[39]
웹사이트
The Licence Review Process | Open Source Initiative
https://opensource.o[...]
2018-02-08
[40]
웹사이트
How to choose a license for your own work
https://www.gnu.org/[...]
2018-02-09
[41]
웹사이트
Common Development and Distribution License (CDDL) Description and High-Level Summary of Changes
http://www.sun.com/c[...]
sun.com
2018-03-25
[42]
웹사이트
OSI Board Meeting Minutes, Wednesday, March 4, 2009
http://www.opensourc[...]
Open Source Initiative
2011-04-01
[43]
웹사이트
Speech Transcript - Craig Mundie, The New York University Stern School of Business
http://www.microsoft[...]
2011-02-07
[44]
웹사이트
Share Alike
https://wiki.creativ[...]
Creative Commons
2017-08-13
[45]
웹사이트
Public Domain Is Not Open Source
https://opensource.o[...]
2018-02-25
[46]
웹사이트
Ladies and Gentlemen, SCO v. IBM Is Officially Reopened
http://www.groklaw.n[...]
Groklaw
2014-09-17
[47]
웹사이트
SCO's Complaint In the Third Judicial District Court of Salt Lake County, State of Utah
http://groklaw.net/p[...]
2018-02-24
[48]
웹사이트
Archived copy
http://sco.tuxrocks.[...]
2004-08-02
[49]
웹사이트
Uses Mozilla Firefox trademark without permission
http://bugs.debian.o[...]
2018-02-24
[50]
웹사이트
[51]
웹사이트
Legal milestone for open source
http://news.bbc.co.u[...]
2018-02-09
[52]
웹사이트
Open Source Licenses by Category | Open Source Initiative
https://opensource.o[...]
2018-02-09
[53]
웹사이트
Apache License, Version 2.0
https://www.gnu.org/[...]
2018-02-09
[54]
웹사이트
Modified BSD license
https://www.gnu.org/[...]
2018-02-09
[55]
웹사이트
FreeBSD license
https://www.gnu.org/[...]
2018-02-09
[56]
웹사이트
GNU General Public License (GPL) version 3
https://www.gnu.org/[...]
2018-02-09
[57]
문서
GPLそのものであるため。
[58]
웹사이트
GNU Lesser General Public License (LGPL) version 3
https://www.gnu.org/[...]
2018-02-09
[59]
웹사이트
X11 License
https://www.gnu.org/[...]
2018-02-09
[60]
웹사이트
Mozilla Public License (MPL) version 2.0
https://www.gnu.org/[...]
2018-02-09
[61]
웹사이트
MPL 2.0 FAQ
https://www.mozilla.[...]
2018-02-09
[62]
웹사이트
Common Development and Distribution License (CDDL), version 1.0
https://www.gnu.org/[...]
2018-02-09
[63]
웹사이트
Top 10 Common Development and Distribution License (CDDL) Questions Answered
https://www.whitesou[...]
2018-02-09
[64]
웹사이트
Eclipse Public License Version 2.0
https://www.gnu.org/[...]
2018-02-09
[65]
웹사이트
Creative Commons Attribution 4.0 license
https://www.gnu.org/[...]
2018-02-09
[66]
웹사이트
Creative Commons Attribution-Sharealike 4.0 license
https://www.gnu.org/[...]
2018-02-09
[67]
웹사이트
OSI Board Meeting Minutes, Wednesday, March 4, 2009
https://opensource.o[...]
2018-02-09
[68]
웹사이트
CC0
https://www.gnu.org/[...]
2018-02-09
[69]
웹사이트
Creative Commons FAQ: Can I use a Creative Commons license for software?
https://creativecomm[...]
Creative Commons
2018-03-08
[70]
웹사이트
Shared Source Initiative
https://www.microsof[...]
Microsoft
2018-02-15
[71]
웹사이트
Perspectives on the Shared Source Initiative
http://www.onlamp.co[...]
2018-02-15
[72]
웹사이트
Microsoft gets the open-source licensing nod from the OSI
http://www.zdnet.com[...]
2018-02-15
[73]
웹사이트
SCEA Shared Source License 1.0
http://research.scea[...]
Sony Computer Entertainment Inc.
2018-02-14
[74]
웹사이트
Software License List
https://fedoraprojec[...]
Fedora
2018-02-14
[75]
웹사이트
Introducing “Business Source”: The Future of Corporate Open Source Licensing?
http://timreview.ca/[...]
2018-02-09
[76]
웹사이트
Open Source and Closed Source
https://www.eyerys.c[...]
2018-02-09
[77]
웹사이트
Basic closed-source license? - GDNet Lounge - GameDev.net
https://www.gamedev.[...]
2018-02-09
[78]
웹사이트
Q: What are antonyms for open source software?
http://dodcio.defens[...]
United States Department of Defense
2018-02-09
[79]
웹인용
Brief Definition of Open Source Licenses
http://opensource.or[...]
Open Source Initiative
2013-04-25
[80]
문서
Relationship between the Free Software movement and Open Source movement
https://www.gnu.org/[...]
Free Software Foundation, Inc
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com