본 사건의 의뢰인은 보안 소프트웨어를 개발·공급하는 기업입니다.

의뢰인은 오픈소스 관리체계에 관한 국제 표준 인증(ISO/IEC 5230)을 업계 선도적으로 획득할 계획을 세우고 있었습니다.

그런데 의뢰인의 일부 제품에는 GPL 라이선스가 적용된 오픈소스가 사용되고 있었습니다.

인증 획득 사실을 대외적으로 홍보하면 오히려 경쟁사, 언론, 제3자로부터 소스코드 공개 요구가 촉발되는 것은 아닌지, 공개를 거부하면 어떤 법적 책임이 따르는지가 검토되지 않은 상태였습니다.

보안 기업에게 소스코드는 핵심 기술 그 자체이므로, 인증 추진에 앞서 리스크의 실체를 정확히 확인할 필요가 있었습니다.

 

 

본 변호사는 의뢰인과의 회의를 통해 사실관계부터 확정하였습니다.

GPL 오픈소스가 사용된 제품은 대부분 기업 고객 대상(B2B)이고 일반 소비자 대상 제품에는 사용되지 않았다는 점과, 관련 업계에 확인한 결과 지금까지 고객으로부터 소스코드 공개 요청을 받은 전례가 없다는 점을 확인한 뒤, 이를 전제로 쟁점을 나누어 검토하였습니다.

 

◆ 첫째, 인증과 공개의무의 관계를 정리하였습니다.

GPL 라이선스에 따른 소스코드 공개의무는 오픈소스를 사용하여 제품을 배포하는 행위 자체에서 발생하는 것이지 인증 취득으로 새로 생기는 것이 아닙니다.

본 변호사는 인증을 받든 받지 않든 공개의무의 존부는 달라지지 않으며, 다만 인증 획득과 홍보가 외부의 공개 요구를 촉발하는 계기가 될 가능성은 있다는 점을 구분하여 설명하였습니다.

 

 

◆ 둘째, 라이선스 유형별 공개의무의 범위를 분석하였습니다.

GPL은 오픈소스와 결합한 코드까지 동일한 라이선스로 공개해야 하는 반면, LGPL은 라이브러리를 링크 방식으로 결합한 경우 그 라이브러리 부분만 공개하면 되고, AGPL은 네트워크로 서비스를 제공하는 서버에까지 의무가 미치는 등 유형별로 범위가 다릅니다.

본 변호사는 이러한 차이를 정리하여 의뢰인이 제품별로 실제 부담하는 의무의 범위를 확인할 수 있도록 하였습니다.

 

 

◆ 셋째, 공개를 거부할 경우의 법적 리스크를 판례에 근거하여 검토하였습니다.

본 변호사는 국내 판결(서울중앙지방법원 2006. 11. 1. 선고 2005노3002 판결)을 분석하여, GPL 위반은 저작권 침해가 아니라 계약 위반으로 취급될 여지가 크고, 개발한 소스코드가 영업비밀에 해당함을 이유로 공개를 거부할 가능성이 있다는 점을 확인하였습니다.

다만 영업비밀 논리는 소스코드를 공개하기 전에만 쓸 수 있는 방어 수단이라는 한계, 공개를 거부하면 라이선스 위반을 이유로 한 사용금지 청구나 손해배상 청구의 위험이 남는다는 점, 해외에서는 GPL의 계약적 효력을 인정하여 일반 소비자의 공개 청구를 받아들인 사례까지 있다는 점을 함께 제시하여 리스크의 한계를 분명히 하였습니다.

 

 

의뢰인은 검토 의견을 통해 인증 획득이 곧 공개의무를 발생시키는 것은 아니라는 점, 공개 요구를 받더라도 시나리오별로 어떤 대응이 가능하고 어떤 위험이 남는지를 확인하였습니다.

그 결과 의뢰인은 리스크의 실체와 한계를 정확히 인지한 상태에서 인증 추진 여부를 결정할 수 있게 되었습니다.

 

 

오픈소스 자체가 리스크인 것이 아니라, 관리되지 않은 오픈소스가 리스크입니다.

같은 오픈소스라도 GPL, LGPL, AGPL 등 어떤 라이선스가 적용되는지, 코드가 어떤 방식으로 결합되는지에 따라 공개의무의 범위가 달라지므로, 제품별 사용 현황의 정리가 검토의 출발점이 됩니다.

특히 인증 취득이나 대외 홍보처럼 기업의 기술이 외부에 노출되는 계기를 앞두고 있다면, 그 전에 의무의 범위와 거부 시의 책임을 점검해 두어야 합니다.

공개 요구가 실제로 들어온 뒤에 검토를 시작하면 영업비밀 방어처럼 사전에만 유효한 선택지를 잃을 수 있습니다.

 

오픈소스를 사용한 제품의 출시, 인증, 홍보를 앞두고 계시다면, 라이선스 의무의 범위를 사전에 진단받으시기 바랍니다.