네덜란드 및 EU 법률에 따른 오픈 소스 소프트웨어 라이선스

거의 모든 상용 소프트웨어 제품에는 개발자가 선택한 수백 개의 오픈 소스 구성 요소가 포함되어 있습니다. 이는 법률 전문가의 의견이 아닌 개발자의 판단에 따른 것입니다. 따라서 어떤 라이선스가 적용되는지, 라이선스가 요구하는 사항은 무엇인지, 그리고 제품이 해당 라이선스를 준수하는지 여부를 명확히 규정할 수 없는 문제가 발생합니다. 이 글에서는 네덜란드 및 EU 법률에 따른 오픈 소스 라이선스의 작동 방식, 관련 위험 요소, 그리고 필요한 조치에 대해 설명합니다.

법률적인 관점에서 오픈 소스 라이선스란 무엇인가

오픈 소스 라이선스는 특정 조건을 전제로 부여되는 저작권 라이선스입니다. 이는 권리 포기나 공공 영역으로의 이양, 권리 양도가 아니며, 이러한 점에서 네덜란드 법률에 따른 다른 소프트웨어 라이선스 와 동일하게 작동합니다 . 저작자는 컴퓨터 프로그램을 저작물로 보호하는 네덜란드 저작권법 제1조 및 제10조에 따라 저작권을 보유하며, 이 라이선스는 제12조 및 제13조에 따른 배타적 권리를 침해할 수 있는 행위를 허용합니다.

정의보다는 결과가 더 중요합니다. 규정을 준수하면 복제 및 배포가 합법적입니다. 하지만 규정을 준수하지 않으면 허가가 적용되지 않아 저작권 침해가 발생하며, 이는 계약 위반이 아닙니다. 대부분의 카피레프트 라이선스는 위반 시 자동으로 계약이 종료되도록 규정하고 있습니다. GPLv2는 시정 기간이 없으며, GPLv3 및 AGPLv3는 통지 후 정해진 기간 내에 위반 사항을 시정하면 권리가 복원됩니다.

네덜란드 법원은 이러한 논리를 적용합니다. Rb. Amsterdam 2020년 9월 22일, ECLI:NL:RBAMS:2020:4717 판례에서, 포크된 코드베이스에서 라이선스 텍스트와 저작권 표시를 삭제한 배포자는 사용 권한을 상실하고 저작권을 침해한 것으로 판결되었습니다. 대량의 새 코드를 추가한다고 해서 독립적인 저작물이 생성되는 것은 아니며, 원본은 여전히 ​​식별 가능한 형태로 존재하므로 관련 의무는 원본과 함께 이전됩니다.

두 가지 계열: 허용적 계열과 카피레프트 계열

관대한 라이선스 (MIT, BSD 라이선스, Apache 2.0 등)는 저작권 고지 및 라이선스 텍스트를 유지하는 조건 하에 폐쇄형 소스 제품 내부를 포함하여 사용, 수정 및 재배포를 허용합니다.

카피레프트 라이선스는 소프트웨어 또는 이를 기반으로 제작된 무언가를 배포할 때 동일한 라이선스를 적용하고 해당 소스 코드를 공개하도록 요구합니다. 라이선스마다 적용 범위가 다릅니다.

카피레프트 트리거와 링크 관련 질문

카피레프트 의무는 사용이 아닌 배포에 적용됩니다. 아무리 많이 수정했더라도 GPL 소프트웨어를 내부적으로 사용하는 회사는 아무것도 배포하지 않으며, 그에 따른 의무도 없습니다. "우리가 배포했는가?"라는 질문이 항상 첫 번째로 떠오르며, 컨테이너, 어플라이언스, 펌웨어 및 SDK가 내부 도구보다 더 중요한 이유도 바로 여기에 있습니다.

두 번째 질문은 더 어렵습니다. GPL은 미국의 파생 저작물 개념을 차용하여 "프로그램에 기반한 저작물"이라는 용어를 사용합니다. 네덜란드 법에는 그러한 용어가 없으므로, 복제 및 각색 권리를 분석하여 원본의 보호받는 표현이 복제되었는지 여부를 판단해야 합니다.

