groups 2010.02: offenheit des android-betriebssystems (digital sustainability)
DESCRIPTION
Offenheit des Android-Betriebssystems Bericht von Michael Single, Pascal Zimmermann, Severin HeinigerTRANSCRIPT
Wie offen ist Android?
Michael Single ∗ Pascal Zimmermann † Severin Heiniger ‡
14. November 2010, ETH Zurich
Dieser Bericht entstand im Rahmen der Vorlesung Digitale Nachhaltigkeit in der
Wissensgesellschaft bei Marcus M. Dapp. Er darf gemass folgender Creative Commons-
Lizenz verwendet werden: CC-BY-SA http://creativecommons.org/licenses/by-sa/3.0/
Inhaltsverzeichnis
1 Einfuhrung 1
1.1 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Geschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Architektur 4
2.1 Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Dalvik Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1 Oracle-Klage . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Anwendungs-Framework . . . . . . . . . . . . . . . . . . . . . . 7
3 Offenheit 7
3.1 Lizenzierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Beurteilung der Lizenzwahl . . . . . . . . . . . . . . . . 10
3.2 Entwicklungsprozess . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1 Private Code-Zweige . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Mitarbeit durch externe Entwickler . . . . . . . . . . . . 13
3.2.3 Beitrag zur Kernel-Entwicklung . . . . . . . . . . . . . . 14
3.3 Drittparteien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.1 Mobilfunkbetreiber . . . . . . . . . . . . . . . . . . . . . 15
3.3.2 Hardware-Hersteller . . . . . . . . . . . . . . . . . . . . . 17
3.3.3 Anwendungsentwickler . . . . . . . . . . . . . . . . . . . 18
3.4 Konsumenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4 Vergleich zu anderen Betriebssystemen 21
4.1 Apple iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 MeeGo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1 Lizenzierung . . . . . . . . . . . . . . . . . . . . . . . . . 24
5 Fazit 25
1 Einfuhrung
1 Einfuhrung
In nur zwei Jahrzehnten haben Mobiltelefone eine immense Verbreitung erfah-
ren und sind heute fur viele Menschen unverzichtbarer Bestandteil ihres Le-
bens als Mittel zur mobilen Kommunikation, Unterhaltung und Informations-
beschaffung. Angetrieben durch den technologischen Fortschritt, insbesondere
der Miniaturisierung und zunehmender Leistungsfahigkeit von Prozessoren, so-
wie des breitflachigen, mobilen Zugangs zum Internet, ist in den vergangenen
vier Jahren eine neue Generation von Mobiltelefonen in Erscheinung getreten.
Die Rede ist von Smartphones, die sich im Gegensatz zu herkommlichen Fea-
turephones durch bessere Hardware und fortschrittliche Betriebssysteme aus-
zeichnen, die es dem Benutzer ermoglichen, durch die Installation von Anwen-
dungen das Gerat den personlichen Bedurfnissen anzupassen.
Der Lancierung des iPhones durch Apple Inc. im Jahr 2007 folgte bald die
Ankundigung des plattformubergreifenden, mobilen Betriebssystems Android
durch Google. Mittlerweile stellt dieses einen ernst zu nehmenden Bestreiter
im Markt dar, bemuht um die Gunst der Hardware-Hersteller, Anwendungs-
entwickler und nicht zuletzt der Konsumenten. Weitere konkurrierende mobile
Betriebssysteme sind Nokias Symbian, webOS von Palm, das in Zusammen-
arbeit von Nokia und Intel entwickelte MeeGo und Windows Mobile aus dem
Hause Microsoft. In den USA stellen Smartphones inzwischen das am schnells-
ten wachsende Segment im Mobiltelefon-Markt dar.1 Die gegenwartigen Ver-
kaufszahlen der verschiedenen mobilen Betriebssysteme lassen sich Tabelle 1
entnehmen.
Durch die zunehmende Bedeutung von Smartphones im Alltag wachst auch der
Einfluss der entsprechenden Hersteller mobiler Betriebssysteme. Konsumenten
vertrauen den Geraten personliche Informationen an und technisch versierte
Parteien haben das Bedurfnis, auf solchen Plattformen aufbauend neue Diens-
te zu realisieren oder die Plattformen selbst zu verbessern. Es kommt daher die
Frage auf, ob und in welcher Weise diese Hersteller Kontrolle uber ihr Produkt
1http://www.android.com/
1
1 Einfuhrung
Betriebssystem 3. Quartal 2010 % 3. Quartal 2009 %Symbian 29’480.1 36.6 18’314.8 44.6Android 20’500.0 25.5 1’424.5 3.5iOS 13’484.4 16.7 7’040.4 17.1BlackBerry 11’908.3 14.8 8’522.7 20.7Windows Mobile 2’247.9 2.8 3’259.9 7.9Linux 1’697.1 2.1 1’918.5 4.7Andere 1’214.8 1.5 612.5 1.5Total 80’532.6 100 41’093.3 100
Tabelle 1: Weltweite Verkaufe von Smartphones geordnet nach Betriebssyste-men. Quelle: http://www.gartner.com/it/page.jsp?id=1466313
ausuben und dadurch Konsumenten und Entwickler in ihren Moglichkeiten be-
schrankt werden. Die vorliegende Arbeit hat das Ziel, dieser Frage mit Fokus
auf Android nachzugehen und aufzuzeigen, ob sich die verschiedenen Plattfor-
men diesbezuglich wesentlich unterscheiden.
1.1 Gliederung
Nach einem Uberblick der wichtigsten geschichtlichen Ereignisse im Bezug auf
Android beschreibt Kapitel 2 die der Android-Plattform zu Grunde liegenden
Technologien, deren Ursprung und Bedeutung. Diese Grundlagen sind dann im
Kapitel 3 von Bedeutung, in welchem der eigentlichen Fragestellung auf den
Grund gegangen wird, indem die Lizenzsituation von Android, die Organisa-
tion der Weiterentwicklung der Plattform und die Einflussnahme von Mobil-
funkbetreibern, Hardware-Herstellern und Anwendungsentwicklern beschrie-
ben und beurteilt wird. Die dabei gewonnenen Erkenntnisse zu Android werden
dann im Kapitel 4 in Relation zu den konkurrierenden mobilen Betriebssyste-
men iOS und MeeGo gesetzt, was zum abschliessenden Fazit uberleitet.
1.2 Geschichte
Die Ubernahme des Unternehmens Android Inc. im Jahr 2005 durch Google
nahrte die Geruchte, dass der Suchmaschinenriese im Begriff war, den Mobil-
2
1 Einfuhrung
funkmarkt zu betreten, um so seine Dienste besser zuganglich zu machen.2
Das Startup-Unternehmen hatte bis dahin unter Verschluss an Software fur
Mobiltelefone gearbeitet.
Unter der Leitung von Google wurde Ende 2007 die Grundung der Open Hand-
set Alliance bekannt gegeben, einem Konsortium 34 grosser Unternehmen,
darunter Hersteller von Mobiltelefonen und Prozessoren, aber auch Software-
Unternehmen und Mobilfunkbetreiber. Bekannte Namen sind dabei China Mo-
bile, T-Mobile, eBay, Intel, nVidia, sowie HTC, LG, Motorola und Samsung.3
Als erklartes Ziel dieses Konsortiums wurde die Schaffung der Plattform An-
droid fur mobile Gerate angegeben, die durch ihre Offenheit die Kosten fur die
beteiligten Unternehmen senken und den technischen Fortschritt beschleunigen
sollte.
Die Veroffentlichung des Software Development Kit (SDK) fur Anwendungs-
entwickler folgte knapp ein Jahr spater und Google stellte den Code der auf
dem Linux-Kernel basierten Android-Plattform unter die Apache Software Li-
cense, eine Open-Source-Lizenz.4
Ende 2008 wurde mit dem HTC Dream (auch bekannt als T-Mobile G1 ) das
erste auf Android-basierte Mobiltelefon auf den Markt gebracht. Neue Versio-
nen von Android wurden in rascher Folge durch Google, dem fur die Weiter-
entwicklung primar verantwortlichen Unternehmen, veroffentlicht.
Gemass Google-CEO Eric Schmidt wurden im August 2010 200’000 Android-
Gerate pro Tag verkauft5, die von Dutzenden verschiedener Hardware-Hersteller
auf den Markt gebracht wurden.
2http://www.androidpolice.com/2010/07/29/meet-andy-android%E2%80%99s-history-in-a-nutshell/
3http://www.openhandsetalliance.com/4http://source.android.com/5http://www.wired.com/gadgetlab/2010/08/google-200000-android-phones/
3
2 Architektur
2 Architektur
Android wird von Google auch als Software-Stack bezeichnet.6 Dies ruhrt da-
her, dass sich das System aus mehreren Software-Schichten zusammensetzt,
wobei jede Schicht auf den jeweils darunterliegenden aufbaut und so eine zu-
nehmende Abstraktion erreicht wird. Der Android-Software-Stack ist in Ab-
bildung 1 schematisch dargestellt.
Abbildung 1: Software-Stack von Android.
Java-Bibliotheken
Dalvik Virtual Machine
Bibliotheken
Anwendungs-Framework
Anwendungen
Linux-Kernel
Insgesamt setzt sich die Android-Plattform aus mehr als 10 Millionen Zeilen
Code zusammen.7
2.1 Kernel
Die Grundlage von Android bildet der Linux-Kernel8 in Version 2.6. Seine
Aufgaben sind unter anderem die Speicher- und Energieverwaltung, sowie die
Hardware-Abstraktion durch passende Treiber.
Es ist aber erwahnenswert, dass die Android-Plattform wenig Gemeinsamkei-
ten mit dem herkommlichen Software-Stack hat, den man von Linux-basierten
6http://developer.android.com/guide/basics/what-is-android.html7http://www.gubatron.com/blog/2010/05/23/how-many-lines-of-code-does-it-take-to-
create-the-android-os/8http://www.linux.org/
4
2 Architektur
Desktop-Rechnern kennt. Insbesondere wurden durch Google weitreichende
Modifikationen am Kernel durchgefuhrt, wozu beispielsweise die Energiever-
waltung gehort, die bei mobilen Geraten von besonderer Bedeutung ist.9
2.2 Bibliotheken
Diese Schicht stellt einen Grossteil der grundlegenden Android-Funktionalitat
bereit. Diese meist in den Programmiersprachen C und C++ geschriebenen
Komponenten sind verantwortlich fur die Verarbeitung verschiedener Arten
von Daten. Dazu gehort eine Datenbank, 2D- und 3D-Grafikbibliotheken, Kom-
ponenten fur Bild-, Ton- und Videoverarbeitung und eine zur Darstellung von
Webseiten.10
Ein Grossteil dieser Komponenten wurde nicht von Mitgliedern der Open
Handset Alliance entwickelt, sondern existierte bereits vor der Entstehung von
Android als Open-Source-Software verschiedener Herkunft. Der Einsatz dieser
Software ermoglichte es Google, mit moderatem Aufwand Android mit den
entsprechenden Funktionalitaten auszustatten.
2.3 Dalvik Virtual Machine
Hohere Schichten im Software-Stack von Android sind in der Programmier-
sprache Java umgesetzt. Eine Virtual Machine bietet die Moglichkeit, Java-
Anwendungen unabhangig von den konkreten Eigenheiten der zu Grunde lie-
genden Hardware-Architektur und anderen Anwendungen auszufuhren. Absturze
von Anwendungen haben dadurch weniger gravierende Auswirkungen auf den
Rest des Systems und zudem wird die Speicherverwaltung vereinfacht.11
9http://mikeymorckos.googlecode.com/svn-history/r5/trunk/Presentations/androidmichaelmorckos may 13 09.pdf
10Im Detail handelt es sich um die Projekte SQLite, OpenGL, OpenCore, FreeType, Web-Kit und OpenSSL.
11http://electronics.howstuffworks.com/google-phone2.htm
5
2 Architektur
Anstelle einer konventionellen Java Virtual Machine (JVM) kommt bei An-
droid die Dalvik Virtual Machine12 zum Einsatz, die speziell fur Gerate mit
niedrigen Stromverbrauch und beschrankten Speicher- und Rechenkapazitaten
entwickelt wurde. Sie stellt daher eine der wichtigsten Komponenten von An-
droid dar.
Dalvik basiert auf einer Teilmenge der unter die Apache Software License ste-
henden Java-Implementierung Harmony13 der Apache Software Foundation.
2.3.1 Oracle-Klage
Nachdem Oracle im Januar 2010 Sun Microsystems ubernommen hat, gingen
insbesondere die Rechte an der von Sun entwickelten Java-Plattform an Oracle
uber. Das Unternehmen hat in der Folge eine Klage gegen Google eingereicht
mit der Begrundung, Google habe durch die Entwicklung von Dalvik in mehre-
ren Punkten wissentlich gegen das Patentrecht verstossen. Es soll zudem wis-
sentlich, gewollt und unrechtmassig ein erheblicher Anteil kopiergeschutzten
Codes kopiert, verandert und vertrieben worden sein. Dadurch seien Oracles
Exklusivrechte verletzt und der Firma finanzielle Schaden zugefugt worden,
wahrend Google profitierte. Dabei sollen auch fruhere Sun-Mitarbeiter einge-
stellt worden sein, um an Dalvik zu arbeiten.14
Google wertet die Klage als Angriff auf die Java-Open-Source-Community.15
Der entsprechende Prozess hat noch nicht begonnen. Sofern das Gericht zu
Gunsten von Oracle entscheidet, mussten Anpassungen des Codes an beste-
hendes Recht gemacht werden, wahrend die Zahlung grosser Summen Scha-
densersatz durch Google fallig wurde.
12http://www.dalvikvm.com/13http://harmony.apache.org/14http://regmedia.co.uk/2010/08/13/oracle complaint against google.pdf15http://www.theregister.co.uk/2010/08/16/google oracle android lawsuit/
6
3 Offenheit
2.4 Anwendungs-Framework
Android-Anwendungen greifen weder direkt auf den Kernel zu, noch auf die
darauf aufbauenden Bibliotheken. Stattdessen gehort ein in Java realisiertes
Anwendungs-Framework zur Android-Plattform, das eine umfassende Schnitt-
stelle bietet und Anwendungen die Moglichkeit gibt, die Funktionalitat der
Plattform zu erweitern. Die hohe Abstraktion ermoglicht eine einfache Ver-
wendung.
Beispielsweise erlaubt es den Anwendungen konsistente grafische Oberflachen
umzusetzen, Daten untereinander auszutauschen, Telefonie-Funktionalitaten
zu verwenden und mit Hilfe von GPS-Daten standortbasierte Dienste zu rea-
lisieren.
Daruber hinaus sind bereits eine Reihe von grundlegenden Anwendungen in
Android enthalten, wozu ein E-Mail-Programm, ein Webbrowser, eine Kon-
taktverwaltung und ein Kalender zahlt.
3 Offenheit
Der Begriff der Offenheit ist ein zentrales Element in der Charakterisierung
von Android durch die Open Handset Alliance.
Mehrfach wird Android auf deren Homepage als “erste offene, vollstandige
und kostenlose Plattform fur mobile Gerate”16 bezeichnet. Android wird also
bewusst nicht als Produkt bezeichnet, das von einem einzelnen Unternehmen
entwickelt und vermarktet wird, sondern als Plattform, die durch Kooperation
verschiedener Parteien entsteht. Auf der Open-Source-Webseite von Android17
wird dies prominent dadurch begrundet, dass es in der Mobilfunkindustrie
keinen zentralen Punkt des Scheiterns geben sollte. Kein Unternehmen durfe
die Innovationen anderer einschranken und kontrollieren.
16first open, complete, and free platform created specifically for mobile devices17http://source.android.com/index.html
7
3 Offenheit
Die Open Handset Alliance gibt weiter an, dass sich jedes seiner Mitglieder fur
grossere Offenheit im mobilen Okosystem engagiere, da dies allen Parteien, die
auf Android setzen, zu schnellerer Innovation verhelfe und dadurch schneller
auf die Nachfrage der Kunden reagiert werden konne. Umgekehrt lasst sich das
so interpretieren, dass es Unternehmen, die nicht auf Android, sondern auf ge-
schlossene Eigenentwicklungen setzen, es eventuell schwerer haben, innovative
Produkte in nutzlicher Frist auf den Markt zu bringen.
Dadurch wird deutlich, dass das Ziel von Android ist, von moglichst vielen Un-
ternehmen in der Mobilfunkindustrie als Basis fur unterschiedlichste Produkte
und Dienste verwendet zu werden.18 Die Logik dahinter scheint zu sein, dass
eine starkere Android-Plattform noch mehr Unternehmen davon uberzeugt, die
Plattform zu adaptieren, um nicht als abseits stehende Partei den Anschluss
zu verlieren.
Die angeblichen Vorteile einer offenen Plattform fur die verschiedenen Parteien
in der Mobilfunkindustrie und nicht zuletzt der Konsumenten, werden wie folgt
beschrieben:19
• Konsumenten profitierten von gunstigeren und innovativen mobilen Geraten
und Diensten, insbesondere einer reichhaltigen Auswahl an Anwendun-
gen und einfacher zu bedienender Benutzeroberflachen.
• Betreiber von Mobilfunknetzen seien in der Lage, ihre Angebote flexibel
zu differenzieren und von tieferen Kosten zu profitieren.
• Hersteller von Mobiltelefonen hatten eine Kostenersparnis durch die weg-
fallenden Lizenzkosten fur Software. Nicht zuletzt verkurze Android die
Zeit, um neue Gerate auf den Markt zu bringen.
• Chip-Hersteller benotigen eine Software, die den zunehmenden Funk-
tionsreichtum ihrer Produkte nutzen kann und so Anwendungsentwick-
lern zuganglich macht.
18http://www.youtube.com/watch?v=7Y4thikv-OM19http://www.openhandsetalliance.com/oha faq.html
8
3 Offenheit
• Software-Unternehmen seien in der Lage, ihre Produkte in eine vollstandige
Plattform zu integrieren, und Hersteller von Mobiltelefonen hatten durch
die wegfallenden Software-Lizenzkosten mehr Ressourcen, um solche Pro-
dukte zu erwerben.
• Anwendungsentwickler hatten Zugriff auf eine reichhaltige API, was zu
hoherer Produktivitat und Innovation fuhre.
Die Frage, die sich nun stellt, ist, welche Formen diese von der Open Handset
Alliance lautstark propagierten Offenheit von Android im Detail hat und ob
und inwiefern einzelne Unternehmen, allen voran Google als treibende Kraft
bei der Weiterentwicklung der Android-Plattform, trotzdem die Kontrolle uber
verschiedene Aspekte der Plattform fur sich beanspruchen.
Hierzu beleuchten die folgenden Abschnitte die Art und Weise der Lizenzie-
rung von Android, den Entwicklungsprozess, sowie den Einfluss von anderen
Unternehmen auf die Offenheit von Android.
3.1 Lizenzierung
Der grosste Teil des Android-Projektes steht unter der Apache Software Licen-
se 2.020 die auf der Homepage von Android auch explizit als bevorzugte Lizenz
angegeben wird.21
Die Apache Software License (kurz ASL) ist eine Open-Source-Lizenz der
Apache Software Foundation. Die Version 2.0 wurde im Jahr 2004 heraus-
gegeben. Eine unter der ASL lizenzierte Software darf verwendet, weiterentwi-
ckelt und vertrieben werden, wobei eigene Copyright-Zusatze angefugt werden
durfen. Zudem enthalt die Lizenz keine Copyleft-Klausel, die erfordern wurde,
dass Anderungen nur unter gleichen Lizenzbedingungen weitergegeben werden
durfen.
20http://www.apache.org/licenses/LICENSE-2.0.html21http://source.android.com/source/licenses.html
9
3 Offenheit
3.1.1 Beurteilung der Lizenzwahl22
Google begrundet die Wahl der Apache Lizenz damit, dass die Entwickler frei
sein sollen, zu bestimmen, wie ihre Software vertrieben werden soll. Dies werde
durch das Fehlen der Copyleft-Klausel erreicht und gewahre den Entwicklern
von proprietarer Software den fur ihre Geschaftsmodelle notigen Spielraum,
was insbesondere die kommerzielle Entwicklung fordere.
Nur ein kleiner Teil von Android steht unter einer anderen Lizenz. Dazu gehort
beispielsweise der Linux-Kernel, der unter der GNU General Public License23
(GPL) in Version 2 lizenziert ist. Deren Copyleft-Klausel verbietet die Verwen-
dung des Codes in proprietaren Programmen. Dies hat zur Folge, dass jegliche
Anderungen am Kernel von Google und anderen Unternehmen ebenfalls ent-
sprechend lizenziert werden mussen. Zu diesem Zweck hat der Hardwareher-
steller HTC eine eigene Website24 geschaffen. Von dieser kann der Code der
Kernel-Versionen, welche in seinen Produkten zum Einsatz kommt, bezogen
werden.
Die Copyleft-Klausel der GPL betrifft nicht Anwendungen, die mit Hilfe des
Kernels ausgefuhrt werden, da diese primar mit dem Nutzer des Systems in-
teragieren (d.h. im sogenannten Usermode ausgefuhrt werden). Anwendungen
konnen daher trotz der GPL-Lizenzierung des Kernels unter einer beliebigen
Lizenz stehen.25 Enthielten aber hohere Schichten des Android-Software-Stacks
GPL-lizenzierten Code, wurde dort die Copyleft-Klausel wirksam werden. Es
erstaunt daher nicht, dass Google dort konsequent die Verwendung von GPL-
lizenziertem Code vermeidet. Das zeigt sich insbesondere darin, dass das Un-
ternehmen von Grund auf eine Alternative zur GPL-lizenzierten Bibliothek
libc26 entwickelt hat, obwohl jene grosse Akzeptanz geniesst. Auch hat Google
Apache Harmony den Vorzug gegenuber der freien, GPL-lizenzierten Java-
22http://www.openhandsetalliance.com/android faq.html23http://www.gnu.de/documents/gpl-2.0.de.html24http://developer.htc.com/25http://itmanagement.earthweb.com/osrc/article.php/12068 3801396 3/Bruce-Perens-
Combining-GPL-and-Proprietary-Software.htm26http://www.gnu.org/software/libc/
10
3 Offenheit
Implementierung OpenJDK27 gegeben.28
Im Gegensatz zur General Public License erlaubt die Lesser General Public
License, dass unter dieser Lizenz stehende Bibliotheken auch in proprietarer
Software verwendet werden durfen.29 Google lehnt deren Verwendung jedoch
ab, um Unternehmen, die auf Android basierte Produkte verkaufen, nicht
zusatzliche Einschrankungen30 auferlegen zu mussen.
3.2 Entwicklungsprozess
Es wurde bereits erwahnt, dass der Quellcode von Android offen unter einer
Open Source-Lizenz verfugbar ist. Fur diesen Zweck wurde eine Website An-
droid Open Source Project31 durch Google ins Leben gerufen. Sie beschreibt,
wie interessierte Entwickler an den Quellcode der Software herankommen und
Beitrage leisten konnen, und wie Hardware-Hersteller die Plattform zum Lau-
fen bringen und die Kompatibilitat sicherstellen konnen.
Die Tatsache, dass Android Open Source ist, garantiert zwar, dass der Quell-
code frei verfugbar sein muss, kopiert und verandert werden darf. Jedoch sagt
dies nichts aus uber den Quellcode von zukunftigen Android-Versionen, die
sich noch in Entwicklung befinden. Auch gibt es nicht beliebigen Personen das
Recht, Anderungen am offiziellen Quellcode von Android vorzunehmen - etwa,
um Verbesserungen oder Fehlerkorrekturen anzubringen.
27http://openjdk.java.net/28http://arstechnica.com/open-source/reviews/2009/02/an-introduction-to-google-
android-for-developers.ars/329http://www.gnu.org/licenses/lgpl.html30Beispielsweise erfordert die Verwendung LGPL-lizenzierter Bibliotheken, dass der
Code ebenfalls offen ist, oder aber die Bibliothek durch den Benutzer ausge-tauscht werden kann. Dies stellt ein Problem dar, da Android-Software oft alsGanzes ausgeliefert wird. Auch sog. Reverse Engineering ist ausdrucklich erlaubt.http://source.android.com/source/licenses.html
31http://source.android.com
11
3 Offenheit
3.2.1 Private Code-Zweige
Die Entwicklung von Android erfolgt nicht sequentiell, sondern gleichzeitig in
mehreren sogenannten Code Lines (auch Zweige genannt), so dass der Code
der aktuell stabilen Version von Android von dem potentiell instabilen der
zukunftigen Version getrennt wird.32
Die Code Line der zukunftigen Version halt Google aber unter Verschluss.
Der entsprechende Code wird erst als Ganzes mit dieser zukunftigen Ver-
sion veroffentlicht. Als Grund dafur wird angegeben, damit den Fokus der
Offentlichkeit auf die aktuelle Version zu lenken. Gleichzeitig behalt sich da-
durch Google das Recht vor, die strategische Richtung von Android als Platt-
form zu bestimmen. Dadurch konne sich Google auf eine kleine Anzahl von
Geraten konzentrieren, um die Weiterentwicklung voranzutreiben, aber auch
um mit Android verwandtes geistiges Eigentum zu schutzen. Insbesondere sei
Google manchmal im Besitz vertraulicher Informationen von Drittunterneh-
men, die rechtlich noch nicht angemessen geschutzt seien.
Der nicht erwahnte, aber entscheidende Grund fur diese Politik ist aber wahr-
scheinlich ein anderer. Innovationen geschehen in diesem hart umkampften
Markt so schnell, dass es sich kein Anbieter leisten kann, seine mittel- und
langerfristigen Plane (sogenannte Roadmaps) der Offentlichkeit kund zu tun,
um der Konkurrenz nicht einen unnotigen Vorteil zu geben. Beispielsweise
erfahrt die Offentlichkeit erst kurz vor dem Verkaufsstart neuer Versionen von
Apples iPhone uber dessen Neuerungen. Darum erscheint es nur konsequent,
dass neben den privaten Code-Zweigen von Android keine Informationen uber
Zukunftsplane im Voraus preis gegeben werden.
Von diesem Ausschluss sind explizit also nicht nur Entwickler von Anwen-
dungen betroffen, sondern auch Personen, die Beitrage zum Code von Android
leisten. Ausser fur ausgewahlte Partnerunternehmen besteht fur externe Perso-
nen also keine Moglichkeit der direkten Einflussnahme auf bzw. Einsicht in die
zukunftige Versionen von Android. Da neue Versionen im Abstand von durch-
32http://source.android.com/source/code-lines.html
12
3 Offenheit
schnittlich 6 Monaten erscheinen33, hinken solche Personen also dem aktuellen
Entwicklungsstand bis zu 6 Monate hinterher. Google erkennt immerhin an,
dass diese Politik nicht allen Beitragenden gefallt, hat aber keine Absicht, diese
in Zukunft zu andern.
In der Anfangsphase des Projekts wurden neue Versionen des SDK mit gros-
ser Verzogerung und technischen Mangeln freigegeben. Zeitweise erhielten nur
die Finalisten eines Programmierwettbewerbs unter Unterzeichnung eines Ge-
heimhaltungsvertrags Zugang.34 Dies fuhrte zu einer gewissen Frustration bei
einem Grossteil der Entwickler, die sich neu mit der Plattform beschaftigen,
aber auch bei einigen Google-Mitarbeitenden. Als Reaktion wurde von einem
Entwickler eine Petition35 gestartet, mit dem Ziel, Google zur Behebung die-
ser Missstande zu bewegen, da die Entwickler die Grundlage des Erfolges einer
solchen Plattform seien.
3.2.2 Mitarbeit durch externe Entwickler
Obwohl Google hauptverantwortlich fur den Entwicklungsprozess von Android
ist, werden Beitrage (Ideen, Code, Dokumentation und Fehlerberichte) von
ausserhalb der Firma akzeptiert. Insbesondere stehen mit Mailinglisten und
Chat-Kanalen die notigen Kommunikationsmittel zur Verfugung.
Von solchen Personen bzw. Unternehmen wird verlangt, online einen so ge-
nannten Individual bzw. Corporate Contributor License Grant zu unterschreiben.36
Damit soll die rechtliche Situation geklart werden. Dadurch wird dem Android-
Projekt zum Beispiel die weltweite, nicht-exklusive und kostenfreie Lizenz er-
teilt, die Beitrage zu verwenden.
Bevor ein Beitrag von externen Entwicklern in das Projekt einfliessen kann,
muss er gepruft und akzeptiert werden. Dies geschieht durch die sogenannten
33http://en.wikipedia.org/wiki/Android (operating system)#Update history34http://arstechnica.com/open-source/reviews/2009/02/an-introduction-to-google-
android-for-developers.ars/335http://groups.google.com/group/android-discuss/browse thread/thread/
957fa043e2a199b6?hl=en&pli=136http://source.android.com/source/licenses.html
13
3 Offenheit
Approvers, erfahrenen Mitglieder des Projekts, die in der Vergangenheit um-
fangreiche Beitrage gemacht haben. Es wird Kritik geubt an der Tatsache, dass
diese normalerweise selber Google-Mitarbeiter37 seien und angeblich manche
Beitrage ohne Begrundung abgelehnt wurden.38
3.2.3 Beitrag zur Kernel-Entwicklung
Wie bereits erwahnt, baut die Android-Plattform auf verschiedener Software
auf, die unabhangig von Android entwickelt wird, insbesondere dem Linux-
Kernel. Man bezeichnet diese Software auch als Upstream.39 Da in Android
zahlreiche Veranderungen daran vorgenommen wurden, stellt sich die Frage,
ob und in welchem Rahmen diese in die ursprunglichen Projekte zuruckfliessen,
so dass letztlich alle davon profitieren wurden, die die jeweilige Software ver-
wenden.
Diese Praktik wird von den gangigen Open-Source-Lizenzen in keiner Wei-
se gefordert oder empfohlen. Abgeleitete Werke (derived works) sind explizit
erlaubt. Trotzdem ist es der Welt von Open-Source-Software ublich, Verbesse-
rungen wenn moglich dem Upstream zukommen zu lassen. Die Unterlassung
davon wird auch als Forking40 bezeichnet.
Forking hat den Nachteil, dass neue Versionen der ursprunglichen Software nur
mit beachtlichem Aufwand in die eigene Codebasis integriert werden konnen,
da die eigenen Anderungen erhalten bleiben mussen. Werden Anderungen hin-
gegen in den Upstream-Code integriert, werden diese in der nachsten Version
bereits enthalten sein, und der Aufwand zum Aktualisieren bleibt gering.
Google hat seine Anderungen am Code des Linux-Kernels in den Staging-
Zweig eingefugt, in dem Code so lange aufbewahrt wird, bis er genugend sta-
bil fur den offiziellen Code-Zweig des Kernels (Mainline) ist. Jedoch wurde
Anfang 2010 dieser Code jedoch von Kernel-Entwicklern aus dem Staging-
37http://source.android.com/faqs.html38http://www.visionmobile.com/blog/2010/04/is-android-evil/39http://en.wikipedia.org/wiki/Upstream (software development)40http://en.wikipedia.org/wiki/Fork (software development)
14
3 Offenheit
Bereich geloscht. Der Kernel-Entwickler Greg Kroah-Hartmann begrundete41
diesen Entscheid damit, dass Google den Code nicht betreut habe. Der Rest des
Linux-Okosystems wurde daher nie von diesen Anderungen (und Beitragen von
Hardwareherstellern, die davon abhangen) profitieren konnen und Google habe
somit faktisch ein Fork des Linux-Kernels geschaffen. An der Linux-Konferenz
Mitte April 2010 versprach ein Google-Mitarbeiter aber Besserung.42
Eine ahnliche Situation ergab sich mit Dalvik, das auch dem Apache-Projekt
Harmony basiert. Wahrend Google den Marktstart des ersten Android-basierten
Gerats vorzubereiten, seien die zwei Codebasen immer starker voneinander ab-
gewichen. Spater habe Google dann versucht, diese Lucke wieder zu verkleinern
und Verbesserungen in Dalvik an das Harmony-Projekt zuruckzugeben.43
3.3 Drittparteien
Dass Google weder Hardware herstellt, noch Mobilfunknetze betreibt und die
vielfaltigen Wunsche von Konsumenten alleine befriedigen kann, sind Dritt-
unternehmen fur den Erfolg und Misserfolg der Android-Plattform ebenso zen-
tral.
3.3.1 Mobilfunkbetreiber
Konsumenten beziehen mobile Gerate in der Regel von Mobilfunkbetreibern.
Zwar hat Google den Direktvertrieb des Gerats namens Nexus One versucht,
doch diese Bestrebungen wurden im Juli 2010 mangels Nachfrage eingestellt.44
Durch die im Kapitel 3.1 beschrieben Lizenz-Bedingungen ist es den Mo-
bilfunkbetreibern moglich, weitreichende proprietare Modifikationen an der
Android-Software anzubringen und die Gerate mit zusatzlicher, vorinstallierter
41http://www.kroah.com/log/linux/android-kernel-problems.html?seemore=y42http://www.zdnet.com/blog/open-source/dibona-google-will-hire-two-android-coders-
to-work-with-kernelorg/627443http://arstechnica.com/open-source/reviews/2009/02/an-introduction-to-google-
android-for-developers.ars/244http://googleblog.blogspot.com/2010/05/nexus-one-changes-in-availability.html
15
3 Offenheit
Software auszuliefern. Dies geschieht einerseits aus dem Bestreben heraus, sich
von der Konkurrenz abzusetzen, aber auch davon, durch zusatzliche Dienste
Umsatz zu generieren.
Insbesondere von Branchenkennern wird kritisiert45, dass diese Software oft
von schlechter Qualitat ist, nur von wenigen Konsumenten gewunscht werde
und oft nicht einmal deinstalliert werden konne. Solche Software wird daher
auch salopp als Bloat- bzw. Crapware bezeichnet.
Eine weitere Moglichkeit der Einflussnahme durch Mobilfunkbetreiber ist die
Einfuhrung von Beschrankungen. Kunden des Unternehmens AT&T ist es
nicht einmal gestattet, Anwendungen zu installieren, die nicht aus dem An-
droid Market stammen.46 Als weiteres Beispiel sei das sogenannte Tethering
erwahnt. Diese neue Funktion von Android 2.2 ermoglicht es, ein Android-
Gerat als mobilen Hotspot zu betreiben, so dass sich in der Nahe befindliche
Gerate ebenfalls Internetzugang erhalten konnen. Mobilfunkbetreiber konnen
diese Funktion nach Belieben sperren. Des Weiteren erlaubte die erste Version
der Internettelefonie-Software Skype fur Android auf Verizon47-Geraten keine
kostenlosen Gesprache, obwohl dies die wichtigste Funktion der Anwendung
darstellt.
Ein weiterer Kritikpunkt ist, dass die Mobilfunkbetreiber die Kontrolle daruber
haben, ob und wann neue Versionen von Android an bereits verkaufte Gerate
ausgeliefert werden. Dies kann als Grund gesehen werden, warum auch ein
halbes Jahr nach Erscheinen der Version 2.2 immer noch zwei Drittel der Kon-
sumenten eine altere Version verwendeten.48 Es ist naheliegend, dass Mobil-
funkbetreiber lieber neue Gerate und Abonnemente verkaufen, als bestehenden
Kunden einen Gefallen zu tun.
Zusammenfassend lasst sich sagen, dass die Mobilfunkbetreiber durchaus von
der Offenheit von Android profitieren, aber diese infolge von Eigeninteres-
sen, die primar finanzieller Natur sind, nur beschrankt an ihre Konsumenten
45http://techcrunch.com/2010/09/09/android-open/46http://www.tuaw.com/2010/11/08/dissecting-androids-openness/47Ein grosser Mobilfunkbetreiber in den USA48http://developer.android.com/resources/dashboard/platform-versions.html
16
3 Offenheit
weitergeben. Dieser Gegensatz in angeblich in den Vereinigten Staaten noch
deutlicher zu spuren als in Europa.49
3.3.2 Hardware-Hersteller
Seit der Lancierung der Android-Plattform ist die Anzahl der Unternehmen,
die Android-Gerate produzieren, deutlich gestiegen. Zu den namhaftesten Un-
ternehmen zahlen HTC, Dell, Motorola, Samsung und LG.50
Das hat zur Folge, dass Konsumenten eine wachsende Anzahl Wahlmoglichkeiten
haben. Jedoch ist dies nicht direkt ein Indiz fur die Offenheit der Plattform,
da beispielsweise auch das Betriebssystem Windows Phone auf Geraten von
unterschiedlichen Herstellern verfugbar ist. Immerhin fuhrt Konkurrenzdruck
aber zu einem Preisverfall im Sinne der Konsumenten.51
Genau wie bei den Mobilfunkbetreibern ist auch fur Hardwarehersteller die
Diversifizierung ein wichtiges Thema. HTC vermarktet seine weitreichenden
Anderungen an der Benutzeroberflache von Android HTC Sense. Diese ist
proprietar, was aber im Einklang mit den Lizenzbestimmungen von Android
ist.
Wahrend der Entwicklung der vergangenen Versionen von Android hat Goo-
gle jeweils exklusiv mit ausgewahlten Partnerunternehmen wie HTC und Mo-
torola zusammengearbeitet, was diesen einen wettbewerbstechnischen Vorteil
gegenuber anderen Unternehmen gegeben hat.52
Obwohl die Apache Software License beliebige Anderungen an der Android-
Plattform erlaubt, wurden Hardwareherstellern (aber auch Mobilfunkbetrei-
bern) gewisse Beschrankungen auferlegt, sofern diese ihre Produkte unter Ver-
wendung des Markennamens “Android” vermarkten wollen. Zum Android Open
Source Project gehort zu diesem Zweck ein Android Compatibility Program, das
49http://www.osnews.com/story/23789/Android Not Open Wait What50http://en.wikipedia.org/wiki/List of Android devices51http://blog.zentity.com/2010/09/the-android-openness-delusion/52http://seekingalpha.com/article/173363-android-handset-makers-are-at-google-s-mercy
17
3 Offenheit
genau vorgibt, welche Kriterien Gerate erfullen mussen, um als Android com-
patible gelten zu durfen.53 Geraten, die diese nicht erfullen, steht insbesondere
der Android Market nicht offen.54 Als Grund fur diese Einschrankungen wird
angegeben, dass unkontrollierte Anpassungen zu inkompatiblen Implementa-
tionen fuhren konnen. Das konne sich zum Beispiel dadurch aussern, dass nicht
alle Android-Anwendungen auf einem Gerat lauffahig sind.
3.3.3 Anwendungsentwickler
Die Masse und Qualitat von Anwendungen, die fur ein mobiles Betriebssystem
verfugbar sind, gehort zu den entscheidenden Faktoren fur den Erfolg einer
solchen Plattform, da Konsumenten damit die Grundfunktionalitaten eines
entsprechenden Gerats nach Belieben erweitern konnen. Mit Hilfe des Software
Development Kits (SDK) (siehe Kapitel 2.4) konnen Anwendungsentwickler
kostenlos eigene Anwendungen bauen und auf ihren Geraten testen.
Jedoch braucht es einen Kanal, uber den solche Anwendungen zu den Kon-
sumenten gelangen konnen. Hierzu dient primar der Android Market. Dies
ist ein proprietarer Dienst von Google, den Hardware-Hersteller nur mit Ein-
verstandnis von Google auf ihren Android-Geraten anbieten durfen.55 Im No-
vember 2010 enthielt der Android Market ungefahr 160’000 Anwendungen.56
Ein Anwendungsentwickler kann selbst entscheiden, ob er fur seine Anwendun-
gen Geld verlangen mochten oder nicht. In ersterem Fall erhalt dieser aber nur
70 % des Verkaufspreises, wahrend der Rest an die Mobilfunkbetreiber und die
Unternehmen, die die Zahlungen abwickeln, verteilt wird.57
Anwendungen mussen aber nicht unbedingt uber den Android Market vertrie-
ben werden. Diese konnen vom Entwickler direkt zum Herunterladen angebo-
ten werden oder uber Dienste wie SlideMe verteilt werden.58 Auf den ersten
53http://source.android.com/about/philosophy.html54http://source.android.com/compatibility/index.html55http://www.visionmobile.com/blog/2010/04/is-android-evil/56http://www.androlib.com/appstats.aspx57http://en.wikipedia.org/wiki/Android Market58http://slideme.org/
18
3 Offenheit
Blick scheint dies ein klares Indiz fur die Offenheit von Android zu sein. Aller-
dings ist die manuelle Installation von Anwendungen technisch anspruchsvoll59
und wegen der Non-Compete-Klausel im Android Market Developer Distributi-
on Agreement60 ist es nicht erlaubt, uber den Android Market selbst konkurrie-
rende Dienste zu bewerben.61 Dies macht den Android Market zur dominanten
Plattform fur den Vertrieb von Android-Anwendungen.
Es stellt sich die Frage, ob und inwiefern Google Kontrolle uber die im An-
droid Market vertriebenen Anwendungen ausubt. Das Android Market Devel-
oper Distribution Agreement gibt eine Liste von Kriterien vor, die zu vertrei-
bende Android-Anwendungen erfullen mussen. Google beabsichtige nicht zu
uberprufen, ob diese erfullt werden. Sollte Google jedoch uber eine Verletzung
der Kriterien62 informiert werden, behalte sich das Unternehmen das Recht
vor, entsprechende Anwendungen aus dem Android Market zu entfernen und
den Entwickler gegebenenfalls zu sperren.
Google hat von dieser Moglichkeit bereits Gebrauch gemacht: Im Fruhling
2009 wurde von Google eine Tethering-Anwendung (siehe Kapitel 3.3.1) aus
dem Android-Markt entfernt und spater fur alle Kunden ausser denjenigen des
Mobilfunkbetreibers T-Mobile USA wieder freigegeben. Diese Beschrankung
wurde rund ein Jahr spater aufgehoben.63
Anwendungsentwickler haben durch den SDK die Moglichkeit, auch grund-
legende Funktionalitaten des Betriebssystems in ihren Anwendungen anzu-
bieten. Dazu gehort beispielsweise die grafische Software fur Telefonie, SMS-
und E-Mail-Versand. In anderen Worten sind in Android alle Anwendungen
gleichberechtigt.64 Aus technischer Sicht spricht dies fur die Offenheit von An-
droid.
59http://www.softsailor.com/how-to/49241-how-to-install-non-android-market-apk-apps-on-android-devices.html
60http://www.android.com/us/developer-distribution-agreement.html61“You may not use the Market to distribute or make available any Product whose primary
purpose is to facilitate the distribution of Products outside of the Market.”62Dazu gehort beispielsweise die Verletzung von Rechten bzgl. geistigen Eigentums, Ent-
halten von Schadcode, usw.63http://news.cnet.com/8301-1035 3-10210515-94.html64http://www.openhandsetalliance.com/android overview.html
19
3 Offenheit
3.4 Konsumenten
Im Kapitel 3.3.1 wurde beschrieben, dass manche Mobilfunkbetreiber und
Hardwarehersteller dem Konsumenten die Kontrolle uber sein Gerat entziehen,
fur das er Geld bezahlt hat. Welche Moglichkeiten stehen dem Konsumenten
zur Verfugung, um diese Kontrolle zuruckzuerhalten, ohne zu Alternativen
wechseln zu mussen, die ihm mehr Freiheiten gewahren?
Mittels Rooting ist es moglich, privilegierten Zugriff (Root Access) auf das
Android-Betriebssystem zu erlangen. Damit lassen sich weitreichende Anderungen
am Gerat durchfuhren, wozu das Entfernen von vorinstallierten Anwendungen,
die Installation neuer Versionen von Android oder sogar die Installation von
modifizierten Android-Versionen gehort.65 Lange Zeit wurde dies von Mobil-
funkbetreibern in den USA nicht geduldet66 und Gegenmassnahmen wurden
getroffen. Als Begrundung wird angegeben, dass verhindert werden soll, dass
Gerate korrumpiert oder unbrauchbar werden. Rooting wurde schliesslich Mit-
te 2010 von der fur Copyright-Fragen verantwortlichen US-Behorde fur legal
erklart.67
Die Notwendigkeit des Rootings ist somit ein klares Beispiel fur fehlende Of-
fenheit. Nur ein kleiner Teil der Konsumenten ist technisch versiert genug, um
damit die Kontrolle uber solche Android-Gerate zuruckzuerhalten.68 Der Rest
ist der Willkur von Mobilfunkbetreibern und Hardwareherstellern ausgeliefert.
CyanogenMod ist eine von privaten Android-Nutzern entwickelte modifizier-
te Version von Android, eines sogenannten Custom ROMs, das zahlreiche
Funktionen69 enthalt, die in der offiziellen Ausgabe von Android nicht enthal-
ten sind.70 Im September 2009 wurde der Hauptentwickler von Google abge-
mahnt mit der Begrundung, dass CyanogenMod die Rechte von Google verlet-
ze, da es die proprietaren Anwendungen die Google Maps, den Android Market
65http://en.wikipedia.org/wiki/Rooting (Android OS)66http://www.androidguys.com/2010/07/26/rooting-android-phone-longer-crime/67http://www.copyright.gov/1201/68http://www.pcworld.com/article/205414/googles openness on android is overrated.html69Zum Beispiel die Unterstutzung fur das verlustfreie, freie Audioformat FLAC, USB-
Thethering, usw.70http://en.wikipedia.org/wiki/CyanogenMod
20
4 Vergleich zu anderen Betriebssystemen
und YouTube enthalte. Diese seien Teil der Google Experience und geistiges
Eigentum von Google.71 Um sie verwenden zu konnen, ist eine Lizenzierung
durch Google notig. Die betroffenen Anwendungen wurden in der Folge aus
CyanogenMod entfernt.
Ohne diese proprietaren Anwendungen ist allerdings die Funktionalitat von
Android deutlich eingeschrankt. Wie im vorherigen Abschnitt erwahnt, gibt
es ausser dem Android Market beispielsweise keine einfache Moglichkeit, An-
wendungen zu installieren. Google meint dazu, dass diese Anwendungen, die
nicht Teil der Android-Plattform sind, Google die Moglichkeit geben, von An-
droid zu profitieren. Weiter wird angegeben, dass die unerlaubte Verbreitung
derselben Google schade wie jedem anderem Unternehmen, auch wenn es mit
guten Absichten geschehe.72 Was genau damit gemeint ist, bleibt allerdings im
Unklaren.
Googles strikte Haltung fuhrte zu gewissem Unverstandnis seitens der Android-
Community, insbesondere, wenn man bedenkt, dass eine umfangreiche Verbes-
serung am Linux-Kernel aus dem CyanogenMod-Projekt in den experimentel-
len Android-Code ubernommen wurde.
Zum Zweck einer grosseren Offenheit von Android ware es also wunschenswert,
wenn Open-Source-Alternativen zu diesen wichtigen Grundfunktionen existier-
ten.
4 Vergleich zu anderen Betriebssystemen
In der Einleitung wurden verschiedene Betriebssysteme fur mobile Gerate auf-
gefuhrt, die zueinander in Konkurrenz stehen. Neben der Funktionalitat und zu
Grunde liegenden Technik unterscheiden sich diese auch durch die Haltung der
dahinter stehenden Unternehmen, ob und inwiefern Offenheit einen positiven
Einfluss auf die Zukunft ihres Produkts hat.
71http://www.cyanogenmod.com/home/the-current-state72http://android-developers.blogspot.com/2009/09/note-on-google-apps-for-
android.html
21
4 Vergleich zu anderen Betriebssystemen
4.1 Apple iOS
Im Jahr 2007 stellte Apple das Smartphone mit Namen iPhone vor, auf dem
das Betriebssystem namens iOS (damals iPhone OS) lauft. Beim iOS handelt
es sich um ein proprietares Derivat des hauseigenen Betriebssystems Mac OS
X fur Desktop-Rechner. Apple untersagt es, iOS auf Hardware von Drittpar-
teien zu betreiben. iOS ist also ausschliesslich durch den Kauf eines iPhones
erhaltlich. Derzeit wird das iPhone in den Vereinigten Staaten nur mit ei-
nem SIM-Lock vertrieben, was die Verwendung einer beliebigen SIM-Karte73
unmoglich macht.74
Besitzer von iPhones durfen Anwendungen ausschliesslich uber den von App-
le kontrollierten App Store installieren, dem Aquivalent zu Googles Android
Market. Diese Beschrankung wird mit Digital Rights Management (DRM),
also technischen Schutzmassnahmen, aufrecht erhalten.
Um dennoch alternative, von Apple nicht unterstutzte Software, wie zum Bei-
spiel den Adobe Flash Player, installieren zu konnen, bleibt dem Nutzer nur
die Moglichkeit des Rootings, dass im Kontext des iPhones primar unter dem
Begriff Jailbreaking75 bekannt ist. Der bereits im Kapitel 3.4 erwahnte Ent-
scheid, dass dieser Vorgang keine Copyright-Verletzung darstellt, richtete sich
primar gegen Apple.76 Apple hingegen meint, dass die iPhone-Benutzer gar
keine eigene Veranderungen am System wollen, da Gerate dadurch beschadigt
werden konnen.77
Entwickler, die Anwendungen fur den App Store erstellen mochten, mussen
sich gegen eine Gebuhr beim iPhone-Development-Programm registrieren und
73Eine SIM-Karte ist ein Chip, der den Nutzer im Mobilfunknetz identifiziert und dadurchfur die Kommunikation vorausgesetzt wird.
74http://en.wikipedia.org/wiki/IPhone#SIM unlocking75jailbreakme.com76http://arstechnica.com/tech-policy/news/2010/07/apple-loses-big-in-drm-ruling-
jailbreaks-are-fair-use.arshttp://arstechnica.com/apple/news/2009/02/apple-sides-with-mpaa-riaa-against-drm-circumvention.ars
77If modifications of the the OS were to interfere with these control functions [volumegovernors, temperature sensors, charging circuitry], even unintentionally, the phone couldbe physically damaged or the battery could be overcharged.
22
4 Vergleich zu anderen Betriebssystemen
eine Jahresgebuhr fur die Verwendung des Software Development Kits (SDK)
verrichten. 30% des aus der Anwendung erwirtschafteten Gewinnes an Apple
abgeben. Jede Anwendung, die in den App Store aufgenommen werden soll,
durchlauft zuerst eine Prufung durch Apple. Eine weitere Einschrankung der
Entwickler aussert sich darin, dass die im SDK enthaltene Entwicklungsumge-
bung Xcode nur auf Mac OS X lauffahig ist.
Seit Version 4.0 des iOS untersagt Apple zudem die Verwendung von Zwischen-
schichten zur Entwicklung von Anwendungen. Davon ist beispielsweise Adobes
Flash-Technologie, aber auch Java und Microsofts Silverlight betroffen.
Im Gegensatz zu Android kommt im iOS keine Virtual Machine zu Einsatz.
Das lasst sich dadurch begrunden, dass dazu gar keine Notwendigkeit besteht,
da iOS nicht auf zahlreichen verschiedenen Plattformen funktionieren muss,
sondern nur auf der von Apple bestimmten Hardware.
4.2 MeeGo
Durch die Vereinigung von Intels Moblin-Projekt mit Nokias Maemo hat im
ersten Quartal des Jahres 2010 die Entwicklung des auf Linux basierenden
Open-Source-Betriebssystems MeeGo begonnen. Ziel ist es, eine Plattform fur
verschiedene Endgerate wie Mobiltelefone und Notebooks bereitzustellen.78
Wahrend der finnische Konzern Nokia langjahriger Marktfuhrer bei Mobilte-
lefonen ist, liegt er im Bereich der Smartphones gegenuber seiner Konkurrenz
zuruck.79 Intel hingegen versucht durch die Entwicklung von MeeGo mit sei-
nen Atom-Prozessoren in Markt der Smartphones Fuss zu fassen, der momen-
tan von der konkurrierenden ARM-Architektur dominiert wird.80 Durch seine
Plattformunabhangigkeit soll MeeGo beide Architekturen unterstutzen.
78http://conversations.nokia.com/2010/02/15/nokia-and-intel-create-meego-for-new-era-of-mobile-computing/
79http://www.theepochtimes.com/n2/content/view/44768/80http://www.wired.com/gadgetlab/2009/07/atom-processor-phones/
23
4 Vergleich zu anderen Betriebssystemen
Anders als beim iOS wird der MeeGo-SDK81 von verschiedenen Plattformen
kostenfrei unterstutzt. Die Applikationen werden nebst der auch von Andro-
id verwendeten Programmiersprache Java auch in C++ entwickelt, wobei QT
die zur Verfugung gestellte Entwicklungsumgebung ist. Die entwickelten An-
wendungen werden als RPM-Programmpakete angeboten und verteilt, einem
Format, dass ursprunglich von Red Hat entwickelt wurde und in verschiedenen
Linux-Distributionen Verwendung findet.
4.2.1 Lizenzierung82
MeeGo ubernimmt alle Lizenzbestimmungen aus Maemo und Moblin, welche
ihrerseits primar unter Open-Source-Lizenzen stehen. Im Gegensatz zu An-
droid findet hier hauptsachlich die GNU General Public License Verwendung.
Anders als bei Android gibt es keine absolute MeeGo-Distribution.
Fur die einzelnen Programme gibt es keine explizite Lizenz. Gefordert wird
einzig, dass die Lizenzierungsform der Definition der Open Source Initiative83
(OSI) entspricht. Nach dieser bedeutet Open Source nicht nur den Zugriff
auf den Quelltext, vielmehr soll die Lizenz technologieunabhangig sein und
proprietare Erweiterungen zulassen.
Im Gegensatz zu Android, welches die Apache Software License bevorzugt,
sollen Bibliotheken, welche das Betriebssystem erweitern, bevorzugt unter der
LGPL lizenziert werden. Ziel dieser Lizenzierungsform ist es, durch ihren Copyleft-
Charakter Fragmentierungen der MeeGo-Schnittstelle vorzubeugen, wahrend
Vertreiber von kommerziellen Produkten trotzdem die Moglichkeit von pro-
prietaren Erweiterungen haben.
81MeeGo 1.1 SDK Beta Release: 10.11.2010http://meego.com/
82http://meego.com/about/licensing-policy83http://www.opensource.org/docs/osd
24
5 Fazit
5 Fazit
Die Analyse der Offenheit von Android hat zu Tage gebracht, dass die Li-
zenzierung von Android unter einer Open-Source-Lizenz zwar von zentraler
Bedeutung fur die Offenheit von Android ist, aber trotzdem zahlreiche Aspek-
te bleiben, in denen Moglichkeiten von Konsumenten und Entwicklern einge-
schrankt werden, indem bestimmte Unternehmen Kontrolle uber die Plattform
und deren Entwicklung ausuben. Die Wahl der Apache Software License wurde
primar von kommerziellen Motiven geleitet.
Zusammenfassend lasst sich sagen, dass die Philosophie hinter der Plattform
von Pragmatismus gepragt ist, ein Begriff, der auch von Google selber zur
Charakterisierung verwendet wird.84 Dies bedeutet, dass fehlende Offenheit in
Kauf genommen wird, sofern dies nach Ansicht der Open Handset Alliance
einen positiven Einfluss auf den langerfristigen Markterfolg der Plattform hat.
Wie beschrieben wurde, aussert sich diese fehlende Offenheit deutlich im Ent-
wicklungsprozess, zu dem Aussenstehende nur beschrankten Zugriff haben, da-
mit Google keine wettbewerbstechnischen Nachteile in Kauf nehmen muss und
Google und die Mitglieder der Open Handset Alliance so exklusiv uber die
Zukunft der Plattform entscheiden konnen. Umso gravierender ist aber die
Tatsache, dass den Hardwareherstellern und Mobilfunkbetreibern weitreichen-
de Freiheiten eingeraumt werden, was die Plattform sehr attraktiv fur diese
macht. Es wurde gezeigt, dass diese Unternehmen regen Gebrauch von diesen
Freiheiten machen ganz im Sinn deren Geschaftsinteressen. Der Konsument
als Kaufer der als offenen angepriesenen Plattform ist hier am kurzeren Hebel.
Der Vergleich mit dem iOS zeigte allerdings deutlich, dass Benutzer und An-
wendungsentwickler des iOS viel weniger Freiheiten geniessen als diejenigen
von Android. Dem Konsumenten wird beim Kauf keine Wahl ermoglicht, was
im Kontrast steht zu der grossen Anzahl verschiedener Gerate steht, die auf
Android basieren. Apple selbst sieht diese Uniformitat, starke Integration und
Moglichkeit der vollstandigen Kontrolle jedoch als Vorteil.
84http://source.android.com/about/philosophy.html
25
5 Fazit
Als junges Projekt hat MeeGo aus Marktsicht gegenuber Android und iOS
noch einen weiten Weg vor sich. Es ist aber erfreulich zu sehen, dass man
bei MeeGo bemuht ist, die Entwicklung offener zu gestalten als bei Android.
Das Projekt erfahrt nicht die bei letzterem ausgefuhrte strikte Kontrolle und
Geheimhaltung der Weiterentwicklung.
Personen, die den Kauf eines Smartphones erwagen, haben heute dank eines
kompetitiven Marktes verschiedenste Angebote. Es liegt in deren Verantwor-
tung, die Vor- und Nachteile der einzelnen Plattformen gemass eigenen Krite-
rien abzuwagen. Die Offenheit einer Plattform spielt wahrscheinlich fur viele
mangels Aufklarung und technischer Versiertheit eine untergeordnete Rolle.
Gemass Marktanalysen85 werde der weltweite Marktanteil von Android bis
2014 auf Kosten der anderen Smartphone-Betriebssysteme auf rund 25 % wach-
sen. Android scheint also eine bluhende Zukunft vor sich zu haben.
85http://www.zdnet.de/news/mobile wirtschaft idc hebt prognose fuer weltweitensmartphone markt um zehn prozent an story-39002365-41537463-1.htm
26