라이선스 범람

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

1. 개요
2. 라이선스 범람의 문제점
- 2.1. 호환성 문제
- 2.2. 공허한 라이선스 (Vanity Licenses)
3. 라이선스 범람에 대한 대응
4. 라이선스 선택 가이드
- 4.1. 프로젝트 유형별 권장 라이선스
참조

1. 개요

라이선스 범람은 소프트웨어 개발 과정에서 서로 다른 라이선스 간의 호환성 문제로 인해 발생하는 현상이다. 라이선스 수가 증가함에 따라 자유-오픈 소스 소프트웨어(FOSS) 개발자들이 소프트웨어를 병합하는 것이 어려워지고, 기업의 라이선스 평가 비용이 증가하는 문제가 발생한다. 이러한 문제로 인해 자유 소프트웨어 재단(FSF), 오픈 소스 이니셔티브(OSI), 구글, 깃허브 등 다양한 단체와 기업들이 라이선스 범람에 대응하기 위한 노력을 기울이고 있다. 한국에서도 오픈 소스 소프트웨어 활용이 증가함에 따라 라이선스 관련 인식과 전문성이 중요해지고 있으며, FSF는 개발자들이 적합한 라이선스를 선택할 수 있도록 지침을 제공하고 있다.

더 읽어볼만한 페이지

자유 및 오픈 소스 소프트웨어 사용권 - GNU 약소 일반 공중 사용 허가서
GNU 약소 일반 공중 사용 허가서(LGPL)는 GPL과 달리 비(L)GPL 프로그램에 저작물을 링크할 수 있도록 허용하는 자유 소프트웨어 라이선스로, 자유 및 사유 소프트웨어에 적용 가능하며 특정 조건 하에 배포를 허용하고, 라이브러리 사용 프로그램이 LGPL의 새 버전과 링크될 수 있도록 공유 라이브러리나 소스 코드 제공 방법을 활용한다.
자유 및 오픈 소스 소프트웨어 사용권 - 카피레프트
카피레프트는 저작권자가 저작물의 복제, 배포, 수정의 자유를 사용자에게 부여하고, 2차 저작물에도 동일한 라이선스를 적용하여 자유로운 공유와 발전을 장려하는 개념으로, 리처드 스톨만이 자유 소프트웨어 운동의 일환으로 알렸으며 GNU 일반 공중 사용 허가서가 대표적이다.
자유 소프트웨어 - 김프
김프(GIMP)는 GNU 프로젝트에서 개발된 크로스 플랫폼 기반의 무료 오픈소스 래스터 그래픽 편집기로, 다양한 운영체제를 지원하며 풍부한 기능을 제공하지만 사용자 인터페이스에 대한 비판과 일부 기능의 부족함에 대한 평가도 존재한다.
자유 소프트웨어 - PHP
PHP는 라스무스 러도프가 개발한 범용 스크립팅 언어로, 웹 개발에 널리 사용되며 LAMP 아키텍처의 핵심 요소이다.

라이선스 범람
라이선스 범람
여러 자유/오픈 소스 라이선스의 수가 시간이 지남에 따라 증가하는 것을 보여주는 그래프
개요
정의	소프트웨어 라이선스가 시간이 지남에 따라 증가하는 현상.
문제점	라이선스 간의 호환성 문제 발생 가능성 최종 사용자에게 혼란을 야기할 수 있음
원인
근본적인 원인	소프트웨어 라이선스를 작성하는 데 드는 상대적인 용이성.
주요 원인	특정 주체(개인 또는 회사)가 특정 요구 사항을 충족시키기 위해 새로운 라이선스 제작. 기존 라이선스에 대한 불만족. 라이선스 작성자가 법률 시스템 및 법적 의미에 익숙하지 않음.
결과
라이선스 호환성 문제	여러 라이선스 하에 배포되는 코드를 결합하는 데 어려움 발생.
라이선스 이해의 어려움	최종 사용자와 개발자 모두에게 혼란을 야기.
법적 불확실성 증가	다양한 라이선스의 법적 의미에 대한 불확실성이 증가.
해결 방안
라이선스 선택 단순화	몇 가지 널리 사용되는 라이선스만 사용하는 것을 권장.
라이선스 간의 호환성 분석	라이선스 간의 호환성을 명확히 하는 도구 및 리소스 제공.
라이선스 작성 지원	라이선스 작성자를 위한 교육 및 지원 제공.
추가 정보
관련 문서	블랙 덕 소프트웨어, 오픈 소스 라이선스 수가 50% 증가했다고 발표 다양한 라이선스 및 주석에 대한 간략한 설명

