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

2024

한국 소프트웨어 기업이 알아야 할 EU의 3대 디지털 규제 핵심 내용
To Mine or Not To Mine: 독일 법원이 AI 시대의 저작권 딜레마에 내린 판결
중국 저작권 침해 소송 사례 “GPL 기반 소프트웨어 제품은 어차피 소스 공개 의무가 있으니 배껴도 되는 것 아닌가요?
또 다시 Elasticsearch 라이선스 변경, 기업의 대응 방안은?
SPDX 3.0 소개와 기업 도입 전략
프랑스 법원, 대형 통신사 Orange에게 GPL 위반으로 손해배상 판결

한국 소프트웨어 기업이 알아야 할 EU의 3대 디지털 규제 핵심 내용

By 장학성 | 2024년 11일 12월

서론

유럽연합(EU)이 최근 도입한 3대 주요 법안은 한국 기업에게 매우 중요한 의미를 갖습니다. Product Liability Directive(PLD), Cyber Resilience Act(CRA), 그리고 AI Act는 소프트웨어와 AI 시스템의 개발, 배포, 사용에 관한 포괄적인 규제 프레임워크를 제시하고 있습니다.

이 법안들이 한국 기업에 중요한 이유는 다음과 같습니다:

EU 시장 진출: EU는 세계 최대 단일 시장 중 하나로, 많은 한국 기업이 진출을 목표로 하고 있습니다. 이 법안들을 준수하지 않으면 EU 시장 접근이 제한될 수 있습니다.
글로벌 표준 설정: EU의 규제는 종종 글로벌 표준이 되는 경향이 있습니다. 이른바 ‘브뤼셀 효과‘로, 다른 국가들도 유사한 규제를 도입할 가능성이 높습니다.
기업 책임의 확대: 이 법안들은 기업의 책임 범위를 크게 확대합니다. 특히 PLD의 무과실 책임 원칙은 한국 기업들에게 새로운 도전이 될 수 있습니다.

한국 기업들이 이 법안들을 접근할 때 중요하게 고려해야 할 관점은 다음과 같습니다:

선제적 대응: 법안 시행 전에 미리 준비하여 경쟁 우위를 확보해야 합니다.
통합적 접근: 각 법안을 개별적으로 보지 않고, 전체적인 규제 환경의 변화로 인식해야 합니다.
혁신과 규제 준수의 균형: 규제 준수를 위해 혁신을 저해하지 않도록 주의해야 합니다.

이제 각 법안의 주요 내용을 살펴보겠습니다.

1. Product Liability Directive (PLD)

1.1 개요

Product Liability Directive(PLD)는 EU에서 제품 책임에 관한 법적 프레임워크를 현대화하고 디지털 시대에 맞게 조정하는 것을 목표로 합니다. 이 지침은 소프트웨어와 AI 시스템을 포함한 모든 제품에 대해 엄격한 책임 체제를 도입합니다.

1.2 주요 변경사항

소프트웨어의 제품 정의 포함: PLD는 ‘제품’의 정의를 확장하여 소프트웨어를 명시적으로 포함시켰습니다. 이는 운영 체제, 펌웨어, 컴퓨터 프로그램, 애플리케이션 및 AI 시스템을 포함한 모든 종류의 소프트웨어에 적용됩니다.
무과실 책임 원칙: PLD는 ‘무과실 책임’ 원칙을 도입합니다. 이는 제조업체가 과실이 없더라도 제품의 결함으로 인한 손해에 대해 책임을 질 수 있음을 의미합니다.
손해의 범위 확대: PLD는 개인이나 재산에 대한 손해뿐만 아니라 데이터 손상까지 포함하도록 손해의 범위를 확대했습니다.

1.3 적용 범위

PLD는 EU 시장에 출시되거나 서비스되는 모든 제품에 적용됩니다. 이는 EU 외부에서 제조된 제품이라도 EU 시장에서 판매되는 경우 적용됩니다.

1.4 주요 의무사항

의무사항	설명
문서화 및 정보 제공	제조업체는 제품의 기능, 안전성 및 규정 준수에 대한 정확한 문서를 제공해야 합니다.
지속적인 모니터링	제조업체는 제품이 시장에 출시된 후에도 지속적으로 모니터링하고 필요한 경우 업데이트를 제공해야 합니다.
리스크 평가 및 관리	제조업체는 제품의 전체 수명 주기 동안 리스크 평가 및 관리 시스템을 구축해야 합니다.

1.5 시행 일정

PLD는 2024년 11월에 발표될 예정이며, 2년 후인 2026년부터 벌금이 적용될 예정입니다.

1.6 기업에 미치는 영향

책임 범위 확대: 소프트웨어 기업들은 이제 자사의 제품이 야기할 수 있는 모든 종류의 손해에 대해 책임을 져야 합니다. 이는 물리적 손해뿐만 아니라 데이터 손실이나 개인정보 침해까지 포함합니다.
제품 설계 및 개발 프로세스 변화: 기업들은 제품 설계 단계부터 안전성과 보안을 고려해야 합니다. 이는 ‘Security by Design’ 원칙의 적용을 의미합니다.
문서화 및 투명성 강화: 기업들은 제품의 기능, 리스크, 안전 기능 등에 대해 더욱 상세하고 명확한 문서를 제공해야 합니다.
지속적인 모니터링 및 업데이트: 제품이 시장에 출시된 후에도 지속적인 모니터링과 필요한 경우 보안 업데이트를 제공해야 합니다.

2. Cyber Resilience Act (CRA)

2.1 개요

Cyber Resilience Act(CRA)는 EU에서 디지털 제품의 사이버 보안을 강화하기 위해 도입된 법안입니다. 이 법안은 소프트웨어를 포함한 모든 디지털 요소가 있는 제품(Products with Digital Elements, PDEs)에 적용됩니다.

2.2 적용 범위

CRA는 EU 시장에서 판매되는 모든 PDEs에 적용됩니다. 이는 EU 외부에서 제조된 제품이라도 EU 시장에서 판매되는 경우 적용됩니다.

2.3 주요 요구사항

필수 사이버 보안 요구사항: 제조업체는 제품의 리스크에 적합한 “필수 사이버 보안 요구사항"을 갖춘 제품을 개발, 생산, 배포해야 합니다.
사이버 보안 리스크 평가: 제조업체는 PDE와 관련된 사이버 보안 리스크 평가를 수행해야 합니다. 이 평가는 지원 기간 동안 업데이트되어야 하며 제품 수명 주기 전반에 걸쳐 고려되어야 합니다.
취약점 관리: PDEs는 알려진 취약점 없이 시장에 출시되어야 하며, 취약점에 대한 보안 업데이트를 지체 없이 제공해야 합니다. 또한 해결된 취약점을 공개적으로 공개해야 합니다.
지원 기간: 제품의 지원 기간은 예상 사용 시간에 해당해야 하며, 최소 5년 이상이어야 합니다. 지원 기간의 종료 시점(월 및 연도)은 구매 시점에 사용자가 접근할 수 있어야 합니다.
Software Bill of Materials (SBOM): 제조업체는 제품 구성 요소와 취약점을 식별하고 문서화해야 합니다. 이는 최소한 제품의 최상위 종속성에 대한 소프트웨어 구성 목록(SBOM)을 작성하는 것을 포함합니다.
테스팅: 제조업체는 제품 보안을 정기적으로 테스트해야 합니다.
취약점 보고: 제조업체는 취약점 보고 정책을 수립하고 이를 공개적으로 사용할 수 있도록 해야 합니다.

2.4 시행 일정

CRA는 2024년 하반기에 발효될 예정이며, 제조업체는 2027년까지 규정을 준수하는 제품을 EU 시장에 출시해야 합니다.

2.5 기업에 미치는 영향

영향	설명
제품 설계 및 개발 프로세스 변화	기업들은 제품 설계 단계부터 사이버 보안을 고려해야 합니다. 이는 ‘Security by Design’ 원칙의 적용을 의미합니다.
문서화 및 투명성 강화	기업들은 제품의 보안 기능, 취약점, SBOM 등에 대해 더욱 상세하고 명확한 문서를 제공해야 합니다.
지속적인 모니터링 및 업데이트	제품이 시장에 출시된 후에도 지속적인 모니터링과 필요한 경우 보안 업데이트를 제공해야 합니다.
취약점 관리 프로세스 개선	기업들은 취약점을 신속하게 식별, 평가, 해결할 수 있는 프로세스를 구축해야 합니다.

2.6 기업의 대응 방안

보안 중심 설계 도입: 제품 개발 초기 단계부터 보안을 고려한 설계 방법론을 도입합니다.
SBOM 관리 시스템 구축: 제품에 사용된 모든 소프트웨어 구성 요소를 추적하고 관리할 수 있는 시스템을 구축합니다.
취약점 관리 프로세스 개선: 취약점을 신속하게 발견하고 대응할 수 있는 체계를 마련합니다.
장기 지원 계획 수립: 제품의 예상 수명을 고려한 장기 지원 계획을 수립합니다.
보안 테스팅 강화: 정기적이고 체계적인 보안 테스팅 프로세스를 도입합니다.
문서화 및 보고 체계 개선: CRA 요구사항에 맞는 상세한 문서화 및 보고 체계를 구축합니다.
인력 교육 및 역량 강화: 사이버 보안 전문가를 채용하거나 기존 직원의 역량을 강화합니다.

CRA는 디지털 제품의 사이버 보안을 크게 강화할 것으로 예상됩니다. 기업들은 이를 단순한 규제 준수가 아닌 제품 품질과 신뢰성을 높이는 기회로 활용해야 합니다. 선제적인 대응을 통해 EU 시장에서의 경쟁력을 확보하고, 나아가 글로벌 시장에서도 우위를 점할 수 있을 것입니다.

3. AI Act

3.1 개요

AI Act는 EU에서 AI 시스템의 개발, 배포, 사용에 관한 최초의 포괄적인 법적 프레임워크입니다. 이 법안은 AI 시스템의 리스크를 다루고 유럽이 전 세계적으로 주도적인 역할을 할 수 있도록 하는 것을 목표로 합니다.

3.2 AI 시스템의 분류

AI Act는 AI 시스템을 리스크 수준에 따라 다음과 같이 분류합니다:

용인할 수 없는 리스크
고위험
제한된 리스크
최소 리스크

3.3 주요 요구사항

고위험 AI 시스템에 대한 요구사항: 고위험 AI 시스템은 시장에 출시되기 전에 다음과 같은 엄격한 의무사항을 준수해야 합니다:
- 적절한 리스크 평가 및 완화 시스템
- 리스크와 차별적 결과를 최소화하기 위한 고품질 데이터셋
- 결과의 추적성을 보장하기 위한 활동 로깅
- 당국이 규정 준수를 평가하는 데 필요한 모든 정보를 제공하는 상세한 문서
- 배포자에게 명확하고 적절한 정보 제공
- 리스크를 최소화하기 위한 적절한 인간 감독 조치
- 높은 수준의 견고성, 보안 및 정확성
제한된 리스크 AI 시스템에 대한 요구사항: 제한된 리스크 AI 시스템에 대해서는 특정 투명성 의무가 부과됩니다. 예를 들어, 챗봇을 사용할 때 사용자는 기계와 상호작용하고 있다는 사실을 알아야 합니다.
General-Purpose AI 모델에 대한 요구사항: General-Purpose AI 모델에 대해서는 투명성 의무가 부과됩니다. 매우 강력하고 영향력 있는 모델에 대해서는 추가적인 리스크 관리 의무가 부과됩니다.

3.4 시행 일정

AI Act는 2024년 8월 1일에 발효되었으며, 2년 후인 2026년 8월부터 완전히 적용될 예정입니다. 단, 일부 조항은 더 빨리 적용됩니다:

금지 사항은 6개월 후 적용
거버넌스 규칙 및 General-Purpose AI 모델에 대한 의무는 12개월 후 적용
규제 제품에 내장된 AI 시스템에 대한 규칙은 36개월 후 적용

3.5 기업에 미치는 영향

영향	설명
AI 시스템 분류 및 평가	기업들은 자사의 AI 시스템이 어떤 리스크 카테고리에 속하는지 평가하고, 해당 카테고리에 맞는 요구사항을 준수해야 합니다.
고위험 AI 시스템에 대한 엄격한 관리	고위험으로 분류된 AI 시스템을 개발하거나 사용하는 기업은 엄격한 요구사항을 준수해야 합니다. 이는 상세한 문서화, 지속적인 모니터링, 인간 감독 등을 포함합니다.
투명성 강화	모든 AI 시스템에 대해 투명성이 강화됩니다. 특히 챗봇이나 딥페이크와 같은 기술을 사용할 때는 사용자에게 명확히 알려야 합니다.
General-Purpose AI 모델에 대한 추가 의무	General-Purpose AI 모델을 개발하는 기업은 추가적인 투명성 및 리스크 관리 의무를 준수해야 합니다.
국제 경쟁력 고려	EU 기업들은 이러한 규제가 국제 경쟁력에 미치는 영향을 고려해야 합니다. 규제 준수에 따른 비용 증가와 혁신 속도 저하 가능성에 대비해야 하며, 동시에 EU의 높은 AI 표준을 충족하는 것이 글로벌 시장에서 경쟁 우위로 작용할 수 있음을 인식해야 합니다.
윤리적 AI 개발 촉진	AI Act는 기업들이 윤리적이고 책임감 있는 AI 개발에 더 많은 관심을 기울이도록 유도할 것입니다. 이는 기업의 평판 관리와 사회적 책임 측면에서도 중요한 의미를 갖습니다.
AI 거버넌스 체계 구축	기업들은 AI 시스템의 개발, 배포, 모니터링을 위한 내부 거버넌스 체계를 구축해야 합니다. 이는 리스크 관리, 품질 보증, 윤리적 검토 등을 포함하는 종합적인 프레임워크가 되어야 합니다.

3.6 시행 준비를 위한 기업의 대응 방안

