정책 on OpenChain KWG

§3.1.1 정책

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 1 — 기반 수립 단계에서 구축합니다. 전체 구축 로드맵 보기

1. 조항 개요

오픈소스 정책이 없는 기업은 개발자가 오픈소스 라이선스 의무를 인지하지 못한 채 소프트웨어를 배포하게 되며, 이는 저작권 침해 소송, 소스코드 강제 공개, 거래처 계약 해지 등 심각한 법적·사업적 위험으로 이어질 수 있다. §3.1.1은 이러한 위험을 예방하기 위해 오픈소스 라이선스 컴플라이언스를 관리하는 문서화된 정책을 수립하고, 조직 내 모든 프로그램 참여자가 정책의 존재를 인식할 수 있도록 전파할 것을 요구한다. 이 조항은 ISO/IEC 5230 프로그램 전체의 기반이 되며, 이후 모든 조항(역량·프로세스·산출물 등)은 이 정책 위에서 작동한다.

§4.1.1 정책

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 1 — 기반 수립 단계에서 구축합니다. 전체 구축 로드맵 보기

1. 조항 개요

§4.1.1은 ISO/IEC 5230 §3.1.1(라이선스 컴플라이언스 정책)과 대응하는 조항이지만, 초점이 보안 보증으로 전환된다. 오픈소스 컴포넌트의 알려진 취약점과 새로 발견되는 취약점을 체계적으로 관리하는 정책이 문서화되어 있어야 하며, 그 정책이 조직 내부에 전파되어야 한다. ISO/IEC 5230 §3.1.1과의 핵심 차이점은 정책과 전파 절차 자체에 대한 정기 검토 프로세스를 요구한다는 점이다. 정책을 수립하는 것에 그치지 않고, 정책이 항상 유효하고 최신 상태를 유지하도록 검토 체계를 갖추어야 한다.

3.1 정책

Mon, 01 Jan 0001 00:00:00 +0000

구축 단계

이 조항은 Phase 1 — 프로그램 기반 단계에서 구축한다. 전체 구축 로드맵 보기

1. 조항 개요

AI SBOM 정책이 없는 조직은 개발자가 모델과 데이터셋의 라이선스 의무를 인지하지 못한 채 AI 시스템을 배포하게 된다. AI에서는 추적할 대상이 코드를 넘어선다. 모델 가중치, 학습 데이터셋, 다른 모델에서 파생된 모델 트리가 각자 고유한 라이선스를 가지며, Llama 커뮤니티 라이선스나 RAIL 계열처럼 사용 목적을 제한하는 비표준 라이선스도 흔하다. 이런 의무를 놓치면 저작권 분쟁, 사용 제한 위반, 거래처 계약 해지로 이어진다.

Appendix

Mon, 01 Jan 0001 00:00:00 +0000

Appendix 1. 담당자 현황

No	역할	책임	필요 역량	담당 조직	담당자
1	오픈소스 프로그램 매니저 (OSPM)	회사의 오픈소스 프로그램에 대한 총괄 책임을 담당합니다.	소프트웨어 개발 프로세스 이해 저작권 및 특허 이해 오픈소스 라이선스 컴플라이언스 전문 지식 커뮤니케이션 스킬	오픈소스 관리팀	[이름]
2	법무 담당	오픈소스 라이선스와 관련된 법적 위험을 평가하고 법적 자문을 제공합니다.	오픈소스 생태계 이해 소프트웨어 저작권 전문 지식 오픈소스 라이선스 전문 지식 법적 위험 평가 능력	법무팀	[이름]
3	IT 담당	오픈소스 분석 도구를 운영하고 자동화합니다.	오픈소스 라이선스 컴플라이언스 프로세스 이해 오픈소스 분석 도구 이해 IT 인프라 전문 지식 자동화 및 CI/CD 파이프라인 이해	IT팀	[이름]
4	보안 담당	오픈소스 보안 취약점 분석 도구를 운영합니다.	DevSecOps 이해 오픈소스 보안 취약점 분석 도구 이해 알려진 취약점 및 새로 발견된 취약점 전문 지식 위험 평가 및 관리 능력	보안팀	[이름]
5	개발 문화 담당	사내 개발자들이 오픈소스를 적극적으로 활용하도록 지원합니다.	소프트웨어 개발 프로세스 이해 오픈소스 라이선스 컴플라이언스 기본 지식 교육 및 트레이닝 설계 능력 오픈소스 커뮤니티 참여 경험	개발팀	[이름]
6	품질 담당	공급 소프트웨어 배포 시 오픈소스 라이선스 의무를 확인합니다.	소프트웨어 개발 프로세스 이해 오픈소스 라이선스 컴플라이언스 기본 지식 오픈소스 정책 이해 오픈소스 라이선스 기본 지식	품질보증팀	[이름]
7	OSRB (Open Source Review Board)	오픈소스 관리를 위한 정책과 프로세스를 수립 및 개선합니다.	오픈소스 정책 및 프로세스 전문 지식 협의체 운영 경험	OSRB	[이름]
8	OSPO (Open Source Program Office)	외부 오픈소스 프로젝트로의 기여와 사내 프로젝트 오픈소스 공개를 지원합니다.	오픈소스 커뮤니티 참여 경험 오픈소스 프로젝트 관리 능력	OSPO	[이름]

