Blog

• Open Source Compliance
• 프랑스 법원, 대형 통신사 Orange에게 GPL 위반으로 손해배상 판결
• 기업의 효과적인 오픈소스 관리 방안 (2) OpenChain Korea Work Group
• 기업의 효과적인 오픈소스 관리 방안 (1) 글로벌 협력을 위한 OpenChain Project
• Anaconda 꼭 사서 쓰세요. 아니라면 conda-forge!
• Akka는 더 이상 오픈소스가 아닙니다.
• SFC vs. Vizio 판결 겉핥기
• 이너소스 도입을 위한 과제와 효과
• 상용 AI 서비스에 공개 Dataset을 사용해도 되나요?
• SaaS로 서비스를 제공할 때에도 오픈소스 컴플라이언스가 필요한가요?
• 중국 첫 GPL 소송 사례, VirtualApp
• GPLv2도 설치정보를 요구한다고?
• Dockerfile 배포 시 컴플라이언스 책임은 누구에게?
• OSPO란?
• Elastic License 2.0 그리고 진화하는 오픈소스 라이선스
• 소스 코드 내 저작권 표시 방법
• 2019 FOSS Legal Issue Top 10
• Open Source Vulnerability
• OSS Supply Chain Security

Open Source Compliance

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

안녕하세요.

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

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

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

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

GPL이란?

GNU General Public License의 약자로, 대표적인 오픈소스 라이선스 중 하나인 GPL은 소프트웨어의 저작권자가 “누구든지 소프트웨어를 자유롭게 사용하고, 수정하고, 배포할 수 있도록 허용하는 동시에, 수정된 버전이나 파생된 저작물도 GPL을 따라야 한다는 조건을 부과"하는 강력한 Copyleft 성격의 라이선스입니다.

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

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

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.

https://lasso.entrouvert.org/

피고: Orange

프랑스의 대형 통신사인 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년 동안 지속된 이 대규모 공공 시장에서 부당하게 이익을 창출했다고 지적했습니다.

시사점

1. 5G의 성장 한계에 도달하면서 비통신 전략을 가속화하고 있는 통신사가 소송의 대상이 된 것은 흥미로운 점입니다. AI, 클라우드, IoT, 로보틱스, 반도체, UAM 등 첨단 기술 분야에서 다양한 제품과 서비스를 출시하고, B2B 영역을 함께 공략하고 있는 통신사들은 이제 다른 산업 분야의 회사와 마찬가지로 소프트웨어 개발 환경에서 오픈소스를 필수적으로 사용하게 되었습니다. 따라서, 오픈소스 관리를 위한 정책과 프로세스를 수립하는 것이 중요하게 되었습니다.

2. 오픈소스 라이선스 분쟁 사례는 주로 오픈소스를 사용하여 개발한 디바이스나 소프트웨어 상품이 무단으로 배포될 때 발생하였습니다. 그러나 이번 사례에서는 정부 기관의 웹사이트를 구축하기 위해 소프트웨어 공급 계약자가 사용한 오픈소스가 분쟁의 대상이 되었습니다. 따라서 기업들은 소프트웨어 디바이스, 앱 등의 배포 대상뿐만 아니라, B2B 형태로 웹서비스 구축 계약을 체결하여 정부기관이나 고객사에 소프트웨어를 공급할 때에도 오픈소스 관리를 위한 프로세스를 적용해야 함에 유의해야 합니다.

References

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

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

바로바로 업데이트하겠습니다. ^^

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

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

OpenChain Korea Work Group

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

OpenChain KWG 정기 미팅

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

기업이 보유한 오픈소스 관리 자산을 경쟁사와 공유한다고 해도 매출에 악영향을 끼치지 않습니다. 반면, 경쟁사의 오픈소스 관리 정책을 알아내더라도 이를 기업의 이익과 연결할 수 없습니다. 기업들이 서로 오픈소스 관리 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)

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

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

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

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

ISO/IEC 5230은 오픈소스 컴플라이언스를 위한 국제 표준입니다. 이 표준은 2020년에 ISO에 등록되었으며, 세계의 많은 기업이 이 표준을 준수하여 오픈소스 컴플라이언스 관리를 훌륭하게 수행하고 있습니다. 기업이 오픈소스를 관리해야 하는 이유는 라이선스 컴플라이언스 뿐만 아니라 보안 취약점에 대한 리스크도 존재하기 때문입니다. OpenChain Project에서는 보안 취약점 관리를 위한 표준, ISO/IEC DIS 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전자, 김소임)

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

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

FOSSLight Roadmap (LG전자, 김경애)

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

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

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

OLIVE Platform은 카카오에서 개발한 오픈소스 라이선스 검증 서비스이며, 카카오 계정만 있으면 누구나 무료로 사용할 수 있습니다. 카카오의 황은경 님은 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 Global Community

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

Platinum Members

Community Structure

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

OpenChain Standard

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

가장 가시적인 결과는 오픈소스 관리를 위한 최초의 국제 표준을 개발한 것입니다. 2020년 12월, ISO/IEC 5230이 오픈소스 컴플라이언스를 위한 유일한 국제 표준으로 등록되었습니다. ISO/IEC DIS 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에서는 오픈소스 관리에 대한 온라인 웨비나를 계속하고 있습니다.

Training Courses

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

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

Update on China and Japan

China

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

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

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

Japan

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

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

Korea market - challenge and opportunities

Current situation

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

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

Opportunities

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

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

글을 마치며

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

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

감사합니다.

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

안녕하세요.

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

https://www.anaconda.com/

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

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

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

https://www.anaconda.com/pricing

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

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

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

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

https://repo.anaconda.com/

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

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

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

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

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

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

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

https://github.com/conda/conda

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

https://conda-forge.org/

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

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

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

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

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

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

conda config --remove channels defaults

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

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

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

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

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

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

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

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

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

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

감사합니다.

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

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

Akka란?

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

라이선스 변경

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

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

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

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

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

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

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

• MariaDB
• CockroachDB
• Sentry
• materialize

Business Source License

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

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

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

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

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

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

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

Change Date, Change License

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

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

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

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

Additional Use Grant

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

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

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

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

Akka의 라이선스 FAQ

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

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

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

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

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

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

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

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

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

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

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

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

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

마치며

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

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

감사합니다.

SFC vs. Vizio 판결 겉핥기

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

SFC(Software Freedom Conservancy)가 GPL 위반을 이유로 미국의 스마트 TV 제조사인 Vizio에 소송을 제기하였는데요, 지난 2022년 5월 13일, 이와 관련한 미국 연방 법원의 판결이 있었습니다.

이번 판결의 배경과 시사점을 수박 겉핥기로 정리해보았습니다. 제가 법률 전문가가 아니기 때문에 용어나 해석에 있어서 오류가 있을 수 있습니다. 여러 전문가분께서 피드백 주시면 고맙겠습니다. ^^

References

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

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

1. 배경지식

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

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

1-1 저작권법과 계약법

저작권법

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

계약법

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

사례

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

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

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

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

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

2021-10-19

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

2021-11-29

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

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

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

만약 이를 연방 법원이 승인할 경우, 미국 저작권법에 따라 심사가 진행되어야 하고, SFC는 저작권자가 아니기 때문에 원고로서의 자격조차 없게 됩니다.

In Response,

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

2022-05-13

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

3. 주목할 만한 사항

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

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

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

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의 소스 코드를 받는 것임

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

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

4-1. 주요 관건

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

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

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

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

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

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

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

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

4-5 판결

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

5. 시사점

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

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

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

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

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

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

감사합니다.

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

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

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

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

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

1. 오픈소스 Practice 주요 사항

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

(1) 조직간 협업

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

(2) 문서화

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

(3) Continous Test

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

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

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

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

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

2. 이너소스 도입 효과

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

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

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

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

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

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

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

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

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

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

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

감사합니다.

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

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

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

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

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

1. Intro

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

GitHub Copilot

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

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

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

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

2. Background

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

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

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

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

4. Case Study Details

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

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

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

5. THREATS TO VALIDITY

이럻게 위에서 설명한 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로 서비스를 제공할 때에도 오픈소스 컴플라이언스가 필요한가요?

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

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

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

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

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

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

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

고지 내용 제공은 어떻게?

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

LGPL-2.1

1. … and distribute a copy of this License along with the Library.

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

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

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

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

MIT

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

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

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

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

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

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

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

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

GPL-2.0

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

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

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

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

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

AGPL-3.0

13. 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 소프트웨어를 다음 두가지 방식으로 사용한다면, 소스 코드를 제공해야 합니다.

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

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

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

Google’s AGPL Policy

*WARNING: Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.

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

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

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

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

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

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

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

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

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

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

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

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

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

중국 첫 GPL 소송 사례, VirtualApp

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

지난 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 저작권자입니다.

피고

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

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

