미국에서는 소프트웨어 리버스엔지니어링(Reverse Engineering, 프로그램역분석) 저작권 침해 여부에 대하여 다툼을 벌여 오다가, 1990년대에 공정이용의 항변이 받아들여져 리버스엔지니어링을 허용하게 되었습니다. Atari v. Nintendo 사건, Sega v. Accolade 사건, Sony v. Connectix 사건 등에서 공정이용의 원칙에 따라 리버스엔지니어링이 인정된 사안들입니다. 아래 내용은 강기봉, 컴퓨터프로그램의 리버스엔지니어링에 관한 법정책적 소고, 법제논단, 2014. 4. 논문의 내용을 참조하였습니다.

 

Atari v. Nintendo 사건에서 Atari NES칩의 목적코드의 해독을 시도했습니다. 닌텐도 콘솔의 보안용칩은 사용허가를 받지 않은 카트리지를 감지해 작동을 막는 10NES programming 프로토콜이 내장되어 있습니다. Atari 10NES 목적코드를 Binary code 필사하고 미국 저작권청(US Copyright Office)에서 얻은 10NES 원시코드를 이용하여 필사본의 에러를 보완하였습니다. Atari 최종 완성된 코드를 디스어셈블하고 분석하였습니다. Atari 10NES 해킹하기 위해 Rabbit 개발했는데, Rabbit 10NES 호환되도록 기능합니다. Atari 닌텐도의 NES 시스템에서 Atari사의 게임이 동작할 있도록 것입니다.

 

연방항소법원은 Atrai 미국 저작권청에서 부정하게 얻은 프로그램에 대해 공정이용의 원칙이 적용되지 않고 저작권 남용의 형평법 항변을 주장할 없다고 판단하였지만, 소프트웨어 프로그램에 대한 리버스엔지니어링은 공정이용에 해당될 있음이 확인되었습니다.

 

Sega v. Accolade 사건에서 Accolade Sega Genesis 콘솔의 호환조건을 확인하기 위해 Sega 게임프로그램을 리버스엔지니어링한 것이 문제가 되었습니다. Accolade 판매중인 Sega 게임 카트리지에 포함된 목적코드를 디스어셈블 또는 디컴파일을 통해 원시코드를 확보하고 이를 분석하여 Genesis 콘솔의 호환요건 등에 대한 매뉴얼을 작성하였습니다. 매뉴얼에는 인터페이스를 위한 설명만을 포함하고 Sega 목적코드, 소스코드 등은 포함되지 않았습니다.

 

CAFC 공정이용의 원칙에 대한 구체적인 판단 기준을 제시하면서 Accolade 리버스엔지니어링을 공정이용으로 판단하였습니다. 법원은 디스어셈블은 프로그램에서 보호받지 않는 부분들에 접근할 있는 유일한 방법이고 Accolade Genesis 콘솔의 호환되는 프로그램의 제작을 위한 리버스엔지니어링에 합법적인 이유가 있고 공정이용에 해당한다고 인정한 것입니다.

 

Sony v. Connectix 사건에서 Connectix VGS(Virtual Game Station) 에뮬레이터를 개발하기 위하여 PlayStation 하드웨어와 Bios 펌웨어를 모두 에뮬레이션한 것이 문제가 되었습니다. Connectix PlayStation 하드웨어의 에뮬레이션을 위해서, PlayStation내의 칩에서 BIOS 펌웨어를 추출하고 이것을 컴퓨터의 RAM 복제한 후에 VGS 하드웨어 에뮬레이션 과정에서 디버깅 프로그램 통해 BIOS 기능을 확인하고 BIOS 펌웨어를 이용하여 에뮬레이션 소프트웨어를 디버깅하였는데, Connectix 과정에서 Connectix BIOS 펌웨어를 복제하고 디스어셈블한 것입니다.

 

연방순회법원은 Connectix BIOS 펌웨어의 복제 이용을 Sony 프로그램의 보호받지 않는 요소들에 접근할 목적의 공정이용이라고 판결했습니다. 법원은 Sega v. Accolade 사건을 인용하여 디스어셈블이 저작권이 있는 컴퓨터프로그램에 내재된 아이디어와 기능 요소들에 대해 접근하는 유일한 방법이고 그런 접근에 합법적인 이유가 있는 경우에, 디스어셈블은 저작물의 공정이용이라고 판단하였습니다. 또한 공정이용의 원칙은 컴퓨터프로그램에 포함된 아이디어와 기능적 요소들에 대한 공중의 접근을 보장한다고 판시하였습니다.

 

