애플리케이션 개발에서의 라이선스 유형과 그 차이점

소프트웨어 라이선스란?

소프트웨어 라이선스는 애플리케이션 또는 소스 코드를 다른 사람이 어떻게 사용할 수 있는지 설명하는 규칙의 집합입니다.

라이선스를 통해 애플리케이션 제작자는 다음 사항을 결정할 수 있습니다:

• 애플리케이션을 무료로 사용할 수 있는지
• 소스 코드를 수정할 수 있는지
• 애플리케이션을 재판매할 수 있는지
• 상업 프로젝트에 코드를 사용할 수 있는지
• 파생 저작물을 만들 수 있는지
• 수정 후 소스 코드를 비공개로 전환할 수 있는지
• 수정된 소스 코드를 공유해야 하는지

따라서 GitHub에 소스 코드가 공개되어 있더라도 제한 없이 자유롭게 사용할 수 있다는 의미는 아닙니다.

라이선스가 없는 경우 저작권 규칙이 자동으로 적용됩니다. 즉, 코드 소유자가 모든 권리를 보유하며, 다른 사람은 기본적으로 코드를 복사, 수정 또는 배포할 권한이 없습니다.

오픈 소스가 규칙 없는 무료를 의미하지는 않습니다

많은 사람들이 오픈 소스가 조건 없이 어떤 용도로든 소스 코드를 사용할 수 있다고 생각합니다. 실제로 각 오픈 소스 라이선스에는 서로 다른 규칙이 있습니다.

일반적으로 오픈 소스 라이선스는 소프트웨어를 사용, 연구, 수정 및 공유할 수 있도록 허용합니다. 그러나 일부 라이선스는 매우 광범위한 자유를 부여하는 반면, 다른 라이선스는 파생 애플리케이션이 오픈 소스로 유지되도록 요구합니다.

소프트웨어 라이선스는 일반적으로 몇 가지 주요 그룹으로 나뉩니다:

1. 허용적 라이선스
2. 카피레프트 라이선스
3. 약한 카피레프트 라이선스
4. 독점 라이선스
5. 퍼블릭 도메인 라이선스

소프트웨어 라이선스 비교 표

라이선스	유형	상업적 사용 허용	수정 허용	비공개 소스 전환 가능	소스 코드 공개 필수	특허 보호	적합한 용도
MIT	허용적	예	예	예	아니요	명시되지 않음	라이브러리, 애플리케이션, 개인 프로젝트
Apache 2.0	허용적	예	예	예	아니요	예	회사 프로젝트 및 기술
BSD 2-Clause	허용적	예	예	예	아니요	명시되지 않음	시스템, 라이브러리, 애플리케이션
BSD 3-Clause	허용적	예	예	예	아니요	명시되지 않음	제작자 이름 보호가 필요한 프로젝트
ISC	허용적	예	예	예	아니요	명시되지 않음	소규모 프로젝트 및 JavaScript 라이브러리
GNU GPL	강한 카피레프트	예	예	파생 저작물의 경우 아니요	배포 시 예	버전에 따라 다름	완전 오픈 소스 애플리케이션
GNU LGPL	약한 카피레프트	예	예	특정 조건 하에 예	특정 라이브러리 부분만	버전에 따라 다름	오픈 소스 라이브러리
GNU AGPL	강한 네트워크 카피레프트	예	예	일반적으로 아니요	네트워크 서비스 포함 예	AGPLv3에서 예	서버, SaaS, 웹 애플리케이션
MPL 2.0	파일 수준 카피레프트	예	예	별도 파일의 경우 예	수정된 MPL 라이선스 파일만	예	혼합 오픈 소스 및 독점 프로젝트
Unlicense	퍼블릭 도메인 스타일	예	예	예	아니요	아니요	자유롭게 사용되도록 의도된 간단한 코드
독점	비공개 소스	소유자 허가에 따라 다름	일반적으로 아니요	예	아니요	계약에 따라 다름	내부 애플리케이션 및 유료 제품

1. MIT 라이선스

MIT 라이선스는 가장 간단하고 유연한 오픈 소스 라이선스 중 하나입니다.

