맨위로가기

자유 소프트웨어 사용권

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

자유 소프트웨어 사용권은 소프트웨어의 사용, 수정, 배포의 자유를 보장하는 라이선스이다. 1980년대 GNU 프로젝트에서 시작되어, GNU 일반 공중 사용 허가서(GPL)를 통해 널리 사용되었다. 1990년대 이후 다양한 라이선스가 등장하며 라이선스 난립과 호환성 문제가 발생했고, 소프트웨어 특허 및 TiVo화와 같은 새로운 위협에 대응하기 위한 조항들이 추가되었다. 자유 소프트웨어 라이선스는 카피레프트, 특허 보복, 귀속, 면책 조항 등 다양한 조건을 포함하며, 라이선스 호환성, 사용 목적 제한, 라이선스 정의 충돌 등 실제적인 문제에 직면해 있다. 현재는 MIT 라이선스가 GPLv2를 제치고 가장 인기 있는 라이선스 중 하나가 되었으며, BSD 라이선스, 아파치 라이선스 등 다양한 유형의 라이선스가 존재한다.

더 읽어볼만한 페이지

  • 이용 약관 - 인터넷 프라이버시
    인터넷 프라이버시는 개인 식별 정보의 획득, 공개, 사용을 통제하려는 사용자의 권리 주장으로, IP 주소, 쿠키 등 기술적 요소와 온라인 광고, 사이버 범죄 등 다양한 위협에 대한 보호 노력을 포함하며, 개인 정보 보호 검색 엔진, 브라우저, 법률 및 규정을 통해 보호된다.
  • 이용 약관 - 개인정보처리방침
    개인정보처리방침은 개인 정보의 수집, 이용, 제공 등에 대한 기업이나 조직의 정책을 명시한 문서로, 컴퓨터 기술 발전과 함께 개인 정보 보호 필요성이 커지면서 각국에서 관련 법률이 제정되었으나, 효용성과 소비자의 이해도에 대한 비판도 제기되고 있다.
  • 자유 및 오픈 소스 소프트웨어 사용권 - GNU 약소 일반 공중 사용 허가서
    GNU 약소 일반 공중 사용 허가서(LGPL)는 GPL과 달리 비(L)GPL 프로그램에 저작물을 링크할 수 있도록 허용하는 자유 소프트웨어 라이선스로, 자유 및 사유 소프트웨어에 적용 가능하며 특정 조건 하에 배포를 허용하고, 라이브러리 사용 프로그램이 LGPL의 새 버전과 링크될 수 있도록 공유 라이브러리나 소스 코드 제공 방법을 활용한다.
  • 자유 및 오픈 소스 소프트웨어 사용권 - 카피레프트
    카피레프트는 저작권자가 저작물의 복제, 배포, 수정의 자유를 사용자에게 부여하고, 2차 저작물에도 동일한 라이선스를 적용하여 자유로운 공유와 발전을 장려하는 개념으로, 리처드 스톨만이 자유 소프트웨어 운동의 일환으로 알렸으며 GNU 일반 공중 사용 허가서가 대표적이다.
자유 소프트웨어 사용권
개요
유형소프트웨어 라이선스
특징소스 코드 사용, 수정, 배포 자유롭게 허용
파생 저작물에 동일 라이선스 적용 요구 (일부 라이선스)
주요 목표소프트웨어 사용자의 자유 보장
관련 개념오픈 소스 라이선스, 카피레프트
상세 정보
정의소프트웨어의 사용, 수정, 배포에 대한 특정한 자유를 사용자에게 부여하는 라이선스
주요 자유소프트웨어 실행의 자유
소프트웨어 연구 및 수정의 자유
소프트웨어 복제 및 배포의 자유
수정된 버전 배포의 자유
제한 사항저작자 표기 의무
라이선스 조건 유지 의무 (카피레프트 라이선스)
보증 부인
유형
허용적 라이선스기능 제한이 적음
MIT 라이선스, BSD 라이선스, 아파치 라이선스 등이 해당
카피레프트 라이선스파생 저작물에 동일 라이선스 적용
GNU 일반 공중 사용 허가서 (GPL) 등이 해당
역사
배경자유 소프트웨어 운동의 철학적 기반
주요 인물리처드 스톨먼
특징
소스 코드 공개필수적으로 소스 코드를 공개해야 함
자유로운 사용누구나 자유롭게 사용, 복제, 배포 가능
수정 가능소스 코드 수정 및 개선 가능
파생 저작물라이선스 조건에 따라 소스 코드 공개 의무 발생 가능
카피레프트 라이선스의 경우 파생 저작물도 동일한 라이선스를 따라야 함
장점
사용자 자유 증진소프트웨어 사용자의 권리 강화
기술 혁신 촉진공동 개발 및 개선 용이
보안 강화소스 코드 공개로 인한 보안 취약점 발견 및 수정 용이
단점
상업적 이용 제한카피레프트 라이선스의 경우 상업적 이용에 제약 발생 가능
라이선스 조건 준수 의무
예시
주요 라이선스GNU 일반 공중 사용 허가서 (GPL)
MIT 라이선스
BSD 라이선스
아파치 라이선스
관련 단체
주요 단체자유 소프트웨어 재단 (FSF)
오픈 소스 이니셔티브 (OSI)

2. 역사

자유 소프트웨어 사용권의 역사는 초기의 비공식적인 소스 코드 공유 문화에서 시작되었다. 저작권법이 소프트웨어에도 적용되면서 사용권의 필요성이 대두되었고, 1980년대 GNU 프로젝트를 통해 카피레프트 개념에 기반한 GNU 일반 공중 사용 허가서(GPL)가 등장하며 본격적으로 발전하기 시작했다.

이후 오픈 소스 운동의 확산과 함께 다양한 라이선스가 등장했으나, 이는 라이선스 호환성 문제를 야기하기도 했다.[81] 또한, 소프트웨어 특허 소송[82]이나 하드웨어 제약을 통한 소프트웨어 수정 제한(TiVo화)[83]과 같은 새로운 법적, 기술적 도전에 대응하며 라이선스는 지속적으로 변화해왔다. GNU GPL과 같은 주요 라이선스는 법정 공방을 통해 그 법적 효력을 인정받기도 했다.

2. 1. 1980년대 이전

소프트웨어 초기에는 학술 기관과 같은 특정 커뮤니티에서 소프트웨어와 소스 코드를 공유하는 것이 일반적이었다.

1974년 미국 저작권법 신기술 사용 위원회(CONTU)가 "컴퓨터 프로그램은 저작자의 독창적인 창작물을 구현하는 한, 저작권의 적절한 대상이 된다"고 결정하기 전까지[3][4] 소프트웨어는 저작권 보호 대상으로 간주되지 않았다. 따라서 당시 소프트웨어에는 별도의 소프트웨어 라이선스가 붙지 않았고, 퍼블릭 도메인 소프트웨어로 자유롭게 공유되었다. CONTU의 결정과 1983년 오브젝트 코드에 대한 ''애플 대 프랭클린''(Apple v. Franklin) 판결 등 법원의 판단을 통해, 저작권법이 컴퓨터 프로그램에도 문학 작품과 동일한 지위를 부여한다는 점이 명확해지면서 소프트웨어 라이선스가 등장하기 시작했다.

