Oracle-Google-retssag fortsætter: Sun ville have penge for Java

Illustration: Android Logo
Det var ikke et spørgsmål om penge, der fik Google til at undlade at betale Sun licens. Snarere et spørgsmål om kontrol over Androids nøglekomponenter.

E-mails mellem Google og Sun fra Androids spæde barndom, afslører at de to softwaregiganter var tæt på en aftale om at bruge Suns programmeringssprog Java til Android. Det skriver Venturebeat.com.

Læs også: Oracles sag mod Google: Hvornår er kode omfattet af ophavsret?

Dog valgte Google alligevel at bruge deres egen version af Java til Android, fordi Google ikke ville have, at Sun skulle have kontrol over nøglekomponenter i Android.

Ifølge den tidligere Google-CEO Eric Schmidt, som også arbejdede på Java, da han var ansat ved Sun, forlangte Sun licensafgifter, hvis en virksomhed ville bruge Suns implementering af Java. Men hvis en virksomhed brugte sin egen implementering slap man for licenser.

Derfor følte Google sig ikke forpligtet til at købe licens til Android. Eric Schmidt forklarer dog, at Google var parat til at betale Sun, hvis virksomheden havde valgt at bruge Suns Java.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Lars Bjerregaard

Da artiklen er en smule overfladisk, kommer her lige en vigtig forebyggende kommentar.

Dog valgte Google alligevel at bruge deres egen version af Java til Android

I Android bruges ikke "en egen version af Java". Programmerings sproget som bruges til at kode Android apps er sproget "Java"(tm), uden nogen modifikationer eller svinkærinder. Denne Java sourcekode compiles til alm. .class filer. Disse .class filer oversættes til .dex filer. Disse .dex filer, samt ens resourcer pakkes sammen til en .apk fil. Denne .apk fil deployes til ens Android device. .dex koden i ens .apk fil afvikles på ens Android device, af den virtuelle maskine med navnet Dalvik. På runtime tidspunktet bruges open source klassebiblioteket Apache Harmony, som indeholder det subsæt af klasserne i JSE som er relevante for en mobil (Android) app.

Umiddelbart er de teknologier som anvendes, der har noget med Sun/Oracle at gøre følgende: Den almindelige JSE Java compiler (javac), JSE Java klassebiblioteket (kun i udviklingsfasen).

Resten er open source teknologi og komponenter, udviklet af diverse: Dex compiler, Apache Harmony klassebiblioteket, Dalvik Virtuel maskine.

Der er således ikke tale om nogen "egen version af Java". Håber det gør tingene klart.

  • 10
  • 0
#2 Tore Green

Et definere sin egen delmængde af JSE, herunder en delmængde af java.lang kan vel godt kaldes en "egen version af java".

Og så vidt jeg husker går en del af sagen på at dalvik indeholder kode kopieret fra jvm samt krænker sun/oracles patenter. Hvis disse påstande holder, er tingene vist ikke så sort/hvide som forklaret her.

  • 1
  • 3
#3 Lars Bjerregaard

Et definere sin egen delmængde af JSE, herunder en delmængde af java.lang kan vel godt kaldes en "egen version af java".

Der er adskillige "additions" af "java" som kommer fra Oracle's hånd, nogen er subsæt, nogen er supersæt af JSE. Desuden har mange firmaer og organisationer deres egen distribution af java, f.eks. IBM, Apple, Apache, Debian, etc... Alt sammen "blessed by Oracle".

Om du vil kalde alt dette "egen version" er op til dig. En del af problemet her er, at når folk kaster ordet Java omkring, snakker de om vidt forskellige ting: Måske et programmeringssprog, måske et klassebibliotek, måsket et sæt API'er, måske et VM, etc... Grunden til at jeg siger at Google ikke har lavet "deres egen version" af Java er, at de ikke, ligesom Microsoft gjorde i sin tid (og blev dømt for), har lavet vold på java, ved at indføre inkompatible ændringer. De har blot defineret, om du vil, et specifikt subsæt af java som kan bruges til Android, præcis som Oracle har med JME, etc.