이 라이선스는 다른 사람이 다음을 할 수 있도록 허용합니다:

• 소프트웨어 사용
• 소스 코드 복사
• 소스 코드 수정
• 소프트웨어 판매
• 유료 애플리케이션에 코드 포함
• 애플리케이션을 비공개 소스로 전환

주요 요구 사항은 저작권 고지와 MIT 라이선스 텍스트가 소프트웨어의 모든 사본 또는 중요한 부분에 포함되어야 한다는 것입니다.

MIT 라이선스의 장점

• 라이선스 텍스트가 짧습니다.
• 이해하기 쉽습니다.
• 상업적 사용에 친숙합니다.
• 비공개 소스 애플리케이션에서 사용할 수 있습니다.
• 라이브러리 및 프레임워크에서 널리 사용됩니다.

MIT 라이선스의 단점

• 다른 사람이 코드를 가져와 수정한 후 비공개 소스 애플리케이션으로 판매할 수 있습니다.
• Apache 2.0만큼 명확한 특허 보호가 없습니다.
• 코드 소유자는 수정된 버전이 오픈 소스로 유지되도록 요구할 수 없습니다.

적합한 경우

MIT는 소스 코드가 많은 제한 없이 최대한 널리 사용되기를 원하는 개발자에게 적합합니다.

2. Apache License 2.0

Apache License 2.0은 MIT와 유사한 특성을 가지고 있습니다. 소프트웨어를 사용, 수정, 배포하고 상업용 애플리케이션에 포함할 수 있습니다.

주요 차이점은 Apache 2.0에 특허 허여에 관한 조항이 포함되어 있다는 것입니다. 이 라이선스는 또한 LICENSE 파일과 가능한 경우 NOTICE 파일을 통한 귀속 고지를 요구합니다.

Apache 2.0의 장점

• 상업 프로젝트에 사용할 수 있습니다.
• 비공개 소스 애플리케이션에 포함할 수 있습니다.
• 더 명확한 특허 보호 및 조항이 있습니다.
• 회사 프로젝트에 적합합니다.
• 사용자는 중요한 변경 사항을 문서화해야 합니다.

Apache 2.0의 단점

• 라이선스 텍스트가 MIT에 비해 깁니다.
• 귀속 및 NOTICE 파일 관리가 더 복잡할 수 있습니다.
• 파생 저작물이 오픈 소스여야 한다고 요구하지 않습니다.

적합한 경우

Apache 2.0은 더 명확한 특허 보호와 함께 유연한 라이선스를 원하는 전문 프로젝트나 회사에 적합합니다.

3. BSD 라이선스

BSD 라이선스는 MIT와 유사한 허용적 라이선스입니다. 여러 버전이 있지만 가장 일반적인 것은 BSD 2-Clause와 BSD 3-Clause입니다.

둘 다 소스 코드 및 바이너리 형식으로 사용, 수정 및 배포를 허용합니다.

BSD 2-Clause

BSD 2-Clause는 Simplified BSD License라고도 합니다.

주요 요구 사항:

• 저작권 고지가 포함되어야 합니다.
• 라이선스 텍스트와 면책 조항이 포함되어야 합니다.

BSD 3-Clause

BSD 3-Clause에는 추가 규칙이 하나 있습니다: 제작자나 기여자의 이름을 허가 없이 파생 제품을 홍보하는 데 사용할 수 없습니다.

BSD 라이선스의 장점

• 간단하고 유연합니다.
• 상업적으로 사용할 수 있습니다.
• 비공개 소스 애플리케이션에 포함할 수 있습니다.
• 라이브러리 및 시스템 소프트웨어에 적합합니다.

BSD 라이선스의 단점

• 코드 변경 사항을 공유할 필요가 없습니다.
• Apache 2.0만큼 명확한 특허 조항이 없습니다.
• 다른 사람이 코드를 사용하여 독점 제품을 만들 수 있습니다.

4. ISC 라이선스

ISC 라이선스는 매우 간결한 허용적 라이선스입니다. 기능적으로 MIT 및 BSD 2-Clause와 거의 동일합니다.

