© ampower, 123RF.com

Entwickler für I-Phone, Android und andere Smartphones kommen um die Nutzung der Hersteller-SDKs nicht herum. Die Lizenzbedingungen erinnern dabei manchmal eher an Knebelverträge des Mittelalters. Und so sehen sie aus !

Gute Zeiten für Programmierer, könnte meinen, wer die rasant wachsende Zahl der Smartphone-Nutzer sieht und den Bedarf an Applikationen dafür. Zusammen mit den Telefonen veröffentlichen die Hersteller das passende Entwickler-Kit. Je mehr Kunden einen Gerätetyp kaufen, desto größer der Bedarf an Apps und umso mehr Programmierer sind nötig, den Hunger zu stillen.

Monopoly

Der Markt, auf dem diese Software landet, entspricht allerdings nicht ganz dem herkömmlichen Modell von Angebot und Nachfrage, das die Wirtschaftskunde lehrt. Beim neuen, zentralisierten Konstrukt hat sich einer zwischen den Anbieter und die Nachfrager gedrängt, und der bündelt, vermittelt, makelt, hält eine Plattform für den Austausch vor und bestimmt auf die eine oder andere Weise, was sein darf und was nicht.

Ob dieses Vermittlungsmonopol auf den App-Marktplätzen zulässig ist, darüber lässt sich streiten. Neben Apple und Googles Android versucht Palm mit dem Web OS den Mobilfunkmarkt zu erobern, seit Neuestem unter den Fittichen von Hewlett-Packard. Microsoft entsendet Windows Mobile und Blackberry-Hersteller RIM redet ebenfalls ein gewichtiges Wörtchen mit.

Aus diesem Grund besteht zwar das Vermittlungsmonopol der Anbieter, weil aber die Verbraucher den Anbieter wechseln können, gilt das System als kaum angreifbar. Es stellt sich die Frage: Was wird vom Programmierer verlangt, wenn er hinein will in die App-Märkte?

Apple exklusiv

Wer Apps für das I-Phone veröffentlichen will (Abbildung 1), ist auf Gedeih und Verderb dem Apple-eigenen Prüfverfahren ausgeliefert. Nur Software, die der I-Phone- und I-Pad-Erfinder für gut und würdig befindet, darf in den App Store – und nur dort finden I-Nutzer Programme, die auf ihren Geräten laufen. Abseits davon führt ein Weg, bestimmte Programme zu finden und herunterzuladen, wenn der Benutzer das Gerät zuvor per so genanntem Jailbreak gecrackt hat, was aber nur eine Minderheit der I-Phone-Nutzer wagt. Einer Statistik [1] zufolge beträgt der Anteil der Geräte mit Jailbreak in Deutschland rund 10 Prozent, in den USA gar nur halb so viel.

Abbildung 1: Hallo Welt. Bis dahin wirkt die Apple-Entwicklungswelt vertraut. © Apple

Die “Apple I-Phone Developer Program”-Lizenzbedingungen unterliegen zwar einer Verschwiegenheitsklausel, die EFF (Electronic Frontier Foundation) hat sich aber den Text besorgt und ihn auf der eigenen Website veröffentlicht [2]. Jeder, der Programme im App Store anbieten will, muss diesen Bedingungen zuvor zustimmen.

Verbotskatalog

Abschnitt 2.6 dieser Bedingungen verbietet rigoros jede Art des Reverse Engineering – einschließlich derjenigen, die zur Herstellung von Interoperabilität zwischen Software nötig ist. Auf Deutsch: So viel, wie man braucht, um sein eines Programm in Verbindung mit einem anderen sachgerecht nutzen zu können. Dergleichen Reverse Engeneering ist in den USA durch Gerichtsurteil für zulässig erklärt und in Europa in Gesetzesform gegossen, dennoch verbietet Apple es.

Gemäß Abschnitt 3.2(e) besteht ein umfassendes Verbot jeder Art der Umgehung oder Überwindung der Sicherheits- oder Authentifizierungs-Maßnahmen beziehungsweise -Systeme einschließlich des Digital Rights Management auf allen Apple-Geräten und für jede Apple-Software und jeden Apple-Dienst.

