이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.

이 페이지의 일반 화면으로 돌아가기.

Guide

기업의 오픈소스 컴플라이언스를 위한 가이드를 제공합니다.

1 - Welcome Package

OpenChain KWG의 웰컴 패키지는 신규 멤버들이 KWG 활동에 효과적으로 적응하고 기여할 수 있도록 필요한 정보와 자료를 종합적으로 제공하는 안내서입니다.

1. OpenChain KWG 소개

KWG의 미션과 비전

OpenChain Korea Work Group(KWG)의 미션은 오픈소스 정신인 협업과 공유를 통해 모든 기업이 효과적으로 오픈소스 컴플라이언스를 달성할 수 있도록 돕는 것입니다. KWG의 비전은 OpenChain Project와 동일하며 신뢰할 수 있는 소프트웨어 공급망을 구축하는 것입니다.

설립 배경 및 역사

KWG는 다음과 같은 배경에서 설립되었습니다:

  1. 대기업들도 복잡한 소프트웨어 공급망에서 오픈소스 리스크에 노출될 수 있다는 인식.
  2. 소프트웨어 공급망 내 모든 기업의 오픈소스 관리 수준 향상의 필요성.
  3. 기업 간 오픈소스 관리 노하우 공유의 중요성.

KWG는 Linux Foundation의 OpenChain Project의 하위 그룹으로, 한국 기업들의 오픈소스 컴플라이언스를 지원하기 위해 설립되었습니다. 주요 대기업들의 오픈소스 담당자들이 참여하여 LG전자에서 2019년 1월 첫 번째 모임을 개최하면서 공식적으로 활동을 시작했습니다.

주요 성과

KWG는 설립 이후 다음과 같은 주요 성과와 마일스톤을 달성했습니다:

  1. 정기 모임 개최: 매 분기마다 정기 모임을 진행하며, 코로나 이후에는 3년 만에 오프라인 모임을 재개했습니다.
  2. 기업 간 협력 강화: LG전자, SK텔레콤, 카카오, 현대자동차, 삼성전자 등 주요 기업들의 오픈소스 담당자들이 참여하여 협력을 강화했습니다.
  3. 오픈소스 관리 가이드 개발: 기업들이 효과적으로 오픈소스를 관리할 수 있도록 상세한 가이드를 개발하고 공유했습니다.
  4. 커뮤니티 확장: 현재 약 70명의 멤버가 활발히 활동하며, 5-6년 이상의 지속적인 커뮤니티 활동을 통해 높은 수준의 전문성을 갖추게 되었습니다.
  5. 온라인 플랫폼 구축: GitHub를 통해 문서와 자료를 공유하고, Discord 채널을 통해 멤버 간 소통을 활성화했습니다.

KWG는 이러한 활동을 통해 한국 기업들의 오픈소스 관리 수준을 높이고, 글로벌 오픈소스 생태계에 기여하는 중요한 역할을 수행하고 있습니다. 앞으로도 지속적인 협력과 지식 공유를 통해 더 많은 기업들이 효과적으로 오픈소스를 활용하고 관리할 수 있도록 지원할 예정입니다.

2. OpenChain KWG 활동 안내

정기 모임 일정 및 참여 방법

OpenChain Korea Work Group(KWG)은 오픈소스 컴플라이언스에 관심 있는 기업들이 모여 지식과 경험을 공유하는 정기 모임을 개최합니다. 이 모임은 오픈소스 관리의 베스트 프랙티스를 공유하고, 업계의 최신 동향을 파악하는 중요한 기회입니다.

모임 일정

  1. 주기: KWG는 분기별로 정기 모임을 개최합니다. 즉, 연 4회 모임이 있습니다.
  2. 일정 공지: 다음 모임의 구체적인 날짜와 장소는 KWG 웹사이트와 메일링 리스트를 통해 공지됩니다.
  3. 최근 모임:
    • 21차 모임: 2024년 3월 26일 (화) / 카카오 판교아지트
    • 22차 모임: 2024년 6월 20일 (목) / CJ Talent Training Center
    • 23차 모임: 2024년 9월 10일 (화) / ETRI 서울사옥

참여 방법

  1. 가입 자격: 소프트웨어를 개발하여 배포하는 한국 기업/기관에서 오픈소스 컴플라이언스 업무를 담당하는 분이라면 누구나 참여 가능합니다.
  2. 메일링 리스트 가입:
    • KWG의 주요 소통 채널인 메일링 리스트에 가입해야 합니다.
    • 가입 방법은 KWG 웹사이트에서 확인할 수 있습니다.
  3. 사전 등록:
    • 각 모임 전에 사전 등록 절차가 있을 수 있습니다.
    • 등록 방법은 메일링 리스트를 통해 공지됩니다.
  4. 발표 기회:
    • 참가자들은 자사의 오픈소스 관리 경험이나 사례를 공유할 수 있습니다.
    • 발표를 원하는 경우, GitHub Discussions에 미리 등록하여 일정을 조율할 수 있습니다.
  5. 온/오프라인 참여:
    • 주로 오프라인으로 진행되고 있습니다. (COVID-19에는 온라인으로 진행)
    • 참여 방식은 각 모임 공지 시 메일링 리스트로 안내됩니다.
  6. 자료 공유:
    • 모임에서 공유된 발표 자료는 대부분 KWG 웹사이트나 GitHub 저장소를 통해 공개됩니다.
    • 참가자들은 이를 통해 모임 내용을 복습하고 추가 학습할 수 있습니다.

KWG 정기 모임은 오픈소스 컴플라이언스에 관심 있는 모든 이들에게 열려 있는 귀중한 학습과 네트워킹의 장입니다. 적극적인 참여를 통해 기업 간 협력을 도모하고, 오픈소스 관리 역량을 높일 수 있는 기회를 제공합니다.

온라인 커뮤니케이션 채널 사용 가이드

OpenChain Korea Work Group(KWG)은 멤버들 간의 원활한 소통과 정보 공유를 위해 다양한 온라인 커뮤니케이션 채널을 운영하고 있습니다. 주요 채널은 메일링 리스트와 Discord입니다. 이 채널들을 통해 멤버들은 지속적으로 정보를 교환하고 협력할 수 있습니다.

1. 메일링 리스트

메일링 리스트는 KWG의 주요 공식 소통 채널입니다. 이 채널은 공식 공지, 모임 안내, 중요 토론, 자료 공유 등에 사용됩니다. 이 메일링 리스트를 통해 OpenChain KWG의 최신 소식, 이벤트 정보, 그리고 다른 멤버들과의 소통을 경험하실 수 있습니다. 오픈소스 컴플라이언스에 관심 있는 전문가들과 지식과 경험을 공유할 수 있는 좋은 기회가 될 것입니다.

가입 방법:
  1. 가입 신청 이메일 작성:
  2. 이메일 발송: 작성한 내용을 위 이메일 주소로 보내주세요.
  3. 승인 절차: Steering Committee에서 신청 내용을 확인한 후 가입 절차를 진행합니다.
  4. 승인 완료: 승인이 완료되면 메일링 리스트 가입을 위한 초대 메일을 받게 됩니다.
가입 문의:

OpenChain KWG 가입과 관련하여 추가적인 문의사항이 있으시면 Steering Committee로 연락 주시기 바랍니다.

메일링 리스트 사용 가이드:
  1. 이메일 발송: 수신자로 korea-wg@lists.openchainproject.org 를 지정 후 이메일을 발송하면 메일링 리스트에 가입된 모든 멤버에게 메일이 발송됩니다.
  2. 메일링 리스트 에티켓:
    • 명확하고 구체적인 제목을 사용하세요. 이는 다른 멤버들이 내용을 빠르게 파악하는 데 도움이 됩니다.
    • 항상 전문적이고 예의 바른 언어를 사용하세요.
    • 메일링 리스트의 목적과 관련 없는 주제나 스팸성 내용은 피해주세요.
    • 긴 내용의 메일을 보낼 때는 주요 내용을 요약하고, 필요시 첨부 파일을 사용하세요.
    • 답장 시 원본 메일의 관련 부분만 인용하고, 불필요한 내용은 삭제하세요.
    • 특정 개인이나 기업을 비방하는 내용은 삼가주세요.
  3. 아카이브 활용: 메일링 리스트의 모든 내용은 보관되어 있습니다. 과거 논의 내용을 찾아보고 싶다면 메일시스템를 활용하세요.

2. Discord

Discord는 보다 가벼운 대화와 실시간 소통을 위한 채널입니다. 비공식 토론, 질의응답, 네트워킹 등에 활용됩니다.

Discord 참여 방법:
  1. KWG 웹사이트 또는 메일링 리스트를 통해 공유되는 Discord 초대 링크를 확인합니다.
  2. 링크를 클릭하여 KWG Discord 서버에 참여합니다.
  3. 필요한 경우 Discord 계정을 생성합니다.
Discord 사용 가이드:
  1. 채널 구조 이해:
    • #공지: KWG의 공식 공지사항을 전달하는 채널입니다. 관리자만 글을 작성할 수 있으며, 멤버들은 주요 안내사항을 확인해야 합니다.
    • #정보-뉴스: 오픈소스 및 컴플라이언스 관련 최신 정보와 뉴스를 공유하는 공간입니다. 멤버들이 관련 뉴스 기사, 블로그 포스트, 컨퍼런스 정보 등을 공유할 수 있습니다.
    • #오픈소스이야기: 오픈소스 전반에 대한 자유로운 토론과 정보 교환이 이루어지는 채널입니다. 오픈소스 관련 질문, 경험 공유, 의견 교환 등이 가능합니다.
    • #툴링리걸그룹: 오픈소스 관리 도구와 법적 이슈에 대해 논의하는 전문 채널입니다. 오픈소스 관리 도구 사용 경험, 법적 문제에 대한 질문과 답변이 이루어집니다.
    • #온보딩tf: 새로운 멤버의 온보딩 프로세스 개선을 위한 태스크 포스 채널입니다. 온보딩 관련 아이디어 제안, 프로세스 개선 논의 등이 이루어집니다.
    • #아무말대잔치: 자유로운 대화와 친목 도모를 위한 비공식 채널입니다. 업무 외적인 주제, 가벼운 대화, 유머 등을 공유할 수 있습니다.
  2. 알림 설정:
    • 각 채널별로 알림 설정을 조정할 수 있습니다.
    • 중요한 채널은 모든 메시지에 대해 알림을 받고, 덜 중요한 채널은 멘션될 때만 알림을 받도록 설정하는 것이 좋습니다.
  3. Discord 에티켓:
    • 각 채널의 목적에 맞는 주제로 대화해주세요.
    • 긴 코드나 로그를 공유할 때는 코드 블록 기능을 사용하세요.
    • 다른 멤버의 의견을 존중하고, 건설적인 대화를 나누세요.
    • 개인적인 대화는 DM(Direct Message)을 이용해주세요.
    • 이모지 반응을 통해 간단한 동의나 반응을 표현할 수 있습니다.
  4. 음성 채널 활용:
    • Discord에는 음성 채널도 있습니다. 필요시 실시간 음성 대화나 화면 공유에 활용할 수 있습니다.
    • 음성 채널 사용 시 주변 소음에 주의하고, 적절한 마이크 설정을 확인하세요.

3. 기타 온라인 리소스

  1. GitHub 저장소:
    • 주소: https://github.com/OpenChain-KWG
    • KWG의 문서, 코드, 프로젝트 관리가 이루어지는 공간입니다.
    • 문서에 기여하고 싶거나, 이슈를 제기하고 싶을 때 활용하세요.
    • Pull Request를 통해 직접 문서 수정을 제안할 수 있습니다.
    • Issues 섹션에서 새로운 아이디어나 문제점을 제기할 수 있습니다.
  2. 공식 웹사이트:
    • 주소: https://openchain-project.github.io/OpenChain-KWG/
    • KWG의 공식 정보와 자료를 제공하는 웹사이트입니다.
    • 정기 모임 일정, 발표 자료, 활동 내역 등을 확인할 수 있습니다.
    • 웹사이트는 정기적으로 업데이트되므로, 자주 방문하여 최신 정보를 확인하세요.

이러한 다양한 온라인 커뮤니케이션 채널을 적절히 활용하면, KWG 멤버로서 오픈소스 컴플라이언스 활동에 더욱 효과적으로 참여할 수 있습니다. 각 채널의 특성을 이해하고, 목적에 맞게 사용하는 것이 중요합니다.

3. OpenChain KWG 멤버십 혜택

OpenChain Korea Work Group(KWG) 멤버십은 오픈소스 관리 분야에서 귀하와 귀사에 다양한 혜택을 제공합니다. 이 단원에서는 KWG 멤버십의 주요 혜택을 상세히 살펴보겠습니다.

지식 공유 및 네트워킹 기회

1. 정기 모임 참여:

  • 분기별 개최되는 KWG 정기 모임에 참석할 수 있습니다.
  • 국내 주요 기업의 오픈소스 관리 사례와 최신 트렌드를 직접 들을 수 있습니다.

2. 전문가 네트워크 구축:

  • LG전자, SK텔레콤, 카카오, 현대자동차, 삼성전자 등 국내 주요 기업의 오픈소스 전문가들과 교류할 수 있습니다.
  • 업계 선도 기업의 베스트 프랙티스를 배우고 적용할 수 있습니다.

3. 온라인 지식 공유 플랫폼 활용:

  • KWG Discord 채널을 통해 실시간으로 질문하고 답변을 받을 수 있습니다.
  • 메일링 리스트를 통해 중요한 정보와 업데이트를 받아볼 수 있습니다.

기업 간 협력 프로젝트 참여 가능성

1. 공동 연구 프로젝트:

  • 오픈소스 관리 도구 개발, 프로세스 최적화 등의 공동 프로젝트에 참여할 수 있습니다.
  • 예: ‘OpenChain 준수를 위한 자동화 도구 개발’ 프로젝트 참여

2. 번역 및 현지화 작업:

  • OpenChain 프로젝트의 문서를 한국어로 번역하는 작업에 참여할 수 있습니다.
  • 국제 표준의 한국 기업 적용을 위한 가이드라인 개발에 기여할 수 있습니다.

3. 산업별 워킹 그룹:

  • 자동차, 전자, IT 서비스 등 산업별 특화된 오픈소스 관리 이슈를 논의하는 소그룹 활동에 참여할 수 있습니다.
  • 동종 업계의 기업들과 협력하여 산업 특화된 솔루션을 개발할 수 있습니다.

4. 멘토링 프로그램:

  • 오픈소스 관리 경험이 풍부한 기업의 전문가로부터 멘토링을 받을 수 있습니다.
  • 자사의 경험을 공유하며 멘토로 활동할 기회도 얻을 수 있습니다.

글로벌 오픈소스 커뮤니티와의 연계

1. 국제 컨퍼런스 참여 기회:

  • OpenChain Global Work Group 미팅에 참여할 수 있습니다.
  • 글로벌 오픈소스 컨퍼런스에서 KWG의 활동을 소개하고 발표할 기회를 얻을 수 있습니다.

2. 국제 표준화 활동 참여:

  • ISO/IEC 5230(오픈소스 컴플라이언스)과 ISO/IEC 18974(오픈소스 보안) 등의 국제 표준 개발에 의견을 제시할 수 있습니다.
  • 한국의 오픈소스 생태계를 대표하여 글로벌 표준 설정에 기여할 수 있습니다.

3. 글로벌 네트워크 확장:

  • Linux Foundation, OpenChain Project, SPDX 등 국제 오픈소스 단체의 핵심 인사들과 교류할 수 있습니다.
  • 글로벌 기업들의 오픈소스 관리 사례를 직접 들을 수 있는 기회를 얻습니다.

4. 국제 협력 프로젝트 참여:

  • 다국적 기업들과 함께 오픈소스 관리 도구나 프레임워크를 개발하는 프로젝트에 참여할 수 있습니다.
  • 글로벌 오픈소스 생태계 발전에 직접 기여할 수 있는 기회를 얻습니다.

KWG 멤버십은 단순한 참여를 넘어 오픈소스 관리의 최전선에서 활동할 수 있는 기회를 제공합니다. 국내외 전문가들과의 협력을 통해 자사의 오픈소스 관리 역량을 높이고, 나아가 글로벌 오픈소스 생태계 발전에 기여할 수 있습니다. KWG와 함께 오픈소스의 무한한 가능성을 탐험해보세요!

4. 리소스 및 학습 자료

OpenChain Korea Work Group(KWG)은 회원들의 오픈소스 관리 역량 강화를 위해 다양한 리소스와 학습 자료를 제공합니다. 이 장에서는 이러한 자료들을 상세히 소개하고 효과적인 활용 방법을 안내합니다.

KWG 웹사이트 주요 섹션 안내