1980년대 후반 이전까지 사용된 자유 소프트웨어 라이선스는 대부분 개발자가 직접 작성한 비공식적인 형태였으며, 주로 "퍼미시브 라이선스" 유형에 속했다.

2. 2. 1980년대

1980년대 중반, GNU 프로젝트는 각 소프트웨어 패키지에 대해 카피레프트 개념을 적용한 자유 소프트웨어 라이선스를 만들기 시작했다. 이러한 노력의 일환으로 1985년 GNU Emacs를 위한 초기 라이선스인 "GNU Emacs 복사 허가 통지"가 만들어졌으며,[5] 같은 해 말 "GNU Emacs 일반 공중 사용 허가서"로 수정되었고, 이후 1987년 3월과 1988년 2월에 걸쳐 내용이 명확하게 다듬어졌다.[6][7][8]

GNU 컴파일러 모음(GCC) 역시 1987년 처음 공개될 때 유사한 "GCC 일반 공중 사용 허가서"가 적용되었다.[9][10] 1988년에는 초기 BSD 라이선스가 등장했는데, 이 또한 초기의 중요한 자유 소프트웨어 라이선스 중 하나로 평가받는다.

1989년, GNU 프로젝트는 이전에 개별적으로 존재하던 라이선스들을 통합하여 GNU 일반 공중 사용 허가서 (GPL) 버전 1을 발표했다. 이후 1991년에 발표된 GPL 버전 2는 가장 널리 사용되는 자유 소프트웨어 라이선스로 자리 잡게 되었다.[11][12][13]

2. 3. 1990년대 - 2000년대

1990년대 중반부터 2000년대 중반까지 오픈 소스 운동이 활발해지면서 자유 소프트웨어의 개념이 대중과 기업에게 널리 알려지기 시작했다.[14] 특히 1998년 닷컴 버블 시기에 넷스케이프 커뮤니케이션즈가 자사의 웹 브라우저 소스 코드를 자유 및 오픈 소스 소프트웨어(FOSS) 라이선스로 공개한 것은 중요한 계기가 되었다.[15][16] 이는 모질라, 아파치 재단, 썬 마이크로시스템즈 등 다른 기업들이 FOSS 생태계에 참여하고 기여하는 계기를 마련했다.[17] (관련 라이선스 목록 참조)

이러한 흐름 속에서 여러 기업과 새로운 프로젝트들이 독자적인 FOSS 라이선스를 만들거나 기존 라이선스를 수정하기 시작했다. 이러한 라이선스 다변화 현상은 라이선스 호환성 문제를 야기하고 라이선스 관리를 복잡하게 만들어 FOSS 생태계의 주요한 과제로 떠올랐다.[18][81] 라이선스 종류가 무분별하게 늘어나는 라이선스 난립 경향은 이후 다소 둔화되었지만, 호환성 문제는 여전히 FOSS 생태계가 해결해야 할 중요한 문제로 남아있다.

1990년대에는 소프트웨어 특허를 이용한 소송이 증가하면서 자유 소프트웨어를 보호하기 위한 새로운 장치가 필요해졌다. 이에 따라 특허 침해 시 라이선스 권한을 박탈하는 특허 보복 조항 등이 라이선스에 포함되기 시작했다.[82] 2000년대 들어서는 하드웨어 제조사가 소프트웨어 수정을 제한하는 TiVo화라는 새로운 문제가 등장하여, 일부 기존 자유 소프트웨어 라이선스로는 사용자의 권리를 충분히 보호하기 어려운 상황이 발생하기도 했다.[83]

한편, 가장 널리 사용되던 GNU GPL 버전 2는 2004년경 독일과 미국에서 법적 효력을 인정받았다.

  • 독일 법원은 'netfilter/iptables' 소프트웨어 관련 소송에서 GPL 조항의 유효성을 직접적으로 판단하지는 않았지만, 피고가 해당 소프트웨어를 사용하기 위해서는 GPL을 준수해야 한다고 판결했다. 피고가 GPL을 위반했기 때문에 소프트웨어 사용 중단 명령을 받았다.[19]
  • 미국에서는 MySQL이 Progress Software를 상대로 제기한 소송이 판결 전에 합의로 종결되었지만, 담당 판사는 초기 심리에서 GPL을 법적으로 집행하지 못할 이유를 찾지 못했다고 언급하며 GPL의 법적 구속력을 간접적으로 시사했다.[20]


2004년경 변호사 로렌스 로젠은 "공개 도메인이 왜 라이선스가 아닌가"라는 글을 통해 소프트웨어 저작권은 완전히 포기될 수 없으며, 따라서 공개 도메인으로 간주될 수 없다고 주장했다. 이는 매우 허용적인 FOSS 라이선스와도 다르다는 입장이었다.[21] 다니엘 J. 번스타인 등 일부 개발자들은 로젠의 주장에 반박했다.[22] 이 논쟁은 2012년 로젠이 CC0 라이선스를 오픈 소스 라이선스로 인정하면서 일단락되었다. 그는 미국 제9 연방 순회 항소 법원의 판결을 근거로 저작권 포기가 법적으로 가능하다는 점을 받아들이며 자신의 이전 주장을 철회했다.[23]

소프트웨어 특허와 TiVo화 같은 새로운 문제에 대응하기 위해 자유 소프트웨어 재단(FSF)은 2006년 GNU GPL 버전 3의 초안을 발표했고, 수년간의 논의를 거쳐 2007년에 공식 발표했다. 하지만 GPLv3는 라이선스 적용 범위가 크게 확장되면서 GPLv2와 호환되지 않는다는 문제점이 제기되어 논란을 낳았다.[24][48] 이로 인해 리눅스 커널,[25][26] MySQL,[27] BusyBox,[28][29] 블렌더,[30] VLC 미디어 플레이어[31] 등 여러 주요 FOSS 프로젝트들이 GPLv3 채택을 거부했다. 반면, 2009년 구글의 오픈 소스 프로그램 매니저였던 크리스 디보나는 구글 코드에 호스팅된 프로젝트를 포함하여 약 50%의 프로젝트가 GPLv2에서 GPLv3로 라이선스를 전환했다고 밝히기도 했다.[32]

2. 4. 2010년대

2011년, GPLv3가 출시된 지 4년 후, 블랙 덕 소프트웨어(Black Duck Software)의 자료에 따르면 오픈 소스 라이선스 프로젝트 중 6.5%가 GPLv3를 사용했고, 여전히 42.5%는 GPLv2를 사용하고 있었다.[26][33] 같은 해, ''451 그룹(451 Group)''의 분석가 매튜 애슬렛(Matthew Aslett)은 이 통계를 바탕으로 카피레프트 라이선스가 줄어들고 허가형 라이선스가 증가하는 추세라고 주장했다.[34][35]

