웹사이트나 앱을 만들 때 오픈소스는 유용한 출발점입니다. 다만 소스가 공개돼 있거나 무료로 내려받을 수 있다는 이유만으로 아무 조건도 없다고 볼 수는 없습니다. 실제로 지켜야 할 조건은 각 라이선스와 사용 방식에 따라 달라집니다. 개발이 끝난 뒤 한꺼번에 확인하기보다 도입할 때부터 이름과 버전을 기록해두는 편이 효율적입니다.
라이선스 이름만 적지 말고 버전도 남기기
프로젝트의 공식 저장소나 배포본에서 라이선스 파일과 저작권 고지를 확인하세요. 같은 이름의 소프트웨어라도 버전이나 구성 요소별 조건이 다를 수 있습니다. ‘MIT 계열’, ‘GPL 계열’ 정도로만 적으면 실제로 적용되는 조건을 놓칠 수 있습니다. 다운로드 날짜와 가져온 경로까지 남겨두면 업데이트 시 변경 여부를 비교하기도 쉽습니다.
내부 사용·고객 배포·웹 서비스 구분하기
프로그램을 회사 안에서만 쓰는지, 고객에게 실행 파일을 전달하는지, 서버에서 서비스를 제공하는지에 따라 검토할 부분이 달라집니다. 일부 라이선스에는 소스코드 제공이나 수정 사항 고지와 관련된 조건이 있고, 결합 방식이나 네트워크 제공 여부도 쟁점이 될 수 있습니다. 특정 라이선스가 모든 경우에 ‘전체 코드 공개’를 요구한다고 단순화하지 말고 원문과 사용 형태를 대조하세요.
가상의 납품 앱에서 남겨둘 자료
외주 앱에 오픈소스 라이브러리 세 개를 사용했다면 이름·버전·라이선스·수정 여부·사용 위치를 표로 받아둘 수 있습니다. 라이선스 사본과 고지문은 어디에 제공하는지, 소스 제공 의무가 있다면 어떤 자료를 어떤 방식으로 제공할지도 확인해야 합니다. 이미지나 폰트처럼 프로그램에 함께 들어간 자산의 조건도 별도로 점검하는 것이 좋습니다.
- 직접 도입한 것과 하위 의존성의 목록 만들기
- 라이선스 원문과 NOTICE 등 배포 파일 보관하기
- 업데이트·배포 전에 변경된 의무 확인하기
- 결합 관계가 복잡하면 전문 상담으로 검토하기
한국저작권위원회의 OLIS는 오픈소스 라이선스 원문과 설명, 가이드와 상담 경로를 제공합니다. ‘무료인가’ 다음에 ‘어떤 조건으로 제공할 수 있는가’를 묻는 습관이 유지보수와 납품 분쟁을 줄이는 데 도움이 됩니다.