OSS (Open Source Software) Usage Considerations and Verification Method

1. OSS 라이선스

SW는 저작권자만이 해당 SW에 대한 사용 권리를 갖는 지적 재산권에 의해 보호받는데 이런 해당 SW의 독점 사용 권리에 대해 SW 개발자와 사용자 간의 이용 방법과 조건을 명시한 대여 규칙을 정해 놓은 허가권을 SW 라이선스라 한다. 이런 OSS 라이선스는 소스 코드의 공개 여부에 따라 강력한 상호 허가권(Strong Reciprocal License)을 갖는 것과 약한 상호 허가권(Weak Reciprocal License)을 갖는 것, 그리고 관대한 허가권(Permissive License)을 갖는 것으로 나눌 수 있다. 강력한 상호 허가권(Strong Reciprocal License)을 갖는 OSS 라이선스는 공개 SW의 일부 혹은 전체를 사용하여 SW를 개발한 경우 사용 혹은 수정한 공개 SW와 더불어 개발 SW 소스 코드 전체를 공개해야 하는 것으로 대표적으로 AGPL-3.0, GPL-2.0, GPL-3.0 등이 있다. 그리고 약한 상호 허가권(Weak Reciprocal License) 갖는 OSS 라이선스는 공개 SW의 일부 혹은 전체를 사용하여 SW를 개발한 경우 사용 혹은 수정한 공개 SW 소스 코드만을 공개하면 되는 것으로 대표적으로 MPL-2.0, LGPL-2.1 등이 있다. 마지막으로 관대한 허가권(Permissive License)을 갖는 OSS 라이선스는 공개 SW의 일부 혹은 전체를 사용하여 SW를 개발한 경우 사용 혹은 수정한 공개 SW 소스 코드와 개발 SW 소스 코드를 공개하지 않아도 되는 것으로 대표적으로 MIT, BSD 3-Clause, Apache-2.0 등이 있다.

<표 1>은 주요 OSS에 대한 라이선스 의무 사항을 비교 및 요약한 것이다[1]-[6]. 공개된 OSS는 누구든 자유롭게 사용, 수정, 복제가 가능하다. 다만, OSS 사용 하여 개발한 기술이나 제품을 만들어 제 3자에게 배포하거나 기술 이전하는 경우 OSS 활용한 개발 SW 소스코드 전체를 공개해야 하는 OSS 라이선스 의무사항이 있음을 주의해야 하며 이와 같은 라이선스를 갖는 대표적인 OSS가 GPL 계열과 AGPL 그리고 LGPL과 MPL 및 EPL 등이 있다. 그리고 OSS 를 사용하여 개발한 기술에 특허가 포함된 경우 개발에 사용한 OSS 라이선스 의무사항으로 개발 소스 코드 전체를 공개해야 한다면 개발 기술에 포함된 특허의 권리 주장이 쉽지 않다는 사실도 OSS 사용전에 미리 고려해야 하는 부분이다. 그 외 대부분의 OSS는 사용 후 OSS 수정 내용과 함께 저작권 관련 사항을 해당 OSS 라이선스에 포함하여 고지해야 하는 의무가 있다는 사실도 기억할 필요가 있다.

<표 1>

주요 OSS 라이선스 의무사항

2. OSS 활용 절차

OSS는 말 그대로 공개된 SW로 누구나 언제든지 사용할 수 있는 SW이다. 다만, OSS를 사용 혹은 수정하여 개발한 소스 코드 OSS를 사용 혹은 수정하여 기술이나 제품을 만들어 기술 이전 혹은 판매 등 제 3자에게 배포 및 사용하게 하는 경우 기술 개발에 사용한 OSS를 포함해 개발 기술 및 제품 전체 소스 코드는 기본적으로 해당 OSS 라이선스를 따르게 된다. 따라서 SW 개발 프로젝트 수행에서 OSS를 사용하여 기술이나 제품 개발을 고려하는 경우 먼저 개발하는 기술의 공개나 기술 이전 혹은 상품화 여부에 따라 어떤 OSS를 활용할 것인지를 해당 OSS 라이선스를 사전 검토하여 판단하는 것이 중요하다.