우리나라 저작권법에도 위와 같은 사안을 위하여 프로그램의 복제와 리버스엔지니어링에 대한 공정이용 규정을 두고 있습니다.

 

저작권법 101조의3(프로그램의 저작재산권의 제한) 다음 호의 어느 하나에 해당하는 경우에는 목적상 필요한 범위에서 공표된 프로그램을 복제 또는 배포할 있다. 다만, 프로그램의 종류·용도, 프로그램에서 복제된 부분이 차지하는 비중 복제의 부수 등에 비추어 프로그램의 저작재산권자의 이익을 부당하게 해치는 경우에는 그러하지 아니하다.

6. 프로그램의 기초를 이루는 아이디어 원리를 확인하기 위하여 프로그램의 기능을 조사·연구·시험할 목적으로 복제하는 경우(정당한 권한에 의하여 프로그램을 이용하는 자가 해당 프로그램을 이용 중인 때에 한한다)

101조의4(프로그램코드역분석) 정당한 권한에 의하여 프로그램을 이용하는 또는 그의 허락을 받은 자는 호환에 필요한 정보를 쉽게 얻을 없고 획득이 불가피한 경우에는 해당 프로그램의 호환에 필요한 부분에 한하여 프로그램의 저작재산권자의 허락을 받지 아니하고 프로그램코드역분석을 있다.

 

 

저작권법 규정과 같이 호환을 목적으로 하지 않는 경우에는 리버스엔지니어링이 허용되지 않는다고 해석되므로 저작권법 101조의3 1 6호와 101조의4 규정은 미국에 비해 리버스엔지니어링의 허용 범위가 좁을 있다는 점은 주의가 필요합니다. 다만, 저작권법 35조의3 공정이용 일반규정을 이용한다면 호환 이외에 아이디어와 기능 등을 확인하기 위한 리버스엔지니어링도 허용될 있는 여지는 있습니다.

 

저작권법 35조의3(저작물의 공정한 이용) 23조부터 35조의2까지, 101조의3부터 101조의5까지의 경우 외에 저작물의 통상적인 이용 방법과 충돌하지 아니하고 저작자의 정당한 이익을 부당하게 해치지 아니하는 경우에는 저작물을 이용할 있다.

 

 

정회목 변호사

 

KASAN_소프트웨어 저작권과 공정이용에 의한 리버스엔지니어링.pdf

 

 

 

[질문 또는 상담신청 입력하기]

 

 

 

 

 

작성일시 : 2018. 3. 14. 17:40
Trackback 0 : Comment 0

댓글을 달아 주세요


 

 

소프트웨어 프로그램은 통상 이진파일(binary file) 포맷인 실행파일 형태로 배포되어 소스코드를 확인할 없기에 저작권 침해 여부를 확인하기 매우 어렵습니다. 이러한 경우 소스코드의 확보를 위해 침해 혐의자를 고소, 형사사건화하여 압수, 수색을 시도하기도 합니다.

 

보통 소프트웨어 프로그램 저작권 침해 사건은 소스코드의 유출이 발단이 되는 경우가 많습니다. 이때 소스코드를 유출한 직원은 경쟁업체를 설립하고 유출된 소스코드를 기반으로 개발하여 배포, 판매로 나아가게 되므로, 결국 소송에서는 프로그램 저작권 침해뿐만 아니라 경업 전직금지, 영업비밀 침해 쟁점이 함께 다투어집니다. 이때 수사절차는 대부분 피해자가 저작권 침해죄, 영업비밀 침해죄 혐의 등으로 침해 혐의자를 고소하는 것에서 시작됩니다. 그런데, 고소 이후 압수수색으로 나아가기 위해서는 검사의 청구에 의하여 판사가 발부한 영장이 필요합니다. 문제는 영장을 발부받기 위해 범죄의 혐의를 소명할 필요가 있다는 것입니다.

 

