라이선스 변경 이전 버전을 유지하는 방법

오픈소스 프로젝트가 라이선스를 변경할 때, 기존에 배포된 과거 버전까지 소급하여 라이선스를 바꿀 수는 없습니다. 저작권법상 이미 오픈소스(BSD, Apache 2.0, MPL 2.0)로 배포된 버전은 영구히 오픈소스 상태를 유지합니다.

이러한 특성 때문에 많은 개발팀이 라이선스 리스크를 회피하기 위해 ‘라이선스 변경 직전의 마지막 오픈소스 버전’에 소프트웨어를 고정(Pinning)하여 사용하는 전략을 취합니다. 본 가이드에서는 버전 경계의 기술적 의미, 실무 버전 고정 방법, 그리고 장기 운용 시 발생하는 보안 취약점 대책을 안내합니다.

1. 버전 경계(Version Boundary)란 무엇인가?

버전 경계(Version Boundary)는 새로운 라이선스가 처음으로 적용된 릴리스 버전을 의미합니다.

• 경계 미만 버전 (Before Boundary): 이전의 자유로운 오픈소스 라이선스가 적용됩니다. (영구 유효)
• 경계 이상 버전 (After Boundary): 소스 공개(Source-Available) 라이선스 조건이 적용되며, 상업적 서비스 제공 등이 제한됩니다.

2. 환경별 버전 고정(Version Pinning) 실무 방법

의도치 않은 자동 업데이트로 인해 라이선스 경계를 넘어서지 않도록 빌드 및 배포 파이프라인에서 정확한 버전을 고정해야 합니다:

1) Dockerfile 컨테이너 이미지 태그 고정

절대로 :latest나 메이저 버전 태그(:7)를 사용하지 말고, 마이너/패치 버전까지 명시합니다:

# 잘못된 예 (라이선스 변경 버전으로 자동 갱신될 위험)
FROM redis:latest
FROM hashicorp/terraform:light

# 올바른 예 (마지막 오픈소스 버전으로 정확히 고정)
FROM redis:7.2.4-alpine
FROM hashicorp/terraform:1.5.5

2) Kubernetes Helm Chart 및 패키지 매니저 설정

Helm values.yaml 파일에서 image.tag를 고정하고, 패키지 매니저의 와일드카드나 캐럿(^) 표기를 제거합니다:

# Helm values.yaml
image:
  repository: redis
  tag: "7.2.4-alpine"
  pullPolicy: IfNotPresent

3. 구 버전을 유지할 때 반드시 직면하는 치명적 한계

구 버전 고정은 단기적으로 라이선스 리스크를 막아주는 유효한 임시 방편이지만, 장기 운영 시 다음과 같은 위험이 발생합니다:

• 공식 보안 패치 공급 중단 (EOL): 공식 개발사는 라이선스 변경 이후의 최신 버전에만 버그 수정 및 보안 패치를 릴리스합니다. 경계 이전 버전은 제로데이(0-day) 취약점이나 CVE가 보고되어도 공식 보안 패치를 받을 수 없습니다.
• 클라우드 환경 및 OS 호환성 단절: 최신 Linux 커널, 신규 CPU 아키텍처, 최신 라이브러리와의 호환성 지원이 중단됩니다.
• 생태계 플러그인 호환성 저하: 주변 드라이버나 플러그인들이 최신 버전 기준으로 발전함에 따라 연동 문제가 발생합니다.

4. 궁극적인 해결책: 커뮤니티 오픈소스 포크로의 전환

보안 패치를 지속적으로 받으면서도 영구한 오픈소스 라이선스를 유지하는 가장 건강한 방법은 중립 재단(Linux Foundation 등)이 이끄는 공식 커뮤니티 포크로 이동하는 것입니다:

• Redis 7.2.4 → Valkey (리눅스 재단, BSD-3-Clause)
• Terraform 1.5.5 → OpenTofu (리눅스 재단, MPL-2.0)
• Elasticsearch 7.10.2 → OpenSearch (아파치 2.0)

포크 전환 시 점검해야 할 구체적인 기술 항목은 커뮤니티 포크 전환 체크리스트에서 확인하실 수 있습니다.