Archive

• 1: NIPA OpenChain Guide
• 1.1: I. OpenChain Project란?
• 1.1.1: 1. OpenChain Specification
• 1.1.2: 2. OpenChain Conformance
• 1.1.3: 3. OpenChain Curriculum
• 1.2: II. OpenChain Specification 준수 방법
• 1.2.1: 1. 프로그램 성립
• 1.2.2: 2. 관련 업무 정의 및 지원
• 1.2.3: 3. 오픈소스 콘텐츠 검토 및 승인
• 1.2.4: 4. 컴플라이언스 결과물 생성 및 전달
• 1.2.5: 5. 오픈소스 커뮤니티 참여에 대한 이해
• 1.2.6: 6. 설명서 요건 준수
• 1.3: 부록
• 1.3.1: 1. 샘플 오픈소스 정책 for OpenChain 2.1
• 1.3.2: 2. 오픈소스 컴플라이언스 프로세스 (template)
• 1.3.3: 3. 오픈소스도구 (FOSSology, SW360)
• 1.3.3.1: FOSSology
• 1.3.3.2: SW360
• 2: [out of date] Open Source Governance for Enterprises
• 2.1: 1. What is ISO/IEC 5230
• 2.2: 2. Essential elements
• 2.3: 3. Team
• 2.4: 4. Policy
• 2.5: 5. Process
• 2.6: 6. Tool
• 2.7: 7. Training
• 2.8: 8. Conformance
• 2.9: Appendix
• 2.9.1: 1. Open Source Policy (Sample)
• 2.9.2: 2. Open Source Compliance Process (Sample)

1 - NIPA OpenChain Guide

OpenUP conducted research under the supervision of the National Information and Communication Industry Promotion Agency (NIPA) and produced a guidebook explaining detailed methods for companies to comply with the OpenChain Specification. : OpenChain 2.0 Guide for Open Source Governance in the Enterprise

With the permission of NIPA, the contents of the guide are published on GitHub, and anyone can refer to the contents, modify / improve the contents.

References

Language

This page contains only Korean language materials for Korean companies.

1.1 - I. OpenChain Project란?

오늘날 소프트웨어는 갈수록 그 규모와 복잡도가 커지고 있다. 하나의 소프트웨어를 개발하기 위해서는 자체 개발하는 소프트웨어뿐 아니라 오픈소스, 3rd party Software, 반도체 벤더의 SDK 등 소프트웨어 공급망에 걸친 다양한 소프트웨어가 사용될 수 있기 때문이다.

이러한 복잡한 소프트웨어 공급망의 조직 중 한 곳이라도 라이선스 의무를 준수하지 않거나, 올바른 오픈소스 정보를 제공하지 못한 경우, 최종 소프트웨어를 배포하는 기업은 라이선스 준수에 실패하고 이로 인해 제품 판매가 중단되는 상황이 발생할 수 있다. 실제로 2009년 12월, Busybox라는 오픈소스 관련된 소송이 있었다. Busybox는 임베디드 시스템에 광범위하게 사용되고 있는 GPL-2.0 라이선스가 적용된 오픈소스인데, 두 곳의 국내 회사를 포함하여 총 14개 회사가 소송 대상이 되었다. 이 사례에서 주목할만한 점은 이 중에는 제품을 직접 개발하지 않고 배포만 한 회사도 소송을 당했다는 점이다.

이와 같은 복잡한 소프트웨어 공급망 환경에서는 어느 한 기업이 아무리 훌륭한 프로세스를 갖추고 있다고 해도 자체적으로 완벽한 오픈소스 컴플라이언스를 달성하는 건 매우 어렵다. 결국 소프트웨어를 최종 배포하는 기업이 오픈소스 컴플라이언스를 제대로 이행하기 위해서는 소프트웨어 공급망의 모든 구성원이 라이선스 의무를 준수하고 올바른 오픈소스 정보를 제공하여 공급망 전체에 신뢰가 구축되어야 한다.

Linux Foundation의 OpenChain 프로젝트는 기업이 오픈소스 컴플라이언스를 위해 준수해야 할 활동을 더 간단하고 일관성 있게 만들어 소프트웨어 공급망 전체에 신뢰를 구축할 수 있도록 해준다.

2016년 유럽의 한 오픈소스 콘퍼런스에서 퀄컴의 오픈소스 변호사인 데이브 머(Dave Marr)는 한 기업의 오픈소스 컴플라이언스 수준을 높이기 위해서는 소프트웨어 공급망 내의 모든 구성원이 오픈소스 컴플라이언스 수준을 높이는 것이 중요함을 강조한 바 있다. 아울러 이를 위해서는 오픈소스를 충분히 이해하고, 정책 및 프로세스를 앞서 구축하고 있는 기업들이 자신들의 자산과 노하우를 공개해 누구나 이를 참고할 수 있게 해야 한다는 의견을 제시했다. 콘퍼런스 참석자들은“오픈소스 컴플라이언스는 기업의 이익을 차별화할 수 있는 분야가 아니다. 기업은 최소한의 리소스를 투입하여 적정한 수준의 리스크 관리를 원하기 때문에 기업들이 가진 자산을 공유하면 할수록 적은 비용으로 모두 함께 컴플라이언스를 달성 할 수 있다”는 아이디어에 공감했다. OpenChain 프로젝트(당시에는 Work Group)는 그렇게 시작됐고, Qualcomm, Siemens, Wind River, ARM, Adobe 등 다수 글로벌 기업들이 참여했다.

1.1.1 - 1. OpenChain Specification

OpenChain 프로젝트는 곧 OpenChain Specification 1.0을 제작하여 배포했다. OpenChain Specification은 오픈소스 컴플라이언스를 위한 핵심 요구사항을 정의한 12페이지 분량의 표준 규격으로, 기업의 규모나 업종과 관계없이 모든 분야의 회사에 적합하도록 고안되었다. 2019년 4월에는 버전 2.0의 Specification이 배포됐으며, 기업이 오픈소스 컴플라이언스 달성을 위해 꼭 수행해야 할 여섯 가지 주요 요건에 대한 설명과 이를 수행하고 있음을 입증하기 위한 검증 자료 목록을 정의하고 있다.

1. 오픈소스 컴플라이언스를 관리하기 위한 프로그램
2. 효과적인 리소스 제공을 위한 업무 정의 및 지원
3. 오픈소스 검토 및 승인을 관리하는 프로세스
4. 컴플라이언스 결과물 생성 및 제공을 위한 프로세스
5. 오픈소스 커뮤니티 참여를 이해하고 관리하기 위한 정책
6. OpenChain Specification 요건 준수

오픈소스 컴플라이언스를 처음 시작하는 기업이라면 이와 같은 OpenChain Specification의 요건을 하나씩 충족해가면서 수준을 향상시키는 것이 좋은 전략이다.

1.1.2 - 2. OpenChain Conformance

OpenChain Project는 기업이 OpenChain Specification을 충족하는지 자체적으로 확인할 수 있도록 온라인 자체 인증 웹사이트를 제공한다.

기업의 오픈소스 담당자는 OpenChain 자체 인증 웹사이트에 가입해 온라인 자체 인증을 시작할 수 있으며, Yes/No 질문에 답변하는 방식으로 진행된다.

자체 인증을 통해 부족한 부분이 무엇인지, 추가로 필요한 활동이 무엇인지 판단할 수 있다.

만약, 오픈소스 컴플라이언스 체계가 잘 구축된 기업이 OpenChain 자체 인증 질문지의 모든 항목을 Yes로 대답할 수 있다면 이 결과를 웹사이트상에 제출할 수 있다(Conforming Submission). 그러면 OpenChain 준수(Conformant) 기업으로 인정됨과 동시에, OpenChain 프로젝트의 웹사이트에서 OpenChain 준수 프로그램을 갖춘 기업 목록에 기업의 로고를 등록할 수 있게 된다.

OpenChain 준수 기업에게는 OpenChain 로고를 사용할 수 있는 자격이 주어진다. 이렇게 OpenChain 준수 프로그램을 갖췄다고 인정받은 기업은 소프트웨어 공급망 내에서 오픈소스 컴플라이언스를 충실하게 수행하고 있음을 보여줄 수 있다.

1.1.3 - 3. OpenChain Curriculum

OpenChain 프로젝트에서는 기업이 컴플라이언스 프로그램을 구축하는데 필요한 정책 문서 템플릿, 교육 자료 등 다양한 참고자료를 제공한다. 이 자료들은 OpenChain Specification 및 일반적인 오픈소스 컴플라이언스 활동을 지원하기 위해 고안됐으며, 누구나 자유롭게 사용할 수 있도록 Public Domain으로 제공된다.

1.2 - II. OpenChain Specification 준수 방법

OpenChain Specifiation에서는 오픈소스 컴플라이언스를 위한 핵심 요구 사항을 정의한다. OpenChain Specification을 준수한다고 인정받은 기업은 소프트웨어 솔루션을 배포하는 조직간에 신뢰를 제공할 수 있게 된다. 여기에서는 기업들이 OpenChain Specification을 준수하기 위해 충족해야 하는 여섯가지 주요 요건과 그 방법을 세부적으로 설명한다.

1.2.1 - 1. 프로그램 성립

1.1 정책 (Policy)

오픈소스를 이용하여 소프트웨어를 개발하고 배포하는 기업이라면 오픈소스를 관리하기 위한 정책과 프로세스를 구축하고, 이를 위한 인력과 자원을 할당해야 한다. OpenChain에서는 이러한 일련의 활동을 관리하는 체계를 오픈소스 프로그램이라고 부르고, OpenChain Specification을 준수하기 위한 첫번째 요건은 바로 이 프로그램을 설립해야 하는것이다. 여기서 오픈소스 프로그램이란 정책, 프로세스, 인원 등 기업이 오픈소스 컴플라이언스 활동을 수행하기 위한 일련의 관리 체계를 의미한다. OpenChain Specification에서는 이를 입증하기 위한 자료로 우선 문서화된 오픈소스 정책을 요구한다. 이 안내서에서는 참고를 위해 OpenChain Specification의 요건을 충족하는 오픈소스 정책 문서 예시를 “[부록 01] 샘플 오픈소스 정책”에서 제공한다.

OpenChain Specification은 이어지는 장에서 오픈소스 프로그램이 갖춰야할 요건들을 설명하고 있다.

오픈소스 프로그램은 소프트웨어 공급담당자가 이 오픈소스 정책 문서의 존재를 알고, 필요한 활동을 할 수 있도록 교육, 내부 위키 등 실질적인 수단을 제공해야 한다. 여기서 소프트웨어 공급담당자(Software Staff)란 기업이 소프트웨어를 개발하고 배포, 기여하는데 관여하는 모든 직원을 의미하며, 소프트웨어 개발자, 배포 엔지니어, 품질 엔지니어 등을 포함한다.

많은 기업들은 오픈소스 정책 문서를 사내 위키 사이트를 통해 공개하여 직원 누구나 필요한 사항을 확인할 수 있게 한다. 또한, 신규 채용인원의 입사 연수 시 오픈소스 정책에 대한 교육을 의무화하고, 소프트웨어 공급담당자를 대상으로 매년 혹은 2년에 한번씩 주기적인 교육을 제공함으로 모든 소프트웨어 공급담당자가 오픈소스 정책의 존재를 인식하도록 할 수 있다. 이러한 방법들을 오픈소스 정책 문서에 구체화하여 포함해야 한다.

1.2 역량 (Competence)

오픈소스 프로그램이 올바르게 구축되고 운영될 수 있도록 역할과 책임(R&R)을 정의해야 한다. 각 역할을 수행할 담당자가 갖춰야 할 역량을 정의하고, 지정된 담당자가 해당 역할을 수행할 수 있는 역량을 갖추었는지 파악해야 한다. 해당 인원이 교육, 훈련 및 경험을 바탕으로 맡은 역할을 수행할 수 있는 자격을 갖추었음을 보장해야 한다. 이를 위해 각 인원이 필요한 역량을 갖출 수 있도록 교육을 제공한다.

이를 입증하기 위해 기업은 프로그램 내 여러 참여자에 대한 책임 및 역할 목록과 각 역할을 수행하는 담당자가 갖춰야할 역량을 정의하여 문서화 한다. 이 안내서에서는 참고를 위해 오픈소스 프로그램의 각 참여자의 역할과 책임 및 필요한 역량을 정의한 샘플 문서를 “[부록 01] 오픈소스 정책 for OpenChain 2.0(예)의 4. 역할, 책임 및 역량”에서 제공한다.

그리고, 기업은 각 참여자가 역량을 갖추고 있는지 평가하고, 이를 보관한다. 이를 위해 기업은 각 참여자가 필요한 역량을 보유할 수 있도록 교육을 제공한다. 교육 내용을 기반으로 평가하고, 그 결과는 기업의 교육 시스템 혹은 HR 부서에서 보관해야 한다. 소프트웨어 공급담당자가 수천명 이상이어서 교육 제공이 쉽지 않을 경우, 기업의 온라인 교육과 평가 시스템을 이용하는 것도 좋은 방법이다.

1.3 인지도 (Awareness)

프로그램 참여자가 오픈소스 정책, 기업의 오픈소스 관련 목표, 오픈소스 프로그램이 효과적일 수 있도록 참여자의 기여 방법, 그리고 프로그램 요건을 준수하지 않았을 때의 발생할 수 있는 위험에 대해 인식하도록 한다.

이를 위해 오픈소스 정책은 프로그램 참여자가 오픈소스 정책 등의 주요 내용을 인식할 수 있도록 다음의 내용을 포함해야 한다.

