Templates

• 1: 오픈소스 정책
• 2: 오픈소스 프로세스

1 - 오픈소스 정책

1. 목적

(1) 정책의 목적

이 정책은 OOO 주식회사(이하 “회사"라 함)에서 소프트웨어 개발, 서비스, 배포에 관여하는 전체 조직이 올바르게 오픈소스 소프트웨어(이하 “오픈소스"라 함)를 활용하기 위해 다음과 같은 원칙을 제공합니다.

1. 오픈소스 컴플라이언스 / 보안 보증 원칙
2. 외부 오픈소스 프로젝트로의 기여 원칙
3. 사내 프로젝트를 오픈소스로 공개하기 위한 원칙

이러한 원칙은 회사의 모든 구성원이 오픈소스의 가치를 이해하고, 오픈소스를 올바르게 사용하며, 오픈소스 커뮤니티에 기여하기 위한 방법을 제공합니다.

회사의 모든 구성원은 사내 위키의 다음 링크에서 오픈소스 정책을 확인할 수 있습니다 : [internal_link]

(2) 미준수 시 영향

이 정책을 준수하지 않는다면 다음과 같은 상황이 발생할 수 있습니다.

• 외부로부터 오픈소스 라이선스 준수 요구를 받을 수 있습니다.
• 회사가 개발한 소스 코드를 원치 않게 공개해야 할 수 있습니다.
• 오픈소스 저작권자로부터 법적 소송을 제기당할 수 있습니다.
• 저작권 침해 및 계약 위반으로 벌금을 부과받거나, 제품 판매 중지 명령을 받을 수 있습니다.
• 회사 평판이 손상될 수 있습니다.
• 공급업체와의 계약 위반이 되어 손해배상 청구를 받을 수 있습니다.
• 심각한 보안 사고에 노출되어 회사에 막대한 손해를 입힐 수 있습니다.

이러한 이유로 회사는 오픈소스 정책의 위반을 심각하게 간주하며, 이를 위반하는 구성원이나 조직은 징계 절차에 처할 수 있습니다.

(3) 구성원의 기여 방법

회사의 모든 구성원은 이 정책의 근거와 내용을 이해하고 필요한 활동을 충실히 수행함으로써 정책의 효과 및 회사의 컴플라이언스 수준 향상에 기여할 수 있습니다.

2. 적용 범위

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

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

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

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

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

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

3. 용어

• SBOM (Software Bill of Materials) : 소프트웨어 구성 요소 목록
• 소프트웨어 배포 참여자 : 회사가 소프트웨어를 개발하고 배포, 기여하는 데 관여하는 모든 직원을 의미하며, 소프트웨어 개발자, 배포 엔지니어, 품질 엔지니어 등을 포함합니다.
• …

4. 역할, 책임 및 역량

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

각 역할의 담당 조직/담당자와 필요 역량 수준은 [부록 1. 담당자 현황]에서 정의합니다.

• 오픈소스 프로그램 매니저는 회사의 비즈니스 상황에 맞추어 주기적으로 명단을 업데이트합니다.
• 각 역할에 대한 담당 조직의 장은 조직 내 담당자를 지정하고, 담당자가 역할을 충실하게 수행할 수 있는 적절한 시간과 예산을 할당합니다.
  • 각 역할의 담당자는 자신이 역할을 수행하면서 적절한 지원이 되지 않는다면 오픈소스 프로그램 매니저에게 문제를 제기해야 합니다.
  • 오픈소스 프로그램 매니저는 해당 조직장과 문제 해결을 논의합니다. 적절하게 해결되지 않는다면, 오픈소스 프로그램 매니저는 OSRB에 문제 해결을 요청할 수 있습니다.
  • OSRB는 상위 조직의 장에게 문제를 공유하고 해결을 요청합니다.

(1) OSRB

OSRB(Open Source Review Board)는 회사의 오픈소스 관리를 위해 오픈소스 프로그램 매니저와 법무팀, 특허팀, 개발팀, 인프라팀 등 관련 조직의 책임자로 구성된 협의체입니다.