2. 라이선스 범람의 문제점

라이선스 범람은 소프트웨어 개발자와 사용자에게 여러 문제를 야기한다. 개발자가 서로 다른 소프트웨어의 일부를 합치려 할 때, 라이선스가 호환되지 않아 합칠 수 없는 경우가 종종 발생한다.^[1] 라이선스 수가 증가하면서, 자유-오픈 소스 소프트웨어(FOSS) 개발자가 호환되지 않는 라이선스를 가진 소프트웨어를 결합하려 할 확률이 높아진다. 또한, 기업에서 사용하는 모든 FOSS 소프트웨어 패키지에 대해 각 라이선스를 평가해야 하는 비용도 증가한다.^[1]

엄밀히 말하면, 라이선스 범람을 선호하는 사람은 없다. 이는 조직이 자체 소프트웨어 배포에 대한 현실적인 요구, 또는 그러한 요구가 있다는 인식 때문에 새로운 라이선스를 만드는 경향에서 비롯된 문제이다.

2. 1. 호환성 문제

소프트웨어 개발자가 서로 다른 소프트웨어 프로그램의 일부를 병합하려는 경우, 종종 라이선스가 호환되지 않아 병합할 수 없는 경우가 발생한다. 두 개의 서로 다른 라이선스 하에 있는 소프트웨어를 더 큰 소프트웨어 작업으로 병합할 수 있을 때, 해당 라이선스는 호환된다고 말한다.^[1] 라이선스 수가 증가함에 따라, 자유-오픈 소스 소프트웨어(FOSS) 개발자가 호환되지 않는 라이선스 하에 제공되는 소프트웨어를 병합하려는 확률이 높아진다. 또한, 회사에서 사용하는 모든 FOSS 소프트웨어 패키지에 대해 각 라이선스를 평가해야 하는 비용도 증가한다.^[1]

라이선스 범람은 라이선스가 다른 라이선스와 제한적이거나 복잡한 라이선스 호환성 관계를 가질 때 특히 문제가 된다. 따라서 일부는 널리 사용되는 GNU 일반 공중 사용 허가서(GPL)와의 호환성을 중요한 특성으로 간주하며, 예를 들어 데이비드 A. 휠러^[2]^[3]뿐만 아니라 GPL과 호환되는 라이선스 목록을 관리하는 자유 소프트웨어 재단(FSF)도 마찬가지다.^[4] 반면, 일부는 더 많은 라이선스와의 더 나은 호환성 때문에 카피레프트 라이선스 대신 허용적 라이선스를 권장한다.^[5]^[6]^[7]

예를 들어, 아파치 재단은 아파치 라이선스가 카피레프트 GPLv3와 호환되는 반면, GPLv3는 허용적 아파치 라이선스와 호환되지 않는다는 사실을 비판한다. 즉, 아파치 소프트웨어는 GPLv3 소프트웨어에 포함될 수 있지만 그 반대는 불가능하다.^[8] 또 다른 관련 예로, GPLv2는 그 자체로 GPLv3와 호환되지 않는다.^[9] 2007년에 출시된 GPLv3는 FOSS 생태계에 또 다른 비호환 라이선스를 추가했다는 이유로 여러 저자들에게 비판을 받았다.^[10]^[11]^[12]^[13]^[14]^[15]^[16]