분쟁 대상 소프트웨어

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

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

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

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

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

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

1. 피고 Fujian Fengling Company와 피고 Beijing Fengling Company는 즉시 원고의 컴퓨터 소프트웨어 저작권 침해를 중단할 것
   • 즉, 인터넷을 통한 모든 버전의 “Dim Sum Desktop” 소프트웨어 다운로드, 설치 및 운영 서비스 제공을 즉시 중단해야 함
2. 피고 Fujian Fengling Company와 피고 Beijing Fengling Company는 원고에게 2천만 위안의 경제적 손실을 배상할 것
3. 피고 Fujian Fengling Company와 피고 Beijing Fengling Company는 침해에 대해 원고에게 50만 위안의 합리 비용을 배상할 것 _{compensate the plaintiff for a reasonable fee of 500,000 yuan for stopping the infringement}
4. 피고 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 8. Termination
  • GPL-3.0의 사용 조건을 위반하는 경우 GPL-3.0을 통해 얻은 권한은 자동으로 종료됨
  • “You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License”
• 중국 민법 총칙 제158조
  • “민사법률행위는 조건이 있을 수 있다… 해제 조건이 있는 민사법률행위는 조건이 충족되면 무효”라고 규정
• 오픈소스 소프트웨어의 특성상 GPL-3.0서에 명시된 사용조건(소스코드 공개, 저작권 / 수정 정보 표시 등)은 라이선스 제공자가 사용자가 이를 사용할 수 있도록 하기 위한 전제조건임
  • 사용자가 사용 전제조건을 위반한 경우 라이선스 제공자와 사용자 간의 GPL-3.0 계약은 자동으로 해지
  • 계약에 따른 사용자의 라이선스는 즉시 종료됨
  • 이후 사용자가 수행하는 복제, 수정, 배포 등의 행위는 권리의 상실로 인한 침해에 해당함

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

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

1. 코드 호스팅 웹사이트의 업로드 기록과 인증 내역에 따라 원고가 VirtualApp의 저작권 소유자임을 입증할 수 있음
2. 원고는 소송을 제기하는데 기여자의 동의 또는 승인 없이 소송을 제기할 권리가 있음
   • 원고의 주주인 Lody는 프로젝트 Owner로서 원고 주장의 근거가 되는 GitHub에 VirtualApp 초기버전의 소스 코드 중 총 31,097줄을 공개함.
   • 기여자는 GPL-3.0에 따라 VirtualApp 프로젝트에 자신의 소스 코드를 업로드하고, 라이선스도 부여함.
     • 이는 자신이 기여한 기여물에 대한 라이선스를 프로젝트 소유자 및 기타 사용자에게 부여하는데 동의한 것으로 간주.
   • 만약, 모든 기여자의 만장일치 동의 또는 승인이 필요하게 요구한다면 실제로 권리 보호 조치를 시작조차 못하게 될 것임. 이는 오픈소스 프로젝트의 소송 권리 보호에 도움이 디지 않을 것.
   • 즉, 원고는 소송을 시작하기 위해 기여자의 동의나 승인이 필요하지 않음
3. 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 라이선스가 우선한다고 판단하였습니다.

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

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

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

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

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

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

마무리

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

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

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

안녕하세요.

미국의 저명한 오픈소스 라이선스 전문 변호사인 P. McCoy Smith는 최근 JOLTS_{Journal of Open Law, Technology & Society}에 GPLv2가 ‘설치정보’를 요구하는가를 주제로 글을 게재하였습니다.

지난 2021년 3월, SFC_{Software Freedom Convervancy}의 블로그에 “Understanding Installation Requirements in GPLv2“라는 주제로 GPLv2에서도 설치 정보 제공을 요구한다는 글이 올라왔었는데, 이에 대한 분석과 GPLv3의 ‘설치 정보’ 요구 사항은 GPLv2에서는 해당하지 않는다는 의견을 자세한 근거를 들어 설명하였습니다.

여기서는 원문을 번역하되 Readability를 고려하고 독자의 이해를 돕기 위해 가능한 배경 설명을 추가하여 작성하였습니다.

혹시, 오류를 발견하였거나 추가 의견이 있으신 분들은 언제든 연락해주세요. haksung@sk.com

감사합니다. :)

Abstract

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

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

1. Introduction

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      “[T]he Tivo itself is the prototype of [T]ivoisation. The Tivo contains a small GNU/Linux operating system, thus, several programs under the GNU GPL[v2]. And, as far as I know, the Tivo company does obey GPL version 2. … [T]he trouble begins because the Tivo will not run modified versions, the Tivo contains hardware designed to detect that the software has been changed and shuts down.”¹⁸

      “TiVo is a provider of hardware and software …. Our concern with them is that they have rights as users, but they should respect the rights of the users to whom they sell. Having a personal video recorder … which won’t run software if you modify the box … is not user-respecting conduct. (TiVo) complied with GPL 2 by the skin of its teeth.”¹⁹

      “TiVoization is described by Peter Brown [Executive Director of FSF in 2006-07 during drafting of GPLv3] as circumventing GPL2 ‘in spirit, not technically.’”²⁰

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

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

      “’The FSF is trying to make some things no longer permissible under the GPLv3 that the GPLv2 left open, and I just happen to think that those things were better off being left open.’”²¹

      “‘I don’t think the GPL v3 conversion is going to happen for the kernel, since I personally don’t want to convert any of my code.’ … ‘I think it’s insane to require people to make their private signing keys available, for example. I wouldn’t do it,’ [Torvalds] said.”²²

      “[If] you can not install or run your changes on somebody else’s hardware … it in no way changes the fact that you got all the source code, and you can make changes (and use their changes) to it. That requirement has always been there, even with plain GPLv2. You have the source. The difference? The hardware may only run signed kernels. The fact that the hardware is closed is a hardware license issue. Not a software license issue. I’d suggest you take it up with your hardware vendor, and quite possibly just decide to not buy the hardware. Vote with your feet. … [I]t’s important to realize that signed kernels that you can’t run in modified form under certain circumstances is not at all a bad idea in many cases.”²³

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

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

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

      “There are several primary areas where version 3 is different from version 2. One is in regard to [T]ivoisation."²⁷

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

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

      “GPLv2 did not address the use of technical measures to take back the rights that … GPL[v2] granted, because such measures did not exist in 1991 [when GPLv2 was written], and would have been irrelevant to the forms in which software was then delivered to users. … GPLv3 must address these issues: free software is ever more widely embedded in devices that impose technical limitations on the user’s freedom to change it.”²⁹

      “Does GPLv2 have a requirement about delivering installation information?…

      “GPLv3 explicitly requires redistribution to include the full necessary ‘Installation Information.’ GPLv2 doesn’t use that term, but it does require redistribution to include scripts used to control compilation and installation of the executable with the complete and corresponding source code. This covers part, but not all, of what GPLv3 calls ‘Installation Information.’ Thus, GPLv3’s requirement about installation information is stronger.”³⁰

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

      ““Keeping a program under GPLv2 won’t create problems. The reason to migrate is because of the existing problems which GPLv3 will address.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      “A computer script is a list of commands that are executed by a certain program or scripting engine. Scripts may be used to automate processes on a local computer …. Script files are usually just text documents that contain instructions written in a certain scripting language. … [W]hen opened by the appropriate scripting engine, the commands within the script are executed.”⁴²

      “Script[:] … a sequence of instructions or commands for a computer to execute … especially … one that automates a small task (such as assembling or sorting a set of data).”⁴³

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

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

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

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

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

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

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

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

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

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

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

       “GPLv2 §3 requires that the source code include ‘meta-material’ like scripts, interface definitions, and other material that is used to ‘control compilation and installation’ of the binaries.”⁴⁹

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

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

9. Conclusion

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

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

About the author

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

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

안녕하세요!

2021년 4월, 독일의 유명한 오픈소스 변호사인 Till Jaeger는 Dockerfile이 생성하는 Docker image내 포함될 오픈소스에 대한 라이선스 컴플라이언스 책임은 누구에게 있는가에 대한 글을 발표하였습니다. Till은 독일법과 유럽 연합 사법 재판소_CJEU의 판례를 근거로 Dockerfile 제공자가 라이선스 의무를 준수해야 한다고 설명하였습니다.

여기서는 Till의 영어 원본을 국문으로 번역하였습니다. 이해를 돕기 위해 이미지를 추가하였고, 군데군데 개인 의견을 인용구(높임말)로 작성하였습니다.

• 번역 오류나 문의는 이메일로 연락주시기 바랍니다. : haksung@sk.com
• 감수에 도움 주신 카카오의 Sean에게 깊이 감사드립니다. ^^

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

1. 소개 및 문제점

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