• 먼저, 오픈소스를 사용, 배포, 기여하는 일련의 활동을 수행하는 목표를 포함한다. 예를 들어,“오픈소스를 이용하여 제품을 만들때 오픈소스 컴플라이언스 리스크를 최소화하고, 오픈소스 커뮤니티에 참여하고 기여함으로 최고의 가치를 창출한다”와 같은 형태로 목표를 수립할 수 있다.
• 그리고, 프로그램 참여자가 자신의 역할에 대한 책임을 완수함으로써 오픈소스 프로그램의 효과가 증대될 수 있음을 알린다.
• 또한, 오픈소스 프로그램의 요건들을 준수하지 않았을 때 어떠한 위험이 발생하는지에 대해서도 알린다.

대표적인 위험 요소는 다음과 같다.

• 사용한 코드의 저작권자로부터 법적 클레임
• 의도하지 않은 기업 독점 코드의 공개
• 라이선스 의무 위반으로 인한 벌금
• 평판 손실
• 수익 손실
• 공급업체 및 고객과의 계약 위반

각 프로그램 담당자가 프로그램의 목표, 프로그램에 기여 방법, 프로그램 미준수의 의미에 대해 올바르게 인식할 수 있도록 교육을 제공하고, 이를 평가한다. 평가한 결과는 문서화하여 보관한다. 1.2장에서 언급한 교육 및 평가 시 이에 대한 내용을 포함하면 될 것이다.

1.4 프로그램 적용 범위 (Program Scope)

오픈소스 프로그램은 반드시 기업 전체에 적용해야 하는 것은 아니다. 기업 내 각 조직의 특성에 따라 프로그램의 적용 범위를 달리 할 수 있다. 예를 들어, 소프트웨어를 전혀 배포하지 않는 조직이라면 오픈소스 프로그램의 적용 범위에 해당하지 않을 수 있다. 따라서, 기업의 오픈소스 정책은 오픈소스 프로그램의 적용 범위와 한계를 명확히 정의해야 한다.

예를 들어, “이 오픈소스 정책은 회사가 외부에 배포하는 모든 제품에 적용한다. 향후 배포하는 제품의 형태에 따라 프로그램의 구성과 적용 범위가 달라질 수 있으며, 이에 대해서는 오픈소스 팀이 OSRB와의 협의를 통해 결정한다.”와 같은 형태로 프로그램 적용 범위를 정의할 수 있다.

1.5 라이선스 의무 (License Obligations)

오픈소스의 사용 가능 여부를 판단하기 위해서는 먼저 오픈소스의 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무사항을 검토하고 확인해야 한다. 오픈소스 프로그램은 소프트웨어 개발팀에서 오픈소스 라이선스가 부여하는 의무, 제한 및 권리를 검토할 수 있도록 오픈소스 라이선스 의무 요약 자료를 제공하는 것이 좋다. 공개SW 라이선스(https://www.oss.kr/oss_license )에서는 주요 오픈소스 라이선스의 의무, 제한 및 권리를 자세히 설명한다.

오픈소스를 사용하기에 앞서 라이선스 검토하고 이를 문서화하는 절차는“[부록 02] 오픈소스 컴플라이언스 프로세스 (예시)”절차의 오픈소스 식별 단계에 해당한다.

1.2.2 - 2. 관련 업무 정의 및 지원

2.1 접근성 (Access)

배포한 제품에 사용된 오픈소스에 대해 고객 및 오픈소스 저작권자가 기업에게 오픈소스 관련 문의, 요청 및 클레임을 제기하는 경우가 있다. 소송까지 당하지 않기 위해서는 이러한 외부 문의에 가능한 빠르고 정확하게 대응하는 것이 중요하다. 따라서 기업은 외부에서 기업에게 오픈소스 관련 문의를 할 수 있는 연락 방법을 공개적으로 밝히고, 외부 오픈소스 문의를 접수하였을 때 빠르고 효과적으로 대응 할 수 있는 프로세스를 갖추고 있어야 한다.

외부에서 기업에게 오픈소스 관련 문의를 할 수 있는 연락 방법은 회사의 오픈소스 담당자의 이메일 주소를 공개하거나, Linux Foundation의 Open Compliance Directory를 이용하는 것이다.

오픈소스 개발자들이 기업의 오픈소스 컴플라이언스 관련 이슈를 논의하기 위해 기업 담당자에게 연락하고 싶어도 연락 방법을 찾지 못하다가 결국 법적 클레임까지 제기하는 경우가 있다. Linux Foundation은 이러한 경우를 최소화 하기 위해 기업들에게 오픈소스 관련 문의를 받을 수 있는 연락처를 공개할 수 있도록 Open Compliance Directory라는 공간을 마련하였다.

이를 통해 오픈소스 개발자들은 원하는 기업의 컨택 포인트 정보를 쉽게 확인할 수 있고, 법적 클레임까지 제기하기 이전에 기업의 오픈소스 담당자와 오픈소스 컴플라이언스 이슈를 논의하여 문제를 해결할 수 있다. 기업의 오픈소스 담당자는 Open Compliance Directory에 기업 정보 및 연락 방법을 등록하는 것이 소송 리스크를 줄일 수 있는 방법 중 하나이다.

외부 문의 및 요청의 주된 내용은 다음과 같다.

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

외부로부터의 이러한 오픈소스 컴플라이언스 문의에 신속하고 정확하게 대응한다면 소송까지 진행되는 위험을 크게 줄일 수 있다. 따라서, 기업은 외부의 오픈소스 컴플라이언스 문의에 대응하기 위한 절차를 갖고 있어야 한다. 컴플라이언스 문의를 대응하기 위한 일반적인 절차는 다음과 같다.

1. 접수 확인 (Acknowledge) 문의를 받으면 즉시 응답하여, 문의가 제대로 접수되었음을 알린다. 이때 조치 예정일을 함께 알린다. 요청자의 의도가 무엇인지 정확히 파악하는 것이 중요하기 때문에 문의가 불명확한 경우 추가 설명을 요청한다.
2. 요청자에게 알림 (Inform) 요청자에게 오픈소스 컴플라이언스를 충실히 수행하고 있음과 요청자의 문의에 대해 조사하고 있음을 알린다. 내부 조사 진행사항이 업데이트되면 알리는 것이 좋다.
3. 내부 조사 (Investigate) 문의에 대해 내부 조사를 진행한다. 문제가 된 제품의 버전에 대하여 컴플라이언스 프로세스가 적절하게 수행되었는지 BOM 및 문서화 된 검토 이력을 통해 확인한다.
4. 요청자에게 보고 (Report) 요청자에게 통보했던 조치 예정일 내에 내부 조사를 마치고, 이에 대한 내부 기록을 남긴 후 요청자에게 결과를 알린다.
5. 처리 종료 (Close Inquiry) 요청자의 문의가 오해로 인한 잘못된 지적이나 요청이었다면 추가 조치 없이 요청자에게 이를 알리고 처리를 종료한다.
6. 문제 보완 (Rectify) 내부조사에서 실제 컴플라이언스 문제가 발견되면 해당 조직은 제품 또는 서비스의 컴플라이언스 문제를 해결하기 위해 필요한 모든 절차를 수행한다. 예상되는 완료 일자를 요청자에게 다시 한번 알린다. 즉, 해당 오픈소스 라이선스의 의무를 이행하기 위한 정확한 방법과 시기를 알려야 한다. 문제를 해결한 후에는 즉시 요청자에게 알리고 문제가 해결되었음을 확인할 수 있는 최선의 방법을 제공한다.
7. 프로세스 개선 (Improve) 컴플라이언스 문제가 있었던 경우, OSRB 미팅을 통해 사례를 검토하고, 문제가 발생한 경위를 파악하여, 문제가 재발하지 않을 수 있도록 프로세스를 개선한다.

2.2 효과적인 리소스 제공 (Effectively Resourced)

기업은 오픈소스 프로그램이 원활하게 기능을 수행할 수 있도록 리소스를 충분하게 제공해야 한다.

• 프로그램 참여자들이 업무를 수행할 수 있는 시간과 자금을 할당하고, 주기적으로 오픈소스 정책을 검토하여 기업의 소프트웨어 전략에 맞추어 업데이트해야 한다.
• 프로그램 참여자들이 컴플라이언스 이슈 해결을 위한 프로세스가 구축되어야 하고, 이슈 해결을 위해 법적인 검토가 필요할 경우 법무 자문을 요청할 수 있는 방법이 제공되어야 한다.

오픈소스 프로그램이 기능을 수행하기 위해서는 각 역할 별 담당자가 지정되어야 한다.

• 각 역할 별 담당자 혹은 담당 조직을 지정하고, 누구나 이를 참고할 수 있도록 문서화하여 공유한다.
• 각 조직의 책임자는 프로그램 내의 각 역할별 담당자가 적절히 충원되었는지, 업무를 수행하는데 필요한 자금이 적절하게 제공되었는지를 확인한다.

만약, 프로그램 참여자가 자신의 역할을 수행하는데 리소스나 자금 지원이 부족하다고 판단한다면, 반드시 기업의 오픈소스 책임자에게 문제를 제기하여 해결해야 한다. 문제가 효과적으로 해결되지 않을 경우, 오픈소스 이사회에 보고하고, 이사회는 필요한 의사결정을 수행하여 적절한 자원이 할당 될 수 있도록 해야 한다.

기업은 프로그램 참여자가 이슈 해결을 위해 법률적인 검토가 필요할 경우, 이에 대해 법률 자문을 요청할 수 있는 방법을 제공해야 한다. 회사 내의 법무팀을 통해 우선 제공하고, 이슈가 첨예한 경우, 오픈소스 전문 변호사를 보유한 외부 법무 법인을 이용할 수 있다. OpenChain Project에서는 파트너 프로그램을 통해 오픈소스 관련 자문을 제공하는 글로벌 법무법인 리스트를 제공한다.

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

오픈소스 책임자는 기업의 오픈소스 컴플라이언스 활동을 위한 기업 내부의 역할과 책임을 할당해야 한다. 오픈소스 정책 문서에는 오픈소스 책임자가 오픈소스 컴플라이언스 이슈 해결을 위해 담당해야 할 역할에 대해 기술한다.

컴플라이언스 미준수 이슈가 제기된 경우, 기업은 이를 신속히 검토하고 대응하기 위한 절차를 문서화해야 한다. 이에 대한 자세한 내용은 2.1장에서 외부 문의 대응에 대한 프로세스 설명 부분을 참고할 수 있다.

1.2.3 - 3. 오픈소스 콘텐츠 검토 및 승인

3.1 BOM (Bill of Materials)

오픈소스 컴플라이언스 활동의 가장 기본은 바로 공급 대상 소프트웨어에 포함된 오픈소스 현황을 파악하는 것이다. 공급 대상 소프트웨어에 포함된 오픈소스와 그 라이선스를 식별하여 그 정보를 담고있는 BOM을 작성하고 관리하는 프로세스를 구축해야 한다. 공급 대상 소프트웨어마다 어떤 오픈소스가 포함되어 있는지 알고 있어야 소프트웨어를 배포할 때 각 라이선스가 요구하는 의무 사항을 준수할 수 있기 때문이다. 모든 오픈소스는 배포 대상 소프트웨어에 통합하기 전에 검토 및 승인되어야 한다. 오픈소스의 기능, 품질 뿐만 아니라 출처, 라이선스 요건을 충족하는지 검토가 되야 한다. 이를 위해 검토 요청 → 리뷰 → 승인 과정이 필요하다. [부록 02]에서는 기업의 오픈소스 컴플라이언스를 위한 프로세스 전과정에 대해 설명하고 있다. 식별부터 등록까지의 과정을 통해 BOM을 작성하고 관리하게 된다.

{% page-ref page="../../appendix/process.md" %}

공급 대상 소프트웨어에 포함된 오픈소스 목록은 문서화하여 보관해야 한다. Eclipse 재단에서 후원하는 오픈소스 프로젝트인 SW360(https://projects.eclipse.org/proposals/ sw360)은 공급 대상 소프트웨어별로 포함하고 있는 오픈소스 목록을 트래킹할 수 있는 기능을 제공한다. SW360 사용 방법은 [부록 03]을 참고할 수 있다.

오픈소스 컴플라이언스 프로세스의 모든 과정과 결과는 문서화가 되어야 한다. 이메일을 사용하는 것 보다는 Jira, Bugzilla 등의 이슈 트래킹 시스템을 이용하는 것이 이러한 과정을 효율적으로 문서화 할 수 있다.

3.2 라이선스 컴플라이언스

오픈소스 라이선스를 제대로 준수하기 위해서는 오픈소스 라이선스 별로 요구하는 사항에 대해 정확히 알고 있어야 한다. 개별 소프트웨어 개발자가 이를 일일이 파악하는 것은 어렵기 때문에 오픈소스 책임자는 자주 사용되는 오픈소스 라이선스 들에 대해 일반적인 사용 사례별 요구사항/주의사항을 정리하여 회사 내부에 공유하는 것이 좋다. 오픈소스 책임자는 자주 사용되는 오픈소스 라이선스별로 일반적인 사용 사례에 대한 의무 요약 자료를 제공한다. 오픈소스 라이선스에 대한 일반적인 가이드와 라이선스 의무 요약 자료는 NIPA에서 제공하는“공개SW 라이선스 가이드”를 참고할 수 있다. (https://www.oss.kr/oss_license)

[부록 2] 오픈소스 컴플라이언스 프로세스 (예시)의 오픈소스 컴플라이언스 프로세스의 식별, 검사, 문제해결, 리뷰, 승인 단계를 통해 공급 대상 소프트웨어의 오픈소스 컴포넌트에 대해 일반적인 오픈소스 라이선스 사용 사례를 처리할 수 있다.

식별 및 검사 단계에서는 소스코드 스캔 도구를 사용할 수 있다. 소스코드 스캔 도구는 무료로 사용할 수 있는 오픈소스 기반 도구부터 상용 도구까지 다양하게 있다. 각 도구들은 특장점 들이 있지만 어떤 하나도 모든 문제를 해결할 수 있는 완벽한 기능을 제공하지 않는다. 따라서 기업은 제품의 특성과 요구사항에 맞는 적합한 도구를 선택해야 한다. 많은 기업들이 이러한 자동화된 소스 코드 스캔 도구와 수동 검토를 병행하여 이용한다. Linux Foundation의 FOSSology Project는 오픈소스로 공개된 소스 코드 스캔 도구로서 기업들이 손쉽게 무료로 사용할 수 있다. 사용 방법은 [부록 03] 오픈소스도구 (FOSSology, SW360)을 참고할 수 있다.

1.2.4 - 4. 컴플라이언스 결과물 생성 및 전달

3.1장에서 오픈소스 컴플라이언스 활동의 가장 기본은 공급 대상 소프트웨어에 포함된 오픈소스 현황을 파악하는 것이라고 하였다. 이는 바로 오픈소스 컴플라이언스의 핵심인 오픈소스 라이선스의 의무를 파악하여 요건들을 충족하기 위해서이다. 즉, 공급 대상 소프트웨어에 포함된 것으로 식별한 오픈소스에 대한 컴플라이언스 결과물 세트를 생성하는 프로세스가 구축되어야 한다.

컴플라이언스 결과물은 크게 두가지로 구분된다.

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

컴플라이언스 결과물은 공급 대상 소프트웨어를 배포할 때 함께 제공해야 한다.“[부록 02] 오픈소스 컴플라이언스 프로세스(예시)”의 고지, 확인, 배포 단계를 통해 컴플라이언스 결과물을 생성하여 배포한다.

공급 대상 소프트웨어를 배포 시, 공개할 소스코드 패키지를 동봉하는 것이 곤란할 경우, 최소 3년간 소스코드를 제공하겠다는 서면 약정서(Written Offer)를 제공하는 것으로 대신할 수 있다. 일반적으로 서면 약정서는 제품의 사용자 매뉴얼을 통해 제공하며, 예시는 다음과 같다.

The software included in this product contains copyrighted software that is licensed under the GPL. A copy of that license is included in this document on page X. You may obtain the complete Corresponding Source code from us for a period of three years after our last shipment of this product, which will be no earlier than 2011-08- 01, by sending a money order or check for $5 to:

GPL Compliance Division
Our Company
Any Town, US 99999

Please write“source for product Y” in the memo line of your payment.
You may also find a copy of the source at http://www.example.com/sources/Y/.
This offer is valid to anyone in receipt of this information.

따라서, 컴플라이언스 결과물은 3년 이상 보관해야 하며 이를 위한 프로세스가 구축되어야 한다. 기업들은 자체적인 웹사이트(예: http://opensource.lge.com/) 구축하여 외부 고객들이 공급 대상 소프트웨어에 대한 오픈소스 고지문과 공개할 소스코드 패키지를 언제든지 다운받을 수 있도록 편의를 제공한다.

1.2.5 - 5. 오픈소스 커뮤니티 참여에 대한 이해

5.1 기여 (Contributions)

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

[부록 01] 오픈소스 정책 for OpenChain 2.0(예시)의 8장 오픈소스 기여 정책을 참고할 수 있다.

1.2.6 - 6. 설명서 요건 준수

6.1 준수 (Conformance)

기업이 OpenChain을 준수하는 오픈소스 프로그램을 가지고 있다고 선언한다는 것은 OpenChain Specification의 모든 요건을 충족한다는 것이다. 어느 하나의 요건이라도 충족하지 못한다면 OpenChain을 준수한다고 할 수 없다.

OpenChain Specification의 모든 요건을 충족한다면, [부록 01] 오픈소스 정책 for OpenChain 2.0(예시)의 9장에서와 같이 OpenChain을 충족하고 있음을 문서상에 명시할 수 있다.

6.2 기간 (Duration)

오픈소스 프로그램이 OpenChain을 준수한다고 선언한 이후에도 계속해서 준수하는 활동을 유지하는 것이 중요하다. OpenChain Specification 2.0의 6.2.1조에서는 OpenChain을 준수한다고 선언한 이후에도 최소 18개월 이상은 변함없이 OpenChain Specification 2.0의 모든 요건을 준수하고 있어야 함을 요구한다.

기업은 오픈소스 프로그램이 OpenChain을 준수함을 선언한 이후 적어도 18개월 이상 계속해서 준수하는 상태를 유지하여야 하며, 그렇게 하고 있다면, [부록 01] 오픈소스 정책 for OpenChain 2.0 (예시)의 9장에서와 같이 OpenChain을 18개월 이상 계속하여 충족하고 있음을 문서상에 명시할 수 있다.

1.3 - 부록

1.3.1 - 1. 샘플 오픈소스 정책 for OpenChain 2.1

OO회사 오픈소스 정책

1. 목적

이 정책은 오픈소스를 사용하는 조직 전체가 오픈소스 컴플라이언스 활동을 수행하도록 수립되었다. 또한 이 정책은 직원들이 오픈소스의 가치를 이해하게 하고, 오픈소스 커뮤니티에 기여하기 위한 방법을 제공한다.

<OO회사>의 직원은 이 정책의 근거와 내용을 이해하고 필요한 활동을 충실히 수행함으로써 정책의 효과 및 회사의 컴플라이언스 수준 향상에 기여한다.

이 정책을 준수하는 것은 중요하다. 준수하지 않을 경우 다음과 같은 상황을 초래할 수 있다.

• 사용 중인 코드에 대한 저작권 또는 기타 지식재산권 보유자의 법적 클레임
• 고객으로부터의 클레임
• 회사 독점 코드의 의도치 않은 공개
• 라이선스 의무 위반으로 인한 벌금 부과
• 평판 손실
• 수익 손실
• 공급업체 및 고객과의 계약 위반

이러한 이유로 회사는 코드 침해를 심각하게 간주하며, 코드를 침해하는 개인은 회사의 징계 절차에 처해질 수 있다.

2. 적용

이 오픈소스 정책은 [회사가 외부로 제공하거나 배포하는 모든 제품]에 적용된다. 오픈소스를 내부 사용 목적으로만 사용하는 것은 이 정책의 범위에 포함되지 않는다.

또한 이 정책은 <OO회사>의 직원이 오픈소스 프로젝트에 기여하거나 <OO회사>의 코드를 오픈소스로 공개할때 적용한다.

<OO회사>의 오픈소스 정책은 [LINK]에서 확인할 수 있다.

3. 용어

“오픈소스” - Open Source Initiative(OpenSource.org)에서 발표한 Open Source Definition 혹은 Free Software Foundation에서 발표한 Free Software Definition을 충족하는 라이선스, 혹은 유사한 라이선스가 하나 이상 적용된 소프트웨어.

“공급 대상 소프트웨어” - 회사가 제3자 (다른 조직 또는 개인)에게 배포하는 소프트웨어

4. 역할, 책임 및 역량

이 정책의 효과적인 수행을 보장하기 위해 다음과 같이 필요한 역할 및 책임과 각 역할의 담당자가 갖추어야 할 역량을 정의한다.

<OO회사>의 소프트웨어 개발 및 배포를 담당하는 최고 임원은 각 역할 및 책임을 위한 담당자가 지정되고, 역할을 수행할 적절한 자금과 시간이 할당되도록 보장해야 한다.

각 역할의 담당자는 자신의 역할에 대해 적절하게 지원이 되지 않는다면 반드시 오픈소스 책임자를 통해 문제를 해결해야 한다. 적절하게 해결되지 않는다면, 오픈소스 운영위원회를 통해 문제를 제기할 수 있다.

가) 오픈소스 책임자

오픈소스 책임자는 오픈소스가 사용된 <OO회사> 제품의 컴플라이언스를 보장할 책임과 함께 다음 사항에 대한 책임이 있다.

• 오픈소스 정책을 검토, 개선 및 전파한다.
• 효율적인 오픈소스 정책 수행을 위해 회사 내부의 역할 및 책임을 검토하고 할당한다.
• 오픈소스 컴플라이언스 관련 이슈에 대한 교육과 평가를 검토하고 구현한다.
• 오픈소스 운영위원회의 의장을 맡아서 활동을 지휘한다.
• 소프트웨어 개발팀이 오픈소스 정책과 프로세스를 이해하고 준수하도록 안내하는 역할을 하고, 필요할 경우 경영진에게 문제를 제기한다.
• 외부로부터의 오픈소스 사용 및 컴플라이언스에 대한 문의에 답변한다.

오픈소스 책임자는 업무 수행을 위해 오픈소스 관련 IP 리스크, 개발 프로세스를 이해하고, 커뮤니케이션 스킬에 대한 역량을 갖춰야 한다.

2020년 1월 현재 OOO팀의 OOO가 오픈소스 책임자 역할을 담당한다.

나) 오픈소스 센터

오픈소스 센터는 오픈소스 컴플라이언스를 위한 전문 센터이며, 컴플라이언스를 효과적으로달성하기위한프로세스를정의한다. 오픈소스책임자가리더역할을수행 하고, 센터의 구성원들은 오픈소스 책임자가 원활하게 책임을 수행할 수 있도록 돕는 역할을 맡는다. 오픈소스 센터는 다음과 같은 역할을 수행한다.

• 컴플라이언스 실무 교육을 개발 및 제공한다.
• 컴플라이언스 도구를 선택 / 개발 및 배포한다.
• 코드 검사 및 자동 스캔을 수행하여 <OO회사> 제품 내 오픈소스 포함 여부를 식별한다.
• 오픈소스 사용 요청을 검토하고 승인한다.
• 오픈소스 사용 목록에 관한 기록을 유지한다.
• 오픈소스 고지 및 소스코드 공개를 위한 웹 사이트를 개발하고 유지 관리한다.

다) 소프트웨어 개발팀

소프트웨어 개발팀은 소프트웨어 개발에 사용할 오픈소스를 식별하고 오픈소스 센터에 오픈소스 사용 승인 요청을 제출한다.

소프트웨어 개발팀은 소프트웨어 개발에 사용한 오픈소스에 적용되는 오픈소스 라이선스의 의무를 이행할 책임이 있다.

소프트웨어 개발팀은 오픈소스 정책 및 프로세스와 소프트웨어 아키텍쳐를 이해한다.

라) 법무팀

