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: 오픈소스 기여의 혜택
• 2.2: SK텔레콤 오픈소스 기여 Rule
• 2.3: SK텔레콤 오픈소스 기여 절차
• 2.3.1: 기여 제출 세부 절차
• 2.4: 오픈소스 기여 배경 정보
• 2.4.1: 오픈소스 기여의 유형
• 2.4.2: 오픈소스 프로젝트 멤버십
• 2.4.3: 오픈소스 프로젝트 주요 문서
• 2.4.4: 좋은 기여자가 되기 위해
• 2.4.5: 기여하기에 좋은 프로젝트 확인 방법
• 2.4.6: 커뮤니케이션 방법
• 3: 오픈소스 공개하기
• 3.1: 오픈소스 공개의 혜택
• 3.2: SK텔레콤 오픈소스 공개 Rule
• 3.3: SK텔레콤 오픈소스 공개 절차
• 3.3.1: 오픈소스 프로젝트 이름 결정
• 3.3.2: 파일 내 저작권 및 라이선스 표시

1 - 오픈소스 사용하기

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

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

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

필요한 기능을 구현하기 위해 오픈소스를 사용하기로 했다면 유사한 기능을 제공하는 여러 오픈소스 프로젝트 중 어느 오픈소스를 선택하는게 좋을까? 여러 측면의 고려해야 할 포인트를 알아보자.

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

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

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

오픈소스 라이선스란?

오픈소스를 올바르게 사용하기 위해서는 먼저 저작권 및 오픈소스 라이선스에 대해 이해해야 한다.

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

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

• 오픈소스 라이선스 란?

라이선스 확인하기

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

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

라이선스 별 의무 사항

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

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

라이선스 의무 준수 활동

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

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

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

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

자가 점검

CVE 확인

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

GitHub 확인

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

보안취약점 진단 요청

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

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

SK텔레콤 오픈소스 정책

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

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

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

필요한 기능을 구현하기 위해 오픈소스를 사용하기로 했다면 유사한 기능을 제공하는 여러 오픈소스 프로젝트 중 어느 오픈소스를 선택하는게 좋을까? 여러 측면의 고려해야 할 포인트를 알아보자.

품질

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

커뮤니티

오픈소스가 얼마나 많은 사용자를 보유하고 있는지, Issue 관리는 이루어지고 있는지, 지속적으로 업데이트를 하는지 등 커뮤니티 활성화 여부도 오픈소스 선택 시 고려해야 할 사항이다. 커뮤니티 활동이 수년전에 정지된 오픈소스보다는 현재에도 활발히 활동하는 커뮤니티를 보유한 오픈소스를 선택하는게 유리함은 당연한다.

문서화

오픈소스를 적절히 도입하고 유지보수하기 위해서는 프로젝트가 얼마나 문서를 충실하게 제공하는지도 확인해야 할 포인트다. 문서화가 잘 된 프로젝트의 산출물은 기업이 도입하는데 수월하다. 또 기업이 개선한 패치를 다시 프로젝트에 기여하는 것도 가능하게 한다.

보안 취약점

오픈소스 보안 취약점이 알려진 오픈소스는 사용해서는 안된다. 보안 취약점이 발견된 오픈소스의 버전은 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 라이선스들은 이용자들이 소프트웨어를 수정한 후 배포하고자 할 때 수정된 소프트웨어도 동일한 License로 배포할 것을 요구한다.

예) 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

Trivy

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

trivy fs --scanners license .

자동화 도구에 대한 상세한 사용법은 자동화 섹션을 참고하시기 바랍니다.

라이선스 정보 우선순위

만약 방법 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"의 요구사항을 준수하는 것은 쉽지 않기 때문에 사용을 제한합니다.

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

• Support (opensource@sktelecom.com)

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

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

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

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

• 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가 추천
판단: 사용 방식에 따라 다름, OSPO 검토

모델 카드 의무

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일 릴리스 → 2028년 1월 1일 Change Date

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만)
→ 7억 미만 → 자유롭게 사용 가능

시나리오 2: Facebook (MAU 30억)
→ 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. 고위험 분야 (단독 의사결정)

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

Meta에서 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-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텔레콤은 구성원이 패치 제공 등의 방법으로 외부 오픈소스 프로젝트에 기여하는 것을 적극 권장한다. 버그를 찾았거나, 코드를 개선했다면 오픈소스 프로젝트에 다시 기여하라. 이는 개인 뿐만 아니라 기업에게도 혜택을 기대할 수 있기 때문이다.

• 오픈소스 기여의 혜택

다만, 몇 가지 염두해야 할 사항이 있다. 흔한 경우는 아니지만 오픈소스 프로젝트와 커뮤니티에 대한 이해와 전략 없이 뛰어들면 실망감만 안겨줄 수 있다. 특히, 커뮤니티에서 기업의 명성이 떨어질 뿐만 아니라 법적 위험이 발생할 수도 있다. ‌이 가이드는 이러한 법적 문제가 발생하지 않고 오픈소스 커뮤니티와의 효과적인 협업을 안내하기 위해 작성되었으며, SK텔레콤 구성원이 오픈소스 프로젝트에 기여하기 전에 따라야 할 몇 가지 요구 사항과 올바른 기여 방법을 설명한다.

알아두면 좋은 오픈소스 기여 지식

먼저 오픈소스 기여와 관련하여 도움이 될 만한 사항들을 안내한다. (이미 일반적인 오픈소스 기여에 익숙하다면 이 내용은 스킵해도 좋다.)

• 오픈소스 기여의 유형
• 오픈소스 프로젝트 멤버십
• 오픈소스 프로젝트 주요 문서
• 좋은 기여자가 되기 위해
• 기여하기에 좋은 프로젝트 확인 방법
• 커뮤니케이션 방법

SK텔레콤 오픈소스 기여 Rule

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

• 오픈소스 기여 Rule

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

SK텔레콤의 오픈소스 기여 규칙에 따라 구성원은 외부 오픈소스 프로젝트에 기여할 때 다음과 같은 기여 절차를 따른다.

• 오픈소스 기여 절차

2.1 - 오픈소스 기여의 혜택

오늘날 소프트웨어를 개발하는 기업이라면 당연하게 오픈소스를 사용한다. 그리고 또 많은 기업은 오픈소스를 사용하는 것에 그치지 않고 다시 오픈소스 커뮤니티에 기여한다. 왜 오픈소스에 다시 기여하려고 할까? 오픈소스 프로젝트에 기여하는 것을 권장하는 기업은 다음과 같은 효과를 기대하기 때문이다.

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

기업이 오픈소스에 기여하는 목적과 이익은 무엇인가? 기업은 왜 구성원의 오픈소스 기여 활동을 장려해야 하나? 기업의 비즈니스 관점에서도 오픈소스에 기여해야 하는 이유는 다음과 같다.

1. 유지 관리 비용을 절감할 수 있다.

기업은 오픈소스를 사용하여 제품을 만들면서 버그를 수정하거나 새로운 기능을 추가한다. 그런데 이를 다시 오픈소스 프로젝트로 기여하지 않는다면 어떻게 될까? ‌

오픈소스 프로젝트는 중요한 보안 패치 등 새로운 버전을 계속해서 릴리즈할 텐데, 그때마다 기업은 새로운 버전을 적용하기 전에 자체적으로 수정한 사항을 다시 새로운 버전에 반영한 후, 기능은 이상 없이 동작하는지, 성능에는 영향이 없는지 매번 테스트해야 하는 노력이 필요하다. 이러한 수고가 반복된다면 이에 투입해야 하는 인력과 시간 등의 관리 비용은 악몽과도 같이 크게 증가할 것이다. 만약 수정 사항을 오픈소스 프로젝트에 기여했다면 향후 새로운 버전이 릴리즈될 때 수정 사항이 이미 포함되어 있기 때문에 추가로 유지 관리해야 할 필요가 없게 된다.

따라서 오픈소스를 사용하는 기업은 기여의 중요성을 개발자들에게 교육해야 한다. 물론, 오픈소스 프로젝트에 기여하는 것은 적지 않은 수고와 시간이 들어갈 수 있다. 개발자들은 타이트한 개발 일정 때문에 패치를 만들어도 당장 제품에만 적용하려고 하지, 이를 오픈소스 프로젝트에 기여하지 않으려고 할 수 있다. 그러나 패치를 기여하지 않으면 신규 버전의 오픈소스가 새롭게 릴리즈될 때마다 개발자는 자기가 만든 패치를 재적용해야 한다는 점을 재차 강조하는 바이다. 이러한 작업이 반복될수록 더 많은 시간과 노력을 쏟는 악순환이 된다.

2. 오픈소스 프로젝트의 방향에 영향을 미칠 수 있다.

기업이 제품 개발에 중요하게 사용하는 오픈소스 프로젝트에서 기업에 꼭 필요한 기능을 추가해주기를 바라는가? 그렇다면 그 오픈소스 프로젝트에 바라는 기능을 제안하고, 경우에 따라서는 일부분을 직접 개발하고 기여하는 등, 활발히 활동할 것을 권한다. 기업에서 이렇게 기여한 이후에는 여러 사람의 참여를 통해 해당 기능을 안정화하고 고도화하여 결과적으로는 기업이 원하는 방향으로 성장하게 된다.