거의 모든 FOSS 라이선스는 라이선스 의무 준수를 “배포_distribution” (또는 GPL-3.0의 “전달_conveying“와 연결시킨다. 대부분의 라이선스는 라이선스 내에서 “배포” 또는 “전달"이 무엇인지에 대해 추가로 정의하지는 않기 때문에, “배포"의 정의는 적용되는 저작권법에 따라 판단해야 한다².

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

라이선스 컴플라이언스에 대한 중요성 때문에 “배포"라는 용어는 계속해서 법적인 분석 대상이 되고 있다. Heather Meeker는 미국 저작권 관점에서 오픈소스 라이선스에서의 배포를 주제로 글을 작성하였다³. 많은 오픈소스 라이선스가 미국 저작권법을 배경으로 작성되었지만, 유럽 법원은 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

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

Docker 엔진

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

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

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

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

“배포권_{right of distribution}은 저작물의 원본 또는 사본을 일반 대중에게 제안_offer하거나 유통할 수 있는 권리이다”

“The right of distribution is the right to offer the original or copies of the work to the public or to put it into circulation.”

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

4. Dockerfile의 배포 - 분석

이 섹션에서는 먼저 저작권법에 따른 배포가 프로그램 코드의 물리적인 전송을 반드시 요구하는지 여부에 대해 살펴본다. 이후에는 Docker image의 다양한 구성 요소, 즉, Base image, 프로그램 라이브러리, 패치 및 업데이트에 관해 설명한다.

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

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

• 저작권 법에서 정의된 배포의 개념인 프로그램 복사본의 “물리적” 배포
• 제삼자로부터 프로그램 복사본을 취득하게 하는 기타 행위

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

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

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

BGH, judgment of 2020-03-05

“이러한 맥락에서, 결정적인 요소는 제조사가 ‘복제 기기를 대신_{taking the place of the reproduction device}‘하여 상대방의 ‘필요한 도구_{necessary tool}‘로 행위하는 것에 국한되는지 (이 경우 복제는 구매자에게 귀속되어야 함) 또는 사적 이용으로 정당화될 수 없을 정도의 범위와 강도로 저작권 침해 사용을 요구하는지 (이 경우 복제는 제조사에 귀속되어야 함) 여부이다. 규범적 판단에 근거한 이번 조사에서는 녹음 과정에 대한 조직적 주도권_{organizational sovereignty}을 고객이 가졌는지 여부도 판단해야 한다.

“In this context, the decisive factor is whether the manufacturer is limited to ’taking the place of the reproduction device’ and acting as a ‘necessary tool’ of the other party - in which case the reproduction is to be attributed to the purchaser - or whether he opens up a copyright-relevant use to an extent and intensity that cannot be reconciled with the considerations that justify the privileges of private use - then the reproduction is to be attributed to the manufacturer. Within the framework of this examination, which is based on normative standards, it must also be determined whether the client has organizational sovereignty over the recording process."

인터넷 라디오 음악 녹음 서비스에 대한 세부 내용은 한국저작권위원회의 2019년 자료 독일 지방법원, 인터넷 라디오 음악 녹음 서비스(stream ripping) 제공자는 복제권과 전송권을 침해한다를 참고할 수 있습니다.

이 판결의 원고는 음반 제작자인 독일 소니 뮤직(Sony Music)이며, 피고는 인터넷 라디오에서 방송되는 음악을 녹음하여 제공하는 서비스를 운영하는 MusicMonster.FM입니다.

독일 법원은 피고의 서비스는 복제를 위한 기술적 수단을 단순히 제공하는 것을 넘어서고 사적 이용으로 정당화되는 범위를 초과하기 때문에 피고가 복제 및 공중접근의 행위자이고, 피고가 원고의 복제권과 전송권을 침해하였다고 판결하였습니다.

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

CJEU of 2015-05-13

“이러한 정황을 고려했을 때, 법원은 일반 대중에게 배포하는 것은 적어도 매매 계약 체결부터 공공의 구성원에게 전달하기까지의 일련의 행위들로 구성된다는 것을 구체적으로 발견하였다. 이러한 상황에서 판매자_trader는 배포 저작물을 (저작권으로 보호하는 회원국의) 일반 대중에게로 배포를 유발한 자신이 (또는 자신을 대신하여 누군가) 수행한 모든 행위에 대한 책임이 있다. …

이러한 일련의 행위에는 제안_offer을 하기 위한 권유 또는 해당 물건의 판매를 목적으로 취해진 보호 대상에 대한 구속력이 없는 광고도 포함한다. …

전술한 고려사항에 비추어볼 때, 언급된 질문에 대한 대답으로는 2001/29의 지침 제4조 제1항은 다음과 같은 의미로 해석해야 한다. 저작권 보유자에게 저작물 배포를 위한 독점적 권리를 허용하고, 이는 제삼자가 해당 저작물 원본 또는 사본의 판매 제안이나 광고하는 것을 방지할 수 있다. 이는 해당 저작물을 저작권으로 보호하는 회원국의 소비자를 대상으로 광고하는 한 해당 광고로 인해 EU 구매자가 보호 대상 저작물을 구매하게 되었다는 사실이 입증되지 않은 경우에도 마찬가지이다.”

“Taking that context into account, the Court specifically found that distribution to the public is characterised by a series of acts going, at the very least, from the conclusion of a contract of sale to the performance thereof by delivery to a member of the public. A trader in such circumstances bears responsibility for any act carried out by him or on his behalf giving rise to a distribution to the public in a Member State where the goods distributed are protected by copyright. … As regards an invitation to submit an offer, or a non-binding advertisement for a protected object, those also fall under the series of acts taken with the objective of making a sale of that object. … In the light of the foregoing considerations, the answer to the questions referred is that Article 4(1) of Directive 2001/29 must be interpreted as meaning that it allows a holder of an exclusive right to distribute a protected work to prevent an offer for sale or a targeted advertisement of the original or a copy of that work, even if it is not established that that advertisement gave rise to the purchase of the protected work by an EU buyer, in so far as that that advertisement invites consumers of the Member State in which that work is protected by copyright to purchase it."

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

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

4.2 패치

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

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

4.3 시스템 요구 사항 및 Base image

시스템 요구 사항

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

참고로, GPL-2.0 3조에서는 다음과 같이 컴파일러, 커널 등 운영 체제의 주요 컴포넌트는 소스 코드 공개 범위에 포함되지 않는다는 예외를 두고 있습니다.

“3. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."

https://www.gnu.org/licenses/old-licenses/gpl-2.0.html

Base image

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

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

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

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

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

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

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

4.4 프로그램 라이브러리

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

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

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

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

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

4.5 업데이트

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

4.6 라이선스 조건 준수 시점

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

하지만, 만약 관련 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

Copyright © 2021 Till Jaeger

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OSPO란?

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

안녕하세요!

TODO Group은 Talk Openly, Develop Openly를 표방하며 협업을 통해 성공적인 오픈소스 프로젝트와 프로그램을 만들어가고자 하는 Linux Foundation 산하의 그룹입니다. TODO 그룹에서는 오픈소스 가이드, 도구 등을 함께 만들어서 공개하며 오픈소스에 관심 있는 누구나 활용할 수 있게 하고 있습니다.

기업 등의 조직이 오픈소스를 효과적으로 관리하고 사용하기 위해서는 OSPO_{Open Source Program Office}를 설립하여 개발자 교육, 컴플라이언스 보장, 커뮤니티 참여 및 구축, 오픈소스 공개, 코드 점검 등의 활동이 필요하다고 합니다. 이 글에서는 OSPO가 무엇이고, 어떤 역할을 하는지에 대해 TODO Group에서 정의한 글을 옮겼습니다.

• OSPO의 정의
  • 법적 위험 완화
  • 엔지니어 작업 방식 개선
  • 재정적 이익 실현
• OSPO 가이드
• OSPO Examples

OSPO의 정의

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

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

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

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

법적 위험 완화

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

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

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

엔지니어 작업 방식 개선

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

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

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

재정적 이익 실현

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

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

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

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

OSPO 가이드

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

• How to Create an Open Source Program
• Measuring Your Open Source Program
• Tools for Managing Your Open Source Program

OSPO Examples

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

• Autodesk
• Capital One
• Comcast
• Facebook
• Microsoft
• Red Hat
• Salesforce
• SAP
• Uber
• Yahoo/Verizon Media

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

감사합니다.

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

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

안녕하세요.

미국의 오픈소스 전문 변호사인 Heather Meeker가 2021년 3월 11일 공개한 Elastic License에 대한 White Paper를 기반으로 아래의 글을 작성하였습니다. 대부분 원글을 번역하는 방식이며, 제 의견은 인용구로 추가하였습니다.

참고로, Heather Meeker는 이 백서를 자신의 개인적인 견해임을 나타내면서도 일부 Elastic의 자금 지원이 있었다고 밝혔습니다. 그래서인지, 원글은 Elastic License에 호의적인 입장을 보입니다.

(조금 찾아보니, Elastic License 2.0을 Heather Meeker가 작성하였군요.)

여하튼 시대가 변하며 소프트웨어 배포 방식이 바뀌는 상황에 따라 상용 오픈소스 기업들이 개발과 사업을 병행하기 위해 어떤 라이선스 모델을 도입해야 할지 고민해야 했고, Elastic License가 나온 배경에 대한 한 측면을 이해하는 데 도움이 되는 글이라 생각합니다. 글에 오류가 있다면 언제든 연락해주세요. :-)