저작권 고지와 허가 텍스트가 포함되는 한 사용자는 소프트웨어를 사용, 복사, 수정 및 배포할 수 있습니다.

ISC 라이선스의 장점

• 매우 짧은 텍스트.
• 적용하기 쉽습니다.
• 상업적 사용이 허용됩니다.
• 비공개 소스 애플리케이션에서 사용할 수 있습니다.

ISC 라이선스의 단점

• 수정된 버전이 오픈 소스여야 한다고 요구하지 않습니다.
• 특허 조항이 Apache 2.0만큼 명확하지 않습니다.
• 제작자가 파생 코드의 개방성을 유지하려는 경우 덜 적합합니다.

ISC는 JavaScript 생태계의 패키지 및 라이브러리에서 꽤 일반적입니다.

5. GNU General Public License (GPL)

GNU는 단일 라이선스 이름이 아닙니다. GNU에는 다음과 같은 여러 유형의 라이선스가 있습니다:

• GNU GPL
• GNU LGPL
• GNU AGPL

GNU General Public License (GPL)는 강한 카피레프트 라이선스입니다. 즉, GPL 소프트웨어를 수정하고 파생 저작물로 배포하는 경우 해당 애플리케이션의 소스 코드도 호환되는 GPL 라이선스로 제공되어야 합니다.

GPL은 상업적 사용을 금지하지 않습니다. 개발자는 여전히 GPL 소프트웨어를 판매할 수 있습니다. 그러나 소프트웨어 수령인은 GPL이 부여하는 권리(라이선스가 요구하는 조건에 따른 소스 코드 접근 포함)를 받아야 합니다.

GNU GPL의 장점

• 소프트웨어와 그 파생물을 오픈 상태로 유지합니다.
• 개선 사항과 개발이 커뮤니티로 환류될 수 있습니다.
• 다른 사람이 코드를 가져와 파생 저작물의 소스를 비공개로 전환하는 것을 방지합니다.
• 커뮤니티 기반 프로젝트에 적합합니다.

GNU GPL의 단점

• 독점 제품에서 사용하기 어렵습니다.
• 다른 라이선스의 코드와 결합할 때 주의해야 합니다.
• 제품 소스 코드를 비공개로 유지하려는 회사에 덜 적합합니다.

내부 코드를 공개해야 하나요?

항상 그렇지는 않습니다.

GPL 애플리케이션이 내부적으로만 사용되고 다른 사람에게 배포되지 않는 경우 일반적으로 소스 코드를 공개할 필요는 없습니다.

GPL의 주요 의무는 일반적으로 소프트웨어 또는 파생 저작물이 배포될 때 발생합니다.

6. GNU Lesser General Public License (LGPL)

LGPL은 GPL에 비해 더 유연한 카피레프트 버전입니다.

이 라이선스는 일반적으로 라이브러리에 사용됩니다. 독점 애플리케이션은 라이선스 조건을 준수하는 한 LGPL 라이브러리를 사용하거나 링크할 수 있습니다. GNU는 LGPL 라이브러리가 독점 애플리케이션과 링크될 수 있다고 명시하며, 이는 파생 저작물에 더 강한 카피레프트 효과를 가지는 GPL과 다릅니다.

GNU LGPL의 장점

• 오픈 소스 라이브러리에 적합합니다.
• 비공개 소스 애플리케이션에서 사용할 수 있습니다.
• LGPL 라이브러리에 대한 변경 사항은 여전히 LGPL 규칙을 따라야 합니다.
• 모든 카피레프트 보호를 포기하지 않고 라이브러리 사용을 확장합니다.

GNU LGPL의 단점

• 통합 규칙이 MIT보다 복잡합니다.
• 링크 및 배포 방법에 주의해야 합니다.
• 라이브러리에 대한 직접 수정은 라이브러리 소스 코드 공유 의무를 촉발할 수 있습니다.

적합한 경우

LGPL은 오픈 소스와 독점 애플리케이션 모두에서 사용할 수 있는 라이브러리를 만들 때 적합합니다.

7. GNU Affero General Public License (AGPL)

