소프트웨어 저작권 분쟁에서 침해·위반 여부를 판단할 때 필요한 자료와 증거

핵심 요약

주요 쟁점: 소프트웨어 저작권 분쟁에서는 프로그램이 보호받는 저작물인지, 문제 된 부분이 보호되는 창작적 표현인지, 상대방이 기존 프로그램에 의거하여 작성했는지와 실질적으로 유사한지를 구분하여 확인해야 합니다.

먼저 확인할 내용: 프로그램 개발자와 권리자, 개발시기, 소스코드 원본, 버전관리 기록, 상대방의 접근 가능성, 라이선스 계약과 실제 사용범위를 확인하는 것이 중요합니다.

초기 대응: 분쟁 당시의 소스코드와 실행파일, 저장소 기록, 개발문서, 이메일·메신저, 프로그램 배포자료와 계약서를 원본 상태로 보존하고 비교 대상이 되는 버전을 정확히 특정해야 합니다.

주의사항: 화면이나 기능이 비슷하다는 이유만으로 침해라고 단정하거나 분쟁이 발생한 뒤 소스코드·저장소 기록을 수정하면 오히려 쟁점이 복잡해질 수 있습니다. 라이선스 계약 위반과 저작권 침해도 동일한 문제로 취급하지 않는 것이 좋습니다.

소프트웨어가 비슷하다는 사실만으로 저작권 침해가 결정되지는 않습니다

안녕하세요. 유왕현 변호사입니다.

퇴사한 개발자가 유사한 프로그램을 만들었거나 외주업체가 납품한 프로그램과 경쟁업체의 서비스가 비슷하다는 이유로 소프트웨어 저작권 분쟁이 발생하는 경우가 있습니다. 반대로 정식으로 프로그램을 구매해 사용했는데 라이선스 범위를 위반했다는 통지를 받는 경우도 있습니다.

이러한 사건에서는 프로그램의 기능이나 화면이 비슷하다는 인상만으로 결과를 단정하기 어렵습니다. 누가 어떤 프로그램을 개발했는지, 저작권이 누구에게 있는지, 상대방이 기존 프로그램을 접할 수 있었는지, 실제로 어떤 부분이 같거나 다른지를 단계별로 확인해야 합니다.

먼저 어떤 프로그램과 어느 버전을 비교할 것인지 특정해야 합니다

소프트웨어는 지속적으로 수정되고 업데이트되기 때문에 단순히 두 회사의 프로그램을 비교한다고 해서는 정확한 판단이 어렵습니다.

권리자가 주장하는 원본 프로그램의 버전과 침해가 의심되는 프로그램의 버전을 각각 특정하고, 어느 시점의 코드가 문제 되는지를 정리해야 합니다.

• 최초 개발 소스코드
• 분쟁 당시의 소스코드
• 각 버전의 실행파일
• 버전별 배포일자
• 버전관리시스템의 커밋 기록
• 수정·업데이트 내역
• 프로그램 빌드 및 배포기록

분쟁 이후 변경된 최신 버전만 비교하면 실제 침해가 주장되는 시점의 프로그램과 다른 결과가 나올 수 있으므로 비교 대상과 기준시점을 먼저 확정하는 것이 중요합니다.

저작권자가 누구인지 개발계약부터 확인해야 합니다

프로그램을 개발했다고 주장하는 사람과 현재 저작재산권을 주장하는 사람이 항상 동일한 것은 아닙니다. 회사 직원이 업무상 개발한 경우, 외주개발을 맡긴 경우, 공동개발한 경우에는 권리귀속이 별도의 쟁점이 될 수 있습니다.

따라서 침해 여부를 비교하기 전에 자신에게 해당 프로그램에 관한 권리를 행사할 근거가 있는지를 확인해야 합니다.

특히 개발비를 전액 지급했다는 사실과 저작재산권이 당연히 모두 이전되었다는 것은 동일한 문제라고 단정하기 어렵습니다. 계약서에 권리귀속과 이용범위를 어떻게 정했는지를 확인해야 합니다.

프로그램의 기능과 아이디어는 보호되는 표현과 구분해야 합니다

저작권법은 컴퓨터프로그램저작물을 보호하지만 프로그램을 작성하기 위해 사용하는 프로그램 언어, 규약과 해법 자체에는 저작권법을 적용하지 않는다고 규정하고 있습니다.

