오픈소스 라이선스 리스크 관리

# oss # compliance # linux-master-1

오픈소스 라이선스 리스크 관리

_data/lm11/notes.md의 라이선스 비교 내용을 바탕으로, 실무에서 어떤 리스크를 주의해야 하는지 정리한 노트입니다.

1. 강한 카피레프트(GPL) 계열 리스크

• GPL 코드를 제품에 통합하면, 그 제품 전체에 GPL 의무(소스 공개)가 전파될 수 있습니다.
• 폐쇄형 상용 제품에서 무심코 GPL 라이브러리를 통합하면, 나중에 소스 공개 요구가 들어올 수 있습니다.
• 따라서:
  • GPL 코드는 툴(chain)로만 쓰는지, 런타임에 링크되는지를 구분해서 검토해야 합니다.
  • 배포 대상 바이너리에 GPL 코드가 직접 포함되는지 체크해야 합니다.

2. LGPL 사용 시 체크포인트

• 단순 링크는 상대적으로 안전하지만, LGPL 라이브러리 자체를 수정한 경우 수정분 공개 의무가 생깁니다.
• 상용 앱에서 LGPL을 쓸 때는:
  • “우리가 라이브러리를 수정했는가?”
  • “업데이트 시 교체 가능한 형태(동적 링크 등)로 배포하는가?” 를 함께 확인해야 합니다.

3. BSD / MIT / Apache 계열

• 공통점:
  • 코드 공개 의무가 거의 없고, 저작권 표시만 잘 지키면 대부분 문제 없습니다.
• Apache 라이선스는:
  • 특허 관련 조항이 포함되어 있어, 기업 입장에서 특허 분쟁 리스크를 줄여주는 장점이 있습니다.

4. 실무에서의 기본 전략

• 어떤 라이선스를 쓰고 있는지 목록화 (SBOM 수준까지는 아니어도 리스트 유지)
• 각 라이선스별로:
  • 필수 표기(저작권/라이선스 문구)를 문서/앱 내에 포함
  • GPL 계열은 “배포 범위”와 “소스 공개 의무”를 명확히 이해하고 사용
• 새 라이브러리를 도입할 때:
  • 최소한 GPL / LGPL / BSD / Apache / MIT 중 어느 계열인지 확인
  • 제품의 배포 방식(온프레미스/클라우드/SaaS)에 따라 영향 범위를 체크

요약: 기능만 보지 말고, “이 코드를 쓰면 무엇을 반드시 공개해야 하는가?”를 항상 같이 보는 습관이 필요하다.