법무팀은 오픈소스 라이선스와 의무를 해석한다. 이러한 의무를 이행하기 위한 가이드를 소프트웨어 개발팀에 제공한다. 호환되지 않는 오픈소스 라이선스로 인한 충돌을 포함하여 라이선스 및 지식재산권 문제에 대해 자문을 제공한다. 필요할 경우 오픈소스 사용 검토 및 승인 결정에 참여한다.

오픈소스 프로젝트로의 기여를 위한 검토 요청에 의견을 제공한다.

5. 교육 및 평가

소프트웨어 배포에 관여하는 <OO회사>의 모든 직원은 교육 및 평가를 통해 오픈소스 정책을 숙지한다.

이 정책을 수행하는 모든 대상자는 자신의 역할에 필요한 역량을 다루는 최소한의 기본 교육을 수강하고 평가를 받는다.

교육 및 평가 프로그램은 <OO회사> 오픈소스정책의 목표, 컴플라이언스 수준 향상에 기여 하기 위한 참여자의 역할 및 컴플라이언스 미준수 시 회사 및 개인에 미치는 영향 등에 대해 다룬다.

평가 기록은 최소 3년동안 유지한다.

6. 오픈소스 사용 정책

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

이를 효과적으로 수행하기 위해 <OO회사> 오픈소스 컴플라이언스 프로세스를 준수한다.

오픈소스 라이선스 준수를 위한 과정에서 의문사항이 있는 경우 [오픈소스 책임자]는 법무팀에게 문의 할 수 있다.

오픈소스 사용 결정 결과 및 관련 근거는 오픈소스 이슈 추적 시스템에 기록한다.

7. 외부 문의 대응 정책