(그림 1)은 프로젝트 수행 시작 시점부터 프로젝트 완료 단계에 이르기까지 기술 개발 과정에서 OSS 활용 결정부터 활용 후 검증 및 분석, 그리고 라이선스 공지 단계까지의 절차와 연관 관계를 나타내고 있다. 중요한 것은 프로젝트 시작 시점에 기술 개발에 OSS 활용 여부를 결정하는 부분이고, OSS를 이용하여 기술 개발을 진행하는 것으로 결정한 경우 개발할 기술의 공개 혹은 제 3자 베포 여부 등 활용 목적에 따라 어떤 OSS를 사용하고 라이선스 따를 것인지 결정하는 부분이다. 또한, SW 개발 프로젝트 수행에서 OSS를 이용하여 기술 개발을 진행할 때 기술 개발 과정에서 개발자에 의해 사용한 OSS 라이선스의 확인 및 검증은 기본적으로 진행할 필요가 있으며, 기술 개발 완료 시점에서 사용한 OSS 라이선스에 대한 최종적인 확인 및 검증을 추가적으로 진행할 필요가 있다. 아울러 기술 개발 과정에서 진행한 OSS 라이선스 분석 및 검증 내용에 대해서는 개발 기술과 함께 별도 관리할 필요가 있으며, 마지막으로 기술 개발 과정에서 활용한 OSS 라이선스를 참조하여 OSS 수정 내용과 함께 저작권 관련 사항을 라이선스에 포함하여 고지하는 부분도 OSS 활용 단계에서 꼭 필요한 부분이다.

(그림 1)

OSS 활용 절차

3. OSS 활용시 고려사항

가. 개발소스 코드 공개 의무 여부

OSS는 기본적으로 누구나 자유롭게 사용·수정·배포가 가능하다. 이는 가능한 많은 사람이 OSS를 이용할 수 있도록 하는 것이고, OSS 이용 후에도 OSS 커뮤니티에 또 다른 기여가 계속 가능하도록 하는 목적일 것이다. 따라서 OSS를 이용해 SW를 개발하는 경우는 기본적으로 개발한 SW를 공개한다는 생각을 갖고 OSS를 이용하는 것이 무리가 없을 것이다. 그럼에도 OSS 이용자는 활용 목적에 따라 자신이 개발한 SW의 공개를 원치 않을 수 있기에 OSS 사용전 OSS라이선스 공개 의무 여부를 반드시 확인할 필요가 있다. 물론 OSS를 이용해 개발한 SW를 제 3자에게 배포하지 않고 자신의 연구 목적으로만 사용하는 경우는 개발 SW의 공개 의무 사항을 고려하지 않아도 된다. 따라서 OSS를 이용해 개발한 기술을 이전하거나 제 3자 배포시 개발 기술 전체 소스 코드 공개 의무사항이 포함된 GPL 2.0, GPL 3.0, LGPL 2.0, LGPL 3.0 AGPL 3.0 등과 같은 강한 OSS 라이선스와 MPL 1.0, EPL 1.0 등과 같이 OSS가 포함된 파일이나 모듈만 공개하는 약한 OSS 라이선스, 그리고 MIT 1.0, Apache 2.0, BSD 등과 같이 개발 SW를 전혀 공개하지 않아도 되는 OSS 라이선스가 있음을 사전에 파악하여 기술 개발 과정에서 어떤 OSS를 사용할 것인지 고려할 필요가 있다.

나. OSS에 포함된 특허권 유효 여부

특허가 포함된 OSS를 사용하는 경우 해당 OSS와 포함된 특허를 일반적으로 무상 사용할 수 있다고 GPL3.0, LGPL 3.0, AGPL 3.0, Apache 2.0, 그리고 MPL 2.0 및 EPL과 같은 주요 OSS라이선스는 명시하고 있다. 다만, 제 3자의 특허가 해당 OSS에 포함된 경우 특허권을 주장할 수 있기에 OSS 사용 전 해당 OSS에서의 제 3자 특허 포함 여부와 특허권 유무상 여부의 확인이 필요하다. 그 외 OSS를 이용해 개발한 SW의 제 3자 배포 시 개발 소스 코드 공개 의무사항이 전혀 없는 라이선스 경우 개발 기술에 특허를 포함시켜 특허 유효 항목을 추가해 특허권을 주장할 수도 있으니 이 또한 해당 OSS를 사용하기에 앞서 반드시 라이선스 내용에 대한 확인이 필요하다.