• 감수에 도움 주신 카카오의 Sean, Robin 그리고 LG전자의 김경애님에게 깊은 감사 드립니다.

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

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

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

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

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

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

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

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

클라우드의 출현과 AGPL

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

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

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

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

AGPL과 듀얼 라이선스

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

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

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

무상 사용_Strip-mining

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

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

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

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

주요 오픈소스 라이선스가 작성되었던 시점에는 AWS의 “Program as a Service” 형태의 프로그램이 없었으니, 이에 대한 조건도 고려하지 않았을 테지요.

오픈소스 상용 기업들은 오픈소스 프로그램을 개발해서 듀얼 라이선스 모델 (GPL or 상용)로 사업을 하고 있었는데, 클라우드 제공 업체에서 이 오픈소스 프로그램을 그대로 가져다가 클라우드 서비스로 제공하는 사업을 하고, 자기네한테는 아무런 이윤도 안겨주지 않으니, 사업 또는 개발 측면에서 모두 좋지 않은 영향을 미쳤을 것은 충분히 추측할 수 있습니다.

클라우드 공급 업체가 MongoDB를 Amazon DocumentDB나 Azure Cosmos DB로 서비스하며 고객을 확보하는게 대표적인 예라고 볼 수 있을 것 같습니다.

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

SSPL과 소스 공개 라이선스

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

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

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

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

SSPL

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

1.  Offering the Program as a Service.

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

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

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

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

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

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

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

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

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

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

Elastic License 2.0

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

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

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

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

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

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

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

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

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

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

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

Elastic License 2.0는 오직 클라우드 서비스 공급 업체에서 Elasticsearch를 자기네 클라우드 서비스로 제공하는 것만은 막겠다는 의지인 것 같습니다.

결국 AWS는 Elasticsearch 서비스를 계속하기 위해 Elasticsearch를 Fork했고, 이를 Open Distro for Elasticsearch라고 명명하며 Apache License 2.0을 적용하고, 커뮤니티를 키워가기로 했습니다.

누가 오픈소스의 지속가능성과 발전에 기여하고 있는 것일까요?

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

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

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

더 나은 라이선스 만들기

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

소스 코드 내 저작권 표시 방법

안녕하세요.

오픈소스 분야의 저명한 변호사인 Matija Šuklje는 최근 소스 코드 내 저작권 표시가 필요한 이유와 올바르게 작성하는 방법을 소개하였습니다.

아래 글은 위의 원글을 기반으로 작성하였습니다. 대부분 원글을 그대로 번역하여 저자의 의도가 충실히 전달되도록 하였습니다.

개발자를 위한 간단한 저작권 표시 가이드로 생각하고 시작하였으나, 저작권 정보 표시에 대한 통일된 가이드가 없었기 때문에 가이드 작성이 쉽지 않았다. 결국 새로 하나 작성하기로 하였다.

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

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

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

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

TL;DR

아래 포맷의 저작권 및 라이선스 표시 당신이 작성한 모든 소스 코드 파일에 추가하라.

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

SPDX-License-Identifier: {$SPDX_license_name}

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

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

SPDX-License-Identifier: BSD-3-Clause

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

저작권이란?

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

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

어쨌든, 저작권법의 기본 요건을 준수해야 하며, 이를 위해서는 최소한 다음 두 가지가 필요한다.

• 저작자 표시 (attribution) : 저작권 보유자 및/또는 저자를 명시한다. (특히 도덕적 권리를 인정하는 관할권에서)

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

Inbound vs. Outbound 라이선스

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

왜 저작권 표시를 해야 하는가?

1989년 베른 협약에 가입하기 전까지 미국 저작권법은 저작물을 보호하려면 명시적인 저작권 표시를 요구하였다. 그러나 베른 협약으로 저작권 표시를 하지 않아도 저작권은 자동으로 생성된다. 그럼에도 저작권 표시는 유용한다.

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

저작권 표시는 실질적으로 다음과 같은 이유로 필요한다.

1. 대부분의 라이선스가 저작권 표시를 요구한다.
2. 라이선스에서 요구하지 않더라도 대부분의 관할권의 저작권 법률에서 요구한다.
3. (이러한 요구가 없더라도) 사용자는 법적 또는 기술적인 이유로 원저작자에게 연락하기를 원할 수도 있다.

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

저작권 표시 및 라이선스 고지의 올바른 방법

저작권 표시

좋은 저작권 표시는 다음 정보로 구성되어야 한다.

• ​© 기호​

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

• 저작권 보유자 이름 : 일반적으로 저자이지만, 저자의 고용주일 수 있다. 또한, CLA에 따라 다른 법인이나 개인이 될 수도 있다.

• ​유효한 연락처 : 저작권 보유자에게 연락할 수 있는 정보

예를 들어, 오늘 소스 코드 파일을 작성하였다면 다음과 같이 저작권 표시를 파일 상단 헤더 부분에 추가한다.

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

라이선스 고지

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

REUSE.software

​REUSE.software 프로젝트는 SPDX tag를 사용해서 저작권 표시와 라이선스 고지를 작성하는 Best Practice를 제공한다.

• 저작권 표시 tag : SPDX-FileCopyrightText

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

아래의 예는 위의 모든 사항을 고려하고 SPDX 및 REUSE.software 요구사항을 모두 준수하는 저작권 표시 및 라이선스 고지이다.

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

SPDX-License-Identifier: BSD-3-Clause

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

FAQ

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

어떤 사람들은 연도를 생략하고 단순하게 작성하는 게 오히려 저작권 표시를 유지하기 쉬울 것이라고 주장한다. 실제로 이는 Microsoft와 GitHub의 정책이기도 한다.

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

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

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

다음과 같은 저작권 표시를 보았을 거다.

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

이렇게 계속해서 연도를 추가하는 건 이렇게 하면 저작권 보호 기간을 연장할 수 있다는 생각이 있기 때문이며, 실제 널리 행해 지고 있다. 하지만, 불행하게도 이런 작업은 쓸모가 없고, 오히려 해가 될 도 있다.

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

반면에 저작권은 저자의 사망 이후 (혹은 저작권자가 법인일 경우, 발행 이후) 최소 50년 (보통 70년) 동안 지속된다. 따라서, 굳이 저작권 표시에 연도를 계속해서 추가하지 않아도 보호 기간 만료 때문에 저작권을 주장하지 못하게 될 위험은 매우 낮다.

게다가, 일반적으로 하나의 소스 코드 파일은 소프트웨어를 구성하는 수많은 파일 중 하나일 뿐이다. 소프트웨어가 성장해가면서 새롭게 파일이 추가될 텐데, 그때 새로운 파일에 새로운 작성 연도를 추가해간다면 전체 저작물로서의 소프트웨어에는 최신 연도의 저작권 표시가 이미 포함되고 있는 거다.

Git/VCS 히스토리를 더럽히지 마라

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

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

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

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

• 파일이 마지막으로 수정 시간?

• 패키지가 릴리즈된 시간?

• 처음 다운로드 한 시간?

• 마지막으로 실행한 시간?

• 아니면 바로 지금?

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

Git/Mercurial이 저작권 정보를 추적하는데 더 좋지 않는가?

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

먼저 Git은 ‘Committer’ 필드와 별개로 ‘Author’ 필드가 있다. 기여자마다 ‘Author’ 필드에 제각각의 값을 포함시킬 뿐더러, ‘Author’ 필드에 입력된 사람이 실제 저자라고 가정하여도 저자는 저작권 보유자가 아닐 수도 있다.

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

이러한 문제들은 모든 파일에 저작권 및 라이선스 정보를 표시하면 해결된다. REUSE.software의 Best Practice는 이를 아주 잘 처리한다.

왜 © 기호를 사용하는가?

어떤 사람은 “Copyright"라는 영어 단어가 더 자주 사용되고, 이미 많은 사람이 익숙하다고 주장할 수도 있지만, 실제로 저작권법을 보면 “©” (Copyright Sign)을 사용하는 것이 저작권 진술을 위한 유일한 방법임을 알 수 있다.

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

또한, © 는 “common global denominator"이기 때문에 이를 사용하는 것이 합리적이다.

© 기호가 호불호가 있을 수 있지만, 실용적인 관점에서 볼 때 사실 그다지 중요하지 않은 부분이다. 위에서 설명했듯이 저작권은 자동으로 생성되기 때문에 어떤 기호를 쓰느냐에 따라 법적인 리스크가 달라지지는 않다.

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