대법원도 프로그램저작권 침해 여부를 판단할 때 프로그램 전체가 비슷해 보이는지를 보는 것이 아니라 저작권으로 보호되는 창작적인 표현형식을 중심으로 실질적 유사성을 판단해야 한다고 보고 있습니다.

따라서 같은 업무를 처리하고 같은 결과를 출력하거나 비슷한 기능을 제공한다는 사실만으로 소스코드가 무단 복제되었다고 단정할 수는 없습니다.

특정 기능을 구현하기 위해 선택 가능한 표현방법이 제한되어 있거나 기술적으로 통상적인 부분이라면 저작권으로 보호되는 범위인지부터 검토해야 합니다.

소스코드 비교에서는 공통부분의 성격을 분석해야 합니다

두 프로그램에서 동일하거나 유사한 코드가 발견되었다면 그 부분이 얼마나 긴지만 확인해서는 충분하지 않을 수 있습니다.

해당 코드가 개발자의 창작적인 선택이 반영된 부분인지, 특정 기능을 구현하기 위해 일반적으로 사용되는 코드인지, 공개된 라이브러리나 오픈소스에서 비롯된 것인지 등을 구분해야 합니다.

• 동일하거나 유사한 코드의 위치와 범위
• 함수·클래스·변수의 구성
• 코드의 선택과 배열
• 주석과 오탈자의 동일성
• 비정상적이거나 독특한 코드의 일치 여부
• 공개 라이브러리·오픈소스 사용 부분
• 자동 생성된 코드인지 여부

특히 동일한 주석이나 특이한 오류, 개발과정에서만 나타날 수 있는 비정상적인 코드까지 일치한다면 코드의 작성경위를 확인하는 단서가 될 수 있습니다. 반대로 공통된 부분 대부분이 공개 라이브러리나 통상적인 구현방식이라면 그 의미를 다르게 평가해야 할 수 있습니다.

상대방이 기존 프로그램을 접할 수 있었는지도 확인해야 합니다

저작권 침해를 주장하려면 결과물의 유사성뿐 아니라 상대방 프로그램이 기존 저작물에 의거하여 작성되었는지도 중요한 쟁점이 됩니다.

대법원은 기존 저작물에 대한 접근 가능성과 두 저작물 사이의 유사성 등을 통해 의거관계를 판단할 수 있다고 보고 있습니다.

따라서 퇴사한 개발자나 기존 외주업체가 관련된 사건에서는 해당 사람이 실제 소스코드에 접근할 권한이 있었는지와 어떤 자료를 보유했는지를 확인해야 합니다.

• 소스코드 저장소 접근권한
• 계정 로그인기록
• 파일 다운로드 기록
• 회사 PC·서버 접근기록
• 이메일 첨부파일 전송내역
• 퇴사 전후 저장매체 사용기록
• 외주업체에 전달한 개발자료 목록

다만 접근할 수 있었다는 사실만으로 실제 복제가 있었다고 단정할 수는 없습니다. 접근 가능성과 실제 프로그램의 창작적 표현에 관한 유사성을 함께 검토해야 합니다.

독립적으로 개발했다는 주장에는 개발이력이 중요한 증거가 됩니다

저작권 침해를 지적받은 쪽에서는 해당 프로그램을 독립적으로 개발했다고 주장할 수 있습니다. 이 경우 결과물만 비교하기보다 실제 개발과정을 보여주는 자료가 중요합니다.

기획서가 언제 작성되었는지, 최초 코드가 언제 생성되었는지, 개발자가 어떤 순서로 기능을 추가했는지를 버전관리 기록과 업무자료를 통해 확인할 수 있습니다.

분쟁이 시작된 이후 작성한 설명서보다 개발 당시 자연스럽게 생성된 기록이 실제 개발과정을 확인하는 데 중요한 의미를 가질 수 있습니다.

라이선스 위반과 저작권 침해는 구분해서 살펴봐야 합니다

기업에서 사용하는 상용 소프트웨어의 경우 무단복제뿐 아니라 라이선스 범위를 넘는 사용이 문제되는 경우가 있습니다.

예를 들어 계약상 허용된 사용자 수나 설치대수, 서버 수, 사용지역, 사용기간 또는 계열회사 사용범위를 넘었다는 주장이 제기될 수 있습니다.