다. 개발 SW 소스 코드에 특허 포함 여부

OSS를 사용한 개발 기술 소스 코드에 특허가 포함될 경우 GPL 3.0, LGPL 3.0, AGPL 3.0, MPL 계열, EPL 계열, 그리고 Apache 2.0등에서는 특허권을 주장할 수 없기에 가능한 특허 등 지적 재산권 내용을 포함하지 않도록 주의해야 한다. 만약 GPL 계열 OSS를 이용해 SW를 개발하고 개발한 SW 소스 코드에 특허를 포함해 공개하여 제 3자가 해당 SW를 사용할 때 이에 대한 특허권을 주장하거나 특허 소송을 제기하면 오히려 GPL OSS 라이선스는 종료되며 그 외 특허 소송 등에 따른 비용도 청구될 수 있음을 고려해야 한다. 따라서 OSS를 이용해 SW를 개발하는 경우 개발 SW 소스 코드 내용에 가능한 특허 등 지적 재산권이 포함되지 않도록 하는 것이 좋다.

라. 2개 이상의 서로 다른 OSS 사용가능 여부

GPL 2.0 및 Apache 2.0과 같이 2개 이상의 서로 다른 OSS를 사용하여 SW를 개발하는 경우 각 라이선스 간의 의무사항 충돌로 양립할 수 없는 경우가 발생할 수 있으니 OSS를 이용한 SW 개발에서 2개 이상의 서로 다른 OSS 사용은 가능한 피하는 것이 좋다. 따라서 2개 이상의 OSS를 이용하여 SW를 개발하는 경우 사용한 두 개 이상의 OSS 라이선스 의무사항 준수에 따른 상호 충돌 등 OSS 라이선스 양립성 문제가 발생하지 않도록 해당 OSS 라이선스 의무사항을 사전에 반드시 확인할 필요가 있다.

마. OSS 라이선스 정보 사전확인 여부

OSS를 사용하여 SW를 개발하는 경우 사용에 앞서 해당 라이선스 정보의 확인이 필요하다. OSS 라이선스 정보 확인은 보통 공개 SW 프로젝트 사이트나 소스코드가 배포되는 사이트에서 확인 가능하다. 그리고 다운 받아 사용하는 OSS의 경우, 다운 시 포함된 파일 중 LICEENSE, README, COPYING, LEGAL, 그리고 NOTICE 등의 파일 내용을 통해 해당 OSS의 라이선스 정보 확인이 가능하다. 그 외에 다운 받은 OSS 소스코드의 헤더 주석문에 고지된 라이선스 문구로 확인할 수 있으며 일부 공개 SW의 경우 라이선스 확인이 어려운 경우가 있으나 이 경우는 웹 사이트(구글, github, sourceforge 등)에서 코드 검색을 통해 추가로 확인할 수 있다.

바. OSS 라이선스 고지방법 확인 여부

OSS 라이선스 항목에 소스코드 반환 의무가 있을 경우는 소스코드의 제 3자 배포 시 OSS 수정 내용과 저작권 정보 그리고 해당 라이선스 사본을 함께 고지 및 제공해야 한다. 또한, OSS를 이용해 SW를 개발하는 개발자는 개발 SW의 제 3자 배포 시 사용한 OSS 라이선스정보를 삭제하지 않도록 주의해야 한다. OSS를 이용한 개발 소스코드의 공개에 따른 라이선스 고지 및 제공 방법은 해당 소스코드나 제품에 포함하여 배포 및 고지하는 방법, 웹 사이트에 소스코드를 업로드 해놓고 사용 OSS의 입수 경로와 수정 내용, 저작권 정보와 라이선스 사본 등에 대한 고지문을 제공하는 방법, 그 외 소스코드 요청 시 전자우편이나 CD 등을 이용하여 보내는 방법 등이 있다. OSS 라이선스 사본은 SPDX(Software Package Data Exchange)를 통해 표준화된 라이선스 정보 형식을 구할 수 있고, 그 외 한국저작권위원회의 OLIS(Open source SW License Information System)을 통해 국문 형태의 라이선스 정보를 도움 받을 수 있다.

