Who owns the perk in Java?
May 8th 2012, 0:28 by G.F. | SEATTLE
2010년 오라클은 구글이 그들의 지적 재산권(IP)을 안드로이드 모바일 플랫폼에서 이용하여 침해 했다고 비난했다. 오라클은 그 이후 구글 경영진들 간의 이메일, 복제된 것으로 알려진 프로그램 코드의 단편 등 수많은 법적 증거들을 제시했다. 5월 7일 샌프란시스코 연방 재판소는 그들에게 유리한 판결을 내렸다. 어느 정도는.
배심원의 결정에 따르면, 구글은 자바 기반 구조의 부분적인 면과 관련 있는 오라클의 지적재산권을 배꼈다는 것이다. 우선, 구글은 그들 자신만의 자바 버전을 위해 이 논쟁이 되는 소프트웨어를 구성하는 1500만 줄의 오라클 코드 중 9줄을 무단으로 복사했다는 것이다. 이 재판의 다음 단계에서 판정이 날 이 악행으로 인한 손해는 법령 상 150,000달러를 넘을 수 없다. 더 논쟁이 되는 것은 또한, 구글은 코드를 직접적으로 복사해온 것은 아니지만 “저작물의 전반적인 구조, 절차, 조직”을 배껴서 오라클의 저작권을 침해했다고 여겨지고 있다는 점이다.
이상하게도, 배심원들은 이 침해가 법적으로 납득할 만한 것인지 여부에 대한 합의에 이르지 못했다. 이것은 오라클이 구글로 인한 피해를 수집하지도 (10억불 이상을 목표로) 또는 적어도 현재는 안드로이드가 부분적으로 다시 작성되어야 한다고 요구하지도 못하고 있다는 것을 의미한다. 이 혼란에 더하여, 한 배심원은 이 문제에 대해서 그녀의 남편과 상의하는 법으로 금지된 행동을 했다는 것이 드러났다. 구글은 미결정 심리를 요구해왔다. 현재 따분한 특허 분쟁으로 이어지고 있는 이 소송의 전반부는 재심되거나 항소될 것으로 보인다.
그렇다면, 이 모든 호들갑은 무엇 때문인가? 오라클의 저작권 관련 고소들은 두 종류의 소프트웨어 배관을 중심에 두고 있다. 어플리케이션 프로그래밍 인터페이스(APIs)와 자바 가상 머신이다. (JVMs)
API부터 살펴보자. 이것은 소프트웨어 개발자로 하여금 프로그래밍 언어(Java나 C++) 혹은 서비스 (Facebook나 Twitter)와 매끄럽게 상호 연동되는 어플리케이션을 개발할 수 있게 해주는 링크이다. API가 없다면, 프로그래머는 우선 대상으로 하는 플랫폼 내부의 기어와 톱니들이 어떻게 작동되는지 이해한 후, 이러한 것들을 조합하여 소프트웨어를 개발해야 한다. 게다가, 서로 다른 하드웨어 플랫폼은 여기에 쓰이는 언어나 서비스들이 제작자에 의해 수정될 때 마다 끊임 없이 업데이트 되어야 하는 별도의 소프트웨어 버전을 필요로 한다. API는 이러한 비효율성을 줄여준다.
다행스럽게도 프로그래머들은 이해할 수 없는 0과 1의 연속으로 컴퓨터 프로세서가 이해하는 기계 코드로 소프트웨어를 작성하지 않아도 된다. 대신, 컴파일러라고 하는 별도의 프로그램을 통해 특정한 “고 수준”의 언어(어휘나 문법이 자연어와 완전히 다르지 않다)로 작성된 코드를 기계가 이해할 수 있는 명령으로 변환한다. API는 날짜를 표시해주는 것과 같은 간단한 것에서부터, 암호화 키를 생성하는 것처럼 더 복잡한 것 까지 기본적이고 잘 정의된 작업을 수행하는 코드의 만들어진 집합을 이용할 수 있게 제공하여 코더를 훨씬 더 편하게 만든다.
특정 언어를 위한 하나의 API는 하나의 기능적인 대응물과 쌍을 이루는데, 이는 하나의 라이브러리로서 여기에는 문제의 작업들을 수행하는 해당 언어의 코드 조각들이 포함되어 있다. 이들은 프로그래밍 언어, 유료나 라이센스 애드온, 또는 공개된 소스와 무료이지만 저작권이 있는 코드의 조합에서 필수적인 부분이다. 그리고 비록 기술적이지만 명확하게 설명된 사용 설명서가 있다. 여기에는 각 코드의 부분이 어떤 일을 하는지에 대한 설명이, 프로그램의 소스코드에 삽입되면 라이브러리의 관련된 부분을 바로 실행되게 하는 명령어(함수 호출로 불리는)와 함께 나와있다. 라이브러리 코드의 어떤 부분이라도 밑바탕부터 작성될 수는 있지만 이는 시간이 걸리는 일이고, 결정적으로 광범위한 테스트를 거친 라이브러리에 포함된 코드들을 이용하는 장점을 얻지 못한다. 새롭게 작성되는 프로그램에서는 원하는 기능에 대한 참조만을 이용하는 것이 더 쉽고, 안전하고, 단순하다.
하드웨어의 특정 부분을 구동하기 위해서는 고 수준의 언어로 작성된 프로그램은 반드시 우선 머신 코드로 변환되거나 “컴파일”되어야 한다. (이 작업은 일반적으로 프로그램이 완성되고 배포되기 전에 일어난다) 하드웨어가 컴파일 된 프로그램을 구동하면서 함수 호출에 다다르면, 라이브러리(완성된 코드 안에 포함되어 함께 컴파일 된다)의 해당 부분으로 점프하고, 그 기능의 코드를 실행한 후, 다시 프로그램의 주 흐름으로 돌아온다.
고 수준 언어의 부분적인 코드들 외에, 몇 API 코드 라이브러리들은 특정 하드웨어 플랫폼을 위해 미리 컴파일 된 부분들을 포함하고 있는데, 이 중 나머지 부분의 프로그램이 해당 장치로 컴파일 될 때 적절한 것을 자동적으로 선택하게 된다. 자바 API 코드 라이브러리들은 고 수준의 코드만을 포함하고 있다. 자바 프로그램은 이들 모두를 한번에 컴파일 한다. 이 부분이 가상 머신이 관여하는 곳이다.
가상 머신은 물리적인 연산 장치를 흉내 내는 컴퓨터 프로그램이다. 이것은 예를 들면 마이크로소프트의 윈도우처럼 하나의 플랫폼을 위해 디자인 된 어플리케이션을 애플의 매킨토시처럼 다른 곳에서 구동할 수 있게 해준다. 자바 가상 머신 자체는 자바가 아닌 C++와 같은 언어로 작성되고, 설치될 기기에 맞는 기계 코드로 컴파일 된다. 모든 프로세서와 운영 체제의 조합은 각자 고유의 자바 가상 머신을 가진다. (인텔의 칩에서 구동되는 애플의 iMac 처럼)
특정 언어의 방언을 이해하는 실제 프로세서처럼, 모든 자바 가상 머신은 자바의 머신 코드와 같은 버전으로 말한다. (자바 바이트코드라 불리는). 사실상, 그들은 자바 바이트 코드와 물리적 하드웨어의 머신 언어 사이를 번역하는 역할을 한다. 이론적으로는, 어떤 자바 프로그램도 한번 컴파일 되면 모든 자바 가상 머신에서도 구동될 수 있고, 선 마이크로시스템즈(오라클이 2009년 인수했다)는 이를 “한번 작성하고, 모든 곳에서 작동된다.”라고 부르며 자바 개발자들을 모집했다.
하지만 현실적으로 오라클은 자바 바이트코드의 방언들을 지원하기 위해, 스마트 카드, 모바일, 데스크탑, 서버에 맞추어진 4가지 종류의 자바 가상머신을 제공한다. 서버 자바 가상 머신을 위해 컴파일 된 프로그램은 실행을 위해 반드시 필요로 한 요소가 다른 종류의 가상 머신에서는 빠져 있을 수도 있으므로 모바일 자바 가상 머신에서 반드시 구동되어야 하는 것은 아니고, 이 반대도 마찬가지다. 예를 들어, 경량화된 모바일 가상 머신은 연산 능력을 필요로 하거나, 불필요하게 스마트폰을 느리게 만드는 복잡한 서버 기능들을 수행할 능력을 가지고 있지 않다. 반면, 서버 가상 머신은 배터리 소비에 있어서 효율적이어야 할 필요가 없다.
오라클은 4종류의 가상 기기 중 최소한 하나 이상을 위해 작성된 어떤 소프트웨어라도 구동할 수 있는 능력이 있다는 것을 보이는 조건 하에 다른 기업들에게 그들만의 자바 가상 머신을 만들수 있게 허가 하고 있다. 이것은 장치 제조사들이 그들의 기기를 위한 맞춤형 자바 가상 머신을 만들 수 있도록 한다.
구글은 그들의 안드로이드 모바일 플랫폼을 위해 Dalvik이라고 불리는 자신만의 자바를 만들고 Dalvik APIs와 라이브러리, 그리고 가상 머신까지 개발하였다. 표면상으로 Dalvik과 Java는 다르지만, 그들의 구조나, 많은 특징들은 동일하다. 결론적으로, 자바 프로그램도 Dalvik으로 변형되어 구동될 수 있고 그 반대도 마찬가지다. 결정적으로, 한 언어를 알고 있는 개발자들은 이 언어의 근본적인 유사성 때문에 다른 언어도 능숙하게 다룰 수 있다. 하지만 Dalvik 프로그램이 안드로이드 플랫폼에서 구동되기 위해서 컴파일 될때, 이의 바이트코드는 자바의 것과는 달라서 다른 자바 가상 머신과는 호환되지 않는다.
Dalvik과 관련 제품들을 만들기 위해 구글은 오픈 소스 프로젝트를 활용했고 그 중 소수가 오라클 소유의 보호 라이센스를 가지고 있었다. 구글은 이 것들을 자신들의 코드를 보강하기 위해 이용했지만 라이센스를 얻지는 않았다. 비록 내부적으로 다른 코드로 구현 되었음에도 불구하고 결과적으로 Dalvik의 173개의 API 중 37개가 자바의 것(총 166개를 보유했음을 자랑한다)과 동일하다.
이 모든 것들이 오라클을 여러가지 면에서 짜증나게 했고, 소송까지 이어졌다. 첫 째로, 오라클은 구글이 Dalvik의 API관련 라이브러리에서 자신들의 코드 일부를 훔쳤었다고 주장했다. 구글은 이를 인정했지만 논란이 되는 부분은 오래전에 삭제 되었다고 주장했다. 법정은 평결에서 언급한 9줄의 코드를 제외하고는 구글의 손을 들어주었다. 둘째로, 오라클은 구글이 어떤 허락이나 라이센스를 얻지도 않은채 그들의 언어 디자인을 배끼고, API 상세를 이용했으며, 또한 자바 인프라스트럭처의 다른 요소와 호환되지도 않는 가상 머신을 만들었다고 주장한다. 이 부분에서, 배심원들은 오라클의 손을 들었다.
그리하여, 재판장은 양측에게 평이한 영어로된 API 상세, 함수 호출 또는 내부 코드에 있어서의 특정한 표현은 저작권에 의해 보호 받을 수 없다고 가정한다고 말했다. 소프트웨어로 어떻게 구현되어 있던지는 상관하지 않고, 최소한 함수의 입력과 출력이 구분 불가능한 함수에 한하여 저작권이 적용된다. 몇 참관인들은 현재 API의 기능이 정말로 저작권의 대상이 될지에 대한 원칙이 없는 상황에서의 이러한 결정에 의아해 했다.
어느 쪽이든 실제 저작권 침해가 일어났다는 결론에도 불구하고, 배심원단은 아직도 구글의 행동들이 “공정 사용” 원칙에 포함되는 것인지 여부를 결정 짓지 못했다. 공정 사용 원칙은 소프트웨어 관점에서 라이센스나 허가를 구하지 않고도 구글이 자바가 이루어 놓은 것들을 생각하거나 모두 모방할 수 있도록 허가하는 것으로 해석 될 수 있다. 재판부는 이 불완전한 평결을 받아들였고, 원칙과 관련된 의문과 관련된 자신만의 의견을 재판의 다음 단계에서 제시할 것으로 보인다.
구글은 API 함수 기능은 코드와는 다르게 저작권의 보호 대상이 될 수 없다고 주장한다. 구글이 경고해왔던 것처럼 이것은 언어에서 평이한 단어 하나의 소유권을 주장하는 것과 마찬가지가 될 수 있다. 만약 그들의 미결정 심리 요구가 받아들여진다면, 새로운 소송들이 잇따를 것이다. 만약 그렇지 않다면, 아마 판결문에 의의를 제기하고 대법원까지 끌고 갈 가능성이 크다.
많은 기술 전문가들은 완전히 오라클에 우호적인 판결이 나올까 초초해하고 있다. 다른 소스코드에 기반한 동일한 API 기능은 인터넷과 오프라인 상의 하드웨어, 소프트웨어, 서비스 전반에 걸쳐 넘쳐난다. 만약 법원이 오라클의 편을 들면, 기술적인 개발 환경 전체가 요동 칠 것이다.