실질적인 문제는 링크입니다. 독점 모듈을 GPL 라이브러리에 링크하는 것이 카피레프트 라이선스가 적용되는 하나의 저작물을 생성하는지 여부는 네덜란드 법원에서 판결된 적이 없으며, EU에서도 구속력 있는 판례가 없습니다. 링크가 결합된 저작물을 생성한다는 자유소프트웨어재단의 견해는 라이선스 관리자의 해석일 뿐 법률이 아니며, 반대 의견 역시 검증되지 않았습니다. 인터넷에서 흔히 볼 수 있는 "동적 링크는 안전하지만 정적 링크는 위험하다"는 답변은 컴파일러의 동작 방식을 묻지 않는 네덜란드 저작권법에 근거가 없습니다. 보다 타당한 분석은 구성 요소들이 얼마나 밀접하게 결합되어 있는지를 묻는 것입니다. 주소 공간과 데이터 구조를 공유하는지, 결합된 구성 요소가 하나의 제품으로 출시되는지, 각각 독립적으로 작동할 수 있는지, 독점 모듈 측이 카피레프트 모듈 측의 헤더, 매크로 또는 인라인 코드를 복제하는지 등을 살펴봐야 합니다. 이러한 질문들을 통해 위험성을 판단할 수 있습니다. 만약 위험성이 판단되지 않는다면, 해당 구성 요소를 프로세스 경계 뒤에 격리하거나, 교체하거나, 상업용 라이선스를 취득해야 합니다.

AGPL 및 네트워크 사용

AGPL이 존재하는 이유는 카피레프트가 배포에 의해 발생하는데, SaaS 제공업체는 배포를 하지 않기 때문입니다. AGPL의 네트워크 조항은 소프트웨어를 수정하여 원격으로 상호 작용하는 사용자에게 제공하는 경우, 수정된 버전의 소스 코드도 함께 제공해야 한다고 규정합니다.

흔히 간과되는 세 가지 중요한 점이 있습니다. 첫째, 이 의무는 서비스 사용자에게 적용되는데, 누구나 가입할 수 있는 제품에서는 그다지 위안이 되지 않습니다. 둘째, 수정이 있을 때 이 의무가 발생하므로, 수정되지 않은 구성 요소는 이 의무의 적용을 받지 않지만 패치된 빌드는 적용될 수 있습니다. 셋째, 이는 스택의 나머지 부분에 적용되는 GPL과 동일한 공동 작업 문제를 제기합니다. 바로 이러한 이유로 많은 기업에서 프로덕션 코드에 AGPL을 금지하는 것입니다.

라이선스 호환성

호환성 문제는 서로 다른 라이선스가 부과하는 의무를 하나의 배포판에서 모두 충족할 수 없는 구성 요소를 결합할 때 발생합니다. 관대한 라이선스는 거의 모든 것과 호환되지만, 카피레프트 라이선스는 자체 약관에서 허용하는 범위 내에서만 호환됩니다. 대표적인 예는 Apache 2.0과 GPLv2입니다. Apache 소프트웨어 재단과 자유 소프트웨어 재단은 Apache 2.0의 특허 종료 및 면책 조항이 GPLv2에서 허용되지 않는 추가적인 제한 사항이기 때문에 두 라이선스의 조합이 허용되지 않는다는 데 동의합니다. GPLv3는 이러한 조항을 수용하도록 설계되었습니다. 호환성은 또한 방향성을 가집니다. Apache 코드는 GPLv3 프로젝트에 통합될 수 있지만, 그 반대는 불가능합니다. 잘못된 위치에 있는 하나의 GPL 구성 요소는 라이선스 변경, 재설계 또는 제거 중 하나를 선택해야 하는 상황을 초래할 수 있으며, 이는 출시 후보다 출시 전에 처리하는 것이 훨씬 저렴합니다.

출처 표기 및 고지 의무

가장 빈번하게 위반되는 의무는 가장 눈에 띄지 않는 것들입니다. 바로 배포 자료에 저작권 고지, 라이선스 문구, 면책 조항, 그리고 아파치 2.0 라이선스에 따라 NOTICE 내용을 포함하는 것입니다. MIT와 BSD를 포함한 모든 배포판에서 이러한 의무를 요구합니다. 이러한 의무가 위반되는 이유는 누구의 소유권도 없기 때문이며, 수정하기도 가장 쉽습니다. 보통 제품에 포함된 저작권 표시 파일을 통해 해결할 수 있습니다. 앞서 언급한 네덜란드 사례도 바로 이러한 의무 위반에서 비롯되었습니다.