사. OSS 보안 취약점 및 품질 수준검토 여부

현재 수많은 OSS가 공개되고 있으며 기술 및 제품 개발이나 SW 개발 프로젝트 수행에서 누구나 공개된 OSS 활용이 가능하다. 그러나 공개된 OSS 사용에 따른 품질 및 보안 취약점, 그리고 기타 어떤 문제 발생에 대해서도 OSS 공개자에게는 책임 의무가 없는 것이 현실이다. 따라서 OSS를 이용해 SW를 개발하는 경우 해당 OSS의 라이선스에 대한 확인도 필요하지만, 해당 OSS의 보안 취약점 및 품질 수준에 대한 사전 점검도 고려해야 하며 이와 같은 사전 점검이 전체 기술 개발 기간이나 프로젝트 수행 기간, 그리고 OSS 활용에 따른 비용 측면에서 유리하다. OSS의 보안 취약점 및 품질 수준 점검은 CC 인증 받은 상용 정적분석 툴 이용하여 확인할 수 있으며 굳이 상용 점검 툴을 이용하지 않는 경우는 일부 보안 취약점과 품질을 점검할 수 있는 수준으로 컴파일러에서 기본적으로 제공하는 기능을 통해 확인할 수 있고, 그 외 무료로 활용할 수 있는 CppCheck, PMD, SonarQube 등과 같은 오픈소스 기반 점검 툴을 개발 환경에 설치하여 활용하는 방법도 고려할 수 있다.

1. OSS 라이선스 검증 방법

OSS는 저작권이 있으며 OSS 사용과 배포 등에 따라 다양한 라이선스 의무사항을 포함하고 있다. 따라서 OSS 사용에 따른 라이선스 인식 부족과 의무사항 미유지로 인해 원치 않는 법적 분쟁 발생이나 조직 이미지 손실 및 개발 지연 등의 문제가 야기될 수 있다. 그러므로 이런 문제를 사전에 예방할 수 있도록 OSS 사용에 따른 라이선스 검증은 반드시 필요하다. OSS 라이선스 검증은 크게 사람에 의한 검증, 기계에 의한 검증, 그리고 사람과 기계에 의한 병행 검증을 고려할 수 있다.

가. 사람(개발자/사용자)에 의한 검증

OSS를 이용해 기술과 제품을 개발하는 경우 먼저 사용하려는 해당 OSS 라이선스 의무사항을 확인해야 한다. 라이선스 의무사항 확인을 통해 개발자는 OSS 사용 여부를 최종 결정하고 해당 OSS를 사용하면 된다. 이때 해당 OSS 라이선스 내용에 대한 해석을 개발자 혼자 판단하기 어려운 경우는 법무팀 협조를 받아 진행할 수 있다. 인터넷(구글 등) 소스코드 검색을 통해 찾은 OSS의 경우 개발자 및 사용자는 OSS 사용에 앞서 해당 OSS 소스코드에 대한 추가적인 추적을 통해 OSS에 대한 최초 라이선스 확인이 필요하며 또한 OSS 사이트를 통해 확보한 OSS를 사용할 때 개발자는 해당 OSS 라이선스를 사전에 확인하고 그 내용을 숙지하고 있어야 한다. 이런 방법을 사람에 의해 수동[7]으로 수행하는 OSS 라이선스 검증 방식이라 할 수 있다. 이렇게 인터넷 검색 혹은 OSS 사이트를 통해 확보한 OSS와 사전 확인 및 검증한 해당 OSS 라이선스 경우는 이후 SW 개발 프로젝트 수행에서 OSS를 이용한 기술 및 제품 개발 진행에 따른 추가적인 라이선스 검증을 진행하지 않을 수 있다. 따라서 OSS 사용에 앞서 개발자가 해당 OSS 라이선스의 사전 확인을 한 경우가 OSS 라이선스 검증을 위한 방법중 한 경우라 할 수 있다.