이러한 경향은 계속되어, 2015년에는 블랙 덕 소프트웨어[76]와 깃허브(GitHub) 통계[79]에 따라 허가형 라이선스인 MIT 라이선스가 GPLv2를 제치고 두 번째로 인기 있는 자유 소프트웨어 라이선스가 되었다. 또 다른 허가형 라이선스인 아파치 라이선스는 이미 3위를 차지하고 있었다. 2016년 6월, 페도라 프로젝트의 패키지 분석 결과에서도 가장 많이 사용되는 라이선스는 GPL 계열, MIT 라이선스, BSD 계열 라이선스, 그리고 LGPL 순서로 나타나, 허가형 라이선스의 강세가 확인되었다.[36]

3. 자유 소프트웨어 라이선스의 조건

자유 소프트웨어 운동 내에서는 어떤 종류의 제약 조건까지 자유 소프트웨어로 인정될 수 있는지에 대한 논쟁이 계속되고 있다.

완전히 제약이 없는 소프트웨어는 퍼블릭 도메인 소프트웨어나 퍼블릭 도메인과 유사한 라이선스를 따르는 경우뿐이다. 예를 들어, WTFPL이나 CC0와 같은 라이선스가 여기에 해당한다. 허가형 라이선스는 원 저작자의 저작자 표시와 같은 최소한의 의무만을 부과하며, 사실상 거의 모든 방식의 코드 사용을 허용한다.

반면, 카피레프트 라이선스와 같은 특정 라이선스들은 더 강력한 제한을 의도적으로 포함한다. 이는 파생된 프로젝트에서도 원본 소프트웨어가 보장했던 특정 권리(자유)들이 그대로 유지되도록 하기 위함이며, 특히 소프트웨어를 배포하는 사람에게 적용되는 경우가 많다.

이처럼 많은 자유 소프트웨어 라이선스는 소프트웨어의 사용, 학습, 수정, 재배포라는 핵심적인 자유를 지키기 위해 배포자에게 적용되는 여러 요구 사항이나 제약 조건을 담고 있다. 어떤 제약이 자유를 지키는 데 필요한 것이고, 어떤 제약이 오히려 자유를 과도하게 제한하는지에 대한 경계는 자유 소프트웨어 커뮤니티 내에서 활발하게 논의되는 주제이다.

3. 1. 카피레프트

1980년대 중반 리처드 스톨먼이 작성한 자유 소프트웨어 라이선스들은 카피레프트라는 개념을 개척했다. 카피레프트 조항은 자유 소프트웨어의 수정된 버전을 배포할 때, 원본 소프트웨어와 동일한 조건으로 배포해야 한다고 명시한다. 따라서 카피레프트 소프트웨어에 대한 모든 개선이나 기능 추가 역시 자유 소프트웨어로 배포되어야 한다. 이는 "공유 동일"(share and share alike) 또는 라틴어로 quid pro quo|퀴드 프로 크오la(quid pro quo, 대응)라고도 불린다. 이는 새로운 소프트웨어 역시 오픈 소스가 됨을 의미하며, 소프트웨어의 후속 버전에서도 코드를 수정할 자유를 보장하므로 "자유 소프트웨어"이다. 반면, 카피레프트가 아닌 라이선스는 소프트웨어의 후속 버전에서 자유가 유지되도록 보장하지 않는다.

GPL 코드를 제품에 사용하는 개발자는 소스 코드를 오브젝트 코드와 함께 공유하거나 판매할 때 누구나 이용할 수 있도록 제공해야 한다. 이때 제공되는 소스 코드에는 개발자가 수정한 내용도 포함되어야 한다. 만약 GPL 코드를 사용하지만 이를 배포하거나 판매하지 않는 경우에는 코드를 제공할 의무가 없으며, 변경 사항은 비공개로 유지될 수 있다. 이는 개발자나 조직이 개인적인 목적(코드나 프로젝트가 판매되거나 배포되지 않는 경우)으로 GPL 코드를 사용하고 수정할 수 있게 하며, 변경 내용을 대중에 공개할 필요가 없음을 의미한다.

GPL 지지자들은 파생 저작물이 GPL 하에 유지되도록 의무화함으로써 자유 소프트웨어의 성장을 촉진하고 모든 사용자의 동등한 참여를 요구한다고 주장한다. 반면, GPL 반대자들은 "어떤 라이선스도 미래의 소프트웨어 가용성을 보장할 수 없다"고 주장하며[38], GPL의 단점이 장점보다 크다고 본다.[39] 일부는 배포를 제한하는 것 자체가 라이선스를 덜 자유롭게 만든다고 주장하기도 한다. 이에 대해 지지자들은 배포 시 자유를 보존하지 않으면 오히려 덜 자유로워진다고 반박한다. 예를 들어, 카피레프트가 아닌 라이선스는 저작물이 공개적으로 게시되더라도 수정된 버전을 볼 자유를 저자에게 부여하지 않지만, 카피레프트 라이선스는 그러한 자유를 보장한다.

자유 소프트웨어의 사용, 학습, 수정, 재배포의 자유를 지키기 위해 많은 자유 소프트웨어 라이선스는 배포자에게 적용될 요구 사항과 제약을 포함하고 있다. 자유 소프트웨어 커뮤니티 내에서는 자유를 지키는 제약과 자유를 제한하는 제약 사이의 경계를 어디에 두어야 할지에 대한 논의가 활발히 이루어지고 있다.

일부 카피레프트 조항을 포함하는 자유 소프트웨어 라이선스는 해당 조항에 따라 2차 저작물의 소프트웨어 라이선스에도 원 저작물과 동일하거나 동등한 라이선스를 적용할 것을 요구한다.[89] 이를 라이선스 감염이라고 부르기도 하는데, 원 저작물의 라이선스 제약에 따라 소프트웨어의 소스 코드 공개, 2차 저작자의 광고 조항 의무, 연동되는 다른 소프트웨어에 대한 라이선스 적용 등의 필요성이 발생할 수 있다.

3. 2. 특허 보복

1990년대 들어 소프트웨어 특허 관련 소송이 늘어나면서, 자유 소프트웨어 사용권은 이를 방어하기 위해 특허 보복 조항을 포함하기 시작했다. 이러한 특허 위협은 2006년 GNU GPL 버전 3(GPLv3)을 만드는 주요 이유 중 하나이기도 했다.[40]

특허 보복 조항은 특정 조건 하에서 라이선스 사용자에게 부여된 권리(예: 소프트웨어 재배포 권리)가 종료될 수 있음을 명시한다. 예를 들어, 라이선스 사용자가 해당 소프트웨어와 관련된 특허를 이용하여 소송을 제기하는 경우 권리가 박탈될 수 있다. 애플 공개 소스 라이선스(Apple Public Source License)는 사용자가 애플을 상대로 특허 소송을 시작하면 해당 라이선스에 따른 권리를 종료시킬 수 있도록 규정하고 있다. 이처럼 특허 보복 조항은 소프트웨어 특허의 확산과 남용에 대한 대응책으로 등장했다.

최근에는 티보화(tivoization)라는 용어도 등장했는데, 이는 TiVo와 같이 하드웨어가 특정 소프트웨어의 수정된 버전 실행을 막는 기술적 제한을 가리킨다. 자유 소프트웨어 재단(FSF)은 티보화가 자유 소프트웨어를 실질적으로 비자유롭게 만드는 방법이라고 보고 GPLv3에서 이를 금지하도록 했다.[41]