Google har defineret det subsæt af java (den addition) som skal bruges til Android, hvor der er udeladt forskellige ting som ikke giver mening, f.eks. Swing. Fuldstændigt på samme måde som Oracle har deres JME. Det som det handler om er, at Oracle er pissed fordi at Android er blevet en success, uden at de har brugt deres (Oracle's) JME, men har lavet noget der var bedre, og Oracle har ikke fået penge (enhver der kender Oracle ved at det handler om én eneste ting: penge).

Og så vidt jeg husker går en del af sagen på at dalvik indeholder kode kopieret fra jvm samt krænker sun/oracles patenter. Hvis disse påstande holder, er tingene vist ikke så sort/hvide som forklaret her.

Så vidt jeg er up-to-date med sagen nu (check groklaw.net) handler sagen nu om, at Oracle mener de har copyright på java api'er, at der er kopieret 9 liniers kode fra en fil (som ikke længere findes), og at de har et par patenter som de mener Google overtræder. Dalvik er et fuldstændigt nyt VM, skrevet fra bunden til Android, og har intet med Java, Sun eller Oracle at gøre.

Så snart der er advokater involveret, er intet sort-hvidt. Grunden til at jeg skrev mit indlæg er, at jeg synes artiklen er misvisende, da det første indtryk den sagesløse læser vil få er, at Android bruger en eller anden variant af Java sproget, som Google har kogt sammen, hvilket ikke er korrekt.

  • 8
  • 0
#7 Nikolaj Brinch Jørgensen

. IBM, Apple, Apache, Debian, etc... Alt sammen "blessed by Oracle".

Debian? Kører den ikke Sun Java? (OpenJDK m.fl.)? De andre (inklusive BEA JRockit, HP osv., eksklusive Apache) er alle Java, da de er lavet med licens til Sun (de har gennemført TCK testen).

Apache Harmony er dermed ikke "blessed by Oracle" eller Sun. Men en clean room implementation af noget af Java (f.eks. er der ingen Applet support, så NemLogin kan man ikke foretage :-).

  • 1
  • 0
#9 Lars Bjerregaard

Apache Harmony er dermed ikke "blessed by Oracle" eller Sun. Men en clean room implementation af noget af Java (f.eks. er der ingen Applet support, så NemLogin kan man ikke foretage :-).

Fint nok. Den er så "blessed" i den udstrækning at Oracle ikke har noget imod den, hvilket gør det så meget mere "pudsigt", at de nu har noget imod Android, som de før roste til skyerne.

  • 0
  • 0
#10 Lars Bjerregaard

Hvordan er den sej? Så vidt jeg ved er den langsommere end både JRockit og Hotspot.

Den er sej pga. måderne den forsøger optimalt at løse problemet om, at køre på mobile enheder, med de ekstreme constraints der findes på sådan nogen. JRockit og Hotspot har intet med mobil at gøre, og der er meget store forskelle på at køre på en desktop, server eller mobil enhed. Check videoen ud og dan din egen mening.

  • 0
  • 0
#11 Nikolaj Brinch Jørgensen

Fint nok. Den er så "blessed" i den udstrækning at Oracle ikke har noget imod den, hvilket gør det så meget mere "pudsigt", at de nu har noget imod Android, som de før roste til skyerne.

Det siger da sig selv. Android bevæger sig jo ind på et marked som Oracle ejer, nemlig Java på mobilen. Apache Harmony bevæger sig ingen steder for der er en hel masse software den ikke kan afvikle. Desuden har Oracle/Sun jo forhindret at den nogensinde bliver til "Java". Derudover er Apache Harmony en cleanroom implementation, hvor Google påstår, at Android har kopieret kodeelementer fra Sun JDK. Så der er meget stor forskel på hvorfor den ene er blessed, og den anden ikke er.

  • 0
  • 0
#12 Nikolaj Brinch Jørgensen
  • 0
  • 0
#14 Baldur Norddahl

Det viser sig at de 9 linjer kommer fra Google kode som er blevet doneret til Sun. Så de har faktisk sagsøgt Google for at kopiere deres egen kode...

Ok, det er faktisk skete var det her, i dommerens egne ord:

Oracle has made much of nine lines of code that crept into both Android and Java. This circumstance is so innocuous and overblown by Oracle that the actual facts, as found herein by the judge, will be set forth below for the benefit of the court of appeals.

Dr. Joshua Bloch worked at Sun from August 1996 through July 2004, eventually holding the title of distinguished engineer. While working at Sun, Dr. Bloch wrote a nine-line code for a function called “rangeCheck,” which was put into a larger file, “Arrays.java,” which was part of the class library for the 37 API packages at issue. The function of rangeCheck was to check the range of a list of values before sorting the list. This was a very simple function. In 2004, Dr. Bloch left Sun to work at Google, where he came to be the “chief Java architect” and “Java guru.” Around 2007, Dr. Bloch wrote the files, “Timsort.java” and “ComparableTimsort,” both of which included the same rangeCheck function he wrote while at Sun. He wrote the Timsort files in his own spare time and not as part of any Google project. He planned to contribute Timsort and ComparableTimsort back to the Java community by submitting his code to an open implementation of the Java platform, OpenJDK, which was controlled by Sun. Dr. Bloch did, in fact, contribute his Timsort file to OpenJDK and Sun included Timsort as part of its Java J2SE 5.0 release.

In 2009, Dr. Bloch worked on Google’s Android project for approximately one year. While working on the Android team, Dr. Bloch also contributed Timsort and ComparableTimsort to the Android platform. Thus, the nine-line rangeCheck function was copied into Google’s Android. This was how the infringement happened to occur.

When discovered, the rangeCheck lines were taken out of the then-current version of Android over a year ago. The rangeCheck block of code appeared in a class containing 3,179 lines of code. This was an innocent and inconsequential instance of copying in the context of a massive number of lines of code.

Citatet er fra dommen.

  • 2
  • 0
Log ind eller Opret konto for at kommentere