KWG 웹사이트(https://openchain-project.github.io/OpenChain-KWG/)는 다음과 같은 주요 섹션으로 구성되어 있습니다:

  1. About: KWG의 소개, 가입 방법, 멤버 목록 등을 확인할 수 있습니다.
  2. Meeting: 정기 모임 일정과 과거 모임의 발표 자료를 제공합니다.
  3. Resource: 오픈소스 관리에 필요한 각종 문서와 도구를 소개합니다.
  4. Blog: KWG 멤버들의 오픈소스 관련 경험과 인사이트를 공유하는 공간입니다.
  5. Subgroup: 특정 주제에 대해 심도 있게 다루는 소그룹 활동 정보를 제공합니다.

기업 오픈소스 관리 가이드 활용법

KWG에서 제공하는 “기업 오픈소스 관리 가이드“는 기업이 오픈소스를 효과적으로 관리하기 위한 종합적인 지침서입니다. 이 가이드의 활용 방법은 다음과 같습니다:

  1. 오픈소스 관리 조직 구축: 가이드의 “조직” 섹션을 참고하여 자사의 상황에 맞는 조직을 구축합니다.
  2. 오픈소스 정책 수립: 가이드의 “정책” 섹션을 참고하여 자사의 상황에 맞는 정책을 수립합니다.
  3. 프로세스 구축: “프로세스” 부분을 활용하여 자사의 개발 환경에 맞는 프로세스를 설계합니다.
  4. 도구 선택: “도구” 섹션에서 소개하는 다양한 도구 중 자사에 적합한 것을 선택합니다.
  5. 교육 프로그램 개발: “교육” 부분을 참고하여 임직원 대상 교육 프로그램을 개발합니다.
  6. 준수 선언: “준수” 섹션을 통해 자사의 컴플라이언스 수준을 점검하고, 준수 하고 있음을 선언합니다.

추천 외부 리소스 및 학습 자료 목록

  1. OpenChain Project 공식 자료:
    • OpenChain Specification: 오픈소스 컴플라이언스 프로그램의 핵심 요구사항을 제공합니다.
    • OpenChain Curriculum: 오픈소스 라이선스와 컴플라이언스에 대한 기본 교육 자료입니다.
  2. Linux Foundation 교육 과정:
  3. 오픈소스 라이선스 관련 자료:
    • SPDX License List: 표준화된 오픈소스 라이선스 목록과 약어를 제공합니다.
    • Choose a License: 프로젝트에 적합한 라이선스를 선택하는 데 도움을 주는 웹사이트입니다.
  4. 오픈소스 보안 관련 자료:

이러한 리소스와 학습 자료를 적극 활용하면, KWG 멤버들은 오픈소스 관리에 대한 깊이 있는 이해와 실무 능력을 키울 수 있습니다. 또한, KWG 웹사이트와 정기 모임을 통해 지속적으로 업데이트되는 최신 정보와 사례를 접할 수 있어, 빠르게 변화하는 오픈소스 생태계에 효과적으로 대응할 수 있습니다.

5. 참여 및 기여 방법

OpenChain Korea Work Group(KWG)은 회원들의 적극적인 참여와 기여를 통해 발전합니다. 이 장에서는 KWG 활동에 참여하고 기여할 수 있는 다양한 방법을 소개합니다.

KWG 활동에 기여할 수 있는 다양한 방법

KWG 회원들은 다음과 같은 다양한 방법으로 활동에 참여하고 기여할 수 있습니다:

  1. 정기 모임 참석 및 피드백 제공: 분기별 모임에 참석하여 의견을 나누고 피드백을 제공합니다.
  2. 특정 주제에 대한 워킹 그룹(소그룹) 참여: 관심 있는 주제의 소그룹 활동에 참여하여 심도 있는 논의를 진행합니다.
  3. 토론 중 전문 지식 및 경험 공유: 자신의 경험과 지식을 다른 회원들과 공유합니다.
  4. 오픈소스 정책 및 모범 사례 개발에 기여: KWG에서 개발하는 가이드라인이나 정책 문서 작성에 참여합니다.
  5. 이벤트, 웨비나 또는 교육 세션 조직 지원: KWG에서 주최하는 다양한 행사의 기획과 운영에 참여합니다.
  6. 효과적인 오픈소스 컴플라이언스 사례 제공: 자사의 성공적인 오픈소스 관리 사례를 공유합니다.
  7. 커뮤니티 내 산업 간 협력 참여: 다른 산업 분야의 회원들과 협력하여 새로운 인사이트를 얻습니다.
  8. 리소스 번역 또는 현지화: KWG의 문서나 자료를 한국어로 번역하거나 현지화하는 작업에 참여합니다.
  9. Discord 채널에서의 토론 참여: 온라인 채널을 통해 지속적으로 의견을 교환하고 토론에 참여합니다.

모임 장소 및 물품 후원

KWG 활동에 대한 장소나 물질적 지원도 매우 중요한 기여 방법입니다.

  • 정기 모임, 서브그룹 모임 등 다양한 KWG 모임을 위한 장소를 제공합니다.
    • 예: 회사 회의실이나 강당을 KWG 모임에 무상으로 대여
  • 모임에 필요한 다과, 기념품, 선물 등을 후원합니다.
    • 예: 정기 모임 참석자를 위한 간식과 음료 제공, KWG 로고가 새겨진 기념품 제작 후원

이러한 물질적 지원은 다음과 같은 이점을 제공합니다:

  • 모임의 원활한 진행을 돕고 참석자들의 만족도를 높입니다.
  • 후원 기업의 이미지를 긍정적으로 홍보할 수 있는 기회가 됩니다.
  • KWG 커뮤니티의 결속력을 강화하고 지속적인 활동을 가능하게 합니다.

물질적 지원을 통한 기여는 직접적인 기술적 기여만큼이나 KWG의 성장과 발전에 중요한 역할을 합니다. 이는 커뮤니티의 지속가능성을 높이고, 더 많은 참여자들이 편안한 환경에서 지식을 공유하고 네트워킹할 수 있는 기회를 제공합니다.

왜 기여해야 하나요? 나에게 무슨 도움이 된다고?

KWG에 기여하는 것은 개인과 기업 모두에게 다양한 이점을 제공합니다. 이 섹션에서는 KWG 기여의 중요성과 그로 인한 혜택을 살펴보겠습니다.

1. 전문성 향상

  • 사례: KWG의 “Legal Subgroup”에 참여한 A씨는 다양한 라이선스 이슈를 다루며 전문성을 크게 향상시켰습니다.
  • 혜택: 최신 오픈소스 트렌드와 기술에 대한 지속적인 학습 기회를 얻을 수 있습니다.

2. 네트워크 확장

  • 사례: B기업의 오픈소스 담당자는 KWG 활동을 통해 타 기업의 전문가들과 협력 관계를 구축했습니다.
  • 혜택: 업계 리더들과의 교류를 통해 귀중한 인사이트와 협력 기회를 얻을 수 있습니다.

3. 기업 이미지 제고

  • 사례: C기업은 KWG 프로젝트에 적극 기여함으로써 오픈소스 커뮤니티에서 긍정적인 평판을 얻었습니다.
  • 혜택: 기업의 기술력과 오픈소스에 대한 헌신을 공개적으로 보여줄 수 있습니다.

4. 문제 해결 능력 향상

  • 사례: D씨는 KWG 포럼에서 자사의 오픈소스 관리 문제를 공유하고, 다른 회원들의 조언을 통해 해결책을 찾았습니다.
  • 혜택: 다양한 경험을 가진 전문가들의 집단 지성을 활용할 수 있습니다.

5. 산업 표준 형성에 참여

  • 사례: E기업은 KWG를 통해 기업 오픈소스 관리 가이드라인 제정에 참여했습니다.
  • 혜택: 산업 표준과 정책 형성 과정에 직접 참여하여 영향력을 행사할 수 있습니다.

6. 개인 브랜딩

  • 사례: F씨는 KWG에서의 활발한 활동을 통해 오픈소스 전문가로 인정받아 다수의 컨퍼런스 발표 기회를 얻었습니다.
  • 혜택: 개인의 전문성과 리더십을 업계에 알릴 수 있는 플랫폼으로 활용할 수 있습니다.

8. 혁신 촉진

  • 사례: H기업은 KWG 활동을 통해 접한 새로운 오픈소스 도구를 도입하여 개발 프로세스를 혁신했습니다.
  • 혜택: 다양한 기업의 혁신 사례를 접하고 자사에 적용할 수 있습니다.

KWG에 기여하는 것은 단순히 지식을 공유하는 것 이상의 의미를 갖습니다. 이는 개인의 성장, 기업의 발전, 그리고 한국 오픈소스 생태계 전체의 향상에 기여하는 중요한 활동입니다. KWG 활동을 통해 얻은 지식, 네트워크, 경험은 참여자 개인과 소속 기업에게 장기적이고 지속적인 가치를 제공할 것입니다.

이러한 다양한 참여 및 기여 방법을 통해 KWG 회원들은 한국의 오픈소스 생태계 발전에 적극적으로 기여할 수 있습니다. 각자의 전문성과 관심사에 맞는 방법을 선택하여 참여함으로써, KWG는 더욱 풍부하고 다양한 지식과 경험을 공유하는 커뮤니티로 성장할 수 있습니다.

6. OpenChain KWG의 Subgroup 활동

OpenChain Korea Work Group(KWG)은 다양한 Subgroup을 통해 특정 분야에 대한 심도 있는 논의와 협력을 진행하고 있습니다. 이러한 Subgroup 활동은 KWG의 핵심적인 요소로, 오픈소스 관리의 다양한 측면을 다루고 있습니다.

현재 운영 중인 Subgroup

  1. Tooling & Legal Subgroup
  2. Conformance Subgroup

Tooling & Legal Subgroup

2024년 8월, 기존의 Tooling Subgroup과 Legal Subgroup이 통합되어 Tooling & Legal Subgroup이 출범했습니다. 이 통합은 오픈소스 관리 도구와 법적 이슈를 함께 다룸으로써 더욱 효과적인 오픈소스 컴플라이언스를 달성하기 위한 목적으로 이루어졌습니다.

주요 활동:

  1. 오픈소스 컴플라이언스 도구 평가 및 비교
    • 다양한 오픈소스 스캔 도구의 성능 및 기능 비교
    • 새로운 오픈소스 관리 도구의 소개 및 평가
  2. 법적 이슈 분석 및 대응 방안 논의
    • 최신 오픈소스 라이선스 동향 분석
    • 라이선스 충돌 문제에 대한 해결 방안 모색
  3. 도구와 법적 요구사항의 연계
    • 컴플라이언스 도구의 법적 요구사항 충족 여부 검토
    • 법적 리스크를 최소화하기 위한 도구 사용 가이드라인 개발
  4. 베스트 프랙티스 개발 및 공유
    • 효과적인 오픈소스 관리를 위한 프로세스 및 워크플로우 설계
    • 회원사의 성공 사례 및 실패 사례 분석
  5. 교육 및 워크샵 진행
    • 오픈소스 도구 사용법 및 법적 이슈에 대한 정기 교육 세션 개최
    • 실무자를 위한 핸즈온 워크샵 진행

Conformance Subgroup

Conformance Subgroup은 OpenChain 표준 준수를 위한 활동을 중점적으로 진행합니다.

OpenChain Project는 기업이 ISO/IEC 5230을 충족하는지 자체적으로 확인할 수 있도록 온라인 자체 인증 방법을 제공합니다.

기업은 자체 인증을 통해 부족한 부분이 무엇인지, 추가로 필요한 활동이 무엇인지 판단할 수 있습니다. 만약, 오픈소스 컴플라이언스 체계가 잘 구축된 기업이 ISO/IEC 5230 자체 인증 질문지의 모든 항목을 Yes로 대답할 수 있다면 이 결과를 웹사이트상에 제출할 수 있습니다(Conforming Submission). 그러면 ISO/IEC 5230 준수(Conformant) 기업으로 인정됨과 동시에, OpenChain 프로젝트의 웹사이트에서 ISO/IEC 5230 준수 프로그램을 갖춘 기업 목록에 기업의 로고를 등록할 수 있게 됩니다.

Conformance Group은 기업이 이러한 ISO/IEC 5230 Conformant 프로그램을 구축하기 위해 수행해야 하는 활동 및 Best Practice를 연구하고 공유하기 위한 그룹입니다.

Subgroup 참여 방법

각 Subgroup은 특정 분야에 관심 있는 KWG 회원 누구나 참여할 수 있습니다. 참여 방법은 다음과 같습니다:

  1. KWG 웹사이트(https://openchain-project.github.io/OpenChain-KWG/subgroup/)에서 Subgroup 정보 확인
  2. 관심 있는 Subgroup의 메일링 리스트에 가입
  3. Subgroup 리더에게 이메일로 참여 의사 전달
  4. 첫 미팅 참석 및 자기소개

Subgroup 활동을 통해 회원들은 자신의 전문 분야에서 더욱 깊이 있는 지식을 공유하고, 산업 전반의 오픈소스 관리 수준을 높이는 데 기여할 수 있습니다. KWG는 앞으로도 필요에 따라 새로운 Subgroup을 만들거나 기존 그룹을 조정하여, 변화하는 오픈소스 생태계에 효과적으로 대응해 나갈 것입니다.

7. OpenChain KWG 운영위원회 소개

OpenChain Korea Work Group(KWG)의 운영위원회(Steering Committee)는 KWG의 핵심 운영 조직으로, 그룹의 전반적인 방향성과 활동을 이끌어가는 중요한 역할을 담당합니다.

운영위원회의 목적

운영위원회는 다음과 같은 주요 목적을 가지고 활동합니다:

  1. OpenChain KWG의 정책 수립 및 Charter 작성
  2. 정기 미팅 운영 및 관리
  3. 주요 의사 결정 수행
  4. 예산 집행 및 투명한 관리

운영위원회의 주요 역할

  1. 거버넌스 체계 구축:
    • KWG의 장기적인 비전과 전략 수립
    • 운영 규정 및 지침 개발
    • 회원사 간 협력 프레임워크 구축
  2. 정기 미팅 운영:
    • 분기별 정기 미팅 일정 및 의제 결정
    • 발표자 섭외 및 프로그램 구성
    • 미팅 결과 정리 및 공유
  3. 의사 결정:
    • KWG의 주요 활동 방향 결정
    • 새로운 프로젝트 또는 이니셔티브 승인
    • 회원사 간 이견 조정
  4. 예산 관리:
    • 연간 예산 계획 수립
    • 예산 집행 승인 및 모니터링
    • 재무 보고서 작성 및 공개
  5. 대외 협력:
    • 글로벌 OpenChain 프로젝트와의 연락 및 협력
    • 타 국가 OpenChain 워크그룹과의 교류
    • 국내 오픈소스 커뮤니티와의 협력 관계 구축

현재 운영위원회 멤버 (2024년 기준)

  • 장학성, SK텔레콤 (Lead)
  • 황은경, 카카오
  • 이서연, 라인플러스
  • 김소임, LG전자
  • 한지호, NCSOFT
  • 정윤환, 삼성전자
  • 안다래, 삼성전자

각 멤버는 자사의 오픈소스 전략과 KWG의 목표를 연계하여 그룹의 발전에 기여하고 있습니다.

운영위원회의 활동 방식

  1. 정기 회의:
    • 분기 1회 정기 화상 회의 진행
    • 주요 안건 논의 및 의사 결정
  2. 연간 계획 수립:
    • 매년 말 차년도 KWG 활동 계획 수립
    • 주요 목표 및 이니셔티브 설정

운영위원회 임기 및 선발 절차

운영위원회 임기와 선발 절차는 Charter에 따라 아래와 같습니다.

  1. 임기:
    • 운영위원회 위원의 임기는 2년입니다.
    • 연임이나 재선출이 가능합니다.
  2. 선발 절차:
    • 운영위원회 위원은 KWG의 정회원 중에서 선출됩니다.
    • 선출 과정은 매년 정기 총회에서 진행됩니다.
    • 후보 추천 또는 자원을 통해 후보자를 모집합니다.
    • 회원들의 투표를 통해 최종 선출됩니다.
  3. 운영위원회 리더 선출:
    • 운영위원회 리더는 선출된 운영위원 중에서 호선으로 선출됩니다.
    • 리더의 임기도 1년이며, 연임이 가능합니다.
  4. 임기 시작:
    • 새로운 운영위원회의 임기는 선출 후 다음 달 1일부터 시작됩니다.
  5. 중도 사퇴 시 대책:
    • 운영위원이 중도 사퇴할 경우, 남은 임기 동안 대행할 위원을 운영위원회에서 선출할 수 있습니다.
  6. 역할 및 책임:
    • 운영위원회 리더는 Group을 대표하여 대외 커뮤니케이션을 담당합니다.
    • 모든 활동을 투명하게 공개하고, 정기적으로 회원들에게 보고해야 합니다.

이러한 임기와 선발 절차는 KWG의 지속적이고 안정적인 운영을 보장하며, 다양한 회원들이 리더십 역할을 수행할 기회를 제공합니다. 또한 정기적인 선출 과정을 통해 그룹의 민주성과 투명성을 유지할 수 있습니다.

운영위원회 연락 방법

운영위원회에 문의나 제안이 있는 경우, 공식 이메일 주소로 연락할 수 있습니다. 운영위원회는 모든 회원사의 의견을 소중히 여기며, 접수된 의견은 정기 회의에서 논의됩니다.

OpenChain KWG 운영위원회는 한국 기업들의 오픈소스 관리 역량 강화와 건강한 오픈소스 생태계 조성을 위해 지속적으로 노력하고 있습니다. 회원사들의 적극적인 참여와 협력을 통해 KWG는 앞으로도 한국의 오픈소스 문화를 선도해 나갈 것입니다.

8. OpenChain 표준 소개

OpenChain 프로젝트는 오픈소스 소프트웨어의 효과적인 관리와 컴플라이언스를 위한 국제 표준을 제공합니다. 이 장에서는 두 가지 주요 OpenChain 표준에 대해 살펴보겠습니다.

ISO/IEC 5230 (오픈소스 컴플라이언스) 개요

ISO/IEC 5230은 오픈소스 라이선스 컴플라이언스를 위한 국제 표준입니다.

주요 특징:

  • 2020년 12월에 공식 ISO 표준으로 채택되었습니다.
  • 기업 규모나 산업에 관계없이 적용 가능한 유연한 표준입니다.
  • 오픈소스 컴플라이언스 프로그램의 핵심 요구사항을 정의합니다.

핵심 요구사항:

  1. 프로그램 기반: 오픈소스 정책과 책임을 명확히 정의
  2. 관련 업무 정의 및 지원: 오픈소스 프로그램 운영을 위한 충분한 리소스 제공
  3. 오픈소스 콘텐츠 검토 및 승인: 사용된 오픈소스 컴포넌트의 BOM(Bill of Materials) 관리
  4. 컴플라이언스 산출물 생성 및 전달: 라이선스 의무사항 준수
  5. 오픈소스 커뮤니티 참여 이해: 오픈소스 프로젝트 기여 정책 문서화
  6. 규격 요구사항 준수: OpenChain 표준의 모든 요구사항 충족

ISO/IEC 18974 (오픈소스 보안) 소개

ISO/IEC 18974는 오픈소스 소프트웨어의 보안 취약점 관리를 위한 표준입니다.

주요 특징:

  • OpenChain Security Assurance Specification 1.1을 기반으로 합니다.
  • 2023년 중반 정식 ISO 표준으로 채택될 예정입니다.
  • 오픈소스 보안 취약점 관리 프로세스의 핵심 요구사항을 정의합니다.

주요 내용:

  1. 보안 프로세스가 필요한 핵심 영역 식별
  2. 역할과 책임 할당 방법
  3. 프로세스의 지속가능성 보장 방법
  4. CVE, GitHub 종속성 경고, 패키지 관리자 경고 등 알려진 보안 취약점 확인 방법

표준 준수의 중요성과 방법

표준 준수의 중요성:

  1. 신뢰성 향상: 오픈소스 관리에 대한 신뢰를 구축합니다.
  2. 리스크 관리: 법적, 보안적 리스크를 효과적으로 관리할 수 있습니다.
  3. 효율성 증대: 표준화된 프로세스로 오픈소스 관리 효율성이 향상됩니다.
  4. 글로벌 경쟁력: 국제 표준 준수로 글로벌 시장에서의 경쟁력이 강화됩니다.

표준 준수 방법:

  1. 자체 인증: OpenChain 프로젝트에서 제공하는 자체 인증 도구를 활용합니다.
  2. 독립 평가: OpenChain 공인 파트너를 통해 독립적인 평가를 받습니다.
  3. 제3자 인증: 공인된 인증 기관을 통해 공식 인증을 획득합니다.

표준 준수를 위한 자세한 방법은 다음의 발표 자료와 영상을 참고하실 수 있습니다.

준수를 위한 단계:

  1. 현재 상태 평가: 기존 오픈소스 관리 프로세스를 표준과 비교 평가합니다.
  2. 갭 분석: 현재 상태와 표준 요구사항 간의 차이를 분석합니다.
  3. 개선 계획 수립: 갭을 해소하기 위한 구체적인 계획을 수립합니다.
  4. 프로세스 구현: 계획에 따라 필요한 프로세스와 도구를 구현합니다.
  5. 교육 및 인식 제고: 관련 직원들에게 새로운 프로세스에 대한 교육을 제공합니다.
  6. 모니터링 및 개선: 지속적으로 프로세스를 모니터링하고 개선합니다.

이를 위한 자세한 방법은 기업 오픈소스 관리 가이드를 참고할 수 있습니다.

OpenChain 표준을 준수함으로써, 기업은 오픈소스 소프트웨어를 더욱 효과적이고 안전하게 관리할 수 있으며, 이는 궁극적으로 기업의 혁신과 성장에 기여할 것입니다.

9. 마치며

OpenChain Korea Work Group(KWG)의 웰컴 패키지는 신규 멤버들이 오픈소스 관리의 복잡한 세계에 성공적으로 진입하고, KWG 커뮤니티의 일원으로서 적극적으로 기여할 수 있도록 돕기 위해 설계되었습니다. 이 패키지는 오픈소스의 기본 개념부터 KWG의 활동, 참여 방법, 그리고 다양한 리소스와 학습 자료에 이르기까지 포괄적인 정보를 제공하여, 멤버들이 자신감을 가지고 오픈소스 컴플라이언스와 관련된 업무를 수행할 수 있도록 지원합니다. KWG의 일원이 되어 한국의 오픈소스 생태계 발전에 함께 기여하는 여정을 시작해 보시기 바랍니다. 여러분의 참여와 기여가 KWG의 성장과 발전에 큰 힘이 될 것입니다.

2 - ISO 표준 기반 기업 오픈소스 관리 가이드

ISO 국제 표준에 기반하여 기업이 오픈소스를 효과적으로 관리하기 위한 방안을 소개합니다.

기업이 오픈소스를 관리하지 않으면 라이선스 컴플라이언스, 보안 등 리스크에 노출될 수 있습니다. 그럼 무엇을 어떻게 관리해야 할까요?

여기에서는 ISO 국제표준에 근거하여 기업이 오픈소스 관리를 위해 수행해야 할 최소한의 핵심 요구 사항과 그 방법을 알아봅니다.

Author : 장학성 (haksung@sktelecom.com)

오픈소스 관리 국제표준

오픈소스 관리를 위한 국제 표준은 아래 두가지가 있습니다.

  1. ISO/IEC 5230 : OpenChain Specification - 오픈소스 컴플라이언스를 위한 국제표준
  2. ISO/IEC 18974 : OpenChain Security Assurance Specification - 오픈소스 보안을 위한 국제 표준

OpenChain과 ISO/IEC 5230

ISO/IEC 5230은 오픈소스 컴플라이언스를 위한 유일한 국제표준입니다. 이에 대한 소개는 다음 페이지를 참고하세요. : OpenChain 살펴보기

기업은 무엇을 해야 할까요?

두 표준 (ISO/IEC 5230, ISO/IEC 18974)의 요구사항을 준수한다면 기업은 오픈소스 관리를 효과적으로 하고 있다고 볼 수 있습니다.

그럼 기업은 표준을 준수하기 위해 무엇을 해야 할까요? 다음과 같이 6가지 구성 요소를 갖추면 됩니다.

이 가이드에서는 각 구성 요소를 기업이 어떻게 갖춰나갈 수 있는지에 대해 상세히 설명합니다.

References

이 가이드는 다음 자료를 참고하여 작성하였습니다.

  1. OpenChain Project Website
  2. OpenChain ISO/IEC 5230
  3. OpenChain ISO/IEC 18974
  4. OpenChain Open Source Policy Template
  5. Open Source Compliance In The Enterprise

2.1 - 0. OpenChain 살펴보기

OpenChain Project

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

이러한 복잡한 소프트웨어 공급망의 여러 조직 중 한 곳이라도 오픈소스 라이선스 의무를 준수하지 않거나 올바른 오픈소스 사용 정보를 제공하지 않으면 최종 소프트웨어를 배포하는 기업은 오픈소스 라이선스 의무 준수에 실패할 수밖에 없다. 이로 인해 소송을 제기당해 제품 판매가 중단되는 상황이 발생할 수도 있다.

[OpenChain Open Source Software License Compliance General Public Guide]

2009년 12월, Busybox라는 오픈소스 관련된 소송이 있었다. Busybox는 임베디드 시스템에 광범위하게 사용되고 있는 GPL-2.0 라이선스가 적용된 오픈소스인데, 국내 회사 두 곳을 포함하여 14개 회사가 소송 대상이 되었다. 이 사례에서 주목할만한 점은 이 중에는 제품을 직접 개발하지 않고 배포만 한 회사도 소송을 당하였다는 점이다.

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

Linux Foundation의 OpenChain 프로젝트는 기업이 오픈소스 컴플라이언스를 위해 준수해야 할 핵심 사항을 간결하고 일관성 있게 정의하고, 이를 모두가 준수한다면 소프트웨어 공급망 전체에 걸쳐 오픈소스 라이선스 측면의 신뢰를 구축할 수 있다는 믿음으로 설립되었다.

[OpenChain Project Logo]

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

OpenChain 프로젝트는 기업들이 오픈소스 컴플라이언스를 더욱 쉽게 달성 할 수 있도록 크게 다음 세 가지를 제공한다.

  1. OpenChain 규격1
  2. OpenChain 적합성 인증2
  3. 문서 자료3

기업이 어떻게 이들을 활용할 수 있을지 하나씩 알아보자.

OpenChain 규격과 ISO/IEC 5230

OpenChain 규격은 오픈소스 컴플라이언스를 위한 핵심 요구사항을 정의한 10페이지 분량의 문서이다. 2016년 OpenChain 규격 버전 1.0이 발표되었다. OpenChain 규격은 기업의 규모나 업종과 관계없이 모든 기업에 적합하도록 설계되었다.

2020년에는 버전 2.1의 규격이 배포됐으며, 기업이 오픈소스 컴플라이언스 달성을 위해 꼭 수행해야 할 여섯 가지 핵심 요구사항과 이를 입증하기 위해 필요한 자료 목록을 정의하고 있다.

  1. 프로그램 설립
  2. 관련 업무 정의 및 지원
  3. 오픈소스 콘텐츠 검토 및 승인
  4. 컴플라이언스 산출물 생성 및 전달
  5. 오픈소스 커뮤니티 참여에 대한 이해
  6. 규격 요구사항 준수

오픈소스 컴플라이언스를 처음 시작하는 기업이라면 이러한 OpenChain 규격의 요구사항을 하나씩 충족해가면서 수준을 향상시키는 것이 좋은 전략이다.

< 출처 : https://github.com/OpenChain-Project/Specification/blob/master/Official/en/2.1/openchainspec-2.1.pdf>

이 OpenChain 규격은 2020년 12월 오픈소스 컴플라이언스에 대한 국제 표준4으로 정식 등록되었다.

< 출처 : https://www.iso.org/standard/81039.html>

지난 4년간 사실상의 표준이었던 OpenChain 규격이 ISO/IEC 5230:2020이라는 정식 국체 표준으로 전환되었고, 이는 오픈소스 컴플라이언스 및 프로세스 관리를 정의한 최초의 국제 표준이다. 이로써 글로벌 IT기업의 ISO/IEC 5230 준수에 관한 관심이 높아지고 있고, 소프트웨어 공급망에서 공급자들에게 ISO/IEC 5230 준수를 요구하는 기업이 늘어날 것으로 예상된다.

ISO/IEC 5230 인증 방법

ISO/IEC 5230에서의 요구 사항을 모두 준수한다면 ISO/IEC 5230에 적합한 오픈소스 프로그램을 보유했음을 인증받을 수 있다. 오픈소스 프로그램이란 정책, 프로세스, 인원 등 기업이 오픈소스 컴플라이언스 활동을 수행하기 위한 일련의 관리 체계를 의미한다.

아래의 이미지는 ISO/IEC 5230이 요구하는 항목 번호를 나열한 그림이다. 이 항목을 모두 충족하는 기업은 소프트웨어 공급망에서 투명하고 신뢰할 수 있는 오픈소스 거버넌스 체계를 구축하였다고 인정받을 수 있다.

OpenChain 프로젝트에서 제안하는 인증 방법은 세 가지 이다.

  • 자체 인증
  • 독립 평가
  • 타사 인증

https://www.openchainproject.org/get-started/conformance >

각각의 방법을 알아보자.

1. 자체 인증 (Self Certification)

자체 인증은 OpenChain 프로젝트에서 제일 권장하는 방법이며, 비용이 발생하지 않는다는 장점이 있다. OpenChain Project는 기업이 OpenChain 규격을 준수하는지 자체적으로 확인할 수 있도록 OpenChain 자체 인증 웹사이트를 제공한다2. 기업의 오픈소스 담당자는 OpenChain 자체 인증 웹사이트에 가입해 온라인 자체 인증을 시작할 수 있다. 자체 인증은 아래와 같이 Yes/No 질문에 답변하는 방식으로 진행된다.

< 출처 : https://certification.openchainproject.org/>

오픈소스 컴플라이언스 체계를 잘 구축하여 OpenChain 자체 인증의 모든 질문에 Yes로 대답할 수 있다면 이 결과를 웹사이트상에 제출할 수 있다Conforming Submission. 그러면 Linux Foundation의 간단한 문답식의 확인 절차를 거친 후 ISO/IEC 5230 인증을 선언을 할 수 있게 된다.

<예: SK텔레콤 인증 선언 - 출처: https://www.openchainproject.org/featured/2021/09/08/sk-telecom>

이렇게 인증 선언을 하게 되면, Global Software Supply Chain에서 ISO/IEC 5230을 준수하는 오픈소스 프로그램을 가진 기업으로 인정 받게 된다.

< ISO/IEC 5230 적합 프로그램 보유 선언 기업, 출처 - https://www.openchainproject.org/ >

OpenChain 프로젝트는 자체 인증 방식을 권장한다. 참고로, OpenChain 적합성을 선언한 대부분의 기업도 자체 인증 방식을 채택하였다.

또한, 기업은 자체 인증 과정을 통해 부족한 부분이 무엇인지, 추가로 필요한 활동이 무엇인지 판단할 수 있다. 이 가이드에서는 조직, 정책, 프로세스 등 주요 구성 요소 별로 ISO/IEC 5230 요구 사항을 준수할 수 있는 방법을 설명한다.

가이드만으로 자체적으로 보완할 수 있는 역량이 부족한 기업인 경우 독립 평가 방법을 고려할 수 있다.

2. 독립 평가 (Independent Assessment)

독립 평가는 기업 외부의 독립 기관이 공정한 관점에서 기업의 오픈소스 컴플라이언스 상태를 점검하고 평가한다. 독립 평가의 특징은 평가 보고서를 생성하는 것에 그치지 않고 도출된 미비점을 보완하기 위한 컨설팅을 제공한다. (단, 공인 인증서를 발급하지는 않는다.)

기업은 독립 기관으로부터의 공정한 평가와 컨설팅을 받아 컴플라이언스 수준을 높이고, 다시 독립 평가를 수행하는 반복적인 과정을 통해 정책을 세분화하고 프로세스를 구축할 수 있다.

< Independent Compliance Assessment, 출처 - https://youtu.be/DEBd-g0Ab8E >

결국 기업은 ISO/IEC 5230 인증을 받을 수 있는 수준에 도달하게 되고, 그때 자체 인증, 혹은 타사 인증을 획득하는 절차에 돌입할 수 있다. 독립 평가는 이렇게 기업의 오픈소스 컴플라이언스 수준을 높이기 위한 평가와 컨설팅을 제공하여서 기업이 ISO/IEC 5230 적합 프로그램을 보유하고 인증을 획득할 수 있게 지원한다.

독립 평가를 제공하는 업체는 AlektoMetis5, Source Code Control6 등이 있다.

국내에서는 OpenChain Korea Work Group의 Subgroup인 Conformance Group7에서 기업간에 자체적으로 ISO/IEC 5230 준수를 위한 방법을 논의하고 공유하는 커뮤니티가 있다. OpenChain Korea Work Group 멤버라면 누구나 참여하여 도움을 받을 수 있다.

3. 타사 인증 (Third-Party Certification)

소프트웨어 공급망에서 구매자에게 보다 신뢰성 있고 투명한 오픈소스 컴플라이언스 수준을 나타내고자 한다면 타사 인증 기관으로부터 인증서를 발급받고 이를 홍보에 활용할 수 있다. 또한, 오픈소스 컴플라이언스의 보다 견고한 신뢰성을 요구하는 일부 구매자는 공급자Supplier에게 타사 인증을 의무화 할 수도 있을 것으로 예상된다.

2021년 10월 기준, OpenChain의 공인 타사 인증 기관은 ORCRO8, PWC9, TÜV SÜD10, Synopsys11, Bureau Veritas12이다.

< Third-Party Certifiers, 출처 - https://www.openchainproject.org/partners >

이들은 ISO/IEC 5230 적합 프로그램 확인을 위한 평가를 제공하고 통과한 기업에 인증서를 발급한다.

< PWC certification, 출처 - https://youtu.be/HslvXCM-4pQ >

2021년 10월 현재, 아직은 타사 인증을 의무적으로 요구하는 구매자나 기관은 없어 보인다. 하지만 유럽의 자동차 업계에서는 ISO/IEC 5230이 ASPICEAutomotive SPICE13 자동차 소프트웨어 개발을 위한 국제 표준 프로세스 모델)와 같이 자동차 소프트웨어 공급자에게 의무화될 날이 머지않을 것이라고 예견하는 전문가도 있다.

또한, 자세한 자체 인증 방법은 다음 슬라이드를 참고할 수 있다.

OpenChain Resources

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

< OpenChain Curriculum, 출처 - https://www.openchainproject.org/resources >

이 가이드의 많은 내용도 OpenChain에서 공개한 자료를 기반으로 작성하였다. 각 기업의 오픈소스 담당자는 정책, 프로세스, 교육자료가 필요하다면 OpenChain Resources를 먼저 찾아보기 바란다. 또한 이 자료는 한국어로도 번역되어 공개되고 있다. OpenChain Korea Work Group14에서 이러한 번역 작업을 주도하고 있다. 한국어 번역은 관심 있는 누구나 참여할 수 있다15.

ISO/IEC 5230 추세

2021년 초, 독일의 자동차 제조사가 부품 Supplier에게 ISO/IEC 5230 준수 계획을 요구하기 시작했다는 소식이 들렸고, 유럽의 한 오픈소스 분야 교수는 “앞으로 소프트웨어 공급망의 Buyer는 Supplier에게 ISO/IEC 5230 준수를 요구할 것은 명백하다"며, “자동차 업계로 보면 A-SPICE처럼 될 것이다"라고 말했다.

이를 반영하듯 2021년 5월, 폭스바겐 그룹의 Scania는 Supplier가 따라야 하는 자체 기업 표준(STD 4589)에 ISO/IEC 5230 준수를 요구하는 내용을 포함시켰다.

linkedin, May 2021

또한, 2021년 7월, 자동차 및 산업 기술 기업인 Boash는 연말까지 모든 그룹사가 ISO/IEC 5230을 준수하는 프로그램을 갖추겠다고 선언하였다. 업계에서는 모든 자동차 제조사나 다른 산업에서도 소프트웨어 공급망 내에서 ISO/IEC 5230을 요구하기 시작하는건 시간 문제라는 전망도 내놓고 있다.

linkedin, July 2021

  1. OpenChain 규격 - https://www.openchainproject.org/get-started/conformance ↩︎

  2. OpenChain 자체 인증 웹사이트 - https://certification.openchainproject.org/ ↩︎ ↩︎

  3. OpenChain 문서 자료 - https://www.openchainproject.org/resources ↩︎

  4. ISO/IEC 5230 : https://www.iso.org/standard/81039.html ↩︎

  5. AlektoMetis - https://alektometis.com/, ↩︎

  6. Source Code Control - https://sourcecodecontrol.co/ ↩︎

  7. Conformance Group - https://openchain-project.github.io/OpenChain-KWG/subgroup/conformance/ ↩︎

  8. ORCRO- https://orcro.co.uk/ ↩︎

  9. PWC - https://www.pwc.de/en/opensource ↩︎

  10. TÜV SÜD - https://www.tuvsud.com ↩︎

  11. Synopsys - https://www.synopsys.com/ ↩︎

  12. Bureau Veritas - https://group.bureauveritas.com/ ↩︎

  13. ASPICE : 자동차 소프트웨어 개발을 위한 국제 표준 프로세스 모델 - http://www.automotivespice.com ↩︎

  14. OpenChain Korea Work Group - https://openchain-project.github.io/OpenChain-KWG/ ↩︎

  15. 한국어 번역 작업 - https://openchain-project.github.io/OpenChain-KWG/resource/ ↩︎

2.2 - 1. 조직

먼저, 기업은 오픈소스 관리 업무를 담당할 조직을 구성해야 합니다.

조직 구성 시 고려해야 할 내용은 다음과 같습니다:

  • 조직의 역할과 책임
  • 각 역할의 필요 역량
  • 각 역할을 담당할 조직/담당자

1. 조직의 역할과 책임 정의

ISO 표준은 공통적으로 다음과 같이 프로그램 내 여러 참여자의 역할과 책임을 기술한 문서를 요구합니다.

오픈소스 프로그램 매니저

오픈소스 관리 체계를 구축하기 위해서는 먼저 이를 책임지고 수행할 책임자가 필요합니다. 책임자는 오픈소스 프로그램 매니저 또는 오픈소스 컴플라이언스 담당자 등의 명칭으로 불리며, 여기서는 오픈소스 프로그램 매니저라는 용어를 사용합니다.

오픈소스 프로그램 매니저는 기업의 오픈소스 프로그램 오피스를 담당합니다. 오픈소스 프로그램 오피스란 기업의 오픈소스 관리를 위한 조직을 의미하며, 오픈소스 사무국이라는 용어로도 사용됩니다.

아래의 역량을 가지고 있다면 오픈소스 프로그램 매니저 역할에 적합하다고 할 수 있습니다.

  • 오픈소스 생태계에 대한 이해 및 개발 경험
  • 기업의 비즈니스에 대한 폭넓은 이해
  • 기업 구성원에게 효과적인 오픈소스 활용을 전파할 수 있는 열정과 커뮤니케이션 능력

오픈소스 프로그램 매니저는 가능한 풀타임으로 역할을 수행할 수 있도록 보장되는 것이 좋습니다.

글로벌 ICT 기업은 이와 같은 우수한 오픈소스 프로그램 매니저를 채용하기 위해 노력하고 있습니다. 다음 사이트에서 다양한 채용 공고를 확인할 수 있습니다. : https://github.com/todogroup/job-descriptions

역할과 책임 문서화

기업은 오픈소스 프로그램 오피스에 필요한 각 역할을 정의하고, 어떠한 책임을 부여해야 하는지를 판단해야 합니다.

소규모 기업의 경우, 오픈소스 프로그램 매니저 혼자서 모든 역할을 수행하는 것도 가능합니다. 기업의 규모에 따라 오픈소스 도구를 운영하는 IT 담당자도 필요할 수 있으며, 전문적인 법무 자문을 제공하기 위한 법무 담당의 역할이 요구될 수도 있습니다.

일반적으로 기업의 오픈소스 관리 체계 구축을 위해서는 아래의 역할이 필요합니다.

  • 법무 담당
  • IT 담당
  • 보안 담당
  • 개발 문화 담당

Individuals and teams involved in ensuring open source compliance : https://www.linuxfoundation.org/wp-content/uploads/OpenSourceComplianceHandbook_2018_2ndEdition_DigitalEdition.pdf

이를 위해 아래와 같이 오픈소스 프로그램 오피스를 구성하는 역할과 책임을 문서화해야 합니다.

No역할책임
1Open Source Program Manager회사의 오픈소스 프로그램에 대한 총괄 책임을 담당한다.
2법무 담당오픈소스 라이선스와 의무를 해석한다. 이러한 의무를 실제 이행하는 등 오픈소스 활용을 위해 발생할 수 있는 법적 위험의 완화를 위한 자문을 제공한다.
3IT 담당오픈소스 분석 도구를 운영하고 자동화하여 모든 배포용 소프트웨어에 대해 오픈소스 분석이 원활히 수행되도록 시스템을 구축한다.
4보안 담당오픈소스 보안취약점 분석 도구를 운영하여 모든 배포용 소프트웨어에 대해 보안취약점 분석이 수행되도록 시스템을 구축하고 발견된 보안취약점이 기준에 맞게 보완되도록 조치한다.
5개발 문화 담당사내 개발자들이 오픈소스를 적극적으로 활용하고 사내외 커뮤니티에 참여하여 선진 개발 문화를 습득할 수 있도록 지원한다.
6사업 부서소프트웨어 개발/배포 조직은 올바른 오픈소스 활용을 위해 오픈소스 정책 및 프로세스를 준수한다.

2. 필요 역량 정의

각 역할과 그에 대한 책임을 정의하였다면, 그 역할을 수행할 인원이 갖춰야 할 필수 역량이 무엇인지 파악해야 합니다.

ISO 표준은 공통적으로 다음과 같이 각 역할을 위해 필요한 역량을 기술한 문서를 요구합니다.

이를 통해 역할별 담당자가 해당 역할을 수행할 수 있는 역량을 갖추었는지 평가하고, 필요시 교육을 제공해야 하기 때문입니다.

이를 위해 기업은 아래와 같이 각 역할을 위해 필요한 역량을 기술하여 문서화해야 합니다.

No역할필요 역량
1Open Source Program Manager1. 소프트웨어 개발 프로세스 이해
2. 저작권, 특허 등 오픈소스 라이선스와 관련한 지식재산 이해
3. 오픈소스 컴플라이언스에 대한 전문 지식
4. 오픈소스 개발 경험
5. 커뮤니케이션 스킬
2법무 담당1. 오픈소스 생태계에 대한 기본 지식
2. 소프트웨어 저작권에 대한 전문 지식
3. 오픈소스 라이선스에 대한 전문 지식
3IT 담당1. 오픈소스 컴플라이언스 프로세스에 기본 지식
2. 오픈소스 분석 도구에 대한 이해
3. IT 인프라에 대한 전문 지식
4보안 담당1. DevSecOps에 대한 폭넓은 이해
2. 오픈소스 보안취약점 분석 도구에 대한 이해
3. 오픈소스 보안취챡점에 대한 전문 지식
43. 커뮤니케이션 스킬
5개발 문화 담당1. 소프트웨어 개발 프로세스 이해
2. 오픈소스 컴플라이언스에 대한 기본 지식
3. 오픈소스 정책에 대한 이해
6사업 부서1. 소프트웨어 개발 프로세스 이해
2. 오픈소스 컴플라이언스에 대한 기본 지식
3. 오픈소스 정책에 대한 이해
4. 오픈소스 라이선스에 대한 기본 지식

3. 담당자 지정

오픈소스 프로그램 매니저는 관련 부서와 협의하여 각 역할을 위한 담당자를 지정하고 이를 문서화합니다. 물론 이를 위해서는 CEO 등 최고 의사결정권자에게 오픈소스 컴플라언스 체계 구축을 위한 목표와 방향을 보고하여 필요한 지원을 받아야 할 것입니다.

오픈소스 관련 조직과 담당자는 반드시 풀타임으로 오픈소스 업무에 참여할 필요는 없습니다. OSRB (Open Source Review Board) 형태의 가상 조직을 구성하여 필요한 역할을 수행하는 것도 가능합니다.

이를 위해 ISO 표준은 공통적으로 다음과 같이 프로그램 내 각 역할을 담당하는 인원, 그룹 또는 직무의 이름을 기재한 문서를 요구합니다.

이를 위해 기업은 아래와 같이 프로그램 내 각 역할을 담당하는 인원, 그룹 또는 직무의 이름을 문서화해야 합니다.

No역할담당 조직담당자
1Open Source Program ManagerCTOOOO
2법무 담당법무팀OOO
3IT 담당IT 인프라팀OOO
4보안 담당보안팀OOO
5개발 문화 담당DROOO
6사업 부서개발팀전원

다음 페이지에서는 역할, 책임, 필요 역량 및 담당자 지정 등을 문서화한 샘플을 참고할 수 있습니다. [부록1]오픈소스 정책(샘플) - Appendix 1. 담당자 현황

SK텔레콤은 OSRB를 구성하여 기업 내 오픈소스 정책과 프로세스를 만들고, 이슈 발생 시 협업하여 대응 방안을 마련하고 있습니다.

https://sktelecom.github.io/about/osrb/

Summary

역할, 책임, 필요 역량 및 담당자 지정을 문서화한 샘플은 오픈소스 정책 템플릿 문서에서 확인할 수 있습니다. : Appendix 1. 담당자 현황

기업은 이를 참고하여 기업의 상황에 맞게 오픈소스 관리 조직을 구성할 수 있습니다.

이렇게 오픈소스 프로그램 오피스 조직을 지정하고 문서화하면, ISO 표준 규격 중 아래의 붉은색으로 표시된 요구사항을 충족하게 됩니다.

사실, 문서화하는 것보다 실제 업무를 충실히 수행할 담당자를 지정하고, 담당자가 역량을 확보할 수 있도록 지원하는 것이 더 중요합니다.

한국저작권위원회의 오픈소스 라이선스 전문 교육이나 NIPA의 공개소프트웨어 매니지먼트 아카데미에 참여하여 체계적인 교육을 수강하는 것도 매우 도움이 됩니다.

2.3 - 2. 정책

1. 오픈소스 정책 문서화

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

이를 위해 ISO 표준은 공통적으로 다음과 같이 문서화된 오픈소스 (보안 보증) 정책을 요구합니다.

일반적인 오픈소스 정책은 다음을 포함합니다. 기업은 이러한 원칙을 포함한 오픈소스 정책을 만들어서 문서화해야 합니다.

  • 소프트웨어 제품과 서비스 배포할때 라이선스 및 보안 취약점 리스크를 최소화하기 위한 원칙
  • 외부 오픈소스 커뮤니티에 기여하기 위한 원칙
  • 기업의 소프트웨어를 오픈소스로 공개하기 위한 원칙

2. 오픈소스 정책에서 다뤄야할 내용

오픈소스 정책이 어떤 내용을 포함해야 하는지 보다 자세히 알아보겠습니다.

오픈소스 리스크 대응

오픈소스를 사용하여 제품/서비스를 개발 시 발생할 수 있는 라이선스 및 보안취약점 리스크를 최소화하기 위해 다음과 같은 원칙을 포함해야 합니다.

  1. 오픈소스 식별 및 라이선스 의무 사항 검토
  2. 오픈소스 라이선스 고려 설계
  3. 오픈소스 컴플라이언스 산출물 생성
  4. SBOM (Software Bill of Materials) 생성
  5. 오픈소스 라이선스 컴플라이언스 이슈 대응
  6. 오픈소스 보안 취약점 대응

[부록1] 오픈소스 정책 template의 6. 오픈소스 사용에서 이를 문서화한 원칙을 살펴보실 수 있습니다.


1. 오픈소스 사용

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(4) SBOM (Bill of Materials) 생성

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

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

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

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

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

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

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

내부 책임 할당 절차

오픈소스 정책은 오픈소스 관리 이슈를 해결하기 위한 책임을 내부에 할당하는 절차를 다뤄야 합니다.

ISO 표준은 공통적으로 다음과 같이 내부 책임을 할당하는 문서화된 절차를 요구합니다.

먼저 오픈소스 프로그램 매니저는 컴플라이언스 이슈를 파악하고 이를 해결하기 위해 각 역할의 담당자에게 적절히 책임을 할당해야 합니다. 마찬가지로 오픈소스 보안 취약점 이슈에 대해서는 보안 담당이 이슈를 파악하고 이를 해결하기 위해 적절한 인원에게 책임을 할당합니다.

이를 위해 아래의 예시와 같이 오픈소스 정책에 내부 책임을 할당하는 문서화된 절차를 반영할 수 있습니다.


4. 역할, 책임 및 역량

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

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

- 오픈소스 컴플라이언스를 위해 필요한 역할을 정의하고, 각 역할을 책임질 담당 조직 및 담당자를 지정합니다. 필요 시 OSRB와 협의합니다. 오픈소스 보안 보증을 위한 내부 책임은 보안 담당자가 할당합니다.

(6) 보안 담당

- 오픈소스 보안 보증을 성공할 수 있도록 각 업무에 대한 책임을 할당합니다.

미준수 사례 대응

기업은 컴플라이언스 미준수 사례가 발생히면 이를 신속히 검토하고 대응하기 위한 절차를 문서화해야 합니다.

ISO/IEC 5230은 다음과 같이 미준수 사례를 검토하고 이를 수정하기 위한 문서화된 절차 요구합니다.

이를 위해 기업은 아래의 예시와 같이 오픈소스 정책에 미준수 사례를 검토하고 이를 수정하기 위한 문서화된 절차를 반영할 수 있습니다.


6. 오픈소스 사용

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

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

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

인원, 예산 지원

기업은 오픈소스 프로그램이 원활하게 기능을 수행할 수 있도록 충분한 리소스를 제공해야 합니다. 프로그램 내 각 역할을 담당하는 인원을 적합하게 배치하고, 충분한 예산과 업무 시간을 보장해야 합니다. 그렇지 않을 경우, 이를 보완할 수 있는 절차가 마련되어야 합니다.

ISO 표준은 공통적으로 다음과 같이 프로그램 내 각 역할을 담당하는 인원이 적합하게 배치되고, 예산이 적절하게 지원되어야 함을 요구합니다.

이를 위해 기업은 아래의 예시와 같이 오픈소스 정책에 인원, 예산 지원에 대한 내용을 반영할 수 있습니다.

4. 역할, 책임 및 역량

각 역할에 대한 담당 조직의 장은 조직 내 담당자를 지정하고, 담당자가 역할을 충실하게 수행할 수 있는 적절한 시간과 예산을 할당합니다.

- 각 역할의 담당자는 자신이 역할을 수행하면서 적절한 지원이 되지 않는다면 오픈소스 프로그램 매니저에게 문제를 제기해야 합니다.
- 오픈소스 프로그램 매니저는 해당 조직장과 문제 해결을 논의합니다. 적절하게 해결되지 않는다면, 오픈소스 프로그램 매니저는 OSRB에 문제 해결을 요청할 수 있습니다.
- OSRB는 상위 조직의 장에게 문제를 공유하고 해결을 요청합니다.

전문 자문 제공

기업은 각 역할의 담당자가 오픈소스 이슈를 해결하기 위해 전문적인 검토가 필요할 경우, 이에 대한 자문을 요청할 수 있는 방법을 제공해야 합니다.

ISO 표준은 공통적으로 다음과 같이 문제 해결을 위해 내부 또는 외부의 전문 자문을 이용할 수 있는 방법을 요구합니다.

오픈소스 라이선스 컴플라이언스 이슈에 대해서는 회사 내의 법무팀을 통해 우선 담당하고, 이슈가 첨예한 경우, 오픈소스 전문 변호사를 보유한 외부 법무 법인을 이용할 수 있습니다.

오픈소스 보안 취약점 이슈에 대해서는 회사 내 보안팀에서 우선 담당하고, 이슈가 복잡하고 첨예한 경우, 외부 보안 전문 기술 업체에 자문을 요청할 수 있습니다.

이를 위해 기업은 아래의 예시와 같이 오픈소스 정책에 자문을 제공하기 위한 내용을 반영할 수 있습니다.

4. 역할, 책임 및 역량

(4) 법무 담당

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

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

(6) 보안 담당

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

- 구성원이 보안 취약점에 대한 문의를 할 수 있는 합리적인 방법을 제공하고, 취약점 해결을 위해 필요 시 외부 전문 기술 자문을 이용합니다.

참고로, OpenChain 프로젝트에서는 파트너 프로그램을 통해 오픈소스 관련 자문을 제공하는 글로벌 법무법인 리스트를 제공합니다. : https://www.openchainproject.org/partners

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

적용 범위 지정

하나의 오픈소스 정책(프로그램)을 반드시 전체 조직에 적용해야 하는 것은 아닙니다. 기업 내 각 조직과 제품의 특성에 따라 적용 범위를 달리 지정할 수 있습니다. 예를 들어, 소프트웨어를 전혀 배포하지 않는 조직은 오픈소스 프로그램의 적용 범위에서 제외할 수 있습니다.

ISO 표준은 공통적으로 다음과 같이 프로그램의 적용 범위와 한계를 명확하게 정의한 문서화된 진술 등을 요구합니다.

기업은 조직과 제품의 특성을 고려하여 오픈소스 프로그램의 적용 범위와 한계를 명확히 정의하고, 이를 오픈소스 정책에 명시해야 합니다.

또한, 비즈니스 환경에 맞추어 변화함에 따라 조직 구조, 제품 및 서비스가 프로그램의 적용 범위를 결정하거나 수정해야 하는 상황이 발생할 수 있습니다. 기업은 적용 범위를 평가하기 위한 측정 기준을 수립하고, 지속적인 개선을 위해 검토, 검사를 수행하여 미흡한 부분을 개선해야 합니다.

이를 위해 기업은 아래와 같이 오픈소스 정책에 다음과 같이 적용 범위에 대해 명확히 정의하고, 활동 이력을 문서화하는 체계를 갖춰야 합니다.

2. 적용 범위

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

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

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

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

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

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

따라서 기업은 오픈소스 정책에 다음과 같이 적용 범위를 명확히 정의하고, 활동 이력을 문서화하는 체계를 갖춰야 합니다.

외부 문의 대응

오픈소스를 사용하여 개발한 제품 또는 서비스에 대해 고객 및 오픈소스 저작권자가 기업에 오픈소스 관련 문의, 요청 및 클레임을 제기하기 위해 연락을 취하는 경우가 있습니다. 외부 문의 및 요청의 주된 내용은 다음과 같습니다.

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

기업은 이러한 외부 문의를 처리할 담당자를 지정해야 합니다. 일반적으로 오픈소스 프로그램 매니저가 담당합니다.

외부의 오픈소스 개발자가 특정 기업의 오픈소스 관련 이슈를 논의하기 위해 기업 담당자에게 연락하고 싶어도 연락 방법을 찾지 못하다가 결국 바로 법적 클레임을 제기하는 경우가 있습니다. 이를 방지하기 위해 기업은 제3자가 기업에 오픈소스 관련하여 문의 및 요청을 할 수 있는 연락 방법을 항시 공개적으로 밝혀야 합니다.

ISO 표준은 공통적으로 다음과 같이 제3자가 오픈소스에 대해 문의할 수 있는 공개된 방법을 요구합니다.

외부에서 기업에 오픈소스 관련 문의를 할 수 있도록 다음과 같이 연락 방법을 제공할 수 있습니다.

  1. 오픈소스 담당 조직의 대표 이메일 주소를 공개합니다.
  2. Linux Foundation의 Open Compliance Directory를 이용합니다.
  3. 기업의 오픈소스 웹사이트가 있다면 이를 통해 이메일 주소를 공개합니다.

제품 및 서비스와 동봉하는 오픈소스 고지문에 오픈소스 담당 조직의 대표 이메일 주소를 포함하여 공개하는 것도 좋은 방법입니다.

기업은 아래의 예시와 같이 오픈소스 정책에 외부 문의 대응에 대한 내용을 반영할 수 있습니다.

9. 외부 문의 대응

(1) 외부 문의 대응 책임

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

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

(2) 연락처 공개

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

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

(3) 외부 문의 대응 절차

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

SK텔레콤은 모든 제품에 오픈소스 고지문을 포함하고 있습니다. 오픈소스 고지문에는 SK텔레콤 오픈소스 웹사이트 주소와 오픈소스 프로그램 오피스로 연락할 수 있는 메일 주소가 함께 제공됩니다.

SK텔레콤 오픈소스 고지문

또한, SK텔레콤 오픈소스 웹사이트에서도 오픈소스 프로그램 오피스로 연락할 수 있는 메일 주소를 제공하고 있습니다.

SK텔레콤 오픈소스 웹사이트

오픈소스 기여

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

ISO/IEC 5230은 다음과 같이 문서화된 오픈소스 기여 정책을 요구합니다.

이러한 오픈소스 기여에 대한 정책은 [부록1] 오픈소스 정책 샘플 7. 오픈소스 기여에서 확인할 수 있습니다.

7. 오픈소스 기여

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

(1) 리뷰 요청 및 승인

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

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

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

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

...

기업은 이를 참고하여 기업의 상황에 맞는 오픈소스 기여에 대한 원칙을 오픈소스 정책에 포함해야 합니다.

Summary

오픈소스 정책을 문서화하는 것은 효과적인 오픈소스 관리를 위해 가장 중요한 과정입니다.

다음 페이지에서 위에서 언급한 ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 충족하는 샘플 오픈소스 정책 문서를 제공합니다. : [부록1] 오픈소스 정책 (template)

위의 내용을 참고하여 각 요구사항을 회사의 상황에 맞게 적절한 원칙을 수립하는 것이 필요합니다. 또한 문서로만 그치지 않고, 실행 가능한 절차까지 고려해야 합니다. 말뿐인 정책은 소용이 없습니다.

이렇게 오픈소스 정책을 수립하고 문서화하면, ISO 표준 규격 중 아래의 주황색으로 표시된 요구사항을 충족할 수 있습니다.

2.4 - 3. 프로세스

오픈소스 프로세스는 소프트웨어 개발 및 배포 과정에서 기업이 오픈소스 정책을 준수할 수 있도록 하는 실행 가능한 절차입니다.

오픈소스 라이선스 컴플라이언스 측면에서는 소프트웨어를 개발하고 배포하면서 사용한 오픈소스에 대해 각 라이선스가 요구하는 조건을 준수하기 위한 활동을 수행하여 오픈소스 고지문(Notice), 공개할 소스 코드 (Source Code) 등의 산출물을 생성하게 됩니다.

Simplified view of the compliance end-to-end process : https://www.linuxfoundation.org/wp-content/uploads/OpenSourceComplianceHandbook_2018_2ndEdition_DigitalEdition.pdf

오픈소스 보안 보증을 위해서는 배포용 소프트웨어에 대한 보안 취약점 존재 여부를 탐지하고, 구조적/기술적 위협을 식별하여 출시 전에 문제를 해결하기 위한 활동을 수행해야 합니다.

기업이 효과적인 오픈소스 라이선스 컴플라이언스와 보안 보증을 이루기 위해서는 아래와 같은 프로세스를 구축해야 합니다.

  • 오픈소스 프로세스
  • 오픈소스 보안 취약점 대응 프로세스
  • 외부 문의 대응 프로세스
  • 오픈소스 기여 프로세스

그럼 각 프로세스가 어떻게 구성되어야 하는지 하나하나 살펴보겠습니다.

1. 오픈소스 프로세스

기업은 소프트웨어 개발 프로세스에 따라 오픈소스 라이선스 컴플라이언스와 보안 취약점 관리를 위한 오픈소스 프로세스를 구축해야 합니다.

아래의 이미지는 기업이 일반적으로 채택하여 사용할 수 있는 샘플 오픈소스 프로세스입니다.

위 오픈소스 프로세스에 맞춰서 각 단계별로 취해야 할 절차는 다음과 같습니다.

(1) 오픈소스 식별 및 검사

오픈소스 식별 및 검사 단계에서는 사용하려는 오픈소스의 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무사항은 무엇인지, 알려진 취약점은 존재하는지 확인해야 합니다.

어떤 오픈소스를 사용하려고 하는지, 그 라이선스는 무엇인지, 각 라이선스가 부여하는 의무는 무엇인지, 알려진 취약점은 무엇인지 검토하고 기록합니다.

ISO/IEC 5230 표준은 라이선스 컴플라이언스를 위해 일반적인 오픈소스 라이선스의 사용 사례를 다룰 수 있어야 하고, 각 식별된 라이선스에 의해 부여된 의무, 제한 및 권리를 검토하고 기록하기 위한 문서화된 절차를 요구합니다.

이를 위한 절차의 예는 다음과 같습니다.

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

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

  2. 사업 부서는 오픈소스 정책에서 정의한 기준에 따라 라이선스와 알려진 취약점을 확인합니다.

  3. 사업 부서는 의문 사항을 오픈소스 프로그램 매니저와 보안 담당에게 문의합니다. 필요할 경우 외부 전문가에게 자문을 요청합니다.

  4. 모든 결정 및 관련 근거는 문서화하여 보관합니다.

이를 위해 기업은 아래의 예시와 같이 제품 출시 전에 오픈소스 식별, 검사 단계를 통해 각 식별된 라이선스가 부가하는 의무, 제한과 알려진 취약점을 검토하고 기록하기 위한 문서화된 절차를 수립해야 합니다.


(1) 오픈소스 식별

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

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

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

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

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

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

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

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

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

(2) 소스 코드 검사

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

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

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

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

오픈소스 식별 및 검사 단계에서는 소스 코드 스캔 도구를 사용할 수 있다. 이에 대한 자세한 내용은 “1. 소스 코드 스캔 도구“에서 설명합니다.

(2) 문제 해결

오픈소스 식별 및 검사를 통해 오픈소스를 식별하고 라이선스와 보안 취약점의 위험을 확인한 후에는 문제를 해결하는 절차가 필요합니다. 다음과 같은 방법으로 검출된 모든 문제를 해결해야 합니다.

  • 이슈가 되는 오픈소스를 삭제합니다.
  • 오픈소스 라이선스 이슈 해결을 위해 다른 라이선스 하의 오픈소스로 교체합니다.
  • 알려진 취약점이 해결된 버전의 오픈소스로 교체합니다.

이를 위한 문서화된 프로세스의 예는 다음과 같습니다.

(3) 문제 해결

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

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

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

(3) SBOM 식별, 검토, 보관

오픈소스 라이선스 컴플라이언스 활동의 가장 기본은 배포용 소프트웨어에 포함된 오픈소스 현황을 파악하는 것입니다. 배포용 소프트웨어에 포함된 오픈소스와 그 라이선스를 식별하여 그 정보를 담고 있는 SBOM(Software Bill of Materials)을 작성하고 관리하는 프로세스를 구축해야 합니다. 배포용 소프트웨어의 버전마다 어떤 오픈소스가 포함되어 있는지 알고 있어야 소프트웨어를 배포할 때 각 오픈소스의 라이선스가 요구하는 의무 사항을 준수할 수 있기 때문입니다. 이는 오픈소스 보안 취약점을 발견하고 대응하기 위해서도 꼭 필요한 과정입니다.

모든 오픈소스는 배포용 소프트웨어에 통합하기 전에 검토 및 승인되어야 합니다. 오픈소스의 기능, 품질뿐만 아니라 출처, 라이선스 요건을 충족할 수 있는지, 알려진 취약점을 해결하였는지 등에 대해 사전 검토가 되어야 합니다. 이를 위해 검토 요청 → 리뷰 → 승인 과정이 필요합니다.

ISO 표준은 공통적으로 다음과 같이 배포용 소프트웨어에 사용된 모든 오픈소스 소프트웨어가 소프트웨어 수명 주기 동안 지속적으로 기록되도록 하는 문서화된 절차를 요구합니다.

이를 위해 기업은 아래의 예시와 같이 오픈소스 프로세스에 SBOM에 대한 내용을 반영할 수 있다.


(4) 검토

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

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

(5) 승인

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

(6) 등록

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

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

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

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

SBOM 관리를 위한 도구에 대해서는 “SBOM 관리 도구“에서 자세히 설명합니다.

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

(4) 라이선스 컴플라이언스 산출물 생성

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

ISO/IEC 5230 표준은 다음과 같이 컴플라이언스 산출물을 준비하고, 이를 배포용 소프트웨어와 함께 제공하기 위한 프로세스를 설명하는 문서화된 절차를 요구합니다.

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

  1. 오픈소스 고지문 : 오픈소스 라이선스 전문과 저작권 정보 제공을 위한 문서

  2. 공개할 소스 코드 패키지 : GPL, LGPL 등 소스 코드 공개를 요구하는 오픈소스 라이선스 의무 이행을 위해 공개할 소스 코드를 취합한 패키지

컴플라이언스 산출물은 배포용 소프트웨어를 배포할 때 함께 제공해야 합니다.

이를 위해 기업은 아래의 예시와 같이 오픈소스 프로세스에 고지 단계부터 배포 단계까지 컴플라이언스 산출물 생성에 대한 내용을 반영할 수 있습니다.

(7) 고지

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

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

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

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

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

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

(8) 배포 전 확인

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

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

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

(9) 배포

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

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

배포용 소프트웨어를 배포하는 경우, 공개할 소스 코드 패키지를 동봉하는 것이 곤란할 수 있습니다. 이 경우, 최소 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.

<출처 : SFLC Guide to GPL Compliance>

따라서, 컴플라이언스 산출물은 3년 이상 보관해야 하며, 이를 위한 프로세스가 구축되어야 합니다.

이를 위해 기업은 오픈소스 웹사이트 구축을 고려할 수 있습니다. 자세한 내용은 “오픈소스 컴플라이언스 산출물 보관“에서 확인하실 수 있습니다.

2. 오픈소스 보안 취약점 대응 프로세스

기업은 제품/서비스를 개발하면서 오픈소스 보안 취약점을 탐지하고 해결하는 등 보안 보증을 위한 활동을 수행해야 합니다.

ISO/IEC 18974 표준은 다음과 같이 보안 보증 방법에 대한 문서화된 절차와 수행된 조치를 기록하도록 요구합니다.

이를 위해 기업은 배포용 소프트웨어에서 알려진 취약점 존재 여부를 탐지하고, 식별된 위험이 출시 전에 해결해야 할 뿐 아니라 출시 후 새롭게 알려진 취약점에 대응하기 위한 방법과 절차를 갖춰야 합니다.

먼저 기업은 배포용 소프트웨어에 알려진 취약점이 있는지 탐지하고, 식별된 위험을 출시 전에 해결해야 합니다. 이와 같이 알려진 취약점을 탐지하고 해결하는 절차는 오픈소스 프로세스의 오픈소스 식별 단계, 소스 코드 검사 단계, 문제 해결 단계를 통해 수행할 수 있습니다.

그리고, 배포용 소프트웨어의 릴리스 후 새롭게 알려진 취약점이 공개되었을 때 이미 배포된 소프트웨어에 존재하는지 확인하고, 해결하기 위해서는 신규 보안 취약점 대응 프로세스를 수립해야 합니다.

아래는 신규 보안 취약점 발견 시 대응을 위한 프로세스 샘플입니다.

신규 보안 취약점 대응 프로세스 (샘플)


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

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

(1) 모니터링

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

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


(2) 초기 대응

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

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

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

(3) 문제 해결

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

(4) 검토

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

(5) 승인

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

(6) 등록

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

(7) 고지

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

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

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

(8) 배포

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

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

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

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

기업이 외부 클레임으로 인해 법적 소송에까지 이르지 않기 위해서는 외부 문의 및 요청에 가능한 한 빠르고 정확하게 대응하는 것이 중요합니다. 이를 위해 기업은 외부 오픈소스 문의에 빠르고 효과적으로 대응할 수 있는 프로세스를 구축해야 합니다.

ISO 표준은 공통적으로 다음과 같이 제3자의 문의에 대응하기 위한 내부의 문서화된 절차를 요구합니다.

아래 그림은 외부 문의 대응을 위해 기업이 갖춰야할 프로세스 샘플입니다.

외부 문의 대응 프로세스 (샘플)


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

(1) 접수 알림

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

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

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

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

(2) 조사 알림

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

(3) 내부 조사

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

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

(4) 요청자에게 보고

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

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

(5) 문제 보완 / 알림

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

(6) 문제 해결 알림

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

(7) 프로세스 개선

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

4. 오픈소스 기여 프로세스

기업이 외부 오픈소스 프로젝트에 기여를 허용하는 정책을 갖고 있다면, 사내 개발자들이 어떤 절차로 외부 프로젝트에 기여할 수 있을지 관리하는 문서화된 절차가 있어야 합니다.

ISO/IEC 5230 표준은 다음과 같이 오픈소스 기여를 관리하는 문서화된 절차를 요구합니다.

SK텔레콤에서 공개한 오픈소스 기여 절차는 좋은 예입니다.

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

5. 프로세스 현행화

프로세스가 문서화만 되어 있고 실제 운영되지 않는다면 바람직하지 않습니다. 또한, 업무 상황이나 조직 구성에 맞지 않게 되어 있는 것도 문제입니다. 기업은 프로세스가 회사 내부 조직과 상황에 맞게 항상 최신 상태로 유지되어야 합니다.

ISO/IEC 18974 표준은 다음과 같이 프로세스를 주기적으로 검토 및 개선해야 함을 요구합니다.

기업은 이를 위해 아래의 샘플과 같이 오픈소스 정책 문서 내에 매년 정기적으로 오픈소스 정책과 오픈소스 프로세스를 개선하고, 모든 과정을 문서화하여 기록하도록 정의할 수 있습니다.

4. 역할, 책임 및 역량

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

(1) OSRB

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

OSRB는 매년 정기적으로 검토하여 정책과 프로세스를 개선합니다. 모든 개선 과정은 문서화하여 기록합니다.
  - OSRB는 회사의 프로세스 수행 성과와 미흡한 부분, 모범 사례를 분석하고 비즈니스 환경을 반영하여 항상 현행화합니다.
  - 오픈소스 컴플라이언스를 위한 정책과 프로세스는 오픈소스 프로그램 매니저가 책임을 갖고 관리합니다.
  - 오픈소스 보안 보증을 위한 정책과 프로세스는 보안 담당이 책임을 갖고 관리합니다.

6. Summary

여기까지 프로세스를 구축하게 되면 ISO 표준 규격 중 아래의 노란색으로 표시된 요구사항을 충족할 수 있습니다.

2.5 - 4. 도구

1. 소스 코드 스캔 도구

오픈소스 프로세스의 오픈소스 식별 및 검사 단계에서는 소스 코드 스캔 도구를 사용할 수 있습니다. 소스 코드 스캔 도구는 무료로 사용할 수 있는 오픈소스 기반 도구부터 상용 도구까지 다양합니다. 각 도구는 특장점이 있지만, 어떤 도구도 모든 문제를 해결할 수 있는 완벽한 기능을 제공하지 않습니다. 따라서 기업은 제품의 특성과 요구사항에 맞는 적합한 도구를 선택해야 합니다.

많은 기업이 이러한 자동화된 소스 코드 스캔 도구와 수동 검토를 병행하여 이용합니다. Linux Foundation의 FOSSology 프로젝트는 오픈소스로 공개된 소스 코드 스캔 도구로서 기업들이 손쉽게 무료로 사용할 수 있습니다.

https://www.fossology.org/

FOSSology의 설치 및 사용 방법은 FOSSology 가이드를 참조하시기 바랍니다.

2. Dependency 분석 도구

최근의 소프트웨어 개발 시에는 Gradle, Maven과 같은 패키지 관리자를 지원하는 빌드 환경을 사용합니다. 이러한 빌드 환경에서는 소스 코드가 없어도 빌드 타임에 필요한 Dependency 라이브러리를 원격의 공간으로부터 받아와서 배포용 소프트웨어를 구성합니다. 이때의 Dependency 라이브러리는 배포용 소프트웨어에는 포함되지만 소스 코드 스캔 도구로는 검출되지 않습니다. 따라서 Dependency 분석을 위한 도구를 활용하는 것도 중요합니다.

오픈소스인 OSS Review Toolkit은 Analyzer라는 Dependency 분석 도구를 제공합니다.

https://github.com/oss-review-toolkit/ort#analyzer

또한 LG전자는 FOSSLight Dependency Scanner를 오픈소스로 공개했습니다. FOSSLight Dependency Scanner는 Gradle, Maven, NPM, PIP, Pub, Cocoapods와 같은 다양한 패키지 관리자를 지원합니다.

https://fosslight.org/ko/scanner/

3. SBOM 관리 도구

ISO/IEC 5230 규격의 3.3.1.2에서는 배포용 소프트웨어에 포함된 SBOM 목록은 문서화하여 보관할 것을 요구합니다.

SBOM은 Excel과 같은 스프레드시트 프로그램으로도 관리할 수 있지만, 배포용 소프트웨어의 개수와 버전이 수백 개가 넘어갈 경우 수동으로 관리하는 것은 쉽지 않습니다. 따라서 이를 위한 오픈소스 자동화 도구를 도입하는 것이 좋습니다.

Eclipse 재단에서 후원하는 오픈소스 프로젝트인 SW360은 배포용 소프트웨어별로 포함하고 있는 오픈소스 목록을 추적할 수 있는 기능을 제공합니다.

SW360의 설치 및 사용 방법은 SW360 가이드를 참고할 수 있습니다.

그리고 위에서 언급한 FOSSLight도 SBOM 관리를 위한 기능을 제공합니다.

https://fosslight.org/fosslight-guide/started/2_try/4_project.html

LG전자는 FOSSLight를 자체 개발하여 지난 수년간 전체 사업부의 배포용 소프트웨어에 대한 SBOM을 관리해왔으며, 2021년 6월, 이를 누구나 사용할 수 있도록 오픈소스로 공개하였음을 발표하였습니다.

자세한 설치 및 사용 방법을 한국어 가이드로 제공하고 있어서 국내 기업에게 큰 도움이 될 것으로 기대합니다.

https://fosslight.org/

4. 오픈소스 보안취약점 관리 도구

기업은 알려진 취약점이 포함된 제품/서비스를 추적하고 이를 해결해야 합니다. 이를 위해 기업은 이를 자동화하는 도구 환경을 구축해야 합니다.

SW360은 등록된 Release에 대해 보안 취약점이 있는지 자동으로 확인할 수 있습니다. 이를 위해 SW360은 CVE 정보를 주기적으로 수집하도록 24시간마다 스케줄링하는 기능을 제공합니다. 이렇게 스케줄링을 설정하면 SW360은 정해진 시간에 CVE Search 사이트(https://cve.circl.lu/)에서 CVE 정보를 수집합니다. 이렇게 Vulnerabilities 정보가 수집된 이후에는 생성한 Project에 보안 취약점이 있는지 조회할 수 있어서, 새로 공개된 취약점이 이미 출시한 제품에 존재하는지 여부도 추적이 가능합니다.

SW360으로 보안취약점 관리하는 방법은 SW360 가이드를 참고할 수 있습니다.

FOSSLight도 이와 유사하게 보안취약점 정보를 자동으로 취득하고, 보안취약점이 검출된 프로젝트 정보를 자동으로 확인하여 필요 시 메일 등 알림을 제공합니다.

5. 오픈소스 컴플라이언스 산출물 생성 도구

주요 오픈소스 컴플라이언스 산출물인 오픈소스 고지문은 배포용 소프트웨어어 포함된 오픈소스의 저작권과 라이선스 정보를 제공하기 위한 문서입니다. 오픈소스 고지문은 문서편집기 도구로 작성하는 방식으로 만들수도 있지만, 자동으로 생성하는 도구를 활용하는 것이 좋습니다.

SK텔레콤은 사내에서 사용하는 오픈소스 고지문 자동 생성 도구를 오픈소스로 공개하였고(onot : https://github.com/sktelecom/onot), 카카오에서 주요 기능을 기여하는 방법으로 공동 개발에 참여하였습니다.

onot 설치방법

onot은 SPDX 문서 형식으로 작성된 SBOM을 자동으로 오픈 소스 고지문 형식으로 변환하는 도구입니다. Python 프로그램으로 가볍고 간단하게 사용할 수 있습니다.

onot 생성 오픈소스 고지문 샘플

FOSSLight도 취득한 SBOM을 기반으로 오픈소스 고지문을 자동으로 생성하는 기능을 제공합니다.

https://fosslight.org/fosslight-guide/started/2_try/4_project.html

6. 오픈소스 컴플라이언스 산출물 보관

기업은 오픈소스 웹사이트를 구축하고, 오픈소스 컴플라이언스 산출물을 등록하여 외부 고객들이 배포용 소프트웨어에 대한 오픈소스 고지문과 공개할 소스 코드 패키지를 언제든지 다운로드할 수 있도록 편의를 제공하는 것이 좋습니다.

이를 위해 ISO/IEC 5230 표준은 다음과 같이 배포용 소프트웨어의 컴플라이언스 산출물 사본을 보관하기 위한 문서화된 절차를 요구합니다.

이러한 도구 환경은 SK텔레콤의 오픈소스 웹사이트에서 참고하실 수 있습니다.

https://sktelecom.github.io/compliance/

이 웹사이트는 오픈소스로 개발하였고, 소스 코드를 공개하고 있어서 다른 기업들도 쉽게 유사한 환경을 구축할 수 있습니다.

https://github.com/sktelecom/sktelecom.github.io

7. Summary

여기까지 도구 환경까지 구축하게 되면 ISO 표준 규격 중 아래의 녹색으로 표시된 요구사항을 충족할 수 있다.

2.6 - 5. 교육

1. 교육

아무리 훌륭한 정책과 프로세스를 구축하였다고 해도 기업의 구성원이 아무도 신경쓰지 않는다면 무용지물일 것입니다. 오픈소스 정책과 오픈소스 프로세스가 기업에서 효과적으로 동작하기 위해서는 구성원 교육이 중요합니다.

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

이를 위해 ISO 표준은 공통적으로 다음과 같이 오픈소스 정책을 알리기 위한 문서화된 절차를 요구합니다.

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

기업은 이러한 방법들을 다음의 예와 같이 작성하여 오픈소스 정책 문서에 포함해야 합니다.

5. 교육 및 평가

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

기업은 프로그램 참여자가 기업의 오픈소스 정책, 오픈소스 관련 목표, 효과적인 오픈소스 프로그램이 되기 위한 참여자의 기여 방법, 그리고 프로그램 요구사항을 준수하지 않을 경우 미치는 영향에 대해 인식하도록 해야 합니다. 이를 위해 기업은 교육을 제공하고, 프로그램 참여자가 올바르게 인식하였는지 확인하기 위해 평가를 수행하고 평가 결과를 문서화하여 보관해야 합니다.

ISO 표준은 공통적으로 다음과 같이 프로그램 참여자의 인식을 평가하였음을 나타내는 문서화된 증거를 요구합니다.

따라서 기업은 아래의 예와 같은 내용을 기업의 오픈소스 정책에 포함할 수 있다.

1. 목적

(1) 정책의 목적 

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

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

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

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

(2) 미준수 시 영향
이 정책을 준수하지 않는다면 다음과 같은 상황이 발생할 수 있습니다.

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

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

(3) 구성원의 기여 방법

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

평가에 대해서는 아래에서 한번 더 자세히 설명합니다.

오픈소스 교육에는 오픈소스 기여 정책에 대한 내용도 포함됩니다. 오픈소스 기여 정책을 만들었다 해도 사내 구성원이 이에 대한 존재를 알지 못한다면 무분별한 기여 활동으로 개인과 회사에 피해가 발생할 우려가 있습니다.

이를 위해 ISO/IEC 5230 표준은 다음과 같이 모든 프로그램 참여자가 오픈소스 기여 정책의 존재를 인식하도록 하는 문서화된 절차를 요구합니다.

따라서 기업은 모든 사내 개발자가 오픈소스 기여 정책의 존재를 알 수 있도록 오픈소스 교육을 제공해야 합니다.

교육자료를 새롭게 제작하는 것도 처음 업무를 시작하는 담당자에게는 쉽지 않은 일일 수 있습니다. 이러한 어려움을 돕고자 엔씨소프트는 사내 오픈소스 교육자료를 누구나 사용할 수 있도록 교안(PPT)와 강의 스크립트를 GitHub에 공개했습니다.

https://github.com/ncsoft/oss-basic-training

또한, 국내 대표 플랫폼 기업인 카카오도 사내 개발자를 위한 오픈소스 교육자료를 누구나 열람할 수 있도록 공개했습니다.

http://t1.kakaocdn.net/olive/assets/opensource_guide_kakao.pdf

아직 교육 자료를 만들지 않았다면, 이런 오픈소스 관리 우수 기업들의 오픈소스 교육 자료를 활용하는 것도 좋은 방법입니다.

2. 평가

기업은 각 역할에 대한 담당자를 지정하였으면, 지정된 담당자가 교육, 훈련 및 경험을 바탕으로 맡은 역할을 수행할 수 있는 자격을 갖추었음을 확인해야 합니다. 역량이 미흡한 프로그램 참여자에게는 충분한 역량을 갖출 수 있도록 교육도 제공해야 합니다. 그리고 기업은 각 참여자가 역량을 갖추고 있는지 평가하고 결과를 보관해야 합니다.

이를 위해 ISO 표준은 공통적으로 다음과 같이 프로그램 참여자의 역량을 평가한 문서화된 증거를 요구합니다.

따라서, 기업은 아래와 같이 교육과 평가를 수행하고 결과를 유지해야 합니다.

  1. 기업은 각 참여자가 필요한 역량을 보유할 수 있도록 교육을 제공합니다.
  2. 교육 내용을 기반으로 평가를 수행합니다.
  3. 평가 결과는 기업의 교육 시스템 혹은 HR 부서에서 보관합니다.

프로그램 참여자가 수백 명 이상이어서 교육 제공이 쉽지 않을 경우, 기업의 온라인 교육과 평가 시스템을 이용하는 것도 좋은 방법입니다.

이와 같은 내용은 기업의 오픈소스 정책에 다음과 같이 포함할 수 있습니다.

4. 역할, 책임 및 역량

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

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


5. 교육 및 평가

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

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

3. 오픈소스 라이선스 가이드

오픈소스 라이선스를 제대로 준수하기 위해서는 오픈소스 라이선스별로 요구하는 사항에 대해 정확히 알고 있어야 합니다. 하지만 개별 소프트웨어 개발자가 이를 일일이 파악하는 것은 어려우므로, 오픈소스 프로그램 매니저는 자주 사용되는 오픈소스 라이선스에 대해 일반적인 사용 사례별 요구사항/주의사항을 정리하여 회사 내부에 공유하는 것이 좋습니다.

오픈소스 라이선스 가이드에는 일반적인 오픈소스 라이선스 사용 사례별 요건을 포함하여 개발 부서에서 오픈소스를 사용하면서 올바른 라이선스 의무 준수 활동을 할 수 있게 해야 합니다.

이를 위해 ISO/IEC 5230 표준은 다음과 같이 배포용 소프트웨어 내의 오픈소스 컴포넌트에 대해 일반적인 오픈소스 라이선스 사용 사례를 처리하기 위한 문서화된 절차를 요구합니다.

오픈소스 라이선스 사용 사례를 처리하기 위해서는 오픈소스 라이선스별로 분류된 라이선스 가이드가 필요합니다. 오픈소스 라이선스에 대한 일반적인 가이드와 라이선스 의무 요약 자료는 한국저작권위원회에서 제공하는 라이선스 가이드를 참고할 수 있습니다.

SK텔레콤의 오픈소스 가이드 내 라이선스별 의무사항항 문서도 좋은 자료입니다.

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

기업은 구성원이 쉽게 접근하여 참고할 수 있는 공간에 오픈소스 라이선스 가이드를 제공해야 합니다.

4. Summary

여기까지 교육, 평가와 가이드 제공 환경까지 구축하게 되면 ISO 표준 규격 중 아래의 하늘색으로 표시된 요구사항을 충족할 수 있다.

2.7 - 6. 준수

ISO/IEC 5230 3.6, ISO/IEC 18974 3.4를 제외한 모든 요구사항을 준수하는 오픈소스 프로그램(오픈소스 정책 / 프로세스 / 도구 / 조직)을 구축한 기업은 다음 두가지를 문서화하여 명시할 수 있습니다.

이를 위해 ISO 표준은 공통적으로 다음과 같이 오픈소스 정책을 알리기 위한 문서화된 절차를 요구합니다.

따라서, 다음의 내용을 문서화할 수 있습니다.

  1. 기업의 오픈소스 프로그램이 ISO/IEC 5230, ISO/IEC 18974 의 모든 요구사항을 충족함
  2. 적합성 인증을 획득한 후 18개월 이상 ISO/IEC 5230, ISO/IEC 18974의 모든 요구 사항을 충족하는 상태 유지를 보장함

기업은 위의 내용을 오픈소스 정책에 포함시킬 수도 있고, 외부에 공개되어 있는 웹사이트를 통해 게재할 수도 있습니다.

아래 이미지와 같이 SK텔레콤에서 오픈소스 포털사이트에 이에 대한 내용을 게재한 것을 참고할 수 있습니다. https://sktelecom.github.io/compliance/iso5230/

이렇게 하면 ISO 표준 규격 중 아래의 파란색으로 표시된 요구사항을 충족할 수 있다.

여기까지 완료하면 기업은 드디어 ISO/IEC 5230, ISO/IEC 18974의 모든 요구사항을 충족하게 됩니다.

3 - 기업 오픈소스SW 거버넌스 - OpenChain 해설서

오픈소스 컴플라이언스의 국제 표준인 OpenChain 규격을 준수하기 위한 가이드를 제공합니다.

정보통신산업진흥원(NIPA)이 주관하고 공개SW역량프라자에서 연구를 수행하여 기업이 오픈소스 컴플라이언스의 국제 표준인 OpenChain 규격을 준수하기 위해 필요한 사항들을 설명하는 해설서를 가이드 형태로 제작하였습니다. : 기업 공개SW 거버넌스 OpenChain 2.0 해설

기업 공개SW 거버넌스 Openchain 2.0 해설

여기서는 NIPA의 허락 하에 가이드 내용을 GitHub에 공개하고, 누구나 내용을 참고하고, 수정 / 개선할 수 있게 하였습니다. : GitHub Repository

References

이 가이드는 다음 자료를 참고하여 작성하였습니다.

  1. OpenChain Project Website
  2. OpenChain ISO/IEC 5230
  3. OpenChain ISO/IEC 18974
  4. OpenChain Open Source Policy Template
  5. Open Source Compliance In The Enterprise

3.1 - I. OpenChain 프로젝트란?

ISO 국제 표준에 기반하여 기업이 오픈소스를 효과적으로 관리하기 위한 방안을 소개합니다.

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

이러한 복잡한 소프트웨어 공급망의 여러 조직 중 한 곳이라도 오픈소스 라이선스 의무를 준수하지 않거나 올바른 오픈소스 사용 정보를 제공하지 않으면 최종 소프트웨어를 배포하는 기업은 오픈소스 라이선스 의무 준수에 실패할 수밖에 없다. 이로 인해 소송을 제기당해 제품 판매가 중단되는 상황이 발생할 수도 있다.

[OpenChain Open Source Software License Compliance General Public Guide]

2009년 12월, Busybox라는 오픈소스 관련된 소송이 있었다. Busybox는 임베디드 시스템에 광범위하게 사용되고 있는 GPL-2.0 라이선스가 적용된 오픈소스인데, 국내 회사 두 곳을 포함하여 14개 회사가 소송 대상이 되었다. 이 사례에서 주목할만한 점은 이 중에는 제품을 직접 개발하지 않고 배포만 한 회사도 소송을 당하였다는 점이다.

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

Linux Foundation의 OpenChain 프로젝트는 기업이 오픈소스 컴플라이언스를 위해 준수해야 할 핵심 사항을 간결하고 일관성 있게 정의하고, 이를 모두가 준수한다면 소프트웨어 공급망 전체에 걸쳐 오픈소스 라이선스 측면의 신뢰를 구축할 수 있다는 믿음으로 설립되었다.

[OpenChain Project Logo]

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

OpenChain 프로젝트는 기업들이 오픈소스 컴플라이언스를 더욱 쉽게 달성 할 수 있도록 크게 다음 세 가지를 제공한다.

  1. OpenChain 규격1
  2. OpenChain 적합성 인증2
  3. 문서 자료3

기업이 어떻게 이들을 활용할 수 있을지 하나씩 알아보자.

  1. OpenChain 규격 - https://www.openchainproject.org/contribute-to-the-standard ↩︎

  2. OpenChain 자체 인증 웹사이트 - https://certification.openchainproject.org/ ↩︎

  3. OpenChain 문서 자료 - https://www.openchainproject.org/resources ↩︎

3.1.1 - 1. OpenChain 표준

ISO/IEC 5230

OpenChain 프로젝트는 2016년 OpenChain 규격 1.0을 제작하여 배포했다. OpenChain 규격은 오픈소스 컴플라이언스를 위한 핵심 요구사항을 정의한 12페이지 분량의 규격으로, 기업의 규모나 업종과 관계없이 모든 분야의 회사에 적합하도록 고안되었다. 2020년 12월 Openchain 규격 2.1은 ISO/IEC 5230 국제표준으로 등록되었다.

ISO/IEC 5230은 기업이 오픈소스 컴플라이언스 달성을 위해 꼭 수행해야 할 여섯 가지 주요 요구사항과 이를 입증하기 위해 필요한 자료 목록을 정의하고 있다.

  1. 프로그램 설립
  2. 관련 업무 정의 및 지원
  3. 오픈소스 컨텐츠 검토 및 승인
  4. 컴플라이언스 산출물 생성 및 제공
  5. 오픈소스 커뮤니티 참여에 대한 이해
  6. 규격 요구사항 적합성

오픈소스 컴플라이언스를 처음 시작하는 기업이라면 이러한 ISO/IEC 5230 표준의 요구사항을 하나씩 충족해가면서 수준을 향상시키는 것이 좋은 전략이다.

< https://standards.iso.org/ittf/PubliclyAvailableStandards/c081039_ISO_IEC_5230_2020(E).zip >

ISO/IEC 18974

OpenChain 프로젝트는 ISO/IEC 5230에 이어 오픈소스 보안 보증을 위한 규격을 제작하였다. 이 규격은 2023년 말 ISO/IEC 18974로 등록되었다. : https://www.iso.org/standard/86450.html

이들 두 표준 내 각 요구사항의 준수 방법은 “3장. OpenChain 표준 준수 방법”에서 상세히 다룬다.

3.1.2 - 2. OpenChain 인증

OpenChain 규격에서의 요구 사항을 모두 준수한다면 OpenChain 적합한 오픈소스 프로그램을 보유했음을 인증받을 수 있다. 오픈소스 프로그램이란 정책, 프로세스, 인원 등 기업이 오픈소스 컴플라이언스 활동을 수행하기 위한 일련의 관리 체계를 의미한다. 이 장에서는 인증 방법과 적합성 선언에 관해 설명한다.

OpenChain 프로젝트에서 제안하는 인증 방법은 세 가지 이다.

  • 자체 인증
  • 독립 평가
  • 타사 인증

각각의 방법을 알아보자.

자체 인증

자체 인증은 OpenChain 프로젝트에서 제일 권장하는 방법이며, 비용이 발생하지 않는다는 장점이 있다. OpenChain 프로젝트는 기업이 자체적으로 OpenChain 규격을 충족하는지 확인할 수 있도록 온라인 자체 인증 웹사이트를 제공한다.

< https://www.openchainproject.org/checklist-iso-5230-2020 >

기업의 오픈소스 담당자는 OpenChain 자체 인증 웹사이트에 가입해 온라인 자체 인증을 시작할 수 있다.

< https://www.openchainproject.org/checklist-iso-5230-2020 >

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

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

< https://www.openchainproject.org/community-of-conformance >

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

< https://www.openchainproject.org/conformance-submission >

타사 인증

소프트웨어 공급망에서 구매자에게 보다 신뢰성 있고 투명한 오픈소스 컴플라이언스 수준을 나타내고자 한다면 타사 인증 기관으로부터 인증서를 발급받고 이를 홍보에 활용할 수 있다. 또한, 오픈소스 컴플라이언스의 보다 견고한 신뢰성을 요구하는 일부 구매자는 공급자Supplier에게 타사 인증을 의무화 할 수도 있을 것으로 예상된다.

OpenChain의 공인 타사 인증 기관은 ORCRO1, PWC2, TÜV SÜD3 등이 있다.

< Third-Party Certifiers, 출처 - https://www.openchainproject.org/partners >

이들은 ISO/IEC 5230 적합 프로그램 확인을 위한 평가를 제공하고 통과한 기업에 인증서를 발급한다.

< PWC certification, 출처 - https://youtu.be/HslvXCM-4pQ >

유럽의 자동차 업계에서는 ISO/IEC 5230이 ASPICEAutomotive SPICE4 자동차 소프트웨어 개발을 위한 국제 표준 프로세스 모델)와 같이 자동차 소프트웨어 공급자에게 의무화될 날이 머지않을 것이라고 예측하는 전문가도 있다.

개별 평가 지원

개별 평가 지원은 기업 외부의 독립 기관이 공정한 관점에서 기업의 오픈소스 컴플라이언스 상태를 점검하고 평가한다. 어떤 인증서를 발급해주지는 않는다는 점이 자체 인증, 타사 인증과는 다른 점이다. 개별 평가 지원의 특징은 평가 보고서를 생성하는 것에 그치지 않고 도출된 미비점을 보완하기 위한 컨설팅을 제공한다.

기업은 독립 기관으로부터의 공정한 평가와 컨설팅을 받아 컴플라이언스 수준을 높이고, 다시 독립 평가를 수행하는 반복적인 과정을 통해 정책을 세분화하고 프로세스를 구축할 수 있다.

< Independent Compliance Assessment, 출처 - https://youtu.be/DEBd-g0Ab8E >

결국 기업은 OpenChain 인증을 받을 수 있는 수준에 도달하게 된다. 그때 자체 인증, 혹은 타사 인증을 획득하는 절차에 돌입할 수 있다. 이렇게 기업의 오픈소스 컴플라이언스 수준을 높이기 위한 평가와 컨설팅을 제공하여서 기업이 OpenChain 적합 프로그램을 보유하고 인증을 획득할 수 있게 지원한다.

개별 평가 지원을 제공하는 업체는 AlektoMetis5, Source Code Control6 등이 있다.

국내에서는 이와 유사한 프로그램을 NIPA의 오픈업7에서 국내 기업 대상으로 공개소프트웨어 활용지원 프로그램8을 통해 무료로 제공한다.

< OpenUp 주요 업무, 출처 - https://www.oss.kr/open_up_task >

  1. ORCRO- https://orcro.co.uk/ ↩︎

  2. PWC - https://www.pwc.de/en/opensource ↩︎

  3. TÜV SÜD - https://www.tuvsud.com ↩︎

  4. ASPICE : 자동차 소프트웨어 개발을 위한 국제 표준 프로세스 모델 - http://www.automotivespice.com ↩︎

  5. AlektoMetis - https://alektometis.com/, ↩︎

  6. Source Code Control - https://sourcecodecontrol.co/ ↩︎

  7. 오픈업 - https://www.oss.kr/open_up_intro ↩︎

  8. 공개소프트웨어 활용 지원 프로그램 - https://www.oss.kr/news/show/49e410fb-604d-4d35-ba25-8286b5f2c50d ↩︎

3.1.3 - 3. OpenChain 리소스

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

< https://www.openchainproject.org/resources >

이 가이드의 많은 내용도 OpenChain에서 공개한 자료를 기반으로 작성하였다. 각 기업의 오픈소스 담당자는 정책, 프로세스, 교육자료가 필요하다면 OpenChain Resources를 먼저 찾아보기 바란다. 또한 이 자료는 한국어로도 번역되어 공개되고 있다. OpenChain Korea Work Group1에서 이러한 번역 작업을 주도하고 있다. 한국어 번역은 관심 있는 누구나 참여할 수 있다2.

2장에서는 두 OpenChain 표준의 각 요구사항을 어떻게 준수해야 할지에 대해 세부적으로 설명한다.

  1. OpenChain Korea Work Group - https://openchain-project.github.io/OpenChain-KWG/ ↩︎

  2. 한국어 번역 작업 - https://openchain-project.github.io/OpenChain-KWG/resource/ ↩︎

3.2 - II. OpenChain ISO 표준 준수 방법

기업 오픈소스 관리를 위한 두개의 ISO 표준은 ISO/IEC 5230과 ISO/IEC 18974이다. 이 두 표준을 모두 준수함을 선언한 기업은 소프트웨어 솔루션을 배포하는 공급망 내에서 신뢰를 제공할 수 있게 된다.

ISO/IEC 5230과 ISO/IEC 18974는 유사한 포맷의 표준으로 공통 요구사항을 다수 포함한다. 아래 표는 두 표준의 요구사항 중 공통 사항과 차이점을 보여준다.

  • 파란색 영역은 두 표준이 공통적으로 포함하는 요구사항이다.
  • 노란색 영역은 License Compliance를 위해 ISO/IEC 5230에서만 요구하는 항목이다.
  • 붉은색 영역은 Security Assurance를 위해 ISO/IEC 18974에서만 요구하는 항목이다.

여기에서는 기업이 이 두 표준을 모두 준수하기 위해 충족해야 하는 여섯 가지 주요 요구사항과 각각의 준수 방법을 세부적으로 설명한다.

3.2.1 - 1. 프로그램 설립

오픈소스를 이용하여 소프트웨어를 개발하고 배포하는 기업이라면 오픈소스를 관리하기 위한 정책과 프로세스를 만들고, 이를 위한 인력과 자원을 적절하게 할당해야 한다.

오픈소스 프로그램이란 정책, 프로세스, 인원 등 기업이 오픈소스 컴플라이언스 활동을 수행하기 위한 일련의 관리 체계를 의미하며, OpenChain 규격의 첫 번째 요구사항은 바로 이 오픈소스 프로그램을 설립하라는 것이다.

1.1 정책

그 첫 번째 요구사항으로 문서화된 오픈소스 정책이 있어야 한다. 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.

1.1.1 문서화된 정책

먼저 오픈소스 정책을 수립하고 문서화해야 한다. 오픈소스 정책은 다음을 포함한다.

  • 기업이 오픈소스를 사용하여 소프트웨어 제품과 서비스를 만들어서 배포하기 위한 정책
  • 외부 오픈소스 커뮤니티에 기여하기 위한 정책
  • 기업의 소프트웨어를 오픈소스로 공개하기 위한 정책

이 안내서에서는 참고를 위해 ISO/IEC 5230, ISO/IEC 18974 두 표준의 요구사항을 충족하는 샘플 오픈소스 정책 문서를 “[부록 1] 오픈소스 정책”에서 제공한다.

1.1.2 정책을 알리는 절차

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

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

이에 대한 예시는 [부록 1] 오픈소스 정책의 5. 교육 및 평가를 참고할 수 있다.

5. 교육 및 평가

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

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

1.2 역량

이 장은 프로그램 참여자가 갖추어야 할 역량에 대한 요구사항을 정의한다. 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:

  • Identify the roles and the corresponding responsibilities of those roles that affects the performance and effectiveness of the program;
  • Determine the necessary competence of program participants fulfilling each role
  • Ensure that program participants are competent on the basis of appropriate education, training, and/or experience;
  • Where applicable, take actions to acquire the necessary competence; and
  • Retain appropriate documented information as evidence of competence.

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:

  • Identify the roles and responsibilities that impact the performance and effectiveness of the Program;
  • Determine the necessary competence of Program Participants fulfilling each role;
  • Ensure that Program Participants have appropriate education, training, and/or experience;
  • Where applicable, ensure Program Participants take actions to acquire the necessary competence;
  • Retain appropriate documented information as evidence of competence as well as who is currently a participant in the program.

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.2.1 역할과 책임

오픈소스 프로그램이 효율적이고 성과를 내기 위해서 필요한 역할이 무엇인지와 그 역할이 담당해야 할 책임을 정의해야 한다. 오픈소스 프로그램에 필요한 일반적인 역할은 다음과 같다.

  • 오픈소스 프로그램 매니저
  • 법무 담당
  • 인프라 담당
  • 보안 담당
  • 개발 문화 담당
  • 품질 담당
  • 소프트웨어 개발부서
  • OSPO1
  • OSRB2

위의 모든 역할을 처음부터 구성해야 하는 것은 아니다. 처음 시작하는 기업이라면 오픈소스 프로그램 매니저 역할을 하는 인원 한 명으로 시작할 수도 있다.

각 역할에 대한 일반적인 책임을 명시한 문서를 [부록 1] 오픈소스 정책의 4. 역할, 책임 및 역량에서 제공한다.

1.2.2 역량

각 역할과 그에 대한 책임을 정의하였으면, 그 역할을 수행할 인원이 갖춰야 할 필요 역량이 무엇인지 정의해야 한다. 이 부분도 마찬가지로 [부록 1] 오픈소스 정책의 4. 역할, 책임 및 역량에 포함하였으니 참고하기 바란다.

1.2.3 평가

기업은 각 역할에 대한 담당자를 지정하고, 지정된 담당자가 교육, 훈련 및 경험을 바탕으로 맡은 역할을 수행할 수 있는 자격을 갖추었음을 확인해야 한다. 필요할 경우, 프로그램 참여자가 충분한 역량을 갖출 수 있도록 교육도 제공해야 한다. 그리고 기업은 각 참여자가 역량을 갖추고 있는지 평가하고 결과를 보관해야 한다.

  1. 기업은 각 참여자가 필요한 역량을 보유할 수 있도록 교육을 제공한다.
  2. 교육 내용을 기반으로 평가를 수행한다.
  3. 평가 결과는 기업의 교육 시스템 혹은 HR 부서에서 보관한다.

프로그램 참여자가 수백 명 이상이어서 교육 제공이 쉽지 않을 경우, 기업의 온라인 교육과 평가 시스템을 이용하는 것도 좋은 방법이다.

이와 같은 내용은 기업의 오픈소스 정책에 다음과 같이 포함할 수 있다.

4. 역할, 책임 및 역량

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

각 역할의 담당 조직/담당자와 필요 역량 수준은 "Appendix 1. 담당자 현황"에서 정의한다. 

5. 교육 및 평가

4장에서 정의한 각 역할을 담당하는 모든 구성원은 [Learning Portal]에서 제공하는 오픈소스 교육을 수강해야 한다. 

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

1.2.4 프로세스 현행화

기업은 프로세스가 효과적인지 주기적으로 검토하여 개선하고, 이에 대한 근거를 문서화하여야 한다. 따라서, 프로세스 문서 상에 아래와 같은 내용을 포함할 수 있다.

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

1.3 인식

다음으로 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:

  • The open source policy;
  • Relevant open source objectives;
  • Their contribution to the effectiveness of the program; and
  • The implications of not following the Program’s requirements.

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.

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:

  • The Open Source Software Security Assurance policy;
  • Relevant Program objectives;
  • Their contribution to the effectiveness of the Program;
  • The implications of not following the Program’s requirements.

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. 교육 및 평가에서 제공한다.

1.4 프로그램 범위

오픈소스 프로그램을 기업 내 어느 조직 혹은 어느 제품에 적용할지를 결정해야 하며 이를 위한 절차가 필요하다. ISO/IEC 5230과 ISO/IEC 18974 표준에서는 다음과 같이 프로그램의 적용 범위에 대한 요구사항과 입증 자료를 정의한다.

ISO/IEC 5230

3.1.4 프로그램 적용 범위

프로그램은 다양한 범위별로 적용하여 관리할 수 있다. 예를 들어, 한 프로그램을 단일 제품군에만 적용할 수도 있고, 전체 부서 또는 전체 조직에 적용하여 관리할 수 있다. 따라서 각 프로그램에서는 적용 범위를 정확히 명시해야 한다.

입증 자료:

  • 3.1.4.1 프로그램의 적용 범위와 한계를 명확하게 정의한 문서화된 진술

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):

  • 3.1.4.1 A written statement that clearly defines the scope and limits of the program.

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.4.1 적용 범위와 한계 문서화

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

이를 위하여 다음의 예와 같은 내용을 오픈소스 정책에 포함한다.

1. 적용 범위

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

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

1.4.2 적용 범위 결정 프로세스

기업의 조직과 제품 및 서비스가 비즈니스 환경에 맞추어 변화함에 따라 프로그램의 적용 범위를 결정하거나 수정해야 하는 상황이 발생할 수 있다. 가업은 이에 대응하기 위한 프로세스를 다음의 예와 같이 준비해야 한다.

  1. 오픈소스 프로그램 매니저는 새로운 프로젝트를 시작할 때 해당 프로젝트가 프로그램 적용 범위 내에 포함되는지 여부를 판단한다.
  2. 포함된다고 판단되는 경우, 해당 프로젝트를 프로그램 적용 범위에 포함 시키기 위한 제안을 OSRB2에 제출한다.
  3. OSRB에서 수락할 경우, 이에 맞게 프로그램의 적용 범위를 수정한다.
  4. 이외 오픈소스 프로그램 매니저는 프로그램 적용 범위에 대한 검토가 필요하다고 판단되는 경우, 동일한 프로세스에 따라 프로그램 적용 범위에 대한 검토를 시작할 수 있다.

이를 위하여 다음의 예와 같은 내용을 오픈소스 정책에 포함한다.

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

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

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

1.4.3 지속적인 개선 수행

기업은 적용 범위를 지속적으로 검토하여 개선하고, 이를 문서화하여야 한다. 이를 위하여 다음의 예와 같은 내용을 오픈소스 정책에 포함한다.


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

이 가이드에서는 프로그램 범위 지정에 대한 예시를 [부록 1] 오픈소스 정책의 2. 적용 범위에서 제공한다.

1.5 라이선스 의무

오픈소스를 사용하면 각 라이선스가 부과하는 의무를 준수해야 한다. ISO/IEC 5230의 3.1.5항에서는 다음과 같이 각 오픈소스 라이선스가 부과하는 의무를 알아내기 위한 검토 프로세스를 요구한다.

ISO/IEC 5230

3.1.5 라이선스 의무

각 라이선스에 의해 부과된 의무, 제한 및 권리를 알아내기 위해 식별된 라이선스를 검토하는 프로세스가 있어야 한다.

입증 자료

  • 3.1.5.1 각 식별된 라이선스에 의해 부여된 의무, 제한 및 권리를 검토하고 기록하기 위한 문서화된 절차

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):

  • 3.1.5.1 A documented procedure to review and document the obligations, restrictions and rights granted by each identified license.

