오픈 소스 라이선스에 대한 개발자 가이드

게시 됨: 2022-03-11

모든 오픈 소스 라이선스가 동일한 것은 아닙니다. 그들 중 일부는 소프트웨어 공급자가 소프트웨어 사용자와 개발자에게 특허 라이선스를 부여하도록 의무화합니다. 기타 라이선스는 라이선스가 부여된 제품 또는 라이브러리를 사용하는 개발자에게 동일한 조건으로 이 제품 또는 라이브러리의 소스 코드를 제공할 의무가 있습니다. 다른 사람들은 어떤 종류의 보증이나 우려도 없이 단순히 코드를 제공합니다. 이 기사에서는 소프트웨어 사용자와 소프트웨어 개발자의 관점에서 가장 많이 사용되는 오픈 소스 라이선스 간의 주요 차이점을 강조하려고 합니다.

난해한 것의 신비화 - 오픈 소스 라이선스

트위터

1984년 Richard Stallman은 무료 운영 체제를 만들기 위한 GNU 프로젝트를 시작했을 때 소프트웨어는 개발자, 엔지니어 및 사용자 간에 공유되어야 한다는 생각을 되찾았습니다. 그리고 그들은 과학이 일반적으로 행해지는 것과 같은 방식으로 협력적인 방식으로 그것을 개선할 수 있어야 합니다.

이 옵션은 대부분의 소프트웨어 회사 및 개발자가 프로그램 배포 및 판매를 위해 선택한 라이선스 소프트웨어의 일반적인 개념과 대조됩니다. 30년 이상이 지난 오늘날, 오픈 소스 소프트웨어는 우리 업계의 광범위한 부문을 천천히 계속해서 정복하고 있습니다. Linux, Android, Apache 및 Git은 해당 범주에서 최고의 오픈 소스 제품의 예입니다.

오픈 소스 또는 자유 소프트웨어?

이 기사에서는 소프트웨어나 라이선스를 언급하면서 "오픈 소스"와 "무료"라는 용어를 동의어로 사용할 것입니다. 제 생각에는 두 용어가 같은 생각을 표현합니다. "오픈 소스"는 실용적이고 기술적인 방식으로 표현하고 "무료"를 사용하면 개념의 철학적, 정치적 의미에 중점을 둡니다.

불행히도 영어로 "free"라는 단어는 "자유"와 관련된 형용사일 뿐만 아니라 "비용 없이"를 의미합니다. 이것이 내가 일반적으로 "오픈 소스"라고 말하는 것을 선호하는 이유입니다.

오픈 소스 소프트웨어의 공통 속성

나는 당신이 이미 오픈 소스 소프트웨어가 무엇인지 대략적인 아이디어를 가지고 있다고 가정합니다. 그러나 다양한 라이선스의 세부 사항에 대해 이야기할 때 먼저 오픈 소스 소프트웨어를 정의하는 특정 속성에 대해 이야기해야 합니다.

먼저 저는 변호사가 아니며 법적 조언이 아닙니다. 의심스러운 경우 내가 말하는 라이선스의 실제 텍스트와 귀하의 법률 고문을 참조하십시오.

Open Source Initiative에 따르면 모든 오픈 소스 소프트웨어는 사용자와 개발자(라이선스 사용자)에게 일부 권한을 부여하는 라이선스 하에 배포됩니다. 전체 목록은 오픈 소스 정의에서 참조할 수 있지만 기본 요약은 다음과 같습니다.

소프트웨어의 무료 재배포: 소프트웨어는 제품으로 판매 또는 제공되거나 소프트웨어 패키지에 포함될 수 있습니다. 로열티를 지불하지 않고도 가능합니다.
라이센스가 부여된 소프트웨어의 소스 코드는 배포판에 포함되어 있거나 최소한 소스 코드를 얻을 수 있는 널리 알려진 방법이 있습니다. 이 소스 코드는 소프트웨어의 수정된 버전을 개발하는 데 사용할 수 있습니다.
파생 저작물의 생성이 허용되며 라이선스를 통해 원본 소프트웨어와 동일한 조건 및 라이선스로 배포할 수 있습니다. 원본 소프트웨어의 라이선스에 따라 일부 경우 이러한 파생 작업은 이름이나 버전 번호를 변경하여 원본 소프트웨어와 구별되어야 하거나 소스 코드 패치의 형태로만 배포될 수 있습니다.
이 소프트웨어는 제한 없이 모든 개인이나 그룹, 모든 노력 분야에서 사용할 수 있습니다.

