| [ garbages ] in KIDS 글 쓴 이(By): cookie () 날 짜 (Date): 2012년 05월 16일 (수) 오전 07시 23분 16초 제 목(Title): 구글과 오라클 특허 분쟁 java Java 를 두고 오러클과 구글이 대대적인 특허소송 한판을 벌이고 있는데 오라클이 내세우는 Java 관련 특허중 특히 문제가 되는 핵심은 인터프리터 구현방식의 한 특허이다. 구글은 Sun/Oracle 이 만든 원래 자바 구현의 소스를 보지않고 공개된 java 외부문서에만 기반해 새 클린룸 방식으로 안드로이드 용 자바 구현를 만들어 쓰고 있으므로 원래 Sun/오러클의 지적재산권을 침해하지 않았다는 거다. 그런데 오러클의 주장은 특허는 저작권과는 달리 클린룸방식으로도 피해갈수 없다는 거다. 하지만 둘다 엉뚱한 주제를 가지고 다투고 있다고 본다. 문제는 이 특허가 (92년 선의 고슬링이 취득) 일반적으로 스크립트 언어의 가상머신 VM 인터프러터에 대부분 채용되는 방식이라는 거다. 특허 내용을 간단하게 줄이자면 Java VM 구현에서 VM 명령어의 데이터 참조를 숫자 메모리 주소가 아닌 심볼릭한 주소로 지정하고 인터프리터에서 이를 번역해 실제 메모리 데이타를 이용한다는 개념의 특허이다. 보통 일반 CPU는 사용자의 변수값같 데이터를 참조할때 숫자로된 주소 address 를 사용해서 접근한다. 메모리는 항상 숫자주소로만 실제로 이용가능하므로 이런식으로 심볼릭한 aaa 를 실제메모리 숫자 주소로 매핑하는걸 바인딩이라 한다. 예를 들어 aaa = 123 은 STORE ($45678), 123 이런식으로 aaa 는 컴파일시에 값이 $45678로 정해지는 숫자 주소 위치 메모리 위치로 대표되어 이용된다. 물론 외부 참조일때는 링크나 런 때까지는 바인딩 되지 않고 있다가 링크나 런타임에 실제 숫자 주소 메모리 위치에 바인딩 된다. 그런데 Python 등 동적 바인딩에 기반한 대부분의 스트립트언어나 Basic 등의 가상머신기반 언어들은 링크라는 바인딩 과정이 없이 실행되므로 최종 컴파일된 프로그램에서도 aaa 라는 변수는 실제 숫자주소가 아니라 여전히 "aaa"라는 심볼로 남아있다가 VM 인터프리터가 런타임에 "aaa"가 이용될 때 각 펑션이나 모듈의 심볼 해쉬 테이블에서 "aaa" 해쉬값으로 찾아서 이용하는 식으로 구현하는게 일반적이다. 즉 바인딩 되는 시간이 늦어서 late binding, 또는 실행중에 실제 메모리 위치가 변할수 있으므로 dynamic binding 이라고 한다. 말하자면 매번 변수를 참조할 때마다 재 링크 재 바인딩 하는 셈이다. 이건 특히 dynamic binding 을 사용하는 모든 언어에선 언어 디자인 자체가 이렇게 실행시간에 바인딩 하는 걸 전체로 설계되어 있다. 그러니 해당 VM의 인스트럭션도 STORE @["aaa"] 123 이런식으로 되어 있다. 즉 "aaa"로 레퍼런스 되는 메모리 위치에 123 을 저장하라는 거다. 이를 동적 바인딩이라고 하며 이는 지극히 일반적인 기술이다. 그러니 이건 특허이므로 저작권 개념인 클린룸이나 공정사용이 적용되는게 아니라는 오라클의 말은 맞지만 이미 동적 언어 인터프리터에서 일반적으로 그전부터 널리 사용되는 (당연히 java 가 이런식의 VM의 최초는 아니다) 방식을 정적언어인 java의 인터프리터 구현에 채용했다는 것외엔 아무 것도 아니니 특허 자체가 "prior art"가 있으므로 무효라고 본다. 정적인 언어인 Basic 도 당연히 이런 방식을 채용하고 있다. Java VM 인스트럭션의 스펙 자체가 이런 동적, 심볼릭 레퍼런스를 지정하고 있으므로 모든 java vm 구현 은 late/dynamic 바인딩을 사용해야 한다. 물론 정적언어인 java의 VM구현에서도 이렇게 함으로서 컴파일러의 구현이나 VM의 속도등에서도 이득이 있으므로 채용하였지만 새로운 발명인건 전혀 아니라고 본다. |