연락처 정보는 저작권법에 의해 요구되는 것은 아니지만, 실용적인 이유로 매우 유용한다.

사용자는 법적 또는 기술적인 문의를 위해 코드의 저자 또는 저작권 보유자에게 연락하고 싶을 수 있다. 코드가 어떻게 동작하는지 물어보거나 수정을 요청할 수도 있다. 라이선스 문제를 발견하여 문제를 해결할 수 있도록 도움을 주거나 별도의 라이선스를 요청해야 할 수도 있다. 이 모든 경우에 연락처 정보가 많은 도움이 된다.

• 현재까지도 이메일이 자주 사용되는 연락 방법이기 때문에 저작권자의 이메일 주소를 제공하는 것이 가장 좋다.

• 저작권이 매우 분산되어 있거나 법인인 경우도 있다. 이런 경우에는 프로젝트 또는 법인 홈페이지의 URL을 제공하는 것이 더 합리적일 수 있다.

• 프로젝트에서 AUTHORS 또는 CONTRIBUTORS와 같은 파일에 저작권 보유자를 표시하는 경우 해당 파일을 가리키는 링크를 제공하는 것도 좋은 옵션이다.

Public Domain은 무엇인가?

일반적으로 Public Domain은 저작권 기간이 만료된 저작물이지만, 까다로운 개념이어서 주의가 필요한다.

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

따라서 저작권과 라이선스를 진지하게 다루는 오픈소스 컴플라이언스 담당자들은 “this is public domain"이라는 표시를 매우 경계한다.

저작권자는 이런 문제를 다음 두 가지 방법으로 완화할 수 있다.

• 자신의 저작물에 대해 저작권을 포기하고 기부하고 싶을 때 “public domain"이라는 단어 대신, CC0-1.0과 같은 매우 허용적인 라이선스를 사용하라.

• “SPDX-FileCopyrightText:” 필드에 이름과 연락처 정보를 남기세요. 사용자가 저작권자의 의도를 궁금해하거나, 어떤 불분명한 사항이 있으면 연락을 취하여 문제를 해결할 수 있게 하라.

Minified JavaScript에서는 저작권 표시를 어떻게 하는가?

최근의 Minifier는 주석을 제거하더라도 저작권 및 라이선스 정보는 보존하는 옵션을 제공한다. 코드를 minify 할 때 이런 옵션을 사용하여 저작권과 라이선스 정보를 유지하라.

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

“All rights reserved” 표시에는 어떤 문제가 있는가?

종종 저작권 표시에 “All rights reserved"라는 문장을 본 적이 있을 거다. 저작권법은 이런 표현을 요구하지 않다. 아마 음악 CD나 책에서 사용하는 걸 보고 단순히 모방해서 사용하는 게 아닐까 생각한다. 하지만, 오픈소스에서 이런 표현은 혼란을 야기시킨다.

“All rights reserved"는 명백히 오픈소스 라이선스와 모순된다. 오픈소스 라이선스는 누구나 코드를 사용, 연구, 공유 및 개선할 수 있는 권리를 제공한다. 반면에 “All rights reserved"는 이러한 모든 권리가 자신에게만 부여된다는 표현이다.

“All right reserved"는 이와 같은 문제만 가져올 뿐, 어떤 이점도 가져오지 않기 때문에 오픈소스에서는 사용하지 말아야 한다.

2019 FOSS Legal Issue Top 10

안녕하세요.

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

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

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

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

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

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

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

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

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

3. OSS에 닥친 무역 전쟁

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

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

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

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

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

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

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

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

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

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

6. Oracle v. Google 전쟁

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

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

7. 독일 Hellwig/VMware case 종결

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Open Source Vulnerability

OSS Supply Chain Security

안녕하세요.

2020년 2월, Linux Foundation에서는 Open Source Software Supply Chain에서의 보안 리스크를 알리기 위한 글을 작성하였으며, 여기에서는 이에 대한 내용을 정리해보았습니다.

Introduction

현대의 Software 개발은 지난 수십 년보다 훨씬 복잡한 프로세스가 되었다. 하나의 조직 내에서 Software 모두를 자체 개발하는 경우는 거의 없다. 대신 대부분의 조직은 Open Source Software(OSS)를 활용한다. 다양한 OSS를 포함하면서 서로 연결되는 부분만 자체 개발하여 제품을 개발한다.

“Software Supply Chain"은 이미 매우 복잡하다. 예전에는 Software가 CD와 같은 물리적 매체를 사용하여 고객에게 제공되었다면, 오늘날의 Software는 (OSS 및 독점 Software 모두) “repository"에 저장이 되고, Project Dependency Manager (PDM)이나 Package Manager를 통해 수시로 원격으로 배포된다.

Software Supply Chain에서의 보안에 대한 최근의 관심은 대부분이 이 Chain의 첫 번째 요소인 Developer이거나 혹은 마지막 부분인 End User였으나, 취약점은 모든 레벨에서 존재한다. 다음과 같은 사건을 살펴보자.

2015년 악성코드 배포를 위한 Xcode Repackaging

2015년 한 보안회사는 App Store를 통해 배포되는 39개의 Application이 iPhone 및 iPad를 감염시키고 있다고 Apple에 경고했다. 디바이스에 다운로드된 악성 Application은 원격 Command/Control 서버에 접속되어 중요한 사용자 정보를 업로드했다. 추가 조사에 따르면 Apple의 공식 개발 플랫폼인 Xcode의 “repackaged” 버전을 통해 악성 코드가 Application에 삽입된 것으로 나타났다.

이 App들은 즉시 제거되었고, Apple은 합법적인 개발자만이 Xcode의 공식 버전에 액세스 할 수 있도록 추가 조치를 취했지만, 이 사건은 Software Supply Chain 내에서 여러 Application에 영향을 미칠 수 있는 Software의 보안 취약점에 대한 위험을 부각했다.

Apple scrambles after 40 malicious “XcodeGhost” apps haunt App Store, Dan Goodin, ArsTechnica (Sep. 25, 2015), https://arstechnica.com/information-technology/2015/09/apple-scrambles-after-40-malicious-xcodeghost-apps-haunt-app-store/

2016년 “left-pad” Dependency 사고

2016년, 관련 없는(unrelated) OSS package에 대한 명명권 분쟁에 이어, 한 유명한 개발자가 Node.js 코드를 배포하는 데 사용되는 Software Registry인 npm에서 모든 OSS package를 제거했다. 이 개발자는 npm에서 총 273개의 package를 제거했지만, 문제는 하나의 package에서 나타났다. “left-pad”

믿을 수 없을 정도로 간단한 package인 “left-pad"는 텍스트를 오른쪽 정렬하여 읽기 쉽게 텍스트 출력을 제공하다. 그러나 “left-pad"는 수많은 중요한 하위(downstream) Package가 의존성을 갖고 있었기 때문에, “left-pad"의 갑작스러운 사라짐은 수많은 하위 Package들이 깨지는 문제를 유발했다. 다른 개발자가 기능적으로 동등한 package로 사라진 package를 대체하였지만, downstream 개발자들은 자신의 코드를 업데이트하고, 새로운 package를 참조하도록 해야 하는 문제가 남아 있었다.

이 사건은 개발자들이 거의 통제할 수 없는 upsgream package에 의존할 때 직면하는 위험을 극명하게 부각했고, 더불어 광범위한 “dependency” 문제를 드러냈는데, 문제는 이 package가 상위(upstream) dependency로 내포되어 있기 때문에 “left-pad"에 의존할 의향이 전혀 없는 개발자들도 영향을 받았다.

이 “left-pad” 사건은 3년 전에 일어났지만, 여전히 이와 같은 문제들은 남아있다.

Rage-quit: Coder unpublished 17 lines of JavaScript and “broke the Internet”, Sean Gallagher, ArsTechnica (March 24, 2016), https:// arstechnica.com/information-technology/2016/03/rage-quit-coder-unpublished-17-lines-of-javascript-and-broke-the-internet/ .

2017년 Python Package (PyPI) Highjacking

2017년 공격자들은 Build-in Python library의 이름을 “매우 비슷하게” 만든 악성 library를 만들었다. 이를 의심하지 않은 개발자들은 이 악성 library들을 다운로드하였다. 이 악성 package들은 원본과 동일한 코드를 포함하지만, 설치 스크립트는 악성 코드를 포함하도록 변경이 되어 있었다.

Goodin, Dan. 2017-09-16. “Devs unknowingly use “malicious” modules snuck into official Python repository: Code packages available in PyPI contained modified installation scripts.” Ars Technica. https://arstechnica.com/information-technology/2017/09/devs-unknowingly-use- malicious-modules-put-into-official-python-repository/

2018년 Python Package Highjacking