그러나 소프트웨어 라이선스는 저작권 소유자가 부여한 권한의 사용 또는 배포에 대해서만 언급한다는 점을 명심해야 합니다. 오픈 소스 라이선스를 통해 소프트웨어 또는 파생 저작물을 자유롭게 재배포할 수 있지만 암호화 소프트웨어 수출이 금지된 일부 국가에서는 해당 허용량이 제한될 수도 있습니다. 비슷한 방식으로 오픈 소스 라이선스를 사용하면 어떤 목적으로든 소프트웨어를 사용할 수 있지만 그렇다고 해서 오픈 소스 라이선스 소프트웨어를 사용하여 은행을 해킹할 수 있다는 의미는 아닙니다. 소프트웨어 특허는 이에 대한 또 다른 예입니다. 일부 오픈 소스 라이선스는 특허를 자유롭게 사용할 수 있는 권한을 부여하지만 전부는 아닙니다.

그렇다면 제품이나 프로젝트 개발에 오픈 소스 소프트웨어를 사용할 수 있습니까? 기본적으로 사용된 소프트웨어의 라이선스와 최종 제품의 의도된 라이선스에 따라 다릅니다. 다른 라이선스는 또한 자신의 코드를 오픈 소스로 게시하고 사용할 라이선스를 결정할 때 중요합니다.

카피레프트

오픈 소스 라이선스에 대한 한 가지 매우 흥미로운 개념은 일반적으로 저작권의 반대인 카피레프트라고 하는 것입니다. 저작권이 지적 재산권(소프트웨어 포함)의 복사 또는 배포를 방지하는 데 사용되는 경우, 카피레프트는 오픈 소스 지적 재산권 및 소프트웨어가 오픈 소스로 복사 또는 배포될 수 있도록 하는 데 사용됩니다.

그 강점에 따라 두 가지 종류의 카피레프트가 있습니다.

강력한 카피레프트: 다른 강력한 카피레프트 라이선스 저작물에서 파생되거나 이러한 작업에 연결된 작업이 계속 강력한 카피레프트 라이선스 또는 정확히 동일한 라이선스를 보유해야 합니다. 즉, 이러한 오픈 소스 작업은 앞으로 닫을 수 없습니다.
약한 카피레프트: 약한 카피레프트 라이선스 저작물을 사용하거나 이에 연결된 작업이 다른 라이선스(클로즈드 소스 라이선스 포함)에 따라 라이선스가 부여될 수 있습니다. 이 경우 카피레프트는 원본의 약한 카피레프트 라이선스 저작물에만 영향을 미칩니다.

카피레프트가 없는 오픈 소스 라이선스도 있습니다. 그들은 단순히 파생된 소프트웨어의 미래 개방성에 대해 신경 쓰지 않습니다.

관용

허용 여부에 따라 라이선스는 다음과 같이 분류될 수도 있습니다.

엄격한 라이선스: 강력한 라이선스 소프트웨어를 폐쇄 소스 또는 더 허가된 라이선스 소프트웨어와 혼합할 수 없는 경우.
허용 라이선스: 일반적으로 제품이 폐쇄형 소스 소프트웨어와 혼합되거나 완전히 공개된 소스 라이선스가 있는 소프트웨어와 혼합될 수 있는 경우.

일반적으로 강력한 카피레프트 라이센스도 엄격하고 약한 카피레프트 라이센스는 더 관대하지만 반드시 그렇게 할 필요는 없습니다.

오픈 소스 라이선스 차이점

많은 오픈 소스 라이선스가 있습니다. Open Source Initiative는 이미 그 중 80개 이상을 승인했습니다. 일부는 중복되며 다른 것과 동등한 것으로 간주될 수 있습니다. 다른 것들은 소프트웨어 게시자의 이익(NASA 라이선스 등)이나 주어진 환경이나 목적(예: Educational Community License, Open Font License)에 따라 다릅니다.

