1.5.2.2.2 GPL, MIT, Apache 등 오픈소스 라이선스 정책 검토 및 소스코드 공개 의무 방어

1.5.2.2.2 GPL, MIT, Apache 등 오픈소스 라이선스 정책 검토 및 소스코드 공개 의무 방어

오픈소스는 무료로 사용 가능한 코드의 집합이지만, 결코 ‘저작권이 없는(Copyright-free)’ 공공재가 아니다. 원저작자는 소스코드를 개방하는 대신 사용자가 지켜야 할 명확한 법적 조건인 사용 권한(License)을 부여하며, 기업이 이를 위반할 경우 막대한 손해 배상 소송은 물론 뼈아프게 개발한 자사 고유의 핵심 알고리즘(Proprietary Code)을 강제로 대중에 공개해야 하는 치명적 리스크를 감수해야 한다.

최고기술책임자(CTO)는 오픈소스 라이선스의 파괴력을 경영학적 리스크 수준에서 이해하고, 엔지니어들이 무심코 끌어다 쓰는 코드 한 줄이 지식재산권(IP)을 훼손되지 않도록 철저한 방어선(Compliance)을 구축해야 한다.

1. 전염성과 소스코드 공개 의무: 카피레프트(Copyleft) 계열

카피레프트 계열 라이선스는 “자유 소프트웨어는 영원히 자유로워야 한다“는 철학을 철저히 관철한다. 이 라이선스의 가장 무서운 점은 강력한 ’전염성(Viral Effect)’이다. 이 코드를 조금이라도 차용하거나 연결(Link)하여 새로운 제품을 만들면, 그 파생 저작물 전체가 동일한 라이선스에 감염되어 소스코드 전체를 일반에 무상 공개(Public Disclosure)해야 하는 강력한 의무가 발생한다.

1.1 GPL (GNU General Public License)

오픈소스 진영을 대표하는 가장 유명한 라이선스이지만, 영리 목적의 상용 소프트웨어를 개발하는 기업에게는 독약과 같다. 개발팀이 무심코 인터넷에서 복사해 온 정규식 파싱(Parsing) 코드가 GPL 라이선스라면, 이를 포함하여 컴파일(Compile)되거나 정적/동적 링크(Static/Dynamic Link)로 결합되어 배포된 우리 회사의 서버 엔진 전체 코드를 무상으로 공개해야 한다. CTO는 사내 규정을 통해 순수 내장형(Embedded) 라이브러리로 GPL 계열의 반입을 원천 금지(Blacklist)해야 한다.

1.2 AGPL (Affero General Public License)

현대 클라우드 기업에게 존재할 수 있는 가장 끔찍한 위협이다. GPL은 소프트웨어를 물리적으로 ’배포(Distribution)’할 때만 소스코드 공개 의무가 발생한다는 허점을 지닌다. 즉, 서버에만 설치해두고 웹 서비스(SaaS) 형태로 제공하면 코드를 공개하지 않아도 되었다. AGPL은 이 허점을 차단하여, 네트워크를 통해 서비스만 하더라도 소스코드를 전면 공개하도록 강제하는 극악의 전염성을 지닌다. SaaS 중심의 딥테크 기업에게 AGPL 코어의 사내 유입은 절대적인 금기 사항이다.

1.3 LGPL (Lesser General Public License)

GPL의 파괴력을 일부 완화한 타협안이다. 소스코드를 직접 수정해서 제품에 통합하는 경우는 GPL과 동일하게 전염되지만, .dll이나 .so 형태의 동적 링크(Dynamic Link) 라이브러리로 단순히 호출하여 사용하는 모듈에 대해서는 자사 소스코드 공개 의무를 면제해 준다. 다만 링크 방식에 대한 법률적 해석 요건이 까다로워 주의가 필요하다.

2. 상업적 이용에 안전한 기업 친화적 라이선스: 퍼미시브(Permissive) 계열

상용화 기술 아키텍처는 가급적 어떠한 코드 공개 의무도 갖지 않는 퍼미시브 라이선스 생태계 내에서 구축되는 것이 가장 안전하다.

2.1 MIT 및 BSD 라이선스

지구상에서 가장 관대하고 많이 쓰이는 라이선스들이다. 우리 제품 내 파일 상단이나 ‘도움말’ 항목에 “이러한 원작자의 코드를 사용했다“는 저작권 및 라이선스 고지문(Copyright Notice)만 포함시키면 끝이다. 소스코드를 마음대로 입맛에 맞게 수정해도 되며, 이를 폐쇄형 영리 소프트웨어(Closed-source)로 묶어 판매해도 전혀 소스코드 공개 의무가 발생하지 않는 완벽한 화이트리스트(Whitelist) 스택이다.

2.2 Apache 2.0 라이선스

MIT 라이선스처럼 자율적인 상업적 이용과 소스코드 비공개를 보장하는 훌륭한 라이선스이다. 이에 더해 “이 코드로 인해 파생된 특허 분쟁이 발생 시 책임을 묻지 않는다(Patent Grant)“는 명시적인 특허 보호 조항이 강력하게 포함되어 있어, 엔터프라이즈 환경에서 도입을 가장 선호하는 최고의 스택이다.

3. CTO를 위한 전사적 라이선스 방어 체계 (Defense in Depth)

엔지니어 한 명의 일탈적 설치 명령어(npm install)만으로 라이선스 전염이 발생할 수 있으므로, 방어는 사람의 수기 확인이 아닌 시스템적 강제로 이루어져야 한다.

  1. 소프트웨어 구성 분석(SCA) 도입 의무화: Black Duck, FOSSA 등 라이선스 자동 스캐닝 솔루션을 소스코드 저장소 파이프라인(CI/CD)에 결합해야 한다.
  2. 사전 차단(Gatekeeping): 개발 파이프라인 빌드 타임에 패키지 의존성(Dependencies) 트리를 스캔하여 GPL, AGPL과 같은 블랙리스트 라이선스가 1개라도 검출되면, 배포를 즉시 중단(Fail)시키고 해당 부서에 경보를 울리도록 데브옵스(DevOps) 환경을 조성해야 한다.

4. 결론

제품 상용화의 막바지, 투자사(VC)의 실사(Due Diligence) 과정에서 라이선스 검토가 실패하여 투자가 철회되는 사례는 비일비재하다. 오픈소스는 만능열쇠가 아니라, 정해진 사용 설명서(License)를 지킬 때만 효력을 발휘하는 계약서 기반의 지식재산이다. CTO는 개발 속도를 이유로 법무적 기초 검토를 후순위로 미루는 우를 범하지 말아야 하며, 퍼미시브 라이선스 중심의 안전한 서플라이 체인을 확립해야 한다.

참고 문헌 및 추천 논문:

  • Meeker, H. J. (2017). Open Source for Business: A Practical Guide to Open Source Software Licensing. Self-Published.
  • Engelfriet, A. (2010). “Choosing an Open Source License”. IEEE Software.
  • Rosen, L. (2004). Open Source Licensing: Software Freedom and Intellectual Property Law. Prentice Hall.