오픈소스의 사용 가능 여부를 판단하기 위해서는 먼저 사용하려는 오픈소스의 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무사항을 확인해야 한다. 오픈소스를 사용하였는지, 라이선스는 무엇인지, 각 라이선스가 부여하는 의무는 무엇인지 검토하고 기록해야 한다. 이를 위한 절차의 예는 다음과 같다.

  1. 오픈소스 프로그램 매니저는 오픈소스 정책에서 정의한 기준에 따라 라이선스를 예비 평가한다.
  2. 의문이 있는 경우, 오픈소스 프로그램 매니저는 외부 법률 전문가에게 자문을 요청한다.
  3. 모든 내외부의 결정 결과 및 관련 근거는 보관한다.

NIPA 산하 오픈소스 소프트웨어 통합지원센터인 오픈업에서 제공하는 “공개SW와 라이선스”(https://www.oss.kr/oss_license )에서는 주요 오픈소스 라이선스의 의무, 제한 및 권리를 설명하고 있다. 또한 SK텔레콤에서 공개한 오픈소스 가이드도 좋은 참고가 된다. : https://sktelecom.github.io/guide/use/license/

위에서 요구하는 “각 식별된 라이선스에 의해 부가된 의무, 제한 및 권리를 검토하고 기록하기 위한 문서화된 절차“는 [부록 2] 오픈소스 프로세스”의 오픈소스 식별 단계에 해당한다.

1.6 표준 사례 구현

ISO/IEC 18974의 3.1.5항에서는 다음과 같이 알려진 취약점 대응 및 강력한 보안 소프트웨어 개발을 위한 절차를 요구한다.

ISO/IEC 18974

3.1.5 표준 사례 구현

프로그램은 다음 절차를 정의하고 구현하여 알려진 취약점 및 보안 소프트웨어 개발을 건전하고 강력하게 처리하는 절차를 갖춘다.

  • 배포용 소프트웨어에 대한 구조적 및 기술적 위협을 식별하는 방법
  • 배포용 소프트웨어에서 알려진 취약점 존재 여부를 탐지하는 방법
  • 확인된 알려진 취약점에 대한 후속 조치 방법
  • 확인된 알려진 취약점을 보증 대상인 고객에게 알리는 방법
  • 배포용 소프트웨어의 릴리스 후 새롭게 알려진 취약점이 공개되었을 때 이미 배포된 소프트웨어에 존재하는지 확인하는 방법
  • 지속적이고 반복적인 보안 테스트가 출시 전에 모든 배포용 소프트웨어에 적용되기 위한 방법
  • 식별된 위험이 배포용 소프트웨어의 출시 전에 해결되었는지 확인하는 방법
  • 식별된 위험에 대한 정보를 제3자에게 적절하게 내보내는 방법

위에 나열된 보안 보증 방법에 대한 프로세스가 존재해야 한다.

입증 자료:

  • 3.1.5.1: 위에서 식별된 각 방법에 대한 문서화된 절차가 존재한다.

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:

  • Method to identify structural and technical threats to the Supplied Software is defined;
  • Method for detecting existence of Known Vulnerabilities in Supplied Software;
  • Method for following up on identified Known Vulnerabilities;
  • Method to communicate identified Known Vulnerabilities to customer base when warranted;
  • Method for analyzing Supplied Software for newly published Known Vulnerabilities post release of the Supplied Software;
  • Method for continuous and repeated Security Testing is applied for all Supplied Software before release;
  • Method to verify that identified risks will have been addressed before release of Supplied Software;
  • Method to export information about identified risks to third parties as appropriate.

A process shall exist for the Security Assurance methods listed above.

Verification Material(s):

  • 3.1.5.1: A documented procedure exists for each of the methods identified above.

따라서 기업은 제품/서비스를 개발하면서 오픈소스 보안 취약점을 탐지하고 해결하는 등 보안 보증을 위한 활동을 수행해야 한다. 이를 위해 기업은 배포용 소프트웨어에서 알려진 취약점 존재 여부를 탐지하고, 식별된 위험이 출시 전에 해결해야 할 뿐 아니라 출시 후 새롭게 알려진 취약점에 대응하기 위한 방법과 절차를 갖춰야 한다. 이에 대해서는 3.3 보안 보증 장에서 자세히 설명한다.

  1. OSPO - Open Source Program Office ↩︎

  2. OSRB - Open Source Review Board ↩︎ ↩︎

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

오픈소스 프로그램이 효과적으로 운용되기 위해서는 충분한 리소스와 인력 할당이 필요하다. 여기에서는 이를 위한 요구사항을 정의한다.

2.1 접근성

ISO/IEC 5230과 ISO/IEC 18974의 3.2.1항에서는 다음과 같이 접근성에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230

3.2.1 외부 문의 대응 (Access)

외부의 오픈소스 문의에 효과적으로 대응하기 위한 프로세스를 유지해야 한다. 제 3자가 오픈소스 컴플라이언스에 대해 문의 할 수 있는 방법을 공개해야 한다.

입증 자료:

  • 3.2.1.1 제 3자가 오픈소스 라이선스 컴플라이언스에 대해 문의 할 수 있는 공개된 방법 (담당자 이메일 주소, 또는 Linux Foundation의 Open Compliance Directory 활용 등)
  • 3.2.1.2 제 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):

  • 3.2.1.1 Publicly visible method that allows any third party to make an open source license compliance inquiry (e.g., via a published contact email address, or the Linux Foundation’s Open Compliance Directory).
  • 3.2.1.2 An internal documented procedure for responding to third party open source license compliance inquiries.