GNU 일반 공중 사용 허가서(GPL)를 관리하는 자유 소프트웨어 재단(FSF)은 GPL과 호환되는 라이선스 목록도 정리하고 있다.^[35] 다른 유명한 FLOSS 라이선스로는 아파치 라이선스가 있다. 아파치 소프트웨어 재단은 각 단체와의 논의를 거친 후, 웹사이트에서 아파치 라이선스는 GPLv3와 양립하지만, "일방적"이라고 언급한다. 즉, ''GPLv3 소프트웨어는 아파치 라이선스 소프트웨어를 포함''할 수 있지만, 그 반대는 불가능하다.^[36]

불필요한 라이선스를 만들고 코드의 재사용성을 저하시키지 않기 위해서는, 기존 라이선스와 호환성이 있는 라이선스를 만들거나, 기존 라이선스 중에서 해당 소프트웨어, 문서의 성격, 규모, 이용 형태에 따라 적절한 것을 선택할 필요가 있다. 자유 소프트웨어 재단(FSF)은 서로 양립하지 않는 라이선스를 잘못 선택하지 않기 위한 하나의 지침을 제시하고 있다.^[49]

2. 2. 공허한 라이선스 (Vanity Licenses)

공허한 라이선스(Vanity Licenses^영어)는 특정 기업이나 개인이 특별한 이유 없이 만들어 낸 라이선스를 비판하는 용어이다. 기존에 널리 알려진 자유 또는 오픈소스 소프트웨어 라이선스보다 뚜렷한 개선이나 차별점이 없는 라이선스를 새로 만드는 경우, 해당 라이선스가 공허하다는 비판을 받곤 한다. 자유 또는 오픈소스 소프트웨어 라이선스의 요구 사항을 충족하지 못하거나, 그 요구 사항 자체를 알지 못하는 상태에서 표준이 아닌 라이선스를 사용하면 제3자에게 프로그램이 거의 무의미해진다는 사실을 인지하지 못하고, 단지 새로운 프로그램이라는 이유로 새로운 라이선스를 작성하는 경우가 2008년 시점에도 많이 있었다.^[53]

개인적인 라이선스는 회사가 자체적인 라이선스를 작성할 목적으로만 만든 라이선스를 의미한다(NIH 증후군).^[17] 새로운 라이선스가 다른 일반적인 자유 오픈 소스 소프트웨어(FOSS) 라이선스에 비해 명확한 개선점이나 차이점이 없다면, 개인적인 라이선스라는 비판을 받을 수 있다. 2008년 기준으로, 많은 사람들이 FOSS 라이선스의 요구 사항을 모르고 비표준 라이선스를 사용하면 해당 프로그램이 다른 사람에게 거의 쓸모없게 될 수 있다는 점을 깨닫지 못한 채 새로 출시된 프로그램에 대한 맞춤형 새 라이선스를 만들었다.^[18]

소프트웨어 개발자들은 서로 다른 소프트웨어 프로그램을 조합하여 사용하려 하지만, 라이선스 비호환성 문제로 인해 불가능한 경우가 많다. 서로 다른 두 라이선스로 허가된 소프트웨어를 결합하여 하나의 더 큰 저작물을 만들 수 있는 경우, 해당 라이선스들은 호환된다고 한다. 라이선스 수가 늘어남에 따라, FLOSS 개발자가 조합하려는 소프트웨어가 있더라도, 서로 호환되지 않는 라이선스로 허가되어 있을 가능성이 높아진다. 이는 소프트웨어 패키지의 각 FLOSS 라이선스를 평가해야 하는 조직에게도 큰 부담이 된다. 엄밀히 말하면, 라이선스 범람을 지지하는 인물이나 조직은 없다. 오히려 이 문제는 소프트웨어 배포를 위해 새로운 라이선스를 작성해야 한다는 현실적인 요구, 또는 그러한 요구가 있다는 인식 때문에 각 조직이 새로운 라이선스를 만드는 경향에서 비롯된다고 할 수 있다.

''공허한 라이선스''(Vanity licenses)는 어떤 기업이나 인물이 특별한 이유 없이 작성한 라이선스를 비꼬는 용어이다. FLOSS에서 더 널리 알려진 라이선스와 비교하여 명백한 개선점 또는 차이점이 없는 라이선스를 작성한 경우, 해당 라이선스가 공허하다고 비판받는 경우가 종종 있다.

