This the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Open Source Compliance

한국 소프트웨어 기업이 알아야 할 EU의 3대 디지털 규제 핵심 내용
To Mine or Not To Mine: 독일 법원이 AI 시대의 저작권 딜레마에 내린 판결
중국 저작권 침해 소송 사례 “GPL 기반 소프트웨어 제품은 어차피 소스 공개 의무가 있으니 배껴도 되는 것 아닌가요?
또 다시 Elasticsearch 라이선스 변경, 기업의 대응 방안은?
SPDX 3.0 소개와 기업 도입 전략
프랑스 법원, 대형 통신사 Orange에게 GPL 위반으로 손해배상 판결
기업의 효과적인 오픈소스 관리 방안 (2) OpenChain Korea Work Group
기업의 효과적인 오픈소스 관리 방안 (1) 글로벌 협력을 위한 OpenChain Project
Anaconda 꼭 사서 쓰세요. 아니라면 conda-forge!
Akka는 더 이상 오픈소스가 아닙니다.
SFC vs. Vizio 판결 겉핥기
이너소스 도입을 위한 과제와 효과
상용 AI 서비스에 공개 Dataset을 사용해도 되나요?
SaaS로 서비스를 제공할 때에도 오픈소스 컴플라이언스가 필요한가요?
중국 첫 GPL 소송 사례, VirtualApp
GPLv2도 설치정보를 요구한다고?
Dockerfile 배포 시 컴플라이언스 책임은 누구에게?
OSPO란?
Elastic License 2.0 그리고 진화하는 오픈소스 라이선스
소스 코드 내 저작권 표시 방법
2019 FOSS Legal Issue Top 10

한국 소프트웨어 기업이 알아야 할 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)
바로바로 업데이트하겠습니다. ^^

기업의 효과적인 오픈소스 관리 방안 (2) OpenChain Korea Work Group

By 장학성 | 2023년 4일 3월

이전 글에서는 기업의 효과적인 오픈소스 관리 방안으로 글로벌 협력을 위한 OpenChain Project를 소개했습니다. 이번에는 한국 기업이 오픈소스를 효과적으로 관리하기 위한 협업 커뮤니티인 OpenChain Korea Work Group에 대해 소개하려고 합니다.

OpenChain Korea Work Group

OpenChain Korea Work Group(KWG)은 Linux Foundation의 OpenChain Project의 하위 그룹입니다. 이 그룹은 오픈소스 정신인 협업과 공유를 통해 모두가 효과적으로 오픈소스 관리에 성공하기 위한 방법을 고민하고 공유하는 모임입니다. KWG에는 한국의 주요 ICT 기업의 오픈소스 담당자들이 참여하고 있습니다.

featured_kwg

OpenChain KWG 정기 미팅

오픈소스 관리를 위한 정책과 프로세스를 이미 구축한 대기업들도, 현대의 거대하고 복잡한 소프트웨어 공급망을 고려한다면 오픈소스 라이선스나 보안 취약점 리스크에서 벗어나기 어렵습니다. 결국, 소프트웨어 공급망 내 모든 기업의 오픈소스 관리 수준을 높이는 것이 중요합니다. 이를 위해서는 오픈소스 관리 방법에 대한 이해도가 높은 기업이 먼저 노하우를 공유하고, 다른 기업에서 쉽게 참여할 수 있도록 안내하는 길잡이가 필요합니다.

기업이 보유한 오픈소스 관리 자산을 경쟁사와 공유한다고 해도 매출에 악영향을 끼치지 않습니다. 반면, 경쟁사의 오픈소스 관리 정책을 알아내더라도 이를 기업의 이익과 연결할 수 없습니다. 기업들이 서로 오픈소스 관리 Best Practice를 공유한다면, 각 기업은 적은 비용과 리소스 투입으로도 큰 효과를 얻을 수 있습니다. 이러한 아이디어에 공감하여, LG전자, SK텔레콤, 카카오, 현대자동차, 삼성전자의 오픈소스 담당자들이 참여한 첫 번째 OpenChain KWG 모임이 2019년 1월에 개최되었습니다.

17차 미팅 (오프라인)

모임은 매 분기 진행하고 있으며, 코로나 기간 동안 온라인으로 진행되었습니다. 그러다가, 지난 2023년 3월 28일에는 3년 만에 오프라인 모임을 개최했습니다. 19개 기업/기관에서 50여 명의 오픈소스 담당자가 참석했습니다. 이번 오프라인 모임은 라인플러스에서 준비해 주었습니다. 쾌적한 장소와 음료, 그리고 기념품 등을 제공해주신 라인플러스의 오픈소스 매니저 이서연, 김동혁 님께 감사드립니다! ^^

Untitled

이번 모임의 첫 번째 부분에서는 OpenChain Project의 국내외 최신 동향과 보안 보증 규격에 대한 발표가 있었으며, AI 기술에 대한 법적 이슈 및 사례 연구에 대한 발표도 있었습니다. 두 번째 부분에서는 기업의 오픈 소스 관리를 위한 도구를 오픈 소스로 개발하여 공유하는 세션 발표가 있었습니다. 자세한 발표 내용은 이어지는 소개에서 다루겠습니다.

1부 : 세션 발표

OpenChain Global Updat (Linux Foundation, Shane Coughlan)

Linux Foundation의 OpenChain Project General Manager Shane Coughlan은 직접 참석하여 OpenChain Project의 Global Trend를 소개했습니다.

Untitled

오픈소스 컴플라이언스를 위한 표준인 ISO/IEC 5230뿐만 아니라 보안을 위한 표준인 ISO/IEC DIS 18974도 개발 중입니다. 이 표준은 곧 공식 ISO 표준으로 등록될 예정이며, 기업이 준수해야 할 Self-Checklist도 공개되어 있습니다. 이러한 자료들을 활용하여 기업은 효율적인 오픈소스 리스크 관리를 수행할 수 있습니다.

Shane은 KWG 멤버들을 위한 기념품도 가져와서 큰 호응을 얻기도 하였습니다. (Thank you, Shane 😊 )

Untitled

OpenChain 보안 표준 소개 (SK텔레콤, 장학성)

ISO/IEC 5230은 오픈소스 컴플라이언스를 위한 국제 표준입니다. 이 표준은 2020년에 ISO에 등록되었으며, 세계의 많은 기업이 이 표준을 준수하여 오픈소스 컴플라이언스 관리를 훌륭하게 수행하고 있습니다. 기업이 오픈소스를 관리해야 하는 이유는 라이선스 컴플라이언스 뿐만 아니라 보안 취약점에 대한 리스크도 존재하기 때문입니다. OpenChain Project에서는 보안 취약점 관리를 위한 표준, ISO/IEC DIS 18974, OpenChain security assurance specification을 만들었습니다. 저는 이 표준이 어떤 내용으로 구성되어 있는지를 간단히 요약하여 소개하였습니다.

Untitled

이 보안 표준은 ISO/IEC 5230과 동일한 포맷으로 구성되어 있습니다. 라이선스 컴플라이언스 대신 보안 취약점 관리를 위해 수행해야 할 요구 사항을 정의합니다. 기업은 라이선스 컴플라이언스 이외에도 보안 취약점 관리를 위한 정책과 프로세스를 구축해야 합니다. 또한, 발견된 보안 취약점에 대응할 수 있는 절차를 마련해야 합니다.

Legal Issues of AI Technologies / Case Study: Getty Images v. Stability AI (ETRI 박정숙)

Untitled

ETRI의 박정숙 님은 최근 제기된 Stable Diffusion 관련 소송을 분석하여 AI 법률 이슈를 소개하였습니다. 발표 자료는 여기에서 확인할 수 있습니다.

Untitled

박정숙님은 AI 관련 법률 제정 현황을 분석하고, 이를 기반으로 AI 관련 오픈소스 컴플라이언스 대응 방안을 모색하여 공유해주셨습니다.

Untitled

2부 : Mini Summit - 오픈소스 관리 자동화 도구

2부에서는 오픈소스 관리를 자동화하기 위한 각 기업의 Best Practice를 공유하는 세션 발표가 있었습니다.

도구 별 의존성 분석 방식 (카카오, 임현지)

카카오 임현지님은 오픈소스 분석 도구의 의존성 분석 방식을 비교 분석하여 발표하셨습니다. 발표 자료는 여기에서 확인할 수 있습니다.

Untitled

대표적인 오픈소스 분석 도구인 FOSSA, FOSSLight, ORT (OSS Review Toolkit), OLIVE Platform 별로 의존성 분석 방식을 파악하여 공유하였습니다.

Untitled

소리소리 OSORI (LG전자, 김소임)

LG전자 김소임님은 OSORI 프로젝트에 대해 소개하는 세션 발표를 하였습니다.

Untitled

OSORI는 오픈소스 정보 데이터를 공개하여 누구나 쉽게 오픈소스 정보를 확인하고 필요한 의무 사항을 준수할 수 있게 하기 위한 오픈소스 프로젝트입니다. LG전자, 삼성전자, 카카오가 보유한 오픈소스 프로젝트에 대한 주요 정보, 라이선스 종류, 이에 따른 주요 준수 사항 및 제약 사항을 항목별로 테이블을 구성한 정보를 데이터베이스화하기 위한 스키마를 정의하였고, 앞으로 데이터 정제, 운영 Policy 정립, 가이드 페이지 구축 등의 로드맵을 소개하였습니다.

Untitled

FOSSLight Roadmap (LG전자, 김경애)

FOSSLight는 LG전자에서 자체 개발하여 사용하고 있는 오픈소스 관리 통합 시스템을 누구나 사용할 수 있도록 2021년 오픈소스로 공개한 프로젝트입니다. LG전자의 김경애 님은 2023년 FOSSLight Roadmap을 소개하였습니다.

Untitled

FOSSLight Project는 2023년 보안 취약점 기능을 개선하고, SBOM 기능 강화, UX개선 등의 로드맵을 가지고 있습니다.

Untitled

요즘 OLIVE 써봤니? (카카오, 황은경)

OLIVE Platform은 카카오에서 개발한 오픈소스 라이선스 검증 서비스이며, 카카오 계정만 있으면 누구나 무료로 사용할 수 있습니다. 카카오의 황은경 님은 OLIVE Platform의 주요 기능을 소개하였습니다.

Untitled

OLIVE Platform은 소스 코드 노출이 우려되는 경우에도 안심하고 사용할 수 있는 OLIVE CLI 기능이 추가되어 보안에 민감한 금융권에서도 도입될 수 있었습니다.

Untitled

onot, 이제 제법 쓸만해졌어요! (카카오, 한현민)

onot은 SK텔레콤과 카카오가 공동 개발한 오픈소스 프로젝트 입니다. SPDX 규격으로 작성된 SBOM을 오픈소스 고지문으로 자동 변환하는 도구입니다. 카카오의 한현민 님은 최근 onot에 추가된 신규 기능에 대해 소개하였습니다. 발표 자료는 여기에서 확인할 수 있습니다.

Untitled

onot은 Package 정보뿐만 아니라 File 정보도 추출하게 되었고, Multi License 표기도 지원하게 되었습니다. RDF/xml 형태의 SPDX 문서도 오픈소스 고지문을 생성할 수 있으며, 특히 Windows PC에서의 GUI와 같은 보다 편리한 사용 환경을 지원하게 되었습니다.

Untitled

글을 마치며

3년여만에 오프라인으로 모인 모임은 짧은 시간이 아쉬울 정도로 알찼습니다. 멋진 장소와 기념품, 추첨 상품까지 준비해준 라인플러스 이서연 님, 김동혁 님께 다시 한번 감사드립니다.

Untitled

기업들은 오픈소스 관리 업무에서 비슷한 어려움을 겪게 되는데, 이를 어떻게 극복하고 효율화하였는지를 공유하는 것은 서로에게 큰 도움이 됩니다. OpenChain Korea Work Group은 이러한 공감을 갖는 기업의 담당자가 자발적으로 참여하는 모임입니다. OpenChain Korea Work Group은 기업/기관에서 오픈소스 관리 업무를 담당하시는 누구나 참여할 수 있습니다. : 가입 방법

끝으로, OpenChain KWG는 분기마다 정기 미팅을 개최하고 있습니다. 다음 모임은 카카오에서 만날 수 있을 것 같습니다.

그때까지 모두 행복하세요! 😃

기업의 효과적인 오픈소스 관리 방안 (1) 글로벌 협력을 위한 OpenChain Project

By 장학성 | 2023년 3일 28월

기업이 개발하는 제품 소프트웨어의 93% 이상이 오픈소스를 사용한다고 할 정도로 현대 소프트웨어 개발에 오픈소스를 사용하는 건 거의 필수적입니다. 그런데, 사용하는 오픈소스의 53%는 라이선스 컴플라이언스 이슈가 있고, 81%는 보안 취약점을 갖고 있다는 보고가 있습니다. 복잡한 현대 소프트웨어의 개발환경과 방대한 Software Supply Chain을 고려한다면, 기업이 오픈소스로 제품을 개발하면서 라이선스 컴플라이언스와 보안 취약점 리스크 최소화를 위한 오픈소스 관리 노력이 필요한데요, Linux Foundation의 OpenChain Project는 이러한 노력을 커뮤니티 차원에서 여러 기업이 공유와 협업으로 함께 하기 위한 Project입니다.

2023년 3월 27일, OpenChain Project의 General Manager인 Shane Coughlan이 SK텔레콤을 방문하여 OpenChain Project의 주요 활동, 오픈소스 관련 국제 표준 및 글로벌 동향에 관해 설명하는 시간을 가졌습니다.

Untitled

이 자리에는 SK텔레콤 OSRB와 SK그룹 오픈소스 협의체 멤버(SK플래닛, SK쉴더스, SK(주), Supex추구협의회 등)가 참여하여 다양한 의견을 나누었는데요,

Untitled

이날 Shane은 OpenChain Project에 대해 소개하고, 어떻게 글로벌 협력을 통해 Software Supply Chain에서의 오픈소스 관리 이슈를 공동으로 해결해 가는지 설명하였습니다. 이 글에서는 주요 내용을 소개하려고 합니다.

OpenChain Project Global Community

Software Supply Chain 이슈 관리를 위해 OpenChain Project를 통해 여러 글로벌 기업이 협력하고 있습니다. : https://www.openchainproject.org/community

Platinum Members

Untitled

Community Structure

OpenChain Project에는 다수의 Work Group이 있으며, 각 Work Group에서는 오픈소스 관리를 위한 표준을 만들고 자동화 도구를 함께 개발하고 있습니다. 또한 국가별로 Work Group이 결성되어 있습니다.

Untitled

OpenChain Standard

ISO/IEC 5230:2020, ISO/IEC DIS 18974

가장 가시적인 결과는 오픈소스 관리를 위한 최초의 국제 표준을 개발한 것입니다. 2020년 12월, ISO/IEC 5230이 오픈소스 컴플라이언스를 위한 유일한 국제 표준으로 등록되었습니다. ISO/IEC DIS 18974는 오픈소스 보안 보증 컴플라이언스를 위한 사실상의 표준이며, 2023년 하반기에 ISO 표준으로 공식 등록될 예정입니다.

이들 표준은 기업이 오픈소스를 관리하는데 꼭 필요한 핵심 요구사항을 정의하고 있습니다. 기업은 이 표준의 요구사항을 준수함으로 Software Supply Chain 내에서 오픈소스 관리가 이뤄지고 있음을 투명하게 나타낼 수 있습니다.

Untitled

Self-Certification

OpenChain Project에서는 Self-Certification을 위한 Checklist도 제공하는데요. 기업은 Checklist 항목을 하나하나 준수해 가면서 기업의 오픈소스 관리 수준을 높일 수 있습니다.

Untitled

Adoption of OpenChain ISO/IEC 5230:2020

Checklist의 모든 항목을 준수하는 기업이라면, ISO/IEC 5230 준수 기업으로 선언할 수 있게 됩니다. ISO/IEC 5230을 채택하였다고 선언한 기업 리스트는 다음과 같습니다. LG전자, 카카오, 삼성전자, 네이버, SK텔레콤, NCSOFT, 현대자동차그룹 등 여러 국내 기업도 볼 수 있습니다.

Untitled

Other Interesting Items

Online Webinar

OpenChain Project에서는 오픈소스 관리에 대한 온라인 웨비나를 계속하고 있습니다.

Untitled

Training Courses

오픈소스 라이선스 컴플라이언스를 위한 Free Training Course가 제공되고 있으며, 이수 시 Badge도 취득할 수 있습니다.

Untitled

이러한 Training Course는 여러 기업이 소속 직원 혹은 Supplier에게 이수를 요구하는 등 다양하게 활용되기도 합니다.

Untitled

Update on China and Japan

China

중국에서도 OpenChain Project와의 협력이 활발히 일어나고 있습니다. 특히 CAICT와 CESI와 같은 중국 정부 기관과도 협력 방안을 논의하고 있습니다.

OpenChain China Work Group에는 Huawie, Honor 및 OPPO와 같은 기업도 활발히 참여하고 있으며, 약 250명의 멤버로 구성되어 있습니다.

2023년 2분기부터 매 분기 OpenChain과 CAICT가 공동 주관하는 이벤트가 예정되어 있으며, OIN과 함께하는 Asian Legal Network (ALN)도 다시 시작하기로 하였다고 합니다.

Japan

OpenChain Japan Work Group은 약 190명의 멤버가 참여하고 있습니다. Fujitsu, Hitachi, NEC, Panasonic, Sony, Toshiba 및 Toyota가 지속적으로 지원하고 있으며, 격월로 커뮤니티 이벤트가 개최됩니다.

TODO Group과 협력하여 2주마다 OSPO 이벤트도 개최하고 있습니다.

Korea market - challenge and opportunities

Current situation

OpenChain Korea Work Group은 규모나 열정 측면에서 일본에 이어 세계에서 두 번째로 영향력 있는 훌륭한 Work Group입니다. SK텔레콤, LG전자, 삼성전자, 현대자동차 등 주요 기업이 참여하고 있으며, NIPA에서도 후원 등의 방식으로 참여하고 있습니다.

그러나 글로벌 경기 침체에서 한국도 자유롭지 못하다는 위기는 있습니다. 또한, OpenChain Board에 한국 기업 멤버가 없다는 점도 아쉽습니다.

Opportunities

OpenChain Korea Work Group이 지금처럼 커뮤니티 미팅과 활동을 지속한다면 기회는 계속될 것입니다. 가능하다면, 일본과 중국처럼 정부의 오픈소스 정책에 OpenChain 표준을 포함시키기 위해 노력하고 이를 위해 정부 기관의 참여를 촉진하면 좋을 것입니다.

끝으로, OpenChain Board에 한국 기업이 참여한다면, OpenChain Project의 전략적 다양성이 증대되고, 글로벌 Supply Chain에서의 영향력을 키울 수 있을 것입니다.

글을 마치며

OpenChain Project는 기업의 오픈소스 관리 영역도 오픈소스의 공유와 협업 방식을 적용하여 모두 함께 적은 비용과 리소스로 높은 수준의 리스크 관리 practice를 달성하기 위한 커뮤니티입니다. 이러한 취지에 공감하는 기업들이 모여 있는 곳이 OpenChain Korea Work Group입니다. OpenChain Korea Work Group에는 100명에 가까운 기업의 오픈소스 담당자들이 메일링리스트에 가입하여 활동하고 있습니다. 마침 코로나 이후 3년만에 오프라인 모임이 3월 28일에 있었습니다. 다음 글에서 이에 대해 자세히 다루겠습니다.

Shane과의 미팅 세션 이후에는 SK텔레콤 Tech HR팀의 후원으로 맛있는 점심을 즐겼습니다. (상기님 감사합니다~ ^^ )

Untitled

감사합니다.

Anaconda 꼭 사서 쓰세요. 아니라면 conda-forge!

Anaconda를 상용 목적으로 사용하려면 유료 버전을 구매해야 합니다. 200인 이상 기업의 개발자가 Anaconda를 사용하는 것은 상용 목적에 해당합니다.

By 장학성 | 2023년 3일 13월

안녕하세요.

Python 개발 환경 만들면서 Anaconda 많이 사용하시지 않나요? Python은 간단한 업무 자동화부터 데이터 분석, 인공지능 학습, 모델링 작업 등에 많이 사용되고 있는데요, 여러 Python 프로젝트 개발을 수행하다 보면 package 버전이 충돌하는 불편함이 생길 수 있습니다. Anaconda는 개발 프로젝트별로 가상 환경을 제공하여 버전 충돌을 방지할 수 있다는 장점이 있으며, 홈페이지에서 쉽게 다운받아 설치가 간단하여 널리 사용되고 있습니다.

https://www.anaconda.com/

그런데 Anaconda는 사서 쓰셔야 합니다.

2020년 9월, Anaconda사는 서비스 약관(Terms of Service)를 변경하여 200명 이상의 직원이 있는 기업 또는 정부 조직이 Anaconda Repository를 사용하는 경우 유료로 구매하게 하였습니다.

따라서, 200명 이상의 기업에서 근무하는 개발자라면 Anaconda 웹사이트에서 Pro 이상의 라이선스를 구매해야 합니다.

https://www.anaconda.com/pricing

조금 자세히 살펴보면, 일반적으로 Anaconda 설치를 위해서는 Anaconda 홈페이지에서 Anaconda Distribution을 무료로 다운 받을 수 있습니다.

https://www.anaconda.com/products/distribution

이를 설치하면 conda package manager와 더불어 Python 및 150여개의 package가 함께 설치되어 손쉽게 개발 환경을 구성할 수 있습니다.

Anaconda사는 Anaconda Repository를 호스팅하며 8천 개 이상의 오픈소스 package를 제공하고, 사용자는 conda install PACKAGENAME 명령어로 이들 package를 안정적으로 설치/관리 할 수 있습니다.

https://repo.anaconda.com/

그런데, 바로 이 Anaconda Repository의 서비스 약관이 2020년 9월에 변경된 것이고, commercial activity 목적일 때에는 Anaconda Repository의 무료 사용이 불가능해졌습니다.

많은 개발자가 Anaconda Distribution을 쉽게 다운받아서 사용하지만 이 과정에서 Anconda Repository를 사용하게 되는데요, 200명 이상 기업의 개발자라면 ‘의도하지는 않았지만’ Anaconda의 서비스 약관을 위반하게 되는 것이고, 이를 방지하기 위해서는 꼭 Anaconda Pro 이상을 구매하셔야 합니다.

참고로, Miniconda는 Anaconda와 마찬가지로 conda package manager와 Python 및 최소한의 dependency를 설치하는 소프트웨어 패키지인데요, Miniconda를 사용하면서도 마찬가지로 Anaconda Repository에 Access하여 package를 다운 받아 사용하게 되며, Anaconda와 동일하게 유료 구매 대상으로 간주될 수 있습니다.

https://docs.conda.io/en/latest/miniconda.html

결국, 200인 이상 기업의 개발자가 Anaconda Distribution을 무료로 다운받아서 사용하더라도 당장 비용이 청구되거나 기능이 막히지는 않겠지만, Anaconda의 안정적인 발전을 위해서도 200인 이상의 기업 개발자는 자발적으로 구매하여 사용하는 것이 좋을 것 같습니다. (물론 어느 순간 회사로 라이선스 위반 통지 및 비용 청구서가 날아올 수도 있습니다. ^^)

대안은 있습니다. ‘conda-forge’

Anaconda사는 conda라는 package manager를 오픈소스로 공개하여 관리하고 있습니다. conda 자체는 BSD-3-Clause 라이선스로 공개된 오픈소스여서 기업이 무료로 사용하는 데 문제되지 않습니다.

https://github.com/conda/conda

conda는 package 설치/관리를 위해 설치할 package를 찾기 위한 저장소 위치가 필요한데요, 이를 channel이라고 칭합니다. 기본 channel이 바로 Anaconda Repository입니다. 그런데, commuinity 기반의 repository가 또 있습니다. 바로 conda-forge인데요,

https://conda-forge.org/

conda를 설치하고 channel에 conda-forge를 추가할 수 있습니다.

conda config --add channels conda-forge
conda config --set channel_priority strict

이렇게 하면 Anaconda Repository를 사용하지 않기 때문에 위에서 설명한 서비스 약관을 위반하지 않고 conda를 사용할 수 있습니다.

Anaconda사의 CEO인 Peter Wang은 Miniconda를 다운 받아서 conda config를 conda-forge로 변경할 경우, 무료로 사용할 수 있다고 직접 밝힌 바 있습니다.

https://www.reddit.com/r/Python/comments/iqsk3y/comment/g4xuabr/

Anaconda Repository를 가리키는 defaults channel을 아예 삭제해 버리면 보다 확실하게 Anaconda Repository 사용을 제한할 수 있습니다.

conda config --remove channels defaults

원하는대로 channel이 변경되었는지는 아래 명령어로 확인할 수 있습니다.

### 변경 전
% conda config --show channels
channels:
  - defaults

### 변경 후
% conda config --show channels
channels:
  - conda-forge

Miniforge는 설치 시 channel에 conda-forge를 추가합니다.

한 걸음 더 나아가서 Miniforge는 conda 설치를 위한 최소의 installer를 제공하는 오픈소스 프로젝트로, 기본 설치 시 channel에 conda-forge를 추가합니다. 또한, Miniforge는 Apple M1을 포함한 다양한 CPU 아키텍처를 지원한다고도 알려져 있습니다.

https://github.com/conda-forge/miniforge

따라서, Anaconda 대신 Miniforge를 설치한다면 비교적 수월하게 라이선스 위반 없이 conda package manager로 개발 환경을 구성할 수 있는 것으로 보입니다.

한 가지 특이한 점은 conda-forge 운영에는 막대한 호스팅 비용이 필요한데 이를 Anaconda사가 지불하고 있다는 점입니다. Anaconda사는 conda-forge를 계속 무료로 유지하기 위해서라도 Anaconda Repository의 서비스 약관 변경을 통한 수익이 필요했다고 설명합니다.

결론적으로 개발 편의성과 안정성을 고려하여 가급적 Anaconda Pro를 구매하여 사용하는 것이 좋겠습니다. 구매 전까지 라이선스 이슈 방지를 위해 Miniconda + conda-forge 조합, 혹은 Miniforge를 대안으로 고려할 수 있을 것 같습니다. 🙂

혹시 틀린 내용이 있다면 알려주시면 감사하겠습니다. ^^

감사합니다.

Akka는 더 이상 오픈소스가 아닙니다.

Apache-2.0이었던 Akka의 라이선스가 2.7 버전부터 기업이 무료로 사용할 수 없는 Business Source License로 변경되었습니다.

By 장학성 | 2022년 9일 30월

오픈소스로 시작한 소프트웨어 기업이 라이선스 정책을 변경하는 사례가 증가하고 있는데요, 그동안 Apache-2.0으로 오픈소스 라이선스 정책을 유지해오던 미국의 Lightbend사도 2022년 9월, Akka의 라이선스를 BUSL-1.1 (Business Source License)로 변경한다고 발표하였습니다.
Business Source License가 무엇인지, Lightbend가 Akka의 라이선스를 BSL로 변경한 배경과 그 영향은 무엇인지에 대해 알아보겠습니다.

Akka란?

Akka는 JVM에서 여러 개의 thread가 동시에 작업하는 분산 애플리케이션을 Actor Model을 기반으로 단순화하는 툴킷으로 live chatting 등 주로 고성능이 요구되는 백엔드 플랫폼에 사용된다고 합니다.

라이선스 변경

미국의 Ligntbend 사는 2022년 9월 Akka의 라이선스를 변경하였습니다.

라이선스 변경의 주요 내용은 다음과 같습니다.

오픈소스(Apache-2.0)이었던 Akka가 v2.7 부터 새로운 라이선스가 적용된다.
새로운 라이선스는 BUSL-1.1 (Business Source License)이다.
상업적 목적이 아닌 경우 무료로 사용할 수 있으나, 상업용에 대해서는 라이선스 비용을 지불해야 한다.

Lightbend는 지난 십여 년간 Apache-2.0으로 Akka 오픈소스 프로젝트를 지원해 왔지만 이를 지속하기가 어려워졌다고 밝혔습니다.

Over the years, Lightbend has steadily borne more of the support for Akka. With Akka now considered critical infrastructure for many large organizations, the Apache 2.0 model becomes increasingly risky when a small company solely carries the maintenance effort. Balancing the global demands of our corporate community while supporting these needs of a vast open source base is a tremendous weight to bear.

결국 Lightbend도 Apache-2.0 오픈소스 모델을 지속하는 것을 포기하고, BUSL-1.1이란 “Source Available” 라이선스를 도입하여 커뮤니티에는 소스 코드를 공개하지만, 기업 사용자에게는 라이선스 비용을 청구하여 수익을 창출하고자 하였습니다. 오픈소스로 소프트웨어를 개발하는 기업이 수익성을 향상하기 위해 라이선스 정책을 변경하는 사례는 2018년 이후 증가하고 있습니다. MongoDB의 SSPL이 대표적인 사례이며, Elasticsearch는 Elastic License를 도입하였습니다. 이에 대한 세부 내용은 이전 글, ‘Elastic License 2.0 (부제: 진화하는 오픈소스 라이선스)‘에서 확인하실 수 있습니다. Lightbend도 이러한 배경과 수익성을 고려하여 라이선스 변경을 결정하였다고 추측할 수 있습니다.

BUSL-1.1은 Akka 이전에도 여러 오픈소스이었던 프로젝트에 적용된 바 있습니다.

Business Source License

BUSL-1.1은 오픈소스 라이선스와 무엇이 다를까요?

non-production use에 한하여 사용 권리 부여

BUSL-1-1은 일반적인 오픈소스 라이선스와는 달리 non-production use에 한하여 복사, 수정, 재배포 등을 할 수 있는 권리를 부여합니다.

The Licensor hereby grants you the right to copy, modify, create derivative works, redistribute, and make non-production use of the Licensed Work.

non-production use에 해당하지 않을 경우, Licensor에게 commercial license를 구매할 것을 요구합니다.

If your use of the Licensed Work does not comply with the requirements currently in effect as described in this License, you must purchase a commercial license from the Licensor, …

따라서, BUSL-1.1이 적용된 Akka 버전 (v2.7 이후)를 사용하는 기업은 더 이상 무료로 Akka를 사용할 수 없으며, Lightbend에게 상용 라이선스를 구매해야 합니다.

Change Date, Change License

BUSL-1.1 또 다른 특징은 Change Date와 Change License입니다. BUSL-1.1이 적용된 버전의 소프트웨어가 릴리즈된 이후 Change Date가 지나면 Change License가 적용되며 더 이상 BUSL-1.1이 적용되지 않게 됩니다.

Effective on the Change Date, or the fourth anniversary of the first publicly available distribution of a specific version of the Licensed Work under this License, whichever comes first, the Licensor hereby grants you rights under the terms of the Change License, and the rights granted in the paragraph above terminate.

Akka의 BUSL-1.1의 경우 Change Date는 릴리즈 후 3년이며, Change License는 Apache-2.0입니다.

예를 들어, Akka 2.8이 2023년 1월 1일에 릴리즈되었다면, 3년이 지난 후, 2026년 1월 1일부터는 Apache-2.0이 적용되어 기업도 무료로 사용이 가능합니다. BUSL-1.1은 이러한 Change License 조항을 제공하여 신규 버전을 사용하려면 돈을 내고 써야 하지만 오래된 버전은 상용 목적의 사용이라고 하더라도 무료로 사용할 수 있게 하였습니다. 이는 소프트웨어의 Heavy user인 대기업에는 비용을 청구하겠다는 의지로 보입니다.

Additional Use Grant

BUSL-1.1은 Licensor가 일정 조건 하에 상용 목적의 사용자에게 권리를 부여할 수 있도록 하는 Additioanl Use Grant 조항을 갖고 있습니다.

The Licensor may make an Additional Use Grant, above, permitting limited production use.

따라서, Licensor는 필요에 따라 사용자의 상용 목적의 소프트웨어 사용을 허락할 수 있습니다. 예를 들어, Lightbend는 Play Framework를 사용하여 application을 개발하는 과정에서 akka가 활용되는 경우는 akka를 사용할 수 있다고 허용하였습니다.

Additional Use Grant: If you develop an application using a version of Play Framework that utilizes binary versions of akka-streams and its dependencies, you may use such binary versions of akka-streams and its dependencies in the development of your application only as they are incorporated into Play Framework and solely to implement the functionality provided by Play Framework; provided that, they are only used in the following way: Connecting to a Play Framework websocket and/or Play Framework request/response bodies for server and play-ws client.

Akka의 라이선스 FAQ