자유 소프트웨어의 핵심 가치인 사용, 학습, 수정, 재배포의 자유를 지키기 위해 많은 라이선스는 배포자에게 특정 요구 사항이나 제약을 부과한다. 어느 정도의 제약이 자유를 지키는 것이고 어느 정도가 자유를 침해하는 것인지에 대한 경계는 자유 소프트웨어 커뮤니티 내에서 계속 논의되는 주제이다. 1990년대 후반 이후 새로 만들어진 대부분의 자유 소프트웨어 라이선스는 어떤 형태로든 특허 보복 조항을 포함하고 있다.

3. 3. 귀속, 면책 조항 및 고지

대부분의 자유 소프트웨어 라이선스는 소프트웨어를 수정한 경우, 그것이 원본과 동일하다거나 수정되지 않았다고 주장하는 것을 금지한다. 또한, 많은 라이선스는 원본 저작권 소유자에 대한 표시를 요구한다.

예를 들어, GNU GPL 버전 2는 보증이나 라이선스에 관한 정보를 표시하는 대화형 프로그램을 수정하여 재배포할 때, 이러한 고지 사항을 임의로 제거할 수 없도록 규정하고 있다.

4. 자유 소프트웨어 라이선스의 실제 문제

자유 소프트웨어 라이선스는 소프트웨어의 자유로운 사용, 수정, 배포를 보장하지만, 실제 적용 과정에서는 몇 가지 중요한 문제점들이 발생하기도 한다. 대표적인 문제로는 서로 다른 라이선스 간의 조건을 맞추기 어려운 라이선스 호환성 문제와, 특정 목적이나 방식의 사용을 제한하려는 시도에서 비롯되는 사용 목적 제한 관련 논란 등이 있다.

4. 1. 라이선스 호환성

400px


서로 다른 요구 사항을 가진 라이선스가 적용된 소프트웨어 패키지는 소스 코드를 결합하여 새로운 패키지를 만드는 것을 어렵거나 불가능하게 만들 수 있다.[43][87] 각 라이선스의 요구 사항이 서로 모순될 경우, 두 요구 사항을 동시에 만족시킬 수 없기 때문이다.

예를 들어, 한 라이선스가 "수정된 버전은 모든 광고 자료에 개발자를 언급해야 한다"고 규정하고, 다른 라이선스가 "수정된 버전은 추가적인 귀속 요구 사항을 포함할 수 없다"고 규정한다면, 이 두 라이선스가 적용된 소프트웨어를 결합하여 배포하는 것은 불가능하다. 따라서 이 두 라이선스는 서로 호환되지 않는다.[47][88]

특히 카피레프트 라이선스와 다른 유형의 라이선스 간의 호환성은 종종 단방향으로만 가능하다.[44] 이는 카피레프트 조항이 파생 저작물도 원본과 동일하거나 유사한 조건으로 배포하도록 요구하는 경우가 많기 때문이다.[89] 리처드 스톨만이 1980년대 중반에 개척한 카피레프트 개념은 자유 소프트웨어의 개정판 역시 자유롭게 유지되도록 하여, 자유 소프트웨어의 성장을 촉진하고 모든 이용자의 참여를 독려하려는 목적을 가진다. GPL 코드를 사용한 제품의 개발자는 소스 코드를 공개해야 하며, 여기에는 모든 수정 사항이 포함되어야 한다. 단, 배포하지 않는 경우에는 공개 의무가 없다.

반면, 아파치 라이선스와 같은 비 카피레프트 허용적 라이선스는 라이선스 간 상호 작용이 덜 복잡하며 일반적으로 더 나은 호환성을 제공한다.[46][47] 이러한 단방향 호환성 특성 때문에 아파치 재단 등 일부에서는 허용적 라이선스를 선호하며 카피레프트를 비판하기도 한다.[45]

카피레프트 라이선스끼리도 호환되지 않는 경우가 있는데, 예를 들어 널리 사용되는 GPLv2 라이선스는 GPLv3 라이선스와 호환되지 않는다.[48][49]

4. 2. 사용 목적

자유 소프트웨어 라이선스는 일반적으로 소프트웨어 사용 목적에 제한을 두지 않는다. 이는 FSF, OSI, 데비안, BSD 기반 배포판 등 주요 기관 및 프로젝트에서 공유하는 원칙이다.[51][85] 예를 들어, 소프트웨어를 비공개 용도로만 사용하게 하거나, 군사적 목적으로 사용하는 것을 금지하거나, 특정 소프트웨어와의 비교 또는 벤치마크 테스트를 막거나, '선한 목적'으로만 사용하도록 강제하거나, 윤리적으로 문제가 있다고 여겨지는 방식의 사용을 제한하거나[50][84], 상업적 조직에서의 사용을 금지하는 것[51][85] 등은 허용되지 않는다.

이러한 사용 목적 제한은 사용자의 자유를 침해하는 것으로 간주되어, 자유 소프트웨어의 핵심 정의(사용, 학습, 수정, 재배포의 자유)에 어긋난다. 따라서 이러한 제한이 포함된 라이선스는 FSF, OSI, 데비안, BSD 계열 배포판 등에서 공인된 자유 소프트웨어 라이선스로 인정받지 못한다.

과거 일부 개발자들은 라이선스를 통해 사용자 행동을 규제하려는 시도를 하기도 했다.[54][55][56] 예를 들어, 더글러스 크락포드는 자신의 코드에 (농담조로) "악의적인 용도로 사용하지 말 것"이라는 조항을 넣었는데, 이는 데비안 배포판의 릴리스 과정에 영향을 미치고[57] JSMin-PHP 프로젝트가 구글 코드에서 제외되는 결과를 낳기도 했다.[58] 2005년에는 분산 컴퓨팅 소프트웨어 ''GPU''의 라이선스에 아시모프의 로봇 3원칙에 기반한 평화주의적 조건을 GPL에 추가하려는 시도도 있었다.[59] 최근에는 대형 클라우드 제공업체들이 자사 서비스에서 특정 오픈 소스 소프트웨어를 활용하는 것을 제한하려는 움직임도 나타나고 있다.[60][61]

핵전쟁과 같이 극단적인 경우에 대한 사용 제한은 도덕적으로 지지받을 수 있지만[52], 이러한 제한을 소프트웨어 라이선스 자체에 포함하는 것은 일반적으로 바람직하지 않다고 여겨진다. 이는 법적 불확실성이나 집행 가능성의 문제, 그리고 도구를 만든 사람이 그 도구의 사용 방식까지 책임지는 것은 아니라는 일반적인 인식 때문이다. 일부 프로젝트는 SQLite처럼 법적 구속력은 없지만 사용자에게 특정 사용 방식을 권고하는 경우도 있다.[53]

FSF의 자유 소프트웨어 정의는 사용 목적뿐만 아니라 개발과 배포에 대해서도 부당한 제약을 가해서는 안 된다고 명시하고 있다.[86] 따라서 자유 소프트웨어를 상업적으로 판매하는 것 역시 허용되며, 이는 점차 일반화되고 있다. 자유 소프트웨어 커뮤니티 내에서는 자유를 보호하기 위한 제약과 자유를 부당하게 제한하는 제약 사이의 경계에 대한 논의가 계속되고 있다.