AI 시스템 평가 및 분류: 기업은 자사의 AI 시스템을 평가하고 AI Act에 따른 리스크 카테고리를 분류해야 합니다. 이를 통해 각 시스템에 적용되는 규제 요구사항을 파악할 수 있습니다.
규제 준수 로드맵 수립: AI Act의 시행 일정에 맞춰 단계적인 규제 준수 로드맵을 수립해야 합니다. 이는 필요한 자원 할당, 프로세스 개선, 기술 개발 등을 포함해야 합니다.
전문 인력 확보 및 교육: AI 규제 준수를 위한 전문 인력을 확보하고, 기존 직원들에 대한 교육을 실시해야 합니다. 이는 법률, 기술, 윤리 등 다양한 분야의 전문성을 포함해야 합니다.
문서화 및 보고 체계 개선: AI 시스템의 개발, 테스트, 배포, 모니터링 과정을 상세히 문서화하고, 필요시 규제 기관에 보고할 수 있는 체계를 구축해야 합니다.
이해관계자 커뮤니케이션 강화: AI Act의 영향과 기업의 대응 방안에 대해 고객, 파트너, 투자자 등 이해관계자들과 적극적으로 소통해야 합니다.

3.7 AI Act의 주요 특징 및 의의

리스크 기반 접근: AI Act는 AI 시스템의 리스크 수준에 따라 규제의 강도를 달리하는 접근 방식을 채택했습니다. 이는 혁신을 저해하지 않으면서도 필요한 규제를 적용할 수 있는 균형 잡힌 접근법입니다.
투명성과 책임성 강화: 이 법안은 AI 시스템의 개발 및 사용 과정에서 투명성과 책임성을 크게 강화합니다. 이는 AI에 대한 사회적 신뢰를 높이는 데 기여할 것으로 예상됩니다.
윤리적 AI 발전 촉진: AI Act는 AI 시스템이 EU의 기본 가치와 권리를 존중하도록 요구함으로써, 윤리적이고 책임감 있는 AI 발전을 촉진합니다.
글로벌 표준 설정: EU의 AI 규제는 글로벌 표준이 될 가능성이 높습니다. 이는 EU 기업들이 글로벌 시장에서 경쟁력을 가질 수 있는 기회가 될 수 있습니다.

AI Act는 AI 기술의 발전과 그에 따른 사회적 영향을 고려한 포괄적인 규제 프레임워크입니다. 이 법안은 AI의 안전성과 신뢰성을 높이는 동시에 혁신을 촉진하는 것을 목표로 하고 있습니다. 기업들은 이러한 규제 환경의 변화에 선제적으로 대응함으로써 리스크를 관리하고 새로운 기회를 창출할 수 있을 것입니다. AI Act는 단순히 규제 준수의 대상이 아니라, 책임감 있고 지속 가능한 AI 발전을 위한 가이드라인으로 활용되어야 할 것입니다.

4. 세 가지 법안의 상호 연관성

EU의 세 가지 주요 법안(PLD, CRA, AI Act)은 서로 밀접하게 연관되어 있으며, 디지털 제품과 서비스에 대한 포괄적인 규제 프레임워크를 형성합니다. 이들의 상호 연관성을 이해하는 것은 기업의 효과적인 대응 전략 수립에 중요합니다.

4.1 규제 목적의 공통점

법안	주요 목적
PLD	디지털 제품의 안전성 보장 및 소비자 보호 강화
CRA	디지털 제품의 사이버 보안 강화
AI Act	AI 시스템의 안전성, 투명성, 책임성 확보

세 법안 모두 디지털 기술의 안전성과 신뢰성을 높이는 것을 공통 목표로 합니다.

4.2 적용 범위의 중첩

많은 경우, 하나의 제품이나 서비스가 여러 법안의 적용을 받을 수 있습니다. 예를 들어, AI 기능이 포함된 IoT 디바이스는 다음과 같이 세 법안의 적용을 모두 받을 수 있습니다:

PLD: 제품 책임 관점
CRA: 사이버 보안 요구사항
AI Act: AI 기능에 대한 규제

4.3 통합적 접근의 필요성

기업들은 이러한 법안들을 개별적으로 대응하기보다는 통합적인 접근 방식을 채택해야 합니다. 이는 다음과 같은 이점을 제공합니다:

중복 작업 방지
일관된 규제 준수 전략 수립
리소스의 효율적 활용
전체적인 리스크 관리 강화

5. 한국 기업을 위한 권장사항

EU의 새로운 규제 환경에 대응하기 위해 한국 기업들이 고려해야 할 주요 권장사항은 다음과 같습니다:

5.1 규제 준수 태스크포스 구성

법률, 기술, 비즈니스 전문가로 구성된 다학제적 팀 구성
EU 규제 동향을 지속적으로 모니터링하고 분석하는 역할 부여
기업 내 다른 부서와의 원활한 소통 및 협력 체계 구축

5.2 제품 및 서비스 포트폴리오 검토

현재 및 향후 출시 예정인 제품/서비스가 EU 규제의 적용을 받는지 평가
각 제품/서비스에 적용되는 구체적인 규제 요구사항 파악
필요한 경우 제품/서비스 재설계 또는 개선 계획 수립

5.3 문서화 및 투명성 강화

제품 개발, 테스트, 배포 과정의 상세한 문서화 시스템 구축
SBOM(Software Bill of Materials) 작성 및 관리 프로세스 도입
AI 시스템의 의사결정 과정을 설명할 수 있는 방안 마련

5.4 리스크 관리 체계 강화

제품 수명 주기 전반에 걸친 리스크 평가 및 관리 프로세스 수립
사이버 보안 리스크에 대한 지속적인 모니터링 및 대응 체계 구축
AI 시스템의 윤리적 영향 평가 도입

5.5 인적 역량 강화

EU 규제 관련 전문가 채용 또는 육성
임직원 대상 EU 규제 교육 프로그램 운영
외부 전문가 및 컨설팅 기관과의 협력 관계 구축

5.6 R&D 및 혁신 전략 재검토

규제 준수를 고려한 R&D 프로세스 재설계
‘Security by Design’ 및 ‘Privacy by Design’ 원칙 적용
윤리적 AI 개발을 위한 가이드라인 수립

5.7 비즈니스 모델 및 전략 조정

EU 규제가 비즈니스 모델에 미치는 영향 분석
필요한 경우 비즈니스 모델 조정 또는 새로운 수익 모델 개발
EU 시장 진출 또는 확장 전략 재검토

5.8 이해관계자 커뮤니케이션 강화

고객, 파트너, 투자자 등에게 EU 규제 대응 현황 정기적 공유
규제 준수를 통한 제품/서비스의 안전성 및 신뢰성 향상 강조
필요한 경우 규제 준수로 인한 비용 증가에 대한 이해 요청

6. 결론

EU의 새로운 디지털 규제 환경은 한국 기업들에게 도전이자 기회입니다. PLD, CRA, AI Act는 단순한 규제 준수의 대상이 아니라, 더 안전하고 신뢰할 수 있는 디지털 제품과 서비스를 개발하기 위한 프레임워크로 활용될 수 있습니다.

이러한 규제에 선제적으로 대응하는 기업은 다음과 같은 이점을 얻을 수 있습니다:

EU 시장에서의 경쟁 우위 확보
글로벌 표준을 선도하는 기회 획득
제품 및 서비스의 품질과 안전성 향상
고객 신뢰도 제고
장기적인 비즈니스 지속가능성 확보

한국 기업들은 이러한 규제 변화를 새로운 혁신과 성장의 기회로 삼아, 글로벌 디지털 경제에서 더욱 강력한 경쟁력을 갖출 수 있을 것입니다. 규제 준수를 넘어 책임감 있는 기술 개발과 활용을 통해, 기업의 사회적 가치를 높이고 지속 가능한 성장을 이룰 수 있을 것입니다.

Disclaimer: 저는 법률 전문가가 아니며, 이 내용은 법적인 근거가 될 수 없음에 유의하여 주시기 바랍니다. 라이선스 및 법적 문제와 관련된 구체적인 상황에 대해서는 반드시 법률 전문가의 조언을 구하시기 바랍니다.

To Mine or Not To Mine: 독일 법원이 AI 시대의 저작권 딜레마에 내린 판결

By 장학성 | 2024년 11일 6월

