2. 정책

1. 오픈소스 정책 문서화

기업은 공급 소프트웨어 개발, 서비스, 배포에 관여하는 조직이 올바르게 오픈소스를 활용하기 위한 원칙으로 구성된 오픈소스 정책을 수립하여 문서화하고 이를 조직 내 전파해야 합니다.

이를 위해 ISO 표준은 공통적으로 다음과 같이 문서화된 오픈소스 정책 및 보안 보증 정책을 요구합니다.

일반적인 오픈소스 정책은 다음을 포함합니다. 기업은 이러한 원칙을 포함한 오픈소스 정책을 만들어서 문서화해야 합니다:

1. 공급 소프트웨어 제품과 서비스 배포 시 오픈소스 라이선스 컴플라이언스 및 보안 취약점 리스크를 최소화하기 위한 원칙
2. 외부 오픈소스 프로젝트에 기여하기 위한 원칙
3. 기업의 소프트웨어를 오픈소스로 공개하기 위한 원칙
4. 오픈소스 소프트웨어 컴포넌트의 SBOM(Software Bill of Materials) 생성 및 관리 원칙
5. 알려진 취약점 및 새로 발견된 취약점에 대한 대응 원칙

또한 오픈소스 정책은 프로그램 참여자에게 전파되어야 하며, 정기적으로 검토 및 업데이트되어야 합니다. 이를 통해 정책이 항상 최신 상태를 유지하고 조직의 요구사항을 반영할 수 있도록 해야 합니다.

2. 오픈소스 정책에서 다뤄야할 내용

오픈소스 정책은 다음과 같은 핵심 내용을 포함해야 합니다:

(1) 오픈소스 라이선스 컴플라이언스 원칙

오픈소스 라이선스 컴플라이언스를 위해 다음 원칙을 수립해야 합니다:

• 공급 소프트웨어에 포함된 모든 오픈소스를 식별하고 문서화
• 각 오픈소스의 라이선스 의무사항 파악 및 준수
• 라이선스 의무를 충족하는 컴플라이언스 산출물 생성
• 오픈소스 고지문 및 소스코드 공개 등 라이선스 의무 이행

(2) 오픈소스 보안 보증 원칙

오픈소스 보안 보증을 위해 다음 원칙을 수립해야 합니다:

• 공급 소프트웨어의 오픈소스 컴포넌트에 대한 알려진 취약점 및 새로 발견된 취약점 모니터링
• 취약점 발견 시 위험/영향 평가 수행
• 심각한 취약점에 대한 신속한 대응 및 패치 적용
• 취약점 정보의 고객 통지 및 업데이트 제공

(3) 오픈소스 리스크 대응

오픈소스 사용에 따른 라이선스 및 보안 리스크를 최소화하기 위해 다음 절차를 수립해야 합니다:

1. 오픈소스 식별 및 라이선스 의무 사항 검토
2. 오픈소스 라이선스를 고려한 아키텍처 설계
3. 오픈소스 컴플라이언스 산출물 생성
4. SBOM (Software Bill of Materials) 생성 및 관리
5. 오픈소스 라이선스 컴플라이언스 이슈 대응
6. 오픈소스 보안 취약점 대응

[부록1] 오픈소스 정책 template의 6. 오픈소스 사용에서 이를 문서화한 원칙을 살펴보실 수 있습니다.

1. 오픈소스 사용

공급 소프트웨어를 개발하고 배포할 때 각 오픈소스 라이선스가 요구하는 의무 사항을 준수해야 합니다. 이를 위한 활동을 오픈소스 라이선스 컴플라이언스라고 합니다.

올바른 오픈소스 라이선스 컴플라이언스 활동과 보안 보증을 위해 소프트웨어 개발/배포 조직은 다음 사항을 준수하고 모든 과정은 이슈 추적 시스템에 기록하여 보존합니다. 

(1) 오픈소스 식별 및 라이선스 의무 사항 검토

오픈소스를 공급 소프트웨어 개발에 도입 시, 먼저 오픈소스 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무 사항을 검토하고 확인합니다.

회사의 [오픈소스 라이선스 가이드]에는 주요 오픈소스 라이선스 목록이 포함되어 있으며, 라이선스마다 다음의 배포 형태별 요구하는 의무사항을 구분하여 설명합니다.