특허 부여 및 특허 보복

MIT와 BSD는 특허에 대해 아무런 언급도 하지 않으며, 특허 라이선스가 묵시적으로 인정될 수 있는지 여부는 불확실합니다. 아파치 2.0은 각 기여자에게 명시적이고 로열티가 없는 특허 라이선스를 부여하는 조항을 추가했으며, 보복 금지 조항도 포함했습니다. 즉, 해당 작업이 특허권을 침해했다고 주장하며 소송을 제기할 경우 특허 라이선스가 종료됩니다. GPLv3도 이와 유사한 라이선스 부여 조항과 자체적인 특허 조항을 포함하고 있습니다.

특허 포트폴리오를 보유한 기업에게는 두 가지 중요한 의미가 있습니다. 첫째, 엔지니어가 Apache 또는 GPLv3 라이선스가 적용된 프로젝트에 기여하는 경우, 해당 기업은 자사 특허에 따라 라이선스를 부여하는 셈입니다. 둘째, 만약 자사가 사용하는 Apache 라이선스 구성 요소를 사용하는 기업을 상대로 특허 소송을 제기할 경우, 보복으로 인해 의존하고 있는 라이선스를 잃을 수도 있습니다.

EUPL과 네덜란드 공공 부문

2017년 5월 유럽 위원회의 시행 결정으로 승인된 유럽 연합 공개 라이선스 버전 1.2는 OSI가 승인한 카피레프트 라이선스로, 세 가지 특징이 있습니다.

• 언어. 이 문서는 EU 공식 언어로 존재하며, 승인된 모든 버전은 동일한 효력을 가지므로 네덜란드 당국은 네덜란드어로 계약을 체결할 수 있습니다.
• 적합성. 부록에는 호환되는 라이선스(GPLv2 및 v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL 및 CeCILL 등) 목록이 있으며, EUPL 코드와 나열된 라이선스에 따른 코드를 결합한 파생 저작물을 해당 라이선스에 따라 배포할 수 있도록 허용합니다.
• 범위. 배포의 정의에는 온라인 또는 오프라인으로 작품을 이용할 수 있도록 하는 것이 포함됩니다. 또는 필수 기능에 대한 접근을 제공하는 것EUPL 제5조는 동일한 기능이 제공되는 원격 상호작용에까지 카피레프트 의무를 적용합니다. 따라서 EUPL은 GPL과 달리 서비스형 소프트웨어에도 적용됩니다.

네덜란드 공공 부문 고객은 법률이 아닌 정책 차원에서 EUPL(유럽 연합 소프트웨어 라이선스)을 요구할 수 있습니다. 상호 운용 가능한 유럽법(EU 규정 2024/903)은 공공 부문 기관이 오픈 소스와 같이 제한적인 라이선스 조건이 없는 상호 운용성 솔루션을 우선시하도록 규정하고 있습니다. 국내적으로 오픈 소스 원칙은 법률이 아닌 정부 결정 및 정책 방향에 따라 적용됩니다. 네덜란드 디지털 법은 디지털 신원 확인 인프라 구축을 지원하지만 모든 소스 코드를 공개해야 하는 강제적인 의무를 부과하지는 않습니다. 입찰 서류를 자세히 살펴보십시오. EUPL 요구 사항은 제출물에 적용되며, 재사용하려는 독점 코드와 호환되지 않을 수 있습니다.

실제 집행

누가 소송을 제기할 수 있을까요? 저작권자, 즉 개인 기여자 또는 양도된 저작권을 보유한 재단이나 회사입니다. 저작권이 분산되어 있다는 점이 실질적인 걸림돌이 됩니다. 소송을 제기하려면 문제의 코드에 대한 소유권을 입증해야 합니다. 이는 유럽에서 가장 잘 알려진 GPL 소송 사례에서 커널 개발자가 가상화 업체에 대해 제기한 소송이 저작권 입증 부족으로 기각된 사례에서 드러납니다(함부르크 지방법원, 2016년 7월 8일, 310 O 89/15; 함부르크 고등법원, 2019년 2월 28일, 5 U 146/16에서 확정 판결).