3. 우수한 개발자를 고용할 수 있다.

우수한 오픈소스 개발자를 찾을 수 있는 가장 좋은 장소는 바로 오픈소스 커뮤니티이다. 오픈소스에 적극적으로 기여하는 기업은 오픈소스 커뮤니티에서 좋은 평판을 쌓게 된다. 오픈소스 커뮤니티의 우수한 개발자는 오픈소스에 적극적으로 기여하는 기업이 어디인지 알고 있고, 그런 기업에서 일하고 싶어 한다. 오픈소스 기여 활동을 전혀 하지 않는 기업이 우수한 오픈소스 개발자를 채용하기는 쉽지 않다.

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

1. 공공의 이익에 기여할 수 있다

사용 중인 오픈소스의 버그를 직접 수정하거나 새로운 기능을 추가하면 소프트웨어가 개선될 뿐만 아니라 이 소프트웨어를 사용하는 모두에게 이익을 제공하게 된다. 작은 기여로 글로벌 커뮤니티에 공헌하는 것이다.

2. 실력을 키울 수 있다

오픈소스에 기여하는 활동을 통해 새로운 기술을 배울 수 있다. 그뿐만 아니라 반복적인 연습과 훈련을 통해 역량을 향상할 수 있다. 버전 관리, Unit Test, Integration Test, CI/CD 등은 오픈소스 프로젝트 개발에서 탄생하여 지금은 거의 모든 소프트웨어 개발 시 사용되고 있는 개발방법론이다. 이들을 오픈소스 프로젝트에서 배울 수 있다. 더구나, 오픈소스 프로젝트는 회사 업무와는 달리 오픈소스 프로젝트에서는 초보자의 실수에 비교적 관대하여 본인의 의지만 확고하다면 기술 역량을 향상할 수 있는 최고의 공간이다. 오픈소스 프로젝트에서는 코딩뿐만 아니라 UI, 그래픽 디자인, 문서 작성 등의 실무를 배울 수 있다.

3. 오픈소스를 깊은 수준에서 이해하고 기술을 습득할 수 있다.

단순히 오픈소스를 사용하는 수준을 넘어 오픈소스 기여를 위해 이슈를 이해하고, 문제를 해결하게 되면 보다 더 깊은 수준으로 오픈소스 기술을 습득하게 된다. 이러한 활동은 오픈소스의 향후 변경 사항을 쉽게 식별하여 유연하게 대응할 수 있게 하며, 오픈소스 활용을 더 확장해나갈 수도 있다.

4. 협업을 배울 수 있다

오픈소스 커뮤니티는 전 세계의 다양한 지역, 다른 시간대의 사람들이 모여 있는 공간이다. 이러한 제약 가운데 공통 과제를 수행하기 위해서는 고도의 협업 능력이 필요하다. 오픈소스 프로젝트에서는 분업, 위험관리를 고려한 진정한 협업이 이뤄진다. 이와 더불어 협업을 가능하게 하는 여러 도구에도 익숙해질 수 있다. 이슈 트래커, 버전 관리 시스템, 메일링리스트와 같은 도구가 대표적이다.

5. 새로운 사람을 만날 수 있다

오픈소스에는 커뮤니티가 있다. 공통 관심사가 있는 사람들이 참여하고 만남으로써 관계를 만들어 갈 수 있다. 어떤 사람을 만나느냐가 경력의 방향에 큰 영향을 미칠 수 있다. 신뢰할 수 있는 관계가 되고 나면 서로 새로운 업무나 직장으로 이끌어줄 수 있다. 오픈소스 커뮤니티에서는 항상 전문적으로 협업하면서 서로 업무 스타일과 인성을 깊이 있게 파악할 수 있어서 가능한 일이다. 이처럼 오픈소스 프로젝트에 기여하면서 형성된 관계야말로 왜 기여해야 하는지를 설명하는 분명한 답변 중 하나이다.

6. 평판과 경력을 키울 수 있다

오픈소스 작업은 모두에게 공개된다. 오픈소스에서 수행한 작업은 어디에서나 누구에게든 보여줄 수 있으며, 이는 개인의 평판을 높이는 데 큰 도움이 된다.

7. 리더쉽을 배울 수 있다

오픈소스에서는 팀 구성, 갈등 해결 및 우선순위 조정과 같은 리더십과 관리 기술을 배울 수 있다. 오픈소스 프로젝트에서 공동 작업을 하려면 누군가에게 업무 수행 방식을 설명해야 하고, 다른 사람들에게 도움을 요청해야 할 일이 있다. 이렇게 배우고 가르치는 일을 통해 리더쉽을 경험하고, 성취감을 맛보게 된다.

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

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

승인을 받아라

오픈소스 기여는 저작권 관점에서 저작자가 저작물을 수정/사용/배포할 수 있는 권한을 오픈소스 프로젝트에 부여하는 것이다. 때에 따라서는 오픈소스 프로젝트에 여러분의 저작권을 양도해야 하기도 한다. 그런데 일반적으로 고용 기간에 만든 저작물의 저작권은 고용주가 소유한다. 즉, SK텔레콤 구성원이 만든 저작물은 SK텔레콤이 소유한다. 구성원이 임의로 저작물을 오픈소스에 기여하는 행위는 불필요한 저작권 침해 이슈를 유발시킬 수 있다.

따라서, 기여하고자 하는 오픈소스 프로젝트가 있다면 SK텔레콤 오픈소스 기여 정책에 따라 최초 기여하기 전에 리뷰 요청 및 승인 절차를 따른다.

• 오픈소스 기여 절차

기여할 권리가 있는 코드만 기여하라

기여할 권리가 있는 코드만 기여하라. 즉, 직접 작성한 코드를 기여하라. 3rd party의 코드를 여러분이 임의로 기여해서는 안된다.

지식 재산 노출에 주의하라

민감한 정보, 특허 등 기업의 지식재산 노출이 우려되는 코드, 문서 기여하지 마라.

기여하려는 코드에 회사의 특허가 포함되어 있다면, 이 특허를 오픈소스 라이선스로 프로젝트에 기여해도 되는지 확인하라. 모호한 부분이 있다면 OSPO에 문의하라.

수준 이하의 코드는 기여하지 마라

수준 이하의 코드는 기여하지 마라. 이는 기업의 평판에도 영향을 미칠 수 있다.

CLA 서명에 주의하라

어떤 오픈소스 프로젝트는 모든 기여자에게 CLA (Contributor License Agreement)에 서명할 것을 요구한다. 이는 프로젝트가 여러 기여자의 저작물을 관리하면서 발생할 수 있는 저작권 분쟁을 줄이기 위해 기여자들에게 동의를 구하는 약정서이다. 보통 대기업이 주도하는 프로젝트에서 CLA에 서명할 것을 요구한다.

CLA는 프로젝트마다 다르지만 주로 다음 사항을 동의한다는 내용을 담고 있다.

- 나(또는 소속 기업)는 내가 기여하려고 하는 기여물을 프로젝트에 기여할 권리가 있다. (즉, 이 기여물의 저작자이다.)
- 나(또는 소속 기업)는 나의 기여물을 프로젝트가 수정, 배포, 관리할 수 있는 권한을 프로젝트에 부여한다.
- 나(또는 소속 기업)는 부여한 권한을 철회하지 않는다.
- 나(또는 소속 기업)는 프로젝트가 향후 필요에 따라 라이선스를 변경할 수 있는 권한을 프로젝트에 부여한다.

또한, 드문 경우지만, 어떤 CLA는 다음과 같은 조건에 대해서도 동의를 요구한다.

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

SK텔레콤은 자사의 지식재산 보호를 위해 저작권 양도를 요구하는 오픈소스 프로젝트로의 기여는 허용하지 않는다. 이러한 판단을 위해 SK텔레콤의 구성원은 기여하려는 오픈소스 프로젝트에서 CLA 서명을 요구할 경우, 서명하기 전에 반드시 OSPO에 리뷰 요청을 하라. : 오픈소스 기여 절차

대부분의 CLA는 서명해도 문제가 되지 않기 때문에 승인 절차가 오래 걸리지 않다.

저작권을 표시하라

구성원이 재직 기간에 생성한 저작물의 지식재산은 기본적으로 기업이 소유한다. 따라서, 구성원은 외부 오픈소스 프로젝트에 코드를 기여할 때 SK텔레콤의 저작권을 표기해야 한다.

하나 이상의 파일을 기여할 때, 다음과 같이 파일 상단에 저작권과 라이선스를 표기하라.

Copyright 2021 SK TELECOM CO., LTD.
SPDX-License-Identifier: {$SPDX_license_name}

• 여기서 $SPDX_license_name은 해당 오픈소스 프로젝트의 라이선스 정책에 따라 작성한다.
• 단, 버그 수정 등의 목적으로 기존 코드를 수정하는 정도라면 해당 코드 수정에 대해 저작권을 표기할 필요는 없다.
• 자세한 저작권 및 라이선스 표기 규칙은 다음 페이지를 참고하라. : 파일 내 저작권 및 라이선스 표시