- 바이너리 형태
- 소스 형태
- 강한/약한 Copyleft
- SaaS 기반 제공
- 수정 여부
- 저작자 표시 요구 오픈소스 포함 등

소프트웨어 개발/배포 조직은 오픈소스 라이선스 의무 검토 시 이 가이드를 참고할 수 있습니다. 이 가이드에서 언급하지 않는 오픈소스 라이선스의 검토가 필요할 경우, 오픈소스 프로그램 매니저에게 문의합니다.

(2) 오픈소스 라이선스 고려 설계

오픈소스의 결합 관계를 파악하여 자사의 코드가 오픈소스 라이선스의 영향을 받지 않도록 소프트웨어 아키텍처를 설계합니다.

회사의 [오픈소스 라이선스 가이드]에서는 오픈소스 라이선스별 소스 코드 공개 범위 및 자사 코드의 공개를 방지하기 위한 설계 방법을 설명합니다.

(3) 오픈소스 컴플라이언스 산출물 생성

오픈소스 라이선스 컴플라이언스 활동의 가장 기본은 공급 소프트웨어에 포함된 오픈소스 현황을 파악하는 것입니다. 이는 바로 오픈소스 라이선스 컴플라이언스의 핵심인 오픈소스 라이선스 요구사항을 올바르게 충족하기 위해서입니다. 즉, 공급 소프트웨어에 포함된 오픈소스에 대한 컴플라이언스 산출물 세트를 생성해야 합니다.

오픈소스 컴플라이언스 산출물은 크게 두 가지로 구분됩니다.

1. 오픈소스 고지문 : 오픈소스 라이선스 전문과 저작권 정보 제공을 위한 문서
2. 공개할 소스 코드 패키지 : GPL, LGPL 등 소스 코드 공개를 요구하는 오픈소스 라이선스 의무 이행을 위해 공개할 소스 코드를 취합한 패키지

이러한 컴플라이언스 산출물을 취합, 배포, 보관하기 위해 다음 사항을 준수합니다.

- 오픈소스 고지문이나 공개할 소스 코드 패키지는 각 라이선스가 요구하는 조건대로 취합합니다. 예를 들어, 라이선스가 라이선스 전체 텍스트의 동봉을 요구하는데, 링크만을 제공해서는 안 됩니다.
- 취합한 산출물은 별도의 저장소에 보관합니다.
- 공개할 소스 코드를 서면 청약으로 제공할 경우, 취합한 산출물의 저장소를 외부에서 접근할 수 있도록 다운로드 링크를 공개합니다.
  
회사의 오픈소스 프로세스를 통해 오픈소스 고지문을 발급하고, 공개할 소스 코드 패키지를 취합할 수 있습니다.

(4) SBOM (Software Bill of Materials) 생성

공급 소프트웨어를 구성하는 각 오픈소스 소프트웨어 컴포넌트 내역을 포함하는 SBOM(Software Bill of Materials)을 생성하고 이를 유지하는 프로세스가 있어야 합니다.

회사의 오픈소스 프로세스를 통해 오픈소스 도구를 활용하여 SBOM을 생성하고 보존할 수 있습니다.

(5) 컴플라이언스 이슈 대응 절차

컴플라이언스 이슈가 제기될 경우, 오픈소스 프로그램 매니저는 다음의 절차를 수행하여 신속히 대응합니다.

1. 문의 접수를 확인하고 적절한 해결 시간을 명시합니다.
2. 이슈 내용이 실제 문제를 지적하고 있는지를 확인합니다. (아닐 경우, 이슈 제기자에게 문제가 아님을 알립니다.)
3. 실제 문제인 경우, 우선순위를 정하고 적절한 대응 방안을 결정합니다.
4. 대응을 수행하고, 필요할 경우, 오픈소스 프로세스를 적절하게 보완합니다.
5. 위의 내용은 이슈 추적 시스템을 이용하여 보존합니다.

(6) 오픈소스 보안 보증 관리

공급 소프트웨어의 오픈소스 소프트웨어 컴포넌트에 대한 알려진 취약점의 탐지 및 해결을 위한 문서화된 절차를 수립하고 유지해야 합니다. 이 절차에는 다음 사항이 포함되어야 합니다:

- 알려진 취약점의 존재를 발견하기 위한 방법 적용
- 각 발견된 취약점에 대한 위험/영향 평가
- 필요한 경우 고객에게 연락, 소프트웨어 컴포넌트 업그레이드 등 적절한 조치 수행

또한 다음과 같은 프로세스를 구축해야 합니다:

- 공급 소프트웨어에 대한 구조적 및 기술적 위협 식별
- 지속적이고 반복적인 보안 테스트 적용
- 식별된 위험이 공급 소프트웨어의 출시 전에 해결되었는지 확인
- 공급 소프트웨어가 시장에 출시된 후 모니터링 및 대응 기능 확보

각 오픈소스 소프트웨어 컴포넌트에 대해 식별된 알려진 취약점 및 새로 발견된 취약점, 그리고 수행된 조치에 대한 기록을 유지해야 합니다.

(4) 내부 책임 할당 절차

오픈소스 정책은 오픈소스 관리 이슈를 해결하기 위한 책임을 내부에 할당하는 절차를 다뤄야 합니다.

ISO 표준은 공통적으로 다음과 같이 내부 책임을 할당하는 문서화된 절차를 요구합니다.

오픈소스 프로그램 매니저는 라이선스 컴플라이언스 이슈를 파악하고 이를 해결하기 위해 각 역할의 담당자에게 적절히 책임을 할당해야 합니다. 마찬가지로 오픈소스 보안 취약점 이슈에 대해서는 보안 담당이 이슈를 파악하고 이를 해결하기 위해 적절한 인원에게 책임을 할당합니다.

이를 위해 아래의 예시와 같이 오픈소스 정책에 내부 책임을 할당하는 문서화된 절차를 반영할 수 있습니다.

4. 역할, 책임 및 역량

정책의 효과를 보장하기 위해 다음과 같이 역할과 책임 및 각 역할의 담당자가 갖추어야 할 역량을 정의합니다.

(2) 오픈소스 프로그램 매니저

- 오픈소스 라이선스 컴플라이언스를 위해 필요한 역할을 정의하고, 각 역할을 책임질 담당 조직 및 담당자를 지정합니다. 필요 시 OSRB와 협의합니다. 

(6) 보안 담당

- 오픈소스 보안 보증을 성공할 수 있도록 각 업무에 대한 책임을 할당합니다.

이러한 절차를 통해 오픈소스 라이선스 컴플라이언스와 보안 보증에 대한 내부 책임을 명확히 할당하고, 각 담당자가 자신의 역할을 이해하고 수행할 수 있도록 합니다. 또한 OSRB(Open Source Review Board)와의 협의를 통해 조직 전체의 오픈소스 전략과 일관성을 유지할 수 있습니다.

내부 책임 할당 절차는 정기적으로 검토하고 업데이트해야 하며, 조직의 구조나 프로젝트의 변화에 따라 유연하게 조정될 수 있어야 합니다. 이를 통해 오픈소스 관리의 효율성과 효과성을 지속적으로 개선할 수 있습니다.

(5) 미준수 사례 대응

기업은 오픈소스 라이선스 컴플라이언스 및 보안 보증 미준수 사례가 발생하면 이를 신속히 검토하고 대응하기 위한 절차를 문서화해야 합니다.

ISO/IEC 5230과 ISO/IEC 18974는 다음과 같이 미준수 사례를 검토하고 이를 수정하기 위한 문서화된 절차를 요구합니다.

이를 위해 기업은 아래의 예시와 같이 오픈소스 정책에 미준수 사례를 검토하고 이를 수정하기 위한 문서화된 절차를 반영할 수 있습니다.

6. 오픈소스 사용

(5) 컴플라이언스 및 보안 보증 이슈 대응 절차

라이선스 컴플라이언스 또는 보안 보증 이슈가 제기될 경우, 오픈소스 프로그램 매니저는 다음의 절차를 수행하여 신속히 대응합니다:

1. 문의 접수를 확인하고 적절한 해결 시간을 명시합니다.
2. 이슈 내용이 실제 문제를 지적하고 있는지를 확인합니다. (아닐 경우, 이슈 제기자에게 문제가 아님을 알립니다.)
3. 실제 문제인 경우, 우선순위를 정하고 적절한 대응 방안을 결정합니다.
   - 라이선스 컴플라이언스 이슈의 경우, 법무 담당과 협의하여 라이선스 의무 준수 방안을 수립합니다.
   - 보안 보증 이슈의 경우, 보안 담당과 협의하여 취약점 해결 방안을 수립합니다.
4. 대응을 수행하고, 필요할 경우 오픈소스 프로세스를 적절하게 보완합니다.
5. 위의 내용은 이슈 추적 시스템을 이용하여 기록하고 보존합니다.
6. 미준수 사례에 대한 근본 원인을 분석하고, 재발 방지를 위한 개선 계획을 수립합니다.
7. OSRB(Open Source Review Board)에 미준수 사례와 대응 결과를 보고하고, 필요시 정책 및 프로세스 개선 방안을 논의합니다.

이러한 절차를 통해 기업은 오픈소스 라이선스 컴플라이언스 및 보안 보증과 관련된 미준수 사례를 체계적으로 관리하고, 지속적인 개선을 도모할 수 있습니다. 또한, SPDX와 같은 표준화된 형식을 사용하여 라이선스 및 보안 정보를 관리하면, 미준수 사례를 더욱 효과적으로 식별하고 대응할 수 있습니다.

(6) 인원, 예산 지원

기업은 오픈소스 프로그램이 원활하게 기능을 수행할 수 있도록 충분한 리소스를 제공해야 합니다. 프로그램 내 각 역할을 담당하는 인원을 적합하게 배치하고, 충분한 예산과 업무 시간을 보장해야 합니다. 그렇지 않을 경우, 이를 보완할 수 있는 절차가 마련되어야 합니다.

ISO 표준은 공통적으로 다음과 같이 프로그램 내 각 역할을 담당하는 인원이 적합하게 배치되고, 예산이 적절하게 지원되어야 함을 요구합니다.

이를 위해 기업은 아래의 예시와 같이 오픈소스 정책에 인원, 예산 지원에 대한 내용을 반영할 수 있습니다:

4. 역할, 책임 및 역량

각 역할에 대한 담당 조직의 장은 조직 내 담당자를 지정하고, 담당자가 역할을 충실하게 수행할 수 있는 적절한 시간과 예산을 할당합니다.

- 각 역할의 담당자는 자신이 역할을 수행하면서 적절한 지원이 되지 않는다면 오픈소스 프로그램 매니저에게 문제를 제기해야 합니다.
- 오픈소스 프로그램 매니저는 해당 조직장과 문제 해결을 논의합니다. 적절하게 해결되지 않는다면, 오픈소스 프로그램 매니저는 OSRB에 문제 해결을 요청할 수 있습니다.
- OSRB는 상위 조직의 장에게 문제를 공유하고 해결을 요청합니다.

추가적으로, 기업은 다음과 같은 사항을 고려하여 인원 및 예산 지원을 강화할 수 있습니다:

1. 오픈소스 프로그램 매니저에게 전담 인력 할당
2. 오픈소스 라이선스 컴플라이언스 및 보안 보증을 위한 전문 도구 구매 예산 확보
3. 프로그램 참여자의 교육 및 역량 강화를 위한 예산 책정
4. 외부 전문가 자문을 위한 예산 할당
5. 정기적인 인력 및 예산 검토 프로세스 수립

이러한 지원을 통해 기업은 오픈소스 라이선스 컴플라이언스와 보안 보증 프로그램의 효과성을 높이고, ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 충족할 수 있습니다.

(7) 전문 자문 제공

기업은 각 역할의 담당자가 오픈소스 이슈를 해결하기 위해 전문적인 검토가 필요할 경우, 이에 대한 자문을 요청할 수 있는 방법을 제공해야 합니다.

ISO 표준은 공통적으로 다음과 같이 문제 해결을 위해 내부 또는 외부의 전문 자문을 이용할 수 있는 방법을 요구합니다.

오픈소스 라이선스 컴플라이언스 이슈에 대해서는 회사 내의 법무팀을 통해 우선 담당하고, 이슈가 첨예한 경우, 오픈소스 전문 변호사를 보유한 외부 법무 법인을 이용할 수 있습니다.