• OSRB는 오픈소스 관리를 위한 정책과 프로세스를 수립하고, 이를 수행하기 위한 회사 내의 역할과 책임을 정의합니다.
• OSRB는 매년 정기적으로 검토하여 정책과 프로세스를 개선합니다. 모든 개선 과정은 문서화하여 기록합니다.
  • OSRB는 회사의 프로세스 수행 성과와 미흡한 부분, 모범 사례를 분석하고 비즈니스 환경을 반영하여 항상 현행화합니다.
  • 오픈소스 컴플라이언스를 위한 정책과 프로세스는 오픈소스 프로그램 매니저가 책임을 갖고 관리합니다.
  • 오픈소스 보안 보증을 위한 정책과 프로세스는 보안 담당이 책임을 갖고 관리합니다.
• OSRB는 회사 내 오픈소스 이슈 발생 시, 해결 방안을 논의하고, 대응책을 마련합니다.
• OSRB는 필요 시, 임원진에 이슈를 보고하여 리스크 완화 방안에 대한 피드백을 받습니다.

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

오픈소스 프로그램 매니저는 회사의 오픈소스 프로그램에 대한 총괄 책임을 담당합니다. 오픈소스를 사용한 제품과 서비스의 오픈소스 관리 활동을 보장하기 위해 다음 사항에 대한 책임이 있습니다.

• 오픈소스 컴플라이언스를 위해 필요한 역할을 정의하고, 각 역할을 책임질 담당 조직 및 담당자를 지정합니다. 필요 시 OSRB와 협의합니다. 오픈소스 보안 보증을 위한 내부 책임은 보안 담당자가 할당합니다.
• 오픈소스 교육을 주관하고 평가합니다.
• OSRB의 의장을 맡아서 활동을 지휘합니다.
• 외부로부터의 오픈소스 사용 및 컴플라이언스 관련 문의 및 요청에 대응합니다.
• 오픈소스 사용 요청을 검토하고 승인합니다.
• SBOM 기록을 유지합니다.
• 구성원이 오픈소스 관련 자문을 받는 방법을 제공합니다.
• 오픈소스 고지 및 소스 코드 공개를 위한 저장소를 유지합니다.

(3) OSPO

OSPO(Open Source Program Office)는 회사 안팎으로 오픈소스 활동의 성장을 위해 지원하고 육성하는 역할을 합니다.

• 외부 오픈소스 프로젝트로의 코드 기여를 위한 가이드를 제공합니다.
• 사내 프로젝트를 오픈소스로 공개하기 위한 가이드를 제공합니다.
• 오픈소스 포털을 개발하고 운영합니다.
• 오픈소스 도구를 개발하고 선택합니다.
• 오픈소스 프로젝트 이벤트를 후원합니다.
• 오픈소스 커뮤니티와의 관계를 관리합니다.

(4) 법무 담당

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

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

(5) IT 담당

IT 담당은 오픈소스 분석 도구를 운영하고 자동화하여 모든 배포용 소프트웨어에 대해 오픈소스 분석이 원활히 수행되도록 시스템을 구축합니다.

• 오픈소스 분석 도구를 운영합니다.
• DevOps 환경과 통합하여 오픈소스 분석을 자동화합니다.
• 모든 배포용 소프트웨어를 대상으로 오픈소스 분석이 수행되도록 시스템과 프로세스를 구축합니다.
• 모든 배포용 소프트웨어에 대한 SBOM을 확보하고 유지합니다.

(6) 보안 담당

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

• 오픈소스 보안 보증을 성공할 수 있도록 각 업무에 대한 책임을 할당합니다.
• 오픈소스 보안 취약점 분석 도구를 운영합니다.
• DevSecOps 환경과 통합하여 오픈소스 보안 취약점 분석을 자동화합니다.
• 모든 배포용 소프트웨어를 대상으로 오픈소스 보안 취약점 분석이 수행되도록 시스템과 프로세스를 구축합니다.
• 구성원이 보안 취약점에 대한 문의를 할 수 있는 합리적인 방법을 제공하고, 취약점 해결을 위해 필요 시 외부 전문 기술 자문을 이용합니다.

(7) 개발 문화 담당