ISO/IEC 18974

3.2.1 - 외부 문의 대응

알려진 취약점에 대한 외부 문의에 효과적으로 대응하기 위한 프로세스를 유지해야 한다. 제3자가 특정 소프트웨어 제품과 관련하여 알려진 취약점에 대해 문의할 수 있는 방법을 공개해야 한다.

입증 자료:

  • 3.2.1.1: 제3자가 알려진 취약점 또는 새로 발견된 취약점에 대해 문의할 수 있는 공개된 방법 (예: 이메일 주소 또는 프로그램 참여자가 모니터링하는 웹 포털)
  • 3.2.1.2: 제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.2.1.1: Publicly visible method to allow third parties to make Known Vulnerability or Newly Discovered Vulnerability enquires (e.g., via an email address or web portal that is monitored by Program Participants);
  • 3.2.1.2: An internal documented procedure exists for responding to third party Known Vulnerability or Newly Discovered Vulnerability inquiries.

2.1.1 연락 담당자 지정

오픈소스를 사용하여 개발한 제품 혹은 서비스에 대해 고객 및 오픈소스 저작권자가 기업에 오픈소스 관련 문의, 요청 및 클레임을 제기하는 경우가 있다. 외부 문의 및 요청의 주된 내용은 다음과 같다.

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