이 경우에는 프로그램이 설치되어 있다는 사실만 볼 것이 아니라 실제 이용허락계약이 어떤 범위의 사용을 허용했는지를 먼저 확인해야 합니다.

• 소프트웨어 구매계약
• 라이선스 증서
• 최종사용자 이용계약
• 구매수량과 설치수량
• 사용자·장비·서버 목록
• 유지보수 및 갱신계약
• 라이선스 키 발급·관리자료

계약 위반이 있었다고 해서 그 모든 위반이 곧바로 동일한 범위의 저작권 침해가 되는 것은 아닙니다. 계약상 의무 위반인지 저작재산권의 보호범위를 침해한 것인지 각각 검토할 필요가 있습니다.

오픈소스를 사용했다면 라이선스와 코드 출처를 확인해야 합니다

현대의 소프트웨어는 외부 라이브러리와 오픈소스 코드를 함께 사용하는 경우가 많습니다. 두 프로그램에서 같은 코드가 발견되더라도 양쪽이 동일한 공개 소스를 적법하게 이용했다면 해당 부분의 일치만으로 상대방의 복제를 단정하기 어렵습니다.

따라서 사용한 외부 라이브러리의 명칭과 버전, 다운로드 경로, 적용 라이선스와 수정 여부를 정리해 두는 것이 좋습니다.

반대로 오픈소스라는 이유만으로 아무 조건 없이 사용할 수 있다고 생각해서도 안 됩니다. 각 라이선스의 고지, 저작권 표시, 소스코드 제공 등 구체적인 조건을 확인해야 하는 경우가 있습니다.

프로그램코드역분석에는 별도의 법률상 요건이 있습니다

경쟁 프로그램의 동작원리를 확인하기 위해 역분석한 자료가 문제되는 사건도 있습니다. 저작권법은 독립적으로 창작한 프로그램과 다른 프로그램의 호환에 필요한 정보를 얻기 위한 프로그램코드역분석에 일정한 요건을 두고 있습니다.

따라서 역분석을 했다는 사실만으로 위법 여부를 단정하거나, 반대로 호환성을 목적으로 했다는 주장만으로 모든 이용이 허용된다고 단정해서는 안 됩니다.

누가 어떤 프로그램을 적법하게 이용하고 있었는지, 필요한 정보를 다른 방법으로 쉽게 얻을 수 있었는지, 어느 범위까지 역분석하고 그 결과를 어떻게 이용했는지를 확인해야 합니다.

분쟁이 발생하면 원본 증거를 그대로 보존하는 것이 중요합니다

소프트웨어 분쟁은 디지털 자료가 중심이 되므로 증거를 확보한다는 이유로 파일을 임의로 수정하면 생성·수정시각 등 메타데이터가 달라질 수 있습니다.

소스코드 저장소를 정리하면서 과거 커밋을 삭제하거나 문제가 된 프로그램을 급히 수정하면 실제 분쟁 당시 상태를 확인하기 어려워질 수 있습니다.

따라서 원본 저장소와 서버자료를 보존하고 분석용 복사본을 별도로 만드는 방식 등을 검토하는 것이 좋습니다. 필요하다면 전문적인 디지털 포렌식이나 프로그램 감정의 필요성도 검토할 수 있습니다.

상대방 자료를 무단으로 확보하는 행동은 피해야 합니다

저작권 침해를 입증한다는 이유로 상대방 서버나 계정에 권한 없이 접속해서는 안 됩니다. 퇴사자의 계정을 임의로 사용하거나 상대방 프로그램의 비공개 소스코드를 부적절한 방법으로 확보하는 행동도 새로운 법적 문제를 만들 수 있습니다.

반대로 침해를 지적받은 회사가 관련 PC를 초기화하거나 저장소 기록을 삭제하는 행동 역시 피해야 합니다.

현재 적법하게 보유하고 있는 자료를 먼저 보존하고, 상대방이 보유한 자료가 필요한 경우에는 민사소송의 증거절차나 수사절차 등 적법한 확보방법을 검토하는 것이 중요합니다.

사건을 검토할 때 확인해야 할 사항

제가 소프트웨어 저작권 분쟁을 검토할 때는 먼저 권리자가 주장하는 프로그램과 침해 프로그램의 정확한 버전을 특정합니다. 그다음 개발계약과 권리이전 자료를 통해 누가 해당 프로그램에 관한 권리를 행사할 수 있는지를 확인합니다.