5. 라이선스 관련 단체 및 정의 충돌

자유 소프트웨어 사용권에 대한 정의와 지침을 발표하는 여러 단체와 그룹이 존재하는데, 대표적으로 자유 소프트웨어 재단(FSF), 오픈 소스 이니셔티브(OSI), 데비안 프로젝트, 그리고 BSD 관련 그룹 등이 있다. 이들 단체는 각자의 기준과 철학에 따라 라이선스를 평가하고 목록을 관리하며, 때로는 서로 상충하는 의견과 해석을 내놓기도 한다.

자유 소프트웨어 재단(FSF)은 자유 소프트웨어 정의를 관리하는 핵심 단체로, 이 정의에 부합하는 자유 소프트웨어 사용권 목록을 유지하고 있다.[37][80] FSF는 일반적으로 허용적인 라이선스보다 카피레프트(상호 공유) 방식의 라이선스를 선호하며, 라이선스 목록을 GNU 일반 공중 사용 허가서(GPL)와의 호환성 여부에 따라 분류한다. 또한, FSF가 여러 이유로 자유롭지 않다고 판단하는 라이선스 목록도 함께 관리한다.

1998년에 설립된 오픈 소스 이니셔티브(OSI) 역시 승인된 오픈 소스 라이선스 목록을 정의하고 관리한다. OSI는 자유 소프트웨어 정의가 아닌 오픈 소스 정의를 기준으로 라이선스를 평가한다는 점에서 FSF와 차이가 있다. 하지만 널리 사용되는 대부분의 자유 소프트웨어 라이선스에 대해서는 FSF와 OSI 모두 의견을 같이하며 승인하고 있다. 두 목록 간의 불일치는 주로 OSI가 퍼블릭 도메인에 준하는 라이선스(예: CC0, WTFPL)를 잘 승인하지 않는 반면, FSF는 소스 코드의 개인적 이용 등 특정 조건 하에서 엄밀하게 자유롭지 않은 라이선스를 승인하지 않는 등의 기준 차이에서 비롯된다. OSI는 허가형 라이선스 그룹을 자유 소프트웨어 라이선스의 참조 구현으로 간주하는 경향이 있다.

5. 1. 허가형 라이선스 vs 카피레프트 라이선스

BSD 계열 운영체제의 사용자 및 개발자들과 GNU 진영은 자유 소프트웨어 사용권에 대해 서로 다른 입장을 보인다. 특히 BSD 진영에서는 카피레프트 라이선스, 그중에서도 GNU 일반 공중 사용 허가서(GPL)가 불필요하게 복잡하고 제약이 많다고 보는 경향이 있다.[62][90] GPL은 코드를 수정한 파생 저작물 역시 GPL에 따라 배포하도록 요구하지만, BSD 라이선스는 이러한 제약이 없다. BSD 라이선스의 핵심 요구 사항은 원 저작자를 명시하는 것뿐이며, 소스 코드의 사용 방식에는 거의 제한을 두지 않는다.

이러한 특징 때문에 BSD 라이선스 코드는 독점 소프트웨어에서도 자유롭게 사용될 수 있으며, 원 저작자를 밝히기만 하면 된다. 대표적인 예로 마이크로소프트 윈도우의 초기 버전(마이크로소프트 윈도우 NT 3.1)과 macOS는 BSD 라이선스 기반의 IP 스택을 사용했다.[63] 하지만 때로는 BSD 라이선스와 같은 허가형 라이선스가 추가적인 제한과 결합되어 오픈 소스 생태계에서의 활용을 막는 경우도 있다. 예를 들어, MathWorks의 FileExchange 저장소는 사용자가 기여한 코드에 BSD 라이선스를 적용하면서도, 별도의 사용 약관을 통해 자사의 독점 소프트웨어인 MATLAB 외에 GNU Octave와 같은 FOSS 환경에서의 사용을 금지하기도 한다.[64][65][66]

BSD 라이선스 지지자들은 원 저작자 표시만 지키면 소스 코드로 무엇이든 할 수 있는 권한을 부여하므로 GPL보다 더 자유롭다고 주장한다. 이러한 개방성 덕분에 BSD 코드는 널리 사용되는 상용 소프트웨어에 통합될 수 있었다. 반면, GPL 지지자들은 BSD 코드가 독점 소프트웨어에 사용될 경우, 최종 사용자는 소프트웨어를 자유롭게 사용, 연구, 수정, 공유할 권리를 잃게 된다고 지적한다.[67] 그들은 진정한 자유란 단순히 제약이 없는 상태가 아니라, 소프트웨어를 사용하고, 연구하고, 수정하고, 공유할 수 있는 권리가 보장되는 것이라고 본다. 따라서 파생 저작물의 자유까지 보장하지 못하는 BSD 라이선스가 GPL보다 덜 자유롭다고 주장하며, 타인이 자유롭지 않은 소프트웨어를 만들 자유는 필요한 자유라기보다는 권력의 불공정한 형태라고 본다.[91] 결국, BSD 라이선스나 GPL 모두 '어떠한 제한도 없는' 완전한 자유를 의미하지는 않는다.

리처드 스톨만이 1980년대 중반에 고안한 카피레프트 개념은 자유 소프트웨어 라이선스의 중요한 축을 이룬다. 카피레프트 조항은 자유 소프트웨어를 수정한 버전을 배포할 때, 원본과 동일한 자유로운 조건으로 배포해야 한다고 규정한다. 즉, 카피레프트 소프트웨어에 추가된 개선 사항이나 기능 역시 자유 소프트웨어로 공개되어야 한다. 이는 '균등 분배'(share and share alike) 또는 '대가 교환'(quid pro quo) 원칙으로 설명되기도 한다. GPL 코드를 사용한 제품을 배포하는 개발자는 (유료 판매 여부와 관계없이) 수정한 부분을 포함한 전체 소스 코드를 공개해야 한다. 단, GPL 코드를 수정하여 사용하더라도 외부에 배포하지 않고 내부적으로만 사용한다면 수정 내용을 공개할 의무는 없다. GPL 지지자들은 이러한 방식이 파생 저작물 역시 자유롭게 유지되도록 보장함으로써 자유 소프트웨어 생태계의 지속적인 성장과 모든 사용자의 참여를 촉진한다고 강조한다.

라이선스 간 호환성 문제도 존재한다. BSD와 같은 허가형 라이선스 코드는 카피레프트 라이선스(예: GPL) 프로젝트에 통합될 수 있으며, 이때 원작자의 별도 승인은 필요 없다. 하지만 그 반대로 GPL 코드를 BSD 라이선스 프로젝트에 통합하거나 BSD 라이선스로 변경하려면 모든 저작권자의 동의를 얻어야 한다. 따라서 두 종류의 라이선스 코드를 결합하여 배포할 경우, 전체 결과물은 허가형 라이선스가 아닌 GPL을 따라야 한다.