기업은 이러한 외부 문의를 처리할 담당자를 지정해야 한다. 일반적으로 오픈소스 프로그램 매니저가 담당한다.

2.1.2 연락 담당자 정보 공개

외부의 오픈소스 개발자가 특정 기업의 오픈소스 컴플라이언스 관련 이슈를 논의하기 위해 기업 담당자에게 연락하고 싶어도 연락 방법을 찾지 못하다가 결국 바로 법적 클레임을 제기하는 경우가 있다. 이를 방지하기 위해 기업은 제 3자가 기업에 오픈소스 관련하여 문의 및 요청을 할 수 있는 연락 방법을 항시 공개적으로 밝혀야 한다.

외부에서 기업에 오픈소스 관련된 문의를 할 수 있는 연락 방법은 (1) 기업 오픈소스 프로그램 매니저의 이메일 주소를 공개하거나, (2) Linux Foundation의 Open Compliance Directory1를 이용하는 것이다. 기업 오픈소스 프로그램 사무소의 대표 이메일 주소는 제품 및 서비스와 동봉하는 오픈소스 고지문에 포함하여 공개하는 것도 한 방법이다.

Linux Foundation은 기업이 오픈소스 담당자의 연락처를 공개할 수 있도록 Open Compliance Directory라는 공간을 마련하였다.

directory.png

< https://compliance.linuxfoundation.org/references/open-compliance-directory/ >


기업의 오픈소스 담당자는 “Add an Organization"을 이용하여 기업의 연락처를 등록한다. 외부 개발자는 “Request a Contact"에서 오픈소스 컴플라이언스 관련 문의 및 요청을 할 수 있다. 이를 통해 오픈소스 개발자들은 원하는 기업의 컨택 포인트 정보를 쉽게 확인할 수 있고, 법적 클레임까지 제기하기 이전에 기업의 오픈소스 담당자와 오픈소스 컴플라이언스 이슈를 논의하여 문제를 해결할 수 있다. Open Compliance Directory에 기업 정보 및 연락 방법을 등록하는 것이 소송 리스크를 줄일 수 있는 방법의 하나다.

2.1.3 문의 대응 절차 문서화

기업이 외부 클레임에 의해 법적 소송까지 당하지 않기 위해서는 외부 문의 및 요청에 가능한 빠르고 정확하게 대응하는 것이 중요하다. 이를 위해 기업은 외부 오픈소스 문의를 빠르고 효과적으로 대응 할 수 있는 프로세스를 갖추고 있어야 한다.

위의 내용은 다음의 예시 문장을 오픈소스 정책에 반영할 수 있다.

9. 외부 문의 대응

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

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

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

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

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

또한 이 가이드에서는 외부 문의에 대응하기 위한 일반적인 절차에 대한 예시를 [부록 2] 오픈소스 프로세스의 3. 외부 문의 대응 프로세스에서 제공한다.

2.2 효과적인 리소스 제공

ISO/IEC 5230과 ISO/IEC 18974의 3.2.2항에서는 다음과 같이 효과적인 오픈소스 프로그램의 운영을 위한 리소스 제공에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230

3.2.2 효과적인 리소스 제공

프로그램이 효과적일 수 있도록 다음과 같이 업무를 정의하고 리소스를 제공해야 한다:

  • 프로그램을 성공적으로 수행할 수 있도록 각 업무에 대한 책임을 할당한다.
  • 프로그램의 업무를 위한 충분한 리소스를 제공한다.
    • 업무 수행 시간을 할당한다.
    • 예산을 적절하게 지원한다.
  • 정책 및 지원 업무를 검토하고 개선하는 프로세스가 존재한다.
  • 오픈소스 라이선스 컴플라이언스와 관련된 전문 법률 자문을 이용 할 수 있게 한다.
  • 오픈소스 라이선스 컴플라이언스 문제를 해결하기 위한 프로세스가 존재한다.

입증 자료:

  • 3.2.2.1 프로그램 내 각 역할을 담당하는 인원, 그룹 또는 직무의 이름을 기재한 문서
  • 3.2.2.2 프로그램 내 각 역할을 담당하는 인원이 적합하게 배치되고, 예산이 적절하게 지원되어야 한다.
  • 3.2.2.3 오픈소스 라이선스 컴플라이언스 문제 해결을 위해 내부 또는 외부의 전문 법률 자문을 이용하는 방법
  • 3.2.2.4 오픈소스 컴플라이언스에 대한 내부 책임을 할당하는 문서화된 절차
  • 3.2.2.5 미준수 사례를 검토하고 이를 수정하기 위한 문서화된 절차

3.2.2 Effectively resourced

Identify and Resource Program Task(s):

  • Assign accountability to ensure the successful execution of program tasks.
  • Program tasks are sufficiently resourced:
    • Time to perform the tasks have been allocated; and
    • Adequate funding has been allocated.
  • A process exists for reviewing and updating the policy and supporting tasks;
  • Legal expertise pertaining to open source license compliance is accessible to those who may need such guidance; and
  • A process exists for the resolution of open source license compliance issues.

Verification material(s):

  • 3.2.2.1 Document with name of persons, group or function in program role(s) identified.
  • 3.2.2.2 The identified program roles have been properly staffed and adequate funding provided.
  • 3.2.2.3 Identification of legal expertise available to address open source license compliance matters which could be internal or external.
  • 3.2.2.4 A documented procedure that assigns internal responsibilities for open source compliance.
  • 3.2.2.5 A documented procedure for handling the review and remediation of non-compliant cases.

ISO/IEC 18974

3.2.2 - 효과적인 리소스 제공

프로그램이 효과적일 수 있도록 다음과 같이 업무를 정의하고 리소스를 제공해야 한다:

  • 프로그램을 성공적으로 수행할 수 있도록 각 업무에 대한 책임을 할당한다.
  • 프로그램의 업무를 위한 충분한 리소스를 제공한다.
  • 업무를 수행하기에 충분한 시간을 할당한다.
  • 예산을 적절하게 지원한다.
  • 정책 및 지원 업무를 검토하고 개선하는 프로세스가 존재한다.
  • 알려진 취약점과 관련된 전문 기술 자문을 이용할 수 있게 한다.

입증 자료:

  • 3.2.2.1: 프로그램 내 각 역할을 담당하는 인원, 그룹 또는 직무의 이름을 기재한 문서
  • 3.2.2.2: 프로그램 내 각 역할을 담당하는 인원이 적합하게 배치되고, 예산이 적절하게 지원되어야 한다.
  • 3.2.2.3: 식별된 알려진 취약점을 해결을 위해 전문 기술 자문을 이용할 수 있는 방법
  • 3.2.2.4: 보안 보증에 대한 내부 책임을 할당하는 문서화된 절차

3.2.2 - Effectively Resourced

Identify and Resource Program Task(s):

  • Assign accountability to ensure the successful execution of Program tasks;
  • Program tasks are sufficiently resourced;
  • Sufficient time to perform the tasks have been allocated;
  • Adequate funding has been allocated;
  • A process exists for reviewing and updating the policy and supporting tasks;
  • Technical expertise pertaining to Known Vulnerabilities is accessible to those who may need such guidance.

Verification Material(s):

  • 3.2.2.1: Document with name of persons, group or function in Program role(s) identified;
  • 3.2.2.2: The identified Program roles have been properly staffed and adequate funding provided;
  • 3.2.2.3: Identification of expertise available to address identified Known Vulnerabilities;
  • 3.2.2.4: A documented procedure that assigns internal responsibilities for Security Assurance.

2.2.1 각 역할 담당자 문서화

기업은 각 프로그램 참여자의 역할 및 그에 따른 책임을 나열하고, 각 역할을 담당하는 담당자 혹은 담당 조직을 지정해야 한다. 그리고 이를 문서화하고 오픈소스 정책 문서에 포함해서 누구나 열람할 수 있게 해야 한다. 다음의 예시를 참고하라.

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

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

- 오픈소스 프로그램 매니저는 회사의 비즈니스 상황에 맞추어 주기적으로 명단을 업데이트합니다.

2.2.2 인원과 예산 지원

기업은 오픈소스 프로그램이 원활하게 기능을 수행할 수 있도록 충분한 리소스를 제공해야 한다. 프로그램 내 각 역할을 담당하는 인원을 적합하게 배치하고, 충분한 예산과 업무 시간을 보장해야 한다. 그렇지 않을 경우, 이를 보완할 수 있는 절차가 마련되어야 한다. 다음의 예시 문장을 오픈소스 정책 문서에 추가할 수 있다.

4. 역할, 책임 및 역량

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

2.2.3 외부 전문 자문 이용 방법 제공

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


4. 역할, 책임 및 역량

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

- 구성원이 오픈소스 관련 자문을 받는 방법을 제공합니다.

참고로, OpenChain 프로젝트에서는 파트너 프로그램을 통해 오픈소스 관련 자문을 제공하는 글로벌 법무법인 리스트를 제공한다.

partners.png

< https://www.openchainproject.org/partners >

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

2.2.4 내부 책임 할당 절차 문서화

오픈소스 컴플라이언스와 보안 보증에 대한 내부 책임을 할당하는 절차가 있어야 한다. 오픈소스 프로그램 매니저와 보안담당자는 이슈를 파악하고 각 역할의 담당자에게 적절히 이슈를 할당해야 한다. 이를 위해 기업은 오픈소스 정책 문서에 이러한 내용을 아래와 같이 기술할 수 있다.

4. 역할, 책임 및 역량

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

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

- 오픈소스 컴플라이언스를 위해 필요한 역할을 정의하고, 각 역할을 책임질 담당 조직 및 담당자를 지정합니다. 필요 시 OSRB와 협의합니다. 오픈소스 보안 보증을 위한 내부 책임은 보안 담당자가 할당합니다.

2.2.5 미준수 사례 검토 및 수정 절차 문서화

기업은 오픈소스 정책 문서에 위의 내용을 기술하여 오픈소스 프로그램에 효과적인 리소스가 제공될 수 있도록 해야 한다.

컴플라이언스 미준수 문제가 제기된 경우, 기업은 이를 신속히 검토하고 대응하기 위한 절차를 문서화해야 한다. 다음의 예시를 참고하여 오픈소스 정책에 포함할 수 있다.

6. 오픈소스 사용

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

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

이 가이드에서는 효과적인 리소스 제공에 대한 예시를 [부록 01] 샘플 오픈소스 정책의 4. 역할, 책임 및 역량에서 제공한다.

  1. Open Compliance Directory - https://compliance.linuxfoundation.org/references/open-compliance-directory/ ↩︎

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

3.1 SBOM (Software Bill of Materials)

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.1 배포용 소프트웨어를 구성하는 오픈소스 컴포넌트에 대한 정보를 식별, 추적, 검토, 승인 및 보관하는 문서화된 절차
  • 3.3.1.2 문서화된 절차가 적절히 준수되었음을 보여주는 배포용 소프트웨어에 대한 오픈소스 컴포넌트 기록

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):

  • 3.1.1.1 A documented procedure for identifying, tracking, reviewing, approving, and archiving information about the collection of open source components from which the supplied software is comprised.
  • 3.3.1.2 Open source component records for the supplied software that demonstrates the documented procedure was properly followed.

ISO/IEC 18974

3.3.1 - SBOM (Software Bill of Materials)

배포용 소프트웨어를 구성하는 각 오픈소스 소프트웨어 컴포넌트 내역을 포함하는 BOM(Bill of Materials)을 생성하고 이를 유지하는 프로세스가 있어야 한다.

입증 자료:

  • 3.3.1.1: 배포용 소프트웨어에 사용된 모든 오픈소스 소프트웨어가 배포용 소프트웨어의 수명 주기 동안 지속적으로 기록되도록 하는 문서화된 절차. 여기에는 배포용 소프트웨어에 사용된 모든 오픈소스 소프트웨어의 저장소도 포함된다.
  • 3.3.1.2: 문서화된 절차가 적절히 준수되었음을 보여주는 배포용 소프트웨어에 대한 오픈소스 소프트웨어 컴포넌트 기록

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):

  • 3.3.1.1: A documented procedure ensuring all Open Source Software used in the Supplied Software is continuously recorded across the lifecycle of the Supplied Software. This includes an archive of all Open Source Software used in the Supplied Software;
  • 3.3.1.2: Open Source Software Component Records for the Supplied Software that demonstrates the documented procedure was properly followed.

3.1.1 SBOM 관리 절차 문서화

오픈소스 관리 활동의 가장 기본은 배포용 소프트웨어에 포함된 오픈소스 현황을 파악하는 것이다. 배포용 소프트웨어에 포함된 오픈소스와 그 라이선스를 식별하여 그 정보를 담고 있는 SBOM(Software Bill of Materials)을 작성하고 관리하는 프로세스를 구축해야 한다. 배포용 소프트웨어의 버전마다 어떤 오픈소스가 포함되어 있는지 알고 있어야 소프트웨어를 배포할 때 각 오픈소스의 라이선스가 요구하는 의무 사항을 준수할 수 있기 때문이다.

모든 오픈소스는 배포용 소프트웨어에 통합하기 전에 검토 및 승인되어야 한다. 오픈소스의 기능, 품질뿐만 아니라 출처, 라이선스 요건을 충족할 수 있는지 사전 검토가 되어야 한다. 이를 위해 검토 요청 → 리뷰 → 승인 과정이 필요하다. [부록 02] 오픈소스 프로세스에서는 기업의 오픈소스 관리를 위한 프로세스 모든 과정에 관해 설명하고 있다.

1. 오픈소스 식별부터 6. 등록까지의 과정을 통해 SBOM을 작성하고 관리하게 된다.

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

3.1.2 SBOM 기록

배포용 소프트웨어에 포함된 오픈소스 목록은 문서화하여 보관해야 한다. Eclipse 재단에서 후원하는 오픈소스 프로젝트인 SW3601은 배포용 소프트웨어별로 포함하고 있는 오픈소스 목록을 트래킹할 수 있는 기능을 제공한다. SW360 사용 방법은 부록 3. 오픈소스 도구을 참고할 수 있다.

이 가이드에서는 SBOM 사용 정책에 대한 예시를 “[부록 1] 샘플 오픈소스 정책의 6. 오픈소스 사용에서 제공한다.

3.2 라이선스 컴플라이언스

ISO/IEC 5230의 3.3.2항에서는 다음과 같이 라이선스 컴플라이언스에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230

3.3.2 라이선스 컴플라이언스

프로그램은 배포용 소프트웨어에 대해 프로그램 참여자가 접할 수 있는 일반적인 오픈소스 라이선스의 사용 사례를 관리할 수 있어야 한다. 여기에는 다음과 같은 사용 사례가 포함될 수 있다(아래 목록이 모든 사례를 다루는 것은 아니며, 또한 이 사례를 모두 다뤄야만 하는 것은 아님). :

  • 바이너리 형태로 배포
  • 소스 형태로 배포
  • 추가 라이선스 의무를 유발하는 다른 오픈소스와 통합
  • 수정된 오픈소스 포함
  • 배포용 소프트웨어 내의 다른 컴포넌트와 서로 호환되지 않는 라이선스 하의 오픈소스 또는 다른 소프트웨어를 포함
  • 저작자 표시 요구사항을 갖는 오픈소스 포함

입증 자료:

  • 3.3.2.1 배포용 소프트웨어 내의 오픈소스 컴포넌트에 대해 일반적인 오픈소스 라이선스 사용 사례를 처리하기 위한 문서화된 절차

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):

  • 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.

Verification Material(s):

  • 3.3.2.1 A documented procedure for handling the common open source license use cases for the open source components of the supplied software.

오픈소스 라이선스를 제대로 준수하기 위해서는 오픈소스 라이선스별로 요구하는 사항에 대해 정확히 알고 있어야 한다. 하지만 개별 소프트웨어 개발자가 이를 일일이 파악하는 것은 어려우므로 오픈소스 책임자는 자주 사용되는 오픈소스 라이선스에 대해 일반적인 사용 사례별 요구사항/주의사항을 정리하여 회사 내부에 공유하는 것이 좋다. 오픈소스 라이선스에 대한 일반적인 가이드와 라이선스 의무 요약 자료는 NIPA에서 제공하는 공개소프트웨어 라이선스 가이드2를 참고할 수 있다. 또한, 소프트웨어의 사용 사례별 라이선스 의무를 분석한 SK텔레콤의 오픈소스 라이선스 가이드3도 좋은 사례가 된다.

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

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

3.3 보안 보증

ISO/IEC 18974 표준은 다음과 같이 보안 보증 방법에 대한 문서화된 절차와 수행된 조치를 기록하도록 요구한다.

ISO/IEC 18974

3.3.2 - 보안 보증

  • 검토 중인 배포용 소프트웨어 릴리스에 대한 BOM의 각 오픈소스 소프트웨어 컴포넌트에 대해 다음 사항을 확인한다.
  • 알려진 취약점의 존재를 발견하기 위한 방법을 적용한다.
  • 각각의 발견된 취약점과 할당된 점수에 대해 소프트웨어의 사용 사례에 적합하게 필요한 수정 단계를 결정 및 문서화하고 이전에 결정된 수준 이상(즉, 심각도 점수 4.5 이상인 모든 경우 등)에서는 고객 동의를 얻는다.
  • 위험/영향 점수에 따라 적절한 조치를 취한다(예: 필요한 경우 고객에게 연락, 소프트웨어 컴포넌트 업그레이드, 추가 조치 없음 등).
  • 새로 발견된 취약점이 이전에 배포된 배포용 소프트웨어에 있는 경우 위험/영향 점수에 따라 적절한 조치를 취한다(예: 보증이 필요한 고객에게 연락).
  • 배포용 소프트웨어가 시장에 출시된 후 모니터링하고 알려진 취약점 또는 새로 발견된 취약점 노출에 대응하는 기능을 확보한다.

입증 자료:

  • 3.3.2.1: 배포용 소프트웨어의 오픈소스 소프트웨어 컴포넌트에 대한 알려진 취약점의 탐지 및 해결을 위한 문서화된 절차
  • 3.3.2.2: 각 오픈소스 소프트웨어 컴포넌트에 대해 식별된 알려진 취약점 및 수행된 조치에 대한 기록을 유지한다(조치가 필요하지 않은 경우도 포함).

3.3.2 - Security Assurance

  • For each Open Source Software component in the bill of materials for the Supplied Software release under review;
  • Apply method for detecting existence of Known Vulnerabilities;
  • For each identified Known Vulnerability assign a risk/impact score;
  • For each detection and assigned score determine and document necessary remediation steps suitable for the use-case of the software and get Customer Agreement at or above a previously determined level (i.e., all severity scores above 4.5 …);
  • Depending on the risk/impact score take the appropriate action (e.g., contact customers if necessary, upgrade software component, no further action, …);
  • If a Newly Discovered Vulnerability is present in previously distributed Supplied Software, depending on the risk/impact score take the appropriate action (e.g., contact customers if warranted);
  • An ability to monitor Supplied Software after their release to market and to respond to Known Vulnerability or Newly Discovered Vulnerability disclosures.

Verification Material(s):

  • 3.3.2.1: A documented procedure for handling detection and resolution of Known Vulnerabilities for the Open Source Software components of the Supplied Software;
  • 3.3.2.2: For each Open Source Software component a record is maintained of the identified Known Vulnerabilities and action(s) taken (including even if no action was required).

이를 위해 기업은 배포용 소프트웨어에서 알려진 취약점 존재 여부를 탐지하고, 식별된 위험이 출시 전에 해결해야 할 뿐 아니라 출시 후 새롭게 알려진 취약점에 대응하기 위한 방법과 절차를 갖춰야 한다.

먼저 기업은 배포용 소프트웨어에 알려진 취약점이 있는지 탐지하고, 식별된 위험을 출시 전에 해결해야 합니다. 이와 같이 알려진 취약점을 탐지하고 해결하는 절차는 오픈소스 프로세스의 오픈소스 식별 단계, 소스 코드 검사 단계, 문제 해결 단계를 통해 수행할 수 있다.

그리고, 배포용 소프트웨어의 릴리스 후 새롭게 알려진 취약점이 공개되었을 때 이미 배포된 소프트웨어에 존재하는지 확인하고, 해결하기 위해서는 신규 보안 취약점 대응 프로세스를 수립해야 한다. 2. 신규 보안취약점 대응 프로세스 샘플은 부록 2. 오픈소스 프로세스의 2. 신규 보안취약점 대응 프로세스에서 확인할 수 있다.

  1. SW360 - https://projects.eclipse.org/proposals/sw360 ↩︎

  2. NIPA 공개소프트웨어 라이선스 가이드 - https://www.oss.kr/oss_license ↩︎

  3. SK텔레콤 오픈소스 라이선스 가이드 - https://sktelecom.github.io/guide/use/obligation/gpl-2.0/ ↩︎

  4. FOSSology - http://fossology.org/ ↩︎

3.2.4 - 4. 컴플라이언스 산출물 생성 및 제공

4.1 컴플라이어스 산출물

ISO/IEC 5230의 3.4.1항에서는 다음과 같이 컴플라이언스 산출물에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230

3.4.1 컴플라이언스 산출물

배포용 소프트웨어에 대한 컴플라이언스 산출물을 생성하는 프로세스가 있어야 한다.

입증 자료:

  • 3.4.1.1 식별된 라이선스가 요구하는 컴플라이언스 산출물을 준비하고, 이를 배포용 소프트웨어와 함께 제공하기 위한 프로세스를 설명하는 문서화된 절차
  • 3.4.1.2 배포용 소프트웨어의 컴플라이언스 산출물 사본을 보관하기 위한 문서화된 절차
    • 산출물 사본은 배포용 소프트웨어의 마지막 배포 이후 합리적인 기간 동안 혹은 식별된 라이선스에서 요구하는 기간 동안 보관해야 한다(둘 중 더 긴 기간을 따름).
    • 이러한 절차가 올바르게 수행되었음을 입증하는 기록이 존재해야 한다.

3.4.1 Compliance artifacts

A process shall exist for creating the set of compliance artifacts for the supplied software.

Verification Materials(s):

  • 3.4.1.1 A documented procedure that describes the process under which the compliance artifacts are prepared and distributed with the supplied software as required by the identified licenses.
  • 3.4.1.2 A documented procedure for archiving copies of the compliance artifacts of the supplied software - where the archive is planned to exist for a reasonable period of time (determined by domain, legal jurisdiction and/or customer contracts) since the last offer of the supplied software; or as required by the identified licenses (whichever is longer). Records exist that demonstrate the procedure has been properly followed.

4.1.1 컴플라이언스 산출물 생성 / 제공 절차 문서화

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

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

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

이 가이드에서는 컴플라이언스 산출물 생성을 위한 정책에 대한 예시를 “부록 1. 샘플 오픈소스 정책의 6. 오픈소스 사용”에서 제공한다.

컴플라이언스 산출물은 배포용 소프트웨어를 배포할 때 함께 제공해야 한다. “부록 2. 샘플 오픈소스 컴플라이언스 프로세스”의 고지, 배포 전 확인, 배포 단계를 통해 컴플라이언스 산출물을 생성하여 배포한다.

4.1.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 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.

< https://www.softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed.html >

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

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

5.1 기여

ISO/IEC 5230의 3.5.1항에서는 다음과 같이 컴플라이언스 산출물에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230

3.5.1 기여

조직이 외부 오픈소스 프로젝트로의 기여를 허용하려고 한다면,

  • 외부 오픈소스 프로젝트로의 기여를 관리하는 문서화된 정책이 있어야 한다.
  • 이 정책이 내부에 전파되어야 한다.
  • 정책을 시행하는 프로세스가 있어야 한다.

입증 자료:

조직이 외부 오픈소스 프로젝트로의 기여를 허용하는 경우, 다음 사항이 있어야 한다.:

  • 3.5.1.1 문서화된 오픈소스 기여 정책
  • 3.5.1.2 오픈소스 기여를 관리하는 문서화된 절차
  • 3.5.1.3 모든 프로그램 참여자가 오픈소스 기여 정책의 존재를 인식하도록 하는 문서화된 절차 (예: 교육, 내부 위키, 또는 기타 실질적인 전달 방법 등)

3.5.1 Contributions

If an organization considers contributions to open source projects, then

  • a written policy shall exist that governs contributions to open source projects;
  • the policy shall be internally communicated; and
  • a process shall exist that implements the policy