2018년 Python Software Repository에서 “Colourama"라고 불리는 암호 화폐 도용(cryptocurrency-stealing) package가 발견되었다. 이 packgae의 이름을 의도적으로 Python repository내에서 가장 많이 다운로드되는 20가지 Software 중 하나인 합적적인 package “Colorama"와 비슷하게 해서 혼동을 주었다. 이 악성 package가 발견되었을 때 단지 151번만 다운로드되었지만, 피해를 입은 디바이스에서 감염을 제거하는 데에는 많은 노력이 필요했으며, 이로 인해 Software repository의 보안 취약성이 부각되었다.

Two new supply-chain attacks come to light in less than a week, Dan Goodin, ArsTechnica (October, 23, 2018), https://arstechnica.com/ information-technology/2018/10/two-new-supply-chain-attacks-come-to-light-in-less-than-a-week/.

2018년 “event- stream” Library의 백도어

2018년, 가장 널리 사용되는 JavaScript library 중 하나가 백도어로 암호 화폐 도용 코드가 삽입되었다. 주목할만한 것은 이 삽입이 유사한 사건들보다 훨씬 더 정교해졌다는 것이다 (백도어 발견 시점에 이 라이브러리는 2백만 회의 다운로드 수를 기록했다).

우선, 백도어 뒤의 악의적인 공격자들은 개발자들에게 도움을 제공함으로써 event-sream package에 대한 합법적인 publishing 권한을 얻었다. 일단 그들은 권한을 얻은 후, 이를 이용하여 양호한 packag를 npm registry, flatmap-stream에 추가하였고, 이 package를 event-stream 자체의 dependency로 추가하였다. 약 한 달 후, 이 악성 공격자들은 인기 있는 암호 화폐 지갑 Software를 대상으로 하는 ftatmap-stream에 악성 코드를 추가했다 (따라서, event-stream에도 추가됨).

이러한 단계적 공격 (staged attack)은, 공격자들이 event-stream package에 대한 publishing 권한을 얻기 위해 취한 노력과 함께, 새로운 코드와 새로운 개발자들을 면밀히 조사하는 방식에 약점이 있음을 보여주는 것뿐만 아니라, 악의적인 공격자들이 그러한 노력을 기울인다는 점을 보여준다. 이는 유사한 공격이 계속될 뿐만 아니라, 빈도와 정교함에서도 증가할 가능성이 있음을 시사한다.

Widely used open source software contained bitcoin-stealing backdoor, Dan Goodin, ArsTechnica (November 26, 2018), https:// arstechnica.com/information-technology/2018/11/hacker-backdoors-widely-used-open-source-software-to-steal-bitcoin/

2019년 7월, 인기 있는 Ruby Gems Package의 계정 탈취

2019년 7월, codebase를 업데이트한 한 개발자는 dependency 중 하나에서 changelog.md 파일이 누락된 것을 발견했다. 영향을 받은 package인 strong_password는, 변경 사항에 대한 설명 없이, 그리고 Github에서 호스팅 되는 코드와 Ruby repository에서 호스팅 되는 코드 간에 차이가 있는 상태로, 0.0.6에서 0.0.7로 업데이트되었다. 이 개발자는 추가 조사를 통해 그 package가, production environment 내에서 실행될 때, 원격 URL에 접속하여 추가 코드를 가져와서 그 코드가 포함하도록 업데이트되었음을 발견했다. 일단 그렇게 되면, 새로운 코드는 감염된 환경 내에서 원격 코드가 실행될 기회를 제공했다.

그 개발자는 그 package의 original maintainer에게 이를 통보하였고, 그 maintainer는 자신의 Ruby repository 계정이 탈취되었음을 발견했다. 악의적인 공격자는 maintainer의 계정을 더럽혔고, package 소유권을 변경한 다음, 백도어 코드를 게시했다. 확인되지는 않았지만, original maintainer는 2단계 혹은 다단계 인증 (2FA or MFA)이 없었던 것이 악의적인 공격자가 자신들의 개발자 계정에 접근할 수 있었던 원인이라고 믿었다. strength_password와 같은 dependency는 다양한 환경에서 배포되기 때문에, 그리고 신뢰도에 대한 명성을 얻은 유명한 개발자와 관련이 되어 있기 때문에, 그런 개발자의 계정을 탈취하는 것은 가치가 크다. 이와 비슷한 공격은 증가할 것이다.

strong_password v0.0.7 rubygem hijacked, Tute Costa (July 3, 2019), https://withatwist.dev/strong-password-rubygem-hijacked.html

2018-2019년 Webmin Compromise

2018년 4월에 시작하여 2019년 8월에 발견된, 인기 Webmin 관리 도구에 알려지지 않은 악의적인 공격자가 백도어를 사용했다. 변경은 비교적 작았지만, 상당한 영향을 미칠 수 있었다. 백도어를 사용한 악의적인 공격자는 특수하게 조작된 URL을 활용하여 감염된 서버에 명령을 전송할 수 있고, 이는 최상위 권한 (root)으로 명령을 실행할 수 있게 한다.

Webmin 개발자에 따르면, Webmin 소스 코드가 포함된 서버는 2018년 4월에 악용 되어 악성 코드가 삽입되었다고 한다. 그때 공격자는 관련 서버 로그를 변경하여 파일이 한동안 업데이트되지 않은 것처럼 보이게 하여 코드 비교 툴과 같은 일반적인 탐지 메커니즘으로부터 감지되는 것을 숨겼다. 외부에서 0-day 공격의 일부로 백도어가 공개되었다는 것을 발견한 2019년 8월 17일까지 변경된 코드는 감지되지 않았고, 추가적인 악의적인 행동은 지속되었다.

Webmin의 maintainer가 감염을 제거하고 추가 단계를 수행했지만, 이 사건은 이러한 Software의 취약성과 악의적인 공격자에게 지속적인 매력이 있다는 걸 보여주는 또 다른 사례가 되었다.

The year-long rash of supply chain attacks against open source is getting worse, Dan Goodin, Ars Technica (August 21, 2019) https:// arstechnica.com/information-technology/2019/08/the-year-long-rash-of-supply-chain-attacks-against-open-source-is-gettingworse/; Webmin page explaining exploit, Webmin, http://www.webmin.com/exploit.html.

2019년 8월, 11개의 백도어 RubyGems Library 발견

2019년 8월, Ruby library를 조사한 한 개발자에 의한 분석 결과, 11개의 백도어 된 package가 발견되었다. 각각의 경우, 백도어는 미리 선택된 자격 증명을 보유한 악성 공격자들이 감염된 서버에서 원격으로 코드를 실행할 수 이도록 했다.

감염된 package는 또한 암호 화폐 채굴을 가능하게 했다. 각 library가 어떻게 감염됐는지는 불분명하지만, 적어도 한 개 의상의 package에 대해서는 개발자 계정이 해킹됐기(compromise)때문에 코드의 수정이 가능했다. 그 계정은 이전에 크랙 된 패스워드를 사용해왔으며, 2FA나 MFA로 보호되지 않았다.

이러한 사건들은 package manager와 repository에 의해 사용되는 현재의 정책, 프로세스 및 절차에 내재된 약점을 보여준다. 상황을 더욱 악화시키는 것은, supply chain의 이러한 요소들이 현대의 software 개발에서 필수 불가결하기 때문에, 거의 모든 경우에 조직들은 이러한 요소들을 사용해야 하고, 따라서 통제할 수 없는 높은 수준의 위험에 노출되게 된다.

끝으로, software supply chain과는 별개이지만 필수 불가결한 최종 요소가 하나 있다. : “Vulnerability Database”

현대 software 개발의 분산되고 압도적으로 복잡한 특성을 감안하면, 배포된 softare에서 발견되는 vulnerability를 식별, 분석, 치료 및 추적하는 것은 매우 중요하다. 그러나, CVE (Common Vulnerabilities and Exposures) 프로그램에서 제공하는 NVD (National Vulnerability Database)는 세계에서 가장 의존도가 높은 vulnerability 추적 database인데, 현대 software 개발의 성장, 속도 및 복잡성으로 인해 계속 어려움을 겪고 있다. 이러한 어려움은 CVE 및 NVD 프로그램에 의존하는 개발자 및 회사에 직접적인 영향을 미치며 Software Supply Chain의 보안 및 안정성에 전체적으로 영향을 미친다. 여기서는 현재 Software SupplyChain에 영향을 미치는 보안 및 안정성 문제에 대해 살펴보고, 전반적으로 개선하기 위해 변경할 수 있는 부분과 방법을 소개한다.

Software Supply Chain 조사

개발자 Practice