이후 유사하다고 주장하는 부분을 기능, 아이디어, 공개된 요소와 창작적 표현으로 나누어 살펴봅니다. 프로그램 전체의 인상이 비슷하다는 설명보다 실제 어느 코드와 구조가 문제 되는지를 특정하는 과정이 중요합니다.

유왕현 변호사인 저는 소스코드의 유사성만 따로 보는 것이 아니라 상대방의 접근 가능성과 양쪽 프로그램의 개발이력을 함께 비교하는 것이 필요하다고 봅니다. 독립개발을 주장한다면 분쟁 이전부터 존재했던 커밋과 기획·테스트 기록이 중요한 검토자료가 될 수 있습니다.

상용 소프트웨어 사용 사건이라면 저작물 자체의 복제 문제와 계약상 라이선스 범위 위반을 구분하고, 불리한 자료까지 포함하여 실제 설치·사용상태를 먼저 파악한 뒤 대응 방향을 정하는 것이 좋습니다.

상담 전 준비하면 좋은 서류와 증거

• 문제가 된 프로그램의 소스코드 원본과 실행파일
• 비교 대상 프로그램과 정확한 버전정보
• Git 등 버전관리 저장소의 전체 개발이력
• 개발 기획서·설계서·업무지시서
• 개발자별 업무분장과 개발기간 자료
• 개발 관련 이메일·메신저·이슈관리 기록
• 근로계약서·외주개발계약서·저작권 양도계약서
• 소프트웨어 구매 및 라이선스 계약
• 설치 PC·서버와 실제 사용자 현황
• 외부 라이브러리와 오픈소스 사용목록
• 상대방 프로그램에 접근할 수 있었는지 확인할 기록
• 경고장·내용증명·고소장 등 이미 받은 분쟁서류

자주 묻는 질문

프로그램 기능이 거의 같으면 소프트웨어 저작권 침해인가요?

기능이나 아이디어가 유사하다는 사정만으로 결정되는 것은 아닙니다. 저작권으로 보호되는 창작적 표현이 무엇인지 특정하고 그 부분에서 의거관계와 실질적 유사성이 있는지를 확인해야 합니다.

소스코드 일부가 같으면 바로 침해로 판단되나요?

동일한 코드가 발견되었다면 그 코드의 출처와 성격을 먼저 확인해야 합니다. 통상적인 코드, 공개 라이브러리, 자동 생성 코드인지 또는 개발자의 창작적 표현이 반영된 부분인지에 따라 평가가 달라질 수 있습니다.

퇴사한 개발자가 비슷한 프로그램을 만들면 회사 저작권 침해인가요?

퇴사했다는 사실만으로 침해 여부가 정해지지는 않습니다. 기존 프로그램에 대한 접근 가능성과 실제 이용 여부, 새로운 프로그램의 독립적인 개발과정 및 보호되는 표현 사이의 유사성을 함께 확인해야 합니다.

외주개발비를 전부 지급했다면 프로그램 저작권도 발주회사 것이 되나요?

개발비 지급 사실만으로 모든 저작재산권의 귀속을 단정하기 어렵습니다. 개발계약의 내용과 실제 창작관계, 저작재산권 양도 또는 이용허락 조항을 확인해야 합니다.

정품 소프트웨어를 구매했어도 저작권 문제가 생길 수 있나요?

정식 구매했더라도 계약에서 허용한 설치대수, 사용자, 서버, 사용기간 등의 범위를 초과했다는 분쟁이 발생할 수 있습니다. 다만 계약위반과 저작권 침해 여부는 각각의 요건에 따라 구분해서 검토해야 합니다.

소프트웨어 저작권 침해는 감정이 필요한가요?

소스코드의 규모가 크거나 보호되지 않는 요소와 창작적인 표현을 구분하기 어려운 사건에서는 전문적인 프로그램 분석이나 감정이 필요할 수 있습니다. 어떤 부분을 비교 대상으로 삼을 것인지부터 명확히 정하는 것이 중요합니다.

참고 법령과 절차

법률 고지

이 글은 소프트웨어 저작권 분쟁에서 침해·위반 여부를 판단하기 위한 일반적인 기준과 증거를 설명하기 위한 정보입니다. 실제 적용 법률과 대응 방향은 구체적인 사실관계, 프로그램의 구조, 계약내용, 증거와 사건 진행 상황에 따라 달라질 수 있습니다.