판례가 확립하는 바는 다음과 같습니다. 독일 법원은 최초의 GPL 금지 명령(LG ​​München I 2004년 5월 19일, 21 O 6123/04)을 시작으로 오픈 소스 라이선스가 유효하며, 라이선스 위반 시 배포가 불법이라는 점을 반복적으로 인정해 왔습니다. 미국 연방 항소법원도 Jacobsen v Katzer 사건(535 F.3d 1373 (Fed. Cir. 2008))에서 동일한 결론에 도달했습니다. 즉, 라이선스 조건은 단순한 약정이 아니라 부여 범위에 대한 조건이므로, 라이선스 위반은 저작권 침해 주장 및 금지 명령 구제의 근거가 된다는 것입니다. 미국 소송에서는 하위 수신자가 제3자 수익자로서 GPL을 강제할 수 있는지 여부를 다루고 있습니다. 캘리포니아 고등법원에서 심리 중인 Software Freedom Conservancy v Vizio 사건 의 핵심 쟁점은 바로 이것입니다 . 즉, 소비자가 제3자 수익자로서 GPLv2에 따라 소스 코드 공개를 요구할 수 있는지 여부입니다. 2025년 12월 23일, 법원은 약식 판결을 통해 GPLv2와 LGPLv2.1은 소스 코드를 다른 곳에서 사용하기 위해 획득하고 수정할 수 있어야 하며, 기기에 기능을 그대로 유지한 채 재설치할 수 있어야 한다는 요건은 충족할 수 없다고 판시했습니다. 제3자 수익자 문제는 본 재판에서 다뤄지게 되었으며, 재판은 여러 차례 연기되었습니다. 어쨌든 이는 캘리포니아 계약법에 관한 문제이므로 네덜란드에서는 구속력이 없으며, 다만 불만을 제기할 수 있는 사람의 수가 늘어날 뿐입니다.

네덜란드 법원은 이 사건을 어떻게 다룰까요? 저작권법(Auteurswet)에 따른 저작권 침해의 경우, 원고는 소유권과 복제 또는 전송 사실을 입증해야 합니다. 피고는 라이선스를 주장하고, 원고는 라이선스 계약 조건이 충족되지 않았다고 반박하므로 피고의 주장은 받아들여지지 않습니다. 계약법 제6조 265항에 따른 계약상 구제책도 있지만, 저작권이 더 강력한 구제 수단입니다.

구제책으로 는 독일 민법 제3조 296항에 따른 금지명령(일반적으로 벌금 부과 및 약식 절차 진행 가능), 독일 민법 제27조에 따른 손해배상 및 이익 반환 청구, 독일 민법 제28조에 따른 회수, 반환 또는 파기 명령, 그리고 독일 민법 제1019h조에 따른 합리적이고 비례적인 소송비용 전액 회수 등이 있습니다. 소프트웨어가 무료로 배포된 경우 손실액을 정확히 산정하기 어렵기 때문에 독일 항소법원은 금지명령은 유지하면서 손해배상은 인정하지 않았습니다(OLG Hamm, 2017년 27월 13일, 4 U 72/16). 실제로 가장 큰 부담은 손해배상이 아니라 금지명령, 회수 명령, 소송비용 부담, 그리고 의도치 않게 소스 코드를 공개해야 하는 상황입니다.

규정 준수 문제를 발견했을 때

일반적으로 보안 취약점은 고객의 보안 질문서, 실사 과정 중 실시한 검사 또는 권리 보유자의 서신을 통해 발견됩니다. 이후 복구 조치는 다음과 같이 진행됩니다. 취약점이 심각한 경우 해당 빌드의 배포를 중단합니다. 어떤 구성 요소, 어떤 버전, 어떤 라이선스, 어떤 제품 및 릴리스에 대해 어떤 기간 동안 문제가 발생했는지 파악합니다. 라이선스에서 실제로 요구하는 사항(소스 코드 배포보다는 저작권 표시 파일인 경우가 많음)을 확인합니다. 공지, 라이선스 텍스트, 빌드 스크립트를 포함한 해당 소스 코드 전체, 그리고 필요한 경우 서면 제안서와 같은 관련 자료를 준비합니다. 규정을 준수하는 릴리스를 배포한 후, 권리 보유자에게 조치 내용을 알리고 조치 의무 여부에 대한 논쟁을 피합니다.