나. 툴을 이용한 검증

툴을 이용한 OSS 라이선스 검증이란 개발자 및 사용자가 OSS를 이용하여 SW 개발할 때, 사용한 OSS 소스코드에 대한 라이선스 검증을 자동화 툴을 이용하여 수행하는 방법을 의미한다. 툴을 이용한 OSS 라이선스 검증은 해당 OSS 소스코드를 스캔 한 후 툴의 DB에 저장된 소스코드와 비교하여 검증하는 방식, 해당 OSS 소스코드 내 주석문 및 문자열 검색을 통해 비교 및 검증하는 방식, 그리고 해당 OSS 소스 코드에 대한 파일 사이즈를 비교하여 Checksum 방식으로 검증하는 방식 등이 있다.

• 문자열 검색 및 비교를 통한 검증: 해당 소스코드 내 주석문 및 문자열 검색을 통해 비교 및 검증하는 방식을 의미하는 것으로 대표적인 문자열 비교 OSS 라이선스 검증 툴은 GPL 2.0 오픈소스 기반 FOSSology가 있으며 그 외 AGPL 3.0 오픈소스 기반 Ninka와 TripleCheck가 있다.

• CheckSum 방식을 이용한 검증: OSS를 이용해 개발한 소스코드 파일 크기를 CheckSum 방식으로 비교해서 라이선스를 검증하는 방식을 의미한다. 아웃소싱을 통해 들어오는 개발 코드에서 사용한 OSS 소스코드에 대한 검증과 공급망 관리 차원에서 이를 적용하는 예도 있다.

• 코드 스캔을 이용한 검증: OSS 라이선스의 보편적인 기계적 검증으로 가장 많이 사용되고 있다. OSS를 이용해 개발한 SW 소스코드를 스캔하여 검증 툴의 DB로 갖고 있는 OSS 소스코드와 비교해서 일치하거나 유사한 패턴의 코드 존재 여부를 확인해서 검증하는 방식이다. 대표적인 상용 툴로 Black Duck(현재는 Synopsys)의 Protex가 있으며 그 외 FlexNet Code Insight 사의 Palamida가 있고, 기타 한국 저작권 위원회에서 개발한 오픈소스 기반 Code eye가 있다.

다. 툴과 사람에 의한 검증

