Open Source Guide

• 1: 오픈소스 사용하기
• 1.1: 오픈소스 선택 시 고려사항
• 1.2: 오픈소스 라이선스란?
• 1.3: 오픈소스 라이선스 확인하기
• 1.4: 오픈소스 라이선스별 의무사항
• 1.4.1: AGPL-3.0 가이드
• 1.4.2: Apache-2.0 가이드
• 1.4.3: BigScience RAIL 가이드
• 1.4.4: BSD-2-Clause 가이드
• 1.4.5: BSD-3-Clause 가이드
• 1.4.6: BSD-4-Clause 가이드
• 1.4.7: BSL 가이드
• 1.4.8: CDDL-1.0 가이드
• 1.4.9: CreativeML Open RAIL-M 가이드
• 1.4.10: Elastic License 2.0 가이드
• 1.4.11: EPL-2.0 가이드
• 1.4.12: GPL-2.0 가이드
• 1.4.13: GPL-3.0 가이드
• 1.4.14: LGPL-2.1 가이드
• 1.4.15: LGPL-3.0 가이드
• 1.4.16: Llama 2 Community License 가이드
• 1.4.17: MIT 가이드
• 1.4.18: MPL-2.0 가이드
• 1.4.19: SSPL 가이드
• 2: 오픈소스 기여하기
• 2.1: SK텔레콤 오픈소스 기여 Rule
• 2.2: SK텔레콤 오픈소스 기여 절차
• 2.3: 기여 제출
• 2.4: 오픈소스 기여 배경 지식
• 2.4.1: 오픈소스 기여의 혜택
• 2.4.2: 오픈소스 기여의 유형
• 2.4.3: 오픈소스 프로젝트 멤버십
• 2.4.4: 오픈소스 프로젝트 주요 문서
• 2.4.5: 좋은 기여자가 되기 위해
• 2.4.6: 기여하기에 좋은 프로젝트 확인 방법
• 2.4.7: 커뮤니케이션 방법
• 3: 오픈소스 공개하기
• 3.1: SK텔레콤 오픈소스 공개 Rule
• 3.2: SK텔레콤 오픈소스 공개 절차
• 3.2.1: 오픈소스 프로젝트 이름 결정
• 3.2.2: 파일 내 저작권 및 라이선스 표시
• 3.2.3: 민감정보 제거 체크리스트
• 3.2.4: 라이선스 선택
• 3.3: 오픈소스 공개 배경 지식
• 3.3.1: 오픈소스 공개의 혜택
• 4: 공급망 보안
• 4.1: 소프트웨어 공급망 공격과 보안 필요성
• 4.1.1: 규제 동향
• 4.1.2: SK텔레콤 공급망 보안 정책
• 4.2: SBOM 이란?
• 4.2.1: SBOM 개념 및 필요성
• 4.2.2: SBOM 표준
• 4.3: 공급사 SBOM 제출 가이드
• 4.3.1: SBOM 제출 요구사항
• 4.3.2: BomLens
• 4.3.3: 오픈소스 도구를 활용한 SBOM 생성
• 4.3.4: 서버(OS + 애플리케이션) SBOM 생성
• 4.3.5: SBOM 제출 전 검증 체크리스트
• 4.3.6: SBOM 제출 절차
• 5: 오픈소스 교육 슬라이드

1 - 오픈소스 사용하기

오픈소스를 사용하지 않고 제품이나 서비스를 개발하는 것은 불가능하다고 할 수 있을 만큼, 오픈소스는 소프트웨어 개발의 핵심 요소가 되었습니다. 오픈소스를 사용하면 소프트웨어 개발 시간을 단축하면서도 서비스 안정성과 보안 강화를 기대할 수 있습니다. 다만 오픈소스를 사용할 때는 라이선스가 무엇인지 확인하고, 라이선스가 요구하는 의무사항을 준수해야 합니다.

여기에서는 외부 오픈소스를 가져와 SK텔레콤의 제품이나 서비스에 올바르게 사용하는 방법과 주의해야 할 사항을 설명합니다.

사용할 오픈소스 선택 시 고려사항

필요한 기능을 구현하려고 오픈소스를 사용하기로 했다면, 비슷한 기능을 제공하는 여러 오픈소스 프로젝트 중 어느 것을 선택하는 게 좋을까요? 여러 측면에서 고려할 점을 살펴봅니다.

• 오픈소스 선택 시 고려사항

오픈소스 컴플라이언스 활동

기업이 오픈소스를 사용하여 제품과 서비스를 개발할 때 법적 문제를 일으키지 않으려면, 오픈소스 라이선스를 확인하고 각 라이선스가 요구하는 바를 준수해야 합니다. 이러한 활동을 오픈소스 컴플라이언스라고 합니다. SK텔레콤 구성원은 오픈소스를 사용하면서 적절한 컴플라이언스 활동을 수행해야 합니다.

오픈소스 라이선스란?

오픈소스를 올바르게 사용하려면 먼저 저작권과 오픈소스 라이선스를 이해해야 합니다.

• 저작권은 소프트웨어를 보호합니다. 소프트웨어를 개발하면 저작권법에 따라 저작권자를 제외한 누구도 그 소프트웨어를 사용, 복제, 수정, 배포할 수 없습니다.
• 오픈소스의 목적은 많은 사람이 자유롭게 사용, 수정, 배포할 수 있게 하는 것입니다. 이를 위해서는 이러한 권한을 명시적으로 나타내는 라이선스가 필요합니다. 이를 오픈소스 라이선스라고 하며, 오픈소스 라이선스가 적용되지 않은 소프트웨어는 오픈소스가 아닙니다. 오픈소스가 아니라면 저작권자를 제외한 누구도 그 소프트웨어를 사용, 복제, 수정, 배포할 수 없습니다.

오픈소스 라이선스에 대한 자세한 사항은 다음 페이지를 참고하세요.

• 오픈소스 라이선스 란?

라이선스 확인하기

오픈소스 라이선스는 여러 방법으로 확인할 수 있으며, 분석 도구를 사용하지 않고도 확인할 수 있습니다. 사용하려는 오픈소스의 라이선스를 확인하는 방법은 다음 페이지를 참고하세요.

• 오픈소스 라이선스 확인하기

라이선스 별 의무 사항

SK텔레콤은 제품과 서비스 개발 시 오픈소스 사용을 적극 권장합니다. 다만 SK텔레콤의 지식재산 보호를 위해 오픈소스 라이선스별로 요구하는 의무 사항을 준수해야 합니다. SK텔레콤 구성원은 이를 숙지하여 오픈소스 사용 시 라이선스를 확인하고 의무 사항을 준수해야 합니다. 어떤 오픈소스 라이선스를 주의해야 할지는 다음 페이지에서 확인하세요.

• 오픈소스 라이선스 별 의무사항

라이선스 의무 준수 활동

SK텔레콤의 제품과 서비스에 오픈소스를 포함하여 배포할 경우, 각 오픈소스 라이선스가 요구하는 사항을 준수해야 합니다. 오픈소스 라이선스에 따라 고지 의무만 요구하기도 하고, 소스 코드 공개까지 요구하기도 합니다.

• 고지 의무: 기본적으로 대부분의 오픈소스 라이선스가 요구하는 “저작권 표시"와 “라이선스 고지” 등의 고지 의무를 준수해야 합니다. 예를 들어 SK텔레콤이 배포하는 모바일 애플리케이션은 요구되는 고지 사항을 “About” 페이지로 제공할 수 있습니다.
• 소스 공개 의무: 소스 코드 공개 의무를 요구하는 Copyleft 라이선스 하의 오픈소스를 포함하는 소프트웨어를 배포할 경우, 사용자에게 소스 코드를 직접 제공하거나 사용자가 요청 시 소스 코드를 제공하겠다는 서면 약정서를 제공해야 합니다.

이와 같이 오픈소스 라이선스 의무사항을 준수하여 법적 리스크를 최소화하는 활동을 오픈소스 컴플라이언스라고 합니다.

오픈소스 보안취약점 점검 활동

자가 점검

CVE 확인

CVE는 알려진 오픈소스 보안 취약점을 데이터베이스로 제공합니다. 사용하려는 오픈소스를 CVE에서 검색하여 알려진 보안 취약점이 있는지 확인할 수 있습니다.

GitHub 확인

대표적인 오픈소스 저장소인 GitHub은 Public Repository에서 취약한 Dependency를 감지해 Dependabot 경고를 생성합니다.

보안취약점 진단 요청

SK텔레콤은 오픈소스 보안취약점 진단을 위한 도구를 운영합니다. 담당부서(정보보호담당)에 진단을 요청할 수 있습니다.

• 오픈소스 보안취약점 진단 요청

SK텔레콤 오픈소스 정책

SK텔레콤 오픈소스 정책과 부서별 R&R, 검증 프로세스는 다음 페이지를 참고하세요.

• 오픈소스 점검 프로세스 (사내한)

1.1 - 오픈소스 선택 시 고려사항

필요한 기능을 구현하려고 오픈소스를 사용하기로 했다면, 비슷한 기능을 제공하는 여러 오픈소스 프로젝트 중 어느 것을 선택하는 게 좋을까요? 여러 측면에서 고려할 점을 살펴봅니다.

품질

기능, 성능, 호환성 등 오픈소스의 품질은 오픈소스를 선택할 때 가장 중요한 요소입니다. GitHub에서 호스팅하는 프로젝트라면 Star 수와 Fork 수로 오픈소스의 완성도를 가늠할 수 있습니다. 오픈소스를 사용하려는 기술 조직은 충분히 기능과 성능을 검증한 후 제품과 서비스에 도입해야 합니다.

커뮤니티

오픈소스가 얼마나 많은 사용자를 확보하고 있는지, 이슈를 잘 관리하는지, 꾸준히 업데이트하는지 등 커뮤니티의 활성화 여부도 오픈소스를 선택할 때 고려할 사항입니다. 커뮤니티 활동이 수년 전에 멈춘 오픈소스보다는 지금도 활발한 커뮤니티를 가진 오픈소스를 선택하는 것이 유리합니다.

문서화

오픈소스를 제대로 도입하고 유지보수하려면 프로젝트가 문서를 얼마나 충실하게 제공하는지도 확인해야 합니다. 문서화가 잘 된 프로젝트의 산출물은 기업이 도입하기 수월합니다. 또한 기업이 개선한 패치를 프로젝트에 다시 기여하기도 쉽게 해 줍니다.

보안 취약점

알려진 취약점이 미패치 상태로 남아 있는 오픈소스 버전은 피해야 합니다. 보안 취약점이 발견된 버전은 CVE 같은 데이터베이스에서 관리합니다. 사용하려는 버전에 알려진 취약점이 있는지 확인하고, 있다면 패치된 상위 버전을 사용해야 합니다.

라이선스

오픈소스 라이선스는 소프트웨어를 누구나 자유롭게 사용할 수 있는 권리를 부여하는 허가증입니다. 다만 대부분의 오픈소스 라이선스는 오픈소스를 재배포할 때 준수해야 할 의무사항을 요구합니다. 예를 들어 고지 의무, 소스 코드 공개 의무 등입니다. 대표적인 오픈소스 라이선스인 GPL-2.0은 이와 결합하는 소프트웨어의 소스 코드까지 공개할 것을 요구합니다. 따라서 오픈소스를 선택할 때는 라이선스가 무엇인지, 라이선스를 준수할 수 있는 환경인지 반드시 미리 확인해야 합니다. 이를 위한 오픈소스 컴플라이언스 활동을 아래에서 설명합니다.

1.2 - 오픈소스 라이선스란?

오픈소스 란?

오픈소스란 라이선스 방식을 통해 배포된 소스 코드를 자유롭게(freely) 복사, 수정, 사용, 재배포할 수 있는 소프트웨어를 뜻합니다. 오픈소스는 누구라도 버그를 수정하거나 코드를 개조해 기능을 추가할 수 있으며, 소프트웨어 개발에 참여할 수 있습니다. 이렇게 오픈소스는 개발자에게 프로그램 배포 권리, 소스 코드 접근 권리, 소스 코드 수정 권리를 제공합니다.

오픈소스에도 법적 책임이!

오픈소스는 잘 활용하면 개발 비용과 기간을 줄일 수 있어 널리 쓰이지만, 적지 않은 사용자가 오픈소스의 법적 책임과 그에 따른 위험을 잘 알지 못합니다.

• 상용 소프트웨어와 마찬가지로 오픈소스를 사용하려면 해당 오픈소스의 라이선스를 반드시 준수해야 합니다. 이를 위반하면 사용 권리가 박탈되고, 이를 제품화한 경우 제품을 판매할 수 없습니다.
• 또한 오픈소스 커뮤니티로부터 클레임을 받아, 라이선스 위반 기업으로 기업 이미지에 큰 손실을 입을 수 있습니다.
• 최악의 경우 법적 소송에 연루될 수 있으므로, 오픈소스에 대해 미리 알고 대처하는 것이 중요합니다.

오픈소스의 법적 책임은 오픈소스 라이선스의 종류에 따라 다르므로, 오픈소스를 사용할 때는 각 라이선스의 법적 책임을 반드시 알고 사용해야 합니다.

소프트웨어 지식재산권

오픈소스의 법적 리스크를 이해하려면 소프트웨어에 관한 지식재산권과 라이선스의 기본 개념을 이해해야 합니다. 오픈소스 라이선스는 소프트웨어 라이선스의 일종이기 때문입니다. 소프트웨어를 보호하는 법적 장치, 즉 소프트웨어에 관한 지식재산권으로는 저작권, 특허권, 상표권, 영업비밀이 있습니다.

저작권 (Copyright)

저작권(Copyright)은 창작자(저작자)가 창작물에 대해 취득하는 권리로, 창작의 결과물을 보호하며 창작과 동시에 발생합니다. 따라서 어떤 프로그래머가 소프트웨어를 개발하면 저작권이 자동으로 발생하며, 그 권리는 프로그래머 또는 그가 속한 회사에 부여됩니다. 저작권이 있는 저작물은 저작권자의 허락 없이는 누구도 복제, 배포, 수정할 수 없습니다.

특허권 (Patent)

특허권(Patent)은 발명에 관하여 발명자(특허권자)가 갖는 독점 배타권입니다. 저작권과 달리 일정한 방식으로 출원해야 하며, 심사를 통과한 후 등록되어야 권리가 발생합니다. 특허기술을 사용하려면 반드시 특허권자의 허락을 얻어야 합니다. 특허받은 방식을 구현하는 소프트웨어라면 프로그래밍 언어와 상관없이 특허권의 범위에 속합니다.

소프트웨어 라이선스

소프트웨어에 대한 독점배타권을 가진 권리자는 다른 사람이 해당 소프트웨어를 사용하거나 배포하는 것을 허락할 수 있습니다. 간단히 말해 라이선스는 자신의 저작물을 다른 사람이 사용, 복사, 수정, 배포할 수 있도록 허가하는 것을 말합니다.

• 일반적인 상용 소프트웨어는 그 대가로 로열티를 요구합니다.

오픈소스 라이선스

일반 상용 소프트웨어와 마찬가지로 오픈소스에도 저작권 등 지식재산권이 있습니다. 그래서 권리자의 허락 없이 함부로 사용하면 소송을 당할 수 있습니다. 그런데 오픈소스의 권리자들은 많은 사람이 자유롭게 사용할 수 있도록 광범위한 라이선스를 부여합니다.

예를 들어 사용자에게 사용 권리뿐만 아니라 자유롭게 복제와 배포를 할 수 있도록 하고, 소스코드까지 제공해 자유롭게 수정할 수 있도록 허락합니다. 이를 위해서는 이러한 권한을 명시적으로 나타내는 오픈소스 라이선스가 필요합니다. 따라서 오픈소스 라이선스가 적용되지 않은 소프트웨어는 오픈소스가 아니며, 저작권자를 제외한 누구도 그 소프트웨어를 사용, 복제, 수정, 배포할 수 없습니다.

오픈소스 라이선스는 상용 소프트웨어처럼 로열티를 요구하지는 않으며, 대신 소스 코드 제공 등 몇 가지 지켜야 할 의무사항을 요구합니다.

주요 의무 사항

오픈소스의 의무사항을 이해하고 준수하는 것은 중요합니다. 오픈소스 라이선스의 일반적인 의무사항은 고지와 소스 코드 공개입니다.

저작권 표시 및 라이선스 고지

대부분의 오픈소스 라이선스는 개발자나 기여자에 관한 사항과 저작권에 관한 사항을 제품에 표시하거나 포함하도록 요구하며, 이용자가 오픈소스에 관한 권리를 잘 이해할 수 있도록 배포자가 해당 라이선스의 사본을 함께 첨부하도록 요구합니다.

예) Apache License 2.0
 
4. a. You must give any other recipients of the Work or Derivative Works a copy of
this License;
 
4. c. You must retain, in the Source form of any Derivative Works that You distribute,
all copyright, patent, trademark, and attribution notices from the Source form of the
Work, excluding those notices that do not pertain to any part of the Derivative Works;

소스코드 공개

대표적으로 GPL 계열의 라이선스는 바이너리 형태의 소프트웨어 배포를 허용하는 대신, 바이너리에 해당하는 소스코드를 함께 공개하도록 요구합니다.

예) GPL 2.0
 
3. You may copy and distribute the Program (or a work based on it, under Section 2) in
object code or executable form under the terms of Sections 1 and 2 above provided that
you also do one of the following:
 a) Accompany it with the complete corresponding machine-readable source code,

재배포시 동일 라이선스 적용

라이선스에 따라 큰 차이를 보이는 부분은 ‘Copyleft’에 관한 사항입니다. GPL을 대표로 하는 Copyleft 라이선스들은 이용자가 소프트웨어를 수정한 후 배포하려 할 때, 수정된 소프트웨어도 동일한 라이선스로 배포하도록 요구합니다.

예) GPL 2.0
 
2. You may modify your copy or copies of the Program or any portion of it, thus forming
a work based on the Program, and copy and distribute such modifications or work under
the terms of Section 1 above, provided that you also meet all of these conditions:
 b) You must cause any work that you distribute or publish, that in whole or in part
contains or is derived from the Program or any part thereof, to be licensed as a whole
at no charge to all third parties under the terms of this License.

1.3 - 오픈소스 라이선스 확인하기

여러 가지 방법으로 오픈소스 라이선스를 확인할 수 있습니다. 분석 도구를 사용하지 않고도 수동으로 확인하거나, 자동화 도구를 활용하여 효율적으로 확인할 수 있습니다.

수동 확인 방법

방법 1. 소스 코드 파일 상단 주석 확인

일반적인 오픈소스는 소스 코드 파일 상단에 저작권과 라이선스 정보를 표시합니다.