그리고 소스코드를 확보하지 못한 저작권 침해소송을 진행하는 방법으로서 감정이 사용됩니다. 그런데 감정으로 나아가기 위해서도 압수수색 영장 발부의 경우와 마찬가지로 저작권이 침해되었다는 점에 대한 소명은 필요합니다. 소명이란 입증에는 이르지 못하는 정도이지만 적어도 그럴 개연성이 있다는 점을 보이는 것입니다. 결국 소스코드 없이 어떻게, 침해하였을 개연성이 있다는 점을 보일 있는가라는 물음으로 되돌아오게 됩니다.

 

이하에서는 위와 같은 문제에 대해 실무적으로는 어떻게 접근하고 있는지에 관하여, 저작권 침해 사실의 소명을 중심으로 말씀드립니다.

 

[1] 저작권 침해 인정요건

 

저작권의 침해가 인정되려면 원칙적으로 (1) 침해자가 피해자의 저작물을 보고 베낀 사실(의거성) (2) 침해자의 결과물이 피해자의 저작물과 실질적으로 유사한 사실(실질적 유사성) 인정되어야 합니다. 소프트웨어 프로그램의 경우도 침해자가 피해자의 컴퓨터프로그램의 소스코드에 접근하였다는 사실과 침해자의 컴퓨터프로그램이 피해자의 것과 유사하다는 사실을 보여야만 합니다. 가운데 실제 소송에서 주로 쟁점이 되는 것은 실질적 유사성의 문제입니다.

 

[2] 실질적 유사성의 소명

 

법원에서는 우선 비교대상 소프트웨어 프로그램들의 기능을 추상화하여 유사성을 살피고, 다음으로 컴퓨터프로그램을 둘러싼 주변 요소들 사상의 영역과 표현을 위해 사용되는 수단적 요소들을 제거하여 여과한 다음, 남는 부분들을 비교, 검토하여 유사성 여부를 가리는 과정을 거쳐 판단합니다.

 

또한 추상화와 여과 과정을 거친 후에 남는 구체적 표현(소스코드 혹은 목적코드) 개별적으로 비교하는 외에도, 명령과 입력에 따라 개별 파일을 호출하는 방식의 유사도, 모듈 사이의 기능적 분배의 유사도, 분석 결과를 수행하기 위한 논리적 구조 계통 역시 검토하게 되고, 그와 같은 구조와 개별 파일들의 상관관계에 따른 전체적인 저작물 제작에 어느 정도의 노력과 시간, 그리고 비용이 투입되는지 여부도 함께 고려됩니다. 다만 이와 같은 검토 과정은 사안에 따라 유동적으로 사용됩니다.

 

[3] 소스코드를 확보할 없는 경우의 유사성 소명 방법

 

소스코드를 확보할 없는 사건 초기에 실질적 유사성을 소명하기 위해서는 상대방의 제품에서 이진파일 상태인 목적코드, DLL, 실행파일 등을 추출하여 비교할 밖에 없습니다. 경우에는 역어셈블 또는 역컴파일을 통해서 어셈블리어 수준 또는 소스코드 수준에서 비교를 해야 합니다만, 디버깅 정보가 모두 제거된 상태이므로 어셈블리 수준에서는 변수와 함수 명칭 등이 모두 메모리상의 주소(숫자) 변환되어 있고, 소스코드 수준으로 변환하여도 명칭 등이 모두 임의로 변경되어 있어 비교가 쉽지 않습니다.

 

이에 전체 구조의 유사성을 살피기 위해서는 함수 호출관계 차트를 그려서 이를 분석, 피해자의 소스코드와 비교하여 함수 간의 관계를 살피는 작업을 거치게 됩니다. 이것을 기준으로 유사한 함수 내의 기능과 내부 코드를 비교하여 유사도를 확인합니다. 여기서 먼저 분석할 함수로는 전체 컴퓨터프로그램에서 중요한 기능을 차지하고 새롭게 창작한 부분에 포함되는 것들을 선택하여야 것입니다.

 

이렇게 어느 정도 유사도가 확인되면, 이를 소명 자료로 만들어 법원 또는 검찰에 제출하여, 압수수색을 도모하거나 감정신청으로 나아갈 있게 됩니다. 소프트웨어 저자권 침해 또는 영업비밀 침해 사건에서 피해를 입은 회사 또는 개발자 등은 위와 같이 침해 사실의 소명이 필요하다는 사실에 주의하여야 합니다.

 

정회목 변호사

 

 

 

작성일시 : 2017. 6. 20. 14:00
Trackback 0 : Comment 0

댓글을 달아 주세요