OSS를 이용해 개발한 소스코드 크기가 크고 OSS 라이선스 검증을 위한 시간적 여유가 없는 경우 툴을 이용해 OSS 라이선스 검증하는 것이 쉽고 빠를 수 있으나, 툴에서는 기본적으로 OSS 소스코드와의 유사 및 일치 패턴 만을 찾아 줄 뿐이다. 이 경우 툴에서 찾아낸 유사 및 일치 패턴의 OSS 소스코드는 한 개 이상 검출될 수 있다. 이렇게 여러 개의 유사 및 일치 패턴 소스코드를 찾아 낸 경우 SW 개발에서 실제 사용한 OSS 라이선스는 어떤 것인지 판단하기가 쉽지 않다. 더구나 오픈소스 특성상 시간이 지나면서 여러 개발자에 의해 수정 및 배포가 반복되면서 다수의 새로운 오픈 소스로 재 배포될 수 있는데 이런 경우 툴에서 찾아낸 여러 개의 OSS에서 실제 개발에서 사용한 OSS 라이선스를 찾아 결정하는 것이 쉽지 않다. 따라서 이런 경우 1차 툴에서 찾아낸 여러 개의 OSS 라이선스 중 SW 개발에서 실제 사용한 OSS가 어떤 것인지 최종 결정은 사람(개발자/사용자)이 해야 한다. 이렇게 1차 툴에서 유사 및 일치한 OSS 소스코드를 찾아내고 찾아낸 여러 개의 OSS에서 실제 개발에서 사용한 OSS에 대해 사람이 최종 결정하는 OSS 라이선스 검증 방식을 툴과 사람에 의한 검증이라 할 수 있다. 개발자는 검증 툴을 통해 찾아낸 소스 코드 패턴이 일치한 여러 개의 OSS 라이선스 중 실제 개발에서 사용한 OSS 라이선스가 어떤 것인지를 최종 결정하는 데는 소스코드 내 주석이나 라이선스 정보, 기타 소스코드에 대한 인터넷 검색을 통해 추가적인 정보 확인을 통해 진행할 수 있다. 그러나 오픈소스 라이선스에 대한 이해가 익숙하지 않는 개발자나 사용자 혹은 해당 SW를 직접 개발하지 않은 사람이면 개발 SW에서 사용한 OSS 라이선스에 대한 최종 판단을 하기가 쉽지 않을 수 있다. 따라서 이 경우는 OSS 검증 툴 사용에 익숙한 사람이나 라이선스 이해를 도울 수 있는 전문가를 통해 추가적인 지원을 받아 개발 SW에서 사용한 OSS 라이선스가 어떤 것인지를 최종 결정하도록 하는 것이 바람직하다. 즉, OSS를 이용해 SW 개발할 때 사용 한 OSS에 대한 라이선스를 툴과 사람에 의해 병행할 경우 1차 OSS 분석 툴을 이용하여 라이선스 검증을 진행한 후 SW를 실제 개발한 개발자나 사용자가 툴 및 라이선스 해석 전문가의 도움을 받아 최종적으로 결정하는 것이 정확한 검증 결과를 가져올 수 있다.

2. OSS 라이선스 검증 절차

프로젝트 수행 시작 단계에서 OSS를 이용하여 기술이나 제품 개발을 결정한 경우 먼저 기술이나 제품 개발 과정에서 사용할 OSS를 찾고, 이 OSS의 라이선스를 사용 전 반드시 확인할 필요가 있다. 또한, 기술이나 제품 개발 과정에서 사용한 OSS의 라이선스를 사전에 확인하지 못하고 OSS를 이용하여 기술 개발을 진행한 경우 OSS 라이선스 분석 툴을 이용하여 (그림 2)와 같은 절차를 통해 개발 소스 코드에 대한 라이선스 검증을 진행할 필요가 있다. (그림 2)는 OSS를 이용해 개발한 소스 코드에 대해 자동화 툴을 이용하여 OSS 라이선스를 분석 및 검증하는 과정으로, 먼저 개발한 소스 코드를 자동화 툴에 업로드 하고 스캔 한 후 자동화 툴 DB 내 구축된 OSS 코드와 비교하여 일치하는 OSS 코드를 찾아 낸 다음 OSS 소스 코드 확인을 통해 해당 OSS 라이선스를 찾아 낸다. 이 과정에서 두 개 이상의 OSS가 SW 개발에 실제 사용한 OSS와 일치하는 경우 툴의 DB에서 찾아낸 OSS 소스 코드분석을 통해 실제 SW 개발에 사용한 OSS 라이선스를 찾아내야 한다. 또한 툴을 통해 찾아낸 OSS 라이선스가 개발 기술 이전이나 외부 배포에 따른 개발 소스코드 공개 의무 상황이 발생한 경우는 개발 소스 코드 공개 의무가 없는 다른 OSS로 대체하거나 해당 OSS부분에 대한 추가적인 개발을 통해 발생한 OSS 라이선스 충돌 및 이슈를 해결해야 한다. 아울러 발생한 OSS 라이선스 이슈에 대한 법률적 해석이나 자문이 필요한 경우 별도의 법률 전문가의 도움을 통해 개발 기술에서 사용한 OSS 라이선스 문제 및 이슈를 명백히 정리하고 종결할 필요가 있다.

(그림 2)

OSS 라이선스 검증 절차

3. OSS 라이선스 검증 환경

(그림 3)은 앞서 기술한 OSS 라이선스 검증 방법과 절차를 지원할 수 있는 룰기반 OSS 검증 환경 예이다. OSS 거버넌스를 수행하는 대부분의 조직에서는 OSS 라이선스 검증을 위해 기본적으로 (그림 3)과 같은 검증 환경 구축 방향으로 진행한다[8].

