이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.
정보통신산업진흥원(NIPA)이 주관하고 공개SW역량프라자에서 연구를 수행하여 기업이 오픈소스 컴플라이언스의 국제 표준인 OpenChain 규격을 준수하기 위해 필요한 사항들을 설명하는 해설서를 가이드 형태로 제작하였습니다. : 기업 공개SW 거버넌스 OpenChain 2.0 해설
기업 공개SW 거버넌스 Openchain 2.0 해설
여기서는 NIPA의 허락 하에 가이드 내용을 GitHub에 공개하고, 누구나 내용을 참고하고, 수정 / 개선할 수 있게 하였습니다. : GitHub Repository
이 가이드는 다음 자료를 참고하여 작성하였습니다.
오늘날 소프트웨어는 갈수록 그 규모와 복잡도가 커지고 있다. 하나의 소프트웨어를 개발하기 위해서는 자체 개발한 소프트웨어뿐 아니라 오픈소스, 타사 소프트웨어3rd party software, 벤더의 SDK 등 소프트웨어 공급망에 걸친 다양한 소프트웨어가 사용될 수 있다.
이러한 복잡한 소프트웨어 공급망의 여러 조직 중 한 곳이라도 오픈소스 라이선스 의무를 준수하지 않거나 올바른 오픈소스 사용 정보를 제공하지 않으면 최종 소프트웨어를 배포하는 기업은 오픈소스 라이선스 의무 준수에 실패할 수밖에 없다. 이로 인해 소송을 제기당해 제품 판매가 중단되는 상황이 발생할 수도 있다.
2009년 12월, Busybox라는 오픈소스 관련된 소송이 있었다. Busybox는 임베디드 시스템에 광범위하게 사용되고 있는 GPL-2.0 라이선스가 적용된 오픈소스인데, 국내 회사 두 곳을 포함하여 14개 회사가 소송 대상이 되었다. 이 사례에서 주목할만한 점은 이 중에는 제품을 직접 개발하지 않고 배포만 한 회사도 소송을 당하였다는 점이다.
이와 같은 복잡한 소프트웨어 공급망 환경에서는 어느 한 기업이 아무리 훌륭한 프로세스를 갖추고 있다고 해도 자체적으로 완벽한 오픈소스 컴플라이언스를 달성하는 건 매우 어렵다. 결국 한 기업이 오픈소스 컴플라이언스를 제대로 이행하기 위해서는 소프트웨어 공급망의 모든 구성원이 라이선스 의무를 준수하고 올바른 오픈소스 정보를 제공해야 한다. 공급망 전체에 걸쳐 이런 신뢰가 구축되어야 한다.
Linux Foundation의 OpenChain 프로젝트는 기업이 오픈소스 컴플라이언스를 위해 준수해야 할 핵심 사항을 간결하고 일관성 있게 정의하고, 이를 모두가 준수한다면 소프트웨어 공급망 전체에 걸쳐 오픈소스 라이선스 측면의 신뢰를 구축할 수 있다는 믿음으로 설립되었다.
2016년 유럽에서의 한 오픈소스 콘퍼런스에서 퀄컴의 오픈소스 변호사인 데이브 머Dave Marr는 바로 이 점을 강조하였다. 한 기업의 오픈소스 컴플라이언스 수준을 높이기 위해서는 소프트웨어 공급망 내 모든 구성원의 오픈소스 컴플라이언스 수준을 높여야 한다. 아울러 이를 위해서는 오픈소스를 충분히 이해하고, 정책 및 프로세스를 이미 구축하고 있는 선진 기업이 자신의 자산과 노하우를 공개하여 누구나 이를 참고할 수 있게 하면 어떻겠냐는 의견을 제시하였다. 콘퍼런스 참석자들은 “오픈소스 컴플라이언스는 기업의 이익을 차별화할 수 있는 분야가 아니다. 기업은 적은 리소스를 투입하면서도 적정한 수준의 리스크 관리를 원한다. 그렇기 때문에 기업이 가진 자산을 서로 공유하면 할수록 적은 리소스로 모두 함께 컴플라이언스를 달성 할 수 있게 된다”는 아이디어에 공감하였다. 그렇게 OpenChain 프로젝트(당시에는 Work Group)는 시작되었고, 퀄컴, 지멘스, 윈드리버, ARM, 어도비 등 다수 글로벌 기업들이 참여하였다.
OpenChain 프로젝트는 기업들이 오픈소스 컴플라이언스를 더욱 쉽게 달성 할 수 있도록 크게 다음 세 가지를 제공한다.
기업이 어떻게 이들을 활용할 수 있을지 하나씩 알아보자.
OpenChain 규격 - https://www.openchainproject.org/contribute-to-the-standard ↩︎
OpenChain 자체 인증 웹사이트 - https://certification.openchainproject.org/ ↩︎
OpenChain 문서 자료 - https://www.openchainproject.org/resources ↩︎
OpenChain 프로젝트는 2016년 OpenChain 규격 1.0을 제작하여 배포했다. OpenChain 규격은 오픈소스 컴플라이언스를 위한 핵심 요구사항을 정의한 12페이지 분량의 규격으로, 기업의 규모나 업종과 관계없이 모든 분야의 회사에 적합하도록 고안되었다. 2020년 12월 Openchain 규격 2.1은 ISO/IEC 5230 국제표준으로 등록되었다.
ISO/IEC 5230은 기업이 오픈소스 컴플라이언스 달성을 위해 꼭 수행해야 할 여섯 가지 주요 요구사항과 이를 입증하기 위해 필요한 자료 목록을 정의하고 있다.
오픈소스 컴플라이언스를 처음 시작하는 기업이라면 이러한 ISO/IEC 5230 표준의 요구사항을 하나씩 충족해가면서 수준을 향상시키는 것이 좋은 전략이다.
OpenChain 프로젝트는 ISO/IEC 5230에 이어 오픈소스 보안 보증을 위한 규격을 제작하였다. 이 규격은 2023년 말 ISO/IEC 18974로 등록되었다. : https://www.iso.org/standard/86450.html
이들 두 표준 내 각 요구사항의 준수 방법은 “3장. OpenChain 표준 준수 방법”에서 상세히 다룬다.
OpenChain 규격에서의 요구 사항을 모두 준수한다면 OpenChain 적합한 오픈소스 프로그램을 보유했음을 인증받을 수 있다. 오픈소스 프로그램이란 정책, 프로세스, 인원 등 기업이 오픈소스 컴플라이언스 활동을 수행하기 위한 일련의 관리 체계를 의미한다. 이 장에서는 인증 방법과 적합성 선언에 관해 설명한다.
OpenChain 프로젝트에서 제안하는 인증 방법은 세 가지 이다.
각각의 방법을 알아보자.
자체 인증은 OpenChain 프로젝트에서 제일 권장하는 방법이며, 비용이 발생하지 않는다는 장점이 있다. OpenChain 프로젝트는 기업이 자체적으로 OpenChain 규격을 충족하는지 확인할 수 있도록 온라인 자체 인증 웹사이트를 제공한다.
기업의 오픈소스 담당자는 OpenChain 자체 인증 웹사이트에 가입해 온라인 자체 인증을 시작할 수 있다.
기업은 자체 인증을 통해 부족한 부분이 무엇인지, 추가로 필요한 활동이 무엇인지 판단할 수 있다.
만약, 어떤 기업이 오픈소스 컴플라이언스 체계를 잘 구축하여 OpenChain 자체 인증 질문지의 모든 항목을 Yes로 대답할 수 있다면 이 결과를 웹사이트상에 제출할 수 있다(Conforming Submission). 그렇게 OpenChain 적합성 선언을 하게 되면, OpenChain 적합(Conformant) 프로그램을 가진 기업으로 인정됨과 동시에, OpenChain 프로젝트의 웹사이트에 기업의 로고를 등록할 수 있게 된다.
OpenChain 적합 기업에는 OpenChain 로고를 사용할 수 있는 자격이 주어진다. 이렇게 OpenChain 적합 프로그램을 갖췄다고 인정받은 기업은 소프트웨어 공급망 내에서 오픈소스 컴플라이언스를 충실하게 수행하고 있음을 보여줄 수 있게 된다.
소프트웨어 공급망에서 구매자에게 보다 신뢰성 있고 투명한 오픈소스 컴플라이언스 수준을 나타내고자 한다면 타사 인증 기관으로부터 인증서를 발급받고 이를 홍보에 활용할 수 있다. 또한, 오픈소스 컴플라이언스의 보다 견고한 신뢰성을 요구하는 일부 구매자는 공급자Supplier에게 타사 인증을 의무화 할 수도 있을 것으로 예상된다.
OpenChain의 공인 타사 인증 기관은 ORCRO1, PWC2, TÜV SÜD3 등이 있다.
이들은 ISO/IEC 5230 적합 프로그램 확인을 위한 평가를 제공하고 통과한 기업에 인증서를 발급한다.
유럽의 자동차 업계에서는 ISO/IEC 5230이 ASPICEAutomotive SPICE4 자동차 소프트웨어 개발을 위한 국제 표준 프로세스 모델)와 같이 자동차 소프트웨어 공급자에게 의무화될 날이 머지않을 것이라고 예측하는 전문가도 있다.
개별 평가 지원은 기업 외부의 독립 기관이 공정한 관점에서 기업의 오픈소스 컴플라이언스 상태를 점검하고 평가한다. 어떤 인증서를 발급해주지는 않는다는 점이 자체 인증, 타사 인증과는 다른 점이다. 개별 평가 지원의 특징은 평가 보고서를 생성하는 것에 그치지 않고 도출된 미비점을 보완하기 위한 컨설팅을 제공한다.
기업은 독립 기관으로부터의 공정한 평가와 컨설팅을 받아 컴플라이언스 수준을 높이고, 다시 독립 평가를 수행하는 반복적인 과정을 통해 정책을 세분화하고 프로세스를 구축할 수 있다.
결국 기업은 OpenChain 인증을 받을 수 있는 수준에 도달하게 된다. 그때 자체 인증, 혹은 타사 인증을 획득하는 절차에 돌입할 수 있다. 이렇게 기업의 오픈소스 컴플라이언스 수준을 높이기 위한 평가와 컨설팅을 제공하여서 기업이 OpenChain 적합 프로그램을 보유하고 인증을 획득할 수 있게 지원한다.
개별 평가 지원을 제공하는 업체는 AlektoMetis5, Source Code Control6 등이 있다.
국내에서는 이와 유사한 프로그램을 NIPA의 오픈업7에서 국내 기업 대상으로 공개소프트웨어 활용지원 프로그램8을 통해 무료로 제공한다.
ORCRO- https://orcro.co.uk/ ↩︎
TÜV SÜD - https://www.tuvsud.com ↩︎
ASPICE : 자동차 소프트웨어 개발을 위한 국제 표준 프로세스 모델 - http://www.automotivespice.com ↩︎
AlektoMetis - https://alektometis.com/, ↩︎
Source Code Control - https://sourcecodecontrol.co/ ↩︎
공개소프트웨어 활용 지원 프로그램 - https://www.oss.kr/news/show/49e410fb-604d-4d35-ba25-8286b5f2c50d ↩︎
OpenChain 프로젝트에서는 기업이 컴플라이언스 프로그램을 구축하는 데 필요한 정책 문서 템플릿, 교육 자료 등 다양한 리소스를 제공한다. 이 자료들은 OpenChain 표준 준수와 일반적인 오픈소스 컴플라이언스 활동을 지원하기 위해 고안됐으며, 누구나 자유롭게 사용할 수 있도록 CC-0 라이선스로 제공된다.
이 가이드의 많은 내용도 OpenChain에서 공개한 자료를 기반으로 작성하였다. 각 기업의 오픈소스 담당자는 정책, 프로세스, 교육자료가 필요하다면 OpenChain Resources를 먼저 찾아보기 바란다. 또한 이 자료는 한국어로도 번역되어 공개되고 있다. OpenChain Korea Work Group1에서 이러한 번역 작업을 주도하고 있다. 한국어 번역은 관심 있는 누구나 참여할 수 있다2.
2장에서는 두 OpenChain 표준의 각 요구사항을 어떻게 준수해야 할지에 대해 세부적으로 설명한다.
OpenChain Korea Work Group - https://openchain-project.github.io/OpenChain-KWG/ ↩︎
한국어 번역 작업 - https://openchain-project.github.io/OpenChain-KWG/resource/ ↩︎
기업 오픈소스 관리를 위한 두개의 ISO 표준은 ISO/IEC 5230과 ISO/IEC 18974이다. 이 두 표준을 모두 준수함을 선언한 기업은 소프트웨어 솔루션을 배포하는 공급망 내에서 신뢰를 제공할 수 있게 된다.
ISO/IEC 5230과 ISO/IEC 18974는 유사한 포맷의 표준으로 공통 요구사항을 다수 포함한다. 아래 표는 두 표준의 요구사항 중 공통 사항과 차이점을 보여준다.
여기에서는 기업이 이 두 표준을 모두 준수하기 위해 충족해야 하는 여섯 가지 주요 요구사항과 각각의 준수 방법을 세부적으로 설명한다.
오픈소스를 이용하여 소프트웨어를 개발하고 배포하는 기업이라면 오픈소스를 관리하기 위한 정책과 프로세스를 만들고, 이를 위한 인력과 자원을 적절하게 할당해야 한다.
오픈소스 프로그램이란 정책, 프로세스, 인원 등 기업이 오픈소스 컴플라이언스 활동을 수행하기 위한 일련의 관리 체계를 의미하며, OpenChain 규격의 첫 번째 요구사항은 바로 이 오픈소스 프로그램을 설립하라는 것이다.
그 첫 번째 요구사항으로 문서화된 오픈소스 정책이 있어야 한다. ISO/IEC 5230과 ISO/IEC 18984 표준에의 3.1.1항에서는 다음과 같이 정책에 대한 요구사항과 입증 자료를 정의하고 있다.
ISO/IEC 5230
3.1.1 Policy
배포용 소프트웨어의 오픈소스 라이선스 컴플라이언스를 관리하는 문서화된 오픈소스 정책이 있어야 한다. 이 정책은 조직 내부에 전파되어야 한다.
입증 자료:
3.1.1.1 문서화된 오픈소스 정책
3.1.1.2 프로그램 참여자가 오픈소스 정책의 존재를 알 수 있게 하는 문서화된 절차 (교육, 내부 위키, 혹은 기타 실질적인 전달 방법 등)
3.1.1 Policy
A written open source policy shall exist that governs open source license compliance of the supplied software. The policy shall be internally communicated.
Verification Material(s):
3.1.1.1 A documented open source policy.
3.1.1.2 A documented procedure that makes program participants aware of the existence of the open source policy (e.g., via training, internal wiki, or other practical communication method).
ISO/IEC 18974
3.1.1 정책
배포용 소프트웨어의 오픈소스 소프트웨어 보안 보증을 관리하는 문서화된 오픈소스 정책이 있어야 한다. 이 정책은 조직 내부에 전파되어야 한다. 정책과 전파 방법은 항상 유효하고 최신 상태를 유지하기 위한 검토 프로세스를 가져야 한다.
입증 자료:
3.1.1.1: 문서화된 오픈소스 소프트웨어 보안 보증 정책
3.1.1.2: 프로그램 참가자에게 보안 보증 정책을 알리기 위한 문서화된 절차.
3.1.1 Policy
A written policy will be created that governs Open Source Software Security Assurance of Supplied Software. The policy will be internally communicated. The policy and its method of communication will have a review process to ensure they are current and relevant.
Verification Material(s):
3.1.1.1: A documented Open Source Software Security Assurance policy;
3.1.1.2: A documented procedure to make Program Participants aware of the Security Assurance policy.
먼저 오픈소스 정책을 수립하고 문서화해야 한다. 오픈소스 정책은 다음을 포함한다.
이 안내서에서는 참고를 위해 ISO/IEC 5230, ISO/IEC 18974 두 표준의 요구사항을 충족하는 샘플 오픈소스 정책 문서를 “[부록 1] 오픈소스 정책”에서 제공한다.
기업은 모든 프로그램 참여자가 조직 내에 오픈소스 정책이 있다는 것을 인식하고 필요한 활동을 할 수 있도록 교육, 내부 위키 등 실질적인 수단을 제공해야 한다. 여기서 프로그램 참여자란 기업이 소프트웨어를 개발하고 배포, 기여하는 데 관여하는 모든 직원을 의미하며, 소프트웨어 개발자, 배포 엔지니어, 품질 엔지니어 등을 포함한다.
많은 기업은 오픈소스 정책 문서를 사내 위키 사이트를 통해 공개하여 직원 누구나 필요한 사항을 확인할 수 있게 한다. 또한, 신규 채용 인원의 입사 연수 시 오픈소스 정책에 대한 교육을 의무화하고, 프로그램 참여자를 대상으로 매년 혹은 2년에 한 번씩 주기적인 교육을 제공함으로 모든 프로그램 참여자가 오픈소스 정책의 존재를 인식하게 한다. 즉, 기업은 이러한 방법들을 다음의 예와 같이 작성하여 오픈소스 정책 문서 포함해야 한다.
이에 대한 예시는 [부록 1] 오픈소스 정책의 5. 교육 및 평가를 참고할 수 있다.
5. 교육 및 평가
4장에서 정의한 각 역할을 담당하는 모든 구성원은 [Learning Portal]에서 제공하는 오픈소스 교육 고급 과정을 수강해야 합니다. 이를 통해 오픈소스 정책, 관련 교육 정책 및 조회 방법을 숙지합니다.
교육 이력과 평가 결과는 [Learning Portal]에 최소 3년간 보존합니다.
이 장은 프로그램 참여자가 갖추어야 할 역량에 대한 요구사항을 정의한다. ISO/IEC 5230과 ISO/IEC 18974 표준의 3.1.2항에서는 다음과 같이 역량에 대한 요구사항과 입증 자료를 정의하고 있다.
ISO/IEC 5230
3.1.2 역량
조직은 다음 사항을 수행해야 한다:
입증 자료:
3.1.2.1 프로그램의 여러 참여자에 대한 역할과 각 역할의 책임을 나열한 문서
3.1.2.2 각 역할을 위해 필요한 역량을 기술한 문서
3.1.2.3 각 프로그램 참여자의 역량을 평가한 문서화된 증거
3.1.2 Competence
The organization shall:
Verification Material(s):
3.1.2.1 A documented list of roles with corresponding responsibilities for the different participants in the program.
3.1.2.2 A document that identifies the competencies for each role.
3.1.2.3 Documented evidence of assessed competence for each program participant.
ISO/IEC 18974
3.1.2 역량
조직은 다음 사항을 수행해야 한다:
입증 자료:
3.1.2.1: 여러 프로그램 참여자에 대한 각각의 책임을 나열한 문서
3.1.2.2: 각 역할을 위해 필요한 역량을 기술한 문서
3.1.2.3: 참여자 명단과 그들의 역할
3.1.2.4: 각 프로그램 참여자의 역량을 평가한 문서화된 증거
3.1.2.5: 프로세스를 주기적으로 검토하고 개선했음을 나타내는 문서화된 증거
3.1.2.6: 이러한 프로세스는 회사 내부 모범 사례를 반영하여 항상 현행화되어야 하고, 이를 누가 책임지고 수행해야 하는지를 명시한 문서화된 증거
3.1.2 Competence
The organization shall:
Verification Material(s):
3.1.2.1: A documented list of roles with corresponding responsibilities for the different Program Participants;
3.1.2.2: A document that identifies the competencies for each role;
3.1.2.3: List of participants and their roles;
3.1.2.4: Documented evidence of assessed competence for each Program Participant;
3.1.2.5: Documented Evidence of periodic reviews and changes made to the process;
3.1.2.6: Documented verification that these processes are current with company internal best practices and who is assigned to accomplish them.
오픈소스 프로그램이 효율적이고 성과를 내기 위해서 필요한 역할이 무엇인지와 그 역할이 담당해야 할 책임을 정의해야 한다. 오픈소스 프로그램에 필요한 일반적인 역할은 다음과 같다.
위의 모든 역할을 처음부터 구성해야 하는 것은 아니다. 처음 시작하는 기업이라면 오픈소스 프로그램 매니저 역할을 하는 인원 한 명으로 시작할 수도 있다.
각 역할에 대한 일반적인 책임을 명시한 문서를 [부록 1] 오픈소스 정책의 4. 역할, 책임 및 역량에서 제공한다.
각 역할과 그에 대한 책임을 정의하였으면, 그 역할을 수행할 인원이 갖춰야 할 필요 역량이 무엇인지 정의해야 한다. 이 부분도 마찬가지로 [부록 1] 오픈소스 정책의 4. 역할, 책임 및 역량에 포함하였으니 참고하기 바란다.
기업은 각 역할에 대한 담당자를 지정하고, 지정된 담당자가 교육, 훈련 및 경험을 바탕으로 맡은 역할을 수행할 수 있는 자격을 갖추었음을 확인해야 한다. 필요할 경우, 프로그램 참여자가 충분한 역량을 갖출 수 있도록 교육도 제공해야 한다. 그리고 기업은 각 참여자가 역량을 갖추고 있는지 평가하고 결과를 보관해야 한다.
프로그램 참여자가 수백 명 이상이어서 교육 제공이 쉽지 않을 경우, 기업의 온라인 교육과 평가 시스템을 이용하는 것도 좋은 방법이다.
이와 같은 내용은 기업의 오픈소스 정책에 다음과 같이 포함할 수 있다.
4. 역할, 책임 및 역량
이 정책의 효과를 보장하기 위해 다음과 같이 역할과 책임 및 각 역할의 담당자가 갖추어야 할 역량을 정의한다.
각 역할의 담당 조직/담당자와 필요 역량 수준은 "Appendix 1. 담당자 현황"에서 정의한다.
5. 교육 및 평가
4장에서 정의한 각 역할을 담당하는 모든 구성원은 [Learning Portal]에서 제공하는 오픈소스 교육을 수강해야 한다.
교육 이력과 평가 결과는 [Learning Portal]에서 최소 3년간 보존한다.
기업은 프로세스가 효과적인지 주기적으로 검토하여 개선하고, 이에 대한 근거를 문서화하여야 한다. 따라서, 프로세스 문서 상에 아래와 같은 내용을 포함할 수 있다.
오픈소스 프로그램 매니저는 프로세스를 1년에 한 번 이상 주기적으로 검토하여 내부 모범 사례는 확산 전파하고, 미흡한 부분은 보완할 수 있도록 개선해야 합니다.
다음으로 ISO/IEC 5230과 ISO/IEC 18974 표준의 3.1.3항에서는 다음과 같이 인식에 대한 요구사항과 입증 자료를 정의하고 있다.
ISO/IEC 5230
3.1.3 인식
조직은 프로그램 참여자가 다음 사항을 인식하도록 보장해야 한다:
입증 자료:
3.1.3.1 다음 사항에 대한 프로그램 참여자의 인식을 평가하였음을 나타내는 문서화된 증거 : 프로그램의 목표, 프로그램 내에서의 참여자 기여 방법 및 프로그램을 준수하지 않을 경우 미치는 영향
3.1.3 Awareness
The organization shall ensure that the program participants are aware of:
Verification material(s):
ISO/IEC 18974
3.1.3 인식
조직은 프로그램 참여자가 다음 사항을 인식하도록 보장한다.:
입증 자료:
3.1.3.1: 다음 사항에 대한 프로그램 참여자의 인식을 평가하였음을 나타내는 문서화된 증거 : 프로그램의 목표, 프로그램 내에서의 참여자 기여 방법 및 프로그램을 준수하지 않을 경우 미치는 영향.
3.1.3 Awareness
The organization will ensure that the Program Participants are aware of:
Verification Material(s):
3.1.3.1: Documented Evidence of assessed awareness for the Program Participants - which should include the Program’s objectives, one’s contribution within the Program, and implications of Program non-conformance.
기업은 프로그램 참여자가 기업의 오픈소스 정책, 오픈소스 관련 목표, 효과적인 오픈소스 프로그램이 되기 위한 참여자의 기여 방법, 그리고 프로그램 요구사항을 준수하지 않을 경우 미치는 영향에 대해 인식하게 해야 한다. 이를 위해 기업은 교육을 제공하고, 프로그램 참여자에게 올바르게 인식하였는지 확인하기 위해 평가를 수행한다. 평가 결과는 문서화하여 보관한다.
이를 위한 아래의 예와 같은 내용을 기업의 오픈소스 정책에 포함할 수 있다.
1. 목적
(1) 정책의 목적
이 정책은 OOO 주식회사(이하 “회사"라 함)에서 소프트웨어 개발, 서비스, 배포에 관여하는 전체 조직이 올바르게 오픈소스 소프트웨어(이하 “오픈소스"라 함)를 활용하기 위해 다음과 같은 원칙을 제공합니다.
1. 오픈소스 컴플라이언스 / 보안 보증 원칙
2. 외부 오픈소스 프로젝트로의 기여 원칙
3. 사내 프로젝트를 오픈소스로 공개하기 위한 원칙
이러한 원칙은 회사의 모든 구성원이 오픈소스의 가치를 이해하고, 오픈소스를 올바르게 사용하며, 오픈소스 커뮤니티에 기여하기 위한 방법을 제공합니다.
회사의 모든 구성원은 사내 위키의 다음 링크에서 오픈소스 정책을 확인할 수 있습니다 : [internal_link]
(2) 미준수 시 영향
이 정책을 준수하지 않는다면 다음과 같은 상황이 발생할 수 있습니다.
- 외부로부터 오픈소스 라이선스 준수 요구를 받을 수 있습니다.
- 회사가 개발한 소스 코드를 원치 않게 공개해야 할 수 있습니다.
- 오픈소스 저작권자로부터 법적 소송을 제기당할 수 있습니다.
- 저작권 침해 및 계약 위반으로 벌금을 부과받거나, 제품 판매 중지 명령을 받을 수 있습니다.
- 회사 평판이 손상될 수 있습니다.
- 공급업체와의 계약 위반이 되어 손해배상 청구를 받을 수 있습니다.
- 심각한 보안 사고에 노출되어 회사에 막대한 손해를 입힐 수 있습니다.
이러한 이유로 회사는 오픈소스 정책의 위반을 심각하게 간주하며, 이를 위반하는 구성원이나 조직은 징계 절차에 처할 수 있습니다.
(3) 구성원의 기여 방법
회사의 모든 구성원은 이 정책의 근거와 내용을 이해하고 필요한 활동을 충실히 수행함으로써 정책의 효과 및 회사의 컴플라이언스 수준 향상에 기여할 수 있습니다.
또, 프로그램 참여자가 오픈소스 정책을 인식하게 하기 위한 교육과 평가 방침도 수립해야 한다. 이에 대한 예시를 [부록 1] 오픈소스 정책의 5. 교육 및 평가에서 제공한다.
오픈소스 프로그램을 기업 내 어느 조직 혹은 어느 제품에 적용할지를 결정해야 하며 이를 위한 절차가 필요하다. ISO/IEC 5230과 ISO/IEC 18974 표준에서는 다음과 같이 프로그램의 적용 범위에 대한 요구사항과 입증 자료를 정의한다.
ISO/IEC 5230
3.1.4 프로그램 적용 범위
프로그램은 다양한 범위별로 적용하여 관리할 수 있다. 예를 들어, 한 프로그램을 단일 제품군에만 적용할 수도 있고, 전체 부서 또는 전체 조직에 적용하여 관리할 수 있다. 따라서 각 프로그램에서는 적용 범위를 정확히 명시해야 한다.
입증 자료:
3.1.4 Program scope
Different programs may be governed by different levels of scope. For example, a program could govern a single product line, an entire department or an entire organization. The scope designation needs to be declared for each program.
Verification material(s):
ISO/IEC 18974
3.1.4 프로그램 적용 범위
프로그램은 전체 조직의 위험 관리 정책과 일치하는 기본 원칙과 범위를 정의해야 한다. 프로그램의 적용 범위가 특정 제품 라인인지, 하나의 부서인지 혹은 전체 조직인지 여부가 명확해야 한다. 또한 이 범위는 시간이 지남에 따라 변경될 수 있으며 지속적인 효과를 평가하기 위한 측정 기준이 사용될 수 있음을 이해해야 한다.
입증 자료:
3.1.4.1: 프로그램의 적용 범위와 한계를 명확하게 정의한 문서화된 진술
3.1.4.2: 프로그램 개선을 위해 달성해야 하는 일련의 측정 기준
3.1.4.3: 지속적인 개선을 위해 검토, 업데이트 또는 검사를 수행했음을 입증하는 문서화된 증거
3.1.4 Program scope
A Program should have defined guiding principles and scope that match the risk management policy of the entire organization. It should be clear whether the Program applies to a product line, a department, or the entire organization. It should also be understood that this scope may change over time and metrics may be used to assess its ongoing effectiveness.
Verification Material(s):
3.1.4.1: A written statement that clearly defines the scope and limits of the Program;
3.1.4.2: A set of metrics the program shall achieve to improve;
3.1.4.3: Documented Evidence from each review, update, or audit to demonstrate continuous improvement.
하나의 오픈소스 프로그램을 반드시 기업 전체에 적용해야 하는 것은 아니다. 기업 내 각 조직과 제품의 특성에 따라 적용 범위를 달리 지정할 수 있다. 조직별로, 제품별로 다른 오픈소스 프로그램을 적용할 수 있다. 마찬가지로, 소프트웨어를 전혀 배포하지 않는 조직이라면 오픈소스 프로그램의 적용 범위에서 제외할 수 있다. 기업은 조직과 제품의 특성을 고려하여 오픈소스 프로그램의 적용 범위와 한계를 명확히 정의하고, 이를 오픈소스 정책에 명시할 수 있다.
이를 위하여 다음의 예와 같은 내용을 오픈소스 정책에 포함한다.
1. 적용 범위
이 정책은 다음 세 부분에 적용됩니다.
1. 회사가 외부로 제공하거나 배포하는 모든 제품에 적용됩니다. 단, 오픈소스를 내부 사용 목적으로만 사용하는 것은 이 정책의 범위에 포함되지 않습니다.
2. 구성원이 외부 오픈소스 프로젝트에 기여할 때 적용됩니다.
3. 내부 코드를 오픈소스로 공개할 때 적용됩니다.
기업의 조직과 제품 및 서비스가 비즈니스 환경에 맞추어 변화함에 따라 프로그램의 적용 범위를 결정하거나 수정해야 하는 상황이 발생할 수 있다. 가업은 이에 대응하기 위한 프로세스를 다음의 예와 같이 준비해야 한다.
이를 위하여 다음의 예와 같은 내용을 오픈소스 정책에 포함한다.
적용 범위는 회사의 비즈니스 환경에 맞추어 변경할 수 있습니다. 특히, 오픈소스 프로그램 매니저는 지속적인 효과를 보장하기 위해 이 정책의 적용되지 않고 사외로 배포 혹은 서비스되는 제품이 있는지 월 1회 이상 조사합니다. 이를 측정하여 1건이라도 발견 시 적용 범위를 변경해야 하는 기준으로 삼습니다.
적용 범위를 변경하기 위한 절차는 다음과 같습니다.
1. 오픈소스 프로그램 매니저는 신규사업, 조직개편 등 회사의 비즈니스 환경이 변화에 따라 정책의 적용 범위 변경이 필요하다고 판단할 경우, 이를 위한 제안을 OSRB에 제출합니다.
2. OSRB에서는 적절한 수준의 적용 범위 변경을 승인합니다.
3. OSRB는 오픈소스 정책을 수정하여 정책의 적용 범위를 변경합니다.
기업은 적용 범위를 지속적으로 검토하여 개선하고, 이를 문서화하여야 한다. 이를 위하여 다음의 예와 같은 내용을 오픈소스 정책에 포함한다.
오픈소스 프로그램 매니저는 지속적으로 월 1회 이상 적용 범위를 개선하기 위해 검토, 업데이트 및 검사 이력을 Jira Issue Tracker를 활용하여 문서화합니다.
이 가이드에서는 프로그램 범위 지정에 대한 예시를 [부록 1] 오픈소스 정책의 2. 적용 범위에서 제공한다.
오픈소스를 사용하면 각 라이선스가 부과하는 의무를 준수해야 한다. ISO/IEC 5230의 3.1.5항에서는 다음과 같이 각 오픈소스 라이선스가 부과하는 의무를 알아내기 위한 검토 프로세스를 요구한다.
ISO/IEC 5230
3.1.5 라이선스 의무
각 라이선스에 의해 부과된 의무, 제한 및 권리를 알아내기 위해 식별된 라이선스를 검토하는 프로세스가 있어야 한다.
입증 자료
3.1.5 License obligations
A process shall exist for reviewing the identified licenses to determine the obligations, restrictions and rights granted by each license.
Verification material(s):
오픈소스의 사용 가능 여부를 판단하기 위해서는 먼저 사용하려는 오픈소스의 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무사항을 확인해야 한다. 오픈소스를 사용하였는지, 라이선스는 무엇인지, 각 라이선스가 부여하는 의무는 무엇인지 검토하고 기록해야 한다. 이를 위한 절차의 예는 다음과 같다.
NIPA 산하 오픈소스 소프트웨어 통합지원센터인 오픈업에서 제공하는 “공개SW와 라이선스”(https://www.oss.kr/oss_license )에서는 주요 오픈소스 라이선스의 의무, 제한 및 권리를 설명하고 있다. 또한 SK텔레콤에서 공개한 오픈소스 가이드도 좋은 참고가 된다. : https://sktelecom.github.io/guide/use/license/
위에서 요구하는 “각 식별된 라이선스에 의해 부가된 의무, 제한 및 권리를 검토하고 기록하기 위한 문서화된 절차“는 [부록 2] 오픈소스 프로세스”의 오픈소스 식별 단계에 해당한다.
ISO/IEC 18974의 3.1.5항에서는 다음과 같이 알려진 취약점 대응 및 강력한 보안 소프트웨어 개발을 위한 절차를 요구한다.
ISO/IEC 18974
3.1.5 표준 사례 구현
프로그램은 다음 절차를 정의하고 구현하여 알려진 취약점 및 보안 소프트웨어 개발을 건전하고 강력하게 처리하는 절차를 갖춘다.
위에 나열된 보안 보증 방법에 대한 프로세스가 존재해야 한다.
입증 자료:
3.1.5 - Standard Practice Implementation
The Program demonstrates a sound and robust handling procedures of Known Vulnerabilities and Secure Software Development by defining and implementing following procedures:
A process shall exist for the Security Assurance methods listed above.
Verification Material(s):
따라서 기업은 제품/서비스를 개발하면서 오픈소스 보안 취약점을 탐지하고 해결하는 등 보안 보증을 위한 활동을 수행해야 한다. 이를 위해 기업은 배포용 소프트웨어에서 알려진 취약점 존재 여부를 탐지하고, 식별된 위험이 출시 전에 해결해야 할 뿐 아니라 출시 후 새롭게 알려진 취약점에 대응하기 위한 방법과 절차를 갖춰야 한다. 이에 대해서는 3.3 보안 보증 장에서 자세히 설명한다.
오픈소스 프로그램이 효과적으로 운용되기 위해서는 충분한 리소스와 인력 할당이 필요하다. 여기에서는 이를 위한 요구사항을 정의한다.
ISO/IEC 5230과 ISO/IEC 18974의 3.2.1항에서는 다음과 같이 접근성에 대한 요구사항과 입증 자료를 정의하고 있다.
ISO/IEC 5230
3.2.1 외부 문의 대응 (Access)
외부의 오픈소스 문의에 효과적으로 대응하기 위한 프로세스를 유지해야 한다. 제 3자가 오픈소스 컴플라이언스에 대해 문의 할 수 있는 방법을 공개해야 한다.
입증 자료:
3.2.1 Access
Maintain a process to effectively respond to external open source inquiries. Publicly identify a means by which a third party can make an open source compliance inquiry.
Verification material(s):
ISO/IEC 18974
3.2.1 - 외부 문의 대응
알려진 취약점에 대한 외부 문의에 효과적으로 대응하기 위한 프로세스를 유지해야 한다. 제3자가 특정 소프트웨어 제품과 관련하여 알려진 취약점에 대해 문의할 수 있는 방법을 공개해야 한다.
입증 자료:
3.2.1 - Access
Maintain a process to effectively respond to Known Vulnerability external inquiries. Publicly identify a means by which a third party can inquire about a Known Vulnerability with respect to a given software offering.
Verification Material(s):
오픈소스를 사용하여 개발한 제품 혹은 서비스에 대해 고객 및 오픈소스 저작권자가 기업에 오픈소스 관련 문의, 요청 및 클레임을 제기하는 경우가 있다. 외부 문의 및 요청의 주된 내용은 다음과 같다.
기업은 이러한 외부 문의를 처리할 담당자를 지정해야 한다. 일반적으로 오픈소스 프로그램 매니저가 담당한다.
외부의 오픈소스 개발자가 특정 기업의 오픈소스 컴플라이언스 관련 이슈를 논의하기 위해 기업 담당자에게 연락하고 싶어도 연락 방법을 찾지 못하다가 결국 바로 법적 클레임을 제기하는 경우가 있다. 이를 방지하기 위해 기업은 제 3자가 기업에 오픈소스 관련하여 문의 및 요청을 할 수 있는 연락 방법을 항시 공개적으로 밝혀야 한다.
외부에서 기업에 오픈소스 관련된 문의를 할 수 있는 연락 방법은 (1) 기업 오픈소스 프로그램 매니저의 이메일 주소를 공개하거나, (2) Linux Foundation의 Open Compliance Directory1를 이용하는 것이다. 기업 오픈소스 프로그램 사무소의 대표 이메일 주소는 제품 및 서비스와 동봉하는 오픈소스 고지문에 포함하여 공개하는 것도 한 방법이다.
Linux Foundation은 기업이 오픈소스 담당자의 연락처를 공개할 수 있도록 Open Compliance Directory라는 공간을 마련하였다.
기업의 오픈소스 담당자는 “Add an Organization"을 이용하여 기업의 연락처를 등록한다. 외부 개발자는 “Request a Contact"에서 오픈소스 컴플라이언스 관련 문의 및 요청을 할 수 있다. 이를 통해 오픈소스 개발자들은 원하는 기업의 컨택 포인트 정보를 쉽게 확인할 수 있고, 법적 클레임까지 제기하기 이전에 기업의 오픈소스 담당자와 오픈소스 컴플라이언스 이슈를 논의하여 문제를 해결할 수 있다. Open Compliance Directory에 기업 정보 및 연락 방법을 등록하는 것이 소송 리스크를 줄일 수 있는 방법의 하나다.
기업이 외부 클레임에 의해 법적 소송까지 당하지 않기 위해서는 외부 문의 및 요청에 가능한 빠르고 정확하게 대응하는 것이 중요하다. 이를 위해 기업은 외부 오픈소스 문의를 빠르고 효과적으로 대응 할 수 있는 프로세스를 갖추고 있어야 한다.
위의 내용은 다음의 예시 문장을 오픈소스 정책에 반영할 수 있다.
9. 외부 문의 대응
(1) 외부 문의 대응 책임
외부로부터 오픈소스에 대한 문의 및 요청에 대한 대응은 오픈소스 프로그램 매니저가 담당합니다.
- 오픈소스 프로그램 매니저는 회사 내의 적절한 인원에게 문의에 대한 전체 또는 일부의 처리를 할당할 수 있습니다. 필요할 경우 법률 담당자에게 문의하여 처리합니다.
- 외부로부터 오픈소스에 대한 문의를 받은 사람은 누구나 이를 오픈소스 프로그램 매니저에게 알려서 신속한 대응이 될 수 있게 합니다.
(2) 연락처 공개
오픈소스 프로그램 매니저는 외부에서 오픈소스 관련한 문의 및 요청을 할 수 있도록 담당자의 연락처를 공개적으로 제공합니다.
- 오픈소스 고지문에 연락받을 수 있는 이메일 주소 정보를 제공합니다.
- 오픈소스 웹사이트에 이메일 주소 정보를 제공합니다.
- Linux Foundation의 Open Compliance Directory에 연락처를 등록합니다.
(3) 외부 문의 대응 절차
외부로부터의 오픈소스 문의에 신속하고 정확하게 대응한다면 클레임이나 법적 소송 위험을 크게 줄일 수 있습니다. 이를 위해 회사는 외부의 오픈소스 문의에 대응하기 위해 회사의 오픈소스 프로세스에서 정의한 외부 문의 대응 절차를 준수합니다.
또한 이 가이드에서는 외부 문의에 대응하기 위한 일반적인 절차에 대한 예시를 [부록 2] 오픈소스 프로세스의 3. 외부 문의 대응 프로세스에서 제공한다.
ISO/IEC 5230과 ISO/IEC 18974의 3.2.2항에서는 다음과 같이 효과적인 오픈소스 프로그램의 운영을 위한 리소스 제공에 대한 요구사항과 입증 자료를 정의하고 있다.
3.2.2 효과적인 리소스 제공
프로그램이 효과적일 수 있도록 다음과 같이 업무를 정의하고 리소스를 제공해야 한다:
입증 자료:
3.2.2 Effectively resourced
Identify and Resource Program Task(s):
Verification material(s):
3.2.2 - 효과적인 리소스 제공
프로그램이 효과적일 수 있도록 다음과 같이 업무를 정의하고 리소스를 제공해야 한다:
입증 자료:
3.2.2 - Effectively Resourced
Identify and Resource Program Task(s):
Verification Material(s):
기업은 각 프로그램 참여자의 역할 및 그에 따른 책임을 나열하고, 각 역할을 담당하는 담당자 혹은 담당 조직을 지정해야 한다. 그리고 이를 문서화하고 오픈소스 정책 문서에 포함해서 누구나 열람할 수 있게 해야 한다. 다음의 예시를 참고하라.
4. 역할, 책임 및 역량
정책의 효과를 보장하기 위해 다음과 같이 역할과 책임 및 각 역할의 담당자가 갖추어야 할 역량을 정의합니다.
각 역할의 담당 조직/담당자와 필요 역량 수준은 [부록 1. 담당자 현황]에서 정의합니다.
- 오픈소스 프로그램 매니저는 회사의 비즈니스 상황에 맞추어 주기적으로 명단을 업데이트합니다.
기업은 오픈소스 프로그램이 원활하게 기능을 수행할 수 있도록 충분한 리소스를 제공해야 한다. 프로그램 내 각 역할을 담당하는 인원을 적합하게 배치하고, 충분한 예산과 업무 시간을 보장해야 한다. 그렇지 않을 경우, 이를 보완할 수 있는 절차가 마련되어야 한다. 다음의 예시 문장을 오픈소스 정책 문서에 추가할 수 있다.
4. 역할, 책임 및 역량
각 역할에 대한 담당 조직의 장은 조직 내 담당자를 지정하고, 담당자가 역할을 충실하게 수행할 수 있는 적절한 시간과 예산을 할당합니다.
- 각 역할의 담당자는 자신이 역할을 수행하면서 적절한 지원이 되지 않는다면 오픈소스 프로그램 매니저에게 문제를 제기해야 합니다.
- 오픈소스 프로그램 매니저는 해당 조직장과 문제 해결을 논의합니다. 적절하게 해결되지 않는다면, 오픈소스 프로그램 매니저는 OSRB에 문제 해결을 요청할 수 있습니다.
- OSRB는 상위 조직의 장에게 문제를 공유하고 해결을 요청합니다.
기업은 프로그램 참여자가 이슈 해결을 위해 법률적인 검토가 필요할 경우, 이에 대해 법률 자문을 요청할 수 있는 방법을 제공해야 한다. 회사 내의 법무팀을 통해 우선 제공하고, 이슈가 첨예한 경우, 오픈소스 전문 변호사를 보유한 외부 법무 법인을 이용할 수 있다. 이를 위한 오픈소스 정책의 예시는 다음과 같다.
4. 역할, 책임 및 역량
(2) 오픈소스 프로그램 매니저
- 구성원이 오픈소스 관련 자문을 받는 방법을 제공합니다.
참고로, OpenChain 프로젝트에서는 파트너 프로그램을 통해 오픈소스 관련 자문을 제공하는 글로벌 법무법인 리스트를 제공한다.
OpenChain 파트너로 등록된 법무법인은 OpenChain 프로젝트에서 요구하는 요건을 충족한 곳들이며, 대한민국에서는 유일하게 법무법인 태평양이 등록되어 있다.
오픈소스 컴플라이언스와 보안 보증에 대한 내부 책임을 할당하는 절차가 있어야 한다. 오픈소스 프로그램 매니저와 보안담당자는 이슈를 파악하고 각 역할의 담당자에게 적절히 이슈를 할당해야 한다. 이를 위해 기업은 오픈소스 정책 문서에 이러한 내용을 아래와 같이 기술할 수 있다.
4. 역할, 책임 및 역량
(2) 오픈소스 프로그램 매니저
오픈소스 프로그램 매니저는 회사의 오픈소스 프로그램에 대한 총괄 책임을 담당합니다. 오픈소스를 사용한 제품과 서비스의 오픈소스 관리 활동을 보장하기 위해 다음 사항에 대한 책임이 있습니다.
- 오픈소스 컴플라이언스를 위해 필요한 역할을 정의하고, 각 역할을 책임질 담당 조직 및 담당자를 지정합니다. 필요 시 OSRB와 협의합니다. 오픈소스 보안 보증을 위한 내부 책임은 보안 담당자가 할당합니다.
기업은 오픈소스 정책 문서에 위의 내용을 기술하여 오픈소스 프로그램에 효과적인 리소스가 제공될 수 있도록 해야 한다.
컴플라이언스 미준수 문제가 제기된 경우, 기업은 이를 신속히 검토하고 대응하기 위한 절차를 문서화해야 한다. 다음의 예시를 참고하여 오픈소스 정책에 포함할 수 있다.
6. 오픈소스 사용
(5) 컴플라이언스 이슈 대응 절차
컴플라이언스 이슈가 제기될 경우, 오픈소스 프로그램 매니저는 다음의 절차를 수행하여 신속히 대응합니다.
1. 문의 접수를 확인하고 적절한 해결 시간을 명시합니다.
2. 이슈 내용이 실제 문제를 지적하고 있는지를 확인합니다. (아닐 경우, 이슈 제기자에게 문제가 아님을 알립니다.)
3. 실제 문제인 경우, 우선순위를 정하고 적절한 대응 방안을 결정합니다.
4. 대응을 수행하고, 필요할 경우, 오픈소스 프로세스를 적절하게 보완합니다.
5. 위의 내용은 Jira Tracker를 이용하여 보존합니다.
이 가이드에서는 효과적인 리소스 제공에 대한 예시를 [부록 01] 샘플 오픈소스 정책의 4. 역할, 책임 및 역량에서 제공한다.
Open Compliance Directory - https://compliance.linuxfoundation.org/references/open-compliance-directory/ ↩︎
ISO/IEC 5230과 ISO/IEC 18974의 3.3.1항에서는 다음과 같이 BOM(Bill of Materials)에 대한 요구사항과 입증 자료를 정의하고 있다.
ISO/IEC 5230
3.3.1 BOM
배포용 소프트웨어를 구성하는 오픈소스 컴포넌트(및 식별된 라이선스)에 대한 BOM(Bill of Materials)을 생성하고 관리하는 프로세스가 있어야 한다.
입증 자료:
3.3.1 Bill of Materials
A process shall exist for creating and managing a bill of materials that includes each open source component (and its identified licenses) from which the supplied software is comprised.
Verification Material(s):
ISO/IEC 18974
3.3.1 - SBOM (Software Bill of Materials)
배포용 소프트웨어를 구성하는 각 오픈소스 소프트웨어 컴포넌트 내역을 포함하는 BOM(Bill of Materials)을 생성하고 이를 유지하는 프로세스가 있어야 한다.
입증 자료:
3.3.1 - Software Bill of Materials (SBOM)
A process shall exist for creating and maintaining a bill of materials that includes each Open Source Software component from which the Supplied Software is comprised.
Verification Material(s):
오픈소스 관리 활동의 가장 기본은 배포용 소프트웨어에 포함된 오픈소스 현황을 파악하는 것이다. 배포용 소프트웨어에 포함된 오픈소스와 그 라이선스를 식별하여 그 정보를 담고 있는 SBOM(Software Bill of Materials)을 작성하고 관리하는 프로세스를 구축해야 한다. 배포용 소프트웨어의 버전마다 어떤 오픈소스가 포함되어 있는지 알고 있어야 소프트웨어를 배포할 때 각 오픈소스의 라이선스가 요구하는 의무 사항을 준수할 수 있기 때문이다.
모든 오픈소스는 배포용 소프트웨어에 통합하기 전에 검토 및 승인되어야 한다. 오픈소스의 기능, 품질뿐만 아니라 출처, 라이선스 요건을 충족할 수 있는지 사전 검토가 되어야 한다. 이를 위해 검토 요청 → 리뷰 → 승인 과정이 필요하다. [부록 02] 오픈소스 프로세스에서는 기업의 오픈소스 관리를 위한 프로세스 모든 과정에 관해 설명하고 있다.
1. 오픈소스 식별부터 6. 등록까지의 과정을 통해 SBOM을 작성하고 관리하게 된다.
또 이와 같은 오픈소스 프로세스의 모든 과정과 결과는 문서화가 되어야 한다. 이메일을 사용하는 것보다는 Jira, Bugzilla 등의 이슈 트래킹 시스템을 이용하는 것이 이러한 과정을 효율적으로 문서화 할 수 있다.
배포용 소프트웨어에 포함된 오픈소스 목록은 문서화하여 보관해야 한다. Eclipse 재단에서 후원하는 오픈소스 프로젝트인 SW3601은 배포용 소프트웨어별로 포함하고 있는 오픈소스 목록을 트래킹할 수 있는 기능을 제공한다. SW360 사용 방법은 부록 3. 오픈소스 도구을 참고할 수 있다.
이 가이드에서는 SBOM 사용 정책에 대한 예시를 “[부록 1] 샘플 오픈소스 정책의 6. 오픈소스 사용에서 제공한다.
ISO/IEC 5230의 3.3.2항에서는 다음과 같이 라이선스 컴플라이언스에 대한 요구사항과 입증 자료를 정의하고 있다.
ISO/IEC 5230
3.3.2 라이선스 컴플라이언스
프로그램은 배포용 소프트웨어에 대해 프로그램 참여자가 접할 수 있는 일반적인 오픈소스 라이선스의 사용 사례를 관리할 수 있어야 한다. 여기에는 다음과 같은 사용 사례가 포함될 수 있다(아래 목록이 모든 사례를 다루는 것은 아니며, 또한 이 사례를 모두 다뤄야만 하는 것은 아님). :
입증 자료:
3.3.2 License Compliance
The program shall be capable of managing common open source license use cases encountered by program participants for supplied software, which may include the following use cases (note that the list is neither exhaustive, nor might all of the use cases apply):
Verification Material(s):
오픈소스 라이선스를 제대로 준수하기 위해서는 오픈소스 라이선스별로 요구하는 사항에 대해 정확히 알고 있어야 한다. 하지만 개별 소프트웨어 개발자가 이를 일일이 파악하는 것은 어려우므로 오픈소스 책임자는 자주 사용되는 오픈소스 라이선스에 대해 일반적인 사용 사례별 요구사항/주의사항을 정리하여 회사 내부에 공유하는 것이 좋다. 오픈소스 라이선스에 대한 일반적인 가이드와 라이선스 의무 요약 자료는 NIPA에서 제공하는 공개소프트웨어 라이선스 가이드2를 참고할 수 있다. 또한, 소프트웨어의 사용 사례별 라이선스 의무를 분석한 SK텔레콤의 오픈소스 라이선스 가이드3도 좋은 사례가 된다.
부록 2. 샘플 오픈소스 컴플라이언스 프로세스의 오픈소스 컴플라이언스 프로세스의 오픈소스 식별, 검사, 문제해결, 리뷰, 승인 단계를 통해 배포용 소프트웨어의 오픈소스 컴포넌트에 대해 일반적인 오픈소스 라이선스 사용 사례를 처리할 수 있다.
식별 및 검사 단계에서는 소스 코드 스캔 도구를 사용할 수 있다. 소스 코드 스캔 도구는 무료로 사용할 수 있는 오픈소스 기반 도구부터 상용 도구까지 다양하게 있는데, 각 도구는 특장점 들이 있지만 어떤 하나도 모든 문제를 해결할 수 있는 완벽한 기능을 제공하지 않는다. 따라서 기업은 제품의 특성과 요구사항에 맞는 적합한 도구를 선택해야 한다. 많은 기업이 이러한 자동화된 소스 코드 스캔 도구와 수동 검토를 병행하여 이용한다. Linux Foundation의 FOSSology4 프로젝트는 오픈소스로 공개된 소스 코드 스캔 도구로서 기업들이 손쉽게 무료로 사용할 수 있다. 사용 방법은 부록 3. 오픈소스 도구를 참고한다.
ISO/IEC 18974 표준은 다음과 같이 보안 보증 방법에 대한 문서화된 절차와 수행된 조치를 기록하도록 요구한다.
ISO/IEC 18974
3.3.2 - 보안 보증
입증 자료:
3.3.2 - Security Assurance
Verification Material(s):
이를 위해 기업은 배포용 소프트웨어에서 알려진 취약점 존재 여부를 탐지하고, 식별된 위험이 출시 전에 해결해야 할 뿐 아니라 출시 후 새롭게 알려진 취약점에 대응하기 위한 방법과 절차를 갖춰야 한다.
먼저 기업은 배포용 소프트웨어에 알려진 취약점이 있는지 탐지하고, 식별된 위험을 출시 전에 해결해야 합니다. 이와 같이 알려진 취약점을 탐지하고 해결하는 절차는 오픈소스 프로세스의 오픈소스 식별 단계, 소스 코드 검사 단계, 문제 해결 단계를 통해 수행할 수 있다.
그리고, 배포용 소프트웨어의 릴리스 후 새롭게 알려진 취약점이 공개되었을 때 이미 배포된 소프트웨어에 존재하는지 확인하고, 해결하기 위해서는 신규 보안 취약점 대응 프로세스를 수립해야 한다. 2. 신규 보안취약점 대응 프로세스 샘플은 부록 2. 오픈소스 프로세스의 2. 신규 보안취약점 대응 프로세스에서 확인할 수 있다.
NIPA 공개소프트웨어 라이선스 가이드 - https://www.oss.kr/oss_license ↩︎
SK텔레콤 오픈소스 라이선스 가이드 - https://sktelecom.github.io/guide/use/obligation/gpl-2.0/ ↩︎
FOSSology - http://fossology.org/ ↩︎
ISO/IEC 5230의 3.4.1항에서는 다음과 같이 컴플라이언스 산출물에 대한 요구사항과 입증 자료를 정의하고 있다.
ISO/IEC 5230
3.4.1 컴플라이언스 산출물
배포용 소프트웨어에 대한 컴플라이언스 산출물을 생성하는 프로세스가 있어야 한다.
입증 자료:
3.4.1 Compliance artifacts
A process shall exist for creating the set of compliance artifacts for the supplied software.
Verification Materials(s):
앞 장에서 오픈소스 컴플라이언스 활동의 가장 기본은 배포용 소프트웨어에 포함된 오픈소스 현황을 파악하는 것이라고 하였다. 이는 바로 오픈소스 컴플라이언스의 핵심인 오픈소스 라이선스 요구사항을 올바르게 충족하기 위해서이다. 즉, 배포용 소프트웨어에 포함된 오픈소스에 대한 컴플라이언스 산출물 세트를 생성하는 프로세스가 구축되어야 한다.
컴플라이언스 산출물은 크게 두 가지로 구분된다.
이 가이드에서는 컴플라이언스 산출물 생성을 위한 정책에 대한 예시를 “부록 1. 샘플 오픈소스 정책의 6. 오픈소스 사용”에서 제공한다.
컴플라이언스 산출물은 배포용 소프트웨어를 배포할 때 함께 제공해야 한다. “부록 2. 샘플 오픈소스 컴플라이언스 프로세스”의 고지, 배포 전 확인, 배포 단계를 통해 컴플라이언스 산출물을 생성하여 배포한다.
배포용 소프트웨어를 배포 시, 공개할 소스 코드 패키지를 동봉하는 것이 곤란할 경우, 최소 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 99999Please 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/) 구축하여 외부 고객들이 배포용 소프트웨어에 대한 오픈소스 고지문과 공개할 소스 코드 패키지를 언제든지 다운받을 수 있도록 편의를 제공한다.
ISO/IEC 5230의 3.5.1항에서는 다음과 같이 컴플라이언스 산출물에 대한 요구사항과 입증 자료를 정의하고 있다.
3.5.1 기여
조직이 외부 오픈소스 프로젝트로의 기여를 허용하려고 한다면,
입증 자료:
조직이 외부 오픈소스 프로젝트로의 기여를 허용하는 경우, 다음 사항이 있어야 한다.:
3.5.1 Contributions
If an organization considers contributions to open source projects, then
Verification Materials(s):
If an organization permits contributions to open source projects, then the following shall exist:
글로벌 소프트웨어 기업들은 제품을 만들고 서비스를 하는 데 오픈소스를 사용하는 것뿐만 아니라 오픈소스 프로젝트에 기여하며 창출할 수 있는 전략적 가치도 중요하게 여긴다. 그러나 오픈소스 프로젝트 생태계와 커뮤니티 운영방식에 대한 충분한 이해와 전략 없이 접근한다면 예기치 않게 회사의 명성이 손상되고 법적 위험이 발생할 수 있다. 따라서 기업은 오픈소스 프로젝트로의 참여 및 기여를 위한 전략과 정책을 만드는 것이 중요하다.
이러한 오픈소스 기여에 대한 정책은 “부록 1. 샘플 오픈소스 정책의 7. 오픈소스 기여“를 참고할 수 있다.
외부 오픈소스 프로젝트에 기여를 허용하는 정책을 갖고 있다면, 사내 개발자들이 어떤 절차로 외부 프로젝트에 기여할 수 있을지 관리하는 문서화된 절차가 있어야 한다. SK텔레콤에서 공개한 오픈소스 기여 절차[^skt-contribution]는 좋은 예이다.
오픈소스 기여 정책을 만들었다 해도 사내 구성원이 이에 대한 존재를 알지 못한다면 무용지물이 되어버린다. 모든 사내 개발자가 오픈소스 기여 정책의 존재를 알 수 있게 하는 절차가 필요하다. 3.1.1.2에서의 오픈소스 정책 전파 활동과 병행하여 오픈소스 기여 정책을 전파하라.
ISO/IEC 5230의 3.6.1항과 과 ISO/IEC 18974의 3.4.1항에서는 다음과 같이 적합성에 대한 요구사항과 입증 자료를 정의하고 있다.
ISO/IEC 5230
3.6.1 적합성
프로그램이 OpenChain에 적합하다고 간주하기 위해서는 조직은 프로그램이 이 규격에서 제시한 모든 요구사항을 충족하는지 확인해야 한다.
입증 자료:
3.6.1 Conformance
In order for a program to be deemed OpenChain conformant, the organization shall affirm that the program satisfies the requirements presented in this document.
Verification Materials(s):
ISO/IEC 18974
3.4.1 - 완전성 프로그램이 이 규격을 준수하는 것으로 간주되기 위해서, 조직은 프로그램이 이 문서에 제시된 요구사항을 충족한다는 것을 확인해야 한다.
입증 자료:
3.4.1 - Completeness
For a Program to be deemed conformant with this specification, the organization shall affirm that the Program satisfies the requirements presented in this document.
Verification Material(s):
ISO/IEC 5230과 ISO/IEC 18974의 모든 요구사항을 충족하는 기업은 이를 Linux Foundation OpenChain Project의 Self Certification을 통해 자체 인증을 선언할 수 있다. 어느 하나의 요구사항이라도 충족하지 못한다면 각 표준에 적합하다고 할 수 없다.
두 표준의의 모든 요구사항을 충족한다면, 부록 1. 샘플 오픈소스 정책의 10. ISO 표준 준수 선언과 유지에서와 같이 ISO 표준을 준수한다고 정책 문서상에 명시할 수 있다.
10. ISO 표준 준수 선언과 유지
회사는 소프트웨어 공급망에서의 오픈소스 컴플라이언스 수준 향상을 위해 Linux Foundation의 OpenChain 프로젝트의 정신을 지지하며 적극적으로 참여합니다.
- 회사는 이 오픈소스 정책을 적용하여 2021년 10월 1일부로 ISO/IEC 5230:2020을 준수함을 보장합니다.
ISO/IEC 5230의 3.6.2항과 ISO/IEC 18974의 3.4.2항에서는 다음과 같이 지속 기간에 대한 요구사항과 입증 자료를 정의하고 있다.
ISO/IEC 5230
3.6.2 지속 기간
이 규격의 버전 2.1에 적합한 OpenChain 프로그램은 적합성 인증을 획득한 날로부터 18개월 동안 지속되어야 한다. 적합성 인증 등록 절차는 OpenChain 프로젝트의 웹사이트에서 확인할 수 있다.
입증 자료:
3.6.2 Duration
A program that is OpenChain conformant with this version of the specification shall last 18 months from the date conformance validation was obtained. The conformance validation registration procedure can be found on the OpenChain project’s website.
Verification Materials(s):
ISO/IEC 18974
3.4.2 - 지속 기간
이 버전의 규격을 준수하는 프로그램은 다음의 시기마다 다시 검토가 되어야 한다. : 1차 인증일로부터 18개월, 2차 인증일로부터 24개월, 3차 인증일로부터 36개월. 이후에는 36개월마다 검토가 필요하다.
입증 자료:
3.4.2 - Duration
A Program that is conformant with this version of the specification will have a review period as follows: 18 months from the first certification, 24 months from the second certification and 36 months from the third certification. It will require review every 36 months after this.
Verification Material(s):
기업은 ISO 표준을 준수한다고 선언한 이후에도 계속해서 유지하는 것이 중요하다. ISO 표준에서는 준수한다고 선언한 이후에도 최소 18개월 이상은 변함없이 ISO 표준의 모든 요구사항을 준수하고 있어야 함을 요구한다.
기업은 ISO 표준을 준수한다고 선언한 이후 적어도 18개월 이상 계속해서 준수하는 상태를 유지하여야 하며, 그렇게 하고 있다면, 부록 1. 샘플 오픈소스 정책의 10. ISO 표준 준수 선언과 유지에서와 같이 ISO표준을 18개월 이상 계속하여 충족하고 있음을 문서상에 명시할 수 있다.
10. ISO 표준 준수 선언과 유지
- 회사는 적합성 인증을 획득한 후 18개월 이상 ISO/IEC 5230:2020의 모든 요구사항을 충족함을 보장합니다.
- 회사는 최소 18개월 간격으로 적합성을 검토하고 필요에 따라 정책을 변경 및 갱신합니다.
여기까지 완료하면 기업은 드디어 ISO/IEC 5230, ISO/IEC 18974의 모든 요구사항을 충족하게 된다.