FLOSS 라이선스 요구 사항을 충족하지 못하며, 해당 요구 사항 자체도 알지 못하고, 표준적이지 않은 라이선스를 이용하는 것이 프로그램을 제3자에게 거의 무의미하게 만든다는 것을 깨닫지 못하고, 새롭게 출시한 프로그램용으로 새로운 라이선스를 작성하는 사람이 2008년 시점에도 많았다.^[37]

3. 라이선스 범람에 대한 대응

소프트웨어 개발자가 서로 다른 소프트웨어 프로그램의 일부를 합치려고 할 때, 라이선스가 호환되지 않아 합칠 수 없는 경우가 종종 발생한다. 라이선스 수가 증가함에 따라, 자유-오픈 소스 소프트웨어(FOSS) 개발자가 호환되지 않는 라이선스를 가진 소프트웨어를 합치려는 경우가 많아진다. 또한, 회사에서 사용하는 모든 FOSS 소프트웨어 패키지에 대해 각 라이선스를 평가해야 하는 비용도 증가한다.^[1]

라이선스 범람에 대응하기 위해 여러 단체와 기업들이 다양한 노력을 기울였다.

자유 소프트웨어 재단(FSF)은 GPL 호환 라이선스 목록을 만들어, 소프트웨어 개발자에게 GPL과 호환되는 자유 소프트웨어 라이선스 사용을 권장한다.^[60]
오픈 소스 이니셔티브(OSI)는 ‘라이선스 범람 문제 프로젝트’를 시작하였고,^[55] ‘라이선스 범람 보고서’를 준비하였다.^[56]
구글은 2006년에는 구글 코드(Google Code)에서 특정 라이선스만 허용하는 정책을 발표하였으나,^[57] 2010년에는 OSI 승인 라이선스를 모두 허용하는 정책으로 변경하였다.^[59]
깃허브는 사용자가 쉽게 라이선스를 선택할 수 있도록 "choosealicense"라는 라이선스 선택 도구를 출시했다.^[19]
인텔은 라이선스 범람을 줄이기 위해 자사의 OSI 오픈 소스 라이선스인 인텔 오픈 소스 라이선스를 자발적으로 철회했다.^[31]

3. 1. 자유 소프트웨어 재단 (FSF)의 입장

자유 소프트웨어 재단(FSF) 대표 리처드 스톨먼과 브랜들리 M. 쿤 집행위원은 2000년부터 라이선스 범람 문제를 주장해 왔다.^[60] FSF는 GPL 호환 라이선스 목록을 만들어, 소프트웨어 개발자에게 GPL과 호환되는 자유 소프트웨어 라이선스 사용을 권장한다.^[60]

FSF는 GPL과 호환되지 않는 소프트웨어 프로그램도 목록에 포함했지만, "해당 라이선스 하에 이미 부여된 소프트웨어 사용 또는 동작에는 문제가 없다. 그러나 이 목록을 읽는 사람이 작성하는 소프트웨어에는 해당 라이선스를 이용하지 않도록 권한다."라고 언급했다.^[60]

FSF 유럽의 키어런 오리어던은 FSF가 라이선스 범람을 막으려면 새로운 라이선스를 만들 이유를 줄여야 한다고 주장하며, ''GPLv3가 라이선스 범람에 대처하는 방법''이라는 사설을 썼다.^[30] FSF 유럽은 가능한 한 GNU GPL을 사용하고, 불가능하면 GPL 호환 라이선스를 사용하라고 권장한다.

3. 2. 오픈 소스 이니셔티브 (OSI)의 입장

오픈 소스 이니셔티브(OSI)는 스스로 모든 오픈 소스 라이선스를 관리하는 역할을 한다고 생각한다. OSI는 OSI 인증 라이선스 목록을 관리하고 있다.^[54] 초기에는 공허한 라이선스를 만들고 승인을 장려하는 움직임이 있었으나, 마크 셔틀워스를 비롯한 사람들은 OSI가 새로운 라이선스를 계속 승인하면서 라이선스 범람 문제가 심화되고 있다고 생각하여, OSI에 그 문제에 대한 중대한 책임이 있다고 주장하였다.^[43]