Verification Materials(s):

If an organization permits contributions to open source projects, then the following shall exist:

  • 3.5.1.1 A documented open source contribution policy;
  • 3.5.1.2 A documented procedure that governs open source contributions; and
  • 3.5.1.3 A documented procedure that makes all program participants aware of the existence of the open source contribution policy (e.g., via training, internal wiki, or other practical communication method).

5.1.1 오픈소스 기여 정책

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

이러한 오픈소스 기여에 대한 정책은 “부록 1. 샘플 오픈소스 정책의 7. 오픈소스 기여“를 참고할 수 있다.

5.1.2 오픈소스 기여 절차 문서화

외부 오픈소스 프로젝트에 기여를 허용하는 정책을 갖고 있다면, 사내 개발자들이 어떤 절차로 외부 프로젝트에 기여할 수 있을지 관리하는 문서화된 절차가 있어야 한다. SK텔레콤에서 공개한 오픈소스 기여 절차[^skt-contribution]는 좋은 예이다.

5.1.3 오픈소스 기여 정책 인식 절차 문서화

오픈소스 기여 정책을 만들었다 해도 사내 구성원이 이에 대한 존재를 알지 못한다면 무용지물이 되어버린다. 모든 사내 개발자가 오픈소스 기여 정책의 존재를 알 수 있게 하는 절차가 필요하다. 3.1.1.2에서의 오픈소스 정책 전파 활동과 병행하여 오픈소스 기여 정책을 전파하라.

3.2.6 - 6. 규격 요구사항 준수

6.1 적합성

ISO/IEC 5230의 3.6.1항과 과 ISO/IEC 18974의 3.4.1항에서는 다음과 같이 적합성에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230

3.6.1 적합성

프로그램이 OpenChain에 적합하다고 간주하기 위해서는 조직은 프로그램이 이 규격에서 제시한 모든 요구사항을 충족하는지 확인해야 한다.

입증 자료:

  • 3.6.1.1 3.1.4조에서 명시한 프로그램이 이 규격의 모든 요구사항을 충족함을 확인하는 문서

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):

  • 3.6.1.1 A document affirming the program specified in §3.1.4 satisfies all the requirements of this document.

ISO/IEC 18974

3.4.1 - 완전성 프로그램이 이 규격을 준수하는 것으로 간주되기 위해서, 조직은 프로그램이 이 문서에 제시된 요구사항을 충족한다는 것을 확인해야 한다.

입증 자료:

  • 3.4.1.1: §3.1.4에 명시된 프로그램이 이 문서의 모든 요구 사항을 충족함을 확인하는 문서화된 증거.

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):

  • 3.4.1.1: Documented Evidence affirming the Program specified in §3.1.4 satisfies all the requirements of this document.

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을 준수함을 보장합니다.

6.2 지속 기간

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.1 프로그램이 적합성 인증을 획득한 후 지난 18개월 동안 이 규격 버전(v2.1)의 모든 요구사항을 충족하고 있음을 확인하는 문서

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):

  • 3.6.2.1 A document affirming the program meets all the requirements of this document, within the past 18 months of obtaining conformance validation.

ISO/IEC 18974

3.4.2 - 지속 기간

이 버전의 규격을 준수하는 프로그램은 다음의 시기마다 다시 검토가 되어야 한다. : 1차 인증일로부터 18개월, 2차 인증일로부터 24개월, 3차 인증일로부터 36개월. 이후에는 36개월마다 검토가 필요하다.

입증 자료:

  • 3.4.2.1: 프로그램이 적합성 인증을 획득한 후 지난 18개월 동안 이 규격의 모든 요구사항을 충족하고 있음을 확인하는 문서

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):

  • 3.4.2.1: A document affirming the Program meets all the requirements of this specification, within the past 18 months of obtaining conformance validation.

기업은 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의 모든 요구사항을 충족하게 된다.

4 - Templates

오픈소스 정책, 오픈소스 프로세스 등 기업이 오픈소스 관리를 위해 필요한 문서 템플릿을 제공합니다.

4.1 - 오픈소스 정책

1. 목적

(1) 정책의 목적

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

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

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

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

(2) 미준수 시 영향

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

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

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

(3) 구성원의 기여 방법

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

2. 적용 범위

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

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

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

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

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

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

3. 용어

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

4. 역할, 책임 및 역량

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

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

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

(1) OSRB

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

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

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

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

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

(3) OSPO

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

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

(4) 법무 담당

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

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

(5) IT 담당

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

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

(6) 보안 담당

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

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

(7) 개발 문화 담당

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

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

(8) 품질 담당

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

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

5. 교육 및 평가

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

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

6. 오픈소스 사용

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(4) SBOM (Bill of Materials) 생성

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

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

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

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

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

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

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

7. 오픈소스 기여

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

(1) 리뷰 요청 및 승인

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

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

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

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

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

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

(3) 지식 재산 노출 주의

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

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

(4) CLA 서명 주의

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

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

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

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

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

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

(5) 저작권 표시

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

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

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

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

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

(6) 회사 이메일 사용

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

8. 오픈소스 공개

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

(1) 승인

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

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

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

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

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

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

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

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

(4) 유용한 코드 공개

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

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

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

(5) 리소스 확보

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

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

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

(6) 회사 이메일 사용

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

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

9. 외부 문의 대응

(1) 외부 문의 대응 책임

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

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

(2) 연락처 공개

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

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

(3) 외부 문의 대응 절차

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

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

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

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

Appendix 1. 담당자 현황

No역할책임필요 역량담당 조직담당자
1Open Source Program Manager회사의 오픈소스 프로그램에 대한 총괄 책임을 담당한다.1. 소프트웨어 개발 프로세스 이해
2. 저작권, 특허 등 오픈소스 라이선스와 관련한 지식재산 이해
3. 오픈소스 컴플라이언스에 대한 전문 지식
4. 오픈소스 개발 경험
5. 커뮤니케이션 스킬		CTOOOO
2법무 담당오픈소스 라이선스와 의무를 해석한다. 이러한 의무를 실제 이행하는 등 오픈소스 활용을 위해 발생할 수 있는 법적 위험의 완화를 위한 자문을 제공한다.1. 오픈소스 생태계에 대한 기본 지식
2. 소프트웨어 저작권에 대한 전문 지식
3. 오픈소스 라이선스에 대한 전문 지식		법무팀OOO
3IT 담당오픈소스 분석 도구를 운영하고 자동화하여 모든 배포용 소프트웨어에 대해 오픈소스 분석이 원활히 수행되도록 시스템을 구축한다.1. 오픈소스 컴플라이언스 프로세스에 기본 지식
2. 오픈소스 분석 도구에 대한 이해
3. IT 인프라에 대한 전문 지식		IT 인프라팀OOO
4보안 담당오픈소스 보안취약점 분석 도구를 운영하여 모든 배포용 소프트웨어에 대해 보안취약점 분석이 수행되도록 시스템을 구축하고 발견된 보안취약점이 기준에 맞게 보완되도록 조치한다.1. DevSecOps에 대한 폭넓은 이해
2. 오픈소스 보안취약점 분석 도구에 대한 이해
3. 오픈소스 보안취챡점에 대한 전문 지식
43. 커뮤니케이션 스킬		보안팀OOO
5개발 문화 담당사내 개발자들이 오픈소스를 적극적으로 활용하고 사내외 커뮤니티에 참여하여 선진 개발 문화를 습득할 수 있도록 지원한다.1. 소프트웨어 개발 프로세스 이해
2. 오픈소스 컴플라이언스에 대한 기본 지식
3. 오픈소스 정책에 대한 이해		DROOO
6사업 부서소프트웨어 개발/배포 조직은 올바른 오픈소스 활용을 위해 오픈소스 정책 및 프로세스를 준수한다.1. 소프트웨어 개발 프로세스 이해
2. 오픈소스 컴플라이언스에 대한 기본 지식
3. 오픈소스 정책에 대한 이해
4. 오픈소스 라이선스에 대한 기본 지식		개발팀전원

4.2 - 오픈소스 프로세스

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

1. 오픈소스 프로세스

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

process

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RiskCVSS 2.0CVSS 3.0조치 권고 일정
Low0.0 - 3.90.0 - 3.9-
Medium4.0 - 6.94.0 - 6.9-
Hgh7.0 - 10.07.0 - 8.94주 이내
Critical-9.0 - 10.01주 이내

(3) 문제 해결Resolving Issues

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

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

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

(4) 검토Reviews

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

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

(5) 승인Approval

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

(6) 등록Registration

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

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

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

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

(7) 고지Notices

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

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

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

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

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

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

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

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

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

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

(9) 배포Distribution

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

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

(10) 최종 확인Final Verifications

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

(11) 모니터링Monitoring

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

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

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

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

(1) 모니터링

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

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

(2) 초기 대응

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

RiskCVSS 2.0CVSS 3.0조치 권고 일정
Low0.0 - 3.90.0 - 3.9-
Medium4.0 - 6.94.0 - 6.9-
Hgh7.0 - 10.07.0 - 8.94주 이내
Critical-9.0 - 10.01주 이내

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

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

(3) 문제 해결

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

(4) 검토

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

(5) 승인

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

(6) 등록

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

(7) 고지

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

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

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

(8) 배포

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

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

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

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

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

general-inquiry-process

(1) 접수 알림Acknowledge

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

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

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

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

(2) 조사 알림Inform

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

(3) 내부 조사Investigate

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

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

(4) 요청자에게 보고Report

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

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

(5) 문제 보완 / 알림Rectify

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

(6) 문제 해결 알림Report

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

(7) 프로세스 개선Improve

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

5 - Tools

오픈소스 관리를 위해 필요한 오픈소스 도구를 소개하고 사용법을 안내합니다.

5.1 - FOSSology

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

https://www.fossology.org/

< https://www.fossology.org/ >

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 정보는 어떻게 되는지를 간단히 확인할 수 있다.

5.2 - SW360

(Updated on August 29, 2023.)

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

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

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

https://www.eclipse.org/sw360/

< https://www.eclipse.org/sw360/ >

주요 특징

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

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

https://www.eclipse.org/sw360/

