오픈소스 공개 의무 사항은 무엇인가요?

오픈소스 공개 의무 사항은 무엇인가요?

오픈소스 공개 의무 사항은 무엇인가요? 오픈소스 라이선스의 가장 핵심적인 공개 의무 사항은 오픈소스를 수정하거나 결합하여 외부로 배포(Distribution)할 때 해당 프로그램의 전체 또는 일부 소스 코드를 사용자에게 제공해야 한다는 점입니다. 하지만 모든 라이선스의 기준이 동일하지는 않으며, 사용 방식에 따라 그 범위가 크게 달라집니다.

대부분의 개발자가 이 부분에서 혼란을 겪습니다. 솔직히 말해서, 라이선스 법적 문서를 처음부터 끝까지 정독하는 사람은 거의 없습니다. (저 역시 주니어 시절 컴플라이언스 문제로 꼬박 2주를 날려버린 적이 있습니다). 산업 통계를 보면 상용 소프트웨어의 약 78%가 오픈소스를 포함하고 있지만, 라이선스 충돌 문제를 출시 전에 파악하는 기업은 절반도 되지 않습니다. 이것은 심각한 리스크입니다. 코드를 배포하는 순간 - 특히 강력한 상호호환성 라이선스가 포함되어 있다면 - 당신의 독점 자산이 강제로 공개될 위험에 처하기 때문입니다.

내 회사 독점 소스코드가 강제로 전체 공개될까 봐 걱정됨: 라이선스별 핵심 의무

많은 기업이 가장 두려워하는 것은 실수로 오픈소스를 가져다 썼다가 수십억 원의 가치를 지닌 자체 개발 소스 코드까지 무료로 공개해야 하는 상황입니다. 이 두려움을 해소하려면 오픈소스 소스코드 공개 범위와 라이선스를 세 가지로 분류해서 이해해야 합니다.

1. 강력한 상호호환성 라이선스 (Copyleft)

소스 코드 공개 의무가 가장 엄격한 라이선스입니다. 대표적으로 GPL(General Public License)과 AGPL이 있습니다. 이 라이선스가 적용된 코드를 조금이라도 수정하거나 결합하여 외부로 배포하면, 연동된 전체 프로그램의 소스 코드를 동일한 GPL 라이선스 공개 의무에 따라 무료 공개해야 합니다.

무섭게 들리나요? 맞습니다. 상용 소프트웨어를 개발하는 기업이라면 GPL 코드를 사용할 때 극도로 주의해야 합니다. 전체 코드가 전염되듯 강제 공개 대상이 될 수 있기 때문입니다. 단, 내부 서버에서만 돌리고 외부로 판매나 배포를 하지 않는다면 소스 공개 의무는 발생하지 않습니다. AGPL은 예외입니다. 네트워크를 통해 서비스(SaaS)를 제공하는 것만으로도 배포로 간주하여 소스 코드를 공개해야 합니다.

2. 약한 상호호환성 라이선스 (Weak Copyleft)

LGPL(Lesser GPL)이나 MPL(Mozilla Public License)이 여기에 속합니다. 오픈소스를 수정하여 배포할 때, 해당 오픈소스 자체의 수정본만 소스 코드를 공개하면 됩니다. 결합한 자체 개발 코드는 독점 권리를 유지할 수 있습니다.

어떻게 결합하느냐가 관건입니다. (이 부분은 아래 비교 표에서 자세히 다루겠습니다). 동적 링크(Dynamic Linking) 방식으로 결합했다면 당신의 독점 코드는 안전합니다. 이 방식은 기업 환경에서 오픈소스를 활용하면서도 지적 재산권을 보호하는 가장 현실적인 타협안으로 꼽힙니다. 실제 통계에서도 기업용 솔루션의 약 65%가 이 약한 카피레프트 방식의 라이브러리를 동적 링크 형태로 채택하고 있습니다.

3. 허용적 라이선스 (Permissive)

MIT, Apache 2.0, BSD 라이선스가 대표적입니다. 소스 코드 공개 의무가 전혀 없습니다. 가장 자유롭게 사용할 수 있으며 상용 제품 개발에 최적화되어 있습니다.

완전 무료일까요? 아닙니다. 코드를 공개할 필요는 없지만, MIT 라이센스 고지 의무처럼 해당 오픈소스를 사용했다는 저작권 공지(Copyright Notice) 및 라이선스 원문 문구는 반드시 프로그램 정보 창이나 설명서에 포함해야 합니다. 이것마저 누락하면 라이선스 위반으로 간주됩니다.

오픈소스 내부 사용과 외부 재배포의 기준

많은 개발자들이 헷갈려 하는 질문이 있습니다. 회사 내부 서버에서 분석용으로 쓰는 프로그램도 오픈소스 내부 사용 소스 공개를 해야 하나요? (13) 아닙니다. (1) 기업 내부에서만 사용하고 외부 유저에게 다운로드 형태로 제공하거나 임베디드 기기에 탑재해 판매하지 않는다면, 공개 의무는 발생하지 않습니다.