이러한 이유로 BSD 계열 운영체제 프로젝트들은 핵심 시스템에 GPL 코드를 포함하는 것을 피하려는 경향이 있다. GCC처럼 다른 대안이 없거나 기능 차이가 압도적인 경우에만 예외적으로 GPL 코드를 사용한다. 예를 들어 OpenBSD 프로젝트는 시스템에서 GPL 라이선스 도구를 배제하기 위해 BSD 라이선스를 따르는 대체 도구를 직접 개발하거나 오래된 코드를 재활용하는 노력을 기울이고 있다.

5. 2. 데비안

데비안 프로젝트는 자체적인 기준인 데비안 자유 소프트웨어 지침 (DFSG)을 사용하여 자유 소프트웨어 라이선스를 평가한다. 이 기준에 따라 데비안은 자유 소프트웨어 재단(FSF)과 일부 라이선스에 대해 다른 견해를 보이기도 한다.

주목할 만한 의견 차이는 아티스틱 라이선스와 GNU 자유 문서 라이선스 (GFDL)에서 나타난다. 데비안은 아티스틱 라이선스를 자유 소프트웨어 라이선스로 인정하지만, FSF는 이에 동의하지 않는다. 그러나 아티스틱 라이선스는 대부분 GNU 일반 공중 사용 허가서(GPL)와 함께 이중 라이선스 형태로 사용되기 때문에 이 견해 차이가 실제 미치는 영향은 미미하다.

GNU 자유 문서 라이선스(GFDL)의 경우, 데비안은 배포판 내 문서에도 DFSG를 적용하기로 결정했다. 이는 문서는 소프트웨어와 다르므로 다른 기준이 필요하다는 FSF의 입장과 차이가 있다. 오랜 논의 끝에 데비안 프로젝트는 투표를 진행했고[92], GFDL 문서 중 수정할 수 없는 부분("invariant section")을 포함하지 않는 경우에 한해서만 자유로운 라이선스로 인정하기로 결론 내렸다. 하지만 대부분의 GNU 문서는 이러한 수정 불가 부분을 포함하고 있다.

5. 3. 논란의 여지가 있는 경계 사례

대부분의 자유 소프트웨어는 논란의 여지가 없는 자유 소프트웨어 사용권을 사용하지만, 일부 특정 라이선스가 자유 소프트웨어의 정의에 부합하는지에 대해서는 많은 논쟁이 있어 왔다.

논쟁을 일으킨 라이선스의 예는 다음과 같다.

  • 애플 공개 소스 라이선스(Apple Public Source License, APSL) 버전 1.x는 오픈 소스 이니셔티브(OSI)의 승인을 받았지만, 자유 소프트웨어 재단(FSF)이나 데비안 프로젝트에서는 자유 소프트웨어 라이선스로 인정받지 못했다.
  • RealNetworks Public Source Licenseeng(RPSL)는 OSI와 FSF의 승인을 받았지만, 데비안 프로젝트는 이를 인정하지 않았다.
  • 2007년에 나온 Common Public Attribution Licenseeng(CPAL)는 OSI만이 승인했다.[93]


자유 소프트웨어 재단(FSF)이 권장한 GNU 자유 문서 라이선스(GFDL) 역시 논란의 대상이 되었다.[68] GFDL은 GPL과 호환되지 않으며,[69] 2006년경 데비안 프로젝트,[70] 나타나엘 네로데,[71] 그리고 브루스 페렌스 등은 GFDL을 '비자유'(non-free) 라이선스로 간주했다.[72] FSF는 문서가 소프트웨어와는 질적으로 다르며 다른 요구 사항을 따른다고 주장했다. 데비안은 나중에 논란이 되었던 "불변 섹션" 조항을 제거한다면 GFDL이 데비안 자유 소프트웨어 지침을 준수한다고 인정했지만, 여전히 문제가 있는 라이선스로 보고 있다.[73] 그럼에도 불구하고 대부분의 GNU 문서는 여전히 불변 섹션을 포함하고 있다. 자유 소프트웨어 매뉴얼 제작 단체인 FLOSS 매뉴얼 재단도 2007년에 GFDL과 GPL 간의 비호환성, GFDL 구현의 어려움, 그리고 GFDL이 특히 디지털 문서의 "쉬운 복제 및 수정"을 어렵게 한다는 점을 들어 문서 작성에 GFDL 대신 GPL을 사용하기로 결정했다.[74]

2006년 12월 스페인에서 발표된 Software License for Use in Commandrieseng (SLUC)는 군사적 사용을 제외한 모든 사용을 허용하는 라이선스이다. 이 라이선스의 작성자는 이를 자유 소프트웨어라고 주장했지만, FSF는 어떤 목적으로든 소프트웨어를 사용할 자유, 즉 GPL의 소위 "영 자유"(Freedom Zero)를 침해하기 때문에 자유 소프트웨어 라이선스가 아니라고 판단했다.[75]

자유 소프트웨어 재단(FSF)은 자체적인 자유 소프트웨어 정의에 따라 자유 소프트웨어 라이선스로 인정하는 소프트웨어 라이선스 목록을 관리하고 있다.[80] 이 목록은 라이선스를 GPL 호환 여부에 따라 분류하며, FSF가 여러 이유로 자유롭지 않다고 간주하는 라이선스 목록도 포함한다. 1998년에 설립된 오픈 소스 이니셔티브(OSI) 역시 승인된 라이선스 목록을 관리한다. OSI와 FSF는 널리 사용되는 대부분의 자유 소프트웨어 라이선스에 대해서는 의견이 일치하지만, 일부 차이점도 존재한다. 예를 들어, OSI는 퍼블릭 도메인에 준하는 라이선스(예: CC0, WTFPL)를 승인하지 않는 반면, FSF는 소스 코드를 개인적인 목적으로 이용할 때는 필요하지 않은 라이선스 등 엄밀하게 자유롭지 않은 라이선스를 승인하지 않는다.

6. 시장 점유율

역사적으로 가장 널리 사용된 자유-오픈 소스 소프트웨어(FOSS) 라이선스는 GPLv2였지만, 2015년 블랙 덕 소프트웨어(Black Duck Software)의 조사에 따르면 허용적인 MIT 라이선스가 GPLv2를 제치고 2위로 올라섰으며, 허용적인 아파치 라이선스가 3위를 차지했다.[76]

그러나 2012년의 한 연구에서는 블랙 덕 소프트웨어가 통계 수집에 사용한 방법론을 공개하지 않았다고 비판했다.[77] 캐나다 빅토리아 대학교 컴퓨터 과학과 교수인 다니엘 저먼(Daniel German)은 2013년 강연에서 가장 널리 사용되는 자유 소프트웨어 라이선스를 결정하는 방법론적 어려움을 지적하며, 블랙 덕 소프트웨어의 결과를 재현할 수 없었다고 밝혔다.[78]

한편, 깃허브는 2015년 자체 통계 데이터를 바탕으로 한 연구에서 MIT 라이선스가 해당 플랫폼에서 가장 두드러진 FOSS 라이선스임을 확인했다.[79]