오픈소스 보안 취약점 이슈에 대해서는 회사 내 보안팀에서 우선 담당하고, 이슈가 복잡하고 첨예한 경우, 외부 보안 전문 기술 업체에 자문을 요청할 수 있습니다.

이를 위해 기업은 아래의 예시와 같이 오픈소스 정책에 자문을 제공하기 위한 내용을 반영할 수 있습니다.

4. 역할, 책임 및 역량

(4) 법무 담당

법무 담당은 오픈소스 라이선스와 의무를 해석하는 등 오픈소스 활용 과정에서 발생할 수 있는 법적 위험과 완화 방안에 대한 자문을 제공합니다.

- 프로그램 참여자가 오픈소스 라이선스 컴플라이언스 이슈에 대한 문의를 할 수 있는 합리적인 방법을 제공합니다.
- 호환되지 않는 오픈소스 라이선스로 인한 충돌을 포함하여 라이선스 및 지식재산권 문제에 대해 자문을 제공합니다.
- 외부 오픈소스 프로젝트로의 기여 시 오픈소스 라이선스, CLA(Contributor License Agreement) 등 필요한 법적 사항을 검토합니다.
- 이슈가 첨예한 경우, 오픈소스 전문 변호사를 보유한 외부 법무 법인에 자문을 요청합니다.

(6) 보안 담당

보안 담당은 오픈소스 보안 취약점 분석 도구를 운영하여 모든 공급 소프트웨어에 대해 보안 취약점 분석이 원활히 수행되도록 시스템을 구축합니다.

- 프로그램 참여자가 알려진 취약점 또는 새로 발견된 취약점에 대한 문의를 할 수 있는 합리적인 방법을 제공하고, 취약점 해결을 위해 필요 시 외부 전문 기술 자문을 이용합니다.

참고로, OpenChain 프로젝트에서는 파트너 프로그램을 통해 오픈소스 관련 자문을 제공하는 글로벌 법무법인 리스트를 제공합니다: https://www.openchainproject.org/partners

OpenChain 파트너로 등록된 법무법인은 OpenChain 프로젝트에서 요구하는 요건을 충족한 곳들이며, 대한민국에서는 유일하게 법무법인 태평양이 등록되어 있습니다.

(8) 적용 범위 지정

하나의 오픈소스 정책(프로그램)을 반드시 전체 조직에 적용해야 하는 것은 아닙니다. 기업 내 각 조직과 제품의 특성에 따라 적용 범위를 달리 지정할 수 있습니다. 예를 들어, 공급 소프트웨어를 전혀 배포하지 않는 조직은 오픈소스 프로그램의 적용 범위에서 제외할 수 있습니다.

ISO 표준은 공통적으로 다음과 같이 프로그램의 적용 범위와 한계를 명확하게 정의한 문서화된 진술 등을 요구합니다.

기업은 조직과 제품의 특성을 고려하여 오픈소스 프로그램의 적용 범위와 한계를 명확히 정의하고, 이를 오픈소스 정책에 명시해야 합니다.

또한, 비즈니스 환경에 맞추어 변화함에 따라 조직 구조, 제품 및 서비스가 프로그램의 적용 범위를 결정하거나 수정해야 하는 상황이 발생할 수 있습니다. 기업은 적용 범위를 평가하기 위한 측정 기준을 수립하고, 지속적인 개선을 위해 검토, 검사를 수행하여 미흡한 부분을 개선해야 합니다.

이를 위해 기업은 아래와 같이 오픈소스 정책에 다음과 같이 적용 범위에 대해 명확히 정의하고, 활동 이력을 문서화하는 체계를 갖춰야 합니다.

2. 적용 범위

이 정책은 다음 세 부분에 적용됩니다.

1. 회사가 외부로 제공하거나 배포하는 모든 공급 소프트웨어에 적용됩니다. 단, 오픈소스를 내부 사용 목적으로만 사용하는 것은 이 정책의 범위에 포함되지 않습니다.
2. 프로그램 참여자가 외부 오픈소스 프로젝트에 기여할 때 적용됩니다.
3. 내부 코드를 오픈소스로 공개할 때 적용됩니다.

