Chapter2-3.md

오픈소스 컴플라이언스 프로세스

오픈소스 컴플라이언스란 오픈소스 라이선스와 관련된 리스크를 사전에 식별하고 평가하여 리스크 발생 가능성을 최소화하기 위한 활동입니다.

• 론칭 전
  • 지금 바쁘니까 나중에 할게요
  • 곧 론칭 인데 론칭 후에 하면 안되요?
• 론칭 후
  • 헉… GPL 코드가 발견되었...

• 자체 독점 소프트웨어
• 3rd Party 소프트웨어
• 오픈소스

↓

1. 오픈소스 식별 : 소스코드 스캔 대상 선정 및 요청
2. 소스코드 검사 : 소스코드 스캔하여 오픈소스 식별
3. 크로스 체크 : 개발부서와 스캔 결과 크로스 체크
4. 검토 : 라이선스 충돌 및 카피레프트 라이선스 검토
5. 수정 : 필요 시 코드 수정 또는 오픈소스 교체 - 소스코드 공개 의무가 있는 오픈소스는 반드시 제거
6. 등록 : 오픈소스 사용목록을 BOM(Bills of Material)에 등록
7. 고지: 라이선스 고지문 준비
8. 배포 전 확인 : 라이선스 고지문 등록
9. 배포 : 소프트웨어 배포
10. 최종확인

↓

• 저작권 & 라이선스 고지
• 서면 약정서

1. 오픈소스 식별 : 오픈소스 컴플라이언스의 대상이 되는 코드는 클라이언트, 서버, 웹서비스 코드입니다.

• 외부 배포
  • 클라이언트
• 외부 / 내부
  • 서버, 웹서비스
• 내부
  • 운영툴
  • 테스트 코드
  • 내부 전용
  • 빌드툴
• 클라이언트: 배포 대상에 무조건 포함
• 서버: 해외지사, 3rd Party, 퍼블리셔에게 제공되는 경우�배포로 보게 됨
• 웹서비스: AGPL은 네트워크로 연결되어 연동되는 프로그램의 전체 소스코드 공개를 하도록 하고 있음

2. 소스코드 검사 : 오픈소스 식별 도구로 소스코드를 스캔하여 오픈소스를 식별합니다.

회사의 오픈소스 탐지 도구 스크린샷을 삽입하세요.

3. 검토 : GPL 오픈소스를 사용했을 경우, 라이선스 간 요구조건이 모순(라이선스 충돌) 되는 것은 없는지 확인하고,

• MPL : 다른 소스와 결합할 경우, MPL로 선언된 부분만 공개하고 라이선스는 MPL로 선언해야 함
• GPL : 다른 소스와 결합할 경우, 결합되는 모든 소스를 공개해야 하고, 라이선스는 GPL로 선언해야 함
• MPL + GPL : 라이선스 충돌

소스코드 공개 의무가 있는 라이선스는 없는지 확인합니다.

• AGPL
• GPL
• LGPL

4. 수정 : 소스코드 공개 의무가 있는 오픈소스는 제거하거나 다른 오픈소스로 대체하고, 필요 시 상용 라이선스를 구매하기도 합니다.

• AGPL, GPL
  • 코드 공개 준비
  • 다른 오픈소스로 대체 또는 상용 라이선스 구매
• LGPL
  • 코드 공개 준비
  • Dynamic Linking 방식으로 변경
• 상용 폰트
  • 상용 폰트 구매
  • 오픈소스 폰트로 대체

5. 등록 : 모든 이슈가 clear 되면 오픈소스 사용목록을 BOM(Bills of Material)에 등록합니다.

회사의 BOM 관리 도구 스크린샷을 삽입하세요.

6.재검증 : 프로젝트 구성이나 라이브러리 의존도가 변경되는 경우 라이선스 재검증이 필요합니다.