오픈소스 정책

Mon, 01 Jan 0001 00:00:00 +0000

Note:

This sample open source policy was written with reference to the following two materials.

Author : OpenChain Korea Work Group Authors / CC BY 4.0

1. 목적 및 적용 범위

1.1 목적

이 정책은 회사가 오픈소스 소프트웨어를 안전하고 효과적으로 활용하기 위한 원칙과 절차를 제공합니다. 정책의 주요 목적은 다음과 같습니다:

오픈소스 라이선스 컴플라이언스:
- 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 라이선스 의무를 준수하고, 관련 법적 요구사항을 충족합니다.
오픈소스 보안 보증:
- 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을 식별하고, 적절한 대응 조치를 통해 보안 위험을 최소화합니다.
외부 오픈소스 프로젝트로의 기여:
- 외부 오픈소스 프로젝트에 기여함으로써 오픈소스 커뮤니티와의 협업을 촉진하고, 회사의 지식재산을 보호합니다.
사내 프로젝트의 오픈소스화:
- 내부 프로젝트를 오픈소스로 공개하여 오픈소스 커뮤니티와의 협력을 증진시키고, 회사의 기술력을 홍보합니다.

이러한 원칙은 ISO/IEC 5230(오픈소스 라이선스 컴플라이언스) 및 ISO/IEC 18974(오픈소스 보안 보증)의 요구사항을 충족하도록 설계되었습니다.

2. 정책

Mon, 01 Jan 0001 00:00:00 +0000

이 섹션이 다루는 요구사항

ISO/IEC 5230: 3.1.1.1, 3.1.4.1, 3.2.1.1, 3.2.2.2, 3.2.2.3, 3.2.2.4, 3.2.2.5, 3.5.1.1
ISO/IEC 18974: 4.1.1.1, 4.1.4.1, 4.1.4.2, 4.1.4.3, 4.2.1.1, 4.2.2.2, 4.2.2.3, 4.2.2.4

금융권이라면

금융권은 정책에 폐쇄망 반입 통제, 망분리 예외 자체 위험평가, 외주·전자금융보조업자의 SBOM 제출 요구 같은 고유 항목을 더해야 한다. 금융 변형 정책의 골격과 절차는 금융분야 오픈소스 관리 실무 가이드에서 다룬다.

1. 오픈소스 정책 문서화

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

정책·절차 템플릿

Mon, 01 Jan 0001 00:00:00 +0000

여기 담은 양식은 금융권 고유 항목을 보강한 골격이다. 일반 오픈소스 정책과 프로세스 양식은 기존 정책·절차 템플릿 가이드를 쓰고, 금융권에서 추가로 필요한 반입 통제, 망분리 예외 위험평가, 외주 SBOM 요구는 아래 양식으로 채운다.

활용 안내

아래 골격은 그대로 쓰는 완성본이 아니라 채워 넣을 틀이다. 대괄호로 표시한 부분은 조직 상황에 맞게 바꾼다. 발행 전 사내 법무·보안 검토를 거친다.

금융 오픈소스 정책 (보강 항목)

기존 오픈소스 정책에 금융권 고유 항목을 더한다. 아래는 정책에 포함할 항목의 골격이다.