이 글은 JBB Rechtsanwält:innen의 블로그 포스트 “To Mine or Not To Mine”(https://jbb.de/to-mine-or-not-to-mine/)를 기반으로 작성하였으며, 텍스트 및 데이터 마이닝(TDM)에 관한 최근 독일 법원의 판결을 설명하고 관련 지식을 공유하기 위한 목적으로 공개합니다.

단, 저는 법률 전문가가 아니며, 이 내용은 법적인 근거가 될 수 없음에 유의하여 주시기 바랍니다. 라이선스 및 법적 문제와 관련된 구체적인 상황에 대해서는 반드시 법률 전문가의 조언을 구하시기 바랍니다.

배경

2021년, 독일의 사진작가 로버트 크네슈케(Robert Kneschke)는 자신의 사진이 LAION(Large-scale Artificial Intelligence Open Network)이라는 비영리 단체가 만든 AI 학습용 데이터셋에 무단으로 포함되었다는 사실을 알게 되었습니다.

AI 학습용 데이터셋이란 인공지능 모델을 훈련시키기 위해 사용되는 대규모 데이터 모음을 말합니다. ‘LAION-5B‘라는 데이터셋은 약 58억 개의 이미지와 그에 해당하는 설명 텍스트로 구성되어 있었습니다. 이러한 데이터셋은 AI가 이미지를 인식하고 이해하는 능력을 향상시키는 데 사용됩니다.

CommonCrawl

이 사건의 핵심에는 ‘CommonCrawl‘이라는 비영리 조직이 중요한 역할을 합니다. CommonCrawl은 정기적으로 인터넷의 ‘백업’ 또는 ‘이미지’를 생성합니다. 이들은 링크를 통해 접근 가능한 모든 웹페이지를 텍스트 형태로 복제합니다.

CommonCrawl의 데이터 수집 방식:
1. 웹페이지의 텍스트 내용을 복제합니다.
2. 이미지, 비디오 등 비텍스트 데이터는 직접 저장하지 않습니다.
3. 대신 이러한 콘텐츠에 대한 링크를 포함한 웹페이지의 소스 코드를 저장합니다.

CommonCrawl은 이렇게 수집한 데이터셋을 자체 웹사이트에서 제공합니다. 이 데이터셋은 웹페이지의 ‘소스 코드’를 포함하고 있어, 연구자들이 인터넷의 구조와 내용을 분석하는 데 사용할 수 있습니다.

LAION의 데이터 처리 과정

LAION은 CommonCrawl이 제공하는 이 데이터셋을 활용하여 자체적인 이미지 데이터셋을 생성했습니다. 이 과정은 다음과 같습니다:

CommonCrawl 데이터셋에서 이미지 링크 추출: LAION은 CommonCrawl 데이터에서 이미지 파일에 대한 링크만을 필터링했습니다.
추가 정보 수집: LAION은 단순히 이미지 링크만 수집하는 것이 아니라, 각 이미지에 대한 추가 정보도 수집하고자 했습니다. 이 추가 정보에는 다음과 같은 것들이 포함됩니다:
- 이미지 설명
- 워터마크 유무
- 청소년 유해 콘텐츠 포함 여부
이미지 다운로드 및 분석: 이러한 추가 정보를 얻기 위해, LAION은 수집한 링크를 통해 실제 이미지를 다운로드하고, 자체 개발한 AI 모델을 사용하여 이미지를 분석했습니다.
데이터셋 구성: 최종적으로 LAION이 만든 데이터셋은 일종의 표 형태로, 각 행에는 이미지 링크와 해당 이미지에 대한 추가 정보가 포함되어 있습니다.

이러한 과정을 통해 LAION은 AI 학습에 활용할 수 있는 대규모 이미지 데이터셋을 구축했습니다. 그러나 이 과정에서 저작권 문제가 제기되었고, 이는 결국 법적 분쟁으로 이어졌습니다.

크네슈케는 자신의 사진이 포함된 웹사이트의 이용약관에 자동화된 콘텐츠 다운로드를 금지하는 조항이 있음에도 불구하고, LAION이 자신의 사진을 무단으로 다운로드하고 분석한 것이 저작권 침해라고 주장했습니다. 이에 대해 LAION은 자신들의 활동이 과학 연구 목적의 텍스트 및 데이터 마이닝(TDM)에 해당하므로 저작권법 제60d조에 따라 허용된다고 반박했습니다.

이 사건은 AI 시대에 데이터 수집과 저작권 보호 사이의 균형을 어떻게 맞출 것인가에 대한 중요한 법적, 윤리적 질문을 제기하게 되었습니다.

소송의 시작

2023년 4월 27일, 크네슈케는 함부르크 지방법원에 LAION을 상대로 저작권 침해 소송을 제기했습니다. 저작권 침해란 저작권자의 허락 없이 저작물을 사용하는 행위를 말합니다. 크네슈케는 자신의 사진이 허락 없이 사용된 것에 대해 이의를 제기하고, 데이터셋에서 자신의 이미지를 제거할 것을 요구했습니다. 이는 AI 시대에 창작자의 권리를 어떻게 보호할 것인가에 대한 중요한 질문을 제기했습니다.

법적 쟁점

이 소송의 핵심 쟁점은 다음과 같습니다:

텍스트 및 데이터 마이닝(TDM) 예외 규정의 적용 범위: TDM 예외 규정이란 저작권법에서 특정 조건 하에 저작권자의 허락 없이도 저작물을 사용할 수 있도록 하는 규정을 말합니다. 이는 연구나 기술 발전을 위해 대량의 데이터를 분석할 필요가 있는 경우에 적용됩니다. 이 소송에서는 AI 학습을 위한 데이터셋 생성이 이 예외 규정에 해당하는지가 쟁점이었습니다. 예를 들어, 연구 목적으로 웹사이트의 텍스트를 자동으로 수집하고 분석하는 것이 저작권 침해인지, 아니면 이 예외에 해당하여 허용되는지를 판단해야 했습니다.
비상업적 과학 연구 목적의 정의: LAION이 주장하는 ‘비상업적 과학 연구’가 정확히 무엇을 의미하는지, 그리고 그들의 활동이 이에 해당하는지가 논점이었습니다.
저작권자의 ‘opt-out’ 권리의 유효성: ‘Opt-out’이란 저작권자가 자신의 작품이 TDM에 사용되는 것을 거부할 수 있는 권리를 말합니다. 이 권리를 어떻게 행사할 수 있고, 어떤 형태의 거부 의사 표시가 유효한지가 쟁점이 되었습니다.

EU 저작권 지침의 영향

2019년 EU는 디지털 단일 시장 저작권 지침(DSM Directive)을 채택했고, 이는 2021년 6월 7일부터 EU 회원국들에서 시행되었습니다. 이 지침은 텍스트 및 데이터 마이닝에 대한 두 가지 예외 규정을 포함하고 있었습니다:

과학 연구 목적의 TDM (제3조)
- 대상: 연구 기관 및 문화유산 기관에만 적용됩니다.
- 목적: 오직 과학 연구를 위한 목적으로만 허용됩니다.
- 권한: 저작권자의 사전 허가가 필요 없으며, 어떤 형태의 보상도 요구되지 않습니다.
- 접근 조건: 합법적으로 접근할 수 있는 데이터에만 적용됩니다(예: 구독, 라이선스, 온라인 무료 콘텐츠 등)
- 제한: 민간 기업의 결정적인 영향력 하에 있는 기관은 제외됩니다.
일반적 목적의 TDM (제4조)
- 대상: 모든 개인이나 단체에 적용됩니다.
- 목적: 모든 목적(상업적 목적 포함)의 TDM에 적용됩니다.
- 권한: 저작권자가 명시적으로 권리를 유보하지 않은 경우에만 적용됩니다.
- 접근 조건: 합법적으로 접근할 수 있는 데이터에만 적용됩니다.
  - Opt-out 메커니즘: 저작권자는 ‘적절한 방식’으로 권리를 유보할 수 있습니다(예: 온라인 콘텐츠의 경우 기계가 읽을 수 있는 형식).
- 데이터 보관: TDM 목적으로 복제물을 보관할 수 있습니다.

독일은 이 지침을 국내법에 반영하여 저작권법을 다음과 같이 개정했습니다:

제44b조: 일반적 목적의 TDM에 대한 예외 규정을 신설했습니다. 이 조항은 상업적 목적을 포함한 모든 목적의 TDM을 허용하지만, 저작권자가 명시적으로 거부(opt-out)할 수 있는 권리를 인정합니다.
제60d조: 과학 연구 목적의 TDM에 대한 기존 예외 규정을 확대했습니다. 이 조항은 비상업적 과학 연구 목적의 TDM에 대해 더 넓은 자유를 부여하며, 저작권자의 opt-out 권리를 인정하지 않습니다.

판결

2024년 9월 27일, 함부르크 지방법원은 LAION의 행위가 저작권 침해에 해당하지 않는다고 판결했습니다. 주요 판결 내용은 다음과 같습니다:

LAION의 데이터셋 생성 활동은 독일 저작권법 제60d조에 따른 비상업적 과학 연구 목적의 TDM에 해당한다.
LAION이 상업 기업과 협력 관계에 있다는 사실만으로는 비상업적 성격이 부정되지 않는다.
웹사이트 이용약관에 명시된 자연어로 된 TDM 금지 문구도 ‘기계가 읽을 수 있는 형식’의 opt-out으로 간주될 수 있다

판결의 의의

TDM 예외 규정의 광범위한 해석:
- 법원은 LAION의 이미지 데이터셋 구축 활동을 비상업적 과학 연구 목적의 TDM으로 인정했습니다.
- 이는 AI 학습 데이터셋 구축과 같은 현대적 연구 방법도 TDM 예외에 포함될 수 있음을 의미합니다.
- 이러한 해석은 AI 연구와 개발에 더 넓은 자유를 제공할 수 있습니다.
비상업적 연구의 정의 확장:
- LAION이 상업 기업과 협력 관계에 있다는 사실이 비상업적 성격을 부정하지 않는다고 판단했습니다.
- 이는 학계와 산업계 간의 협력 연구에 대한 법적 보호를 강화할 수 있습니다.
- 순수 학술 연구뿐만 아니라 산학 협력 프로젝트도 TDM 예외의 혜택을 받을 수 있게 되었습니다.
opt-out 메커니즘에 대한 새로운 해석: 비록 이 사건에서 LAION의 활동이 비상업적 과학 연구 목적의 TDM으로 인정되어 opt-out이 적용되지 않았지만, 이 판단은 더 넓은 맥락에서 중요한 의미를 갖습니다:
- 법적 해석의 유연성: 법원은 ‘기계가 읽을 수 있는 형식’이라는 요건을 기술 발전에 맞춰 유연하게 해석했습니다. 이는 법률이 빠르게 변화하는 기술 환경에 적응할 수 있음을 보여줍니다.
- 향후 상업적 TDM에 대한 영향: 비록 이 사건에서는 적용되지 않았지만, 이 해석은 상업적 목적의 TDM에 대해서는 중요한 의미를 가질 수 있습니다. 상업적 TDM의 경우 저작권자의 opt-out이 유효하기 때문입니다.
- 저작권자를 위한 지침: 이 판결은 저작권자들에게 자신의 콘텐츠를 TDM에서 제외하고 싶다면, 웹사이트 이용약관에 명확한 언어로 이를 명시할 수 있다는 지침을 제공합니다.
- 기술 기업들에 대한 영향: AI 및 데이터 마이닝 기업들은 이제 웹사이트의 이용약관을 더욱 주의 깊게 검토해야 할 수 있습니다.
저작권법과 기술 혁신 간의 균형:
- 이 판결은 저작권 보호와 기술 혁신 촉진 사이의 균형을 모색하려는 시도로 볼 수 있습니다.
- 저작권자의 권리를 완전히 무시하지 않으면서도, AI와 데이터 과학 발전에 필요한 법적 공간을 제공했습니다.

향후 전망

이 판결에 대해 크네슈케는 항소할 수 있으며, 사안의 중요성을 고려할 때 상급 법원이나 유럽사법재판소(CJEU)까지 갈 가능성도 있습니다. 또한 이 판결은 다른 EU 회원국들의 유사 사건에도 영향을 미칠 것으로 보입니다.

이 사건은 AI 시대의 저작권 보호와 기술 혁신 사이의 균형을 어떻게 맞출 것인가에 대한 중요한 법적, 윤리적 질문을 제기하고 있습니다. 앞으로 이 분야에 대한 더 많은 논의와 법적 판단이 이어질 것으로 예상됩니다.

국내 AI 기업에 대한 시사점

이번 판결은 독일의 사례이지만, 국내 AI 기업들에게도 중요한 시사점을 제공합니다:

상업적 목적의 TDM: 이번 판결은 비상업적 연구에 초점을 맞추고 있지만, 상업적 목적의 TDM도 일정 조건 하에서 허용될 수 있음을 시사합니다. 다만, 상업적 TDM의 경우 저작권자의 opt-out 권리를 존중해야 할 것입니다.
데이터 수집 방식: AI 기업들은 데이터 수집 시 웹사이트의 이용약관을 주의 깊게 확인해야 합니다. TDM을 명시적으로 금지하는 조항이 있다면, 이를 존중해야 할 수 있습니다.
연구 협력: 비영리 연구 기관과의 협력을 통해 데이터셋을 구축하는 방식을 고려해볼 수 있습니다. 이는 법적 리스크를 줄이면서도 필요한 데이터를 확보하는 방법이 될 수 있습니다.
투명성과 윤리: AI 모델 개발 과정에서의 데이터 사용에 대해 투명성을 유지하고, 윤리적 가이드라인을 수립하는 것이 중요합니다. 이는 잠재적인 법적 분쟁을 예방하는 데 도움이 될 수 있습니다.
국내법 개정 대비: EU의 저작권 지침과 유사한 법률이 국내에서도 논의될 가능성이 있습니다. AI 기업들은 이러한 법적 변화에 대비하여 자사의 데이터 수집 및 사용 정책을 미리 점검하고 필요한 경우 조정할 필요가 있습니다.

이 사건은 AI 시대의 저작권 보호와 기술 혁신 사이의 균형을 어떻게 맞출 것인가에 대한 중요한 법적, 윤리적 질문을 제기하고 있습니다. 국내 AI 기업들도 이러한 글로벌 트렌드를 주시하며, 책임 있는 AI 개발을 위한 노력을 지속해야 할 것입니다.

중국 저작권 침해 소송 사례 “GPL 기반 소프트웨어 제품은 어차피 소스 공개 의무가 있으니 배껴도 되는 것 아닌가요?

By 장학성 | 2024년 9일 23월

오픈소스 소프트웨어의 사용이 널리 퍼지면서, 이와 관련된 법적 문제들도 점점 더 복잡해지고 있습니다. 특히 GPL(GNU General Public License)과 같은 copyleft 라이선스를 사용하는 오픈소스 프로젝트를 기반으로 한 2차적 저작물의 저작권 문제는 많은 기업들에게 골치 아픈 주제입니다. 최근 중국에서 있었던 한 소프트웨어 저작권 침해 소송은 이러한 문제에 대한 중요한 시사점을 제공합니다.

소송 당사자

원고: Wangjing Technology(왕징)
피고:
- Yibang Communication Technology(이방)
- Qi’ao Network Technology(치아오)
- 그리고 3명의 개인(Liu, Wu, Xie)

사건의 개요

2009년, 왕징은 ‘OfficeTen’이라는 융합 통신 스마트 게이트웨이 제품을 개발했습니다.

OfficeTen SDG 1800 by Wangjing - http://www.cncr-it.com/product_detail.php?sid=26&cid=133&id=388

이 제품에 내장된 ‘OfficeTen1800’ 소프트웨어는 오픈소스 프레임워크인 ‘OpenWRT’를 기반으로 개발되었으며, 2013년 국가판권국에서 저작권 등록 증서를 취득했습니다.

이 소프트웨어는 두 가지 구성 요소로 이루어져 있었습니다: OpenWRT를 기반으로 한 기본 시스템 소프트웨어와 상위 계층 기능 소프트웨어입니다. 왕징은 후자가 OpenWRT 시스템과는 “독립적이고 별개의 프로그램"이라고 주장했습니다.

2015년, 왕징은 경쟁사인 이방의 제품이 자사의 저작권을 침해했다고 의심하여 조사를 시작했습니다. 조사 결과, 왕징의 전 직원들이 ‘OfficeTen1800’의 소스코드를 치아오에 제공하여 매우 유사한 소프트웨어를 개발하도록 도왔고, 이 소프트웨어가 이방의 제품에 사용된 것으로 밝혀졌습니다.

감정 결과, 왕징의 ‘OfficeTen1800’과 이방 제품에 사용된 소프트웨어 간의 비오픈소스 코드 동일 비율이 90.2%에 달했고, 이방의 제품에서 왕징의 특수 마크가 발견되었습니다.

소송의 전개

2018년 7월, 왕징은 이방과 치아오를 상대로 소프트웨어 저작권 침해 소송을 제기했습니다. 왕징은 침해 중지와 300만 위안의 손해배상을 요구했습니다.

피고 측의 주장

이방과 치아오는 침해 사실을 부인하며 다음과 같이 주장했습니다:

‘OfficeTen1800’은 ‘OpenWRT’라는 오픈소스 프레임워크를 기반으로 개발되었다.
‘OpenWRT’는 GPLv2 라이선스의 제약을 받는다.
왕징가 ‘OfficeTen1800’의 소스코드를 공개하지 않은 것은 GPLv2 위반이다.
따라서 왕징은 해당 소프트웨어에 대한 저작권을 주장할 수 없다.

법원의 판단

1심 판결

쑤저우 중급법원은 다음과 같이 판단했습니다:

개발자가 오픈소스 제품을 수정하거나 2차 개발한 경우에도, 독창적인 작품을 생성했다면 해당 작품에 대한 저작권을 가진다.
GPLv2 계약에 따라 모든 관련 소프트웨어가 공개되어야 한다고 단정할 수 없다.

이에 따라 법원은 이방과 치아오의 침해 행위를 인정하고, 침해 중지와 50만 위안(약 70,961 달러, 약10억)의 손해배상을 명령했습니다.

최고인민법원의 판결

이방과 치아오가 항소했으나, 최고인민법원은 원심 판결을 유지했습니다. 최고인민법원의 주요 판단 내용은 다음과 같습니다:

이 사건의 당사자들은 ‘OpenWRT’ 시스템 소프트웨어의 권리자가 아니므로, GPLv2 계약 준수 여부를 심리할 수 없다.
왕징의 GPLv2 계약 위반 여부와 저작권 침해에 대한 배상 청구는 별개의 문제이다.
소프트웨어 개발자의 독창적인 기여를 기반으로 한 저작권을 불합리하게 박탈하거나 제한해서는 안 된다.

판결의 의의

이 판결은 오픈소스 소프트웨어를 기반으로 한 2차적 저작물의 저작권 보호에 대해 중요한 시사점을 제공합니다.

독창성의 인정: 법원은 오픈소스 소프트웨어를 기반으로 한 2차적 저작물이라도 개발자의 독창적인 기여가 있다면 저작권 보호의 대상이 될 수 있다고 판단했습니다.
라이선스 위반과 저작권 보호의 분리: GPLv2 라이선스 위반 여부와 저작권 침해에 대한 배상 청구를 별개의 문제로 보았습니다. 이는 라이선스 위반이 있더라도 저작권 자체는 유효할 수 있음을 의미합니다.
권리 남용 방지: 피고 측의 “어차피 소스 공개 의무가 있으니 배껴도 된다"는 주장을 받아들이지 않음으로써, GPL 라이선스를 악용한 무분별한 복제를 방지했습니다.
오픈소스 생태계 보호: 2차적 저작물에 대한 저작권을 인정함으로써, 오픈소스 기반 혁신을 장려하고 건전한 오픈소스 생태계 발전을 도모했습니다.

WordPress 테마 사건과의 유사성

칼스루에 고등법원의 WordPress 테마 사건(2020년 11월 13일 판결, 참조번호 6 U 60/20)에서도 GPLv2가 방어 논리로 주장되었습니다. 이 사건에서 법원은 다음과 같은 중요한 판단을 내렸습니다:

(주장된) 파생 저작물 저작권 소유자가 해당 저작물을 GPLv2에 따라 라이선스했는지 여부에 따라 구분이 이루어져야 합니다.
Copyleft 위반의 단순한 가능성만으로는 저작권 주장에 대항하기에 충분하지 않습니다.
GPLv2의 집행은 라이선서의 책임이며, 사용자가 소프트웨어를 “GPL 라이선스"라고 선언하는 것만으로는 집행될 수 없습니다.
카피레프트 효과가 자동으로 GPL 라이선싱으로 이어지지는 않습니다. 이는 파생 저작물의 저자가 적극적으로 수행해야 하는 행위입니다.

이러한 판단은 중국 최고인민법원의 판결과 맥을 같이 하며, GPL 라이선스와 2차적 저작물의 권리에 대한 국제적인 법적 해석의 흐름을 보여줍니다.

기업의 오픈소스 관리에 대한 시사점

이 판결은 기업의 오픈소스 관리자들에게 다음과 같은 중요한 시사점을 제공합니다:

철저한 라이선스 준수: GPL 등 copyleft 라이선스를 사용하는 오픈소스 소프트웨어를 활용할 때는 해당 라이선스의 요구사항을 철저히 준수해야 합니다.
독창적 기여의 중요성: 오픈소스 프로젝트를 기반으로 개발할 때도 독창적인 기여를 명확히 하고 문서화하는 것이 중요합니다.
소스코드 관리: 오픈소스 코드와 자체 개발 코드를 명확히 구분하고 관리해야 합니다.
법적 리스크 평가: 오픈소스 사용 시 발생할 수 있는 법적 리스크를 사전에 평가하고 대비해야 합니다.
지속적인 모니터링: 자사 제품과 경쟁사 제품의 유사성을 지속적으로 모니터링하여 잠재적인 저작권 침해를 조기에 발견해야 합니다.

결론

이번 중국 법원의 판결과 독일 법원의 유사 판결은 “GPL 기반 소프트웨어 제품은 어차피 소스 공개 의무가 있으니 배껴도 되는 것 아닌가요?“라는 오해를 명확히 해소했습니다. GPL 라이선스를 사용하는 오픈소스 소프트웨어를 기반으로 한 2차적 저작물이라도, 개발자의 독창적인 기여가 있다면 저작권 보호의 대상이 될 수 있습니다.

이는 오픈소스 소프트웨어를 활용한 혁신을 장려하면서도, 무분별한 복제와 저작권 침해를 방지하는 균형 잡힌 접근법이라고 볼 수 있습니다. 기업들은 이러한 법적 해석을 참고하여 오픈소스 정책을 수립하고, 라이선스 준수와 독창적 개발 사이의 균형을 잡아나가야 할 것입니다.

오픈소스 소프트웨어의 사용이 더욱 보편화되는 현재, 이러한 법적 판단은 앞으로 더 많은 국가에서 참고될 것으로 예상됩니다. 따라서 기업의 오픈소스 관리자들은 이러한 법적 동향을 지속적으로 모니터링하고, 자사의 오픈소스 정책에 반영해 나가야 할 것입니다.

마지막으로, 이번 판결은 오픈소스 커뮤니티와 상업적 이용자 모두에게 중요한 메시지를 전달합니다. 오픈소스 정신을 존중하면서도 개발자의 노력과 창의성을 인정하는 것, 그리고 라이선스를 준수하면서도 혁신을 추구하는 것이 건강한 소프트웨어 생태계를 만드는 길임을 다시 한 번 상기시켜 줍니다.

참고문서

2024-09-20 OpenWRT, the GPL and the Supreme People’s Court of China: https://www.ifross.org/?q=node/1676
2023-12-29 오픈 소스 코드 기반 2차적 저작물의 저작권 분쟁 사례: https://www.copyright.or.kr/information-materials/trend/International-copyright-center/download.do?brdctsno=52544&brdctsfileno=22493

이 글은 Perplexity (https://www.perplexity.ai/)와 함께 작성하였습니다.

SKT고객은 Perplexicy Pro를 1년간 무료로 이용할 수 있습니다.: https://perplexity.sktadotevent.com/

또 다시 Elasticsearch 라이선스 변경, 기업의 대응 방안은?

By 장학성 | 2024년 9일 6월

서론: Elasticsearch 라이선스 배경

Elasticsearch는 오픈소스 프로젝트로 시작했으며, 그동안 여러 번의 라이선스 정책 변경을 겪었습니다. 처음에는 Apache 2.0 라이선스 하에 배포되었지만, 2021년 Elastic은 Elastic License 2.0과 Server Side Public License로 라이선스를 변경했습니다. 이후 2024년 8월 30일에는 다시 AGPL-3.0을 추가하는 발표(Elasticsearch is Open Source, Again)를 하면서 주목을 받고 있습니다.

이러한 변화는 오픈소스 커뮤니티뿐만 아니라 이를 사용하는 기업들에도 큰 영향을 미치고 있습니다. 이번 글에서는 Elasticsearch가 왜 다시 라이선스 정책을 변경했는지, 그리고 이를 사용하는 기업들이 어떻게 대응해야 하는지 살펴보겠습니다.

1. Elasticsearch 라이선스 변경의 역사

1.1 Apache 2.0에서 Elastic License 2.0으로의 전환

Elasticsearch는 처음에 Apache 2.0 라이선스를 사용했으나, 2021년 1월 Elastic은 Elastic License 2.0과 SSPL로 전환했습니다. Elastic이 이러한 변화를 선택한 이유는 클라우드 제공자, 특히 AWS와의 경쟁 때문입니다. AWS는 Elasticsearch를 기반으로 한 자체 서비스를 제공하면서도, 이에 대한 기여나 비용 지불 없이 수익을 창출했기 때문에 Elastic은 이를 견제하고자 라이선스를 변경했습니다.

Elastic License 2.0은 소스 코드를 공개하지만 상업적인 클라우드 서비스에서의 사용을 제한하는 라이선스로, Elastic의 기술적 자산을 보호하는 수단으로 활용되었습니다. AWS는 이에 대응해 OpenSearch 프로젝트를 시작하며 Apache 2.0 라이선스를 계속 유지했습니다.

이에 대해서는 이전 블로그, “Elastic License 2.0 그리고 진화하는 오픈소스 라이선스“에서 자세히 다룬 바 있습니다.

1.2 Elastic License 2.0는 오픈소스 라이선스가 아니다

그러나 Elastic License 2.0은 **Open Source Initiative (OSI)**에서 인정하는 오픈소스 라이선스가 아니었습니다. 이는 오픈소스 커뮤니티에서 논란을 불러일으켜습니다. Elastic의 결정은 오픈소스의 자유로운 사용과 상업적 이익 사이에서 갈등을 불러일으켰고, 기업들이 오픈소스를 도입할 때 라이선스 문제에 대한 경각심을 높이는 계기가 되었습니다.

2. Elasticsearch, AGPL-3.0 도입 배경

2.1 AGPL-3.0의 주요 특징

2024년 8월, Elastic은 GNU Affero General Public License v3 (AGPL-3.0)를 Elasticsearch와 Kibana의 무료 부분에 대한 라이선스 옵션으로 추가한다고 발표했습니다. AGPL-3.0은 네트워크를 통한 소프트웨어 사용에 대해서도 소스 코드를 공개해야 한다는 점에서 기존 GPL 라이선스와 차별화됩니다.

AGPL-3.0의 주요 특징은 다음과 같습니다:

소스 코드 공개 의무: 네트워크를 통해 소프트웨어를 제공할 때, 사용자가 요청하면 소스 코드를 제공해야 합니다.
강력한 카피레프트: AGPL-3.0은 소프트웨어의 변경 사항도 동일한 라이선스 하에 배포되도록 요구합니다.

AGPL-3.0에 대한 자세한 가이드는 여기에서 참고하실 수 있습니다.: AGPL-3.0 가이드

2.2 AGPL-3.0으로 복귀한 이유

Elastic이 AGPL-3.0을 선택한 이유는 다음과 같습니다:

오픈소스 커뮤니티와의 관계 회복: 이전의 라이선스 변경으로 인해 커뮤니티의 신뢰를 잃었기 때문에, 이를 회복하고자 OSI가 인정하는 AGPL-3.0으로 돌아섰습니다. Elastic의 창립자이자 CTO인 Shay Banon은 “우리는 항상 오픈소스의 정신과 그것이 가능하게 하는 명확성과 투명성을 강하게 믿어왔습니다"라고 말했습니다.
사용자들에게 더 많은 자유와 유연성 제공: AGPL-3.0은 OSI가 승인한 라이선스로, 사용자들에게 더 많은 권리를 제공합니다.
신뢰도 향상: OSI가 승인한 라이선스를 사용함으로써 오픈소스 커뮤니티 내에서의 신뢰도를 높이고자 했습니다.

Elastic의 이 결정은 커뮤니티와의 관계 회복을 시도하는 동시에, 여전히 상업적 사용을 통제하려는 전략적 선택으로 볼 수 있습니다.

그러나 일부 전문가들은 이러한 변화가 커뮤니티의 신뢰를 빠르게 회복할 수 있을지에 대해 의문을 제기하고 있습니다. 또한, OpenSearch의 성공이 Elastic의 이번 결정에 영향을 미쳤을 수 있다는 분석도 있습니다.

3. 오픈소스 라이선스 변화의 시대, 기업은 어떻게 해야 하나?

이러한 라이선스 변경은 오픈소스를 사용하는 기업들에게 중요한 시사점을 제공합니다. 기업들은 오픈소스 소프트웨어의 라이선스 변경 가능성을 항상 염두에 두고, 이에 대한 대응 전략을 수립해야 할 필요성이 있습니다.

3.1 라이선스 변경에 대한 모니터링

오픈소스 라이선스의 잦은 변경은 기업에게 새로운 법적 리스크를 안겨줄 수 있습니다. 이를 예방하기 위해서는 지속적인 모니터링이 필요하며, 이를 위한 전담 팀 구성 및 관리 시스템 도입이 중요합니다. 오픈소스 가버넌스를 통해 기업 전반에서 오픈소스 라이선스를 준수하도록 체계적인 프로세스를 구축해야 합니다.

전담 팀 구성: 법무팀과 기술팀이 협력하여 라이선스 변화를 추적하는 전담 팀을 구성합니다.
오픈소스 가버넌스: 기업 내부적으로 오픈소스 사용에 대한 명확한 정책과 가이드라인을 수립합니다.
자동화 도구 활용: 소프트웨어 구성 분석(SCA) 도구를 사용하여 사용 중인 오픈소스 컴포넌트와 라이선스를 자동으로 추적합니다.

3.2 교육과 내부 가이드라인 마련

기업 내부에서 오픈소스를 사용하는 개발자들이 라이선스 변경 사항을 이해하고 대응할 수 있도록 교육과 가이드라인을 마련해야 합니다. 이를 통해 라이선스 위반으로 인한 법적 분쟁을 줄일 수 있습니다.

정기적인 교육 프로그램: 개발자와 관리자를 대상으로 오픈소스 라이선스에 대한 정기적인 교육을 실시합니다.
라이선스 가이드 제공: 주요 오픈소스 라이선스의 특징과 준수 사항을 정리한 가이드를 제작하여 배포합니다.
사내 전문가 양성: 오픈소스 라이선스 전문가를 양성하여 내부 자문 역할을 수행하도록 합니다.

3.3 클라우드 환경에서의 AGPL-3.0 대응

클라우드 서비스를 운영하는 기업들은 AGPL-3.0에 대한 법적 의무를 명확히 이해하고, 소스 코드 공개 요청에 대비할 수 있는 체계를 마련해야 합니다. 이러한 대응 전략에는 내부 검토 과정 강화와 대체 라이선스 고려가 포함될 수 있습니다.

내부 검토 강화: 클라우드 서비스에 AGPL-3.0 소프트웨어를 도입하기 전 법적, 기술적 검토를 철저히 수행합니다.
대체 솔루션 검토: AGPL-3.0 라이선스의 제약이 부담스러운 경우, 대체 오픈소스 솔루션이나 상용 솔루션을 고려합니다.
라이선스 준수 자동화: 클라우드 환경에서 사용되는 소프트웨어의 라이선스 준수 여부를 자동으로 확인하는 시스템을 구축합니다.

참고로, AGPL-3.0은 오픈소스를 재배포하거나 외부로 서비스하지 않고 내부에서만 사용할 경우 소스 공개 등의 요구사항을 부과하지 않습니다. 따라서, 사내 용도로만 사용할 경우, 소스 코드 공개 등의 의무 준수 없이 자유롭게 사용 가능합니다. 단, 기업 내 AGPL-3.0 오픈소스의 사용 범위와 그에 대한 의무에 대한 명확한 판단은 사내 법무팀과 논의하시기 바랍니다.

결론: 오픈소스 라이선스 변화, 기업의 전략적 대응

Elasticsearch가 다시 AGPL-3.0으로 돌아가는 결정은 오픈소스 생태계 내에서 큰 의미를 지닙니다. 이는 상업적 이익과 오픈소스 정신 간의 균형을 찾으려는 Elastic의 노력일 뿐만 아니라, 오픈소스를 사용하는 모든 기업에게도 중요한 시사점을 제공합니다.

기업은 오픈소스 라이선스의 변화에 적극적으로 대응해야 하며, 이를 통해 법적 리스크를 줄이고, 기술적 기회를 극대화할 수 있는 전략을 마련해야 합니다. AGPL-3.0과 같은 강력한 카피레프트 라이선스는 클라우드 시대에서 더욱 주목받을 것이며, 기업은 이에 맞춰 내부 시스템을 강화하고, 오픈소스 관리 체계를 발전시켜야 할 것입니다.

오픈소스 라이선스의 변화는 피할 수 없는 현실이지만, 이를 기회로 삼아 적절히 대응하는 기업은 경쟁 우위를 확보할 수 있습니다. 체계적인 오픈소스 관리 전략을 통해 법적 리스크를 최소화하고 기술적 이점을 극대화함으로써, 기업은 오픈소스 생태계 내에서 지속 가능한 성장을 이룰 수 있을 것입니다.

이 글은 Perplexity(https://www.perplexity.ai/)와 함께 작성하였습니다.

SKT고객은 Perplexicy Pro를 1년간 무료로 이용할 수 있습니다.: https://perplexity.sktadotevent.com/

SPDX 3.0 소개와 기업 도입 전략

By 장학성 | 2024년 9일 6월

1. SPDX 3.0 소개

SPDX(Software Package Data Exchange)는 소프트웨어 구성 요소, 라이선스, 저작권 및 보안 정보를 표준화된 방식으로 전달하기 위한 오픈 표준입니다. SPDX 3.0은 이 표준의 최신 버전으로, 2024년 4월에 출시되었으며 소프트웨어 공급망의 투명성과 보안을 크게 향상시키는 중요한 업데이트입니다[2].

SPDX의 정의와 목적

SPDX는 Linux Foundation의 프로젝트로, 소프트웨어 패키지와 관련된 중요 정보를 공유하기 위한 표준 형식을 제공합니다. 주요 목적은 다음과 같습니다:

소프트웨어 구성 요소의 투명성 제공
라이선스 컴플라이언스 개선
보안 취약점 관리 지원
소프트웨어 공급망의 신뢰성 향상

SPDX 3.0의 주요 변경사항

SPDX 3.0은 이전 버전에 비해 큰 변화를 가져왔습니다:

모듈화된 구조: SPDX 3.0은 코어 모델과 여러 프로필로 구성되어 있어, 다양한 사용 사례에 유연하게 대응할 수 있습니다.
확장성 개선: 새로운 버전은 사용자 정의 필드와 관계를 쉽게 추가할 수 있어, 미래의 요구사항에 대응할 수 있습니다.
다양한 프로필 지원: 소프트웨어, 보안, 라이선스, 빌드, AI/ML 등 다양한 프로필을 제공하여 특정 도메인의 요구사항을 충족시킵니다.
향상된 데이터 모델: 엔티티 간의 관계를 더 명확하게 표현할 수 있어, 복잡한 소프트웨어 구조를 더 정확하게 기술할 수 있습니다.

SPDX 3.0의 중요성

SPDX 3.0은 다음과 같은 이유로 기업의 오픈소스 관리에 중요합니다:

SBOM 생성 표준화: 소프트웨어 부품 목록(SBOM) 생성을 위한 표준 형식을 제공하여, 조직 간 정보 교환을 용이하게 합니다.
규제 준수 지원: 미국 NTIA의 SBOM 최소 요구사항을 충족하며, 다양한 국제 표준 및 규제에 부합합니다.
보안 강화: CVE 정보와의 통합을 통해 취약점 관리를 개선하고, 소프트웨어 공급망 보안을 강화합니다.
글로벌 표준화: ISO/IEC 5962:2021로 채택되어 국제적으로 인정받는 표준이 되었습니다[2].

SPDX 3.0은 소프트웨어 개발 및 배포 과정에서 투명성, 보안, 컴플라이언스를 크게 향상시키는 강력한 도구입니다. 기업의 오픈소스 관리자는 이 표준을 이해하고 적용함으로써, 조직의 소프트웨어 관리 프로세스를 현대화하고 리스크를 줄일 수 있습니다.

Citations:
[1] https://fossa.com/blog/understanding-using-spdx-license-identifiers-license-expressions/
[2] https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[3] https://fossa.com/learn/spdx
[4] https://fossa.com/blog/sbom-examples-explained/
[5] https://ossna2023.sched.com
[6] https://ossna2023.sched.com/list/descriptions/
[7] https://fossa.com/blog/spdx-3-0/

2. SPDX 3.0의 핵심 기능

SPDX 3.0은 소프트웨어 패키지 데이터 교환의 최신 버전으로, 이전 버전에 비해 크게 개선된 기능을 제공합니다. 주요 핵심 기능은 다음과 같습니다:

모듈화된 구조

SPDX 3.0은 모듈화된 구조를 도입하여 유연성과 확장성을 크게 향상시켰습니다[1][5]. 이 구조는 다음과 같은 요소로 구성됩니다:

코어 모델: 모든 SPDX 문서의 기본이 되는 핵심 요소들을 정의합니다.
프로필: 특정 사용 사례에 맞춘 추가 정보와 기능을 제공합니다.

이러한 모듈화된 접근 방식은 사용자가 필요한 정보만을 선택적으로 사용할 수 있게 하여, 복잡성을 줄이고 효율성을 높입니다.

확장성 개선

SPDX 3.0은 사용자 정의 필드와 관계를 쉽게 추가할 수 있도록 설계되었습니다[5]. 이는 다음과 같은 이점을 제공합니다:

새로운 기술과 요구사항에 빠르게 대응 가능
산업별 특수한 요구사항을 쉽게 통합 가능
미래의 소프트웨어 생태계 변화에 유연하게 적응 가능

다양한 사용 사례 지원

SPDX 3.0은 6가지 주요 프로필을 통해 다양한 사용 사례를 지원합니다[7]:

보안 프로필: 취약점 정보와 보안 관련 메타데이터를 포함
라이선스 프로필: 상세한 라이선스 정보와 컴플라이언스 데이터 제공
AI 프로필: AI 모델 훈련 및 특성화 관련 정보 포함
데이터셋 프로필: 데이터셋의 출처와 특성 정보 제공
소프트웨어 패키징 프로필: 패키지 구조와 의존성 정보 포함
빌드 프로세스 프로필: 소프트웨어 빌드 과정에 대한 상세 정보 제공

이러한 프로필들은 소프트웨어 엔지니어, 보안 전문가, 법률 및 규정 준수 전문가들이 SPDX를 더 쉽게 사용할 수 있도록 돕습니다[7].

향상된 데이터 모델

SPDX 3.0은 엔티티 간의 관계를 더 명확하게 표현할 수 있는 향상된 데이터 모델을 제공합니다[1]. 이를 통해:

복잡한 소프트웨어 구조를 더 정확하게 기술 가능
소프트웨어 구성 요소 간의 의존성을 더 명확하게 표현 가능
보안 및 라이선스 정보를 더 세밀하게 연결 가능

국제 표준 준수

SPDX 3.0은 ISO/IEC 5962:2021 표준을 준수하며, 이는 글로벌 소프트웨어 공급망 관리에 중요한 의미를 갖습니다[5][6]. 이를 통해:

국제적으로 인정받는 형식으로 SBOM 생성 가능
다양한 규제 요구사항(예: 미국 정부 EO 14028, EU 사이버 복원력법)을 충족 가능
조직 간 소프트웨어 정보 교환의 일관성과 신뢰성 향상

SPDX 3.0의 이러한 핵심 기능들은 소프트웨어 공급망의 투명성, 보안, 그리고 컴플라이언스를 크게 개선하며, 현대적인 소프트웨어 개발 및 관리 요구사항을 충족시키는 데 중요한 역할을 합니다.

Citations:
[1] https://scribesecurity.com/ko/blog/spdx-vs-cyclonedx-sbom-formats-compared/
[2] https://github.com/spdx/spdx-3-model/releases
[3] https://olis.or.kr/license/licenseSPDX.do?mapcode=010107
[4] https://ettrends.etri.re.kr/ettrends/203/0905203008/0905203008.html
[5] https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[6] https://www.prnewswire.com/news-releases/spdx-3-0-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases-302118321.html
[7] https://www.gttkorea.com/news/articleView.html?idxno=5131

3. SPDX 3.0 프로필

SPDX 3.0에서 도입된 프로필 개념은 다양한 사용 사례에 맞춰 SPDX 데이터를 구성하고 관리할 수 있게 해주는 핵심 기능입니다. 각 프로필은 특정 도메인이나 사용 사례에 필요한 정보와 구조를 정의합니다.

코어 프로필

코어 프로필은 모든 SPDX 문서의 기본이 되는 핵심 요소들을 정의합니다.

주요 구성 요소:
- Element: 모든 SPDX 객체의 기본 클래스
- Artifact: 소프트웨어 구성 요소를 나타내는 클래스
- Agent: 개인, 조직, 도구 등을 나타내는 클래스
- Relationship: 엔티티 간의 관계를 정의하는 클래스
목적: 다른 모든 프로필에서 공통적으로 사용되는 기본 구조와 정보를 제공합니다.
사용 예: 모든 SPDX 문서는 코어 프로필을 기반으로 작성되며, 여기에 다른 프로필의 정보가 추가됩니다.

소프트웨어 프로필

소프트웨어 프로필은 소프트웨어 패키지와 관련된 상세 정보를 제공합니다.

주요 구성 요소:
- Package: 소프트웨어 패키지에 대한 정보
- File: 개별 파일에 대한 정보
- Snippet: 파일의 일부분에 대한 정보
목적: 소프트웨어의 구조, 구성 요소, 메타데이터를 상세히 기술합니다.
사용 예: 오픈 소스 라이브러리의 구조와 구성 요소를 문서화할 때 사용됩니다.

보안 프로필

보안 프로필은 소프트웨어의 보안 관련 정보를 다룹니다.

주요 구성 요소:
- Vulnerability: 취약점 정보
- Assessment: 취약점 평가 정보
목적: 소프트웨어의 보안 취약점과 관련 평가 정보를 제공합니다.
사용 예: CVE(Common Vulnerabilities and Exposures) 정보를 SPDX 문서에 포함시킬 때 사용됩니다.

라이선스 프로필

라이선스 프로필은 소프트웨어 라이선스 관련 정보를 상세히 다룹니다.

주요 구성 요소:
- License: 라이선스 정보
- LicenseExpression: 복잡한 라이선스 표현
목적: 소프트웨어의 라이선스 정보를 정확하고 상세하게 기술합니다.
사용 예: 오픈 소스 소프트웨어의 라이선스 정보를 문서화할 때 사용됩니다.

빌드 프로필

빌드 프로필은 소프트웨어 빌드 프로세스에 대한 정보를 제공합니다.

주요 구성 요소:
- BuildStep: 빌드 단계 정보
- BuildTool: 빌드 도구 정보
목적: 소프트웨어가 어떻게 컴파일되고 패키징되는지에 대한 상세 정보를 제공합니다.
사용 예: CI/CD 파이프라인의 빌드 프로세스를 문서화할 때 사용됩니다.

AI/ML 프로필

AI/ML 프로필은 인공지능과 머신러닝 모델에 특화된 정보를 다룹니다.

주요 구성 요소:
- AIModel: AI 모델 정보
- Dataset: 학습 데이터셋 정보
목적: AI/ML 모델의 특성, 학습 데이터, 성능 메트릭 등을 기술합니다.
사용 예: 딥러닝 모델의 구조와 학습 데이터셋을 문서화할 때 사용됩니다.

각 프로필은 SPDX 3.0의 모듈화된 구조를 반영하며, 사용자는 필요에 따라 적절한 프로필을 선택하여 SPDX 문서를 생성할 수 있습니다. 이를 통해 소프트웨어 공급망의 다양한 측면을 효과적으로 문서화하고 관리할 수 있습니다.

Citations:
[1] https://spdx.dev/leveraging-profiles-for-license-compliance-insights-from-spdx-mini-summit/
[2] https://spdx.dev/providing-transparency-at-software-developments-core-process-build-time/
[3] https://spdx.github.io/spdx-spec/v2.3/SPDX-license-list/
[4] https://spdx.dev/capturing-software-vulnerability-data-in-spdx-3-0/
[5] https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[6] https://spdx.dev/understanding-spdx-profiles/
[7] https://github.com/spdx/spdx-3-model/actions
[8] https://spdx.github.io/spdx-spec/v3.0/model/AI/AI/

4. SPDX 3.0 데이터 모델

SPDX 3.0의 데이터 모델은 이전 버전에 비해 더욱 유연하고 확장 가능하도록 설계되었습니다. 이 모델은 소프트웨어 공급망의 복잡성을 더 잘 반영하고, 다양한 사용 사례를 지원합니다.

주요 엔티티 및 관계

Element
- SPDX 3.0의 모든 주요 객체의 기본 클래스입니다.
- 모든 Element는 고유한 SPDX ID를 가집니다.
Artifact
- 소프트웨어 구성 요소를 나타냅니다 (예: 패키지, 파일, 스니펫).
- 이름, 버전, 공급자 등의 속성을 포함합니다.
Agent
- 개인, 조직, 도구 등 SPDX 문서 생성에 관여한 주체를 나타냅니다.
Relationship
- 엔티티 간의 관계를 정의합니다 (예: 의존성, 포함 관계).
- 소스, 대상, 관계 유형을 지정합니다.
LifecycleScopedRelationship
- 소프트웨어 라이프사이클 단계와 관련된 특정 관계를 나타냅니다.
Annotation
- 엔티티에 대한 추가 정보나 주석을 제공합니다.

식별자 체계

SPDX 3.0은 더 강력하고 유연한 식별자 체계를 도입했습니다:

SPDX ID: 모든 Element에 대해 고유한 식별자를 제공합니다.
외부 식별자: 다른 시스템의 식별자를 참조할 수 있습니다 (예: CVE, PURL).
네임스페이스: 식별자의 범위를 명확히 하고 충돌을 방지합니다.

메타데이터 관리

CreationInfo
- SPDX 문서 자체에 대한 메타데이터를 포함합니다.
- 생성 날짜, 작성자, 도구 버전 등의 정보를 제공합니다.
프로필별 메타데이터
- 각 프로필(소프트웨어, 보안, 라이선스 등)에 특화된 메타데이터 필드를 정의합니다.

확장성 메커니즘

사용자 정의 속성
- 표준 필드 외에 사용자가 정의한 추가 속성을 포함할 수 있습니다.
외부 참조
- 외부 시스템이나 문서에 대한 링크를 제공합니다.

데이터 타입

SPDX 3.0은 다양한 데이터 타입을 지원합니다:

문자열, 정수, 부울, 날짜/시간
열거형 (예: 라이선스 타입, 관계 타입)
복합 타입 (예: 버전 범위, 체크섬)

직렬화 형식

SPDX 3.0 데이터 모델은 다양한 형식으로 직렬화될 수 있습니다:

JSON-LD
YAML
RDF
XML

이러한 다양한 형식 지원은 다른 시스템과의 통합을 용이하게 합니다.

프로필 지원

데이터 모델은 다양한 프로필을 지원하도록 설계되었습니다:

코어 프로필: 모든 SPDX 문서에 공통적인 기본 요소
소프트웨어 프로필: 소프트웨어 패키지 관련 정보
보안 프로필: 취약점 및 보안 관련 데이터
라이선스 프로필: 상세한 라이선스 정보
AI/ML 프로필: AI 모델 관련 메타데이터
데이터셋 프로필: 데이터셋 관련 정보

각 프로필은 특정 사용 사례에 필요한 추가 필드와 관계를 정의합니다.SPDX 3.0의 데이터 모델은 소프트웨어 공급망의 복잡성을 포괄적으로 표현할 수 있으며, 동시에 특정 도메인의 요구사항을 충족시킬 수 있는 유연성을 제공합니다. 이를 통해 조직은 소프트웨어 구성 요소에 대한 더 정확하고 상세한 정보를 관리하고 공유할 수 있게 되었습니다.

5. SPDX 3.0 구현 가이드

SPDX 3.0을 효과적으로 구현하기 위한 상세한 가이드를 제공합니다.

도구 및 라이브러리

SPDX 3.0을 지원하는 주요 도구와 라이브러리는 다음과 같습니다:

SPDX Java 라이브러리
- GitHub: https://github.com/spdx/tools-java
- 기능: SPDX 문서 파싱, 생성, 변환, 검증
- 사용법: Maven 의존성으로 추가하여 Java 프로젝트에서 사용
SPDX Python 라이브러리
- GitHub: https://github.com/spdx/tools-python
- 기능: SPDX 문서 파싱, 생성, 검증
- 특징: SPDX 3.0에 대한 실험적 지원 제공
SPDX Online Tools
- 웹사이트: https://tools.spdx.org
- 기능: 웹 기반 SPDX 문서 생성 및 검증
FOSSology
- GitHub: https://github.com/fossology/fossology
- 기능: 오픈소스 컴플라이언스 도구로, SPDX 문서 생성 지원
SPDX SBOM Generator
- GitHub: https://github.com/opensbom-generator/spdx-sbom-generator
- 기능: 다양한 프로그래밍 언어 프로젝트에 대한 SPDX SBOM 생성

이러한 도구들을 활용하여 SPDX 3.0 문서를 생성, 파싱, 검증할 수 있습니다.

파일 형식 (JSON, YAML, RDF)

SPDX 3.0은 다양한 파일 형식을 지원합니다:

JSON-LD

가장 권장되는 형식

예시:

{
  "@context": "<https://spdx.org/spdx-3.0-context.jsonld>",
  "@type": "SpdxDocument",
  "name": "Example SPDX 3.0 Document",
  "elements": [
    {
      "@type": "Package",
      "name": "ExamplePackage",
      "version": "1.0.0"
    }
  ]
}

YAML

사람이 읽기 쉬운 형식

예시:

---
$schema: <https://spdx.org/spdx-3.0-schema.json>
spdxVersion: SPDX-3.0
name: Example SPDX 3.0 Document
elements:
  - type: Package
    name: ExamplePackage
    version: 1.0.0

RDF

시맨틱 웹 애플리케이션에 적합

예시:

<rdf:RDF xmlns:rdf="<http://www.w3.org/1999/02/22-rdf-syntax-ns#>"
         xmlns:spdx="<http://spdx.org/rdf/terms#>">
  <spdx:SpdxDocument>
    <spdx:name>Example SPDX 3.0 Document</spdx:name>
    <spdx:element>
      <spdx:Package>
        <spdx:name>ExamplePackage</spdx:name>
        <spdx:versionInfo>1.0.0</spdx:versionInfo>
      </spdx:Package>
    </spdx:element>
  </spdx:SpdxDocument>
</rdf:RDF>

각 형식은 특정 사용 사례에 적합하며, 개발자는 프로젝트 요구사항에 따라 적절한 형식을 선택할 수 있습니다.

기존 SPDX 2.x에서 마이그레이션

SPDX 2.x에서 3.0으로 마이그레이션하는 과정은 다음과 같습니다:

구조 변경 이해
- SPDX 3.0의 모듈화된 구조와 프로필 개념 숙지
- 새로운 필드와 관계 유형 파악
도구 업데이트
- SPDX 3.0을 지원하는 최신 버전의 도구와 라이브러리로 업그레이드
문서 변환
- SPDX Python 라이브러리의 spdx_tools.spdx3.bump_from_spdx2.spdx_document 모듈 사용
- bump_spdx_document() 함수를 통해 SPDX 2.x 문서를 3.0으로 변환
새로운 필드 추가
- SPDX 3.0에서 새롭게 도입된 필드 (예: AI/ML 관련 정보) 추가
관계 재정의
- SPDX 3.0의 새로운 관계 유형을 사용하여 기존 관계 재정의
프로필 적용
- 적절한 SPDX 3.0 프로필 선택 및 적용
검증
- SPDX 3.0 검증 도구를 사용하여 변환된 문서의 유효성 확인
테스트 및 통합
- 변환된 SPDX 3.0 문서를 기존 워크플로우에 통합하고 테스트

마이그레이션 과정에서는 SPDX 커뮤니티 리소스와 문서를 적극 활용하고, 필요한 경우 전문가의 도움을 받는 것이 좋습니다.

이러한 구현 가이드를 따라 SPDX 3.0을 효과적으로 도입하고 활용할 수 있습니다.

Citations:
[1] https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[2] https://www.youtube.com/watch?v=iqVk-Sek8Pc
[3] https://github.com/spdx/Spdx-Java-Library
[4] https://spdx.github.io/spdx-spec/v3.0/annexes/diffs-from-previous-editions/
[5] https://github.com/spdx/spdx-3-model/releases
[6] https://spdx.dev/use/spdx-tools/
[7] https://github.com/spdx/tools-python/blob/main/README.md
[8] https://fossa.com/learn/spdx

6. SBOM과 SPDX 3.0

소프트웨어 부품 목록(Software Bill of Materials, SBOM)은 소프트웨어 공급망 보안의 핵심 요소로 자리잡았습니다. SPDX 3.0은 SBOM 생성과 관리를 위한 강력한 프레임워크를 제공하며, 이를 통해 조직은 더욱 효과적으로 소프트웨어 구성 요소를 추적하고 관리할 수 있습니다.

SBOM 생성 및 관리

자동화된 SBOM 생성
- SPDX 3.0은 CI/CD 파이프라인에 통합되어 자동으로 SBOM을 생성할 수 있습니다[6].
- 이는 “machine-speed” SBOM 생성을 가능하게 하여, 소프트웨어 릴리스 주기에 맞춰 즉시 SBOM을 업데이트할 수 있습니다.
일관된 포맷 사용
- SPDX 3.0은 표준화된 SBOM 포맷을 제공하여 일관성을 보장합니다[6].
- 이를 통해 조직 간 SBOM 데이터 교환이 용이해지고, 자동화된 분석이 가능해집니다.
정기적인 업데이트
- 각 소프트웨어 릴리스마다 SBOM을 업데이트해야 합니다[6].
- SPDX 3.0의 자동화 기능을 활용하면 이 프로세스를 효율적으로 관리할 수 있습니다.
메타데이터 포함
- SPDX 3.0은 라이선스 정보, 패치 상태 등 풍부한 메타데이터를 SBOM에 포함할 수 있게 합니다[6].
- 이는 보안 및 컴플라이언스 관리를 크게 개선합니다.

SPDX 3.0을 활용한 SBOM 개선

모듈화된 구조
- SPDX 3.0의 프로필 기반 구조를 활용하여 다양한 사용 사례에 맞는 SBOM을 생성할 수 있습니다[1].
- 소프트웨어, 보안, 라이선스 등 각 프로필에 특화된 정보를 SBOM에 포함시킬 수 있습니다.
보안 취약점 정보 통합
- SPDX 3.0의 보안 프로필을 활용하여 SBOM에 취약점 정보를 직접 포함시킬 수 있습니다[1].
- 이를 통해 보안 팀은 더 빠르고 효과적으로 취약점을 식별하고 대응할 수 있습니다.
라이선스 컴플라이언스 강화
- SPDX 3.0의 라이선스 프로필을 활용하여 상세한 라이선스 정보를 SBOM에 포함시킬 수 있습니다[2].
- 이는 법률 및 컴플라이언스 팀이 라이선스 의무사항을 더 쉽게 파악하고 관리할 수 있게 합니다.
AI/ML 모델 정보 포함
- SPDX 3.0의 AI/ML 프로필을 활용하여 AI 모델 및 데이터셋 정보를 SBOM에 포함시킬 수 있습니다[2].
- 이는 AI 시스템의 투명성과 책임성을 높이는 데 기여합니다.

NTIA 최소 요구사항 충족

SPDX 3.0은 NTIA(National Telecommunications and Information Administration)가 정의한 SBOM 최소 요구사항을 충족하고 있습니다[4][5].

기본 데이터 필드
- SPDX 3.0은 NTIA가 요구하는 7가지 기본 데이터 필드를 모두 포함합니다:
  - 공급자 이름
  - 구성 요소 이름
  - 구성 요소 버전
  - 기타 고유 식별자
  - 의존성 관계
  - SBOM 작성자
  - 타임스탬프
자동화 및 상호운용성
- SPDX 3.0은 기계 판독 가능한 형식(JSON-LD, YAML, RDF)을 지원하여 NTIA의 자동화 요구사항을 충족합니다[5].
실행 가능성
- SPDX 3.0은 다양한 도구와 라이브러리를 통해 SBOM 생성 및 관리를 지원하여 실행 가능성을 보장합니다.
확장성
- SPDX 3.0의 모듈화된 구조는 미래의 요구사항을 수용할 수 있는 확장성을 제공합니다.

SPDX 3.0을 활용한 SBOM 관리는 단순히 규제 요구사항을 충족하는 것을 넘어, 조직의 소프트웨어 공급망 보안을 크게 강화하고 투명성을 높이는 데 기여합니다. 이는 궁극적으로 더 안전하고 신뢰할 수 있는 소프트웨어 생태계 구축으로 이어집니다.

Citations:
[1] https://spdx.dev/capturing-software-vulnerability-data-in-spdx-3-0/
[2] https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[3] https://www.legitsecurity.com/blog/best-practices-for-managing-maintaining-sboms
[4] https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom
[5] https://cybellum.com/blog/ntia-minimum-elements-for-a-software-bill-of-materials-sbom-a-guide/
[6] https://jfrog.com/devops-tools/article/best-practices-for-software-bill-of-materials-management/
[7] https://about.gitlab.com/blog/2022/10/25/the-ultimate-guide-to-sboms/
[8] https://scribesecurity.com/sbom/how-to-generate-an-sbom/

7. 보안 및 취약점 관리

SPDX 3.0은 소프트웨어 보안 및 취약점 관리를 위한 강력한 기능을 제공합니다. 이를 통해 조직은 소프트웨어 공급망의 보안을 더욱 효과적으로 관리할 수 있습니다.

CVE 정보 통합

CVE(Common Vulnerabilities and Exposures) 정보를 SPDX 3.0 문서에 통합하는 것은 보안 관리의 핵심 요소입니다.

CVE 참조 방법

SPDX 3.0은 ExternalReference 클래스를 사용하여 CVE 정보를 참조합니다.

예시:

{
  "@type": "ExternalReference",
  "referenceType": "SecurityAdvisory",
  "referenceLocator": "CVE-2021-44228",
  "referenceCategory": "CVE"
}

CVE 상세 정보 포함
- CVSS(Common Vulnerability Scoring System) 점수
- 영향을 받는 버전 범위
- 패치 가능 여부 및 패치 정보
자동 CVE 업데이트
- SPDX 3.0 도구들은 NVD(National Vulnerability Database)와 같은 외부 소스에서 자동으로 CVE 정보를 가져와 SPDX 문서를 업데이트할 수 있습니다.
CVE 정보와 구성 요소 연결
- SPDX 3.0은 특정 소프트웨어 구성 요소와 관련 CVE 정보를 명확하게 연결할 수 있습니다.
- 이를 통해 취약한 구성 요소를 쉽게 식별하고 추적할 수 있습니다.

취약점 추적 및 보고

SPDX 3.0은 취약점을 효과적으로 추적하고 보고하기 위한 기능을 제공합니다.

취약점 라이프사이클 관리

발견 날짜, 보고 날짜, 패치 날짜 등 취약점의 전체 라이프사이클을 추적할 수 있습니다.

예시:

{
  "@type": "Vulnerability",
  "name": "CVE-2021-44228",
  "description": "Log4j RCE vulnerability",
  "discoveredDate": "2021-12-09",
  "publishedDate": "2021-12-10",
  "patchedDate": "2021-12-14"
}

취약점 심각도 평가

CVSS 점수를 사용하여 취약점의 심각도를 평가하고 기록할 수 있습니다.

예시:

{
  "@type": "VulnerabilityAssessment",
  "vulnerability": "CVE-2021-44228",
  "cvssV3": {
    "baseScore": 10.0,
    "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"
  }
}

취약점 보고서 생성
- SPDX 3.0 데이터를 기반으로 자동화된 취약점 보고서를 생성할 수 있습니다.
- 보고서에는 영향을 받는 구성 요소, 심각도, 패치 상태 등이 포함됩니다.
취약점 트렌드 분석
- 시간에 따른 취약점 발생 패턴을 분석할 수 있습니다.
- 이를 통해 보안 팀은 장기적인 보안 전략을 수립할 수 있습니다.

보안 프로필 활용

SPDX 3.0의 보안 프로필은 보안 관련 정보를 체계적으로 관리할 수 있게 해줍니다.

보안 프로필 구조
- Vulnerability: 취약점 정보를 나타내는 클래스
- VulnerabilityAssessment: 취약점 평가 정보를 나타내는 클래스
- SecurityAdvisory: 보안 권고사항을 나타내는 클래스

보안 프로필 사용 예시

{
  "@type": "SecurityProfile",
  "vulnerabilities": [
    {
      "@type": "Vulnerability",
      "name": "CVE-2021-44228",
      "description": "Log4j RCE vulnerability"
    }
  ],
  "assessments": [
    {
      "@type": "VulnerabilityAssessment",
      "vulnerability": "CVE-2021-44228",
      "cvssV3": {
        "baseScore": 10.0,
        "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"
      }
    }
  ],
  "advisories": [
    {
      "@type": "SecurityAdvisory",
      "title": "Update Log4j to version 2.15.0 or later",
      "description": "Upgrade Log4j to mitigate CVE-2021-44228"
    }
  ]
}

보안 프로필 활용 방안
- 취약점 스캐닝 도구와 연동하여 자동으로 보안 프로필 업데이트
- 보안 대시보드 구축을 위한 데이터 소스로 활용
- 컴플라이언스 감사 시 보안 상태 증명 자료로 사용
보안 메트릭 추적
- 오픈 취약점 수, 평균 패치 시간, 고위험 취약점 비율 등의 보안 메트릭을 SPDX 3.0 데이터를 기반으로 추적할 수 있습니다.

SPDX 3.0의 보안 및 취약점 관리 기능을 활용함으로써, 조직은 소프트웨어 공급망의 보안을 크게 강화할 수 있습니다. CVE 정보의 통합, 체계적인 취약점 추적 및 보고, 그리고 보안 프로필의 활용은 보안 팀이 더 효과적으로 위협에 대응하고 조직의 전반적인 보안 태세를 개선하는 데 도움을 줍니다.

8. 라이선스 컴플라이언스

SPDX 3.0은 소프트웨어 라이선스 컴플라이언스를 효과적으로 관리할 수 있는 강력한 기능을 제공합니다. 이를 통해 조직은 오픈 소스 및 상용 소프트웨어의 라이선스 의무사항을 더욱 쉽게 파악하고 준수할 수 있습니다.

라이선스 정보 관리

라이선스 식별자
- SPDX 3.0은 표준화된 라이선스 식별자를 사용합니다.
- 예: “MIT”, “Apache-2.0”, “GPL-3.0-only”
- 이를 통해 라이선스 정보의 일관성과 정확성을 보장합니다.

라이선스 텍스트 포함

전체 라이선스 텍스트를 SPDX 문서에 포함시킬 수 있습니다.

예시:

{
  "@type": "License",
  "licenseId": "MIT",
  "name": "MIT License",
  "text": "MIT License\\n\\nCopyright (c) [year] [fullname]\\n\\nPermission is hereby granted, ..."
}

사용자 정의 라이선스
- 표준 SPDX 라이선스 목록에 없는 라이선스의 경우, 사용자 정의 라이선스를 정의할 수 있습니다.
- 이 경우 “LicenseRef-” 접두사를 사용합니다.
- 예: “LicenseRef-CompanyA-Proprietary”
라이선스 표현식
- 복잡한 라이선스 조합을 표현할 수 있습니다.
- 예: “(MIT OR Apache-2.0) AND CC-BY-4.0”
파일 및 패키지 수준 라이선스
- 개별 파일, 스니펫, 패키지 수준에서 라이선스 정보를 지정할 수 있습니다.
- 이를 통해 세분화된 라이선스 관리가 가능합니다.

라이선스 호환성 검사

SPDX 3.0 데이터를 활용하여 라이선스 호환성을 자동으로 검사할 수 있습니다.

라이선스 그래프 생성
- 소프트웨어 구성 요소 간의 의존성과 각 구성 요소의 라이선스 정보를 바탕으로 라이선스 그래프를 생성합니다.
호환성 규칙 정의
- 라이선스 간의 호환성 규칙을 정의합니다.
- 예: GPL-3.0은 Apache-2.0과 호환되지만, GPL-2.0은 Apache-2.0과 호환되지 않습니다.
자동 호환성 검사
- 정의된 규칙을 바탕으로 라이선스 그래프를 분석하여 호환성 문제를 자동으로 식별합니다.
충돌 해결 제안
- 라이선스 충돌이 발견된 경우, 가능한 해결 방안을 제안합니다.
- 예: 특정 구성 요소의 대체 버전 사용, 라이선스 예외 요청 등
동적 분석
- 소프트웨어 빌드 과정에서 실시간으로 라이선스 호환성을 검사할 수 있습니다.
- 이를 통해 개발 초기 단계에서 라이선스 문제를 식별하고 해결할 수 있습니다.

컴플라이언스 보고서 생성

SPDX 3.0 데이터를 기반으로 상세한 라이선스 컴플라이언스 보고서를 생성할 수 있습니다.

리스크 평가
- 각 라이선스 및 라이선스 조합에 대한 법적 리스크를 평가하고 보고합니다.
- 고위험 라이선스 사용에 대한 경고를 제공합니다.
컴플라이언스 워크플로우 통합
- 보고서 생성을 자동화하여 정기적인 컴플라이언스 검토 프로세스에 통합할 수 있습니다.
- CI/CD 파이프라인에 통합하여 각 빌드 또는 릴리스마다 컴플라이언스 보고서를 생성할 수 있습니다.
맞춤형 보고서
- 다양한 이해관계자(법무팀, 개발팀, 경영진 등)의 요구에 맞는 맞춤형 보고서를 생성할 수 있습니다.
- 예: 법무팀을 위한 상세 보고서, 경영진을 위한 요약 보고서 등
이력 관리
- 시간에 따른 컴플라이언스 상태 변화를 추적할 수 있습니다.
- 이를 통해 라이선스 컴플라이언스 개선 노력의 효과를 측정할 수 있습니다.

SPDX 3.0의 라이선스 컴플라이언스 기능을 활용함으로써, 조직은 복잡한 소프트웨어 생태계에서 라이선스 의무사항을 효과적으로 관리하고 준수할 수 있습니다. 이는 법적 리스크를 줄이고, 오픈 소스 커뮤니티와의 관계를 개선하며, 전반적인 소프트웨어 개발 프로세스의 투명성과 신뢰성을 높이는 데 기여합니다.

9. SPDX 3.0 활용 사례

SPDX 3.0은 다양한 산업 분야에서 소프트웨어 관리와 보안을 향상시키는 데 활용될 수 있습니다. 주요 활용 사례는 다음과 같습니다:

소프트웨어 공급망 보안

취약점 식별 및 관리
- SPDX 3.0의 보안 프로필을 활용하여 소프트웨어 구성 요소의 취약점을 체계적으로 추적합니다.
- CVE 정보를 SPDX 문서에 통합하여 실시간으로 보안 위험을 평가할 수 있습니다.
공급망 투명성 확보
- SPDX 3.0을 통해 소프트웨어의 전체 구성 요소와 출처를 명확히 문서화할 수 있습니다.
- 이는 악성 코드 삽입이나 공급망 공격의 위험을 줄이는 데 도움이 됩니다.
빌드 프로세스 보안
- SPDX 3.0의 빌드 프로필을 사용하여 소프트웨어 빌드 과정의 무결성을 보장할 수 있습니다.
- 빌드 도구, 환경, 스크립트 등의 정보를 문서화하여 재현 가능한 빌드를 지원합니다.
신속한 보안 패치 적용
- SPDX 3.0 문서를 통해 취약한 구성 요소를 신속하게 식별하고 패치할 수 있습니다.
- 자동화된 도구와 연계하여 보안 업데이트 프로세스를 최적화할 수 있습니다.

오픈소스 관리

라이선스 컴플라이언스
- SPDX 3.0의 라이선스 프로필을 활용하여 오픈소스 라이선스 의무사항을 체계적으로 관리합니다.
- 복잡한 라이선스 조합을 정확히 표현하고 분석할 수 있습니다.
오픈소스 기여 추적
- SPDX 3.0을 통해 프로젝트 내 오픈소스 구성 요소의 출처와 기여자 정보를 명확히 기록할 수 있습니다.
- 이는 오픈소스 커뮤니티와의 협력을 강화하고 기여를 인정하는 데 도움이 됩니다.
오픈소스 정책 시행
- SPDX 3.0 문서를 조직의 오픈소스 정책과 연계하여 승인된 라이선스 및 구성 요소만 사용되도록 보장할 수 있습니다.
오픈소스 감사 효율화
- SPDX 3.0의 표준화된 형식을 통해 오픈소스 감사 프로세스를 자동화하고 간소화할 수 있습니다.

규제 준수

SBOM 요구사항 충족
- SPDX 3.0은 미국 정부의 행정명령 14028 및 EU의 사이버 복원력 법(Cyber Resilience Act) 등에서 요구하는 SBOM 생성 요구사항을 충족합니다.
산업별 규제 대응
- 의료기기, 자동차, 항공우주 등 다양한 산업 분야의 소프트웨어 관련 규제 요구사항을 SPDX 3.0을 통해 효과적으로 대응할 수 있습니다.
데이터 프라이버시 규정 준수
- SPDX 3.0의 데이터셋 프로필을 활용하여 GDPR, CCPA 등 데이터 프라이버시 규정 준수를 지원할 수 있습니다.
감사 및 보고 지원
- SPDX 3.0 문서를 통해 규제 기관이나 감사자에게 필요한 소프트웨어 구성 및 보안 정보를 쉽게 제공할 수 있습니다.
AI 규제 대응
- SPDX 3.0의 AI/ML 프로필을 활용하여 AI 모델의 훈련 데이터, 알고리즘, 성능 메트릭 등을 문서화함으로써 향후 AI 규제에 선제적으로 대응할 수 있습니다.

SPDX 3.0의 이러한 활용 사례들은 조직이 소프트웨어 관리, 보안, 컴플라이언스를 통합적으로 개선할 수 있게 해줍니다. 표준화된 접근 방식을 통해 조직 간 협력을 촉진하고, 소프트웨어 생태계 전반의 투명성과 신뢰성을 높이는 데 기여합니다.

Citations:
[1] https://linuxsecurity.com/news/organizations-events/spdx-3-0
[2] https://spdx.dev/spdx-announces-3-0-release-candidate-with-new-use-cases/
[3] https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[4] https://www.prnewswire.com/news-releases/spdx-3-0-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases-302118321.html
[5] https://spdx.dev/leveraging-profiles-for-license-compliance-insights-from-spdx-mini-summit/
[6] https://www.synopsys.com/blogs/software-security/sboms-and-spdx.html
[7] https://spdx.dev/understanding-spdx-profiles/

10. SPDX 3.0 도입 전략

SPDX 3.0을 조직에 성공적으로 도입하기 위해서는 체계적인 접근이 필요합니다. 다음은 SPDX 3.0 도입을 위한 상세한 전략입니다.

단계별 구현 계획

현황 분석
- 현재 SBOM 생성 및 관리 프로세스 평가
- 기존 도구 및 워크플로우 분석
- SPDX 3.0 도입으로 얻을 수 있는 이점 식별
파일럿 프로젝트 선정
- 규모가 작고 중요도가 낮은 프로젝트 선택
- SPDX 3.0의 특정 프로필(예: 보안 또는 라이선스) 선택하여 적용
도구 선택 및 구성
- SPDX 3.0 지원 도구 평가 (예: SPDX 도구, FOSSology)
- 선택한 도구를 기존 CI/CD 파이프라인에 통합
프로세스 정의
- SPDX 3.0 문서 생성, 검증, 관리를 위한 워크플로우 설계
- 책임자 및 역할 정의
확장 계획
- 파일럿 프로젝트의 결과를 바탕으로 개선점 식별
- 단계적으로 다른 프로젝트 및 부서로 확대 적용
모니터링 및 최적화
- SPDX 3.0 도입 효과 측정을 위한 KPI 설정
- 정기적인 검토 및 프로세스 개선

조직 내 교육 및 인식 제고

경영진 지원 확보
- SPDX 3.0 도입의 비즈니스 가치 제시
- 규제 준수 및 리스크 관리 측면 강조
부서별 맞춤 교육
- 개발팀: SPDX 3.0 문서 생성 및 관리 방법
- 법무팀: 라이선스 컴플라이언스 개선 방안
- 보안팀: 취약점 관리 및 보안 프로필 활용법
워크숍 및 핸즈온 세션
- SPDX 3.0 도구 사용법 실습
- 실제 프로젝트에 SPDX 3.0 적용 연습
내부 커뮤니케이션
- SPDX 3.0 관련 뉴스레터 발행
- 인트라넷에 SPDX 3.0 리소스 센터 구축
성공 사례 공유
- 파일럿 프로젝트의 성과 및 교훈 공유
- SPDX 3.0 도입으로 인한 개선 사항 강조

성공적인 도입을 위한 팁

점진적 접근
- 한 번에 모든 것을 바꾸려 하지 말고, 단계적으로 도입
- 각 단계마다 피드백을 수집하고 개선점 파악
크로스 펑셔널 팀 구성
- 개발, 법무, 보안, 운영 등 다양한 부서의 전문가로 팀 구성
- 정기적인 미팅을 통해 진행 상황 및 이슈 논의
자동화 강조
- SPDX 3.0 문서 생성 및 관리 프로세스 자동화
- CI/CD 파이프라인에 SPDX 3.0 관련 단계 통합
외부 전문가 활용
- 필요시 SPDX 커뮤니티 또는 컨설팅 업체의 도움 요청
- 다른 조직의 성공 사례 벤치마킹
유연성 유지
- SPDX 3.0의 모든 기능을 한 번에 도입하려 하지 않음
- 조직의 니즈에 맞는 프로필과 기능부터 시작
지속적인 학습 강조
- SPDX 커뮤니티 활동 참여 권장
- 관련 컨퍼런스 및 웨비나 참석 지원
성과 측정 및 보고
- SPDX 3.0 도입 전후의 메트릭 비교 (예: 취약점 대응 시간, 라이선스 컴플라이언스 개선도)
- 정기적으로 경영진에게 진행 상황 및 ROI 보고
문화적 변화 관리
- SPDX 3.0을 단순한 도구가 아닌 새로운 업무 방식으로 인식하도록 유도
- 변화에 대한 저항을 극복하기 위한 전략 수립

SPDX 3.0의 성공적인 도입은 기술적 구현뿐만 아니라 조직 문화와 프로세스의 변화를 수반합니다. 체계적인 계획, 지속적인 교육, 그리고 유연한 접근을 통해 SPDX 3.0의 이점을 최대한 활용할 수 있습니다[1][2].

Citations:
[1] https://www.linuxfoundation.org/press/spdx-3-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases
[2] https://spdx.dev/unpacking-the-spdx-3-0-tooling-mini-summit-a-new-era-of-compliance-and-security/
[3] https://spdx.dev/spdx-announces-3-0-release-candidate-with-new-use-cases/
[4] https://openchainproject.org/news/2023/03/31/webinar-50
[5] https://nand-research.com/quick-take-spdx-3-0-release/
[6] https://linuxsecurity.com/news/organizations-events/spdx-3-0
[7] https://spdx.dev/leveraging-profiles-for-license-compliance-insights-from-spdx-mini-summit/

11. 향후 전망 및 발전 방향

SPDX 3.0의 출시는 소프트웨어 공급망 관리의 새로운 장을 열었습니다. 이 섹션에서는 SPDX의 미래와 발전 방향에 대해 자세히 살펴보겠습니다.

SPDX 커뮤니티 참여

오픈 참여 모델
- SPDX는 개방형 커뮤니티 모델을 채택하고 있어, 누구나 참여할 수 있습니다[1].
- 개인, 기업, 단체 등 다양한 이해관계자들이 SPDX의 발전에 기여할 수 있습니다.
참여 방법
- 메일링 리스트 구독: 일반 SPDX 메일링 리스트에 가입하여 최신 소식을 받아볼 수 있습니다[1].
- 정기 회의 참석: 월간 일반 회의에 참여하여 프로젝트 진행 상황을 파악하고 의견을 제시할 수 있습니다[1].
- 작업 그룹 활동: 기술, 법률, 아웃리치 등 다양한 작업 그룹에 참여할 수 있습니다.
도구 개발 참여
- SPDX 도구 개발에 직접 참여할 수 있습니다. 예를 들어, Google Summer of Code 프로젝트를 통해 학생들이 SPDX 관련 프로젝트에 기여할 수 있습니다[7].

향후 업데이트 및 개선 사항

AI/ML 관련 기능 강화
- AI 모델 훈련 및 특성화, 데이터셋 출처 등에 대한 프로필이 더욱 발전될 것으로 예상됩니다[4].
- AI 윤리 및 책임성과 관련된 메타데이터 추가가 고려될 수 있습니다.
보안 기능 확장
- 취약점 정보와 SBOM의 연계가 더욱 강화될 것으로 보입니다.
- 실시간 위협 인텔리전스와의 통합 가능성이 있습니다.
자동화 및 통합 개선
- CI/CD 파이프라인과의 더 깊은 통합이 예상됩니다.
- 자동 SBOM 생성 및 업데이트 기능이 더욱 정교해질 것입니다.
사용자 경험 개선
- 더 직관적인 사용자 인터페이스와 시각화 도구가 개발될 수 있습니다.
- 비기술적 사용자를 위한 간소화된 버전의 SPDX 도구가 나올 수 있습니다.

글로벌 표준화 동향

ISO 표준으로서의 위치 강화
- SPDX는 이미 ISO/IEC 5962:2021 표준으로 채택되었으며, 3.0 버전도 ISO에 제출될 예정입니다[5].
- 이는 SPDX의 글로벌 채택을 더욱 가속화할 것으로 예상됩니다.
국제 규제 대응
- 미국의 행정명령 14028과 EU의 사이버 복원력 법(Cyber Resiliency Act) 등 국제적인 소프트웨어 공급망 보안 규제에 대응하는 핵심 도구로 자리잡을 것입니다[6].
산업별 표준화
- 자동차, 의료기기, 항공우주 등 다양한 산업 분야에서 SPDX를 기반으로 한 산업별 표준이 개발될 수 있습니다.
국제 협력 강화
- SPDX 커뮤니티는 다른 국제 표준 기구 및 오픈소스 재단들과의 협력을 강화할 것으로 예상됩니다.
- 이를 통해 소프트웨어 공급망 보안에 대한 글로벌 접근 방식이 더욱 통일될 수 있습니다.

SPDX 3.0은 소프트웨어 관리의 미래를 형성하는 중요한 이정표입니다. 지속적인 커뮤니티 참여와 기술 발전, 그리고 국제적인 표준화 노력을 통해 SPDX는 앞으로도 소프트웨어 공급망 보안과 투명성 향상에 크게 기여할 것으로 전망됩니다.

Citations: [1] https://spdx.dev/engage/participate/
[2] https://www.linuxinsider.com/story/spdx-becomes-new-standard-for-open-source-software-security-87265.html
[3] https://spdx.dev/engage/join/
[4] https://sbomify.com/2024/04/28/exploring-the-new-spdx-3-0-a-game-changer-for-sboms/
[5] https://www.prnewswire.com/news-releases/spdx-3-0-revolutionizes-software-management-in-systems-with-enhanced-functionality-and-streamlined-use-cases-302118321.html
[6] https://spdx.dev/spdx-announces-3-0-release-candidate-with-new-use-cases/
[7] https://wiki.spdx.org/view/GSOC/GSOC_ProjectIdeas
[8] https://linuxsecurity.com/news/organizations-events/spdx-3-0

12. 결론: 기업의 오픈소스 관리자를 위한 SPDX 3.0 활용 전략

SPDX 3.0은 기업의 오픈소스 관리자에게 강력하고 유연한 도구를 제공합니다. 다음은 SPDX 3.0을 효과적으로 활용하기 위한 전략적 접근 방법입니다:

전략적 도입
- SPDX 3.0을 단순한 도구가 아닌 전략적 자산으로 인식합니다.
- 조직의 오픈소스 정책과 SPDX 3.0을 연계하여 일관된 관리 체계를 구축합니다.
자동화 우선
- SPDX 3.0 문서 생성 및 관리 프로세스를 최대한 자동화합니다.
- CI/CD 파이프라인에 SPDX 3.0 관련 단계를 통합하여 지속적인 모니터링을 실현합니다.
리스크 관리 강화
- SPDX 3.0의 보안 및 라이선스 프로필을 활용하여 오픈소스 사용에 따른 리스크를 체계적으로 관리합니다.
- 정기적인 오픈소스 감사를 SPDX 3.0 기반으로 수행하여 컴플라이언스를 보장합니다.
의사결정 지원
- SPDX 3.0 데이터를 기반으로 오픈소스 채택 및 사용에 대한 정보에 입각한 의사결정을 지원합니다.
- 데이터 기반의 오픈소스 전략 수립에 활용합니다.
협업 촉진
- SPDX 3.0을 통해 개발팀, 법무팀, 보안팀 간의 협업을 강화합니다.
- 표준화된 형식을 통해 외부 파트너와의 정보 교환을 원활히 합니다.
교육 및 역량 강화
- 오픈소스 관리자는 SPDX 3.0에 대한 깊이 있는 이해를 바탕으로 조직 내 교육을 주도합니다.
- SPDX 커뮤니티 활동에 적극 참여하여 최신 동향을 파악하고 모범 사례를 학습합니다.
규제 대응 준비
- SPDX 3.0을 활용하여 SBOM 관련 규제 요구사항에 선제적으로 대응합니다.
- 향후 발생할 수 있는 규제 변화에 유연하게 대처할 수 있는 체계를 구축합니다.
가치 창출
- SPDX 3.0을 통해 오픈소스 관리의 효율성을 높이고, 이를 조직의 경쟁력 강화로 연결합니다.
- 오픈소스 기여 활동을 SPDX 3.0으로 문서화하여 기업의 기술력과 평판을 향상시킵니다.
지속적인 개선
- SPDX 3.0 활용 현황을 정기적으로 평가하고 개선점을 식별합니다.
- 새로운 프로필이나 기능이 추가될 때마다 조직의 프로세스에 신속히 통합합니다.
혁신 주도
- SPDX 3.0을 기반으로 조직 고유의 오픈소스 관리 모델을 개발합니다.
- 이를 통해 업계 내에서 오픈소스 관리의 선도적 위치를 확보합니다.

결론적으로, SPDX 3.0은 기업의 오픈소스 관리자에게 오픈소스 생태계를 효과적으로 관리하고 활용할 수 있는 강력한 도구를 제공합니다. 전략적이고 체계적인 접근을 통해 SPDX 3.0을 활용한다면, 조직은 오픈소스의 이점을 최대화하면서 관련 리스크를 최소화할 수 있을 것입니다. 오픈소스 관리자는 이러한 도구를 통해 조직의 디지털 혁신과 경쟁력 강화에 핵심적인 역할을 수행할 수 있을 것입니다.

이 글은 Perplexity (https://www.perplexity.ai/)와 함께 작성하였습니다.

SKT고객은 Perplexicy Pro를 1년간 무료로 이용할 수 있습니다.: https://perplexity.sktadotevent.com/

프랑스 법원, 대형 통신사 Orange에게 GPL 위반으로 손해배상 판결

By 장학성 | 2024년 2일 19월

안녕하세요.

오늘은 프랑스 법원이 GPL 위반으로 통신사인 Orange에게 손해배상을 판결한 사건에 대해 살펴보려 합니다. 이 사건은 두 가지 주요 측면에서 특별히 주목할 만한 점이 있어 보였습니다.

첫째, 이 사건의 피고인이 대형 통신사인 Orange라는 점입니다. (제가 통신사에 몸 담고 있다보니…)
둘째, GPL 위반 소송이 주로 임베디드 디바이스에서 발생하는 반면, 이 사건에서는 B2B 형태의 웹서비스 구축에 사용된 오픈소스가 이슈가 되었다는 점입니다. 이는 오픈소스 라이선스 준수가 모든 소프트웨어 개발 영역에서 중요하다는 것을 강조합니다.

이 사건은 이러한 측면들을 통해 오픈소스 라이선스 준수의 중요성을 재확인하는 계기가 될 것으로 보입니다. 이는 기업들이 오픈소스를 사용할 때 라이선스 요구사항을 철저히 이해하고 준수해야 함을 강조하는 중요한 사례가 될 것입니다.

감수 및 보완 내용 의견 주신 SK텔레콤의 박철웅 매니저님께 감사 드립니다.

GPL이란?

참고 - GPL-2.0 가이드 : https://sktelecom.github.io/guide/use/obligation/gpl-2.0/

원고: 엔트루베르 (Entr’Ouvert)

2002년 9월에 설립된 프랑스의 소프트웨어 회사인 엔트루베르는 Lasso라는 이름의 C 라이브러리를 개발하였습니다. Lasso는 Liberty Alliance의 SAML 표준과 같은 인증 프로토콜을 구현하는 라이브러리입니다.

lasso

Lasso는 현재 두 가지 라이선스로 제공됩니다.

오픈소스 라이선스 : GPL-2.0 + OpenSSL exception (소스 코드 공개 필요)
상용 라이선스 (유료 구매 필요)

We strongly recommend the use of the GNU General Public License each time it is possible. But for proprietary projects, that wouldn’t want to use it, we designed a commercial license.
https://lasso.entrouvert.org/

피고: Orange

프랑스의 대형 통신사인 Orange는 2005년, 프랑스 전자 행정 개발청(ADAE, 현재 DGME)과 “My Public Service” 포털(현재 https://www.service-public.fr/)을 개발하기 위한 계약을 체결했습니다.

orange

당시 이 포털은 ID 관리 서비스를 지원하기 위해 SAML 프로토콜을 사용해야 했습니다. Orange는 이를 구현하기 위해 Lasso를 사용하였는데, GPL-2.0 라이선스 조건을 준수하지 않았습니다. 즉, Orange는 Lasso 소프트웨어의 출처와 라이선스를 명시하지 않았으며, 수정된 소스 코드를 공개하지 않았습니다.

엔트루베르는 이를 발견하고 2011년 Orange사를 상대로 손해배상을 청구하는 소를 제기하였습니다.

판결

소송은 10년 이상 진행되었고, 마침내 2024년 2월 14일, 파리 항소 법원은 GNU GPL v2 라이선스를 준수하지 않은 이유로 Orange에게 엔트루베르에 총 650,000유로(한화 약 9억4천만원)를 지불하라고 명령했습니다. Orange는 엔트루베르에게 경제적 손실에 대한 보상으로 500,000유로를 지불하고 도덕적 피해에 대해 150,000유로를 지불해야 합니다.

법원은 “Orange가 라이선스 계약을 존중하고 유료 라이선스를 체결했다면 그들은 엔트루베르에게 로열티를 지불했어야 했다.“라고 말했습니다. 또한, 법원은 Orange가 Lasso 소프트웨어를 무료로 활용함으로써 7년 동안 지속된 이 대규모 공공 시장에서 부당하게 이익을 창출했다고 지적했습니다.

시사점

5G의 성장 한계에 도달하면서 비통신 전략을 가속화하고 있는 통신사가 소송의 대상이 된 것은 흥미로운 점입니다. AI, 클라우드, IoT, 로보틱스, 반도체, UAM 등 첨단 기술 분야에서 다양한 제품과 서비스를 출시하고, B2B 영역을 함께 공략하고 있는 통신사들은 이제 다른 산업 분야의 회사와 마찬가지로 소프트웨어 개발 환경에서 오픈소스를 필수적으로 사용하게 되었습니다. 따라서, 오픈소스 관리를 위한 정책과 프로세스를 수립하는 것이 중요하게 되었습니다.
오픈소스 라이선스 분쟁 사례는 주로 오픈소스를 사용하여 개발한 디바이스나 소프트웨어 상품이 무단으로 배포될 때 발생하였습니다. 그러나 이번 사례에서는 정부 기관의 웹사이트를 구축하기 위해 소프트웨어 공급 계약자가 사용한 오픈소스가 분쟁의 대상이 되었습니다. 따라서 기업들은 소프트웨어 디바이스, 앱 등의 배포 대상뿐만 아니라, B2B 형태로 웹서비스 구축 계약을 체결하여 정부기관이나 고객사에 소프트웨어를 공급할 때에도 오픈소스 관리를 위한 프로세스를 적용해야 함에 유의해야 합니다.

References

French Court Issues Damages Award for Violation of GPL: https://heathermeeker.com/2024/02/17/french-court-issues-damages-award-for-violation-of-gpl/amp/
https://www.entrouvert.com/actualites/2019/entrouvert-versus-orange/
https://www.zdnet.fr/blogs/l-esprit-libre/non-respect-de-la-licence-gpl-orange-condamne-en-appel-39964312.htm

이 블로그는 불어로 작성된 기사 등의 번역본을 기반으로 작성하였으며, 저의 법률적인 지식은 극히 제한적이기 때문에 오류가 있을 수 있습니다. 혹시 오류를 발견하시면 알려주세요~ (haksung@sk.com)
바로바로 업데이트하겠습니다. ^^