회사 이메일을 사용하라

오픈소스 프로젝트에 기여 시 개인 이메일을 사용하지 말고, SK텔레콤 이메일을 사용하라. 이를 통해 (1) 구성원은 회사를 대표하여 커뮤니티와 커뮤니케이션한다는 책임감을 갖게 되고, (2) SK텔레콤이 오픈소스 커뮤니티에 기여 활동을 활발히 하는 기업으로 인지도를 개선할 수 있다.

• GitHub에서 이메일 설정하는 방법은 다음 Link를 참고한다.

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

SK텔레콤의 오픈소스 기여 규칙에 따라 구성원은 외부 오픈소스 프로젝트에 기여할 때 다음과 같은 기여 절차를 따른다.

1. 소속 조직 내부 승인

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

2. OSPO Review 요청

조직 내 승인을 받은 후에는 OSPO_{Open Source Program Office}에 리뷰를 요청한다. : Support (opensource@sktelecom.com)

• 리뷰 요청 시에는 다음 내용을 포함한다. : [Template]
  • 오픈소스 프로젝트 이름
  • Repository
  • License
  • 기여 목적
  • 기여 내용
• OSPO는 오픈소스 프로젝트의 License / CLA를 검토하고, 이상이 없을 경우 승인한다.
• OSPO는 SK텔레콤 구성원이 기여하고 있는 오픈소스 프로젝트 현황을 취합하고 있다. 취합 자료는 오픈소스 프로젝트 별 전문가 Pool로 활용한다.

3. 프로젝트 기여 문서 검토

오픈소스 프로젝트마다 요구하는 절차가 조금씩 다르다.

• 프로젝트마다 코딩 스타일, language, formatting, bug/ticket 관리, 릴리즈 시기 등에 대한 다양한 가이드라인을 갖고 있다.
• 어떤 프로젝트는 CLA 서명을 요구하는 반면, 어떤 프로젝트는 DCO Signed-off-by를 요구를 한다.
• Patch를 받는 방식도 요즘은 대부분 Github의 Pull Request로 받지만, 어떤 프로젝트는 여전히 Mailing List를 이용하기도 한다.

그렇기 때문에 기여하고자 하는 프로젝트의 프로세스를 제대로 이해하기 위해서는 우선 프로젝트에서 제공하는 문서를 잘 확인해야 한다. 대개의 프로젝트는 CONTRIBUTING 또는 README 파일로 이러한 문서를 제공한다. 예를 들어, Kubernetes는 기여자를 위한 자세한 가이드를 제공한다. (contributing.md : Kubernetes에 기여하기 위한 가이드) 문서에서 요구하는 사항을 잘 준수할수록 우리의 기여가 수락될 가능성이 커진다.

4. 오픈소스 기여 Rule 준수

SK텔레콤 오픈소스 기여 Rule을 확인하고 이에 따라 기여할 코드를 개선한다.

5. 기여 제출

이제 프로젝트의 문서에서 요구하는 절차에 따라 기여를 제출한다. 일반적인 오픈소스 프로젝트에 기여하는 방법은 다음 페이지를 참고하라.

• 기여 제출 세부 절차
• 커뮤니케이션 방법

2.3.1 - 기여 제출 세부 절차

이제 기여를 제출하는 방법을 알아보자. 일반적인 오픈소스 프로젝트에 기여 제출 방법과 절차는 다음과 같다.

1. 이전 이력을 확인하라

제출하려고 하는 기여가 이전에 다뤄진 이력이 있는지 확인하라. 프로젝트의 README, 이슈, 메일링 리스트를 살펴봐라. 모든 문서를 다 확인할 필요 없이, 몇 가지 키워드를 검색하면 쉽게 확인할 수 있다.

이전 자료에서 관련 내용을 찾을 수 없다면 이슈를 열거나 Pull Request를 통해 커뮤니케이션을 시작할 단계이다. GitHub에서는 Issues와 Pull Request 기능을 제공한다.

• Issues : 대화나 토론을 시작할 수 있다.
• Pull Request : 문제에 대한 솔루션을 기여한다.

Issue 또는 Pull Request를 열기 전에 프로젝트가 제공하는 문서 (일반적으로 CONTRIBUTING 또는 README)를 확인하여 기여 절차 및 방법을 확인하라. 예를 들어 특정 템플릿을 따르도록 요구하거나, 사전 테스트를 요구할 수 있다.

기여를 위한 작업을 시작하기 전에 먼저 Issues를 오픈해서 커뮤니티 구성원에게 먼저 어떤 작업을 하려고 하는지 알리는 것도 좋은 방법이다. 때에 따라 불필요한 작업을 진행하지 않도록 도움을 받을 수 있다.

2. Issue를 생성하라

‌일반적으로 다음 상황에서 Issue를 생성한다.

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

3. Pull Request를 생성하라

기여할 파일이 모두 준비가 되다면, Pull Request를 통해 기여를 제출하라.

Pull Request 시기

‌일반적으로 다음 상황에서 Pull Request를 생성한다. ‌

• 사소한 수정 사항 제출 (예: 오타, 링크 오류 등)
• Issue에서 이미 논의가 된 사항에 대한 작업 시작

Pull Request는 작업이 완료된 이후에 해야 하는 것은 아니다. 일반적으로 Pull Request를 일찍 오픈하여 다른 사람들의 피드백을 받는 게 좋다. 제목 줄에 “WIP” (Work in Progress)라고 표시하여 아직 진행 중인 작업이라고 표시하고, 나중에 언제든지 더 많은 Commit을 추가할 수 있다.

GitHub에서의 Pull Request 절차

GitHub에 있는 프로젝트라면 Pull Request를 제출 시 다음 사항을 참고할 수 있다.

Step 1. Fork

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

Step 2. Clone

Fork한 Repository를 자산의 Local working directory로 Clone 한다.

$ mkdir -p $working_dir
$ cd $working_dir
$ git clone https://github.com/$user/[repository]

Upstream Repository를 Remote에 추가한다.

$ cd [repository]
$ git remote add upstream https://github.com/[upstream]/[repository]
 
# Confirm that your remotes make sense:
$ git remote -v

Step 3. Create a branch

먼저 main branch를 fetch와 rebase하여 최신 상태로 유지한다.

$ cd $working_dir/[repository]
$ git fetch upstream
$ git checkout main
$ git rebase upstream/main

그리고 개발용 branch (myfeature)를 생성한다.

$ git checkout -b myfeature

Step 4. Keep your branch in sync

Branch를 fetch와 rebase하여 최신 상태로 유지한다.

# While on your myfeature branch
$ git fetch upstream
$ git rebase upstream/main

그 상태에서 code 작업을 한다.

Step 5. Commit

수정 사항을 commit 한다.

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

Step 6. Push

myfeature branch의 수정 사항을 자신의 GitHub Repository에 Push한다.

git push -f origin myfeature

Step 7. Create a pull request

GitHub에서 자신의 Repository에 가면 Compare & pull request 버튼이 활성화 된 것을 볼 수 있다. 이를 눌러서 Pull Request를 생성한다.

이후 Upstream Repository의 관리자는 요청된 Pull Request를 검토하여 Merge 여부를 결정한다.

4. Feedback을 받아라

기여를 제출하면 프로젝트로부터 Feedback을 받게 됩니다. 일반적으로 Feedback은 개선이나 변경 사항이 어떤 방식으로 동작하는지, 왜 그런 방식을 채택하였는지 등에 대한 설명을 요구한다. 이 Feedback은 때로는 대응하기 어려울 수도 있지만, 기여의 수준을 높이는 과정이라고 받아들이는 것이 좋다.

Feedback은 보통 다음 네 가지 중 하나에 해당한다.

(1) 응답이 없다?

기여하기 전에 프로젝트가 활발한지 먼저 확인하는 게 좋다. 어느 정도 활발한 프로젝트에서도 기여에 대해 응답을 받지 못할 수도 있다.

일주일 이상 응답을 받지 못한 경우, 동일한 스레드에 정중하게 누군가에게 검토를 요청하는 것이 좋다. 적절한 사람의 이름을 알고 있다면 @-멘션 기능을 이용하라.

그럼에도 여러 가지 이유가 있겠지만 아무도 반응하지 않을 수도 있다. 썩 좋은 기분은 아니지만 낙담할 필요는 없다. 이는 누구에게나 일어날 수 있는 일이다. 기여할 수 있는 다른 방법이나 다른 프로젝트를 찾아보라.‌

(2) 수정을 요청한다?

아이디어에 대한 설명이나 코드를 수정하라는 요청을 받는 것은 일반적이다. 이렇게 누군가 수정을 요청했다면 바로 응답하라. 그는 자기 시간을 내서 우리 기여를 검토했다.