적용 범위는 회사의 비즈니스 환경에 맞추어 변경할 수 있습니다. 특히, 오픈소스 프로그램 매니저는 지속적인 효과를 보장하기 위해 이 정책의 적용되지 않고 사외로 배포 혹은 서비스되는 공급 소프트웨어가 있는지 월 1회 이상 조사합니다. 이를 측정하여 1건이라도 발견 시 적용 범위를 변경해야 하는 기준으로 삼습니다.

적용 범위를 변경하기 위한 절차는 다음과 같습니다.

1. 오픈소스 프로그램 매니저는 신규사업, 조직개편 등 회사의 비즈니스 환경이 변화에 따라 정책의 적용 범위 변경이 필요하다고 판단할 경우, 이를 위한 제안을 OSRB에 제출합니다.
2. OSRB에서는 적절한 수준의 적용 범위 변경을 승인합니다.
3. OSRB는 오픈소스 정책을 수정하여 정책의 적용 범위를 변경합니다.

오픈소스 프로그램 매니저는 지속적으로 월 1회 이상 적용 범위를 개선하기 위해 검토, 업데이트 및 검사 이력을 [Jira](https://www.atlassian.com/software/jira) Issue Tracker를 활용하여 문서화합니다.

따라서 기업은 오픈소스 정책에 다음과 같이 적용 범위를 명확히 정의하고, 활동 이력을 문서화하는 체계를 갖춰야 합니다.

(9) 외부 문의 대응

오픈소스를 사용하여 개발한 공급 소프트웨어에 대해 고객 및 오픈소스 저작권자가 기업에 오픈소스 관련 문의, 요청 및 클레임을 제기하기 위해 연락을 취하는 경우가 있습니다. 외부 문의 및 요청의 주된 내용은 다음과 같습니다:

• 특정 공급 소프트웨어에 오픈소스가 사용되었는지 문의
• 서면 청약에 언급된 GPL, LGPL 라이선스 하의 소스 코드 제공 요청
• 오픈소스 고지문에 명시되지 않았지만, 공급 소프트웨어에서 발견된 오픈소스에 대한 해명 및 소스 코드 공개 요청
• GPL, LGPL 등의 의무로 공개된 소스 코드에 누락된 파일 및 빌드 방법 제공 요청
• 저작권 표시 요청
• 오픈소스 보안 취약점 관련한 문의 및 요청

기업은 이러한 외부 문의를 처리할 담당자를 지정해야 합니다. 일반적으로 오픈소스 프로그램 매니저가 담당합니다.

외부의 오픈소스 개발자가 특정 기업의 오픈소스 관련 이슈를 논의하기 위해 기업 담당자에게 연락하고 싶어도 연락 방법을 찾지 못하다가 결국 바로 법적 클레임을 제기하는 경우가 있습니다. 이를 방지하기 위해 기업은 제3자가 기업에 오픈소스 관련하여 문의 및 요청을 할 수 있는 연락 방법을 항시 공개적으로 밝혀야 합니다.

ISO 표준은 공통적으로 다음과 같이 제3자가 오픈소스에 대해 문의할 수 있는 공개된 방법을 요구합니다:

외부에서 기업에 오픈소스 관련 문의를 할 수 있도록 다음과 같이 연락 방법을 제공할 수 있습니다:

1. 오픈소스 담당 조직의 대표 이메일 주소를 공개합니다.
2. Linux Foundation의 Open Compliance Directory를 이용합니다.
3. 기업의 오픈소스 웹사이트가 있다면 이를 통해 이메일 주소를 공개합니다.

공급 소프트웨어와 동봉하는 오픈소스 고지문에 오픈소스 담당 조직의 대표 이메일 주소를 포함하여 공개하는 것도 좋은 방법입니다.

기업은 아래의 예시와 같이 오픈소스 정책에 외부 문의 대응에 대한 내용을 반영할 수 있습니다:

9. 외부 문의 대응

(1) 외부 문의 대응 책임

외부로부터 오픈소스에 대한 문의 및 요청에 대한 대응은 오픈소스 프로그램 매니저가 담당합니다.

- 오픈소스 프로그램 매니저는 회사 내의 적절한 프로그램 참여자에게 문의에 대한 전체 또는 일부의 처리를 할당할 수 있습니다. 필요할 경우 법률 담당자에게 문의하여 처리합니다.
- 외부로부터 오픈소스에 대한 문의를 받은 프로그램 참여자는 누구나 이를 오픈소스 프로그램 매니저에게 알려서 신속한 대응이 될 수 있게 합니다.

(2) 연락처 공개

오픈소스 프로그램 매니저는 외부에서 오픈소스 관련한 문의 및 요청을 할 수 있도록 담당자의 연락처를 공개적으로 제공합니다.

- 오픈소스 고지문에 연락받을 수 있는 이메일 주소 정보를 제공합니다.
- 오픈소스 웹사이트에 이메일 주소 정보를 제공합니다.
- Linux Foundation의 Open Compliance Directory에 연락처를 등록합니다.

(3) 외부 문의 대응 절차

외부로부터의 오픈소스 문의에 신속하고 정확하게 대응한다면 클레임이나 법적 소송 위험을 크게 줄일 수 있습니다. 이를 위해 회사는 외부의 오픈소스 문의에 대응하기 위해 회사의 오픈소스 프로세스에서 정의한 외부 문의 대응 절차를 준수합니다.

SK텔레콤은 모든 공급 소프트웨어에 오픈소스 고지문을 포함하고 있습니다. 오픈소스 고지문에는 SK텔레콤 오픈소스 웹사이트 주소와 오픈소스 프로그램 오피스로 연락할 수 있는 메일 주소가 함께 제공됩니다.

또한, SK텔레콤 오픈소스 웹사이트에서도 오픈소스 프로그램 오피스로 연락할 수 있는 메일 주소를 제공하고 있습니다.

(10) 오픈소스 기여

글로벌 소프트웨어 기업들은 제품을 만들고 서비스를 제공하는 데 오픈소스를 사용하는 것뿐만 아니라 오픈소스 프로젝트에 기여하고 창출할 수 있는 전략적 가치도 중요시합니다. 그러나 오픈소스 프로젝트 생태계와 커뮤니티 운영 방식에 대한 충분한 이해와 전략 없이 접근한다면 예기치 않게 회사의 명성이 손상되고 법적 위험이 발생할 수 있습니다. 따라서 기업은 오픈소스 프로젝트에 참여하고 기여하기 위한 전략과 정책을 수립하는 것이 중요합니다.

ISO/IEC 5230은 다음과 같이 문서화된 오픈소스 기여 정책을 요구합니다.

이러한 오픈소스 기여에 대한 정책은 [부록1] 오픈소스 정책 샘플 7. 오픈소스 기여에서 확인할 수 있습니다.

7. 오픈소스 기여

회사는 오픈소스에서의 비즈니스 가치 창출을 위해 외부 오픈소스 프로젝트로의 참여와 기여를 권장합니다. 그러나 이 과정에서 의도하지 않은 회사의 지식 재산 노출 혹은 제 3자의 권리 침해에 주의해야 합니다. 이를 위해 회사의 프로그램 참여자가 외부 오픈소스 프로젝트로의 기여를 위해서는 다음 사항을 준수해야 합니다.

(1) 리뷰 요청 및 승인

오픈소스 기여는 저작권 관점에서 저작자가 저작물을 수정/사용/배포할 수 있는 권한을 오픈소스 프로젝트에 부여하는 것입니다. 때에 따라서는 오픈소스 프로젝트에 저작권을 양도해야 하기도 합니다. 일반적으로 고용 기간에 만든 저작물의 저작권은 고용주가 소유합니다. 즉, 프로그램 참여자가 만든 저작물은 회사가 소유합니다. 프로그램 참여자가 임의로 저작물을 오픈소스에 기여하는 행위는 불필요한 저작권 침해 이슈를 유발할 수 있습니다.

따라서, 기여하고자 하는 오픈소스 프로젝트가 있다면 오픈소스 기여 프로세스에 따라 최초 기여하기 전에 리뷰 요청 및 승인 절차를 준수합니다.

단, 다음과 같이 단순한 내용일 경우, 저작권 침해 리스크가 크지 않기 때문에 리뷰 절차 없이 프로그램 참여자의 판단에 따라 기여할 수 있습니다.

- 10 라인 이하의 작은 코드 조각
- Stack Overflow에서의 문의 / 답변
- GitHub에서의 관리 활동 : Issue 생성, Pull Request Review / Approve 등

...

오픈소스 기여 정책에는 기여 절차, 승인 프로세스, 지식재산권 보호 방안, CLA (Contributor License Agreement) 서명 지침 등이 포함되어야 합니다. 또한 프로그램 참여자들이 회사를 대표하여 오픈소스 커뮤니티에 참여할 때의 행동 지침도 제공해야 합니다.

(11) SBOM 생성 및 관리

SBOM (Software Bill of Materials) 생성 및 관리 절차를 수립해야 합니다:

• SBOM 생성 도구 및 방법론 선정
• SBOM 정보의 정확성 및 완전성 보장
• SBOM 업데이트 및 버전 관리 프로세스 수립
• SBOM 공유 및 배포 방법 정의

기업은 아래의 예시와 같이 오픈소스 정책에 SBOM 생성 및 관리에 대한 내용을 반영할 수 있습니다:

6. 오픈소스 사용

(4) SBOM (Software Bill of Materials) 생성

공급 소프트웨어를 구성하는 각 오픈소스 소프트웨어 컴포넌트 내역을 포함하는 SBOM(Software Bill of Materials)을 생성하고 이를 유지하는 프로세스가 있어야 합니다.

회사의 오픈소스 프로세스를 통해 오픈소스 도구를 활용하여 SBOM을 생성하고 보존할 수 있습니다.

- SBOM은 [SPDX](https://spdx.dev/) 또는 [CycloneDX](https://cyclonedx.org/)와 같은 표준 형식을 사용하여 생성합니다.
- 모든 공급 소프트웨어에 대해 SBOM을 생성하고 관리합니다.
- SBOM은 공급 소프트웨어의 릴리스마다 업데이트하고 버전 관리합니다.
- SBOM 정보의 정확성을 주기적으로 검증합니다.
- 필요한 경우 고객 및 규제 기관과 SBOM을 공유할 수 있도록 준비합니다.

SBOM 생성 및 관리는 오픈소스 라이선스 컴플라이언스와 보안 보증을 위한 핵심 요소입니다. 이를 통해 기업은 사용 중인 오픈소스 컴포넌트를 정확히 파악하고, 알려진 취약점이나 라이선스 이슈에 신속하게 대응할 수 있습니다.

기업은 이러한 SBOM 관련 원칙을 오픈소스 정책에 포함하여, 체계적인 SBOM 관리 체계를 구축해야 합니다.

3. Summary

오픈소스 정책을 문서화하는 것은 효과적인 오픈소스 관리를 위해 가장 중요한 과정입니다.

다음 페이지에서 위에서 언급한 ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 충족하는 샘플 오픈소스 정책 문서를 제공합니다: [부록1] 오픈소스 정책 (template)

위의 내용을 참고하여 각 요구사항을 회사의 상황에 맞게 적절한 원칙을 수립하는 것이 필요합니다. 또한 문서로만 그치지 않고, 실행 가능한 절차까지 고려해야 합니다. 말뿐인 정책은 소용이 없습니다.

오픈소스 정책은 다음과 같은 핵심 요소를 포함해야 합니다:

1. 오픈소스 라이선스 컴플라이언스 원칙
2. 오픈소스 보안 보증 원칙
3. 오픈소스 리스크 대응 방안
4. 내부 책임 할당 절차
5. 미준수 사례 대응 방법
6. 인원 및 예산 지원 계획
7. 전문 자문 제공 방식
8. 정책의 적용 범위 지정
9. 외부 문의 대응 절차
10. 오픈소스 기여 가이드라인
11. SBOM(Software Bill of Materials) 생성 및 관리 방법

이러한 요소들을 포함하여 오픈소스 정책을 수립하고 문서화하면, ISO/IEC 5230과 ISO/IEC 18974 표준의 주요 요구사항을 충족할 수 있습니다.

정책은 단순히 문서화에 그치지 않고 조직 내에서 실제로 이행되어야 합니다. 이를 위해 정기적인 검토와 업데이트, 그리고 프로그램 참여자들의 교육이 필요합니다. 효과적인 오픈소스 정책은 조직의 오픈소스 사용과 기여를 체계적으로 관리하고, 잠재적인 법적 및 보안 위험을 최소화하는 데 도움을 줄 것입니다.