<OO회사>에서 배포한 소프트웨어에 대해 외부에서 오픈소스 관련한 문의 및 요청을 할 수 있도록 공개된 연락처를 제공한다. 이를 위해 소프트웨어 배포 시 오픈소스 센터의 이메일 주소를 제공하고,
Linux Foundation의 Open Compliance Directory (https://compliance. linuxfoundation.org/ references/open-compliance-directory/)에 <OO회사>의 연락처를 등록한다.

외부로부터 오픈소스 관련 문의를 받은 사람은 누구나 오픈소스 책임자에게 문의한다. 오픈소스 책임자는 문의를 처리하고 회사 내 적절한 개인 또는 조직에 할당한다. 오픈소스 책임자는 문의를 할당하고 처리하는 것에 대한 전반적인 책임이 있다.

<OO회사>에서 배포한 소프트웨어에 대해 외부로부터 컴플라이언스 미준수 이슈가 제기될 경우, 오픈소스 책임자는 다음과 같이 처리한다.

1. 질의 접수 승인 및 적절한 해결 시간을 명시한다.
2. 질의가 진짜 문제인 것인지를 확인한다. (아니라면 영업일 기준 3일 이내에 질의자에게 응답한다.)
3. 이슈가 진짜 문제라면, 3일 이내에 적절한 대응 방법을 결정하고, 질의자에게 대응 계획에 대해 응답한다.
4. 결정한 방법에 따라 30일 이내에 대응하고, 질의자에게 문제가 해결되었음을 알린다.
5. 이상의 사항을 오픈소스 이슈 추적시스템에 기록한다.

8. 오픈소스 기여 정책

<OO회사>는 오픈소스에서의 비즈니스 가치 창출을 위해 외부 오픈소스 프로젝로의 참여와 기여를 권장한다. 그러나 의도하지 않은 지식 재산의 노출 혹은 침해를 주의해야 한다.

회사의 업무와 관련이 있는 오픈소스 프로젝트에 기여하기 위해서는 먼저 SW개발팀 리더에게 승인을 받아야 한다.

그리고 오픈소스 프로젝트의 오픈소스 라이선스와 특허 조건을 검토한다. 또한 기여 하고자 하는 오픈소스 프로젝트가 요구하는 DCO (Developer Certificate of Origin), CLA (Contributor License Agreement)등의 문서 서명에 대해 검토해야 한다. 필요할 경우 법무팀에 검토를 요청할 수 있다.

9. OpenChain 준수

<OO회사>는 소프트웨어 공급망에서의 오픈소스 컴플라이언스 수준 향상을 위해 Linux Foundation의 OpenChain 프로젝트의 정신을 지지하며 적극적으로 참여한다. <OO회사>의 오픈소스 정책은 OpenChain Specification 2.0을 준수하도록 설계되었다.

<OO회사>는 <OO회사>의 오픈소스 정책을 포함하는 오픈소스 프로그램이 OpenChain Specification 2.0의 모든 요건을 준수하고 있음을 확약한다.

<OO회사>는 <OO회사>의 오픈소스 정책을 포함하는 오픈소스 프로그램이 OpenChain Specification 2.0의 모든 요건을 준수하고 있음을 확약한 이후 18개월 동안 여전히 모든 요건을 준수하기 위한 활동을 수행하고 있음을 확약한다.

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

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

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

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

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

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

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

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

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

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

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

• 오픈소스 사용 요청 접수 : SW개발자는 특정 제품에 오픈소스를 사용하고자 함을 오픈소스 책임자 또는 오픈소스 센터에 알리고, 검토 및 승인을 위한 오픈소스 패키지의 용도에 관한 정보를 제공한다.
• 회사 개발 소프트웨어 검사 (Auditing) : 개발자가 오픈소스의 소스코드를 복사해서 가져와 소프트웨어를 개발할 수 있기 때문에 회사가 개발한 소프트웨어에 대해서도 검사를 수행한다.
• 제3자 소프트웨어 실사 (Due diligence)

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

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

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가 오픈소스 구성요소의 사용을 승인하면 개발팀은 라이선스 의무를 이행하기 위한 준비를 시작한다.

Step 6. 등록 (Registration)

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

Step 7. 고지 (Notices)

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

• 저작권, 라이선스 고지를 제공한다.
• 라이선스 사본을 제공한다.
• (해당되는 경우) 소스 코드 사본을 얻을 수 있는 방법을 최종 사용자에게 알린다.

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

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

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

• 오픈소스 라이선스가 요구하는 공개할 소스 코드를 취합한다.
• 취합한 소스 코드는 제품에 탑재된 바이너리와 매치되어야 한다.
• 소스 코드 내 부적절한 주석을 제거한다.
• 적절한 고지문이 제품에 포함되었다. 여기에는 최종 사용자가 소스 코드를 받을 수 있는 방법 (Written Offer)도 함께 제공한다.

Step 9. 배포 (Distribution)

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

Step 10. 최종 확인 (Final Verifications)

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

1.3.3 - 3. 오픈소스도구 (FOSSology, SW360)

오픈소스 컴플라이언스 활동을 위해서는 정책, 프로세스나 교육자료뿐만 아니라 소스코드 스캔, Dependency 분석, 오픈소스 BOM 관리 등을 위한 다양한 도구와 시스템도 요구된다. 때문에 다수의 기업이 이러한 도구와 시스템을 도입하고 활용하는데 많은 리소스를 투입하고 있다. 특히 오픈소스 컴플라이언스를 처음 시작하는 기업은 프로세스뿐 아니라 비용 측면에서도 어려움을 겪고 있다.

이런 어려움을 해결하기 위해, 2019년 6월, OpenChain 프로젝트에 참여하고 있는 지멘스, 보쉬, 도시바, 후지쓰, 히타치 등의 오픈소스 컴플라이언스 도구 전문가들을 주축으로 OpenChain Tooling Work Group이 시작되었다.

OpenChain Tooling Work Group은 여러 기업의 오픈소스 전문가들이 이슈를 함께 해결하고 결과물을 공유해 오픈소스 컴플라이언스 비용을 절감하고 양질의 컴플라이언스 결과물을 만들어 내기 위해 구성되었다.

구체적으로는 FOSSology, SW360, Software Heritage, ClearlyDefined, SPDX 등의 기존 오픈소스 프로젝트를 활용하여 통합(turn-key) 오픈소스 툴 체인을 만들고, 모든 기업이 이를 자유롭게 사용할 수 있도록 하는 것을 목표로 삼고 있다. (https://groups.io/g/oss-based-compliance-tooling)

여기서는 FOSSology와 SW360에 대해 소개 및 간단한 사용 방법에 대해 알아본다.

1.3.3.1 - FOSSology

오픈소스 컴플라이언스를 위해 소프트웨어 내에 포함된 오픈소스와 라이선스 정보를 검출하기 위해 소스코드 스캔 도구를 사용할 수 있다.

Linux Foundation의 FOSSology 프로젝트는 이러한 스캔 도구를 개발하고 오픈소스로 공개해 누구나 자유롭게 사용할 수 있게 한 도구이다.

주요 특징

FOSSology는 웹기반의 프로그램으로 사용자는 웹사이트에 로그인하여 개별 파일 혹은 소프트웨어 패키지를 업로드할 수 있다. FOSSology는 업로드된 파일 내에 라이선스 텍스트와 Copyright 정보를 검출한다. 개발자는 사용하고자 하는 오픈소스의 라이선스가 무엇인지, Copyright은 어떻게 되는지에 대한 정보를 확인하고자 할때 FOSSology를 이용하는 것이 좋다. FOSSology는 개발자가 업로드한 오픈소스 패키지 내의 모든 파일을 스캔하여 각 파일 내 라이선스 관련 텍스트와 Copyright 정보를 자동으로 검출하고, 이를 리포트로 생성한다. FOSSology 주요 특징에 대한 자세한 내용은 다음 페이지를 참고할 수 있다. : https://www.fossology.org/features/

설치

기업 내에서 FOSSology를 사용하기 위해서는 사내에 FOSSology 서버를 구축해야 한다. 이를 위해 리눅스 기반의 서버 시스템에 FOSSology를 설치해야 한다. FOSSology는 다음 세 가지 방법으로 설치할 수 있다.

1. Docker 사용
2. Vagrant와 VirtualBox 사용
3. Source build하여 설치

여기서는 가장 간편한 방법인 Docker를 사용하는 방법에 대해 설명한다.

FOSSology는 컨테이너화 된 Docker 이미지를 Docker Hub (https://hub.docker.com/)를 통해 공개하고 있다. : https://hub.docker.com/r/fossology/fossology

Pre-built 된 Docker 이미지는 다음 명령어를 사용하여 실행할 수 있다.

$ docker run -p 8081:80 fossology/fossology

Docker 이미지는 다음 URL과 계정 정보로 사용할 수 있다. : http://[IP_OF_DOCKER_HOST]:8081/repo

• Username : fossy
• Passwd : fossy

설치와 관련한 자세한 내용은 다음 페이지를 참고할 수 있다. : https://github.com/fossology/fossology/blob/master/README.md

테스트 서버

FOSSology를 설치할 수 있는 시스템 구축이 곤란한 상황이라면, FOSSology Project에서 제공하는 테스트 서버를 이용할 수 있다. FOSSology 프로젝트에서는 테스트를 위한 환경을 제공한다. (테스트 서버는 예고없이 중단될 수 있다.)

사용자는 다음 계정으로 FOSSology 테스트 서버에 접속하여 FOSSology 기능을 시험해볼 수 있다.

Basic Workflow

FOSSology의 기본 사용 절차는 다음과 같다.

• 사용하고자 하는 오픈소스의 라이선스와 Copyright 정보를 확인하기 위해 오픈소스의 소스 코드를 하나의 파일로 압축하여 FOSSology에 업로드한다.
• 이를 위해 메뉴 > Upload > From File을 선택합니다.

• 업로드할 파일을 선택하고 Upload 버튼을 클릭한다.
• 업로드가 완료되면 Job Agent에 의해 자동으로 분석을 수행한다.
• 메뉴 > Jobs > My Recent Jobs에서 분석 중인 Status를 확인할 수 있다.

• 분석이 완료되면 메뉴 > Browse에서 분석 결과를 확인할 수 있다.

• 개별 파일을 선택하면 FOSSology가 검출한 라이선스 관련 텍스트가 무엇인지 확인할 수 있다.

• 메뉴 > Browser > 파일 혹은 디렉터리를 선택 > Copyright/Email/Url/Author에서는 FOSSology가 검출한 Copyright/Email/Url/Author 정보를 보여다.

사용자는 FOSSology는 이렇게 분석한 결과가 유효한지 여부에 대해 확인 후 잘못 검출된 항목에 대해서는 분석 결과에서 제외시키는 작업을 할 수 있다. FOSSology는 이를 Clearing 과정이라고 설명하며, 자세한 사항은 다음 페이지를 참고할 수 있다. : https://www.fossology.org/get-started/basic-workflow/

위와 같은 방법으로 사용하고자 하는 오픈소스의 라이선스는 무엇인지, Copyright 정보는 어떻게 되는지를 간단히 확인할 수 있다.

1.3.3.2 - SW360

오픈소스를 포함하는 제품을 개발하고 배포하는 기업이라면 각 제품과 릴리스 버전마다 사용한 오픈소스의 버전, 라이선스 등의 정보를 수집하고 추적해야 한다. 이를 통해 기업은 올바른 오픈소스 컴플라이언스 활동을 수행할 수 있다.

특히, NVD (https://nvd.nist.gov/vuln)에서 특정 오픈소스 버전에 보안 취약점이 보고 되었을때, 해당 버전을 사용하고 있는 제품이 무엇인지 추적을 할 수 없다면, 그 기업은 어느 제품에 보안 패치를 적용해야 할 지 알 수 없는 상황에 처하게 되고, 그 기업의 제품들은 보안취약점에 그대로 노출이 될 수 밖에 없다.

이렇듯, 오픈소스 정보를 추적하는 활동은 꼭 필요하다. 기업들은 이를 위해 자체 시스템을 구축하거나, 상용 서비스를 구매하여 사용하기도 한다. SW360은 Eclipse 재단에서 후원하는 오픈소스로서 소프트웨어 BOM에 대한 정보를 수집 및 추적하기 위한 웹 애플리케이션 및 저장소를 제공한다.

주요 특징

SW360은 웹 기반의 UI를 제공하며 주요 기능은 다음과 같다.

• 제품에 사용된 컴포넌트 추적
• 보안 취약점 평가
• 라이선스 의무 관리
• 고지문 등 법적 문서 생성

설치

SW360은 다음과 같이 구성된다.

• Frontend : Liferay-(Tomcat-)based portal application
• Backend : Tomcat-based thrift service
• Database : CouchDB

Project 구조와 설치를 위해 요구되는 소프트웨어 등 자세한 내용은 README의 Required software 부분에서 확인할 수 있다. : https://github.com/eclipse/sw360/blob/master/README.md

SW360은 다음 세 가지의 설치 방법을 제공한다. 사용자는 이 중 하나를 선택하여 설치할 수 있다.

1. Vagrant (https://www.vagrantup.com/) 기반 설치 : Vagrant는 가상화 인스턴스를 관리하는 도구로서 sw360vagrant에서는 SW360을 한 번에 Deploy 하기 위한 환경을 제공한다. : https://github.com/sw360/sw360vagrant
2. SW360의 구성요소를 개별적으로 설치할 수 있다. : https://github.com/eclipse/sw360
3. Docker를 통해 Deploy 할 수 있다. : https://github.com/sw360/sw360chores

여기서는 CentOS 7.6 시스템에 Vagrant 기반으로 설치하여 Deploy하는 방법을 소개한다. 자세한 사항은 README를 참고한다. : https://github.com/sw360/sw360vagrant/blob/master/README.md

1) 사전 설치

vagrant box에 SW360을 설치하기 위해서는 openjdk, VirtualBox 및 Vagrant를 설치해야 다. 먼저 openjdk 1.8.0을 설치한다.

$ yum install java-1.8.0-openjdk
$ java -version
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-b12)”
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

VirtualBox를 설치한다.

$ sudo wget https://download.virtualbox.org/virtualbox/rpm/el/virtualbox.repo -P /etc/yum.repos.d
$ sudo yum install VirtualBox-5.2

CentOS 7에서 VirtualBox 설치 시, “kernel module is not loaded’ 에러가 발생할 경우, kernel-devel을 설치하여 해결한 후 VirtualBox를 재설치한다.

$ sudo yum install https://centos7.iuscommunity.org/ius-release.rpm
$ sudo yum install dkms
$ sudo yum install kernel-devel
# reboot
$ sudo /sbin/vboxconfig
$ systemctl status vboxdrv
● vboxdrv.service - VirtualBox Linux kernel module
   Loaded: loaded (/usr/lib/virtualbox/vboxdrv.sh; enabled; vendor preset: disabled)
   Active: active (exited) since Wed 2020-02-19 09:06:02 KST; 20min ago

Vagrant와 vagrant-aws plugin을 설치한다.

$ sudo yum install https://releases.hashicorp.com/vagrant/2.2.6/vagrant_2.2.6_x86_64.rpm 
# vagrant-aws plugin 설치
$ vagrant plugin install vagrant-aws

그리고, sw360vagrant 코드를 Clone 한다.

$ git clone https://github.com/sw360/sw360vagrant.git

2) Dependency 다운로드

Vagrant box를 빌드하는 시간을 줄이기 위해 Dependency Package들을 미리 다운로드 받는다.

$ cd sw360vagrant
$ ./download-packages.sh

그러면 다음의 package들이 ./shared/package 폴더 안에 다운로드 된다.

• Liferay 7.2.1 CE GA2 with Tomcat (9.0.17)
• Postgresql-42.2.9 ODBC client for Java as *.jar file
• SW 360에서 필요한 11개의 *.jar 파일
• Thrift 0.11
• A box images from the Ubuntu 16.04 LTS (xenial-server-cloudimg-amd64-vagrant.box)

3) Base box 생성

이제 다음 명령어로 Base box를 생성한다.

$ cd generate-box
$ ./generate_box.sh

이 작업은 수십 분 소요될 수 있다.

4) Box 실행

