2025년 1월 9일, Software Freedom Conservancy (SFC)는 독일의 네트워크 장비 제조업체 AVM을 상대로 제기한 소송이 마무리되었다고 발표했습니다. 이 소송의 핵심은 GNU Lesser General Public License (LGPL) 버전 2.1에 명시된 사용자의 권리, 특히 설치 정보 제공 의무에 관한 것이었습니다.
Sebastian Steck이라는 독일의 소프트웨어 개발자가 2021년 5월 AVM의 라우터를 구매한 후, AVM이 제공한 소스 코드로는 수정된 소프트웨어를 라우터에 재설치할 수 없다는 사실을 발견했습니다. Steck은 AVM에게 “uClibc, libblkid, libexif 및 libosip2 라이브러리의 완전한 소스 코드와 컴파일 및 설치 스크립트 제공"을 요구했습니다. AVM이 이를 시정하지 않자 Steck은 2023년 7월 베를린 법원에 소송을 제기했습니다.
소송 결과, 독일 법원은 AVM에게 Steck의 변호사 비용을 지불하도록 판결했습니다. AVM은 이 판결에 대해 항소하지 않기로 결정했습니다. 법원은 이 사건의 분쟁 금액을 7,500 유로로 정했는데, 이는 오픈소스 라이선스 준수 문제의 경제적 가치와 중요성을 반영합니다.
또한, 이 사건은 LGPL-2.1이 사용자에게 장치의 소프트웨어를 수정, 수리, 재설치할 권리를 보장한다는 점을 명확히 했습니다. 특히 네트워크 장비와 같은 임베디드 시스템에서도 이러한 권리가 보장되어야 한다는 점을 확인했다는 데 큰 의의가 있습니다.
Disclaimer:
본 글은 법률 전문가가 작성한 것이 아니며, 법적 근거로 사용될 수 없습니다. 라이선스 및 법적 문제와 관련된 구체적인 상황에 대해서는 반드시 법률 전문가의 조언을 구하시기 바랍니다. 또한 이 글은 공개된 정보를 바탕으로 작성되었으며, 소송 당사자들의 입장을 모두 반영하지 않을 수 있습니다. 판결의 전체 내용과 맥락은 원문을 참고하시기 바랍니다.
2. 소송의 배경과 경과
배경
독일의 소프트웨어 개발자 Sebastian Steck은 2021년 5월, AVM사의 인기 제품인 Fritz!Box 4020 라우터를 구입했습니다. Steck은 이 라우터의 펌웨어에 사용된 소스 코드를 요청했는데, 여기서 문제가 발생했습니다. AVM이 제공한 소스 코드로는 라우터에 수정된 소프트웨어를 다시 설치할 수 없었던 것입니다.
법적 근거
이 소송의 중요한 특징은 Sebastian Steck이 LGPL-2.1 소프트웨어의 저작권자가 아님에도 불구하고 소송을 제기할 수 있었다는 점입니다. 이는 LGPL-2.1 라이선스가 제3자를 위한 계약의 성격을 가지고 있기 때문입니다. 소장(Complaint)에 따르면 LGPL-2.1 라이선스는 제3자를 위한 계약의 성격을 가지고 있습니다:
“This license agreement represents a genuine contract in favor of third parties in accordance with Section 328 of the German Civil Code (BGB), namely in favor of the users who receive the software in object code and, in accordance with the wording of the LGPL-2.1 license conditions to be handed over to them, have a direct right to the transfer of the complete corresponding source code.”
이러한 법적 근거는 오픈소스 소프트웨어 사용자의 권리를 크게 강화합니다. 제조업체가 라이선스 의무를 제대로 이행하지 않을 경우, 저작권자뿐만 아니라 일반 사용자도 법적 조치를 취할 수 있게 되었습니다.
소송 경과
2021년 5월 7일: Steck이 AVM에 Fritz!Box 4020의 펌웨어 버전 6.83 소스 코드를 요청
2021년 5월 11일: AVM 자회사가 소스 코드 다운로드 링크 제공
2021년 5월 14일: Steck이 제공된 소스 코드의 불완전성을 지적하고 시정 요구
2023년 1월 12일: Steck의 변호인이 AVM에 법적 상황을 설명하고 소스 코드 시정 요구
2023년 3월 9일: Steck이 펌웨어 버전 7.02의 소스 코드도 추가로 요청
2023년 7월 27일: Steck이 베를린 지방법원에 소송 제기
소송 제기 수개월 후: AVM이 Steck에게 요청받은 모든 소스 코드를 제공. “라이브러리 설치를 제어하는 스크립트"도 포함
2025년 1월 9일: AVM이 Steck의 변호사 비용을 지불하고 소송 종결. AVM은 판결에 대해 항소하지 않기로 결정
소송의 쟁점
이 소송에서 주요하게 다뤄진 쟁점들은 다음과 같습니다:
컴파일 및 설치 스크립트 제공: AVM이 처음에 제공한 소스 코드에는 LGPL-2.1에서 요구하는 컴파일 및 설치 스크립트가 빠져 있었습니다. 이 스크립트는 소스 코드를 실행 가능한 프로그램으로 변환하고, 그 프로그램을 기기에 설치하는 데 필요한 중요한 요소입니다.
환경 변수 정보: 컴파일 과정에 필수적인 KERNEL_LAYOUT 등의 환경 변수 설정 정보가 제공되지 않았습니다. 환경 변수는 프로그램이 실행되는 환경을 설정하는 중요한 정보로, 이것이 없으면 소스 코드를 제대로 컴파일할 수 없습니다.
영구 설치 가능성: AVM이 제공한 정보로는 수정된 라이브러리를 Fritz!Box에 영구적으로 설치할 수 없었습니다. 이는 사용자가 자신의 기기에 수정된 소프트웨어를 지속적으로 사용할 수 있어야 한다는 LGPL-2.1의 핵심 요구사항을 위반하는 것입니다.
펌웨어 이미지 생성: 제공된 소스 코드로는 Fritz!Box에 설치 가능한 펌웨어 이미지를 만들 수 없었습니다. 펌웨어 이미지는 라우터의 운영 체제와 기능을 담고 있는 파일로, 이를 생성할 수 없다는 것은 사실상 소프트웨어를 수정하고 재설치할 수 없다는 것을 의미합니다.
사용자의 소송 제기 권리 인정:
이번 판결은 오픈소스 소프트웨어의 저작권자가 아닌 일반 사용자도 LGPL-2.1 라이선스 위반에 대해 소송을 제기할 수 있음을 인정했습니다. 이는 오픈소스 소프트웨어 사용자의 권리를 크게 강화하는 결과를 가져왔습니다.
이러한 쟁점들은 모두 LGPL-2.1 라이선스의 핵심 원칙인 ‘사용자의 소프트웨어 자유’와 직결됩니다. 소스 코드를 제공하는 것만으로는 충분하지 않고, 사용자가 그 코드를 실제로 수정하고 기기에 다시 설치할 수 있어야 한다는 것이 이 소송의 핵심 주장이었습니다.
“The information required for the reinstallation of the compiled program libraries on the Fritz!Box (“installation script”) was also deliberately withheld from the plaintiff. Upon request, the plaintiff only received information that could be used to load the libraries in dispute into the working memory (RAM). However, this is not a sufficient installation on the Fritz!Box because the copy is only created temporarily, meaning “fleetingly [volatile].” When the Fritz!Box is switched off and restarted, the modified versions of the LGPL 2.1 libraries would no longer be present on the device, and the versions created by the defendant would be used instead. This is diametrically opposed to the purpose of the LGPL-2.1, namely, to be able to customize and reinstall the software.”
또한, 이번 판결은 오픈소스 소프트웨어 사용자의 권리를 실질적으로 보장했을 뿐만 아니라, 사용자가 직접 이러한 권리를 법적으로 주장할 수 있는 근거를 마련했다는 점에서 큰 의의가 있습니다. 이는 오픈소스 생태계의 건전성을 유지하는 데 중요한 역할을 할 것으로 예상됩니다.
3. 판결 의의
이번 판결은 오픈소스 소프트웨어 라이선스 준수에 대한 중요한 기준을 제시했습니다. 독일 법원은 LGPL(Lesser General Public License) 라이선스 준수를 위해서는 단순히 소스 코드를 제공하는 것만으로는 부족하다고 판단했습니다. 제공된 소스 코드는 실제로 사용자가 펌웨어를 수정하고 재설치할 수 있어야 한다는 것입니다.
이번 판결에서 확인할 수 있는 주요 내용은 다음과 같습니다:
LGPL 준수의 실질적 의미:
법원은 LGPL 준수가 단순한 형식적 절차가 아니라는 점을 분명히 했습니다. 소스 코드를 제공하는 것은 시작일 뿐, 그 코드가 실제로 사용 가능해야 합니다.
실용성 요구:
제공된 소스 코드는 단순히 읽을 수 있는 형태여서는 안 됩니다. 사용자가 이를 실제로 컴파일하고, 수정된 버전을 기기에 재설치할 수 있어야 합니다. 이는 소프트웨어의 ‘수리 가능성’을 보장하는 중요한 요소입니다.
컴파일 및 설치 스크립트 제공 의무:
LGPL은 소스 코드 자체뿐만 아니라, 이를 컴파일하고 설치하는 데 필요한 스크립트도 함께 제공할 것을 요구합니다. 이는 평균적인 기술 수준을 가진 사용자도 소프트웨어를 수정하고 재설치할 수 있어야 한다는 의미입니다.
사용자 권리의 실질적 보장:
LGPL의 근본적인 목적은 사용자에게 소프트웨어를 자유롭게 수정하고 재설치할 수 있는 실질적인 능력을 부여하는 것입니다. 이번 판결은 이러한 권리가 단순한 선언에 그치지 않고 실제로 행사 가능해야 함을 강조했습니다.
이번 판결의 의의는 오픈소스 소프트웨어 사용자의 권리를 실질적으로 보장했다는 점입니다. 특히 임베디드 기기나 IoT 기기와 같이 일반 사용자가 쉽게 수정하기 어려운 환경에서도 제조사가 사용자의 소프트웨어 수정권을 보장해야 한다는 점을 명확히 했습니다.
또한, 사용자가 직접 이러한 권리를 법적으로 주장할 수 있는 근거를 마련했다는 점에서 큰 의의가 있습니다.
4. 시사점
LGPL-2.1의 설치 정보 제공 의무: 이번 판결은 LGPL-2.1도 GPL-3.0과 마찬가지로 설치 정보 제공을 요구한다는 점을 명확히 했습니다. 이는 임베디드 기기 제조사들에게 상당한 부담이 될 수 있습니다.
임베디드 기기 제조사의 부담 증가: 라우터, IoT 기기 등 임베디드 시스템을 생산하는 기업들은 이제 LGPL-2.1 라이브러리 사용 시에도 설치 정보를 제공해야 한다고 볼 수 있습니다. 이는 기술적, 경제적 부담을 증가시킬 수 있습니다.
오픈소스 라이선스 준수의 중요성 재확인: 기업들은 오픈소스 소프트웨어 사용 시 해당 라이선스 조건을 더욱 철저히 준수해야 합니다. LGPL이라고 해서 의무가 가벼운 것이 아님을 인식해야 합니다.
사용자의 법적 권리 강화: 이번 판결로 오픈소스 소프트웨어 사용자들이 직접 라이선스 위반에 대해 법적 조치를 취할 수 있게 되었습니다. 이는 오픈소스 커뮤니티의 힘을 강화하고, 기업들의 라이선스 준수를 더욱 촉진할 것으로 예상됩니다.
오픈소스 생태계의 자정 능력 향상: 저작권자뿐만 아니라 일반 사용자도 라이선스 준수를 요구할 수 있게 됨으로써, 오픈소스 생태계의 자정 능력이 크게 향상될 것으로 보입니다.
기업의 책임 범위 확대: 기업들은 이제 저작권자뿐만 아니라 모든 사용자에 대해 LGPL-2.1 라이선스 의무를 이행해야 합니다. 이는 기업의 책임 범위를 확대하고, 더욱 철저한 라이선스 준수를 요구하게 될 것입니다.
이번 AVM 사건은 LGPL-2.1을 포함한 오픈소스 라이선스 준수의 중요성을 다시 한 번 일깨워주는 계기가 되었습니다. 특히 임베디드 기기 제조사들은 이를 교훈 삼아 라이선스 준수에 더욱 신경 써야 할 것이며, 사용자들의 권리도 더욱 존중해야 할 것입니다.
소프트웨어 지식재산권 침해 논란에서 ‘파생저작물(derivative works)‘이라는 개념은 매우 중요한 역할을 합니다. 특히 GNU General Public License (GPL)과 같은 오픈소스 라이선스를 다룰 때 이 개념은 핵심적인 쟁점이 됩니다. 최근 Oracle과 Rimini Street 간의 소송은 파생저작물의 정의와 관련된 법적 해석을 다시금 주목하게 만들었습니다. 이번 글에서는 이 사건의 배경, 주요 판결 내용, 그리고 오픈소스 라이선스에 미칠 영향을 살펴보겠습니다.
사건의 배경
PeopleSoft와 Rimini Street
PeopleSoft는 Oracle이 제공하는 ERP(Enterprise Resource Planning) 소프트웨어로, 기업의 인사 관리, 재무 관리, 공급망 운영 등을 지원합니다. PeopleSoft는 정기적으로 업데이트를 제공하며, Oracle은 고객들에게 이러한 업데이트를 유지보수 서비스 형태로 제공합니다.
Rimini Street는 Oracle 고객들에게 제3자 유지보수 서비스를 제공하는 회사입니다. Rimini는 고객 대신 PeopleSoft 업데이트를 생성하고 이를 수정하거나 배포하여 고객 시스템에 적용하는 방식으로 운영되었습니다. 그러나 이 과정에서 Oracle은 Rimini가 저작권 및 라이선스 조건을 위반했다고 주장하며 소송을 제기했습니다.
법적 공방
초기 판결: Process 1.0의 문제점
2015년 법원은 Rimini Street가 사용한 초기 운영 방식(Process 1.0)이 Oracle의 저작권을 침해했다고 판결했습니다. 주요 문제는 다음과 같았습니다:
교차 사용(cross-use): 한 고객 환경에서 생성된 업데이트를 다른 고객에게 배포.
Oracle PeopleTools 사용: Oracle 소프트웨어 도구를 활용하여 업데이트 생성.
복제 및 배포: PeopleSoft 파일을 복사하고 수정하여 여러 고객에게 제공.
법원은 Rimini의 이러한 방식이 Oracle의 라이선스 조건을 위반했으며, 저작권 침해에 해당한다고 판단했습니다.
Process 2.0 도입과 새로운 논란
2018년부터 Rimini Street는 기존 방식을 폐기하고 새로운 프로세스인 Process 2.0을 도입했습니다. Process 2.0은 다음과 같은 특징을 가집니다:
고객 환경 내 작업: 모든 업데이트 생성 및 테스트 작업을 각 고객의 PeopleSoft 환경에서 수행.
자동화 도구 사용 제한: 이전에 사용했던 자동화 도구를 최소화하거나 제거.
교차 사용 방지: 고객 간 데이터와 작업물을 분리하여 교차 사용 문제를 방지.
그러나 Oracle은 Process 2.0에서도 여전히 저작권 침해가 발생한다고 주장했습니다. 특히 Rimini가 일부 작업을 자체 서버에서 수행하거나, 한 고객 환경에서 생성된 업데이트를 다른 고객에게 전달한 점이 문제가 되었습니다.
2023년 네바다 연방법원 판결
2023년 7월, 네바다 연방법원은 Rimini Street가 Process 2.0에서도 여전히 Oracle의 저작권을 침해했다고 판단했습니다. 법원은 다음과 같은 이유로 Rimini의 방식을 문제 삼았습니다:
일부 작업이 여전히 자체 서버에서 수행되었음.
업데이트 배포 과정에서 교차 사용이 발생했음.
Rimini가 개발한 자동화 도구가 Oracle 소프트웨어와 밀접하게 연관되었음.
이에 따라 법원은 Rimini에게 영구 금지명령(permanent injunction)을 내렸습니다.
2024년 항소법원 판결
미국 제9순회 항소법원은 2024년 12월, 네바다 연방법원의 일부 결정을 뒤집으며 새로운 법적 기준을 제시했습니다:
파생저작물 정의 축소:
파생저작물이 되려면 Oracle의 저작물이 문자적(literal) 또는 비문자적(nonliteral)으로 실질적으로 포함되어야 한다고 판단했습니다.
단순히 PeopleSoft와 상호작용하거나 호환된다는 이유만으로는 파생저작물로 간주될 수 없다고 보았습니다.
교차 사용 문제 재검토:
한 고객 환경에서 생성된 업데이트가 다른 고객에게 전달된 행위가 라이선스 조건 위반인지 여부를 지방법원이 다시 검토하도록 환송(remand)했습니다.
§117(a) 방어 논리 인정 가능성:
항소법원은 Rimini가 §117(a)에 따라 Oracle 고객 대신 복사를 수행할 권리가 있을 수 있다고 보고, 이를 재검토하도록 명령했습니다.
GPL과 파생저작물
GPL의 파생저작물 해석
GNU General Public License (GPL)은 파생저작물을 광범위하게 정의합니다. GPL 소프트웨어와 결합된 모든 작업물도 GPL 조건을 따라야 한다는 “바이럴(viral)” 특성을 가집니다. GPL FAQ에 따르면, 다음과 같은 경우에 파생저작물로 간주될 수 있습니다:
코드 수정: GPL 소프트웨어의 소스 코드를 직접 수정하는 경우
코드 포함: GPL 소프트웨어의 일부 코드를 자신의 프로그램에 포함시키는 경우
링킹: GPL 라이브러리와 정적 또는 동적으로 링크하는 경우
플러그인 또는 확장: GPL 소프트웨어의 플러그인이나 확장 기능을 개발하는 경우
Oracle v. Rimini 판결과의 차이점
이번 판결에서 항소법원은 파생저작물에 대해 더 좁은 해석을 제시했습니다:
단순 상호작용이나 호환성만으로는 파생저작물이 성립되지 않음.
원본 소프트웨어의 코드나 표현이 “실질적으로 포함"되어야만 파생저작물로 인정됨.
이는 GPL 라이선스 적용 범위에 대한 법적 논쟁을 야기할 수 있으며, 특히 오픈소스 소프트웨어와 상업용 소프트웨어 간 경계 설정에 중요한 영향을 미칠 수 있습니다.
긍정적 측면과 남아 있는 과제
이번 판결은 다음과 같은 긍정적인 영향을 미칠 수 있습니다:
파생저작물 정의를 명확히 하여 불필요한 법적 분쟁 감소.
제3자 유지보수 서비스 제공업체들에게 더 큰 자유 제공.
그러나 여전히 해결해야 할 과제도 남아 있습니다:
정적/동적 링크 문제: C 라이브러리와 정적 또는 동적으로 링크된 프로그램이 해당 라이브러리의 파생저작물인지 여부는 여전히 불분명합니다. 이는 라이브러리의 헤더 파일 내용이 얼마나 “실질적"인지에 따라 달라질 수 있습니다.
오픈소스 프로젝트와 상업용 소프트웨어 간 상호작용 규정 명확화.
마치며
Oracle v. Rimini 사건은 법원이 “파생저작물” 개념을 좁게 해석함으로써 개발자들에게 더 큰 자유를 제공했지만, 동시에 오픈소스 라이선스의 영향력을 약화시킬 가능성도 열었습니다.
개발자들은 이번 판결을 계기로 사용하는 라이선스 조건을 더욱 꼼꼼히 살펴야 하며, 독립적인 설계 방식을 채택하여 법적 분쟁 위험을 줄이는 것이 중요합니다. 오픈소스는 혁신과 협업의 강력한 도구지만, 그 안에서 지켜야 할 규칙도 분명히 존재한다는 점을 잊지 말아야 합니다!
취약점 보고: 제조업체는 취약점 보고 정책을 수립하고 이를 공개적으로 사용할 수 있도록 해야 합니다.
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의 새로운 규제 환경에 대응하기 위해 한국 기업들이 고려해야 할 주요 권장사항은 다음과 같습니다:
이 글은 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의 데이터 수집 방식:
웹페이지의 텍스트 내용을 복제합니다.
이미지, 비디오 등 비텍스트 데이터는 직접 저장하지 않습니다.
대신 이러한 콘텐츠에 대한 링크를 포함한 웹페이지의 소스 코드를 저장합니다.
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 기반 소프트웨어 제품은 어차피 소스 공개 의무가 있으니 배껴도 되는 것 아닌가요?
오픈소스 소프트웨어의 사용이 널리 퍼지면서, 이와 관련된 법적 문제들도 점점 더 복잡해지고 있습니다. 특히 GPL(GNU General Public License)과 같은 copyleft 라이선스를 사용하는 오픈소스 프로젝트를 기반으로 한 2차적 저작물의 저작권 문제는 많은 기업들에게 골치 아픈 주제입니다. 최근 중국에서 있었던 한 소프트웨어 저작권 침해 소송은 이러한 문제에 대한 중요한 시사점을 제공합니다.
소송 당사자
원고: Wangjing Technology(왕징)
피고:
Yibang Communication Technology(이방)
Qi’ao Network Technology(치아오)
그리고 3명의 개인(Liu, Wu, Xie)
사건의 개요
2009년, 왕징은 ‘OfficeTen’이라는 융합 통신 스마트 게이트웨이 제품을 개발했습니다.
이 제품에 내장된 ‘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차적 저작물이라도, 개발자의 독창적인 기여가 있다면 저작권 보호의 대상이 될 수 있습니다.
이는 오픈소스 소프트웨어를 활용한 혁신을 장려하면서도, 무분별한 복제와 저작권 침해를 방지하는 균형 잡힌 접근법이라고 볼 수 있습니다. 기업들은 이러한 법적 해석을 참고하여 오픈소스 정책을 수립하고, 라이선스 준수와 독창적 개발 사이의 균형을 잡아나가야 할 것입니다.
오픈소스 소프트웨어의 사용이 더욱 보편화되는 현재, 이러한 법적 판단은 앞으로 더 많은 국가에서 참고될 것으로 예상됩니다. 따라서 기업의 오픈소스 관리자들은 이러한 법적 동향을 지속적으로 모니터링하고, 자사의 오픈소스 정책에 반영해 나가야 할 것입니다.
마지막으로, 이번 판결은 오픈소스 커뮤니티와 상업적 이용자 모두에게 중요한 메시지를 전달합니다. 오픈소스 정신을 존중하면서도 개발자의 노력과 창의성을 인정하는 것, 그리고 라이선스를 준수하면서도 혁신을 추구하는 것이 건강한 소프트웨어 생태계를 만드는 길임을 다시 한 번 상기시켜 줍니다.
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은 **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과 같은 강력한 카피레프트 라이선스는 클라우드 시대에서 더욱 주목받을 것이며, 기업은 이에 맞춰 내부 시스템을 강화하고, 오픈소스 관리 체계를 발전시켜야 할 것입니다.
오픈소스 라이선스의 변화는 피할 수 없는 현실이지만, 이를 기회로 삼아 적절히 대응하는 기업은 경쟁 우위를 확보할 수 있습니다. 체계적인 오픈소스 관리 전략을 통해 법적 리스크를 최소화하고 기술적 이점을 극대화함으로써, 기업은 오픈소스 생태계 내에서 지속 가능한 성장을 이룰 수 있을 것입니다.
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은 소프트웨어 개발 및 배포 과정에서 투명성, 보안, 컴플라이언스를 크게 향상시키는 강력한 도구입니다. 기업의 오픈소스 관리자는 이 표준을 이해하고 적용함으로써, 조직의 소프트웨어 관리 프로세스를 현대화하고 리스크를 줄일 수 있습니다.
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의 데이터 모델은 소프트웨어 공급망의 복잡성을 포괄적으로 표현할 수 있으며, 동시에 특정 도메인의 요구사항을 충족시킬 수 있는 유연성을 제공합니다. 이를 통해 조직은 소프트웨어 구성 요소에 대한 더 정확하고 상세한 정보를 관리하고 공유할 수 있게 되었습니다.
소프트웨어 부품 목록(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 관리는 단순히 규제 요구사항을 충족하는 것을 넘어, 조직의 소프트웨어 공급망 보안을 크게 강화하고 투명성을 높이는 데 기여합니다. 이는 궁극적으로 더 안전하고 신뢰할 수 있는 소프트웨어 생태계 구축으로 이어집니다.
{"@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 데이터를 활용하여 라이선스 호환성을 자동으로 검사할 수 있습니다.
라이선스 그래프 생성
소프트웨어 구성 요소 간의 의존성과 각 구성 요소의 라이선스 정보를 바탕으로 라이선스 그래프를 생성합니다.
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의 이러한 활용 사례들은 조직이 소프트웨어 관리, 보안, 컴플라이언스를 통합적으로 개선할 수 있게 해줍니다. 표준화된 접근 방식을 통해 조직 간 협력을 촉진하고, 소프트웨어 생태계 전반의 투명성과 신뢰성을 높이는 데 기여합니다.
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을 활용한다면, 조직은 오픈소스의 이점을 최대화하면서 관련 리스크를 최소화할 수 있을 것입니다. 오픈소스 관리자는 이러한 도구를 통해 조직의 디지털 혁신과 경쟁력 강화에 핵심적인 역할을 수행할 수 있을 것입니다.
오늘은 프랑스 법원이 GPL 위반으로 통신사인 Orange에게 손해배상을 판결한 사건에 대해 살펴보려 합니다. 이 사건은 두 가지 주요 측면에서 특별히 주목할 만한 점이 있어 보였습니다.
첫째, 이 사건의 피고인이 대형 통신사인 Orange라는 점입니다. (제가 통신사에 몸 담고 있다보니…)
둘째, GPL 위반 소송이 주로 임베디드 디바이스에서 발생하는 반면, 이 사건에서는 B2B 형태의 웹서비스 구축에 사용된 오픈소스가 이슈가 되었다는 점입니다. 이는 오픈소스 라이선스 준수가 모든 소프트웨어 개발 영역에서 중요하다는 것을 강조합니다.
이 사건은 이러한 측면들을 통해 오픈소스 라이선스 준수의 중요성을 재확인하는 계기가 될 것으로 보입니다. 이는 기업들이 오픈소스를 사용할 때 라이선스 요구사항을 철저히 이해하고 준수해야 함을 강조하는 중요한 사례가 될 것입니다.
감수 및 보완 내용 의견 주신 SK텔레콤의 박철웅 매니저님께 감사 드립니다.
GPL이란?
GNU General Public License의 약자로, 대표적인 오픈소스 라이선스 중 하나인 GPL은 소프트웨어의 저작권자가 “누구든지 소프트웨어를 자유롭게 사용하고, 수정하고, 배포할 수 있도록 허용하는 동시에, 수정된 버전이나 파생된 저작물도 GPL을 따라야 한다는 조건을 부과"하는 강력한 Copyleft 성격의 라이선스입니다.
2002년 9월에 설립된 프랑스의 소프트웨어 회사인 엔트루베르는 Lasso라는 이름의 C 라이브러리를 개발하였습니다. Lasso는 Liberty Alliance의 SAML 표준과 같은 인증 프로토콜을 구현하는 라이브러리입니다.
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.
프랑스의 대형 통신사인 Orange는 2005년, 프랑스 전자 행정 개발청(ADAE, 현재 DGME)과 “My Public Service” 포털(현재 https://www.service-public.fr/)을 개발하기 위한 계약을 체결했습니다.
당시 이 포털은 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 형태로 웹서비스 구축 계약을 체결하여 정부기관이나 고객사에 소프트웨어를 공급할 때에도 오픈소스 관리를 위한 프로세스를 적용해야 함에 유의해야 합니다.
오픈소스 관리를 위한 정책과 프로세스를 이미 구축한 대기업들도, 현대의 거대하고 복잡한 소프트웨어 공급망을 고려한다면 오픈소스 라이선스나 보안 취약점 리스크에서 벗어나기 어렵습니다. 결국, 소프트웨어 공급망 내 모든 기업의 오픈소스 관리 수준을 높이는 것이 중요합니다. 이를 위해서는 오픈소스 관리 방법에 대한 이해도가 높은 기업이 먼저 노하우를 공유하고, 다른 기업에서 쉽게 참여할 수 있도록 안내하는 길잡이가 필요합니다.
기업이 보유한 오픈소스 관리 자산을 경쟁사와 공유한다고 해도 매출에 악영향을 끼치지 않습니다. 반면, 경쟁사의 오픈소스 관리 정책을 알아내더라도 이를 기업의 이익과 연결할 수 없습니다. 기업들이 서로 오픈소스 관리 Best Practice를 공유한다면, 각 기업은 적은 비용과 리소스 투입으로도 큰 효과를 얻을 수 있습니다. 이러한 아이디어에 공감하여, LG전자, SK텔레콤, 카카오, 현대자동차, 삼성전자의 오픈소스 담당자들이 참여한 첫 번째 OpenChain KWG 모임이 2019년 1월에 개최되었습니다.
17차 미팅 (오프라인)
모임은 매 분기 진행하고 있으며, 코로나 기간 동안 온라인으로 진행되었습니다. 그러다가, 지난 2023년 3월 28일에는 3년 만에 오프라인 모임을 개최했습니다. 19개 기업/기관에서 50여 명의 오픈소스 담당자가 참석했습니다. 이번 오프라인 모임은 라인플러스에서 준비해 주었습니다. 쾌적한 장소와 음료, 그리고 기념품 등을 제공해주신 라인플러스의 오픈소스 매니저 이서연, 김동혁 님께 감사드립니다! ^^
이번 모임의 첫 번째 부분에서는 OpenChain Project의 국내외 최신 동향과 보안 보증 규격에 대한 발표가 있었으며, AI 기술에 대한 법적 이슈 및 사례 연구에 대한 발표도 있었습니다. 두 번째 부분에서는 기업의 오픈 소스 관리를 위한 도구를 오픈 소스로 개발하여 공유하는 세션 발표가 있었습니다. 자세한 발표 내용은 이어지는 소개에서 다루겠습니다.
1부 : 세션 발표
OpenChain Global Updat (Linux Foundation, Shane Coughlan)
오픈소스 컴플라이언스를 위한 표준인 ISO/IEC 5230뿐만 아니라 보안을 위한 표준인 ISO/IEC 18974도 개발 중입니다. 이 표준은 곧 공식 ISO 표준으로 등록될 예정이며, 기업이 준수해야 할 Self-Checklist도 공개되어 있습니다. 이러한 자료들을 활용하여 기업은 효율적인 오픈소스 리스크 관리를 수행할 수 있습니다.
Shane은 KWG 멤버들을 위한 기념품도 가져와서 큰 호응을 얻기도 하였습니다. (Thank you, Shane 😊 )
OpenChain 보안 표준 소개 (SK텔레콤, 장학성)
ISO/IEC 5230은 오픈소스 컴플라이언스를 위한 국제 표준입니다. 이 표준은 2020년에 ISO에 등록되었으며, 세계의 많은 기업이 이 표준을 준수하여 오픈소스 컴플라이언스 관리를 훌륭하게 수행하고 있습니다. 기업이 오픈소스를 관리해야 하는 이유는 라이선스 컴플라이언스 뿐만 아니라 보안 취약점에 대한 리스크도 존재하기 때문입니다. OpenChain Project에서는 보안 취약점 관리를 위한 표준, ISO/IEC 18974, OpenChain security assurance specification을 만들었습니다. 저는 이 표준이 어떤 내용으로 구성되어 있는지를 간단히 요약하여 소개하였습니다.
이 보안 표준은 ISO/IEC 5230과 동일한 포맷으로 구성되어 있습니다. 라이선스 컴플라이언스 대신 보안 취약점 관리를 위해 수행해야 할 요구 사항을 정의합니다. 기업은 라이선스 컴플라이언스 이외에도 보안 취약점 관리를 위한 정책과 프로세스를 구축해야 합니다. 또한, 발견된 보안 취약점에 대응할 수 있는 절차를 마련해야 합니다.
Legal Issues of AI Technologies / Case Study: Getty Images v. Stability AI (ETRI 박정숙)
ETRI의 박정숙 님은 최근 제기된 Stable Diffusion 관련 소송을 분석하여 AI 법률 이슈를 소개하였습니다. 발표 자료는 여기에서 확인할 수 있습니다.
박정숙님은 AI 관련 법률 제정 현황을 분석하고, 이를 기반으로 AI 관련 오픈소스 컴플라이언스 대응 방안을 모색하여 공유해주셨습니다.
2부 : Mini Summit - 오픈소스 관리 자동화 도구
2부에서는 오픈소스 관리를 자동화하기 위한 각 기업의 Best Practice를 공유하는 세션 발표가 있었습니다.
도구 별 의존성 분석 방식 (카카오, 임현지)
카카오 임현지님은 오픈소스 분석 도구의 의존성 분석 방식을 비교 분석하여 발표하셨습니다. 발표 자료는 여기에서 확인할 수 있습니다.
대표적인 오픈소스 분석 도구인 FOSSA, FOSSLight, ORT (OSS Review Toolkit), OLIVE Platform 별로 의존성 분석 방식을 파악하여 공유하였습니다.
OSORI는 오픈소스 정보 데이터를 공개하여 누구나 쉽게 오픈소스 정보를 확인하고 필요한 의무 사항을 준수할 수 있게 하기 위한 오픈소스 프로젝트입니다. LG전자, 삼성전자, 카카오가 보유한 오픈소스 프로젝트에 대한 주요 정보, 라이선스 종류, 이에 따른 주요 준수 사항 및 제약 사항을 항목별로 테이블을 구성한 정보를 데이터베이스화하기 위한 스키마를 정의하였고, 앞으로 데이터 정제, 운영 Policy 정립, 가이드 페이지 구축 등의 로드맵을 소개하였습니다.
FOSSLight Project는 2023년 보안 취약점 기능을 개선하고, SBOM 기능 강화, UX개선 등의 로드맵을 가지고 있습니다.
요즘 OLIVE 써봤니? (카카오, 황은경)
OLIVE Platform은 카카오에서 개발한 오픈소스 라이선스 검증 서비스이며, 카카오 계정 뿐만 아니라 GitHub, Google, Facebook 등의 계정만 있으면 누구나 무료로 사용할 수 있습니다.
카카오의 황은경 님은 OLIVE Platform의 주요 기능을 소개하였습니다.
OLIVE Platform은 소스 코드 노출이 우려되는 경우에도 안심하고 사용할 수 있는 OLIVE CLI 기능이 추가되어 보안에 민감한 금융권에서도 도입될 수 있었습니다.
onot, 이제 제법 쓸만해졌어요! (카카오, 한현민)
onot은 SK텔레콤과 카카오가 공동 개발한 오픈소스 프로젝트 입니다. SPDX 규격으로 작성된 SBOM을 오픈소스 고지문으로 자동 변환하는 도구입니다. 카카오의 한현민 님은 최근 onot에 추가된 신규 기능에 대해 소개하였습니다. 발표 자료는 여기에서 확인할 수 있습니다.
onot은 Package 정보뿐만 아니라 File 정보도 추출하게 되었고, Multi License 표기도 지원하게 되었습니다. RDF/xml 형태의 SPDX 문서도 오픈소스 고지문을 생성할 수 있으며, 특히 Windows PC에서의 GUI와 같은 보다 편리한 사용 환경을 지원하게 되었습니다.
글을 마치며
3년여만에 오프라인으로 모인 모임은 짧은 시간이 아쉬울 정도로 알찼습니다. 멋진 장소와 기념품, 추첨 상품까지 준비해준 라인플러스 이서연 님, 김동혁 님께 다시 한번 감사드립니다.
기업들은 오픈소스 관리 업무에서 비슷한 어려움을 겪게 되는데, 이를 어떻게 극복하고 효율화하였는지를 공유하는 것은 서로에게 큰 도움이 됩니다. OpenChain Korea Work Group은 이러한 공감을 갖는 기업의 담당자가 자발적으로 참여하는 모임입니다. OpenChain Korea Work Group은 기업/기관에서 오픈소스 관리 업무를 담당하시는 누구나 참여할 수 있습니다. : 가입 방법
끝으로, OpenChain KWG는 분기마다 정기 미팅을 개최하고 있습니다. 다음 모임은 카카오에서 만날 수 있을 것 같습니다.
그때까지 모두 행복하세요! 😃
기업의 효과적인 오픈소스 관리 방안 (1) 글로벌 협력을 위한 OpenChain Project
기업이 개발하는 제품 소프트웨어의 93% 이상이 오픈소스를 사용한다고 할 정도로 현대 소프트웨어 개발에 오픈소스를 사용하는 건 거의 필수적입니다. 그런데, 사용하는 오픈소스의 53%는 라이선스 컴플라이언스 이슈가 있고, 81%는 보안 취약점을 갖고 있다는 보고가 있습니다. 복잡한 현대 소프트웨어의 개발환경과 방대한 Software Supply Chain을 고려한다면, 기업이 오픈소스로 제품을 개발하면서 라이선스 컴플라이언스와 보안 취약점 리스크 최소화를 위한 오픈소스 관리 노력이 필요한데요, Linux Foundation의 OpenChain Project는 이러한 노력을 커뮤니티 차원에서 여러 기업이 공유와 협업으로 함께 하기 위한 Project입니다.
2023년 3월 27일, OpenChain Project의 General Manager인 Shane Coughlan이 SK텔레콤을 방문하여 OpenChain Project의 주요 활동, 오픈소스 관련 국제 표준 및 글로벌 동향에 관해 설명하는 시간을 가졌습니다.
이 자리에는 SK텔레콤 OSRB와 SK그룹 오픈소스 협의체 멤버(SK플래닛, SK쉴더스, SK(주), Supex추구협의회 등)가 참여하여 다양한 의견을 나누었는데요,
이날 Shane은 OpenChain Project에 대해 소개하고, 어떻게 글로벌 협력을 통해 Software Supply Chain에서의 오픈소스 관리 이슈를 공동으로 해결해 가는지 설명하였습니다. 이 글에서는 주요 내용을 소개하려고 합니다.
OpenChain Project에는 다수의 Work Group이 있으며, 각 Work Group에서는 오픈소스 관리를 위한 표준을 만들고 자동화 도구를 함께 개발하고 있습니다. 또한 국가별로 Work Group이 결성되어 있습니다.
OpenChain Standard
ISO/IEC 5230:2020, ISO/IEC 18974
가장 가시적인 결과는 오픈소스 관리를 위한 최초의 국제 표준을 개발한 것입니다. 2020년 12월, ISO/IEC 5230이 오픈소스 컴플라이언스를 위한 유일한 국제 표준으로 등록되었습니다. ISO/IEC 18974는 오픈소스 보안 보증 컴플라이언스를 위한 사실상의 표준이며, 2023년 하반기에 ISO 표준으로 공식 등록될 예정입니다.
이들 표준은 기업이 오픈소스를 관리하는데 꼭 필요한 핵심 요구사항을 정의하고 있습니다. 기업은 이 표준의 요구사항을 준수함으로 Software Supply Chain 내에서 오픈소스 관리가 이뤄지고 있음을 투명하게 나타낼 수 있습니다.
Self-Certification
OpenChain Project에서는 Self-Certification을 위한 Checklist도 제공하는데요. 기업은 Checklist 항목을 하나하나 준수해 가면서 기업의 오픈소스 관리 수준을 높일 수 있습니다.
Adoption of OpenChain ISO/IEC 5230:2020
Checklist의 모든 항목을 준수하는 기업이라면, ISO/IEC 5230 준수 기업으로 선언할 수 있게 됩니다. ISO/IEC 5230을 채택하였다고 선언한 기업 리스트는 다음과 같습니다. LG전자, 카카오, 삼성전자, 네이버, SK텔레콤, NCSOFT, 현대자동차그룹 등 여러 국내 기업도 볼 수 있습니다.
Other Interesting Items
Online Webinar
OpenChain Project에서는 오픈소스 관리에 대한 온라인 웨비나를 계속하고 있습니다.
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일에 있었습니다. 다음 글에서 이에 대해 자세히 다루겠습니다.
Python 개발 환경 만들면서 Anaconda 많이 사용하시지 않나요? Python은 간단한 업무 자동화부터 데이터 분석, 인공지능 학습, 모델링 작업 등에 많이 사용되고 있는데요, 여러 Python 프로젝트 개발을 수행하다 보면 package 버전이 충돌하는 불편함이 생길 수 있습니다. Anaconda는 개발 프로젝트별로 가상 환경을 제공하여 버전 충돌을 방지할 수 있다는 장점이 있으며, 홈페이지에서 쉽게 다운받아 설치가 간단하여 널리 사용되고 있습니다.
그런데, 바로 이 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와 동일하게 유료 구매 대상으로 간주될 수 있습니다.
결국, 200인 이상 기업의 개발자가 Anaconda Distribution을 무료로 다운받아서 사용하더라도 당장 비용이 청구되거나 기능이 막히지는 않겠지만, Anaconda의 안정적인 발전을 위해서도 200인 이상의 기업 개발자는 자발적으로 구매하여 사용하는 것이 좋을 것 같습니다. (물론 어느 순간 회사로 라이선스 위반 통지 및 비용 청구서가 날아올 수도 있습니다. ^^)
대안은 있습니다. ‘conda-forge’
Anaconda사는 conda라는 package manager를 오픈소스로 공개하여 관리하고 있습니다. conda 자체는 BSD-3-Clause 라이선스로 공개된 오픈소스여서 기업이 무료로 사용하는 데 문제되지 않습니다.
conda는 package 설치/관리를 위해 설치할 package를 찾기 위한 저장소 위치가 필요한데요, 이를 channel이라고 칭합니다. 기본 channel이 바로 Anaconda Repository입니다. 그런데, commuinity 기반의 repository가 또 있습니다. 바로 conda-forge인데요,
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 아키텍처를 지원한다고도 알려져 있습니다.
따라서, Anaconda 대신 Miniforge를 설치한다면 비교적 수월하게 라이선스 위반 없이 conda package manager로 개발 환경을 구성할 수 있는 것으로 보입니다.
한 가지 특이한 점은 conda-forge 운영에는 막대한 호스팅 비용이 필요한데 이를 Anaconda사가 지불하고 있다는 점입니다. Anaconda사는 conda-forge를 계속 무료로 유지하기 위해서라도 Anaconda Repository의 서비스 약관 변경을 통한 수익이 필요했다고 설명합니다.
결론적으로 개발 편의성과 안정성을 고려하여 가급적 Anaconda Pro를 구매하여 사용하는 것이 좋겠습니다. 구매 전까지 라이선스 이슈 방지를 위해 Miniconda + conda-forge 조합, 혹은 Miniforge를 대안으로 고려할 수 있을 것 같습니다. 🙂
혹시 틀린 내용이 있다면 알려주시면 감사하겠습니다. ^^
감사합니다.
2022
Akka는 더 이상 오픈소스가 아닙니다.
Apache-2.0이었던 Akka의 라이선스가 2.7 버전부터 기업이 무료로 사용할 수 없는 Business Source License로 변경되었습니다.
오픈소스로 시작한 소프트웨어 기업이 라이선스 정책을 변경하는 사례가 증가하고 있는데요, 그동안 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 등 주로 고성능이 요구되는 백엔드 플랫폼에 사용된다고 합니다.
상업적 목적이 아닌 경우 무료로 사용할 수 있으나, 상업용에 대해서는 라이선스 비용을 지불해야 한다.
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은 일반적인 오픈소스 라이선스와는 달리 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 사용, 혹은 사용 라이선스 구매)를 취할 수 있어야 하겠습니다.
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 :
breach of contract and
declaratory relief (선언적 판결)
선언적 판결이란 미국의 민사소송법 내 절차로 판사가 민사소송에서 당사자들의 권리, 의무, 책임 등을 선언하는 것을 말하며 이때 어떤 이행 명령이나 조치, 또는 배상을 명령하지는 않음. 특허 등의 소송의 경우, 침해혐의자가 특허권자를 상대로 비침해, 무효, 권리 불행사의 확인을 구하는 소 또는 반소 등으로 사용됨.
이번 소송은 기존 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 소스 코드를 요구할 법적 권리가 생긴 줄로 생각했는데, 이번 판결 내용은 그에 대한 최종 판결을 한 것은 아니었습니다. 앞으로 주 법원에서 이를 위한 다툼을 할 수 있는 기회를 부여 받은 판결로 이해됩니다.
“조세핀 L. 스테튼 미국 지방법원 판사는 판결문에서 “GPLv2가 저작권법으로 제공하는 권리와 추가 계약 약속의 집행은 별도로 구별되는 추가 요소에 해당한다는 SFC의 주장이 연방법에 의해 선점되지 않으므로 (상급법원으로) 환송한다"고 밝혔다.”
이제 이해가 되는 것 같습니다. 그런데, 여전히 왜 “(상급법원으로)” 환송한다고 표현했는지는 잘 모르겠습니다. 미국 지방법원은 연방 법원에 해당하고, 이 사건은 주 법원으로 환송하는 건데, 왜 “(상급법원으로)” 환송한다고 표현했을까요? 오타일까요, 미국에서는 주 법원을 상급법원으로 표현하나요? 아니면 제가 뭔가를 잘 못 이해하고 있는걸끼요? 법률 전문가 분의 의견 부탁 드려봅니다. :)
먼저, 오픈소스 개발방법론에서 강조하는 주요 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?
AI는 사용하지 않는 기업이 없을 정도로 현대 비즈니스에 중요한 기술이 되었습니다. AI 서비스를 만들기 위해서는 많은 양의 data가 필요한데요, 공개 Datasetpublicly 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의 컴플라이언스에 대한 광범위한 법적 논쟁으로 이어졌다.
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의 공식 출처를 찾는다. (웹사이트, 검색 엔진 등 활용)
그런 다음, 위에 나열한 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의 라이선스를 보고 권리 및 의무를 추출한다.
법률전문가는 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 서비스 제공 업체는 서비스를 위해 소프트웨어를 배포하지 않기 때문에 오픈소스를 사용하더라도 라이선스 의무에서 비교적 자유로울 수 있습니다. 하지만, 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가 적용된 소프트웨어를 배포할 때에는 소스 코드를 제공해야 할 뿐만 아니라 라이선스 전문도 함께 제공해야 합니다.
… and distribute a copy of this License along with the Library.
그럼 LGPL인 Javascript 코드를 Client-side로 전달하면서 어떻게 LGPL 라이선스 전문을 전달해야 할까요?
Heather가 제안한 한가지 방법으로는 SaaS 시스템의 대시보드와 같은 화면 내 오픈소스 고지를 위한 페이지를 만들고 여기에 라이선스 전문을 보여주는 링크를 포함하는 것입니다.
하지만 Heather는 이 방법도 100% 라이선스 조건을 충족한다고 볼 수 있을지에 대해서는 다소 의문을 제기합니다. 사실 대부분의 오픈소스 라이선스의 고지 의무 조항은 웹서비스가 존재하기 훨씬 전에 만들어졌고, 당시의 프로그램 전달 방식만을 고려하여 고지 내용이 설치 프로그램과 함께 전달될 것으로 가정하고 있기 때문입니다.
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하의 코드를 사용할 수 없음을 분명히 하였습니다.
*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.
공개소프트웨어 라이선스 개요 및 소개, 의무사항 준수 방법, 저작권 및 특허권 관련 검토사항, 라이선스 관련 체크리스트, 관리방안, 주요 분쟁사례, 자주하는 질문 등 기업이나 조직에 적용할 핵심 내용을 파악하여 다양한 환경에서 활용 가능하도록 구성
공개소프트웨어 라이선스 가이드는 기업 및 조직의 개발자, 관리자들이 공개소프트웨어 라이선스에 대한 전반적인 개념과 주요 준수사항에 대해 보다 쉽게 이해하고 실무에 활용할 수 있도록 제반 검토사항에 대한 가이드를 제공한다.▲공개소프트웨어 개념 및 정의 ▲공개소프트웨어 라이선스 개념과 의무사항 ▲공개소프트웨어의 저작권 및 특허 이슈 ▲공개소프트웨어 라이선스 양립성 및 듀얼 라이선스 ▲배포 방식에 따른 공개소프트웨어 라이선스 체크리스트 ▲공개소프트웨어 라이선스 관리 ▲공개소프트웨어 라이선스 분쟁사례 ▲공개소프트웨어 라이선스 관련 지원에 대한 내용으로 구성된다.공개소프트웨어를 사용하는 사용자 관점에서는 동일한 공개소프트웨어를 사용하더라도 사용 라이선스와 사용형태, 배포 방식 등에 따라 검토 및 적용해야 할 의무사항이 차별화됨에 따라 본 가이드에서는 자신의 기업이나 조직에 적용할 핵심 내용을 파악하여 다양한 환경에서 활용할 수 있도록 각 구성 항목별로 이해에 도움을 주는 별도의 팁도 제시하였다.
가이드공공부문에서 정보화사업의 ▷기획 단계 ▷계획수립 단계▷사업자 선정 및 계약 단계 ▷사업수행 단계 ▷검사 및 운영 단계 ▷성과평가 단계 등 각 단계별 공개소프트웨어 활용 시 확인해야 할 관련 법령·지침, 고려 및 점검 사항을 제공
공공 공개소프트웨어 거버넌스 가이드는 국내외의 공개소프트웨어 관련 정책 동향과 기술 동향을 수집하여 분석한 결과를 반영하고 국내 공공부문에서 정보화사업을 추진함에 있어 공개소프트웨어를 활용하고 관리할 때 필수적으로 확인해야 하는 관련 법령·지침 및 고려해야 할 실무 관점의 정보들과 접근법을 제공한다.각 장은 ▲정보화사업 공개소프트웨어 관리 필요성 ▲정보화사업 공개소프트웨어 관리로 구성된다.‘정보화사업 공개소프트웨어 관리 필요성’에서는 국내외 각국 정부의 공개소프트웨어 정책 및 활용 사례를 소개하고 정보화사업의 관련 법령 및 지침, 해설서를 정리하고 공개소프트웨어 관리를 위한 관련조항을 설명한다.‘정보화사업 공개소프트웨어 관리’에서는 ▷기획 단계 ▷계획수립 단계 ▷사업자 선정 및 계약 단계 ▷사업수행 단계 ▷검사 및 운영 단계 ▷성과평가 단계 등 단계별 기본 관리점검 프로세스 소개와 단계별로 실무담당자가 참고할 수 있는 지침 및 해설서 목록을 제공하며 공개소프트웨어 관리 점검을 위한 관리요소 및 검토사항 등을 제공한다.
기업에서 소프트웨어 개발 및 공급 시 실무에서 활용 가능하도록 공개소프트웨어를 활용하는 세 가지 경우(사용/기여/공개)로 구분하여 설명하고, 마지막으로는 기업의 공개소프트웨어 거버넌스를 위해 필요한 조직의 구성 방안 제공
기업 공개소프트웨어 거버넌스 가이드는 기업에서 공개소프트웨어를 활용한 소프트웨어 제품 및 서비스의 개발과 출시가 증가함에 따라 공개소프트웨어 기반 소프트웨어 개발 및 공급 시 소스 관리 및 공급 정책, 컴플라이언스 프로세스, 관리 도구, 조직 구성 등 기업에서 공개소프트웨어 거버넌스를 수립에 필요한 가이드는 물론 기업의 입장에서 커뮤니티에 기여하는 방법, 공개하는 방법도 함께 설명한다.각 장은 ▲공개소프트웨어 사용하기 ▲공개소프트웨어 기여하기 ▲공개소프트웨어 공개하기▲OSPO(Open Source Program Office), 공개소프트웨어 프로그램 사무소로 구성된다.각 주제는 이해를 돕기 위해 기업 및 구성원의 입장에 따라 각각 기업 편과 개발자 편으로 나누어 설명한다. 기업 편은 공개소프트웨어 담당자가 정책과 프로세스를 구축하기 위해 알아야 할 사항을 중점적으로 다루고, 개발자 편에서는 기업에 속한 개발자가 공개소프트웨어를 활용하는 데에 필요한 사항을 설명한다.
업무용 PC의 개방형OS 전환 시 필요한 개방형OS 소개, 종류, 도입 절차/범위, 유지관리, 적용 사례 등 소개하여 실무담당자가 개방형OS 도입을 검토함에 있어 전체적인 사업계획에 대한 가이드를 제시
개방형OS 도입가이드는 공개소프트웨어 관련 정책 중 최근 국내에서 활발하게 논의되고 있는 개방형OS 확산 정책과 관련하여 개방형OS를 도입하고자 하는 기관의 개방형OS에 대한 이해를 돕고 개방형OS 도입의 검토 및 실행과정에 유용한 자료로 활용될 수 있도록 실 도입 사례를 바탕으로 설명한다.각 장은 ▲개방형OS 개요 ▲개방형OS 도입 사례 ▲개방형OS 도입 사전 검토사항 ▲개방형OS 도입 사업추진 절차 ▲개방형OS 유지관리 프로세스 ▲개방형OS 도입 가이드 활용으로 구성된다.개방형OS 도입에 대한 다양한 레퍼런스 모델 및 사례 등을 바탕으로 전체적인 사업계획에 대한 가이드를 제시하고 실무담당자가 개방형OS 도입을 검토함에 있어 도입의 절차와 고려사항을 제공한다.
지난 2021년 9월, 중국내 최초의 GPL 관련 판결이 있었다는 중국 기사를 통해 공개되었습니다. 번역기를 활용해 이해한 내용을 정리해보았습니다. 제가 법률가도 아니고, 중국어도 모르다보니 틀린 내용이 있을 수도 있음을 감안해주시기 바랍니다. :) 오류를 발견하신 분은 언제든 알려주시면 감사하겠습니다! (haksung@sk.com)
지난 2021년 4월, 중국에서 저작권 침해 분쟁에 대한 민사 1심 판결이 있었습니다. 피고가 원고가 GPL-3.0으로 공개한 코드를 사용하면서 GPL-3.0의 의무수항을 준수하지 않음으로써 GPL-3.0이 부여한 라이선스 권리가 종료되고, 이로 인해 침해가 구성되었다는 판결입니다. 법원은 침해 사실을 확인하고, 피고에게 500,000 RMB (약 1억 원)의 배상금을 부과하였습니다.
분쟁 주체
이 분쟁의 원고와 피고, 그리고 분쟁 대상 소프트웨어는 다음과 같습니다.
원고
원고는 Jining Luohe Network Technology Co., Ltd 이며, VirtualApp 저작권자입니다.
이후, 2017년 3월부터 7월까지 이 프로젝트를 상용으로 이용하기 위해서는 상용 라이선스 취득이 필요하다는 안내가 여러 차례 추가됩니다.
이러한 라이선싱 정책 변화에 대해 중국 내 한 변호사는 Lody가 개발 초기에는 VirtualApp을 오픈소스 라이선스 하에 무료로 공개하였지만, 나중에 이를 이용하여 수익을 창출하려고 마음이 바뀐 것으로 추측하였습니다.
다만, 이렇게 GPL로 공개한 오픈소스에 조건을 추가하는건 GPL에서 허용하지 않은 방식인데요, Lody는 오픈소스 라이선스에 대하여 제대로 이해하지 못하고 있었기 때문에 GPL-3.0에 위반하는 라이선싱 정책을 시도한 것으로 보인다고 중국 변호사는 언급한 바 있습니다.
2017년 8월, Lody는 VirtualApp(원고)을 설립합니다. 본격적으로 VirtualApp으로 비즈니스를 하겠다는 거죠.
그리고, Lody는 결국, 2017년 10월 29일, GitHub에서 오픈소스 라이선스를 제거합니다.
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월, 법원은 이 사건이 컴퓨터 소프트웨어의 저작권 침해에 관한 분쟁이고 오픈소스와 관련된 문제라고 판결하며 다음과 같은 쟁점에 대한 의견을 제시하였습니다.
쟁점 1. GPL-3.0의 법적 효력 여부
법원은 GPL-3.0이 계약적 성격을 띠고 라이선스 제공자와 사용자 간의 저작권 계약으로 판단할 수 있으며 중국 ‘계약법’의 조정 범위에 해당한다고 판단하였습니다. 더불어 GPL-3.0 위반에 대한 불법 행위 책임을 아래와 같이 설명하였습니다.
GPL-3.0 위반에 대한 불법 행위 책임
저작권법은 저작권자의 배타적 권리를 보호함
복제, 수정, 배포 등의 권리는 저작권자에게만 있음 (저작권자 외에는 “공정 이용"의 범위 내에서만 저작물을 사용할 수 있음)
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을 권리 근거로 주장함. 따라서, 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의 침해 이익을 기반으로 계산하였다고 주장함
그동안 중국은 저작권법 위반에 관대하다는 인식이 많았는데, 영문을 기반으로 한 오픈소스 라이선스의 법적 효력을 인정하고, 라이선스 위반을 저작권 침해로 판결한 점이 인상적이었습니다. 기업은 오픈소스 라이선스 의무를 준수하기 위한 정책과 프로세스를 갖추어야 이러한 분쟁에 휘말리는 위험을 최소화 할 수 있을 것입니다.
피고는 사건을 대법원에 상고한 것으로 알려졌습니다. 피고가 항소심에서 어떤 주장을 펴나갈지 궁금합니다. :)
GPLv2도 설치정보를 요구한다고?
GPLv2도 설치정보를 요구하는가에 대한 저자의 분석 결과를 설명한다.
By 원문 저작자 - P. McCoy Smith, 번역 - 장학성 / CC BY 4.0 |
안녕하세요.
미국의 저명한 오픈소스 라이선스 전문 변호사인 P. McCoy Smith는 최근 JOLTSJournal of Open Law, Technology & Society에 GPLv2가 ‘설치정보’를 요구하는가를 주제로 글을 게재하였습니다.
지난 2021년 3월, SFCSoftware 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
GPLv3GNU General Public License version 3 에서 추가된 주요 특징 중 하나는 소프트웨어 배포 시 소스 코드뿐만 아니라 ‘설치 정보’를 제공해야 한다는 요구사항이다. 이는 GPLv2에 존재하는 loophole (Tivoization)을 해결하기 위해 GPLv3에 새롭게 추가되었다. 그런데 최근에 이 설치 정보 요구 사항이 GPLv2에서도 요구한다고 봐야한다는 주장이 제기되었다.
이 글에서는 GPLv3에 ‘설치 정보’ 요구 사항을 포함하게 된 역사적 근거를 검토하고, 이 요구 사항은 GPLv2가 아닌, GPLv3에서 새롭게 적용된 것임을 설명한다. 또한, GPLv2 텍스트 분석을 통해서도 같은 결과를 도출한다.
1. Introduction
1991년 FSFFree Software Foundation에서 공개한 GPLv2GNU General Public License, version 21은 Copyleft (혹은 Reciprocal) 라이선싱 방식을 채택하였다. Copyleft 방식은 정해진 시기에 지정된 방식대로 소스 코드를 공개하고, 소프트웨어를 재배포할 때에는 동일한 라이선스 적용을 요구한다. 이는 소프트웨어가 “free"로 유지되도록 보장하는 최고의 수단이며, 이는 오늘날에도 여전히 많은 사람에게 인정되고 있다2. 여기서 “free"는 다음과 같다3.
수정 사항을 공유할 수 있는 자유
사용자가 코드로 수행할 수 있는 작업에 대한 자유
사용자가 원하는대로 코드를 수정할 수 있는 자유
그럼에도 불구하고 2005년, FSF는 GPLv2를 출시할 당시 고려하지 못한4 법률적5 그리고 기술적6 문제를 해결하기 위해 라이선스 변경의 필요성을 인식하였다. 이에 따라 FSF는 2006년7부터 2007년까지 GPL의 신규 버전을 만들기 위해 대규모의 협업과 다국적 노력을 시작하였으며, 2007년 6월 29일 GPLv3를 공개하였다8.
2. GPLv3의 ‘설치 정보’ 요구 사항
GPLv2가 광범위하게 사용되던 15년 동안 제기된 문제와 우려를 해결하기 위해 GPLv3에는 수많은 기능이 추가되었다. 그중에서도 가장 주목할만한 (그러면서도 가장 논란이 되는9) 부분은 (1) ‘설치 정보’를 정의한 조항과 (2) GPLv3에 따라 라이센스가 부여된 소프트웨어를 ‘전달convey10‘할 때 어떤 상황에서 설치 정보를 제공해야 하는지를 명시한 조항이다. GPLv3에서의 ‘설치 정보’ 요구 사항이 GPLv2에서 요구하는 요소를 어느 정도 포함하는지, 어느 것은 포함하지 않는지를 이해하려면 두 라이선스에서의 표현과 역사에 대한 자세한 검토가 필요하다.
GPLv3, Section 611(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 소프트웨어의 특정 남용 사례를 해결하기 위하여 포함된 것이다12.
GPLv3의 ‘설치 정보’ 의무에 대한 자세한 요구 사항이나 GPLv3에서 설치 정보 제공을 요구하는 방법과 시기는 이 글의 주제를 벗어난다13. 그럼에도 불구하고 설치 정보 의무가 GPLv2에서도 해당한다고 주장할 수 있는 유사 부분은 무엇인지, 설치 정보 의무가 GPLv3에만 있는 고유한 부분임을 입증하는 근거는 무엇인지, 또 이런 내용이 어떤 과정을 통해 채택되었는지에 대한 일반적인 이해가 필요하다. 따라서 GPLv3에 ‘설치 정보’ 의무가 추가되었던 역사적 배경과 GPLv3에 추가된 특정 표현이 무엇인지, 해당 표현이 GPLv2에 언급된 의무들과 어떻게 다른지 이해하는 것이 중요하다.
3. ‘설치 정보’ 요구사항의 역사적 배경: ‘Tivoization’
2006년경 GPL의 새로운 버전인 GPLv3가 제안되었을 무렵, FSF는 ‘software freedom’ 개념을 잠재적으로 훼손할 수 있는 관행에 대한 우려를 나타냈었다. FSF는 이 관행을 ‘Tivoization14‘이라고 명명하였으며, 당시 FSF는 DVRdigital video recorder 회사인 TiVo가 사용자의 자유를 침해한다고 보았다.
2000년대 중반, TiVo의 특정 DVR 하드웨어 디바이스에는 GPLv2 라이선스인 Linux 커널이 설치되어 있었다. 이 디바이스에는 TiVo 하드웨어 장치에 설치할 Linux 커널 버전을 확인하는 메커니즘이 포함되어 있었다. 이 유효성 검사 메커니즘은 체크섬 또는 암호화 해시 함수를 사용하여 장치에 설치된 커널 버전과 비교하였고, 설치하려는 버전이 특정 체크섬 또는 암호화 해시15와 일치하지 않으면 해당 버전의 Linux 커널 설치를 거부하였다. 이러한 방식으로 TiVo 디바이스는 (하드웨어 제조업체로써 내장된 체크섬 또는 해시값에 대한 필요한 정보를 가진 유일한 주체인) TiVo만 디바이스에 Linux 커널의 인증된 버전을 설치할 수 있도록 허용하였다. TiVo 디바이스 사용자(예: 디바이스를 구입한 고객)가 디바이스에 설치된 커널의 소스 코드를 가져와서 해당 커널을 수정한 후 재설치하려면 수정된 커널로는 체크섬 또는 해시가 달라지게 되므로 수정된 커널이 다시 설치 또는 실행되지 않게 되었다16.
이에 따라 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.”17
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.”18
“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.”19
“TiVoization is described by Peter Brown [Executive Director of FSF in 2006-07 during drafting of GPLv3] as circumventing GPL2 ‘in spirit, not technically.’”20
이러한 차이(‘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.’”21
“‘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.”22
“[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.”23
GPLv3의 ‘설치 정보’ 요구사항에 대해 Torvalds의 의견은 여러 주요 커널 개발자들에 의해 아래와 같이 공유되었다24. Torvalds는 10년이 지난 후에도 일관된 입장을 유지했으며, 이는 오늘날까지 Linux Kernel이 ‘GPLv2 only’ 라이선스를 유지하고 있는 이유 중 하나이다25.
“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.”26
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.”27
“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.”28
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.”29
“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.”30
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.31
5. GPLv2의 소스 코드 공개 의무
1991년 공개된 GPLv2와 같은 Copyleft 라이선스의 가장 주목할만한 특징 중 하나는 GPLv2의 조건에 따라 라이선스가 부여된 코드를 배포distribute[s]32하는 모든 개인이나 단체는 ‘소스 코드’33를 제공해야 하는 의무가 있다는 것이다. GPLv2의 Section 3은 GPLv2하의 코드가 object 혹은 executable code form으로 배포되는 경우 반드시 제공해야 하는 ‘소스 코드’의 구성 요소를 구체적으로 정의한다34.
“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.”35
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’36와 ‘설치 정보’37가 모두 포함된다.
“[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"의 정의 내에 인증키를 제공해야 하는 의무가 포함되어 있었다38. 그러나 인증키와 같은 데이터를 소스 코드와 혼용하여 정의하는 것에 대한 반대 의견이 있었고, 이에 따라 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.”39
따라서, GPLv3의 초안 변경 단계에서 FSF는 ‘설치 정보’ 요구 사항이 GPLv2에 존재하다가 GPLv3에도 포함된 ‘Corresponding Source Code’ 의무를 넘어서는 별도의 의무임을 인식하고 인정한 것이다.
“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을 포함하는 별도의 파일로 해석할 수 있다41. 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.”42
“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).”43
Installation script44는 일반적으로 특정 장치에 특정 프로그램을 설치하는 프로세스를 자동화하는데 사용하는 작고 간단한 프로그램이다45.
따라서, 텍스트 해석의 관점에서, 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’46이다. GPLv3에서의 ‘설치 정보’ 제공 요구 사항은 오직 ‘User Product’에만 적용되며 다른 제품에는 적용되지 않는다47.
“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”48
다시 말하지만, 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.”49
“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.”50
이러한 진술에서와 같이 GPLv3의 (executable을 설치하고 실행하기 위한 정보, recipe, 가이드, 설명 등) ‘설치 정보’ 요구 사항 개념을 GPLv2에 포함해서 GPLv2에서도 설치를 위한 ‘script’를 제공하게 하려는 노력이 현재 진행 중이다. 이러한 노력은 모두 GPLv2의 실제 요구 사항에 반대되는 텍스트conter-textual일 뿐만 아니라 반역사적이다. 다시 말하지만 GPLv2 의 작성자는 GPLv2로는 Tivo에게 수정한 executable을 Tivo 디바이스에 다시 설치하기 위한 필요 정보의 제공을 의무화할 수 없음을 인정하였다51.
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
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). ↩︎
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). ↩︎
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. ↩︎
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). ↩︎
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’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. ↩︎
‘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. ↩︎
2021년 4월, 독일의 유명한 오픈소스 변호사인 Till Jaeger는 Dockerfile이 생성하는 Docker image내 포함될 오픈소스에 대한 라이선스 컴플라이언스 책임은 누구에게 있는가에 대한 글을 발표하였습니다. Till은 독일법과 유럽 연합 사법 재판소CJEU의 판례를 근거로 Dockerfile 제공자가 라이선스 의무를 준수해야 한다고 설명하였습니다.
여기서는 Till의 영어 원본을 국문으로 번역하였습니다. 이해를 돕기 위해 이미지를 추가하였고, 군데군데 개인 의견을 인용구(높임말)로 작성하였습니다.
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“의 개념을 설명한다. 연구를 통해 저작권법 의미에서의 배포가 항상 물리적인 배포여야 하는 것은 아니라는 점이 밝혀졌다.
이 글은 OSADLOpen Source Automation Development Lab로부터 자금 지원을 받고, 공동으로 작성하였다.
1. 소개 및 문제점
Docker 기술과 관련된 FOSS 라이선스 컴플라이언스 문제는 최근 몇 년 동안 주요 연구 대상이 되었다. 특히 Docker의 기술적 토대를 설명하고 관련된 라이선스 컴플라이언스 문제를 제기한 Armijn Hemel의 백서인 “Docker Containers for Legal Professionals”1는 광범위한 분석 내용을 제공한다. Hemel은 Dockerfile의 수신자가 이를 사용하기 위하여 제삼자로부터 소스 파일을 다운로드받게 되는데, 이때 다운받는 소프트웨어 컴포넌트에 대한 라이선스 컴플라이언스 책임은 누구에게 있는가에 대해 공개적으로 질문을 제기하였다.
거의 모든 FOSS 라이선스는 라이선스 의무 준수를 “배포distribution” (또는 GPL-3.0의 “전달conveying“와 연결시킨다. 대부분의 라이선스는 라이선스 내에서 “배포” 또는 “전달"이 무엇인지에 대해 추가로 정의하지는 않기 때문에, “배포"의 정의는 적용되는 저작권법에 따라 판단해야 한다2.
대부분의 오픈소스 라이선스는 오픈소스를 “재배포"하는 시점에 준수해야 할 라이선스 의무 사항을 요구합니다. 즉, 오픈소스를 재배포하지 않는다면 라이선스 의무 준수가 요구되지 않습니다.
“배포"의 범위를 어디까지로 판단해야 할지는 해당 지역에 적용되는 저작권법에 따라 해석해야 합니다.
라이선스 컴플라이언스에 대한 중요성 때문에 “배포"라는 용어는 계속해서 법적인 분석 대상이 되고 있다. Heather Meeker는 미국 저작권 관점에서 오픈소스 라이선스에서의 배포를 주제로 글을 작성하였다3. 많은 오픈소스 라이선스가 미국 저작권법을 배경으로 작성되었지만, 유럽 법원은 CJEU(유럽 연합 사법 재판소)Court of Justice of the European Union에서 정교하게 설명한 “배포"에 대한 정의를 바탕으로 판결할 것으로 예상한다.
이 글에서는 먼저 Docker의 기술적인 기본 사항에 대한 개요와 유럽 저작권법에 따른 “배포"라는 용어에 대한 해석을 제공한다. 이어서 Dockerfile을 배포할 때 라이선스 컴플라이언스를 누가 책임져야 하느냐에 대해 논의하겠다.
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를 형성하는 이른바 “레이어"로 추가될 수 있다.
“Dockerfile"은 스크립트와 유사하게 Docker image를 만들기 위한 단계별 명령을 포함하는 텍스트 파일이다. Dockerfile은 일반적으로 Dockerfile 자체에만 적용되는 자체 라이선스를 가질 수 있으며, 이 라이선스는 Docker 컨테이너에 포함되는 프로그램에는 적용되지 않는다.
Docker 컨테이너용 관리 소프트웨어인 “Docker 엔진"은 Dockerfile의 명령을 순차적으로 처리하여 Docker image를 생성한다. 일반적으로, Base image나 개별 레이어를 위한 각 컴포넌트는 내부 또는 외부 저장소에서 다운로드된다. 이는 제공자가 Dockerfile을 제공하더라도 물리적인 프로그램 코드를 전달하지 않는 것이 가능함을 의미하고, 이런 일은 실제로 관례적이다. 고객은 전달받은 Dockerfile을 가지고 자체적으로 공개 저장소로부터 전체 혹은 일부 프로그램 코드를 받아와서 Docker 컨테이너를 구축할 수 있다.
https://cultivatehq.com/posts/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에 비추어 해석되었다4. 독일 및 유럽 최고 법원인 독일 연방 사법 재판소German Federal Court of Justice, Bundesgerichtshof (BGH)와 유럽 연합 사법 재판소Court of Justice of the European Union (CJEU)는 수많은 법원 판결에서 배포권을 해석하는 데 도움이 되는 기여를 했다. 이에 대해서는 아래에서 자세히 설명한다.
4. Dockerfile의 배포 - 분석
이 섹션에서는 먼저 저작권법에 따른 배포가 프로그램 코드의 물리적인 전송을 반드시 요구하는지 여부에 대해 살펴본다. 이후에는 Docker image의 다양한 구성 요소, 즉, Base image, 프로그램 라이브러리, 패치 및 업데이트에 관해 설명한다.
4.1 프로그램 코드의 물리적인 배포가 있어야만 배포인가?
아래의 첫번째 경우뿐만 아니라 두번째 경우도 “배포"에 대한 책임은 Dockerfile 제공자에게 있다.
저작권 법에서 정의된 배포의 개념인 프로그램 복사본의 “물리적” 배포
제삼자로부터 프로그램 복사본을 취득하게 하는 기타 행위
독일과 EU의 최고 법원이 다음의 두가지를 모두 고려되어야 한다는 판결을 자주 했음을 주목하자.
물리적 행위
복제 또는 배포와 법적으로 관련된 행위를 물리적으로 수행하는 제삼자는 단순히 당사자의 “도구"로 간주됨
이러한 측면에는 특히 CJEU가 “필수적 역할essential role“이라고 부르는 조직적 통제organizational control를 포함한다5. 한가지 예는 독일 연방 사법 재판소BGH의 “인터넷 라디오 음악 녹음 서비스” 판결이다. 이 판결은 인터넷 서비스에 의한 디지털 라디오 방송국의 완전 자동 녹음이 클라이언트의 개인 복사본인지 (허가) 혹은 서비스 제공자의 복사본인지에 (무허가) 대해 다룬다. 이에 대해 BGH는 다음과 같이 명시하였다6.
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년 자료7를 참고할 수 있습니다.
이 판결의 원고는 음반 제작자인 독일 소니 뮤직(Sony Music)이며, 피고는 인터넷 라디오에서 방송되는 음악을 녹음하여 제공하는 서비스를 운영하는 MusicMonster.FM입니다.
독일 법원은 피고의 서비스는 복제를 위한 기술적 수단을 단순히 제공하는 것을 넘어서고 사적 이용으로 정당화되는 범위를 초과하기 때문에 피고가 복제 및 공중접근의 행위자이고, 피고가 원고의 복제권과 전송권을 침해하였다고 판결하였습니다.
CJEU는 저작권 침해 행위와 관련하여 누가 “필수적 역할essential role“을 하였는지에 대한 몇 가지 판단을 근거로 삼았다. 이는 특히 §17 UrhG(독일 저작권법)에서 명백하게 드러난다. UrhG는 단순한 “제안offer” 행위, 즉 물리적 배포의 준비 행위preparatory act of a physical distribution도 배포 행위act of distribution라고 지정하였다8.
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나 레이어를 다운로드할 수 있는 저장소의 운영자도 각각 프로그램 코드의 배포 행위를 수행하거나 “공개적으로 이용할 수 있게 한다"는 사실과 충돌하는건 아니다9. 이는 대부분의 Base image나 레이어는 특정 컨테이너를 위해서만이 아니라 일반적인 다운로드도 제공하기 때문이다. 일반적인 다운로드의 경우, 저장소 운영자가 아닌 저장소를 통해 Base image나 레이어를 제공하는 개인 또는 단체가 배포(또는 대중과의 통신) 행위를 잠재적으로 수행하는 것으로 볼 수 있다.
4.2 패치
추가 레이어를 사용하면 이미 설치된 프로그램도 수정할 수 있다. 이 경우, Docker 컨테이너는 수정되지 않은 프로그램을 한 레이어에 포함하고 수정한 프로그램을 다른 레이어에 포함하여 수정된 프로그램이 실행되도록 한다. 이러한 상황에서도 Dockerfile에는 적용될 수정사항이 정의되어 있기 때문에 Dockerfile 제공자는 “필수적 역할"의 책임을 맡아야 한다. 따라서, Dockerfile 제공자가 수정사항에 대한 라이선스 의무를 준수해야 한다.
이는 두 버전이 모두 수신자에게 배포되기 때문에 (수정된 버전만 실제 사용되더라도) 수정된 버전 뿐만 아니라 원 버전에도 적용된다는 사실에 주의해야 한다10. 프로그램이 새 레이어에 의해 제거되더라도 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."
Base image도 시스템 요구 사항으로 간주할 수 있을까? 일반적으로 Base image에 포함되는 프로그램은 Docker 컨테이너에서 실행되는 애플리케이션과 독립적이다. Base image에 포함된 프로그램이 수정되지 않은 형태로 사용되는 한, Dockerfile에 다운로드 명령이 포함되어 있다고 해도 Dockerfile 제공자가 Base image의 제공자는 아니기 때문에 Base image는 시스템 요구 사항으로 간주할 수 있다. 또한, Repository 운영자가 액세스를 거부한다면 더 이상 다운로드가 불가능하다. 이런 사실에 비추어볼때 Base image는 Dockerfile 제공자의 통제를 벗어난다. 패치의 경우에도 비슷하지만 패치와 시스템 요구 사항은 다르게 처리해야 한다.
컴퓨터 프로그램은 일반적으로 다른 독립 프로그램과 작동한다. 이는 다른 형태의 저작물과 구별되는 특징이다. 예를 들어 대부분의 애플리케이션은 운영 체제 없이 실행되지 않는다. 하지만 이러한 애플리케이션 실행을 위해 시스템 요구 사항을 설치해야 한다고 해서 애플리케이션 제공자가 시스템 요구 사항 배포의 필수적 역할essential role을 한다는 것을 의미하지는 않는다.
이런 상황은 다운로드 링크와 다소 비슷하다. 저작권이 있는 저작물을 다운로드하는 링크가 저작권법이 적용되는 관련 행위를 구성하는지, 즉 대중에게 전달하는 행위(따라서 저작권 침해를 초래할 가능성이 있음)에 해당하는지 여부에 대한 문제가 EU에서 치열하게 논의되고 있다. CJEU는 이에 대하여 일련의 복합적인 기준을 설정하였다11. 이 기준은 특히 다음과 같은 사례별 질문을 제시한다. : 새로운 구매자 그룹에 공개되어 있는지 여부, 의도된 용도가 상업적 목적인지 여부, 해당 행위가 제안에 중요한 역할을 하는지 여부, 제안이 불법인지 여부. 이렇게 사례별로 다뤄야하며 포괄적인 판단은 거의 불가능하다. 사실 회원국에서는 이러한 기준을 고려하는 경우가 흔하지 않았다. 그럼에도 이런 기준을 만든건 아마도 인터넷 저작권의 법적 상황을 더 잘 조화시키려는 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가 라이선스를 준수하는지 여부를 검토해야 한다12.
Docker image를 단순히 조직 내부에만 사용하려는 수신자라면, FOSS 프로그램의 단순한 실행은 제한되지 않기 때문에, 문제없이 사용할 수 있다. 예를 들어, GPL-2.0 4조에서는 이를 명확히 말하고 있다13. 그러나, 수신자가 Docker image를 재배포하려고 한다면, Dockerfile의 배포가 저작권을 침해하는 경우라면 배포권이 소진되는 것이 아니기 때문에, 재배포하려는 수신자는 라이선스 조건의 컴플라이언스를 보장해야 한다(아래의 4.6절 참조).
4.4 프로그램 라이브러리
프로그램과 연결된 라이브러리의 경우, 이러한 라이브러리가 독립적인 프로그램으로 간주되는지 또는 링크된 프로그램의 일부가 되는건지에 대해서는 약간의 의견 차이가 있다14. 이러한 맥락에서 다음과 같이 구분할 수 있다.
시스템 라이브러리
GPL 및 AGPL 애플리케이션과 연결되는 비시스템 라이브러리non-system library
GPL 및 AGPL 이외의 다른 라이선스의 애플리케이션과 연결되는 비시스템 라이브러리
GPL-2.0 섹션 3 및 GPL-3.0 섹션 1 (3)에는 라이선스 의무 중 소스 코드를 제공해야 하는 범위 내에 “시스템 라이브러리"는 면제하는 조항이 포함되어 있다15. 따라서 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"로 지정한 경우가 그렇다.
하지만, 만약 관련 Repository에서 라이선스 의무를 완전히 충족하지 않는다면, Dockerfile 제공자는 독립적으로 라이선스 의무를 준수하고 필요한 필수 정보(예 : 라이선스 텍스트, 저작권 고지, 소스 코드 제공)가 포함된 파일을 함께 제공하는 것이 좋다.
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
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.” ↩︎
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]. ↩︎
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]. ↩︎
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]. ↩︎
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]. ↩︎
For efforts of Red Hat to improve the situation see Peterson, S., ibid. ↩︎
“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.” ↩︎
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]. ↩︎
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.” ↩︎
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 Group1은 Talk Openly, Develop Openly를 표방하며 협업을 통해 성공적인 오픈소스 프로젝트와 프로그램을 만들어가고자 하는 Linux Foundation 산하의 그룹2입니다. TODO 그룹에서는 오픈소스 가이드3, 도구4 등을 함께 만들어서 공개하며 오픈소스에 관심 있는 누구나 활용할 수 있게 하고 있습니다.
기업 등의 조직이 오픈소스를 효과적으로 관리하고 사용하기 위해서는 OSPOOpen Source Program Office를 설립하여 개발자 교육, 컴플라이언스 보장, 커뮤니티 참여 및 구축, 오픈소스 공개, 코드 점검 등의 활동이 필요하다고 합니다. 이 글에서는 OSPO가 무엇이고, 어떤 역할을 하는지에 대해 TODO Group에서 정의한 글5을 옮겼습니다.
Photo: TODO Group
OSPO의 정의
OSPOOpen Source Program Office는 조직의 오픈소스 운영을 위해 조직의 중앙에 역량을 집중하도록 설계되었다. 여기에는 오픈소스의 사용, 배포, 선택, 검사 및 관련 정책 수립뿐만 아니라 개발자 교육, 컴플라이언스 보장과 조직에 이익이 되는 커뮤니티 참여와 구축을 촉진하는 활동이 포함될 수 있다.
모든 산업에 걸쳐 적용할 수 있는 오픈소스 프로그램을 구축하기 위한 광범위한 템플릿은 없지만, 여기에서는 일반적인 OSPO의 기능을 세 가지로 분류해보았다.
법적 위험 완화Legal Risk Mitigation
엔지니어 작업 방식 개선Improving Engineers’ Practices
재정적 이익 실현Enabling Financial Benefits
이렇게 세 가지로 분류해보니 각각 두려움Fear, 사랑Love, 돈Money이 연상된다.
법적 위험 완화
기업의 주된 관심사는 법적인 컴플라이언스이다. 따라서, OSPO는 기업의 오픈소스 라이선스 컴플라이언스 프로세스를 구축하고 관리한다. 일반적으로 소프트웨어를 배포하는 기업은 이 문제에 가장 관심이 많으며, 이러한 법적 위험을 완화하기 위해 OSPO의 설립을 시작한다.
OSPO는 법적 위험 관리를 위해 다음과 같은 책임을 가진다.
오픈소스 라이선스 컴플라이언스 관리 감독
인바운드 코드주: 오픈소스 등 외부로부터 입수한 코드 사용을 위한 검토 프로세스 실행
오픈소스 프로젝트에 효과적으로 기여하도록 보장
엔지니어 작업 방식 개선
OSPO는 오픈소스 환경에서 코드 관리에 대한 가이드와 정책을 제공함으로써 엔지니어링 기능을 개선한다. 소프트웨어 엔지니어가 많은 기업은 OSPO를 엔지니어링 정책과 작업 방식에 집중한다.
이와 관련한 OSPO의 책임은 다음과 같다.
기업의 오픈소스 전략을 기업 내부 및 외부에 명확히 전달
조직 내 오픈소스 문화 육성
오픈소스 커뮤니티에 고품질의 코드를 자주 공개하도록 보장
재정적 이익 실현
일부 기업은 오픈소스에 관한 재정적 이익에 초점을 맞춘다. OSPO를 활용하여 상용 벤더를 사용할지 아니면 오픈소스 벤더를 사용할지에 대한 전략을 수립한다. 반면 일부 기술 기업은 자신의 OSPO (및 오픈소스 프로젝트)를 활용하여 고객이 자신의 상용 제품을 구매하도록 유도한다.
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가 나온 배경에 대한 한 측면을 이해하는 데 도움이 되는 글이라 생각합니다.
글에 오류가 있다면 언제든 연락해주세요. :-)
감수에 도움 주신 카카오의 Sean, Robin 그리고 LG전자의 김경애님에게 깊은 감사 드립니다.
최근, 2021년 2월, Elastic은 소프트웨어 제품에 Elastic License 2.0이라는 새로운 라이선스를 도입하였다. 이 라이선스 모델은 Elasticsearch, Kibana 등 주요 소프트웨어 제품군에 적용되었다. 이런 변화의 목적과 의미하는 바가 무엇인지 알아보자.
Elastic License 2.0은 개방형 개발 모델Open Development Model로 사업하는 기업이 취할 수 있는 대표적인 라이선스 모범 사례이다. Elastic License 2.0은 오픈소스 라이선스는 아니지만, 소프트웨어의 사용, 공유 및 변경의 자유와 커뮤니티에 해를 끼는 행동 방지 간의 공정한 균형을 유지하는 데 필요한 최소한의 제한 설정을 목표로 한다.
유닉스, 리눅스, 자유소프트웨어, 그리고 오픈소스
Elastic License 2.0과 같은 새로운 라이선스의 추세를 이해하려면 오픈소스 라이선스 운동이 어떻게 성장했는지 살펴보는 것이 도움이 된다.
오픈소스와 자유소프트웨어Free Software 운동은 소프트웨어가 사유화되는 것에 대한 개발자의 우려에서 시작되었다. 이러한 우려의 불씨는 당시 가장 인기있는 운영체제인 유닉스였다. 유닉스의 개발사인 AT&T Bell Labs은 1956년의 동의령consent decree에 따라 유닉스 및 C언어를 포함하는 연구 프로젝트로 이익 얻는 것을 금지1 당했으며, 이때문에 수년간 매우 관대한 조건의 라이선스로 유닉스를 배포하였다. 학계, 연구자, 개발자들은 유닉스를 수정/개선하여 공유하기 시작했고, 유닉스는 곧 운영체제 분야의 선두가 되었다. 하지만, 1983년 동의령이 해제되자 AT&T는 유닉스에 수정 사항 공유를 허용하지 않는 조항을 적용하였다. 이에 따라 각 업체별로 각자 수정한 운영체제를 사용하며 유닉스는 많은 호환되지 않는 종류로 쪼개졌고, 사용자들은 더 이상 협업할 수 없게 되었다.
유닉스가 사유화되면서 자유소프트웨어 운동, 그리고 이어서 오픈소스 운동이 생겨났으며, 이들은 인프라 소프트웨어가 폐쇄되는 상황이 다시 발생하는 것을 방지하려고 하였다. 이 운동은 유닉스를 대체하는 자유소프트웨어인 리눅스를 중심으로 이루어졌으며 곧 모든 소프트웨어는 자유free(무료free 맥주에서의 Free가 아니라 언론의 자유free에서의 Free)로워야 한다는 철학에 기반한 더 큰 운동으로 발전하였다. 이러한 운동의 한 요소는 소스 코드에 대한 접근, 개선 및 변경 사항을 만들고 공유할 수 있는 권리이다. 이러한 원칙들은 GNU General Public License (GPL)에서 구현되었으며, 이에 따라 바이너리 배포자들은 해당 소스 코드를 공유해야 한다.
시간이 흐르고, 2000년대 초반 인터넷 붐에 힘입어 오픈소스 라이선스는 더욱 인기를 얻게 되었다. GPL과 같은 일부 라이선스는 복잡한 법적 우려를 불러일으키기도 했지만, 기업이 협업할 수 있는 기반을 마련하였다. 2000년 이후 오픈소스와 이를 통해 가능해진 협업은 모든 기술 부문에 채택되었다. 오늘날, 오픈소스는 전자상거래e-commerce의 핵심 기술이며, 기업들은 소프트웨어 인프라를 위한 지속해서 협력한다.
클라우드의 출현과 AGPL
GPL과 같은 라이선스는 변경 사항의 공유를 요구한다. 바이너리 배포에 대한 소스 코드 공유 조건을 부과한다. 반면에 “개인 복사본"을 만들어서 사용하는 건 변경 사항을 공유할 필요가 없다. 이러한 조건은 당시 대부분의 소프트웨어를 직접설치on-premise하는 방식이었기 때문에 공유를 강제하는 데 효과적이었다. 그러나 2000년대 초부터 소프트웨어는 퍼블릭 클라우드로 이동하기 시작하였고, 더 이상 소프트웨어를 배포할 필요가 없었다. 고객은 로컬 사본을 얻지 않고도 소프트웨어를 사용할 수 있게 되었다.
클라우드 서비스 사업이 커지면서, 이러한 패러다임의 변화는 오픈소스 커뮤니티의 기대치와 AWSAmazon 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라면서 비판하기도 하였다. 여하튼, 그렇게 강력하다고 평가 받던 AGPL의 소스 코드 공유 조건도 클라우드 공급 업체가 오픈소스를 대규모로 상업적인 사용을 하면서 개발자나 커뮤니티에 아무것도 되돌려 주지 않는 행위를 막기에는 충분하지 않았다.
무상 사용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 상용)로 사업을 하고 있었는데, 클라우드 제공 업체에서 이 오픈소스 프로그램을 그대로 가져다가 클라우드 서비스로 제공하는 사업을 하고, 자기네한테는 아무런 이윤도 안겨주지 않으니, 사업 또는 개발 측면에서 모두 좋지 않은 영향을 미쳤을 것은 충분히 추측할 수 있습니다.
오픈소스 상용 기업들과 투자자들은 이런 오픈소스 모델의 한계 때문에 고민이 되었다. GPL, AGPL 등 어떤 라이선스도 저작권법을 사용하여 클라우드 공급 업체가 변경 사항을 공유하도록 강제할 수 없었다. 또한 AWS, Azure 또는 Google Cloud와 같은 대규모 고객 기반을 가진 클라우드 공급 업체는 버튼 클릭으로 소프트웨어를 쉽게 추가할 수 있게 하여 고객과 “끈끈한” 관계를 유지하였다. 일부 오픈소스 개발사는 자체 클라우드 서비스를 제공했지만, 소프트웨어를 무료로 사용하는 대형 클라우드 공급 업체와 경쟁하는 건 너무 어렵다는 걸 알게 되었다. 오픈소스 개발사의 서비스가 더 우수한 경우에도, 기존 클라우드 계정에서는 단지 “체크박스를 선택"하여 소프트웨어 제품군을 추가하는 것과는 달리, 새로운 서비스를 사용하기 위한 거래 비용transaction cost이 발생한다는 점이 고객이 등을 돌리게 하였다.
SSPL과 소스 공개 라이선스
2018년 업계는 돌파구를 찾았다. AWS가 오픈소스 플랫폼 소프트웨어를 호스팅하면서 계속 인기를 얻자 오픈소스 개발사들은 행동에 나서기 시작하였다. 라이선스를 변경하였다.
이 두 범주 모두 이전에는 정의되지 않았던 형태이다. 둘 다 MySQL 및 MongoDB 에서와 같은 듀얼 라이선스 모델을 지원하기 위한 것이다.
SSPL
매우 강한 카피레프트 접근 방식은 2018년 SSPLServer 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을 OSIOpen Source Initiative에 승인받기 위해 제출하였다. 수개월 간의 논쟁 끝에 승인을 받지는 못하였지만, MongoDB는 듀얼 라이선스 모델의 오픈소스 선택지로 SSPL을 계속 사용하고 있다. 이 라이선스가 오픈소스 정의Open Source Definition에 적합하지 않은 이유에 대한 논의는 복잡했으며, 이 정의를 충족하는 것만이 유일한 기준은 아니었다. 요약하자면, 이렇게 광범위한 소스 공유 요구 사항을 가진 라이선스가 “소프트웨어 자유를 보장“할지가 분명하지 않았다.
제한 조건을 갖는 소스 공개 라이선스
다른 사람들은 또 다른 경로를 따랐다. 일부 회사는 Salil Deshpande가 주도한 Commons Clause를 채택했으며, 어떤 회사는 Elastic이 Elastic License 1.0을 만든 것처럼 Redis, Confluent, CockroachDB와 같은 자체 라이선스를 제작하였다. SSPL과는 달리, 이 라이선스들은 오픈소스 정의를 충족시키기 위한 것이 아니었다. 대신, 이들은 무상 사용을 겨냥한 제한 조건을 갖고 있다.
왜 이렇게 두 가지 경로로 갈렸을까? 이는 Freedom Zero, “어떤 목적으로든 원하는 대로 프로그램을 실행할 수 있는 자유"와 관련이 있다2.
오픈소스 또는 자유소프트웨어 라이선스의 주요 특징은 라이선스 제약이나 제한이 없다는 것이다3. 일반적인 상용 소프트웨어 라이선스와 비교해보자. 개인용으로 사용하겠다는 라이선스 조건에 클릭하여 수락하는 형태의 최종 사용자 라이선스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은 이러한 추세에 따라 사용 가능한 옵션을 발전시켰다.
“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. ↩︎
The Free Software Definition is similar to the Open Source Definition, but shorter and clearer. ↩︎
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. ↩︎
Enterprise Software 개발 및 컨설팅을 하는 EPAM 에서는 Github 사용량을 측정하여 OSCI (Open Source Contributor Index) 이라는 랭킹 서비스를 제공하고 있습니다.
공개적으로 활용 가능한 Github 커밋 이벤트 데이터를 사용하여 상업 조직의 구성원들의 기여를 측정합니다. 대학, 연구기관 및 무료 이메일 공급자의 기여는 포함되지 않았다고 합니다. 10개 이상의 커밋을 수행한 기여자가 대상이며, 자체 연구한 알고리즘에 의해 활동량 점수를 측정한다고 합니다. 알고리즘은 OSCI Github 에 공개되어 있습니다.
분석 점수에 따르면 구글이 선두에 위치해 있으며, 마이크로소프트, 레드햇이 각각 다음 순위를 차지했습니다. 한국 기업으로는 삼성이 29위, LG 전자가 71위에 랭크 되어 있습니다.
기업별 라이선스 현황
OSCI를 통해 수집된 데이터로 추출된 오픈소스 라이선스 사용조사 도 주목해 볼만 합니다. Google Big Query 같은 툴을 이용하여 측정은 가능했지만 어뷰징 제거 등 유효한 데이터 필터링 안되어서 신뢰도가 낮은편이었는데, OSCI를 구축하면서 의미있는 Github 저장소들을 대상으로 통계를 낸 거라 유용할 것으로 보입니다.
2018 년 초부터 2020 년 중반까지 GitHub에서 생성 된 새로운 공용 리포지토리의 라이선스 선택을 조사했으며, 인기있는 오픈 소스 호스팅 플랫폼의 패턴을 비교하기 위해 GitLab에서 1 년간의 데이터도 함께 연구했다고 합니다.
GitHub 새로운 Repository의 급격한 증가
GitHub에서 생성 된 리포지토리 수가 지난 2 년 반 동안 급격하게 증가하고 있음을 보여줍니다. 이러한 오픈소스의 증가세는 특히 주목해야 하는 트랜드입니다.
2018 년 이후 라이선스 사용 동향
2018 년 초부터 생성 된 저장소를 살펴보면 몇 가지 추세가 두드러집니다.
리포지토리의 34 %가 라이선스 파일을 포함하지 않아 오픈 소스 상태에 문제가 있습니다.
리포지토리의 21 %가 GitHub에서 표준 라이선스 유형으로 인식되지 않습니다. 이는 일반적으로 라이선스 파일에 사용자 정의 라이선스 텍스트가 포함되어 있기 때문입니다. 종종 표준 라이선스 텍스트의 사소한 편집 만 포함합니다. 마지막으로, 가장 중요한 것은 Apache 2.0과 MIT가 가장 많이 사용되는 두 가지 라이선스 유형이며 전체 저장소의 총 35 % 이상입니다.
라이선스 파일이없는 리포지토리를 제외하면, 리포지토리의 절반 이상이 Apache 2.0 또는 MIT 라이선스를 사용합니다. 리포지토리의 1/3은 특정 형태의 사용자 지정 라이선스 텍스트를 사용하며 나머지 13 %에는 BSD 및 Gnu Public License의 변형이 가장 일반적인 다양한 라이선스가 포함되어 있습니다.
GitHub의 조언에도 불구하고 라이선스 파일없이 생성 된 리포지토리. 데이터는 많은 개별 기여자들이 오픈 소스 프로젝트에 라이선스 파일을 포함하는 것의 중요성을 이해하지 못하고 있음을 시사합니다.
OSCI 순위 상위 5 개 회사의 라이선스 사용
상업 조직에 대한 그래프는 GitHub에서 분석 한 모든 리포지토리와 비교하여 다른 차트를 보여줍니다. Apache 2.0은 지금까지 가장 많이 사용되는 라이선스이고 그 다음으로 사용자 지정 라이선스 텍스트가 있습니다. MIT 라이선스는 상당한 인기를 얻은 유일한 다른 표준 라이선스입니다. 카피 레프트 라이선스는 거의 사용되지 않습니다. 마지막으로, 라이선스 파일이없는 리포지토리 수가 적지 않습니다. 샘플을 수동으로 연구 한 후에는 대부분 코드가 아닌 저장소 (예제 또는 문서)입니다.
상위 5개 기업을 각각 개별적으로 살펴보면 그 결과가 흥미롭고 기업 선호도가 서로 다릅니다.
Apache는 Google, IBM 및 Red Hat에서 가장 선호하는 라이선스입니다. Microsoft에서 대부분의 라이선스는 사용자 지정 텍스트이며 MIT가 다음으로 선호되는 표준 라이선스 유형입니다. 사용자 지정 라이선스 텍스트 중 일부를 수동으로 검토 한 결과 실제로 MIT (코드 저장 소용) 및 CreativeCommons (문서 용)가 종종 있음을 발견했습니다.
대조적으로 Intel은 훨씬 더 다양한 라이선스 유형을 사용하는 것으로 보이며 Apache가 가장 선호되고 사용자 지정 라이선스 텍스트와 3-Clause BSD가 그 뒤를 따릅니다. Intel 용 리포지토리의 사용자 지정 라이선스 텍스트에 대한 수동 연구는 Apache 2.0, 3-Clause BSD 및 기타 표준 라이선스 유형을 기반으로 한 혼합 텍스트를 보여줍니다.
GitLab 분석
2019 년 2 분기부터 2020 년 1 분기 말까지 12 개월 동안 GitHub 결과와 매우 다른 패턴이 나타 났습니다. 특히 이 기간에 생성 된 공용 저장소의 77.7 %는 라이선스 파일이 없습니다. 이것은 개발자가 오픈 소스 라이선스 선택의 필요성과 가치를 다시 한번 인식하지 못한다는 것을 의미합니다. 또한 GitLab과 GitHub에서 오픈 소스 프로젝트를 만드는 사용자의 일부 차이를 반영 할 수 있으며 기업 사용에 비해 개별 사용이 더 많습니다.
라이선스 파일이없는 리포지토리를 제외하면 아래 이미지는 MIT가 37 %로 가장 인기가 많았고, 사용자 지정 라이선스 텍스트가 21 %, GPL 3.0이 17 %, Apache 2.0이 10 %로 그 뒤를이었습니다. GitLab에서 요약하면 허용 라이선스 유형이 다시 가장 많이 사용되는 유형이지만 MIT가 리더이며 Apache 2.0 사용량은 GitHub보다 훨씬 적습니다. 카피 레프트 라이선스는 GitLab과 GitHub에서 비슷하게 적은 점유율을 가지고 있습니다.
결론
다음과 같은 많은 흥미로운 결과를 보여줍니다.
Apache 2.0 및 MIT가 확실한 리더로서 허용 라이선스 유형에 대한 추세가 증가하고 있습니다.
카피 레프트 라이선스 유형은 약간 사용됩니다.
라이선스 없이 생성되는 저장소가 점점 늘어나고 있으며, 이는 특히 개별 개발자가 오픈 소스의 법적 측면을 이해하지 못할 수 있음을 시사합니다.
사용자 지정 라이선스 유형은 특히 상업 조직에서 널리 사용됩니다. 대부분의 경우 표준 라이선스 유형을 기반으로하는 것으로 보입니다.
OpenChain KWG News in 2020
OpenChain, ISO 표준 등록
오픈소스 컴플라이언스에 대한 국제 표준, ISO/IEC 5230:2020
By OpenChain Project |
지난 2020년 12월 15일, OpenChain 규격 2.1이 국제 표준인 ISO/IEC 5230:2020로 공식 Publication 되었습니다.
Text can be bold, italic, or strikethrough. Links should be blue with no underlines (unless hovered over).
There should be whitespace between paragraphs. There should be whitespace between paragraphs. There should be whitespace between paragraphs. There should be whitespace between paragraphs.
There should be whitespace between paragraphs. There should be whitespace between paragraphs. There should be whitespace between paragraphs. There should be whitespace between paragraphs.
There should be no margin above this first sentence.
Blockquotes should be a lighter gray with a border along the left side in the secondary color.
There should be no margin below this final sentence.
First Header
This is a normal paragraph following a header. Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong. Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong. Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.
Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.
On big screens, paragraphs and headings should not take up the full container width, but we want tables, code blocks and similar to take the full width.
Lorem markdownum tuta hospes stabat; idem saxum facit quaterque repetito
occumbere, oves novem gestit haerebat frena; qui. Respicit recurvam erat:
pignora hinc reppulit nos aut, aptos, ipsa.
Meae optatos passa est Epiros utiliter Talibus niveis, hoc lata, edidit.
Dixi ad aestum.
Header 2
This is a blockquote following a header. Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.
Header 3
This is a code block following a header.
Header 4
This is an unordered list following a header.
This is an unordered list following a header.
This is an unordered list following a header.
Header 5
This is an ordered list following a header.
This is an ordered list following a header.
This is an ordered list following a header.
Header 6
What
Follows
A table
A header
A table
A header
A table
A header
There’s a horizontal rule above and below this.
Here is an unordered list:
Salt-n-Pepa
Bel Biv DeVoe
Kid ‘N Play
And an ordered list:
Michael Jackson
Michael Bolton
Michael Bublé
And an unordered task list:
Create a sample markdown document
Add task lists to it
Take a vacation
And a “mixed” task list:
Steal underpants
?
Profit!
And a nested list:
Jackson 5
Michael
Tito
Jackie
Marlon
Jermaine
TMNT
Leonardo
Michelangelo
Donatello
Raphael
Definition lists can be used with Markdown syntax. Definition terms are bold.
Name
Godzilla
Born
1952
Birthplace
Japan
Color
Green
Tables should have bold headings and alternating shaded rows.
Artist
Album
Year
Michael Jackson
Thriller
1982
Prince
Purple Rain
1984
Beastie Boys
License to Ill
1986
If a table is too wide, it should scroll horizontally.
Artist
Album
Year
Label
Awards
Songs
Michael Jackson
Thriller
1982
Epic Records
Grammy Award for Album of the Year, American Music Award for Favorite Pop/Rock Album, American Music Award for Favorite Soul/R&B Album, Brit Award for Best Selling Album, Grammy Award for Best Engineered Album, Non-Classical
Wanna Be Startin’ Somethin’, Baby Be Mine, The Girl Is Mine, Thriller, Beat It, Billie Jean, Human Nature, P.Y.T. (Pretty Young Thing), The Lady in My Life
Prince
Purple Rain
1984
Warner Brothers Records
Grammy Award for Best Score Soundtrack for Visual Media, American Music Award for Favorite Pop/Rock Album, American Music Award for Favorite Soul/R&B Album, Brit Award for Best Soundtrack/Cast Recording, Grammy Award for Best Rock Performance by a Duo or Group with Vocal
Let’s Go Crazy, Take Me With U, The Beautiful Ones, Computer Blue, Darling Nikki, When Doves Cry, I Would Die 4 U, Baby I’m a Star, Purple Rain
Beastie Boys
License to Ill
1986
Mercury Records
noawardsbutthistablecelliswide
Rhymin & Stealin, The New Style, She’s Crafty, Posse in Effect, Slow Ride, Girls, (You Gotta) Fight for Your Right, No Sleep Till Brooklyn, Paul Revere, Hold It Now, Hit It, Brass Monkey, Slow and Low, Time to Get Ill
Code snippets like var foo = "bar"; can be shown inline.
Also, this should vertically alignwith thisand this.
Long, single-line code blocks should not wrap. They should horizontally scroll if they are too long. This line should be long enough to demonstrate this.
Inline code inside table cells should still be distinguishable.
Language
Code
Javascript
var foo = "bar";
Ruby
foo = "bar"{
Small images should be shown at their actual size.
Large images should always scale down and fit in the content container.
Components
Alerts
This is an alert.
Note:
This is an alert with a title.
This is a successful alert.
This is a warning!
Warning!
This is a warning with a title!
Sizing
Add some sections here to see how the ToC looks like. Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.
Parameters available
Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.
Using pixels
Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.
Using rem
Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.
Memory
Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.
RAM to use
Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.
More is better
Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.
Used RAM
Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.
This is the final element on the page and there should be no margin below this.
Including images
Here’s an image (featured-sunset-get.png) that includes a byline and a caption.
Fetch and scale an image in the upcoming Hugo 0.43.
Photo: Riona MacNamara / CC-BY-CA
The front matter of this post specifies properties to be assigned to all image resources:
최근 LG전자가 자체 개발해 2014년부터 운영해오고 있는 오픈소스 SW관리 도구인 ‘포스라이트(FOSSLight ; Free and Open Source Software Light)’를 공개해 주목을 받고 있다.
포스라이트는 개발자의 SW를 분석해 오픈소스를 사용했는지, 오픈소스 사용 조건이나 의무사항을 준수했는지 등을 검증해 주는 툴이다.
LG전자 오픈소스 태스크. 사진 왼쪽부터 방재권 선임, 김소임 선임, 최혜성 책임, 김경애 리더, 석지영 선임, 박원재 선임
백지영 기자
‘포스라이트’라는 이름으로 외부에 공개하면서 안정성과 기능을 확대하는 한편 글로벌 인지도를 높일 수 있게 할 계획이다. 포스라이트에는 ‘세상에 빛을 밝혀줄 오픈소스’라는 의미가 담겼다.
이미지 출처