이러한 라이선스의 확산은 기본 오픈 소스 속성에 추가되어 다른 사용을 허용하거나 허용하지 않는 라이선스의 특정 조건을 기반으로 합니다. 이러한 추가 조건의 예는 다음과 같습니다.

카피레프트의 유형: 약하거나 강하거나 존재하지 않습니다.
관용의 유형: 관대하거나 엄격합니다.
소스 코드 또는 사용자 인터페이스에 저작권 표시를 추가할 의무.
라이센스 사용자에게 자동 특허 부여.
소프트웨어가 배포되는 당사자뿐만 아니라 소프트웨어 사용자를 라이선스 사용자로 고려하면(이런 종류의 오픈 소스 소프트웨어를 사용하는 클라우드에서 서비스를 사용하는 사람들은 소프트웨어)

다른 라이선스와 코드 혼합 문제

이전에 이미 말했듯이 일부 라이선스는 허용되므로 사용자가 코드를 다른 라이선스가 있는 소스 코드와 결합할 수 있습니다(추가 조건 포함). 이 경우 이러한 종류의 오픈 소스 라이선스 소프트웨어를 폐쇄 소스 소프트웨어와 혼합할 수 있습니다. 이러한 종류의 라이선스의 예로는 MIT 라이선스가 있습니다.

다른 것들은 더 제한적이므로 소스 코드는 유사한 방식으로 라이선스가 부여된 코드와만 결합될 수 있으며 최종 결과는 동일한 원본 라이선스로 라이선스가 부여되어야 합니다. 이러한 종류의 라이선스의 예로는 GPL(일반 공중 라이선스)이 있습니다.

라이선스가 부여된 코드를 두 개의 다른 제한적인 오픈 소스 라이선스와 결합하고 싶을 수도 있습니다. 오픈 소스 자유를 사용하여 소프트웨어를 원하는 대로 사용할 수 있습니다. 그러나 최종 프로그램은 서로 호환되지 않는 두 가지 라이선스로 배포해야 하므로 재배포할 수 없습니다.

이러한 상황의 한 예가 ZFS입니다. ZFS는 2005년 OpenSolaris에 포함된 매우 진보되고 혁신적인 파일 시스템입니다. 이는 CDDL(Common Development and Distribution License) 조건에 따라 사용이 허가된 오픈 소스 소프트웨어입니다. 오픈 소스 코드이지만 Linux의 소스 코드가 또 다른 제한적인 오픈 소스 라이선스인 General Public License 조건에 따라 배포되기 때문에 Linux 커널에 통합할 수 없습니다. ZFS 지원으로 컴파일된 Linux 커널 바이너리는 라이센스 충돌로 인해 배포할 수 없습니다.

이러한 종류의 충돌은 오픈 소스 프로그램 중 하나의 모든 소유자가 라이선스를 변경하거나 소프트웨어 라이선스에 예외 조건을 추가하는 데 동의하는 경우에만 해결할 수 있습니다. 예를 들어, 많은 GPL 라이선스 프로그램이 OpenSSL 라이브러리와 연결되어 있습니다. OpenSSL 라이브러리 배포는 광고 자료 및 재배포에 문구를 표시해야 하는 라이선스가 있습니다. 이러한 추가 조건은 GPL과 호환되지 않으며 이 때문에 OpenSSL을 사용하는 GPL 제품 개발자는 라이선스에 OpenSSL과의 연결을 특별히 허용하는 예외를 포함했습니다.

오픈 소스 라이선스의 차별화된 기능

이제 가장 인기 있는 오픈 소스 라이선스를 분석하여 차등 기능을 설명하고 언제 사용해야 하는지에 대한 약간의 가이드를 제공하겠습니다. Black Duck Knowledgebase에 따르면 사용 빈도가 높은 것부터 사용하지 않는 것으로 분류했습니다.

GNU 일반 공중 라이선스(GPL)

GPL은 가장 널리 사용되는 오픈 소스 라이선스입니다. FSF에서 GNU 프로젝트의 라이선스로 만들었으며 Linux 커널의 라이선스이기도 합니다.

그것의 차별적인 특성:

강력한 카피레프트.
매우 엄격한 라이센스.
일반적으로 '바이럴' 라이선스라고 합니다. GPL에 따라 라이선스가 부여된 다른 코드에 코드를 연결하고 결과를 배포하려면 전체 제품에 GPL 라이선스가 있어야 합니다.
또한 '포용' 라이선스입니다. 소프트웨어를 개발 중이고 GPL에 따라 라이선스를 부여하려는 경우 이 소프트웨어에 GPL과 호환되는 라이선스가 있는 한 해당 소프트웨어를 연결하거나 다른 오픈 소스 소프트웨어를 포함할 수 있습니다. GPL에서 요구하지 않는 의무는 필요하지 않습니다.

일반적으로 사용된 라이센스 텍스트에는 소프트웨어가 GPL 버전 N(또는 이후 버전)의 조건에 따라 배포된다는 텍스트가 포함됩니다.

현재 사용 중인 GPL 라이선스의 두 가지 버전이 있습니다: v2 및 v3. 버전 3은 1991년 버전 2 출시 이후 나타난 몇 가지 문제를 해결하기 위해 2007년에 출시되었습니다.

GPL v3에는 다른 오픈 소스 라이선스와의 호환성 규정, 특허 라이선스 의무화, GPL 라이선스 소프트웨어를 어플라이언스의 펌웨어로 사용하기 위한 조건 정의, 디지털 권한 관리 개념 고려 등 몇 가지 추가 조항과 조건이 포함되어 있습니다.

MIT 라이선스

일반적으로 X11 라이선스로 알려진 MIT 라이선스로 알려진 오픈 소스 라이선스는 저작권 메시지를 유지하고 소프트웨어는 어떤 종류의 보증 없이 제공됩니다.

이 라이센스는 매우 유명하며 X Window System, Ruby on Rails, jQuery 또는 Node.js와 같은 여러 프로젝트에서 사용됩니다.

GPL과 호환되므로 MIT 라이선스 코드를 GPL 소프트웨어에 혼합할 수 있습니다.

아파치 라이선스 2.0

Apache 라이선스는 Apache Software Foundation(ASF)에서 Apache HTTP 서버에 대한 라이선스로 생성했습니다.

MIT 라이선스와 마찬가지로 저작권에 대한 걱정 없이 소프트웨어를 어떤 목적으로든 사용, 배포, 수정 및 파생된 저작물을 배포할 수 있는 매우 관대한 비 카피레프트 라이선스입니다. MIT 라이선스와 비교한 주요 차이점은 다음과 같습니다.

Apache 라이선스를 사용하여 소프트웨어 작성자는 코드의 모든 사용자 또는 배포자에게 특허 라이선스를 부여합니다. 이 특허 사용권은 소프트웨어 작성자가 사용권을 부여할 수 있는 모든 특허에 적용되며 자신이 만든 코드에 의해 침해될 수 있습니다.
Apache 라이선스는 파생 저작물의 수정되지 않은 부분이 라이선스를 유지하도록 요구했습니다.
라이선스가 부여된 모든 파일에는 원본 저작권, 특허, 상표 또는 귀속 고지가 보존되어야 합니다.
라이선스가 부여된 모든 파일 변경에는 파일이 변경되었음을 알리는 알림이 있어야 합니다.
Apache 라이선스 소프트웨어에 NOTICE 파일이 포함된 경우 이 파일과 그 내용은 모든 파생 작업에서 보존되어야 합니다.
누군가 의도적으로 Apache 라이선스 소프트웨어에 대한 기여를 저작자에게 보내는 경우 이 기여는 Apache 라이선스에 따라 자동으로 사용될 수 있습니다.

이 라이선스는 자동 특허 라이선스와 기여 제출에 관한 조항 때문에 흥미롭습니다.

GPL과 호환되므로 Apache 라이선스 코드를 GPL 소프트웨어에 혼합할 수 있습니다.

BSD 라이선스

3가지 다른 BSD 라이선스가 있습니다. 그들 모두는 카피레프트가 없는 매우 관대한 라이선스입니다.

2절 BSD 라이선스(또는 Simplified BSD 라이선스)는 이전에 설명된 MIT 라이선스와 완전히 동일합니다.