다음 명령어로 Box를 실행한다.

# If you have built a vagrant box from this directory earlier, you will have to destroy it first via
$ vagrant destroy
$ cd ../sw360-single
$ vagrant up

Box를 실행하면 liferay, postgresql 및 couchdb가 구성된다. 이상없이 실행이 될 경우, https://localhost:8443/ 로 Liferay 화면에 접근할 수 있다.

5) SW360 Layout Deploy

마지막 단계는 Liferay에서 SW360의 Layout을 Deploy하는 것이다. 이 작업은 아직 자동화가 되지 않아 관리자가 수동으로 수행해야 다. https://localhost:8443/에 접근하여 다음 계정으로 로그인한다.

• id : setup@sw360.org
• pw : sw360fossy

이후에는 다음 사이트의 안내에 따라 Layout deploy를 수행한다. https://github.com/eclipse/sw360/wiki/Deploy-Liferay7

Deploy가 완료되면 다음과 같은 화면을 볼 수 있다.

Basic Workflow

1) License 등록

SW360을 처음 설치하면 먼저 자주 사용하는 오픈소스 라이선스 들을 등록해야 한다. 라이선스 다음과 같은 정보를 포함한다.

• Full Name
• Short Name
• License Type
• GPL-2.0 Compatibility (예: yes, no)
• License Text

메뉴 > Licenses > Add License를 선택하면 다음과 같이 Create License 화면으로 진입한다.

이와 같이 라이선스를 하나씩 수동으로 등록하는 일은 상당히 수고스러울 수 있는데, 다행히 SW360은 SPDX License List를 한 번에 Import 하는 기능을 제공한다. 메뉴 > Admin < Import SPDX Information을 클릭한다.

그러면, 곧 SPDX License List가 자동으로 등록됩니다. 메뉴 > Licenses에서 338개의 License가 등록된 것을 확인할 수 있다.

2) Component 및 Release 등록

SW360에서 Component는 하나의 소프트웨어 단위이다. 여기에는 다양한 형태의 소프트웨어가 해당할 수 있으며, 그 예는 다음과 같다.

• 오픈소스 소프트웨어
• 라이브러리
• 3rd party 소프트웨어

Component는 다음과 같은 정보를 포함한다.

• Component Name
• Main Licenses
• Categories (예: Library, Cloud, Mobile, …)
• Component Type (예: OSS, Internal, InnerSource, Service, Freeware)
• Default Vendor
• Homepage URL

Release는 Component에서 하나의 Version을 가리키는 단위이다. 따라서 하나의 Component는 여러 개의 Release를 가질 수 있다. Release는 하나의 Component 하위에 생성되어 관리된다.

Release는 다음과 같은 정보들을 포함한다.

• Component Name
• Version
• License
• Download URL
• CPE ID (예: cpe:2.3:a:apache:maven:3.0.4)

예를 들어, zlib-1.2.8을 등록해야 한다면, 먼저 Component에 zlib을 먼저 등록한 후, Release에 zlib 1.2.8을 등록한다. Menu > Components > Add Component를 선택하면 Create Component 화면으로 진입하여 zlib에 대한 정보를 등록할 수 있다.

Component를 생성하면, Components > Releases > Add Release에서 zlib-1.2.8 version에 대한 정보를 등록할 수 있다.

하나의 zlib이라는 Component에 1.2.8과 1.2.11 version을 각각의 Release로 등록하였을 때, Release Overview 화면에서 다음과 같이 2개의 Release가 존재하는 것을 볼 수 있다.

SW360은 다수의 Component 정보를 Import 시키기 위한 기능을 제공한다. 메뉴 > Admin > Import / Export에 CSV template에 등록을 원하는 Component 정보를 입력 후 Import 할 수 있다.

단, 이 기능은 2020년 2월 기준 아직 안정적으로 동작하지 않을 수 있다.

3) Project 생성

Project는 하나의 제품을 가리킨다. 사업 유형에 따라 제품일수도 있고, 서비스 혹은 소프트웨어 일수도 있다. Project에는 제품에 사용된 Component/Release를 등록하여 관리한다.

Project 생성 시에는 다음과 같은 정보를 등록한다.

• Project Name
• Version
• Project type (예: Product, Customer Project, Service, Internal Project, InnerSource)

메뉴 > Projects > Add Project를 통해 Project를 생성할 수 있다.

Project를 생성하고 나면, 포함하는 Release나 하위 Project를 등록한다. 메뉴 > Projects에서 해당 Project를 선택하면 “Linked Releases and Projects”에서 Linked Projects와 Linked Releases를 등록할 수 있다.

다음은 SuperCalc라는 Project에 OpenSSL 1.0.1과 zlib 1.2.8을 Linked Releases로 등록한 이후의 화면이다.

4. 보안 취약점 관리

SW360은 등록된 Release에 대해 보안 취약점이 있는지 자동으로 확인할 수 있다. 이를 위해 SW360은 CVE 정보를 주기적으로 수집하도록 스케쥴링하는 기능을 제공한다. 메뉴 > Admin > Schedule 에서 CVE SEARCH 정보를 24시간마다 수집하도록 스케쥴링을 설정할 수 있다.