Lightbend는 Akka의 라이선스 변경과 관련한 FAQ를 제공하고 있는데요, 여기서는 몇 가지 주요한 내용만 소개하겠습니다.

스타트업 규모의 회사에는 무료로 제공

먼저 Akka의 가격표를 보면 연간 매출이 2,500만 달러 미만의 스타트업 회사에는 무료로 제공됩니다.

이전 버전의 Akka는 계속 사용할 수 있나?

이전 버전의 라이선스는 변경 없이 Apache-2.0입니다. 그러나 추가적인 기능, 개선 사항, non-critical security updates, non-critical bug fix는 제공되지는 않습니다. 2.6.x 버전의 경우, 향후 1년간, 즉 2023년 9월까지만 Apache-2.0으로 critical security updates와 critical bug fix만 제공됩니다.

Production을 위해 사용하기도 하고, 개발, 테스트 나 Staging으로사용하기도 합니다. 어떤 경우에 상용 라이선스가 필요한가요?

Production을 위해 사용하는 소프트웨어 사본에 대한 상용 라이선스만 있으면 됩니다.

수익과 관련 없는 정부 부처에서 일하는데, 상용 라이선스 구매가 필요한가요?

non-production use가 아닌 production에 Akka를 사용한다면 정부 부처에서도 상용 라이선스 구매가 요구됩니다.

Government departments using Akka in production will require a commercial license.

BUSL-1.1이 적용된 소프트웨어의 일부를 Apache-2.0이 적용된 older version에 backport해도 되나요?

아니요, 이는 Lightbend의 저작권을 침해하는 것뿐만 아니라 Apache-2.0을 위반하는 것입니다.

No. In this circumstance, you would either violate Lightbend’s copyright by re-releasing the code under Open Source, or you would violate the earlier Akka version’s Apache license by introducing incompatible BSL code (i.e., code subject to a use limitation not allowed by the Open Source Apache 2.0 license).

마치며

기업의 오픈소스 거버넌스 역할은 갈수록 중요해지고 있습니다. 오픈소스를 제품에 사용하면서 오픈소스 라이선스의 의무를 준수하여 오픈소스 고지, 소스 코드 공개 등의 활동은 기업이 지켜야 할 기본적인 컴플라이언스 활동입니다. 그런데 얼마 전부터는 오픈소스 라이선스 의무 준수뿐만 아니라 오픈소스이었던 소프트웨어가 BUSL-1.1과 같이 상용 구매를 요구하는 라이선스로 변경되는 사례가 증가하고 있습니다. 따라서, 오픈소스를 사용하여 제품/서비스를 개발하는 기업은 이러한 라이선스 변경 소프트웨어에 대한 빠른 대처가 필요합니다. 그렇지 않을 경우, 라이선스 위반으로 큰 손실이 발생 될 수 있음을 기억해야 합니다.

특히 기업은 SBOM(Software Bill of Materials) 관리 체계를 구축하여, 이번 Akka와 같이 라이선스 변경 사례를 확인하였을 경우, 기업 내 어느 제품/서비스 혹은 내부 시스템에 Akka가 사용되고 있는지, 그 버전은 무엇인지를 바로 확인하고, 필요한 조치 (older version 사용, 혹은 사용 라이선스 구매)를 취할 수 있어야 하겠습니다.

감사합니다.

SFC vs. Vizio 판결 겉핥기

SFC와 Vizio의 GPL 소송에 대한 배경과 쟁점을 살펴 보겠습니다.

By 장학성 | 2022년 6일 14월

안녕하세요, 장학성입니다.
SFC(Software Freedom Conservancy)가 GPL 위반을 이유로 미국의 스마트 TV 제조사인 Vizio에 소송을 제기하였는데요, 지난 2022년 5월 13일, 이와 관련한 미국 연방 법원의 판결이 있었습니다.
이번 판결의 배경과 시사점을 수박 겉핥기로 정리해보았습니다. 제가 법률 전문가가 아니기 때문에 용어나 해석에 있어서 오류가 있을 수 있습니다. 여러 전문가분께서 피드백 주시면 고맙겠습니다. ^^

References

먼저 이 글을 작성하면서 참고한 references를 밝힙니다.

PROCEEDINGS: (IN CHAMBERS) ORDER GRANTING PLAINTIFF’S MOTION TO REMAND : https://storage.courtlistener.com/recap/gov.uscourts.cacd.837808/gov.uscourts.cacd.837808.30.0.pdf
Software Freedom Conservancy files right-to-repair lawsuit against California TV manufacturer Vizio Inc. for alleged GPL violations : https://sfconservancy.org/copyleft-compliance/vizio.html
SFC Files GPL Enforcement Suit Against Vizio Advancing Novel Legal Theories : https://heathermeeker.com/2021/11/09/sfc-files-gpl-enforcement-suit-against-vizio-advancing-novel-legal-theories/
First Update on the Vizio lawsuit : https://sfconservancy.org/blog/2021/nov/30/vizio-update-0/
SFC v. Vizio remanded back to California state courts : https://lwn.net/Articles/895405/
Software Freedom Conservancy right-to-repair lawsuit against California TV manufacturer Vizio, Inc. remanded to California State Court : https://sfconservancy.org/news/2022/may/16/vizio-remand-win/
미국 법원 “GPL도 계약”…소비자의 코드 요구권 인정 : https://zdnet.co.kr/view/?no=20220518145132
오픈소스 라이선스 위반과 저작권 침해 : https://olis.or.kr/library/openSwDetail.do?bbsId=103&bbsNum=26400
오픈소스 라이선스에 대한 법적 효력 : https://www.copyright.or.kr/information-materials/trend/the-copyright/download.do?brdctsno=10231&brdctsfileno=4699
연방 법원(Federal Court) 특징 : https://lawandstory.com/연방-법원federal-court-특징/

1. 배경지식

지난 5월 18일, “미국 법원 “GPL도 계약”…소비자의 코드 요구권 인정“이라는 제목의 기사가 나왔는데요, 다음과 같은 문장은 뭔가 중요한 말인 것 같은데 정확히 어떤 의미인지 잘 이해가 되지 않았습니다.

“조세핀 L. 스테튼 미국 지방법원 판사는 판결문에서 “GPLv2가 저작권법으로 제공하는 권리와 추가 계약 약속의 집행은 별도로 구별되는 추가 요소에 해당한다는 SFC의 주장이 연방법에 의해 선점되지 않으므로 (상급법원으로) 환송한다"고 밝혔다.”

그래서 호기심에 몇몇 자료들을 찾아보았고, 나름대로 이해한 바를 정리해 보았습니다. 저와 비슷한 고민이 있으셨던 분들께 도움이 되길 바랍니다.

1-1 저작권법과 계약법

저작권법

이용권자(라이선시)는 저작권법이 허락 하는 이용 방법 및 조건의 범위 안에서 저작물을 이용 가능
- 여기서 ‘이용’은 복제, 공중 송신, 배포, 이차적저작물 작성 등의 저작재산권이 부여하는 행위만을 뜻하고, ‘사용’행위는 포함하지 않음
- ‘사용’행위에 대한 방법이나 조건이 있다면 이를 위반하여도 저작재산권 침해는 성립하지 않고, 계약위반으로 인한 책임만 부담
이용권자(라이선시)가 저작권법이 허락하는 이용 방법과 조건의 범위를 벗어나는 행위를 한다면 저작권 침해에 해당
저작권 침해에 해당한다면 저작권법 위반으로 형사처벌, 금지 청구 가능

계약법

일반적으로 계약은 라이센서(오픈소스라면 copyright owner)와 라이선시 사이의 합의
계약법에 의한 책임을 물으려면 우선 양 당사자 사이에 정당하게 계약이 성립되었음이 요구됨
계약(합의)’의 효력으로서 부담하는 의무에 위반한 경우에는 채무불이행으로 인한 계약 책임만 부담
- 저작권 침해처럼 형사처벌이나 금지 청구를 당할 염려는 없으며 약정된 손해배상액을 물어주어야 함
오픈소스 라이선스 하의 저작물을 계약의 성립이 구성된다고 보는 것은 관할권마다 다툼의 여지가 있음
손해배상의 액수나 구제 조치 등에 있어서 제한적

사례

GPL software의 저작권자가 저작권 침해 주장으로 소송 제기
- 예: Harald Welte, Patrick McHardy)
Jacobsen v. Katzer 판례
- 라이선스 조건을 부과하고 있는 저작권 라이선스가 준수되지 아니한 경우에는 저작권 침해
- 라이선스 규정이 조건(condition)이라면 저작권법이 적용되고 합의사항 (covenants)에 불과하다면 계약법 적용
한컴 vs. 아티팩스
- 한컴은 계약 서명과 같은 행위 또는 상호 합의 과정이 없었기 때문에 계약 위반이 아니라고 주장하
- 법원은 계약 위반에 해당한다고 판결

1-2 미국 연방 법원 (Federal Court)와 주 법원 (State Court)

미국에는 연방 법원과 주 법원이 있으며, 각각 다른 성격의 사건을 다룬다.
- 주 법원 : 대체로 주민의 개인적인 삶에 영향을 미치는 사건 (가정법, 유언법 등)
- 연방 법원
  - 지역 법원 (District Court), 항소 법원 (Appellate Court), 대법원 (Supreme Court)로 이루어져 있음
  - 제한된 사건만 다루고 있음 : 헌법, 연방 범죄, 군법, 지적재산권 등
  - 저작권법(Copyright Act)은 연방 법원에서 다룸
미국에서는 연방 법원에서 저작권 주장에 대한 독점적인 관할권을 갖고 있다.
- 따라서, 과거 미국에서의 GPL 소송을 위한 거의 모든 주장은 저작권법에 대한 독점 관할권을 가진 연방 법원(Federal Court)에 제기됐다.
소장을 엉뚱한 법원에 제출한다면, 사건은 기각되거나 다른 법원으로 이송된다.
- 즉, 주 법원(State Court)에 제기된 action이 연방 법원에 의해 선점(preempt)되는 경우 제거될 수 있음

2. SFC vs. Vizio 소송 히스토리

SFC는 2021년 10월에 Vizio를 상대로 소송을 제기하였습니다. 당시 소송 내용과 이후 히스토리는 다음과 같습니다.

2021-10-19

SFC는 Vizio를 상대로 SmartCast TV와 관련하여 GPL 및 LGPL을 위반했다고 주 법원에 소송을 제기
- plaintiff : Software Freedom Conservancy, Inc. (”SFC”)
- defendant : Vizio, Inc. (”Vizio”)
- allege :
  - Vizio uses “at least twenty-five programs, including the Linux kernel software” in its smart TVs that are covered by the GPL Agreements,
  - Vizio does not make the corresponding source code for these programs available to purchasers of its smart TVs.
- seek :
  - to enforce SFC’s right to have access to the source code corresponding to the executable code resident on Vizio’s devices covered by the GPL Agreements.
  - as a remedy to its breach of contract claim, SFC seeks to compel Vizio to make the source code available
- claim :
  1. breach of contract and
  2. declaratory relief (선언적 판결)
    - 선언적 판결이란 미국의 민사소송법 내 절차로 판사가 민사소송에서 당사자들의 권리, 의무, 책임 등을 선언하는 것을 말하며 이때 어떤 이행 명령이나 조치, 또는 배상을 명령하지는 않음. 특허 등의 소송의 경우, 침해혐의자가 특허권자를 상대로 비침해, 무효, 권리 불행사의 확인을 구하는 소 또는 반소 등으로 사용됨.
참고 : “최근 소송 사례 : Stockfish v. ChessBase, SFC v. Vizio (박원재)”

2021-11-29

이에 대해 Vizio는 다음과 같이 반박하였습니다.

GPL을 위반하는 것은 저작권 침해에 해당
저작권법은 연방 법원이 선점(preemption)하기 때문에 주 법원에서 다룰 사안이 아님
저작권법하에서 저작권 소유자만 GPL 및 LGPL에 따라 소스 코드를 요청할 권리가 있고, SFC가 소비자로서 소스 코드를 요구할 권리는 없다.

그렇기 때문에, Vizio는 주 법원에 제기된 이 사건을 연방 법원에서 맡아줄 것을 요청(NOTICE of REMOVAL of ACTION to FEDERAL COURT)하였습니다.

In Response,

SFC는 이러한 Vizio의 주장에 반박하며 이 사건을 다시 주 법원으로 환송하기 위한 요청서(Motion to Remand)를 연방 법원에 제출하였습니다.

2022-05-13

연방 법원은 SFC의 Motion to Remand를 승인(ORDER GRANTING PLAINTIFF’S MOTION TO REMAND)하여 이 사건을 주 법원으로 환송하였습니다.

3. 주목할 만한 사항

이번 소송은 기존 GPL 소송 사례와는 여러 새로운 면이 있습니다. 미국의 오픈소스 전문 변호사인 Heather Meeker는 이에 대해 아래와 같이 설명하였습니다.

3-1. 계약 위반(Breach of Contract)과 특정 이행(Specific Performance)

과거에는 거의 모든 GPL 소송이 저작권 침해 주장으로 제기되었음
하지만, 이번 소송은 저작권법이 아닌 계약법 하의 claim
금전적 손해 배상(monetary damages)이 아닌 모든 TV 구매자에게 copyleft license가 요구하는 technical information을 제공할 것을 요구 (소스 코드 공개)
- “damages”에 대한 보상이 아닌 소스 코드 공개를 요구 : “specific performance”
계약법에서 금전적 손해를 제외한 모든 구제 청구는 특정 이행(specific performance)을 요구하는 것임 (specific performance는 계약법에서는 드문 구제 방법
일반적으로 원고가 계약을 위반한 피고에게 보상금 대신 specific performance를 요구하는 경우는, 돈으로 대체할 수 없는 것을 원하기 때문

specific performance

Fulfilling the requirements of a contract in exactly the way the contract specifies. When most contracts are disputed in court, the plaintiff expects to receive money, that they can use to remedy the harm that the other party caused them in not holding up their side of the deal. When a plaintiff seeks specific performance, they want something that money can’t replace.

3-2. Claim Brought in State Court

미국에서는 연방 법원에서 저작권 주장에 대한 독점적인 관할권을 갖고 있음
따라서, 과거 미국에서의 GPL 소송을 위한 거의 모든 주장은 저작권법에 대한 독점 관할권을 가진 연방 법원에 제기했다.
하지만 이번 SFC가 제기한 소송은 Orange County, California 주 법원에 제기하였다.
주 법원 소송은 연방 법원에 비해 예측 불가하고, 결과가 일관적이지 않으며, 새로운 법률 이론에 대해 예상치 못한 견해를 보일 가능성이 있다.

3-3. No Author as Plaintiff

SFC는 제품의 구매자로서 소송을 제기
과거 GPL 소송의 원고는 GPL software의 저작권 소유자였다.
이와 달리, 이 소송의 원고는 SFC이고, Vizio TV를 구매한 소비자로서 소송 제기
SFC는 저작권 소유자뿐만 아니라 제품의 소비자도 소스 GPL 코드를 받을 권리가 있음을 증명하고자 함

3-4. Declaratory Relief

이 소송은 본질적으로 법원에 GPL 및 LGPL이 법적으로 집행 가능하고 (enforceable) Vizio가 이를 위반하였음을 선언하도록 요청했다.
GPL을 계약으로 본다고 해도, 일반적으로 계약은 licensor (i.e. code copyright owner)와 licensee 사이의 계약이기 때문에 SFC는 계약 당사자로 보기 어렵다.
그래서, SFC는 자신과 모든 소비자가 계약의 제삼자 수혜자 (third party beneficiary)라는 이론으로 소송을 제기하였다.
- Third Party Beneficiary : 계약서의 당사자가 아니면서 계약서를 강행하도록 소송을 걸 수 있는 사람을 의미, 즉, 계약서의 당사자가 아니더라도 계약의 이익에 직접적으로 관여된 사람을 의미
- GPL의 제삼자 수혜자 : GPL 계약의 당사자는 아니지만, GPL 계약 당사자들이 계약을 성실히 수행할 때 혜택을 얻을 수 있는 자. 이러한 혜택의 한 예는 GPL software의 소스 코드를 받는 것임

third-party beneficiaries of the GPL

People who aren’t a party to a GPL agreement, but who would benefit from the contract if the parties to the GPL do as they promise under the agreement. An example of such a benefit might be the receipt of the source code of the GPL’d software. See also General Public License (GPL).

4. 연방 법원 판결 주요 내용 (2022-05-13)

2022년 5월 13일 연방 법원에서는 어떤 내용의 판결을 했는지 살펴보겠습니다.

4-1. 주요 관건

법원은 우선 연방 법원에서 판단해야 할 주요 관건을 다음과 같이 설명하였습니다.

법원이 결정해야 할 유일한 문제는 federal Copyright Act (연방 저작권법)이 SFC의 claim (breach of contract and declaratory relief)을 완전히 선점(preempt)하여 연방 관할권을 생성하는지 여부이다.
만약 claim이 연방 저작권법에서 다루는 일반적인 저작권 범위 내의 권리(복제, 2차 저작물 배포 및 전시에 대한 배타적 권리 등)와 동등하다면 연방 저작권법에 의해 선점되기 때문에 연방 관할권을 생성한다.
만약 사건이 연방 저작권법에 의해 선점되지 않는다고 주장하려면, 소송 원인이 저작권이 보호하는 권리 이외의 권리를 보호해야 하고, 이에 해당하는 “extra element”가 있어서 소송의 성격을 변경할 수 있어야 한다.

4-2. 관련 판례 : “Versata Software vs. Ameriprise”

GPL이 derivative work에 대해 소스 공개를 요구하는 건 저작권 의무와는 별개이다.
피고는 저작권 침해로 소송을 제기당한게 아니다.
- 오픈소스 프로그램을 포함하는 파생 저작물에 대한 ‘additional obligation : 소스 공개 의무 미준수’을 위반했기 때문에 원고로부터 소송을 당한 것이다.
이처럼 저작권법에 의해 제공되는 권리에 해당하지 않는 “additional contractual promise”은 “extra element”에 해당한다.

4-3. SFC의 Claim이 “extra element”인지 여부

저작권법의 보호 목적은 저작물을 복제, 배포, 전시할 수 있는 사람을 제한하는 독점권이다.
그러나 저작권법은 소스 코드를 받을 권리를 부여하지 않는다. 이런 권리는 오히려 저작권법이 보호하는 독점권과 정반대이다.
저작권자가 아닌 SFC가 GPL agreement의 제삼자 수혜자로서의 지위를 주장하는 것은 저작권법에 따른 권리와는 다르다.
즉, SFC가 GPL agreement의 제삼자 수혜자 (third-party beneficiary)로서 소스 코드를 받을 자격이 있다고 주장하는 건 “extra element”이다.

4-4. Vizio의 주장이 유효한지 여부

Vizio는 오픈소스 라이선스 위반은 저작권 침해라고 주장하지만, SFC는 이번 소송에서 저작권 침해에 대한 claim을 하지 않았다.
- 원고가 claim하지 않은 사항을 법원이 판단할 이유는 없다.
- 게다가 SFC는 저작권자가 아니기 때문에 그런 주장조차 할 수 없다.
- SFC는 저작권법에 의해 Vizio의 복제, 파생저작물 제작 등을 하는 것을 제한하려는 것이 아니라, 소스 코드를 제공하도록 요청할 뿐이다.
Vizio는 소스 코드 제공이 라이선스의 ‘condition’이므로 이를 위반하는 건 ‘계약 위반’이 아니라 ‘저작권 침해’에 해당한다고 주장하였다.
- 따라서 SFC의 ‘contract claim’은 저작권 침해로 전환되어야 한다고 주장하였다.
- 하지만 “수행 의무가 발생하기 전에 반드시 발생해야 하는 행위 또는 사건” 이라는 condition 위반 만이 저작권 침해를 구성할 수 있으며, 이외 다른 모든 license terms, covenants의 위반은 계약법에 의해서만 소송이 가능하다
- 또한, 모호한 계약 조항은 condition이 아니라 covenant로 해석한다

4-5 판결

SFC의 주장이 저작권법에 의해 완전히 선점되지 않았다.
- GPL 계약은 저작권 라이선스뿐만 아니라 계약(contractual agreement)의 기능을 모두 수행한다.
따라서, 연방 법원은 관할권이 없으며 주 법원으로의 환송 신청을 승인한다(the Motion to Remand is GRANTED).

5. 시사점

이번 판결에 대해 SFC는 많은 사람이 GPL은 저작권 라이선스로만 기능한다고 알고 있는데, 저작권 라이선스 뿐만 아니라 계약으로서도 기능한다는 것을 보여준 Copyleft license 역사에서의 분수령이 된 순간이라고 말하였습니다. 또한, SFC는 이 소송이 GPL의 제삼자 수혜자로서의 개인 소비자의 권리에 초점을 맞춘 최초의 법적 사례이며, 이런 소비자의 권리를 주 법원에서 증명할 기회를 기대하고 있다고 밝혔습니다.

사실 저는 국내 기사만을 (대충) 봤을 때는 SFC가 소송에서 이겼고, 이제 일반 소비자도 기업을 대상으로 GPL 소스 코드를 요구할 법적 권리가 생긴 줄로 생각했는데, 이번 판결 내용은 그에 대한 최종 판결을 한 것은 아니었습니다. 앞으로 주 법원에서 이를 위한 다툼을 할 수 있는 기회를 부여 받은 판결로 이해됩니다.

끝으로, 이에 관련한 Heather Meeker의 의견은 좋은 참고가 됩니다.

SFC는 GPL 소송 기준을 새롭게 만들려고 노력하고 있다. 환영할 만하지만 역효과도 우려된다.
- 지난 25년간 GPL software를 사용하여 제품을 만드는 많은 회사는 GPL 소송에 크게 걱정하지 않았다.
- 만약 이번 소송에서 SFC가 승소한다면, 기업은 GPL code를 사용하는 데 부담을 가질 수 있고, 이는 free software의 확산에 걸림돌이 될 수 있다.
- 또한, 일반 대중이 GPL 소송을 제기할 수 있게 되는 경우, 금전적인 이익만을 목적으로 하는 트롤이 나타날 수 있다.
SFC의 시도가 성공할 수 있을지도 아직은 모른다.
- 연방 법원이 이 사건을 기각하지 않고 주 법원으로 환송했다는 것은 SFC의 주장을 모두 받아들였다고 보기보다는 단순히 사건이 연방 법원에 적절하지 않으며, 따라서 기각할 근거도 없기 때문에 환송했다고 볼 수 있다.
- 일단, SFC는 GPL의 제삼자 수혜자로서 피고에 소스 코드 공개를 요청할 자격이 있다고 주장할 입지를 얻었다.
- 하지만, 앞으로 이 소송은 복잡하고, 길어질 수 있으며, 큰 비용이 들어갈 수 있다.
- 대부분의 GPL 소송은 대개 신속히 합의로 해결되기도 한다.

이상으로 정리를 마치며, 다시 잘 이해되지 않았던 국내 기사를 보겠습니다.

이제 이해가 되는 것 같습니다. 그런데, 여전히 왜 “(상급법원으로)” 환송한다고 표현했는지는 잘 모르겠습니다. 미국 지방법원은 연방 법원에 해당하고, 이 사건은 주 법원으로 환송하는 건데, 왜 “(상급법원으로)” 환송한다고 표현했을까요? 오타일까요, 미국에서는 주 법원을 상급법원으로 표현하나요? 아니면 제가 뭔가를 잘 못 이해하고 있는걸끼요? 법률 전문가 분의 의견 부탁 드려봅니다. :)

감사합니다.

이너소스 도입을 위한 과제와 효과

By 장학성 | 2022년 4일 3월

안녕하세요, 장학성입니다.

이너소스(Inner Source)는 오픈소스 개발방법론을 사내에 도입하여 조직간 공유와 협업을 극대화하고, 빠른 개발 속도와 투명한 커뮤니케이션, 코드 품질 향상 등의 효과를 기대하기 위한 방법입니다.

이너소스를 위한 방법은 여러 문서에서 설명하고 있는데요, 오늘은 다음 자료에서 언급하고 있는 이너소스를 시작하는 방법과 기대효과에 대해 간략히 정리하였으니 참고하시기 바랍니다.

Getting Started with InnerSource (Keys to collaboration and productivity inside your company) / Adny Oram

1. 오픈소스 Practice 주요 사항

먼저, 오픈소스 개발방법론에서 강조하는 주요 Practice를 살펴보겠습니다. 어떻게 거대한 오픈소스 프로젝트가 자발적인 참여에 의해 성장해갈 수 있을까요? 왜 오픈소스 프로젝트에 참여하면 개발자 개인의 성장을 이룰 수 있다고 할까요? 오픈소스 프로젝트에는 다음과 같은 주요 Practice가 있기 때문입니다.

(1) 조직간 협업

오픈소스 프로젝트에서는 코드를 전 세계에 공유하기 때문에 이를 누구나 자유롭게 보고, 배우고, 개선할 수 있습니다.
branch를 자유롭게 만들고, 병합하기 위한 rule이 있고, 이를 가능하게 하는 tool이 있습니다.
이로써 근무지와 무관하게 동일한 code에서 작업할 수 있습니다.

(2) 문서화

오픈소스 프로젝트는 Code에 대해서 가능한 자세히 문서화를 합니다.
이런 문서화가 소프트웨어 아키텍처 개선으로 이어집니다. 문서로 설명하다 보면 복잡하고 직관적이지 않은 아키텍처의 변경 필요성에 공감하게 됩니다.
문서화가 잘 되어 있는 프로젝트는 신규 Contributor의 유입도 수월하게 합니다.

(3) Continous Test

일반적으로 오픈소스 프로젝트는 각 기여를 객관적으로 test하는 엄격한 시스템을 구축합니다. 이로써 collaborator 간 신뢰를 유지하게 하고, 코드 품질을 보장합니다.
즉, 변경사항을 commit 하기 전 quality를 보장하기 위해 확인하는 tool과 절차가 있습니다.
- unit test
- continuous integration
- code coverage
- static analysis 등
각 개발자는 자신의 code에 대한 unit test를 작성해야 합니다.

(4) 모든 Communication 및 의사결정이 투명하게 공개됨

오픈소스 프로젝트에서의 모든 communication은 공개되고 이력으로 남습니다.
주로 mailing list로 토론에 기반하여 의사 결정을 합니다.
모든 communication이 문서화 되고, 이력으로 남기 때문에 누구나 문서를 통해 프로젝트를 이해하고 새롭게 참여할 수 있습니다.

(5) 개발자 실력을 인정 받을 수 있고, 다른 개발자 멘토링

많은 commit을 기여한 개발자라면 그 프로젝트에 이해도가 높은 개발자로 간주할 수 있습니다.
이러한 개발자는 Trusted Committer로 인정 받게 됩니다.
Trusted Committer는 다른 개발자의 작업을 review / 승인하는 자격이 주어집니다.
또한, contributor에게 멘토링을 제공함으로 우수 개발자로 성장시키는 역할을 수행합니다.

2. 이너소스 도입 효과

기업이 1에서 설명한 오픈소스 Practice를 사내에 도입하는 것을 이너소스(Inner Source)라고 부릅니다. 참고로, Inner Source는 InnerSource Commons 등의 커뮤니티에서 보다 체계적으로 기법과 Practice를 발전시키고 있습니다.

그럼 기업이 이너소스를 도입하면 어떤 효과를 기대할 수 있을까요?

조직 전체적으로 code 재사용이 늘어납니다.
- 각 팀의 개발자가 다른 팀이 개발한 모듈 및 아키텍처를 이해하고 활용하거나 기여할 수 있습니다.
Code Quality가 개선됩니다.
- unit test, code coverage, CI (continous integration), static analysis, code review 등을 통해 quality가 개선됩니다.
개발 속도가 빨라진다.
- 개발자가 unit test, code coverage, CI (continous integration)를 배워 감에 따라 bug가 줄고, 개발 속도가 빨라집니다.
- communication을 written comment로 하는 것이 처음에는 시간이 걸리는 것처럼 보이지만, 새로운 개발자가 시스템을 빨리 배울 수 있게 하여 개발 속도 향상에 더 도움이 됩니다.
개발자들이 code design, test, 문서화에 대한 새로운 기술을 배우면서 code design에 대해 보다 포괄적으로 고민하게 됩니다.
개발자들이 문서화를 더 잘하게 되고, 이는 다른 팀원이 프로젝트를 더 잘 이해해서 더 많은 기여를 할 수 있게 도와줍니다.
개발자들에게 권한을 부여함으로써 지적 성장과 직업 만족도를 높일 수 있습니다.

3. 이너소스 도입을 위한 과제

이번에는 이너소스를 도입하려는 기업이 고려해야 할 과제에 대해 알아보겠습니다.

사내에 source code를 공개하고 공유하는 것만으로 아너소스의 효과를 기대할 수는 없습니다. 반드시 다음의 사항이 함께 수반되어야 합니다.

Repository내의 모든 code에 대한 문서화
협업을 위해 Github과 같은 협업 환경 및 가이드 제공
test 환경 구축 및 rule 수립 : 신규 유입 code의 quality 보장하기 위함
- code가 commit되기 전에 code coverage test를 code의 90% 이상에서 실행
- commit이 되면 자동 build trigger
다른 조직으부터의 기여를 encourage하기 위해 modular architecture와 API 정의
참여자들에게 수행한 작업에 대한 자부심을 갖게 하고, Conference에서 발표하거나 Blog에 글을 기고하는 것을 적극 권장

4. 개발자는 왜 이너소스 프로젝트에 참여해야 하나?

사내에 이너소스 환경이 구축되었지만, 개발자 입장에서 당장 팀 내의 과제를 수행하다 보면 다른 팀의 코드를 보거나 기여하는 게 엄두가 나지 않을 수 있습니다. 하지만, 개발자 자신의 성장을 위해서라도 이너소스 프로젝트에 참여하는 것이 도움이 됩니다.

외부 오픈소스 프로젝트에 바로 참여하기 전에 사내 이너소스 프로젝트에 참여함으로써 오픈소스 Practice를 배우고 익숙해질 수 있습니다.
- 이너소스에서는 code review, commit, test가 오픈소스 방식으로 수행됩니다.
- 문서화에 익숙해집니다.
- Test, 문서화에 대한 새로운 기술을 배우면서 code design에 대해 보다 포괄적으로 고민하는 우수 개발자가 될 수 있습니다,
Trusted Committer와 Contributor 간의 communication을 지켜보고 있는 것 자체가 도움이 됩니다.

개발자가 오픈소스에 기여해야 하는 이유에 대해서는 다음 블로그에서도 언급하고 있으니 참고하시기 바랍니다. : “개발자가 오픈소스에 기여해야 하는 이유”

감사합니다.

상용 AI 서비스에 공개 Dataset을 사용해도 되나요?

Can I use this publicly available dataset to build commercial AI software?

By 장학성 | 2022년 2일 14월

안녕하세요, 장학성입니다.

AI는 사용하지 않는 기업이 없을 정도로 현대 비즈니스에 중요한 기술이 되었습니다. AI 서비스를 만들기 위해서는 많은 양의 data가 필요한데요, 공개 Dataset_{publicly available datasets}도 널리 사용되고 있습니다. 다만 공개 Dataset이라고 하더라도 저작권이 있기 때문에 이를 상용 AI 서비스에 사용하려면 저작권 침해 등 법적 리스크를 최소화하기 위해 라이선스 측면의 확인이 필요합니다.

오늘은 이와 관련하여 최근 발표된 논문인 Can I use this publicly available dataset to build commercial AI software?– A Case Study on Publicly Available Image Datasets을 소개하려고 합니다. : https://arxiv.org/abs/2111.02374

“Can I use this publicly available dataset to build commercial AI software? – A Case Study on Publicly Available Image Datasets”

- Gopi Krishnan Rajbahadur, Erika Tuck, Li Zi, Dayi Lin, Boyuan Chen, Zhen Ming (Jack)Jiang, Daniel Morales German

이 글을 통해 공개 Dataset을 활용한 AI 서비스를 준비하면서 저작권 침해를 최소화하기 위해 어떤 노력과 절차를 거쳐야 하는지에 대한 인사이트를 얻을 수 있기를 바랍니다.

1. Intro

이 논문에서는 먼저 공개 Dataset을 사용하기 위한 라이선스는 오픈소스 라이선스와는 달리 몇 가지 어려운 문제가 있다고 설명합니다.