개발 문화 담당은 사내 개발자들이 오픈소스를 적극적으로 활용하고 사내외 커뮤니티에 참여하여 선진 개발 문화를 습득할 수 있도록 지원합니다.

• 오픈소스 커뮤니티로의 참여를 장려합니다.
• 활발한 외부 오픈소스 프로젝트 활동을 사내 성과로 인정할 수 있는 문화를 조성합니다.
• 오픈소스 개발자들에게 매력 있는 회사로 인식될 수 있는 개발 문화를 만들어갑니다.

(8) 품질 담당

QA 등 품질을 담당하는 조직은 소프트웨어 배포 시 오픈소스 라이선스 의무를 적절히 수행하였는지 확인합니다.

• 개발 프로세스 단계에 맞추어 오픈소스 관리 활동이 수행되었는지 확인합니다.
• 오픈소스 라이선스가 요구하는 대로 산출물을 생성하였는지 확인합니다.
• 소프트웨어 배포 시 오픈소스 고지문과 공개할 소스 코드를 함께 제공하는지 확인합니다.
• 이슈가 있으면 소프트웨어 개발/배포 조직에 통보하여 즉시 이슈를 수정하도록 안내합니다.

5. 교육 및 평가

4장에서 정의한 각 역할을 담당하는 모든 구성원은 [Learning Portal]에서 제공하는 오픈소스 교육 고급 과정을 수강해야 합니다. 이를 통해 오픈소스 정책, 관련 교육 정책 및 조회 방법을 숙지합니다.

교육 이력과 평가 결과는 [Learning Portal]에 최소 3년간 보존합니다.

6. 오픈소스 사용

오픈소스를 사용하여 제품 및 서비스를 개발하고 배포하려면 각 오픈소스 라이선스가 요구하는 의무 사항을 준수해야 합니다. 이를 위한 활동을 오픈소스 컴플라이언스라고 합니다.

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

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

오픈소스를 제품 / 서비스 개발에 도입 시, 먼저 오픈소스 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무 사항을 검토하고 확인합니다.

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

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

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

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

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

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

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

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

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

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

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

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

회사의 오픈소스 프로세스를 통해 오픈소스 고지문을 발급하고, 공개할 소스 코드 패키지를 취합할 수 있습니다.

(4) SBOM (Bill of Materials) 생성

배포용 소프트웨어에 포함된 오픈소스 현황(BOM : Bill of Materials)을 생성하고 관리해야 합니다.

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

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

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

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

(6) 오픈소스 보안취약점 대응

• 오픈소스 취약점을 식별하고, 심각도를 평가합니다.
• 오픈소스 취약점 분석 결과에 따라 취약점을 수정하거나 보안 패치를 적용합니다. 취약점 조치는 취약점의 심각도, 시스템의 중요도, 취약점 수정 또는 보안 패치의 가용성 등을 고려하여 결정합니다.
• 새로운 오픈소스 보안 취약점이 발표되는 것을 감시하고, 취약점 발생 시 신속하게 대응합니다. 오픈소스 취약점 모니터링은 CVE와 같은 취약점 데이터베이스, 보안 전문 기관의 웹사이트 등을 통해 수행할 수 있습니다.

7. 오픈소스 기여

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

(1) 리뷰 요청 및 승인

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

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

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

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

(2) 기여할 권리가 있는 코드만 기여

기여할 권리가 있는 코드만 기여해야 합니다. 즉, 직접 작성한 코드를 기여합니다. 제 3자의 코드를 임의로 기여해서는 안 됩니다.

(3) 지식 재산 노출 주의

민감한 정보, 특허 등 회사의 지식재산 노출이 우려되는 코드, 문서는 기여하지 않습니다.

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

(4) CLA 서명 주의

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

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

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

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

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

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

(5) 저작권 표시

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

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

Copyright (c) {$year} {$Company}
SPDX-License-Identifier: {$SPDX_license_name}

여기서 $SPDX_license_name은 해당 오픈소스 프로젝트의 라이선스 정책에 따라 작성합니다.

단, 버그 수정 등의 목적으로 기존 코드를 수정하는 정도라면 해당 코드 수정에 대해 저작권을 표기할 필요는 없습니다.

(6) 회사 이메일 사용

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