AGPL은 네트워크를 통해 사용되는 소프트웨어를 위해 특별히 설계된 카피레프트 라이선스입니다. 예:

• 웹 애플리케이션
• SaaS (Software as a Service)
• API
• 서버
• 온라인 플랫폼

일반 GPL을 사용하면 회사가 소프트웨어를 수정하고 서버에서 실행하면서 애플리케이션을 배포하지 않을 수 있습니다. 이러한 상황에서 GPL의 소스 코드 배포 요구 사항이 적용되지 않을 수 있습니다.

AGPL은 네트워크를 통한 소프트웨어 사용과 관련된 의무를 추가합니다. 네트워크를 통해 수정된 소프트웨어 버전과 상호 작용하는 사용자는 해당 소스 코드에 접근할 기회를 가져야 합니다.

GNU AGPL의 장점

• SaaS 애플리케이션을 오픈 소스로 유지하는 데 적합합니다.
• 다른 사람이 서버 애플리케이션을 수정하고 코드를 비공개로 전환하는 것을 방지합니다.
• 더 강력한 카피레프트 보호를 제공합니다.

GNU AGPL의 단점

• 독점 애플리케이션에서 사용하기 어렵습니다.
• 서버 소스 코드를 공개하지 않으려는 회사에서 종종 회피합니다.
• 통합 시 신중한 검토가 필요합니다.

8. Mozilla Public License 2.0

Mozilla Public License (MPL 2.0)는 파일 수준 카피레프트 라이선스입니다.

즉, 이미 MPL 하에 있는 파일을 수정하면 해당 파일은 MPL 하에 계속 제공되어야 합니다. 그러나 해당 파일은 단일 애플리케이션 내에서 다른 독점 파일과 결합될 수 있습니다.

따라서 MPL은 MIT와 같은 허용적 라이선스와 GPL과 같은 강한 카피레프트 라이선스 사이에 위치합니다. MPL 2.0은 또한 Open Source Initiative에서 인정한 오픈 소스 라이선스입니다.

MPL 2.0의 장점

• GPL보다 유연합니다.
• 수정된 오픈 소스 파일은 계속 오픈 상태로 유지됩니다.
• 비공개 소스 코드와 결합할 수 있습니다.
• 오픈 소스와 독점 모듈이 모두 있는 프로젝트에 적합합니다.

MPL 2.0의 단점

• MIT나 BSD보다 복잡합니다.
• 개발자는 어떤 파일이 MPL 하에 있는지 알아야 합니다.
• 전체 파생 애플리케이션을 오픈 소스로 유지하려는 경우 덜 적합합니다.

9. Unlicense

Unlicense는 제작자가 법이 허용하는 최대 범위까지 코드를 퍼블릭 도메인으로 공개하려 할 때 사용됩니다.

일반적으로 사용자는 다음을 할 수 있습니다:

• 코드 복사
• 코드 수정
• 코드 판매
• 코드 배포
• 귀속 없이 코드 사용

Unlicense는 사용자에게 매우 적은 조건을 부과합니다.

Unlicense의 장점

• 매우 자유롭습니다.
• 귀속 의무가 거의 없습니다.
• 작은 코드 조각이나 샘플 코드에 적합합니다.

Unlicense의 단점

• 퍼블릭 도메인의 개념은 국가마다 다르게 취급될 수 있습니다.
• 회사 프로젝트에 이상적이지 않습니다.
• 명확한 특허 보호를 제공하지 않습니다.
• 회사 기여자는 MIT나 Apache 2.0을 선호할 수 있습니다.

10. 독점 라이선스

독점 라이선스는 비공개 소스 애플리케이션을 위한 라이선스입니다. 소프트웨어 사용 권한은 전적으로 애플리케이션 소유자가 결정합니다.

사용자는 일반적으로 애플리케이션을 사용할 권한만 받으며, 소스 코드를 소유하거나 수정할 권한은 없습니다.

예:

• 구독 애플리케이션
• 내부 회사 소프트웨어
• 유료 계산대 애플리케이션
• 호텔 관리 시스템
• 클라이언트별 애플리케이션
• 유료 데스크톱 소프트웨어

일반적인 규칙

