기본 콘텐츠로 건너뛰기

Android: Oracle이 제기한 Google Android에 대한 소송

NOTE - 이 글에 작성한 내용은 이미 언론에 공개되어 있는 내용을 근거로 하여 정리한 개인적인 의견입니다. 회사의 의견이나 회사의 비밀 정보는 전혀 없음을 알립니다.

8월 12일 미국 NORTHERN DISTRICT OF CALIFORNIA의 지방 법원에 Oracle이 Google을 상대로 특허와 저작권을 침해하였다고 Case No. pa-1418106으로 소송을 제기하였다.

이미 많은 뉴스에 기본적인 소송 내용을 소개하고 있으니 아래 링크에서 간단히 확인을 해보시기 바란다.
이 글에서는 pa-1418106에서 구글이 침해하였다고 주장한 오라클이 보유한 7개의 특허를 정리해보려고 한다. 다시 한번 말하지만 아래 내용은 회사 내부 정보와는 전혀 관계 없고 미국 특허청이 제공한 public한 특허 문서를 보고 개인적으로 정리해본 내용이다.

- 실제 특허의 내용과 내가 이해한 내용이 차이가 있을 수 있음을 미리 알린다. -

1. No. 6,125,447
특허명: "Protection Domains To Provide Security In A Computer System"

2. No. 6,192,476
특허명: "Controlling Access To A Resource"

위 1,2 번 특허 모두 permission에 기반한 보안 처리에 대한 특허 내용으로 보인다. 모두 Li Gong이 제안한 특허.

3. No. 5,966,702
특허명: "Method And Apparatus For Preprocessing And Packaging Class Files"

복수 개의 클래스 파일에 중복된 데이터를 전처리 과정에 의해 중복을 합치고 제거하는 처리에 대한 특허 내용인 것 같다. Nedim Fresko가 제안한 특허.

4. No. 7,426,720
특허명: "System And Method For Dynamic Preloading Of Classes Through Memory Space Cloning Of A Master Runtime System Process"

복수 개의 VM 프로세스를 실행 시 초기화 과정을 줄이기 위해 메모리 cloning을 이용한 preloading에 대한 특허 내용으로 보인다. Nedim Fresko가 제안한 특허이다.

5. No. RE38,104
특허명: "Method And Apparatus For Resolving Data References In Generate Code"

컴파일된 바이트 코드를 인터프리트 할 때 성능을 향상 시키기 위해 심볼 정보를 실행 시 숫자 값으로 변경하여 인덱스 정보로 빠르게 링크하는 방법에 대한 특허로 보인다. James Gosling 님께서 제안한 특허.

6. No. 6,910,205
특허명: "Interpreting Functions Utilizing A Hybrid Of Virtual And Native Machine Instructions"

바이트 코드의 특정 부분을 동적으로 컴파일하여 native code로 만들고 인터프리트와 native code 부분을 번갈아가며 수행하는 방법에 대하여 설명하는 특허로 보인다. Sun의 Java ME HotSpot VM을 개발하고 Google로 옮겨 Chrome 브라우저의 V8 엔진을 개발하고 있는 Lars Bak에 의해 제안된 특허. (아... Java ME CLDC-HI는 개인적으로 많이 보던 코드인데 기초를 바로 이 분이 만들었군... 음)

7. No. 6,061,520
특허명: "Method And System for Performing Static Initialization"

static array 초기화에 필요한 많은 바이트 코드 수행 결과를 .mclass 파일에 미리 저장하여 초기화 과정을 최적화하는 내용으로 보인다.
Java Virtual Machine 스팩을 Tim Lindholm과 함께 쓴 Frank Yellin이 제안한 특허. 아... 정말 쟁쟁한 분들이 만든 특허들이다. 현재 이 분도 Google에 있는 듯.

특허의 내용이 많아 얼추 리뷰해서 작성한 내용이라 정확하지 않을 수 있음을 양해 바란다.

이상과 같은 7개의 특허를 침해한 혐의와 함께 Java에 대한 Copyright를 침해한 혐의를 포함하고 있다.

UPDATE1:

해외 언론에서 소송에 대한 기사/의견들이 올라오고 있군요.

UPDATE2:

Java의 아버지라 불리는 James Gosling이 자신의 블로그에 올린 Oracle / Google의 소송에 대한 comment 입니다. 흥미로운 부분을 발췌해서 올려봅니다. 원문은 http://nighthacks.com/roller/jag/에서
  • When it came to cellphones and JavaME, we weren't as able and successful at achieving interoperability. There were a lot of factors, but it all added up to pain for developers and a chilling of the software market. When Google came to us with their thoughts on cellphones, one of their core principles was making the platform free to handset providers. They had very weak notions of interoperability, which, given our history, we strongly objected to. Android has pretty much played out the way that we feared: there is enough fragmentation among Android handsets to significantly restrict the freedom of software developers.
  • Money was, of course, also an issue between Sun and Google. We wanted some compensation for the large amount we would be spending on engineering. Google did have a financial model that benefited themselves (that they weren't about to share). They were partly planning on revenue from advertising, but mostly they wanted to disrupt Apple's trajectory, and Apple's expected entry into advertising. If mobile devices take over as the computing platform for consumers, then Google's advertising channel, and the heart of its revenue, gets gutted. It doesn't take much of a crystal ball to see where Apple is going, and it's not a pretty picture for Google or anyone else. 
짧게 정리해보면 Google이 휴대폰에 대한 플랫폼을 Sun과 논의 시 모바일 플랫폼을 open source로 제공하여 Apple의 iPhone에 의한 시장 지배력을 약화시키는 것에 큰 관심을 두고 있었지만 Java의 상호 호환성에 대해서는 별로 관심이 없었다는 것. 이는 Sun의 입장에서는 예전 MS와의 마찰과 마찬가지로 강력히 반대하는 입장이었다는 것.
또한, Java를 사용하는 것에 대해 Sun은 Google에서 약간의 보상을 원했지만 Google은 플랫폼은 무료로 제공하고 광고에 의한 금전적 이득을 챙기는 것을 목표로 했고 이를 Sun과 나누는 것에는 찬성하지 않았다는 것...

UPDATE3:

업친데 덥친격 Apple이 제기한 Touch UI에 대한 특허 소송에서 승소하였다는 소식...
Google의 Android Bot 로고 또한 표절이라는 의혹까정...


UPDATE4:

ZDNet의 기사에 따르면 Google의 Android 소스 코드내에 Oracle의 Copyright를 포함한 파일들이 발견되었다고 한다. 이 파일들이 기술적으로는 큰 의미가 없다고는 하지만 법정에서는 기술적인 가치를 따지는 것은 별반 중요치 않을 것으로 보인다.

결국 이런 날이 오고야 말았다. 공짜라고 열심히 사용했더만 여기 저기에서 특허 소송을 내고 로열티 챙기기에 나서고 있다. MS에 이어 Oracle도 Java 특허에 대한 로열티를 내라고 삼성에 협상 중이란 소문이다. 결국 Android로 배불리는 것은 미국의 주요 IT 기업들이란 말인가? 
얼마전 Apple의 Touch UI에 대한 특허가 인정되었다는 소식도 있었는데 Apple도 Android 휴대폰 개발업체에 로열티를 요구하면 어떻게 되는건지... 휴대폰 한대 팔아서 30 달러 이상 로열티로 나가게 되면 경쟁력 떨어지고 결국 Apple과 Nokia + MS 진영이 승승장구하게 되지는 않을까?

안드로이드 갈수록 태산이군요. Apple이 얼마전 득한 Touch 관련 특허분쟁도 남아있는데 기존에 HTC를 상대로 제기한 특허소송에서 HTC가 2건의 Apple 특허를 침해하였다는 예비 판결이 나왔다고 합니다. 이 판결이 확정으로 바뀌면 HTC가 미국에 안드로이드 폰을 수출할 수 없다네요. MS 신나겠네요 ...

    댓글

    이 블로그의 인기 게시물

    Wireless: HotSpot 2.0 이란?

    스마트폰 사용자가 HotSpot 2.0을 지원하는 Wi-Fi 망을 사용하는 경우라면 기존 Wi-Fi 망과 달리 이동통신 망에서 Wi-Fi 망으로의 네트워크 연결 전환이 자연스럽게 이루어진다. 예를 들면, 3G 네트워크를 이용하여 영화를 보고 있다가 HotSpot 2.0 네트워크에 연결이 가능하게 되면 영화 시청 중단 없이 Wi-Fi 망으로 자연스럽게 네트워크 연결이 이동하여 3G 망의 부하도 줄이고 사용자의 네트워크 비용도 절약할 수 있다. 시스코에서 제공한 White Paper 를 참고.

    Apple M1 Mac Mini에서 이더리움 (Ethereum) 채굴하기

     돈을 벌 목적은 아니고 이더리움 기술에 대한 호기심에 직접 채굴(마이닝)에 나서 보기로 했다. 머신은 Apple M1 Mac Mini. 스팩을 살펴보니 8 Core GPU에 16GB 메모리를 공유하고 있어 가능은 해보인다. 큰 흐름은 다음과 같다. 채굴한 이더리움을 저장할 지갑을 만든다 만든 지갑의 정보를 잘 보관해둔다 (Secret Recovery Phrase, 지갑의 주소 값) Apple M1용 채굴 프로그램 설치 내 지갑 정보를 이용해서 채굴 프로그램 실행 일단, 채굴한 이더리움을 저장할 지갑(wallet)을 만들어야 한다.  크롬 브라우저 익스텐션 설치로 비교적 간단하게 지갑을 만들 수 있는  https://metamask.io/ 를 이용하기로 했다. 크롬 익스텐션을 설치 후 기존에 만든 지갑이 없으므로 "Create a Wallet"을 선택한다. 패스워드 입력하고 등등의 절차를 거치면 아래와 같은 Secret Recovery Phrase가 나온다. 이 값을 잘 보관해두기 바란다. 나중에 지갑을 복구할 때 필요한 값이다. 이 값이 유출되면 지갑에 모아둔 이더리움을 다 털릴 수 있으므로 안전한 곳에 보관한다. Confirm Your Secret Phrase에서 확인 과정을 거친다. 직접 입력하는 것이 아니라 단어 별 버튼을 일일이 클릭해서 확인해주어야 한다. (좀 번거롭지만 그만큼 Secret Recovery Phrase가 중요함을 인지시키기 위한 과정이다.) 이제 지갑은 준비 완료. 생성된 Account 화면에서 지갑의 주소갑을 얻을 수 있다.  Apple M1용 채굴 프로그램을 설치해보자. Ethminer M1 Github 프로젝트 에서 미리 컴파일된 바이너리를 다운로드 받는다. (Assets를 펼치고 ethminer-m1을 클릭해서 다운 받으면 된다) 원하는 폴더에 파일을 옮겨 놓고 Terminal에서 chmod +x로 실행가능하게 만든다. % mv ~/Downloads/ethminer-m1 .   ...

    SKT HSS 서버 해킹 사태에서 USIM 교체의 보안 효과

    최근 발생한 SKT의 HSS(Home Subscriber Server) 서버 해킹 사건은 이동통신망의 핵심 인프라를 겨냥한 중대한 보안 위협입니다. IT 및 통신 보안 전문가의 관점에서 이번 사태의 기술적 내용을 이해하고, USIM 교체가 왜 효과적인 대응 방안이 될 수 있는지 설명드리겠습니다. HSS(Home Subscriber Server)란 무엇인가? HSS는 이동통신망의 핵심 구성 요소로서, 가입자에 대한 모든 인증, 권한 부여, 이동성 관리 정보를 저장하고 관리하는 중앙 집중식 데이터베이스입니다. 쉽게 말해, 이동통신 가입자의 '마스터 키'와 같은 역할을 수행합니다. 휴대폰을 켜거나 기지국에 연결될 때마다 단말기는 USIM(Universal Subscriber Identity Module)에 저장된 정보를 이용하여 HSS에 접근하고, HSS는 해당 가입자가 네트워크에 접속하고 서비스를 이용할 수 있는 정당한 사용자인지 확인하는 인증 절차를 수행합니다. HSS에 저장되는 주요 정보에는 다음과 같은 민감한 데이터가 포함됩니다. IMSI (International Mobile Subscriber Identity): 가입자를 고유하게 식별하는 국제 표준 식별자입니다. USIM 인증 키 (Authentication Key): USIM과 HSS 간의 상호 인증에 사용되는 비밀 키입니다. 이 키는 통신 세션 설정 시 무단 접근을 방지하는 데 필수적입니다. 서비스 프로파일: 가입자가 어떤 서비스(음성 통화, 데이터 통신, 부가 서비스 등)를 이용할 수 있는지에 대한 정보입니다. 이동성 관리 정보: 가입자의 현재 위치 정보 등을 관리하여 통신 연결을 유지합니다. SKT HSS 서버 해킹의 기술적 의미 이번 SKT HSS 서버 해킹은 공격자가 이동통신망의 가장 민감한 정보를 관리하는 핵심 시스템에 침투했다는 점에서 심각성을 가집니다. 정확한 공격 경로는 조사를 통해 밝혀지겠지만, 일반적으로 HSS와 같은 중요 서버는 외부 인터넷과 분리된...