8. 오픈소스 공개

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

(1) 승인

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

따라서, 소프트웨어를 오픈소스로 공개하고자 한다면 회사 오픈소스 공개 정책에 따라 리뷰 요청 및 승인 절차를 따릅니다.

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

(2) 공개할 권리가 있는 코드만 공개

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

(3) 지식 재산 노출에 주의

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

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

(4) 유용한 코드 공개

성공적인 프로젝트가 되기 위해서는 다른 사람들에게도 유용해야 합니다. 만약, 유사한 프로젝트가 이미 존재한다면, 새로운 프로젝트를 만드는 것보다 기존의 프로젝트에 참여합니다.

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

• 실제 제품이나 서비스에 사용하지 못한 코드라면 오픈소스로도 공개하지 않습니다.
• 오픈소스 커뮤니티에서 이미 해결한 문제를 다루는 코드는 공개하지 않습니다. 이런 경우라면, 기존의 오픈소스 프로젝트에 기여합니다.

(5) 리소스 확보

프로젝트에 투입해야 할 리소스를 확보합니다.

• 초기에는 일반적인 사내 프로젝트와 비슷한 수준의 개발자가 필요합니다.
• 외부의 기여를 신속하게 리뷰할 수 있는 개발자가 필요합니다.
• 법무팀과 마케팅팀의 역할도 필요합니다.

프로젝트를 유지하고 관리하는 데 필요한 인프라에 대한 예산을 확보합니다. 여기에는 GitHub와 같은 프로젝트 호스팅 도구가 포함됩니다. 충분한 리소스를 지원할 수 있는 환경을 조성할 수 없다면 오픈소스로 공개하지 않습니다.

(6) 회사 이메일 사용

오픈소스 공개 활동 시 개인 이메일을 사용하지 말고 회사 이메일을 사용합니다. 이를 통해 다음과 같은 이점이 있습니다.

• 구성원은 회사를 대표하여 커뮤니티와 커뮤니케이션한다는 책임감을 갖게 됩니다.
• 회사는 오픈소스 커뮤니티에 공개 활동을 활발히 하는 기업으로 인지도를 개선할 수 있습니다.

9. 외부 문의 대응

(1) 외부 문의 대응 책임

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

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

(2) 연락처 공개

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

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

(3) 외부 문의 대응 절차

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

10. ISO 표준 준수 선언과 유지

회사는 소프트웨어 공급망에서의 오픈소스 컴플라이언스 수준 향상을 위해 Linux Foundation의 OpenChain 프로젝트의 정신을 지지하며 적극적으로 참여합니다.

• 회사는 이 오픈소스 정책을 적용하여 2021년 10월 1일부로 ISO/IEC 5230:2020을 준수함을 보장합니다.
• 회사는 적합성 인증을 획득한 후 18개월 이상 OpenChain 규격 버전 2.1, ISO/IEC 5230:2020의 모든 요구사항을 충족함을 보장합니다.
• 회사는 최소 18개월 간격으로 적합성을 검토하고 필요에 따라 정책을 변경 및 갱신합니다.

Appendix 1. 담당자 현황

2 - 오픈소스 프로세스

