이 프로젝트에 클린룸 리버싱을 기반으로 한 분석 명세서로 기여 가능한지 여쭙고 싶습니다.

[cho2659]

안녕하세요. 로우레벨 시스템과 역공학을 공부하고 있는 고등학교 2학년 학생입니다.

현재 교내 컴퓨터 동아리 프로젝트로 C++ 기반의 네이티브 HWP/HWPX 파서 및 렌더 엔진을 기획하고 있습니다. 법적인 문제를 피하기 위해 WINE 프로젝트의 '클린룸 리버스 엔지니어링' 방식을 도입하기로 했고, 현재 바이너리 분석팀과 실제 코드 구현팀을 완전히 분리하는 아키텍처와 분석 파이프라인 설계만 막 끝낸 시작 단계입니다.

본격적인 타겟 분석을 준비하던 중 개발자님의 rhwp 프로젝트를 보게 되었습니다. 클린룸 방식 없이 공식 문서와 수많은 테스트만으로 이미 완성에 가까운 파서를 만들어내신 것을 보고 정말 대단하다고 생각했고, 동아리원들과 함께 많이 배우고 있습니다.

특히 최근 Discussion에 남겨주신 hp:lineseg 관련 글을 보며 깊이 공감했습니다. 개발자님께서 짚어주신 것처럼, 공식 문서에는 한컴 원본 엔진이 실제로 사용하는 내부 로직이나 예외 처리(보정 로직)가 빠져 있는 경우가 많습니다. 그래서 저희는 공식 문서의 빈칸을 추측하기보다는, 분석팀이 한컴 바이너리(소스 파일이 없는 SDK 바이너리)를 직접 리버싱해서 그 숨겨진 실제 동작 방식과 보정 로직들을 찾아내어 순수한 텍스트 명세서로 정리하는 것이 더 빠르고 정확할 것이라고 판단했습니다.

저희는 이 구조를 바탕으로 C++ 구현을 막 시작하려는 참인데, 문득 저희 분석팀이 앞으로 찾아내게 될 '공식 문서에 없는 숨겨진 처리 방식'이나 '역공학 기반의 명세 자료'가 혹시 개발자님의 프로젝트를 개선하는 데도 필요하실지 먼저 여쭙고 싶습니다.

만약 이러한 실제 동작 데이터가 rhwp의 엣지 케이스를 처리하거나 구조적 한계를 푸는 데 도움이 될 것 같다면, 앞으로 저희가 분석한 결과를 어떤 방식(Issue, 공유 문서 등)으로 전달해 드리는 것이 가장 편하실지 편하게 말씀해 주시면 감사하겠습니다.

훌륭한 오픈소스 프로젝트를 공개해 주셔서 정말 감사합니다. 답변 기다리겠습니다!

[edwardkim]

이 프로젝트의 기여자 분중에서 다음과 같은 조언을 주셨습니다. 먼저 확인 해보세요.

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

1. 호환 목적 외의 다른 목적을 위하여 이용하거나 제3자에게 제공하는 경우
2. 프로그램코드역분석의 대상이 되는 프로그램과 표현이 실질적으로 유사한 프로그램을 개발·제작·판매하거나 그 밖에 프로그램의 저작권을 침해하는 행위에 이용하는 경우

[cho2659]

조언을 바탕으로, 저희가 계획한 '명세서 공유 기반의 협업'에 대해 관련 법령과 대법원 판례를 깊이 검토해 보았습니다. 결론부터 말씀드리면, 저희가 분석한 명세서를 대표님께 제공하고 이를 바탕으로 구현하시는 것은 법적으로 완벽하게 안전하다는 확신을 얻었습니다. 그 근거는 다음과 같습니다.

1. 대법원 판례 기반 '아이디어'와 '표현'의 분리 (대법원 2013. 3. 28. 선고 2010도8467)

대법원은 프로그램 저작권 침해를 가릴 때 "창작적 표현형식에 해당하는 것만을 가지고 대비해야 한다"고 명시하고 있습니다. 제가 역공학을 통해 추출하여 대표님께 드리는 것은 코드가 아니라 '논리 흐름과 명세(아이디어)'입니다. 대표님께서는 한컴의 원본 코드를 보지 않고 이 명세만을 바탕으로 바닥부터 구현하시기 때문에, 저작권법에서 우려하는 '표현이 실질적으로 유사한 프로그램'이 원천적으로 생성될 수 없습니다.

2. 독립적 창작물 인정 기준 (대법원 2012. 1. 27. 선고 2011도626)

이 판례에서는 기존 프로그램과 소스코드 유사성이 낮을 경우 "실질적인 유사성이 없는 별개의 독립적인 새로운 프로그램"으로 인정하고 있습니다. 대표님께서 명세서를 기반으로 Rust로 새롭게 작성하시는 코드는 한컴 원본과 실질적 유사성이 전혀 없는 완벽한 독립 창작물로 인정받을 것입니다. (덧붙여 한컴 문서의 부정확성과 뻔한 라이브러리 구조의 사용은 침해 예외 대상에 해당합니다.)

3. "제3자 제공" 조항에 대한 합리적 해석

가장 우려하셨을 법조항인 "호환 목적 외의 다른 목적을 위하여 이용하거나 제3자에게 제공하는 경우"에 대해서도 저희 팀 나름의 논리적 검토를 거쳤습니다. 만약 이 조항이 '호환 목적 달성을 위한 팀원이나 파트너 간의 명세서 공유'조차 제3자 제공으로 보아 전면 금지하는 것이라면, 업계 표준인 '클린룸 구현(역공학자와 구현자의 분리)' 자체가 법적으로 불가능해지는 모순이 발생합니다. 이는 오히려 역공학자의 뇌에 남은 원본 코드의 잔재가 새 프로그램에 섞여 들어가 '실질적 유사성'을 발생시키는 위험한 결과를 초래할 것입니다. 따라서, 호환성을 달성하기 위한 필수적인 협업 과정에서, 원본 코드가 철저히 배제된 '추상화된 로직과 명세(텍스트)'만을 공유하는 것은 해당 법조항의 본래 취지(호환성 보장 및 무단 복제 방지)에 부합하는 정당한 행위라고 판단하고 있습니다.

[edwardkim]

rhwp 라는 프로젝트 자체가 소스코드는 단지 결과물일 뿐이고 진정한 가치는 문서를 통한 지식 증류입니다. 말씀 하신 것처럼 진행하시고 문서로 기여하시면 저도 기쁜 마음으로 사용하도록 하겠습니다.