오픈소스와 기업 IP: GPL·Apache 쓸 때 특허·저작권 리스크

“우리 제품에 오픈소스 라이브러리 넣었는데, 나중에 소스 공개하라고 하면 어떡하죠?”

소프트웨어·플랫폼을 만드는 기업이라면 한 번쯤 듣는 질문입니다. 오픈소스는 개발 속도를 높여 주지만, 라이선스 조건을 잘못 이해하면 저작권 공개 의무나 특허 분쟁에 휘말릴 수 있습니다. “그냥 쓰면 되지”라고 넘기기엔, 나중에 M&A·IPO·수출 시 IP 실사에서 걸리는 경우가 많습니다.

오늘은 GPL·Apache 등 오픈소스 라이선스와 기업 IP를 실무 관점에서 정리해 드립니다.

1. 오픈소스, ‘공짜’가 아니라 ‘조건부 사용권’ 📜

오픈소스는 무료이지만 조건 없이 쓸 수 있는 것은 아닙니다. 각 라이선스마다 의무 사항이 다릅니다.

저작권 표시·라이선스 유지: 대부분의 오픈소스는 “이 코드는 OO 라이선스다”라고 표시하고, 라이선스 문을 유지하라고 요구합니다. 이건 기본 중의 기본입니다.
소스 코드 공개 의무 (Copyleft): GPL 계열은 이 라이브러리를 연결한 프로그램까지 소스 코드를 공개하라고 할 수 있습니다. 상용 제품에 GPL을 맹목적으로 넣으면, 제품 전체 공개 요구로 이어질 수 있어 주의가 필요합니다.
특허 조항: Apache 2.0 등은 “이 코드를 쓴다면, 이 코드와 관련된 자신의 특허를 사용자에게 무료로 허용한다”는 특허 라이선스를 포함합니다. 사용하는 쪽에서는 보호받지만, 기여하는 쪽에서는 특허를 내놓는 효과가 있을 수 있습니다.

“그냥 복사해서 썼다”는 식으로 넘기지 말고, 어떤 라이선스인지, 어떤 의무가 붙는지 먼저 확인하는 습관이 필요합니다.

2. 자주 쓰는 라이선스별 한 줄 정리 🔍

GPL (v2 / v3)

핵심: 이 코드를 수정·연결한 결과물도 GPL로 공개해야 합니다. 동적 링크만 해도 GPL이 전파될 수 있어, 상용 제품과 한 바이너리에 묶으면 제품 소스 공개 요구를 받을 수 있습니다.
기업 대응: GPL 코드는 별도 프로세스·별도 모듈로 분리해 두거나, 아예 상용 제품에는 쓰지 않고 내부·테스트용으로만 쓰는 전략이 안전합니다. 꼭 쓸 경우 변리사·법률 자문을 받는 것이 좋습니다.

Apache 2.0

핵심: 소스 공개 의무는 없고(Permissive), 저작권·특허 표시와 변경 사항 고지만 하면 됩니다. 상용 제품에 넣기에는 GPL보다 부담이 적습니다.
주의: Apache 2.0은 특허 허용 조항이 들어 있어, 이 코드를 사용·배포하는 자는 해당 코드와 관련된 자신의 특허를 주장하지 않는다는 효과가 있습니다. 회사가 나중에 그 기술로 특허를 내서 다른 회사를 공격하는 데 쓰기 어려울 수 있으니, 전략적 특허와의 관계를 한 번 점검해 두는 것이 좋습니다.

MIT / BSD

3. 기업이 준비해야 할 3가지 🛡️

라이선스 정책 수립: “어떤 오픈소스를 도입해도 되고, 어떤 것은 금지한다”는 내부 가이드를 만듭니다. GPL은 금지 또는 별도 검토, Apache/MIT는 조건부 허용 등으로 정리해 두면 개발팀이 혼선 없이 따를 수 있습니다.
도입 전 검토: 새 오픈소스를 도입할 때 라이선스·의무 사항을 체크하는 절차(체크리스트 또는 간단한 승인 플로우)를 둡니다. 법무·IP 담당이 한 번씩 보거나, 외부 자문을 받는 것도 방법입니다.
BOM(Bill of Materials) 관리: 제품에 들어간 오픈소스 목록과 라이선스를 문서로 관리합니다. M&A·IPO·수출 시 “이 제품에 어떤 오픈소스가 들어갔고, 각각 라이선스는 무엇인가?”를 바로 답할 수 있게 해 두면 IP 실사 대응이 수월합니다.

Tip: “나중에 정리하면 되지”라고 미루다가, 투자 유치나 상장 단계에서 “GPL 사용 이력이 있는데 소스 공개했나요?”라는 질의를 받으면 답하기 어렵습니다. 도입 시점부터 라이선스와 BOM을 정리하는 습관을 들이세요.

마치며: 오픈소스는 ‘알고 쓰면’ 강력한 도구

소프트웨어를 다루는 기업이라면 오픈소스 IP 정책을 한 번 점검해 보시길 권합니다.