• 애플리케이션을 복사할 수 없습니다.
• 계정을 공유할 수 없습니다.
• 소스 코드를 보거나 수정할 수 없습니다.
• 애플리케이션을 재판매할 수 없습니다.
• 사용은 장치, 사용자, 회사 또는 시간에 따라 제한됩니다.
• 구독이 중단되면 사용 권한이 종료됩니다.

적합한 경우

독점 라이선스는 애플리케이션이 비즈니스 제품이고 소스 코드를 비공개로 유지해야 하는 경우에 적합합니다.

11. 이중 라이선싱

이중 라이선싱은 동일한 소프트웨어에 대해 두 가지 라이선스 옵션을 제공하는 방법입니다.

예:

• 오픈 소스 프로젝트용 GPL로 무료 제공
• GPL을 따르지 않고 소프트웨어를 사용하려는 회사를 위한 상업용 라이선스 유료 제공

이 모델을 통해 소프트웨어 제작자는 오픈 소스 커뮤니티의 이점을 누리면서도 상업용 라이선스를 판매할 수 있습니다.

그러나 이중 라이선싱은 소스 코드 저작권이 단일 회사나 단체에 완전히 속할 때 구현하기 쉽습니다. 많은 기여자가 있는 경우 기여 권리 관리를 명확히 해야 합니다.

Creative Commons를 소스 코드에 사용할 수 있나요?

Creative Commons (CC)는 다음에 더 적합합니다:

• 기사
• 이미지
• 비디오
• 음악
• 문서
• 학습 자료
• 디자인 및 창작 콘텐츠

Creative Commons는 소프트웨어 및 하드웨어에 CC 라이선스를 사용하는 것을 권장하지 않습니다. 소스 코드, 배포 및 수정과 같은 문제를 더 적절하게 다루는 특정 소프트웨어 라이선스가 있기 때문입니다.

단일 애플리케이션 프로젝트에서 다음을 사용할 수 있습니다:

• 소스 코드에는 MIT, Apache 또는 GPL
• 문서, 이미지 또는 기타 자료에는 Creative Commons

각 부분을 별도로 설명하여 사용자에게 혼동을 주지 않도록 하십시오.

허용적 라이선스와 카피레프트의 차이점

측면	허용적 라이선스	카피레프트 라이선스
예	MIT, Apache 2.0, BSD, ISC	GPL, AGPL
상업적 사용	허용	허용
코드 수정	허용	허용
비공개 소스 전환 가능	일반적으로 허용	일반적으로 파생 저작물에 대해 불가
변경 사항 공유 필수	아니요	특정 조건 하에 예
제한 수준	더 간단함	더 엄격함
회사에 적합함	매우 적합함	비즈니스 모델에 따라 다름
오픈 소스 커뮤니티에 적합함	적합함	매우 적합함
코드 개방성 보호	낮음	높음

어떤 라이선스를 선택해야 할까요?

MIT는 다음 경우에 사용

• 간단한 라이선스를 원할 때
• 코드가 최대한 널리 사용되기를 원할 때
• 코드가 비공개 소스 애플리케이션에서 사용되어도 괜찮을 때
• 라이브러리나 개인 프로젝트를 만들 때

Apache 2.0은 다음 경우에 사용

• MIT의 자유로움을 원할 때
• 더 명확한 특허 조항이 필요할 때
• 회사 프로젝트를 만들 때
• 많은 기여를 받을 계획이 있을 때

BSD는 다음 경우에 사용

• 간단한 허용적 라이선스를 원할 때
• 시스템 소프트웨어나 라이브러리를 만들 때
• 제작자의 이름이 파생 제품 홍보에 사용되는 것을 원하지 않을 때

GPL은 다음 경우에 사용

• 파생 애플리케이션이 오픈 소스로 유지되기를 원할 때
• 회사가 코드를 가져와 소스를 비공개로 전환하는 것을 원하지 않을 때
• 커뮤니티 프로젝트를 만들 때

LGPL은 다음 경우에 사용

• 라이브러리를 만들 때
• 라이브러리가 독점 애플리케이션에서 사용될 수 있기를 원할 때
• 라이브러리에 대한 수정 사항이 계속 오픈되기를 원할 때