(그림 3)

OSS 라이선스 검증 환경

OSS 라이선스 검증 환경 구축을 위해서는 검증 서비스를 진행할 인력과 조직 그리고 OSS 검증 툴로 구성된다. 그 외 OSS 검증 환경 구축에는 OSS 검증 결과를 공유하고 다른 기술 개발에서 재활용할 수 있는 라이브러리 환경 구축도 고려할 수 있다. 따라서 OSS 거버넌스 환경을 갖는 조직에서는 대부분 비슷한 OSS 라이선스 검증 환경을 구축하여 운영하고, 그 외 자체적으로 OSS 라이선스 검증 환경을 구축하는 대신 OSS 검증 환경을 구축.운영하는 외부 기관을 통해 OSS를 이용해 개발한 소스 코드에 대한 OSS 라이선스 검증 서비스를 지원 받을 수 있다.

4. OSS 라이선스 분석 및 검증 툴[3]-[5]

OSS를 사용할 때는 반드시 사용할 OSS 라이선스를 사전에 확인할 필요가 있다. SW 개발에 사용한 OSS가 외부 배포에 따라 공개 의무가 있는 라이선스 경우 OSS 사용하여 만든 기술이나 제품 그리고 서비스 연관된 관련 SW 소스코드를 모두 공개해야 하기 때문이다. 또한, 제품이나 기술 개발 일정이 촉박하여 OSS 라이선스 사전 확인 없이 OSS를 사용하는 경우는 개발한 기술이나 제품을 배포하기에 앞서 기술 개발에 사용한 OSS에 대한 라이선스 검증 과정이 필요하다. OSS 라이선스 검증은 개발 SW 소스코드의 크기에 따라 개발자 스스로 확인하는 방법과 OSS 라이선스 검증 툴을 이용하여 분석 및 검증하는 방법 등이 있다. <표 2>는 OSS 라이선스 검증을 위해 현재 사용 가능한 상용 OSS 라이선스 분석 툴이다.

<표 2>

OSS 분석 및 검증 도구 I (상용)

국내에서는 OSS 라이선스 자동 분석 및 검증 툴로 Protex를 가장 많이 사용하는 편이다. ETRI를 포함해 NIPA, LG, KT, 그리고 CJ 등에서 OSS 라이선스 분석 및 검증 툴로 사용하고 있는 Protex는 Black Duck 회사에서 개발해 판매 및 서비스해 오다가 현재는 Synopsys 사에서 인수하여 판매 및 서비스를 하고 있으며 국내의 경우만 Black Duck Software Korea가 별도 기술 지원을 하는 형태이다. 또한, 대부분의 OSS 라이선스 분석 및 검증 툴을 소스 코드를 스캔하여 툴 DB로 갖고 있는 OSS 소스 코드와 비교하여 라이선스를 분석 및 검증하는 방식을 가지며 바이너리 및 실행 파일을 비교 및 분석하는 툴도 일부 있다. 그 외 한국저작권위원회에서는 오픈소스 기반 OSS 라이선스 분석 및 검증 툴인 Code Eye를 개발하여, OSS 검증 및 컨설팅 서비스를 무료로 지원하고 있으며 NIPA 역시 공개 SW 역량 플라자 사업을 통해 OSS 라이선스 분석 및 검증 환경을 구축 및 운영해 오고 있으며 기업이나 기관에 OSS 라이선스 검증 및 컨설팅 서비스를 무료로 지원하고 있다.

<표 3>은 OSS 라이선스 분석 및 검증을 위해 사용 가능한 오픈소스 기반 OSS 라이선스 툴이다. 오픈소스 기반 OSS 라이선스 분석 및 검증 툴은 FOSSology가 대표적이며 검증 방식은 소스코드 내 라이선스 주석이나 문자열을 검색 및 비교를 통해 분석하는 툴이다.

<표 3>

OSS 분석 및 검증 도구 II (오픈소스)