이러한 주장에 대응하기 위해 OSI는 ‘라이선스 범람 문제 프로젝트’를 시작하였고,^[55] ‘라이선스 범람 보고서’를 준비하였다.^[56] OSI는 2004년에 라이선스 범람 프로젝트를 시작하였으며,^[27] 2007년에 라이선스 범람 보고서를 준비했다.^[28] 보고서는 라이선스 종류를 다음과 같이 정의했다.

종류	설명
인기 있고 널리 사용되거나 강력한 커뮤니티를 가진 라이선스	아파치 라이선스 2.0, New BSD 라이선스, GPLv2, LGPLv2, MIT 라이선스, 모질라 공중 사용 허가서 1.1, 공통 개발 및 배포 라이선스, 공통 공중 사용 허가서, 이클립스 공중 사용 허가서 등이 해당된다.
국제 라이선스
특수 목적 라이선스
기타/잡다한 라이선스
더 인기 있는 라이선스와 중복되는 라이선스
재사용할 수 없는 라이선스
대체된 라이선스
자발적으로 폐기된 라이선스
분류되지 않은 라이선스

소프트웨어 개발자들이 서로 다른 소프트웨어 프로그램의 일부를 합치려고 할 때, 라이선스가 호환되지 않아 합칠 수 없는 경우가 종종 발생한다. 라이선스 수가 증가함에 따라, 자유-오픈 소스 소프트웨어(FOSS) 개발자가 호환되지 않는 라이선스를 가진 소프트웨어를 합치려는 경우가 많아진다. 또한, 회사에서 사용하는 모든 FOSS 소프트웨어 패키지에 대해 각 라이선스를 평가해야 하는 비용도 증가한다.^[1]

3. 3. 구글의 입장

2006년부터 2010년까지 구글은 라이선스 범람에 대해 독자적인 입장을 취했다. 특히 2006년에 구글은 자사의 코드 호스팅 사이트인 구글 코드(Google Code)에서 다음 라이선스로 허락된 소프트웨어 프로젝트만 허용하는 방침을 발표하였다.^[57]

허용된 라이선스
아파치 라이선스 2.0
아티스틱 라이선스와 GPL의 듀얼 라이선스
GNU 일반 공중 사용 허가서 3.0
GNU 일반 공중 사용 허가서 2.0
GNU 약소 일반 공중 사용 허가서
MIT 라이선스
새로운 BSD 라이선스
모질라 공중 사용 허가서 1.1
이클립스 공중 사용 허가서

2008년, 구글은 호스팅하는 프로젝트에 아파치 라이선스 또는 GPLv3을 추천한다고 추가 발표하였다.^[58] 그러나 2010년에 이러한 엄격한 운영에 역행하여, 결과적으로 OSI의 입장과 동일해졌다. 즉, OSI 승인 라이선스 프로젝트는 모두 구글 코드에서 호스팅할 수 있게 되었다. 이로 인하여 AGPL 등의 라이선스로 진행되는 프로젝트까지 호스트할 수 있게 되었다.^[59]

3. 4. 깃허브 (GitHub)의 입장

깃허브는 2013년 7월, 사용자가 쉽게 라이선스를 선택할 수 있도록 "choosealicense"라는 라이선스 선택 도구를 출시했다.^[19] 이 도구의 첫 페이지에서는 MIT 라이선스, 아파치 라이선스, GNU 일반 공중 사용 허가서의 세 가지 주요 라이선스를 빠르게 선택할 수 있도록 제공한다. 다른 추가적인 라이선스들은 하위 페이지와 링크를 통해 제공된다.^[20] 2015년에는 깃허브에서 라이선스가 적용된 프로젝트의 약 77%가 이 세 가지 라이선스 중 하나 이상을 사용했다.^[21]

3. 5. 기타 대응

인텔은 라이선스 범람을 줄이기 위해 자사의 OSI 오픈 소스 라이선스인 인텔 오픈 소스 라이선스를 자발적으로 철회하고 더 이상 사용하거나 권장하지 않았다.^[31]