설치

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

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

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

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

  1. Docker를 통해 Deploy 할 수 있다. : https://github.com/eclipse-sw360/sw360/blob/main/README_DOCKER.md
  2. SW360의 구성요소를 개별적으로 설치할 수 있다. : https://github.com/eclipse/sw360
  3. Vagrant (https://www.vagrantup.com/) 기반 설치 : Vagrant는 가상화 인스턴스를 관리하는 도구로서 sw360vagrant에서는 SW360을 한 번에 Deploy 하기 위한 환경을 제공한다. : https://github.com/sw360/sw360vagrant
    • Vagrant 기반 설치 가이드는 여기에서 확인할 수 있다. (단, 가이드 작성 시점과 현재 코드가 상이하여 정상동작하지 않을 가능성이 있습니다.)

이 가이드에서는 Docker로 Deploy하는 방법을 소개한다. 자세한 사항은 README를 참고한다. : https://github.com/eclipse-sw360/sw360/blob/main/README_DOCKER.md

1. 코드 다운로드

Docker Image 빌드를 위해 코드를 다운로드 한다. 테스트가 완료된 코드는 여기서 받을 수 있다. : https://github.com/haksungjang/sw360/tree/docker_build

git clone -b docker_build https://github.com/haksungjang/sw360.git

2. 빌드

먼저 Docker를 설치한다. (기업 개발자가 사용하려면 유료 구매가 필요할 수 있음에 주의하세요.)

아래와 같이 docker_build.sh를 실행하여 빌드한다.

cd sw360
./docker_build.sh

정상적으로 빌드가 완료되면 아래와 같이 생성된 이미지를 확인할 수 있다.

docker image ls

REPOSITORY                       TAG              IMAGE ID       CREATED          SIZE
eclipse-sw360/sw360              18-development   ab0fd848bf80   8 minutes ago    2.95GB
eclipse-sw360/sw360              latest           ab0fd848bf80   8 minutes ago    2.95GB
ghcr.io/eclipse-sw360/sw360      18-development   ab0fd848bf80   8 minutes ago    2.95GB
ghcr.io/eclipse-sw360/sw360      latest           ab0fd848bf80   8 minutes ago    2.95GB
eclipse-sw360/binaries           18-development   aa7debf0a1fc   8 minutes ago    347MB
eclipse-sw360/binaries           latest           aa7debf0a1fc   8 minutes ago    347MB
ghcr.io/eclipse-sw360/binaries   18-development   aa7debf0a1fc   8 minutes ago    347MB
ghcr.io/eclipse-sw360/binaries   latest           aa7debf0a1fc   8 minutes ago    347MB
eclipse-sw360/base               18-development   e5147733fc88   37 minutes ago   1.52GB
eclipse-sw360/base               latest           e5147733fc88   37 minutes ago   1.52GB
ghcr.io/eclipse-sw360/base       18-development   e5147733fc88   37 minutes ago   1.52GB
ghcr.io/eclipse-sw360/base       latest           e5147733fc88   37 minutes ago   1.52GB
ghcr.io/eclipse-sw360/thrift     0.18.1           0012d7998058   4 weeks ago      152MB
ghcr.io/eclipse-sw360/thrift     latest           0012d7998058   4 weeks ago      152MB
eclipse-sw360/thrift             0.18.1           0012d7998058   4 weeks ago      152MB
eclipse-sw360/thrift             latest           0012d7998058   4 weeks ago      152MB

3. 실행

docker-compose up 명령으로 생성된 이미지를 실행한다.

docker-compose up

정상적으로 실행이 완료되면 아래와 같이 세개의 container가 실행된 것을 볼 수 있다.

docker ps 

CONTAINER ID   IMAGE                 COMMAND                  CREATED         STATUS                   PORTS                                              NAMES
4299fd39010c   eclipse-sw360/sw360   "/app/entry_point.sh"    3 minutes ago   Up 3 minutes             0.0.0.0:8080->8080/tcp, 0.0.0.0:11311->11311/tcp   sw360
13fd5696b140   postgres:14           "docker-entrypoint.s…"   3 minutes ago   Up 3 minutes (healthy)   0.0.0.0:5438->5432/tcp                             sw360-postgresdb-1
7bb70f2daaf4   couchdb               "tini -- /docker-ent…"   3 minutes ago   Up 3 minutes (healthy)   4369/tcp, 9100/tcp, 0.0.0.0:5984->5984/tcp         sw360-couchdb-1

이 상태에서 http://localhost:8080/로 접근하면 다음과 같은 화면에 진입한다.

설정

SW360을 정상적으로 설치한 후에는 아래의 절차대로 초기 설정이 필요하다. 자세한 내용은 여기에서 확인할 수 있다. : SW360 Initial Setup Configuration

1. User, Login 설정

설정을 위해 다음 계정으로 로그인한다.

로그인을 하면 아래와 같이 Not Found라는 표시가 나타나게 된다.

화면 우상단의 아이템 아이콘(큐브 모양)을 클릭하고 Control Panel 탭을 선택한다.

SECURITY > Password Policies > Default Password Policy > PASSWORD CHANGES > Change Requried를 활성화한다.

그리고, 다시 Control Panel탭에서 CONFIGURATION > Instance Settings을 선택한다. 그러면, PLATFORM메뉴를 볼 수 있다.

거기서 Users를 선택한다. 그리고, Default User Associations 메뉴로 진입하고, Apply to Existing Users를 체크한다. 그리고 Save한다.

이번에는 Instance Settings > PLATFORM에서 User Authentication를 선택한다. General로 진입하여 모든 항목을 Uncheck한다. (관리 목적상 필요한 항목은 Check하여 활성화할 수 있다.) 그리고 Save한다.

끝으로, jquery와 font awesome을 활성화시켜야 한다. 이를 위해 Control Panel 탭에서 CONFIGURATION > System Settings으로 진입하면 PLATFORM 하위에 Third Party를 볼 수 있다.

Third Party에 진입하여 JQuery와 Font Awesome을 각각 Enable시킨다.

브라우저를 새로 실행하면 변경 사항이 적용된다.

2. LAR 파일 import

SW360 설정을 위해서는 *.lar 파일들을 import해야 한다. 이를 설정하기 위해서는 메뉴로 진입해야 하는데, 메뉴 버튼은 화면 좌측 상단에 있다.

메뉴에서 Publishing > Import에 진입한다.

우측의 + 버튼을 눌러 LAR 파일을 업로드 할 수 있는데, LAR 파일은 SW360 소스 파일 내 frontend/configuration 폴더 하위에 있다. (예: https://github.com/haksungjang/sw360/tree/docker_build/frontend/configuration)

먼저, Public_Pages_7_4_3_18_GA18.lar 파일을 업로드하고 Continue 버튼을 누른다.

File Summary 화면에서 업로드된 LAR 파일 세부 내용을 볼 수 있다.

제일 아래의 AUTHORSHIP OF THE CONTENT를 Use the Current User as Author로 변경하고 Import 버튼을 누른다.

그러면 Import가 성공적으로 완료된 걸 볼 수 있다.

이와 유사하게 Private_Pages_7_4_3_18_GA18.lar 파일을 Import한다. File Summary 화면에서 아래와 같이 PAGES > Private Pages로 변경한다.

그리고, PERMISSIONS, UPDATE DATA, AUTHORSHIP OF THE CONTENT 항목을 각각 아래 이미지와 같이 선택하고, Import버튼을 눌러 Import를 수행한다.

여기까지 수행을 마친 후 메뉴 상단의 Home 버튼을 누른다.

그럼 아래와 같이 Welcome to SW360! 화면에 진입한다.

Start 버튼을 눌러 SW360 첫 화면에 진입할 수 있다. (모든 항목이 비어있다.)

3. User Account 설정 (테스트용)

SW360 메뉴에서 Admin > User를 선택한다.

화면 하단의 UPLOAD USERS 메뉴에서 테스트를 위한 User 리스트를 업로드 한다. (테스트를 위한 User 리스트는 여기에서 다운 받을 수 있다. : test_users_with_passwords_12345.csv )

그러면 다음과 같이 9개의 User 리스트가 업로드 된 것을 볼 수 있다.

여기서 보이는 User 리스트 중 하나인 user@@sw360.org 계정으로 다시 로그인을 시도한다. Password는 12345이다.

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 등록을 자동화시켜서 관리한다면 효율성이 크게 증가될 것이다.

6 - (구) 국제표준(ISO/IEC 5230)에 기반한 기업 오픈소스 거버넌스 구축 가이드

오픈소스 국제 표준인 ISO/IEC 5230에 기반한 기업의 오픈소스 거버넌스 체계 구축 방법을 설명한다.

ISO/IEC 5230은 오픈소스 컴플라이언스를 위한 국제 표준으로 소프트웨어를 배포하는 기업이 올바른 오픈소스의 활용을 위해 준수해야 할 최소한의 핵심 요구사항을 정의하였다. 여기에서는 ISO/IEC 5230에 대해 간단히 소개하고, 이를 기반으로 기업이 어떻게 오픈소스 거버넌스 체계를 구축할 수 있을지에 대하여 설명한다.

Author : 장학성 (haksung@sktelecom.com)

References

이 가이드는 다음 자료를 참고하였습니다.

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

6.1 - 1. ISO/IEC 5230 살펴보기

ISO/IEC 5230 이란?

ISO/IEC 5230은 Linux Foundation의 OpenChain Project에서 만든 규격으로 소프트웨어 공급망 내 신뢰할 수 있는 오픈소스 컴플라이언스를 보장하기 위한 최소한의 핵심 요구 사항을 정의하였다.

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

이러한 복잡한 소프트웨어 공급망의 여러 조직 중 한 곳이라도 오픈소스 라이선스 의무를 준수하지 않거나 올바른 오픈소스 사용 정보를 제공하지 않으면 최종 소프트웨어를 배포하는 기업은 오픈소스 라이선스 의무 준수에 실패할 수밖에 없다. 이로 인해 소송을 제기당해 제품 판매가 중단되는 상황이 발생할 수도 있다.

[OpenChain Open Source Software License Compliance General Public Guide]

2009년 12월, Busybox라는 오픈소스 관련된 소송이 있었다. Busybox는 임베디드 시스템에 광범위하게 사용되고 있는 GPL-2.0 라이선스가 적용된 오픈소스인데, 국내 회사 두 곳을 포함하여 14개 회사가 소송 대상이 되었다. 이 사례에서 주목할만한 점은 이 중에는 제품을 직접 개발하지 않고 배포만 한 회사도 소송을 당하였다는 점이다.

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

Linux Foundation의 OpenChain 프로젝트는 기업이 오픈소스 컴플라이언스를 위해 준수해야 할 핵심 사항을 간결하고 일관성 있게 정의하고, 이를 모두가 준수한다면 소프트웨어 공급망 전체에 걸쳐 오픈소스 라이선스 측면의 신뢰를 구축할 수 있다는 믿음으로 설립되었다.

[OpenChain Project Logo]

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

OpenChain 프로젝트는 기업들이 오픈소스 컴플라이언스를 더욱 쉽게 달성 할 수 있도록 크게 다음 세 가지를 제공한다.

  1. OpenChain 규격1
  2. OpenChain 적합성 인증2
  3. 문서 자료3

기업이 어떻게 이들을 활용할 수 있을지 하나씩 알아보자.

OpenChain 규격과 ISO/IEC 5230

OpenChain 규격은 오픈소스 컴플라이언스를 위한 핵심 요구사항을 정의한 10페이지 분량의 문서이다. 2016년 OpenChain 규격 버전 1.0이 발표되었다. OpenChain 규격은 기업의 규모나 업종과 관계없이 모든 기업에 적합하도록 설계되었다.

2020년에는 버전 2.1의 규격이 배포됐으며, 기업이 오픈소스 컴플라이언스 달성을 위해 꼭 수행해야 할 여섯 가지 핵심 요구사항과 이를 입증하기 위해 필요한 자료 목록을 정의하고 있다.

  1. 프로그램 설립
  2. 관련 업무 정의 및 지원
  3. 오픈소스 콘텐츠 검토 및 승인
  4. 컴플라이언스 산출물 생성 및 전달
  5. 오픈소스 커뮤니티 참여에 대한 이해
  6. 규격 요구사항 준수

오픈소스 컴플라이언스를 처음 시작하는 기업이라면 이러한 OpenChain 규격의 요구사항을 하나씩 충족해가면서 수준을 향상시키는 것이 좋은 전략이다.

< 출처 : https://github.com/OpenChain-Project/Specification/blob/master/Official/en/2.1/openchainspec-2.1.pdf>

이 OpenChain 규격은 2020년 12월 오픈소스 컴플라이언스에 대한 국제 표준4으로 정식 등록되었다.

< 출처 : https://www.iso.org/standard/81039.html>

지난 4년간 사실상의 표준이었던 OpenChain 규격이 ISO/IEC 5230:2020이라는 정식 국체 표준으로 전환되었고, 이는 오픈소스 컴플라이언스 및 프로세스 관리를 정의한 최초의 국제 표준이다. 이로써 글로벌 IT기업의 ISO/IEC 5230 준수에 관한 관심이 높아지고 있고, 소프트웨어 공급망에서 공급자들에게 ISO/IEC 5230 준수를 요구하는 기업이 늘어날 것으로 예상된다.

ISO/IEC 5230 인증 방법

ISO/IEC 5230에서의 요구 사항을 모두 준수한다면 ISO/IEC 5230에 적합한 오픈소스 프로그램을 보유했음을 인증받을 수 있다. 오픈소스 프로그램이란 정책, 프로세스, 인원 등 기업이 오픈소스 컴플라이언스 활동을 수행하기 위한 일련의 관리 체계를 의미한다.

아래의 이미지는 ISO/IEC 5230이 요구하는 항목 번호를 나열한 그림이다. 이 항목을 모두 충족하는 기업은 소프트웨어 공급망에서 투명하고 신뢰할 수 있는 오픈소스 거버넌스 체계를 구축하였다고 인정받을 수 있다.

OpenChain 프로젝트에서 제안하는 인증 방법은 세 가지 이다.

  • 자체 인증
  • 독립 평가
  • 타사 인증

https://www.openchainproject.org/get-started/conformance >

각각의 방법을 알아보자.

1. 자체 인증 (Self Certification)

자체 인증은 OpenChain 프로젝트에서 제일 권장하는 방법이며, 비용이 발생하지 않는다는 장점이 있다. OpenChain Project는 기업이 OpenChain 규격을 준수하는지 자체적으로 확인할 수 있도록 OpenChain 자체 인증 웹사이트를 제공한다2. 기업의 오픈소스 담당자는 OpenChain 자체 인증 웹사이트에 가입해 온라인 자체 인증을 시작할 수 있다. 자체 인증은 아래와 같이 Yes/No 질문에 답변하는 방식으로 진행된다.

< 출처 : https://certification.openchainproject.org/>

오픈소스 컴플라이언스 체계를 잘 구축하여 OpenChain 자체 인증의 모든 질문에 Yes로 대답할 수 있다면 이 결과를 웹사이트상에 제출할 수 있다Conforming Submission. 그러면 Linux Foundation의 간단한 문답식의 확인 절차를 거친 후 ISO/IEC 5230 인증을 선언을 할 수 있게 된다.

<예: SK텔레콤 인증 선언 - 출처: https://www.openchainproject.org/featured/2021/09/08/sk-telecom>

이렇게 인증 선언을 하게 되면, Global Software Supply Chain에서 ISO/IEC 5230을 준수하는 오픈소스 프로그램을 가진 기업으로 인정 받게 된다.

< ISO/IEC 5230 적합 프로그램 보유 선언 기업, 출처 - https://www.openchainproject.org/ >

OpenChain 프로젝트는 자체 인증 방식을 권장한다. 참고로, OpenChain 적합성을 선언한 대부분의 기업도 자체 인증 방식을 채택하였다.

또한, 기업은 자체 인증 과정을 통해 부족한 부분이 무엇인지, 추가로 필요한 활동이 무엇인지 판단할 수 있다. 이 가이드에서는 조직, 정책, 프로세스 등 주요 구성 요소 별로 ISO/IEC 5230 요구 사항을 준수할 수 있는 방법을 설명한다.

가이드만으로 자체적으로 보완할 수 있는 역량이 부족한 기업인 경우 독립 평가 방법을 고려할 수 있다.

2. 독립 평가 (Independent Assessment)

독립 평가는 기업 외부의 독립 기관이 공정한 관점에서 기업의 오픈소스 컴플라이언스 상태를 점검하고 평가한다. 독립 평가의 특징은 평가 보고서를 생성하는 것에 그치지 않고 도출된 미비점을 보완하기 위한 컨설팅을 제공한다. (단, 공인 인증서를 발급하지는 않는다.)

기업은 독립 기관으로부터의 공정한 평가와 컨설팅을 받아 컴플라이언스 수준을 높이고, 다시 독립 평가를 수행하는 반복적인 과정을 통해 정책을 세분화하고 프로세스를 구축할 수 있다.

< Independent Compliance Assessment, 출처 - https://youtu.be/DEBd-g0Ab8E >

결국 기업은 ISO/IEC 5230 인증을 받을 수 있는 수준에 도달하게 되고, 그때 자체 인증, 혹은 타사 인증을 획득하는 절차에 돌입할 수 있다. 독립 평가는 이렇게 기업의 오픈소스 컴플라이언스 수준을 높이기 위한 평가와 컨설팅을 제공하여서 기업이 ISO/IEC 5230 적합 프로그램을 보유하고 인증을 획득할 수 있게 지원한다.

독립 평가를 제공하는 업체는 AlektoMetis5, Source Code Control6 등이 있다.

국내에서는 OpenChain Korea Work Group의 Subgroup인 Conformance Group7에서 기업간에 자체적으로 ISO/IEC 5230 준수를 위한 방법을 논의하고 공유하는 커뮤니티가 있다. OpenChain Korea Work Group 멤버라면 누구나 참여하여 도움을 받을 수 있다.

3. 타사 인증 (Third-Party Certification)

소프트웨어 공급망에서 구매자에게 보다 신뢰성 있고 투명한 오픈소스 컴플라이언스 수준을 나타내고자 한다면 타사 인증 기관으로부터 인증서를 발급받고 이를 홍보에 활용할 수 있다. 또한, 오픈소스 컴플라이언스의 보다 견고한 신뢰성을 요구하는 일부 구매자는 공급자Supplier에게 타사 인증을 의무화 할 수도 있을 것으로 예상된다.

2021년 10월 기준, OpenChain의 공인 타사 인증 기관은 ORCRO8, PWC9, TÜV SÜD10, Synopsys11, Bureau Veritas12이다.

< Third-Party Certifiers, 출처 - https://www.openchainproject.org/partners >

이들은 ISO/IEC 5230 적합 프로그램 확인을 위한 평가를 제공하고 통과한 기업에 인증서를 발급한다.

< PWC certification, 출처 - https://youtu.be/HslvXCM-4pQ >

2021년 10월 현재, 아직은 타사 인증을 의무적으로 요구하는 구매자나 기관은 없어 보인다. 하지만 유럽의 자동차 업계에서는 ISO/IEC 5230이 ASPICEAutomotive SPICE13 자동차 소프트웨어 개발을 위한 국제 표준 프로세스 모델)와 같이 자동차 소프트웨어 공급자에게 의무화될 날이 머지않을 것이라고 예견하는 전문가도 있다.

또한, 자세한 자체 인증 방법은 다음 슬라이드를 참고할 수 있다.

OpenChain Resources

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

< OpenChain Curriculum, 출처 - https://www.openchainproject.org/resources >

이 가이드의 많은 내용도 OpenChain에서 공개한 자료를 기반으로 작성하였다. 각 기업의 오픈소스 담당자는 정책, 프로세스, 교육자료가 필요하다면 OpenChain Resources를 먼저 찾아보기 바란다. 또한 이 자료는 한국어로도 번역되어 공개되고 있다. OpenChain Korea Work Group14에서 이러한 번역 작업을 주도하고 있다. 한국어 번역은 관심 있는 누구나 참여할 수 있다15.

ISO/IEC 5230 추세

2021년 초, 독일의 자동차 제조사가 부품 Supplier에게 ISO/IEC 5230 준수 계획을 요구하기 시작했다는 소식이 들렸고, 유럽의 한 오픈소스 분야 교수는 “앞으로 소프트웨어 공급망의 Buyer는 Supplier에게 ISO/IEC 5230 준수를 요구할 것은 명백하다"며, “자동차 업계로 보면 A-SPICE처럼 될 것이다"라고 말했다.

이를 반영하듯 2021년 5월, 폭스바겐 그룹의 Scania는 Supplier가 따라야 하는 자체 기업 표준(STD 4589)에 ISO/IEC 5230 준수를 요구하는 내용을 포함시켰다.

linkedin, May 2021

또한, 2021년 7월, 자동차 및 산업 기술 기업인 Boash는 연말까지 모든 그룹사가 ISO/IEC 5230을 준수하는 프로그램을 갖추겠다고 선언하였다. 업계에서는 모든 자동차 제조사나 다른 산업에서도 소프트웨어 공급망 내에서 ISO/IEC 5230을 요구하기 시작하는건 시간 문제라는 전망도 내놓고 있다.

linkedin, July 2021

  1. OpenChain 규격 - https://www.openchainproject.org/get-started/conformance ↩︎

  2. OpenChain 자체 인증 웹사이트 - https://certification.openchainproject.org/ ↩︎ ↩︎

  3. OpenChain 문서 자료 - https://www.openchainproject.org/resources ↩︎

  4. ISO/IEC 5230 : https://www.iso.org/standard/81039.html ↩︎

  5. AlektoMetis - https://alektometis.com/, ↩︎

  6. Source Code Control - https://sourcecodecontrol.co/ ↩︎

  7. Conformance Group - https://openchain-project.github.io/OpenChain-KWG/subgroup/conformance/ ↩︎

  8. ORCRO- https://orcro.co.uk/ ↩︎

  9. PWC - https://www.pwc.de/en/opensource ↩︎

  10. TÜV SÜD - https://www.tuvsud.com ↩︎

  11. Synopsys - https://www.synopsys.com/ ↩︎

  12. Bureau Veritas - https://group.bureauveritas.com/ ↩︎

  13. ASPICE : 자동차 소프트웨어 개발을 위한 국제 표준 프로세스 모델 - http://www.automotivespice.com ↩︎

  14. OpenChain Korea Work Group - https://openchain-project.github.io/OpenChain-KWG/ ↩︎

  15. 한국어 번역 작업 - https://openchain-project.github.io/OpenChain-KWG/resource/ ↩︎

6.2 - 2. 필수 구성 요소

오픈소스 거버넌스 체계 필수 구성 요소

기업이 효율적인 오픈소스 거버넌스 체계를 구축하기 위해서는 다음과 같은 구성 요소가 필요하다.

Essential elements of an open source management program : https://www.linuxfoundation.org/wp-content/uploads/OpenSourceComplianceHandbook_2018_2ndEdition_DigitalEdition.pdf

이런 구성 요소 중 기업이 ISO/IEC 5230에서 요구하는 모든 항목에 적합한 오픈소스 거버넌스 체계 구축을 위해서는 기본적으로 아래의 다섯가지 사항을 갖추어야 한다. 여기서는 이에 대한 세부 사항을 설명한다.

  1. 조직 (담당자)
  2. 정책
  3. 프로세스
  4. 도구
  5. 교육/평가

6.3 - 3. 조직 (담당자)

역할과 책임 정의

기업의 오픈소스 거버넌스 체계를 구축하기 위해서는 먼저 이를 책임지고 수행할 책임자가 필요하다. 오픈소스 프로그램 매니저, 오픈소스 컴플라이언스 담당자 등의 명칭으로 불릴 수 있으며, 이 책임자는 기업의 오픈소스 컴플라이언스에 대한 총괄 책임을 담당한다.

아래의 역량을 가지고 있다면 이 역할에 적합하다고 할 수 있겠다.

  • 오픈소스 생태계에 대한 이해 및 개발 경험
  • 기업의 비즈니스에 대한 폭넓은 이해
  • 기업의 구성원에게 효과적인 오픈소스 활용을 전파할 수 있는 열정과 커뮤니케이션 능력

오픈소스 프로그램 매니저는 가능한 풀타임으로 역할을 수행할 수 있도록 보장되는게 좋다.

글로벌 ICT 기업은 이와 같은 우수한 오픈소스 프로그램 매니저를 채용하기 위해 노력하고 있으며, 다음 사이트에서는 다양한 채용 공고를 확인할 수 있다. : https://github.com/todogroup/job-descriptions

기업은 오픈소스 거버넌스 체계를 구축하기 위해 각 역할의 필요성을 정의하고, 어떠한 책임을 할당하여야 하는가를 판단해야 한다. 소규모 기업의 경우, 오픈소스 프로그램 매니저 혼자서 모든 역할을 수행하는 것도 가능하다. 기업의 규모에 따라 오픈소스 도구를 운영하는 IT 담당자도 필요할 수 있고, 전문적인 법무 자문을 제공하기 위한 법무 담당의 역할이 요구될 수도 있다.

일반적으로 기업의 오픈소스 거버넌스 체계 구축을 위해서는 아래의 역할이 필요하다.

  • 법무 담당
  • IT 담당
  • 개발 문화 담당
  • 보안 담당

Individuals and teams involved in ensuring open source compliance : https://www.linuxfoundation.org/wp-content/uploads/OpenSourceComplianceHandbook_2018_2ndEdition_DigitalEdition.pdf

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 1.c프로그램의 성능과 효과에 영향을 미치는 역할과 그에 상응하는 책임을 확인했습니까?
Have you identified the roles and the corresponding responsibilities that affect the performance and effectiveness of the Program?

필요 역량 정의

각 역할과 그에 대한 책임을 정의하였다면 그 역할을 수행할 인원이 갖춰야 할 필요 역량이 무엇인지 파악해야 한다. 이를 통해 역할별 담당자에게 해당 역할을 수행할 수 있는 역량을 갖췄는지 평가하고, 필요시 교육을 제공해야 하기 때문이다.

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 1.d각 역할에 필요한 역량을 확인하고 문서화했습니까?
Have you identified and documented the competencies required for each role?

담당자 지정

오픈소스 프로그램 매니저는 관련부서와 협의하여 각 역할을 위한 담당자를 지정하고 이를 문서화한다. 물론 이를 위해서는 CEO 등 최고 의사결정권자에게 오픈소스 컴플라언스 체계 구축을 위한 목표와 방향을 보고하여 필요한 지원을 받아야 할 것이다.

오픈소스 관련 조직과 담당자는 반드시 풀타임으로 오픈소스 업무에 참여할 필요는 없다. OSRB (Open Source Review Board) 형태의 Virtual한 조직을 구성하여 필요한 역할을 수행하면 된다.

SK텔레콤은 OSRB를 구성하여 기업 내 오픈소스 정책과 프로세스를 만들고, 이슈 발생 시 대응 방안을 마련하고 있다.

https://sktelecom.github.io/about/osrb/

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 2.d프로그램 내 각 역할을 담당하는 인원, 그룹 또는 직무의 이름을 기재한 문서가 있습니까?
Have you documented the persons, group or function supporting the Program role(s) identified?

아래의 테이블은 오픈소스 관련 조직과 담당자의 역할 및 요구되는 필요 역량을 명시한 샘플 담당자 현황이다. 기업은 이를 참고하여 오픈소스 조직을 구성하여 문서화할 수 있다.

이 내용은 다음 페이지에서도 확인할 수 있다. : https://haksungjang.github.io/docs/openchain/#appendix-1-담당자-현황

이렇게 조직을 구성하면 ISO/IEC 5230의 요구 사항 중 아래와 같이 세가지 요구사항을 충족하게 된다.

6.4 - 4. 정책

오픈소스 정책 문서화

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

일반적인 오픈소스 정책은 다음을 포함한다.

  • 오픈소스를 사용하여 소프트웨어 제품과 서비스를 만들어서 배포하기 위한 원칙
  • 외부 오픈소스 커뮤니티에 기여하기 위한 원칙
  • 기업의 소프트웨어를 오픈소스로 공개하기 위한 원칙

다음 페이지에서 ISO/IEC 5230의 요구사항을 충족하는 샘플 오픈소스 정책 문서를 제공한다. : “부록 1. 샘플 오픈소스 정책”

각 기업은 이 샘플 정책을 기반으로 회사의 비즈니스 전략과 환경에 맞게 수정하여 사용할 수 있다.

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 1.a배포용 소프트웨어의 배포를 위한 오픈소스 라이선스 컴플라이언스를 관리하는 문서화된 정책이 있습니까?
Do you have a documented policy that governs open source license compliance of the Supplied Software distribution?

적용 범위 지정

하나의 오픈소스 정책(프로그램)을 반드시 전체 조직에 적용해야 하는 것은 아니다. 기업 내 각 조직과 제품의 특성에 따라 적용 범위를 달리 지정할 수 있다. 조직별로, 제품별로 다른 오픈소스 프로그램을 적용할 수 있다. 마찬가지로, 소프트웨어를 전혀 배포하지 않는 조직이라면 오픈소스 프로그램의 적용 범위에서 제외할 수 있다. 기업은 조직과 제품의 특성을 고려하여 오픈소스 프로그램의 적용 범위와 한계를 명확히 정의하고, 이를 오픈소스 정책에 명시할 수 있다.

기업의 조직과 제품 및 서비스가 비즈니스 환경에 맞추어 변화함에 따라 프로그램의 적용 범위를 결정하거나 수정해야 하는 상황이 발생할 수 있다. 기업은 이에 대응하기 위한 절차를 다음의 예와 같이 준비해야 한다.

  1. 오픈소스 프로그램 매니저는 새로운 프로젝트를 시작할 때 해당 프로젝트가 프로그램 적용 범위 내에 포함되는지 여부를 판단한다.
  2. 포함되지 않는다고 판단되는 경우, 해당 프로젝트를 프로그램 적용 범위에 포함 시키기 위한 제안을 OSRB에 제출한다.
  3. OSRB에서 수락할 경우, 이에 맞게 프로그램의 적용 범위를 수정한다.
  4. 이외 오픈소스 프로그램 매니저는 프로그램 적용 범위에 대한 검토가 필요하다고 판단되는 경우, 동일한 프로세스에 따라 프로그램 적용 범위에 대한 검토를 시작할 수 있다.

다음의 예와 같은 내용을 오픈소스 정책에 포함할 수 있다.

2. 적용 범위
이 정책은 다음 세 부분에 적용한다.

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

적용 범위는 회사의 비즈니스 환경에 맞추어 변경할 수 있으며, 이를 위한 절차는 다음과 같다.

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

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 1.g프로그램의 적용 범위를 결정하는 프로세스가 있습니까?
Do you have a process for determining the scope of your Program?
자체 인증 1.h프로그램의 적용 범위와 한계를 명확하게 정의한 문서화된 진술이 있습니까?
Do you have a written statement clearly defining the scope and limits of the Program?

외부 문의 대응 담당자 지정 / 연락처 공개

오픈소스를 사용하여 개발한 제품 혹은 서비스에 대해 고객 및 오픈소스 저작권자가 기업에 오픈소스 관련 문의, 요청 및 클레임을 제기하는 경우가 있다. 외부 문의 및 요청의 주된 내용은 다음과 같다.

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

기업은 이러한 외부 문의를 처리할 담당자를 지정해야 한다. 일반적으로 오픈소스 프로그램 매니저가 담당한다.

그리고, 외부의 오픈소스 개발자가 특정 기업의 오픈소스 컴플라이언스 관련 이슈를 논의하기 위해 기업 담당자에게 연락하고 싶어도 연락 방법을 찾지 못하다가 결국 바로 법적 클레임을 제기하는 경우가 있다. 이를 방지하기 위해 기업은 제 3자가 기업에 오픈소스 관련하여 문의 및 요청을 할 수 있는 연락 방법을 항시 공개적으로 밝혀야 한다.

외부에서 기업에 오픈소스 관련된 문의를 할 수 있는 연락 방법은 (1) 기업 오픈소스 프로그램 매니저의 이메일 주소를 공개하거나, (2) Linux Foundation의 Open Compliance Directory를 이용하는 것이다.

기업 오픈소스 프로그램 사무소의 대표 이메일 주소는 제품 및 서비스와 동봉하는 오픈소스 고지문에 포함하여 공개하는 것도 좋은 방법이다.

이러한 내용은 아래의 예시와 같이 오픈소스 정책에 반영할 수 있다.

1. 외부 문의 대응
(1) 외부 문의 대응책임
외부로부터 오픈소스 컴플라이언스에 대한 문의 및 요청에 대한 대응은 오픈소스 프로그램
매니저가 담당한다.

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

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

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

(3) 외부 문의 대응 절차
외부로부터의 오픈소스 컴플라이언스 문의에 신속하고 정확하게 대응한다면 소송까지
진행되는 위험을 크게 줄일 수 있다. 이를 위해 회사는 외부의 오픈소스 컴플라이언스
문의에 대응하기 위해 오픈소스 컴플라이언스 프로세스에서 정의한 외부 문의 대응 절차를
준

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 2.a외부 오픈소스 컴플라이언스 문의를 받을 담당자(오픈소스 연락담당자)를 지정했습니까?
Have you assigned individual(s) responsible for receiving external open source compliance inquiries (“Open Source Liaison”)?
자체 인증 2.b오픈소스 연락 담당자 정보가 외부에 공개되어 있습니까(예: 이메일 주소 또는 Linux Foundation의 Open Compliance Directory 활용)?
Is the Open Source Liaison function publicly identified (e.g. via an email address and/or the Linux Foundation’s Open Compliance Directory)?

인원, 예산 등 지원

기업은 오픈소스 프로그램이 원활하게 기능을 수행할 수 있도록 충분한 리소스를 제공해야 한다. 프로그램 내 각 역할을 담당하는 인원을 적합하게 배치하고, 충분한 예산과 업무 시간을 보장해야 한다. 그렇지 않을 경우, 이를 보완할 수 있는 절차가 마련되어야 한다. 다음의 예시 문장을 오픈소스 정책 문서에 추가할 수 있다.

4. 역할, 책임 및 역량

각 역할에 대한 담당 조직의 장은 조직 내 담당자를 지정하고, 담당자가 역할을 충실하게
수행할 수 있는 적절한 사간과 예산을 할당한다. 각 역할의 담당자는 자신이 역할을
수행하면서 적절한 지원이 되지 않는다면 오픈소스 프로그램 매니저에게 문제를 제기해야
한다. 오픈소스 프로그램 매니저는 해당 조직장과 문제 해결을 논의한다. 적절하게
해결되지 않는다면, 오픈소스 프로그램 매니저는 OSRB에 문제 해결을 요청할 수 있다.
OSRB는 상위 조직의 장에게 문제를 공유하고 해결을 요청한다.

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 2.e프로그램 내 각 역할을 담당하는 인원이 적합하게 배치되고, 예산이 적절하게 지원되었습니까?
Have the identified Program roles been properly staffed and has adequate funding provided?

법률 자문 제공

기업은 각 역할의 담당자가 오픈소스 컴플라이언스 이슈 해결을 위해 법률적인 검토가 필요할 경우, 이에 대해 법률 자문을 요청할 수 있는 방법을 제공해야 한다. 회사 내의 법무팀을 통해 우선 제공하고, 이슈가 첨예한 경우, 오픈소스 전문 변호사를 보유한 외부 법무 법인을 이용할 수 있다. 이를 위한 오픈소스 정책의 예시는 다음과 같다.

4. 역할, 책임 및 역량

(2) 오픈소스 프로그램 매니저
* 오픈소스 프로그램 매니저는 구성원이 오픈소스 관련 법률 자문을 받을 수 있는 방법을
  제공한다.
* 오픈소스 프로그램 매니저는 외부 법무 법인을 참여시켜야 하는지 여부를 결정한다.
  외부 법률 고문의 효과와 적절성은 오픈소스 프로그램 매니저가 매년 평가하고 검토한다.

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 2.f오픈소스 컴플라이언스와 관련된 문제 해결을 위해 내부 또는 외부의 법률 전문 자문을 이용하는 방법이 있습니까?
Is legal expertise pertaining to internal and external open source compliance identified?

참고로, OpenChain 프로젝트에서는 파트너 프로그램을 통해 오픈소스 관련 자문을 제공하는 글로벌 법무법인 리스트를 제공한다. : https://www.openchainproject.org/partners

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

내부 책임 할당 절차

오픈소스 컴플라이언스를 위한 내부 책임을 할당하는 절차가 있어야 한다. 이는 오픈소스 프로그램 매니저의 역할이다. 오픈소스 프로그램 매니저는 이슈를 파악하고 각 역할의 담당자에게 적절히 이슈를 할당해야 한다. 이를 위해 기업은 오픈소스 정책 문서에 이러한 내용을 아래와 같이 기술할 수 있다.

4. 역할, 책임 및 역량

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

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

* 오픈소스 컴플라이언스를 위해 필요한 역할을 정의하고, 각 역할을 책임질 담당 조직 
및 담당자를 지정한다. 필요 시 OSRB와 협의한다.

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 2.g오픈소스 컴플라이언스에 대한 내부 책임을 할당하는 문서화된 절차가 있습니까?
Do you have a documented procedure assigning internal responsibilities for Open Source compliance?

미준수 사례 대응

기업은 컴플라이언스 미준수 사례를 신속히 검토하고 대응하기 위한 절차를 문서화해야 한다. 다음의 예시를 참고하여 오픈소스 정책에 포함할 수 있다.

1. 오픈소스 사용

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

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

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 2.h미준수 사례를 검토하고 이를 수정하기 위한 문서화된 절차가 있습니까?
Do you have a documented procedure for handling review and remediation of non-compliant cases?

오픈소스 기여 정책

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

이러한 오픈소스 기여에 대한 정책은 NIPA OpenChain 해설서 부록 1. 샘플 오픈소스 정책의 7. 오픈소스 기여를 참고할 수 있다.

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 5.a조직을 대신하여 오픈소스 프로젝트에 기여하는 것을 관리하는 정책이 있습니까?
Do you have a policy that governs contributions to open source projects on behalf of the organization?

위와 같은 내용을 포함하는 오픈소스 정책까지 수립하게 되면 ISO/IEC 5230 요구사항 중 다음의 사항을 만족하게 된다.

6.5 - 5. 프로세스

프로세스는 소프트웨어 개발 / 배포 과정에서 기업이 오픈소스 정책을 준수할 수 있게 하는 실행 가능한 절차이다. 오픈소스 컴플라이언스 프로세스는 간단히 말해 소프트웨어를 개발하고 배포하면서 사용한 오픈소스에 대해 각 라이선스가 요구하는 조건을 준수하기 위한 활동이고, 오픈소스 고지문(Notice), 공개할 소스 코드 (Source Code) 등의 산출물을 생성하게 된다.

Simplified view of the compliance end-to-end process : https://www.linuxfoundation.org/wp-content/uploads/OpenSourceComplianceHandbook_2018_2ndEdition_DigitalEdition.pdf

오픈소스 컴플라이언스 프로세스를 세분화하여 도식화하면 아래 그림과 같다.

End-to-end compliance process : https://www.linuxfoundation.org/wp-content/uploads/OpenSourceComplianceHandbook_2018_2ndEdition_DigitalEdition.pdf

아래의 이미지는 기업이 일반적으로 채택하여 사용할 수 있는 샘플 오픈소스 컴플라이언스 프로세스이다.

이에 대한 자세한 내용은 다음 페이지를 참고할 수 있다. : https://haksungjang.github.io/docs/openchain/#부록-2-샘플-오픈소스-컴플라이언스-프로세스

이 장에서는 오픈소스 컴플라이언스 프로세스가 포함해야 할 구성 요소에 대해 설명한다.

오픈소스 식별 및 검사

오픈소스의 사용 가능 여부를 판단하기 위해서는 먼저 사용하려는 오픈소스의 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무사항을 확인해야 한다. 오픈소스를 사용하였는지, 라이선스는 무엇인지, 각 라이선스가 부여하는 의무는 무엇인지 검토하고 기록해야 한다. 이를 위한 절차의 예는 다음과 같다.

  1. 개발 부서는 오픈소스 정책에서 정의한 기준에 따라 라이선스를 예비 평가한다.
  2. 의문 사항은 오픈소스 프로그램 매니저에게 문의하고, 필요할 경우 오픈소스 프로그램 매니저는 외부 법률 전문가에게 자문을 요청한다.
  3. 모든 내외부의 결정 결과 및 관련 근거는 보관한다.

“부록 2. 샘플 오픈소스 컴플라이언스 프로세스”의 1. 오픈소스 식별, 검사, 문제 해결, 리뷰, 승인 단계는 각 식별된 라이선스가 부가하는 의무, 제한을 검토하고 기록하기 위한 문서화된 절차의 한 예이다.

이와 같은 절차를 마련한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 1.i오픈소스 라이선스 의무, 제한 및 권리를 검토하는 프로세스가 있습니까?
Do you have a process for reviewing open source license obligations, restrictions and rights?

오픈소스 식별 및 검사 단계에서는 소스 코드 스캔 도구를 사용할 수 있다. 이에 대한 자세한 내용은 “6. 도구“에서 설명한다.

오픈소스 BOM 식별, 검토, 보관

오픈소스 컴플라이언스 활동의 가장 기본은 배포용 소프트웨어에 포함된 오픈소스 현황을 파악하는 것이다. 배포용 소프트웨어에 포함된 오픈소스와 그 라이선스를 식별하여 그 정보를 담고 있는 BOM(Bill of Materials)을 작성하고 관리하는 프로세스를 구축해야 한다. 배포용 소프트웨어의 버전마다 어떤 오픈소스가 포함되어 있는지 알고 있어야 소프트웨어를 배포할 때 각 오픈소스의 라이선스가 요구하는 의무 사항을 준수할 수 있기 때문이다.

모든 오픈소스는 배포용 소프트웨어에 통합하기 전에 검토 및 승인되어야 한다. 오픈소스의 기능, 품질뿐만 아니라 출처, 라이선스 요건을 충족할 수 있는지 사전 검토가 되어야 한다. 이를 위해 검토 요청 → 리뷰 → 승인 과정이 필요하다. 

부록 2. 샘플 오픈소스 컴플라이언스 프로세스에서는 기업의 오픈소스 컴플라이언스를 위한 프로세스 모든 과정에 관해 설명하고 있다. 1. 오픈소스 식별부터 6. 등록까지의 과정을 통해 BOM을 작성하고 관리하게 된다.

오픈소스 BOM 관리를 위한 도구에 대해서는 “6. 도구“에서 자세히 설명한다.

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

이와 같은 절차를 마련한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 3.a배포용 소프트웨어를 구성하는 오픈소스 컴포넌트에 대한 정보를 식별, 추적, 검토, 승인 및 보관하는 문서화된 절차가 있습니까?
Do you have a documented procedure for identifying, tracking and archiving information about the collection of open source components from which a Supplied Software release is comprised?

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

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

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

  1. 오픈소스 고지문 : 오픈소스 라이선스 전문과 저작권 정보 제공을 위한 문서

    • 도구를 활용하여 취합한 오픈소스 BOM에 해당하는 오픈소스 고지문을 생성하는 방법에 대해 “6. 도구“에서 추가로 설명한다.

  2. 공개할 소스 코드 패키지 : GPL, LGPL 등 소스 코드 공개를 요구하는 오픈소스 라이선스 의무 이행을 위해 공개할 소스 코드를 취합한 패키지

컴플라이언스 산출물은 배포용 소프트웨어를 배포할 때 함께 제공해야 한다. “부록 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 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>

따라서, 컴플라이언스 산출물은 3년 이상 보관해야 하며 이를 위한 프로세스가 구축되어야 한다. 이를 위해 기업은 오픈소스 웹사이트 구축을 고려해야 하며, 이에 대한 자세한 내용은 “6. 도구“에서 설명한다.

이와 같은 절차를 마련한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 4.a식별된 라이선스가 요구하는 컴플라이언스 산출물을 준비하고, 이를 배포용 소프트웨어와 함께 제공하기 위한 프로세스를 설명하는 문서화된 절차가 있습니까?
Do you have a documented procedure that describes a process that ensures the Compliance Artifacts are distributed with Supplied Software as required by the Identified Licenses?

외부 문의 대응

기업이 외부 클레임에 의해 법적 소송까지 당하지 않기 위해서는 외부 문의 및 요청에 가능한 빠르고 정확하게 대응하는 것이 중요하다. 이를 위해 기업은 외부 오픈소스 문의를 빠르고 효과적으로 대응 할 수 있는 프로세스를 갖추고 있어야 한다.

아래 그림은 외부 문의 대응을 위해 기업이 갖춰야할 프로세스이다.

https://haksungjang.github.io/docs/openchain/#2-외부-문의-대응-프로세스

“부록 2. 샘플 오픈소스 컴플라이언스 프로세스의 2. 외부 문의 대응 프로세스”에서 세부 내용을 확인할 수 있다.

이와 같은 절차를 마련한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 2.c오픈소스 컴플라이언스 문의를 받고 대응하기 위한 책임을 할당하는 문서화된 절차가 있습니까?
Do you have a documented procedure that assigns responsibility for receiving and responding to open source compliance inquiries?

오픈소스 기여 프로세스

기업이 외부 오픈소스 프로젝트에 기여를 허용하는 정책을 갖고 있다면, 사내 개발자들이 어떤 절차로 외부 프로젝트에 기여할 수 있을지 관리하는 문서화된 절차가 있어야 한다.

SK텔레콤에서 공개한 오픈소스 기여 절차는 좋은 예이다.

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

이와 같은 절차를 마련한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 5.b오픈소스 기여를 관리하는 문서화된 절차가 있습니까?
Do you have a documented procedure that governs Open Source contributions?

여기까지 프로세스를 구축하게 되면 ISO/IEC 5230 요구사항을 아래와 같이 준수하게 된다.

6.6 - 6. 도구

소스 코드 스캔 도구

오픈소스 컴플라이언스 프로세스의 오픈소스 식별 및 검사 단계에서는 소스 코드 스캔 도구를 사용할 수 있다. 소스 코드 스캔 도구는 무료로 사용할 수 있는 오픈소스 기반 도구부터 상용 도구까지 다양하게 있는데, 각 도구는 특장점 들이 있지만 어떤 하나도 모든 문제를 해결할 수 있는 완벽한 기능을 제공하지 않는다. 따라서 기업은 제품의 특성과 요구사항에 맞는 적합한 도구를 선택해야 한다.

많은 기업이 이러한 자동화된 소스 코드 스캔 도구와 수동 검토를 병행하여 이용한다. Linux Foundation의 FOSSology 프로젝트는 오픈소스로 공개된 소스 코드 스캔 도구로서 기업들이 손쉽게 무료로 사용할 수 있다.

https://www.fossology.org/

FOSSology의 설치 및 사용 방법은 부록 3. 오픈소스 도구를 참고한다.

https://haksungjang.github.io/docs/openchain/#1-fossology

Dependency 분석 도구

근래의 소프트웨어 개발 시에는 Gradle, Maven 등 Package Manager를 지원하는 빌드 환경을 사용한다. 이런 빌드 환경에서는 소스 코드가 없어도 빌드 타임에 필요한 Dependency 라이브러리를 원격의 공간으로부터 받아와서 배포용 소프트웨어를 구성한다. 이때의 Dependency 라이브러리는 배포용 소프트웨어에는 포함되지만 소스 코드 스캔 도구로는 검출되지 않는다. 따라서 Dependency 분석을 위한 도구를 활용하는 것도 중요하다.

오픈소스인 OSS Review Toolkit은 Analyzer라는 Dependency 분석 도구를 제공한다.

https://github.com/oss-review-toolkit/ort#analyzer

또한 LG전자는 FOSSLight Dependency Scanner를 오픈소스로 공개하였다. FOSSLight Dependency Scanner는 Gradle, Maven, NPM, PIP, Pub, Cocoapods 등 다양한 Package Manager를 지원한다.

https://fosslight.org/ko/scanner/

오픈소스 BOM 관리 도구

ISO/IEC 5230 규격의 3.3.1.2에서는 배포용 소프트웨어에 포함된 오픈소스 BOM 목록은 문서화하여 보관할 것을 요구한다. 오픈소스 BOM을 Excel과 같은 Spreadsheet 프로그램으로 관리할 수도 있다. 하지만, 배포용 소프트웨어의 개수와 버전이 수백개가 넘어갈 경우, 이를 수동으로 관리하는 것은 쉽지 않다. 이를 위한 오픈소스 자동화 도구를 도입하는 것이 좋다.

Eclipse 재단에서 후원하는 오픈소스 프로젝트인 SW360은 배포용 소프트웨어별로 포함하고 있는 오픈소스 목록을 트래킹할 수 있는 기능을 제공한다.

SW360의 설치 및 사용 방법은 부록 3. 오픈소스 도구를 참고할 수 있다.

https://haksungjang.github.io/docs/openchain/#부록-3-오픈소스-도구

그리고 위에서 언급한 LG전자가 공개한 오픈소스인 FOSSLight도 오픈소스 BOM 관리를 위한 기능을 제공한다.

https://fosslight.org/fosslight-guide/started/2_try/4_project.html

LG전자는 FOSSLight를 자체 개발하여 지난 수년간 전체 사업부의 배포용 소프트웨어에 대한 오픈소스 BOM을 관리해왔으며, 2021년 6월, 이를 누구나 사용할 수 있도록 오픈소스로 공개하였음을 발표하였다.

자세한 설치 및 사용 방법을 한국어 가이드로 제공하고 있어서 국내 기업에게 큰 도움이 될 것으로 기대한다.

https://fosslight.org/

이와 같은 도구를 도입한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 3.b문서화된 절차가 적절히 준수되었음을 보여주는 배포용 소프트웨어에 대한 오픈소스 컴포넌트 기록이 있습니까?
Do you have open source component records for each Supplied Software release which demonstrates the documented procedure was properly followed?

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

오픈소스 컴플라이언스 산출물 중 오픈소스 고지문을 수작업으로 작성하기 보다는 자동으로 생성하는 도구를 활용하는 것이 좋다.

FOSSLight에 오픈소스 BOM을 등록하면 자동으로 오픈소스 고지문을 생성할 수 있다. FOSSLight가 생성한 오픈소스 고지문에는 공개할 소스 코드에 대한 Written Offer (서면약정서)도 포함된다.

https://fosslight.org/fosslight-guide/started/2_try/4_project.html

또한 SK텔레콤은 사내에서 사용하는 오픈소스 고지문 자동 생성 도구를 오픈소스로 공개할 예정이어서 추후 이를 활용하는 것도 좋은 방법이다.

오픈소스 산출물 보관

기업은 오픈소스 웹사이트를 만들고, 오픈소스 컴플라이언스 산출물을 등록하여 외부 고객들이 배포용 소프트웨어에 대한 오픈소스 고지문과 공개할 소스 코드 패키지를 언제든지 다운받을 수 있도록 편의를 제공하는 것이 좋다.

SK텔레콤의 오픈소스 웹사이트를 참고할 수 있다.

https://sktelecom.github.io/compliance/

특히, 이 웹사이트는 오픈소스로 개발하였고, 소스 코드를 공개하고 있어서 다른 기업들도 쉽게 웹사이트를 구축할 수 있다.

https://github.com/sktelecom/sktelecom.github.io

이와 같은 도구 환경을 구축하면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 4.b배포용 소프트웨어의 컴플라이언스 산출물 사본을 보관합니까?
Do you archive copies of the Compliance Artifacts of the Supplied Software?
자체 인증 4.c컴플라이언스 결과물 사본은 적어도 배포용 소프트웨어가 제공되는 중이거나 식별된 라이선스가 요구하는 기간 중 더 긴 시간 동안 보관됩니까?
Are the copies of the Compliance Artifacts archived for at least as long as the Supplied Software is offered or as required by the Identified Licenses (whichever is longer)?

이렇게 도구 환경까지 구축하게 되면 ISO/IEC 5230 요구사항을 아래와 같이 준수하게 된다.

6.7 - 7. 교육/평가

교육

아무리 훌륭한 정책과 프로세스를 구축하였다고 해도 기업의 구성원이 아무도 신경쓰지 않는다면 무용지물일 것이다. 오픈소스 정책과 오픈소스 컴플라이언스 프로세스가 기업에서 효과적으로 동작하기 위해서는 구성원 교육이 중요하다.

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

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

1. 교육 및 평가

모든 소프트웨어 배포 참여자는 매년 [Learning Portal]에서 제공하는 오픈소스 의무
교육을 수강해야 한다.
이를 통해 오픈소스 정책, 관련 교육 정책 및 조회 방법을 숙지한다. 교육 이력은
[Learning Portal]에 보존한다.

이와 같은 교육 환경을 구축하면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 1.b오픈소스 정책의 존재를 모든 프로그램 참여자에게 알리는 문서화된 절차가 있습니까? (예: 교육, 내부 위키 혹은 기타 실질적인 전달 방법)
Do you have a documented procedure that communicates the existence of the open source policy to all Software Staff? (e.g., via training, internal wiki, or other practical communication method)

또한, 기업은 프로그램 참여자가 기업의 오픈소스 정책, 오픈소스 관련 목표, 효과적인 오픈소스 프로그램이 되기 위한 참여자의 기여 방법, 그리고 프로그램 요구사항을 준수하지 않을 경우 미치는 영향에 대해 인식하게 해야 한다. 이를 위해 기업은 교육을 제공하고, 프로그램 참여자에게 올바르게 인식하였는지 확인하기 위해 평가를 수행한다. 평가 결과는 문서화하여 보관한다.

이를 위한 아래의 예와 같은 내용을 기업의 오픈소스 정책에 포함할 수 있다.

1. 목적
  (1) 정책의 목적
    이 정책은 회사에서 소프트웨어 개발, 서비스, 배포에 관여하는 전체 조직이 올바르게
    오픈소스를 활용하기 위해 다음과 같은 원칙을 제공한다.

    1) 오픈소스 라이선스를 고려한 컴플라이언스 수행 원칙
    2) 외부 오픈소스 프로젝트로의 기여 원칙
    3) 사내 프로젝트를 오픈소스로 공개하기 위한 원칙

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

  (2) 미준수 시 영향
   이 정책을 준수하지 않는다면 다음과 같은 상황이 발생할 수 있다.
   * 외부로부터 오픈소스 라이선스 준수 요구를 받게 된다.
   * 회사가 개발한 소스 코드를 원하지 않게 공개해야 한다.
   * 오픈소스 저작권자로부터 법적 소송을 제기당하게 된다.
   * 저작권 침해 및 계약 위반으로 벌금을 부과 당하거나, 제품 판매 중지 명령을 받게 된다.
   * 회사 평판이 손실된다.
   * 공급업체와의 계약 위반이 되어 손해배상 청구를 당하게 된다.
  이러한 이유로 회사는 오픈소스 정책의 위반을 심각하게 간주하며, 이를 위반하는
  구성원이나 조직은 징계 절차에 처할 수 있다.

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