해당 Dataset에 대한 완전하고 정확한 라이선스를 식별하기가 어렵다.
- 예를 들어, Dataset을 제공하던 웹사이트가 폐쇄되는 경우도 있다.
해당 Dataset에 대한 라이선스가 유효한지 확인하는 것이 어렵다.
- 많은 Dataset은 여러 개의 Data Source를 결합하여 생성한다. 이러한 여러 Data Source는 각각 다른 라이선스가 적용된다.
- 더구나 publicly available dataset의 작성자는 Dataset을 만들면서 사용한 다양한 Data Source의 라이선스를 거의 문서화하지 않는다.
- 예를 들어, CIFAR-10 Dataset도 웹사이트에서 요구하는 유일한 라이선스는 ‘인용 요구' 뿐이고 그 외에는 설명하지 않는다.
  - 하지만, CIFAR-10는 상업적 이미지 사용을 제한할 수 있는 라이선스가 적용된 Google Images, Flickr와 같은 다양한 Data Source의 이미지를 크롤링하여 생성되었다.
  - 이러한 경우, CIFAR-10의 라이선스만을 고려하는 것은 컴플라이언스 문제가 될 수 있다.
Publicly available dataset에 적용된 라이선스는 일반적으로 모호하여 권리와 의무를 명확하게 설명하지 않는다.
- 이러한 Dataset을 사용하여 라이선스 리스크 없이 상용 AI software를 구축하는 것은 실제로 어렵다.
- 예를 들어, GitHub Copilot은 Github에서 호스트되는 수십억 줄의 source code로 training한 대규모 AI Model을 사용한다.
  - 그러나 오픈소스 라이선스에서는 소스 코드를 상업적 목적으로 AI Model을 training 하는 데 사용할 권리에 대해 명확하게 정의되지 않았다.
  - 이러한 모호성은 GitHub Copilot의 컴플라이언스에 대한 광범위한 법적 논쟁으로 이어졌다.

GitHub Copilot

여기서 잠깐 GitHub Copilot과 관련한 논쟁에 대해 언급하고 넘어가겠습니다. 최근 미국의 SFC_{Software Freedom Conversancy}에서는 “If Software is My Copilot, Who Programmed My Software?“라는 글을 게재하여 Microsoft와 GitHub의 주장에 대하여 반박하였습니다.

Copilot은 GitHub에 개발자의 코드 작성을 돕기 위해 공개된 source code를 학습한 AI 서비스이며, 여기에는 Copyleft software도 포함되어 있어서 법적 이슈가 되고 있습니다. 이에 대해 GitHub CEO인 Nat Friedman은 아래와 같이 반박하였는데요,

ML system을 training 하기 위한 public data의 사용은 Fair Use이다.
ML system에 의한 output은 시스템 operator에게 속한다_{the output belongs to the operator}.

하지만, SFC는 이러한 GitHub의 입장은 Copilot 다음과 같이 사용자에게 큰 피해를 줄 수 있다고 경고하였습니다. 따라서 다른 사람의 저작권을 침해하지 않으려면 Copilot을 사용하지 않는 것이 좋다는 입장을 표명하였습니다.

“the output belongs to the operator”라는 GitHub의 주장은 잘못된 법적 정당성을 만든다.
GitHub CEO의 진술은 GPL enforcement action에 직면할 수 있는 Copilot 사용자에 대한 배상 책임을 회피한다.
결국 사용자가 Copilot의 output에 대한 ‘Fair Use’ 또는 ‘not copyrightable’하다는 방어책을 마련해야 한다는 말이다.

그러면서, SFC는 Microsoft와 GitHub는 copylefted code로 training 하는 것이 ‘Fair Use’인 이유와 trained model이 “work based on GPL’d software”가 아님을 증명해야 한다고 주장하였습니다.

2. Background

다시 오늘 살펴볼 논문으로 돌아오겠습니다. 논문에서는 Dataset과 관련한 법률 중 저작권법과 계약법에 관해 설명합니다.

저작권법

기본적으로 copyright-protected data는 저작권 소유자가 명시적으로 허용하지 않는 한 상업적으로 사용하거나 배포할 수 없다. publicly available dataset에도 저작권이 있는 data가 포함되었을 수 있다.

이를 상업용 AI software를 개발하는 데 사용하면 잠재적으로 저작권 침해가 발생할 수 있다.
다만, 특정 상황이나 국가에서는 저작권 소유자의 명시적 허가 없이 상업적 목적을 포함한 다양한 목적으로 저작권 보호 data를 사용하는 것이 허용될 수 있다
- 예를 들어, 미국에서는 최근 소송인 Authors Guild v. Google에서 제안한 바와 같이 저작권 보유자에게 실질적인 피해가 없을 때 Fair Use 원칙에 따라 copyrighted data를 사용하는 것이 허용된다.
하지만, 이러한 Fair Use에 대한 판단은 국가마다 다를 수 있다.
- 영국과 캐나다에서는 저작권 침해에 대한 fair dealing exception에 따라 저작권 보유자의 명시적 허가 없이 copyright protected data를 비상업적 목적에 한하여 사용할 수 있다.
- EU에서는 Text and Data Mining Law에 따라 저작권 소유자의 명시적 허가 없이 비상업적 목적으로 copyright-protected material을 사용할 수 있다.
이와 같이 상업용 AI software를 구축하기 위해 저작권으로 보호되는 data가 포함된 publicly available datasets를 사용하면 잠재적인 저작권 침해가 발생할 수 있다.

계약법

계약법에 따르면 저작물(예: 이미지, 비디오)의 저작권 소유자는 다른 사람이 향유할 수 있는 권리와 그러한 권리를 향유하기 위해 이행해야 하는 의무를 설명하는 라이선스를 부여할 수 있다.

라이선스 조건이 존중되지 않는 경우, 즉 라이선스에 의해 부여되지 않은 권리가 data에 의해 행사되거나 의무가 이행되지 않는 경우 (잠재적) 계약 위반 또는 계약 위반에 해당할 수 있다.

결국 공개 Dataset을 사용하여 AI 서비스를 개발하는 기업은 (Fair Use로 판단할 수 있는 경우를 제외한다면) 저작권침해, 계약법 위반 등을 방지하기 위하여 공개 Dataset과 관련된 권리와 의무를 확인하고 라이선스 컴플라이언스를 보장하기 위한 엄격한 접근 방식이 중요하다고 강조합니다.

그런데 이후에 다시 언급하겠지만 사실 공개 Dataset을 사용하면서 Dataset, Data Source 뿐만 아니라 data point 등의 모든 라이선스를 확인하고 각각의 의무를 준수하는 것은 거의 불가능에 가깝습니다. 공개 Dataset을 사용하기 위해 일정 부분의 라이선스 리스크를 감수하거나 Fair Use라고 주장할 수 있는 법적 근거를 마련하는 것이 현실적인 대응 방안이라고 개인적으로 생각합니다.

그럼 이 논문에서 제안하는 공개 Dataset을 상용 AI 서비스에 활용하기 위한 엄격한 접근 방식이 무엇인지 살펴보겠습니다.

3. Approach

이 논문에서는 공개 Dataset을 사용하려는 AI engieer는 적용된 라이선스를 식별해야 하고, Lawyer는 해당 라이선스의 권리와 의무를 분석하여 상용 AI 서비스에 적용할 수 있는지 판단해야 함을 강조합니다.

먼저, Phase 1은 AI engineer에 의해 라이선스를 확인하는 과정입니다. 논문에서는 자세한 내용을 아래와 같이 설명합니다.

Phase 1 : License identification

(Step 1) License extraction

AI engineer는 먼저 공개 Dataset을 다운로드한 웹사이트에서 라이선스를 식별한다.
라이선스를 찾을 수 없는 경우 라이선스가 Dataset내에 별도의 파일로 제공되는지 확인한다.
그래도 없으면 Dataset의 소유자에게 연락하여서라도 라이선스를 확인한다.

CIFAR-10를 예로 들면, 웹사이트에 다음과 같이 이 Dataset을 사용하기 위한 조건이 있고, 이를 라이선스라고 간주할 수 있다.
Please cite it if you intend to use this dataset. “Learning Multiple Layers of Features from Tiny Images, Alex Krizhevsky, 2009."

(Step 2) Provenance extraction

여기서 Provenance는 Dataset의 원출처를 의미한다.

한 연구자가 생성한 Dataset을 누군가 나중에 다른 플랫폼에서도 수정/추가 등 변경 후 배포할 수 있다.
따라서, AI engineer는 입수한 Dataset이 원 작성자가 생성한 것과 동일한지 확인하는 것이 중요하다.
즉, Step 1단계에서 추출한 라이선스가 Dataset의 올바른 라이선스인지 확인하기 위해 Dataset의 원출처를 확인한다.

(Sub-step 1) 우선 적절한 검색어로 검색 엔진에 쿼리하여 Dataset의 공식 출처(예: 공식 웹사이트, 연구 논문 또는 기술 보고서)를 찾는다.
(Sub-step 2) 공식 출처에서 라이선스 및 metadata를 추출한다.

CIFAR-10를 예로 들면, 라이선스 및 원출처에 대한 내용을 다음과 같이 기록해 둘 수 있다.

(Step 3) Lineage extraction

컴퓨터 비전 및 NLP Dataset을 포함하여 많은 publicly available dataset은 일반적으로 이미지와 같은 data를 호스팅하거나 인기 있는 웹사이트 등 다양한 소스에서 data를 수집하여 생성된다. 이러한 Data Source의 라이선스는 Dataset의 라이선스와 다르기 때문에 추가로 확인해야 한다.

(Sub-step 1) Dataset 생성 프로세스를 추적한다.
- 이를 별도로 기록해둔다. (위 테이블의 “Description of the data collection process” 필드 참조)
- 만약, Data Source 내에 또 다른 Data Source가 있다는 것을 알게 되면 해당 Data Source도 찾아서 기록한다. (재귀적으로 반복)
- 예를 들어, CIFAR-10는 80 Million Tiny Images라는 다른 dataset의 subset이다. 논문을 통해 이 Dataset에는 Google, Flickr, Ask, Altavista, Picsearch, Webshots 및 Cydral의 7가지 Data Source가 있다는 것을 알 수 있다.
(Sub-step 2) Data Source의 공식 출처를 찾는다. (웹사이트, 검색 엔진 등 활용)
- 예를 들어, 80 Million Tiny Images 웹사이트에서는 Dataset이 더 이상 제공되지 않는다. 이 경우, 가능한 아카이브 버전을 찾는다. (예: http://web.archive.org/web/20100601000000*/http://groups.csail.mit.edu/vision/TinyImages/)
- 그런 다음, 위에 나열한 7가지 Data Source 각각에 대한 공식 웹사이트를 알아낸다.
(Sub-step 3) 시간적으로 적용 가능한 라이선스인지 확인한다.
- Data Source의 라이선스가 시간에 따라 달라졌을 수도 있음을 염두에 둬야 한다.
- 즉, Dataset이 생성된 시점의 Data Source에 대한 라이선스를 확인한다.
- 예를 들어, Google Images에서 온 data인 경우, Google’s Terms of Service from 2005, and/or 2007, and/or 2012 등 중 어느 라이선스가 적용될지 확인한다.
(Sub-step 4) Data Source에 대한 라이선스를 식별한다.
- Dataset 생성에 기여한 모든 Data Source와 관련된 라이선스를 식별한다.

여기까지가 Phase 1인데, 공개 Dataset을 사용하려는 AI engineer가 확인해야 할 내용이 적지 않습니다. 더 큰 문제는 아무리 노력을 기울인다고 해도 웹사이트에서 라이선스 정보를 제공하지 않거나, 틀린 정보를 제공한다면 AI engineer가 확인할 수 있는 범위는 제한적일 수 밖에 없을 것입니다. 아뭏든, 논문 내용을 더 살펴보겠습니다. 다음은, Phase 2이며, 변호사 등 법률전문가에 의해 라이선스의 권리와 의무를 확인하는 단계입니다.

Phase 2 : License compliance assessment

(Step 1) License interpretation

여기서는 법률전문가가 Dataset과 data의 라이선스를 보고 권리 및 의무를 추출한다.

추출된 권리와 의무를 표준 형식으로 문서화한다.
Montreal Data License (MDL) 형식을 보완하여 사용할 것을 제안한다. → Enhanced MDL
여기에는 다음 내용을 기록할 수 있다.
1. License metadata
  - Licensor
  - License name
  - Dataset name
  - Dataset version
  - Credic / Attribution Notice
  - License validity period
  - Liability / Warranty
  - Designated third parties
  - Additional condition
2. Data (standalone)
  - Rights / Obligations
    - Access
    - Tagging
    - Distribute
    - Re-represent
3. Data rights in conjunction with model
  - Rights / Obligations
    - Benchmark
    - Research
    - Publish
    - Internal Use
    - Commercialization
      - Output
      - Model
    - Model Reverse Engineer

(Step 2) License compatibility analysis

법률전문가는 Enhanced MDL의 정보를 기반으로 위험 평가를 수행하여 dataset을 상업적으로 사용할 수 있는지 결정한다.

Dataset 라이선스가 허용하더라도 Data Source의 라이선스가 사용 사례를 제한하는 경우에 유의한다.
예를 들어, CIFAR-10의 경우 Dataset 라이선스가 허용하는 것과 Data Source 라이선스가 허용하는 것이 서로 다른 경우가 있다.
위의 Table에서 빨간색(x)는 Data Source의 라이선스가 제한한다는 것이다. (Google 및 Flickr의 라이선스 등)

요약하자면 CIFAR-10의 라이선스는 논문이 인용되는 한 dataset에 대한 모든 권리를 허용하지만, Data Source의 라이선스는 더 제한적이므로, 이 Dataset을 AI Model을 학습시키거나 또는 Dataset 자체를 수정 또는 배포를 포함한 상업적 목적으로 사용될 경우 라이선스 컴플라이언스 위반의 잠재적 위험이 발생한다.

여기까지 Phase 2를 거치면서 법률 전문가에 의해 Enhanced MDL 포맷으로 라이선스 권리와 의무를 문서화하고 이를 활용하는 방법을 살펴 보았습니다. Dataset 뿐만 아니라 Data Source의 라이선스까지 확인해서 Data Source의 라이선스가 상업적 사용 등 제한을 가하면 Dataset을 상업용으로 사용하는 것도 리스크가 있음을 설명하고 있습니다.

논문에서는 위와 같은 방식으로 다른 Dataset에 대해서도 Case Study를 진행하였습니다. 그 내용을 살펴보겠습니다.

4. Case Study Details

Case Study에서는 인기도와 상업적으로 사용될 가능성이 높은 6개의 이미지 dataset 선택하였다.

CIFAR-10 : Alex Krizhevsky, Geoffrey Hinton, et al. 2009. Learning Multiple Layers of Features from Tiny Images. Technical Report. University of Toronto.
ImageNet : Olga Russakovsky, Jia Deng, Hao Su, Jonathan Krause, Sanjeev Satheesh, Sean Ma, Zhiheng Huang, Andrej Karpathy, Aditya Khosla, Michael Bernstein, et al. 2015. Imagenet large scale visual recognition challenge. International journal of computer vision 115 (2015), 211–252
Cityscapes : Marius Cordts, Mohamed Omran, Sebastian Ramos, Timo Scharwächter, Markus Enzweiler, Rodrigo Benenson, Uwe Franke, Stefan Roth, and Bernt Schiele. 2015. The Cityscapes Dataset. In Proceedings of the 2015 CVPR Workshop on the Future of Datasets in Vision, Boston, MA, USA, June 11.
FFHQ : Tero Karras, Samuli Laine, and Timo Aila. 2019. A style-based generator architecture for generative adversarial networks. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 4401–4410
VGGFace2 : Georgia M Kapitsaki, Frederik Kramer, and Nikolaos D Tselikas. 2017. Automating the License Compatibility Process in Open Source Software with SPDX. Journal of Systems and Software 131 (2017), 386–401.
MS COCO : Tsung-Yi Lin, Michael Maire, Serge Belongie, James Hays, Pietro Perona, Deva Ramanan, Piotr Dollár, and C Lawrence Zitnick. 2014. Microsoft coco: Common objects in context. In European conference on computer vision. Springer, 740–755.

이 여섯 개 dataset은 모두 이미지에 대한 것이며, 라이선스는 다음과 같은 특징을 갖습니다.

Dataset	Dataset license	Data Source
CIFAR-10	라이선스 언급 없음 (인용만 요구)	Data Source 다수
ImageNet	custom license	Data Source 다수
Cityscapes	custom license	하나의 Data Source
FFHQ	CC-NC-SA-4.0	Data Source 다수
VGGFaces2	CC-NC-SA-4.0	Data Source 다수
MS COCO	CC 4.0	Data Source 다수

그럼 이 논문에서 여섯 개의 dataset에 대하여 연구를 수행한 결과를 살펴보겠습니다.

이미지 Dataset의 가장 일반적인 사용 시나리오는 다음 세 가지로 볼 수 있다.

dataset 자체를 상업적으로 배포 (DD : Distribute Datasets)
dataset으로 AI Model을 학습하고, 이 모델을 포함하는 임베디드 제품 출시 (RPEAI : Release Product with Embedded AI Model)
dataset으로 AI Model을 학습하고, 이 모델 산출물을 상용화 (CAI : Commercialize the Model)

이러한 사용 시나리오에 대한 각 Dataset의 연구 결과는 다음과 같다.

A - Provide a link to license CC-BY-NC 4.0
B - Provide a link to the license CC-BY 4.0
C - Provide a link to license CC-By-NC-SA 4.0
D - Remove infringing content as soon as possible when an infringement is detected
E- Indicate changes

1. Dataset을 상용 AI software와 함께 배포하는 경우 –> 잠재적인 라이선스 컴플라이언스 위반 초래 가능 (6개 중 3개)

CIFAR-10, ImageNet 및 CityScapes의 배포는 허용되지 않음
이러한 제한에도 불구하고 많은 플랫폼에서 이들 Dataset을 배포하고 있다. (예: https://deepai.org/datasets - ImageNet, CIFAR-10 을 배포함) 이는 문제를 유발할 수 있다.
다른 3개 Dataset도 동일한 라이선스로 배포해야 해야 하는 등의 의무를 준수해야 사용할 수 있다.

2. Dataset을 상용 AI software 학습에 사용하는 경우 –> 잠재적 라이선스 컴플라이언스 위반 초래 가능 (6개 중 5개)

MS COCO를 제외하고 어느 것도 Dataset을 학습한 AI Model을 상용화할 수 있는 권리를 명시적으로 허용하지 않음
MS COCO의 경우, Dataset이 상용 AI software를 구축하는 데 사용될 때 다음 사항을 요구함
- 라이선스 링크 제공
- 제품 보증을 위해 dataset를 사용하지 말아야 함

3. 6개 중 3개는 Dataset이 수정될 경우 잠재적인 라이선스 컴플라이언스 위반 초래 가능

AI Model의 성능 향상을 위해 Dataset을 수정하거나 추가하는 경우가 많음
CIFAR-10, ImageNet 및 Cityscapes의 경우 Dataset을 수정할 경우 잠재적인 라이선스 컴플라이언스 위반이 발생할 수 있음
다른 Dataset도 라이선스가 요구하는 대로 정확한 변경 사항을 표시하는 의무를 준수해야 함

이와 같이 Publicly available datasets는 상용 AI software를 구축하는 데 적합하지 않을 수 있다.

논문에서 설명하는 위의 결과만을 보더라도 공개 Dataset을 상용 AI 서비스에 사용하는 것은 잠재적인 라이선스 컴플라이언스 위반을 초래할 가능성이 있습니다. 게다가 논문에서는 이번 연구에서 고려하지 않은 부분이 더 있다고 부연 설명합니다.

5. THREATS TO VALIDITY

External validity

이 논문에서는 라이선스 위반 측면에 대해서만 연구하였다.

Dataset을 사용하여 AI Softwae를 구축할 때에는 개인 정보 보호, 윤리적 문제와 같은 요소도 중요하다.
Dataset을 내부 연구, 학문적 목적으로 사용하는 경우도 다루지 않았다.
Fair Use, fair dealing, 기타 유사한 법률에 따라 사용할 수 있는지도 다루지 않았다.
이 연구에서는 이미지 Dataset에 대해서만 다루었다. video, text 등 다른 Dataset에서는 또 다른 문제가 제기될 수 있기에 추가 연구가 필요하다.

Internal validity

이 연구에서는 Data Source의 라이선스까지만 고려하고, 개별 data point (예: 개별 이미지)와 관련된 라이선스는 고려하지 않았다.

개별 이미지에도 저작권이 있을 수 있다.
하지만, 각 Data Source에는 수천, 수만 개의 data point가 있는데, 이에 대한 각 라이선스를 추출하는 것은 사실상 불가능하다.
따라서, 이 부분은 여전히 위협으로 남아 있다.

Construct validity

이 연구에서 확인한 각 Dataset에 대한 provenance나 lineage가 정확하지 않을 수 있다.

Dataset이 언제, 어디에서 생성되었는지를 정확히 확인하는 것은 불가능하다.
ImageNet과 같은 경우, 정확한 Data Source를 알 수도 없다.
가능한 관련 문서를 통해 Data Source를 유추하여 라이선스를 유추할 수 있도록 최선을 다할 뿐이다.

이럻게 위에서 설명한 data point의 라이선스나 정확하지 않은 정보로 라이선스를 확인할 수 없는 어려움까지 고려한다면 공개 Dataset을 상용 AI 서비스에 라이선스 리스크 없이 사용하는 것은 정말 거의 불가능하다고 봐야 하는 것 아닌가 싶습니다. 그렇다고 AI 제품을 연구하는 데 공개 Dataset을 아예 배제할 수도 없습니다. GitHub가 저작권 침해 이슈가 있음에도 불구하고 Copilot 서비스를 준비하는 것은 일정 부분 법적 리스크를 감수하고, 필요에 따라 법정 다툼도 이어가는 것과 같이 기업이 AI 기술 활용을 위해 어느정도의 잠재적인 저작권 침해 리스크는 부담하는 것도 고려할 필요가 있어 보입니다. 사실, Dataset을 Machine Learning 학습에만 사용하는 것은 저작권 침해에 해당하지 않는다는 견해도 있습니다.

저작권법 제35조의 2에 따르면 ‘저작물을 그 컴퓨터에 일시적으로 복제할 수 있다’고 허용합니다. 이에 따라 Machine Learning training 과정에서 공개 Dataset을 메모리에 일시적으로 복제하는 것도 허용된다고 주장할 여지가 있습니다.
저작권법 제35조의3에서는 저작물의 통상적인 이용 방법과 충돌하지 아니하고 저작자의 정당한 이익을 부당하게 해치지 아니하는 경우 공정 이용에 해당하여 저작물을 이용할 수 있다고 허용합니다. 이미지 정보로 구성된 공개 Dataset을 Machine Learning 학습에만 사용하는 것은 그림이나 사진의 통상적인 이용 방법과 충돌하지 않고, 저작자의 이익을 해치지 않기 때문에 공정이용에 해당한다고 주장할 수 있을 것입니다.

다만, 아직 이에 대한 명확한 판례가 없기 때문에 리스크가 전혀 없다고 할 수는 없습니다. (아참, 저는 법률가가 아니기 때문에 이 내용은 법적인 효력이 전혀 없음을 알려 드립니다. ^^)

유럽, 일본, 미국 등 해외에서는 AI 학습을 위한 빅데이터 이용을 허용하기 위해 법 개정이 되었으며, 우리나라도 이를 위한 저작권법 개정안이 국회에 상정된 것으로 알고 있습니다. 국내 기업들이 공개 Dataset을 보다 수월하게 사용하여 AI 기술 혁신에 박차를 가할 수 있도록 정부에서도 필요한 법안을 신속히 처리해주면 좋겠습니다.

감사합니다.

SaaS로 서비스를 제공할 때에도 오픈소스 컴플라이언스가 필요한가요?

Open Source Compliance for SaaS Vendors

By 장학성 | 2021년 12일 20월

대부분의 오픈소스 라이선스는 오픈소스를 실행시키는 것에는 아무 제한을 두지 않으며, 오픈소스를 재배포할 때 소스 코드 공개, 고지 등의 의무 준수를 요구합니다. 여기서 배포라고 하면, 소프트웨어를 탑재한 임베디드 디바이스의 판매, 앱 마켓을 통한 모바일 앱의 배포 등 일반적으로 소프트웨어의 물리적인 전달을 의미합니다.

SaaS 서비스 제공 업체는 서비스를 위해 소프트웨어를 배포하지 않기 때문에 오픈소스를 사용하더라도 라이선스 의무에서 비교적 자유로울 수 있습니다. 하지만, AGPL 등 네트워크를 통한 서비스 제공 시에도 라이선스 의무를 준수하는 오픈소스 라이선스도 있기 때문에 이에 대해서는 주의가 필요합니다.

미국의 저명한 오픈소스 전문 변호사인 Heather Meeker는 Open Source Compliance for SaaS Vendors라는 글을 게재하여 SaaS 공급업체가 주의해야 할 Open Source Compliance에 대해 설명하였는데요, 오늘은 이 내용을 소개하겠습니다.

1. Client Side로 배포되는 소프트웨어를 고려하라.

Heather는 먼저 Client Side Software에 대해 언급하였습니다. SaaS Platform에서는 대부분의 소프트웨어가 공급업체의 Server-side에 존재하지만, 일부 소프트웨어는 사용자의 컴퓨터(“Client-Side”)로 전달이 되어 동작하게 됩니다.

Heather는 SaaS 형태로 웹사이트 제작 기능을 제공하는 워드프레스를 예로 들어 설명하였습니다. Chrome 브라우저로 워드프레스에 접속하여 블로그를 제작하는 화면을 가정하겠습니다. 거기에서 control-u(맥북 환경에서는 Command + Option + U)를 누르면 page source code를 볼 수 있는데, 3천 라인 가량의 소스 코드가 있는 것을 볼 수 있습니다(물론 블로그 작성 기능을 구성하는 대부분의 소스 코드는 WordPress.com 측 서버에서 구동됩니다).

이러한 Client-side의 코드는 주로 웹페이지 내 입력 ‘form’에 날짜나 주소 등의 값이 유효한지 여부를 체크하는 등 단순한 로직 정도입니다. 이런 small task는 굳이 서버와 연동하느라 시간을 소요할 필요가 없습니다. 이런 Client-side의 코드는 주로 “scripting language” 코드이며, 대개 HTML, Javascript, CSS 입니다. 여기서 주목할 점은 이런 스크립트 코드는 브라우저에서 볼 수 있듯이 항상 소스 코드 형태로 전달이 된다는 겁니다. 그래서, LGPL 같은 Copyleft 라이선스가 적용된 코드라고 하더라도 별도로 소스 코드를 제공해야할 필요가 없습니다.

고지 내용 제공은 어떻게?

Heather는 그래도 고지 의무는 고려해야 한다고 설명하면서 한가지 문제를 제기합니다. 개발자들은 오픈소스인 HTML/CSS/Javascript를 사용할때 로딩 속도를 빠르게 하기 위하여 최소한의 코드만 남기기를 원하고, 이 때문에 코드 내 저작권, 라이선스 표시 부분을 지우는 경우가 많다는 겁니다. 그런데, LGPL과 같은 Copyleft가 적용된 소프트웨어를 배포할 때에는 소스 코드를 제공해야 할 뿐만 아니라 라이선스 전문도 함께 제공해야 합니다.

LGPL-2.1
… and distribute a copy of this License along with the Library.

그럼 LGPL인 Javascript 코드를 Client-side로 전달하면서 어떻게 LGPL 라이선스 전문을 전달해야 할까요?

Heather가 제안한 한가지 방법으로는 SaaS 시스템의 대시보드와 같은 화면 내 오픈소스 고지를 위한 페이지를 만들고 여기에 라이선스 전문을 보여주는 링크를 포함하는 것입니다.

하지만 Heather는 이 방법도 100% 라이선스 조건을 충족한다고 볼 수 있을지에 대해서는 다소 의문을 제기합니다. 사실 대부분의 오픈소스 라이선스의 고지 의무 조항은 웹서비스가 존재하기 훨씬 전에 만들어졌고, 당시의 프로그램 전달 방식만을 고려하여 고지 내용이 설치 프로그램과 함께 전달될 것으로 가정하고 있기 때문입니다.

MIT의 경우도 다음과 같이 요구합니다.

MIT
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

이런 조항을 고려하면, SaaS 시스템 내 별도의 웹페이지에서 라이선스 고지를 하는 방법도 충분하지는 않다는 주장이 있을 수도 있습니다. 물론, 이런 방법이라도 제공하는 것이 안하는 것보다는 훨씬 낫겠지만요. 🙂

Minified Javascript는 소스 코드 공개 방법으로 적절한가?

개발자는 Client-side로 전달하는 코드의 로딩 타임을 최소화 하기 위하여 가급적 코드 사이즈를 경량화합니다. 이를 위해 Javascript 코드 내 불필요한 주석을 제거하고, “white space”도 제거하는 등 Minify 처리를 합니다.

<script id=’wp-media-utils-js-translations’>
	( function( domain, translations ) {
		var localeData = translations.locale_data[ domain ] || 
			translations.locale_data.messages;
		localeData[“”].domain = domain;
		wp.i18n.setLocaleData( localeData, domain );
	} )( “default”, { “locale_data”: { “messages”: { “”: {} } } } );
</script>

예를 들어, 위의 코드를 Minify하면 다음과 같이 변환되고, 당연히 가독성은 떨어지게 됩니다.

<scriptid=’wp-media-utils-js-translations’>(function(domain,translations){varlocaleData=translations.locale_data[domain]||translations.locale_data.messages;localeData[“”].domain=domain;wp.i18n.setLocaleData(localeData,domain);})(“default”,{“locale_data”:{“messages”:{“”:{}}}});</script>

그런데, 소스 코드 공개를 요구 하는 오픈소스 라이선스에서는 ‘소스 코드’를 수정이 용이한 형태여야 한다고 정의하고 있습니다.

GPL-2.0
3. … The source code for a work means the preferred form of the work for making modifications to it.

그렇다면, LGPL인 Javascript 코드가 Client-side로 전달되면서 Minified된다면, 이는 소스 코드 제공의 의무를 준수한 것으로 볼 수 있을까요? Minified 상태로는 사용자가 수정이 곤란하기 때문에 Unminify 상태의 가독성 좋은 코드를 별도로 제공해야 하는건 아닐까요?

이에 대해 Heather는 Minified Javascfript 코드라도 대부분의 개발 도구에서는 자동으로 white space를 삽입하는 등의 가독성을 향상시켜주는 기능을 제공하기 때문에 문제가 되지 않는다고 말하고 있습니다. 즉, Minified Javascript 코드를 전달하는 것도 GPL, LGPL에서 소스 코드의 정의로 요구하는 “the preferred form of the work for making modifications”로 볼 수 있다고 설명하였습니다.

2. 네트워크 Copyleft 라이선스를 주의하라.

Heather가 언급한 SaaS에서의 또 다른 잠재적인 이슈는 네트워크 Copyleft 라이선스입니다. AGPL 등 일부 오픈소스 라이선스는 소프트웨어의 물리적인 배포가 없더라도 네트워크를 통해 사용자와 상호 작용(interacting)할 경우 Server-side 소스 코드의 공개를 요구합니다. Heather는 이런 라이선스를 “네트워크 Copyleft 라이선스"라고 불렀는데요, 대표적인 네트워크 Copyleft 라이선스인 AGPL-3.0은 13조에서 Remote Network Interaction에 대한 의무를 아래와 같이 정의합니다.

AGPL-3.0
Remote Network Interaction; Use with the GNU General Public License.
… if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.

즉, AGPL 소프트웨어를 다음 두가지 방식으로 사용한다면, 소스 코드를 제공해야 합니다.

소프트웨어를 수정하고,
사용자가 네트워크를 통해 소프트웨어와 상호작용 (interacting)하는 방식으로 사용

그럼, 수정하지 않고 사용하는건 얼마든지 가능한 것 아니냐고 반문할 수 있는데요, 개발자가 처음 AGPL-3.0 오픈소스를 도입하는 단계에서는 수정하지 않고 사용한다고 해도, 시간이 지나면서 수정해야만 하는 경우가 발생할 수 있습니다. 하지만 시간이 지나면서 누군가 다른 개발자가 AGPL 라이선스를 고려하지 않고 기능상, 성능상, 호환성 등의 여러 이유로 수정을 가할 수 있습니다. 따라서, 누군가 AGPL-3.0 오픈소스를 수정하지 않고 사용할테니 라이선스 의무 준수가 필요 없을 것이다라고 주장한다면 당장은 그럴듯해 보이지만, 미래의 변동 가능성까지 책임 질 수는 없습니다.

참고로, Google은 “AGPL Policy”를 만들어서 Google에서는 AGPL하의 코드를 사용할 수 없음을 분명히 하였습니다.

Google’s AGPL Policy
*WARNING: Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.
The license places restrictions on software used over a network which are extremely difficult for Google to comply with. Using AGPL software requires that anything it links to must also be licensed under the AGPL. Even if you think you aren’t linking to anything important, it still presents a huge risk to Google because of how integrated much of our code is. The risks heavily outweigh the benefits.*

Google은 다음과 같은 이유료 AGPL Policy를 만들었다고 설명합니다.

AGPL은 AGPL 소프트웨어와 링크하는 모든 것도 AGPL로 라이선스를 부여할 것을 요구한다. → 바이러스 효과
이런 바이러스 효과가 발생하는 시점은 소프트웨어를 배포할 때 뿐만 아니라 사용자가 제품이나 서비스를 원격 네트워크 인터페이스를 통해 액세스 할 때도 포함한다.
Google의 핵심 제품(Search, Gmail, Map, Youtube 등)은 사용자가 원격 네트워크 인터페이스를 통해 상호작용하는 서비스이기 때문에 엔지니어가 이런 서비스를 AGPL에 의존적으로 개발할 경우 상황은 심각해진다.
이런 상황을 고려했을때 Google은 AGPL의 네트워크를 통해 사용되는 소프트웨어에 대한 요구사항을 준수하기 매우 어렵다.

이와 같이 네트워크 조항을 포함하는 라이선스는 AGPL-3.0말고도 여러 라이선스가 있다고 Heather는 설명합니다.

Server Side Public License
Open Software License
Non-Profit Open Source License
Artistic 2.0
Apple Public Source License
RealNetworks Public Source License
Reciprocal Public License
Honest Public License
Academic Free License [Note: this license is permissive. The others are copyleft.]

Heather는 대부분의 회사는 이러한 네트워크 Copyleft 라이선스를 위험도가 높은 라이선스로 분류하고 SaaS 개발에 사용하지 않는 정책을 갖고 있다고 말하였습니다.

사실, 저도 예전에는 AGPL-3.0은 수정한 경우에만 소스 공개 의무를 부여하기 때문에 수정하지 않고 사용하는건 문제가 없다고 생각했습니다. 그래서 굳이 회사에서 정책적으로 AGPL-3.0의 사용을 막을 필요까지는 없는 것 아닌가라는 입장이었습니다. 그런데, AGPL-3.0 오픈소스를 도입하는 시기에는 수정하지 않고 사용한다고 하더라도, 수년이 지나면서도 수정하지 않도록 보장할 수 있는 체계가 회사 내부에 갖춰져 있냐를 봤을때에는 수정하지 않겠다는 것을 장담할 수 없게 됩니다. 따라서, Google과 같이 기본 정책으로는 AGPL-3.0 오픈소스는 사용을 제한하는 정책을 가져가는 것이 라이선스 관리 측면에서 합리적이라고 생각합니다.

3. SaaS 코드도 언젠가는 배포해야 할 수 있음을 고려하라.

Heather는 SaaS 플랫폼의 서버 측 코드도 거의 항상 언젠가는 배포된다는 점을 고려하여 서버 측 코드에 대해서도 오픈소스 컴플라이언스를 고려해야 한다고 말합니다. SaaS 코드를 배포하게 되는 경우는 다음과 같습니다.

SaaS 담당 조직의 매각
SaaS 서버를 고객 서버로 이전
- 금융, Health 등 강력한 규제 산업의 요구 사항으로 인해 서버 이전
- 보안 이슈로 서버 이전
- 국가 간 데이터 이동으로 발생하는 개인 정보 문제 방지를 위해 서버 이전 등
내부 SaaS 도구의 제품화 등

Heather는 이러한 상황이 발생할 수 있음을 고려하여 SaaS 서비스를 개발할 때에도 향후 배포될 경우를 고려하여 GPL 또는 AGPL 오픈소스와 자체 개발 코드를 결합하는 것을 피해야 한다고 설명합니다.

과도한 정책이라도 보시는 분들도 있을 것 같지만, 충분히 고려할 만한 주장이라고 생각합니다. 특히, 근래에 들어서 주로 서버에 사용하는 오픈소스가 라이선스를 변경하고 있는 추세를 고려하면 서버용 프로그램에 대해서도 Software BOM을 파악하여 관리하는 체계를 갖추는 것은 기업에 꼭 필요한 절차가 되고 있습니다.

과거에는 기업의 오픈소스 컴플라이언스 정책에서 외부로 배포하지 않고 내부 서버에만 사용하는 오픈소스인 경우에는 오픈소스 점검 대상에서 아예 제외시키기도 하였습니다. 하지만, (1) AGPL과 같은 네트워크 Copyleft 조항이 있는 오픈소스 라이선스나 (2) 오픈소스였다가 상용 소프트웨어러 라이선스 정책을 변경하는 추세를 고려하면 Server-side의 소프트웨어에 대해서도 라이선스 컴플라이언스 측면의 관리 체계가 필요해지고 있습니다. 기업은 이를 위한 정책, 절차를 개선하고, Server-side 소프트웨어에 대한 Bill of Materials를 자동으로 생성할 수 있는 도구를 도입해야 할 것입니다.

This paper was translated by Haksung Jang from the English version available at this white paper. The original author, Heather Meeker, has not reviewed this translation.

중국 첫 GPL 소송 사례, VirtualApp

피고는 GPL 위반으로 원고에게 배상금 50만 위안 지급 선고

By 장학성 | 2021년 11일 15월

안녕하세요, 장학성입니다.
지난 2021년 9월, 중국내 최초의 GPL 관련 판결이 있었다는 중국 기사를 통해 공개되었습니다. 번역기를 활용해 이해한 내용을 정리해보았습니다.
제가 법률가도 아니고, 중국어도 모르다보니 틀린 내용이 있을 수도 있음을 감안해주시기 바랍니다. :)
오류를 발견하신 분은 언제든 알려주시면 감사하겠습니다! (haksung@sk.com)
(감수에 도움을 주신 한국저작권위원회 최진영 센터장님께 감사 드립니다. ^^)

출처 : “首例！违反 GPL 协议致侵权，被判赔偿 50 万元” - https://www.oschina.net/news/159435

요약

지난 2021년 4월, 중국에서 저작권 침해 분쟁에 대한 민사 1심 판결이 있었습니다. 피고가 원고가 GPL-3.0으로 공개한 코드를 사용하면서 GPL-3.0의 의무수항을 준수하지 않음으로써 GPL-3.0이 부여한 라이선스 권리가 종료되고, 이로 인해 침해가 구성되었다는 판결입니다. 법원은 침해 사실을 확인하고, 피고에게 500,000 RMB (약 1억 원)의 배상금을 부과하였습니다.

분쟁 주체

이 분쟁의 원고와 피고, 그리고 분쟁 대상 소프트웨어는 다음과 같습니다.

원고

피고

피고는 모두 세 곳의 회사입니다.

Fujian Fengling Chuangjing Technology Co., Ltd.
- Dim Sum Desktop 저작권 소유자
- Dim Sum Desktop 공식 웹사이트 운영
Beijing Fengling Chuangjing Technology Co., Ltd. (Fujian Fengling의 모회사)
- Dim Sum Desktop 개발사로 표시됨
Shenzhen Tencent Computer System Co., Ltd.
- “Application Bao” (Dim Sum Desktop을 다운로드, 설치 및 운영하기 위한 서비스를 제공) 운영

분쟁 대상 소프트웨어

1. VirtualApp (원고 측 소프트웨어)

원고는 가상 Android 환경을 제공하는 소프트웨어인 VirtualApp을 개발하여 배포하였습니다.

Gitee : https://gitee.com/mirrors/VirtualApp
GitHub : https://github.com/asLody/VirtualApp

http://www.downcc.com/soft/359746.html

히스토리를 조금 더 자세히 살펴 보겠습니다.

원고 회사의 설립자 중 한 명이자 VirtualApp의 Original Contributor인 Lody는 2016년 7월 7일, VirtualApp을 GitHub에 공개하였습니다.
2016년 7월 8일, LGPL-3.0을 적용하였으며,
2016년 8월 12일, GPL-3.0으로 라이선스를 변경하였습니다.
- 당시 시점의 코드를 보면, Repository 내 GPL-3.0 라이선스 사본이 포함되어 있고, README 내 License 정보도 “GPL-3.0"으로 명시하고 있음을 확인할 수 있습니다.
그런데, 2017년 1월 24일, 갑자기 “당신은 이 프로젝트를 무료로 사용할 수 있는 권한이 없다“는 안내가 추가됩니다.
- 이후, 2017년 3월부터 7월까지 이 프로젝트를 상용으로 이용하기 위해서는 상용 라이선스 취득이 필요하다는 안내가 여러 차례 추가됩니다.
- 이러한 라이선싱 정책 변화에 대해 중국 내 한 변호사는 Lody가 개발 초기에는 VirtualApp을 오픈소스 라이선스 하에 무료로 공개하였지만, 나중에 이를 이용하여 수익을 창출하려고 마음이 바뀐 것으로 추측하였습니다.
- 다만, 이렇게 GPL로 공개한 오픈소스에 조건을 추가하는건 GPL에서 허용하지 않은 방식인데요, Lody는 오픈소스 라이선스에 대하여 제대로 이해하지 못하고 있었기 때문에 GPL-3.0에 위반하는 라이선싱 정책을 시도한 것으로 보인다고 중국 변호사는 언급한 바 있습니다.
2017년 8월, Lody는 VirtualApp(원고)을 설립합니다. 본격적으로 VirtualApp으로 비즈니스를 하겠다는 거죠.
그리고, Lody는 결국, 2017년 10월 29일, GitHub에서 오픈소스 라이선스를 제거합니다.
- https://github.com/asLody/VirtualApp/commit/00f152f98a922ced0d858c31e1a9c2f0afb53ab6
2017년 11월 8일, 원고는 VirtualApp v1.0에 대한 소프트웨어 저작권을 등록하여 등록증을 취득하고, 소프트웨어 저작권의 모든 권리를 향유하려고 합니다.
2017년 12월 30일, VirtualApp을 상용으로 사용 시, 아래와 같이 반드시 상용라이선스 구매가 필요함을 알리고, 이후, 더 이상 GitHub Repo에 소스 코드를 업데이트하지 않았습니다.

"VirtualApp(중국명: Luo box)은 2017년 8월에 정식으로 설립되었습니다. 
VirtualApp을 상업적 목적으로 사용해야 하는 경우 반드시 QQ: 10890으로 
연락하여 상업용 라이선스를 구매하시기 바랍니다. 
VirtualApp의 코드를 상업적 이익, 내부 사용을 위해 자신의 코드로 사용하거나 
승인 없이 소프트웨어 시장에 업로드하는 경우 당사에서 직접 경찰에 신고(저작권 침해)
하여 귀하의 회사에 법적 소송 및 형사 책임이 발생합니다."

참고로, VirtualApp은 Lody가 주요 기여자이고, 이후 30여 명의 개발자가 추가로 기여하였습니다.

2. Dim Sum Desktop (피고 측 소프트웨어)

Dim Sum Desktop은 VirtualApp과 마찬가지로 가상 안드로이드 환경을 제공하는 소프트웨어이며, 피고 Fujian Fengling Chuangjing Technology Co., Ltd.가 개발하였습니다.

http://www.appchina.com/app/com.dianxinos.dxhome

피고는 Dim Sum Desktop을 개발하면서 GitHub에 공개된 VirtualApp의 2017년 8월 16일자 버전을 받아서 포함하였습니다. 이 버전은 GPL-3.0이 적용된 상태이면서 (앞뒤가 맞지 않지만) 상업적 사용을 금지한다는 문구도 포함하고 있습니다.

2018년 9월, 원고는 “Dim Sum Desktop v6.5.8"이 VirtualApp V1.0의 코드를 사용하고 있음을 확인하였습니다.

두 소프트웨어 간 비교 가능한 코드 421개 중 다음과 같은 유사성을 발견하였습니다.
- 308 codes - substantial similarity
- 27 codes - high similarity
- 78 codes - general similarity

청구 취지

원고는 2019년 아래와 같은 청구 취지로 소송을 제기하였습니다.

피고 Fujian Fengling Company와 피고 Beijing Fengling Company는 즉시 원고의 컴퓨터 소프트웨어 저작권 침해를 중단할 것
- 즉, 인터넷을 통한 모든 버전의 “Dim Sum Desktop” 소프트웨어 다운로드, 설치 및 운영 서비스 제공을 즉시 중단해야 함
피고 Fujian Fengling Company와 피고 Beijing Fengling Company는 원고에게 2천만 위안의 경제적 손실을 배상할 것
피고 Fujian Fengling Company와 피고 Beijing Fengling Company는 침해에 대해 원고에게 50만 위안의 합리 비용을 배상할 것 _{compensate the plaintiff for a reasonable fee of 500,000 yuan for stopping the infringement}
피고 Fujian Fengling Company와 피고 Beijing Fengling Company는 이 case에 대한 소송 비용을 부담할 것

법원 판결

2021년 4월, 법원은 이 사건이 컴퓨터 소프트웨어의 저작권 침해에 관한 분쟁이고 오픈소스와 관련된 문제라고 판결하며 다음과 같은 쟁점에 대한 의견을 제시하였습니다.

china_judegement

쟁점 1. GPL-3.0의 법적 효력 여부

법원은 GPL-3.0이 계약적 성격을 띠고 라이선스 제공자와 사용자 간의 저작권 계약으로 판단할 수 있으며 중국 ‘계약법’의 조정 범위에 해당한다고 판단하였습니다. 더불어 GPL-3.0 위반에 대한 불법 행위 책임을 아래와 같이 설명하였습니다.

GPL-3.0 위반에 대한 불법 행위 책임

저작권법은 저작권자의 배타적 권리를 보호함
- 복제, 수정, 배포 등의 권리는 저작권자에게만 있음 (저작권자 외에는 “공정 이용"의 범위 내에서만 저작물을 사용할 수 있음)
- 누구든지 허가 없이 이런 행위를 하는 것은 침해에 해당함
GPL-3.0 8. Termination
- GPL-3.0의 사용 조건을 위반하는 경우 GPL-3.0을 통해 얻은 권한은 자동으로 종료됨
- “You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License”
중국 민법 총칙 제158조
- “민사법률행위는 조건이 있을 수 있다… 해제 조건이 있는 민사법률행위는 조건이 충족되면 무효”라고 규정
오픈소스 소프트웨어의 특성상 GPL-3.0서에 명시된 사용조건(소스코드 공개, 저작권 / 수정 정보 표시 등)은 라이선스 제공자가 사용자가 이를 사용할 수 있도록 하기 위한 전제조건임
- 사용자가 사용 전제조건을 위반한 경우 라이선스 제공자와 사용자 간의 GPL-3.0 계약은 자동으로 해지
- 계약에 따른 사용자의 라이선스는 즉시 종료됨
- 이후 사용자가 수행하는 복제, 수정, 배포 등의 행위는 권리의 상실로 인한 침해에 해당함

쟁점 2. 원고가 이 소송을 제기할 권리가 있는지 여부

법원은 GitHub에서 여러 기여자가 만든 저작물에 대해 소유권의 성격(예: 단독저작물, 공동저작물, 결합저작물 등)을 명확하게 설명하지는 않았습니다. 다만, 원고가 VirtualApp에 대한 저작권 등록을 했다는 등의 이유로 원고가 저작권을 가지며, 다른 기여자의 동의 없이 소송을 제기할 권리가 있다고 판단했습니다.

코드 호스팅 웹사이트의 업로드 기록과 인증 내역에 따라 원고가 VirtualApp의 저작권 소유자임을 입증할 수 있음
원고는 소송을 제기하는데 기여자의 동의 또는 승인 없이 소송을 제기할 권리가 있음
- 원고의 주주인 Lody는 프로젝트 Owner로서 원고 주장의 근거가 되는 GitHub에 VirtualApp 초기버전의 소스 코드 중 총 31,097줄을 공개함.
- 기여자는 GPL-3.0에 따라 VirtualApp 프로젝트에 자신의 소스 코드를 업로드하고, 라이선스도 부여함.
  - 이는 자신이 기여한 기여물에 대한 라이선스를 프로젝트 소유자 및 기타 사용자에게 부여하는데 동의한 것으로 간주.
- 만약, 모든 기여자의 만장일치 동의 또는 승인이 필요하게 요구한다면 실제로 권리 보호 조치를 시작조차 못하게 될 것임. 이는 오픈소스 프로젝트의 소송 권리 보호에 도움이 디지 않을 것.
- 즉, 원고는 소송을 시작하기 위해 기여자의 동의나 승인이 필요하지 않음
GPL-3.0은 라이선스 제공자가 사용자에 대한 특허권을 주장하는 것을 제한할 뿐 라이선스 계약을 위반한 사용자에 대한 저작권 주장을 제한하지 않음
- 따라서 원고의 소송은 분쟁 해결 방식에 관한 GPL-3.0 합의를 위반하지 않았다고 볼 수 있음

다만, 법원은 원고가 VirtualApp을 Relicense할 권리가 있는지에 관해서는 판단하지 않았습니다. 또한, 다른 기여자의 기여물까지 포함하여 Relicense함으로써 GPL-3.0을 오염시킨 부분에 관해서도 판단하지 않았습니다.

쟁점 3. 피고의 행위가 원고의 저작권을 침해했는지 여부

법원은 VirtualApp의 “상용 사용 금지 문구"가 GPL-3.0 (7조 Additional Terms, 10조 Automatic Licensing of Downstream Recipients)을 위반한다고 지적하며, 여전히 GPL-3.0 라이선스가 우선한다고 판단하였습니다.

원고는 VirtualApp을 오픈소스 버전과 상용버전으로 나누고, 후속 오픈소스 버전에서 “GPL-3.0” 라이선스를 삭제함
- 이와 별도로 원고는 오픈소스 버전의 VirtualApp을 권리 근거로 주장함. 따라서, VirtualApp의 오픈소스 버전과 상용버전의 관계 및 영향을 판단할 필요는 없음
- GPL-3.0에 따르면 GPL-3.0을 따르는 이전 버전의 파일은 후속 버전에서도 여전히 GPL-3.0에 구속됨
GPL-3.0은 사용자가 상업적 사용을 수행할 수 있도록 허용하며, 라이선스 제공자가 이를 제한할 수 없음
- 따라서, 법원은 원고의 다음 주장을 지지하지 않음 : “Dim Sum Desktop을 상용화하는 것은 GPL-3.0 위반임?”
피고가 “Dim Sum Desktop” 앱(V6.5.8)이 GPL-3.0을 따라 소스 코드를 무료로 공개해야 하지만 피고 Fujian Fengling Company가 이를 이행하지 않았음
- 이에 따라 GPL-3.0 8조 및 중국 민법 일반원칙 제158조에 따라 피고 Fujian Fengling Company가 획득한 권한은 자동 종료됨
- 따라서, 피고 Fujian Fengling Company의 VirtualApp 복사, 수정 및 배포는 권리 출처 상실로 인한 침해에 해당함

다만, 법원은 GPL-3.0 8조의 “라이선스 복원 조항” (저작권자가 위반 사실을 알렸을 때 위반 통지를 받은 게 처음이고, 30일 이내에 위반 사항을 시정 시 라이선스 영구 복원)에 대한 언급은 없었습니다. 중국의 한 변호사는 “원고가 피고에게 사전에 위반 사실을 통지하였는지?”, “사전 통지 없이 그냥 바로 소송을 제기한 것은 아닌지?”, “그렇다면 아직 ‘30일 내 시정 시 라이선스 영구 회복’의 기회가 남아있는 것인지?” 등이 궁금하다고 언급하기도 하였습니다. (소송까지 가는 순간 통지한 걸로 봐야하지 않을까요?)

쟁점 4. 침해 사실 확인 시 피고의 법적 책임 범위

원고는 피고의 이익에 기반한 손해배상액 산정을 요청하였습니다. 하지만 법원은 법정손해배상금(statutory damages)에 근거하여 배상금을 정한 것으로 보입니다.

피고 Fujian Fengling Company는 “Dim Sum Desktop” 앱(V6.5.8)의 개발자, 운영 및 퍼블리셔로서 법에 따라 VirtualApp의 저작권 침해를 중지할 책임이 있음
- 피고 Fujian Fengling Company가 피고 Beijing Fengling Company의 전액 출자 자회사라는 사실에 비추어 볼 때, 두 피고가 공동으로 불법 행위 책임을 부담한다는 원고의 주장은 합법적이며 법원의 지지를 받음
피고 Tencent는 “AppBao 공식 웹사이트"에서 침해 가능성에 대한 관련 규칙과 불만 제기 채널을 마련하고 고소된 소프트웨어를 즉시 제거함
- 원고는 또한 피고 Tencent에 대해 구체적인 불만을 제기하지 않았음
- 따라서 피고 Tencent는 법적 책임을 질 필요가 없음
보상 문제
- 원고는 피고 Fujian Fengling Company와 피고 Beijing Fengling Company의 침해 이익을 기반으로 계산하였다고 주장함
- 법원은 배상액을 50만 위안으로 결정함

50만 위안은 저작권 침해 법정손해배상액의 최고액 수준이라고 합니다.

마무리

그동안 중국은 저작권법 위반에 관대하다는 인식이 많았는데, 영문을 기반으로 한 오픈소스 라이선스의 법적 효력을 인정하고, 라이선스 위반을 저작권 침해로 판결한 점이 인상적이었습니다. 기업은 오픈소스 라이선스 의무를 준수하기 위한 정책과 프로세스를 갖추어야 이러한 분쟁에 휘말리는 위험을 최소화 할 수 있을 것입니다.

피고는 사건을 대법원에 상고한 것으로 알려졌습니다. 피고가 항소심에서 어떤 주장을 펴나갈지 궁금합니다. :)

GPLv2도 설치정보를 요구한다고?

GPLv2도 설치정보를 요구하는가에 대한 저자의 분석 결과를 설명한다.

By 원문 저작자 - P. McCoy Smith, 번역 - 장학성 | 2021년 8일 1월

안녕하세요.
미국의 저명한 오픈소스 라이선스 전문 변호사인 P. McCoy Smith는 최근 JOLTS_{Journal of Open Law, Technology & Society}에 GPLv2가 ‘설치정보’를 요구하는가를 주제로 글을 게재하였습니다.
지난 2021년 3월, SFC_{Software Freedom Convervancy}의 블로그에 “Understanding Installation Requirements in GPLv2“라는 주제로 GPLv2에서도 설치 정보 제공을 요구한다는 글이 올라왔었는데, 이에 대한 분석과 GPLv3의 ‘설치 정보’ 요구 사항은 GPLv2에서는 해당하지 않는다는 의견을 자세한 근거를 들어 설명하였습니다.
여기서는 원문을 번역하되 Readability를 고려하고 독자의 이해를 돕기 위해 가능한 배경 설명을 추가하여 작성하였습니다.
혹시, 오류를 발견하였거나 추가 의견이 있으신 분들은 언제든 연락해주세요. haksung@sk.com
감사합니다. :)