(https://github.com/SKTBrain/KoBERT/blob/master/kobert/pytorch_kobert.py)

이 내용으로 오픈소스 라이선스를 확인할 수 있습니다.

SK텔레콤은 FOSSology라는 도구를 제공하여 누구나 소스 코드 파일 상단의 오픈소스 라이선스를 쉽게 확인할 수 있게 하였습니다.

방법 2. Root 폴더 내 LICENSE (혹은 COPYING) 파일 확인

일반적인 오픈소스는 Root 폴더 내 LICENSE 혹은 COPYING 파일로 라이선스 정보를 표시합니다.

(https://github.com/openinfradev/tacoplay)

방법 3. README 또는 웹사이트에서 라이선스 정보 확인

어떤 오픈소스는 오픈소스를 설명하는 README나 웹사이트 문서에서 라이선스 정보를 제공합니다.

(https://github.com/metatron-app/metatron-discovery)

자동화 도구를 활용한 확인

대규모 프로젝트나 다수의 의존성을 포함하는 경우, 자동화 도구를 사용하여 효율적으로 라이선스를 확인할 수 있습니다.

Syft

Syft는 컨테이너 이미지와 파일 시스템에서 SBOM을 생성하고 라이선스를 추출하는 도구입니다.

syft dir:. -o json

dir: 스캔은 로컬에서 라이선스를 확인하는 용도입니다. 제출용 SBOM은 패키지 매니저 컨텍스트(빌드된 이미지나 lockfile)가 있는 대상에서 생성해야 purl이 채워집니다. 자세한 내용은 SBOM 생성 방법을 참고하세요.

Trivy

Trivy는 취약점 스캔과 함께 라이선스 정보를 확인할 수 있는 도구입니다.

trivy fs --scanners license .

주의: Trivy를 포함한 외부 도구는 릴리스 태그 변조를 통한 공급망 공격에 노출될 수 있습니다. CLI 설치 시 공식 릴리스 채널을 이용하고, GitHub Actions에서는 가변 태그(@latest, @master 등) 대신 검증된 고정 버전이나 commit SHA를 사용하세요. 보고된 사례와 안전 사용법은 SBOM 생성 방법을 참고하세요.

자동화 도구를 활용한 SBOM 생성은 SBOM 생성 방법을 참고하시기 바랍니다.

라이선스 정보 우선순위

만약 방법 1-3에서 명시한 정보가 서로 상이하다면, 방법 1, 즉 파일 내 표시된 라이선스 정보에 우선순위를 두고 판단하시기 바랍니다.

1.4 - 오픈소스 라이선스별 의무사항

재배포하지 않는다면 자유롭게 사용 가능

먼저, 대부분의 오픈소스 라이선스는 ‘재배포’할 때 의무 사항을 부여합니다. 즉, 오픈소스를 ‘재배포’하지 않는다면 고지, 소스 코드 공개 등의 의무사항이 발생하지 않으므로 자유롭게 사용할 수 있습니다.

1. 제한 없는 라이선스 (Public Domain)

CC0, Public Domain과 같이 아무런 제한 없이 무료로 사용할 수 있는 라이선스가 있습니다.

2. Permissive 라이선스 (수월하게 사용 가능)

Permissive License라고 분류할 수 있는 오픈소스 라이선스는 고지 의무를 요구합니다. 오픈소스 라이선스의 고지 의무는 비교적 수월하게 준수할 수 있습니다.

이와 같이 고지 의무를 요구하는 Permissive 라이선스 하의 오픈소스를 포함하는 소프트웨어를 배포할 경우, “저작권 표시”, “라이선스 고지” 등의 의무를 준수해야 합니다. (참고: 저작권 표시 및 라이선스 고지)

SK텔레콤 오픈소스 컴플라이언스 프로세스를 통해 오픈소스 고지문을 발행하고 소프트웨어 배포 시 이를 동봉하여 고지 의무를 준수할 수 있습니다.

2-1. 주요 Permissive 라이선스

다음은 실무에서 가장 자주 사용되는 Permissive 라이선스로, 사용 사례별 가이드를 제공합니다.

2-2. 기타 Permissive 라이선스

이외에도 아래와 같은 Permissive 라이선스가 있습니다. 이들도 고지 의무를 준수하면 자유롭게 사용 가능합니다.

• Academic Free License v2.1 (AFL-2.1)
• Academic Free License v3.0 (AFL-3.0)
• Artistic License 1.0 (Perl) (Artistic-1.0-Perl)
• Artistic License 2.0 (Artistic-2.0)
• Apache Software License 1.1 (Apache-1.1)
• Boost Software License 1.0 (BSL-1.0)
• BSD-2-Clause Plus Patent License (BSD-2-Clause-Patent)
• Creative Commons Attribution 4.0 International (CC-BY-4.0)
• JSON License (JSON)
• The FreeType Project License (FTL)
• Independent JPEG Group License (IJG)
• libtiff License (libtiff)
• Lucent Public License v1.02 (LPL-1.02)
• Microsoft Public License (MS-PL)
• X11 License (X11)
• CMU License (MIT-CMU)
• University of Illinois/NCSA Open Source License (NCSA)
• OpenSSL License (OpenSSL)
• TCP Wrappers License (TCP-wrappers)
• Unicode License v3 (Unicode-3.0)
• X.Net License (Xnet)
• Zend License v2.0 (Zend-2.0)
• Zope Public License 2.1 (ZPL-2.1)

3. Weak Copyleft (조건부 사용 가능)

Weak Copyleft 유형의 라이선스는 소스 코드 공개를 요구하지만, 공개 범위가 Copyleft 유형의 라이선스에 비해 제한적이라는 특성이 있습니다.

Weak Copyleft 라이선스 유형으로 분류할 수 있는 오픈소스 라이선스는 다음과 같습니다.

Copyleft 라이선스 하의 오픈소스를 포함하는 소프트웨어를 배포할 경우, 사용자에게 소스 코드를 직접 제공하거나, 사용자가 요청시 소스 코드를 제공하겠다는 서면 약정서를 제공해야 합니다.

4. Copyleft (사용 주의)

GPL (GNU General Public License)은 오픈소스를 재배포 시 소스 코드 공개를 요구합니다. 오픈소스 자체의 소스 코드 뿐만 아니라 결합한 소스 코드까지 함께 동일한 라이선스 조건으로 공개할 것을 요구해서 Copyleft 성격의 라이선스라고도 합니다. Copyleft 라이선스 유형은 오픈소스 라이선스 중에 요구하는 의무사항이 가장 많은 라이선스 유형이기 때문에 이 유형의 라이선스로 배포되는 오픈소스는 사용 시 주의가 필요합니다.

Copyleft 라이선스 유형으로 분류할 수 있는 오픈소스 라이선스는 다음과 같습니다.

5. Network Copyleft (SaaS 제공 시 주의)

AGPL (GNU Affero General Public License)은 일반 GPL의 “배포” 개념을 확장하여 네트워크를 통한 서비스 제공도 배포로 간주합니다.

6. Source Available (제한적 오픈소스)

Source Available 라이선스는 소스 코드가 공개되어 있지만, OSI (Open Source Initiative)가 승인한 오픈소스 라이선스가 아닙니다. 이들은 상업적 SaaS 제공 등에 제한을 두며, 일반적인 오픈소스와는 다른 조건이 있습니다.

7. AI Model 라이선스

AI Model 라이선스는 AI 모델(가중치)에 적용되는 라이선스로, 일반 소프트웨어 라이선스와는 다른 특성이 있습니다. 이들은 모델의 사용, 수정, 배포는 허용하지만 특정 용도에 대한 제한을 포함합니다.

8. 사용 제한 라이선스

8-1. 비상업용 (Non-Commercial)

연구, 학습만을 위해서라고 해도 SK텔레콤 내에서 사용한다면 상업적인 활동으로 간주될 수 있습니다. 따라서 비상업적으로만 사용할 수 있도록 제한하는 라이선스에 따라 공개된 오픈소스는 SK텔레콤에서 사용할 수 없습니다. 이러한 비상업용 (Non-Commercial) 라이선스는 다음과 같습니다.

8-2. 광고 조항 포함

BSD-4-Clause 라이선스는 오픈소스의 기능/활용을 언급하는 모든 광고에 특정 문구 (“This product includes software developed by the .")의 포함을 요구합니다. 이러한 “advertising clause"의 요구사항을 준수하는 것은 쉽지 않기 때문에 사용을 제한합니다.

이러한 라이선스 하의 오픈소스를 반드시 포함해야 하는 경우라면 OSRB에 포함할 수 있는 방법을 문의하시기 바랍니다.

• Support (opensource@sktelecom.com)

9. 문서/콘텐츠 라이선스

Creative Commons 라이선스는 주로 문서, 이미지, 데이터셋 등의 콘텐츠에 사용되는 라이선스입니다. 이들은 소프트웨어 코드보다는 창작물에 적합한 라이선스입니다.

10. 이외 언급하지 않은 라이선스

위에서 분류되지 않은 라이선스가 적용된 오픈소스를 SK텔레콤의 제품에 사용하기 위해서는 사전 검토가 필요합니다. OSRB에 사용 가능 여부를 문의하시기 바랍니다.

• Support (opensource@sktelecom.com)

1.4.1 - AGPL-3.0 가이드

SPDX Identifier: AGPL-3.0-only 또는 AGPL-3.0-or-later

소스 코드 내 라이선스 문구

AGPL-3.0 라이선스 하의 오픈소스는 일반적으로 소스 코드 상단에 다음과 같은 문구가 있습니다.

Copyright (C) <year> <name of author>
 
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Affero General Public License for more details.
 
You should have received a copy of the GNU Affero General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.

사용 사례별 의무사항

Case 1. 소스 형태로 재배포

AGPL-3.0 라이선스 하의 오픈소스를 소스 형태로 재배포 시 다음 사항을 준수합니다.

1-1 고지 의무

• 저작권 고지 제공
• 보증 부인 제공
• 라이선스 사본 제공

즉, 소스 코드 내 명시된 저작권/라이선스 정보를 그대로 유지한 상태로 재배포합니다.

Case 2. 바이너리 형태로 재배포

AGPL-3.0 라이선스 하의 오픈소스를 빌드하여 바이너리 형태로만 재배포 시 다음 사항을 준수합니다.

2-1 고지 의무

• 저작권 고지 제공
• 보증 부인 제공
• 라이선스 사본 제공

이상의 내용을 포함하는 오픈소스 고지문을 생성하여 바이너리 재배포 시 동봉합니다.

2-2 소스 코드 제공 의무

바이너리에 해당하는 소스 코드를 제공합니다. 이때 다음 사항을 준수합니다.

1. AGPL-3.0은 파생저작물에도 AGPL-3.0을 적용하여 소스 코드를 공개할 것을 요구합니다. 아래 내용을 참고하여 AGPL-3.0 하의 오픈소스와 파생저작물의 소스 코드를 공개합니다.

2. 바이너리 사용자가 공개된 소스 코드로 동일한 바이너리를 만들 수 있는 빌드 환경을 제공합니다. 여기에는 다음 사항이 포함됩니다.
   • Tool chain 정보
   • 빌드 스크립트
   • 빌드 방법 (README)

소스 코드 대신 서면 약정서(Written Offer)를 제공할 수 있습니다. 여기에는 다음 진술이 포함되어야 합니다.

1. 서면 약정서는 제품 판매 후 3년간 유효합니다.
2. 누구에게나 제공합니다.
3. 비용 청구를 하지 않습니다. (소스 전달을 위해 발생하는 비용 제외)

2-3 설치 정보 제공 의무

바이너리를 User Product와 배포한다면 설치 정보(Installation Information)를 제공합니다.

• User Product : 전자 기기와 같은 Embedded Device
• 설치 정보(Installation Information) : 사용자가 소스 코드를 빌드하여 다시 제품에 설치하기 위해 필요한 모든 정보 및 방법

Case 3. 원격 네트워크 상호 작용

AGPL-3.0 하의 오픈소스를 (1) 수정하고, (2) 수정한 버전이 네트워크를 통해 원격의 사용자와 상호 작용하는 경우:

• 원격 사용자가 수정된 버전의 소스 코드를 다운 받을 수 있도록 네트워크 서버를 제공해야 합니다.
• 여기서의 소스 코드는 위의 “2-2. 소스 코드 제공 의무"에서 요구하는 범위와 동일합니다.

GPL-3.0과의 차이점

AGPL-3.0은 GPL-3.0에 네트워크 사용 조항을 추가한 라이선스입니다.

• GPL-3.0: 바이너리 배포 시에만 소스 코드 공개 의무
• AGPL-3.0: 바이너리 배포 + 네트워크를 통한 서비스 제공 시에도 소스 코드 공개 의무

이는 SaaS나 클라우드 서비스로 소프트웨어를 제공하면서 GPL의 소스 코드 공개 의무를 회피하는 것을 방지하기 위한 조항입니다.

라이선스 호환성

주요 라이선스와의 호환성

참고 자료

• AGPL-3.0 License 원문
• SPDX License List - AGPL-3.0
• GNU AGPL FAQ
• OSADL License Checklist

1.4.2 - Apache-2.0 가이드

SPDX Identifier: Apache-2.0

소스 코드 내 라이선스 문구

Apache-2.0 라이선스 하의 오픈소스는 일반적으로 소스 코드 상단에 다음과 같은 문구가 있습니다.

Copyright [yyyy] [name of copyright owner]
 
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
 
http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

사용 사례별 의무사항

Case 1. 소스 형태로 재배포

Apache-2.0 라이선스 하의 오픈소스를 소스 형태로 재배포 시 다음 사항을 준수합니다.

1-1 고지 의무

• 라이선스 사본 제공
• 저작권, 특허, 상표권 등 정보를 유지합니다.
• NOTICE 파일이 포함되어 있을 경우 이를 유지합니다.

즉, 소스 코드 내 명시된 저작권/라이선스 정보를 그대로 유지한 상태로 재배포합니다.

Case 2. 바이너리 형태로 재배포

Apache-2.0 라이선스 하의 오픈소스를 빌드하여 바이너리 형태로만 재배포 시 다음 사항을 준수합니다.

2-1 고지 의무

• 라이선스 사본 제공
• 저작권, 특허, 상표권 등 정보를 유지합니다.
• NOTICE 파일이 포함되어 있을 경우 이를 유지합니다.

이를 포함하는 오픈소스 고지문을 생성하여 바이너리 재배포 시 동봉합니다.

라이선스 호환성

Apache-2.0 라이선스는 명시적인 특허 허여 조항을 포함하고 있어 대부분의 라이선스와 호환됩니다.

주요 라이선스와의 호환성

참고 자료

• Apache License 2.0 원문
• SPDX License List - Apache-2.0
• OSADL License Checklist

1.4.3 - BigScience RAIL 가이드

SPDX Identifier: BigScience-RAIL-1.0

BigScience RAIL이란?

BigScience RAIL (Responsible AI License)은 2022년 BigScience 프로젝트가 BLOOM 언어 모델과 함께 공개한 라이선스입니다.

BigScience 프로젝트

• BLOOM: 176B 파라미터 다국어 언어 모델
• 1000명 이상의 연구자 참여
• 책임있는 AI 개발을 핵심 가치로 설정

RAIL의 두 가지 버전

BigScience는 RAIL-M 사용 (모델에만 적용)

주요 사용 프로젝트

BLOOM 계열

• BLOOM: BigScience의 176B 모델
• BLOOMZ: 지시 따르기(instruction-following) 버전
• mT0: 다국어 제로샷 모델

기타 RAIL 채택 모델

• 일부 오픈 LLM 파인튜닝 모델
• 연구용 언어 모델들

허용 사항

자유롭게 할 수 있는 것

1. 모델 사용

   • 텍스트 생성
   • 번역, 요약, 질의응답
   • 챗봇 구축
   • 상업적 서비스 제공

2. 모델 수정

   • 파인튜닝
   • 추가 학습
   • LoRA, QLoRA 등 경량화

3. 모델 배포

   • 수정된 모델 공개
   • 파생 모델 배포
   • 상업적 API 서비스

4. 생성물 활용

   • AI 생성 텍스트의 상업적 사용
   • 2차 저작물 제작

금지 사항 (Restrictions)

BigScience RAIL은 다음 용도로 사용할 수 없습니다:

1. 불법 활동

• 범죄 계획 또는 실행 지원
• 불법 콘텐츠 생성
• 테러 활동 지원

2. 아동 보호

• 아동 성 착취물 생성
• 아동을 대상으로 한 유해 콘텐츠
• 아동 그루밍 지원

3. 차별 및 혐오

• 인종, 민족, 종교에 대한 차별
• 성별, 성적 지향에 대한 차별
• 장애, 연령에 대한 차별
• 혐오 발언 생성

4. 허위 정보 및 조작

• 의도적인 가짜 뉴스 생성
• 딥페이크 텍스트 생성 (신원 도용 목적)
• 선거 조작 목적 콘텐츠
• 사기 목적 콘텐츠

5. 프라이버시 침해

• 개인정보 무단 수집
• 스토킹, 괴롭힘 지원
• 감시 목적 사용

6. 의료 및 법률

• 전문적 의료 진단 대체
• 법률 자문 대체
• 재무 자문 대체

7. 자해 및 폭력

• 자살, 자해 조장
• 폭력 조장
• 무기 제조 정보

8. 고위험 의사결정

• 자동화된 신용 평가 (단독 의사결정)
• 자동화된 채용 결정 (단독 의사결정)
• 형사 사법 결정 (단독 의사결정)

사용 시나리오

허용되는 사용

1. 챗봇 서비스

시나리오: 고객 상담 챗봇
사용 방식: BLOOM 파인튜닝하여 상담 봇 구축
판단: 허용 (상업적 사용 OK, 금지 용도 아님)

2. 번역 서비스

시나리오: 다국어 자동 번역
사용 방식: BLOOM의 다국어 능력 활용
판단: 허용

3. 콘텐츠 생성 도구

시나리오: 마케팅 카피 생성 도구
사용 방식: BLOOM 기반 텍스트 생성
판단: 허용 (차별적/허위 콘텐츠 아닌 경우)

금지되는 사용

1. 가짜 뉴스 생성기

시나리오: 자동 가짜 뉴스 생성 도구
사용 방식: 허위 정보 대량 생성
판단: 금지 (허위 정보 생성)

2. 차별적 콘텐츠 생성

시나리오: 특정 집단을 비하하는 텍스트 생성
사용 방식: 혐오 발언 생성
판단: 금지 (차별 및 혐오)

3. 자동화된 신용 평가

시나리오: LLM으로 신용 점수 자동 결정
사용 방식: 대출 승인/거부 자동 결정
판단: 금지 (고위험 의사결정)

검토 필요

1. 교육용 챗봇

시나리오: 학생 상담 챗봇
사용 방식: 진로 상담, 심리 상담
판단: 의료/심리 자문 경계, 전문가 검토 필요

2. 채용 보조 도구

시나리오: 이력서 스크리닝 보조
사용 방식: 최종 결정은 사람이 하지만 AI가 추천
판단: 사용 방식에 따라 다름, OSRB 검토

모델 카드 의무

BigScience RAIL은 모델 카드(Model Card) 제공을 권장합니다.

모델 카드에 포함할 내용

1. 모델 정보

   • 모델 구조, 파라미터 수
   • 학습 데이터 출처
   • 학습 방법

2. 제한 사항

   • 모델의 한계
   • 알려진 편향(Bias)
   • 부적절한 사용 사례

3. 사용 가이드

   • 권장 사용 사례
   • 금지 사항
   • 윤리적 고려사항

예시: BLOOM Model Card

파생 모델의 라이선스

파생 모델을 배포할 때:

필수 사항

• 동일한 용도 제한 사항 적용
• 라이선스 정보 명시
• 모델 카드 제공 (권장)

라이선스 전파

BLOOM을 파인튜닝하여 커스텀 모델을 만든 경우, 커스텀 모델에도 BigScience RAIL 또는 이와 동등한 제한을 적용해야 합니다.

AI 생성물의 책임

중요: 생성된 텍스트의 책임

• 모델 제공자: 모델 사용 제한 명시 의무
• 모델 사용자: 생성물의 적법성 확인 의무
• 서비스 제공자: 사용자의 악용 방지 조치 의무

참고 자료

• BigScience RAIL-1.0 원문
• SPDX License List - BigScience-RAIL-1.0
• BLOOM Model Card
• Responsible AI Licenses Initiative

1.4.4 - BSD-2-Clause 가이드

SPDX Identifier: BSD-2-Clause

소스 코드 내 라이선스 문구

BSD-2-Clause 라이선스 하의 오픈소스는 일반적으로 소스 코드 상단에 다음과 같은 문구가 있습니다.

Copyright (c) <YEAR>, <OWNER>
All rights reserved.
 
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
 
1. Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
 
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

사용 사례별 의무사항

Case 1. 소스 형태로 재배포

BSD-2-Clause 라이선스 하의 오픈소스를 소스 형태로 재배포 시 다음 사항을 준수합니다.

1-1 고지 의무

• 저작권 고지
• 라이선스 사본 제공
• 보증 부인 고지

즉, 소스 코드 내 저작권, 라이선스 등을 그대로 유지합니다.

Case 2. 바이너리 형태로 재배포

BSD-2-Clause 라이선스 하의 오픈소스를 빌드하여 바이너리 형태로만 재배포 시 다음 사항을 준수합니다.

2-1 고지 의무

• 저작권 고지
• 라이선스 사본 제공
• 보증 부인 고지

이를 포함하는 오픈소스 고지문을 생성하여 바이너리 재배포 시 동봉합니다.

라이선스 호환성

BSD-2-Clause 라이선스는 BSD 라이선스 중 가장 간결하며 대부분의 라이선스와 호환됩니다.

주요 라이선스와의 호환성

참고 자료

• BSD-2-Clause License 원문
• SPDX License List - BSD-2-Clause
• OSADL License Checklist

1.4.5 - BSD-3-Clause 가이드

SPDX Identifier: BSD-3-Clause

소스 코드 내 라이선스 문구

BSD-3-Clause 라이선스 하의 오픈소스는 일반적으로 소스 코드 상단에 다음과 같은 문구가 있습니다.

Copyright (c) <year>, <copyright holder>
All rights reserved.
 
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
 
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of the <organization> nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
 
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

사용 사례별 의무사항

Case 1. 소스 형태로 재배포

BSD-3-Clause 라이선스 하의 오픈소스를 소스 형태로 재배포 시 다음 사항을 준수합니다.

1-1 고지 의무

• 저작권 고지
• 라이선스 사본 제공
• 보증 부인 고지

즉, 소스 코드 내 저작권, 라이선스 등을 그대로 유지합니다.

Case 2. 바이너리 형태로 재배포

BSD-3-Clause 라이선스 하의 오픈소스를 빌드하여 바이너리 형태로만 재배포 시 다음 사항을 준수합니다.

2-1 고지 의무

• 저작권 고지
• 라이선스 사본 제공
• 보증 부인 고지

이를 포함하는 오픈소스 고지문을 생성하여 바이너리 재배포 시 동봉합니다.

라이선스 호환성

BSD-3-Clause 라이선스는 조직명 무단 사용 금지 조항을 포함하고 있으며 대부분의 라이선스와 호환됩니다.

주요 라이선스와의 호환성

참고 자료

• BSD-3-Clause License 원문
• SPDX License List - BSD-3-Clause
• OSADL License Checklist

1.4.6 - BSD-4-Clause 가이드

SPDX Identifier: BSD-4-Clause

소스 코드 내 라이선스 문구

BSD-4-Clause 라이선스 하의 오픈소스는 일반적으로 소스 코드 상단에 다음과 같은 문구가 있습니다.

Copyright (c) <year>, <copyright holder>
All rights reserved.
 
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
 
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes software developed by the <organization>.
4. Neither the name of the <organization> nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
 
THIS SOFTWARE IS PROVIDED BY <COPYRIGHT HOLDER> ''AS IS'' AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

사용 사례별 의무사항

Case 1. 소스 형태로 재배포

BSD-4-Clause 라이선스 하의 오픈소스를 소스 형태로 재배포 시 다음 사항을 준수합니다.

1-1 고지 의무

• 저작권 고지
• 라이선스 사본 제공
• 보증 부인 고지
• BSD-4-Clause 하 오픈소스의 기능/활용을 언급하는 모든 광고에 다음 문구 포함
  “This product includes software developed by the <organization>."

즉, 소스 코드 내 저작권, 라이선스 등을 그대로 유지합니다.

Case 2. 바이너리 형태로 재배포

BSD-4-Clause 라이선스 하의 오픈소스를 빌드하여 바이너리 형태로만 재배포 시 다음 사항을 준수합니다.

2-1 고지 의무

• 저작권 고지
• 라이선스 사본 제공
• 보증 부인 고지
• BSD-4-Clause 하 오픈소스의 기능/활용을 언급하는 모든 광고에 다음 문구 포함
  “This product includes software developed by the <organization>."

이를 포함하는 오픈소스 고지문을 생성하여 바이너리 재배포 시 동봉합니다.

라이선스 호환성

BSD-4-Clause는 광고 조항으로 인해 다른 라이선스와의 호환성에 문제가 있습니다.

주요 라이선스와의 호환성

참고 자료

• BSD-4-Clause License 원문
• SPDX License List - BSD-4-Clause
• OSADL License Checklist

1.4.7 - BSL 가이드

SPDX Identifier: BUSL-1.1 (BSL-1.1이라고도 함)

BSL이란?

BSL(Business Source License)은 MariaDB Corporation이 2013년 만든 라이선스입니다. 핵심 특징은 시간 제한부 라이선스라는 점입니다.

동작 원리

1. 초기 기간 (Change Date 이전)

   • 특정 상업적 용도 제한
   • 소스 코드는 공개되어 있음
   • 비상업적/내부 사용은 일반적으로 허용

2. 전환 기간 (Change Date 이후)

   • 자동으로 진짜 오픈소스 라이선스로 전환
   • 보통 Apache-2.0, GPL-2.0, MIT 등으로 전환
   • 모든 제한 해제

BSL의 세 가지 주요 파라미터

1. Additional Use Grant

허용되는 특정 용도를 명시합니다.

예시:

• “연간 사용자 1000명 이하 서비스는 허용”
• “비프로덕션 환경에서는 자유롭게 사용 가능”
• “경쟁 서비스 제공 목적 사용 금지”

2. Change Date

오픈소스로 전환되는 날짜입니다. 일반적으로 릴리스 후 3-4년이 지정됩니다.

예: 2024년 1월 1일에 릴리스한 경우 Change Date는 2028년 1월 1일입니다.

3. Change License

전환될 오픈소스 라이선스입니다.

일반적으로:

• Apache-2.0 (가장 흔함)
• GPL-2.0
• MIT

주요 BSL 채택 프로젝트

데이터베이스

• MariaDB (일부 기능): Change License GPL-2.0, Change Date 릴리스 후 4년
• CockroachDB: Change License Apache-2.0 또는 MIT, Change Date 릴리스 후 3년

기타

• Ceph (일부 기능)
• MinIO (일부 에디션)
• Sentry (일부 기능)
• Akka (2.7 이후)

사용 가능 여부 판단

일반적으로 허용되는 경우

1. 내부 개발/테스트

   • 사내 개발 환경
   • 테스트 서버
   • 프로토타입 개발

2. 비프로덕션 용도

   • 학습/연구
   • 벤치마킹
   • 개념 검증 (PoC)

3. Additional Use Grant에 명시된 경우

제한되는 경우

1. 상업적 프로덕션 사용

   • 고객에게 제공하는 서비스
   • 제품에 포함하여 판매
   • SaaS로 제공

2. 경쟁 서비스 제공

   • BSL 소프트웨어와 경쟁하는 서비스 제공

확인 필요

프로젝트마다 Additional Use Grant가 다르므로 각 프로젝트의 LICENSE 파일 확인이 필수입니다.

Change Date 이후 사용

Change Date가 지나면 자동으로 Change License로 전환됩니다.

예시: CockroachDB v20.1 (2020년 5월 릴리스)

• Change Date: 2023년 5월 19일
• Change License: Apache-2.0
• 2023년 5월 19일부터는 Apache-2.0로 자유롭게 사용 가능

참고 자료

• BSL 1.1 원문
• SPDX License List - BUSL-1.1
• MariaDB BSL FAQ
• CockroachDB Licensing FAQs

1.4.8 - CDDL-1.0 가이드

SPDX Identifier: CDDL-1.0

사용 사례별 의무사항

Case 1. 소스 형태로 재배포

CDDL-1.0 라이선스 하의 오픈소스를 소스 형태로 재배포 시 다음 사항을 준수합니다.

1-1 고지 의무

• 라이선스 사본
• 저작권, 특허, 상표권 등 법적 고지 유지

즉, 소스 코드 내 명시된 저작권/라이선스 정보를 그대로 유지한 상태로 재배포합니다.

Case 2. 바이너리 형태로 재배포

CDDL-1.0 라이선스 하의 오픈소스를 빌드하여 바이너리 형태로만 재배포 시 다음 사항을 준수합니다.

2-1 고지 의무

• 라이선스 사본 제공
• 저작권, 특허, 상표권 등 법적 고지 유지

이상의 내용을 포함하는 오픈소스 고지문을 생성하여 바이너리 재배포 시 동봉합니다.

2-2 소스 코드 제공 의무

바이너리 내 CDDL-1.0에 해당하는 소스 코드 파일을 제공합니다. 이때 다음 사항을 준수합니다.

• CDDL-1.0은 파일 내 추가한 내용에도 CDDL-1.0을 적용하여 소스 코드를 공개할 것을 요구합니다. 따라서 원본 파일과 더불어 수정한 파일도 CDDL-1.0을 적용하여 공개합니다.

오픈소스 고지문에 사용자가 소스 코드를 수령할 수 있는 방법을 안내함으로써 소스 코드 제공 의무를 준수할 수 있습니다.

MPL 기반 라이선스

CDDL-1.0은 Mozilla Public License(MPL)를 기반으로 Sun Microsystems(현 Oracle)가 제작한 라이선스입니다.

• MPL 유사성: 파일 단위 Copyleft 적용
• 주요 사용처: Sun/Oracle 프로젝트 (OpenSolaris, GlassFish 등)
• 현재 상황: 현재는 CDDL 사용이 감소하고 있는 추세

라이선스 호환성

주요 라이선스와의 호환성

참고 자료

• CDDL-1.0 License 원문
• SPDX License List - CDDL-1.0
• OSADL License Checklist

1.4.9 - CreativeML Open RAIL-M 가이드

SPDX Identifier: CreativeML-OpenRAIL-M

CreativeML Open RAIL-M이란?

CreativeML Open RAIL-M (Responsible AI License - Model)은 2022년 Stable Diffusion과 함께 공개된 AI 모델 라이선스입니다.

RAIL (Responsible AI License)의 특징

1. Open: 누구나 자유롭게 사용
2. Responsible: 책임있는 사용을 위한 제한
3. Permissive: Apache-2.0처럼 상업적 사용 허용
4. Use-Based Restrictions: 용도 기반 제한

일반 오픈소스 라이선스와의 차이

주요 사용 프로젝트

Stable Diffusion

• Stable Diffusion v1.x: CreativeML Open RAIL-M
• Stable Diffusion v2.x: CreativeML Open RAIL++-M (개선판)
• Stable Diffusion XL: CreativeML Open RAIL++-M

기타 이미지 생성 모델

• Waifu Diffusion
• DreamBooth 파인튜닝 모델들

허용 사항

자유롭게 할 수 있는 것

1. 모델 사용

   • 이미지 생성
   • 상업적 목적 이미지 생성
   • API 서비스 제공

2. 모델 수정

   • 파인튜닝 (Fine-tuning)
   • 추가 학습
   • 모델 최적화

3. 모델 배포

   • 수정된 모델 재배포
   • 파생 모델 공개
   • 상업적 서비스에 통합

4. 생성물 활용

   • 생성된 이미지의 상업적 사용
   • 생성된 이미지의 판매
   • 생성된 이미지의 2차 저작물 제작

금지 사항 (Use-Based Restrictions)

CreativeML Open RAIL-M은 다음 용도로 사용할 수 없습니다:

1. 폭력 및 범죄

• 폭력을 조장하거나 미화하는 콘텐츠 생성
• 범죄 계획 또는 실행 지원
• 테러 활동 지원

2. 아동 착취

• 아동 성 착취물 (CSAM) 생성
• 미성년자를 성적 대상화하는 콘텐츠

3. 개인 프라이버시 침해

• 개인의 동의 없이 딥페이크 생성
• 신원 도용 목적의 이미지 생성
• 허위 정보 유포 목적

4. 차별 및 혐오

• 인종, 성별, 종교 등에 대한 차별적 콘텐츠
• 혐오 발언을 조장하는 이미지

5. 의료 및 법률 자문

• 전문적 의료 진단 목적
• 법률 자문 대체 목적

6. 기타 유해한 사용

• 자살 또는 자해 조장
• 불법 약물 홍보
• 도박 중독 조장

사용 시나리오

허용되는 사용

1. 마케팅 이미지 생성

시나리오: 광고용 이미지 생성 서비스
사용 방식: Stable Diffusion으로 제품 이미지 생성
판단: 허용 (상업적 사용 OK, 금지 용도 아님)

2. 게임 아트 생성

시나리오: 인디 게임 배경 이미지 제작
사용 방식: 파인튜닝하여 일관된 스타일 생성
판단: 허용

3. 교육용 콘텐츠

시나리오: 온라인 강의 썸네일 생성
사용 방식: AI 이미지 생성 API 제공
판단: 허용

금지되는 사용

1. 딥페이크 서비스

시나리오: 타인의 얼굴로 이미지 생성 서비스
사용 방식: 연예인 얼굴 합성
판단: 금지 (프라이버시 침해)

2. 가짜 뉴스 생성

시나리오: 정치인의 가짜 사진 생성
사용 방식: 허위 정보 유포 목적
판단: 금지 (개인 프라이버시 침해, 허위 정보)

검토 필요

1. 소셜 미디어 프로필 생성

시나리오: AI로 생성한 가상 인물 프로필
사용 방식: 실존하지 않는 인물의 프로필 사진
판단: 목적에 따라 다름, 악용 가능성 검토

파생 모델의 라이선스

CreativeML Open RAIL-M의 중요한 특징은 RAIL 조항 전파입니다.

파생 모델을 배포할 때:

• 동일한 용도 제한 사항 유지 필요
• 라이선스는 변경 가능하지만, Use-Based Restrictions는 유지
• 즉, “책임있는 사용” 조항은 계속 적용

예시: Stable Diffusion을 파인튜닝하여 커스텀 모델을 배포하는 경우, 커스텀 모델에도 동일한 금지 용도가 적용됩니다.

AI 생성물의 저작권

중요: 생성된 이미지는 모델 라이선스와 별개입니다

• 모델 라이선스: CreativeML Open RAIL-M (모델 자체)
• 생성물: 별도 저작권 (사용자가 소유)

생성된 이미지는:

• 사용자가 저작권 소유 (모델 제공자가 아님)
• 자유롭게 상업적 사용 가능
• 단, 생성 과정에서 금지 용도 위반하면 안 됨

참고 자료

• CreativeML Open RAIL-M 원문
• SPDX License List - CreativeML-OpenRAIL-M
• RAIL Initiative
• Stable Diffusion 라이선스 설명

1.4.10 - Elastic License 2.0 가이드

SPDX Identifier: Elastic-2.0

Elastic License 2.0이란?

Elastic License 2.0 (ELv2)은 Elastic사가 2021년 Elasticsearch와 Kibana의 라이선스를 Apache-2.0에서 변경하면서 도입한 라이선스입니다.

라이선스 변경 배경

2021년 1월 이전: Apache-2.0

• AWS가 Elasticsearch를 관리형 서비스로 제공 (Amazon Elasticsearch Service)
• Elastic사의 수익 모델 침해

2021년 1월 이후: Elastic License 2.0 + SSPL 듀얼 라이선스

• AWS의 관리형 서비스 제공 제한
• 결과: AWS는 OpenSearch로 포크

세 가지 금지 사항 (Limitations)

1. 관리형 서비스 제공 금지

금지: 제3자에게 소프트웨어의 실질적 기능을 서비스로 제공하는 것

구체적 예시:

금지되는 경우:

• “Elasticsearch as a Service” 제공
• “Managed Kibana” 제공
• 고객에게 Elasticsearch 클러스터를 관리형으로 제공

허용되는 경우:

• 자사 서비스의 백엔드로 Elasticsearch 사용
• 내부 검색 기능 구현
• 로그 분석 시스템 구축

2. 경쟁 제품의 핵심 기능으로 사용 금지

금지: 소프트웨어의 기능을 우회하거나 경쟁 제품을 만드는 것

구체적 예시:

금지되는 경우:

• Elasticsearch의 유료 기능 제한을 우회
• X-Pack 기능의 라이선스 체크 제거
• Elastic 상용 기능을 무료로 제공하는 제품 개발

허용되는 경우:

• Elasticsearch를 검색 엔진으로 사용하는 일반 애플리케이션
• 로그 수집 및 분석 도구 개발

3. 상표 사용 제한

금지: Elastic 상표를 오해의 소지가 있게 사용

구체적 예시:

금지되는 경우:

• “Powered by Elasticsearch” (공식 승인 없이)
• “Elasticsearch Compatible” (오해 소지)

허용되는 경우:

• “Works with Elasticsearch” (사실 기술)
• “Built on Elasticsearch technology” (명확한 사실 관계)

참고 자료

• Elastic License 2.0 원문
• SPDX License List - Elastic-2.0
• Elastic License 2.0 FAQ
• Elastic vs AWS: 라이선스 변경 배경

1.4.11 - EPL-2.0 가이드

SPDX Identifier: EPL-2.0

소스 코드 내 라이선스 문구

EPL-2.0 라이선스 하의 오픈소스는 일반적으로 소스 코드 상단에 다음과 같은 문구가 있습니다.

This program and the accompanying materials are made available under the
terms of the Eclipse Public License v. 2.0 which is available at
http://www.eclipse.org/legal/epl-2.0, or the Eclipse Distribution License
v. 1.0 which is available at
http://www.eclipse.org/org/documents/edl-v10.php.

사용 사례별 의무사항

Case 1. 소스 형태로 재배포

EPL-2.0 라이선스 하의 오픈소스를 소스 형태로 재배포 시 다음 사항을 준수합니다.

1-1 고지 의무

• 라이선스 사본 제공
• 저작권, 특허, 상표권, 보증부인, 면책 등 법적 고지 수정 금지

즉, 소스 코드 내 명시된 라이선스 정보를 그대로 유지한 상태로 재배포합니다.

Case 2. 바이너리 형태로 재배포

EPL-2.0 라이선스 하의 오픈소스를 빌드하여 바이너리 형태로만 재배포 시 다음 사항을 준수합니다.

2-1 고지 의무

• 라이선스 사본 제공
• 저작권, 특허, 상표권, 보증부인, 면책 등 법적 고지 수정 금지

이상의 내용을 포함하는 오픈소스 고지문을 생성하여 바이너리 재배포 시 동봉합니다.

2-2 소스 코드 제공 의무

바이너리 내 EPL-2.0에 해당하는 모듈의 소스 코드 파일을 제공합니다. 이때 다음 사항을 준수합니다.

• EPL-2.0은 모듈 내 추가한 내용에도 EPL-2.0을 적용하여 소스 코드를 공개할 것을 요구합니다. 따라서 원 모듈과 더불어 모듈 내 추가/수정한 내용도 EPL-2.0을 적용하여 공개합니다.

오픈소스 고지문에 사용자가 소스 코드를 수령할 수 있는 방법을 안내함으로써 소스 코드 제공 의무를 준수할 수 있습니다.

모듈 단위 Copyleft

EPL-2.0의 핵심 특징은 모듈 단위로 Copyleft가 적용된다는 점입니다.

• EPL-2.0 모듈 수정 시: 해당 모듈만 EPL-2.0로 공개
• 별도 모듈 추가 시: 추가한 모듈은 공개 불필요
• 다른 라이선스와 결합: 모듈을 분리하면 결합 가능

이러한 특성으로 인해 Eclipse 재단 프로젝트와 상용 소프트웨어를 함께 개발할 수 있습니다.

라이선스 호환성

주요 라이선스와의 호환성

참고 자료

• EPL-2.0 License 원문
• SPDX License List - EPL-2.0
• Eclipse Foundation FAQ
• OSADL License Checklist

1.4.12 - GPL-2.0 가이드

SPDX Identifier: GPL-2.0-only 또는 GPL-2.0-or-later

소스 코드 내 라이선스 문구

GPL-2.0 라이선스 하의 오픈소스는 일반적으로 소스 코드 상단에 다음과 같은 문구가 있습니다.

Copyright (C) yyyy name of author
 
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
 
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

사용 사례별 의무사항

Case 1. 소스 형태로 재배포

GPL-2.0 라이선스 하의 오픈소스를 소스 형태로 재배포 시 다음 사항을 준수합니다.

1-1 고지 의무

• 저작권 고지 제공
• 보증 부인 제공
• 라이선스 사본 제공

즉, 소스 코드 내 명시된 저작권/라이선스 정보를 그대로 유지한 상태로 재배포합니다.

Case 2. 바이너리 형태로 재배포

GPL-2.0 라이선스 하의 오픈소스를 빌드하여 바이너리 형태로만 재배포 시 다음 사항을 준수합니다.

2-1 고지 의무

• 저작권 고지 제공
• 보증 부인 제공
• 라이선스 사본 제공

이상의 내용을 포함하는 오픈소스 고지문을 생성하여 바이너리 재배포 시 동봉합니다.

2-2 소스 코드 제공 의무

바이너리에 해당하는 소스 코드를 제공합니다. 이때 다음 사항을 준수합니다.

1. GPL-2.0은 파생저작물에도 GPL-2.0을 적용하여 소스 코드를 공개할 것을 요구합니다. 아래 내용을 참고하여 GPL-2.0 하의 오픈소스와 파생저작물의 소스 코드를 공개합니다.

2. 바이너리 사용자가 공개된 소스 코드로 동일한 바이너리를 만들 수 있는 빌드 환경을 제공합니다. 여기에는 다음 사항이 포함됩니다.
   • Tool chain 정보
   • 빌드 스크립트
   • 빌드 방법 (README)

소스 코드 대신 서면 약정서(Written Offer)를 제공할 수 있습니다. 여기에는 다음 진술이 포함되어야 합니다.

1. 서면 약정서는 제품 판매 후 3년간 유효합니다.
2. 누구에게나 제공합니다.
3. 비용 청구를 하지 않습니다. (소스 전달을 위해 발생하는 비용 제외)

라이선스 호환성

주요 라이선스와의 호환성

참고 자료

• GPL-2.0 License 원문
• SPDX License List - GPL-2.0
• GNU GPL FAQ
• OSADL License Checklist

1.4.13 - GPL-3.0 가이드

SPDX Identifier: GPL-3.0-only 또는 GPL-3.0-or-later

소스 코드 내 라이선스 문구

GPL-3.0 라이선스 하의 오픈소스는 일반적으로 소스 코드 상단에 다음과 같은 문구가 있습니다.

Copyright (C) <year> <name of author>
 
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
 
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>

사용 사례별 의무사항

Case 1. 소스 형태로 재배포

GPL-3.0 라이선스 하의 오픈소스를 소스 형태로 재배포 시 다음 사항을 준수합니다.

1-1 고지 의무

• 저작권 고지 제공
• 보증 부인 제공
• 라이선스 사본 제공

즉, 소스 코드 내 명시된 저작권/라이선스 정보를 그대로 유지한 상태로 재배포합니다.

Case 2. 바이너리 형태로 재배포

GPL-3.0 라이선스 하의 오픈소스를 빌드하여 바이너리 형태로만 재배포 시 다음 사항을 준수합니다.

2-1 고지 의무

• 저작권 고지 제공
• 보증 부인 제공
• 라이선스 사본 제공

이상의 내용을 포함하는 오픈소스 고지문을 생성하여 바이너리 재배포 시 동봉합니다.

2-2 소스 코드 제공 의무

바이너리에 해당하는 소스 코드를 제공합니다. 이때 다음 사항을 준수합니다.

1. GPL-3.0은 파생저작물에도 GPL-3.0을 적용하여 소스 코드를 공개할 것을 요구합니다. 아래 내용을 참고하여 GPL-3.0 하의 오픈소스와 파생저작물의 소스 코드를 공개합니다.

2. 바이너리 사용자가 공개된 소스 코드로 동일한 바이너리를 만들 수 있는 빌드 환경을 제공합니다. 여기에는 다음 사항이 포함됩니다.
   • Tool chain 정보
   • 빌드 스크립트
   • 빌드 방법 (README)

소스 코드 대신 서면 약정서(Written Offer)를 제공할 수 있습니다. 여기에는 다음 진술이 포함되어야 합니다.

1. 서면 약정서는 제품 판매 후 3년간 유효합니다.
2. 누구에게나 제공합니다.
3. 비용 청구를 하지 않습니다. (소스 전달을 위해 발생하는 비용 제외)

2-3 설치 정보 제공 의무

바이너리를 User Product와 배포한다면 설치 정보(Installation Information)를 제공합니다.

• User Product : 전자 기기와 같은 Embedded Device
• 설치 정보(Installation Information) : 사용자가 소스 코드를 빌드하여 다시 제품에 설치하기 위해 필요한 모든 정보 및 방법

GPL-2.0 대비 주요 개선사항

GPL-3.0은 GPL-2.0의 핵심 원칙을 유지하면서 다음 사항을 개선하였습니다.

• 특허 허여 명시: 기여자의 특허 라이선스 허여를 명시적으로 규정
• 티보이제이션 방지: User Product에 설치 정보 제공 의무 추가
• 국제화: 전 세계적으로 적용 가능하도록 법적 용어 개선

라이선스 호환성

주요 라이선스와의 호환성

참고 자료

• GPL-3.0 License 원문
• SPDX License List - GPL-3.0
• GNU GPL FAQ
• OSADL License Checklist

1.4.14 - LGPL-2.1 가이드

SPDX Identifier: LGPL-2.1-only 또는 LGPL-2.1-or-later

소스 코드 내 라이선스 문구

LGPL-2.1 라이선스 하의 오픈소스는 일반적으로 소스 코드 상단에 다음과 같은 문구가 있습니다.

Copyright (C) year name of author
 
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
 
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
 
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

사용 사례별 의무사항

Case 1. 소스 형태로 재배포

LGPL-2.1 라이선스 하의 오픈소스를 소스 형태로 재배포 시 다음 사항을 준수합니다.

1-1 고지 의무

• 저작권 고지 제공
• 보증 부인 제공
• 라이선스 사본 제공

즉, 소스 코드 내 명시된 저작권/라이선스 정보를 그대로 유지한 상태로 재배포합니다.

Case 2. 바이너리(라이브러리) 형태로 재배포

LGPL-2.1 라이선스 하의 오픈소스를 빌드하여 바이너리 형태로만 재배포 시 다음 사항을 준수합니다.

2-1 고지 의무

• 저작권 고지 제공
• 보증 부인 제공
• 라이선스 사본 제공

이상의 내용을 포함하는 오픈소스 고지문을 생성하여 라이브러리 재배포 시 동봉합니다.

2-2 소스 코드 제공 의무

바이너리(라이브러리)에 해당하는 소스 코드를 제공합니다. 이때 다음 사항을 준수합니다.

1. LGPL-2.1은 파생저작물에도 LGPL-2.1을 적용하여 소스 코드를 공개할 것을 요구합니다. 아래 내용을 참고하여 LGPL-2.1 하의 오픈소스와 파생저작물의 소스 코드를 공개합니다.

2. 사용자가 공개된 LGPL 라이브러리의 소스 코드를 빌드하여 동일한 라이브러리를 만들 수 있는 빌드 환경을 제공합니다. 여기에는 다음 사항이 포함됩니다.

   • Tool chain 정보
   • 빌드 스크립트
   • 빌드 방법 (README)

3. LGPL 라이브러리를 Static Link하여 생성한 실행파일(Executable)을 배포하는 경우, 사용자가 LGPL 라이브러리를 수정하고 다시 실행파일을 생성할 수 있도록 실행파일을 구성하는 오브젝트 코드를 제공합니다. (#LGPLStaticVsDynamic)

소스 코드 대신 서면 약정서(Written Offer)를 제공할 수 있습니다. 여기에는 다음 진술이 포함되어야 합니다.

1. 서면 약정서는 제품 판매 후 3년간 유효합니다.
2. 누구에게나 제공합니다.
3. 비용 청구를 하지 않습니다. (소스 전달을 위해 발생하는 비용 제외)

동적 링크 vs 정적 링크

LGPL-2.1의 핵심은 링킹 방식에 따라 소스 코드 공개 범위가 달라진다는 점입니다.

• 동적 링크(Dynamic Link): LGPL 라이브러리만 공개, 애플리케이션 코드는 공개 불필요
• 정적 링크(Static Link): LGPL 라이브러리 + 오브젝트 코드 제공 필요

상용 소프트웨어 개발 시에는 동적 링크 사용을 권장합니다.

라이선스 호환성

주요 라이선스와의 호환성

참고 자료

• LGPL-2.1 License 원문
• SPDX License List - LGPL-2.1
• GNU LGPL FAQ
• OSADL License Checklist

1.4.15 - LGPL-3.0 가이드

SPDX Identifier: LGPL-3.0-only 또는 LGPL-3.0-or-later

소스 코드 내 라이선스 문구

LGPL-3.0 라이선스 하의 오픈소스는 일반적으로 소스 코드 상단에 다음과 같은 문구가 있습니다.

Copyright (C) <year> <name of author>
 
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Lesser General Public License for more details.
 
You should have received a copy of the GNU Lesser General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.

사용 사례별 의무사항

Case 1. 소스 형태로 재배포

LGPL-3.0 라이선스 하의 오픈소스를 소스 형태로 재배포 시 다음 사항을 준수합니다.

1-1 고지 의무

• 저작권 고지 제공
• 보증 부인 제공
• 라이선스 사본 제공

즉, 소스 코드 내 명시된 저작권/라이선스 정보를 그대로 유지한 상태로 재배포합니다.

Case 2. 바이너리(라이브러리) 형태로 재배포

LGPL-3.0 라이선스 하의 오픈소스를 빌드하여 바이너리 형태로만 재배포 시 다음 사항을 준수합니다.

2-1 고지 의무

• 저작권 고지 제공
• 보증 부인 제공
• 라이선스 사본 제공

이상의 내용을 포함하는 오픈소스 고지문을 생성하여 라이브러리 재배포 시 동봉합니다.

2-2 소스 코드 제공 의무

바이너리(라이브러리)에 해당하는 소스 코드를 제공합니다. 이때 다음 사항을 준수합니다.

1. LGPL-3.0은 파생저작물에도 LGPL-3.0을 적용하여 소스 코드를 공개할 것을 요구합니다. 아래 내용을 참고하여 LGPL-3.0 하의 오픈소스와 파생저작물의 소스 코드를 공개합니다.

2. 사용자가 공개된 LGPL 라이브러리의 소스 코드를 빌드하여 동일한 라이브러리를 만들 수 있는 빌드 환경을 제공합니다. 여기에는 다음 사항이 포함됩니다.

   • Tool chain 정보
   • 빌드 스크립트
   • 빌드 방법 (README)

3. LGPL 라이브러리를 Static Link하여 생성한 실행파일(Executable)을 배포하는 경우, 사용자가 LGPL 라이브러리를 수정하고 다시 실행파일을 생성할 수 있도록 실행파일을 구성하는 오브젝트 코드를 제공합니다. (#LGPLStaticVsDynamic)

소스 코드 대신 서면 약정서(Written Offer)를 제공할 수 있습니다. 여기에는 다음 진술이 포함되어야 합니다.

1. 서면 약정서는 제품 판매 후 3년간 유효합니다.
2. 누구에게나 제공합니다.
3. 비용 청구를 하지 않습니다. (소스 전달을 위해 발생하는 비용 제외)

2-3 설치 정보 제공 의무

라이브러리를 User Product와 배포한다면 설치 정보(Installation Information)를 제공합니다.

• User Product : 전자 기기와 같은 Embedded Device
• 설치 정보(Installation Information) : 사용자가 소스 코드를 빌드하여 다시 제품에 설치하기 위해 필요한 모든 정보 및 방법

LGPL-2.1 대비 주요 개선사항

LGPL-3.0은 LGPL-2.1의 핵심 원칙을 유지하면서 다음 사항을 개선하였습니다.

• 특허 허여 명시: 기여자의 특허 라이선스 허여를 명시적으로 규정
• Apache-2.0 호환: Apache-2.0과의 호환성 문제 해결
• 티보이제이션 방지: User Product에 설치 정보 제공 의무 추가

라이선스 호환성

주요 라이선스와의 호환성

참고 자료

• LGPL-3.0 License 원문
• SPDX License List - LGPL-3.0
• GNU LGPL FAQ
• OSADL License Checklist

1.4.16 - Llama 2 Community License 가이드

SPDX Identifier: Llama-2 (비공식)

Llama 2 Community License란?

Llama 2 Community License는 2023년 Meta가 Llama 2 언어 모델과 함께 공개한 독점 라이선스입니다.

Llama 모델 계보

왜 “Community License"인가?

Meta는 이 라이선스를 다음과 같이 설명합니다:

• 커뮤니티의 혁신 장려: 대부분의 개발자와 기업이 자유롭게 사용
• 대기업 견제: 빅테크의 독점적 사용 제한
• 책임있는 AI: 유해한 사용 방지

7억 명 규모 제한

MAU (Monthly Active Users) 정의

월간 활성 사용자: 이전 달력월에 제품/서비스를 사용한 고유 사용자 수

예시:

시나리오 1: T전화 앱 (MAU 500만)
MAU가 7억 미만이므로 자유롭게 사용할 수 있습니다.

시나리오 2: Facebook (MAU 30억)
MAU가 7억 이상이므로 Meta에 별도 라이선스를 요청해야 합니다.

7억 명 기준을 넘는 서비스

전 세계적으로 7억 명 이상 MAU를 가진 서비스:

• Facebook, Instagram, WhatsApp (Meta)
• YouTube (Google)
• TikTok
• WeChat

대부분의 기업은 해당 없음

규모 제한 적용 시점

라이선스 동의 시점 + 사용 시작 이후 계속 적용됩니다.

중요: 처음에는 7억 명 미만이었다가 나중에 초과하면 어떻게 될까요? 초과 시점에 Meta에 통보하고 별도 라이선스를 협상해야 합니다.

허용 사항 (MAU 7억 미만)

자유롭게 할 수 있는 것

1. 상업적 사용

   • 유료 서비스 제공
   • API 판매
   • 제품에 통합

2. 모델 수정

   • 파인튜닝
   • 양자화 (4-bit, 8-bit)
   • 모델 병합

3. 모델 배포

   • 파생 모델 공개
   • Hugging Face 등에 업로드
   • 오픈소스 프로젝트 포함

4. 생성물 활용

   • AI 생성 텍스트의 상업적 사용

금지 사항 (Acceptable Use Policy)

Llama 2는 다음 용도로 사용할 수 없습니다:

1. 불법 활동

• 범죄 행위 지원
• 불법 물품 거래
• 테러 활동

2. 아동 보호

• 아동 학대 콘텐츠
• 아동 그루밍

3. 차별 및 혐오

• 차별적 콘텐츠 생성
• 혐오 발언
• 괴롭힘

4. 폭력 및 위험

• 폭력 조장
• 자해, 자살 조장
• 무기 제조

5. 프라이버시 침해

• 개인정보 무단 수집
• 스토킹, 감시

6. 허위 정보

• 고의적 가짜 뉴스
• 사기 콘텐츠

7. 고위험 분야 (단독 의사결정)

• 의료 진단
• 법률 자문
• 재무 자문
• 긴급 서비스

Llama 2로 경쟁 LLM 학습 금지

특이 조항으로, Llama 2를 사용하여 Meta와 경쟁하는 LLM을 학습시킬 수 없습니다.

금지 예시:

• Llama 2의 출력으로 새로운 LLM 학습
• Llama 2를 teacher 모델로 사용한 distillation

허용 예시:

• Llama 2 자체를 파인튜닝
• Llama 2의 출력을 데이터셋으로 사용 (특정 태스크용)

사용 시나리오

허용되는 사용

1. 고객 서비스 챗봇

시나리오: 통신사 고객 상담 챗봇
MAU: 1000만 명
판단: 허용 (7억 미만)

2. B2B AI 솔루션

시나리오: 기업용 문서 요약 솔루션
MAU: 10만 명
판단: 허용

3. 모바일 앱 AI 기능

시나리오: 사진 캡션 생성 앱
MAU: 500만 명
판단: 허용

제한되는 사용

1. 대규모 소셜 미디어

시나리오: MAU 10억 명의 소셜 미디어에 통합
판단: Meta 라이선스 필요

2. 경쟁 LLM 학습

시나리오: Llama 2 출력으로 새 LLM 학습
판단: 금지

검토 필요

1. 글로벌 서비스 확장

시나리오: 현재 MAU 5000만, 향후 10억 목표
판단: 7억 도달 전 Meta와 협의 필요

파생 모델의 라이선스

필수 요구사항

1. 출처 명시

   • “Based on Llama 2” 표시
   • 모델 카드에 명시

2. 라이선스 전파

   • 동일한 Acceptable Use Policy 적용
   • 7억 명 규모 제한 유지

3. Meta 상표 사용 제한

   • “Llama” 상표 무단 사용 금지
   • “Built with Llama 2” 표현은 OK

파생 모델 예시

허용되는 이름:

• “MyModel (based on Llama 2)”
• “CustomLLM-Llama2-7B”

금지되는 이름:

• “Llama 2 Pro”
• “Meta Llama Custom”

Llama 3 업데이트

2024년 4월 공개된 Llama 3는 업데이트된 라이선스를 사용합니다:

• 기본 구조 유사
• 용도 제한 조항 일부 개선
• 7억 명 규모 제한 유지

Llama 3 사용 시에도 동일한 가이드가 적용됩니다.

참고 자료

• Llama 2 Community License 원문
• Llama 2 Acceptable Use Policy
• Llama 2 Model Card
• Meta AI 공식 블로그

1.4.17 - MIT 가이드

SPDX Identifier: MIT

소스 코드 내 라이선스 문구

MIT 라이선스 하의 오픈소스는 일반적으로 소스 코드 상단에 다음과 같은 문구가 있습니다.

Copyright (c) <year> <copyright holders>
 
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without
restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following
conditions:
 
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
 
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.

사용 사례별 의무사항

Case 1. 소스 형태로 재배포

MIT 라이선스 하의 오픈소스를 소스 형태로 재배포 시 다음 사항을 준수합니다.

1-1 고지 의무

• 저작권 고지
• 라이선스 사본 제공

즉, 소스 코드 내 저작권, 라이선스 등을 그대로 유지합니다.

Case 2. 바이너리 형태로 재배포

MIT 라이선스 하의 오픈소스를 빌드하여 바이너리 형태로만 재배포 시 다음 사항을 준수합니다.

2-1 고지 의무

• 저작권 고지
• 라이선스 사본 제공

이를 포함하는 오픈소스 고지문을 생성하여 바이너리 재배포 시 동봉합니다.

라이선스 호환성

MIT 라이선스는 대부분의 다른 라이선스와 호환됩니다.

주요 라이선스와의 호환성

참고 자료

• MIT License 원문
• SPDX License List - MIT
• OSADL License Checklist

1.4.18 - MPL-2.0 가이드

SPDX Identifier: MPL-2.0

소스 코드 내 라이선스 문구

MPL-2.0 라이선스 하의 오픈소스는 일반적으로 소스 코드 상단에 다음과 같은 문구가 있습니다.

This Source Code Form is subject to the terms of the Mozilla Public
License, v.2.0. If a copy of the MPL was not distributed with this file,
You can obtain one at https://mozilla.org/MPL/2.0/.

사용 사례별 의무사항

Case 1. 소스 형태로 재배포

MPL-2.0 라이선스 하의 오픈소스를 소스 형태로 재배포 시 다음 사항을 준수합니다.

1-1 고지 의무

• 라이선스 사본 제공 혹은 참조
• 법적 고지 수정 금지

즉, 소스 코드 내 명시된 라이선스 정보를 그대로 유지한 상태로 재배포합니다.

Case 2. 바이너리 형태로 재배포

MPL-2.0 라이선스 하의 오픈소스를 빌드하여 바이너리 형태로만 재배포 시 다음 사항을 준수합니다.

2-1 고지 의무

• 라이선스 사본 제공

이상의 내용을 포함하는 오픈소스 고지문을 생성하여 바이너리 재배포 시 동봉합니다.

2-2 소스 코드 제공 의무

바이너리 내 MPL-2.0에 해당하는 소스 코드 파일을 제공합니다. 이때 다음 사항을 준수합니다.

• MPL-2.0은 파일 내 추가한 내용에도 MPL-2.0을 적용하여 소스 코드를 공개할 것을 요구합니다. 따라서 원본 파일과 더불어 수정한 파일도 MPL-2.0을 적용하여 공개합니다.

오픈소스 고지문에 사용자가 소스 코드를 수령할 수 있는 방법을 안내함으로써 소스 코드 제공 의무를 준수할 수 있습니다.

파일 단위 Copyleft

MPL-2.0의 핵심 특징은 파일 단위로 Copyleft가 적용된다는 점입니다.

• MPL-2.0 파일 수정 시: 해당 파일만 MPL-2.0로 공개
• 별도 파일 추가 시: 추가한 파일은 공개 불필요
• 다른 라이선스와 결합: 파일을 분리하면 결합 가능

이러한 특성으로 인해 상용 소프트웨어 개발에 유연하게 사용할 수 있습니다.

라이선스 호환성

주요 라이선스와의 호환성

여기서 “호환"은 결합하거나 함께 배포할 수 있고 MPL 파일의 소스 공개 의무는 유지된다는 의미입니다. MPL이 permissive 라이선스라는 뜻은 아닙니다.

참고 자료

• MPL-2.0 License 원문
• SPDX License List - MPL-2.0
• Mozilla MPL FAQ
• OSADL License Checklist

1.4.19 - SSPL 가이드

SPDX Identifier: SSPL-1.0

SSPL이란?

SSPL(Server Side Public License)은 MongoDB가 AWS와 같은 클라우드 제공업체가 MongoDB를 상업적 서비스로 제공하는 것을 막기 위해 2018년 만든 라이선스입니다.

AGPL-3.0과의 차이점

SSPL은 AGPL-3.0 Section 13을 수정하여, 서비스 제공 시 다음을 모두 공개하도록 요구합니다:

• SSPL 소프트웨어 자체
• 서비스와 상호작용하는 모든 소프트웨어
• 서비스를 운영하는 데 필요한 관리 소프트웨어
• 인프라 프로비저닝, 모니터링, 백업 도구 등

주요 사용 사례

MongoDB의 라이선스 변경

• 2018년 10월 이전: AGPL-3.0
• 2018년 10월 이후: SSPL-1.0

기타 SSPL 채택 프로젝트

• Graylog
• 일부 NoSQL 데이터베이스

왜 OSI가 승인하지 않았나?

OSI는 2019년 SSPL을 오픈소스로 인정하지 않기로 결정했습니다:

1. 지나치게 광범위한 공개 요구: “서비스 운영에 필요한 모든 것"의 범위가 불명확
2. 차별 금지 위반: 특정 사업 모델(SaaS)을 사실상 금지
3. 자유로운 사용 제한: 상업적 클라우드 서비스 제공 사실상 불가능

사용 제한 이유

SSPL 소프트웨어를 사용하여 서비스를 제공하면 다음을 모두 공개해야 합니다:

1. SSPL 소프트웨어의 소스 코드
2. 서비스 애플리케이션 코드
3. Kubernetes 설정
4. Terraform 스크립트
5. 모니터링 도구 (Prometheus, Grafana 등)
6. CI/CD 파이프라인
7. 백업 및 복구 시스템

이는 SK텔레콤의 핵심 인프라 정보를 모두 공개해야 하므로 사용이 불가능합니다.

대안

SSPL 소프트웨어를 사용해야 하는 경우 다음 대안을 고려하시기 바랍니다.

MongoDB

• MongoDB Community Edition: SSPL
• 대안 1: MongoDB Atlas (MongoDB 공식 클라우드 서비스)
• 대안 2: PostgreSQL + JSON 기능
• 대안 3: FerretDB (MongoDB 호환 AGPL 프로젝트)

Graylog

• Graylog Open Source: SSPL
• 대안 1: Elasticsearch + Kibana (Elastic License 2.0, 별도 검토 필요)
• 대안 2: Grafana Loki (AGPL-3.0)

참고 자료

• SSPL License 원문
• SPDX License List - SSPL-1.0
• OSI의 SSPL 거부 결정
• MongoDB 라이선스 변경 발표

2 - 오픈소스 기여하기

SK텔레콤은 구성원이 패치 제공 등의 방법으로 외부 오픈소스 프로젝트에 기여하는 것을 적극 권장합니다. 버그를 찾았거나 코드를 개선했다면 오픈소스 프로젝트에 다시 기여하세요. 기여는 개인뿐만 아니라 기업에도 도움이 됩니다.

이 페이지는 기여를 시작하기 전에 “내가 지금 무엇을 해야 하는가"를 판단하는 진입점입니다.

한 장 요약

1. 내가 하려는 기여가 승인이 필요한지 먼저 확인합니다(아래 의사결정 흐름).
2. 승인이 필요하면 소속 조직 내부 승인을 받고 검토를 요청합니다(기여 절차).
3. SK텔레콤 기여 Rule을 지켜 코드를 준비합니다.
4. 프로젝트가 요구하는 방식으로 기여를 제출합니다.

의사결정 흐름

내가 하려는 기여가 어디에 해당하는지 보고 필요한 절차를 정합니다.

승인 없이 바로 기여할 수 있는 경우

다음은 저작권 침해 위험이 크지 않아 구성원의 판단으로 바로 기여할 수 있습니다.

• 10라인 이하의 작은 코드 조각
• Stack Overflow에서의 문의와 답변
• GitHub에서의 관리 활동(이슈 생성, Pull Request 리뷰와 승인 등)

전체 절차 한눈에 보기

• 기여 Rule: 기여할 때 지켜야 할 규칙
• 기여 절차: 승인을 받고 진행하는 절차
• 기여 제출: 프로젝트에 기여를 제출하는 실무 방법
• 배경 지식: 기여를 이해하기 위한 학습 자료

문의

오픈소스 기여 관련 문의와 요청은 OSRB(opensource@sktelecom.com)로 연락하세요.

2.1 - SK텔레콤 오픈소스 기여 Rule

SK텔레콤은 오픈소스 커뮤니티와의 협업 가치를 존중하고, 구성원의 외부 오픈소스 프로젝트로의 기여를 장려합니다. 다만 SK텔레콤의 지식재산을 보호하고 의도치 않은 저작권 침해를 막기 위해 지켜야 할 규칙이 있습니다.

승인 받기

오픈소스 기여는 저작권 관점에서 저작자가 저작물을 수정하고 사용하고 배포할 권한을 프로젝트에 부여하는 행위입니다. 때로는 저작권 자체를 프로젝트에 양도하기도 합니다. 일반적으로 고용 기간에 만든 저작물의 저작권은 고용주가 소유하므로, SK텔레콤 구성원이 만든 저작물은 SK텔레콤이 소유합니다. 구성원이 임의로 기여하면 불필요한 저작권 침해 이슈가 생길 수 있습니다.

따라서 기여하려는 프로젝트가 있다면, 최초 기여 전에 기여 절차에 따라 리뷰 요청과 승인을 받으세요.

기여할 권리가 있는 코드

직접 작성한 코드를 기여하세요. 3rd party의 코드를 임의로 기여해서는 안 됩니다.

지식 재산 노출 주의

민감한 정보나 특허 등 기업의 지식재산이 노출될 우려가 있는 코드와 문서는 기여하지 마세요. 기여하려는 코드에 회사의 특허가 포함되어 있다면, 이 특허를 오픈소스 라이선스로 기여해도 되는지 확인하세요. 모호하면 OSRB에 문의하세요.

참고로 Apache-2.0이나 GPL-3.0처럼 명시적 특허 라이선스 조항이 있는 라이선스로 기여하면, 기여한 코드를 구현하는 데 필요한 회사 보유 특허의 실시권까지 함께 허여될 수 있습니다. 특허가 얽힌 코드라면 기여 전에 OSRB의 검토를 받으세요.

코드 품질

수준 이하의 코드는 기여하지 마세요. 이는 기업의 평판에도 영향을 줄 수 있습니다.

CLA 서명 주의

어떤 프로젝트는 모든 기여자에게 CLA(Contributor License Agreement) 서명을 요구합니다. 이는 여러 기여자의 저작물을 관리하면서 생길 수 있는 저작권 분쟁을 줄이기 위한 약정서입니다. 주로 대기업이 주도하는 프로젝트에서 요구합니다.

CLA는 프로젝트마다 다르지만 주로 다음에 동의하는 내용을 담습니다.

• 나(또는 소속 기업)는 기여물을 프로젝트에 기여할 권리가 있다(기여물의 저작자이다).
• 나(또는 소속 기업)는 기여물을 프로젝트가 수정하고 배포하고 관리할 권한을 부여한다.
• 나(또는 소속 기업)는 부여한 권한을 철회하지 않는다.
• 나(또는 소속 기업)는 프로젝트가 향후 라이선스를 변경할 권한을 부여한다.
• 나(또는 소속 기업)는 기여물에 구현된 특허에 대해 프로젝트와 사용자에게 라이선스(특허 실시권)를 허여한다.

드물게 어떤 CLA는 다음 조건에도 동의를 요구합니다.

• 나(또는 소속 기업)는 기여와 동시에 저작권을 프로젝트 또는 관리 조직으로 양도한다.

SK텔레콤은 자사의 지식재산 보호를 위해 저작권 양도를 요구하는 프로젝트로의 기여는 허용하지 않습니다. 따라서 기여하려는 프로젝트가 CLA 서명을 요구하면, 서명 전에 반드시 OSRB에 리뷰를 요청하세요. 대부분의 CLA는 서명해도 문제가 없어 승인이 오래 걸리지 않습니다.

CLA 대신 DCO(Developer Certificate of Origin)를 요구하는 프로젝트도 많습니다. DCO는 저작권이나 특허권을 양도하거나 별도로 허여하는 것이 아니라, 기여물이 본인의 것이며 기여할 권리가 있음을 커밋의 Signed-off-by로 증명하는 경량 방식입니다. DCO 서명 방법은 기여 제출에서 설명합니다.

저작권 표시

구성원이 재직 기간에 만든 저작물의 지식재산은 기본적으로 기업이 소유합니다. 따라서 외부 프로젝트에 코드를 기여할 때 SK텔레콤의 저작권을 표기해야 합니다. 하나 이상의 파일을 기여할 때 파일 상단에 다음과 같이 저작권과 라이선스를 표기합니다.

SPDX-FileCopyrightText: Copyright {연도} SK TELECOM CO., LTD.
SPDX-License-Identifier: {SPDX_license_id}

• {연도}는 파일을 작성한 연도를 적습니다.
• {SPDX_license_id}는 해당 프로젝트의 라이선스 정책에 따릅니다.
• 버그 수정처럼 기존 코드를 일부 수정하는 정도라면 저작권을 따로 표기하지 않아도 됩니다.

이 표기는 REUSE 표준을 따릅니다. 표기 형식은 공개하기의 저작권 표시와 일치시킵니다.

회사 이메일 사용

기여 시 개인 이메일이 아니라 SK텔레콤 이메일을 사용하세요. 이를 통해 구성원은 회사를 대표해 커뮤니티와 소통한다는 책임감을 갖게 되고, SK텔레콤은 오픈소스 기여 활동을 활발히 하는 기업으로 인지도를 높일 수 있습니다.

2.2 - SK텔레콤 오픈소스 기여 절차

SK텔레콤 기여 Rule에 따라, 구성원은 외부 프로젝트에 기여할 때 다음 절차를 따릅니다. 단, 개요의 의사결정 흐름에서 승인 없이 바로 기여할 수 있는 경우에 해당하면 이 절차를 거치지 않아도 됩니다.

1. 소속 조직 내부 승인

하나의 오픈소스 프로젝트에 기여를 시작하기 전에, 소속 조직의 담당 임원이나 리더에게 승인을 받습니다.

2. 검토 요청

내부 승인을 받은 후 OSRB(opensource@sktelecom.com)에 검토를 요청합니다. 아래 체크리스트의 항목을 모두 채워 요청하면 검토가 빨라집니다.

제출 항목 체크리스트

• 오픈소스 프로젝트 이름
• Repository 주소
• 프로젝트 라이선스
• 기여 목적
• 기여 내용 요약
• 소속 조직 내부 승인 여부
• 프로젝트가 CLA 또는 DCO를 요구하는지 여부

GitHub 이슈 템플릿

사내 이슈 트래커나 GitHub 조직에서 아래 템플릿으로 요청을 접수하면, 빈칸을 채우는 것만으로 제출 항목이 갖춰집니다.

### 오픈소스 기여 검토 요청

- 프로젝트 이름:
- Repository:
- 라이선스:
- 기여 목적:
- 기여 내용 요약:
- 내부 승인(임원/리더):
- CLA/DCO 요구 여부:

처리 예상 소요

검토는 라이선스와 CLA 확인을 포함합니다. 단순 확인은 보통 짧게 끝나고, 추가 확인이 필요하면 더 걸릴 수 있습니다.

OSRB는 프로젝트의 라이선스와 CLA를 검토하고, 이상이 없으면 승인합니다.

3. 승인 후 기여 범위

한 번 승인받은 프로젝트에는 이후 구성원의 재량으로 기여할 수 있습니다. 프로젝트가 바뀌면 다시 검토를 요청합니다.

4. 프로젝트 기여 문서 확인

프로젝트마다 요구하는 절차가 조금씩 다릅니다. 기여 전에 프로젝트의 CONTRIBUTING이나 README를 확인해 다음을 파악합니다.

• 코딩 스타일, 언어, 포매팅, 이슈와 티켓 관리, 릴리스 시기 등의 가이드라인
• CLA 서명 또는 DCO Signed-off-by 요구 여부
• 패치 제출 방식(GitHub Pull Request 또는 메일링 리스트)

5. 기여 제출

기여 Rule에 따라 코드를 다듬은 뒤, 프로젝트가 요구하는 방식으로 기여를 제출합니다.

2.3 - 기여 제출

승인과 준비를 마쳤다면 프로젝트가 요구하는 방식으로 기여를 제출합니다. 아래는 GitHub 기반 프로젝트의 일반적인 절차입니다.

이전 이력 확인

제출하려는 기여가 이전에 다뤄진 적이 있는지 확인하세요. 프로젝트의 README, 이슈, 메일링 리스트에서 몇 가지 키워드를 검색하면 쉽게 확인할 수 있습니다. 관련 내용이 없다면 이슈를 열거나 Pull Request로 커뮤니케이션을 시작하세요.

작업을 시작하기 전에 먼저 이슈를 열어 어떤 작업을 하려는지 알리는 것이 좋습니다. 중복 작업이나 불필요한 작업을 피할 수 있습니다.

이슈 생성

보통 다음 상황에서 이슈를 생성합니다.

• 스스로 해결할 수 없는 오류 보고
• 새로운 기능이나 아이디어 제안
• 커뮤니티 비전이나 정책에 대한 토론

커뮤니케이션 팁은 다음과 같습니다.

• 다루려는 열린 이슈가 있다면 먼저 댓글을 남겨 중복 작업을 막으세요.
• 오래된 이슈는 이미 해결됐을 수 있으니 작업 전에 댓글로 확인하세요.
• 이슈를 연 뒤 스스로 답을 찾았다면, 답을 댓글로 남기고 이슈를 닫으세요. 이런 문서화도 기여입니다.

Pull Request 생성

기여할 파일이 준비됐다면 Pull Request로 제출합니다. 작업을 일찍 공개해 피드백을 받는 것이 좋으며, 진행 중이라면 제목에 “WIP”(Work in Progress)를 표시하고 이후 커밋을 더할 수 있습니다.

GitHub 기반 프로젝트의 Pull Request 절차는 다음과 같습니다.

Fork

Upstream Repository를 자신의 GitHub 계정으로 Fork 합니다.

Clone

Fork한 Repository를 로컬 작업 디렉토리로 Clone 하고, Upstream을 remote에 추가합니다.

$ git clone https://github.com/$user/[repository]
$ cd [repository]
$ git remote add upstream https://github.com/[upstream]/[repository]
$ git remote -v

브랜치 생성

main 브랜치를 최신 상태로 맞춘 뒤 작업용 브랜치를 만듭니다.

$ git fetch upstream
$ git checkout main
$ git rebase upstream/main
$ git checkout -b myfeature

작업과 커밋

코드를 작업하고 커밋합니다. 프로젝트가 DCO를 요구하면 -s 옵션으로 Signed-off-by를 남깁니다.

$ git commit -s -m '[commit message]'

Push

작업한 브랜치를 자신의 Repository에 push 합니다.

$ git push origin myfeature

이미 push한 브랜치를 rebase 등으로 다시 정리해 push해야 하는 드문 경우에만 force 옵션을 쓰되, 공유 브랜치에는 사용하지 않도록 주의하세요.

Pull Request 생성

GitHub의 자신의 Repository에서 Compare & pull request 버튼으로 Pull Request를 생성합니다. 이후 Upstream 관리자가 검토하여 Merge 여부를 결정합니다.

DCO와 CLA

기여물의 출처를 보증하는 방식으로 DCO와 CLA가 있습니다. 프로젝트가 무엇을 요구하는지 미리 확인하세요.

• DCO는 커밋에 Signed-off-by 한 줄을 남기는 경량 방식입니다. git commit -s로 자동 추가됩니다.
• CLA는 별도 약정서에 서명하는 방식입니다. 저작권 양도를 요구하는 CLA는 서명 전에 기여 Rule에 따라 OSRB에 검토를 요청하세요.

피드백 받기

기여를 제출하면 프로젝트로부터 피드백을 받습니다. 피드백은 기여의 수준을 높이는 과정이므로 열린 태도로 받아들이는 것이 좋습니다. 피드백은 보통 다음 넷 중 하나입니다.

응답이 없는 경우

기여 전에 프로젝트가 활발한지 확인하는 것이 좋습니다. 일주일 이상 응답이 없으면 같은 스레드에 정중하게 검토를 요청하세요. 적절한 담당자를 안다면 @-멘션을 쓰세요. 개인적으로 따로 연락하지 말고 공개 채널로 소통하세요. 그래도 반응이 없을 수 있으니, 다른 기여 방법이나 다른 프로젝트를 찾아보세요.

수정을 요청받는 경우

아이디어 설명이나 코드 수정을 요청받는 것은 일반적입니다. 누군가 시간을 내어 검토했으니 바로 응답하세요. 더 진행할 수 없다면 Maintainer에게 알려 다른 사람이 이어받게 하세요.

거절된 경우

기여가 수락되지 않을 수 있습니다. 이유가 이해되지 않으면 설명을 요청하되, 그 결정을 존중하세요. 끝내 이견이 좁혀지지 않으면 Fork 하여 자신의 프로젝트로 이어갈 수 있습니다. 거절을 다음 기여를 개선하는 기회로 삼으세요.

수락된 경우

축하합니다. 오픈소스 기여에 성공했습니다.

참고 자료

• Make a Pull Request
• First Contributions
• Kubernetes GitHub Workflow

2.4 - 오픈소스 기여 배경 지식

이 묶음은 “왜"에 답하는 학습 자료입니다. 실제로 무엇을 해야 하는지를 다루는 행동 페이지(기여 Rule, 기여 절차, 기여 제출)와 분리해 두었습니다.

포함 페이지

• 오픈소스 기여의 혜택: 기여가 기업과 개발자에게 주는 이점
• 기여의 유형: 오픈소스 기여에는 어떤 유형이 있나
• 프로젝트 멤버십: 오픈소스 프로젝트에는 누가 있나
• 주요 문서: 오픈소스 프로젝트에는 어떤 문서가 있나
• 좋은 기여자: 어떻게 좋은 기여자가 될 수 있나
• 좋은 프로젝트: 어떤 프로젝트가 기여할 가치가 있나
• 커뮤니케이션: 오픈소스 커뮤니티에서 소통하는 방법

2.4.1 - 오픈소스 기여의 혜택

기업은 왜 오픈소스에 기여할까

유지 관리 비용 절감

오픈소스를 수정해도 기여하지 않으면, 새 버전이 나올 때마다 자체 수정 사항을 다시 반영하고 테스트하는 노력이 반복됩니다. 기여하면 수정 사항이 향후 버전에 포함되어 추가 유지보수가 줄어듭니다.

프로젝트 방향에 영향

필요한 기능을 직접 개발해 기여하면, 여러 참여자의 손을 거쳐 그 기능이 안정화되고 고도화됩니다.

우수한 개발자 채용

오픈소스에 적극 기여하는 기업은 커뮤니티에서 좋은 평판을 쌓습니다. 우수한 개발자들은 이런 기업에서 일하고 싶어 합니다.

개발자는 왜 오픈소스에 기여할까

• 공공의 이익에 기여할 수 있습니다. 버그 수정이나 기능 추가로 글로벌 커뮤니티에 공헌합니다.
• 실력을 키울 수 있습니다. 버전 관리, Unit Test, Integration Test, CI/CD 같은 실무 기술을 배웁니다.
• 오픈소스를 깊이 이해하고 기술을 습득합니다. 향후 변경에도 유연하게 대응할 수 있습니다.
• 협업을 배웁니다. 다양한 지역과 시간대의 사람들과 일하며 도구 사용법을 익힙니다.
• 새로운 사람을 만납니다. 공통 관심사로 신뢰 관계를 쌓고 경력 발전에 도움을 받습니다.
• 평판과 경력을 키웁니다. 공개된 기여 활동은 누구에게나 보여줄 수 있어 개인의 평판을 높입니다.
• 리더십을 배웁니다. 팀 구성, 갈등 해결, 우선순위 조정을 경험합니다.

2.4.2 - 오픈소스 기여의 유형

오픈소스 프로젝트에는 주로 소프트웨어 개발자들이 소스 코드를 수정해 버그를 고치거나 기능을 개선하는 방식으로 기여합니다. 그러나 개발자만 오픈소스 프로젝트에 기여할 수 있는 것은 아닙니다. 오픈소스 프로젝트에는 다음과 같이 문서화, 디자인 등 다양한 유형의 기여가 필요합니다.

문서 작성 / 번역

• 프로젝트 문서, 튜토리얼을 작성합니다. (예: PyPA’s contributors did)
• 프로젝트의 뉴스레터를 작성하거나 메일링 리스트의 중요 사항을 요약합니다.
• 프로젝트 문서를 자국어로 번역합니다.

테스트 / 이슈 생성

• 소프트웨어가 정상적으로 동작하는지 테스트합니다.
• 문서에 기재된 대로 빌드와 설치가 되는지 테스트합니다.
• 문서와 API가 일관성 있게 작성되었는지 확인합니다.

디자인

• 프로젝트 웹사이트의 레이아웃, 메뉴 등을 개선합니다. (예: Drupal suggest)
• 프로젝트가 일관성 있는 디자인을 가질 수 있도록 스타일 가이드를 만듭니다.
• 새로운 로고나 티셔츠를 만드는 데 기여합니다. (예: hapi.js’s contributors did)

코드 작성 / 리뷰

• 해결할 수 있는 오픈된 이슈를 찾습니다. (예: @dianjin did for Leaflet)
• 새로운 기능을 추가합니다.
• 자동화를 위한 도구와 테스팅을 개선합니다.
• 다른 사람이 제출한 코드를 리뷰합니다.
• 다른 기여자의 멘토가 됩니다. (예: @ereichert did for @bronzdoc on Rust)

마케팅

• SNS, 세미나 발표 등 다양한 방법으로 프로젝트의 목적과 효용성을 홍보합니다.

이벤트 행사

• 프로젝트의 콘퍼런스, 워크숍, 밋업 등 다양한 모임을 기획하고 주관합니다. (예: fzamperin did for NodeSchool)

2.4.3 - 오픈소스 프로젝트 멤버십

오픈소스 프로젝트는 어떻게 공동 작업으로 고품질 소프트웨어 개발을 지속할 수 있을까요? 서로 모르는 여러 사람이 어떻게 코드를 함께 작성하며 안정적인 소프트웨어를 만들어 낼 수 있을까요? 오픈소스 프로젝트는 명확한 역할 구분으로 이를 실현합니다.

리더 (Leader)

모든 프로젝트에는 리더가 있으며, 일반적으로 창시자가 그 역할을 맡습니다. 리더는 프로젝트의 방향을 결정하며, 의사 결정이 필요할 때 최종 결정을 담당합니다. 리더는 개인일 수도 있지만, 규모가 큰 프로젝트는 운영 위원회(Steering Committee)를 조직하여 리더의 역할을 수행합니다.

• 예를 들어 Linus Torvalds는 Linux Kernel의 원저작자로서 진행 상황의 모든 사안에 최종 결정권이 있습니다.
• Node.js 프로젝트는 Technical Steering Committee가 리더의 역할을 수행합니다.

메인테이너 (Maintainer)

메인테이너는 핵심 기여자로서 프로젝트에서 가장 신뢰할 수 있는 기술 역량을 보유한 사람들입니다. 리더로부터 특정 영역을 위임받아 주도적으로 관리하는 역할을 맡습니다.

커미터 (Committer)

커미터는 프로젝트 내 특정 모듈의 코드를 충분히 이해하면서 정기적으로 기여하는 사람들입니다. 기여자의 기여를 리뷰하고 승인할 권한이 있으며, 특정 모듈은 메인테이너의 승인 없이도 Merge 할 수 있습니다.

기여자 (Contributor)

누구든지 간단하게라도 기여한 사실이 있다면 기여자입니다. 기여자는 간단한 버그 수정, 문서화 등의 방법으로 오픈소스 프로젝트에 기여합니다. 이러한 기여는 숙련된 커미터와 메인테이너가 리뷰하고 보완한 후 저장소에 Merge 합니다.

사용자 (User)

사용자는 오픈소스 프로젝트에서 프로젝트의 성패를 좌우하는 역할을 맡습니다. 프로젝트가 아무리 잘 준비되었다고 해도 사용하는 사람이 없다면 프로젝트는 성공할 수 없습니다. 사용자는 프로젝트를 사용하면서 버그 리포트, 새로운 기능 제안 등 아이디어를 제공함으로써 프로젝트에 존재의 목적을 부여합니다.

• 프로젝트의 리더나 기여자들이 사용자의 요청을 신중히 듣지 않으면 장기적으로 건강하게 성장하기 어렵습니다.
• 프로젝트는 사용자의 필요를 충족시키는 방향으로 성장해야 지속할 수 있습니다.

2.4.4 - 오픈소스 프로젝트 주요 문서

올바르게 기여하려면 각 오픈소스 프로젝트의 동작 방식을 이해하고 프로젝트에서 원하는 대로 활동하는 것이 중요합니다. 대부분의 오픈소스 프로젝트는 README, CONTRIBUTING 등의 문서로 이러한 요구 사항을 안내합니다. 오픈소스 프로젝트에는 다음과 같이 공통으로 사용되는 문서가 있으며, 대개 저장소의 최상위 레벨에 있습니다. 기여하기 전에 이러한 문서를 통해 프로젝트의 문화와 행동 강령, 기여 방법을 익혀야 합니다.

README

README 파일은 프로젝트에 처음 접근했을 때 보이는 파일로, 프로젝트 소개와 이 프로젝트를 사용해야 하는 이유, 사용 방법 등을 설명하는 문서입니다. 어떤 프로젝트인지 파악하려면 반드시 봐야 할 문서입니다.

LICENSE (혹은 COPYING)

LICENSE는 프로젝트를 누구나 사용할 수 있다고 명시하는 오픈소스 라이선스를 담은 파일입니다. 모든 오픈소스 프로젝트는 오픈소스 라이선스가 있어야 합니다. 오픈소스 라이선스가 없다면 오픈소스가 아닙니다. 소스 코드는 공개되었지만 사용하거나 배포할 권리가 부여되지 않은 상태입니다. 이런 소스 코드를 제품이나 서비스에 포함하면 저작권 침해 이슈가 발생할 리스크가 있으니 주의해야 합니다.

CONTRIBUTING

README가 프로젝트를 사용하는 사람들을 위한 문서라면, CONTRIBUTING은 프로젝트에 기여하는 사람들을 위한 문서입니다. 어떤 유형의 기여가 필요한지와 기여하는 방법을 설명하므로, 오픈소스에 기여하려 할 때는 이 문서를 자세히 살펴봐야 합니다. 기여자는 이 문서에서 설명하는 기여 방법을 따라야 합니다.

기여하려는 프로젝트에 CONTRIBUTING 파일이 없다면 커뮤니티에 기여 방법을 문의하세요. 적절한 답변을 받지 못한다면, 기여할 가치가 없는 프로젝트로 보고 다른 프로젝트를 찾아도 됩니다.

CODE OF CONDUCT

CODE OF CONDUCT는 행동수칙, 행동강령이라고도 불리며 프로젝트가 건강하게 유지되기 위한 참가자의 행동 규칙을 정의합니다. 예를 들어 성별, 인종, 종교, 나이 등의 차별이 있어서는 안 되고, 누구나 따뜻하게 환영받으며 안전한 활동을 보장받도록 행동해야 함을 강조합니다. 그리고 누군가 그 규칙을 어길 경우 신고할 방법을 안내합니다.

기타 문서

규모가 큰 오픈소스 프로젝트는 튜토리얼, 거버넌스 정책과 같은 문서도 제공합니다.

2.4.5 - 좋은 기여자가 되기 위해

본격적으로 기여 제출을 설명하기 전에 어떻게 하면 좋은 기여자가 될 수 있을지 간단히 살펴봅니다. 물론 프로젝트마다 운영 방식이 다르므로 하나의 정답은 없습니다. 새로운 프로젝트에 참여할 때마다 운영 방식을 익히는 데 시간을 투자해야 합니다. 그렇더라도 다음 사항들은 좋은 기여자가 되는 데 공통으로 도움이 됩니다.

1. 커뮤니티 참여

오픈소스 프로젝트에는 사용자와 개발자들이 모인 커뮤니티가 있습니다. 각 커뮤니티는 참여 방식이 조금씩 다릅니다. 커뮤니티에서 제공하는 문서를 읽고, 메일링 리스트, 포럼, IRC, Slack, Bug tracker 등 주요 커뮤니케이션 채널에 가입하세요.

2. 문화 살펴보기

커뮤니티에 가입한 후에는 기여하기 전에 잠시 커뮤니티의 문화에 익숙해지세요. 지난 커뮤니케이션을 살펴보는 것도 좋은 방법입니다. 이런 과정을 거칠수록 첫 기여가 수락될 가능성이 커집니다.

3. 거버넌스 이해

기여하기 전에 프로젝트 관리와 거버넌스 문서를 통해 프로젝트의 거버넌스 방식을 이해하세요. 누가 어떤 방법으로 결정을 내리는지 알 수 있습니다.

4. 작은 것부터 시작

간단한 버그나 문서 수정으로 시작하세요. 중요도가 크지 않은 작은 기여를 해 보면서 프로세스를 배우고 실수를 수정해 가는 것이 좋습니다. 이러한 경험을 바탕으로 더 크게 기여하면서 점차 프로젝트에 영향을 미칠 수 있습니다.

5. 이벤트 참가

오픈소스 커뮤니티의 다른 참여자와 지속적인 관계를 구축하는 것은 중요합니다. 가장 좋은 방법은 콘퍼런스 등의 이벤트에 참석하는 것입니다. 직접 만나는 것만큼 관계 형성에 좋은 것은 없습니다.

6. 초기 단계부터 자주 기여

어떤 사람은 코드의 양이 상당히 커질 때까지 개발을 마친 다음 한 번에 기여하려 합니다. 이러한 기여는 오픈소스 프로젝트에서 수락되기 쉽지 않습니다. 프로젝트에서 많은 양의 코드를 한꺼번에 리뷰하기도 어렵고, 기여한 코드가 프로젝트가 원하는 방향과 다를 수도 있습니다. 아이디어 단계에서부터 커뮤니티와 논의하고, 개발 초기부터 자주 기여하세요.

2.4.6 - 기여하기에 좋은 프로젝트 확인 방법

물론 업무와 연관이 있거나 기술적인 관심이 있는 분야의 오픈소스 프로젝트에 기여하는 것이 좋습니다. 그런 프로젝트가 여러 개라면, 어떤 프로젝트가 기여할 만한지 따져 보는 것도 필요합니다. 그렇지 않으면 애써 기여하고도 아무 응답을 받지 못한 채 묻혀버릴 수 있습니다.

다음은 관심 있는 오픈소스 프로젝트가 기여 활동에 적합한지 확인하기 위한 체크리스트입니다.

1. 오픈소스 라이선스 파일이 있는가

• LICENSE 파일이 있는가? 일반적으로 저장소의 루트 디렉터리에 LICENSE라는 파일이 있습니다.

오픈소스 라이선스가 적용되지 않은 프로젝트라면 오픈소스가 아닙니다. 소프트웨어의 저작권자가 오픈소스 라이선스를 통해 누구나 사용하고 배포할 수 있는 권리를 부여해야 기업은 그 소프트웨어를 자유롭게 사용할 수 있습니다. 오픈소스 라이선스가 없는 소프트웨어를 임의로 사용하면 저작권 침해 등의 법적 리스크를 유발할 수 있습니다.

2. 프로젝트가 활발히 기여를 받고 있는가

• 가장 최근 Commit은 언제인가?
• 얼마나 많은 기여자가 있는가?
• 얼마나 자주 Commit이 있는가?

기여자가 거의 없거나 최근 수년간 Commit이 없다면 관리가 되지 않는 프로젝트로 볼 수 있습니다.

GitHub에서의 Commit 현황은 화면 상단의 “Commits"에서 확인할 수 있습니다.

3. 프로젝트 이슈 확인

• 얼마나 많은 이슈가 오픈되어 있는가?
• 이슈가 오픈되면 메인테이너는 신속히 대응하는가?
• 이슈에 대한 활발한 토론이 있는가?
• 이슈들은 최근 것인가?
• 이슈들이 Close 되고 있는가?

이슈가 오픈되지 않거나, 오픈되더라도 대응이 되지 않는다면 관리가 되지 않는 프로젝트로 볼 수 있습니다.

GitHub에서 Issues 페이지의 “closed” 탭을 보면 Close 된 이슈 현황을 확인할 수 있습니다.

4. 프로젝트의 Pull Request 확인

• 얼마나 많은 Pull Request가 오픈되어 있는가?
• Pull Request가 오픈되면 메인테이너는 신속히 대응하는가?
• Pull Request에 대한 활발한 토론이 있는가?
• Pull Request들은 최근 것인가?
• 얼마나 최근의 Pull Request들이 머지되었는가?

GitHub에서 Pull Request 페이지의 “closed” 탭을 누르면 Close 된 Pull Request를 볼 수 있습니다.

5. 프로젝트가 기여를 환영하는 분위기인가

• 이슈 관련 질문에 메인테이너가 도움이 되는 답변을 하는가?
• 이슈, 포럼, 채팅(슬랙 등)에서 사람들이 친절한가?
• Pull Request를 하면 Review가 진행되는가?
• 메인테이너가 사람들의 기여에 감사 표시를 하는가?

기여를 환영하지 않는 분위기인 프로젝트는 장기적으로 발전하기 어렵습니다. 이런 부분도 기여할 만한 가치가 있는 프로젝트인지 판단하는 기준이 될 수 있습니다.

2.4.7 - 커뮤니케이션 방법

오픈소스에 기여하는 모든 과정은 커뮤니티 멤버들과의 커뮤니케이션의 연속입니다. 효과적인 커뮤니케이션을 위해 다음 사항을 기억하세요.

정확한 의사 전달

오류 보고라면 어떤 작업에서 발생했는지, 재현 경로는 어떻게 되는지 정확히 설명하세요. 새로운 아이디어 제안이라면 그 아이디어가 프로젝트에 유용하다고 생각하는 이유를 설명하세요.

먼저 스스로 찾아보기

도움을 요청하기 전에 프로젝트의 README 등 문서, 이슈, 메일링 리스트나 검색을 통해 답을 찾아보세요. 이런 노력을 보여주는 것이 좋습니다.

간결한 대화

내가 보낸 모든 기여는 누군가가 검토해야 합니다. 어떤 프로젝트는 검토하기 어려울 정도로 기여나 요청이 많이 쌓입니다. 따라서 가능한 한 간결하게 요청해야 접수될 가능성이 커집니다.

공개 커뮤니케이션

메인테이너에게 개인적으로 연락하는 것은 좋지 않습니다. 모든 대화를 공개하세요. 이를 통해 더 많은 사람이 배우고 혜택을 받을 수 있습니다.

문의 후 기다리기

메인테이너라도 모든 부분을 완벽히 대응할 수 없습니다. 그들에게도 확인할 시간이 필요합니다.

커뮤니티의 결정 존중

여러분의 아이디어가 프로젝트의 우선순위나 비전과 다를 수 있습니다. 커뮤니티에서 그 아이디어를 채택하지 않기로 할 수도 있습니다. 이를 받아들여야 합니다. 타협점을 찾지 못하거나 결코 동의할 수 없다면, Fork 하여 여러분 자신의 프로젝트를 새롭게 시작하는 것을 고려하세요.

품위 유지

오픈소스 프로젝트에서는 전 세계의 구성원과 협업합니다. 언어, 문화, 지역, 시간대에 따라 소통 방법에 온도 차이가 있습니다. 또한 직접 대면해서 대화하는 것이 아니라 글로 의사소통하기 때문에 어조나 분위기를 정확히 전달하기 어려울 수 있습니다. 이런 어려움을 극복하는 좋은 방법은 상대방의 글을 항상 선의로 해석하는 것입니다. 상대의 제안을 거절할 때도 정중히 하고, 자신의 입장은 명확히 표현하는 것이 좋습니다. 오픈소스라는 인터넷 공간에서 자신을 품위 있게 유지하세요.

3 - 오픈소스 공개하기

SK텔레콤은 커뮤니티에 참여할 뿐만 아니라 자사 소프트웨어를 오픈소스로 공개해 커뮤니티와 협업하는 것을 적극 지원합니다. 이 문서는 법적, 윤리적, 기술적 문제를 일으키지 않으면서 오픈소스 협업의 이점을 살리도록 돕습니다.

이 페이지는 공개를 시작하기 전에 “공개해도 되는가, 무엇이 필요한가"를 판단하는 진입점입니다.

한 장 요약

1. 공개할 가치가 있는지 판단합니다(공개 혜택 참고).
2. 소속 조직 내부 승인을 받고 검토를 요청합니다(공개 절차의 A 단계).
3. SK텔레콤 공개 Rule을 지켜 코드를 준비합니다(B 단계).
4. 저장소와 문서 등 프로젝트를 갖추고(C 단계) 공개한 뒤 운영합니다(D 단계).

의사결정 흐름

전체 절차 한눈에 보기

공개 절차는 네 묶음으로 진행합니다.

• A. 공개 승인
• B. 공개 준비
• C. 프로젝트 셋업
• D. 공개와 운영

문의

오픈소스 공개 관련 문의와 요청은 OSRB(opensource@sktelecom.com)로 연락하세요.

3.1 - SK텔레콤 오픈소스 공개 Rule

SK텔레콤은 내부 소프트웨어를 오픈소스로 공개하는 것을 장려합니다. 다만 지식재산을 보호하고 의도치 않은 저작권 침해를 막기 위해 지켜야 할 규칙이 있습니다.

승인 받기

고용 기간에 만든 저작물의 저작권은 고용주가 소유합니다. 구성원이 임의로 공개하면 저작권 침해 이슈가 생길 수 있으므로, 공개 절차에 따라 리뷰 요청과 승인을 받으세요.

공개할 권리가 있는 코드

작성하지 않은 코드는 공개할 권리가 없습니다. 모든 코드의 출처를 확인하고, 법적 문제 소지가 있는 코드는 제거하세요.

지식 재산 노출 주의

민감한 정보나 특허 등 기업의 지식재산이 노출되는 코드와 문서는 공개하지 마세요.

코드 품질

가독성과 성숙도가 갖춰져야 합니다. 수준 이하의 코드는 커뮤니티의 신뢰를 잃게 합니다.

유용한 코드

실제 제품이나 서비스에 쓰는 코드를 공개하세요. 커뮤니티에서 이미 해결한 문제를 다루는 코드라면, 새로 공개하기보다 기존 프로젝트에 기여하는 편이 낫습니다.

리소스 확보

공개와 운영에는 초기 개발자, 외부 기여를 리뷰할 개발자, 법무와 마케팅 지원, 인프라 예산이 필요합니다. 공개 전에 확보 계획을 세우세요.

회사 이메일 사용

개인 이메일이 아니라 SK텔레콤 이메일로 커뮤니티와 소통하세요.

3.2 - SK텔레콤 오픈소스 공개 절차

공개 절차는 네 묶음으로 진행합니다. 먼저 승인을 받고(A), 코드를 준비하고(B), 프로젝트를 갖춘 뒤(C), 공개하고 운영합니다(D).

A. 공개 승인

소속 조직 내부 승인

소프트웨어를 공개하려면 소속 조직의 담당 임원이나 리더에게 승인을 받습니다.

검토 요청

내부 승인을 받은 후 OSRB(opensource@sktelecom.com)에 검토를 요청합니다. 아래 체크리스트를 모두 채워 요청하세요.

• 현재 소스 코드 Repository 링크
• 공개 예정 저장소 링크
• 적용할 오픈소스 라이선스
• 공개로 기대하는 비즈니스 가치
• SK텔레콤 구성원이 작성하지 않은 코드 설명
• 개발팀 담당 임원 승인 여부
• 코드가 쓰인 제품이나 서비스
• 공개 후 지원할 인력 지정 여부
• 공개 준비 완료 여부
• 공개 홍보 방법(블로그, 콘퍼런스 등)
• 관련 특허 여부
• 보안취약점 검토와 보완 여부
• 수출 통제 분류(ECCN) 확인 여부

처리 예상 소요는 검토 범위에 따라 다릅니다.

B. 공개 준비

라이선스 결정

SK텔레콤은 기본적으로 Apache-2.0을 적용합니다. 커뮤니티 관례 라이선스가 있거나 GPL 라이브러리에 종속된 경우 등은 다른 라이선스를 적용할 수 있습니다. 선택 기준은 라이선스 선택을 참고하세요.

3rd party 코드 분리

SK텔레콤이 재배포할 권리가 있는지 확인하고, 외부 라이브러리는 third_party 디렉토리로 분리해 각 디렉토리에 LICENSE 파일을 둡니다.

[Root Directory]
|-- SKT source code
|-- ...
`-- third_party
    |-- [external library A]
    |   |-- LICENSE
    |   `-- ...
    `-- [external library B]
        |-- LICENSE
        `-- ...

저작권과 라이선스 표기

모든 소스 파일에 저작권과 라이선스를 표기합니다. 형식은 REUSE 표준을 따릅니다. 자세한 방법은 저작권 표시를 참고하세요. 프로젝트 루트에는 LICENSE 파일을 포함합니다. Apache-2.0은 공식 사본을, 그 외 라이선스는 SPDX License List에서 받습니다.

민감정보 제거

공개 전에 주석에 남은 작성자 이름과 이메일, 내부 정보(파일 경로, 호스트, IP), 자격증명 같은 시크릿을 제거합니다. 점검 항목과 자동화 방법은 민감정보 제거 체크리스트를 따릅니다.

라이선스 점검과 보안 점검 요청

고지나 소스 공개 의무가 있는 라이선스, 재배포 권리가 없는 3rd party 코드, 라이선스 충돌 여부를 점검합니다. 보안취약점이 있는 오픈소스가 포함됐는지도 확인합니다. 점검은 OSRB에 요청합니다.

수출 통제 분류(ECCN) 확인

암호 기능 등 수출 통제 대상 기술이 포함될 수 있으므로, 공개 전에 수출 통제 분류를 확인합니다. 한국 기업은 대외무역법상 전략물자 판정이 1차 기준이며, 미국산 기술이 포함되면 미국 수출관리규정(EAR)의 ECCN도 함께 확인합니다. 분류와 검토가 필요하면 OSRB를 통해 담당 부서의 확인을 받으세요.

C. 프로젝트 셋업

이름 결정

기억하기 쉽고 프로젝트를 알리는 이름을 정합니다. 상표권 충돌 확인을 포함한 기준은 이름 결정을 참고하세요.

저장소와 인프라

GitHub 또는 GitLab Repository를 권장합니다. SK텔레콤 GitHub 조직(https://github.com/sktelecom)에 멤버 등록이 필요하면 OSRB에 요청합니다. 다음을 갖춥니다.

• 이슈 트래커
• 테스트 자동화: Unit Test, Integration Test, End-to-End Test
• CI/CD: 빌드와 배포까지 포함한 지속적 자동화와 모니터링
• 웹사이트: 사용자 가이드와 홍보용. GitHub Pages 활용을 권장합니다
• 커뮤니케이션 채널: 회사 기밀은 공개 채널에서 논의하지 않습니다

거버넌스와 CODE_OF_CONDUCT

참여 인원의 역할을 명확히 구분합니다. 참가자의 행동 규칙을 정의한 CODE_OF_CONDUCT를 둡니다. 차별 금지, 안전한 활동 보장, 위반 시 신고 방법을 포함합니다. 행동강령은 사실상 표준인 Contributor Covenant를 채택하고, 신고 연락처와 집행 절차를 함께 정합니다.

기여자 라이선스 정책(CLA/DCO) 결정

외부 기여를 받을 계획이라면 기여자 라이선스 정책을 정합니다. 기여물의 저작권과 라이선스 권리를 명확히 하기 위해 CLA(Contributor License Agreement)나 DCO(Developer Certificate of Origin) 중 하나를 채택합니다. DCO는 커밋에 Signed-off-by로 출처와 기여 권리를 증명하는 경량 방식이고, CLA는 별도 약정서로 권한을 정리하는 방식입니다. 저작권 양도를 요구하는 CLA는 회사 정책상 제약이 있으므로, 선택과 운영은 기여 Rule의 CLA 설명과 일관되게 정합니다.

취약점 제보 처리(SECURITY.md)

공개 프로젝트는 외부에서 보안취약점 제보를 받습니다. 제보 경로와 대응 절차를 SECURITY.md에 정의합니다.

# Security Policy

## Reporting a Vulnerability
취약점은 공개 이슈로 올리지 말고 <보안 제보 연락처>로 비공개로 알려 주세요.
접수 후 <대응 기준일> 안에 회신합니다.

## Supported Versions
보안 수정을 제공하는 버전 범위를 적습니다.

GitHub 저장소는 비공개 취약점 제보(Private Vulnerability Reporting)를 켜서 제보 창구로 활용할 수 있습니다. 제보 접수와 회신 기준 시간, 조율된 공개(coordinated disclosure)의 원칙, 수정 후 CVE 발번과 보안 권고(advisory) 게시 절차를 함께 정합니다.

문서화

다음 문서를 갖춥니다.

• README: 무엇을 하는 프로젝트인지, 왜 유용한지, 어떻게 시작하는지, 도움을 어디서 받는지
• 개발 가이드: 빌드 방법, 테스트, 코딩 컨벤션, CI/CD, 릴리스
• CONTRIBUTING: 버그 리포트와 기능 제안 방법, 개발 환경 설정, 원하는 기여 유형, 비전과 로드맵, 관리자 연락처

D. 공개와 운영

공개 전 최종 확인

• 모든 코드와 문서가 Repository에 있는지 확인합니다
• 인프라가 실행 중이고 안전하며 확장 가능한지 확인합니다
• 개발자가 커뮤니케이션 채널에 참여할 수 있는지 확인합니다

공개

https://github.com/sktelecom 에 Public으로 공개합니다.

공개는 되돌리기 어렵습니다. 한 번 공개된 코드는 외부에서 복제되거나 보관될 수 있으므로, 공개 전 점검을 모두 마쳤는지 다시 확인하세요.

마케팅과 커뮤니티 활성화

관련 커뮤니티의 메일링 리스트나 포럼에 알리고, 기술 블로그와 소셜 미디어, 콘퍼런스로 홍보합니다. 프로젝트의 성공은 참여 인원과 기여의 양으로 가늠됩니다. 커뮤니티 구축에는 지속적인 노력이 필요합니다.

공개 후 생명주기 운영

공개로 끝이 아닙니다. 다음을 지속합니다.

• 정기 건강도 점검: 이슈와 PR 응답, 릴리스 주기 유지
• 보안과 버그 수정 지속: 제보된 취약점 대응
• 종료와 아카이빙(EOL): 더 이상 유지하지 않을 때는 상태를 명확히 알리고 저장소를 아카이브합니다

3.2.1 - 오픈소스 프로젝트 이름 결정

기억하기 쉽고 프로젝트를 알리는 이름

기억하기 쉽고, 프로젝트가 무엇을 하는지 알릴 수 있는 이름을 고릅니다. 기존 프로젝트명을 접두사로 활용할 수도 있습니다(예: node-fetch). 다양한 언어권 사용자가 이해하기 쉬운지 고려합니다.

SK텔레콤 브랜드 사용 회피

회사 공식 제품이 아니라면 SK텔레콤 브랜드 사용을 피합니다. “T-” 형태의 이름도 꼭 필요한 경우가 아니면 쓰지 않습니다.

중복 이름 회피

같은 생태계의 기존 프로젝트명과 중복되는지 확인합니다. 도메인과 SNS 계정의 가용성도 미리 살핍니다.

타사 브랜드 미사용

타사 브랜드를 제품명처럼 쓰지 않습니다. 예를 들어 “Java Test Library"보다 “Test Library for Java” 형식이 바람직합니다.

상표권 침해 방지

KIPRIS나 WIPO Global Brand Database에서 상표권 충돌을 확인합니다. 필요하면 IPR팀의 검토를 받습니다.

3.2.2 - 파일 내 저작권 및 라이선스 표시

저작권은 저작물을 만들 때 자동으로 생깁니다. 다른 사용자가 쓰게 하려면 라이선스를 부여해야 합니다. 대부분의 오픈소스 라이선스가 저작권 표시를 요구하므로, SK텔레콤이 공개하는 모든 소스 파일에 저작권 표시와 라이선스 고지를 포함합니다. 표기는 REUSE 표준을 따릅니다.

저작권 표시

소스 파일 상단 헤더에 다음을 포함합니다.

SPDX-FileCopyrightText: Copyright {연도} SK TELECOM CO., LTD.

• {연도}는 최초 작성 연도를 적습니다.
• 연락처나 웹사이트를 덧붙일 수 있습니다(선택). 이 형식은 기여 Rule의 저작권 표기와 동일합니다.

라이선스 고지

SPDX License List에서 라이선스 Identifier를 확인해 파일 상단에 표시합니다.

SPDX-License-Identifier: Apache-2.0

이 형식은 기여 Rule의 저작권 표기와 동일합니다.

자동화 도구

파일이 많을 때는 도구로 일괄 적용합니다. REUSE 표준의 SPDX 태그(SPDX-FileCopyrightText, SPDX-License-Identifier)를 생성하려면 REUSE 도구의 reuse annotate를 사용합니다.

$ reuse annotate --copyright "SK TELECOM CO., LTD." --license Apache-2.0 [filename]

addlicense는 기본적으로 라이선스 헤더 본문을 넣습니다. SPDX 단문 형식이 필요하면 -s 옵션을 사용합니다.

$ addlicense -s -c "SK TELECOM CO., LTD." -l apache [filename]

Java 파일에 일괄 적용하는 예시입니다.

$ find . -type f -name \*.java -exec addlicense -s -c "SK TELECOM CO., LTD." -l apache {} \;

3.2.3 - 민감정보 제거 체크리스트

공개 전에 코드와 커밋 이력에서 민감정보를 제거합니다. 아래 항목을 점검하세요.

점검 목록

• 주석에 남은 작성자 이름과 이메일 제거
• 내부 정보 제거: 파일 경로, 호스트 이름, IP 주소
• 시크릿 제거: 비밀번호, 토큰, API 키, 인증서
• 내부 URL이나 사내 시스템 참조 제거
• 시크릿 스캐닝 도구로 자동 점검 완료
• 커밋 이력에 남은 민감정보 제거 완료

시크릿 스캐닝

수작업만으로는 빠뜨리기 쉽습니다. gitleaks 같은 시크릿 스캐닝 도구로 자동 점검을 수행하고, 가능하면 공개 전 파이프라인에 포함하세요.

$ gitleaks detect --source . --redact

커밋 이력 정리

민감정보가 한 번이라도 커밋됐다면, 현재 파일에서 지워도 이력에는 남습니다. git filter-repo로 이력에서 제거합니다.

$ git filter-repo --invert-paths --path secrets.env

이력 재작성은 모든 커밋 해시를 바꾸므로 기존 클론과 협업 이력에 영향을 줍니다. 공개용으로 새로 만든 저장소에서만 수행하는 것이 안전합니다.

점검에 쓸 검색 예시

특정 키워드가 남아 있는지 빠르게 훑을 때 씁니다.

$ grep -rIn -e "password" -e "token" -e "BEGIN PRIVATE KEY" .

3.2.4 - 라이선스 선택

기본값은 Apache-2.0

SK텔레콤은 기본적으로 Apache-2.0을 적용합니다. 특허 조항을 포함한 permissive 라이선스로, 기업이 공개하는 프로젝트에 무난합니다.

다른 라이선스를 고려하는 경우

• 해당 생태계에서 주로 쓰는 라이선스가 있는 경우. 커뮤니티 관례를 따르면 채택이 쉬워집니다.
• GPL 등 copyleft 라이브러리에 종속된 경우. 의존성의 의무를 따라야 할 수 있습니다.

permissive와 copyleft의 차이

• permissive(예: Apache-2.0, MIT, BSD)는 고지 의무 정도만 요구하고 파생물의 라이선스를 강제하지 않습니다.
• copyleft(예: GPL, LGPL, MPL)는 파생물이나 결합물에 같은 조건의 공개 의무를 요구할 수 있습니다. 의무의 범위는 라이선스마다 다릅니다.

의존성 호환성 확인

선택한 라이선스가 의존성의 라이선스와 충돌하지 않는지 확인합니다. 예를 들어 강한 copyleft 의존성이 있으면 permissive로 공개하기 어려울 수 있습니다. 라이선스별 의무는 가이드의 [사용하기] 라이선스 의무사항 섹션을 참고하고, 판단이 어려우면 OSRB에 검토를 요청하세요.

참고

• choosealicense.com
• SPDX License List

3.3 - 오픈소스 공개 배경 지식

이 묶음은 “왜"에 답하는 학습 자료입니다. 실제로 무엇을 해야 하는지를 다루는 행동 페이지(공개 Rule, 공개 절차)와 분리해 두었습니다.

포함 페이지

• 오픈소스 공개의 혜택: 공개가 기업에 주는 이점

3.3.1 - 오픈소스 공개의 혜택

기업이 소프트웨어를 오픈소스로 공개하는 데에는 다음과 같은 목적이 있습니다.

경제적 이득

오픈소스는 자선 행위가 아닙니다. 기업이 소프트웨어를 공개하거나 기여할 때는 더 높은 투자수익을 기대합니다. 협력은 제로섬 게임이 아니며, 모두가 협력함으로써 투자한 것보다 더 높은 수익을 낼 수 있습니다.

예를 들어 구글은 내부에서 쓰던 Angular를 공개했고, 개발자들이 이를 활용해 많은 확장 도구를 만들었습니다. 구글은 다시 그 생태계의 이득을 누렸습니다.

표준 채택

공개하면 사실상의 표준으로 채택될 가능성이 커집니다. 표준이 되면 외부 기여자가 늘고 생태계가 더 빠르게 진화합니다. GNU와 Linux가 그 예입니다. Linux는 이제 서버와 네트워크 장비, 임베디드 기기에서 사실상의 표준입니다.

생태계 성장

공개하면 다른 사람들이 채택해 자신의 프로그램을 만들고, 그 프로젝트의 성공에 함께 투자합니다. WordPress는 플러그인과 테마 API를 공개해 커뮤니티가 다양한 기능을 제공하는 생태계를 만들었습니다. 구글이 공개한 V8 엔진은 JavaScript 성능을 크게 끌어올려 웹과 Node.js 생태계 전반을 키웠습니다.

우수한 개발자 채용

채용이 주된 목적은 아니지만, 내부에서 널리 쓰이는 소프트웨어를 공개하면 외부 개발자도 그 도구에 익숙해집니다. 기업은 이미 도구를 잘 아는 기여자 중에서 인력을 선택할 수 있고, 교육 부담이 줄어듭니다. 이런 활동으로 커뮤니티에서 명성이 높아지면 인재를 확보하기도 쉬워집니다.

4 - 공급망 보안

소프트웨어 공급망 보안

최근 오픈소스 생태계에서는 라이선스 컴플라이언스와 함께 보안 취약점 관리와 소프트웨어 공급망 보안이 중요한 과제로 부상하였습니다. 미국과 유럽의 규제 강화에 따라 SBOM(Software Bill of Materials) 관리와 체계적인 취약점 대응이 필수가 되었습니다.

SK텔레콤은 소프트웨어 공급망의 투명성과 보안성을 강화하기 위해 체계적인 관리 프로세스를 수립하고, 내부 구성원과 공급사 모두가 준수해야 할 가이드라인을 제공합니다.

가이드 구성

공급망 보안 개요

공급망 보안이 왜 중요한지, 글로벌 규제 동향은 어떠한지, 그리고 SK텔레콤의 공급망 보안 정책을 설명합니다.

SBOM 관리

SBOM이란 무엇이며, 어떻게 생성하고 관리하는지에 대한 내부 구성원 및 공급사 모두를 위한 기술 가이드를 제공합니다.

공급사 가이드

SK텔레콤에 소프트웨어를 납품하는 공급사를 위한 SBOM 제출 요구사항 및 생성 가이드를 제공합니다.

주요 표준 및 규격

• ISO/IEC 18974: OpenChain Security Assurance 규격
• SPDX (ISO/IEC 5962): 소프트웨어 패키지 데이터 교환 표준
• CycloneDX: 보안 중심의 SBOM 표준
• NIST SSDF: 소프트웨어 공급망 보안 프레임워크

관련 규제 동향(미국 EO 14028, EU Cyber Resilience Act 등)은 규제 동향 페이지를 참고하세요.

문의

공급망 보안과 관련하여 문의사항이 있으시면 아래를 참고하세요.

• 공급망 보안 정책 문의: opensource@sktelecom.com
• SBOM 제출: 사업부서 및 보안부서 담당자에게 문의 (제출 절차 참고)

4.1 - 소프트웨어 공급망 공격과 보안 필요성

1. 소프트웨어 공급망 공격이란?

소프트웨어 공급망 공격(Software Supply Chain Attack)은 공격자가 소프트웨어 개발사나 공급업체의 시스템, 또는 개발 과정에 침투하여 악성 코드를 심거나 취약점을 악용하는 사이버 공격 기법입니다.

전통적인 공격이 최종 사용자를 직접 겨냥했다면, 공급망 공격은 신뢰받는 소프트웨어 업데이트나 개발 도구를 오염시켜 이를 사용하는 수많은 하류(Downstream) 기업과 사용자들을 동시에 감염시킵니다.

graph LR
    A[공격자] -->|침투| B[공급업체 빌드 서버]
    B -->|악성코드 주입| C[오염된 소프트웨어 업데이트]
    C -->|배포| D[고객사 A]
    C -->|배포| E[고객사 B]
    C -->|배포| F[고객사 C]
    style B fill:#f9f,stroke:#333,stroke-width:2px
    style C fill:#f96,stroke:#333,stroke-width:2px

2. 주요 공격 사례

최근 몇 년간 발생한 대형 보안 사고들은 공급망 보안의 중요성을 전 세계에 각인시켰습니다.

SolarWinds 사태 (2020)

• 개요: 네트워크 모니터링 솔루션인 SolarWinds Orion의 빌드 시스템이 해킹당해, 정상적인 업데이트 파일에 백도어가 심어졌습니다.
• 피해: 미국 정부 기관, 포춘 500대 기업 등 전 세계 18,000여 개 조직이 피해를 입었습니다.
• 시사점: 신뢰하는 벤더의 정식 서명된 소프트웨어조차 안전하지 않을 수 있음을 보여주었습니다.

Log4j 취약점 (2021)

• 개요: 자바 기반 로깅 라이브러리인 Log4j에서 원격 코드 실행(RCE)이 가능한 치명적인 취약점(Log4Shell)이 발견되었습니다.
• 피해: 이 라이브러리를 직간접적으로 사용하는 전 세계 수억 대의 디바이스와 서버가 위험에 노출되었습니다.
• 시사점: SBOM(Software Bill of Materials)을 통해 우리 시스템이 어떤 오픈소스를 사용하고 있는지 파악하는 것이 얼마나 중요한지 깨닫게 된 계기입니다.

3CX 공급망 공격 (2023)

• 개요: VoIP 소프트웨어 3CX의 데스크톱 앱이 트로이 목마에 감염된 상태로 배포되었습니다.
• 특징: 공격자는 3CX 직원의 PC를 먼저 해킹한 후 개발 환경으로 침투(Lateral Movement)하여 바이너리를 변조했습니다.

3. 왜 공급망 보안인가?

현대 소프트웨어 개발 환경은 복잡하게 얽힌 의존성(Dependency) 위에 구축되어 있습니다.

1. 오픈소스 의존성 증가: 현대 애플리케이션 코드의 70~90%는 오픈소스 컴포넌트로 구성됩니다.
2. 파급력: 하나의 공통 컴포넌트가 오염되면 전 세계적인 피해로 확산됩니다.
3. 탐지의 어려움: 개발 및 빌드 단계에서 오염된 코드는 전통적인 보안 검사(방화벽, 백신 등)를 우회하기 쉽습니다.

이에 따라 SK텔레콤은 공급망의 투명성을 확보하고 리스크를 관리하기 위해 SBOM 도입과 철저한 공급망 보안 정책을 수립하여 시행하고 있습니다.

관련 문서

• 글로벌 규제 동향: 미국 EO 14028, EU CRA 등 주요 규제 현황
• SK텔레콤 공급망 보안 정책: SK텔레콤의 구체적인 요구사항
• 공급사 가이드: 공급사를 위한 SBOM 생성 및 제출 안내

4.1.1 - 규제 동향

1. 미국: 행정명령 14028 (EO 14028)

2021년 5월, 바이든 행정부는 ‘국가의 사이버 보안 개선에 관한 행정명령(Executive Order 14028)‘을 발표했습니다. 이는 SolarWinds 사태 이후 공급망 보안을 국가 안보 차원에서 다루기 시작한 결정적 계기입니다.

핵심 내용

• SBOM 요구 추진: EO 14028은 SBOM의 최소 요소 정의와 안전한 소프트웨어 개발 관행을 지시했고, 연방 납품 기업의 SBOM 제출과 자기증명 의무는 후속 OMB 지침으로 구체화됐습니다.
• NIST 가이드라인 준수: NIST(미국 국립표준기술연구소)가 정의한 ‘보안 소프트웨어 개발 프레임워크(SSDF)‘를 준수해야 합니다.
• 최소 기준 제시: 미 행정부는 SBOM의 최소 요소(데이터 필드, 자동화 지원 등)를 정의하여 표준화를 주도했습니다.

2. 유럽연합(EU): 사이버 복원력 법안 (CRA)

EU는 Cyber Resilience Act (CRA)를 통해 디지털 제품의 전체 생명주기에 걸친 보안 요구사항을 법제화했습니다.

핵심 내용

• CE 마크 인증: 디지털 요소가 포함된 모든 제품은 사이버 보안 요구사항을 충족하고 CE 마크를 부착해야만 EU 내에서 판매할 수 있습니다.
• 보안 지원 기간 명시: 제조사는 제품의 예상 사용 기간 동안 보안 업데이트를 제공해야 하며, 그 기간은 원칙적으로 5년 이상입니다. 예상 사용 기간이 5년보다 짧으면 그 기간에 맞춥니다(Regulation (EU) 2024/2847 제13조, Recital 60). 즉 5년은 상한이 아니라 기준선입니다.
• 취약점 신고 의무: 적극적으로 악용되는(actively exploited) 취약점이나 심각한 보안 사고를 인지하면, 24시간 이내에 조정자로 지정된 CSIRT와 ENISA에 조기경보를 제출하고, 이후 72시간 이내 후속 신고와 최종 보고서를 제출해야 합니다(Regulation (EU) 2024/2847 제14조).
• SBOM 관리: 제조사는 제품의 소프트웨어 구성요소를 식별하고 문서화(SBOM)해야 합니다.

3. 한국: SW 공급망 보안 가이드라인

대한민국 정부(과학기술정보통신부, KISA, 국가정보원)도 글로벌 흐름에 발맞춰 ‘SW 공급망 보안 가이드라인’을 발표하고 실증 사업을 추진하고 있습니다.

주요 내용 (v1.0 기준)

• SBOM 도입 권고: 공공 및 민간 분야에서 SW 개발 및 납품 시 SBOM을 생성하고 활용할 것을 권고합니다.
• 역할별 보안 활동 정의:
  • 공급사(개발사): 안전한 개발 환경 구축, SBOM 생성 및 제공, 보안 취약점 점검.
  • 수요사(운영사): 납품받은 SW의 SBOM 요구 및 검증, 지속적인 취약점 모니터링.

SK텔레콤의 대응

SK텔레콤은 이러한 국내외 규제 흐름에 선제적으로 대응하기 위해 자체적인 공급망 보안 정책을 수립하였으며, 모든 협력사에 대해 글로벌 표준(SPDX, CycloneDX)에 부합하는 SBOM 제출을 의무화하고 있습니다.

관련 문서

• 공급망 보안 개요 : 소프트웨어 공급망 공격의 개념과 주요 사례
• SK텔레콤 공급망 보안 정책: SK텔레콤이 공급사에 요구하는 구체적인 정책
• 공급사 가이드: 공급사를 위한 SBOM 생성 및 제출 안내

4.1.2 - SK텔레콤 공급망 보안 정책

---

NOTICE.

본 문서는 사내 보안 및 문서 관리 정책에 따라 대외비 내용을 제외한 요약본입니다. 전체 내용이 아닌 개략적인 핵심 사항 위주로 작성되었음을 참고해 주시기 바랍니다.

---

1. 정책 목적

본 정책은 SK텔레콤이 도입하는 모든 소프트웨어의 투명성을 확보하고, 알려진 취약점(Known Vulnerabilities) 및 라이선스 위반 리스크를 사전에 식별하여 제거하는 것을 목적으로 합니다.

2. 적용 대상

SK텔레콤과 소프트웨어 공급 계약을 체결하는 모든 공급사는 본 정책의 적용을 받습니다.

3. 주요 요구사항

공급사는 다음 3가지 원칙을 준수해야 합니다.

원칙 1: SBOM 제출 의무화

• 모든 소프트웨어 납품 시, 해당 버전에 부합하는 SBOM(Software Bill of Materials)을 제출해야 합니다.
• 허용 포맷: CycloneDX (v1.3 이상) 또는 SPDX (v2.2 이상)
• 필수 포함 정보: 공급사명, 컴포넌트명, 버전, 의존성 관계, Package URL (PURL)

원칙 2: 취약점 점검 및 조치

• 공급사는 납품 전 자체적으로 최신 보안 취약점(CVE)을 점검해야 합니다.
• Critical/High 등급의 취약점이 발견된 경우, 이를 패치하거나 완화 조치를 적용한 후 납품해야 합니다.
• 패치가 불가능한 경우, ‘취약점 소명서’를 통해 해당 취약점이 실제 서비스에 영향을 주지 않음을 증명해야 합니다.

원칙 3: 투명한 변경 관리

• 계약 기간 중 소프트웨어의 구성 요소가 변경(업데이트, 패치 등)되는 경우, 갱신된 SBOM을 즉시 제출해야 합니다.
• 오픈소스 라이선스 의무 사항(고지 의무, 소스코드 공개 의무 등)을 준수했음을 보증해야 합니다.

관련 문서

• 공급망 보안 개요 : 소프트웨어 공급망 공격의 개념과 주요 사례
• 글로벌 규제 동향: SBOM 관련 국내외 규제 현황
• 공급사 가이드: SBOM 생성 및 제출 방법 상세 안내
• 제출 요구사항: SBOM 포맷 및 필수 데이터 필드 정의

4.2 - SBOM 이란?

개요

이 섹션은 기업 구성원을 위한 SBOM(Software Bill of Materials) 실무 가이드입니다. 단순히 정책을 준수하는 것을 넘어, SBOM을 활용하여 프로젝트의 보안성을 높이고 의존성 관리의 효율성을 높이는 방법을 다룹니다.

가이드 구성

본 가이드는 SBOM의 도입부터 운영까지 단계별로 구성되어 있습니다.

1. 개념 및 필요성: SBOM이 무엇이며, 왜 지금 우리에게 필요한지 근본적인 이유를 설명합니다.
2. 표준 비교 (SPDX vs CycloneDX): 업계 표준 포맷의 차이점을 이해하고, 프로젝트 성격에 맞는 포맷을 선택할 수 있습니다.
3. 프로젝트 SBOM 생성: 개발 중인 프로젝트에서 직접 SBOM을 추출하는 실무적인 방법을 안내합니다.
4. CI/CD 통합: Jenkins, GitHub Actions 등 CI/CD 파이프라인에 SBOM 생성을 자동화하는 방법을 다룹니다.
5. SBOM 관리: 생성된 SBOM을 중앙 저장소에 저장하고 버전별로 관리하는 전략을 소개합니다.

graph TD
    A[개발 시작] --> B[의존성 추가]
    B --> C{빌드/배포}
    C -->|자동화| D[SBOM 생성]
    D --> E[저장소 업로드]
    E --> F[취약점 분석]
    F --> G[보안 조치]

SBOM 생성

상세한 SBOM 생성 방법과 기술적 가이드는 다음 문서를 참고하시기 바랍니다.

• 공급사 가이드 (For Suppliers)
• SBOM 생성 방법

4.2.1 - SBOM 개념 및 필요성

SBOM의 정의

SBOM (Software Bill of Materials)은 소프트웨어를 구성하는 모든 컴포넌트, 라이브러리, 모듈 등의 목록과 그들 간의 의존성 관계를 기술한 정형화된 명세서입니다. 제조업에서 제품의 부품 목록을 관리하는 BOM(Bill of Materials) 개념을 소프트웨어 공학에 적용한 것입니다.

graph TD
    A[소프트웨어 제품] --> B[직접 의존성]
    B --> C[라이브러리 A v1.2.3]
    B --> D[라이브러리 B v2.0.1]
    B --> E[라이브러리 C v3.1.0]
    C --> F[전이적 의존성]
    F --> G[라이브러리 D v1.0.0]
    F --> H[라이브러리 E v2.5.0]
    D --> F

SBOM의 주요 구성 요소

컴포넌트 정보

각 소프트웨어 컴포넌트에 대한 기본 정보를 포함합니다.

• 이름(Name): 컴포넌트의 공식 명칭
• 버전(Version): 정확한 버전 번호
• 공급자(Supplier): 컴포넌트를 제공한 조직 또는 개인
• 라이선스(License): 적용되는 오픈소스 라이선스

고유 식별자

컴포넌트를 명확히 식별하기 위한 표준화된 식별자를 사용합니다.

Package URL (purl)

가장 일반적으로 사용되는 식별자 형식입니다.

pkg:maven/org.springframework/spring-core@5.3.20
pkg:npm/express@4.18.2
pkg:pypi/django@4.1.0

CPE (Common Platform Enumeration)

보안 취약점 데이터베이스와 연동하기 위해 사용됩니다.

cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*

의존성 관계

컴포넌트 간의 의존성 관계를 명시합니다.

• 직접 의존성(Direct Dependencies): 프로젝트가 직접 사용하는 라이브러리
• 전이적 의존성(Transitive Dependencies): 직접 의존성이 다시 의존하는 라이브러리

메타데이터

SBOM 자체에 대한 정보를 포함합니다.

• 생성 도구: SBOM을 생성한 도구의 이름과 버전
• 생성 시각: SBOM이 생성된 날짜와 시간
• 생성자: SBOM을 생성한 조직 또는 개인

왜 필요한가?

SBOM은 단순한 문서가 아니라 소프트웨어 투명성을 위한 핵심 데이터입니다.

1. 보안 취약점의 신속한 식별

새로운 취약점(예: Log4j 사태)이 발표되었을 때, 우리 서비스 중 어디에 해당 라이브러리가 쓰이고 있는지 즉시 파악할 수 있습니다. SBOM이 없다면 모든 서버와 코드를 일일이 전수 조사해야 하며, 대응 골든타임을 놓치게 됩니다.

2. 라이선스 리스크 관리

오픈소스 라이선스 위반은 법적 분쟁으로 이어질 수 있습니다. SBOM을 통해 프로젝트에 포함된 모든 라이선스를 식별하고, 호환되지 않는 라이선스(예: GPL과 상용 코드의 결합) 사용을 사전에 차단할 수 있습니다.

3. 소프트웨어 품질 및 노후화 관리

오래되고 지원이 중단된(EOL, End-of-Life) 컴포넌트를 식별하여 기술 부채를 관리하고 소프트웨어의 건전성을 유지할 수 있습니다.

4. 규제 준수

미국 연방 정부를 비롯한 다양한 조직에서 SBOM 제출을 의무화하고 있습니다.

• 미국 행정명령 14028 (연방 정부 공급사)
• EU Cyber Resilience Act
• 의료기기 FDA 승인

관련 문서

• SBOM 표준 비교 (SPDX vs CycloneDX)
• 공급사 가이드: SBOM 생성 및 제출 방법

참고 자료

• NTIA SBOM Minimum Elements
• CISA SBOM Sharing Lifecycle
• Linux Foundation: SBOM Guide

4.2.2 - SBOM 표준

주요 SBOM 표준

현재 시장을 양분하고 있는 두 가지 주요 표준 형식이 있습니다. 두 형식 모두 널리 사용되지만, 탄생 배경과 주력 분야에 차이가 있습니다.

• SPDX: Software Package Data Exchange
• CycloneDX: OWASP 주관의 보안 중심 SBOM 표준

SPDX (Software Package Data Exchange)

개요

SPDX는 Linux Foundation이 주관하는 오픈소스 프로젝트로, 소프트웨어 패키지의 라이선스 및 저작권 정보를 표준화된 방식으로 표현하기 위해 개발되었습니다. (ISO/IEC 5962:2021)

주요 특징

1. SPDX는 원래 오픈소스 라이선스 정보 교환을 위해 개발되어, 라이선스 관련 정보를 상세하게 표현합니다.

• 표준화된 라이선스 식별자 (SPDX License List)
• 라이선스 표현식 (예: Apache-2.0 OR MIT)
• 저작권 정보 및 파일별 라이선스

2. 패키지뿐만 아니라 개별 파일 레벨의 정보도 포함할 수 있습니다.

• 파일별 해시값
• 파일별 라이선스
• 파일별 저작권 정보

SPDX 문서 구조

{
  "SPDXID": "SPDXRef-DOCUMENT",
  "spdxVersion": "SPDX-2.3",
  "name": "Example-SBOM",
  "documentNamespace": "https://example.com/sbom-2023-001",
  "creationInfo": {
    "created": "2023-01-15T10:30:00Z",
    "creators": ["Tool: SPDX-Tools-2.3"]
  },
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-1",
      "name": "spring-core",
      "versionInfo": "5.3.20",
      "licenseDeclared": "Apache-2.0",
      "externalRefs": [
        {
          "referenceType": "purl",
          "referenceLocator": "pkg:maven/org.springframework/spring-core@5.3.20"
        }
      ]
    }
  ]
}

장점

• ISO 국제 표준으로 공식 인정
• 라이선스 정보가 상세함
• 파일 레벨까지 추적 가능
• 성숙한 도구 생태계

단점

• 보안 취약점 정보가 선택사항
• 구조가 다소 복잡
• 보안 중심 프로젝트에는 부족할 수 있음

CycloneDX

개요

CycloneDX는 OWASP(Open Web Application Security Project)에서 개발한 SBOM 표준으로, 애플리케이션 보안에 중점을 둡니다.

주요 특징

1. 처음부터 보안 취약점 관리를 위해 설계되었습니다.

• 취약점 정보 (Vulnerabilities)
• 보안 분석 결과 (Security Analysis)
• 위협 정보 (Threats)

2. SPDX에 비해 구조가 간결하고 이해하기 쉽습니다.

• 필수 정보에 집중
• JSON, XML 형식 지원
• 작은 파일 크기

3. 다양한 사용 사례를 지원하는 확장 기능을 제공합니다.

• SaaS BOM
• Hardware BOM
• AI/ML BOM
• Cryptography BOM

CycloneDX 문서 구조

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2023-01-15T10:30:00Z",
    "tools": [
      {
        "name": "cyclonedx-maven-plugin",
        "version": "2.7.9"
      }
    ],
    "component": {
      "type": "application",
      "name": "MyApp",
      "version": "1.0.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "spring-core",
      "version": "5.3.20",
      "purl": "pkg:maven/org.springframework/spring-core@5.3.20",
      "licenses": [
        {
          "license": {
            "id": "Apache-2.0"
          }
        }
      ]
    }
  ]
}

장점

• 보안 취약점 정보 기본 포함
• 구조가 간결하고 이해하기 쉬움
• 보안 도구와의 통합이 우수
• 활발한 커뮤니티 및 도구 개발

단점

• ISO 표준은 아니지만 ECMA International의 ECMA-424로 표준화됨
• 파일 레벨 정보는 제한적
• 라이선스 표현이 SPDX보다 단순

SPDX vs CycloneDX 비교

선택 가이드

CycloneDX 선택이 적합한 경우

다음과 같은 경우 CycloneDX를 권장합니다.

• 보안이 최우선: 취약점 관리가 주요 목적
• 빠른 시작: 간결한 구조로 빠르게 도입
• DevSecOps: CI/CD에 통합하여 자동화
• 현대적인 애플리케이션: 클라우드, 컨테이너 환경

SPDX 선택이 적합한 경우

다음과 같은 경우 SPDX를 권장합니다.

• 라이선스 컴플라이언스 중시: 상세한 라이선스 정보 필요
• 파일 레벨 추적: 소스코드 파일별 정보 필요
• ISO 표준 준수: 공식 표준 인증 필요
• 레거시 시스템: 기존 SPDX 도구 사용 중

SK텔레콤 권장사항

SK텔레콤의 내부 프로젝트는 CycloneDX (JSON) 형식을 기본 권장합니다. 이는 내부 취약점 관리 시스템과의 연동성이 CycloneDX가 더 우수하기 때문입니다. 단, 외부 파트너사가 SPDX를 제출하는 경우에도 호환성을 지원합니다.

상호 변환

SPDX와 CycloneDX 간 변환 도구가 제공됩니다.

SPDX에서 CycloneDX로 변환

# cyclonedx-cli 사용
cyclonedx convert --input-file sbom.spdx.json \
  --output-file sbom.cdx.json --input-format spdx \
  --output-format json

CycloneDX에서 SPDX로 변환

# spdx-tools 사용
java -jar tools-java-1.1.0-jar-with-dependencies.jar \
  Convert bom.cdx.json bom.spdx.json

관련 문서

• SBOM이란?: SBOM의 개념과 필요성
• 공급사 제출 요구사항: SK텔레콤이 허용하는 포맷 및 버전

참고 자료

• SPDX Specification
• CycloneDX Specification
• NTIA SBOM Formats Comparison

4.3 - 공급사 SBOM 제출 가이드

SK텔레콤은 소프트웨어 공급망의 투명성과 보안성을 강화하기 위해, 공급사로부터 납품받는 모든 소프트웨어 구성 요소 및 의존성에 대한 SBOM(Software Bill of Materials) 제출을 요청드리고 있습니다. 본 가이드는 공급사가 SK텔레콤의 보안 정책에 맞는 형식으로 SBOM을 생성하고 제출하는 방법을 안내합니다.

적용 대상

다음 형태의 소프트웨어를 납품하는 모든 공급사(개발사, 리셀러 포함)는 본 가이드라인의 적용을 받습니다.

• 소스코드: Java, Python, JavaScript, Go, C/C++ 등으로 작성된 애플리케이션
• 컨테이너 이미지: Docker 이미지 또는 OCI 호환 컨테이너
• 실행 파일: 컴파일된 바이너리(.jar, .dll, .so) 및 라이브러리
• 임베디드 시스템: 펌웨어 이미지, RootFS, 디바이스 드라이버
• 서버: OS(rootfs와 설치 패키지) 위에 애플리케이션과 정적 링크 라이브러리가 결합된 시스템

SBOM 제출 프로세스

공급사는 계약 시점부터 최종 납품까지 아래의 절차에 따라 진행하시기 바랍니다.

flowchart TD
    A[계약 검토] --> B["소프트웨어 개발/빌드"]
    B --> C{SBOM 생성}
    C -->|SKT 제공 도구 활용| D[BomLens 활용]
    C -->|자체 도구 활용| E["오픈소스 도구 활용<br>(cdxgen, Syft 등)"]
    D --> F["데이터 검증 (PURL 확인)"]
    E --> F
    F --> G["SBOM 제출 (이메일/포털)"]
    G --> H[SKT 보안성 검토]
    H -->|승인| I[납품 완료]
    H -->|반려| J[보완 및 재제출]
    J --> F

가이드 구성

본 섹션은 다음과 같이 구성되어 있습니다.

1. 제출 요구사항: SK텔레콤이 요구하는 필수 포맷(CycloneDX, SPDX)과 데이터 필드를 정의합니다.
2. BomLens: SK텔레콤이 제공하는 SBOM 생성 도구 사용법을 안내합니다.
3. 오픈소스 도구 활용: 범용 오픈소스 도구(cdxgen, Syft 등)를 활용한 생성 방법을 안내합니다.
4. 서버 SBOM 생성: OS·애플리케이션·정적 링크 세 층으로 나눠 생성하고 하나로 합치는 방법을 안내합니다.
5. 검증 체크리스트: 제출 전 반드시 확인해야 할 필수 항목 점검표를 제공합니다.
6. 제출 절차: 생성된 SBOM 파일의 명명 규칙과 제출 채널을 안내합니다.

관련 문서

• SK텔레콤 공급망 보안 정책: SBOM 제출 의무화 정책 배경 및 원칙
• 글로벌 규제 동향: SBOM 관련 국내외 규제 현황

4.3.1 - SBOM 제출 요구사항

1. 표준 데이터 형식

SK텔레콤은 글로벌 표준으로 자리 잡은 두 가지 형식을 모두 지원합니다. 공급사는 사용하는 도구가 지원하는 형식을 선택하여 제출할 수 있습니다.

참고: 두 형식 모두 동등하게 인정되나, 내부 시스템 연동성을 위해 CycloneDX (JSON) 형식을 권장합니다.

2. 필수 포함 정보

제출하는 SBOM 문서에는 다음 정보가 반드시 포함되어야 합니다. 정보가 누락되면 반려될 수 있습니다.

2.1 메타데이터 (Metadata)

문서 자체와 생성 도구에 대한 정보입니다.

• Timestamp: 생성 일시 (ISO 8601 형식)
• Tool Info: 생성 도구의 벤더, 이름, 버전 (예: CycloneDX-Maven-Plugin v2.7.9)
• Component Info: 납품하는 최상위 소프트웨어의 명칭 및 버전

생성 도구 명시 형식

생성 도구 정보는 형식에 따라 다음 필드에 기재해야 합니다.

• SPDX: creationInfo.creators 필드에 Tool: 접두어로 도구명과 버전 기재
• CycloneDX: metadata.tools 배열에 vendor, name, version 기재

// SPDX creationInfo 예시
"creationInfo": {
  "created": "2026-04-06T03:22:00Z",
  "creators": ["Tool: Syft-0.98.0", "Organization: VendorName"]
}

2.2 컴포넌트 정보 (Components)

소프트웨어를 구성하는 개별 라이브러리 정보입니다.

• Name: 컴포넌트 이름 (예: commons-lang3)
• Version: 컴포넌트 버전 (예: 3.12.0) — 필수: 버전 없이는 취약점 매핑 불가
• PURL (Package URL): [필수] 패키지 식별자

버전 정보는 반드시 포함해야 합니다. 각 패키지(package/component)는 SPDX의 versionInfo 또는 CycloneDX의 version 필드에 정확한 버전을 기재해야 합니다. 버전이 없으면 취약점 데이터베이스와의 매핑이 불가능하여 보안 분석을 수행할 수 없습니다.

2.3 의존성 범위 (Dependency Scope)

중요: 전이적 의존성(Transitive Dependencies)을 반드시 포함해야 합니다.

SK텔레콤은 제출된 SBOM을 기반으로 취약점을 분석합니다. 직접 의존성만 포함된 SBOM은 숨겨진 취약점을 놓칠 수 있으므로 반려될 수 있습니다.

전이적 의존성이란?

예를 들어 프로젝트가 library-A를 직접 사용하고, library-A가 내부적으로 library-B를 사용하는 경우, library-B가 전이적 의존성입니다. library-B에 취약점이 있어도 SBOM에 포함되지 않으면 탐지할 수 없습니다.

MyApp
  └─ library-A v1.0 (직접 의존성)  ← 공급사가 명시적으로 선언
       └─ library-B v2.3 (전이적 의존성)  ← SBOM에 반드시 포함되어야 함
            └─ library-C v0.9 (전이적 의존성)  ← SBOM에 반드시 포함되어야 함

올바른 SBOM 생성을 위한 전제 조건

전이적 의존성이 정확하게 포함되려면 빌드(또는 패키지 설치)가 완료된 상태에서 SBOM을 생성해야 합니다. 소스코드만 있는 상태에서는 전이적 의존성이 누락될 수 있습니다.

• Java (Maven): mvn package 또는 mvn dependency:resolve 실행 후 생성
• Java (Gradle): ./gradlew dependencies 실행 후 생성
• Python: pip install -r requirements.txt (가상환경 활성화) 후 생성
• Node.js: npm install 또는 yarn install 실행 후 생성
• Go: go mod download 실행 후 생성

각 도구별 전이적 의존성 포함 방법은 오픈소스 도구 활용 가이드를 참고하시기 바랍니다.

3. Package URL (PURL) 준수

PURL(Package URL)은 소프트웨어 패키지를 고유하게 식별하기 위한 표준 URL 형식입니다. SK텔레콤의 취약점 분석 시스템은 PURL을 기준으로 동작하므로, 모든 컴포넌트에 유효한 PURL이 포함되어야 합니다.

PURL은 반드시 pkg: 접두어로 시작하는 표준 형식이어야 합니다. name:version, org/repo:tag 등 자유 텍스트는 허용되지 않으며, 이 경우 취약점 매핑이 불가능해 반려됩니다.

언어별 PURL 예시

purl 타입 제한

purl은 생태계를 특정할 수 있는 타입이어야 합니다.

올바른 / 잘못된 PURL 예시

PURL에 대한 자세한 사양은 Package URL 공식 스펙을 참고하시기 바랍니다.

4. 샘플 문서

CycloneDX 샘플

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "version": 1,
  "metadata": {
    "timestamp": "2023-10-15T10:30:00Z",
    "tools": [{
      "vendor": "Example Corp",
      "name": "cyclonedx-maven-plugin",
      "version": "2.7.9"
    }],
    "component": {
      "type": "application",
      "name": "PaymentModule",
      "version": "2.1.0",
      "purl": "pkg:maven/com.example/payment-module@2.1.0"
    }
  },
  "components": [{
    "type": "library",
    "name": "spring-core",
    "version": "5.3.20",
    "purl": "pkg:maven/org.springframework/spring-core@5.3.20",
    "licenses": [{
      "license": {
        "id": "Apache-2.0"
      }
    }]
  }]
}
...

참고 자료

• CycloneDX Specification
• SPDX Specification
• Package URL Specification

관련 문서

• 공급사 가이드 홈
• BomLens: SK텔레콤이 제공하는 SBOM 생성 도구
• 오픈소스 도구 활용: cdxgen, Syft 등 오픈소스 도구 안내
• 검증 체크리스트: 제출 전 확인 사항
• 제출 절차: 제출 방법 및 이메일 양식

4.3.2 - BomLens

BomLens

BomLens는 공급사가 Docker 환경에서 SK텔레콤 정책에 맞는 산출물을 생성할 수 있는 오픈소스 도구입니다. 로컬에 언어별 도구를 따로 설치하지 않아도 여러 언어를 분석해 CycloneDX(JSON) 산출물을 만듭니다.

이 페이지는 빠른 시작만 다룹니다. 설치, 전체 옵션, 언어별 가이드, 입력 시나리오, 웹 UI 등 자세한 내용은 공식 저장소 문서를 참고하세요.

github.com/sktelecom/sbom-tools

버그 제보, 기능 제안, Pull Request 기여를 환영합니다.

생성되는 산출물

한 번의 실행으로 다음 세 가지가 함께 생성됩니다(--all 옵션).

사전 준비

BomLens는 Docker 위에서 동작합니다. Docker 엔진 20.10 이상을 설치하고 실행해 두세요. Docker가 없는 Windows에서는 무료인 Rancher Desktop을 권장합니다. 첫 실행 때 스캐너 이미지(약 3–4GB)를 내려받느라 5–15분쯤 걸립니다.

Windows에서 명령줄 없이 시작

명령줄이 익숙하지 않다면 두 가지 방법 중 하나로 SBOM을 생성할 수 있습니다. 자세한 절차는 명령줄 없이 시작하기를 참고하세요.

• 실행 파일: 최신 릴리스에서 SBOM-Generator-*.exe(BomLens 실행 파일)를 내려받아 더블클릭합니다. 이 파일은 아직 코드 서명이 되어 있지 않아 Windows SmartScreen 경고가 나타나면 “추가 정보"를 누른 뒤 “실행"을 선택합니다.
• 저장소 ZIP: 저장소의 Code 버튼에서 Download ZIP을 받아 압축을 풀고 scripts\sbom-ui.bat를 더블클릭하면 브라우저에서 http://localhost:8080이 열립니다.

웹 UI에서는 오른쪽에 진행 로그가 실시간으로 표시되고, 완료되면 산출물을 내려받을 수 있습니다.

빠른 시작 (CLI)

macOS와 Linux에서는 셸에서 스크립트를 내려받아 실행합니다.

curl -O https://raw.githubusercontent.com/sktelecom/sbom-tools/main/scripts/scan-sbom.sh
chmod +x scan-sbom.sh
cd /path/to/my-project
/path/to/scan-sbom.sh --project "MyApp" --version "1.0.0" --all --generate-only

• --generate-only는 포털 업로드 없이 로컬에 파일만 생성합니다(제출 전까지 권장).
• 웹 UI로 쓰려면 ./scan-sbom.sh --ui를 실행합니다(브라우저에서 http://localhost:8080).
• Windows에서 명령줄을 쓸 때는 같은 명령을 scripts\scan-sbom.bat로 실행합니다(Git Bash를 거치므로 Git for Windows 필요).
• GitHub URL, 소스 ZIP, Docker 이미지, 펌웨어, 바이너리 등 다른 입력 형태와 전체 옵션은 CLI 레퍼런스를 참고하세요.

더 알아보기

도구 사용법의 정본은 저장소 문서입니다.

다음 단계

SBOM을 생성한 뒤 검증 체크리스트로 파일을 확인하고 제출 절차에 따라 제출합니다. 필수 데이터 필드는 제출 요구사항, SKT 도구 대신 cdxgen, Syft 등을 직접 쓰는 방법은 오픈소스 도구 활용을 참고하세요.

4.3.3 - 오픈소스 도구를 활용한 SBOM 생성

SKT 제공 도구를 사용할 수 없거나, 이미 자체적인 빌드 파이프라인을 보유한 경우 오픈소스 도구를 직접 활용할 수 있습니다. 아래는 SK텔레콤이 검증한 주요 오픈소스 도구 목록과 공식 사용법 링크입니다.

도구 환경 구축에 익숙하지 않은 경우, Docker가 설치되어 있다면 BomLens를 먼저 검토해 보시기 바랍니다.

도구 선택 가이드

graph TD
    A[분석 대상 확인] --> S{OS와 앱이 결합된 서버인가?}
    S -- Yes --> T[층별로 나눠 생성<br>서버 SBOM 생성 가이드 참고]
    S -- No --> B{소스코드인가?}
    B -- Yes --> C[cdxgen 권장]
    B -- No --> D{Docker 이미지인가?}
    D -- Yes --> E[Syft 또는 Trivy 권장]
    D -- No --> F[바이너리/펌웨어]
    F --> G[Syft 권장]

서버처럼 OS와 애플리케이션이 결합된 경우는 한 번의 스캔으로 끝나지 않습니다. 층별로 나눠 생성하는 전체 절차는 서버 SBOM 생성을 참고하세요.

주요 도구 안내

cdxgen (소스코드 분석 권장)

Java, Python, Node.js, Go 등 다양한 언어 프로젝트를 자동 분석하여 CycloneDX 형식의 SBOM을 생성합니다.

• 공식 문서: https://cdxgen.github.io/cdxgen
• GitHub: https://github.com/CycloneDX/cdxgen
• 지원 언어: Java (Maven/Gradle), Python, Node.js, Go, Ruby, PHP, Rust, .NET, C/C++ 등

cdxgen은 lockfile이나 매니페스트를 정적으로 해석합니다. 정확한 결과를 얻으려면 의존성이 설치되거나 해결된 상태(lockfile이 있거나 빌드한 뒤)에서 실행하시기 바랍니다. 의존성이 해결되지 않은 순수 소스만 스캔하면 일부 컴포넌트나 purl이 누락될 수 있습니다.

Syft (컨테이너 이미지 및 바이너리 분석 권장)

빌드된 컨테이너 이미지나 패키지 매니저 메타데이터가 포함된 빌드 산출물을 분석하여 OS 패키지와 애플리케이션 라이브러리를 모두 식별합니다. CycloneDX 및 SPDX 형식을 지원합니다.

• 공식 문서: https://github.com/anchore/syft
• 권장 분석 대상: 빌드된 Docker 이미지, OCI 이미지, tar 파일

# 권장: 빌드된 이미지 스캔 (purl과 생태계를 자동 식별)
syft <이미지명>:<태그> -o cyclonedx-json=sbom.json

# 비권장: 설치 디렉터리나 원시 파일 스캔 (purl 누락으로 반려)
syft dir:/root/nag_pkg   # 패키지 매니저 메타데이터가 없으면 purl이 0개가 됩니다

CentOS 등 OS 위에 애플리케이션을 올려 납품하는 서버는 OS(rootfs/이미지)와 애플리케이션 두 층으로 나눠 생성하고, 정적 링크 라이브러리는 별도로 보강한 뒤 하나로 합칩니다. OS 층은 위 경고대로 패키지 데이터베이스가 있는 rootfs나 이미지를 대상으로 해야 합니다. 전체 절차는 서버 SBOM 생성을 참고하세요.

Trivy (컨테이너 이미지 분석)

컨테이너 이미지 분석과 취약점 스캔을 함께 수행할 수 있는 올인원 도구입니다.

• 공식 문서: https://aquasecurity.github.io/trivy/
• GitHub: https://github.com/aquasecurity/trivy

언어별 전용 플러그인

빌드 도구 플러그인을 사용하면 더 정확한 의존성 정보를 추출할 수 있습니다.

전이적 의존성 포함 확인

SK텔레콤 제출 SBOM은 전이적 의존성(Transitive Dependencies)을 반드시 포함해야 합니다.

전이적 의존성이란 프로젝트가 직접 선언하지 않았지만, 사용하는 라이브러리가 내부적으로 의존하는 라이브러리를 말합니다. 이 항목이 누락되면 숨겨진 취약점을 탐지할 수 없어 SBOM이 반려될 수 있습니다.

핵심 원칙: 빌드(패키지 설치) 완료 후 SBOM을 생성해야 합니다.

소스코드만 있는 상태에서는 전이적 의존성이 누락될 수 있습니다. 아래 표를 참고하여 SBOM 생성 전에 선행 작업을 완료하시기 바랍니다.

도구별 전이적 의존성 지원 현황

권장: Docker 이미지로 납품하는 경우, 빌드된 이미지를 Syft로 스캔하면 소스코드 분석보다 더 완전한 전이적 의존성을 포함할 수 있습니다.

공통 주의사항

도구를 사용하기 전 아래 사항을 확인하시기 바랍니다.

• 전이적 의존성 포함 여부: 위 표를 참고하여 SBOM 생성 전 선행 작업을 완료합니다. 의존성 누락은 반려 사유가 됩니다.
• PURL 포함 여부: 생성된 SBOM에 모든 컴포넌트의 purl 필드가 포함되어 있는지 확인합니다. SK텔레콤 시스템은 PURL을 기반으로 취약점을 매핑합니다. 제출 전 jq '[.components[] | select(.purl)] | length' sbom.json으로 purl 보유 컴포넌트 수를 세어 전체 컴포넌트 수와 일치하는지 확인하고, 0이거나 현저히 적으면 검증 체크리스트의 절차에 따라 재생성하시기 바랍니다.
• 출력 포맷: CycloneDX JSON 형식을 권장합니다. (-o cyclonedx-json 또는 동등한 옵션 사용)
• 프로젝트 정보: 메타데이터에 납품 프로젝트의 이름과 버전이 정확히 기입되었는지 확인합니다.

관련 문서

• 서버 SBOM 생성: OS·애플리케이션·정적 링크가 결합된 서버를 층별로 생성하고 합치는 방법
• 제출 요구사항: SBOM에 포함되어야 할 필수 데이터 필드
• 검증 체크리스트: 제출 전 확인 사항
• BomLens: SK텔레콤이 제공하는 SBOM 생성 도구

4.3.4 - 서버(OS + 애플리케이션) SBOM 생성

납품 서버는 단일 소스 트리가 아닙니다. 운영체제가 있고, 그 위에 설치된 애플리케이션이 있으며, 빌드 과정에서 바이너리에 정적 링크된 라이브러리가 있습니다. 이 중 하나만 스캔하면 나머지가 빠지고, 이것이 서버 SBOM이 반려되는 흔한 원인입니다.

서버는 두 층(OS와 애플리케이션)으로 보고 각 층을 따로 생성한 뒤 하나로 합칩니다. 두 층 모두 BomLens로 만들 수 있고, 층마다 입력만 바꾸면 됩니다. 여기에 더해, 정적 링크된 라이브러리는 두 층의 스캔이 모두 놓치는 사각지대라 별도로 다룹니다.

서버를 이루는 두 층

여기에 더해, 정적 링크된 라이브러리(빌드 시 바이너리에 포함된 openssl·liblfds 등)는 패키지 매니저가 선언하지 않고 OS 패키지 데이터베이스에도 올라 있지 않아 두 층의 스캔이 모두 놓치는 사각지대입니다. 별도로 탐지·기재해야 하며, 이를 빠뜨리는 것이 가장 흔한 반려 원인입니다.

층별 생성

아래 명령은 BomLens의 실행 스크립트 scan-sbom.sh를 사용합니다. BomLens 설치와 기본 사용법(스크립트 내려받기, 옵션, 웹 UI 등)은 BomLens를 먼저 참고하세요. cdxgen·Syft를 직접 쓰려면 오픈소스 도구 활용을 참고합니다.

OS 층

서버의 rootfs(추출한 루트 파일시스템)나 그 컨테이너 이미지를 스캔합니다. 패키지 데이터베이스(rpm/dpkg/apk)를 읽어 설치된 패키지를 모두 실제 purl(pkg:rpm/...)로 식별합니다.

# rootfs 디렉터리를 대상으로
scan-sbom.sh --project myserver-os --version 7 --target /path/to/server-rootfs --all --generate-only

# 서버가 컨테이너 이미지로 패키징돼 있다면
scan-sbom.sh --project myserver-os --version 7 --target myserver:7 --all --generate-only

대상에는 패키지 데이터베이스가 있어야 합니다. 설치 파일만 풀어 놓고 rpm 데이터베이스가 없는 폴더를 스캔하면 purl이 비어 반려됩니다.

애플리케이션 층

빌드를 마친 뒤 애플리케이션 소스를 스캔합니다. 패키지 매니저(Maven·npm·pip·Go modules·Conan 등)를 쓰면 전이 의존성까지 자동으로 해석됩니다.

cd /path/to/app-source
scan-sbom.sh --project myserver-app --version 2.0.0 --all --generate-only

매니페스트가 없는 순수 CMake/Make 애플리케이션은 컴포넌트 목록이 희소해지므로 --deep-license로 자체 소스의 라이선스를 보강합니다.

정적 링크 라이브러리 (사각지대)

소스 스캐너는 바이너리에 정적 링크된 라이브러리를 보지 못하고, OS 패키지 데이터베이스에도 올라 있지 않습니다. 이것이 두 층이 남기는 사각지대입니다. 완전 자동 경로가 없으므로 두 가지를 함께 씁니다. 도구가 찾을 수 있는 만큼은 납품 바이너리를 분석하고, 그래도 빠지는 부분은 빌드 스크립트에서 소스와 버전(예: openssl 1.1.1za)을 직접 기재합니다.

scan-sbom.sh --project myserver-bin --version 2.0.0 --target /path/to/delivered-binary --all --generate-only

정적 링크 구성요소의 정밀 식별은 바이너리 구성 분석(BDBA)의 몫이며, SK텔레콤이 보완 검증으로 수행합니다.

하나로 합쳐 제출

SK텔레콤 제출 시스템은 제품당 SBOM 하나를 등록합니다. 따라서 층별 SBOM을 --merge로 합쳐 단일 BOM으로 제출하고, 최상위 컴포넌트를 납품 제품명·버전으로 기재합니다. --merge는 purl 기준으로 중복을 제거하므로 둘 이상의 층에 나타나는 라이브러리는 한 번만 집계됩니다.

scan-sbom.sh --project myserver --version 1.0.0 \
  --merge myserver-os_7_bom.json myserver-app_2.0.0_bom.json myserver-bin_2.0.0_bom.json \
  --generate-only

서버 전체를 하나의 컨테이너 이미지로 납품한다면, 그 이미지를 --target으로 한 번에 스캔해 OS와 애플리케이션 층을 동시에 담을 수도 있습니다.

제출 전 검증

층별 SBOM과 병합본 모두에 대해 컴포넌트가 실제 purl을 갖는지 확인합니다. 전체 컴포넌트 수와 purl 보유 수가 비슷해야 합니다.

jq '.components | length' myserver_1.0.0_bom.json
jq '[.components[] | select(.purl)] | length' myserver_1.0.0_bom.json

차이가 크면 purl 없는 컴포넌트가 많다는 뜻이고, 보통 원시 디렉터리 스캔이 원인입니다. 자세한 점검은 검증 체크리스트를 따르십시오.

더 알아보기

서버 납품 SBOM의 상세 절차와 예시는 BomLens 저장소의 정본 문서에 있습니다.

서버 납품 가이드

관련 문서

• BomLens: SK텔레콤이 제공하는 SBOM 생성 도구
• 오픈소스 도구 활용: cdxgen·Syft 직접 사용
• 제출 요구사항: 필수 데이터 필드
• 검증 체크리스트: 제출 전 확인 사항

4.3.5 - SBOM 제출 전 검증 체크리스트

필수 점검 항목

아래 체크리스트를 통과하지 못한 SBOM은 시스템에서 자동으로 반려될 수 있습니다.

1. 파일 무결성

• 파일 확장자가 .json 또는 .xml 인가? (압축 파일 아님)
• 파일 크기가 1KB 이상이며, 내용이 비어있지 않은가?
• JSON 문법 오류가 없는가? (jq 등으로 확인 권장)

2. 필수 데이터 필드

• bomFormat: CycloneDX 또는 SPDX가 명시되었는가?
• Metadata: 최상위 컴포넌트(납품 프로젝트)의 이름과 버전이 정확한가?
• Components: 포함된 라이브러리 목록이 실제와 일치하는가?

3. 의존성 완전성 확인

전이적 의존성 누락은 가장 흔한 반려 사유입니다. 아래 항목을 반드시 확인하시기 바랍니다.

• 직접 의존성(프로젝트가 직접 선언한 라이브러리)이 모두 포함되어 있는가?
• 전이적 의존성(직접 의존성이 내부적으로 사용하는 라이브러리)이 포함되어 있는가?
• SBOM 생성 전 빌드(또는 패키지 설치)를 완료하였는가? (예: npm install, mvn package, pip install)
• 컴포넌트 수가 합리적인가? (직접 의존성만 몇 개인 프로젝트에서 총 컴포넌트 수가 10개 미만이라면 전이적 의존성이 누락되었을 가능성이 높음)

의존성 수 기준 가이드: 일반적인 웹 애플리케이션은 전이적 의존성까지 포함하면 수십~수백 개의 컴포넌트가 포함됩니다. SBOM의 컴포넌트 수가 예상보다 현저히 적다면 누락을 의심해 보시기 바랍니다.

4. 식별자 (PURL) 확인

SK텔레콤 시스템은 PURL로 취약점을 매핑합니다. 가장 중요한 항목입니다.

• 모든 컴포넌트(components) 객체 안에 purl 필드가 존재하는가?
• purl 보유 컴포넌트 수가 전체 컴포넌트 수와 일치(또는 근접)하는가?
• PURL 형식이 표준(pkg:type/namespace/name@version)을 따르는가?
• PURL 내에 특수문자 등이 올바르게 인코딩되었는가?

아래 명령으로 purl 개수를 직접 확인하시기 바랍니다. 전체 컴포넌트 수와 purl 보유 수가 같아야 합니다.

# CycloneDX — 두 값이 같아야 한다
jq '.components | length' sbom.json                      # 전체 컴포넌트 수
jq '[.components[] | select(.purl)] | length' sbom.json  # purl 보유 수

# SPDX — purl(externalRef) 보유 패키지 수
jq '[.packages[] | select(.externalRefs[]?.referenceType == "purl")] | length' sbom.json

purl 보유 수가 0이거나 전체 컴포넌트 수보다 현저히 적으면 제출하지 마십시오. 이는 패키지 매니저 메타데이터가 없는 설치 디렉터리나 원시 파일을 스캔했을 때 주로 발생합니다. 스캔 대상을 빌드된 이미지나 패키지 매니저 컨텍스트가 있는 위치로 바꾸거나 도구를 바꿔 재생성하시기 바랍니다. 자세한 내용은 SBOM 생성 방법을 참고하십시오.

온라인 검증 도구

• CycloneDX Validator: https://cyclonedx.github.io/cyclonedx-web-tool/validate

관련 문서

• 제출 요구사항: 필수 데이터 필드 및 PURL 형식 상세 안내
• 제출 절차: 체크리스트 통과 후 제출 방법
• BomLens: 체크리스트 항목을 충족하는 SBOM을 생성하는 도구

4.3.6 - SBOM 제출 절차

1. 제출 시기

• 소프트웨어 계약 체결 후 초기 납품 시
• 소프트웨어의 주요 버전(Major/Minor) 업데이트 시
• 계약서에 명시된 정기 제출 일정 도래 시

2. 제출 방법

SBOM 파일은 SK텔레콤 사업부서 및 보안부서 담당자에게 이메일 혹은 지정된 시스템을 통해 제출합니다.

제출 방법

• 사업부서 및 보안부서 담당자에게 이메일 또는 담당자가 지정한 채널로 SBOM 파일을 전달합니다.
• 이메일 제목: [SBOM 제출] 공급사명_프로젝트명_버전
• 첨부파일: 생성된 SBOM 파일 (비밀번호 걸린 압축 파일 금지)

본문 필수 기재 사항:

1. 납품 계약 번호
2. 담당자 정보 (성명, 부서, 연락처)
3. 프로젝트 정보 (시스템명, 상세 버전)
4. 사용 도구 (예: BomLens v1.0)

사업부서 담당자의 TOSCA 등록 의무

공급사로부터 SBOM을 접수한 SK텔레콤 사업부서 담당자는 사내 오픈소스 & SBOM 관리 시스템인 TOSCA에 해당 SBOM을 등록해야 합니다.

TOSCA (SK텔레콤 오픈소스 & SBOM 관리 시스템) https://tosca.sktelecom.com

• TOSCA는 SK텔레콤 내부 시스템으로, 사내 임직원만 접근 가능합니다.
• [SKT 구성원용] 공급사 SBOM 등록 및 리포트 출력 가이드: https://confluence.tde.sktelecom.com/x/bYNULw

3. 제출 후 검증 및 조치

제출된 SBOM은 TOSCA에 등록된 후 아래 절차에 따라 검증됩니다.

검증 결과와 조치 요청 사항은 사업부서 담당자를 통해 공급사 및 보안부서 담당자에게 통보됩니다.

관련 문서

• 검증 체크리스트: 제출 전 반드시 확인할 필수 항목
• 제출 요구사항: SBOM 포맷 및 필수 데이터 필드
• 공급사 가이드 홈: 전체 프로세스 흐름도 확인

5 - 오픈소스 교육 슬라이드

기업 내 개발자 대상 오픈소스 교육 자료입니다.
라이선스 컴플라이언스, 오픈소스 기여·공개, SBOM 및 소프트웨어 공급망 보안을 다룹니다.

전체 화면으로 보기

슬라이드 구성

슬라이드 원본(Marp Markdown): slides/oss-education.md