‌PR을 오픈한 상태로 응답하지 않고 남겨두는건 결례이다. 더 이상 문제를 해결할 여건이 아닌 경우라면, Maintainer에게 더 진행할 수 없다고 알리세요. 그렇게 PR을 Close 하거나 다른 사람이 인수하여 추가로 진행할 수도 있다.

(3) 거절됐다?

우리 기여는 결국 수락될 수도 있고, 수락되지 않을 수도 있다. 수락되지 않은 이유가 잘 이해되지 않을 경우, Maintainer에게 설명을 요청하는 것도 합리적이다. 그러나 이것이 그들의 결정임을 존중해야 한다. 논쟁하거나 적대적으로 행동하지 마라. 끝까지 이견이 조율되지 않으면, 언제든지 Fork 하여 자신의 프로젝트에 작업할 수 있다.

(4) 수락됐다!‌

축하한다! 드디어 오픈소스 기여에 성공했다.

2.4 - 오픈소스 기여 배경 정보

2.4.1 - 오픈소스 기여의 유형

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

문서 작성 / 번역

• 프로젝트 문서, 튜토리얼을 작성한다. (예: 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.2 - 오픈소스 프로젝트 멤버십

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

리더 (Leader)

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

• 예를 들어, Linus Torvalds는 Linux Kernel의 원저작자로서 진행 상황의 모든 것에 대해 최종 결정권을 가지고 있다.
• Node.js 프로젝트의 경우는 Technical Steering Committee가 리더의 역할을 수행한다.

메인테이너 (Maintainer)

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

커미터 (Committer)

커미터는 프로젝트 내 특정 모듈의 코드를 충분히 이해하면서 정기적인 기여 활동을 하는 자들이다. 기여자의 기여를 Review 및 승인할 권한이 있으며, 특정 모듈에 대해 메인테이너의 승인을 받지 않고도 Merge 할 권한을 갖는다.

기여자 (Contributor)

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

사용자 (User)

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

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

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

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

README

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

LICENSE (혹은 COPYING)

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

CONTRIBUTING

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

기여하고자 하는 프로젝트에 CONTRIBUTING 파일이 없다면 커뮤니티에 기여 방법을 문의하라. 만약 적절한 답변을 받지 못한다면, 기여할 가치가 없는 프로젝트로 간주하고 다른 프로젝트를 찾아도 된다.

CODE OF CONDUCT

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

기타 문서

(규모가 큰 오픈소스 프로젝트의 경우) 튜터리얼, 거버넌스 정책과 같은 문서도 제공한다.

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

본격적으로 기여 제출을 설명하기 전에 어떻게 하면 좋은 기여자가 될 수 있을지에 대해 간단히 알아보자. 물론 프로젝트마다 운영되는 방식이 다르므로 하나의 정답은 없다. 새로운 프로젝트에 참여할 때마다 운영 방식을 습득하기 위한 시간을 투자해야 한다. 그런데도 다음 사항들은 좋은 기여자가 되기 위해 공통으로 도움이 될 수 있는 내용이다.

1. 커뮤니티에 참여하라

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

2. 잠시 살펴봐라

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

3. 거버넌스를 이해하라

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

4. 작은 것부터 시작하라

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

5. 이벤트에 참가하라

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

6. 초기 단계의 코드부터 기여하라

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

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

물론 업무와 연관이 있거나 기술적인 관심이 있는 분야의 오픈소스 프로젝트에 기여해야 한다. 그런 프로젝트가 여러 개일 경우, 어떤 프로젝트가 기여할 만한 프로젝트인지 확인하는 것도 필요하다. 그렇지 않으면 수고한 기여가 아무 응답도 받지 못하고 묻혀버릴 수도 있다.

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

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

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

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

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

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

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

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

3. 프로젝트 이슈를 확인하라

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

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

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

4. 프로젝트의 Pull Request를 확인하라.

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

GitHub에서 Pull Request 페이지 내 “closed” tab을 누르면 Close 된 Pull Request를 볼 수 있다.

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

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

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

2.4.6 - 커뮤니케이션 방법

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

정확한 의사를 전달하라

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

무조건 물어보지 말고, 먼저 스스로 해볼 수 있는 걸 하라

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

대화는 가능한 간결하게 하라

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

모든 커뮤니케이션은 공개하라

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

문의하였으면 기다려라

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

커뮤니티의 결정을 존중하라

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

무엇보다도 품위를 유지하라

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

3 - 오픈소스 공개하기

SK텔레콤은 오픈소스 커뮤니티에 참여할 뿐만 아니라 자사의 소프트웨어를 오픈소스로 공개하여 커뮤니티와 협업하는 것을 적극적으로 지원한다. 이는 오픈소스 커뮤니티와의 협업이 얼마나 소중한 가치가 있음을 인식하고 있기 때문이다.

• 오픈소스 공개의 혜택

이 문서에서는 SK텔레콤의 소프트웨어를 오픈소스로 공개할때 법적, 윤리적, 기술적인 문제를 유발하지 않고, 오픈소스 협업의 이점을 최대한 활용하기 위한 가이드를 제공한다.

SK텔레콤 오픈소스 공개 Rule

SK텔레콤은 오픈소스 커뮤니티와의 협업의 가치를 존중하고, 이를 내부 소프트웨어를 오픈소스 프로젝트로의 공개를 장려한다.

하지만, SK텔레콤의 지식재산 보호와 의도치 않은 저작권 침해를 방지하기 위해 준수해야 할 몇가지 규칙이 있다.

• 오픈소스 공개 Rule

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

SK텔레콤의 오픈소스 공개 Rule에 따라 오픈소스 공개를 위한 주요 절차는 다음과 같다.

• 오픈소스 공개 절차

3.1 - 오픈소스 공개의 혜택

기업이 소프트웨어를 오픈소스로 공개하는 데에는 다음과 같은 목적을 위해서이다.

경제적으로 이득이 될 수 있다.

오픈소스는 자선 행위가 아니다. 기업이 자신의 소프트웨어를 오픈소스로 공개하거나 오픈소스에 기여할 때는 보다 높은 투자수익을 기대하기 때문이다.

‌유명한 수학자로서 “협력 게임” 이론으로 노벨 경제학상을 수상한 존 내쉬는 협력은 제로섬 게임이 아니며 모든 참가자가 협력함으로써 자신들이 투자한 것보다 더 높은 수익을 낼 수 있다는 것을 증명했다. 오픈소스는 이 이론의 가장 실제적인 사례이다.

‌한 예로 구글은 내부에서만 사용하던 Angular(web application framework)를 오픈소스로 공개하였고, Angular는 웹 개발자들에게 빠르게 확산되었다. 개발자들은 Angular를 사용하여 많은 확장 프로그램과 도구를 개발하고, 구글은 다시 그러한 확장 프로그램과 도구를 활용하는 이득을 취할 수 있었다. Angluar가 구글에 가져다 준 직접적인 매출을 산정하는 것은 쉽지 않겠지만, 링크드인의 Job Tag 분석에 따르면 약 70만개 이상의 일자리가 창출되었는데, 이러한 고용 시장을 고려할 때 Angluar를 이용한 상품 시장 역시 상당히 클 것으로 예상할 수 있다.

‌여러분의 프로젝트가 이와 같이 높은 투자 수익을 기대할 수 있나? 그렇다면 오픈소스 공개 준비를 시작하라.

표준이 될 수 있다

오픈소스로 프로젝트를 공개하면 표준으로 채택될 가능성이 커진다.

프로젝트가 해당 기술 분야의 사실상의 표준이 되면 참여하는 외부 기여자가 많아지고, 프로젝트와 그 주변 생태계가 더 빠르게 진화한다. 이는 산업 전반의 혁신을 가속화하고 프로젝트를 이용하여 구축한 서비스 및 제품의 채택을 용이하게 한다.

GNU와 Linux를 예로 들어보겠다. GNU와 Linux는 Unix 운영체제를 표방하며 오픈소스로 공개되면서 빠르게 확산되었다. Linux는 이제 서버, 라우터, 커넥티드 디바이스에서는 사실상의 표준이며, 소비자 전자 제품에서도 점점 활용도가 증가하고 있다. 이로 인해 소프트웨어 공급 업체가 Linux를 지원하고 Linux 사용자에게 익숙한 도구도 제공한다(예: Microsoft Windows에서 Bash 지원).

여러분의 프로젝트를 오픈소스로 공개하면 업계의 표준이 되어 많은 외부 기여자를 기대할 수 있나? 그렇다면 오픈소스 공개 준비를 시작하라.

생태계를 성장시킬 수 있다

‌오픈소스로 프로젝트를 공개하면 다른 사람들이 프로젝트를 채택하고 이를 이용하여 자신의 프로그램을 개발한다. 그렇게 되면 그들은 자신의 프로그램뿐만 아니라 프로젝트의 성공을 위해 투자한다. 오픈소스 커뮤니티에는 각자의 소속 회사와 상관없이 프로젝트 내에서 서로 협력하는 우수한 개발자들이 있다. 이러한 개발자는 프로젝트에 다양한 관점을 제공할 뿐만 아니라 생태계가 성장될 수 있게 한다.

이는 WordPress와 같이 확장 메커니즘이 있는 프로젝트의 경우 특히 효과적인 전략이다. WordPress는 플러그인 및 테마 API를 공개하여 개발자, 디자이너 및 컨설턴트 등 기여자들이 다양한 추가 기능을 제공하도록 생태계를 구성하였다. 이렇게 커뮤니티가 플러그인과 테마를 무료 혹은 유료로 제공함으로써 WordPress가 모든 플러그인이나 디자인을 다룰 필요가 없게 되었다. 이러한 생태계 환경은 WordPress 뿐만 아니라 커뮤니티 구성원 및 최종 사용자에게도 혜택을 줍니다.

또 하나의 예로 2008년, JavaScript는 너무 느려서 이를 많이 쓰는 웹사이트는 거의 사용할 수 없었다. 구글은 Chromium을 오픈소스로 발표하면서 V8 JavaScript 엔진도 공개하였다. V8은 JavaScript를 실행하기 전에 기계 코드로 컴파일하고 다양한 최적화 기술을 사용하는 엔진이다. 이로 인해 브라우저의 성능이 크게 향상되어 웹사이트의 사용자 환경이 개선되었고 웹 응용 프로그램 개발이 길이 열렸으며, JavaScript가 Node.js와 같은 서버 소프트웨어와 함께 사용될 수 있게 되었다. V8이 오픈소스로 공개되었기 때문에 단순히 크롬뿐만 아니라 전체 생태계가 함께 발전할 수 있었다.

여러분의 프로젝트를 오픈소스로 공개하였을때 이와 유사하게 프로젝트와 생태계의 성장을 기대할 수 있나? 그렇다면 오픈소스 공개 준비를 시작하라.

우수한 개발자를 채용할 수 있다

‌채용이 오픈소스의 주요 목적은 아니다. 그러나 기업이 내부에서 널리 사용되는 소프트웨어를 오픈소스로 공개할 때 주로 나타나는 효과 중 하나이다.‌

예를 들어, 구글의 내부 빌드 시스템인 Bazel을 오픈소스로 공개하면서 이를 외부 개발자도 사용하게 되었다. 이렇게 도구가 오픈소스가 되면서 외부 인원들도 이 도구에 익숙해지고, 기업은 이미 이 도구를 잘 알고 있는 외부 기여자 중에서 채용할 인력을 선택할 수 있다는 장점이 생깁니다. 이러한 인력은 이미 기술, 커뮤니티 구축, 지원 등에 익숙하기 때문에 실무에 투입하기 위한 교육 프로세스가 훨씬 간소화될 수 있다.

기업은 이러한 오픈소스 활동으로 커뮤니티에서 명성이 높아지고, 오픈소스 개발자에게는 매력적인 일터로 비치게 되면서 인재를 확보할 수 있다.

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

SK텔레콤은 오픈소스 커뮤니티와의 협업의 가치를 존중하고, 이를 내부 소프트웨어를 오픈소스 프로젝트로의 공개를 장려한다. 하지만, SK텔레콤의 지식재산 보호와 의도치 않은 저작권 침해를 방지하기 위해 준수해야 할 몇가지 규칙이 있다.

• 승인을 받아라
• 공개할 권리가 있는 코드만 공개하라
• 지식 재산 노출에 주의하라
• 수준 이하의 코드는 공개하지 마라
• 유용한 코드를 공개하라
• 리소스를 확보하라
• 회사 이메일을 사용하라

승인을 받아라

오픈소스 공개는 저작권 관점에서 저작자가 저작물을 누구나 수정/사용/배포할 수 있는 권한을 오픈소스 라이선스를 통해 부여하는 것이다. 일반적으로 고용 기간에 만든 저작물의 저작권은 고용주가 소유한다. 즉, SK텔레콤 구성원이 만든 저작물은 SK텔레콤이 소유한다. 구성원이 임의로 저작물을 오픈소스로 공개하는 행위는 불필요한 저작권 침해 이슈를 유발시킬 수 있다.

따라서, 소프트웨어를 오픈소스로 공개하고자 한다면 SK텔레콤 오픈소스 공개 정책에 따라 리뷰 요청 및 승인 절차를 따른다. 오픈소스 공개 절차

공개하는 과정에서 어느 것이라도 무언가 바람직하지 않아 보이는 상황이 있다면 주저하지 말고 OSPO에 문의하라.

공개할 권리가 있는 코드만 공개하라

여러분이 작성하지 않은 코드는 여러분이 공개할 권리가 없다.

오픈소스 프로젝트에서 발생할 수 있는 최악의 상황 중 하나는 법적으로 문제가 있는 코드가 프로젝트에 포함되는 것이다. 회사가 배포할 권리가 없는 코드이거나, 다른 회사의 특허와 같은 IP를 침해하는 코드가 법적인 문제를 유발시킬 수 있다. 따라서, 공개할 코드를 준비하면서 모든 코드의 출처를 확인하고 문제 소지가 있는 코드는 삭제해야 한다.‌

지식 재산 노출에 주의하라

민감한 정보, 특허 등 기업의 지식재산 노출이 우려되는 코드, 문서는 공개하지 마라.

공개하려는 코드에 회사의 특허가 포함되어 있다면, 이 특허를 오픈소스 라이선스로 공개해도 되는지 확인하라. 모호한 부분이 있다면 OSPO에 문의하라.

수준 이하의 코드는 공개하지 마라

‌코드의 가독성과 성숙도는 오픈소스로 공개하기 위한 준비가 되었는지에 대한 척도가 된다. 성숙하지 않은 코드는 커뮤니티의 신뢰를 잃게 한다.

그렇다고 코드가 완벽해야 한다는 건 아니다. 코드를 완벽하게 준비하려고 한다면 아마 시작할 수도 없을 것이다. 주어진 환경에서 최선의 수준으로 준비하여 공개하라. 커뮤니티가 활성화되면 외부 기여자들이 코드를 개선하는 데 참여할 것이다.

유용한 코드를 공개하라

성공적인 프로젝트가 되기 위해서는 다른 사람들에게도 유용해야 한다. 만약, 유사한 프로젝트가 이미 존재한다면, 새로운 프로젝트를 만드는 것보다 기존의 프로젝트에 참여하는 게 낫다. 경쟁 업체가 추진하는 프로젝트라도 오픈소스에서는 협력하는 것이 중요하다. 함께 참여하고 협력하면서 모두가 훌륭한 코드를 가질 수 있다.

‌더 이상 유용하지 않은 코드인데도 공개만 하면 무조건 커뮤니티가 관리할 것으로 생각해서는 안된다. 오픈소스 커뮤니티는 오래된 코드를 관리해주는 조직이 아니다. 실제로 매력적이지 않은 코드를 반복해서 공개한다면 그 회사는 오픈소스 세계에서 신뢰를 잃게 되고, 나중에는 다른 코드를 오픈소스로 공개하여도 개발자는 관심을 두지 않을 것이다.

여러분이 공개하는 오픈소스가 (1) 오픈소스 커뮤니티에 차별화된 가치를 제공하고, (2) 커뮤니티가 해결되지 못했던 문제를 해결하며, (3) 우리의 기술력을 공개함으로 긍정적인 관심을 끌 수 있는 프로젝트가 되기를 기대할 수 있어야 한다.

• 여러분이 실제 제품이나 서비스에 사용하지 못한 코드라면 오픈소스로도 공개하지 않는 것이 좋다. 우리의 제품에도 사용하도록 설득할 수 없다면 다른 사람도 사용하도록 설득하기는 쉽지 않다.
• 오픈소스 커뮤니티에서 이미 해결한 문제를 다루는 코드는 공개하지 않다. 이런 경우라면, 기존의 오픈소스 프로젝트에 기여하는 것이 좋다.

공개하려는 코드가 외부에서도 유용할 수 있다고 판단이 되면 공개 절차를 계속 진행하라.

리소스를 확보하라

개발자를 포함해서 프로젝트에 투입해야 할 리소스를 확보해야 한다.‌

• 초기에는 일반적인 사내 프로젝트와 비슷한 수준의 개발자가 필요하다.
• 또한, 외부의 기여를 신속하게 리뷰 할 수 있는 개발자가 필요하다.
• 그리고, 법무팀, 마케팅팀의 역할도 필요하다.
• 또한, 프로젝트를 유지, 관리하는데 요구되는 인프라에 대한 예산을 확보해야 한다. 여기에는 Github와 같은 프로젝트 호스팅을 위한 도구가 포함된다.

충분한 리소스가 지원되는 환경을 조성할 수 없다면, 오픈소스로 공개하지 않는 것이 좋다.

회사 이메일을 사용하라

오픈소스 공개 활동 시 개인 이메일을 사용하지 말고, SK텔레콤 이메일을 사용하라. 이를 통해 (1) 구성원은 회사를 대표하여 커뮤니티와 커뮤니케이션한다는 책임감을 갖게 되고, (2) SK텔레콤이 오픈소스 커뮤니티에 공개 활동을 활발히 하는 기업으로 인지도를 개선할 수 있다.

GitHub에서 이메일 설정하는 방법은 다음 Link를 참고한다.

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

• 1. 소속 조직 내부 승인
• 2. OSPO 지원 요청
• 3. 주요 의사 결정
  • 프로젝트 이름 결정
  • 라이선스 결정
  • CLA 결정
• 4. 공개할 코드 준비 및 점검
  • 3rd party 코드 정리
  • 파일 내 저작권 및 라이선스 표시
  • 불필요한 주석 제거
  • 라이선스 파일 포함
  • 오픈소스 라이선스 점검
  • 오픈소스 보안취약점 점검
• 5. 개발 환경 / 인프라 구축
  • 저장소/Issue Tracker
  • 테스트 자동화
  • CI/CD
  • 웹사이트
  • 커뮤니케이션 채널
• 6. 거버넌스 체계 수립
  • 멤버십
  • CODE OF CONDUCT
• 7. 문서화
  • README 파일
  • 개발 가이드
  • CONTRIBUTING 파일
• 8. OSPO 리뷰 요청
• 9. 공개
• 10. 마케팅
• 11. 커뮤니티 활성화

1. 소속 조직 내부 승인

소프트웨어를 오픈소스로 공개하기 위해 소속 조직의 담당 임원 혹은 리더에게 승인을 받는다.

2. OSPO 지원 요청

오픈소스 공개를 결정하고 소속 조직의 승인을 받은 후, OSPO에 지원을 요청한다. : Support (opensource@sktelecom.com)

OSPO는 이 가이드의 내용 위주로 오픈소스 공개 Rule 및 절차를 설명하고, 필요 사항을 지원한다.

3. 주요 의사 결정

프로젝트 이름 결정

듣기 좋고 외우기 쉬우며, 어떤 프로젝트인지 나타낼 수 있는 이름으로 짓는게 좋다. 문제가 될 소지가 있는 이름은 피해야 한다. 자세한 사항은 다음 페이지를 참고한다.

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

라이선스 결정

소프트웨어를 오픈소스로 공개하기 위해서는 라이선스를 부여해야 한다. 그래야 다른 사람들도 소프트웨어를 사용, 복사, 수정 및 배포할 수 있다. 또한, 라이선스는 법적인 문제로부터 기여자를 보호한다. 따라서, 오픈소스 프로젝트를 시작할 때 적절한 오픈소스 라이선스를 선택하고 이를 프로젝트에 적용해야 한다.‌

SK텔레콤은 소프트웨어를 오픈소스로 공개 시 기본적으로 Apache-2.0를 적용한다. Apache-2.0는 사용자에게 광범위한 자유를 제공하면서 명시적인 특허 허여 조항 등 법적인 관점에서도 잘 작성된 라이선스이다.

단, 예외적으로 다음과 같은 경우는 Apache-2.0 외의 라이선스도 적용할 수 있다.‌

• 커뮤니티에서 주로 사용하는 라이선스가 지정되어 있는 경우도 있다. 예를 들어, Node.JS 프로젝트는 MIT 라이선스를 사용한다. 이때는 해당 라이선스를 적용할 수 있다.

• 어떤 프로젝트는 GPL 라이선스의 라이브러리와의 종속성이 있어서 GPL로 공개해야 하는 경우도 있다. 이때는 GPL을 적용할 수 있다.

참고로, GitHub에서는 오픈소스 공개 시 라이선스 선택에 대한 가이드를 제공하고 있다. : https://choosealicense.com

CLA 결정

오픈소스로 공개한 프로젝트를 운영하면서 어떤 이유에서든지 기존의 오픈소스 라이선스를 다른 라이선스로 변경해야 할 상황이 발생할 수 있다. 이때는 프로젝트의 Leader라고 해도 임의로 라이선스를 변경할 수 없으며, 프로젝트에 저작물을 기여한 모든 저작권자의 동의를 얻어야 가능하다. 오랜 기간동안 많은 기여자로부터 저작물을 기여 받은 프로젝트의 경우 모든 저작권자에게 동의를 받는 것은 사실상 거의 불가능하고, 따라서 오픈소스 라이선스의 변경 또한 불가능하다.

이와 같이 다수의 기여자의 저작물을 관리하면서 발생할 수 있는 분쟁을 줄이기 위해 기여자에게 사전에 동의를 구하는 약정서가 CLA (Contributor License Agreement)이며, 주로 기여자로부터 다음 사항의 동의를 구하는 내용을 담고 있다.

- 나(또는 소속 기업)는 내가 기여하려고 하는 기여물을 프로젝트에 기여할 권리가 있다. (즉, 이 기여물의 저작자이다.)
- 나(또는 소속 기업)는 나의 기여물을 프로젝트가 수정, 배포, 관리할 수 있는 권한을 프로젝트에 부여한다.
- 나(또는 소속 기업)는 부여한 권한을 철회하지 않는다.
- 나(또는 소속 기업)는 프로젝트가 향후 필요에 따라 라이선스를 변경할 수 있는 권한을 프로젝트에 부여한다.

기여자에게 CLA 서명을 요구할 경우, 프로젝트가 기여자의 저작물을 관리하기 용이해지는 장점이 있지만, CLA 서명을 거부하는 기여자로부터 기여를 받을 수 없다는 단점이 있다.

SK텔레콤은 첨부의 CLA를 사용하고 있다. SK텔레콤 템플릿

• 프로젝트에 CLA를 사용할지 여부는 프로젝트 목적 및 환경에 따라 공개하는 조직에서 결정한다.
• (1) 향후 오픈소스 라이선스를 변경할 계획이 없거나, (2) 다수의 기업이 참여하고 저작권 분쟁이 발생할 가능성이 크지 않을 경우, CLA를 사용하지 않아도 된다.

4. 공개할 코드 준비 및 점검

‌오픈소스로 코드를 공개하기 전에 불필요하게 이슈가 될 부분은 사전에 제거하는 등 정리하라. 

3rd party 코드 정리

프로젝트에 3rd party 코드를 포함해야 하는 경우라면, 즉, SK텔레콤이 저작권을 갖고 있지 않은 코드를 프로젝트에 포함해야 한다면 먼저 SK텔레콤이 재배포할 수 있는 권한이 있는지 확인하라. 이미 오픈소스 라이선스가 적용된 코드라면 라이선스 의무를 준수하는 조건으로 재배포할 수 있다.

• 재배포할 수 있는 권한 확인에 대한 도움이 필요하다면 OSPO(_{Open Source Program Office}에 문의하라. : Support (opensource@sktelecom.com)

SK텔레콤이 재배포할 수 있는 3rd party 코드인 경우, 기존 코드와는 다른 디렉토리(예: third_party)에 위치시킨다. 이는 라이선스 관점에서 프로젝트의 투명성을 증대시키며, 향후 사용자도 3rd party 코드를 쉽게 찾게 찾게 되어 정확한 라이선스 요구사항을 준수할 수 있게 한다.

3rd party 디렉토리에 있는 모든 디렉토리는 각각 LICENSE 파일 (저작권 정보와 라이선스 전문을 포함하는 텍스트 파일)을 포함해야 한다. 예를 들어, Repository에서 third_party 디렉토리의 구조는 다음과 같다.

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

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

‌소스 코드를 포함하는 모든 파일은 저작권 및 라이선스 표기를 포함하라. 이는 몇몇 파일만 복사해서 사용하려는 사용자들도 라이선스 의무를 준수하는데 도움이 된다. 자세한 내용은 다음 페이지를 참고하라.

• 저작권 및 라이선스 표시

불필요한 주석 제거

공개하려는 코드에 회사의 영업 비밀이나 문제를 일으킬만한 불필요한 주석이 포함되지 않도록 확인하라.‌

• (굳이 외부에 공개할 필요가 없는) SK텔레콤 구성원의 이름과 이메일 주소를 삭제하라.
• 내부 정보를 삭제하라. (내부 코드 파일 이름 / 경로, 내부 호스트 / IP정보 등)

참고로, 아래의 명령어를 사용하면, 불필요한 주석을 쉽게 찾을 수 있다.

### 회사 웹사이트, 이메일, IP 주소 검색
$ egrep -r '\.sktelecom\.com|@sk\.com|@sktelecom\.com|([0-9]+\.){3}[0-9]+' <path-to-source-directory>

### Java/C/C++/Go/Objective-C/Objective-C++/Swift/Kotlin 주석 검색
$ find <path-to-source-dir> -type f | egrep '\.(c|cc|h|cpp|go|java|kt|m|mm|swift)' | \
  while read f; do echo "------------ $f ------------------"; sed -n -e '/\/\*.*\*\// {p; b}' \
  -e '/\/\*/,/\*\//p' -e '/\/\//p' "$f"; done

### Python/Bash 주석 검색
$ find <path-to-source-dir> -type f | egrep '\.(py|sh)' | while read f; \
  do echo "------------ $f ------------------"; grep -o "#.*" "$f"; done

라이선스 파일 포함

라이선스 사본을 담고 있는 LICENSE라는 이름의 텍스트 파일을 최상위 디렉토리에 포함한다.

오픈소스 라이선스 점검

오픈소스 라이선스 점검 도구를 이용하여 공개할 소스 코드를 점검하여 다음 사항을 확인한다. 

• 고지 / 소스 코드 공개 의무를 요구하는 라이선스 하의 다른 오픈소스 포함 여부
• 여러분이 공개할 권리가 없는 3rd party 소스 코드 포함 여부
• 여러분이 적용할 오픈소스 라이선스와 충돌하는 라이선스하의 코드 포함 여부

오픈소스 보안취약점 점검

오픈소스 보안취약점 점검 도구를 이용하여 공개할 소스 코드에 보안취약점 이슈가 있는 오픈소스가 포함되어 있는지 확인한다. 

5. 개발 환경 / 인프라 구축

저장소/Issue Tracker

프로젝트를 위한 저장소를 준비하라. 많은 프로젝트가 GitHub 또는 GitLab repository를 사용하거나 Gerrit과 같은 도구를 사용하여 자체 저장소를 제공한다. Bug, issue, feature tracking을 위한 기능도 인프라 계획의 일부로 포함되어야 한다.

SK텔레콤 GitHub Repository를 이용할 것을 권장한다. : https://github.com/sktelecom

• GitHub 멤버 등록은 OSRB에 요청한다. : Support (opensource@sktelecom.com)

테스트 자동화

오픈소스 개발은 원격지의 다수가 비동기로 협업해야 하는 특성을 갖는다. 그러면서도 우수한 품질을 유지하기 위해서는 테스트 자동화가 필수이다. 다음과 같은 테스트를 제공하고 자동화하라. 

• Unit Test
• Integration Test
• End-to-End Test

CI/CD

테스트 뿐만 아니라 빌드, 배포까지 개발 라이프 사이클 전체에 걸쳐 지속적인 자동화와 모니터링을 제공하는 환경을 구축하라. 다시 말하지만 오픈소스 프로젝트의 성공과 지속을 위해서는 자동화된 개발, 빌드, 테스트와 배포 환경이 필수이다. 

웹사이트

사용자 가이드를 제공하고 프로젝트를 홍보하기 위한 웹사이트를 구축하라. 프로젝트의 리더십, 거버넌스 세부 사항 등에 대한 내용도 제공할 수 있다.

GitHub Pages는 간단히 웹사이트를 제작하고 호스팅할 수 있는 방법을 제공한다. 

커뮤니케이션 채널

커뮤니티에서 원활한 커뮤니케이션이 가능하도록 채널을 제공하는 것이 중요하다. 또한 코드 체크인, 오류 로그 등 기타 작업에 대한 알림을 주는 등 전체 개발 Work Flow에 통합할 수 있는 도구가 필요하다. 이는 프로젝트를 실시간으로 진행하는 중요한 수단이 된다.

• 우수한 도구 중 하나는 Slack이다. Slack은 사용자가 메시지와 파일을 공유하고, Work Flow 구성, 정보 검색 등의 작업을 수행할 수 있게 하는 온라인 프로젝트 관리 및 통신 플랫폼이다. 그러나 Slack은 상용 도구이며 유지 관리 비용이 발생한다.

• 오픈소스로 공개된 도구들로는 IRC, Gitter.im, Rocket.Chat 등이 있다. Rocket.Chat은 오픈소스이며 Slack과 유사한 기능을 제공한다.

단, Slack과 같은 타사 서비스에서는 회사의 기밀 정보를 논의해서는 안된다. 이러한 커뮤니케이션 채널은 공개 토론으로만 사용해야하며 회사 내부 조직의 논의 도구로는 사용하지 않는다.

6. 거버넌스 체계 수립

멤버십

오픈소스 프로젝트는 여러 지역의 다양한 인원이 모여서 협업을 수행한다. 효과적인 협업을 위해서는 참여 인원의 명확한 역할 구분이 필요하다. 이를 위해 어떤 멤버십을 구성할지 결정하라. 

• 일반적인 오픈소스 프로젝트의 멤버십은 다음 페이지를 참고하라. : 오픈소스 프로젝트 멤버십
• 또한, 멤버십의 한 예로 HANU 오픈소스 프로젝트의 멤버십을 참고할 수 있다.

CODE OF CONDUCT

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

다음은 SK텔레콤의 오픈소스 프로젝트에서 사용할 수 있는 CODE OF CONDUCT 템플릿이다. : 

7. 문서화 

오픈소스 프로젝트가 많은 사용자와 기여자를 확보하기 위해 가장 중요한 부분이 문서화이다. 얼마나 자세하고 정확한 문서를 제공하느냐가 프로젝트의 품질로 인식된다. 소프트웨어의 기능이 아무리 우수하더라도 이를 문서로 성실하게 표현하지 않으면 사용자는 발길을 돌리고 말 것이다. 

README 파일

여러분이 공개한 오픈소스를 많은 사용자들이 사용하기를 원하는가? 그렇다면 사람들이 쉽게 시작할 수 있도록 README 파일을 제공하라. README 파일은 새로운 사람들에게 프로젝트에 대해 설명하는 가장 중요한 문서이다.

README에서는 다음 질문에 답할 수 있는 내용을 포함해야 한다.‌

• 이 프로젝트는 무엇을 하는 프로젝트 인가?
• 왜 이 프로젝트가 유용한가?
• 어떻게 시작하면 되나?
• 도움이 필요하면 어디서 도움을 받을 수 있나?

프로젝트 사용자의 배경지식은 매우 다양한다. 프로젝트를 막 시작하여 경험이 없는 사람도 쉽게 이해할 수 있도록 자세하게 문서를 제공하는 것이 좋다. 문서가 충실하게 제공될 수록 더 많은 사용자와 기여자를 확보할 수 있음을 기억하라.

개발 가이드

프로젝트에 참여할 의지가 있는 예비 기여자들을 위해 개발 가이드를 제공하라. 이 문서에는 다음 내용을 포함한다. 

• How to build
• Testing Guide
• Coding Convention
• CI/CD
• Release

개발 가이드의 예는 HANU 프로젝트 Developing 문서를 참고한다.

CONTRIBUTING 파일

기여자들이 참고할 수 있는 “How to Contribute"에 대한 내용을 제공하는 파일이다. CONTRIBUTING 파일이 충실하지 않다면 프로젝트로의 기여에 관심이 있던 사용자들도 열정을 잃게 된다.‌

CONTRIBUTING 파일은 다음과 같은 사항을 포함한다.

• 버그 리포트를 제출하는 방법 (Issue 생성 / Pull Request 제출 방법)
• 새로운 기능을 제안하는 방법
• 개발 환경을 설정하고 테스트를 실행하는 방법‌

또한, 다음과 같이 기여자들로부터 기여받기를 바라는 바에 대해 안내할 수 있다.

• 원하는 기여 유형
• 프로젝트의 비전과 로드맵
• 기여자들이 프로젝트 관리자에게 연락을 취할 수 있는 방법

프로젝트의 초기 단계에서의 CONTRIBUTING 파일은 간단해도 된다. 단, 버그 리포트 및 이슈 제기 방법과 사전 테스트와 같이 기여를 하기 위한 필수 조건에 대해서는 꼭 설명해야 한다.

그리고, 따뜻하고 친근한 분위기의 문서를 제공하라. 이러한 문서가 잠재적인 기여자들에게 프로젝트에 참여하고 싶은 기분이 들게 한다. 예를 들어, Active Admin이라는 프로젝트의 Contributing 가이드는 다음과 같이 시작한다.

“먼저 Active Admin에 기여하는 것을 고려해주셔서 감사한다. Active Admin을 훌륭한 도구가 될 수 있는건 바로 당신 때문이다!”

CONTRIBUTING 파일도 README와 마찬가지로 프로젝트 Repository내 최상이 폴더에 위치시킨다. 그리고, 사용자들이 접근하기 쉽도록 README 파일 내에 링크를 제공하라.

8. OSPO 리뷰 요청

위의 절차를 통하여 공개할 준비가 되면 다음 정보를 OSPO에 제공하고 리뷰를 요청한다. OSPO는 SK텔레콤의 소프트웨어를 오픈소스로 올바르게 공개하고 커뮤니티를 활성화하기 위해 지원한다. : Support (opensource@sktelecom.com)

한번 공개를 하면 이를 되돌리는 것은 쉽지 않다. 그렇기 때문에 가능한 충분한 시간을 갖고 코드를 검토하고 준비하라. 물론 완벽한 코드를 요구하는 것은 아니다. 공개한 후 후회하는 부분이 없도록 실수를 줄여야 한다.

검토 과정에서 문제가 없다면 승인 과정은 매우 간단하며 신속하게 진행한다. OSPO는 오픈소스 공개를 막는 것이 아니라 장려하고 돕기 위한 서비스를 제공한다.

‌OSPO 승인이 된 후 프로젝트 공개를 진행하라.

9. 공개

모든 준비와 검토 단계를 마친 후에는 최종적으로 다음 사항을 확인한다.

• 공개를 위한 Repository에 모든 코드와 문서가 존재하는지 확인하라.
• 모든 프로젝트 인프라가 실행 중이고, 안전하며, 확장 가능한지 확인하라.
• 개발자가 커뮤니케이션 채널 (IRC, Mailing List 등)에 참여하고 모니터링할 수 있는지 확인하라.

그리고, 오픈소스 프로젝트를 런칭한다. OSPO의 안내에 따라 https://github.com/sktelecom에 소스 코드 저장소를 Public하게 공개하라. (개발팀의 필요에 따라 다른 repository를 이용하여 공개할 수 있다.)

10. 마케팅

프로젝트를 계속 진행하기 위해서는 마케팅이 필수적이다. 마케팅에는 프로젝트 홍보, 성공적인 운영 전략 수립, 현실적인 예산 및 프로젝트 브랜딩 제공, 소셜 미디어 계정 활성화 등 장기적인 성공을 위한 활동 등이 포함된다. 여기에서는 프로젝트를 공개하고 이를 알리기 위한 몇가지 방법을 안내한다.

1. 프로젝트와 관련이 있는 커뮤니티의 메일링 리스트나 포럼에 프로젝트가 공개되었음을 알린다.
2. SK텔레콤 기술 블로그(https://sktelecom.github.io/)에 프로젝트에 대해 소개한다. 
3. 프로젝트의 소셜 미디어(Twitter, Facebook, LinkedIn 등)를 통해 홍보한다. SK텔레콤의 소셜 미디어 계정을 활용할 수도 있다. 
4. 프로젝트와 관련이 있는 오픈소스 컨퍼런스에서 주제 발표를 한다.

11. 커뮤니티 활성화

이제 프로젝트를 홍보하고 사람들에게 프로젝트를 사용할 수 있도록 알리는 것은 여러분의 임무이다. 얼마나 많은 사람이 프로젝트에 참여하여 코드를 사용하고, 버그를 수정하고, 문제를 보고하는지에 따라 프로젝트의 성공을 판단할 수 있다. 

• 커뮤니티 구축은 자동으로 이루어지지 않다. 커뮤니티 구축을 위한 세부 활동은 다음 페이지를 참고하라. : (커뮤니티 활성화 가이드는 준비 중 : haksung@sk.com )
• 또한, 이를 위해 프로젝트를 측정할 수 있어야 한다. 측정 지표와 측정 방법에 대한 세부 내용은 다음 페이지를 참고하라. : (오픈소스 측정 가이드는 준비 중 : haksung@sk.com )

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

듣기 좋고 외우기 쉬우며, 어떤 프로젝트인지 나타낼 수 있는 이름으로 짓는게 좋다. 문제가 될 소지가 있는 이름은 피해야 한다.

기억하기 쉬운 이름을 선택하라.

기억하기 쉽고, 프로젝트가 무엇을 하는지에 대해 알릴 수 있는 이름으로 선택하라. 예를 들면 다음과 같다.

• Sentry (보초, 감시) : Crash Reporting을 모니터하는 앱이다.
• Thin (얇은, 간단한) : 빠르고 간단한 Ruby web server 이다.

만약 기존의 어떤 프로젝트를 기반으로 한다면 그 프로젝트 이름을 앞에 붙여서 사용할 수도 있다. 예를 들어, node-fetch는 Node.js에 window.fetch를 제공하는 모듈이다.

무엇보다도 명확성을 고려하라. 조크가 가미된 이름이 재미있으나 다른 문화나 언어를 가진 사람에게는 이해되지 않을 수 있다.

SK텔레콤 브랜드 이름은 피하라.

SK텔레콤이 홍보하는 제품 혹은 서비스가 아니라면 SK텔레콤의 브랜드를 사용하지 마라. 또한 꼭 필요한 경우가 아니라면 “T-이름” 형태의 이름(예: T world)을 사용하지 마라.

중복되는 이름은 피하라.

유사한 이름의 오픈소스 프로젝트가 있는지 먼저 확인하라. 특히, 같은 생태계에 동일한 이름의 프로젝트가 있다면 그 이름은 피해야 한다. 이미 존재하는 인기있는 프로젝트와 이름이 겹칠 경우, 사용자에게 혼란을 줄 수 있다.

웹사이트, 트위터 등을 이용한 홍보를 고려해서 미리 원하는 도메인 이름이나 SNS 계정을 확보할 수 있는지 확인하라. 당장 필요하지 않더라도 미리 확보하는게 좋다.

타사 브랜드를 사용하지 마라.

즉, “Java Test Library” 보다는 “Test Library for Java"가 낫다.

상표권을 침해하지 마라.

프로젝트 이름이 상표권을 침해하지 않는지 확인하는 것도 중요하다. 추후 상표권을 가진 회사가 프로젝트 중단 요청이나 법적조치를 취해올 수 있다. 이러한 위험을 감수해야 하는 상황을 만들 필요는 없다. Kipris의 상표권 검색 (해외의 경우 WIPO Global Brand Databae)에서 상표권 충돌 여부를 확인할 수 있다.

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

저작권은 (베른 협약 이후) 저작자가 저작물 만들 때 자동으로 생성된다. 모든 저작물은 저작권에 의해 보호되며, 저작권 보유자에게 저작물에 대한 독점적인 권한이 부여된다. 따라서 우리의 저작물(소스 코드, 텍스트, 이미지, 기타 미디어 등)을 다른 사용자가 사용할 수 있게 하려면 그들에게 라이선스를 부여해야 한다. 라이선스의 사전적 정의는 “특정 권리를 실행하기 위해 자격이 있는 기관으로부터 받은 허가"이며, 이러한 허가 없이 특정 권리를 실행하는 것은 저작권 침해와 같은 불법 행위가 된다.

저작권 표시가 법에 따라 요구되는 것은 아니지만, (1) 대부분의 오픈소스 라이선스가 저작권 표시를 요구하고, (2) 사용자가 법적 또는 기술적인 이유로 저작권자에게 연락하기를 원할 수 있다는 점을 고려하여 소스 코드 파일에 저작권 표시를 포함하는 것은 의미가 있다.

SK텔레콤에서 작성하여 오픈소스로 공개하는 모든 소스 코드 파일에는 다음과 같은 방법으로 저작권 표시 및 라이선스를 고지하라.

저작권 표시

소스 코드 상단 헤더 부분에 다음 정보를 포함하는 저작권 표시를 추가하라.

• Copyright (혹은 © 기호)
• 최초 작성 연도
• 저작권 보유자 이름
  • SK텔레콤 구성원이 저자인 저작물의 저작권은 SK텔레콤이 보유한다. 따라서, 회사 이름을 작성한다. (SK TELECOM CO., LTD.)
  • SK텔레콤의 자체적인 개발보다 외부 기여를 적극적으로 수용할 계획이라면 저작권 정보를 “The [Project] Authors"라고 표시하고, 저자 정보를 AUTHORS 파일로 관리하는 것도 고려할 수 있다.
• 연락처 (Optional)
  • 사용자가 저자에게 기술적, 법률적 문의를 위해 연락을 취하고 싶을 수 있다. 이를 대응하기 위한 저자의 이메일 정보를 제공할 수 있다. 이는 필수는 아니다.
  • 또는, 사용자가 정보를 얻을 수 있는 프로젝트의 웹사이트 URL 등 연락처 정보를 작성한다.

저작권 표시는 REUSE.software 에서 권장하는 방법인 SPDX Tag (“SPDX-FileCopyrightText”)를 사용하여 표시한다. 그 예는 아래와 같다.

SPDX-FileCopyrightText: Copyright 2021 SK TELECOM CO., LTD. <{$project-website-url}>

라이선스 고지

각 소스 코드 파일마다 라이선스가 무엇인지 알리는 것도 매우 중요한다. 라이선스는 혼란을 줄이기 위해 Linux Foundation의 SPDX 프로젝트에서 제공하는 SPDX ID를 사용하여 표시한다. SPDX ID를 사용하는 방법은 간단한다.

먼저 적용하고자 하는 오픈소스 라이선스의 SPDX Identifier가 무엇인지 SPDX License List 페이지에서 확인한다. 예를 들어, Apache License version 2의 SPDX Identifier는 Apache-2.0이다.

그리고 소스 코드 파일 상단에 SPDX-License-Identifier라는 tag를 이용하여 라이선스 Identifier를 표시한다. 그 예는 아래와 같다.

SPDX-License-Identifier: Apache-2.0

자동화 도구

(SPDX tag와 함께 추가되도록 도구 개선 후 가이드 개선 필요 : haksung@sk.com )

addlicnse

• addlicense : 소스 파일을 자동으로 인식하여 저작권/라이선스 표시를 추가한다.

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

autogen

• autogen : 새로운 파일에 주석 및 코드를 자동으로 추가한다.

autogen --no-code --no-tlc -c "SK TELECOM CO., LTD." -l apache [filename]

이를 batch 로 적용할 수도 있다. 아래 예는 Java 파일에 적용하는 batch이다.

find . -type f -name \*.java -exec autogen -i --no-code --no-tlc -c \
  "SK TELECOM CO., LTD." -l apache {} \;