2016년 6월, 페도라 프로젝트의 패키지를 분석한 결과에서는 GPL 계열 라이선스가 가장 많이 사용되었고, 그 뒤를 MIT, BSD, LGPL 계열, Artistic (펄 패키지용), LPPL (texlive 패키지용), ASL 순으로 따랐다. 단일 라이선스로는 GNU GPLv2+가 가장 인기가 많았다.[36]

7. 라이선스 비교

자유 소프트웨어 사용권은 개발자가 소프트웨어 개발 및 배포 과정에서 마주할 수 있는 다양한 법적 위협이나 제약 조건을 완화하는 데 도움을 준다. 이러한 라이선스는 크게 허가형 라이선스와 카피레프트 라이선스로 나눌 수 있다.


  • 허가형 라이선스: MIT, 아파치, MPL 등이 대표적이다. 이 라이선스들은 소스 코드 사용, 수정, 배포에 대한 권한을 폭넓게 부여하며, 다른 라이선스와의 라이선스 호환성이 높고 전용화를 허용하는 경우가 많다.
  • 카피레프트 (보호형 라이선스): GPL, AGPL 등이 대표적이다. 사용 권한을 부여하는 동시에, 해당 소프트웨어를 수정하거나 결합하여 만든 파생 저작물 역시 동일한 라이선스 조건으로 배포하도록 요구하여 소프트웨어의 자유를 지속적으로 보장하고 전용화를 방지하는 것을 목표로 한다.


자주 사용되는 주요 자유 소프트웨어 라이선스들은 다음과 같은 측면에서 차이를 보인다.

자주 사용되는 보호 및 허가형 라이선스 비교
기준AGPLv3GPLv3GPLv2LGPLv3LGPLv2.1MPL 2.0BSD
SaaS/클라우드 환경에서의 소스 코드 공개 의무OXXXXXX
티보화 방지OOXOXXX
특허 공격 방어 (암묵적 특허 라이선스 부여 등)OOXOXXX
전용화 방지 (파생 저작물의 동일 라이선스 강제)OOO부분적부분적부분적X
라이선스 적용 범위프로젝트 전체프로젝트 전체프로젝트 전체라이브러리라이브러리파일 단위해당 없음
상표권 사용 허가 관련 조항OO?O?XX


참조