This paper was translated by Haksung Jang from the English version available at this article. The original author, P. McCoy Smith, has not reviewed this translation.

Abstract

GPLv3_{GNU General Public License version 3} 에서 추가된 주요 특징 중 하나는 소프트웨어 배포 시 소스 코드뿐만 아니라 ‘설치 정보’를 제공해야 한다는 요구사항이다. 이는 GPLv2에 존재하는 loophole (Tivoization)을 해결하기 위해 GPLv3에 새롭게 추가되었다. 그런데 최근에 이 설치 정보 요구 사항이 GPLv2에서도 요구한다고 봐야한다는 주장이 제기되었다.

이 글에서는 GPLv3에 ‘설치 정보’ 요구 사항을 포함하게 된 역사적 근거를 검토하고, 이 요구 사항은 GPLv2가 아닌, GPLv3에서 새롭게 적용된 것임을 설명한다. 또한, GPLv2 텍스트 분석을 통해서도 같은 결과를 도출한다.

1. Introduction

1991년 FSF_{Free Software Foundation}에서 공개한 GPLv2_{GNU General Public License, version 2}¹은 Copyleft (혹은 Reciprocal) 라이선싱 방식을 채택하였다. Copyleft 방식은 정해진 시기에 지정된 방식대로 소스 코드를 공개하고, 소프트웨어를 재배포할 때에는 동일한 라이선스 적용을 요구한다. 이는 소프트웨어가 “free"로 유지되도록 보장하는 최고의 수단이며, 이는 오늘날에도 여전히 많은 사람에게 인정되고 있다². 여기서 “free"는 다음과 같다³.

수정 사항을 공유할 수 있는 자유
사용자가 코드로 수행할 수 있는 작업에 대한 자유
사용자가 원하는대로 코드를 수정할 수 있는 자유

그럼에도 불구하고 2005년, FSF는 GPLv2를 출시할 당시 고려하지 못한⁴ 법률적⁵ 그리고 기술적⁶ 문제를 해결하기 위해 라이선스 변경의 필요성을 인식하였다. 이에 따라 FSF는 2006년⁷부터 2007년까지 GPL의 신규 버전을 만들기 위해 대규모의 협업과 다국적 노력을 시작하였으며, 2007년 6월 29일 GPLv3를 공개하였다⁸.

2. GPLv3의 ‘설치 정보’ 요구 사항

GPLv2가 광범위하게 사용되던 15년 동안 제기된 문제와 우려를 해결하기 위해 GPLv3에는 수많은 기능이 추가되었다. 그중에서도 가장 주목할만한 (그러면서도 가장 논란이 되는⁹) 부분은 (1) ‘설치 정보’를 정의한 조항과 (2) GPLv3에 따라 라이센스가 부여된 소프트웨어를 ‘전달_convey¹⁰‘할 때 어떤 상황에서 설치 정보를 제공해야 하는지를 명시한 조항이다. GPLv3에서의 ‘설치 정보’ 요구 사항이 GPLv2에서 요구하는 요소를 어느 정도 포함하는지, 어느 것은 포함하지 않는지를 이해하려면 두 라이선스에서의 표현과 역사에 대한 자세한 검토가 필요하다.