여러 기관 및 전문가들은 라이선스 범람 문제에 대한 다양한 해결책을 제시하고 있다. 2009년 워싱턴 대학교 로스쿨 논문에서는 라이선스 선택 도구 ("더 멋진 마법사"), 모범 사례 및 레거시 라이선스, 해커를 위한 더 많은 법률 서비스를 해결책으로 제시했다.^[33]

오픈소스 소프트웨어 협업 상담(OSSCC)은 아파치 라이선스 2.0, 뉴 BSD 라이선스, CDDL, MIT 라이선스, 그리고 어느 정도의 MPL을 협업을 지원하고, 특허 사용을 허가하며 특허 보호를 제공하는 라이선스로 권장한다. 특히 GPL은 다른 라이선스 하에 다른 작업 내에서 사용할 수 없다는 이유로 권장되지 않았다.^[34]

4. 라이선스 선택 가이드

자유 소프트웨어 재단(FSF)은 개발자들이 라이선스 선택에 혼란을 겪지 않도록 라이선스 선택 지침을 제공하고 있다.^[49] FSF는 GNU 일반 공중 사용 허가서(GPL)를 관리하며, GPL과 호환되는 라이선스 목록도 정리하고 있다.^[35]

리처드 스톨만과 브래들리 M. 쿤은 2000년경부터 라이선스 범람에 대해 주장해왔다. 이들은 FSF ''라이선스 목록''을 제정하여, 개발자가 소프트웨어 라이선스로 GPL과 호환되는자유 소프트웨어 라이선스를 채택하도록 권장한다.^[46]^[47]

FSF 유럽의 키어런 오리어던은 FSF가 라이선스 범람을 막기 위해 할 수 있는 주요한 일은 새로운 라이선스를 만들 이유를 줄이는 것이라고 주장하며, ''GPLv3가 라이선스 범람에 대처하는 방법''이라는 사설을 썼다.^[30] FSF 유럽은 가능한 GNU GPL을 사용하고, 불가능할 경우 GPL 호환 라이선스를 사용할 것을 권장한다.

FSF ''라이선스 목록''에는 GPL과 호환되지 않는 여러 자유 소프트웨어 라이선스도 주석과 함께 등재되어 있다. 이 라이선스 하에 이미 허가된 소프트웨어의 이용에는 문제가 없지만, FSF는 독자들에게 해당 라이선스를 사용하지 않도록 권고한다.^[46]^[47]^[35]

4. 1. 프로젝트 유형별 권장 라이선스

자유 소프트웨어 재단(FSF)은 불필요하게 새 라이선스를 만들고 코드 재사용성을 떨어뜨리지 않도록, 기존 라이선스와 호환되는 라이선스를 만들거나, 기존 라이선스 중에서 소프트웨어, 문서의 성격, 규모, 이용 형태에 따라 적절한 것을 선택해야 한다고 권고한다. FSF는 라이선스 선택 지침을 제시하고 있다.^[49]

프로그램 유형	권장 라이선스
라이브러리	LGPL 또는 완화된 카피레프트 라이선스
웹 애플리케이션	GNU AGPL
소규모 소프트웨어 또는 독점 형식 대체	Apache License 2.0
기타 프로그램 또는 라이브러리	GPL

라이브러리의 경우, 이미 독점적 구현이 존재하는 소프트웨어(특히 라이브러리에 많음)의 2차적 저작물을 동일한 라이선스 하에 두는 것은 제한이 너무 강해 결합하여 배포할 수 없으므로, 약한 카피레프트를 가진 LGPL이 적절하다.
웹 애플리케이션에서는 배포되지 않아도 카피레프트를 발휘하는 "원격 네트워크 상호 작용" 조항을 가진 GNU AGPL (버전 3)이 적절하다.
독점적인 형식의 대체 (예: MP3에 대한 Ogg+Vorbis)를 목표로 하거나 소규모 소프트웨어에서 카피레프트가 필요하지 않다고 생각되는 경우에는 Apache License 버전 2가 적절하다.
그 외의 프로그램이나 라이브러리는 GPL이 적절하다.