하지만 웹 서비스(SaaS)로 제공하는 경우는 어떨까요? 웹 브라우저를 통해 기능만 제공하고 클라이언트에게 실행 파일을 주지 않는다면, 일반적인 GPL 라이선스 하에서는 배포로 보지 않습니다. 하지만 앞서 언급한 AGPL 라이선스는 이를 배포로 간주합니다. 클라우드 시대에 접어들면서 AGPL로 라이선스를 전환하는 오픈소스(예: MongoDB 과거 버전 등)가 늘어나고 있으므로, 도입 전에 반드시 오픈소스 공개 의무 사항은 무엇인가요?라고 자문하고 확인해야 합니다.

오픈소스 결합 방식에 따른 소스 공개 의무 비교

정적 링크 (Static Linking)

• MIT, Apache 등 허용적 라이선스를 사용할 때만 권장

• 컴파일 시점에 오픈소스와 독점 코드가 하나의 단일 실행 파일로 합쳐짐

• 리버스 엔지니어링을 허용하거나 오브젝트 파일을 제공하여 사용자가 라이브러리를 교체할 수 있게 해야 함 (실질적으로 번거로움)

• 전체 프로그램(자체 개발 코드 포함) 소스 코드 공개 필수

동적 링크 (Dynamic Linking)

• 상용 프로그램에서 LGPL 라이브러리를 안전하게 활용하고자 할 때 가장 많이 쓰이는 방식

• 실행 시점에 외부의 독립된 라이브러리(DLL, SO 파일 등)를 호출하여 사용

• 자체 개발 코드는 공개할 필요 없음. 수정한 LGPL 라이브러리 코드만 공개하면 됨

• 원칙적으로 전체 프로그램 소스 코드 공개 필수 (단일 프로그램으로 간주)

⭐ 독립 프로세스 실행 (Independent Process)

• GPL 프로그램을 상용 서비스 아키텍처에 가장 안전하게 통합하는 마이크로서비스 방식

• 오픈소스 프로그램과 독점 코드가 별개의 프로세스로 실행되며 파이프나 소켓(API)으로 통신

• 자체 개발 코드 공개 의무 없음

• 단순한 데이터 통신(REST API 등)이라면 별개의 프로그램으로 인정받아 자체 코드는 공개 의무 없음

국내 B2B 솔루션 스타트업의 라이선스 위반 극복기

서울에 위치한 B2B 데이터 분석 스타트업에서 일하는 개발팀장 민수는 솔루션 출시를 한 달 앞두고 심각한 문제에 직면했습니다. 팀원이 핵심 데이터 파싱 모듈에 GPL 라이선스가 걸린 오픈소스를 정적 링크로 깊숙이 결합해 놓은 것을 뒤늦게 발견한 것입니다. 이대로 고객사에 배포하면 2년간 개발한 회사의 독점 AI 알고리즘 소스 코드를 전부 무료로 공개해야 할 판이었습니다.

첫 번째 시도: 민수는 3명의 팀원을 투입해 해당 GPL 모듈을 자체 코드로 처음부터 다시 짜려고 했습니다. 하지만 2주가 지나도록 성능이 나오지 않았고 기존 코드와의 의존성 문제로 시스템 전체가 계속 다운되었습니다. 런칭일은 다가오는데 버그는 늘어만 갔습니다. 팀 전체가 패닉에 빠졌습니다.

그러다 금요일 밤 아키텍처 다이어그램을 보던 중 해결책을 깨달았습니다. 해당 GPL 모듈을 굳이 핵심 시스템 안에 내장할 필요가 없었던 것입니다. 민수는 GPL 모듈을 완전히 별도의 독립된 마이크로서비스(Docker 컨테이너)로 분리하고, 회사의 독점 시스템과는 단순한 REST API 소켓 통신만 주고받도록 구조를 뜯어고쳤습니다.

결과적으로 아키텍처 재설계에 3주가 더 소요되었지만, 두 시스템이 '독립된 별개의 프로그램'으로 인정받아 회사의 독점 코드를 안전하게 지켜낼 수 있었습니다. 이후 이 스타트업은 모든 외부 라이브러리 도입 시 자동화된 라이선스 스캐너를 CI/CD 파이프라인에 의무적으로 연동하게 되었습니다.

본 아티클에서 제공하는 정보는 일반적인 오픈소스 라이선스 이해를 돕기 위한 교육용 콘텐츠이며, 특정 상황에 대한 공식적인 법률 자문이나 법적 효력을 갖지 않습니다. 실제 기업 환경에서 오픈소스를 제품에 결합하여 상용화하거나 법적 분쟁의 소지가 있는 경우, 반드시 전문 변호사나 오픈소스 컴플라이언스 전문가의 검토를 받으시길 바랍니다.