개발자는 앞에서 소개한 그림에서 Software Supply Chain의 첫 번째에 표시되어 있다. 이것은 사실이기도 하지만, 개발자들은 모든 단계에 존재에 어디에나 존재한다. 개발자들은 프로그래밍 language, repository, PDM을 선택한다. 그들은 소비자가 구매할 회사의 완성 제품을 구성하는 library, package 및 OSS를 선택한다. 즉, 개발자들은 Software Supply Chain에서 가장 없어서는 안 될 구성원이다.

그러나 많은 개발자들은 Software를 개발할 때 보안 Best Practice를 따르지 않는다. 여기에는 여러 가지 이유가 있다. 그중 하나는, 오늘날의 Software 개발은 엄청나게 복잡한 과정이다. 따라서, 하나의 “Best Practice"의 전략이 다른 사람에게는 치명적인 약점이 될 수도 있다는 걸 감안해야 한다. 또 다른 이유로, 보안은 종종 개발자와 user experience에 방해가 되는 역할로 보인다. 결과적으로 많은 개발자들은 올바른 보안 practice의 사용을 피하거나 최소화한다.

이렇게 보안 practice를 무시하거나 꺼리는 건 여러 가지 결과를 가져오고, 그중 많은 것은 위에서 설명한 Supply Chain 사건에서 강조되었다. 개발자들이 다음과 같은 보안 Practice를 사용했다면 이러한 사건들 중 많은 부분을 피할 수 있었을 것이다.

• 특정 프로젝트의 설계, 구축 및 유지 관리와 관련된 개발자 계정 및 기타 중요 계정에 대해 2단계 혹은 다단계 (2FA 또는 MFA) 인증 사용
• 개발 프로세스 전반에 걸쳐 프로젝트가 change contrl tracking(누가 변경했는지, 언제 변경되었는지 포함)을 지원하도록 요구
• 프로젝트가 각 release에 대해 고유한 version identifier를 갖도록 보장하여 downstream user가 새로운 release를 추적하고, 이를 control 및 verification 하는 mechanism을 구축할 수 있게 함
• 프로젝트의 개발 lifecycle에 testing을 통합하여 일반적인 버그와 예기치 않은 동작을 확인하는 것뿐만 아니라 개발자가 알지 못하는 상태로 이루어지는 악의적인 변경이 있는지 확인
• Downstream user가 쉽게 소비할 수 있도록 프로젝트의 dependency를 문서화하고 전달하는 것을 보장하는 도구 또는 다른 mechanism을 활용
• Dependency를 적절하게 추적, 분석, 관리하는 도구 활용
• 암호화 Signing 또는 프로젝트의 무결성에 대해 입증 가능한 증거를 presenting
• 새로 개발된 코드 및 프로젝트에 통합된 OSS dependency 모두에 대해 vulnerability를 추적하고 치료

많은 개발자들이 이들을 준수하지 못하고 있다. 필요한 자원, 전문지식 또는 지원이 부족해서일 수도 있다. 그러나 분명한 건, 이런 Best Practice를 따르지 못한다면 개발자뿐만 아니라 Software의 최종 사용자에게 심각한 결과를 초래한다는 것이다.

Repository

예전에는 많은 Software 개발이 협력업체나 벤더로부터 라이선스 된 코드를 사용하였지만, 현재는 대부분의 개발이 인터넷에서 제한 없이 무료로 검색된 대량의 OSS를 포함시키고 있다. 많은 개발자들은 “repository"라고 알려진 Software 저장소를 의지하여 개발한다.

기본적으로 Software Repository는 Software Package 세트를 보관하는 서버이다. 이러한 Package는 소규모 Utility Library에서부터 Full Command Line Tool 및 개발 Framework에 이르기까지 다양하다. 일반적으로 Linux 시스템은 Operating System repository를 사용하여 Linux 배포판을 기반으로 application과 해당 application의 depencency를 관리한다. 해당 배포판의 개발자들은 repository의 집합 내에서 모든 package를 관리하며 upstream software package의 release를 기반으로 최신 package를 유지하고, 필요할 경우, 해당 package의 보고된 보안 및 기타 버그를 수정한다.

Perl로 시작하여 interpreted programming language가 성장함에 따라, 사용자를 위해 “helper” library의 확장된 repository를 제공하는 것이 유리해졌다. 이러한 repository의 크기 때문에, 이들은 일반적으로 개별 Linux 배포판의 main packaging에서 제외되었다. 이러한 language별 repository의 성장으로 인해 해당 language를 사용하는 모든 개발자는 비개발 시스템에서 개발 software를 실행해야 하는 시기뿐만 아니라, 필요한 dependency를 설치하기 위해 language repository 도구를 사용해야 한다.

오늘날 software 개발의 상당 부분이 OSS에 의존하고 있으며, 전 세계에서 가장 의존적인 OSS의 많은 부분이 그들의 library를 위해 language repository에 의존하는 language로 작성되기 때문에, 개발자들은 이러한 repository에서 software의 일부를 추출해야 한다. 그러나, 다양한 역사적, 경제적 이유로 그러한 language repository는 기본적인 보안이나 품질 관리조차 결여되어 있다. 예를 들면 :

• 현재 저장된 코드가 목적대로 검사 되는 mechanism을 제공하는 language repository는 거의 없으며, 소비자 혼동을 증가시키고, 경우에 따라 악의적인 활동을 가능하게 한다.
• 저장된 코드 또는 deprecated package의 vulnerability를 체계적으로 검사하는 langugae repository는 거의 없다.
• 현재 소비자가 저장된 코드 중 하나가 다른 코드에서 파생되었는지 여부를 확인할 수 있는 mechanism을 제공하는 language repository는 없으며, 이는 vulnerability 또는 다른 문제가 dependency로부터 이어지는지 여부를 확인할 능력을 제한한다.
• 대부분의 language repository에서, 취약하거나 누락된 인증 및 publisher verification mechanism은 저장된 코드의 출처에 대한 불확실성과 위험을 야기한다.
• 일부 language repository는 개발자 계정에 대해 2단계 또는 다단계 (2FA 또는 MFA) 인증을 제공하지 않으며, 종종 이를 요구하지 않거나, 이를 조장하거나, 개발자 계정(및 계정을 제어하는 package)이 취약하게 보호되고 있음을 다른 사람에게 알려준다.
• 많은 language repository가 code signing을 제공하지만, 그러한 서명의 유효성을 검증하기 위한 강력한 mechanism을 제공하거나 가능하게 하는 경우는 거의 없다.
• 일부 language repository는 성실한 소비자들이 자기 스스로 저장된 코드에 대해 보안 및 품질 분석을 수행할 수 없도록 제한하는 EULA (End User License Agreement)를 포함한다.
• 많은 language repository는 생성된 package가 다른 사람이 검사할 수 있는 예상된, 공개적으로 사용 가능한 소스에서 생성되었는지 검증하지 않거나, 다른 사용자가 쉽게 확인할 수 있도록 하지 않는다.

일부 language repository는 이러한 우려들을 해결하기 위한 조치를 취했지만, 모든 문제를 해결하는 mechanism을 개발한 repository는 없다. 또한, 이러한 우려를 해결하려고 시도한 일부 language repository의 경우, 저장소 자체를 “상업화"하였고, “premium” 서비스를 이용하는 고객들에게만 이런 기능을 제공한다. 결과적으로, 기본적으로 필요한 보안과 품질 제어는 많은 일상 소비자의 손이 미치지 않는 곳에 남아 있다.

Project Dependency Manager (“Package Manager”)

오늘날 대규모의 Software를 효율적으로 관리가 위해서는 간단하면서도 강력한 도구가 필요하다. 그러한 도구가 많이 존재하지만, 그중 가장 널리 보급되고 있는 것은 “package manager"이다. package manager는 software package, library 등 파일을 특정 시스템에서 설치, 업그레이드, configuring 및 제거하는 과정을 자동화한다. 특히, “project/application dependency manager”(PDM)이라고 하는 package manager가 자주 사용된다.

PDM을 활용하면서 사용자는 software를 찾고 설치하고 구성하는 이전의 복잡한 여러 단계를 하나의 단계로 전환할 수 있다. PDM은 위에서 설명한 것과 같은 language repository에 연결하여 간접적으로 의존성이 있는 모든 software를 포함하여 사용자가 지정한 software를 검색하고, 구성한다. 이러한 방식으로 software 검색과 관리를 단순화하면서 PDM은 현대 software 개발에 필요한 전문지식과 자원의 수준을 크게 줄였다.

그러나 PDM은 단순한 software 검색 도구일 뿐이다. PDM은 검색된 software에 대해 다음 사항을 확인하지 않으며, 이를 수정하기 위한 실행 가능한 방법도 없다.

• 알려진 보안 및 신뢰성 문제가 있는지
• 예상치 않은 혹은 악의적인 행동이 포함되었는지
• 오해의 소지가 있는 package 이름이 있는지 (“typosquatting” 및/또는 built-in library의 이름과 비슷한)