OO 회사(이하 “회사"라 함)는 소프트웨어를 포함하는 제품과 서비스를 개발하면서 오픈소스 소프트웨어를 적극적으로 활용합니다. 회사는 오픈소스 리스크를 최소화하기 위해 소프트웨어를 배포하면서 (1) 오픈소스 라이선스가 부과하는 의무사항을 준수하기 위한 활동과 (2) 오픈소스 보안 취약점을 검출하고 후속 조치를 위한 적절한 활동을 수행해야 합니다. 이러한 활동을 보장하기 위해 오픈소스 프로세스를 따릅니다.

1. 오픈소스 프로세스

오픈소스 프로세스는 회사가 소프트웨어 제품 및 서비스를 개발하고 배포하기 위한 각 개발 단계에 맞게 오픈소스 라이선스 의무 준수와 오픈소스 보안 취약점 해결을 위해 수행해야 할 절차를 정의합니다. 소프트웨어 제품 개발/배포에 관여하는 모든 구성원은 다음의 오픈소스 프로세스 11단계를 준수합니다.

회사는 오픈소스 프로세스를 통해 오픈소스 리스크를 최소화하고, 고객에게 안전하고 안정적인 소프트웨어 제품과 서비스를 제공하기 위해 노력합니다.

오픈소스 프로그램 매니저는 프로세스를 1년에 한 번 이상 주기적으로 검토하여 내부 모범 사례는 확산 전파하고, 미흡한 부분은 보완할 수 있도록 개선해야 합니다.

(1) 오픈소스 식별_{Identification of Open Source}

사업 부서는 소프트웨어 설계 단계에서 다음 사항을 준수합니다.

• 소프트웨어를 설계하면서 예측 가능한 오픈소스 사용 현황을 파악하고 라이선스를 확인합니다.
• 오픈소스 라이선스별 의무 사항을 확인합니다. 라이선스별 의무 사항은 회사의 오픈소스 라이선스 가이드에서 확인할 수 있습니다. : https://sktelecom.github.io/guide/use/obligation/
• 각 오픈소스 라이선스의 소스 코드 공개 범위를 고려하여 소프트웨어를 설계합니다.

오픈소스 프로그램 매니저는 주요 오픈소스 라이선스 의무, 제한, 권리에 대한 가이드를 작성하고 공개하여 전사의 사업 부서에서 참고할 수 있도록 합니다. 이 가이드에는 일반적인 오픈소스 라이선스의 사용 사례가 관리될 수 있도록 다음과 같은 사용 사례가 포함되어야 합니다.

• 바이너리 형태로 배포
• 소스 형태로 배포
• 추가 라이선스 의무를 유발하는 다른 오픈소스와 통합
• 수정된 오픈소스 포함

사업 부서는 회사 규칙에 맞게 소스 코드에 저작권 및 라이선스를 표기합니다. 회사의 소스 코드 내 저작권 및 라이선스 표기 규칙은 다음 페이지에서 확인할 수 있습니다. (insert_link)

사업 부서는 새로운 오픈소스 도입 검토 시, 먼저 라이선스를 식별합니다. 회사의 오픈소스 라이선스 가이드에 따라 라이선스 의무, 제한 및 권리를 확인합니다. 회사의 오픈소스 라이선스 가이드에서 설명하지 않는 라이선스일 경우, 오픈소스 프로그램 매니저에게 도입 가능 여부 및 주의 사항을 문의합니다. 문의를 위해서 Jira Ticket을 생성합니다.

오픈소스 프로그램 매니저는 오픈소스 라이선스 의무를 분석하여 소프트웨어 개발 조직에 안내합니다.

• 의문이 있는 경우, 법무 담당에 자문을 요청하여 명확한 가이드를 제공합니다.
• 새롭게 분석한 라이선스 정보는 전사 라이선스 가이드에 반영합니다.

보안 담당은 회사의 보안 보증을 위한 가이드를 제공합니다.

(2) 소스 코드 검사_{Auditing Source Code}

사업 부서는 IT 담당자의 안내에 따라 오픈소스 점검을 요청하고 소스 코드를 제공합니다.

IT 담당은 오픈소스 분석 도구를 사용하여 오픈소스 점검을 하고, SBOM(Software Bill of Materials)을 생성합니다.

오픈소스 프로그램 매니저는 오픈소스 라이선스 의무 준수 가능 여부, 오픈소스 라이선스 충돌 여부를 검토하고, 이슈가 있으면 사업 부서에 해결을 요청합니다. 이슈 사항은 Jira Ticket으로 생성하여 사업 부서에 할당합니다.

보안 담당은 검출된 알려진 취약점을 검토하고 사전 정의한 Risk 분류 기준에 따라 사업 부서에 대응 가이드를 제공합니다. Risk는 CVSS(Common Vulnerability Scoring System) Score로 분류하며, Critical Risk는 1주 이내 조치할 수 있는 계획을 수립하도록 안내합니다.

(3) 문제 해결_{Resolving Issues}

사업 부서는 소스 코드 검사 단계에서 발견된 모든 문제를 해결합니다.

이슈가 된 오픈소스를 제거하거나, 다른 라이선스 하의 오픈소스로 교체합니다. 보안 취약점 이슈의 경우 알려진 취약점이 수정된 버전으로 교체하는 등의 조치를 취합니다.

사업 부서는 발견된 모든 이슈를 해결하면 Jira Ticket 이슈를 Resolve하고, 재검토를 요청합니다.

(4) 검토_Reviews

오픈소스 프로그램 매니저는 모든 이슈가 적절하게 보완되었는지 검토합니다. 필요할 경우, 오픈소스 분석 도구를 사용하여 소스 코드 검사를 재수행합니다.

보안 담당은 심각한 취약점이 모두 해결되었는지 검토합니다. 해결하기 어려운 취약점이 남아 있을 경우, 비즈니스 형태와 서비스 노출 현황 등을 고려하여 승인 가능 여부를 검토합니다.

(5) 승인_Approval

오픈소스 프로그램 매니저는 오픈소스 컴플라이언스 절차가 적절하게 수행되었는지 최종 승인하거나 거절합니다. 거절 시에는 이유에 대한 설명과 수정 방법을 사업 부서에 제안합니다.

(6) 등록_Registration

오픈소스 프로그램 매니저는 소프트웨어의 버전별 오픈소스 사용 목록을 추적하기 위한 BOM을 확정합니다.

IT 담당은 확정된 BOM을 시스템에 등록합니다. BOM에는 배포용 소프트웨어에 포함된 오픈소스 목록과 다음과 같은 정보를 포함합니다.

• 배포용 소프트웨어의 제품(혹은 서비스) 이름과 버전
• 오픈소스 목록
  • 오픈소스 이름 / 버전
  • 오픈소스 라이선스

오픈소스 프로그램 매니저는 소프트웨어의 버전별 오픈소스 사용 목록을 추적하기 위한 BOM을 확정합니다.

(7) 고지_Notices

오픈소스 프로그램 매니저는 고지 의무를 준수하기 위해 오픈소스 고지문을 생성합니다. 오픈소스 고지문에는 다음과 같은 내용이 포함됩니다.

• 오픈소스 관련 문의할 수 있는 오픈소스 연락처
• 오픈소스별 고지 내용
  • 저작권
  • 오픈소스 라이선스 이름
  • 오픈소스 라이선스 사본
  • (해당하는 경우) 소스 코드 사본을 얻을 수 있는 서면 약정 (Written Offer)

오픈소스 프로그램 매니저는 오픈소스 고지문을 생성하여 사업 부서에 전달합니다. 이때 소스 코드 공개가 필요할 경우 사업 부서에 공개할 소스 코드 취합 방법을 안내합니다.

사업 부서는 오픈소스 고지문을 제품 배포 시 동봉합니다. 화면이 있는 제품일 경우, 사용자가 메뉴를 통해 확인할 수 있도록 조치합니다. (예: 앱 > 메뉴 > 설정 > 저작권 정보 > 오픈소스 라이선스)

사업 부서는 GPL, LGPL 등 소스 코드 공개를 요구하는 라이선스 하의 오픈소스를 사용하였을 경우, 이에 대한 소스 코드 공개 범위를 확인하여 공개할 소스 코드를 취합합니다.

• GPL, LGPL 등의 라이선스 의무 준수를 위해 취합한 소스 코드는 제품에 탑재된 바이너리를 구성하는 소스 코드와 일치해야 합니다. 즉, 취합한 소스 코드를 빌드하면 제품에 탑재된 바이너리와 동일해야 합니다.

(8) 배포 전 확인_{Pre-Distribution Verifications}

사업 부서는 오픈소스 컴플라이언스 활동이 적절히 수행되었음을 입증하는 다음의 산출물을 제출합니다.

1. 제품에 포함한 최종 오픈소스 고지문
2. 제품에 오픈소스 고지문이 포함되었음을 확인하는 자료 (예: 오픈소스 고지문을 보여주는 화면 캡처 이미지)
3. (해당할 경우) 공개할 소스 코드 (하나의 파일로 압축하여 제출)

오픈소스 프로그램 매니저는 사업 부서가 제출한 자료를 검토하여 이상 여부를 확인합니다.

(9) 배포_Distribution

오픈소스 프로그램 매니저는 사업 부서가 제출한 컴플라이언스 산출물을 IT 담당자에게 제출합니다.

IT 담당은 컴플라이언스 산출물을 회사의 오픈소스 배포 사이트에 등록합니다.

(10) 최종 확인_{Final Verifications}

오픈소스 프로그램 매니저는 컴플라이언스 산출물이 이상 없이 회사의 오픈소스 포털에 등록되었는지, 외부에서 이상 없이 다운로드가 되는지 등 종합적인 확인을 합니다.

(11) 모니터링_Monitoring

오픈소스 프로그램 매니저는 오픈소스 컴플라이언스 산출물 생성이 미흡한 제품이 있는지 주기적으로 확인합니다. 그리고, 외부 문의에 신속하게 대응하기 위한 프로세스를 운영합니다. 외부 문의 대응 프로세스의 자세한 절차는 [2. 외부 문의 대응 프로세스]를 따릅니다.

보안 담당은 새롭게 알려진 취약점을 모니터링하고 대응하기 위한 프로세스를 운영합니다. 신규 보안 취약점 대응 프로세스의 자세한 절차는 [3. 신규 보안 취약점 대응 프로세스]를 따릅니다.

2. 신규 보안취약점 대응 프로세스

제품/서비스가 시장에 출시된 후 새롭게 보안 취약점이 보고될 경우 위험도에 따라 적절한 조치를 취하기 위해 다음과 같은 프로세스를 준수합니다.

(1) 모니터링

IT 담당은 새로운 보안 취약점을 모니터링하는 시스템을 구축하여 운영합니다. 이 시스템은 다음과 같은 기능을 수행합니다.

• 새로운 보안 취약점이 공개되는 것을 주기적으로 수집합니다.
• 새로운 알려진 취약점을 갖고 있는 오픈소스가 이미 출시된 제품/서비스에 사용된 경우, 해당 제품/서비스의 사업 부서 담당자에게 알림을 보냅니다. 이때 알림부터 검토, 조치, 해결 사항이 모두 문서화되어 기록될 수 있도록 Jira Issue Tracker를 사용합니다.

(2) 초기 대응

보안 담당은 사전 정의한 위험 분류 기준에 따라 사업 부서에 대응 가이드를 제공합니다. 위험은 CVSS(Common Vulnerability Scoring System) 점수로 분류하며, Critical Risk는 1주 이내에 조치할 수 있는 계획을 수립하도록 안내합니다.

사업 부서는 기존 출시한 제품/서비스에 새로운 보안 취약점이 발견된 경우, 보안 담당자가 제공한 대응 가이드에 따라 조치 계획을 수립합니다.

보증이 필요한 고객이 있는 경우, 사업 부서는 위험도에 따라 필요한 경우 이메일 등의 방법으로 확인된 알려진 취약점을 고지합니다.

(3) 문제 해결

사업 부서는 수립한 조치 계획에 따라 문제가 되는 오픈소스를 삭제하거나 패치된 버전으로 교체하는 등의 방법으로 보안 취약점 문제를 해결합니다. 발견된 모든 이슈를 해결하면, 재검토를 요청합니다.

(4) 검토

IT 담당은 오픈소스 분석 도구를 활용하여 문제가 적절하게 해결되었는지 확인합니다.

(5) 승인

보안 담당은 심각한 취약점이 모두 해결되었는지 검토합니다. 해결하기 어려운 취약점이 남아 있을 경우, 비즈니스 형태와 서비스 노출 현황 등을 고려하여 승인 여부를 검토합니다.

(6) 등록

IT 담당은 오픈소스 보안 취약점이 해결된 SBOM을 시스템에 등록합니다.

(7) 고지

오픈소스 프로그램 매니저는 오픈소스 보안 취약점이 해결된 SBOM을 기준으로 오픈소스 고지문을 생성하여 사업 부서에 전달합니다.

사업 부서는 제품 배포 시 동봉한 오픈소스 고지문을 교체합니다.

IT 담당은 수정된 오픈소스 고지문을 회사의 오픈소스 배포 사이트에 등록합니다.

(8) 배포

사업 부서는 오픈소스 보안 취약점 문제가 해결된 버전의 소프트웨어를 재배포합니다.

보안 담당은 제3자에게 공개가 필요한 위험 정보가 존재하는지 식별하고, 존재할 경우 IT 담당자에게 전달합니다.

IT 담당은 신별된 위험에 대한 정보를 오픈소스 웹사이트에 등록하여 제3자가 확인할 수 있게 합니다.

3. 외부 문의 대응 프로세스

외부로부터의 오픈소스 컴플라이언스 문의에 신속하고 정확하게 대응한다면 소송까지 진행되는 위험을 크게 줄일 수 있습니다. 이를 위해 기업은 외부의 오픈소스 컴플라이언스 문의에 대응하기 위해 다음과 같은 프로세스를 준수합니다.

(1) 접수 알림_Acknowledge

오픈소스 프로그램 매니저는 문의를 받은 즉시 요청자에게 문의가 접수되었음을 알립니다. 이때 조치 예정일을 함께 알립니다. 요청자의 의도가 무엇인지 정확히 파악하는 것이 중요하기 때문에 문의가 불명확한 경우 추가 설명을 요청합니다.

대응이 필요한 문의 및 요청의 주요 내용은 아래와 같습니다.

• 특정 제품 및 서비스에 오픈소스가 사용되었는지 문의
• 서면 약정(Written Offer)에 언급된 GPL, LGPL 라이선스 하의 소스 코드 제공 요청
• 오픈소스 고지문에 명시되지 않았지만, 제품에서 발견된 오픈소스에 대한 해명 및 소스 코드 공개 요청
• GPL, LGPL 등의 의무로 공개된 소스 코드에 누락된 파일 및 빌드 방법 제공 요청
• 저작권 표시 요청

오픈소스 프로그램 매니저는 접수한 요청에 대한 Jira Issue를 생성하여 대응 상황을 모두 자세히 기록합니다.

(2) 조사 알림_Inform

오픈소스 프로그램 매니저는 요청자에게 오픈소스 컴플라이언스를 충실히 수행하고 있음과 요청자의 문의를 조사하고 있음을 알립니다. 내부 조사 진행 상황이 업데이트될 때마다 알리는 것이 좋습니다.

(3) 내부 조사_Investigate

오픈소스 프로그램 매니저는 요청 사항에 대한 내부 조사를 진행합니다. 문제가 된 제품의 버전에 대하여 컴플라이언스 프로세스가 적절하게 수행되었는지 BOM 및 문서화된 검토 이력을 통해 확인합니다. 필요 시 법무 담당에 자문을 요청합니다.

특정 사업 부서에서 확인이 필요한 사항일 경우 오픈소스 프로그램 매니저는 사업 부서에 조사를 요청합니다. 조사를 요청받은 사업 부서는 컴플라이언스 산출물에 문제가 있는지 즉시 확인하고 결과를 오픈소스 프로그램 매니저에게 보고합니다.

(4) 요청자에게 보고_Report

오픈소스 컴플라이언스 담당은 조치 예정일 내에 내부 조사를 마치고, 요청자에게 결과를 알립니다.

• 요청자의 문의가 오해로 인한 잘못된 지적이었다면 추가 조치 없이 요청자에게 이를 알리고 처리를 종료합니다.
• 문제가 맞는다면 요청자에게 해당 오픈소스 라이선스의 의무를 이행하기 위한 정확한 방법과 시기를 알립니다.

(5) 문제 보완 / 알림_Rectify

내부조사에서 실제 컴플라이언스 문제가 발견되면 해당 사업 부서는 컴플라이언스 문제를 해결하는 데 필요한 모든 절차를 수행합니다.

(6) 문제 해결 알림_Report

문제를 해결한 후에는 즉시 요청자에게 알리고 문제가 해결되었음을 확인할 수 있는 최선의 방법을 제공합니다.

(7) 프로세스 개선_Improve

컴플라이언스 문제가 있었던 경우, OSRB 미팅을 통해 사례를 검토하고, 문제가 발생한 경위를 파악하여, 문제가 재발하지 않을 수 있도록 프로세스를 개선합니다.