이렇게 스케쥴링을 설정하면 SW360은 정해진 시간에 CVE Search 사이트(https://cve.circl.lu/)에서 CVE 정보를 수집한다. 수집한 CVE 정보는 메뉴 > Vulnerabilities에서 확인할 수 있다.

이렇게 Vulnerabilities 정보가 수집된 이후에는 생성한 Project에 보안 취약점이 있는지 조회할 수 있다. 위에서 생성한 SuperCalc Project에서는 85개의 보안 취약점이 보고된 것을 확인할 수 있다.

이와 같은 방법으로 기업에서 개발/배포하는 소프트웨어를 SW360에 등록하여 관리한다면, 오픈소스 컴플라이언스뿐만 아니라 보안 취약점에 대해서도 리스크를 최소화할 수 있는 형태로 관리가 가능하다.

또한 SW360은 위와 같은 Web Interface 뿐만 아니라 대부분의 기능을 REST API로 제공하여서 FOSSology 등의 다른 도구와의 연동이 가능하다. : https://github.com/eclipse/sw360/wiki/Dev-REST-API

즉, 소스 코드 스캐닝 도구의 분석 결과를 SW360에 Import 시키는 등의 방법으로 DevOps에 Integration 시켜서 Project, Release 등록을 자동화시켜서 관리한다면 효율성이 크게 증가될 것이다.

2 - [out of date] Open Source Governance for Enterprises

References

This guide has referenced the following resources:

1. OpenChain Project Website
2. OpenChain Open Source Policy Template
3. Open Source Compliance In The Enterprise

2.1 - 1. What is ISO/IEC 5230

You can find everything about ISO/IEC 5230 on the OpenChain project website. : https://www.openchainproject.org/

2.2 - 2. Essential elements

Essential elements of an open source program

You need the following components to build an effective open source governance for your comapny.

Among the above elements, in order to establish an open source governance suitable for all items required by ISO/IEC 5230, a company must have the following five core elements.

1. Team
2. Policy
3. Process
4. Tool
5. Education

2.3 - 3. Team

Identify the roles and the corresponding responsibilities

In order to establish a company’s open source governance, it is necessary to appoint a person in charge of it. It may be called an open source program manager, an open source compliance officer, etc., and this person in charge is responsible for the overall open source compliance of the company.

A person with the following competencies is suitable for this role.

• Understanding and development experience in the open source ecosystem
• Broad understanding of the company’s business
• Passion and communication skills to spread the effective use of open source to members of the company

An open source program manager should be guaranteed to be able to perform the role as full-time as possible.

Global ICT companies are working hard to hire such excellent open source program managers, and you can check various job postings at the following site. : https://github.com/todogroup/job-descriptions

To establish open source governance, you need to define the needs of each role and determine what responsibilities should be assigned. For small businesses, it is possible for an open source program manager to perform all the roles alone. Depending on the size of the enterprise, an infrastructure person who operates open source tools may be required, and the role of a legal person may be required to provide professional legal advice.

In general, the following roles are required to establish a corporate open source governance system.

• Legal
• Infrastructure
• Development culture
• Security

If you do the above, you can prepare the following evidence required by ISO/IEC 5230.

Define competencies

Once you have defined each role and its responsibilities, you need to figure out what competencies the person performing that role should have. This is because, through this, it is necessary to evaluate whether the person in charge of each role has the capability to perform the role, and if there is not enough, the company must provide the necessary training to him.

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

Identify person or group

The open source program manager, in consultation with the relevant department, designates and documents the person in charge for each role. Of course, for this, it will be necessary to report the goals and directions for establishing an open source compliance system to the top decision makers such as the CEO to receive the necessary support.

Open source-related person and group in charge do not necessarily have to participate in open source work full-time. You can organize a virtual group in the form of an OSRB (Open Source Review Board) and perform the necessary roles.

SK Telecom has formed the OSRB to create open source policies and processes, and prepare countermeasures when issues arise.

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

The table below is a sample representative that specifies the roles of open source-related organizations and people in charge, and the required competencies. You can refer to this and form an open source organization and document it.

This can also be found on this page. : appendix-1-list-of-persons-in-charge

If you organize in this way, you will now meet the following three requirements among the requirements of ISO/IEC 5230.

2.4 - 4. Policy

Document open source policy

A company should establish, document, and disseminate an open source policy composed of principles for a company to properly use open source in software development, service, and distribution.

Common open source policies include:

• Principles for creating and distributing software products and services using open source
• Principles for contributing to the external open source community
• Principles for releasing open source

The following pages provide sample open source policy documents that meet the requirements of ISO/IEC 5230. : “Appendix 1. Open Source Poicy (Sample)”

Each company can use this sample policy by modifying it according to the company’s business strategy and environment.

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

Define scope

An open source program does not necessarily apply to the entire organization. The scope can be specified differently depending on the characteristics of each organization and product within the company. Different open source programs can be applied to different organizations and products. Similarly, organizations that do not distribute software at all may be excluded from the scope of the open source program. A company can clearly define the scope and limits of the application of an open source program in consideration of the characteristics of the organization and product, and specify it in the open source policy.

As a company’s organization and its products and services change with the business environment, it may be necessary to determine or modify the scope of the program. A company should prepare a procedure to manage it as in the following example.

1. When starting a new project, the open source program manager determines whether the project falls within the scope of the program’s coverage.
2. If it is determined that the project is not included, a proposal to include the project in the scope of application is submitted to the OSRB.
3. If accepted by OSRB, the scope of the open source program will be modified accordingly.
4. Other than that, if the open source program manager determines that it is necessary to review the program scope, it may start the program scope review according to the same process.

The following examples can be included in the open source policy.

2. Scope
This policy applies to the following three parts:

1. Applies to [all products provided or distributed by the company externally]. 
   However, the open source only for internal use is not included in the scope of 
   this policy.
2. Applied when contributing to external open source projects.
3. Applied when releasing internal code as open source.

The scope can be changed according to the business environment of the company, 
and the procedure for this is as follows.

1. If the open source program manager determines that it is necessary to change 
   the scope of policy according to changes in the company's business environment, 
   such as a new business or reorganization, submit a proposal for this to the OSRB.
2. OSRB approves proposals for scope changes at the appropriate level.
3. OSRB modifies the open source policy to change the scope of the policy.

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

Respond to external inquiries

For products or services developed using open source, customers and open source copyright holders may raise open source related inquiries, requests and claims to companies. The main contents of external inquiries and requests are as follows.

• Ask if open source is used for certain products and services
• Request to provide source code under the GPL, LGPL license mentioned in the Written Offer
• A request for a description of the open source found in the product and disclosure of the source code, although not specified in the open source notice
• Request to provide missing files and build methods in the source code published under GPL, LGPL, etc.
• Request for copyright notice

You should designate a contact person to handle these external inquiries. This is usually done by an open source program manager.

In addition, even if an external open source developer wants to contact a company representative to discuss an issue related to a specific company’s open source compliance, they cannot find a way to contact them and eventually file a legal claim. In order to prevent this, you must always disclose publicly how to contact the company from outside to make inquiries and requests related to open source.

To disclose your contact information so that external open source related inquiries can be received, (1) publicly disclosed the email address of the company’s open source program manager, or (2) the Linux Foundation’s [Open Compliance Directory] (https://compliance.linuxfoundation. org/references/open-compliance-directory/).

It is also a good idea to disclose the representative email address of the company open source program office in the open source notice that accompanies the product and service.

These contents can be included in the open source policy as in the example below.

Respond to external inquiries

(1) Responsibility for responding to external inquiries
The open source program manager is responsible for responding 
to inquiries and requests for open source compliance from 
outside.<sub>(3.2.1.2)</sub>

* The open source program manager may assign all or part of 
  the handling of inquiries to appropriate personnel within the 
  company. If necessary, contact the legal team to deal with it.
* Anyone who receives an inquiry about open source compliance 
  from outside will notify the open source program manager so 
  that a prompt response can be made.

(2) Disclosure of contact information
The open source program manager publicly provides the contact 
information of the person in charge so that external inquiries 
and requests related to open source can be submitted to the 
company.<sub>(3.2.1.1)</sub>

* Include the email address of the person in charge in the open 
  source notice.
* Register your contact in the Linux Foundation's Open Compliance 
  Directory.

(3) External Inquiry Response Procedure
If you respond quickly and accurately to open source compliance 
inquiries from outside, you can significantly reduce the risk of 
going to a lawsuit. To this end, in order to respond to external 
open source compliance inquiries, you should follow the external 
inquiry response process defined in the company's open source 
compliance process.<sub>(3.2.1.2)</sub>

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

Provide staff and funding

You must provide sufficient resources for open source programs to function properly. Staff for each role in the program should be appropriately assigned, and sufficient funding and working hours should be ensured. If there is a shortage, there should be a procedure to make up for it. The following example sentences can be added to the open source policy document.

4. Roles, Responsibilities and Competencies

The head of the organization responsible for each role designates 
a person in charge within the organization, and allocates appropriate 
time and budget for the person in charge to fulfill the role.
 * The person in charge of each role should raise an issue with 
   the open source program manager if appropriate support is not 
   provided while performing his/her role.
 * The open source program manager discusses problem solving with 
   the head of the organization. If not properly resolved, the open 
   source program manager may request the OSRB to resolve the issue.
 * OSRB shares the problem with the head of the higher level organization 
   and asks for a solution.

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

Identify Legal Expertise

You should provide a way for the person in charge of each role to seek legal advice when a legal review is needed to resolve an open source compliance issue.

The legal team within the company provides legal advice first, and if the issue is complex, you can seek advice from an external law firm with an open source lawyer. An example of an open source policy for this is as follows.

4. Roles, Responsibilities and Competencies

(2) Open Source Program Manager
* Provides a way to request legal advice on open source.

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

For reference, the OpenChain project provides a list of global law firms that provide open source-related advice through partner programs. : https://www.openchainproject.org/partners

Assigns internal responsibilities

There should be a process for assigning internal responsibilities for open source compliance. This is the role of an open source program manager. The open source program manager must identify the issues and assign them appropriately to the person in charge of each role. To do this, you should include this in your open source policy document as follows:

4. Roles, Responsibilities and Competencies

(2) Open Source Program Manager

The open source program manager is responsible for the overall 
responsibility for the company's open source programs. 
To ensure open source compliance of products and services using 
open source, open source program manager is responsible for:

- Define the roles required for open source compliance, and 
  designate a responsible person and group in charge of each 
  role. Consult with OSRB if necessary.

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

Handle non-compliant cases

Businesses should document procedures for promptly reviewing and responding to non-compliance cases. Refer to the following examples and include them in your open source policy.

6. Use open source

(5) Compliance Issue Remediation Procedure

Should a non-compliance issue be raised, the Open Source Program Manager 
responds promptly by performing the following procedures.

1. Acknowledge receipt of the query and state a reasonable time for resolution;
2. Determine whether the query discloses a genuine issue or not 
   (and if not, respond to the querier accordingly);
3. If the issue is genuine, apply to prioritise, and determine the appropriate response.
4. Carry out response and, where necessary, improve open source compliance processes.
5. Document the above using Jira Tracker.

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

Open Source Contribution Policy

Global IT companies value not only the use of open source to make products and services, but also the strategic value that can be created by contributing to open source projects. However, if you contribute without a sufficient understanding and strategy for the open source project ecosystem and how the community operates, unexpected legal risks may arise and the company’s reputation may be damaged. Therefore, it is important for companies to create strategies and policies for participation and contribution to open source projects.

The following pages provide sample open source contribution policy documents. : 7. Open Source Contribution

If you do this, you can prepare the following evidence required by ISO/IEC 5230.

If you even establish an open source policy that includes the above, the following green items among the ISO/IEC 5230 requirements will be satisfied.

2.5 - 5. Process

A process is an actionable procedure that enables a company to comply with open source policies during software development/distribution. Simply put, the open source compliance process is an activity to comply with the obligations required by each license for the open source used while developing and distributing software, and it generates artifacts such as open source notices and source code to be disclosed.

If the open source compliance process is subdivided and schematized, it is shown in the figure below.

The image below is a sample open source compliance process that companies can commonly use.

You can refer to the next page for more details on this. : 2. Open Source Compliance Process (Sample)

This chapter describes the elements that an open source compliance process should include.

Identify and audit

In order to determine whether an open source can be used, it is necessary to first identify the license of the open source to be used and check the obligations required by the license. You should review and record whether you used open source, what the licenses are, and what obligations each license gives you. An example of the procedure for this is as follows.

1. The development team makes a preliminary assessment of the license based on the open source policy.
2. In case of any doubt, contact the open source program manager, and if necessary, the open source program manager refers the question to external legal experts.
3. The outcome of any determination, and associated rationale (whether internal or external) is recorded.

The Identification of Open Source, Auditing Source Code, Resolving Issues, Reviews, and Approval steps are an example of a documented process for reviewing and documenting the obligations, restrictions and rights imposed by each identified license.

If you prepare such a procedure, you can prepare the following evidence required by ISO/IEC 5230.

In the open source identification and audit phase, you use a code scan tool to inspect the source code. For details on this, refer to “6. Tool”.

Create Bill of Materials

The most basic of open source compliance activities is to determine open source included in the supplied software. It is necessary to establish a process for creating and managing a Bill of Materials (BOM) containing the information by identifying the open source included in the supplied software and identified license. This is because it is necessary to know which open source is included in each version of the supplied software so that when distributing the software, you can comply with the obligations required by the identified license of each open source.

All open source must be reviewed and approved prior to integration into the supplied software. It should be reviewed in advance whether it can meet license requirements as well as the function and quality of open source. For this, a review request → review → approval process is required.

Appendix 2. Open Source Compliance Process (Sample) explains all the processes for open source compliance. BOM is created and managed through the process from 1. Identification of Open Source to 6. Registration.

The tool for managing the open source BOM is described in detail in “6. Tool”.

In addition, all processes and results of such an open source compliance process should be documented. Rather than using e-mail, it is better to use an issue tracking system such as [Jira] (https://www.atlassian.com/software/jira) and [Bugzilla] (https://www.bugzilla.org/) to effectively document this process.

If you prepare such a procedure, you can prepare the following evidence required by ISO/IEC 5230.

Create Artifacts

As mentioned above, the most basic of open source compliance activities is to determine the open source included in the supplied software. This is to properly meet the open source license requirements, which are the core of open source compliance. In other words, a process for generating a set of compliance artifacts for open source included in the supplied software should be established.

Compliance artifacts are divided into two main categories.

1. Open Source Notice: A document to provide full open source license and copyright information

   

   • The method of automatically generating an open source notice corresponding to an open source BOM is further described in “6. Tool”.

2. Source code package to be disclosed: A package that collects source codes to be disclosed to fulfill open source license obligations that require source code disclosure such as GPL, LGPL, etc.

Compliance artifacts must be provided when distributing supplied software.

In “Appendix 2. Open Source Compliance Process (Sample)”, the compliance artifacts are created and distributed through 7. Notices to 9. Distribution.

When distributing supplied software, if it is difficult to enclose the source code package to be disclosed, it can be replaced by providing a written offer to provide the source code for at least 3 years. Typically, a written offer is provided through the product’s user manual, examples of which are as follows.

The software included in this product contains copyrighted software 
that is licensed under the GPL. A copy of that license is included 
in this document on page X. You may obtain the complete Corresponding 
Source code from us for a period of three years after our last shipment 
of this product, which will be no earlier than 2011-08- 01, by sending 
a money order or check for $5 to:

GPL Compliance Division
Our Company
Any Town, US 99999

Please write“source for product Y” in the memo line of your payment.
You may also find a copy of the source at http://www.example.com/sources/Y/.
This offer is valid to anyone in receipt of this information.

<SFLC Guide to GPL Compliance>

Therefore, a process must be established to store compliance artifacts for at least 3 years. To this end, a company needs to build an open source website, which is described in detail in “6. Tool”.

If you prepare such a procedure, you can prepare the following evidence required by ISO/IEC 5230.

Respond to third party inquiries

It is important for a company to respond to third party inquiries as quickly and accurately as possible in order to avoid legal litigation. For this, a company must have a process that can respond quickly and effectively to third party open source inquiries.

The figure below shows the process a company must have to respond to third party inquiries.

Details can be found in “Appendix 2. Open Source Compliance Process (Sample) 2. External Inquiry Response Process”.

If you prepare such a procedure, you can prepare the following evidence required by ISO/IEC 5230.

Open Source Contribution Process

If you have a policy to allow contributions to external open source projects, there should be a documented procedure to manage how in-house developers can contribute to external projects.

The Open Source Contribution Procedure released by SK telecom is a good example.

https://sktelecom.github.io/guide/contribute/process/

If you prepare such a procedure, you can prepare the following evidence required by ISO/IEC 5230.

If you build the process up to this point, you will comply with the ISO/IEC 5230 requirements as follows.

2.6 - 6. Tool

Source code scanning tool

You should use a source code scanning tool during the identification of open source and audit phase of the open source compliance process. Source code scanning tools range from freely available, open source-based tools to commercial tools, each with their own strengths and weaknesses, but none of them seem to provide complete functionality to solve all problems. Therefore, companies can choose the appropriate tool for the characteristics and requirements of the product.

Many companies use a combination of these automated source code scanning tools and manual reviews. Linux Foundation’s FOSSology project is an open source source code scanning tool that companies can use for free.

For instructions on how to install and use FOSSology, refer to Get Started.

Dependency analysis tool

In recent software development, build environments that support Package Manager such as Gradle and Maven are used. In such a build environment, even if there is no source code, the required dependency library at build time is received from the remote to compose the supplied software. At this time, the dependency library is included in the supplied software, but it is not detected by the source code scanning tool. Therefore, it is also important to utilize a tool for dependency analysis.

The OSS Review Toolkit provides a dependency analysis tool called Analyzer.

LG Electronics has released FOSSLight Dependency Scanner as an open source. FOSSLight Dependency Scanner supports various package managers such as Gradle, Maven, NPM, PIP, Pub, and Cocoapods.

Open Source BOM Management Tool

3.3.1.2 of the ISO/IEC 5230 standard requires that the open source BOM list included in the supplied software be documented and kept. The open source BOM can also be managed with a spreadsheet program such as Excel. However, if the number and version of supplied software exceed hundreds, it is not easy to manage them manually. Therefore, it is better to use an automated tool to manage it.

SW360, an open source project hosted by the Eclipse Foundation, provides a function to track the list of open source BOM included in the supplied software.

How to install and use SW360 is SW360 wiki

And FOSSLight, an open source released by LG Electronics mentioned above, also provides a function for open source BOM management.

LG Electronics developed FOSSLight on its own and has been managing the open source BOM for supplied software for all business divisions for the past several years, and in June 2021, it announced that it had been released as an open source for anyone to use.

For detailed installation and usage instructions, refer to the following English guide. : https://fosslight.org/fosslight-guide-en/

If you have the above tools, you can prepare the following evidence required by ISO/IEC 5230.

Create artifacts

It is better to use a tool that automatically generates an open source notice, which is an open source compliance product, rather than writing it manually.

You can automatically generate an open source notice by registering an open source BOM using the FOSSLight tool. The open source disclaimer generated by FOSSLight also includes a Written Offer to provide source code.

In addition, SK Telecom is planning to release the open source automatic notice generation tool used in-house.

Archive open source artifacts

It is recommended that companies create an open source website and register open source compliance artifacts to provide convenience so that external customers can download open source notices and source code packages to be disclosed at any time.

You can refer to SK Telecom’s open source website.

In particular, this website was developed as an open source, and since the source code is open, you can easily build a website by referring to it.

If you build a tool environment like this, you can prepare the following evidence required by ISO/IEC 5230.

If you build the tool environment in this way, you will comply with the ISO/IEC 5230 requirements as follows.

2.7 - 7. Training

Training

No matter how good policies and processes are in place, they will be useless if no one in the company understands and follows them. In order for the open source policy and open source compliance process to work effectively in the company, it is important to educate employees.

You should provide practical methods, such as training and internal wikis, to ensure that all program participants are aware that there is an open source policy within the company and can take necessary actions. Program participants here mean all employees involved in the development, distribution, and contribution of software by a company, including software developers, distribution engineers, and quality engineers.

Many companies publish open source policy documents through their in-house wiki site, so that any employee can see what they need. In addition, training on open source policy is mandatory for new hires during training, and regular training is provided annually or every two years to program participants so that all program participants are aware of the existence of open source policies. . In other words, you should write these methods as the following example and include the open source policy document.

5. Training and Assessment
All program participants should take the open source mandatory 
training provided by [Learning Portal] every year. Through training, 
all participants should be familiar with open source policies and 
processes. Training history is stored in [Learning Portal].

If you build an educational environment like this, you can prepare the following evidence required by ISO/IEC 5230.

In addition, you should ensure that program participants are aware of the company’s open source policies, the relevant open source objectives, the contributions expected to ensure the effectiveness of the Program, and the implications of failing to follow the Program requirements. To this end, you should provide training and conduct assessments to ensure that program participants are properly aware. The assessment results are documented and stored.

To do this, you can include the example below in your company’s open source policy.

1. Purpose

(1) Purpose of the policy<sub>(3.1.3.1)</sub>

This policy provides the following principles for all organizations 
involved in software development, service, and distribution in OOO 
Company (hereinafter referred to as the "Company") to properly utilize 
open source software (hereinafter referred to as "Open Source"). 

1. Principles for open source license compliance
2. Principles for contribution to external open source projects
3. Principles for releasing open source

These principles provide a way for all members of the company to 
understand the value of open source, use it correctly, and contribute 
to the open source community.

(2) Impact of non-compliance
It is important that [COMPANY] adheres to this policy. Failure to do 
so may lead to:
- legal claims from the holders of copyright or other intellectual 
  property rights in code we use
- claims from our customers;
- the inadvertent release of [COMPANY] proprietary code;
- breach of regulatory obligations by [COMPANY] potentially leading to fines;
- loss of reputation;
- loss of revenue;
- breach of contract with suppliers and customers.
For this reason, we take breaches of this policy seriously, and any 
individual breaching the policy may find themselves subject to [COMPANY]'s 
disciplinary procedure.

(3) How to contribute to the effectiveness of the Program

All members of the company can contribute to the effectiveness of the 
program and improvement of the company's compliance level by understanding 
the rationale and content of this policy and faithfully performing the 

Assessment will be described in more detail later.

If you include the content of such education in your policy, you can prepare the following evidence required by ISO/IEC 5230.

Open source training also includes content on the open source contribution policy. Even if an open source contribution policy has been created, if program participants are not aware of its existence, there is a risk of harm to individuals and companies due to unexpected copyright infringement. You should provide open source training so that all program participants are aware of the existence of the open source contribution policy.

If you provide training on the contribution policy in this way, you can prepare the following evidences required by ISO/IEC 5230.

If you want to create a new educational material, it may not be easy for the person in charge who is starting the job for the first time. The OpenChain Project has released the reference training slides for anyone to refer to.

NCSOFT, a Korean game company, has published teaching plans (PPT) and lecture scripts on GitHub so that anyone can use in-house open source educational materials (Korean only).

In addition, Kakao, a representative platform company in Korea, has also released open source training materials for in-house developers so that anyone can refer to it (Korean only).

If you have not yet created training materials, it is also a good way to use open source training materials from these excellent open source management companies.

Assessment

Once you have designated a person in charge for each role, you should ensure that the person assigned is qualified to perform the role based on education, training and experience. Training should also be provided to program participants with insufficient competencies so that they can acquire sufficient competencies. And the company should assess each participant’s competencies and archive the results.

1. Provide training so that each participant has the necessary competencies.
2. Assess based on education content.
3. Keep the assessment results in the company’s training system or HR team.

If it is difficult to provide training because there are more than hundreds of participants in the program, it is also a good idea to use the company’s online training and assessment system.

You can include this in your company’s open source policy as follows.

4. Roles, Responsibilities and Competencies
In order to ensure the effectiveness of the policy, the roles and 
responsibilities and the competencies that the person in charge of 
each role should have are defined as follows.
The person/group in charge of each role and the required competency 
level are defined in [Appendix 1. Status of Person in Charge].

5. Training and Assessment
All members in charge of each role defined in Chapter 4 should take 
the advanced open source training course provided by [Learning Portal]. 
Training history and evaluation results are stored in [Learning Portal] 
for at least 3 years.

If you have this training and evaluation system, you can prepare the following evidence required by ISO/IEC 5230.

Open Source License Guide

To properly comply with open source licenses, you must know exactly what each open source license requires. However, since it is difficult for a software developer to figure it out on their own, it is recommended that an open source program manager identify requirements / conditions for common use cases for frequently used open source licenses and share them within the company.

The Open Source License Guide should include requirements specific to common open source licensing use cases to ensure that software developers use open source and comply with its license obligations properly.

For general guides on open source licenses and summary of license obligations, refer to the Open Source License Checklists provided by the OSADL.

The document Obligations by license in SK Telecom’s open source guide is also a good resource (Korean only).

https://sktelecom.github.io/guide/use/obligation/gpl-2.0/

If you provide this open source licensing guide, you can prepare the following evidence required by ISO/IEC 5230.

If you build an environment for providing training, assessment and guide in this way, you will comply with ISO/IEC 5230 requirements as follows.

2.8 - 8. Conformance

If you build an open source program (open source policy / process / tool / organization) that complies with all requirements except Article 6 of the ISO/IEC 5230 standard, you can write and publish a document specifying the following two.

1. A document affirming the program specified in requirement §3.1.4 satisfies all the requirements of this specification.
2. A document affirming the program meets all the requirements of this version of the specification (version 2.1), within the past 18 months of obtaining conformance validation

You may include the above document in the open source policy, or you may publish it through an externally public website.

As shown in the image below, you can refer to the content that SK Telecom posted on the open source portal site. https://sktelecom.github.io/en/compliance/iso5230/

If you document that you meet all the requirements of ISO/IEC 5230 in this way, you can prepare the following evidence required by ISO/IEC 5230.

If you’ve made it this far, your company will finally meet all the requirements of ISO/IEC 5230.

2.9 - Appendix

2.9.1 - 1. Open Source Policy (Sample)

1. Purpose

(1) Purpose of the policy_(3.1.3.1)

This policy provides the following principles for all organizations involved in software development, service, and distribution in [COMPANY] (hereinafter referred to as the “Company”) to properly utilize open source software (hereinafter referred to as “Open Source”).

1. Principles for open source license compliance
2. Principles for contribution to external open source projects
3. Principles for releasing open source

These principles provide a way for all members of the company to understand the value of open source, use it correctly, and contribute to the open source community.

All members of the company can view the open source policy at the following link on the in-house wiki: [internal_link]_(3.1.1.1)

(2) Impact of non-compliance

It is important that [COMPANY] adheres to this policy. Failure to do so may lead to:

• legal claims from the holders of copyright or other intellectual property rights in code we use
• claims from our customers;
• the inadvertent release of [COMPANY] proprietary code;
• breach of regulatory obligations by [COMPANY] potentially leading to fines;
• loss of reputation;
• loss of revenue;
• breach of contract with suppliers and customers. For this reason, we take breaches of this policy seriously, and any individual breaching the policy may find themselves subject to [COMPANY]’s disciplinary procedure.

(3) How to contribute to the effectiveness of the Program

All members of the company can contribute to the effectiveness of the program and improvement of the company’s compliance level by understanding the rationale and content of this policy and faithfully performing the necessary activities.

2. Scope_(3.1.4.1)

This policy applies to the following three parts:

1. Applies to [all products provided or distributed by the company externally]. However, the open source only for internal use is not included in the scope of this policy.
2. Applied when contributing to external open source projects.
3. Applied when releasing internal code as open source.

The scope can be changed according to the business environment of the company, and the procedure for this is as follows.

1. If the open source program manager determines that it is necessary to change the scope of policy according to changes in the company’s business environment, such as a new business or reorganization, submit a proposal for this to the OSRB.
2. OSRB approves proposals for scope changes at the appropriate level.
3. OSRB modifies the open source policy to change the scope of the policy.

3. Terms

• “compliance artifacts” - a collection of artifacts that represent the output of a compliance program and accompany the supplied software. The collection may include (but is not limited to) one or more of the following: attribution notices, source code, build and install scripts, copy of licenses, copyright notices, modification notifications, written offers, open source component bill of materials, and SPDX documents.
• “open source” - software subject to one or more licenses that meet the Open Source Definition published by the Open Source Initiative (see opensource.org/osd) or the Free Software Definition published by the Free Software Foundation (see gnu.org/philosophy/free-sw.html) or similar license.
• “program” - the set of policies, processes and personnel that comprise an organization’s open source license compliance activities.
• “program participants” - any organization employee or contractor that defines, contributes to or has responsibility for preparing supplied software. Depending on the organization, that may include (but is not limited to) software developers, release engineers, quality engineers, product marketing and product management.
• “SPDX” - the format standard created by the Linux Foundation’s SPDX (Software Package Data Exchange) Working Group for exchanging bill of materials for a given software package, including associated license and copyright information (see spdx.org).
• “supplied software” - software that an organization distributes to third parties (e.g., other organizations or individuals).

4. Roles, Responsibilities and Competencies_(3.1.2.1)

In order to ensure the effectiveness of the policy, the roles and responsibilities and the competencies that the person in charge of each role should have are defined as follows.

The person/group in charge of each role and the required competency level are defined in [Appendix 1. Status of Person in Charge]._(3.1.2.2)

• The open source program manager periodically updates the list according to the company’s business situation._(3.2.2.1)
• The head of the organization responsible for each role designates a person in charge within the organization, and allocates appropriate time and budget for the person in charge to fulfill the role._(3.2.2.2)
  • The person in charge of each role should raise an issue with the open source program manager if appropriate support is not provided while performing his/her role.
  • The open source program manager discusses problem solving with the head of the organization. If not properly resolved, the open source program manager may request the OSRB to resolve the issue.
  • OSRB shares the problem with the head of the higher level organization and asks for a solution.

(1) OSRB

OSRB_{Open Source Review Board} is a consultative body composed of an open source program manager, legal team, patent team, development team, and infrastructure team for the company’s open source compliance.

• Create policies and processes for open source compliance, and define roles and responsibilities within the company to implement them.
• When an open source compliance issue occurs within the company, discuss solutions and prepare countermeasures.
• If necessary, report issues to the executive team to receive feedback on risk mitigation measures.

(2) Open Source Program Manager

The open source program manager is responsible for the overall responsibility for the company’s open source programs. To ensure open source compliance of products and services using open source, open source program manager is responsible for:_(3.2.2.4)

• Define the roles required for open source compliance, and designate a responsible person and group in charge of each role. Consult with OSRB if necessary.
• Supervise and assess open source compliance training.
• Serves as the chair of the OSRB and directs its activities.
• Respond to inquiries and requests related to open source use and compliance from outside.
• Review and approve requests for use of open source.
• Maintain open source BOM records.
• Provides a way to request legal advice on open source._(3.2.2.3)
• Maintain a repository for open source notices and source code disclosure.

(3) OSPO

OSPO_{Open Source Program Office} is responsible for supporting and nurturing the growth of open source activities inside and outside the company.

• Establish, improve and disseminate open source policies.
• Provides a guide for contributing code to external open source projects.
• Provides a guide for releasing an in-house project as an open source.
• Develop and operate an open source portal.
• Develop and select open source tools.
• Sponsor open source project events.
• Manage relationships with the open source community.

(4) Legal team

The legal team provides advice on legal risks and mitigation measures that may arise in the process of using open source, such as interpreting open source licenses and obligations.

• Advise on licensing and intellectual property issues, including conflicts due to incompatible open source licenses.
• When contributing to external open source projects, review necessary legal matters such as open source licenses and CLA_{Contributor License Agreement}.

(5) IT infrastructure team

The IT infrastructure team operates and automates open source analysis tools to build a system so that license analysis is performed automatically for supplied software.

• Operate an open source license analysis tool.
• Automate license analysis by integrating with DevOps.
• Establish systems and processes so that license analysis is performed for supplied software.
• Obtain and maintain an open source BOM for supplied software.

(6) Security Officer

The security officer operates an open source security vulnerability analysis tool to build a system so that security vulnerability analysis is performed smoothly for supplied software.

• Operate an open source security vulnerability analysis tool.
• Automate open source security vulnerability analysis by integrating with DevSecOps.
• Establish systems and processes so that open source security vulnerability analysis is performed for supplied software.

(7) Development Culture

The development culture manager supports developers to actively utilize open source and participate in the open source community to learn a good development culture.

• Encourage developers to participate in the open source community.
• Create a culture where activities in open source projects can be recognized as achievements.
• Create a development culture that can be perceived as an attractive company to open source developers.

(8) Quality Responsible

The organization responsible for quality, such as QA, checks whether the open source license obligations have been properly performed when distributing software.

• Check whether open source compliance activities are performed in accordance with the development process.
• Check that the artifacts are generated as required by the open source license.
• When distributing software, make sure that the open source notice and the source code to be released are provided together.
• If an issue is found, notify the software development/deployment team and guide them to fix the issue immediately.

5. Training and Assessment

All program participants should take the open source mandatory training provided by [Learning Portal] every year. Through training, all participants should be familiar with open source policies and processes. Training history is stored in [Learning Portal]._(3.1.1.2)

All members in charge of each role defined in Chapter 4 should take the advanced open source training course provided by [Learning Portal]. Training history and assessment results are stored in [Learning Portal] for at least 3 years._(3.1.2.3)

6. Use open source

If you use open source to develop and distribute products and services, you should comply with the obligations required by each open source license. The activities that companies perform for this purpose are called open source compliance.

For proper open source compliance activities, software development/distribution organizations should comply with the following:_(3.3.1.1)

• All processes of the open source compliance process are recorded and preserved in Jira Issue Tracker.

(1) Identify open source and review license obligations.

When using open source to develop products / services, first identify what an open source license is, and review and investigate the obligations that the license requires.

The company’s [Open Source License Guide] provides a guide for frequently used open source licenses, and explains the obligations for each type of distribution as follows for each license._(3.3.2.1)

• Distributed in binary form;
• Distributed in source form;
• Integrated with other open source such that it triggers additional licensing obligations;
• Contains modified open source;
• Contains open source or other software under an incompatible license interacting with other components within the supplied software; and/or
• Contains open source with attribution requirements.

Software development/distribution teams can refer to this guide when reviewing their open source license obligations. If you need to review an open source license not mentioned in this guide, contact your open source program manager.

(2) Design software considering open source licenses.

Identify open source dependencies and design your software architecture so that your code is not subject to open source licenses. .

The company’s [Open Source Licensing Guide] describes the source code disclosure scope for each open source license and design methods to prevent disclosure of own code.

(3) Create an open source compliance artifact.

The most basic of open source compliance activities is to identify open sources included in supplied software. This is to properly meet the open source license requirements, which are the core of open source compliance. That is, a set of compliance artifacts for open source included in the supplied software should be generated._(3.4.1.1)

Open source compliance artifacts are divided into two main categories.

1. Open source notice: A document to provide full open source license and copyright notice
2. Source code package to be disclosed: A package that collects source code to be disclosed to fulfill open source license obligations that require source code disclosure such as GPL, LGPL, etc.

To collect, distribute and store these compliance artifacts, the following should be complied with._(3.4.1.2)

• Open source notices or source code packages to be disclosed are collected according to the conditions required by each license. For example, a license requires the accompanying full text of the license, but not just a link.
• Collected artifacts are stored in a separate storage.
• When providing source code to be made public by a written agreement, provide a download link so that the external general public can access the repository of the collected artifacts.

Follow the company’s open source compliance process to create and provide open source compliance artifacts as above.

(4) Create open source Bill of Materials (BOM)

Create and manage the Bill of Materials (BOM) included in the supplied software._(3.3.1.2)

Follow the company’s open source compliance process to create and preserve open source BOMs using open source tools.

(5) Compliance Issue Remediation Procedure

Should a non-compliance issue be raised, the Open Source Program Manager responds promptly by performing the following procedures._(3.2.2.5)

1. Acknowledge receipt of the query and state a reasonable time for resolution;
2. Determine whether the query discloses a genuine issue or not (and if not, respond to the querier accordingly);
3. If the issue is genuine, apply to prioritise, and determine the appropriate response.
4. Carry out response and, where necessary, improve open source compliance processes.
5. Document the above using Jira Tracker.

7. Open Source Contributions

The company encourages participation and contribution to external open source projects to create business value in open source. However, in this process, you should be careful about unintentional exposure of the company’s intellectual property or infringement of the rights of third parties. Therefore, members of the company should comply with the following when contributing to external open source projects._(3.5.1.1)

(1) Request a review and get approval.

An open source contribution is to grant an open source project the right of an author to modify/use/distribute a work from a copyright point of view. In some cases, you may need to transfer your copyright to an open source project. In general, however, the copyright of a work created during employment is owned by the employer. In other words, works created by company members are owned by the company. Contributing to open source works created while you were employed may raise unnecessary copyright infringement issues.

Therefore, if there is an open source project that you would like to contribute to, follow the review request and approval procedures before making the initial contribution according to the open source contribution process.

However, in the case of a small contribution as follows, since the risk of copyright infringement is not large, you can contribute at your own discretion without the review process.

• Small code snippets of 10 lines or less
• Inquiries and answers on Stack Overflow
• Activities on GitHub: Issue creation, Pull Request Review / Approve, etc.

(2) Contribute only code that you have the right to contribute

Only contribute code for which you have the right to contribute. In other words, contribute your own code, not third-party code.

(3) Be careful not to expose the company’s intellectual property

Do not contribute code or documents that may expose the company’s intellectual property such as sensitive information or patents.

• If the code you want to contribute includes [Company]’s patent, you should check whether you can contribute to the project under the open source license. If there is any ambiguity, contact OSPO.

(4) Be careful about signing the CLA.

Some open source projects require all contributors to sign a CLA_{Contributor License Agreement}. This is an agreement to seek consent from contributors to reduce copyright disputes that may arise when a project manages the works of multiple contributors. Typically, a company-led project requires a CLA to be signed.

The CLA varies from project to project, but primarily includes agreement to the following:

• I (or my company) have the right to contribute to the project the contribution I intend to contribute. (i.e. I am the author of this contribution.)
• I (or my company) grant the project the right to modify, distribute, and manage my contributions to the project.
• I (or my company) will not revoke the authority granted to me.
• I (or my company) grant the project the right to change the license according to future needs of the project.

In addition, in rare cases, some CLAs also require consent to the following terms and conditions:

• I (or my company) transfer my copyright to the project or project management organization at the same time as I contribute my contribution.

[Company] does not allow contributions to open source projects that require transfer of copyright to protect the company’s intellectual property. Therefore, if the open source project you want to contribute to requires the CLA to be signed, be sure to ask OSPO for a review before signing.

(5) Add company copyright notice

The intellectual property of the work you create during your employment is basically owned by the company. Therefore, you should add your company’s copyright notice when contributing code to external open source projects.

When contributing more than one file, add the copyright and license notices at the top of the files, like this:

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

Here, $SPDX_license_name is written according to the license of the corresponding open source project.

However, if your contribution is only to modify existing code for the purpose of fixing a bug, you do not need to add a copyright notice for that code modification.

(6) Use your company email

When contributing to an open source project, use your company email, not your personal email. This will (1) give you a sense of responsibility to communicate with the community on behalf of the company, and (2) improve the awareness of the company that actively contributes to the open source community.

8. Open Source Release

[Company] respects the value of collaboration with the open source community and encourages the release of internal software as an open source project. However, there are several rules that should be followed to protect the company’s intellectual property and prevent unintentional copyright infringement.

(1) Get approval

From a copyright point of view, releasing as open source means that the author grants the right to modify/use/distribute the work by anyone through an open source license. In general, the copyright of a work created during employment is owned by the employer. In other words, the work you create is owned by the company. The act of arbitrarily releasing a work as open source may cause unnecessary copyright infringement issues.

Therefore, if you want to release the software as open source, follow the review request and approval procedure according to the company’s open source release policy.

Do not hesitate to contact OSPO if anything in your open source process appears to be undesirable.

(2) Release only the code you have the right to publish.

One of the worst things that can happen to an open source project is that the project contains legally problematic code. Code that the company does not have the right to release, or code that infringes IP, such as another company’s patent, can cause legal problems. Therefore, while preparing the code to be released, check the source of all code and delete problematic code.‌

(3) Be careful about the exposure of the company’s intellectual property.

Do not release code or documents that may expose sensitive information or patents to the company’s intellectual property.

If the code you want to release contains [Company] patent, see if you can release it under the open source license. If there are any ambiguities, please contact OSPO.

(4) Publish useful code

To be a successful project, it should also be useful to others. If a similar project already exists, join the existing project rather than create a new one.

An open source that intends to release should be able to expect: (1) provide differentiated value to the open source community; (2) to solve problems that the community has not been able to solve; (3) We receive positive attention by releasing our technology.

• If the code we haven’t used in our products or services, don’t even release it as open source.
• Do not publish code that addresses a problem that has already been addressed by the open source community. If this is the case, contribute to an existing open source project.

(5) Prepare the resource

Prepare in advance the resources that will be put into the open source project, including developers.

• In the beginning, the number of developers similar to that of a general in-house project is required.
• Get developers who can quickly review external contributions.
• The role of the legal team and marketing team is also required.
• Secure a budget for the infrastructure required to maintain and manage the project. This includes tools for hosting projects like Github.

If you can’t create an environment with enough resources to support it, don’t release it as open source.

(6) Use your company email

For open source release activities, do not use personal emails, but use company emails. This will (1) give you a sense of responsibility to communicate with the community on behalf of the company, and (2) improve the awareness of the company that actively contributes to the open source community.

9. Respond to external inquiries

(1) Responsibility for responding to external inquiries

The open source program manager is responsible for responding to inquiries and requests for open source compliance from outside._(3.2.1.2)

• The open source program manager may assign all or part of the handling of inquiries to appropriate personnel within the company. If necessary, contact the legal team to deal with it.
• Anyone who receives an inquiry about open source compliance from outside will notify the open source program manager so that a prompt response can be made.

(2) Disclosure of contact information

The open source program manager publicly provides the contact information of the person in charge so that external inquiries and requests related to open source can be submitted to the company._(3.2.1.1)

• Include the email address of the person in charge in the open source notice.
• Register your contact in the Linux Foundation’s Open Compliance Directory.

(3) External Inquiry Response Procedure

If you respond quickly and accurately to open source compliance inquiries from outside, you can significantly reduce the risk of going to a lawsuit. To this end, in order to respond to external open source compliance inquiries, you should follow the external inquiry response process defined in the company’s open source compliance process._(3.2.1.2)

10. OpenChain

[COMPANY] supports the Linux Foundation’s OpenChain project. This policy has been carefully designed to be compliant with the OpenChain Specification v2.1, ISO/IEC 5230:2020.

• [COMPANY] affirms that as of [insert date] it is in compliance with the OpenChain Specification v 2.1, ISO/IEC 5230:2020._(3.6.1.1)
• [COMPANY] affirms that within the past 18 months of obtaining conformance validation, the program meets all the requirements of the OpenChain Specification v2.1, ISO/IEC 5230:2020._(3.6.2.1)
• [COMPANY]’s affirmation of conformance will be reviewed and renewed if appropriate at intervals of at least [12|18 months].

Appendix 1. List of persons in charge

2.9.2 - 2. Open Source Compliance Process (Sample)

OOO Corporation (hereinafter referred to as the “Company”) actively uses open source software (hereinafter referred to as “Open Source”) while developing products and services including the software. When a company distributes its software, it should perform activities to comply with the obligations imposed by the open source license, which is called open source compliance.

1. Process for software development/distribution

This open source compliance process defines the procedures a [company] should follow to comply with its open source license obligations for each stage of development for developing and distributing software products and services. All employees involved in developing/distributing software products should follow these 10 steps of the Open Source Compliance Process.

1. Identification of Open Source

The development team should adhere to the following during the software design phase.

• Identify predictable open source usage and check licenses while designing software.
• Check the obligations for each open source license. You can check the obligations for each license in the company’s Open Source Licensing Guide.
• Design software considering the source code disclosure scope of each open source license.

Open source program managers should write a guide on the obligations, restrictions, and rights of frequently used open source licenses, and make them available for reference to the development team.

The development team should display the copyright and license in the source code according to the company’s policy. The copyright and license notation rules in the company’s source code can be found on the following page. : (insert_link)

When a development team needs to use a new open source, first identify the license. Check your license obligations, restrictions, and rights according to your company’s Open Source Licensing Guide. If the license is not described in the company’s open source license guide, ask the open source program manager whether it can be introduced or not. Create a Jira Ticket and inquire.

Open source program managers guide the software development team by analyzing their open source license obligations.

• If in doubt, seek advice from the Legal Department to provide clear guidance.
• Add newly analyzed open source licenses to the guide.

2. Auditing Source Code

The development team requests open source audit by providing the source code according to the guidance of the infrastructure team.

The development team uses the open source analysis tool provided by the infrastructure team to audit the open source and generate the open source BOM.

The open source program manager reviews whether the obligations of the open source license can be complied with and whether there is an open source license conflict, and if there is an issue, ask the development team to resolve it. Create issues with Jira Tickets and assign them to the development team.

3. Resolving Issues

The development team should resolve any issues found during the source code inspection phase. Take action, such as removing the open source that has become an issue, or replacing it with an open source under a different license.

When the development team resolves all issues found, Resolve the Jira Ticket issue and request a review.

4. Reviews

Open source program managers review that all issues have been properly addressed. If necessary, re-audit the source code using an open source analysis tool.

5. Approval

The open source program manager should finally approve or reject whether the open source compliance process has been properly performed. In case of rejection, explain the reason and suggest to the development team how to fix it.

6. Registration

The open source program manager confirms the BOM for tracking the list of open source usage by version of the software.

The person in charge of infrastructure registers the confirmed BOM in the system. Include in the BOM a list of the open sources included with the supplied software and information such as:

• Product (or service) name and version of the supplied software
• Open Source List
  • Open source name / version
  • Open source license

7. Notices

Open Source Program Managers create Open Source Notices to comply with notice obligations. Include the following in the Open Source Notice.

• Open source contact information for external inquiries related to open source
• Notice by open source
  • Copyright notice
  • Open source license name
  • A copy of the open source license
  • Written Offer to receive a copy of the source code (if applicable)

The open source program manager creates an Open Source Notice and delivers it to the development team. In this case, if it is necessary to disclose the source code, guide the development team on how to collect the source code to be disclosed.

The development team should enclose the Open Source Notice when distributing the product. In the case of a product with a screen, take measures so that the user can check it through the menu. (Example: Apps > Menu > Settings > Copyright Information > Open Source License)

If the development team uses open source under a license that requires source code disclosure, such as GPL or LGPL, check the source code disclosure scope for this and collect the source code to be disclosed.

• The source code collected to comply with license obligations such as GPL and LGPL should match the source code that creates the binaries loaded in the product. In other words, when the compiled source code is built, it should be the same as the binary loaded on the product.

8. Pre-Distribution Verifications

The development team should submit the following artifacts demonstrating that the open source compliance activities were properly conducted.

1. Final Open Source Notice included in the product
2. Materials confirming that the product includes Open Source Notice (eg, screen capture image showing Open Source Notice)
3. (if applicable) source code to be disclosed (compressed and submitted in one file)

The open source program manager should review the data submitted by the development team and check for any abnormalities.

9. Distribution

Open source program managers should submit compliance artifacts submitted by the development team to the infrastructure team.

The infrastructure team registers the compliance artifacts on the company’s open source distribution site.

10. Final Verifications

The open source program manager should comprehensively check whether the compliance product is registered on the company’s open source portal without any abnormality or whether it is downloaded from outside the company.

2. External Inquiry Response Process

If you respond quickly and accurately to open source compliance inquiries from outside, you can greatly reduce the risk of going to a lawsuit. Therefore, you should follow the following process to respond to external open source compliance inquiries.

1. Acknowledge

The open source program manager immediately informs the requester that the inquiry has been received. In this case, inform the requester of the expected date of action. Since it’s important to know exactly what the requester’s intent is, ask for further clarification if the inquiry is unclear.

The main contents of inquiries and requests that require response are as follows.

• Inquiries about whether open source has been used for certain products and services
• Request to provide source code under the GPL, LGPL license mentioned in the Written Offer
• Request for clarification of open source found in the product and disclosure of source code even though it is not specified in the Open Source Notice
• Request to provide missing files and build methods in the source code published due to GPL, LGPL, etc.
• Request for copyright notice

The open source program manager creates a Jira Issue for the received request and records all responses in detail.

2. Inform

The open source program manager informs the requester that it is faithfully performing open source compliance and is investigating the requester’s inquiry. Notify the requestor whenever possible internal investigation progress is updated.

3. Investigate

The open source program manager conducts an internal investigation of the request. Check the BOM and documented review history to ensure that the compliance process has been properly implemented for the version of the product in question. Seek advice from the Legal Department if necessary.

If a specific development team needs confirmation, the open source program manager should ask the development team to investigate. The development team requested to be investigated immediately identifies any issues with the compliance artifacts and reports the findings to the open source program manager.

4. Report

The open source program manager should complete the internal investigation within the due date for action and inform the requester of the results.

• If the requester’s complaint was a misunderstanding rather than a compliance issue, notify the requester without further action and terminate the procedure.
• If any compliance issues are discovered, inform the requester of the exact method and timing to fulfill the obligations of the applicable open source license.

5. Rectify

If an internal investigation reveals an actual compliance issue, the development team should take all necessary steps to resolve the compliance issue.

6. Report

After resolving the issue, notify the requester immediately and provide the best way to confirm that the issue has been resolved.

7. Improve

If there are compliance issues, conduct an OSRB meeting to review the case, find out how the issue arose, and improve the process so that the issue does not recur.