Apache License 버전 2는 BSD 라이선스와 마찬가지로 퍼미시브 라이선스이며, 2차적 저작물을 동일한 허가 조건에 둘 필요는 없다. 따라서 독점 소프트웨어와 결합할 수 있지만, BSD 라이선스와 달리 특허에 대한 어느 정도의 방어책이 마련되어 있기 때문에, 단순한 BSD 라이선스를 채택하는 것보다 부당한 특허권 주장 소송 공격을 완화할 수 있을 것으로 기대된다.

참조

_[1] 문서 OSI and License Proliferation https://fossbazaar.o[...] FOSSBazaar 2008-08-21
_[2] 문서 The Free-Libre / Open Source Software (FLOSS) License Slide http://www.dwheeler.[...] 2007-09-27
_[3] 웹사이트 Make Your Open Source Software GPL-Compatible. Or Else. http://www.dwheeler.[...] 2014-02-16
_[4] 웹사이트 Various Licenses and Comments about Them https://www.gnu.org/[...] GNU 2000-08-15
_[5] 웹사이트 The GPLv3 and compatibility issues http://www.eolevent.[...] University of Namur 2015-05-30
_[6] 웹사이트 Should I use a permissive license? Copyleft? Or something in the middle? http://opensource.co[...] opensource.com 2015-05-30
_[7] 웹사이트 Licence Compatibility and Interoperability https://joinup.ec.eu[...] joinup.ec.europa.eu 2015-05-30
_[8] 웹사이트 GPL compatibility https://www.apache.o[...] 2015-05-30
_[9] 웹사이트 Frequently Asked Questions about the GNU Licenses – Is GPLv3 compatible with GPLv2? https://www.gnu.org/[...] gnu.org 2014-06-03
_[10] 웹사이트 CELF 2013 Toybox talk http://landley.net/t[...] landley.net 2013-08-21
_[11] 웹사이트 Michigan Telecommunications and Technology Law Review Volume 14 - Issue 22008 The General Public License Version 3.0: Making or Breaking the Foss Movement http://repository.la[...] law.umich.edu
_[12] 웹사이트 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
_[13] 웹사이트 7 Reasons Why Free Software Is Losing Influence: Page 2 http://www.datamatio[...] Datamation.com 2013-08-23
_[14] 웹사이트 Kernel developers' position on GPLv3 - The Dangers and Problems with GPLv3 https://lwn.net/Arti[...] LWN.net 2015-03-11
_[15] 웹사이트 Licensing in a Post Copyright World http://lucumr.pocoo.[...] lucumr.pocoo.org 2015-11-18
_[16] 문서 Are you sure you want to use the GPL? http://lucumr.pocoo.[...] 2009
_[17] 문서 Sharing medical software: FOSS licensing in medicine http://www.freesoftw[...] freesoftwaremagazine.com 2007-06-14
_[18] 웹사이트 David A. Wheeler's Blog https://dwheeler.com[...]
_[19] 문서 GitHub finally takes open source licenses seriously http://www.infoworld[...] Infoworld 2013-07
_[20] 문서 Choosing an open source license doesn't need to be scary - Which of the following best describes your situation? http://choosealicens[...] choosealicense.com 2015-11-29
_[21] 문서 Open source license usage on GitHub.com https://github.com/b[...] github.com 2015-03-09
_[22] 웹사이트 Google says no to license proliferation https://www.zdnet.co[...] 2010-09-11
_[23] 웹사이트 Standing Against License Proliferation http://google-openso[...] 2010-09-11
_[24] 문서 License Proliferation - Less is More, One is Best https://fossbazaar.o[...] 2009-01-27
_[25] 웹사이트 License Evolution and Hosting Projects on Code.Google.Com http://googlecode.bl[...] 2010-09-11
_[26] 문서 OSI Approved Licenses http://opensource.or[...] opensource.org
_[27] 문서 License Proliferation Project http://opensource.or[...] opensource.com 2004
_[28] 문서 License Proliferation Report http://opensource.or[...] opensource.com 2007
_[29] 뉴스 Various Licenses and Comments about Them https://www.gnu.org/[...] Free Software Foundation 2015-11-29
_[30] 문서 How GPLv3 tackles license proliferation https://archive.toda[...] linuxdevices.com
_[31] 웹사이트 Intel to stop using open-source license http://news.cnet.com[...] CNet 2014-10-06
_[32] 문서 The Myth of Open Source License Proliferation https://web.archive.[...] the451group.com
_[33] 문서 Open Source License Proliferation: Helpful Diversity or Hopeless Confusion? http://www.law.washi[...] law.washington.edu 2009
_[34] 문서 License compatibility http://www.osscc.net[...] osscc.net
_[35] 웹사이트 Various Licenses and Comments about Them http://www.gnu.org/l[...] Free Software Foundation 2011-05-10
_[36] 웹사이트 Apache License v2.0 and GPL Compatibility http://www.apache.or[...] Apache Software Foundation 2011-05-10
_[37] 웹사이트 FLOSS License Proliferation: Still a problem https://dwheeler.com[...] 2021-04-24
_[38] 웹사이트 Google says no to license proliferation http://www.zdnet.com[...] 2011-05-10
_[39] 웹사이트 Standing Against License Proliferation http://google-openso[...] 2010-09-11
_[40] 웹사이트 License Evolution and Hosting Projects on Code.Google.Com https://googlecode.b[...] 2010-09-11
_[41] 웹사이트 Google Codeのライセンス要件が緩和、全OSI承認ライセンスを受け入れへ http://osdn.jp/magaz[...] OSDN Magazine 2011-05-10
_[42] 웹사이트 Licenses by Name http://opensource.or[...] Open Source Initiative 2011-05-10
_[43] 웹사이트 '#11: Simplified, rationalised licensing' http://www.markshutt[...] www.markshuttleworth.com 2011-05-10
_[44] 웹사이트 The Licence Proliferation Project http://opensource.or[...] Open Source Initiative 2011-05-10
_[45] 웹사이트 Report of License Proliferation Committee and draft FAQ http://opensource.or[...] Open Source Initiative 2011-05-10
_[46] 뉴스 Various Licenses and Comments about Them http://www.gnu.org/p[...] Free Software Foundation 2000-08-15
_[47] 웹사이트 さまざまなライセンスとそれらについての解説 http://www.gnu.org/l[...] Free Software Foundation 2011-05-10
_[48] 웹사이트 How GPLv3 tackles license proliferation http://www.linuxdevi[...] www.linuxfordevices.com 2011-05-10
_[49] 웹사이트 How to choose a license for your own work http://www.gnu.org/l[...] Free Software Foundation 2011-05-27
_[50] Youtube 賢く著作物を共有する方法 - クリエイティブ・コモンズ・ライセンスの付け方(1/2)（第32回日本分子生物学会年会） https://www.youtube.[...] クリエイティブ・コモンズ・ジャパン 2012-01-05
_[51] 문서 list of the licenses that are compatible with the GPL http://www.gnu.org/p[...]
_[52] 문서 Apache License is listed compatible with the GPLv3 but only one way http://www.apache.or[...]
_[53] 문서 FLOSS License Proliferation: Still a problem http://www.dwheeler.[...]
_[54] 문서 OSI Approved Licenses http://opensource.or[...]
_[55] 문서 License Proliferation Project http://opensource.or[...]
_[56] 웹인용 License Proliferation Report http://opensource.or[...] 2012-12-01
_[57] 웹인용 Google says no to license proliferation http://www.zdnet.com[...] 2010-09-11
_[58] 웹인용 Standing Against License Proliferation http://google-openso[...] 2010-09-11
_[59] 웹인용 License Evolution and Hosting Projects on Code.Google.Com http://googlecode.bl[...] 2010-09-11
_[60] 뉴스 Various Licenses and Comments about Them http://www.gnu.org/p[...] Free Software Foundation 2000-08-15

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

문의하기 : help@durumis.com