AGPL은 다음 경우에 사용

• SaaS 또는 서버 애플리케이션을 만들 때
• 네트워크를 통해 사용되는 변경 사항이 공유되기를 원할 때
• 회사가 수정된 버전을 자체 서버에서 비공개로 실행하는 것을 원하지 않을 때

MPL 2.0은 다음 경우에 사용

• 코드의 일부가 오픈 상태로 유지되기를 원할 때
• 여전히 독점 모듈과 코드를 결합하고 싶을 때
• MIT와 GPL 사이의 중간 지점이 필요할 때

독점 라이선스는 다음 경우에 사용

• 소스 코드를 공개할 수 없을 때
• 애플리케이션이 비즈니스 목적으로 만들어졌을 때
• 소프트웨어 사용을 제한하려 할 때
• 라이선스 또는 구독 시스템을 통해 애플리케이션이 판매될 때

GitHub에서의 라이선스 적용 예시

일반적으로 라이선스 텍스트는 다음 파일에 저장됩니다:

LICENSE

또는:

LICENSE.md

해당 파일은 저장소의 메인 또는 루트 폴더에 배치됩니다. GitHub는 또한 프로젝트가 클론, 다운로드 또는 배포될 때 사용할 수 있도록 라이선스 파일을 저장소에 직접 포함할 것을 권장합니다.

예시 프로젝트 구조:

app-name/
├── app/
├── public/
├── src/
├── README.md
├── LICENSE
└── package.json

간략한 정보를 README.md에 추가할 수도 있습니다:

## 라이선스

이 프로젝트는 MIT 라이선스 하에 제공됩니다.
자세한 내용은 LICENSE 파일을 참조하세요.

라이선스 선택 전 확인 사항

라이선스를 결정하기 전에 다음을 고려하십시오:

1. 애플리케이션을 상업적으로 사용할 수 있습니까?
2. 다른 사람이 소스 코드를 수정할 수 있습니까?
3. 수정 사항을 공유해야 합니까?
4. 파생 저작물을 비공개 소스로 전환할 수 있습니까?
5. 애플리케이션이 SaaS로 사용됩니까?
6. 프로젝트에서 타사 라이브러리를 사용합니까?
7. 각 종속성의 라이선스가 호환됩니까?
8. 다른 기여자의 코드가 있습니까?
9. 특허 보호가 필요합니까?
10. 애플리케이션이 클라이언트에게 판매됩니까?

인기 있다는 이유만으로 라이선스를 선택하지 마십시오. 프로젝트의 목표와 애플리케이션이 어떻게 사용될지에 따라 라이선스를 선택하십시오.

결론

각 소프트웨어 라이선스는 서로 다른 권리와 의무를 제공합니다.

MIT, BSD, ISC는 사용자에게 광범위한 자유를 부여하려는 프로젝트에 적합합니다. Apache 2.0은 더 명확한 특허 조항과 함께 유사한 자유를 제공합니다.

GPL은 파생 애플리케이션을 오픈 소스로 유지하는 데 적합합니다. LGPL은 라이브러리에 더 적합하며, AGPL은 웹 애플리케이션, 서버 및 SaaS에 대한 추가 보호를 제공합니다.

MPL 2.0은 특정 파일만 오픈 상태로 유지하면 되므로 중간 지점이 될 수 있습니다. 한편, 독점 라이선스는 소스 코드를 비공개로 유지해야 하는 비즈니스 애플리케이션에 더 적합합니다.

라이선스 선택은 개발 초기에 이루어져야 합니다. 애플리케이션 제작자를 보호할 뿐만 아니라 명확한 라이선스는 사용자와 기여자가 허용되는 것과 허용되지 않는 것을 이해하는 데 도움이 됩니다.

참고: 이 글은 일반적인 설명을 제공하며 법적 조언이 아닙니다. 대규모 상업용 애플리케이션, 많은 종속성 사용 또는 많은 기여자가 있는 프로젝트의 경우 라이선스 선택에 대해 지식 재산권 법률에 정통한 사람과 상담하십시오.