3절 BSD 라이선스(또는 새로운 BSD 라이선스)는 특정 사전 서면 허가 없이 소프트웨어에서 파생된 제품을 보증하거나 홍보하는 데 저작권 소유자의 이름이나 기여자의 이름을 사용할 수 없음을 지정하는 한 조항을 추가합니다. 이 버전은 GPL과 호환되므로 3절 BSD 라이선스 코드를 GPL 소프트웨어에 혼합할 수 있습니다.

4절 BSD 라이선스(또는 원본 BSD 라이선스)는 소프트웨어의 기능이나 사용을 언급하는 모든 광고 자료에 저작권 소유자가 개발한 소프트웨어가 포함되어 있다는 확인을 표시해야 한다고 지정하는 또 다른 조항을 추가합니다. 이 4절 BSD 라이선스는 GPL과 호환되지 않습니다. 이 라이선스가 있는 코드는 GPL 조건에 따라 라이선스를 다시 부여할 수 없습니다. 네 번째 조항은 GPL에 필요하지 않은 요구 사항을 추가하기 때문입니다.

GNU 약소 일반 공중 사용 허가서(LGPL)

LGPL은 FSF가 더 약한 카피레프트를 사용하여 GPL을 수정하여 LGPL 라이선스 소프트웨어를 다른 소프트웨어와 연결할 수 있도록 만들었습니다. 원래 LGPL은 "Library General Public License"를 의미했지만 이후에 모든 소프트웨어는 무료여야 하고 LGPL은 자유로워야 한다는 FSF의 의견을 나타내는 "Lesser General Public License"라는 현재 이름을 사용했습니다. 일반적으로 사용됩니다.

폐쇄 소스 코드를 LGPL 라이브러리 또는 소프트웨어에 연결하고 다음 조건에 따라 최종 결과를 배포할 수 있습니다.

모든 수정 사항과 함께 LGPL된 부분의 소스 코드를 제공합니다.
충분한 지식을 가진 사용자는 프로그램의 LGPL된 부분을 수정된 버전으로 교체할 수 있습니다. 이것은 프로그램의 LGPL된 부분을 동적 라이브러리(Windows의 경우 DLL, Linux/Unix의 경우 .so)로 배포하거나 프로그램의 LGPL되지 않은 부분의 개체 코드를 제공하여 수행할 수 있습니다.

LGPL v3는 GPLv3와 호환되므로 LGPLv3 코드를 GPL 소프트웨어에 입력할 수 있습니다.

예술적 라이선스

현재 버전 2.0의 예술적 라이선스는 MIT 라이선스와 유사한 카피레프트가 없는 허용되는 오픈 소스 라이선스입니다.

MIT 라이선스와 예술적 라이선스의 주요 차이점은 후자의 경우 코드에 대한 수정 사항을 명확하게 명시해야 한다는 것입니다.

이 라이센스는 Perl 커뮤니티에서 거의 독점적으로 사용됩니다.

현재 Artistic License 2.0은 GPL과 호환됩니다. Artistic-Licensed 코드를 GPL 소프트웨어에 혼합할 수 있습니다.

마이크로소프트 공중 라이선스(MS-PL)

Microsoft Public License는 이 회사가 Shared Source Initiative에서 만든 오픈 소스 라이선스 중 하나로 2008년에 만들었습니다.

그것은 엄격하고 약한 카피레프트 라이선스입니다. MS-PLed 코드로 비공개 소스 프로그램의 생성 및 배포를 허용하지만 소스 코드로 배포되는 경우 파생 작업의 라이선스로 MS-PL을 사용해야 합니다.

나는 개인적으로 이 라이센스가 오픈 소스의 정신에 어긋나고 저작권 소유자가 소프트웨어로 무엇을 할 수 있는지 신경 쓰지 않도록 코드를 닫을 수 있도록 허용한다고 생각합니다. 다른 카피레프트 소스 코드와 혼합할 수 있도록 코드를 공유합니다. 따라서 다른 방식으로 저작권 소유자는 사용자가 할 수 있는 작업에 대해 정말로 관심을 갖고 있으며 Linux 개선과 같은 이유로 사용자가 코드를 사용하는 것을 원하지 않습니다.

