63. 소프트웨어 라이선스 컴플라이언스 및 오픈소스 감리

⚠️ 이 문서는 공공 및 민간의 정보시스템 구축 사업에서 외부의 상용 소프트웨어나 오픈소스(Open Source)를 가져다 썼을 때, 그 저작권과 라이선스 규정(GPL, MIT, Apache 등)을 합법적으로 준수하고 명시했는지를 점검하여 치명적인 법적 소송과 소스코드 강제 공개의 위험을 차단하는 감리 활동을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: "공짜로 다운로드받은 코드라고 해서 내 마음대로 써도 되는 것은 아니다." 상용 SW의 불법 복제 점검은 물론, 수백 개의 오픈소스 라이브러리마다 각기 다르게 매겨진 법적 의무(고지 의무, 소스 공개 의무)를 지켰는지 샅샅이 뒤져내는(Audit) 과정이다.
  2. 가치: 나중에 원저작자나 국제 단체(SFC 등)로부터 수십억 원의 지식재산권 침해 소송을 당하거나, 회사 고유의 영업 비밀이 담긴 소스코드를 인터넷에 강제로 공개해야 하는 대재앙(Copyleft 효과)을 예방한다.
  3. 기술 체계: 감리인은 자동화된 라이선스 점검 도구(FOSSID, Black Duck 등)를 사용하여 코드베이스에 섞인 오픈소스를 식별하고, 가장 위험한 전염성 라이선스(GPL 계열)가 상용 코드와 섞이지 않게 격리(Dynamic Linking 등)되었는지 점검한다.

Ⅰ. 상용 SW 불법 사용과 오픈소스의 함정

개발자는 편의를 위해 가져다 쓰지만, 회사는 법적 책임을 진다.

  1. 상용 SW의 라이선스 위반:
    • 오라클(Oracle DB)이나 상용 차트 컴포넌트를 프로젝트에 쓰면서 정품 라이선스를 구매하지 않거나, 'CPU 2Core용' 라이선스를 샀는데 클라우드에서 오토스케일링으로 '8Core'까지 서버를 확장해 버려 라이선스를 초과 위반하는 경우가 흔히 발생한다.
  2. 오픈소스(OSS)의 조건부 무료 원칙:
    • 오픈소스는 누구나 쓸 수 있지만 '저작권자의 룰'을 지킬 때만 무료다.
    • 대표적인 룰: "이 코드를 가져다 썼다는 사실을 앱 화면 한구석에 반드시 적어라(고지 의무)", "이 코드를 수정해서 팔 거면, 네가 만든 앱 전체의 소스코드도 세상에 공짜로 공개해라(소스 공개 의무)."

📢 섹션 요약 비유: 도서관의 책을 공짜로 빌려볼 수는 있지만, 그 책의 내용을 베껴서 논문을 쓸 때는 반드시 출처를 밝혀야(고지 의무) 하며, 어떤 위험한 책은 "이 책을 한 줄이라도 인용했다면 네 논문 전체를 도서관에 영구 기증하라(소스 공개 의무)"는 무서운 조건이 걸려있는 것과 같습니다.

Ⅱ. 오픈소스 라이선스의 3대 계열과 전염성(Copyleft)

모든 라이선스가 똑같이 위험한 것은 아니다. 독성의 강도가 다르다.

  1. 퍼미시브 (Permissive) 계열 - MIT, Apache, BSD:
    • 독성 매우 약함: 마음대로 쓰고, 수정해서 상업적으로 팔아도 된다. 내가 짠 소스코드를 공개할 필요도 없다.
    • 의무: 다만 앱의 '설정 -> 오픈소스 라이선스' 화면 등에 "나는 MIT 라이선스 기반의 XXX 라이브러리를 사용했습니다"라고 출처(저작권 알림)만 고지하면 된다.
  2. 약한 카피레프트 (Weak Copyleft) 계열 - LGPL, MPL:
    • 독성 중간: 이 라이브러리의 코드를 '직접 수정'했다면 그 수정한 부분의 코드는 세상에 공개해야 한다.
    • 하지만 내 상용 앱과 이 라이브러리를 하나로 섞지 않고, 단순히 파일(DLL, SO 등) 형태로 따로 떨어뜨려 '동적 링크(Dynamic Linking)'로 호출만 해서 썼다면 내 상용 코드는 공개하지 않아도 된다.
  3. 강한 카피레프트 (Strong Copyleft) 계열 - GPL (GNU General Public License):
    • 독성 매우 강함 (바이러스성): GPL 코드를 한 줄이라도 내 프로그램에 섞어 쓰면(정적 링크), 내 프로그램 전체가 GPL로 강제 전염된다. 즉, 회사의 피땀 어린 상용 소스코드를 100% 인터넷에 무료로 공개해야 한다.

📢 섹션 요약 비유: MIT 라이선스는 밀가루 포장지에 "우리 집 밀가루 썼다고 간판에만 적어주세요"라는 착한 재료라면, GPL 라이선스는 "우리 집 비법 소스를 한 방울이라도 당신 국밥에 섞었다면, 당신 식당의 국밥 끓이는 모든 레시피를 동네 사람들에게 공짜로 다 알려줘야 합니다"라는 무서운 마법의 소스입니다.

Ⅲ. 감리 시 오픈소스 컴플라이언스 점검 절차

감리인은 숨겨진 1%의 GPL 코드를 찾아내야 한다.

  1. 식별 (Identification):
    • 개발사가 제출한 '오픈소스 사용 명세서(BOM, Bill of Materials)'를 받는다.
    • 소스코드 스캐너 툴을 돌려서, 명세서에 안 적혀있는데 개발자가 Stack Overflow나 GitHub에서 몰래 긁어다 붙인 코드가 없는지 대조한다.
  2. 충돌 및 전염성 검증 (Compliance Check):
    • 강한 전염성을 가진 GPLv2나 GPLv3 코드가 상업용 모듈과 섞여 있는지(정적 링킹) 찾아낸다. 섞여 있다면 즉시 해당 모듈을 덜어내고 퍼미시브(MIT 등) 계열의 대체 라이브러리로 다시 개발하도록 시정 요구를 내린다.
  3. 고지문 (Notice) 배포 확인:
    • 앱이 완성되어 출시될 때, "오픈소스 고지문(Open Source Notice)" 파일이 앱 내에 적절히 삽입되어 사용자가 읽을 수 있도록 UI/UX가 구현되었는지 마지막으로 점검한다.

📢 섹션 요약 비유: 식품 위생 감사관(감리인)이 공장에 들어가, 공장장이 제출한 재료 목록(BOM) 외에 몰래 넣은 불법 화학첨가물(무단 OSS)이 없는지 성분 분석기(스캐너)로 찔러보고, 제품 포장지 뒷면에 알레르기 유발 물질 표기(고지문)가 법대로 잘 적혀있는지 단속하는 과정입니다.