GPLv3 및 AGPLv3에서는 시정 기간이 속도에 대한 법적 효력을 부여합니다. GPLv2에서는 시정권이 없기 때문에 대부분의 법적 집행은 협상을 통한 준수 약정으로 마무리됩니다. 또한, 변호사의 자문에는 특권이 적용되지만 내부 엔지니어링 보고서에는 적용되지 않는다는 점에 유의하십시오.

인수합병 및 실사 분야에서 오픈소스 활용

소프트웨어 인수 시 오픈 소스는 표준적인 실사 과정이며, 핵심 제품에 공개되지 않은 카피레프트 구성 요소가 포함되어 있는 경우는 거래 성사에 실질적인 영향을 미치는 몇 안 되는 발견 사항 중 하나입니다. 소스 코드를 공개하지 않고는 제품을 배포할 수 없다면, 구매자는 당초 가격에 책정된 자산과는 다른 자산을 인수하는 것이 되기 때문입니다.

코드베이스 스캔, 라이선스가 포함된 구성 요소 목록, 기여자 및 계약자 계약 관련 질문 등이 예상됩니다. 일반적인 결과로는 특정 면책 조항, 시정 조치 이행 시 보유금 지급, 제거를 요구하는 선행 조건, 또는 맞춤형 오픈 소스 보증 등이 있습니다. 판매자는 먼저 스캔을 진행해야 합니다. 판매자가 공개하는 내용은 협상의 소재가 되지만, 구매자 측 고문이 제시하는 내용은 협상력을 높여줍니다. 구매자는 "회사가 지적 재산권을 소유하고 있다"는 확인보다는, 독점 소스 코드 공개를 요구하는 오픈 소스가 제품에 포함되어 있지 않다는 확언을 얻어내야 합니다.

자재 명세서, 스캐닝 및 사이버 복원력법

소프트웨어 BOM(제품 명세서)은 제품 구성 요소, 버전 및 라이선스를 나열한 목록입니다. 최근까지는 순전히 계약상의 사항이었지만, 이제는 규제상의 의무도 되었습니다.

사이버 복원력법(Cyber ​​Resilience Act, CRA), 규정(EU) 2024/2847은 2024년 12월 10일에 발효되었으며 단계적으로 시행됩니다. 이 법은 제품이 아닌 조직을 대상으로 하는 네덜란드 사이버보안법 과 함께 적용됩니다 . CRA 제14조에 따른 활발히 악용되는 취약점 및 심각한 사고에 대한 보고 의무는 2026년 9월 11일부터, 적합성 평가 기관 통지 관련 조항은 2026년 6월 11일부터, 그리고 규정 전체는 2027년 12월 11일부터 시행됩니다(CRA 제71조). CRA 부록 I에서는 제조업체가 제품의 구성 요소를 식별하고 문서화하도록 요구하며, 여기에는 최소한 최상위 종속성을 포함하는 일반적으로 사용되는 기계 판독 가능한 형식의 소프트웨어 구성 요소 명세서(BOM) 작성이 포함됩니다. BOM은 공개할 필요는 없지만, 시장 감시 당국이 요청할 수 있습니다.

상업적 활동 외에서 제공되는 무료 및 오픈 소스 소프트웨어는 사이버보안법(CRA)의 적용을 받지 않습니다. 본 규정은 상업적 활동을 목적으로 하는 오픈 소스 소프트웨어 개발을 지속적으로 지원하는 법인인 오픈 소스 소프트웨어 관리자를 도입하여, CRA 제24조에서 관리자에게 완화된 의무를 부여합니다. 관리자의 의무에는 문서화된 사이버보안 정책, 시장 감시 당국과의 협력, 그리고 보고가 포함됩니다. 오픈 소스 소프트웨어를 상업화하거나 타인이 상업화하는 프로젝트에 자금을 지원하는 경우, 본인이 어떤 역할을 수행하는지 명확히 해야 합니다. 유럽 위원회는 2026년 7월 27일, 사이버보안법(CRA) 적용에 관한 첫 번째 지침인 'CRA 적용에 관한 위원회 지침'(통신 C(2026) 5252 첨부)을 채택했으며, 이 지침은 무료 및 오픈 소스 소프트웨어가 적용 대상에 포함되는 경우 등을 다루고 있습니다. 소프트웨어 구성 요소 목록(SBOM)의 형식을 규정하는 시행령은 아직 채택되지 않았으므로, 당분간은 규정 자체의 표준인 일반적으로 사용되는 기계 판독 가능 형식이 기준이 됩니다.