MS-PL은 GPL과 호환되지 않습니다.

이클립스 공중 라이선스(EPL)

Eclipse Public License는 Eclipse Foundation에서 통합 개발 환경을 위해 만든 라이센스입니다. 여러 면에서 LGPL과 유사한 제한적이고 약한 카피레프트 라이선스입니다. 여기에는 자동 특허 라이선스 부여에 대한 조항도 포함됩니다.

EPL은 GPL과 호환되지 않습니다.

Mozilla 공중 라이선스(MPL)

Mozilla Public License 버전 2.0은 Mozilla Foundation에서 해당 제품에 대해 만든 약한 카피레프트 허용 라이선스입니다.

우리는 이 라이선스를 LGPL과 유사하다고 생각할 수 있지만, 주요 차이점은 MPL이 MPL된 코드 조각을 폐쇄 소스 소프트웨어로 정적 링크할 수도 있다는 점입니다.

현재 버전 2.0의 MPL은 GPL과 호환됩니다. 이전 버전의 MPL에는 해당되지 않습니다.

공통 개발 및 배포 라이선스(CDDL)

CDDL은 MPL 버전 1.1을 기반으로 Sun(현재 Oracle)에서 만든 약한 카피레프트 허용 라이선스입니다. 기본적으로 MPL과 동일한 속성을 가지고 있습니다. 용어는 명확했지만 크게 변경되지는 않았습니다.

CDDL은 OpenSolaris 또는 NetBeans와 같은 많은 제품에 대해 Sun(현재 Oracle)이 선택한 오픈 소스 라이센스입니다.

이 라이센스는 MPLv1.1을 기반으로 하므로 이 라이센스는 GPL과 호환되지 않으므로 CDDL 라이센스 소스를 GPL 라이센스 소프트웨어에 혼합할 수 없습니다. 많은 사람들이 이것이 의도적이라고 말하므로 OpenSolaris 소스 코드는 Linux 커널에 도입될 수 없습니다.

GNU Affero 일반 공중 사용 허가서(AGPL)

AGPL은 훨씬 강력하고 제한적인 카피레프트가 있는 GPL 버전입니다. 응용 프로그램의 소스 코드를 소프트웨어 사본을 받는 사람뿐만 아니라 컴퓨터 네트워크를 통해 이 소프트웨어를 사용하는 사람에게도 제공해야 합니다.

이 라이선스는 GPL이 서비스 제공자가 사용자에게 소스 코드를 제공하도록 강제할 수 없기 때문에 네트워크 서버 또는 클라우드에서 실행될 때 개발자에게 오픈 소스 소프트웨어의 실질적인 폐쇄를 피할 수 있는 수단을 제공하기 위해 FSF에서 생성했습니다. . 이 경우 소프트웨어는 배포되지 않습니다.

AGPLv3은 GPL3과 호환됩니다. 최종 결과가 AGPLv3에 따라 라이선스가 부여되는 한 AGPLv3 코드를 GPLv3 코드에 넣을 수 있습니다.

ISC 라이선스

ISC 라이선스는 ISC(Internet Software Consortium)에서 작성한 허용되는 자유 소프트웨어 라이선스입니다. 불필요한 것으로 간주되는 일부 언어를 제거한 후 2절 BSD 및 MIT 라이센스와 기능적으로 동일합니다.

처음에 ISC의 자체 소프트웨어 릴리스에 사용된 이후로 다른 프로젝트 중에서 OpenBSD(2003년 6월 시작)의 기본 라이센스가 되었습니다.

GPL과 호환됩니다. ISC 라이선스 코드를 GPL 소프트웨어에 혼합할 수 있습니다.

Microsoft 상호 라이선스(MS-RL)

Microsoft Reciprocal License는 이 회사가 Shared Source Initiative에서 만든 오픈 소스 라이선스 중 하나로 2008년에 만들었습니다.

앞서 설명한 MS-PL과 비슷하지만 LGPL, CDDL, EPL의 조건을 닮아 카피레프트가 조금 더 강하다. 코드를 MS-RL 라이선스 소스 코드와 혼합하고 최종 결과를 배포하려면 최소한 원래 MS-RL 라이선스 부분이 이 라이선스로 계속 라이선스되어야 합니다.

