2. 오픈소스 컴플라이언스 프로세스 (template)

오픈소스 컴플라이언스의 주요 두가지 목적은 다음과 같다.

  1. 의무 파악 : 공급 대상 소프트웨어가 포함하고 있는 오픈소스를 식별하고 각 오픈소스 라이선스가 요구하는 의무를 파악한다.
  2. 의무 사항 이행 : 식별한 의무 사항을 이행한다.

이를 위해 기업은 공급 대상 소프트웨어를 배포하는 시점에 오픈소스 라이선스 의무사항을 준수할 수 있도록 오픈소스 컴플라이언스 프로세스를 구축해야 한다. 여기서는 일반적인 오픈소스 컴플라이언스 프로세스의 구성요소와 각각의 기능 및 역할을 포함하는 프로세스(예시)를 제안한다.

<OO 회사> 오픈소스 컴플라이언스 프로세스 (예시)

<OO 회사>의 오픈소스 정책에 근거하여 오픈소스를 사용하기 위해서는 먼저 오픈소스 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무 사항을 검토하고 확인해야 한다. 그렇게 공급 대상 소프트웨어에 포함된 오픈소스와 라이선스 의무사항을 식별하고, 소프트웨어를 배포 시 라이선스 의무사항을 준수하기 위한 오픈소스 컴플라이언스 활동을 해야 한다.

<OO회사>의 오픈소스 컴플라이언스 프로세서는 공급 대상 소프트웨어에 사용되는 오픈소스를 관리하는 일련의 과정을 정의한다. 이 과정에는 다음 사항이 포함된다.

  1. 공급 대상 소프트웨어에 사용된 모든 오픈소스 식별
  2. 식별한 오픈소스에 의해 발생하는 모든 의무를 식별하고 추적
  3. 모든 의무를 충족하기 위한 활동

이를 효과적으로 수행하기 위해 <OO회사>의 모드 소프트웨어 공급관리자는 다음 10단계를 수행한다.

Step 1. 오픈소스 식별 (Identification of Open Source)

오픈소스 식별 단계는 오픈소스 컴포넌트를 식별하기 위한 검토 단계이다. 자체 독점 소프트웨어인지, 제3자 소프트웨어인지 여부에 관계 없이 공급 대상 소프트웨어에 포함된 오픈소스를 모니터링한다. 오픈소스 식별 방법은 다음과 같다.

  • 오픈소스 사용 요청 접수 : SW개발자는 특정 제품에 오픈소스를 사용하고자 함을 오픈소스 책임자 또는 오픈소스 센터에 알리고, 검토 및 승인을 위한 오픈소스 패키지의 용도에 관한 정보를 제공한다.
  • 회사 개발 소프트웨어 검사 (Auditing) : 개발자가 오픈소스의 소스코드를 복사해서 가져와 소프트웨어를 개발할 수 있기 때문에 회사가 개발한 소프트웨어에 대해서도 검사를 수행한다.
  • 제3자 소프트웨어 실사 (Due diligence)
식별 단계 시작 조건식별 단계 결과
• 개발자로부터 특정 오픈소스 사용 요청 접수
• 개발 프로세스 상 소프트웨어 검사 단계
• 제3자 소프트웨어 입수 및 개발소프트웨어로의 통합		• 오픈소스에 대한 컴플라이언스 기록 생성 (Jira 등 활용)
• 소스코드 스캔 대상 선정 및 요청

Step 2. 소스 코드 검사 (Auditing Source Code)

소스 코드 검사 단계에서는 소스 코드 분석 도구를 사용하여 소스 코드를 스캔하여 오픈소스를 발견한다. 소스 코드 스캔도구는 FOSSology를 이용한다. GPL-3.0 등 정책적으로 사용할 수 없는 오픈소스 라이선스가 적용된 오픈소스 혹은 라이선스 충돌로 양립할 수 없는 오픈소스가 발견될 경우 문제로 식별하여 개발팀에 보완을 요청한다.

식별 단계 시작 조건식별 단계 결과
• 개발자로부터 특정 오픈소스 사용 요청 접수
• 개발 프로세스 상 소프트웨어 검사 단계
• 제3자 소프트웨어 입수 및 개발소프트웨어로의 통합		• 오픈소스에 대한 컴플라이언스 기록 생성 (Jira 등 활용)
• 소스코드 스캔 대상 선정 및 요청

Step 3. 문제 해결 (Resolving Issues)

소스 코드 검사 단계에서 식별된 모든 문제를 해결한다. 문제 사항은 Jira Ticket으로 생성하여 개발팀에 할당되고, 오픈소스 책임자는 모든 문제가 적절하게 해결되었는지 확인한다.

문제 해결 단계 시작 조건문제 해결 단계 결
• 소스 코드 스캔 완료 및 결과 생성 • 문제 식별• 식별된 문제를 모두 해결

Step 4. 검토 (Reviews)

식별된 모든 문제가 해결되면 검토 단계로 이동한다. 검토 단계의 절차는 다음과 같다.

  1. 소프트웨어 PL : 소프트웨어에 포함된 오픈소스에 대한 사용 승인 요청서를 제출한다.
  2. 오픈소스 책임자 : 사용 승인 요청서를 접수하면 모든 정보가 누락없이 포함 되었는지를 확인하고, Jira ticket을 생성하여 검토 절차를 진행한다.
  3. 소스코드 검사 담당자: Jira ticket이 생성되면 소스코드 검사를 수행하여 문제가 모두 해결되었는지 확인한다.
  4. 법무팀 : 라이선스 이슈를 검토한다.
