English · 한국어

라이선스 안내 (서드파티와 프로젝트 라이선스)¶

이 문서가 다루는 것: 오늘 기준으로 pqcota가 내부에서 쓰는 모든 라이선스를, 쓰이는 형태별로 정리한 것입니다. 배포하는 바이너리에 링크되는지에 따라 라이선스 의무가 완전히 달라지므로 쓰이는 형태가 중요합니다.

이 문서는 라이선스 축입니다. 각 의존성이 어떤 라이선스인지, 어떤 형태로 쓰이는지를 다룹니다.

§ 표기: 이 문서에 나오는 §N은 이 문서의 절 번호입니다.

⚠️ 면책: 이 문서는 법률 자문이 아닙니다. 배포 전에는 OSS 라이선스를 전문으로 하는 법률가의 실사(GPL과 AGPL의 구분, or-later, 버전별 정확한 조건)가 필요합니다.

0. 한 줄 결론¶

pqcota 제품 바이너리에 링크되거나 묶여 들어가는 서드파티는 모두 허용형(permissive) 라이선스(Apache-2.0 / MIT / BSD-3)입니다. 카피레프트(GPL 계열)는 별도 프로세스로 실행되는 도구(Ansible, 데모 환경의 JDK)에만 있고, 어느 것도 pqcota 바이너리에 링크되거나 묶여 들어가지 않습니다(§5). 그것이 각 도구의 라이선스상 무엇을 뜻하는지는 따로 검토할 일이며, 이 문서가 정하지 않습니다.

1. pqcota 자체의 라이선스¶

이 리포(pqcota)는 Apache-2.0입니다. 배포 산출물(Go 바이너리, Java 사이드카)에 링크되거나 묶여 들어가는 서드파티는 모두 허용형입니다(§2 표).

CBOM 적재 명령(pqcota-cbom-ingest)은 CBOMkit 같은 GPL 계열 생성 도구를 실행하지 않고, 그 도구가 만든 CycloneDX 파일만 읽습니다(CBOM 수신을 위임하는 설계). 그것이 그 도구들의 라이선스상 무엇을 뜻하는지는 따로 검토할 일입니다(아래).

2. 빌드 산출물에 링크되는 런타임 의존성 (Go)¶

이 리포에서 빌드하는 정적 Go 바이너리(수집기, CLI)에 컴파일되어 링크되는 의존성입니다. 모두 허용형입니다.

gopkg.in/yaml.v3(MIT)는 위 목록에 없습니다. 데모 토폴로지 생성기와 테스트에서만 쓰이므로 수집기나 CLI에는 링크되지 않습니다.

요약: 링크되는 카피레프트는 없습니다. Apache-2.0, MIT, BSD-3은 보통 Apache-2.0 배포와 호환되는 것으로 보며, 저작권 고지는 지켜야 합니다(아래). (배포할 때는 각 라이선스가 요구하는 고지와 조건을 지켜야 합니다. MIT는 저작권·허가 고지를, BSD-3-Clause는 저작권 고지·조건·면책 고지를 요구하고 기여자 이름을 제품 홍보에 쓰는 것을 제한합니다. 이 리포는 그것을 THIRD-PARTY-NOTICES에 모아 둡니다. 그 파일 이름 자체가 요건은 아닙니다.)

3. 빌드 시점 도구 (산출물에 링크되지 않음)¶

코드 생성과 컴파일에만 쓰이고, 결과 바이너리에는 링크되지 않습니다.

4. 데모 환경 구성 요소 (demo/): 별도 프로세스와 컨테이너, 링크되지 않음¶

아래 구성 요소는 관측 데모(demo/)에서 SSH, 하위 프로세스, 컨테이너로 실행되며 어떤 pqcota 바이너리에도 링크되지 않습니다.

demo/는 컨테이너와 별도 실행 파일로 동작합니다. 거기 있는 어느 것도 pqcota 바이너리에 정적으로도 동적으로도 링크되지 않습니다. 모두 SSH, 하위 프로세스, 컨테이너의 프로세스 경계 너머에서 실행됩니다 → GPL이나 카피레프트 도구는 거기서도 별도 프로그램으로 남습니다. 그 라이선스가 무엇을 요구하는지는 따로 검토합니다(§5).

GPL 도구(Ansible, Temurin)를 다루는 방식: 이 도구들은 pqcota가 호출하는 별도 프로그램이지 링크 대상이 아닙니다. Ansible은 플레이북을 실행하는 오케스트레이터이고, Temurin은 대상 노드의 런타임일 뿐입니다. 이 도구들을 쓰는 것이 GPL상 의무를 만드는지는 프로그램이 주고받는 방식만으로 정해지지 않으므로 따로 검토합니다. 지금 제공하는 빌드 절차에서는 사용자가 이미지를 만들 때 이 도구들을 내려받으며, pqcota가 싣지 않습니다. 완성된 컨테이너 이미지를 배포한다면 그 안에 든 구성 요소의 재배포 조건을 따로 확인합니다.

5. GPL 코드를 떼어 두는 방법: 무엇이 지키는가¶

GPL 코드는 구조로 pqcota의 코드와 배포물에서 떼어 둡니다. 원칙은 셋입니다(기술적 조치이며 법적 결론이 아닙니다).

1. 프로세스 분리: GPL 구성 요소는 독립된 바이너리로 호출하고, 라이브러리로 링크하지 않습니다.
2. 표준 데이터 경계: 프로세스 사이의 교환은 CycloneDX CBOM(표준)으로만 합니다. 핵심 내부 API는 이 경계를 넘지 않습니다.
3. 배포 분리: GPL 코드는 이 리포나 그 배포물에 묶어 넣거나, 정적으로 링크하거나, vendor하지 않습니다.

직접 GPL 수집기를 만들더라도 같은 경계가 적용됩니다. 구성 요소별 정확한 라이선스(GPL과 AGPL, or-later)와 SaaS 배포에서의 AGPL 영향은 실사가 필요합니다. 이 문서는 법률 자문이 아닙니다.

이 원칙을 지키는 것은 아래 표입니다.

demo/의 Ansible(GPL-3)과 Temurin(GPLv2+CE)도 같은 경계 밖에서 별도 프로세스로 실행됩니다.

이 리포는 Apache-2.0으로 공개됩니다. 요점은 관측 가능성을 열어 커뮤니티가 수집기를 더할 수 있게 하는 것이고, 참조 수집기가 OSS인 것도 같은 이유입니다(시중 도구가 다루지 않는 JVM 내부 조회도 포함합니다).

라이선스를 적는 자리. 각 수집기는 CollectorCapabilities.license(와 Envelope.collector_license)에 라이선스를 적으므로, 호출하는 쪽이 그 백엔드가 「따로 설치하는 GPL 구성 요소」인지 「참조 구현 = Apache-2.0, 포함됨」인지 밝힐 수 있습니다.

부록: 쓰이는 형태별 한눈에 보기¶