[1] 웹사이트 The fight for freedom https://www.linuxvoi[...] 2016-02-17
[2] 웹사이트 What if copyright didn't apply to binary executables? http://www.freesoftw[...] Free Software Magazine 2008-08-29
[3] 문서 "Apple Computer, Inc. v. Franklin Computer Corporation Puts the Byte Back into Copyright Protection for Computer Programs" http://digitalcommon[...] Golden Gate University Law Review 1984-01
[4] 서적 Software and Internet Law
[5] 웹사이트 GNU Emacs Copying Permission Notice (1985) https://github.com/l[...] 2015-11-08
[6] 웹사이트 GPLv3 - Transcript of Richard Stallman from the third international GPLv3 conference, Barcelona; 2006-06-22 - FSFE https://fsfe.org/act[...] 2021-07-15
[7] 뉴스 Montgomery EMACS : when did it leave the Public Domain ? https://groups.googl[...] 1985-12-12
[8] 웹사이트 Free Software - GPL Enforcement https://tech-insider[...] Tech Insider 2015-05-01
[9] 웹사이트 GCC Releases https://www.gnu.org/[...] 2015-03-19
[10] 뉴스 GPLv3 - Transcript of Richard Stallman from the second international GPLv3 conference, Porto Alegre, Brazil; 2006-04-21 http://fsfe.org/proj[...] 2015-03-19
[11] 웹사이트 The Curse of Open Source License Proliferation http://socializedsof[...] socializedsoftware.com 2008-05-08
[12] 웹사이트 Estimating Linux's Size http://www.dwheeler.[...]
[13] 웹사이트 SourceForge.net: Software Map http://www.dwheeler.[...] Dwheeler.com 2008-11-17
[14] 웹사이트 The Cultural Significance of free Software - Two Bits http://twobits.net/p[...] Duke University press - durham and london
[15] 웹사이트 Netscape Announces Plans to Make Next-Generation Communicator Source Code Available Free on the Net http://wp.netscape.c[...] Netscape Communications Corporation 1998-01-22
[16] 웹사이트 MOUNTAIN VIEW, Calif., April 1 /PRNewswire/ -- Netscape Communications and open source developers are celebrating the first anniversary, March 31, 1999, of the release of Netscape's browser source code to mozilla.org http://www.prnewswir[...] Netscape Communications 1999-03-31
[17] 웹사이트 The Cultural Significance of free Software - Two Bits http://twobits.net/p[...] Duke University press - durham and london
[18] 웹사이트 Report of License Proliferation Committee and draft FAQ http://www.opensourc[...] Open Source Initiative 2007-12-12
[19] 웹사이트 Groklaw - The German GPL Order - Translated http://www.groklaw.n[...] 2015-03-19
[20] 문서 Progress Software Corporation v. MySQL AB
[21] 웹사이트 Why the public domain isn't a license http://www.rosenlaw.[...] rosenlaw.com 2004-05-25
[22] 웹사이트 Placing documents into the public domain https://cr.yp.to/pub[...]
[23] 웹사이트 (License-review) (License-discuss) CC0 incompliant with OSD on patents, (was: MXM compared to CC0) https://lists.openso[...] opensource.org 2012-03-08
[24] 웹사이트 The Curse of Open Source License Proliferation http://socializedsof[...] socializedsoftware.com 2008-05-08
[25] 웹사이트 Torvalds Still Keen On GPLv2 http://www.internetn[...] internetnews.com 2008-01-08
[26] 웹사이트 7 Reasons Why Free Software Is Losing Influence: Page 2 http://www.datamatio[...] Datamation.com 2011-11-22
[27] 웹사이트 MySQL changes license to avoid GPLv3 http://www.businessr[...] 2007-01-04
[28] 웹사이트 Busy busy busybox https://lwn.net/Arti[...] lwn.net 2015-11-21
[29] 웹사이트 Re: Move GPLv2 vs v3 fun... https://lwn.net/Arti[...] lwn.net 2015-11-21
[30] 웹사이트 What's up with DWG adoption in free software? http://libregraphics[...] libregraphicsworld.org 2015-12-05
[31] 웹사이트 VLC media player to remain under GNU GPL version{{nbsp}}2 http://www.videolan.[...] videolan.org
[32] 웹사이트 GPLv3 hits 50 percent adoption | The Open Road - CNET News http://news.cnet.com[...] News.cnet.com 2009-07-23
[33] 웹사이트 GPL, copyleft use declining faster than ever http://www.itworld.c[...] 2011-12-16
[34] 웹사이트 GPL, copyleft use declining faster than ever - Data suggests a sharper rate of decline, which raises the question: why? http://www.itworld.c[...] IT world 2011-12-16
[35] 웹사이트 On the continuing decline of the GPL https://blogs.the451[...] 2011-12-15
[36] 웹사이트 Software Licenses in Fedora Ecosystem https://anweshadas.i[...] anweshadas.in 2016-06-27
[37] 웹사이트 Various Licenses and Comments about Them - GNU Project - Free Software Foundation https://www.gnu.org/[...] 2015-03-19
[38] 웹사이트 Why you should use a BSD style license for your Open Source Project http://www.freebsd.o[...] 2015-03-19
[39] 웹사이트 Why you should use a BSD style license for your Open Source Project http://www.freebsd.o[...] 2015-03-19
[40] 웹사이트 GPLv3 - Transcript of Richard Stallman from the fifth international GPLv3 conference, Tokyo, Japan; 2006-11-21 http://fsfeurope.org[...] 2015-03-19
[41] 웹사이트 Richard Stallman discusses changes in GPLv3 http://fsfe.org/proj[...]
[42] 웹사이트 The Free-Libre / Open Source Software (FLOSS) License Slide https://web.archive.[...] 2015-11-28
[43] 웹사이트 How GPLv3 tackles license proliferation https://archive.toda[...]
[44] 웹사이트 The GPLv3 and compatibility issues https://web.archive.[...] University of Namur 2015-05-30
[45] 웹사이트 GPL compatibility https://www.apache.o[...] 2015-05-30
[46] 웹사이트 Should I use a permissive license? Copyleft? Or something in the middle? http://opensource.co[...] opensource.com 2015-05-30
[47] 웹사이트 Licence Compatibility and Interoperability https://web.archive.[...] joinup.ec.europa.eu 2015-05-30
[48] 웹사이트 Frequently Asked Questions about the GNU Licenses – Is GPLv3 compatible with GPLv2? https://www.gnu.org/[...] gnu.org 2014-06-03
[49] 웹사이트 CELF 2013 Toybox talk http://landley.net/t[...] landley.net 2013-08-21
[50] 웹사이트 The HESSLA's Problems - GNU Project - Free Software Foundation https://www.gnu.org/[...] 2015-03-19
[51] 웹사이트 GPLv3 - Transcript of Richard Stallman from the third international GPLv3 conference, Barcelona; 2006-06-22 http://fsfeurope.org[...] 2015-03-19
[52] 웹사이트 Censorship envy and licensing — Free Software Foundation — Working together for free software https://www.fsf.org/[...]
[53] 웹사이트 Distinctive Features of SQLite https://sqlite.org/d[...]
[54] 웹사이트 A Peaceful Open Source License | Wise Earth Technology http://wiseearthtech[...]
[55] 웹사이트 Non-military Use Only https://mindprod.com[...]
[56] 웹사이트 ❌(REVERTED): Add text to MIT License banning ICE collaborators by jamiebuilds · Pull Request #1616 · lerna/Lerna https://github.com/l[...]
[57] 웹사이트 Evil, or why Douglas Crockford is harmful to Free Software https://apebox.org/w[...] 2012-11-08
[58] 웹사이트 JSMin isn't welcome on Google Code - wonko.com https://wonko.com/po[...] 2024-06-01
[59] 웹사이트 Open source project adds "no military use" clause to the GPL https://www.linux.co[...] 2006-08-14
[60] 웹사이트 Home https://commonsclaus[...]
[61] 웹사이트 The SSPL is Not an Open Source License | Open Source Initiative https://opensource.o[...] 2021-01-19
[62] 웹사이트 OpenBSD Copyright Policy http://www.openbsd.o[...]
[63] 웹사이트 FreeBSD der unbekannte Riese http://www.heise.de/[...] 2023-08-30
[64] 웹사이트 terms of use http://nl.mathworks.[...]
[65] 웹사이트 File Exchange Licensing Transition FAQ https://nl.mathworks[...]
[66] 웹사이트 Why can't I use code from File Exchange in Octave? It's released under a BSD license! http://wiki.octave.o[...]
[67] 웹사이트 Freedom or Power? by Bradley Kuhn and Richard Stallman https://www.gnu.org/[...]
[68] 웹사이트 Frequently Asked Questions about the GNU Licenses: Why don't you use the GPL for manuals? https://www.gnu.org/[...] 2009-06-20
[69] 간행물 Re: Proposed statement wrt GNU FDL http://lists.debian.[...]
[70] 웹사이트 Draft Debian Position Statement about the GNU Free Documentation License (nerGFDL) http://people.debian[...] 2007-09-25
[71] 웹사이트 Why You Shouldn't Use the GNU FDL http://home.twcny.rr[...] 2003-09-24
[72] 웹사이트 stepping in between Debian and FSF https://lists.debian[...] lists.debian.org/debian-legal 2003-09-02
[73] 웹사이트 Resolution: Why the GNU Free Documentation License is not suitable for Debian http://www.debian.or[...] 2006-02
[74] 웹사이트 License Change http://en.flossmanua[...] FLOSS Manuals Foundation 2007-06-06
[75] 웹사이트 Transcript of Richard Stallman at the 3nd international GPLv3 conference http://fsfe.org/camp[...] Free Software Foundation Europe 2006-06-22
[76] 웹사이트 Top 20 licenses http://www.blackduck[...] Black Duck Software 2015-11-19
[77] 웹사이트 GPL use in Debian on the rise: study http://www.itwire.co[...] Itwire.com 2012-02-07
[78] 웹사이트 Surveying open source licenses https://lwn.net/Arti[...] Lwn.net
[79] 웹사이트 Open source license usage on GitHub.com https://github.com/b[...] github.com 2015-03-09
[80] 문서 Various Licenses and Comments about Them - GNU Project - Free Software Foundation (FSF) http://www.gnu.org/l[...]
[81] 웹사이트 Report of License Proliferation Committee and draft FAQ http://www.opensourc[...] Open Source Initiative 2011-05-09
[82] 문서 GPLv3 - Transcript of Richard Stallman from the fifth international GPLv3 conference, Tokyo, Japan; 2006-11-21 http://fsfeurope.org[...]
[83] 웹사이트 Richard Stallman discusses changes in GPLv3 http://fsfe.org/proj[...]
[84] 문서 HESSLA licence - GNU Project comments http://www.gnu.org/l[...]
[85] 문서 GPLv3 - Transcript of Richard Stallman from the third international GPLv3 conference, Barcelona; 2006-06-22 http://fsfeurope.org[...]
[86] 문서 The Free Software Definition - GNU Project - Free Software Foundation (FSF) http://www.gnu.org/p[...]
[87] 웹사이트 How GPLv3 tackles licence proliferation http://www.linuxdevi[...]
[88] 웹사이트 Stallman explains licence compatibility while discussing GPLv3 http://fsfe.org/proj[...]
[89] 웹사이트 Comparative merits of GPL, BSD and Artistic licences (Critique of Viral Nature of GPL v.2 - or In Defense of Dual Licensing Idea) http://icfcst.kiev.u[...] 2000-01-01
[90] 웹사이트 OpenBSD Copyright Policy http://www.openbsd.o[...]
[91] 웹사이트 Freedom or Power? by Bradley Kuhn and Richard Stallman http://www.gnu.org/p[...]
[92] 웹사이트 一般決議: 何故 GNU Free Documentation License は Debian main に不適切なのか https://www.debian.o[...]
[93] 웹사이트 Open-source badgeware http://lwn.net/Artic[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com