검토 단계 시작 조건검토 단계 결과
• 식별된 모든 문제 해결• 오픈소스 책임자, 소스코드 검사 담당자, 법무팀 등의 검토를 완료하여 승인 준비가 된 상태

Step 5. 승인 (Approval)

검토가 완료되면 Jira ticket은 승인 단계로 이동한다. OSRB는 오픈소스의 사용을 승인하거나 거절한다. 거절시에는 이유에 대한 설명과 수정 방법을 제안한다. OSRB가 오픈소스 구성요소의 사용을 승인하면 개발팀은 라이선스 의무를 이행하기 위한 준비를 시작한다.

승인 단계 시작 조건승인 단계 결과
• 검토가 완료된 상태• OSRB는 오픈소스의 사용을 승인하거나 거절함
• 거절 시에는 이유에 대한 설명과 수정 방법 제안

Step 6. 등록 (Registration)

사용이 승인된 오픈소스 구성요소는 오픈소스 사용을 추적하는 BOM (소프트웨어 인벤토리)에 추가한다. BOM에는 오픈소스 구성요소 이름, 버전, 관리 담당자 이름, 이를 사용하는 제품 이름, 제품 버전, 제품 릴리즈 번호 등의 정보를 포함한다. BOM을 관리하는 도구는 SW360을 사용한다.

등록 단계 시작 조건등록 단계 결과
• OSRB가 오픈소스 사용을 승인• 오픈소스 구성요소를 BOM에 등록

Step 7. 고지 (Notices)

오픈소스를 사용할 때 주요 의무 중 하나는 고지 의무이다. 이를 위해 다음 사항을 수행 한다.

  • 저작권, 라이선스 고지를 제공한다.
  • 라이선스 사본을 제공한다.
  • (해당되는 경우) 소스 코드 사본을 얻을 수 있는 방법을 최종 사용자에게 알린다.
고지 단계 시작 조건고지 단계 결과
오픈소스를 BOM에 등록저작권, 라이선스 고지를 준비하고, 이를 제품에 포함되도록 관련 부서로 전달

이와 같은 사항을 제품 배포 시 포함시킬 수 있도록 관련 부서에 전달한다. 화면이 있는 제품이면 사용자가 메뉴 > 오픈소스 고지 정보에서 오픈 소스 고지 내용을 확인할 수 있게 한다. 제품에 화면이 없을 경우, 사용자 매뉴얼에 오픈소스 고지 내용을 포함시킨다.

Step 8. 배포 전 확인 (Pre-Distribution Verifications)

이 단계에서는 다음 사항을 보장하기 위한 확인을 수행한다.

  • 오픈소스 라이선스가 요구하는 공개할 소스 코드를 취합한다.
  • 취합한 소스 코드는 제품에 탑재된 바이너리와 매치되어야 한다.
  • 소스 코드 내 부적절한 주석을 제거한다.
  • 적절한 고지문이 제품에 포함되었다. 여기에는 최종 사용자가 소스 코드를 받을 수 있는 방법 (Written Offer)도 함께 제공한다.
배포 전 확인 단계 시작 조건배포 전 확인 단계 결과
• 모든 오픈소스 구성요소가 BOM에 등록• 고지 의무를 이행할 수 있도록 조치
• 공개할 소스 코드 취합
• 소스 코드 제공 방법 결정
• 배포 전 확인 수행 완료

Step 9. 배포 (Distribution)

배포 전 확인이 완료되면 공개할 소스 코드 패키지를 오픈소스 배포사이트에 업로드한다. 오픈소스 배포사이트에는 제품 및 버전별로 등록할 수 있다. 최종 사용자는 자신이 원하는 제품의 버전에 해당하는 소스 코드 패키지를 오픈소스 배포사이트에서 검색하여 다운로드 받을 수 있다.

배포 단계 시작 조건배포 단계 결과
• 모든 배포 전 확인 완료• 특정 제품의 버전에 대한 공개할 소스 코드 패키지를 오픈소스 배포사이트에 업로드

Step 10. 최종 확인 (Final Verifications)

공개할 소스 코드 패키지를 오픈소스 배포사이트에 업로드 후 패키지가 올바르게 업로드 되었고, 외부에서 오류 없이 다운로드 및 압축 해제가 되는지 확인한다. 라이선스에 따라 빌드하여 바이너리 생성까지 보장을 요구하는 경우, 외부에서 다운받은 소스 코드가 README의 안내대로 오류 없이 빌드하여 바이너리가 생성되는지, 생성된 바이너리가 제품에 탑재된 바이너리와 동일한지 확인한다.

최종 확인 단계 시작 조건최종 확인 단계 결과
• 공개할 소스 코드가 오픈소스 배포사이트에 게시• 외부에서 다운로드가 이상없이 수행되는지, 제품과 동일한 버전의 바이너리와 매치가 되는지 확인

Last modified November 21, 2021: add iso/iec5230 guide (5909c280)