GPL과 호환되지 않습니다.

공개 도메인(CC0)

공개 도메인에는 여러 소프트웨어 프로젝트가 있습니다. 예를 들어 SQLite는 Mozilla 프로젝트, Android 등과 같은 여러 다른 프로젝트에 포함된 내장 가능하고 간단한 SQL 데이터베이스 엔진을 구현하는 라이브러리입니다.

소프트웨어를 공개 도메인에 할당하는 방법에는 여러 가지가 있습니다. 크리에이티브 커먼즈는 저작물을 퍼블릭 도메인에 양도하는 보편적인 방법인 CC0 퍼블릭 도메인 헌정을 만들었습니다. FSF는 소프트웨어를 공개 도메인에 전용할 때 이 텍스트를 사용할 것을 권장합니다.

공개 도메인 작업은 모든 공개 또는 비공개 소스 라이선스와 호환되며 다른 소프트웨어와 혼합할 수 있습니다.

다중 라이선스

이중 또는 삼중 라이선스가 부여된 일부 오픈 소스 소프트웨어가 있습니다. 즉, 이 다중 라이선스 소프트웨어를 받는 사람은 배포할 라이선스를 선택할 수 있습니다. 모든 라이선스는 다른 권한을 부여하고 다른 의무를 부과하므로 요구 사항에 가장 적합한 라이선스를 선택하기 위해 선택해야 합니다.

이것은 일부 라이브러리의 일반적인 경우입니다. 예를 들어 NSS는 다른 보안 관련 기능 중에서 SSL/TLS 지원을 구현하는 Mozilla에서 만든 라이브러리입니다. MPL, GPL 및 LGPL 라이선스에 따라 3중 라이선스가 부여됩니다.

라이센스를 선택하십시오

많은 사람들이 서면 라이선스 없이 플랫폼에 코드를 GitHub로 게시합니다. 아무도 그 코드를 사용해서는 안됩니다. 우리는 그것을 사용하기 위해 어떤 권한이 있는지 전혀 모릅니다. 사용하면 소송을 당할 수 있습니다. 마치 이 사람들이 “이봐, 내가 만든 것 좀 봐! 멋지지 않나요? 그러나 당신은 그것을 사용할 수 없습니다, 나는 단지 당신에게 보여주고 싶었습니다!”.

그들 중 하나가 되지 마십시오. GitHub 또는 이와 유사한 공개 사이트에 코드를 업로드하는 경우 다른 사람이 사용하도록 허용하고 향상시키십시오. 많은 생각을 하고 싶지 않다면 다음을 추천합니다.

간단하고 관대하게 유지하고 모든 사람이 귀하에게 귀속을 제공하고 귀하에게 책임을 묻지 않는 한 원하는 작업을 수행할 수 있도록 하려면 MIT 라이선스를 사용하십시오.
수정 사항을 공유하는 데 관심이 있고 폐쇄형 개발(폐쇄형 소프트웨어 제품이나 폐쇄형 하드웨어 어플라이언스가 아님)에서 코드를 사용하지 않으려면 GPL v3을 사용하십시오.
- 폐쇄된 기기에서 소프트웨어가 사용될 가능성에 대해 신경 쓰지 않는다면 GPL v2를 사용하십시오. 그러나 "또는 이후 버전" 문장을 사용하여 코드를 GPLv3 프로젝트에서도 사용할 수 있도록 하십시오.
- 귀하의 소프트웨어가 폐쇄된 소프트웨어에서 사용될 가능성에 대해 신경 쓰지 않는다면 귀하의 소프트웨어 또는 이를 사용하는 부품이 동일한 조건에서 계속해서 오픈 소스인 한 LGPL v3를 사용하십시오.
- 네트워크를 통해 소프트웨어를 사용하는 모든 사람이 소스 코드를 받을 수 있는 권한을 가지려면 AGPL v3을 사용하십시오.

이 모든 후에는 거의 말도 안되는 준법률 횡설수설에 지칠 수 있습니다. 근데 뭔지 아세요? 필요합니다. 라이선스가 없으면 코드를 사용하거나 배포할 권한이 없기 때문입니다.