GPLv3, Section 6¹¹(GPLv3 코드를 “Non-Source Form으로 Convey"시 의무 사항 명시)에서는 ‘설치 정보’를 위해 특별히 공개해야 할 의무를 정의한다.

“‘Installation Information’ ... means any methods, procedures, authorization keys, or other 
information required to install and execute modified versions of a covered work ... from a 
modified version of its Corresponding Source. The information must suffice to ensure that the 
continued functioning of the modified object code is in no case prevented or interfered with 
solely because modification has been made.”

GPLv3의 ‘설치 정보’ 정의에서 주목할만한 것은 ‘인증키_{authorization key}’ 및 ‘기타 정보’를 구체적으로 언급한 점이다. 이는 GPLv3를 만드는 프로세스가 시작될 당시 FSF가 우려했던 GPLv2 소프트웨어의 특정 남용 사례를 해결하기 위하여 포함된 것이다¹².

GPLv3의 ‘설치 정보’ 의무에 대한 자세한 요구 사항이나 GPLv3에서 설치 정보 제공을 요구하는 방법과 시기는 이 글의 주제를 벗어난다¹³. 그럼에도 불구하고 설치 정보 의무가 GPLv2에서도 해당한다고 주장할 수 있는 유사 부분은 무엇인지, 설치 정보 의무가 GPLv3에만 있는 고유한 부분임을 입증하는 근거는 무엇인지, 또 이런 내용이 어떤 과정을 통해 채택되었는지에 대한 일반적인 이해가 필요하다. 따라서 GPLv3에 ‘설치 정보’ 의무가 추가되었던 역사적 배경과 GPLv3에 추가된 특정 표현이 무엇인지, 해당 표현이 GPLv2에 언급된 의무들과 어떻게 다른지 이해하는 것이 중요하다.

3. ‘설치 정보’ 요구사항의 역사적 배경: ‘Tivoization’

2006년경 GPL의 새로운 버전인 GPLv3가 제안되었을 무렵, FSF는 ‘software freedom’ 개념을 잠재적으로 훼손할 수 있는 관행에 대한 우려를 나타냈었다. FSF는 이 관행을 ‘Tivoization¹⁴‘이라고 명명하였으며, 당시 FSF는 DVR_{digital video recorder} 회사인 TiVo가 사용자의 자유를 침해한다고 보았다.

https://blog.codinghorror.com/tivoization-and-the-gpl/

2000년대 중반, TiVo의 특정 DVR 하드웨어 디바이스에는 GPLv2 라이선스인 Linux 커널이 설치되어 있었다. 이 디바이스에는 TiVo 하드웨어 장치에 설치할 Linux 커널 버전을 확인하는 메커니즘이 포함되어 있었다. 이 유효성 검사 메커니즘은 체크섬 또는 암호화 해시 함수를 사용하여 장치에 설치된 커널 버전과 비교하였고, 설치하려는 버전이 특정 체크섬 또는 암호화 해시¹⁵와 일치하지 않으면 해당 버전의 Linux 커널 설치를 거부하였다. 이러한 방식으로 TiVo 디바이스는 (하드웨어 제조업체로써 내장된 체크섬 또는 해시값에 대한 필요한 정보를 가진 유일한 주체인) TiVo만 디바이스에 Linux 커널의 인증된 버전을 설치할 수 있도록 허용하였다. TiVo 디바이스 사용자(예: 디바이스를 구입한 고객)가 디바이스에 설치된 커널의 소스 코드를 가져와서 해당 커널을 수정한 후 재설치하려면 수정된 커널로는 체크섬 또는 해시가 달라지게 되므로 수정된 커널이 다시 설치 또는 실행되지 않게 되었다¹⁶.

이에 따라 FSF는 2006년, GPLv2 소프트웨어의 수정 버전을 기존 장치에 재설치할 수 없다는 것은 사용자가 소프트웨어에 대해 가져야 하는 자유를 침해하는 것으로 여겼고, 이 관행을 매우 경멸적인 용어로 설명하는 것을 주저하지 않았다.

“A tyrant is a malicious device that refuses to allow users to install a different operating system or a modified operating system. These devices have measures to block execution of anything other than the ‘approved’ system versions.”¹⁷

https://fsfe.org/activities/gplv3/brussels-rms-transcript.en.html

4. 역사적 분석: GPLv3의 ‘설치 정보’ 의무와 GPLv2와의 관계

FSF는 ‘Tivoization’의 (수정한 바이너리를 재설치할 수 없게 하는) 관행에 대해 오랫동안 반대해 왔지만, GPLv3 초안 작성 중, FSF의 회장, 수석 변호사 및 Executive Director의 성명을 통해 이러한 관행이 GPLv2에서는 허용될 수 있다는 점도 분명히 했다.

      “[T]he Tivo itself is the prototype of [T]ivoisation. The Tivo contains a small GNU/Linux operating system, thus, several programs under the GNU GPL[v2]. And, as far as I know, the Tivo company does obey GPL version 2. … [T]he trouble begins because the Tivo will not run modified versions, the Tivo contains hardware designed to detect that the software has been changed and shuts down.”¹⁸
      “TiVo is a provider of hardware and software …. Our concern with them is that they have rights as users, but they should respect the rights of the users to whom they sell. Having a personal video recorder … which won’t run software if you modify the box … is not user-respecting conduct. (TiVo) complied with GPL 2 by the skin of its teeth.”¹⁹
      “TiVoization is described by Peter Brown [Executive Director of FSF in 2006-07 during drafting of GPLv3] as circumventing GPL2 ‘in spirit, not technically.’”²⁰

이러한 차이(‘Tivoization’을 금지하는 GPLv3와 허용하는 GPLv2간의 차이)는 Linux Kernel의 저작자인 Linus Torvalds가 GPLv3으로 라이선스를 변경하지 않고 ‘GPLv2 only’로 유지하게 된 결정적인 이유였다.

https://www.youtube.com/watch?v=bV3cKq26nKQ

      “’The FSF is trying to make some things no longer permissible under the GPLv3 that the GPLv2 left open, and I just happen to think that those things were better off being left open.’”²¹
      “‘I don’t think the GPL v3 conversion is going to happen for the kernel, since I personally don’t want to convert any of my code.’ … ‘I think it’s insane to require people to make their private signing keys available, for example. I wouldn’t do it,’ [Torvalds] said.”²²
      “[If] you can not install or run your changes on somebody else’s hardware … it in no way changes the fact that you got all the source code, and you can make changes (and use their changes) to it. That requirement has always been there, even with plain GPLv2. You have the source. The difference? The hardware may only run signed kernels. The fact that the hardware is closed is a hardware license issue. Not a software license issue. I’d suggest you take it up with your hardware vendor, and quite possibly just decide to not buy the hardware. Vote with your feet. … [I]t’s important to realize that signed kernels that you can’t run in modified form under certain circumstances is not at all a bad idea in many cases.”²³

GPLv3의 ‘설치 정보’ 요구사항에 대해 Torvalds의 의견은 여러 주요 커널 개발자들에 의해 아래와 같이 공유되었다²⁴. Torvalds는 10년이 지난 후에도 일관된 입장을 유지했으며, 이는 오늘날까지 Linux Kernel이 ‘GPLv2 only’ 라이선스를 유지하고 있는 이유 중 하나이다²⁵.

“I give you source code, you give me your changes back; we’re even. … That’s my take on GPL version 2 and it’s that simple. … Version 3 extended that in ways that I personally am really uncomfortable with. Namely I give you source code, that means if you use that source code, you can’t use it on your device unless you follow my rules. And to me that’s a violation of everything version 2 stood for. And I understand why the FSF did it, because I know what the FSF wants, but to me it’s not the same license at all. So I was very upset, and made it very clear, and this was months before version 3 was actually published.”²⁶

FSF는 GPLv3를 만들고 공개하는 과정에서 GPLv2와는 달리 GPLv3에서는 ‘Tivoization’을 막을 수 있는 내용을 추가하고 있음을 분명히 하였다.

“There are several primary areas where version 3 is different from version 2. One is in regard to [T]ivoisation."²⁷
“The Tivo includes some GPL-covered software. …[Y]ou can get the source code for that, as required by the GPL … and once you get the source code, you can modify it, and there are ways to install the modified software in your Tivo and if you do that, it won’t run, period. Because, it does a check sum of the software and it verifies that it’s a version from them and if it’s your version, it won’t run at all. So this is what we are forbidding, with the text we have written for GPL version three. It says that the source code they must give you includes whatever signature keys, or codes that are necessary to make your modified version run.”²⁸

FSF는 (GPLv3이 처음 제안되었을 때부터 이 글이 발표되는 날까지 계속해서) 실제로 GPLv3에는 GPLv2에 포함된 어떤 요구 사항보다 광범위한 ‘설치 정보’ 요구 사항에 대한 정의가 있음을 분명히 하였다.

      “GPLv2 did not address the use of technical measures to take back the rights that … GPL[v2] granted, because such measures did not exist in 1991 [when GPLv2 was written], and would have been irrelevant to the forms in which software was then delivered to users. … GPLv3 must address these issues: free software is ever more widely embedded in devices that impose technical limitations on the user’s freedom to change it.”²⁹
      “Does GPLv2 have a requirement about delivering installation information?…
      “GPLv3 explicitly requires redistribution to include the full necessary ‘Installation Information.’ GPLv2 doesn’t use that term, but it does require redistribution to include scripts used to control compilation and installation of the executable with the complete and corresponding source code. This covers part, but not all, of what GPLv3 calls ‘Installation Information.’ Thus, GPLv3’s requirement about installation information is stronger.”³⁰

Richard Stallman은 소프트웨어 개발자에게 GPLv2의 기존 문제를 해결하기 위해 라이선싱 정책을 GPLv3으로 “upgrade"할 것을 호소하였고, 개발자가 GPLv3으로 전환해야 하는 첫 번째 이유로 설치 정보 요구 사항이 새롭게 도입되었음을 언급하였다.

““Keeping a program under GPLv2 won’t create problems. The reason to migrate is because of the existing problems which GPLv3 will address.
“One major danger that GPLv3 will block is tivoization. Tivoization means computers (called “appliances”) contain GPL-covered software that you can’t change, because the appliance shuts down if it detects modified software. The usual motive for tivoization is that the software has features the manufacturer thinks lots of people won’t like. The manufacturers of these computers take advantage of the freedom that free software provides, but they don’t let you do likewise.³¹

5. GPLv2의 소스 코드 공개 의무

1991년 공개된 GPLv2와 같은 Copyleft 라이선스의 가장 주목할만한 특징 중 하나는 GPLv2의 조건에 따라 라이선스가 부여된 코드를 배포_{distribute[s]}³²하는 모든 개인이나 단체는 ‘소스 코드’³³를 제공해야 하는 의무가 있다는 것이다. GPLv2의 Section 3은 GPLv2하의 코드가 object 혹은 executable code form으로 배포되는 경우 반드시 제공해야 하는 ‘소스 코드’의 구성 요소를 구체적으로 정의한다³⁴.

“The source code for a work means the preferred form of the work for making modifications to it.
For an executable work, complete source code means all the source code for all modules it 
contains, plus any associated interface definition files, plus the scripts used to control 
compilation and installation of the executable.”

소스 코드를 제공해야 하는 의무에 대한 설명은 주로 컴퓨터 프로그래밍에서의 ‘소스 코드’가 무엇인지에 대한 일반적인 상식과 연결해서 이해할 수 있다.

“Source Code: … The form in which a computer program (software) is written by the programmer. Source code is written in some formal programming language which can be compiled automatically into object code or machine code or executed by an interpreter.”³⁵

GPLv2에는 또한 라이선스의 ‘소스 코드’ 정의에 해당하는 다른 두 항목도 포함하고 있다.

‘associated interface definition files’
‘scripts used to control compilation and installation of the executable’

GPLv2의 공개 의무가 GPLv3의 공개 의무와 어떻게 다른지 이해하기 위해서는 이러한 조항의 의미를 검토하는 것이 필요하다.

6. 텍스트 분석: GPLv3의 ‘설치 정보’ 의무와 GPLv2 의 소스 코드 의무

위에서 논의한 바와 같이, executable code 배포에 대한 GPLv3의 공개 의무에는 ‘Corresponding Source’³⁶와 ‘설치 정보’³⁷가 모두 포함된다.

“[A]ll the source code needed to generate, install, and (for an executable work) run the object 
code and to modify the work, including scripts to control those activities.”

“[A]ny methods, procedures, authorization keys, or other information required to install and 
execute modified versions of a covered work ... from a modified version of its Corresponding 
Source.”

GPLv3의 원래 초안에서는 “Corresponding Source"의 정의 내에 인증키를 제공해야 하는 의무가 포함되어 있었다³⁸. 그러나 인증키와 같은 데이터를 소스 코드와 혼용하여 정의하는 것에 대한 반대 의견이 있었고, 이에 따라 FSF는 인증키 요구 사항을 다른 section으로 옮겼다.

“We have moved the technical restrictions provisions from section 1, where they formed part of the definition of Corresponding Source, to section 6, where they are presented as a condition on the right to convey object code works. Some critics of the provisions in our earlier drafts focused on what they regarded as an inappropriate equation of cryptographic keys with source code. Placing the requirements in section 6 should make their purpose and reasonableness more evident.”³⁹

따라서, GPLv3의 초안 변경 단계에서 FSF는 ‘설치 정보’ 요구 사항이 GPLv2에 존재하다가 GPLv3에도 포함된 ‘Corresponding Source Code’ 의무를 넘어서는 별도의 의무임을 인식하고 인정한 것이다.

GPLv2의 소스 코드 공개 의무는 다음과 같다⁴⁰.

“For an executable work, complete source code means all the source code for all modules it 
contains, plus any associated interface definition files, plus the scripts used to control 
compilation and installation of the executable.”

GPLv2의 ‘corresponding source code’ 요구 사항 내에서 GPLv3의 ‘설치 정보’ 요구 사항과 유사한 부분이 있다면, 이는 별도로 명시된 아래의 두 가지 항목에 대한 것이다.

‘any associated interface definition files’
‘scripts used to control compilation and installation of the executables.’

‘interface definition file’은 컴퓨터 프로그래밍에서 흔하게 사용되는 용어이다(GPLv2에서는 이 용어에 대한 더 자세한 정의가 없다). 특정 소프트웨어의 프로그래밍 인터페이스에 대한 attribute와 definition을 포함하는 별도의 파일로 해석할 수 있다⁴¹. GPLv2의 이러한 요구 사항이 수정된 바이너리의 설치 또는 실행을 허용하는데 필요한 인증키나 체크섬 또는 기타 정보를 제공해야 하는 의무를 부과하는 것으로 보이지는 않는다. 대신, 배포한 바이너리에 대한 인터페이스를 이해하는데 필요한 정보를 공개할 것을 요구하는 것이다(이는 공개된 소스 코드만으로는 알아내기 어렵기 때문).

반면에, 두 번째 항목인 executable을 컴파일하고 설치하는데 사용되는 script는 분명 GPLv2 대상 executable의 설치와 관련된 자료이다. 다만, 이 요구 사항은 컴퓨팅에서 일반적으로 의미하는 ‘script’ 자체에 대한 것이다.

“A computer script is a list of commands that are executed by a certain program or scripting engine. Scripts may be used to automate processes on a local computer …. Script files are usually just text documents that contain instructions written in a certain scripting language. … [W]hen opened by the appropriate scripting engine, the commands within the script are executed.”⁴²
“Script[:] … a sequence of instructions or commands for a computer to execute … especially … one that automates a small task (such as assembling or sorting a set of data).”⁴³

Installation script⁴⁴는 일반적으로 특정 장치에 특정 프로그램을 설치하는 프로세스를 자동화하는데 사용하는 작고 간단한 프로그램이다⁴⁵.

따라서, 텍스트 해석의 관점에서, GPLv2의 ‘scripts used to control … installation of the executable’ 제공 의무가 GPLv2 executable code를 설치하는데 필요한 체크섬, 해시, 승인/서명키, 또는 기타 숫자 데이터를 포함하여 제공하는 것으로 해석될 수 없다는 것은 의심의 여지가 없어 보인다. 이러한 데이터는 ‘script’에 대한 일반적인 범위에 속하지 않는다.

차라리 이보다 흥미로운 해석상의 문제라고 한다면, 어떤 형태로든 executable의 유효성 검증을 위한 설치 프로그램을 실행하는 펌웨어가 하드웨어 디바이스 자체에 포함된 경우이다(예를 들어, executable에 수정을 가했을 경우, 유효하지 않은 것으로 판단하여 설치를 제한시키는 기능). 하지만 이런 경우라고 하더라도 GPLv3의 초안 작성 및 공개 과정 동안 FSF와 Linux Kernel 개발자 모두가 오랜 기간 동안 일관되게 GPLv2하에서는 (TiVo와 같이 PROM-loaded information을 사용한 경우 등) 어떠한 설치 유효성 검사도 허용된다는 입장을 고수했음을 고려하면, 펌웨어에서 즉시 검사하는 기능이 있더라도 이것이 GPLv2의 ‘scripts used to … installation of the executable’ 요건에 의해 설치 정보를 제공해야 한다고 주장하기는 어려울 것이다.

7. 설치 정보 요구 사항을 GPLv2로 Backporting

어떤이는 GPLv3의 전체 ‘설치 정보’ 정의 부분을 GPLv2의 소스 코드 의무 부분 내에 backporting하려고 하기도 하는데, 이런 노력은 역사적, 텍스트 해석적으로 잘못된 결과를 초래한다. 완전한 전체 ‘설치 정보’ 정의를 GPLv2의 Section 3에 포함했다고 가정해보자. 그런데 그렇게 하는 순간 딜레마에 빠지게 된다. GPLv3의 ‘설치 정보’ 요구 사항은 의무가 적용되는 대상이 특정 제품으로 한정되어 있다. 바로 ‘User Product’⁴⁶이다. GPLv3에서의 ‘설치 정보’ 제공 요구 사항은 오직 ‘User Product’에만 적용되며 다른 제품에는 적용되지 않는다⁴⁷.

“If you convey an object code work under this section in, or with, or specifically for use in, 
a User Product ... the Corresponding Source conveyed under this section must be accompanied by the 
Installation Information.”

반면에 GPLv2에는 소스 코드 의무가 적용되는 제품 유형에 대한 정의나 제한이 없다. ‘User Product’이든지 아니든지 모두 GPLv2의 의무에 따라 소스 코드를 제공해야 한다. 따라서, GPLv3의 완전한 ‘설치 정보’ 의무 정의가 GPLv2의 기존 공개 의무를 되풀이하거나 명확히 하는 것에 불과했다면 GPLv3은 이러한 공개 의무가 존재할 수 있는 상황을 줄여버리게 된 것이다. 그렇다면 결과적으로 GPLv3은 GPLv2에 비해 더 적은 범위의 일부 소프트웨어만 적용되는 것이 때문에 ‘software freedom’ 측면에서 범위가 축소된 것이 된다. 이러한 해석은 최초 GPLv3을 만들고자 했던 목표와 정반대가 되는 것이다.

“As a free software license … this license [GPLv3] intrinsically disfavours technical attempts to restrict users freedom to copy, modify, and share copyrighted works. Each of [the licenses] provisions shall be interpreted in light of this specific declaration of the licensor’s intent. We wish courts all over the world to understand that our intent [in creating GPLv3] is to maximise freedom, not to restrict it, and that everything should be so understood when effect is given to its terms”⁴⁸

다시 말하지만, GPLv3는 ‘설치 정보’ 의무 자체가 GPLv2의 공개 의무를 넘어 ‘freedom’을 확장하는 경우여야 원래의 취지대로 freedom을 극대화할 수 있다. 그렇지 않다면, GPLv2 의무가 오히려 특정 제품 유형에 국한되지 않기 때문에, User Product에 대해서만 의무를 부과하는 GPLv3는 ‘freedom’ 범위를 축소한 것이 된다는 해석의 딜레마에 빠지게 된다.

8. GPLv2의 텍스트 및 역사적 수정주의_Revisionism

위에서 상세히 설명한 바와 같이, 텍스트 분석과 과거 기록을 검토한 결과, GPLv3의 ‘설치 정보’ 의무는 GPLv2의 소스 코드 의무에는 존재하지 않는 것이며, 어떤 방식으로도 이를 GPLv2에 backport할 수 없음은 명확하다. 이러한 사실에도 불구하고, 최근 과거 기록을 변경하고, GPLv2의 요구 사항을 재해석하여, GPLv2의 소스 코드 의무를 GPLv3의 ‘설치 정보’ 요구 사항과 동일시하려는 노력이 있다.

“GPLv2 §3 requires that the source code include ‘meta-material’ like scripts, interface definitions, and other material that is used to ‘control compilation and installation’ of the binaries.”⁴⁹
“GPLv2 included a clear obligation to provide ‘the scripts used to control … installation’ that function for the GPLv2’d works. GPLv2 assures, to the purchaser of an embedded product, their absolute right to receive the information necessary to install a modified version of the GPLv2’d works. … The GPLv2 was designed to assure bug-fixing. Furthermore, the drafters knew that, on embedded systems and devices, you need to know how to install those fixes. Scripts can be technical [artefacts] like shell scripts, but can also be merely a recipe and/or guidance — written instructions that explain how to succeed at install.”⁵⁰

이러한 진술에서와 같이 GPLv3의 (executable을 설치하고 실행하기 위한 정보, recipe, 가이드, 설명 등) ‘설치 정보’ 요구 사항 개념을 GPLv2에 포함해서 GPLv2에서도 설치를 위한 ‘script’를 제공하게 하려는 노력이 현재 진행 중이다. 이러한 노력은 모두 GPLv2의 실제 요구 사항에 반대되는 텍스트_{conter-textual}일 뿐만 아니라 반역사적이다. 다시 말하지만 GPLv2 의 작성자는 GPLv2로는 Tivo에게 수정한 executable을 Tivo 디바이스에 다시 설치하기 위한 필요 정보의 제공을 의무화할 수 없음을 인정하였다⁵¹.

9. Conclusion

GPLv3의 텍스트와 역사적 기록은 GPLv2에는 없는 새로운 요구 사항인 ‘설치 정보’ 제공을 추가하기 위해 GPLv3이 특별히 설계되었음을 분명히 한다.
이러한 역사적 기록은 또한 GPLv2에서는 (GPLv2 코드의 수정 버전 설치를 막을 수 있는 인증키 또는 기타 하드웨어 내장 정보와 같은) 설치 정보를 제공하지 않고 배포하는 것이 완벽하게 허용되었고, 단지 좁은 범위의 정보 (설치 script)만 요구한다는 것을 분명히 하였다.
GPLv3의 ‘설치 정보’ 요구 사항을 GPLv2로 backporting하려는 노력은 모두 반역사적이며, GPLv3이 GPLv2보다 ‘freedom’을 제한하게 하는 반 직관적인 결과를 초래한다. 이는 처음부터 결코 GPLv3을 만든 목적이 아니다.
이러한 반 직관적인 결과를 주장하는 자들은 software freedom을 사랑하는 개발자들에게 GPLv3보다 GPLv2를 선호하도록 조언했을 것이며, 이는 GPLv3을 만들고 출시하려는 모든 목적에 반대되는 결과이다.

GPLv2에 대한 반역사적이고 텍스트로 뒷받침되지 않는 해석이 어디까지나 단순한 이론적 논쟁인지, 아니면 컴플라이언스 소송의 결과로 재판소에서 최종적으로 판단을 받을 것인지는 두고 봐야 할 일이다. (위에서 자세히 설명한) GPLv3 초안을 만들면서 작성된 많은 진술과 GPLv2의 실제 표현들이 GPLv2의 소스 코드 의무의 범위에 대한 모든 결정에 근거가 될 것이다.

About the author

P. McCoy Smith is Founding Attorney at Lex Pan Law (www.lexpan.law), a full-service intellectual property law firm in Portland, Oregon, U.S.A., that has a sub-speciality in free and open source licensing, as well as Founder at Opsequio (www.opsequ.io), an software licence compliance consultancy. As a member of GPLv3 Discussion Committee B, he was an active participant in the debate over, and revision of, the ‘Installation Information’ requirement in that licence.

Licence and Attribution

This paper was published in the Journal of Open Law, Technology, & Society, Volume 12, Issue 1 (April 2021). It originally appeared online at https://www.jolts.world

This article should be cited as follows:

Smith, P. McCoy (2021) ‘Does GPLv2 Include an “Installation Information” Obligation? A Textual & Historical Analysis’, Journal of Open Law, Technology & Society, 12(1), pp 21 – 31

DOI: 10.5033/jolts.v12i1.149ㅊㅊ

This article is licensed under a Creative Commons Attribution 4.0 CC-BY available at

https://creativecommons.org/licenses/by/4.0/

ccby

GNU Operating System, ‘GNU Library General Public License, version 2.0,’ (June, 1991) https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html (accessed March 8, 2021). ↩︎
Although GPLv3 was designed to eventually supplant GPLv2, in the 14 years since GPLv3 was published, the use of GPLv3, by some measures, is roughly equal in measure to the use of GPLv2; GPLv3’s relative use is also declining while GPLv2 remains steady state. Johnson, Patricia, ‘Open Source Licenses in 2021: Trends and Predictions,’ WhiteSource (January 28, 2021) https://resources.whitesourcesoftware.com/blog-whitesource/open-source-licenses-trends-and-predictions (accessed March 30, 2021). ↩︎
See GNU Operating System, ‘What is free software? The Free Software Definition,’ https://www.gnu.org/philosophy/free-sw.en.html (accessed March 8, 2021). ↩︎
Free Software Foundation, ‘Rationale for 1st discussion draft,’ http://gplv3.fsf.org/gpl-rationale-2006-01-16.html (accessed March 22, 2021). ↩︎
One example of a change in the law that the authors of GPLv3 felt needed to be addressed in that license was the adoption in 1996 of the WIPO Copyright Treaty (WCT), and the passage in 1998 of its counterpart in the United States, the Digital Millennium Copyright Action (DMCA), particularly the provisions against circumvention of ‘technological protection measures’, See WCT Article 11; 17 U.S.C. § 1201 (1998). GPLv3, § 3 directly addresses these additions to copyright law. ↩︎
The technology in TiVo’s devices, preventing reinstallation of modified binaries on devices running GPLv2 software, was one example of technology developed long after the GPLv2 licence was drafted that was of concern to the drafters of GPLv3. Subsequent to the release of GPLv3, millions, if not billions, of devices continue to be distributed with a GPLv2-licensed Linux kernel that prevent the reinstallation of modified binaries. GPLv3 also addressed the outmoded language around distribution of source code in GPLv2, and GPLv3 ‒ in Section 6 ‒ added several additional mechanisms for fulfilling source code obligations more consistent with current mechanisms for software distribution. See GPLv3, § 6(d)-(e). ↩︎
Irish Free Software Organization, ‘Transcript of Opening session of first international GPLv3 conference,’ (January 16th 2006) http://www.ifso.ie/documents/gplv3-launch-2006-01-16.html (accessed March 22, 2021). ↩︎
GNU Operating System, ‘GNU General Public License, version 3,’ (‘GPLv3’) (June 29, 2007) https://www.gnu.org/licenses/gpl-3.0.html (accessed March 22, 2021). ↩︎
Burnette, Ed, ‘Tivo and GPL: Beauty and the Beast?,’ ZDNet, (October 2, 2006) https://www.zdnet.com/article/tivo-and-gpl-beauty-and-the-beast/ (accessed March 29, 2021). ↩︎
‘Convey’ is the activity defined in GPLv3 as triggering source code disclosure obligations. GPLv3, n. 6, §§ 4-6. ↩︎
GPLv3, n. 6 above, § 6. ↩︎
See ‘Transcript of Opening Session of First International GPLv3 Conference,’ (January 16th 2006) http://www.ifso.ie/documents/gplv3-launch-2006-01-16.html (accessed May 5, 2021) at 0h 03m 59s ↩︎
Perhaps the most notable feature of the ‘Installation Information’ requirement, and an important feature in understanding how that requirement differs from the source code obligations in GPLv2, is that the ‘Installation Information’ requirement of GPLv3 applies only to a specified subset of products – ‘User Products’ upon which GPLv3 might be installed. See GPLv3, n. 6 above, at § 6. ↩︎
The Computer Language Company, ‘Tivoization,’ The Free Dictionary by Farlex https://encyclopedia2.thefreedictionary.com/Tivoization (accessed April 2, 2021). ↩︎
Checksums and cryptographic hashes are techniques used to determine whether a received binary file is identical to, or deviates from, an expected binary file. Various techniques are used to generate a numerical value associated with the digits in the expected file to generate a value; that value is then compared at the receiving end to a stored representation of the same value. In this way, any changes to the binary file, even so much as changing one bit from ‘0’ to ‘1’ or vice versa, will produce a different value which will not match the stored value, thus indicating at the received binary file is not identical to the expected binary file. See Fisher, T., ‘What Is a Checksum?’ Lifewire (June 14, 2021) https://www.lifewire.com/what-does-checksum-mean-2625825 (accessed June 14, 2021). ↩︎
Miller, Todd, ‘Using large disks with TiVo,’ Sudo Project (2008) https://web.archive.org/web/20120206023943/http://www.gratisoft.us/tivo/bigdisk.html (accessed April 2, 2021) (‘it is not possible to replace the kernel on a Series2 TiVo since the PROM requires that the kernel be cryptographically signed with a key from TiVo’). Note that although most of the commentary about the Series 2 TiVo devices of the mid-2000s indicate that they would not allow modified GPLv2 binaries to install or execute, at least one commentator has stated that that device allowed such binaries to be installed and run, but only prevented execution of non-GPLv2 proprietary code on that device. See Kuhn, Bradley & Webster, Behan, ‘Safely Copylefted Cars: Reexamining GPLv3 Installation Information Requirements,’ Linux Foundation Events (2017) at 13 https://events19.linuxfoundation.org/wp-content/uploads/2017/11/Safely-Copylefted-Cars-Reexamining-GPLv3-Installation-Information-Requirements-ALS-Bradley-Kuhn-Behan-Webster-1.pdf (accessed April 9, 2021) ↩︎
GNU Operating System, ‘Proprietary Tyrants,’ https://www.gnu.org/proprietary/proprietary-tyrants.html (accessed April 2, 2021). ↩︎
Stallman, Richard, ‘Transcript of Richard Stallman at the 5th international GPLv3 conference,’ (November 21, 2006) https://fsfe.org/activities/gplv3/tokyo-rms-transcript#tivoisation (accessed April 2, 2021). ↩︎
Shankland, Stephen, ‘Defender of the GPL,’ CNet (January 19, 2006) https://www.cnet.com/news/defender-of-the-gpl/ (accessed April 2, 2021). ↩︎
Byfield, Bruce, ‘GPLv2 or GPLv3?: Inside the Debate,’ Datamation (June 17, 2007) https://www.datamation.com/trends/gplv2-or-gplv3-inside-the-debate/ (accessed April 9, 2021). ↩︎
Bennett, Amy, ‘Linux creator Torvalds still no fan of GPLv3,’ Computerworld (July 28, 2006) https://www.computerworld.com/article/2820022/linux-creator-torvalds-still-no-fan-of-gplv3.html (accessed April 7, 2021). ↩︎
Shankland, Stephen, ‘Torvalds rules out GPL3 for Linux,’ ZDNet UK (January 27, 2006) https://web.archive.org/web/20080424051024/http:/news.zdnet.co.uk/software/0,1000000121,39249370,00.htm (accessed April 7, 2021). ↩︎
Barr, Joe, ‘Torvalds versus GPLv3 DRM restrictions,’ Linux.com (February 2, 2006) https://www.linux.com/news/torvalds-versus-gplv3-drm-restrictions/ (accessed April 8, 2021). ↩︎
Bottomley, James, et al., ‘Kernel developers’ position on GPLv3,’ LWN.net (September 22, 2006) https://lwn.net/Articles/200422/ (accessed April 8, 2021). See also Bottomley, James, et al., ‘The Dangers and Problems with GPLv3,’ (September 15, 2006) https://lore.kernel.org/lkml/1158941750.3445.31.camel@mulgrave.il.steeleye.com (accessed May 27, 2021). ↩︎
Linux kernel licensing notice, https://elixir.bootlin.com/linux/latest/source/COPYING (accessed April 8, 2021). ↩︎
Deb Conf, ‘Linus Torvalds says GPL v3 violates everything that GPLv2 stood for,’ YOUTUBE (accessed May 5, 2021, at 0h 0m 34s) https://www.youtube.com/watch?v=PaKIZ7gJlRU. ↩︎
Stallman, Richard, ‘Transcript of Richard Stallman at the 3rd international GPLv3 conference,’ (June 22, 2006) https://fsfe.org/activities/gplv3/barcelona-rms-transcript.en.html#tivoisation (accessed April 2, 2021). ↩︎
Stallman, Richard, ‘Transcript of Richard Stallman speaking on GPLv3 in Torino,’ (March 18, 2006) https://fsfe.org/activities/gplv3/torino-rms-transcript.en.html#drm (accessed April 2, 2021). ↩︎
Free Software Foundation, ‘Opinion on Digital Restrictions Management,’ (August, 2006) http://gplv3.fsf.org/drm-dd2.html (accessed March 17, 2021). ↩︎
GNU Project, ‘Frequently Asked Questions About the GNU Licenses,’ https://www.gnu.org/licenses/gpl-faq.html#InstInfo (accessed April 7, 2021) ↩︎
Stallman, Richard M. ‘Why Upgrade to GPL Version 3,’ (May 31, 2007) http://gplv3.fsf.org/rms-why.html (accessed May 6, 2021). ↩︎
GPLv3 uses the term ‘convey,’ n. 8 above, whereas GPLv2 uses the term ‘distribute,’ to articulate acts that trigger, among other things, obligations to provide source. Although there are subtle differences between the two terms, they are intended to cover the same acts. GNU Project, ‘Frequently Asked Questions About the GNU Licenses,’ https://www.gnu.org/licenses/gpl-faq.html#ConveyVsDistribute (accessed March 29, 2021). ↩︎
Brown, Neil, ‘GNU GPL 2.0 and 3.0: obligations to include licence text, and provide source code,’ JOLTS vol. 2, no. 1 (2010) DOI: 10.5033/ifosslr.v2i1.31 (accessed March 30, 2021). ↩︎
GPLv2, n. 1 above, § 3. ↩︎
‘Source Code,’ Computer Dictionary of Information Technology https://www.computer-dictionary-online.org/definitions-s/source-code.html (accessed March 30, 2021). ↩︎
GPLv3, n. 6 above, § 1. ↩︎
GPLv3, n. 6 above, § 6. ↩︎
Free Software Foundation, ‘GPLv3 First Discussion Draft,’ §1 (January 16, 2006) http://gplv3.fsf.org/gpl-draft-2006-01-16.html (accessed June 14, 2021). ↩︎
Free Software Foundation, ‘GPLv3 Third Discussion Draft Rationale,’ (March 28, 2007) http://gplv3.fsf.org/gpl3-dd3-rationale.pdf/download (accessed June 14, 2021). ↩︎
GPLv2, n. 1 above, § 3. ↩︎
E.g., Microsoft, ‘Interface Definition (IDL) File,’ Windows Developer Documentation (May 31, 2018) https://docs.microsoft.com/en-us/windows/win32/midl/interface-definition-idl-file (accessed April 8, 2021); de St. Germain, H. James, ‘Interfaces in Object Oriented Programming Languages,’ University of Utah Computing Department https://www.cs.utah.edu/~germain/PPS/Topics/interfaces.html (accessed April 8, 2021). ↩︎
Christensson, Per, ‘Script Definition,’” TechTerms. (2006) https://techterms.com/definition/script (accessed April 8, 2021). ↩︎
‘Script,’ Merriam-Webster.com Dictionary, Merriam-Webster https://www.merriam-webster.com/dictionary/script (accessed April 8, 2021). ↩︎
GPLv2’s requirement to provide ‘compilation’ scripts are not analysed in this article; compilation is part the process of converting source code into executable code, and is not related to the subsequent activities of installing, or executing, that executable code. ↩︎
Arthur, Ty, ‘How to Write a Simple Script to Install a Program,’ Techwalla https://www.techwalla.com/articles/how-to-write-a-simple-script-to-install-a-program (accessed April 8, 2021) ↩︎
‘User Products’ in GPLv3 are subject to a rigorous definition which excludes a large class of products which can, and currently do, use code licensed under one of the GPL family of licences: “A ‘User Product’ is either (1) a ‘consumer product’, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. … A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product.” GPLv3, n. 6 above, at Section 6. ↩︎
GPLv3, n. 6 above, at Section 6. ↩︎
Transcript of Opening Session of First International GPLv3 Conference, see n.10 above, at 0h 23m 30s. ↩︎
Kuhn, Bradley, et al., ‘Copyleft and the GNU General Public License: A Comprehensive Tutorial and Guide,’ Copyleft.org at § 5.2 (2003-2018) https://copyleft.org/guide/comprehensive-gpl-guidech6.html#x9-460005.2 (accessed April 9, 2021). ↩︎
Gingerich, Denver, ‘Understanding Installation Requirements in GPLv2,’ Software Freedom Conservancy (March 25, 2021) https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ (accessed April 9, 2021). ↩︎
See above nn. 17 and 22-23. ↩︎

Dockerfile 배포 시 컴플라이언스 책임은 누구에게?

Distribution of Dockerfiles: Who is responsible for FOSS Licence Compliance?

By Haksung Jang (@haksungjang) | 2021년 5일 4월

안녕하세요!
2021년 4월, 독일의 유명한 오픈소스 변호사인 Till Jaeger는 Dockerfile이 생성하는 Docker image내 포함될 오픈소스에 대한 라이선스 컴플라이언스 책임은 누구에게 있는가에 대한 글을 발표하였습니다. Till은 독일법과 유럽 연합 사법 재판소_CJEU의 판례를 근거로 Dockerfile 제공자가 라이선스 의무를 준수해야 한다고 설명하였습니다.
여기서는 Till의 영어 원본을 국문으로 번역하였습니다. 이해를 돕기 위해 이미지를 추가하였고, 군데군데 개인 의견을 인용구(높임말)로 작성하였습니다.
번역 오류나 문의는 이메일로 연락주시기 바랍니다. : haksung@sk.com
감수에 도움 주신 카카오의 Sean에게 깊이 감사드립니다. ^^

This paper was translated by Haksung Jang from the English version available at the Distribution of Dockerfiles. The original document is licensed under CC-BY-4.0. The original author, Till Jaeger, has not reviewed this translation.

> **개요** > > 컨테이너 기술은 Target 시스템과 관계 없이 통합 소프트웨어 배포를 가능하게 한다. 이런 장점으로 Docker를 이용하는 배포가 점점 더 인기를 얻고 있다. 그런데 이때 FOSS 라이선스 컴플라이언스에 대한 새로운 의문이 제기되었다. Docker 환경에서는 "Docker image" 형태의 전체 소프트웨어를 배포하는 것뿐만 아니라, Dockerfile만을 배포할 수도 있다. Dockerfile은 스크립트 파일과 유사한 형태로 외부 Repository로부터 소프트웨어를 다운로드받게 하는 일종의 명령만을 포함하고 있다. 이러한 분산형 배포_{decentralized distribution}의 형태는 라이선스 컴플라이언스를 누가 책임을 져야 하는지에 대한 의문을 제기하였다. 이 글에서는 프리 라이선스를 설명하기 위한 출발점으로 유럽 저작권법에 따른 "배포_distribution"의 개념을 설명한다. 연구를 통해 저작권법 의미에서의 배포가 항상 물리적인 배포여야 하는 것은 아니라는 점이 밝혀졌다. > > 이 글은 [OSADL](https://www.osadl.org/)_{Open Source Automation Development Lab}로부터 자금 지원을 받고, 공동으로 작성하였다.

1. 소개 및 문제점

Docker 기술과 관련된 FOSS 라이선스 컴플라이언스 문제는 최근 몇 년 동안 주요 연구 대상이 되었다. 특히 Docker의 기술적 토대를 설명하고 관련된 라이선스 컴플라이언스 문제를 제기한 Armijn Hemel의 백서인 “Docker Containers for Legal Professionals”¹는 광범위한 분석 내용을 제공한다. Hemel은 Dockerfile의 수신자가 이를 사용하기 위하여 제삼자로부터 소스 파일을 다운로드받게 되는데, 이때 다운받는 소프트웨어 컴포넌트에 대한 라이선스 컴플라이언스 책임은 누구에게 있는가에 대해 공개적으로 질문을 제기하였다.

대부분의 오픈소스 라이선스는 오픈소스를 “재배포"하는 시점에 준수해야 할 라이선스 의무 사항을 요구합니다. 즉, 오픈소스를 재배포하지 않는다면 라이선스 의무 준수가 요구되지 않습니다. “배포"의 범위를 어디까지로 판단해야 할지는 해당 지역에 적용되는 저작권법에 따라 해석해야 합니다.

라이선스 컴플라이언스에 대한 중요성 때문에 “배포"라는 용어는 계속해서 법적인 분석 대상이 되고 있다. Heather Meeker는 미국 저작권 관점에서 오픈소스 라이선스에서의 배포를 주제로 글을 작성하였다³. 많은 오픈소스 라이선스가 미국 저작권법을 배경으로 작성되었지만, 유럽 법원은 CJEU(유럽 연합 사법 재판소)_{Court of Justice of the European Union}에서 정교하게 설명한 “배포"에 대한 정의를 바탕으로 판결할 것으로 예상한다.

2. Docker의 기술적 배경

Docker는 컨테이너에 프로그램을 설치하고 배포하는 기술이다. 모든 Dependency가 하나의 기술 Unit에 존재하고, 호스트 시스템과 대부분 독립적이라는 장점이 있다. Hypervisor를 통한 가상화와 달리 Docker 컨테이너에는 운영 체제 커널이 포함되어 있지 않다. 대신 특정 운영 체제 명령을 사용하면 컨테이너의 파일 시스템 트리가 컨테이너의 모든 프로그램에 대한 루트 디렉터리로 표시된다. 따라서 컨테이너 외부의 나머지 파일 시스템은 컨테이너 프로그램에서 보이지 않게 된다. Docker 컨테이너에는 Unix 계열 운영 체제가 필요하며 주로 Linux 커널과 함께 사용하도록 되어 있다.

Docker image

사전에 구성된 컨테이너는 “Docker image"로 배포될 수 있으며, 기본 프로그램 외에 애플리케이션, 프로그램 코드로서의 Dependency, 필요한 경우 유틸리티 및 구성 파일도 포함할 수 있다. Docker image는 개별적으로 배포될 수 있지만 “Docker Hub"와 같은 공용 Repository를 통해서도 배포될 수 있다. 이는 C 라이브러리, Package Manager, Shell 및 디렉터리 트리와 같은 필수 시스템 구성 요소를 포함하고 특정 Linux 배포를 참조하는 이른바 “Base Image"에도 해당된다. 이 Base image 위에, 추가 기능은 개별 보관 파일로 별도로 배포될 수 있지만 서로 빌드되어 완전한 Docker image를 형성하는 이른바 “레이어"로 추가될 수 있다.

image-layer — *레이어 저장방식 : https://cultivo-hy.github.io/docker/image/usage/2019/03/14/Docker정리/*

Dockerfile

“Dockerfile"은 스크립트와 유사하게 Docker image를 만들기 위한 단계별 명령을 포함하는 텍스트 파일이다. Dockerfile은 일반적으로 Dockerfile 자체에만 적용되는 자체 라이선스를 가질 수 있으며, 이 라이선스는 Docker 컨테이너에 포함되는 프로그램에는 적용되지 않는다.

Docker 엔진

Docker 컨테이너용 관리 소프트웨어인 “Docker 엔진"은 Dockerfile의 명령을 순차적으로 처리하여 Docker image를 생성한다. 일반적으로, Base image나 개별 레이어를 위한 각 컴포넌트는 내부 또는 외부 저장소에서 다운로드된다. 이는 제공자가 Dockerfile을 제공하더라도 물리적인 프로그램 코드를 전달하지 않는 것이 가능함을 의미하고, 이런 일은 실제로 관례적이다. 고객은 전달받은 Dockerfile을 가지고 자체적으로 공개 저장소로부터 전체 혹은 일부 프로그램 코드를 받아와서 Docker 컨테이너를 구축할 수 있다.

여기서 이러한 Dockerfile을 사용하여 빌드한 Docker image에 포함된 FOSS의 라이선스 의무를 Dockerfile 제공자가 준수해야 하는지 여부와 어떤 라이선스 의무를 준수해야 하는지에 대한 의문이 제기될 수 있다.

3. 법적 배경 - EU 법률에 따른 배포 권한

거의 모든 FOSS 라이선스는 저작권법에 따라 소프트웨어를 배포_distributing 또는 전달_conveying 행위를 위한 조건으로 라이선스 의무 준수를 요구한다. 즉, 프로그램의 사본을 제삼자에게 전달할 때 라이선스 의무를 준수해야 한다. 일부 라이선스는 “배포_distribution“에 대한 정의를 라이선스 내에 포함(예: GPL-3.0은 “전달_convey“이라는 용어 정의를 포함함)하지만, 대부분의 라이선스는 이에 대해 정의하지 않고 있다. 따라서, 해당하는 저작권법이 배포를 어떻게 해석하는가를 참조하는 것이 일반적이다. 독일에서는 독일 저작권법의 §69c no 3 UrhG에서 배포를 “Verbreitung“라는 용어로 사용하여 “컴퓨터 프로그램의 원본 또는 사본을 배포하는 모든 형태(임대 포함)“라고 정의한다. 여기서 “Verbreitung“은 §17 (1) UrhG에서와 같이 컴퓨터 프로그램 말고도 일반적인 저작물을 사용할 수 있는 권리를 제공하는 것으로 이해할 수 있다.

“배포권_{right of distribution}은 저작물의 원본 또는 사본을 일반 대중에게 제안_offer하거나 유통할 수 있는 권리이다”
“The right of distribution is the right to offer the original or copies of the work to the public or to put it into circulation.”

이는 컴퓨터 프로그램의 법적 보호에 관한 유럽 의회 및 이사회의 지침 2009/24/EG 4조_{Directive 2009/24/EG of the European Parliament and of the Council}에 비추어 해석되었다⁴. 독일 및 유럽 최고 법원인 독일 연방 사법 재판소_{German Federal Court of Justice, Bundesgerichtshof (BGH)}와 유럽 연합 사법 재판소_{Court of Justice of the European Union (CJEU)}는 수많은 법원 판결에서 배포권을 해석하는 데 도움이 되는 기여를 했다. 이에 대해서는 아래에서 자세히 설명한다.

4. Dockerfile의 배포 - 분석

4.1 프로그램 코드의 물리적인 배포가 있어야만 배포인가?

아래의 첫번째 경우뿐만 아니라 두번째 경우도 “배포"에 대한 책임은 Dockerfile 제공자에게 있다.

제삼자로부터 프로그램 복사본을 취득하게 하는 기타 행위

독일과 EU의 최고 법원이 다음의 두가지를 모두 고려되어야 한다는 판결을 자주 했음을 주목하자.

물리적 행위
복제 또는 배포와 법적으로 관련된 행위를 물리적으로 수행하는 제삼자는 단순히 당사자의 “도구"로 간주됨

이러한 측면에는 특히 CJEU가 “필수적 역할_{essential role}“이라고 부르는 조직적 통제_{organizational control}를 포함한다⁵. 한가지 예는 독일 연방 사법 재판소_BGH의 “인터넷 라디오 음악 녹음 서비스” 판결이다. 이 판결은 인터넷 서비스에 의한 디지털 라디오 방송국의 완전 자동 녹음이 클라이언트의 개인 복사본인지 (허가) 혹은 서비스 제공자의 복사본인지에 (무허가) 대해 다룬다. 이에 대해 BGH는 다음과 같이 명시하였다⁶.

BGH, judgment of 2020-03-05
“이러한 맥락에서, 결정적인 요소는 제조사가 ‘복제 기기를 대신_{taking the place of the reproduction device}‘하여 상대방의 ‘필요한 도구_{necessary tool}‘로 행위하는 것에 국한되는지 (이 경우 복제는 구매자에게 귀속되어야 함) 또는 사적 이용으로 정당화될 수 없을 정도의 범위와 강도로 저작권 침해 사용을 요구하는지 (이 경우 복제는 제조사에 귀속되어야 함) 여부이다. 규범적 판단에 근거한 이번 조사에서는 녹음 과정에 대한 조직적 주도권_{organizational sovereignty}을 고객이 가졌는지 여부도 판단해야 한다.
“In this context, the decisive factor is whether the manufacturer is limited to ’taking the place of the reproduction device’ and acting as a ‘necessary tool’ of the other party - in which case the reproduction is to be attributed to the purchaser - or whether he opens up a copyright-relevant use to an extent and intensity that cannot be reconciled with the considerations that justify the privileges of private use - then the reproduction is to be attributed to the manufacturer. Within the framework of this examination, which is based on normative standards, it must also be determined whether the client has organizational sovereignty over the recording process."

인터넷 라디오 음악 녹음 서비스에 대한 세부 내용은 한국저작권위원회의 2019년 자료 독일 지방법원, 인터넷 라디오 음악 녹음 서비스(stream ripping) 제공자는 복제권과 전송권을 침해한다를 참고할 수 있습니다.
이 판결의 원고는 음반 제작자인 독일 소니 뮤직(Sony Music)이며, 피고는 인터넷 라디오에서 방송되는 음악을 녹음하여 제공하는 서비스를 운영하는 MusicMonster.FM입니다.
독일 법원은 피고의 서비스는 복제를 위한 기술적 수단을 단순히 제공하는 것을 넘어서고 사적 이용으로 정당화되는 범위를 초과하기 때문에 피고가 복제 및 공중접근의 행위자이고, 피고가 원고의 복제권과 전송권을 침해하였다고 판결하였습니다.

CJEU는 저작권 침해 행위와 관련하여 누가 “필수적 역할_{essential role}“을 하였는지에 대한 몇 가지 판단을 근거로 삼았다. 이는 특히 §17 UrhG(독일 저작권법)에서 명백하게 드러난다. UrhG는 단순한 “제안_offer” 행위, 즉 물리적 배포의 준비 행위_{preparatory act of a physical distribution}도 배포 행위_{act of distribution}라고 지정하였다⁷.

CJEU of 2015-05-13
“이러한 정황을 고려했을 때, 법원은 일반 대중에게 배포하는 것은 적어도 매매 계약 체결부터 공공의 구성원에게 전달하기까지의 일련의 행위들로 구성된다는 것을 구체적으로 발견하였다. 이러한 상황에서 판매자_trader는 배포 저작물을 (저작권으로 보호하는 회원국의) 일반 대중에게로 배포를 유발한 자신이 (또는 자신을 대신하여 누군가) 수행한 모든 행위에 대한 책임이 있다. …
이러한 일련의 행위에는 제안_offer을 하기 위한 권유 또는 해당 물건의 판매를 목적으로 취해진 보호 대상에 대한 구속력이 없는 광고도 포함한다. …
전술한 고려사항에 비추어볼 때, 언급된 질문에 대한 대답으로는 2001/29의 지침 제4조 제1항은 다음과 같은 의미로 해석해야 한다. 저작권 보유자에게 저작물 배포를 위한 독점적 권리를 허용하고, 이는 제삼자가 해당 저작물 원본 또는 사본의 판매 제안이나 광고하는 것을 방지할 수 있다. 이는 해당 저작물을 저작권으로 보호하는 회원국의 소비자를 대상으로 광고하는 한 해당 광고로 인해 EU 구매자가 보호 대상 저작물을 구매하게 되었다는 사실이 입증되지 않은 경우에도 마찬가지이다.”
“Taking that context into account, the Court specifically found that distribution to the public is characterised by a series of acts going, at the very least, from the conclusion of a contract of sale to the performance thereof by delivery to a member of the public. A trader in such circumstances bears responsibility for any act carried out by him or on his behalf giving rise to a distribution to the public in a Member State where the goods distributed are protected by copyright. … As regards an invitation to submit an offer, or a non-binding advertisement for a protected object, those also fall under the series of acts taken with the objective of making a sale of that object. … In the light of the foregoing considerations, the answer to the questions referred is that Article 4(1) of Directive 2001/29 must be interpreted as meaning that it allows a holder of an exclusive right to distribute a protected work to prevent an offer for sale or a targeted advertisement of the original or a copy of that work, even if it is not established that that advertisement gave rise to the purchase of the protected work by an EU buyer, in so far as that that advertisement invites consumers of the Member State in which that work is protected by copyright to purchase it."

CJEU의 이 판결과 다른 판결들은 기술적으로 배포하는 것뿐만 아니라, 배포를 위한 준비 행위도, 적어도 배포자가 배포 과정에서 “필수적 역할"을 하는 경우라면, 배포가 될 수 있다는 것을 보여준다. Dockerfile의 경우가 정확히 그렇다. Dockerfile은 (의도된 용도에 따라) Dockerfile의 수신자에게 완전한 기능의 시스템_{complete functioning system}을 전송하기 위해 조직된 명령을 제공하기 때문에 Dockerfile 제공자는 Docker image에 포함된 소프트웨어의 배포에 필수적인 역할을 하는 것이다. 이런 점에서, 조직적 통제권_{organizational control}을 가진 것은 Dockerfile 제공자이다. 따라서, Dockerfile 제공자는 이러한 형태로 배포되는 (Docker image에 포함될) FOSS의 라이선스 의무를 준수해야 한다.

Dockerfile의 제공자가 Dockerfile이 참조하는 소프트웨어를 배포한다는 사실이, Base image나 레이어를 다운로드할 수 있는 저장소의 운영자도 각각 프로그램 코드의 배포 행위를 수행하거나 “공개적으로 이용할 수 있게 한다"는 사실과 충돌하는건 아니다⁸. 이는 대부분의 Base image나 레이어는 특정 컨테이너를 위해서만이 아니라 일반적인 다운로드도 제공하기 때문이다. 일반적인 다운로드의 경우, 저장소 운영자가 아닌 저장소를 통해 Base image나 레이어를 제공하는 개인 또는 단체가 배포(또는 대중과의 통신) 행위를 잠재적으로 수행하는 것으로 볼 수 있다.

4.2 패치

추가 레이어를 사용하면 이미 설치된 프로그램도 수정할 수 있다. 이 경우, Docker 컨테이너는 수정되지 않은 프로그램을 한 레이어에 포함하고 수정한 프로그램을 다른 레이어에 포함하여 수정된 프로그램이 실행되도록 한다. 이러한 상황에서도 Dockerfile에는 적용될 수정사항이 정의되어 있기 때문에 Dockerfile 제공자는 “필수적 역할"의 책임을 맡아야 한다. 따라서, Dockerfile 제공자가 수정사항에 대한 라이선스 의무를 준수해야 한다.

이는 두 버전이 모두 수신자에게 배포되기 때문에 (수정된 버전만 실제 사용되더라도) 수정된 버전 뿐만 아니라 원 버전에도 적용된다는 사실에 주의해야 한다⁹. 프로그램이 새 레이어에 의해 제거되더라도 Docker image에 물리적으로 여전히 포함된 경우에도 마찬가지이다.

4.3 시스템 요구 사항 및 Base image

시스템 요구 사항

이 섹션은 오픈소스 라이선스는 오픈소스 소프트웨어를 사용하는 데 필요하지만 라이선스 범위에 포함되지 않는 독립 프로그램에 대한 사용 권한을 부여하는 데까지는 확장되지 않는다는 점에서 출발한다. 애플리케이션을 실행하는 데 필요한 운영 체제 또는 웹 서버가 대표적인 예입니다. 이와 같이 애플리케이션 실행에 필요한 독립 프로그램을 “시스템 요구 사항"이라고 하겠다. Dockerfile을 배포하는 제공자는 Docker 엔진 또는 Linux 커널과 같은 시스템 요구 사항에 대한 라이선스 의무는 준수할 책임이 없다. 이런 시스템 요구 사항은 Dockerfile에서 참조하지도 않는다.

참고로, GPL-2.0 3조에서는 다음과 같이 컴파일러, 커널 등 운영 체제의 주요 컴포넌트는 소스 코드 공개 범위에 포함되지 않는다는 예외를 두고 있습니다.
“3. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html

Base image

Base image도 시스템 요구 사항으로 간주할 수 있을까? 일반적으로 Base image에 포함되는 프로그램은 Docker 컨테이너에서 실행되는 애플리케이션과 독립적이다. Base image에 포함된 프로그램이 수정되지 않은 형태로 사용되는 한, Dockerfile에 다운로드 명령이 포함되어 있다고 해도 Dockerfile 제공자가 Base image의 제공자는 아니기 때문에 Base image는 시스템 요구 사항으로 간주할 수 있다. 또한, Repository 운영자가 액세스를 거부한다면 더 이상 다운로드가 불가능하다. 이런 사실에 비추어볼때 Base image는 Dockerfile 제공자의 통제를 벗어난다. 패치의 경우에도 비슷하지만 패치와 시스템 요구 사항은 다르게 처리해야 한다.

컴퓨터 프로그램은 일반적으로 다른 독립 프로그램과 작동한다. 이는 다른 형태의 저작물과 구별되는 특징이다. 예를 들어 대부분의 애플리케이션은 운영 체제 없이 실행되지 않는다. 하지만 이러한 애플리케이션 실행을 위해 시스템 요구 사항을 설치해야 한다고 해서 애플리케이션 제공자가 시스템 요구 사항 배포의 필수적 역할_{essential role}을 한다는 것을 의미하지는 않는다.

이런 상황은 다운로드 링크와 다소 비슷하다. 저작권이 있는 저작물을 다운로드하는 링크가 저작권법이 적용되는 관련 행위를 구성하는지, 즉 대중에게 전달하는 행위(따라서 저작권 침해를 초래할 가능성이 있음)에 해당하는지 여부에 대한 문제가 EU에서 치열하게 논의되고 있다. CJEU는 이에 대하여 일련의 복합적인 기준을 설정하였다¹⁰. 이 기준은 특히 다음과 같은 사례별 질문을 제시한다. : 새로운 구매자 그룹에 공개되어 있는지 여부, 의도된 용도가 상업적 목적인지 여부, 해당 행위가 제안에 중요한 역할을 하는지 여부, 제안이 불법인지 여부. 이렇게 사례별로 다뤄야하며 포괄적인 판단은 거의 불가능하다. 사실 회원국에서는 이러한 기준을 고려하는 경우가 흔하지 않았다. 그럼에도 이런 기준을 만든건 아마도 인터넷 저작권의 법적 상황을 더 잘 조화시키려는 CJEU의 바람 때문일 것이다.

지금까지 제시된 견해에 따르면, Base image의 Repository 운영자와 제공자는 Base image의 배포에 필수적인 역할을 하는 반면, Dockerfile이 단지 참조하는 Base image는 시스템 요구 사항을 쉽게 취득하게 하기 위한 것이다. 그러므로, Repository의 운영자가 일반 대중에게 전달하는 행위를 수행하는 것이고, Repository 운영자는, 최소한 이러한 제공이 합법적이라면, 포함된 FOSS의 라이선스 의무를 단독으로 준수해야 한다.

위에서 언급한 해석은 본 연구 저자의 법적 의견이다. 일반적으로 컴퓨터 프로그램 및 특히 Dockerfile에 대한 이러한 특정 상황에 관한 판례는 없다. 다른 해석들도 분명 논쟁의 여지가 있다(특히 Base image를 포함하는 모든 참조 레이어가 Dockerfile의 제공자에 의해 배포되는 경우).

한가지 언급해야 할 사항은 현재 수많은 Repository 운영자들이 FOSS의 라이선스 의무를 올바르게 준수하지 않고 있으며 (예: GPL 및 LGPL 구성 요소의 소스 코드를 적절하게 제공하지 않음), 이는 저작권 침해의 책임이 있다는 점이다. 이 경우, 만약 Dockerfile의 제공자가 라이선스 위반을 알고 있다면 혹은 알고 있어야 한다면, 라이선스를 위반하는 참조를 포함하는 Dockerfile을 제공하는 것은 독립적인 배포 행위로 간주되거나 최소한 기여 저작권 침해(즉, 라이선스 위반에 대한 선동 또는 방조)로 간주될 수 있다. 따라서 Dockerfile 제공자는 지정된 Repository에서 제공하는 Base image가 라이선스를 준수하는지 여부를 검토해야 한다¹¹.

Docker image를 단순히 조직 내부에만 사용하려는 수신자라면, FOSS 프로그램의 단순한 실행은 제한되지 않기 때문에, 문제없이 사용할 수 있다. 예를 들어, GPL-2.0 4조에서는 이를 명확히 말하고 있다¹². 그러나, 수신자가 Docker image를 재배포하려고 한다면, Dockerfile의 배포가 저작권을 침해하는 경우라면 배포권이 소진되는 것이 아니기 때문에, 재배포하려는 수신자는 라이선스 조건의 컴플라이언스를 보장해야 한다(아래의 4.6절 참조).

4.4 프로그램 라이브러리

프로그램과 연결된 라이브러리의 경우, 이러한 라이브러리가 독립적인 프로그램으로 간주되는지 또는 링크된 프로그램의 일부가 되는건지에 대해서는 약간의 의견 차이가 있다¹³. 이러한 맥락에서 다음과 같이 구분할 수 있다.

시스템 라이브러리
GPL 및 AGPL 애플리케이션과 연결되는 비시스템 라이브러리_{non-system library}
GPL 및 AGPL 이외의 다른 라이선스의 애플리케이션과 연결되는 비시스템 라이브러리

GPL-2.0 섹션 3 및 GPL-3.0 섹션 1 (3)에는 라이선스 의무 중 소스 코드를 제공해야 하는 범위 내에 “시스템 라이브러리"는 면제하는 조항이 포함되어 있다¹⁴. 따라서 Dockerfile이 Docker 컨테이너에서 수정되지 않은 이러한 시스템 라이브러리를 사용하라는 명령을 포함하는 경우, 이러한 시스템 라이브러리에 대한 라이선스 의무는 준수할 필요가 없다. 그러므로 이러한 시스템 라이브러리의 법적인 상황은 Base image에 적용되는 상황(위 4.3 참조)과 동일하며, 이때는 배포를 위한 필수적인 역할이 Dockerfile 제공자에게 있는 것은 아니다.

그러나 Dockerfile이 제삼자 Repository에서 (시스템 라이브러리 이외의) 라이브러리를 다운로드하고 이 라이브러리가 Docker 컨테이너 내에서 GPL-3.0 또는 AGPL-3.0 애플리케이션과 링크하는 레이어를 지정하는 경우라면, 이러한 라이브러리에 대해서는 각각 링크하는 애플리케이션의 라이선스(GPL-3.0 또는 AGPL-3.0) 의무를 준수해야 한다. 예를 들어 라이브러리의 소스 코드를 반드시 제공해야 한다 (cf. section 1 GPL-3.0: “Corresponding Source includes …, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, …”). 이는 GPL-2.0에도 동일하게 적용된다. 라이브러리의 물리적 배포의 경우와 마찬가지로 (라이선스 충돌 문제가 없다면) 해당 라이선스 조건을 준수해야 한다. 즉, 분산형 배포 프로세스_{decentralized distribution process}로 카피레프트 요구 사항을 회피할 수 없다.

Dockerfile 제공자는 프로그램 라이브러리를 Dependency로 선택하는 조직적 제어권_{organizational control}을 가졌기 때문에 Dockerfile 제공자가 프로그램 라이브러리를 배포한다고 판단할 수 있다. 따라서, 프로그램 라이브러리의 배포 프로세스에서 Dockerfile 제공자가 필수적인 역할_{essential role}을 한다.

4.5 업데이트

업데이트 처리는 Dockerfile 제공자가 업데이트를 제어하는지 여부에 따라 달라진다. Dockerfile 제공자(또는 대리인)가 직접 Repository에 업데이트를 업로드하여 Dockerfile의 수신자가 이를 받아올 수 있게 하였다면 Dockerfile 제공자가 업데이트를 배포한다고 볼 수 있다. 반면, Repository 운영자의 통제하에 업데이트가 제공된다면 (예 : Dockerfile이 “최신 버전"을 참조하는 경우) 이는 Dockerfile 제공자가 배포하는 것이 아니다. 이 경우, Dockerfile 제공자가 프로그램 버전을 선택하고 Dockerfile 내에 명명하는 것과는 대조적으로, Dockerfile 제공자는 업데이트의 내용에 관련해서 영향을 미치지 않는다.

4.6 라이선스 조건 준수 시점

라이선스 의무는 배포 (또는 대중에게 전달) 시점에 준수해야 한다. 같은 일련의 배포 단계에서 Dockerfile의 전달과 같은 준비 행위는 이미 배포로 간주 될 수 있으므로, 엄격히 말해서, Dockerfile 전달 시 라이선스 의무를 이행해야 한다. 그러나 Repository에서 다운로드 하는 시점에 라이선스 의무를 준수하는 것도 충분하다는 방식으로 오픈소스 라이선스를 해석할 수 있다. 특히 Dockerfile 배포 시, 다운로드되는 레이어에 어떤 프로그램 코드가 포함되는지 명확하지 않다는 점도 이러한 해석을 뒷받침한다. 예를 들어 프로그램 버전을 “latest"로 지정한 경우가 그렇다.

5. 결론

Dockerfile 제공자는 Dockerfile을 build/run 하는 과정에서 Docker 컨테이너에 포함되는 FOSS의 라이선스 조건에 대한 컴플라이언스 책임이 있다. Dockerfile 수신자가 외부 공개 Repository로부터 소프트웨어를 다운로드 받는 방식이라고 해도 Dockerfile 제공자의 책임을 회피할 수는 없다.
Dockerfile을 제공하는 건 준비 행위_{preparatory acts}에 해당하고, 이는 “배포"에 포함된다는 사실이 유럽 연합 사법 재판소_{Court of Justice of the European Union}의 판례에서 드러났다.
하지만, 컴퓨터 프로그램 상호 작용의 특수성을 고려하여 운영 체제, 웹서버 등 “시스템 요구 사항"에 대한 라이선스 컴플라이언스는 Dockerfile 제공자가 책임지지 않는다.
단, Docker 레이어가 FOSS 라이선스를 준수하지 않는 상태로 Repository에서 제공된다면. 이를 참조하는 Dockerfile 제공자에게도 위험을 초래한다.
따라서, FOSS 라이선스 컴플라이언스는 Dockerfile 제공자와 Docker 레이어를 공개 Repository에 공개한 배포자가 공동으로 책임져야할 사항이다.

About the author
Till Jaeger has been a partner at JBB Rechtsanwälte since 2001 (www.jbb.de). He is a Certified Copyright and Media Law Attorney and advises large and medium-sized IT businesses as well as government authorities and software developers on matters involving contracts, licensing and IP rights.
One particular focus of Till Jaeger’s work is on the legal issues created by free and open source software (FOSS). He is co-founder of the Institute for Legal Aspects of Free & Open Source Software, ifrOSS (www.ifross.org), contributing to its work with academic publications, lectures and seminars in the fields of software law and copyright law.
Till Jaeger is a lecturer at the Humboldt University Berlin in the subjects of IT law and IP law and general counsel of Open Source Automation Development Lab (OSADL) eG.
He represented the gpl-violations.org project in several lawsuits to enforce the GPL and has published articles and books related to legal questions of Free and Open Source Software (among them Jaeger/Metzger, Open Source Software - Rechtliche Rahmenbedingungen der Freien Software, 5th ed. Munich 2020, and Van den Brande/Coughlan/Jaeger - The International FOSS Law Book, 2nd ed. Munich 2014). He was member of the Committee C in the GPLv3 drafting process.

Licence and Attribution
This paper was published in the Journal of Open Law, Technology, & Society, Volume 12, Issue 1 (April 2021). It originally appeared online at http://www.jolts.world
This article should be cited as follows:
Jaeger, Till (2021) ‘Distribution of Dockerfiles: Who is responsible for FOSS License Compliance?’, Journal of Open Law, Technology, & Society, 12(1), pp 13 – 20 DOI: 10.5033/jolts.v12i1.147
Copyright © 2021 Till Jaeger
This article is licensed under a Creative Commons Attribution 4.0 CC-BY available at
https://creativecommons.org/licenses/by/4.0/

1: Hemel, Armijn, (2020), ‘Docker Containers for Legal Professionals,’ [pdf] Available at: https://www.linuxfoundation.org/wp-content/uploads/Docker-Containers-for-Legal-Professionals-Whitepaper_042420.pdf [Accessed 16 February 2021]. See also Peterson, Scott, (2020), ‘Making compliance scalable in a container world.’ Available at: https://opensource.com/article/20/7/compliance-containers [Accessed 16 February 2021]. ⏎

2: Sec. 0 GPL-3.0 provides as follows: “To ‘convey’‘ a work means any kind of propagation that enables other parties to make or receive copies.” and “To ’propagate’ a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy.”⏎

3: Meeker, Heather (2012), ‘The Gift that Keeps on Giving – Distribution and Copyleft in Open Source Software Licenses’, JOLTS, 4(1), pp 29 – 40, [DOI: 10.5033/ifosslr.v4i1.66].⏎

4: Directive 2009/24/EC on the legal protection of computer programs (codified version). Available at: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32009L0024 [Accessed 16 February 2021]. ⏎

5: See the ‘Opinion of Advocate General Saugmandsgaard Øe in the joined Cases C‑682/18 and C‑683/18 (Frank Peterson v Google LLC et al), ECLI:EU:C:2020:586. Available at: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:62018CC0682 [Accessed 16 February 2021].⏎

6: BGH (German Federal Court of Justice), judgment of 2020-03-05 - I ZR 32/19 – Internet radio recorder. Available at: https://openjur.de/u/2202077.html [Accessed 16 February 2021].⏎

7: CJEU of 2015-05-13, C-516/13 – Dimensione Direct Sales and Labianca. Available at: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:62013CJ0516&qid=1607613372933&from=EN [Accessed 16 February 2021]. ⏎

8: Please not that the “Right of communication to the public of works and right of making available to the public” in Art. 3 are independent rights from the “distribution right” in Art. 4 Directive 2001/29/EC. Available at: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32001L0029 [Accessed 16 February 2021].⏎

9: See Hemel Armijn, ibid n. 1, p. 19. ⏎

10: As the CJEU, judgment of 14 June 2017 in case C-610/15 – Stichting Brein (The Pirate Bay) itself declares: “In order to determine whether a user is making a ‘communication to the public’ within the meaning of Article 3(1) of Directive 2001/29, it is necessary to take into account several complementary criteria, which are not autonomous and are interdependent. Consequently, those criteria must be applied both individually and in their interaction with one another, since they may, in different situations, be present to widely varying degrees.” Available at: http://curia.europa.eu/juris/liste.jsf?language=en&T,F&num=c-610-15 [Accessed 16 February 2021]. ⏎

11: For efforts of Red Hat to improve the situation see Peterson, S., ibid. ⏎

12: “However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.” ⏎

13: See for more details Jaeger, Till and Metzger, Aaxel, Open Source Software, 5th edition, 2020, 64 et seq; Meeker, Heather, Open Source for Business, A practical Guide to Open Source Software Licensing, 3rd edition 2020, 119 et seq; Working Paper on the legal implication of certain forms of Software Interactions (a.k.a linking), Available at: https://www.ifosslr.org/public/LinkingDocument.odt [Accessed 16 February 2021]. ⏎

14: The definition in section 1 GPL-3.0 reads as follows: ’The “System Libraries’ of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A ‘Major Component’, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.” ⏎

OSPO란?

OSPO_{Open Source Program Office}의 정의와 가이드

By Haksung Jang (@haksungjang) | 2021년 4일 18월

This paper was translated by Haksung Jang from the English version available at the OSPO Definition. The original document is licensed under CC-BY-SA-4.0.

안녕하세요!
TODO Group은 Talk Openly, Develop Openly를 표방하며 협업을 통해 성공적인 오픈소스 프로젝트와 프로그램을 만들어가고자 하는 Linux Foundation 산하의 그룹입니다. TODO 그룹에서는 오픈소스 가이드, 도구 등을 함께 만들어서 공개하며 오픈소스에 관심 있는 누구나 활용할 수 있게 하고 있습니다.
기업 등의 조직이 오픈소스를 효과적으로 관리하고 사용하기 위해서는 OSPO_{Open Source Program Office}를 설립하여 개발자 교육, 컴플라이언스 보장, 커뮤니티 참여 및 구축, 오픈소스 공개, 코드 점검 등의 활동이 필요하다고 합니다. 이 글에서는 OSPO가 무엇이고, 어떤 역할을 하는지에 대해 TODO Group에서 정의한 글을 옮겼습니다.

OSPO의 정의
OSPO 가이드
OSPO Examples

OSPO의 정의

OSPO_{Open Source Program Office}는 조직의 오픈소스 운영을 위해 조직의 중앙에 역량을 집중하도록 설계되었다. 여기에는 오픈소스의 사용, 배포, 선택, 검사 및 관련 정책 수립뿐만 아니라 개발자 교육, 컴플라이언스 보장과 조직에 이익이 되는 커뮤니티 참여와 구축을 촉진하는 활동이 포함될 수 있다.

모든 산업에 걸쳐 적용할 수 있는 오픈소스 프로그램을 구축하기 위한 광범위한 템플릿은 없지만, 여기에서는 일반적인 OSPO의 기능을 세 가지로 분류해보았다.

법적 위험 완화_{Legal Risk Mitigation}
엔지니어 작업 방식 개선_{Improving Engineers’ Practices}
재정적 이익 실현_{Enabling Financial Benefits}

이렇게 세 가지로 분류해보니 각각 두려움_Fear, 사랑Love, 돈_Money이 연상된다.

법적 위험 완화

기업의 주된 관심사는 법적인 컴플라이언스이다. 따라서, OSPO는 기업의 오픈소스 라이선스 컴플라이언스 프로세스를 구축하고 관리한다. 일반적으로 소프트웨어를 배포하는 기업은 이 문제에 가장 관심이 많으며, 이러한 법적 위험을 완화하기 위해 OSPO의 설립을 시작한다.

OSPO는 법적 위험 관리를 위해 다음과 같은 책임을 가진다.

오픈소스 라이선스 컴플라이언스 관리 감독
인바운드 코드_{주: 오픈소스 등 외부로부터 입수한 코드} 사용을 위한 검토 프로세스 실행
오픈소스 프로젝트에 효과적으로 기여하도록 보장

엔지니어 작업 방식 개선

OSPO는 오픈소스 환경에서 코드 관리에 대한 가이드와 정책을 제공함으로써 엔지니어링 기능을 개선한다. 소프트웨어 엔지니어가 많은 기업은 OSPO를 엔지니어링 정책과 작업 방식에 집중한다.

이와 관련한 OSPO의 책임은 다음과 같다.

기업의 오픈소스 전략을 기업 내부 및 외부에 명확히 전달
조직 내 오픈소스 문화 육성
오픈소스 커뮤니티에 고품질의 코드를 자주 공개하도록 보장

재정적 이익 실현

일부 기업은 오픈소스에 관한 재정적 이익에 초점을 맞춘다. OSPO를 활용하여 상용 벤더를 사용할지 아니면 오픈소스 벤더를 사용할지에 대한 전략을 수립한다. 반면 일부 기술 기업은 자신의 OSPO (및 오픈소스 프로젝트)를 활용하여 고객이 자신의 상용 제품을 구매하도록 유도한다.

이와 관련한 OSPO의 책임은 다음과 같다.

전략 실행에 대한 오너쉽과 감독
상용 제품 및 서비스에서 오픈소스를 효과적으로 사용하도록 촉진
전략적 오픈소스 프로젝트이의 채택을 장려하기 위하여 개발자 커뮤니티와 협력

이처럼 각 OSPO는 기업 비즈니스, 제품 및 목표에 맞게 구성된다.

OSPO 가이드

TODO Group은 기업이 OSPO를 설립하고 운영하기 위한 가이드를 제공합니다.

OSPO Examples

TODO Group은 Microsoft, Faceboo, Uber 등 오픈소스를 효과적으로 활용하는 기업들이 어떻게 OSPO를 운영하고 있는지, 각 기업의 사례를 취합하여 공개하였습니다.

SK텔레콤의 OSPO에 대한 글을 소개 하며 글을 마칩니다. : SK텔레콤 OSPO
감사합니다.

Elastic License 2.0 그리고 진화하는 오픈소스 라이선스

Elastic License 2.0의 작성 배경을 설명합니다

By Haksung Jang (@haksungjang) | 2021년 3일 28월

This paper was translated by Haksung Jang from the English version available at this white paper. The original author, Heather Meeker, has not reviewed this translation.

안녕하세요.
미국의 오픈소스 전문 변호사인 Heather Meeker가 2021년 3월 11일 공개한 Elastic License에 대한 White Paper를 기반으로 아래의 글을 작성하였습니다. 대부분 원글을 번역하는 방식이며, 제 의견은 인용구로 추가하였습니다.
참고로, Heather Meeker는 이 백서를 자신의 개인적인 견해임을 나타내면서도 일부 Elastic의 자금 지원이 있었다고 밝혔습니다. 그래서인지, 원글은 Elastic License에 호의적인 입장을 보입니다.
(조금 찾아보니, Elastic License 2.0을 Heather Meeker가 작성하였군요.)
여하튼 시대가 변하며 소프트웨어 배포 방식이 바뀌는 상황에 따라 상용 오픈소스 기업들이 개발과 사업을 병행하기 위해 어떤 라이선스 모델을 도입해야 할지 고민해야 했고, Elastic License가 나온 배경에 대한 한 측면을 이해하는 데 도움이 되는 글이라 생각합니다. 글에 오류가 있다면 언제든 연락해주세요. :-)
감수에 도움 주신 카카오의 Sean, Robin 그리고 LG전자의 김경애님에게 깊은 감사 드립니다.

유닉스, 리눅스, 자유소프트웨어, 그리고 오픈소스
클라우드의 출현과 AGPL
AGPL과 듀얼 라이선스
무상 사용_Strip-mining
SSPL과 소스 공개 라이선스
- SSPL
- 제한 조건을 갖는 소스 공개 라이선스
Elastic License 2.0
왜 듀얼 라이선스를 사용하였는가?
Elastic License 2.0과 최신 라이선스 기술
더 나은 라이선스 만들기

최근, 2021년 2월, Elastic은 소프트웨어 제품에 Elastic License 2.0이라는 새로운 라이선스를 도입하였다. 이 라이선스 모델은 Elasticsearch, Kibana 등 주요 소프트웨어 제품군에 적용되었다. 이런 변화의 목적과 의미하는 바가 무엇인지 알아보자.

Elastic License 2.0은 개방형 개발 모델_{Open Development Model}로 사업하는 기업이 취할 수 있는 대표적인 라이선스 모범 사례이다. Elastic License 2.0은 오픈소스 라이선스는 아니지만, 소프트웨어의 사용, 공유 및 변경의 자유와 커뮤니티에 해를 끼는 행동 방지 간의 공정한 균형을 유지하는 데 필요한 최소한의 제한 설정을 목표로 한다.

scale

유닉스, 리눅스, 자유소프트웨어, 그리고 오픈소스

Elastic License 2.0과 같은 새로운 라이선스의 추세를 이해하려면 오픈소스 라이선스 운동이 어떻게 성장했는지 살펴보는 것이 도움이 된다.

오픈소스와 자유소프트웨어_{Free Software} 운동은 소프트웨어가 사유화되는 것에 대한 개발자의 우려에서 시작되었다. 이러한 우려의 불씨는 당시 가장 인기있는 운영체제인 유닉스였다. 유닉스의 개발사인 AT&T Bell Labs은 1956년의 동의령_{consent decree}에 따라 유닉스 및 C언어를 포함하는 연구 프로젝트로 이익 얻는 것을 금지¹ 당했으며, 이때문에 수년간 매우 관대한 조건의 라이선스로 유닉스를 배포하였다. 학계, 연구자, 개발자들은 유닉스를 수정/개선하여 공유하기 시작했고, 유닉스는 곧 운영체제 분야의 선두가 되었다. 하지만, 1983년 동의령이 해제되자 AT&T는 유닉스에 수정 사항 공유를 허용하지 않는 조항을 적용하였다. 이에 따라 각 업체별로 각자 수정한 운영체제를 사용하며 유닉스는 많은 호환되지 않는 종류로 쪼개졌고, 사용자들은 더 이상 협업할 수 없게 되었다.

유닉스가 사유화되면서 자유소프트웨어 운동, 그리고 이어서 오픈소스 운동이 생겨났으며, 이들은 인프라 소프트웨어가 폐쇄되는 상황이 다시 발생하는 것을 방지하려고 하였다. 이 운동은 유닉스를 대체하는 자유소프트웨어인 리눅스를 중심으로 이루어졌으며 곧 모든 소프트웨어는 자유_free(무료_free 맥주에서의 Free가 아니라 언론의 자유_free에서의 Free)로워야 한다는 철학에 기반한 더 큰 운동으로 발전하였다. 이러한 운동의 한 요소는 소스 코드에 대한 접근, 개선 및 변경 사항을 만들고 공유할 수 있는 권리이다. 이러한 원칙들은 GNU General Public License (GPL)에서 구현되었으며, 이에 따라 바이너리 배포자들은 해당 소스 코드를 공유해야 한다.

시간이 흐르고, 2000년대 초반 인터넷 붐에 힘입어 오픈소스 라이선스는 더욱 인기를 얻게 되었다. GPL과 같은 일부 라이선스는 복잡한 법적 우려를 불러일으키기도 했지만, 기업이 협업할 수 있는 기반을 마련하였다. 2000년 이후 오픈소스와 이를 통해 가능해진 협업은 모든 기술 부문에 채택되었다. 오늘날, 오픈소스는 전자상거래_e-commerce의 핵심 기술이며, 기업들은 소프트웨어 인프라를 위한 지속해서 협력한다.

클라우드의 출현과 AGPL

GPL과 같은 라이선스는 변경 사항의 공유를 요구한다. 바이너리 배포에 대한 소스 코드 공유 조건을 부과한다. 반면에 “개인 복사본"을 만들어서 사용하는 건 변경 사항을 공유할 필요가 없다. 이러한 조건은 당시 대부분의 소프트웨어를 직접설치_on-premise하는 방식이었기 때문에 공유를 강제하는 데 효과적이었다. 그러나 2000년대 초부터 소프트웨어는 퍼블릭 클라우드로 이동하기 시작하였고, 더 이상 소프트웨어를 배포할 필요가 없었다. 고객은 로컬 사본을 얻지 않고도 소프트웨어를 사용할 수 있게 되었다.

클라우드 서비스 사업이 커지면서, 이러한 패러다임의 변화는 오픈소스 커뮤니티의 기대치와 AWS_{Amazon Web Services}와 같은 클라우드 서비스 공급 업체 사이에 긴장감을 조성하였다. 클라우드 서비스 공급 업체는 개선 사항을 공유해야 하는 법적 의무에서 자유로웠다. 구글이 검색 서비스 강화를 위해 Linux에 의존하는 것으로 잘 알려졌기 때문에 이를 “구글 루프홀_Loophole“이라고도 불렀다. 이에 대응하기 위해 자유소프트웨어 커뮤니티는 Affero GPL (AGPL)이라는 GPL을 부분 변경한 형태의 라이선스를 만들었다. AGPL 3.0은 GPL 3.0과 거의 동일하지만 다음과 같은 원격 네트워크 상호 작용_{Remote Network Interaction} 조항을 포함한다.

[I]f you modify the Program, your modified version must prominently offer 
all users interacting with it remotely through a computer network … 
an opportunity to receive the Corresponding Source of your version by 
providing access to the Corresponding Source from a network server at no 
charge, through some standard or customary means of facilitating copying 
of software….

이 새로운 라이선스는 GPL이 리눅스 배포에 대해 했던 것처럼 클라우드 서비스 공급 업체가 소스 코드 개선 사항을 공유하도록 강제하기 위한 것이다.

AGPL과 듀얼 라이선스

AGPL은 첫 번째 릴리스부터 논란이 있었다. 2007년, GPL 3.0 초안 작성이 마무리되어 가는 과정에서 일부 작성자들은 GPL을 네트워크 카피레프트_Copyleft 모델로 변경하기를 원하였다. 하지만 커뮤니티는 GPL 3.0의 “루프홀"을 그대로 유지하기로 결정했고, 몇 달 후, 이에 대한 대안으로 AGPL을 내놓았다. 그러나 AGPL은 널리 채택되지 않았다. 매우 인기 있는 분산 데이터베이스 제품인 MongoDB가 유일무이한 AGPL의 “킬러 앱_{killer app}“이다. 기업들은 처음에는 AGPL을 이해하고 받아들이기 어려워했지만, 대부분 사용자는 소프트웨어를 변경하거나 서비스로 제공하지 않았기 때문에 AGPL하의 소프트웨어를 사용하겠다는 합리적인 결정을 내릴 수 있었다.

AGPL 3.0의 Remote Network Interaction 조항은 프로그램을 변경하였을 때에 한하여 변경 사항의 소스 코드를 컴퓨터 네트워크를 통한 원격 사용자에게 제공해야 합니다. 즉, 변경하지 않는다면 소스 코드 공개 의무가 발생하지 않습니다.

MongoDB는 “듀얼 라이선스” 비즈니스 모델로 AGPL을 사용하였다. 사용자_licensee에게 AGPL 또는 상용 소프트웨어 라이선스 중 하나를 선택하게 하였다. 사용자는 AGPL의 요구사항을 준수하고 싶지 않거나 준수하기 위한 법적인 검토조차 관여하고 싶지 않다면 상용 라이선스를 선택하였다. 이러한 듀얼 라이선스 비즈니스 모델은 원래 GPL과 상용 라이선스를 선택하게 하는 방식으로 개발되었으나 시간이 지나면서 GPL 대신 보다 카피레프트 범위를 확장한 AGPL이 사용되었다. MongoDB의 이 라이선스 모델은 상당히 성공적이었다. AGPL은 가장 강력한 카피레프트 라이선스였기 때문에 MongoDB가 상업적인 협상을 추진하는 데 유용하였다. 한편, AGPL을 만든 이들은 AGPL이 MongoDB의 사업 수단으로 사용되는 모습이 유해한 갈취_{toxic shakedown}라면서 비판하기도 하였다. 여하튼, 그렇게 강력하다고 평가 받던 AGP의 소스 코드 공유 조건도 클라우드 공급 업체가 오픈소스를 대규모로 상업적인 사용을 하면서 개발자나 커뮤니티에 아무것도 되돌려 주지 않는 행위를 막기에는 충분하지 않았다.

무상 사용_Strip-mining

클라우드 이용이 GPL 모델을 “파괴_broken“시켰던 것처럼, 2010년대 클라우드 컴퓨팅이 발전하면서 AGPL 듀얼 라이선스 모델도 압박을 받기 시작하였다. 이번에는 문제가 달랐다. GPL 또는 AGPL의 범위는 하나의 단일 실행 가능 프로그램_{single program executable}까지만 확장된다. 이 “기능"은 저작권 라이선스가 단일 저작물에 대해서만 사용 조건을 지정할 수 있다는 이론에 따라 GPL에서 의도적으로 설계된 것이었다. 즉, GPL은 파생 저작물_{derivative work}에 대한 소스 코드 공유 요건을 갖지만, 집합 저작물_{collective work}에 대해서는 아니다. 법적으로 이 둘 간의 경계는 상당히 불분명하지만 GPL이 인기를 얻으면서 단일 프로그램이란 하나의 실행 가능한 프로세스라고 정의하는 것이 일반적인 관행이 되었다. 자유소프트웨어재단_{Free Software Foundation}은 GPL FAQ에서 오랫동안 이런 원칙을 주장해왔다.

하지만 클라우드 서비스가 발전하면서 두 가지 일이 발생하였다. 첫째, 소프트웨어 엔지니어링을 클라우드 구현에 더욱 집중하게 되었다. 클라우드 공급 업체는 한때 클라우드 환경에서 실행하기 위한 소프트웨어를 개선하거나 수정해야 했던 반면, 소프트웨어 엔지니어링이 발전하면서 클라우드 공급 업체는 기존 오픈소스 소프트웨어를 “플러그 앤드 플레이_{plug and play}“형태로 사용할 수 있게 되었다. 그러다 보니 클라우드 공급 업체는 혁신의 주체를 주요 실행 파일이 아닌 곳으로 변화할 수 있었다. 그들은 소프트웨어를 관리, 모니터링 및 배포하기 위한 소프트웨어를 추가로 개발했으며, 이러한 혁신은 클라우드 서비스를 키울 수 있었다. AGPL은 클라우드 공급 업체의 이러한 개선사항에 대해서는 이를 공유하도록 강제하는 데 아무런 도움이 되지 않았다.

이렇게 오픈소스 상용 기업들은 대형 클라우드 공급 업체가 무료로 갖다 쓰기 좋은 상점처럼 되어 버렸다. 특히 “플랫폼 소프트웨어” 또는 미들웨어 (컴퓨터 스택에서 최상위 계측인 응용 프로그램과 운영 체제의 중간에 있는 소프트웨어)에서 문제는 더 심각하였다. 이 범주의 소프트웨어는 최신 컴퓨팅에 필수적이며 클라우드 구현에 매우 유용하다.

이 때문에 비즈니스 세계에서 클라우드 공급 업체의 오픈소스 사용에 대한 비판이 제기되었다. Bain Capital의 Salil Deshpande는 2018년 “분명히 이것은 불법은 아니다. 그러나 우리는 이것이 잘못되었고, 오픈소스 커뮤니티의 지속 가능성에 도움이 되지 않는다고 생각한다"라고 하였다. 또 다른 전문가는 “AWS는 오픈소스의 아킬레스건을 건드리고 있다. 다른 사람의 저작물을 무료로 가져다가 이에 대한 접근 권한을 임대하는 사업을 하는 것이다.“라고 하였다. 문제는 모든 주요 오픈소스 라이선스는 이런 방식으로 소프트웨어를 사용하는 것을 제지하지 않는다는 것이다.

주요 오픈소스 라이선스가 작성되었던 시점에는 AWS의 “Program as a Service” 형태의 프로그램이 없었으니, 이에 대한 조건도 고려하지 않았을 테지요.
오픈소스 상용 기업들은 오픈소스 프로그램을 개발해서 듀얼 라이선스 모델 (GPL or 상용)로 사업을 하고 있었는데, 클라우드 제공 업체에서 이 오픈소스 프로그램을 그대로 가져다가 클라우드 서비스로 제공하는 사업을 하고, 자기네한테는 아무런 이윤도 안겨주지 않으니, 사업 또는 개발 측면에서 모두 좋지 않은 영향을 미쳤을 것은 충분히 추측할 수 있습니다.
클라우드 공급 업체가 MongoDB를 Amazon DocumentDB나 Azure Cosmos DB로 서비스하며 고객을 확보하는게 대표적인 예라고 볼 수 있을 것 같습니다.

오픈소스 상용 기업들과 투자자들은 이런 오픈소스 모델의 한계 때문에 고민이 되었다. GPL, AGPL 등 어떤 라이선스도 저작권법을 사용하여 클라우드 공급 업체가 변경 사항을 공유하도록 강제할 수 없었다. 또한 AWS, Azure 또는 Google Cloud와 같은 대규모 고객 기반을 가진 클라우드 공급 업체는 버튼 클릭으로 소프트웨어를 쉽게 추가할 수 있게 하여 고객과 “끈끈한” 관계를 유지하였다. 일부 오픈소스 개발사는 자체 클라우드 서비스를 제공했지만, 소프트웨어를 무료로 사용하는 대형 클라우드 공급 업체와 경쟁하는 건 너무 어렵다는 걸 알게 되었다. 오픈소스 개발사의 서비스가 더 우수한 경우에도, 기존 클라우드 계정에서는 단지 “체크박스를 선택"하여 소프트웨어 제품군을 추가하는 것과는 달리, 새로운 서비스를 사용하기 위한 거래 비용_{transaction cost}이 발생한다는 점이 고객이 등을 돌리게 하였다.

SSPL과 소스 공개 라이선스

2018년 업계는 돌파구를 찾았다. AWS가 오픈소스 플랫폼 소프트웨어를 호스팅하면서 계속 인기를 얻자 오픈소스 개발사들은 행동에 나서기 시작하였다. 라이선스를 변경하였다.

오픈소스 개발사들은 두 가지 다른 경로를 통해 무상 사용 문제에 대응하였다.

매우 강한_ultra-strong 네트워크 카피레프트 라이선스
제한 조건을 갖는 소스 공개 라이선스_{Source Available Licensing}

이 두 범주 모두 이전에는 정의되지 않았던 형태이다. 둘 다 MySQL 및 MongoDB 에서와 같은 듀얼 라이선스 모델을 지원하기 위한 것이다.

SSPL

매우 강한 카피레프트 접근 방식은 2018년 SSPL_{Server Side Public License}을 만든 MongoDB에 의해 시도되었다.

1.  Offering the Program as a Service.

If you make the functionality of the Program or a modified version 
available to third parties as a service, you must make the Service 
Source Code available via network download to everyone at no charge, 
under the terms of this License. Making the functionality of the 
Program or modified version available to third parties as a service 
includes, without limitation, enabling third parties to interact 
with the functionality of the Program or modified version remotely 
through a computer network, offering a service the value of which 
entirely or primarily derives from the value of the Program or 
modified version, or offering a service that accomplishes for users 
the primary purpose of the Program or modified version.

"Service Source Code" means the Corresponding Source for the Program 
or the modified version, and the Corresponding Source for all programs 
that you use to make the Program or modified version available as a 
service, including, without limitation, management software, user 
interfaces, application program interfaces, automation software, 
monitoring software, backup software, storage software and hosting 
software, all such that a user could run an instance of the service 
using the Service Source Code you make available. [emphasis added].

이 라이선스는 무상 사용 문제에 대응하기 위한 오픈소스 솔루션을 만들기 위해 작성되었다. 소스 코드 공유 요구 사항은 AGPL의 요구 사항보다 훨씬 광범위하다. 이러한 요구 사항의 범위는 분산 소프트웨어에 대해서도 GPL 요구 사항과 유사하게 작동하도록 설계되었다. MongoDB는 SSPL 또는 상용 라이선스에 따라 소프트웨어를 사용할 수 있는 듀얼 라이선스 모델을 적용하였다.

MongoDB는 SSPL을 OSI_{Open Source Initiative}에 승인받기 위해 제출하였다. 수개월 간의 논쟁 끝에 승인을 받지는 못하였지만, MongoDB는 듀얼 라이선스 모델의 오픈소스 선택지로 SSPL을 계속 사용하고 있다. 이 라이선스가 오픈소스 정의_{Open Source Definition}에 적합하지 않은 이유에 대한 논의는 복잡했으며, 이 정의를 충족하는 것만이 유일한 기준은 아니었다. 요약하자면, 이렇게 광범위한 소스 공유 요구 사항을 가진 라이선스가 “소프트웨어 자유를 보장“할지가 분명하지 않았다.

제한 조건을 갖는 소스 공개 라이선스

다른 사람들은 또 다른 경로를 따랐다. 일부 회사는 Salil Deshpande가 주도한 Commons Clause를 채택했으며, 어떤 회사는 Elastic이 Elastic License 1.0을 만든 것처럼 Redis, Confluent, CockroachDB와 같은 자체 라이선스를 제작하였다. SSPL과는 달리, 이 라이선스들은 오픈소스 정의를 충족시키기 위한 것이 아니었다. 대신, 이들은 무상 사용을 겨냥한 제한 조건을 갖고 있다.

왜 이렇게 두 가지 경로로 갈렸을까? 이는 Freedom Zero, “어떤 목적으로든 원하는 대로 프로그램을 실행할 수 있는 자유"와 관련이 있다².

오픈소스 또는 자유소프트웨어 라이선스의 주요 특징은 라이선스 제약이나 제한이 없다는 것이다³. 일반적인 상용 소프트웨어 라이선스와 비교해보자. 개인용으로 사용하겠다는 라이선스 조건에 클릭하여 수락하는 형태의 최종 사용자 라이선스_{End User license Agreement}는 소프트웨어를 사용하는 것만 허용하며, 변경하거나 배포할 수 없다. 엔터프라이즈 라이선스는 소프트웨어를 사용할 수 있는 사용자, 서버 또는 물리적 위치의 수에 대한 제한을 설정하고, 기업은 해당 사용을 감시해야 한다. 그러나 오픈소스 라이선스에는 그러한 제한이 없다. 따라서, 소스 코드를 무료로 제공한다고 하더라도 상업적 사용 불가와 같은 제한을 갖고 있다면 정의상 오픈소스가 아니다.

즉, 모든 라이선스 제한은 오픈소스 범주에서 벗어나게 한다.

2018년 이후 발생한 라이선스 변경의 물결 가운데 출시된 모든 라이선스는 거의 비슷한 제한을 갖고 있다. 각각 고유한 조건이 있지만, 이들은 모두 사용자가 소프트웨어를 무료로 사용할 수 있도록 허용하는 동시에 경쟁 호스팅 서비스 제공을 위한 소프트웨어 사용을 금지하는 데 초점을 맞추고 있다.

Elastic License 2.0

2021년 초, Elasticsearch는 이 두 가지 경로를 모두 따르는 하나의 길을 개척하였다. SSPL과 새로운 Elastic License 2.0 (ELv2)이라는 두 가지 무료 선택지를 제공하여 소프트웨어 제품군을 사용할 수 있게 하였다.

새로운 Elastic 2.0 라이선스는 짧고 (한 페이지에 불과) 쉬운 언어로 작성되었으며 오픈소스 라이선스의 거의 모든 자유를 허용한다. 소프트웨어 수신자는 소프트웨어를 자유롭게 사용, 변경 및 재배포 할 수 있다. 전에 소프트웨어 라이선스를 읽어본 적이 없더라도 이 라이선스는 한번 읽어볼 가치가 있다.

여기에는 두 가지 주요 제한이 있다.

You may not provide the software to third parties as a hosted or 
managed service, where the service provides users with access to 
any substantial set of the features or functionality of the software.

You may not move, change, disable, or circumvent the license key 
functionality in the software, and you may not remove or obscure 
any functionality in the software that is protected by the license key.

첫 번째 제한은 무상 사용 문제를 해결하는 데 초점이 맞춰져 있다. 이로써 이 제한을 위반하여 소프트웨어를 사용하면 소프트웨어의 권한을 침해하게 된다.

두 번째 제한은 소프트웨어 라이선스 키의 해킹을 금지하기 위한 것이다. 이러한 제한은 소프트웨어 라이선스에서는 오래전부터 일반적이었으나, 소스 공개 라이선스에서는 이제 막 사용되기 시작하였다. 이 조항을 통해 개발자는 유료 서비스를 ELv2하의 소프트웨어와 상호 작용하게 하거나, 유료 기능을 위한 소프트웨어 구성 요소 일부를 보호할 수 있게 되었다.

이 라이선스의 다른 조항들은 매우 간단하며 오픈소스 라이선스를 읽은 사람이라면 누구나 익숙할 것이다.

왜 듀얼 라이선스를 사용하였는가?

Elasticsearch는 사용자에게 SSPL과 Elastic License 중 하나를 선택할 수 있게 하는 특이한 경로를 택하였다. 오늘날 많은 기업이 “오픈 코어_{open core}” 모델을 사용하고 있으며, 실제로 Elasticsearch도 전에는 이 모델을 사용하였다. 둘의 차이는 미묘하다고 할 수 있다. 오픈 코어 모델은 (대부분 Apache 2.0과 같은 허용적인_permissive) 오픈소스 라이선스로 핵심 소프트웨어를 제공한다. 그런 다음 제한된 라이선스로 또는 서비스로만_{as a service} 추가 기능(대개 기업이 대규모로 배포하는 데 유용한 기능)을 제공한다. 그러나 Elasticsearch는 동일한 소프트웨어를 두 개의 다른 라이선스로 사용할 수 있는 듀얼 라이선스 모델을 고수하였다. 이 듀얼 라이선스 모델은 MySQL에 의해 개척되었고, 일반적으로 무료 라이선스 선택지로 GPL, AGPL 또는 SSPL과 같은 카피레프트 라이선스를 사용한다. 그러나 이 모델은 오픈소스 라이선스와 클라우드 서비스 간의 충돌 때문에 최근 몇 년 동안 인기가 시들해졌다.

Elastic의 선택은 SSPL과 Elastic License 2.0의 두 가지 무료 라이선스 선택권을 제공하였다는 점에서 더욱 이례적이었다. 듀얼 라이선스는 일반적으로 하나의 무료 옵션만 제공한다. 이러한 이례적인 방법을 통해 Elasticsearch는 거의 모든 사용자가 소프트웨어를 무료로 사용할 수 있도록 하는 유연성을 강조하였다.

Elastic License 2.0는 오직 클라우드 서비스 공급 업체에서 Elasticsearch를 자기네 클라우드 서비스로 제공하는 것만은 막겠다는 의지인 것 같습니다.
결국 AWS는 Elasticsearch 서비스를 계속하기 위해 Elasticsearch를 Fork했고, 이를 Open Distro for Elasticsearch라고 명명하며 Apache License 2.0을 적용하고, 커뮤니티를 키워가기로 했습니다.
누가 오픈소스의 지속가능성과 발전에 기여하고 있는 것일까요?

Elastic License 2.0과 최신 라이선스 기술

Elasticsearch는 사용자와 개발자 모두에게 공정하고 지속 가능한 비즈니스 모델을 유지하면서 가능한 한 개방성을 유지하기 위해 새로운 라이선스 모델로 전환하였다. 그렇게 함으로써 소스 공개 운동_{source-available movement}에 참여한 다른 참여자들의 목표와 추구하는 바를 라이선스 작성 시 반영하였다.

라이선스 변경에 대한 FAQ에서 요약한 바와 같이 Elastic의 라이선스 변경은 고객이나 커뮤니티 사용자 수에 영향을 미치지 않을 것으로 예상된다. 대부분의 사용자는 Elastic의 소프트웨어를 기반으로 애플리케이션을 구축한다. 이는 “제3자에게 호스팅 또는 관리 서비스_{as a hosted or managed Service}로 제공"하는 비즈니스가 아니기 때문이다.

더 나은 라이선스 만들기

또한, Elastic은 Elastic License 2.0을 작성하는 데 리소스를 투입함으로써 라이선스 작성 기술의 발전을 추구하였다. 어떤 의미에서 소스 공개 라이선스는 소프트웨어만큼 오래되었다. 사실, 바이너리 전용 라이선스는 1980년대 PC / Mac 플랫폼 표준화의 산물이었다. 그 이전에는 거의 모든 소프트웨어가 소스 코드 형식으로 라이선스 되었다. 그러나 시간이 지남에 따라 라이선스의 배포 형식과 방법은 크게 달라졌다.

Elastic License 2.0은 이러한 추세의 정점이다. 형식적으로는 오픈소스 라이선스의 가장 인기 있는 간단하고 직관적인 작성 방식과 템플릿을 채택하였다. 또한 라이선스 키 보존 조항을 통해 공급 업체가 무료 및 유료 기능을 모두 갖춘 소프트웨어에 대한 라이선스를 쉽게 사용할 수 있도록 지원한다.

수십 년 전 유닉스에서 분리된 수많은 호환되지 않은 독점 버전과 마찬가지로 독점 라이선스는 제각각의 조항과 조건으로 덕지덕지 붙여진 누더기이다. 일반 소비자 소프트웨어 제품에 대한 단순한 최종 사용자 라이선스조차도 일반적으로 너무 길고 난해하여 대부분의 사용자는 이해할 수 없다. 아무도 그것을 읽지 않는다는 말도 많다. 그러나 이러한 복잡성은 대부분 불필요하다. 오픈소스 라이선스, 특히 허용_permissive 라이선스는 이를 교훈으로 삼았다. 간단한 일련의 규칙으로도 충분해야 하며 이해하기 쉬울수록 사용자가 이를 존중할 가능성은 높아진다.

Elastic License 2.0은 짧고 간단하며 이해하기 쉬울 뿐만 아니라 사람들이 이를 템플릿으로 사용할 수도 있다. 무상 사용 방지 논쟁이 시작된 후, 마찰이 없는 방식으로, 합리적인 제한을 가지며, 간단하고 이해 가능한 라이선스에 대한 수요가 증가하고 있다. 그러나 대부분의 소규모 소프트웨어 회사는 자체적으로 라이선스를 작성할 리소스가 없다. 많은 소프트웨어 스타트업이 Elastic License 2.0과 Confluent Community License와 같은 라이선스를 그들이 채택할 수 있는 모델로 찾고 있는 것은 놀라운 일이 아니다.

이 분야는 Fair Code가 이에 대한 표준을 만들면서 대중화되었다. Fair Code는 다음과 같이 말한다.

Fair-code is not a software license. 
It describes a software model where software:

* is generally free to use and can be distributed by anybody
* has its source code openly available
* can be extended by anybody in public and private communities
* is commercially restricted by its authors

이 계획은 아직 초기 단계에 있지만, 이로써 사용자와 개발자 모두에게 공정한 패러다임의 필요성을 업계가 인식하기 시작하고 있으며, 오픈소스 상용 기업이 오픈소스 모델보다 더 유연한 방식으로 둘 사이의 균형을 맞출 수 있도록 하고 있음은 분명하다. 한 전문가는 최근의 라이선스 발전을 “오픈소스 이후 시대“라고 부르기까지 하였다. 하지만 실제로는 이러한 소스 공개 라이선스는 비즈니스 및 라이선스 모델이 계속 발전함에 따라 일반적으로 오픈소스 라이선스와 함께 사용된다. 따라서 두 모델은 엄격한 대체품이 아니라 보완품이다.

또 다른 표준화된 라이선스 옵션도 있다. 2020년, 한 변호사 그룹은 PolyForm Project를 시작하여 소스 공개 라이선스 템플릿 모음을 작성하였다. 이러한 라이선스는 오픈소스 라이선스와 독점 라이선스 모두에 경험이 있는 변호사에 의해 상호 리뷰되었다. 개방형 콘텐츠 라이선싱을 위한 Creative Commons와 마찬가지로 비상업적, 평가 전용, 경쟁 방지 라이선스 등의 옵션 메뉴를 제공한다. Elastic License 2.0과 같이 모두 무료로 소스 코드에 대한 접근을 제공하며 필요한 특허 라이선스를 부여한다. PolyForm Perimeter 및 PolyForm Shield는 선조라고 할 수 있는 Confluent Community License와 유사하며, Elastic License 2.0은 이러한 추세에 따라 사용 가능한 옵션을 발전시켰다.

질문이 있거나 더 자세한 내용을 알아가고 싶다면 다음과 같은 몇 가지 자료를 참조하라.

“The rise of open source IPOs” https://coss.media/rise-of-the-open-source-ipo/. This article tracks some of the spectacular business successes of open source companies.

“The After Open Source Era Has Started” https://monetize.substack.com/p/open-source-eras . This article discusses the sea change represented by companies moving to source available licenses.

US House of Representatives Committee on the Judiciary’s report on investigation into competition in digital markets, spearheaded by the Subcommittee on Antitrust, Commercial and Administrative Law. https://www.documentcloud.org/documents/7222836-Investigation-of-Competition-in-Digital-Markets.html. Note the mention of Elasticsearch on page 326.

1: “Modification of Final Judgment,” August 24, 1982, filed in case 82-0192, United States of America v. Western Electric Company, Incorporated, and American Telephone and Telegraph Company, U.S. District Court for the District of Columbia web.archive.org/web/20060827191354/members.cox.⏎

2: The Free Software Definition is similar to the Open Source Definition, but shorter and clearer.⏎

3: Open source licenses can contain conditions, such as notices or source code sharing. But these are not limitations that tell you what you cannot do with software, they only require that if you elect to do certain things, you also must do others.⏎

By Haksung Jang (@haksungjang) | 2020년 8일 12월

안녕하세요.
오픈소스 분야의 저명한 변호사인 Matija Šuklje는 최근 소스 코드 내 저작권 표시가 필요한 이유와 올바르게 작성하는 방법을 소개하였습니다.
아래 글은 위의 원글을 기반으로 작성하였습니다. 대부분 원글을 그대로 번역하여 저자의 의도가 충실히 전달되도록 하였습니다.

다음 사항을 고려하며 균형을 맞춰서 작성하려고 하였다.

무엇을 하면 되는지만 간단히 알고 싶어하는 개발자를 위해
단지 모범 사례 뿐만 아니라 그 이면에 있는 이유에 대해서도 이해하고자 하는 FOSS 컴플라이언스 담당자와 법률가를 위해

시간이 극단적으로 없다면, TL;DR에서 최소한의 가이드를 확인하라. 2분 정도의 시간이 있다면 아래의 actual HowTo a bit lower below를 읽어라.

물론, 20분 정도의 시간이 있다면, 처음부터 끝까지 한번 읽어보는 것이 제일 좋다.

TL;DR

SPDX-FileCopyrightText: © {$year_of_file_creation} {$name_of_copyright_holder} <{$contact}>

SPDX-License-Identifier: {$SPDX_license_name}

예를 들어, 내가 오늘 소스 코드 파일을 하나 작성하였고, 이를 [BSD-3-Clause license][bsd-3-clause] 라이선스로 공개하였다면, 다음과 같은 내용을 파일 상단 주석 부분에 추가한다.

SPDX-FileCopyrightText: © 2020 Matija Šuklje <matija@suklje.name>

SPDX-License-Identifier: BSD-3-Clause

참고로 [REUSE.software][reuse] 프로젝트의 가이드를 따르면 모든 파일에 적절한 표시가 되었는지 확인할 수 있다.

저작권이란?

저작권은 ([베른 협약][berne] 이후) 저작자가 저작물 만들 때 자동으로 생성된다. 모든 저작물은 저작권에 의해 보호되며, 저작권 보유자에게 저작물에 대한 독점적인 권한이 부여된다. 따라서 당신의 저작물(소스 코드, 텍스트, 이미지, 기타 미디어 등)을 다른 사용자가 사용할 수 있게 하려면 그들에게 라이선스를 부여해야 한다. 라이선스의 사전적 정의는 “특정 권리를 실행하기 위해 자격이 있는 기관으로부터 받은 허가"이며, 이러한 허가 없이 특정 권리를 실행하는 것은 저작권 침해와 같은 불법 행위가 된다.

마찬가지로 당신이 다른 사람의 소스 코드를 복사, 수정 등의 작업을 하려면 필요한 권한을 부여 받아야 한다. 즉, 라이선스를 받아야 한다. 만약, 그 라이선스가 권리 실행 허가 조건으로 특정 의무를 요구한다면, 당신은 권리 실행을 위해 그 의무사항도 따라야만 한다.

라이선스 (license) : 라이선스는 저작권 보유자 이외의 다른 사람에게 코드를 사용할 권한을 부여하는 유일한 방법이기 때문에 라이선스를 고지하고 전체 라이선스 텍스트를 제공하는 것이 좋다. 이는 당신이 내보내는 Outbound 라이선스나 (복사된 코드나 라이브러리 같은 3rd party 저작물을 사용하면서) 다른 이로부터 받는 Inbound 라이선스 모두에 해당한다.

Inbound vs. Outbound 라이선스
당신이 사용자(downstream)에게 부여한 라이선스를 Outbound 라이선스라고 부른다. 이는 당신으로부터 흘러나오는(out) 코드의 권한을 다루기 때문이다. 반대로, (동일한 코드의) 사용자 입장에서는 그들에게 흘러들어오는 (In) 코드의 권한을 다루기 때문에 Inbound 라이선스로 간주한다. 간단히 말해, 유입되는 권한을 설명하는 라이선스를 Inbound 라이선스라고 하고, 유출되는 권한을 설명하는 라이선스를 Outbound 라이선스라고 한다. 다행인 점은 저작자 표시는 저자의 권리이지 의무는 아니다. 또한 사용자는 저자가 저작자 표시 권리를 사용한 경우에만 이를 유지해야 하는 의무가 있다. 즉, 저자가 저작자 표시를 하지 않았을 때에는 사용자가 이를 직 표시하려고 수고하지 않아도 된다.

저작권 표시가 법에 따라 요구되는 것은 아니지만, 실제로는 해당 저작물의 저작권이 누구에게 있는지에 대한 증거로서 매우 유용한다. 또한, 이는 컴플라이언스 측면이나 코드 추적을 위해서도 큰 도움이 된다.

(이러한 요구가 없더라도) 사용자는 법적 또는 기술적인 이유로 원저작자에게 연락하기를 원할 수도 있다.

따라서, 저작물에 저작자의 이름과 연락처 정보를 포함하는 것은 의미가 있다.

저작권 표시

© 기호
연도 : 처음 소스 코드 파일을 작성한 연도이다. 한번 작성했으면 더 수정하지 마라.

© 2020 Matija Šuklje <matija@suklje.name>

라이선스 고지

또한, 코드를 공개하면서 라이선스가 무엇인지 알리는 것도 매우 중요한다. SPDX ID를 사용하면 코드의 라이선스를 명확하게 알릴 수 있다. 라이선스 고지가 명확하지 않으면 이를 보는 사용자에게 혼란을 야기시킬 수 있다.

REUSE.software

라이선스 고지 tag : SPDX-License-Identifier

SPDX-FileCopyrightText: © 2020 Matija Šuklje <matija@suklje.name>

SPDX-License-Identifier: BSD-3-Clause

이제 당신이 작성한 모든 소스 코드 파일에 이러한 주석이 포함되었는지 확인하라!

FAQ

왜 연도를 표시해야 하는가?

연도를 표시하지 않는 게 작업을 크게 단순화한다는 데에는 동의하지만, 이를 유지한다면 코드 베이스에서의 모호한 타임라인을 확인하는 데 도움이 된다. 또한, 발명이 처음으로 일반인에게 언제 공개되었는지를 알아내는데 유용할 수 있다. 특히 특허 방어에 유용하게 사용될 수 있다.

이런 사항들을 고려하여 Liferay의 새로운 정책에서는 파일 생성 연도를 작성하고, 연도를 더 변경하지 않다.

왜 연도 표시를 변경하지 말아야 하는가?

Copyright (C) 1992, 1995, 2000, 2001, 2003 CompanyX Inc.

게다가 새로운 변경이나 기여를 받을 때마다 이렇게 그 연도를 추가하는 행위를 법적으로 본다면 논란의 여지가 있다. 문제는 모든 기여가 저작권을 주장할 수 있을 정도로 독창적이거나 규모가 있지 않다. 따라서, 문제 소지를 없애려면 모든 기여에 대해 법률에 따라 저작권 보호를 받을 수 있을 만큼 독창적인지 여부를 먼저 판단하고, 그에 따라 저작권 표시에 연도를 추가해야할 것이다.아

Git/VCS 히스토리를 더럽히지 마라
만약 매년 모든 파일에 연도 표시를 새롭게 추가한다면 이로 인해 Git/VCS 히스토리가 불필요하게 길어지게 되고, 저장소 공간을 소비하며, 정작 중요한 정보를 찾을 때 방해가 될 수 있다.

연도를 범위로 표시하는 건 어떤가요?

연도를 범위로 표시하는 것(예: 1999-2020)도 매년 연도 표시를 변경해줘야 하기 때문에 위의 질문에서 언급한 모든 사항이 동일하게 적용된다.

어떤 경우는 ‘{$year}-present’와 같은 형태로 범위를 지정하기도 한다. 이 또한 위에서 언급한 사항들이 대부분 적용되며, 추가로 또 다른 혼란을 줄 수 있다. ‘present’가 의미하는 것은 추상적이다. ‘present’는 어떤 것을 의미하는 걸까요?

파일이 마지막으로 수정 시간?
패키지가 릴리즈된 시간?
처음 다운로드 한 시간?
마지막으로 실행한 시간?
아니면 바로 지금?

이처럼 ‘present’는 전혀 도움이 되지 않는 표시이다.

항상 그렇지는 않다. Git (및 다른 VCS)은 메타데이터 관리에 뛰어나지만, 항상 이 의존하는 것은 주의해야 한다.

더 중요하게는, 파일이 저장소에서 옮기게 되면 메타데이터는 사라진다. 소스 코드만 압축해서 배포한다거나, 저장소를 fork 혹은 rebase하는 방식으로 각 파일을 새로운 코드 베이스로 복사하면 이전까지의 추적 데이터는 더 이상 확인할 수 없다.

왜 © 기호를 사용하는가?

EU에서의 한 예로, 슬로베니아의 ZASP §175. (1)은 독점적 저작권 보유자가 자신의 저작물을 표시하기 위해 “(c)” 또는 “©"로 표시할 수 있다고 명시하고 있다. 반면에 미국에서는 17 U.S. Code § 401. (b)(1) 에서는 다음과 같이 저작물 표시 방법을 지정하고 있다. “the symbol © (the letter C in a circle), or the word “Copyright”, or the abbreviation “Copr.””

왜 연락처를 남겨야 하는가? 두 명 이상의 저자가 있을 때는 어떻게 하는가?

Public Domain은 무엇인가?

일부 관할권 (예: 미국, 영국)에서는 저작권 보유자가 자신의 저작권을 포기하고 저작물을 Public Domain으로 기부할 수 있지만, 대부분의 관할권(예: 대부분의 EU 회원국)에서는 이런 행위가 불가능한다. 이는 관할권에 따라 저자가 자신의 저작물을 Public Domain으로 제공한다고 표시하였다고 하더라도 이것이 실제로 유효하게 하기 위한 법적 기준을 충족할 수 없고, 결국 여전히 저작물에 대한 저작권을 저작권자만 보유하고 있음을 의미한다.

소스 코드를 다른 언어나 컴파일러 및 다른 형태로 변환하더라도 모두 저작권 보유자에게 독점적 권리가 있다. 따라서, minify 한 코드를 사용할 때에도 유효한 라이선스가 필요하다.

2019 FOSS Legal Issue Top 10

Top 10 FOSS legal developments in 2019

By Haksung Jang (@haksungjang) | 2020년 1일 30월

안녕하세요.
DLA Piper의 IP 전문 변호사인 Mark Radcliffe는 최근 “Top 10 FOSS legal developments in 2019“라는 글을 기고하였습니다. Open Source Compliance에 관심 있는 분들에게 도움이 될 것으로 기대하여 내용을 제가 이해하는 선에서 정리해보았습니다. (저는 법률가가 아니기 때문에 법적인 용어나 해석 부분은 미흡한 부분이 있을 수 있습니다. 보완이 필요한 부분을 알려주시면 고맙겠습니다.)

1. McHardy (Linux system copyright 트롤, 독일), 새로운 전략 채택

Linux kernel의 초기 기여자인 Patrick McHardy는 독일에서 소송을 무기로 금적적인 이익을 취득하려는 Copyright 트롤과 같은 활동을 하였다. 그는 7년 반 동안 활동했으며, 80개가 넘는 회사에 접근한 것으로 알려져 있지만, 많은 기업이 소송까지 가지 않고 합의로 처리하였고, 독일 법원의 소송 절차는 기밀로 유지되기 때문에 정확한 수치는 추정하기는 어렵다. 2017년 McHardy가 소송을 제기한 Geniatech 사건의 항소 법원 판사는 2018년 GPLv2 위반에 대한 저작권 주장을 제기하는 McHardy의 주장에 대해 회의적으로 대응하였고, 결국 MacHardy는 소송을 취하하였다.

이후 McHardy는 추가적인 소송 제기하는 상황을 만들고 있지는 않지만, 여전히 GPLv2에 대한 Compliance 위반에 대한 주장을 계속하고 있다. 그는 그동안 가벼운 Contractual Penalty를 우선 체결하고, 이후 추가적인 위반을 발견해서 무거운 Penalty를 집행하는 방법으로 금전적인 이익을 취했다면, 2019년 초부터는 위반을 찾아내기 위해 그가 소비한 시간에 대한 배상을 요구(과다한 Engineering cost 요구)하는 새로운 전략으로 전환했다.

2. Richard Stallman, GNU, MIT 및 Free Software Foundation에서 사임

Richard Stallman이 Free Software Foundation의 President 겸 이사직을 사임했다. Free Software (및 Open Source) 운동은 Richard Stallman의 비전과 지속적인 노력에 힘입은 바가 크다. 그러나 지난 수년간 그는 FOSS 운동 이외의 문제에 대해 여러 의견을 제시하여 논쟁을 불러일으켰다. Jeffrey Epstein 사건의 희생자에 대한 올해의 그의 진술은 Free Software Foundation으로부터의 사임 압력을 받게 하였다.

그는 또한 MIT에서 사임했고, GNU 운영 체제의 Maintainer들은 그를 쫓아냈다. 그들은 그의 기여에 대해서는 인정했지만, 다음과 같이 언급했다. “그러나, 몇 년 동안 Stallman의 행동이 GNU 프로젝트의 핵심 가치인 모든 컴퓨터 사용자의 이익을 약화시켰음을 인정해야 한다. GNU는 리더의 행동이 우리가 도달하고자 하는 가치에서 멀어질 때 제대로 된 임무를 수행할 수 없다.”

앞으로 누가 Free Software 운동의 리더십 역할을 맡을지는 분명하지 않다.

(관련 국내 기사 : http://www.zdnet.co.kr/view/?no=2019091817351)

3. OSS에 닥친 무역 전쟁

2019년 5월, 미 산업안전국(BIS)은 Huawei Technologies Co., Ltd. 및 68개 미국 이외의 계열사를 Entry List에 올렸다. BIS는 2019년 8월 Entry List에 46개의 미국 이외의 Huawei 계열사를 추가했다. 회사들은 BIS가 임시 라이선스를 발급한 4개 영역(2019년 8월, 3개로 축소)을 제외하고는 수출 관리 규정(EAR)에 해당하는 품목을 Huawei로 수출, 재수출, 또는 양도할 수 없다.

Google은 즉시 Google Play Store와 같은 Google Service 뿐만 아니라 Android OS에 대한 접근을 차단했다(단, BIS 예외에 따라 일부 업데이트 제공). Huawei는 Android Open Source Project를 사용하는 것으로 되돌아가야 했다. BIS는 Temporary General License를 여러 차례 연장했다. Huawei는 Android를 대체할 수 있는 버전을 개발 중이며, 다음 버전의 폰과 함께 배포할 수 있을 것이라고 발표했다. 이번 Huawei의 Google Android OS 접속 중단은 영구적일 것으로 보여 Android가 미국에 본사를 둔 생태계와 중국에 본사를 둔 생태계 두 곳으로 쪼개질 가능성도 있다.

4. OSS 라이선스에서의 윤리적 제한

OSS에는 윤리적인 이유에 대해 사용을 조건화하려는 여러 차례의 시도가 있었다. 올해, 여러 가지의 “Ethical License” 사례가 있었다. 한 예로, 개발자인 Seth Vargo는 자신의 open source library project인 Chef Sugar를 사용자들이 사용할 수 없도록 삭제해버렸다. 그는 Chef Sugar가 미국 이민 관세 수사청(U.S. Immigration and Customs Enforcement, ICE)과의 계약의 일부로 사용(되었고, 그는 ICE가 불법 입국한 부모와 자녀를 격리 수용한 것을 비판하기)때문에 Chef Sugar를 삭제했다.

초기에는 Chef Sugar 제공사인 Chef가 Chef Sugar 프로젝트의 저작권을 소유하고 있다고 주장하며, 문제를 해결하려고 했다. Chef의 CEO는 Chef가 ICE에 서비스를 계속 제공할 것이라고 했지만, 4일 후 CEO는 Chef가 ICE와의 라이선스를 갱신하지 않고, ICE 계약의 수익을 이산가족(ICE로 인해 헤어진 가족)을 다루는 자선단체에 기부할 것이라도 발표했다.

운동가인 Coraline Ada Ehmke는 Hippocratic License를 만들었다. 그녀는 이 라이선스가 “Open Source 프로젝트에 윤리를 추가"한다고 말한다. Hippocratic License는 MIT License에 다음 조항을 추가한다.:

“The software may not be used by anyone for systems or activities that actively and knowingly endanger, harm, or otherwise threaten the physical, mental, economic, or general well-being of other individuals or groups, in violation of the United Nations Universal Declaration of Human Rights.”

OSI는 Hippocratic License가 “open source” 라이선스가 아니라고 신속하게 언급했다. 불행히도 이 추가 조항으로 인해 매우 해석하기 어려운 라이선스가 됐다.

5. 블록체인 프로젝트의 FOSS 전략

많은 블록체인 프로젝트가 FOSS 라이선스 하에 공개되었다. 블록체인 커뮤니티가 인프라 기술에 대한 복잡하고 특이한 선택을 했다. 새로운 블록체인인 Algorand 블록체인 프로젝트는 2019년 SDK, example application, helper library를 MIT License로 공개하였다. 그러나 Algorand node software는 AGPLv3로 라이선스 되었다. 많은 회사의 법률 또는 Compliance 부서는 AGPLv3 하의 software는 compliance를 보장하기가 어렵기 때문에 이를 사용하지 못하도록 제한한다. 이로 인해 기업들이 Algorand 프로젝트를 채택하는데 어려움을 초래할 수 있게 되었다.

6. Oracle v. Google 전쟁

연방 순회 항소 법원(CAFC)은 Oracle v. Google의 사건에 대한 두 번째 결정을 발표했으며, 여기에서 Google이 Android 운영체제에서 Oracle의 Java Application Programing Interface (API) 37개 package를 무단 사용한 것이 Oracle의 저작권을 침해했다고 판결하였다. 2014년 CAFC는 지방 법원의 1심 판결을 뒤집고 API가 저작권을 가지고 있다고 인정했으며, 다만 Fair Use 여부를 심리하도록 1심으로 환송하였다. 2016년 지방 법원은 Google의 API 사용이 Fair Use에 해당한다는 사실을 근거로 Google이 승소하는 판결을 내렸고, Oracle은 항소했다. 2019년 3월, CAFC는 다시 한번 지방 법원의 판결을 뒤집어 Google의 API 사용이 법적인 관점에서 Fair Use에 해당하지 않는다고 판결하였다. 대법원은 이송 명령서(certiorari)를 부여했다 (2020년 3월부터 심리 예정). 이 사건은 컴퓨터 소프트웨어의 저작권 보호 범위를 결정하는 데 매우 중요한 근거가 될 것이다.

(관련 국내 기사 : https://byline.network/2020/02/11-94/)

7. 독일 Hellwig/VMware case 종결

2015년 3월, Linux kernel의 핵심 개발자인 Christoph Hellwig는 독일 함부르크 지방 법원에 VMware를 고소했다. Hellwig는 VMware가 (1) 파생 저작물을 생성하는 방식으로 Linux와 “vmkernel"이라는 VMware의 독점 코드를 결합하였음에도 (2) GPLv2에 따라 vmkernel의 완전한 해당 소스 코드(complete corresponding source code)를 제공하지 않음으로써 GPLv2의 조건을 위반했다고 주장했다. VMware ESXi 운영체제의 “kernel"인 vmkernel은 물리 서버의 하드웨어 및 소프트웨어 리소스를 관리한다.

VMware는 vmkernel이 Linux의 파생 저작물이 아니라 단지 VMK API를 통해 Linux와 통신한다고 응답했다. 또한, VMware는 또한 vmkernel과 동작하는 드라이버는 Linux 드라이버일 필요는 없으며, “‘vmklinux’라고 불리는 loadable kernel module을 통한 compatiblity alternative(어떤 Linux driver와도 연동)가 vmkernel에 의해 로드되고, VMK API를 통해 vmkernel과 인터페이스 한다.“라고 하였다. 공소장 및 법정 문서들은 독일 법원의 규정에 따라 기밀로 유지되기 때문에 분쟁과 관련된 사실은 확인할 수 없다.

함부르크 법원은 Hellwig가 자신이 개발한 Linux 시스템의 구성 요소와 VMware가 해당 구성 요소를 사용했는지 여부를 입증하지 못했다는 근거로 Hellwig의 소송을 기각했다. 함부르크 고등 법원은 1심 판결에 대한 항소를 기각했으며, Hellwig는 그 결정에 항소하지 않기로 결정했다. 두 법원은 고소장의 실질적인 문제는 다루지 않았으며, Linux에서 가져온 일부 component의 right ownership 또는 copyright protection 능력에 대한 불충분한 증거에 근거하여 결정을 내렸다.

이러한 결정에 대한 대응으로 VMware는 “VMware는 소송과 무관하게 vSphere에서 vmklinux를 제거하기 위한 활동을 다년간 활발히 진행해 왔으며, 향후 major release에서 이를 달성하기를 희망한다"라고 발표했다.

8. OSS 비즈니스 모델 및 라이선스

많은 상용 FOSS 회사들이 전통적인 OSS 라이선스는 Cloud Service Provider가 FOSS 회사에 비용을 지불하지 않고도 그들의 프로그램을 사용하는 것을 허용한다는 우려를 표명한다. 2019년 6월, CockroachDB는 Open Source 운동의 창시자 중 한 명인 Bruce Perens가 MariaDB를 위해 처음 개발한 BSL (Business Source License)를 채택했다. CockroachDB의 CEO는 다음과 같이 말했다. “오늘 우리는 매우 permissive 한 라이선스인 BSL (Business Source License)를 채택한다. CockroachDB의 사용자는 CockroachDB를 여러 노드로 확장할 수 있다. CockroachDB를 사용하거나 application에 포함시킬 수 있다 (application을 고객에게 배포하거나 servicve 형태로 실행하거나 상관없이). 내부적으로 서비스로 실행할 수도 있다. 단 하나의 유일한 제한은 라이선스를 구매하지 않은 상태로 CockroachDB를 상용 버전의 서비스로 제공할 수 없다는 것이다.”

11월, Sentry도 BSL을 채택했다. 2018년에 채택된 새로운 라이선스들에도 몇 가지 새로운 발전이 있었다. 2018년 Redis Labs는 Redis 모듈의 라이선스를 AGPL에서 Common Clause가 추가된 Apache v2.0으로 변경하였다 (이 Redis 모듈은 Redis core 위에 add-on 된다). Common Clause는 Cloud Service Provider에 의한 제품 사용을 제한하기 위해 Apache Software License version 2에 추가되는 형식으로 도입되었다. 이 혼합 라이선스의 도입은 논란의 여지가 많았으며, Redis는 Commons Clause를 포기하고, RediSearch, RedisGraph, RedisJSON, Redis-ML 및 RedisBloom에 Redis Source Available License를 채택했다. 다른 회사들도 비슷한 라이선스를 채택했다.

9. FOSS governance와 표준 제정기구 governance를 사용하는 프로젝트 간 RAND 특허 라이선스에 대한 충돌

FOSS가 하나의 개발 방법론으로 널리 보급되면서 표준 제정기구 (standard setting organizations / SSO)는 FOSS 접근 방식을 자신의 프로세스에 통합하기 위해 노력해왔다. 그러나 FOSS 프로젝트와 SSO의 방법론은 상당히 다르다. FOSS 프로젝트는 매우 다양한 책임과 더 분산된 방식으로 실행된다. 특히 마찰이 되는 요인 중 하나는 SSO의 일반적인 접근 방식으로써 SSO는 멤버들에게 royalty-bearing 기준(공정하고, 합리적이고, 비차별적 혹은 FRAND 조건으로 / FRAND : Fair, Reasonable, And Non-Discriminator)의 특허권을 부여한다. 이러한 마찰은 open source license에서 특허 라이선싱에 관한 분쟁을 다룬 기사들에서 보여준다 (here 및 here).

David Kappos 전 특허청장은 다음과 같이 언급했다. “대신, 우리는 OSD 준수 라이선스는 명시적 특허 허여 조항이 없는 한 특허 라이선스를 부여하는 것으로 가정해서는 안 된다는 반대 결론에 대한 상당한 지지를 얻었다. 즉, OSS 라이센서는 특허 라이선스를 부여하는 라이선스를 선택하거나, MIT와 Berkely처럼 부여하지 않는 라이선스를 선택할 수 있다. 그래서 OSS와 실질 표준특허(standard-essential patents, SEP)가 혁신을 발전시키는데 협력할 수 있는 능력을 보존할 수 있다.”

반면에 Van Lindberg는 다음과 같이 응답했다. : “이것이 open source와 FRAND가 상호보완적이지만 호환될 수 없는 이유이다.: open source와 FRAND는 서로 다른 지적 재산 정책에 의존하여 혁신해간다. 이 두 개발 모델은 서로 배우고, 서로 경쟁할 수 있지만, 근본적으로 다른 기본 원칙을 기반으로 한다. "

“SSO가 OSS를 포함시키려는 이유는 이해할만하다. open source는 저렴하고, 상호 운용이 가능하며, 혁신적이다. SSO는 OSS와 상호 운용성을 확보하기 위해 변화할 수 있는 능력이 있다. 많은 조직이 그랬던 것처럼 Royalty-free IPR(지식 재산권) 정책을 채택하기만 하면 된다. 그러나 FRAND 로열티를 부과하고자 하는 SSO라면 궁극적으로 open source를 다룰 때 상업적인 기업들이 가지고 있는 것과 같은 선택권을 가지고 있는 것이다. 즉, OSS 사용 시 준수해야 하는 라이선스와 규칙을 존중하거나, 아니라면 상용 버전을 만들어내는데 시간을 투자해야 한다. "

특허에 대한 로열티 지불 방식의 차이는 FOSS와 SSO 커뮤니티 사이에 긴장을 유발하고 있다. 그리고 일부 SSO 커뮤니티는 “open source"가 무엇인지 정의할 수 있어야 한다고 주장했다. 이 문제는 가까운 시일 내에 해결되지 않을 것 같다.

10. Open source license, 데이터 및 암호 문제로 확장

데이터는 “new oil"이라고 불린다. Open source 개념이 데이터 라이선스에 적용되었다(2017년 Linux Foundation의 Community Data License Agreement 참조). 그러나 올해에는 데이터와 사이버 보안(cybersecurity)에 적용되었다. 예를 들어, Holochain에서 잘 알려진 open source 변호사인 Van Lindberg에 의해 Cryptographic Autonomy License (CAL)가 개발되었다. Holochain은 이 라이선스에 대해 다음과 같이 설명했다. “분산 앱의 경우, 암호화 키(cryptograhpic key)는 code와 user data 사이의 낯선 중간 영역에 들어간다. Code는 기능적이며 컴퓨팅 시스템의 입력 또는 출력으로 user data를 라우팅하고 변환하는 프로세스를 제공한다. User data는 일반적으로 code에 의해 처리되고 저장될 수 있는 수동 콘텐츠에 더 가깝다. 암호화 키는 user data이면서 기능적(functional)이다. Holochain에서 암호화 키는 데이터의 소유권에 대한 증명을 조율한다 : 데이터가 어디에 저장되는지, 누가 데이터를 제어하는지, 통신과 스토리지의 보안과 암호화를 누가 확인하는지, 데이터의 순서와 무결성을 확립하는 progressive hashing 및 signning을 위한 체인 구조의 운영 등.”

CAL은 user data와 관련하여 다음과 같은 의무를 제공한다. “Throughout any period in which You exercise any of the permissions granted to You under this License, You must also provide to any Recipient to whom you provide services via the Work, a no-charge copy, provided in a commonly used electronic form, of the Recipient’s User Data in your possession, to the extent that such User Data is available to You for use in conjunction with the Work.”

또한 이 라이선스는 또한 보안상의 결함을 다루는 경우, 소스 코드 제공의 지연을 허용하는데 이는 새롭고 환영받는 접근 방식이다. “You may delay providing the Source Code corresponding to a particular modification of the Work for up to ninety (90) days (the ‘Embargo Period’) if: a) the modification is intended to address a newly-identified vulnerability or a security flaw in the Work, b) disclosure of the vulnerability or security flaw before the end of the Embargo Period would put the data, identity, or autonomy of one or more Recipients of the Work at significant risk, c) You are participating in a coordinated disclosure of the vulnerability or security flaw with one or more additional Licensees, and d) Access to the Source Code pertaining to the modification is provided to all Recipients at the end of the Embargo Period.”

Linux Foundation은 JDF (Joint Development Foundation)을 통해 open data 문제에 대해 작업을 계속했다. JDF는 AWS, Genesys 및 Salesforce와 협력하여 Cloud 애플리케이션 전반에서 데이터 상호 운용성을 표준화하는 open source data 모델인 Cloud Information Model을 개발했다.