Entwicklungen dürfen ausschließlich über den App Store angeboten werden, selbst dann, wenn Apple die Aufnahme verweigert, wofür keine Bekanntgabe von Gründen nötig ist. Damit haben Programmierer keine Möglichkeit, Anwendung auf dem freien Markt zu verwerten, denn es gibt keinen. Der Entwickler darf infolge dieser Klausel dann auch nicht mehr auf Stores für Geräte mit Jailbreak zurückgreifen

Fernabschaltung

Apple genehmigt sich zudem ganz ungeniert die Erlaubnis, jederzeit einzelne Apps nicht nur aus dem Store zu nehmen, sondern per Remote-Zugriff auf den Geräten zu deaktivieren (Abschnitt 8). Apple nutzt dazu ein Zertifikat auf der eigenen Website, das – sofern ungültig geschaltet – den Start bereits installierter Apps verhindert. Damit steht auch fest, dass I-Phone & Co. nach Hause telefonieren.

Dass Entwickler einen Maulkorb tragen, regelt Abschnitt 10.4. Das betrifft nicht nur Apple-interne, also geschäftlich relevante Informationen wie etwa bestimmte Algorithmen, deren Umsetzung oder technische Details über I-Phone & Co., sondern auch wie erwähnt den Vertrag und seinen Inhalt selbst. Die Maximalsumme für Schadensersatz versucht Apple auf 50 US-Dollar zu begrenzen. Eine derartige Begrenzung dürfte im Streitfall kaum wirksam sein, der Betrag zeigt aber indirekt, wie wenig wertvoll Apple die Mitarbeit der einzelnen Developer einschätzt.

Die einzelnen Bedingungen mögen vor Gericht nicht oder nicht in vollem Umfang durchsetzbar sein, doch davon hat der einzelne Entwickler nichts. Weil Apple nach Gutsherrenart in seinem Store regiert und damit unmittelbar jede Ertragsmöglichkeit des Entwicklers für das jeweilige Programm oder sogar alle seine Apps in der Hand hält, riskiert kein Entwickler und kein Software-Unternehmen in Misskredit zu fallen.

Wer meint, das sei eine unzulässige Ausübung der Monopolstellung, dem wird Apple entgegenhalten, dass es ja noch andere Anbieter gibt. Google etwa. Was die wohl für Lizenzbedingungen für den Entwickler aufstellen?

Android only

Auch Google macht die Benutzung seines Android Software Development Kit von der Unterwerfung unter die zugehörige Lizenzvereinbarung [3] abhängig. Die Einschränkungen fallen hier aber wesentlich geringer aus:

Gemäß Abschnitt 3 darf das Android-SDK ausschließlich dafür genutzt werden, Apps für das Android-Betriebssystem zu entwickeln. Außerdem stellt Google klar, dass das SDK keine freie Software ist, sondern eine proprietäre Entwicklungsumgebung, deren Rechte sich der Hersteller vorbehält. Programmierer dürfen das Android-SDK daher nur benutzen, nicht aber anpassen.

Rechtskonforme Apps

Google schränkt die Programmiererfreiheit dergestalt ein, dass nur Programme, die weder Gesetze noch Gewohnheitsrecht oder die guten Sitten verletzten, damit entwickelt werden dürfen. Das darf man getrost als leerlaufende Klausel betrachten, doch versucht das Unternehmen sich dadurch gegen Ansprüchen Dritter abzusichern.

In Abschnitt 4 und seinen Unterbestimmungen erklärt der Programmierer im Wesentlichen, dass Google nicht für seine Programme (und seine eigenen Fehler) verantwortlich ist. Und dass er fremde Software in Verbindung mit dem Android-SDK auf eigene Gefahr benutzt. Womit implizit auch klargestellt ist, dass Google keine Einwände hat, auch fremde Programme auf oder zusammen mit dem SDK einzusetzen.

Abschnitt 5 bestimmt, dass der Programmierer für seine Programme im Android Store selbst verantwortlich ist. Die Lizenzbestimmungen vermeiden den Terminus “Store” oder auch nur die Erwähnung einer zentralen Anlaufstelle – vielmehr sagt die Lizenz nur aus, dass der Entwickler für alles selbst verantwortlich ist, was unter seinen “Developer Credentials” veröffentlicht ist. Wo und wie die Apps veröffentlicht werden, ist in der Lizenz nicht erwähnt.