CI 환경에서 실행되는 소프트웨어 구성 분석은 규정 준수, 라이선스 검토 및 실사 작업을 한 번에 수행할 수 있는 인벤토리를 생성합니다. 그러나 이러한 도구는 벤더링된 코드를 놓치거나, 이중 라이선스가 적용된 프로젝트를 잘못 식별하거나, 라이선스 조건을 읽을 수 없습니다. 따라서 출력 결과는 검토의 시작점으로만 활용하고, 검토 자체로 간주해서는 안 됩니다.

직접 코드를 게시하는 경우: CLA 및 DCO

코드를 공개하고 외부 기여를 수용하는 회사는 자신이 통합하는 코드에 대한 권리를 보유하고 있음을 알고 있어야 합니다. 기여자 라이선스 계약 은 프로젝트와 기여자 간의 계약으로, 일반적으로 광범위한 저작권 라이선스와 명시적인 특허 라이선스를 부여하고 독창성과 권한에 대한 보증을 포함합니다. 이는 회사가 나중에 프로젝트의 라이선스를 재조정하거나 오픈 소스 라이선스와 함께 상업용 라이선스를 제공할 수 있도록 하는 기반이 됩니다. 하지만 이러한 계약의 비용은 마찰이라는 측면에서 발생합니다.

리눅스 커널과 여러 프로젝트에서 사용되는 개발자 원산지 증명서는 라이선스 부여가 아니라, 기여자가 해당 프로젝트의 라이선스에 따라 코드를 제출할 수 있음을 증명하는 간단한 확인서입니다. 각 커밋에 서명란으로 추가되는 이 증명서는 부담이 적고 보호 수준도 낮습니다. 특허 라이선스도 없고, 재라이선스도 필요하지 않습니다.

이중 라이선스 또는 향후 재라이선스가 가능하다면 CLA(공유 라이선스 계약)를 사용하십시오. 프로젝트가 진정한 공유 자산이라면 일반적으로 DCO(개발 허가 계약)로 충분합니다. 어떤 경우든 고용 계약 및 계약서에 직원들이 작성한 코드의 저작권을 양도한다는 내용을 명시하십시오.

실용적인 정책 체크리스트

• 제품 및 릴리스별 구성 요소 목록을 수동으로 작성하는 대신 빌드 파이프라인에서 생성하세요.
• 내부 정책을 수립하세요. 허용 목록, 금지 목록, 그리고 그 외 모든 사항에 대한 승인 절차를 명시하십시오.
• 배포에 포함되는 항목을 문서로 정의하십시오. 여기에는 온프레미스 설치, 어플라이언스, 컨테이너, SDK, 모바일 앱, 펌웨어가 포함됩니다.
• 생성된 저작권 표시 파일을 모든 제품에 포함하여 배송하세요.
• 라이선스 선택은 출시 시점이 아닌 구성 요소를 선택하는 설계 단계에서 승인해야 합니다.
• 특허권 부여와 관련된 사항을 고려하여 외부 프로젝트에 대한 기여에 승인이 필요한지 여부를 결정하고, 첫 번째 외부 기여 전에 CLA 또는 DCO를 선택하십시오.
• 제품에 실제로 포함된 오픈 소스에 맞춰 지적 재산권 보증, 면책 및 에스크로 조건을 조정하십시오.
• 자금 조달이나 매각 절차가 시작되기 전에 검토를 진행하세요. 절차 도중에 진행해서는 안 됩니다.

Law & More 소프트웨어 회사와 투자자들에게 다음과 같은 조언을 제공합니다. Eindhoven Amsterdam 오픈소스 규정 준수, 라이선스 검토, 기여자 계약 및 거래 내 오픈소스 워크스트림에 관한 내용입니다.