평가에 대해서는 아래에서 한번 더 자세히 설명한다.

이와 같은 교육에 대한 내용을 정책에 포함하면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 1.f다음 주제에 대한 프로그램 참여자의 인식을 문서화 한 증거가 있습니까?
i. 오픈소스 정책 및 이를 찾을 수 있는 위치
ii. 오픈소스 관련 목표
iii. 효과적인 프로그램이 되기 위한 참여자의 기여 방법
iv. 프로그램 요구사항을 준수하지 않을 경우 미치는 영향
Do you have evidence documenting the awareness of your personnel of the following topics?
i - The open source policy and where to find it;
ii - The relevant open source objectives;
iii - The contributions expected to ensure the effectiveness of the Program;
iv - The implications of failing to follow the Program requirements.

오픈소스 교육에는 오픈소스 기여 정책에 대한 내용도 포함한다. 오픈소스 기여 정책을 만들었다 해도 사내 구성원이 이에 대한 존재를 알지 못한다면 무분별한 기여 활동으로 개인과 회사에 피해가 발생할 우려가 있다. 모든 사내 개발자가 오픈소스 기여 정책의 존재를 알 수 있도록 오픈소스 교육을 제공한다.

이와 같이 기여 정책에 대한 교육을 제공하면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 5.c모든 프로그램 참여자가 오픈소스 기여 정책의 존재를 인식하도록 하는 문서화된 절차가 있습니까?
Do you have a documented procedure that makes all Software Staff aware of the existence of the Open Source contribution policy?

교육자료를 새롭게 제작하는 것도 처음 업무를 시작하는 담당자에게는 쉽지 않은 일일 수 있다. 이런 어려움을 돕고자 엔씨소프트는 사내 오픈소스 교육자료를 누구나 사용할 수 있도록 교안(PPT)와 강의 스크립트를 GitHub에 공개하였다.

https://github.com/ncsoft/oss-basic-training

또, 국내 대표 플랫폼 기업인 카카오도 사내 개발자를 위한 오픈소스 교육자료를 누구나 열람할 수 있도록 공개하였다.

http://t1.kakaocdn.net/olive/assets/opensource_guide_kakao.pdf

아직 교육 자료를 만들지 않았다면 이런 오픈소스 관리 우수 기업들의 오픈소스 교육 자료를 활용하는 것도 좋은 방법이다.

평가

기업은 각 역할에 대한 담당자를 지정하였으면, 지정된 담당자가 교육, 훈련 및 경험을 바탕으로 맡은 역할을 수행할 수 있는 자격을 갖추었음을 확인해야 한다. 역량이 미흡한 프로그램 참여자에게는 충분한 역량을 갖출 수 있도록 교육도 제공해야 한다. 그리고 기업은 각 참여자가 역량을 갖추고 있는지 평가하고 결과를 보관해야 한다.

  1. 기업은 각 참여자가 필요한 역량을 보유할 수 있도록 교육을 제공한다.
  2. 교육 내용을 기반으로 평가를 수행한다.
  3. 평가 결과는 기업의 교육 시스템 혹은 HR 부서에서 보관한다.

프로그램 참여자가 수백 명 이상이어서 교육 제공이 쉽지 않을 경우, 기업의 온라인 교육과 평가 시스템을 이용하는 것도 좋은 방법이다.

이와 같은 내용은 기업의 오픈소스 정책에 다음과 같이 포함할 수 있다.

4. 역할, 책임 및 역량
이 정책의 효과를 보장하기 위해 다음과 같이 역할과 책임 및 각 역할의 담당자가 갖추어야
할 역량을 정의한다.
각 역할의 담당 조직/담당자와 필요 역량 수준은 "Appendix 1. 담당자 현황"에서 정의한다.

5. 교육 및 평가
4장에서 정의한 각 역할을 담당하는 모든 구성원은 [Learning Portal]에서 제공하는
오픈소스 교육을 수강해야 한다.
교육 이력과 평가 결과는 [Learning Portal]에서 최소 3년간 보존한다.

이러한 교육과 평가 체계를 갖추면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 1.e각 프로그램 참여자의 역량을 평가한 증거를 문서화했습니까?
Have you documented evidence of assessed competence for each Program participant?

오픈소스 라이선스 가이드

오픈소스 라이선스를 제대로 준수하기 위해서는 오픈소스 라이선스별로 요구하는 사항에 대해 정확히 알고 있어야 한다. 하지만 개별 소프트웨어 개발자가 이를 일일이 파악하는 것은 어려우므로 오픈소스 프로그램 매니저는 자주 사용되는 오픈소스 라이선스에 대해 일반적인 사용 사례별 요구사항/주의사항을 정리하여 회사 내부에 공유하는 것이 좋다.

오픈소스 라이선스 가이드에는 일반적인 오픈소스 라이선스 사용 사례 별 요건을 포함하여 개발 부서에서 오픈소스를 사용하면서 올바른 라이선스 의무 준수 활동을 할 수 있게 해야 한다.

오픈소스 라이선스에 대한 일반적인 가이드와 라이선스 의무 요약 자료는 한국저작권위원회에서 제공하는 라이선스 가이드을 참고할 수 있다.

SK텔레콤의 오픈소스 가이드 내 라이선스별 의무사항 문서도 좋은 자료이다.

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

이러한 오픈소스 라이선스 가이드를 제공함으로써 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 3.c각 배포용 소프트웨어 릴리스 내의 오픈소스 컴포넌트에 대해 적어도 다음과 같은 일반적인 오픈소스 라이선스 사용 사례를 처리하는 절차를 구현했습니까?
i - 바이너리 형태로 배포;
ii - 소스 형태로 배포;
iii - Copyleft 의무를 발생시킬 수 있는 다른 오픈 소스와 통합;
iv - 수정된 오픈소스 포함;
v - 배포용 소프트웨어 내의 다른 컴포넌트와 서로 호환되지 않는 라이선스 하의 오픈소스 또는 다른 소프트웨어를 포함
Have you implemented a procedure that handles at least the following common open source license use cases for the open source components of each supplied Supplied Software release?
i - distributed in binary form;
ii - distributed in source form;
iii - integrated with other open source such that it may trigger copyleft obligations;
iv - contains modified open source;
v - contains open source or other software under an incompatible license interacting with other components within the Supplied Software;
vi - contains open source with attribution requirements.

이와 같이 교육, 평가와 가이드 제공 환경까지 구축하게 되면 ISO/IEC 5230 요구사항을 아래와 같이 준수하게 된다.

6.8 - 8. 준수 선언

ISO/IEC 5230 규격의 6조를 제외한 모든 요구사항을 준수하는 오픈소스 프로그램(오픈소스 정책 / 프로세스 / 도구 / 조직)을 구축한 기업은 다음 두가지를 명시하는 문서를 작성하여 게시할 수 있다.

  1. 기업의 오픈소스 프로그램이 OpenChain 규격 2.1의 모든 요구사항을 충족함
  2. 기업의 오픈소스 프로그램이 적합성 인증을 획득한 후 18개월 이상 OpenChain 규격 2.1의 모든 요구 사항을 충족하는 상태 유지를 보장함

기업은 위의 내용을 오픈소스 정책에 포함시킬 수도 있고, 외부에 공개되어 있는 웹사이트를 통해 게재할 수도 있다.

아래 이미지와 같이 SK텔레콤에서 오픈소스 포털사이트에 이에 대한 내용을 게재한 것을 참고할 수 있다. https://sktelecom.github.io/compliance/iso5230/

이렇게 ISO/IEC 5230의 모든 요구사항을 충족함을 보장한다고 문서화하면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 6.a프로그램이 이 규격의 모든 요구사항을 충족함을 확인하는 문서가 있습니까?
Do you have documentation confirming that your Program meets all the requirements of this specification?
자체 인증 6.b지난 18개월 이내에 프로그램 적합성을 검토했음을 확인하는 문서가 있습니까?
Do you have documentation confirming that your Program conformance was reviewed within the last 18 months?

여기까지 완료하면 기업은 드디어 ISO/IEC 5230의 모든 요구사항을 충족하게 된다.

6.9 - Appendix

6.9.1 - 1. 오픈소스 정책 (샘플)

1. 목적

(1) 정책의 목적(3.1.3.1)

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

  1. 오픈소스 라이선스를 고려한 컴플라이언스 수행 원칙
  2. 외부 오픈소스 프로젝트로의 기여 원칙
  3. 사내 프로젝트를 오픈소스로 공개하기 위한 원칙

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

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

(2) 미준수 시 영향

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

  • 외부로부터 오픈소스 라이선스 준수 요구를 받게 된다.
  • 회사가 개발한 소스 코드를 원하지 않게 공개해야 한다.
  • 오픈소스 저작권자로부터 법적 소송을 제기당하게 된다.
  • 저작권 침해 및 계약 위반으로 벌금을 부과 당하거나, 제품 판매 중지 명령을 받게 된다.
  • 회사 평판이 손실된다.
  • 공급업체와의 계약 위반이 되어 손해배상 청구를 당하게 된다.

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

(3) 구성원의 공헌 방법

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

2. 적용 범위(3.1.4.1)

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

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

적용 범위는 회사의 비즈니스 환경에 맞추어 변경할 수 있으며, 이를 위한 절차는 다음과 같다.

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

3. 용어

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

4. 역할, 책임 및 역량(3.1.2.1)

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

각 역할의 담당 조직/담당자와 필요 역량 수준은 [Appendix 1. 담당자 현황]에서 정의한다.(3.1.2.2)

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

(1) OSRB

OSRBOpen Source Review Board는 회사의 오픈소스 컴플라이언스 위해 오픈소스 프로그램 매니저와 법무팀, 특허팀, 개발팀, 인프라팀 등 관련 조직의 책임자로 구성된 협의체이다.

  • 오픈소스 컴플라이언스를 위한 정책과 프로세스를 만들고, 이를 수행하기 위한 회사 내의 역할과 책임을 정의한다.
  • 회사 내 오픈소스 컴플라이언스 이슈 발생 시, 해결 방안을 논의하고, 대응책을 마련한다.
  • 필요 시, 임원진에 이슈를 보고하여 리스크 완화 방안에 대한 피드백을 받는다.

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

오픈소스 프로그램 매니저는 회사의 오픈소스 프로그램에 대한 총괄 책임을 담당한다. 오픈소스를 사용한 제품과 서비스의 오픈소스 컴플라이언스를 보장하기 위해 다음 사항에 대한 책임이 있다.(3.2.2.4)

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

(3) OSPO

OSPOOpen Source Program Office는 회사 안팎으로 오픈소스 활동의 성장을 위해 지원, 육성하는 역할을 한다.

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

(4) 법무 담당

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

  • 호환되지 않는 오픈소스 라이선스로 인한 충돌을 포함하여 라이선스 및 지식재산권 문제에 대해 자문을 제공한다.
  • 외부 오픈소스 프로젝트로의 기여 시 오픈소스 라이선스, CLAContributor License Agreement 등 필요한 법적 사항을 검토한다.

(5) IT 담당

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

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

(6) 보안 담당

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

  • 오픈소스 보안취약점 분석 도구를 운영한다.
  • DevSecOps 환경과 통합하여 오픈소스 보안취약점 분석을 자동화한다.
  • 모든 배포용 소프트웨어를 대상으로 오픈소스 보안취약점 분석이 수행되도록 시스템과 프로세스를 구축한다.

(7) 개발 문화 담당

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

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

(8) 품질 담당

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

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

5. 교육 및 평가

모든 소프트웨어 배포 참여자는 매년 [Learning Portal]에서 제공하는 오픈소스 의무 교육을 수강해야 한다. 이를 통해 오픈소스 정책, 관련 교육 정책 및 조회 방법을 숙지한다. 교육 이력은 [Learning Portal]에 보존한다.(3.1.1.2)

4장에서 정의한 각 역할을 담당하는 모든 구성원은 [Learning Portal]에서 제공하는 오픈소스 교육 고급 과정을 수강해야 한다. 교육 이력과 평가 결과는 [Learning Portal]에 최소 3년간 보존한다.(3.1.2.3)

6. 오픈소스 사용

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

올바른 오픈소스 컴플라이언스 활동을 위해 소프트웨어 개발/배포 조직은 다음 사항을 준수해야 한다.(3.3.1.1)

  • 오픈소스 컴플라이언스 프로세스의 모든 과정은 Jira Tracker에 기록하여 보존한다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(4) 오픈소스 BOM (Bill of Materials) 생성

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

회사의 오픈소스 컴플라이언스 프로세스를 통해 오픈소스 도구를 활용하여 오픈소스 BOM을 생성하고 보존할 수 있다.

(5) 컴플라이언스 이슈 수정 절차

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

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

7. 오픈소스 기여

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

(1) 리뷰 요청 및 승인

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

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

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

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

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

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

(3) 지식 재산 노출 주의

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

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

(4) CLA 서명 주의

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

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

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

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

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

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

(5) 저작권 표시

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

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

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

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

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

(6) 회사 이메일 사용

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

8. 오픈소스 공개

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

(1) 승인

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

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

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

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

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

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

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

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

(4) 유용한 코드 공개

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

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

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

(5) 리소스 확보

개발자를 포함해서 프로젝트에 투입해야 할 리소스를 확보한다.‌

  • 초기에는 일반적인 사내 프로젝트와 비슷한 수준의 개발자가 필요하다.
  • 외부의 기여를 신속하게 리뷰 할 수 있는 개발자가 필요하다.
  • 법무팀, 마케팅팀의 역할도 필요하다.
  • 프로젝트를 유지, 관리하는데 요구되는 인프라에 대한 예산을 확보한다. 여기에는 Github와 같은 프로젝트 호스팅을 위한 도구가 포함된다.

충분한 리소스가 지원되는 환경을 조성할 수 없다면, 오픈소스로 공개하지 않는다.

(6) 회사 이메일 사용

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

9. 외부 문의 대응

(1) 외부 문의 대응책임

외부로부터 오픈소스 컴플라이언스에 대한 문의 및 요청에 대한 대응은 오픈소스 프로그램 매니저가 담당한다.(3.2.1.2)

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

(2) 연락처 공개

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

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

(3) 외부 문의 대응 절차

외부로부터의 오픈소스 컴플라이언스 문의에 신속하고 정확하게 대응한다면 소송까지 진행되는 위험을 크게 줄일 수 있다. 이를 위해 회사는 외부의 오픈소스 컴플라이언스 문의에 대응하기 위해 회사의 오픈소스 컴플라이언스 프로세스에서 정의한 외부 문의 대응 절차를 준수한다.(3.2.1.2)

10. OpenChain

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

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

Appendix 1. 담당자 현황

No역할책임필요 역량담당 조직담당자
1Open Source Program Manager회사의 오픈소스 프로그램에 대한 총괄 책임을 담당한다.1. 소프트웨어 개발 프로세스 이해
2. 저작권, 특허 등 오픈소스 라이선스와 관련한 지식재산 이해
3. 오픈소스 컴플라이언스에 대한 전문 지식
4. 오픈소스 개발 경험
5. 커뮤니케이션 스킬		CTOOOO
2Legal오픈소스 라이선스와 의무를 해석한다. 이러한 의무를 실제 이행하는 등 오픈소스 활용을 위해 발생할 수 있는 법적 위험의 완화를 위한 자문을 제공한다.1. 오픈소스 생태계에 대한 기본 지식
2. 소프트웨어 저작권에 대한 전문 지식
3. 오픈소스 라이선스에 대한 전문 지식		법무팀OOO
3Infrastructure오픈소스 분석 도구를 운영하고 자동화하여 모든 배포용 소프트웨어에 대해 라이선스 분석이 원활히 수행되도록 시스템을 구축한다.1. 오픈소스 컴플라이언스 프로세스에 기본 지식
2. 오픈소스 라이선스 분석 도구에 대한 이해
3. IT 인프라에 대한 전문 지식		IT 인프라팀OOO
4Security오픈소스 보안취약점 분석 도구를 운영하여 모든 배포용 소프트웨어에 대해 보안취약점 분석이 원활히 수행되도록 시스템을 구축한다.1. 오픈소스 컴플라이언스 프로세스에 기본 지식
2. 오픈소스 라이선스 분석 도구에 대한 이해
3. 보안에 대한 전문 지식		보안팀OOO
5Development culture사내 개발자들이 오픈소스를 적극적으로 활용하고 사내외 커뮤니티에 참여하여 선진 개발 문화를 습득할 수 있도록 지원한다.1. 소프트웨어 개발 프로세스 이해
2. 오픈소스 컴플라이언스에 대한 기본 지식
3. 오픈소스 정책에 대한 이해		DROOO
6Development team소프트웨어 개발/배포 조직은 올바른 오픈소스 활용을 위해 오픈소스 정책 및 프로세스를 준수한다.1. 소프트웨어 개발 프로세스 이해
2. 오픈소스 컴플라이언스에 대한 기본 지식
3. 오픈소스 정책에 대한 이해
4. 오픈소스 라이선스에 대한 기본 지식		개발팀전원

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

OOO 주식회사(이하 “회사"라 함)는 소프트웨어를 포함하는 제품과 서비스를 개발하면서 오픈소스 소프트웨어(이하 “오픈소스"라 함)를 적극적으로 활용한다. 회사는 소프트웨어를 배포하면서 오픈소스 라이선스가 부과하는 의무사항을 준수하기 위한 활동을 수행해야 하며 이를 오픈소스 컴플라이언스라고 한다.

1. 소프트웨어 제품 개발/배포를 위한 프로세스

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

general-osc-process

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

개발 부서는 소프트웨어 설계 단계에서 다음 사항을 준수한다.

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

오픈소스 프로그램 매니저는 주요 오픈소스 라이선스 의무, 제한, 권리에 대한 가이드를 작성하고 공개하여 전사의 개발 부서에서 참고하게 한다.

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

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

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

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

2. 소스 코드 검사Auditing Source Code

개발 부서는 IT 담당의 안내에 따라 소스 코드를 제공하여 오픈소스 점검을 요청한다.

IT 담당은 오픈소스 분석 도구를 사용하여 오픈소스 점검을 하고, 오픈소스 BOM을 생성한다.

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

3. 문제 해결Resolving Issues

개발 부서는 소스 코드 검사 단계에서 발견된 모든 문제를 해결한다. 이슈가 된 오픈소스를 제거하거나, 다른 라이선스 하의 오픈소스로 교체하는 등 조치를 한다.

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

4. 검토Reviews

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

5. 승인Approval

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

6. 등록Registration

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

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

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

7. 고지Notices

오픈소스 프로그램 매니저는 고지 의무를 준수하기 위한 오픈소스 고지문을 생성한다. 오픈소스 고지문에는 다음 사항을 포함한다.

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

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

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

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

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

8. 배포 전 확인Pre-Distribution Verifications

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

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

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

9. 배포Distribution

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

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

10. 최종 확인Final Verifications

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

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

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

general-inquiry-process

1. 접수 알림Acknowledge

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

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

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

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

2. 조사 알림Inform

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

3. 내부 조사Investigate

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

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

4. 요청자에게 보고Report

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

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

5. 문제 보완 / 알림Rectify

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

6. 문제 해결 알림Report

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

7. 프로세스 개선Improve

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

6.9.3 - 3. Tools (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에 대해 소개 및 간단한 사용 방법에 대해 알아본다.

6.9.3.1 - FOSSology

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

https://www.fossology.org/

< https://www.fossology.org/ >

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 정보는 어떻게 되는지를 간단히 확인할 수 있다.

6.9.3.2 - SW360

(Updated on August 29, 2023.)

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

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

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

https://www.eclipse.org/sw360/

< https://www.eclipse.org/sw360/ >

주요 특징

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

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

https://www.eclipse.org/sw360/

설치

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

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

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

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

  1. Docker를 통해 Deploy 할 수 있다. : https://github.com/eclipse-sw360/sw360/blob/main/README_DOCKER.md
  2. SW360의 구성요소를 개별적으로 설치할 수 있다. : https://github.com/eclipse/sw360
  3. Vagrant (https://www.vagrantup.com/) 기반 설치 : Vagrant는 가상화 인스턴스를 관리하는 도구로서 sw360vagrant에서는 SW360을 한 번에 Deploy 하기 위한 환경을 제공한다. : https://github.com/sw360/sw360vagrant
    • Vagrant 기반 설치 가이드는 여기에서 확인할 수 있다. (단, 가이드 작성 시점과 현재 코드가 상이하여 정상동작하지 않을 가능성이 있습니다.)

이 가이드에서는 Docker로 Deploy하는 방법을 소개한다. 자세한 사항은 README를 참고한다. : https://github.com/eclipse-sw360/sw360/blob/main/README_DOCKER.md

1. 코드 다운로드

Docker Image 빌드를 위해 코드를 다운로드 한다. 테스트가 완료된 코드는 여기서 받을 수 있다. : https://github.com/haksungjang/sw360/tree/docker_build

git clone -b docker_build https://github.com/haksungjang/sw360.git

2. 빌드

먼저 Docker를 설치한다. (기업 개발자가 사용하려면 유료 구매가 필요할 수 있음에 주의하세요.)

아래와 같이 docker_build.sh를 실행하여 빌드한다.

cd sw360
./docker_build.sh

정상적으로 빌드가 완료되면 아래와 같이 생성된 이미지를 확인할 수 있다.

docker image ls

REPOSITORY                       TAG              IMAGE ID       CREATED          SIZE
eclipse-sw360/sw360              18-development   ab0fd848bf80   8 minutes ago    2.95GB
eclipse-sw360/sw360              latest           ab0fd848bf80   8 minutes ago    2.95GB
ghcr.io/eclipse-sw360/sw360      18-development   ab0fd848bf80   8 minutes ago    2.95GB
ghcr.io/eclipse-sw360/sw360      latest           ab0fd848bf80   8 minutes ago    2.95GB
eclipse-sw360/binaries           18-development   aa7debf0a1fc   8 minutes ago    347MB
eclipse-sw360/binaries           latest           aa7debf0a1fc   8 minutes ago    347MB
ghcr.io/eclipse-sw360/binaries   18-development   aa7debf0a1fc   8 minutes ago    347MB
ghcr.io/eclipse-sw360/binaries   latest           aa7debf0a1fc   8 minutes ago    347MB
eclipse-sw360/base               18-development   e5147733fc88   37 minutes ago   1.52GB
eclipse-sw360/base               latest           e5147733fc88   37 minutes ago   1.52GB
ghcr.io/eclipse-sw360/base       18-development   e5147733fc88   37 minutes ago   1.52GB
ghcr.io/eclipse-sw360/base       latest           e5147733fc88   37 minutes ago   1.52GB
ghcr.io/eclipse-sw360/thrift     0.18.1           0012d7998058   4 weeks ago      152MB
ghcr.io/eclipse-sw360/thrift     latest           0012d7998058   4 weeks ago      152MB
eclipse-sw360/thrift             0.18.1           0012d7998058   4 weeks ago      152MB
eclipse-sw360/thrift             latest           0012d7998058   4 weeks ago      152MB

3. 실행

docker-compose up 명령으로 생성된 이미지를 실행한다.

docker-compose up

정상적으로 실행이 완료되면 아래와 같이 세개의 container가 실행된 것을 볼 수 있다.

docker ps 

CONTAINER ID   IMAGE                 COMMAND                  CREATED         STATUS                   PORTS                                              NAMES
4299fd39010c   eclipse-sw360/sw360   "/app/entry_point.sh"    3 minutes ago   Up 3 minutes             0.0.0.0:8080->8080/tcp, 0.0.0.0:11311->11311/tcp   sw360
13fd5696b140   postgres:14           "docker-entrypoint.s…"   3 minutes ago   Up 3 minutes (healthy)   0.0.0.0:5438->5432/tcp                             sw360-postgresdb-1
7bb70f2daaf4   couchdb               "tini -- /docker-ent…"   3 minutes ago   Up 3 minutes (healthy)   4369/tcp, 9100/tcp, 0.0.0.0:5984->5984/tcp         sw360-couchdb-1

이 상태에서 http://localhost:8080/로 접근하면 다음과 같은 화면에 진입한다.

설정

SW360을 정상적으로 설치한 후에는 아래의 절차대로 초기 설정이 필요하다. 자세한 내용은 여기에서 확인할 수 있다. : SW360 Initial Setup Configuration

1. User, Login 설정

설정을 위해 다음 계정으로 로그인한다.

로그인을 하면 아래와 같이 Not Found라는 표시가 나타나게 된다.

화면 우상단의 아이템 아이콘(큐브 모양)을 클릭하고 Control Panel 탭을 선택한다.

SECURITY > Password Policies > Default Password Policy > PASSWORD CHANGES > Change Requried를 활성화한다.

그리고, 다시 Control Panel탭에서 CONFIGURATION > Instance Settings을 선택한다. 그러면, PLATFORM메뉴를 볼 수 있다.

거기서 Users를 선택한다. 그리고, Default User Associations 메뉴로 진입하고, Apply to Existing Users를 체크한다. 그리고 Save한다.

이번에는 Instance Settings > PLATFORM에서 User Authentication를 선택한다. General로 진입하여 모든 항목을 Uncheck한다. (관리 목적상 필요한 항목은 Check하여 활성화할 수 있다.) 그리고 Save한다.

끝으로, jquery와 font awesome을 활성화시켜야 한다. 이를 위해 Control Panel 탭에서 CONFIGURATION > System Settings으로 진입하면 PLATFORM 하위에 Third Party를 볼 수 있다.

Third Party에 진입하여 JQuery와 Font Awesome을 각각 Enable시킨다.

브라우저를 새로 실행하면 변경 사항이 적용된다.

2. LAR 파일 import

SW360 설정을 위해서는 *.lar 파일들을 import해야 한다. 이를 설정하기 위해서는 메뉴로 진입해야 하는데, 메뉴 버튼은 화면 좌측 상단에 있다.

메뉴에서 Publishing > Import에 진입한다.

우측의 + 버튼을 눌러 LAR 파일을 업로드 할 수 있는데, LAR 파일은 SW360 소스 파일 내 frontend/configuration 폴더 하위에 있다. (예: https://github.com/haksungjang/sw360/tree/docker_build/frontend/configuration)

먼저, Public_Pages_7_4_3_18_GA18.lar 파일을 업로드하고 Continue 버튼을 누른다.

File Summary 화면에서 업로드된 LAR 파일 세부 내용을 볼 수 있다.

제일 아래의 AUTHORSHIP OF THE CONTENT를 Use the Current User as Author로 변경하고 Import 버튼을 누른다.

그러면 Import가 성공적으로 완료된 걸 볼 수 있다.

이와 유사하게 Private_Pages_7_4_3_18_GA18.lar 파일을 Import한다. File Summary 화면에서 아래와 같이 PAGES > Private Pages로 변경한다.

그리고, PERMISSIONS, UPDATE DATA, AUTHORSHIP OF THE CONTENT 항목을 각각 아래 이미지와 같이 선택하고, Import버튼을 눌러 Import를 수행한다.

여기까지 수행을 마친 후 메뉴 상단의 Home 버튼을 누른다.

그럼 아래와 같이 Welcome to SW360! 화면에 진입한다.

Start 버튼을 눌러 SW360 첫 화면에 진입할 수 있다. (모든 항목이 비어있다.)

3. User Account 설정 (테스트용)

SW360 메뉴에서 Admin > User를 선택한다.

화면 하단의 UPLOAD USERS 메뉴에서 테스트를 위한 User 리스트를 업로드 한다. (테스트를 위한 User 리스트는 여기에서 다운 받을 수 있다. : test_users_with_passwords_12345.csv )

그러면 다음과 같이 9개의 User 리스트가 업로드 된 것을 볼 수 있다.

여기서 보이는 User 리스트 중 하나인 user@@sw360.org 계정으로 다시 로그인을 시도한다. Password는 12345이다.

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 등록을 자동화시켜서 관리한다면 효율성이 크게 증가될 것이다.