감사받은 상용 코드베이스의 98%가 오픈소스를 포함합니다. 그리고 68%에서 라이선스 충돌이 발견됐습니다. 오픈소스를 쓰지 않는 선택지는 이제 없습니다. 문제는 카피레프트 의무를 지키려고 소스코드를 공개하는 순간, 그 안에 담긴 기술적 아이디어까지 ‘공지’된다는 점입니다.
오픈소스를 안 쓰는 선택지는 없습니다
라이선스 충돌은 대개 악의가 아니라 무엇을 쓰고 있는지 모르는 상태에서 생깁니다. 그래서 질문은 “쓸 것인가”가 아니라 “어떻게 관리할 것인가”로 옮겨 왔고, 그 기준이 ISO/IEC 5230입니다.
ISO/IEC 5230 — 제품이 아니라 ‘체계’를 인증합니다
ISO/IEC 5230:2020은 리눅스 재단의 OpenChain 규격 2.1을 그대로 국제표준화한 것입니다. 오해가 잦은데, 적합 판정의 대상은 특정 소프트웨어 제품이 아니라 라이선스 컴플라이언스 프로그램 — 정책·프로세스·인력의 집합입니다. 제품은 그 체계를 ‘통과’할 뿐입니다. 그래서 “ISO 5230 인증을 받은 제품”이라는 표현은 정확하지 않고, “적합한 컴플라이언스 체계를 갖춘 조직”이라고 해야 맞습니다.
잠깐, ISO/IEC 5230 정리
- 요구사항 6개 영역 — ① 프로그램 기반(정책·역량·인식) ② 업무의 정의와 지원 ③ 오픈소스 검토·승인(BOM·라이선스 준수) ④ 컴플라이언스 산출물 ⑤ 커뮤니티 기여 이해 ⑥ 규격 준수
- 적합 확인 — 자체선언(self-certification)과 제3자 인증이 모두 인정되며, 적합 상태의 유효기간은 18개월입니다.
- 자매 표준 — ISO/IEC 18974:2023은 같은 구조로 오픈소스 보안 관리체계를 다룹니다.
- 국내에서도 삼성전자·LG전자·현대자동차·카카오·KT 등이 적합 조직 목록에 올라 있습니다.
“라이선스는 지켰는데, 특허를 잃는 일이 생깁니다.”
소스코드를 공개하면, 특허는 어떻게 될까요
GPL 계열 라이선스를 쓴 코드를 제품에 결합해 배포하면, 결합 저작물 전체의 대응 소스코드(Corresponding Source)를 제공해야 합니다. AGPL-3.0은 수정한 버전을 네트워크로 원격 이용시키는 경우에도 소스 제공 기회를 주도록 정합니다(제13조). 컴플라이언스 관점에서는 당연히 지켜야 할 의무입니다.
그런데 특허법의 눈으로 보면 사정이 달라집니다. 우리 특허법 제29조 제1항 제2호는 “전기통신회선을 통하여 공중이 이용할 수 있게 된 발명”을 신규성 상실 사유로 명시합니다. 공개 저장소에 올라간 소스코드는 이 문언에 그대로 들어맞고, 커밋에는 날짜와 시각까지 기록되어 공지 시점을 다투기도 어렵습니다.
저작권과 특허는 다릅니다. 공개해도 저작권은 사라지지 않습니다. 오히려 모든 오픈소스 라이선스가 저작권을 근거로 조건을 부과하죠. 그러나 그 코드에 담긴 기술적 아이디어는 공개 시점에 공지되어 특허의 신규성을 잃습니다. 그리고 이 손실은 나라마다 회복 가능성이 다릅니다.
한국은 특허법 제30조에 따라 자기 공지일부터 12개월 안에 출원하면서 출원서에 취지를 적고 증명서류를 내면 구제받을 수 있습니다(2011년 개정, 2012년 3월 15일 이후 출원분부터 적용). 미국도 1년의 유예가 있습니다. 그러나 유럽특허조약 제55조는 명백한 남용과 공인 국제박람회 전시 두 가지만 6개월간 예외로 인정하고, 중국 특허법 제24조도 한정된 네 가지 사유뿐입니다. 깃허브에 올린 코드는 어느 쪽에도 해당하지 않습니다.
라이선스에 숨은 ‘특허 조항’도 봐야 합니다
공개 여부만 문제가 아닙니다. 라이선스 자체가 특허를 건드립니다. Apache License 2.0 제3조는 기여자가 자신의 기여에 필수적으로 침해되는 특허청구항에 대해 무상·전세계·비독점의 실시권을 부여하도록 하고, GPL-3.0 제11조도 기여자의 필수 특허청구항에 같은 취지의 실시권을 부여합니다. 사내 특허 기술이 들어간 코드를 오픈소스로 기여하는 순간, 그 특허를 스스로 열어 주는 결과가 될 수 있다는 뜻입니다.
| 라이선스 | 소스코드 공개 의무 | 특허 조항 |
|---|---|---|
| MIT · BSD | 없음(고지만 유지) | 명시적 조항 없음 |
| Apache 2.0 | 없음(고지·변경 표시) | 제3조 특허 실시권 부여 + 특허 보복 조항 |
| LGPL | 라이브러리 부분 + 재링크 수단 | (v3) 있음 |
| GPL-2.0 | 결합 저작물 전체 | 명시적 부여 조항 없음(제7조) |
| GPL-3.0 · AGPL-3.0 | 결합 저작물 전체 (AGPL은 수정 후 원격 제공 시에도) | 제11조 특허 실시권 부여 |
공개할 것과 지킬 것을 먼저 가르십시오
실무에서 필요한 것은 세 가지입니다. 첫째, 공개 일정과 출원 일정을 맞추는 것 — 릴리스 날짜가 잡히면 그 전에 출원이 끝나 있어야 합니다. 둘째, 공개 범위에서 핵심 아이디어를 분리하는 설계 — 무엇이 결합 저작물에 들어가느냐에 따라 공개 범위가 달라집니다. 셋째, 기여 전 특허 조항 검토입니다.
ISO/IEC 5230은 라이선스 리스크를 다루는 훌륭한 틀이지만, 특허를 지켜 주지는 않습니다. 두 축을 같은 일정표 위에 올려놓는 일은 결국 사람이 해야 합니다.