Die Nutzung von Google-Data- und anderen APIs regelt Abschnitt 8: Die Bestimmungen stellen klar, dass die über Google-Data-APIs bezogenen Daten fremden Urheber-, Leistungsschutz- oder anderen Rechten unterliegen, und verbieten diese zu bearbeiten, zu verändern, weiterzugeben oder auf eine Weise zu verwenden, die über eine einfache urheberrechtliche Nutzung hinausgeht.

Kündigung

In Abschnitt 9 schließlich sind die Modalitäten einer Kündigung aufgezählt. Der Programmierer hat’s leicht: Er beendet die Lizenzvereinbarung durch Nicht-(mehr)-Gebrauch des SDK und Löschen seiner “Developer Credentials”, also seines oder seiner Entwicklerkontos für die Android-Plattform. Die Gründe, die Google selbst sich vorbehält, um die Lizenzvereinbarung zu beenden, sind unspektakulär, Verstöße gegen die Bedingungen und Verpflichtung durch einen Richterspruch zählen dazu.

Hand auf den Mund

Wer für einen weiteren Anbieter, Palm, Programme entwickeln und vertreiben möchte, braucht das “Palm Web OS Mojo Software Development Kit” [4] und muss sich der Lizenzvereinbarung [5] unterwerfen. Auch Palm verlangt von seinen Entwicklern strenge Verschwiegenheit. In Abschnitt 2 des “Palm Software Development Kit License Agreements” heißt es: Mund halten und nichts weitergeben, sofern nicht ausdrücklich (Abschnitt 3) ermächtigt.

Abschnitt 3 stellt klar, dass der Entwickler kein “Palm-Material”, also Software, Dokumentation, Module oder Beispielcode, das übers SDK oder die Entwickler-Website zur Verfügung steht, weitergeben darf. Auch verpflichtet sich der Entwickler einen Lizenzhinweis in sein Programm aufzunehmen, wonach die Rechte bei Palm und deren Unterlizenznehmern (unter anderem beim jeweiligen Programmierer) liegen. Eine Klausel, die deutschem Urheberrecht entspricht und nicht überrascht – proprietäre Software eben (Abbildung 2).

Abbildung 2: Zertifzierungsstelle für Entwickler im Android-Programm.

Dennoch widmet sich ein Passus der freien Software, die zum Teil in den Beispielcodes steckt. Der Text weist darauf hin, dass die Lizenzen freier Software im Kollisionsfall die Palm-Lizenz verdrängen und den Entwickler an die freie Lizenz binden.

Zertifikatszwang

Ausgenommen in Testumgebungen dürfen nur von Palm zertifizierte Anwendungen in den Handel kommen. Hierfür gelten gesonderte Vereinbarungen, die unter anderem auch Gebühren vorsehen können, die für die Signierung beziehungsweise Freigabe vom Entwickler an die Firma Palm zu bezahlen sind. Anwendungen, die mit dem Palm-SDK für Palm-Geräte erstellt sind, dürfen ausschließlich über den “Palm Application Catalog”, Palms App Store (Abbildung 3), vertrieben werden.

Abbildung 3: Palms App Store aus der Sicht des interessierten Nutzers.

Qual der Wahl

Damit verhält sich Palm nahezu wie der Mitbewerber Apple: Auch hier will der Anbieter oder Hersteller keine Verantwortung oder Haftung für die Programme übernehmen. Auch hier sind Entwickler darauf angewiesen, dass ihre Programme “zertifiziert” sind. Die Lizenzbedingungen bieten keine Garantie, unter welchen Voraussetzungen ein Programm solch ein Zertifikat erhält, vergleichbar zu Apple.

Im Gegensatz dazu dürfen Android-Apps beliebig vertrieben werden. Auch wenn letztlich der bestehende Markt bekannter sein dürfte als die kleine Homepage eines einzelnen Entwicklers: Wer sich nicht knebeln lassen will, setzt daher auf Android. (uba)