Vaidya et al, “Security Issues in Language-based Software Ecosystems, March 6, 2019, https://arxiv.org/abs/1903.02613

대신에, 이런 practice는, 위에서 논의한 바와 같이, 일반적으로 software supply chain의 다른 부분에서 수행되어야 하는데, 일반적으로 그렇지 못한다. 이로 인해 어느 정도의 보안과 품질을 보장하기 위한 PDM 사용자와 PDM maintainer의 노력은 검색된(retrieved) software 내에서 좌절된다. 특히, PDM과 관련된 보안 사고의 빈도가 증가되는 것에서도 볼 수 있듯이, PDM의 현재 절차 내에 내재된 약점들은 악의적인 공격자들에게 인기 있는 수단이 되고 있기 때문에 문제가 된다.

Vulnerability Database

위에서 논의한 바와 같이 현대의 software는 많은 software package가 함께 구성된다. 이러한 “building block” package는 독점 코드, 라이선스 받은 코드, 또는 OSS 일 수 있으며, 수십 개에서 수천 개의 block이 구성될 수 있다. 이는 상당한 이점을 제공하지만, 위험 또한 초래한다. 오늘날 개발자와 회사는 자체 코드의 버그와 취약점뿐만 아니라 제품이 의존하는 각각의 software package에 대해서도 관리해야 한다.

현대 software 개발이 사내 개발 전략보다 앞서가는 것처럼, 현대 software에서 발견되는 취약점과 버그의 수, 다양성 및 고유성은 사내의 취약점 tracking으로 따라가는 것은 불가능하다. 이는 software 커뮤니티가 초기에 인정한 현실이었고, 이에 따라 취약성과 버그의 지정, 설명 및 추적을 위한 표준화된 미국 기반의 프로그램인 CVE (Common Vulnerability and Exposure) 프로그램과 NVD (National Vulnerability Database) 프로그램을 만들게 되었다.

이 두 프로그램은 20년 이상 존재했으며, 많은 현대의 사이버 보안 도구, 제품 및 practice의 토대가 되었다.

The NVD is considered so important that in 2018 it was exempted from the U.S. government shutdown. See “Closed Down: Government Shutdown Impacts Enterprise Security, December 31, 2018, https://duo.com/decipher/government-shutdown-impacts-enterprise-security

그러나 최근 몇 년 동안 두 프로그램 모두 새로운 기술의 놀라운 성장과 함께, NVD로의 추가 요청이 크게 증가하면서 어려움을 겪고 있다. 이러한 어려움은 다음과 같은 여러 가지 downstream 문제를 야기시켰다.

• vulnerability가 누락되거나 거부되어 NVD의 불완전한 coverage를 초래 (Over 6,000 vulnerabilities went unassigned by MITRE’s CVE project in 2015, Steve Ragan, CSO Online (Sep. 22, 2016), https://www. csoonline.com/article/3122460/over-6000-vulnerabilities-went-unassigned-by-mitres-cve-project-in-2015.html.)
• vulnerability identifer의 할당이 심각하게 지연되면서, 이를 알지 못하고 있는 downstrea party에게 위험을 초래
• vulnerability에 대한 설명이 부족하여 치료와 관리의 어려움이 증대
• 과도하게 부풀려지거나 낮게 평가된 vulnerability score로 인해 리소스가 잘못 할당되거나, 어떤 경우에는 vulnerability " 피로"가 발생
• 이력서를 채우기 위해 vulnerability 수를 부풀리는 개발자에 의한 남용
• 할당된 vulnerability가 유효하지 않은 것으로 판명될 경우, 이를 취소하는 게 어렵고, 혼동을 유발하여 전체 프로그램에 대한 신뢰 부족 초래
• CVE 할당을 정상적인 Software 업그레이드를 수행할 수 없는 어려운 관리 절차를 회피하는 방법으로 간주하는 조직의 엔지니어에 의한 남용
• CVE 프로그램이 미국 연방 기관에 의해 관리되는 것 자체가 불편
• 장기간에 걸쳐 여러 package를 여러 번 수정해야 하는 지속적이고 복잡한 vulnerability를 처리할 수 없음

결과적으로 거의 모든 현대 기업, 연방 기관 및 기타 조직을 포함하여 CVE 및 NVD 프로그램에 의존하는 많은 이해관계자들은 vulnerability 노출을 완전히 해결하지 못하고 있다. 더 나쁜 것은, NVD coverage의 부족해서 알람이 적은 상황임에도 이해관계자들은 자신들의 제품이 안전하고 신뢰할 수 있다고 믿는 잘못된 보안 의식을 야기할 수 있다는 것이다.

End User Practice

Software supply chain의 최종에 있는 이들의 위치를 고려할 때 End User는 보안에 대한 통제력이 가장 낮을 것이다.

그러나, supply chain이 loop 형태라고 생각한다면 이야기는 달라진다.

End User의 경우 일반적으로 기술 공급 업체의 솔루션을 사용할 것이고, 이 경우, PDM 또는 OSS package 선택에 대한 결정을 내릴 수 없다. 하지만, End User는 “인수 요구사항” (Acuisition Requirement)을 통제할 수 있다 (다만, 많은 User는 이를 충분히 활용하지 않고 있다).

여기서의 Best Practice는 End User가 기술 제공업체와 협상할 때 계약서에 다음과 같은 요구사항을 추가하는 것이다.

• Dependency List, Software BOM (bills-of-material) 또는 이러한 component tracking mechanism이 매우 견고하고 투명한 방식으로 제공된다.
• 제품 내의 Vulnerability는 특정 기간 내에 개선되어야 한다.
• 개발에 관련된 모든 개발자 계정은 2FA 또는 MFA를 사용해야 한다.

End user가 자신의 솔루션 내의 OSS package에 대해 개발자 Practice에서 논의된 동일한 practice를 자체적으로 수행하는 경우도 있다. 또한, 이러한 practice와 “인수 요구사항” practice 외에도 End User가 취할 수 있는 실질적인 단계가 있다. 즉, Software 신뢰도를 검사하고, Software 다운로드는 신뢰할 수 있는 곳에서 하고, 그들이 수취한 software가 요청한 software인지 확인하는 것이다. 그리고 Supply chain 문제의 영향을 줄이기 위해 Software에 주는 권한을 제한하는 것이다.

그럼에도 여전히 다음과 같은 사실은 남아 있다.

• Software가 실제로 “신뢰할 수 있다”(trustworthy)는 것이 무엇을 의미하는지 합의된 이해가 부족하고 효과적인 도구가 없기 때문에 Software가 신뢰할 수 있는지 판단하기 어렵다.
• 이와 유사하게, 위에서 논의한 repository와 같은 다운로드 장소가 신뢰할 수 있는지를 알아내는 것은 어렵다.
• User는 정종 그들이 요청한 Software가 그들이 신뢰하는 package인지 아니면 악의적, 사기적, 혹은 잘못된 것인지 확인하기 어렵다.
• 마찬가지로, User는 그들이 받은 Software가 자신들이 원하는 software인지 digital signature를 확인하는 등의 방법으로 확인하지 못한다. 그리고, 일부 user는 보안, 품질 등의 확인도 없이 software를 받자 마다 코드를 실행한다.

End User는 Software Supply Chain에 영향을 미칠 수 있는 가장 좋은, 그리고 가장 나쁜 위치에 있다. Vendor로부터 기술을 취득하는 기업의 경우, acquition practice를 활용하여 vendor에게 보안 best practice를 적용하도록 권장할 수 있지만, 여전히 제공받은 제품의 결함을 시정하거나 혹은 이를 알아내는 조차도 어려움이 있다. 자신의 Software를 스스로 관리하려는 End User의 경우, 이를 위해서는 End User가 본질적으로 개발자가 되어야 하고, 이를 위해 적절하게 행동해야 함을 인식해야 한다. 두 경우 모두, End User는 현대의 Software 개발이 변화하면서 그들 자신의 행동도 변화해야 함을 알아야 한다.

결론

현대의 Software 개발은 “Supply Chain"이 대규모로 분산되어 있다. 계속 증가만 하는 이런 경향은 제품의 평균 출시 시간을 줄이고, 상당한 가치를 창출했지만, 또한 위험과 남용의 기회를 창출했다.

Software repository, package manager 및 vulnerability database는 이를 활용하는 개발자 및 End User와 마찬가지로 모두 software supply chain에서 필요한 구성 요소이다. 그러나 현재의 내재된 vulnerability가 해결되지 않는 한, 이에 의존하는 기업과 개발자들은 계속해서 중대한 위험에 노출될 것이다. 이 글은 Software supply chain 내의 알려진 문제를 강조하고 이를 해결하기 위한 조치를 취하기 위해 작성되었다. Linux Foundation은 이러한 문제를 해결하기 위한 종합적인 솔루션을 설계하기 위해 글로벌 기술 리더 회의를 소집할 것이다.