Gestaltung von Service Level Agreements bei Software as a Service

kuschert.de

Gestaltung von Service Level Agreements bei Software as a Service

European Legal Informatics Study Programme XV

Wintersemester 2009 / 2010

Gestaltung von Service Level Agreements

bei

Software as a Service

Masterarbeit im

Ergänzungsstudiengang IT-Recht & Recht des geistigen Eigentums

vorgelegt von: Jochen Kuschert

an der Leibniz Universität Hannover


Inhaltsübersicht

Inhaltsübersicht...............................................................................................................I

Literaturverzeichnis .....................................................................................................IV

Abkürzungsverzeichnis............................................................................................. VIII

Gestaltung von Service Level Agreements bei Software as a Service ......................- 1 -

A. Aufgabenstellung ...............................................................................................- 1 -

B. Hauptteil.............................................................................................................- 3 -

I. Software as a Service.....................................................................................- 3 -

1. Einführung .................................................................................................- 3 -

2. Das SaaS Geschäftsmodell ........................................................................- 4 -

a) IaaS ........................................................................................................- 8 -

b) PaaS........................................................................................................- 9 -

c) SaaS......................................................................................................- 10 -

d) Ergebnis ...............................................................................................- 10 -

3. Unterschiede zum ASP Geschäftsmodell ................................................- 11 -

a) Begriffserklärung .................................................................................- 11 -

b) Unterscheidungsmöglichkeit................................................................- 12 -

c) Scheitern des ASP Modells..................................................................- 16 -

4. Chancen und Risiken von SaaS ...............................................................- 17 -

5. Die Vision ................................................................................................- 19 -

6. Ergebnis ...................................................................................................- 21 -

II. Vertragstypologische Einordnung ...............................................................- 22 -

1. Einführung ...............................................................................................- 22 -

2. Sachqualität von Software .......................................................................- 24 -

3. Typengemischter Vertrag.........................................................................- 25 -

4. Mietvertrag...............................................................................................- 26 -

a) Charakterisierung.................................................................................- 26 -

b) SaaS = Softwaremiete? ........................................................................- 28 -

c) Ergebnis ...............................................................................................- 31 -

5. Werkvertrag .............................................................................................- 32 -

I


6. Dienstvertrag............................................................................................- 34 -

7. Ergebnis ...................................................................................................- 34 -

III. Service Level Agreements .......................................................................- 36 -

1. Einführung ...............................................................................................- 36 -

2. Rechtsnatur von SLA...............................................................................- 37 -

a) Begriffsbestimmung.............................................................................- 37 -

b) Rechtliche Qualifizierung ....................................................................- 39 -

3. Gestaltung eines SLA ..............................................................................- 42 -

a) Standardangebote und individuelle Gesamtlösungen ..........................- 43 -

b) Methodik..............................................................................................- 44 -

c) Strafrechtliche Einflüsse bei der Vertragsgestaltung...........................- 47 -

4. Einzelne Klauseln und ihre rechtliche Bewertung bei SaaS....................- 50 -

a) Regelungen über die Systemerreichbarkeit .........................................- 50 -

(1) Verfügbarkeitsklausel ..................................................................- 51 -

(a) Beschreibung............................................................................- 51 -

(b) Rechtliche Einordnung und AGB Bezug.................................- 54 -

(2) Wartungsklauseln.........................................................................- 56 -

b) Regelungen zum Datenumgang ...........................................................- 57 -

(1) Datenschutz..................................................................................- 57 -

(2) Datenmigration und Datenstandardisierung ................................- 58 -

(3) Datenrückholung..........................................................................- 60 -

(4) Regelungen über den Softwarestandort .......................................- 61 -

c) Compliance und Auditfähigkeit...........................................................- 62 -

d) Sanktionsmechanismen........................................................................- 62 -

(1) Vergütungsminderung..................................................................- 64 -

(2) Vertragsstrafen und pauschalierter Schadensersatz .....................- 65 -

(3) Vertragsstrafen bei Sicherheitsverletzungen................................- 65 -

(4) Außerordentliche Kündigung.......................................................- 66 -

e) Service Level Management..................................................................- 67 -

f) Sonstiges ..............................................................................................- 68 -

(1) Systemverantwortung ..................................................................- 68 -

(2) Gestaltungsanforderungen der Weboberfläche............................- 69 -

(3) Ressourcenanpassung ..................................................................- 71 -

(4) Force Majeure Klauseln...............................................................- 72 -

II


IV. Datenschutzrecht......................................................................................- 73 -

1. Einführung ...............................................................................................- 73 -

2. Unterschied Auftragsdatenverarbeitung vs. Funktionsübertragung ........- 73 -

3. Compliance Anforderungen § 11 BDSG .................................................- 76 -

a) 10-Punkte Katalog ...............................................................................- 77 -

b) Sorgfalts-, Auswahl- und Überwachungspflichten ..............................- 77 -

c) Besondere Pflichten des SaaS Anbieters .............................................- 79 -

d) Subunternehmer ...................................................................................- 79 -

4. Internationale Aspekte .............................................................................- 79 -

5. Sensitive Daten ........................................................................................- 82 -

V. Urheberrechtliche Aspekte...........................................................................- 83 -

1. Territorialprinzip......................................................................................- 83 -

2. Lizenzverhältnis zwischen SaaS-Anbieter und Softwarehersteller .........- 84 -

3. Lizenzverhältnis zwischen SaaS-Anbieter und –Nutzer..........................- 86 -

4. SaaS als eigene Nutzungsart gem. §§ 31 ff. UrhG ..................................- 86 -

5. Ergebnis ...................................................................................................- 87 -

C. Zusammenfassung der Ergebnisse...................................................................- 88 -

III


Literaturverzeichnis

Bartsch, Michael: Softwarepflege nach neuem Schuldrecht, in: NJW 2002, 1526

Bettinger, Torsten / Scheffelt, Michael: Application Service Providing:

Vertragsgestaltung und Konflikt-Management, in: CR 2001, 729

Beyer, Jochen: ASP - Zweckmäßige Gestaltung von Service Level Agreements aus

Sich des Providers, in: ITRB 2006, 20

Bierekoven, Christiane: Lizenzierung in der Cloud - Neue Formen der

Vertragsgestaltung, in ITRB 2010, 42

Brain, Marshall: How ASPs Work, http://computer.howstuffworks.com/asp.htm

(Stand: 12.07.2010)

Braun, Heiko: Die Zulässigkeit von Service Level Agreements - am Beispiel der

Verfügbarkeitsklausel, München: Beck, 2006

Bräutigam, Peter (Hrsg.): IT-Outsourcing, Berlin: Schmidt, 2004

Bräutigam, Peter: SLA: In der Praxis alles klar?, in: CR 2004, 248

Catteddu, Daniele / Hogben, Giles: Cloud Computing Risk Assessment, November

2009, http://www.enisa.europa.eu/act/rm/files/deliverables/cloud-computing-riskassessment

(Stand. 12.07.2010)

Döser, Wulf: Anglo-amerikanische Vertragsstrukturen in deutschen Vertriebs-,

Lizenz- und sonstigen Vertikalverträgen, in: NJW 2000, 1451

Dreier, Thomas / Schulze, Gernot: Urheberrechtsgesetz (UrhG), Kommentar, 3. Aufl.,

München: Beck, 2009

Feil, Thomas: Software as a Service, Juni 2009, http://it-vergabeblog.de/vertragsrecht/software-as-a-service

(Stand: 12.07.2010)

Fischer, Thomas (Hrsg.): Strafgesetzbuch und Nebengesetze, Kurzkommentar, 55.

Aufl., München: Beck 2008

Gennen, Klaus / Völkel Anne: Recht der IT-Verträge, Köln: C.F. Müller, 2009

Gola, Peter / Schomerus, Rudolf: BDSG Bundesdatenschutz Kommentar, 9. Aufl.,

München: Beck, 2007

Grohamm, Werner: Von der Software zum Service - ASP - Software on Demand -

Software-as-a-Service - Cloud Computing, 5. Aufl. 2009

Grundewald, Barbara: Just-in-time-Geschäfte - Qualitätssicherungsvereinbarungen

und Rügelast, in: NJW 1995, 1777

IV


Grützemacher, Malte: Application Providing - Urhebervertragsrechtliche Aspekte, in:

ITRB 2001, 59

Grützemacher, Malte: Auftragsdatenverarbeitung oder Funktionsübertragung, in:

ITRB 2007, 183

Hannemann, Thomas / Wiegner, Michael (Hrsg.): Münchener Anwaltshandbuch

Mietrecht, 3. Aufl., München: Beck, 2009

Härting, Niko: Datenschutz und Anwaltsgeheimnis, in: ITRB 2009, 138

Heghmanns, Michael / Niehaus, Holger: Outsourcing im Versicherungswenden und

der Gehilfenbegriff des § 203 III 2 StGB, in: NStZ 2008, 57

Helbing, Thomas: Datenschutz bei Software as a Service (SaaS), April 2010,

http://www.softmixx.de/blog/branchen/201004/dr-thomas-helbing-zu-saasvertragsgestaltung-und-datenschutz.html

(Stand: 12.07.2010)

Helwig, Björn / Koglin, Olaf: Service Level Agreements Für Software As A Service-

Dienste, in: Taeger, Jürgen / Wiebe, Andreas (Hrsg.): Inside the Cloud - Neue

Herausforderungen für das Informationsrecht: DSRI Tagungsband Herbstakademie

2009

Herrmann, Wolfgang: Grundlagen des Cloud Computing, März 2009,

http://www.tecchannel.de/webtechnik/soa/1837978/grundlagen_cloud_computing_s

aas_virtualisierung/ (Stand: 13.07.2010)

Heussen, Benno: Systemverantwortung bei Computerverträgen, in: NJW 1988, 2441

Heymann, Thomas: Outsourcing in Deutschland - eine Bestandsaufnahme zur

Vertragsgestaltung, in: CR 2005, 706

Hoeren, Thomas / Sieber, Ulrich (Hrsg.): Handbuch Multimedia – Recht, Stand: Juni

2009 (22. Ergänzungslieferung), München: Beck, 2009

Hörl, Bernhard / Häuser, Markus: Service Level Agreements in IT-

Outsourcingverträgen, in: CR 2003, 713

Intveen, Michael / Lohmann, Lutz: Die Haftung des Providers bei ASP-Verträgen -

Wonach richtet sich die Providerhaftung und welche vertraglichen Möglichkeiten

zur Beschränkung gibt es noch?, in: ITRB 2002, 210

Koch, Frank A.: Weltweit verteiltes Rechnen im Grid Computing, in CR 2006, 42

Koch, Frank A.: Web Services als neue IT-Vertragsleistung, in: ITRB 2007, 71

Köhler-Schute, Christiane (Hrsg.): Software as a Service - Strategien, Konzepte,

Lösungen und juristische Rahmenbedingungen, Berlin: KS-Energy-Verlag, 2009

Kramer, André / König, Peter: Nie wieder installieren - Webanwendungen

konkurrieren mit lokalen Programmen, in: c’t 23/2008, S. 118

V


Lejeune, Mathias: Force Majeure Klauseln in IT-Verträgen, in: ITRB 2009, 189

Müller-Hengstenberg, Claus D. / Kirn, Stefan: Vertragscharakter des Application

Service Providing-Vertrags, in: NJW 2007, 2370

Nägele, Thomas / Jacobs, Sven: Rechtsfragen des Cloud Computing, in: ZUM 2010,

281

Niemann, Fabian / Paul, Jörg-Alexander: Bewölkt oder wolkenlos - rechtliche

Herausforderungen des Cloud Computings, in: KuR 2009, 444

Palandt: Bürgerliches Gesetzbuch, Kurzkommentar, 67. Aufl., München: Beck 2008

Peter, Stephan: Verfügbarkeitsvereinbarungen beim ASP-Vertrag, in: CR 2006, 404

Pohle, Jan / Ammann, Thorsten: Software as a Service - auch rechtlich eine Evolution,

in: KuR 2009, 625

Pohle, Jan / Ammann, Thorsten: Über den Wolken … - Chancen und Risiken des

Cloud Computing, in: CR 2009, 273

Rath, Michael: Hinweis zur Ausgestaltung von Service Level Agreements (SLA), in:

KuR 2007, 362

Redeker, Helmut: IT-Recht, 4. Aufl., München: Beck, 2007

Roth, Birgit: Organisatorische und technische Maßnahmen zum Schutz

personenbezogener Daten, in: ITRB 2010, 60

Säcker, Franz Jürgen / Rixecker, Roland (Hrsg.): Münchener Kommentar zum BGB,

5. Aufl., München: Beck, 2006

Schmitz, Ludger: Megatrend Virtualisierung, in: Computerwoche 9/2007, 20,

http://www.computerwoche.de/software/office-collaboration/588872/ (Stand:

12.07.2010)

Schüler, Peter: Firmen-IT im Abo - Web-Dienste als Ersatz für lokale Multiuser-

Programme, in: c’t 23/2008, S. 132

Schulz, Carsten / Rosenkranz, Timo: Cloud Computing - Bedarfsorientierte Nutzung

von IT-Ressourcen, in: ITRB 2009, 232

Schulz, Uwe: Von der Software zum Service, in: IX extra 9/2007

Schumacher, Volker: Service Level Agreements: Schwerpunkt bei IT- und

Telekommunikationsverträgen, in: MMR 2006, 12

Schuster, Fabian / Reichl, Wolfgang: Cloud Computing & SaaS: Was sind die

wirklich neuen Fragen, in: CR 2010, 38

VI


Schuster, Fabian: Rechtsnatur der Service Level bei IT-Verträgen, in: CR 2009, 205

Sedlmeier, Tobias / Kolk, Daniel: ASP - Eine vertragstypologische Einordnung, in:

MMR 2002, 75

Sjöberg, Cecilia Magnusson (ED.): Legal Management of Information Systems -

incorporating law in e-solutions, Stockholm: Studentlitteratur, 2005

Söbbing, Thomas: Handbuch IT-Outsourcing: rechtliche, strategische und steuerliche

Fragen, 1. Aufl., Bonn: Redline, 2002

Söbbing, Thomas: Service Level Agreements, in: ITRB 2004, 257

Söbbing, Thomas / Limbacher, Stefan: Transformierung englischer IT-Verträge ins

deutsche Recht, in: MMR 7/2009, S. XXIX

Söbbing, Thomas: Cloud und Grid Computing: IT-Strategien der Zukunft rechtlich

betrachtet, in: MMR 2008, XII

Söbbing, Thomas: Auswirkungen der BDSG-Novelle II auf Outsourcingprojekte, in:

ITRB 2010, 36

Spies, Alex: USA: Cloud Computing - Schwarze Löcher im Datenschutz, in: MMR

2009, XI

Spindler, Gerald: Neues im Vertragsrecht der Internet-Provider - Einflüsse der

Reform des Schuldrechts und des Telekommunikationsrechts, in: CR 2004, 203

Stanoevsak-Slabeva, Katarina / Wozniak, Thomas / Ristol, Santi (ED.): Grid and

Cloud Computing - A Business Perspective on Technology and Applications, Berlin

/ Heidelberg: Springer Verlag, 2010

Thome, R.: SaaS - ASP - interessanter Hintergrund zu modernen ERP-Systemen, Juli

2009, http://www.meck-online.de/wp-content/uploads/2010/01/2009-08_saasasp1.pdf

(Stand: 12.07.2010)

Trienekens, Jos J.M. / Bouman, Jacques J. / van der Zwan, Mark: Specification of

Service Level Agreements: Problems, Principles and Practices, in: Software Quality

Journal, 12, 2004, S. 43 ff., Niederlande: Springer, 2004

Wesselmann, Bettina: Unbeschwert auf Wolken, in: iX extra 3/2010 IV

VII


Abkürzungsverzeichnis

API Application Programming Interface

ASP Application Service Provider

B2B Business-to-Business

CRM Customer-Relationship-Management

ENISA European Network and Information Security Agency

ERP Enterprise Resource Planning

HMI Human Machine Interface

IaaS Infrastructure as a Service

IMAP Internet Message Access Protocol

KPI Key Performance Indicator

MTTR Mean Time To Repair

PaaS Platform as a Service

POP Post Office Protocol

SaaS Software as a Service

VIII


SLA Service-Level-Agreement

SMTP Simple Mail Transfer Protocol

XML Extensible Markup Language

Weitere verwendete Abkürzungen folgen dem

IX

Abkürzungsverzeichnis der Rechtssprache,

von: Kirchner, Hildebert / Nutz Cornelie,

5. Aufl., Gruyter, Berlin 2003


Gestaltung von Service Level Agreements

bei

Software as a Service

A. Aufgabenstellung

Dem Software as a Service Modell (SaaS) wird von führenden Analysten

eine erfolgreiche Zukunft vorausgesagt. 1 Zu den traditionellen Lizenz-

geschäften mit Software stellen „On Demand" - Angebote wie SaaS oder

Application Service Provider (ASP) eine flexible Alternative dar, die das

Potential haben, sich immer stärker durchzusetzen. 2 Sowohl für den

Softwareanbieter wie auch für den Softwarenutzer bringen diese Modelle

viele Vorteile mit sich, die mit den traditionellen Lizenzgeschäften nicht zu

erreichen sind. 3 Viele nutzen bereits SaaS ohne es zu merken. Beispiele

hierfür finden sich in Bereichen der Emailkommunikation via

Webmaildienst oder auch in neueren Formen wie des Online

Videorekorders.

Der Softwarenutzer erspart sich den hohen Aufwand im eigenen

Unternehmen selbst eine IT-Abteilung betreiben zu müssen. Zudem muss er

keine kostspieligen Lizenzen für Software erwerben, die schon nach kurzer

Zeit veraltet sein kann. Letztendlich werden hierdurch die notwendigen

Anfangsinvestitionen gesenkt.

Für den Softwareanbieter, sofern er selbst seine Software im SaaS Modell

vertreibt, verringert sich die rechtliche Problematik bezüglich des

Weiterverkaufs seiner Software als Gebrauchtsoftware, an welchem er meist

kein Interesse hat. Eine urheberrechtsverletzende Weitergabe von

Softwarekopien, sog. Raubkopien, kann dabei völlig ausgeschlossen werden.

1

http://www.computerwoche.de/management/it-services/1895119/ (Stand: 06.07.2010)

2

http://www.computerwoche.de/management/cloud-computing/1905913/ (Stand:

14.07.2010)

3

Kramer, A. / König, P., c’t 23/2008, S. 118 ff.; Schüler, P., c’t 23/2008, S. 132 ff.

- 1 -


Da die Software, besser spricht man bei SaaS von Softwarefunktionen,

jedoch nicht mehr lokal bei den Nutzern gespeichert wird, sondern von

Dritten aus der Ferne administriert und zur Verfügung gestellt wird, ist eine

genaue vertragliche Leistungsbeschreibung erforderlich. Nur so kann die

unverzichtbare ständige Verfügbarkeit der Software vertraglich

gewährleistet, die Risiken sachgerecht verteilt und Vertrauen gefördert

werden. Es stellt sich somit die rechtliche Frage nach den notwendigen

vertraglichen Regelungen, der Vereinbarkeit mit AGB Recht, der

Risikoverteilung sowie der Einführung von Sanktionen wie Vertragsstrafen,

Minderungen / Preisreduktionen oder pauschalierten Schadensersatzan-

sprüchen um die Leistungsqualität aufrecht zu erhalten.

Um eine sachgerechte Beantwortung der Fragen zu SaaS vornehmen zu

können, widmet sich die Arbeit im ersten Teil der Untersuchung von SaaS

und im Besonderen der Abgrenzung zum ASP Vertrag. Dies erscheint

notwendig, da es in der juristischen Literatur häufig zu einer Vermischung

von technischen Begriffen zu kommen scheint. Zudem soll eine andere

Sichtweise im rechtlichen Umgang und der technischen Einordnung von

SaaS angestrebt werden. Hierzu wird das SaaS Modell genauer untersucht

und in sein ursprüngliches Umfeld (dem „CloudComputing“) zurückgeführt,

um hieraus eine erneute rechtliche Einordnung vornehmen zu können, die

den Zielen von SaaS besser entspricht. Dabei soll auch ein Blick in die

Zukunft gewagt werden, wie sich SaaS weiterentwickeln kann, um hieraus

Rückschlüsse auf die vertragliche Einordnung vornehmen zu können und

das Problembewusstsein bei der Gestaltung der SLA zu schärfen.

Im nachfolgenden Teil wird auf den zuvor gewonnenen Grundlagen eine

rechtliche Einordnung in die bestehenden Vertragstypen des BGB

untersucht. Auch wenn sich durch die Schuldrechtsreform die rechtlichen

Folgen der unterschiedlichen Vertragstypen bei Mängeln angenähert haben,

bestehen im Einzelnen noch Differenzen. Dabei erscheint die Einordnung

weiter notwendig, da die Gerichte weiterhin in den Grenzen der bestehenden

Vertragstypen denken.

- 2 -


In einem dritten Teil dieser Arbeit werden die Service Level Agreements

allgemein dargestellt und Wege zur Gestaltung aufgezeigt. Im Anschluss

werden einige typische SLA untersucht.

Sodann wird das Thema Datenschutz im Umgang mit SaaS in einem

eigenen Teil dargestellt und es wird kurz auf urheberrechtliche

Fragestellungen einzugehen sein.

Im Schlussteil dieser Arbeit werden die Ergebnisse kurz zusammengefasst

und ein Ausblick auf die weitere Entwicklung gegeben.

B. Hauptteil

I. Software as a Service

1. Einführung

Das SaaS Modell ist eine neue Entwicklung, die sich im Umfeld von Cloud

Computing 4 , also der virtualisierten IT, bewegt. Zuweilen mangelt es

deswegen noch an einer eindeutigen Begrifflichkeit und einem eindeutigen

Begriffsverständnis. 5 So hat man mit einer Armada von neuen und alten

Begriffen wie Cloud Computing, ASP, SaaS, PaaS, IaaS, Outsourcing oder

OnDemand, um nur ein paar wenige zu nennen, zu kämpfen. Erschwerend

kommt hinzu, dass alte Techniken, die ebenso schon das Internet und andere

Datennetze nutzten und sich manchmal nur im Detail und den Zielen von

SaaS unterscheiden, mit in die Diskussionen einspielen und zur Verwirrung

beitragen, wenn alte Begrifflichkeiten nicht exakt abgegrenzt werden

(können). Dann verwundert es nicht, wenn SaaS teilweise auch als böse

Marketingstrategie gewertet wird, nur um eine alte Technik unter neuem

Namen anzubieten. Vielleicht werden hin und wieder auch neue Begriffe für

etwas, das es schon gab, benutzt, weil sie schicker klingen. Das ist dann

bedauerlich und könnte verhindert werden.

4 zu Begrifflichkeit: Stanoevsak-Slabeva / Wozniak / Ristol, „Grid and Cloud Computing“,

S. 47 ff.; http://de.wikipedia.org/wiki/ Cloud_Computing (Stand: 11.07.2010)

5 Stanoevsak-Slabeva / Wozniak / Ristol, „Grid and Cloud Computing“, S. 47 f.

- 3 -


Doch was ist Software as a Service genau? Schon der Begriff weckt

Verwirrung, war doch Software bisher immer etwas das man kaufen oder

mieten konnte, aber eben nicht als Dienstleistung erhielt. 6 Ohne den

nachfolgenden Kapiteln vorwegzugreifen, ist meines Erachtens nach die

Virtualisierung der Dreh und Angelpunkt bei SaaS, wie auch bei Cloud

Computing. 7 Man muss sich von dem Gedanken lösen, dass Software als ein

Produkt verkauft wird, dass aus einer ganz bestimmten Abfolge von

Befehlen, dem Algorithmus, besteht (hierzu später mehr).

In den nachfolgenden Kapiteln soll versucht werden, das SaaS Modell unter

einem anderen Gesichtspunkt zu sehen, als es teilweise noch gesehen wird.

Es soll der Versuch unternommen werden zu erklären, dass SaaS nicht ASP

ist und dass Sinn und Zweck dieses neuen Softwarevertriebs nicht mehr die

Zurverfügungstellung einer ganz bestimmten Software in der Form einer

eindeutigen und individuellen Abfolge von Befehlen ist, sondern die damit

erzielbaren Funktionalitäten. Dies wird dann als Grundlage dazu dienen,

SaaS nicht mehr als Softwaremiete einzuordnen, wie seinerseits ASP.

2. Das SaaS Geschäftsmodell

Eine genaue Definition zu SaaS gibt es nicht, dafür aber viele

unterschiedliche Ansichten. Teilweise wird auch vertreten, dass SaaS

lediglich eine Fortführung von ASP sei oder ASP selbst, welches durch die

Namensänderung wieder vertriebstauglich gemacht werden sollte. 8

Der deutsche Artikel der freien Internetenzyklopädie Wikipedia 9 beschreibt

SaaS als ein Softwaredistributionsmodell, wonach Software als

Dienstleistung basierend auf Internettechnologie bereitgestellt, betreut und

6

Grohamm, W., „Von der Software zum Service“, S. 17

7

so auch Stanoevska-Slabeva, Wozniak in: Stanoevsak-Slabeva / Wozniak / Ristol, „Grid

and Cloud Computing“, S. 49

8

SaaS als neuer Begriff für ASP: Grohamm, W., „Von der Software zum Service“, S. 15

9

obwohl Wikipedia nicht wissenschaftlich ist, gibt es doch einen wertvollen Eindruck

wieder, wie die Allgemeinheit ein bestimmtes Thema einordnet.

- 4 -


etrieben wird. 10 Vorteilhaft an dieser Beschreibung ist, dass sie mit dem

Begriff der Dienstleistung arbeitet, die auch schon in dem englischen Wort

Service“ zum Ausdruck kommt. Ansonsten bleibt die Erklärung

mehrdeutig, da auch viele andere Angebote sich auf die Internettechnologie

stützen, ohne gleich dem SaaS Modell zu unterliegen.

Eine durchgängige Auffassung besteht jedenfalls darin, dass auf die

Software per Webbrowser oder mittels anderweitiger Clients, die die

bildschirmhafte Darstellung erlauben, zugegriffen wird und sich SaaS

allgemein durch das pay-per-use Prinzip auszeichnet, also die

nutzungsabhängige Bezahlung. 11 Hervorzuheben ist aber auch, dass ein

Zugriff direkt auf die Programmierschnittstellen 12

- 5 -

(Application

Programming Interfaces, kurz: APIs) der angebotenen Software erfolgen

kann und nicht nur per Webbrowser. 13

Bsp.: Hierbei kann der entfernt liegenden Software eine oder mehrere Variablen beim

Aufruf übermittelt werden, mit denen die Software nun bestimmte Rechenoperationen

ausführt. Am Ende erhält das aufrufende Programm das gewünschte Ergebnis zurück. Dies

funktioniert dann sozusagen im Verborgenen ohne Einfluss eines Menschen. Beispiel: Bei

einem Additionsprogramm würde diesem zwei Zahlen übergeben werden. Das Programm

addiert diese und sendet die Summe als Ergebnis an das aufrufende Programm zurück.

Die in dieser Form genutzte Software, die sich auch in der Cloud finden

lässt, beschreibt SaaS wie auch Cloud Computing wohl in seiner reinsten

Form. Eine Bildschirmausgabe der Software erfolgt nicht, die

Softwarenutzung findet im Verborgenen statt. Zweck dieser

Softwarenutzung ist allein die zur Verfügung gestellte Funktionalität (z.B.

Addition zweier Zahlen). Dem aufrufenden Nutzer ist es gleichgültig wie

die Software zu dem Ergebnis kommt, solange das Ergebnis korrekt ist bzw.

der vertraglichen Leistungsbeschreibung entspricht.

10

http://de.wikipedia.org/wiki/Software_as_a_Service (Stand: 15.07.2010)

11

statt vieler: Stanoevsak-Slabeva / Wozniak / Ristol, „Grid and Cloud Computing“, 43

12

http://www.itwissen.info/definition/lexikon/application-programming-interface-API-

Programmierschnittstelle.html

13

Stanoevsak-Slabeva / Wozniak / Ristol, „Grid and Cloud Computing“, 43


Richtigerweise wird SaaS auch den Prinzipien des Cloud Computing

zugeordnet. 14 Diese sog. Wolke wird man sich als eine Ansammlung von

allerlei Applikationen vorstellen können, von der Software bis zur Hardware.

Wie eine echte Wolke nicht greifbar ist, ist auch das Cloud Computing nicht

greifbar, da es sich durch ein hohes Maß an Virtualisierung auszeichnet. Die

angebotenen Leistungen (Software oder Hardware) liegen nur virtuell vor

und werden emuliert. 15 Wer auf die Cloud zurückgreift, kann Rechen-

leistung oder Speicherplatz beziehen, aber auch Softwareapplikationen.

Letzteres dürfte hierbei als kleinstmögliche Einheit zu finden sein, wie z.B.

das Addieren von zwei Zahlen, aber auch in Form von größeren und

umfangreichen Einheiten, wie z.B. in Form einer Textverarbeitung.

Falsch hingegen ist, die zum ASP ergangene vertragstypologische

Einordnung als Mietvertrag paradigmenhaft auf SaaS-Angebote zu

übertragen und in jedem SaaS-Angebot eine Softwaremiete zu sehen. 16

Denn dabei wird übersehen, dass sowohl im Bereich des Cloud Computing

wie auch im Bereich von SaaS eine Modularisierung der EDV-Prozesse

stattfindet und nicht mehr ein Gesamtsystem im Vordergrund steht. 17

Vielmehr werden einzelne Aufgaben bis auf die kleinstmögliche Einheit

zusammengeschrumpft, so dass am Ende die Funktionserfüllung im

Vordergrund steht und nicht mehr die darunter liegende Software oder

Hardwarebasis, mit welcher eine bestimmte Funktionserfüllung erreicht

wird.

Fälschlicherweise wird SaaS oft auch als mehrmandantenfähig (multi

tenancy) beschrieben, um damit eine Abgrenzung zu ASP vorzunehmen,

wonach Software individuell für jeden Nutzer als eigene Instanz installiert

werden müsste (single tenancy). 18 Zwar mag es zu Beginn von ASP

überwiegend nur solche Software gegeben haben, die für jeden Nutzer eine

individuelle Installation erforderte, wodurch Skaleneffekte wieder

14

Schuster, F. / Reichl, W., CR 2010, 38, 39; Niemann, F. / Paul, J., KuR 2009, 444, 445

15

Bierekoven, C. ITRB 2010, 42

16

so wohl Schuster, F. / Reichl, W., CR 2010, 38, 41; Feil, T., Software as a Service;

Schulz, C. / Rosenkranz, T., ITRB 2009, 232, 233

17

Stanoevsak-Slabeva / Wozniak / Ristol, „Grid and Cloud Computing“, 44

18

Pohle, J. / Ammann, T., KuR 2009, 625, 626

- 6 -


neutralisiert wurden. ASP gibt es nunmehr aber auch in der Form, dass eine

installierte Software mehrere Benutzer bedienen kann. Im SaaS Bereich ist

es ebenso möglich, das System auf eine single tenancy Architektur

aufzubauen. 19

An dieser Stelle ist auch zu ergänzen, dass das oft zitierte Beispiel der

elektronischen Energie, wonach Software wie Strom aus der Steckdose

bezogen werden kann 20 nicht dem SaaS Prinzip gerecht wird. Denn nach

diesem Modell liegt der Fortschritt von SaaS lediglich darin, dass viele

Kunden einen Stromgenerator zur Stromerzeugung nutzen, wobei der

Stromgenerator den SaaS Anbieter darstellen soll. Das SaaS Modell und

somit das Cloud Computing können aber wesentlich mehr leisten, da sie die

Modularisierung der Leistung erlauben. Das bedeutet, dass sich eine

Software oder der Speicherplatz aus vielen Teilsystemen zusammensetzen

können und sich lediglich dem Nutzer gegenüber als ein einheitliches

System zeigen. Auf das o.g. Strommodell übertragen bedeutet dies speziell

für SaaS, dass der Stromgenerator selbst nicht mehr als Ganzes an einem

Ort steht, sondern seine Einzelteile, wie Schrauben oder Gehäuse, auf der

ganzen Welt verstreut sind und erst virtuell zu einer Einheit

zusammengesetzt werden. Zwar würde in diesem Beispiel der Generator in

der Realität denklogisch nicht mehr funktionstüchtig sein (er wäre als

solches gar nicht existent). Im virtuellen Raum ist eine Funktionalität aber

dennoch möglich, weil die einzelnen Komponenten durch das Internet

miteinander verbunden sind und zusammenarbeiten können.

Um das Prinzip SaaS besser verstehen und damit die notwendige

vertragstypologische Einordnung später vornehmen zu können, wie auch

Unterschiede zum ASP Geschäftsmodell ausfindig machen zu können, lohnt

sich der Blick auf das Umfeld, in dem sich SaaS bewegt. Dies erscheint

deswegen sinnvoll, da hier die gleichen Techniken benutzt werden wie bei

SaaS und somit durch Rückschlüsse die grundlegenden Ideen verständlicher

werden. Darüber hinaus erleichtert dies auch die Abgrenzung zum ASP

19 White Paper by Sapien: http://www.sapiensoftware.com/multitenant.aspx (21.07.2010)

20 Pohle, J. / Ammann, T., KuR 2009, 625, 626

- 7 -


Geschäftsmodell, welches zu einer Zeit entwickelt wurde, in der Cloud

Computing noch kein Begriff war.

Neben SaaS gibt es Infrustucture as a Service (IaaS) und Platform as a

Service (PaaS) Alle drei Varianten stellen eine unmittelbare

Konkretisierung des Cloud Computing dar. 21

a) IaaS

Unter IaaS versteht man die Bereitstellung von Rechnerressourcen, wie

Prozessorleistung oder Speicherkapazitäten, also der Infrastruktur. 22

Allerdings wird hierbei keine Hardware im ursprünglichen Sinne zur

Verfügung gestellt, sondern typischerweise ein virtuelles Abbild in Form

eines Services. 23 Ein Beispiel hierfür ist der Simple Storage Service (S3)

von Amazon, der einen Zugriff auf einen virtualisierten, flexibel

skalierbaren Datenspeicher ermöglicht. 24 Amazon bietet bei diesem Service

die Möglichkeit zur Speicherung und selbstverständlich den Abruf von

Daten an. Der Zugriff erfolgt über eine spezielle Schnittstelle (API), so dass

es letztendlich möglich ist, den virtuellen Datenspeicher wie eine lokale

Festplatte zu nutzen. Wichtig hierbei ist, dass die angebotene Leistung die

Datenspeicherung an sich ist. Denn da das ganze System virtualisiert

aufgebaut ist, befinden sich die Daten niemals auf einem eindeutig

identifizierbaren, realen Datenspeicher.

- 8 -

25

Dies könnte bei der

vertragstypologischen Einordnung als Mietvertrag zu Problemen führen, da

kein eindeutig identifizierbarer Mietgegenstand (z.B. Festplatte) vorhanden

ist. Das gleiche gilt wenn Rechenleistungen angeboten werden. In diesem

Fall ist es schlicht unbekannt, welcher Prozessor eine Aufgabe berechnet hat,

teilweise werden Aufgaben aufgespaltet und von verschiedenen Prozessoren

berechnet.

21 Spies, A., MMR 2009, XI; Stanoevsak-Slabeva / Wozniak / Ristol, „Grid and Cloud

Computing“, S. 51 (Part. 4.3.2.); Niemann, F. / Paul, J., KuR 2009, 444, 445; Nägele, T. /

Jacobs, S., ZUM 2010, 281, 282

22 Stanoevsak-Slabeva / Wozniak / Ristol, „Grid and Cloud Computing“, Part. II 4.3.2.1

23 Stanoevsak-Slabeva / Wozniak / Ristol, „Grid and Cloud Computing“, Part II 4.3.2.1

24 http://www.computerwoche.de/management/cloud-computing/1902791/

25 Söbbing, T., MMR 2008, XII, XIV


Zum Verständnis: In der realen Welt gibt es ebenfalls Beispiele, die dem IaaS Prinzip nahe

kommen. Ein Beispiel ist das Prinzip der dynamischen (chaotischen) Lagerhaltung. 26 Es

dient dazu in einer Lagerhalle den Lagerplatz optimal auszunutzen. Dieser besteht aus

vielen Regalen, die bestimmte Abstellflächen aufweisen. Wird ein Paket in das System

gegeben, berechnet ein Computer den günstigsten Lagerplatz und legt das Paket per

Automationstechnik dort ab. Niemand außer dem Computer weiß, in welcher der

millionenfach vorhandenen Abstellflächen sich das Paket befindet. Entsteht z.B. die

Situation, dass nur noch kleinere Lagerflächen vorhanden sind und ein größeres Paket

abgelegt werden muss, besteht die Möglichkeit, zwei nebeneinander liegende kleine Pakete

so umzulagern, dass dadurch eine größere Lagerfläche geschaffen wird. D. h. das System

ist in ständiger Bewegung. Bisher gibt es noch keine solchen Systeme, die Lagerflächen für

außenstehende Dritte anbieten. Daher hat sich auch noch nicht die interessante rechtliche

Frage gestellt, ob hier noch Mietvertragsrecht anzuwenden wäre. Das Ergebnis könnte

jedenfalls ähnlich wie bei IaaS-Systemen ausfallen.

b) PaaS

PaaS ist eine Abstraktionsschicht zwischen SaaS und IaaS. 27 Zielgruppe

hierfür sind insbesondere Softwareentwickler, die mittels PaaS leicht und

skalierbar ihre Softwareapplikationen anbieten können und dabei auf

verschiedene IaaS Services zurückgreifen können. Hierdurch wird der

Betrieb der Applikationen extrem flexibel und kostenübersichtlich.

Das Prinzip soll an einem Vergleich mit herkömmlichen Methoden beschrieben werden.

Nach herkömmlichen Strukturen muss sich der Softwarebetreiber oder -entwickler, z.B.

eines Online Shops, selbst administrativ um die notwendige Infrastruktur zum Betrieb

seiner Webapplikation kümmern. In der Regel wird hierzu neben Speicherplatz auch ein

Webserver benötigt, sowie die Anbindung an Datenbanken, eine Accountverwaltung oder

ein Emailsystem. Gerade bei starken Schwankungen im Bereich der notwendigen

Ressourcen oder auch bei starkem Wachstum des Angebots muss das System kontinuierlich

angepasst werden, um Betriebsausfälle zu vermeiden, z.B. durch Zukauf von zusätzlichem

Speicherplatz. Durch PaaS wird dem Applicationprovider diese Arbeit abgenommen und

eine umfassende Betriebsumgebung für die Software zur Verfügung gestellt. Vor allem

kann er sich bei der Softwareherstellung den bereitgestellten API’s des PaaS Anbieter

bedienen und somit z.B. direkten Zugriff auf Datenbankfunktionen erhalten. Der PaaS

Anbieter sorgt dafür, dass sich die Systemumgebungsbedingungen den Anforderungen der

26 http://de.wikipedia.org/wiki/Dynamische_Lagerhaltung (Stand: 06.07.2010)

27 Stanoevsak-Slabeva / Wozniak / Ristol, „Grid and Cloud Computing“, Part II 4.3.2.2

- 9 -


Software anpassen, so dass für den Softwarebetreiber eine überschaubare pay-as-use

Kostenstruktur entsteht. 28

Auch bei diesem Modell ist zu beachten, dass dem Softwareanbieter gerade

keine konkreten Ressourcen zu Verfügung gestellt werden. Wo früher eine

konkrete Datenbank gemietet wurde, erfolgt nach diesem Model lediglich

die Aufforderung (durch entsprechenden Programmcode) an den Anbieter,

eine bestimmte Information „datenbankmäßig“ einzulagern und bei Bedarf

den Abruf der Daten zu gewährleisten. Bei einer vertragstypologischen

Einordnung gilt es dies zu beachten. Es muss sich auch hier wiederum die

Frage gestellt werden, ob noch von Mietvertragsrecht ausgegangen werden

kann.

c) SaaS

Auch bei SaaS stehen die Funktionserfüllung einer Software sowie das pay-

per-use Prinzip im Vordergrund. Der SaaS Nutzer kennt nur die Oberfläche

der Software und die vereinbarten Funktionen. Wie dies auf tiefer liegende

technischer Ebenen realisiert wird, ist für den Nutzer nicht relevant. Es

könnte auch der komplette Programmcode der Software ausgetauscht

werden, solange sich dadurch nicht das nach außen tretende Verhalten der

Software verändert.

d) Ergebnis

Man kann SaaS nicht erklären und verstehen, ohne die Umgebung zu

berücksichtigen, in der SaaS eingebettet ist. SaaS muss den gleichen Regeln

folgen wie IaaS und PaaS. Dies bedeutet ein hohes Maß an

Virtualisierung. 29 Man muss sich von alten Gedankenstrukturen lösen.

Sowenig bei CloudStorage noch eine reale Festplatte oder ein realer

Prozessor existiert, genauso wenig existiert bei SaaS eine reale Software im

herkömmlichen Sinne, die sich aus einem festen Programmcode

zusammensetzt, über den der Benutzer wie vom Kauf- oder Mietrecht

verlangt, Kontrolle ausüben kann. Bei SaaS hat der Nutzer nur noch

28 http://www.youtube.com/watch?v=3Ztr-HhWX1c (Stand: 06.07.2010)

29 Bierekoven, C. ITRB 2010, 42

- 10 -


Kontrolle über die Funktionen, aber nicht mehr wie diese softwaremäßig

erreicht werden.

3. Unterschiede zum ASP Geschäftsmodell

a) Begriffserklärung

Unter dem Begriff Application Service Provider (ASP) versteht man

überwiegend ein Softwaredistributionsmodell über das Internet oder andere

Netzwerke. Hierbei überlässt der ASP eine bestimmte Software zeitweilig

an einen Nutzer in der Weise, dass der Zugriff und somit die Nutzung der

Software durch ein Computernetzwerk erfolgt und keine lokale Installation

der Software auf dem Rechner des Nutzers vorgenommen wird. 30 Es wird

also lediglich die Bildschirmausgabe zu dem Nutzer übertragen und die

Nutzereingaben zur Software. Im ASP Modell ist es möglich, dass eine

Vielzahl von Nutzern auf nur eine installierte Softwareinstanz zugreifen

können (multi tenancy) oder, wenn die Software dies nicht unterstützt, für

jeden Nutzer eine eigene Softwareinstallation notwendig ist (single

tenancy). 31 Nicht nachvollziehbar ist es jedenfalls, wie bereits oben erwähnt,

dass mit diesem Merkmal eine Abgrenzung zwischen ASP und SaaS

vorgenommen wird. 32 Vielmehr wird man aufgrund des technischen

Fortschritts auch im ASP Bereich eine Angleichung an SaaS annehmen

müssen. 33

Es ist davon auszugehen, dass der ASP in der Regel als Leistung die

Bereitstellung einer ganz bestimmten Software eines Herstellers schuldet. 34

Dabei bedeutet „eine ganz bestimmte Software“ eine genaue Abfolge von

30

Redeker, H., NJOZ 2008, 2917, 2923; in einem Satz abgehandelt: Sedlmeier, T. / Kolk,

D., MMR 2002, 75

31

http://en.wikipedia.org/wiki/Application_service_provider#The_ASP_model, Redeker,

H., NJOZ 2008, 2917, 2923

32

so aber Pohle, J. / Ammann, T., KuR 2009, 625, 626; a.A.

http://en.wikipedia.org/wiki/Multitenancy, wonach „multi tenancy“ Software durch ASP

angeboten wurde; wohl auch Stanoevsak-Slabeva / Wozniak / Ristol, „Grid and Cloud

Computing“, Part II 3.6.2, wonach das ASP Model bedeutet, „… that the application is

operated in a centralized manner by the ASP and is offered in the same form to many

customers.“

33

Stanoevsak-Slabeva / Wozniak / Ristol, „Grid and Cloud Computing“, Part II 3.6.2

34 Schulz, U., IX extra 9/2007, S. II

- 11 -


Befehlen, wie z.B. in einem Buch die genaue Abfolge der Worte den Inhalt

bestimmt. Der Vertrag ist folglich nur erfüllt, wenn der Nutzer Zugriff auf

eine bestimmte Version eines eindeutigen Softwareprodukts erhält und nicht,

wenn beispielsweise ein Office Programm eines anderen Hersteller zur

Verfügung gestellt wird oder eine andere Version des ursprünglichen

Programms. Denn nur so lässt sich erklären, dass der Bundesgerichtshof in

einer konkret entschiedenen und viel beachteten Entscheidung einen ASP

Vertrag als Mietrecht einordnen konnte. 35 Denn ein Mietvertrag ist

schlechthin nicht möglich, wenn der Mietgegenstand nicht konkretisiert ist,

da er nur virtuell existiert. Deswegen muss der Kunde im Rahmen eines

ASP Vertrages auch gesondert die Entscheidung über Versionen und

Upgrades treffen und bezahlen. 36 Nur wenn die Zulässigkeit von Upgrades

in den Vertrag einbezogen wurden, kann von einer Leistungserfüllung auch

dann ausgegangen werden, wenn der ASP Anbieter eine nächst höhere

Version installiert. Andernfalls ist er hierzu nicht berechtigt.

Parallelen: Obwohl der Begriff ASP dem Softwarevertrieb zugeordnet wird, ist das Prinzip

als solches ein wirtschaftlich nicht unbekanntes Modell. Hierbei handelt es sich um die

kostengünstige Auslagerung eigener Anwendungen auf Dritte unter gleichzeitiger

Zurückholung der Anwendung in Form der Miete, von Diensten oder Werkerstellung, was

auch unter dem Begriff Outsourcing Bekanntheit erlangte. Ein klassisches Beispiel für

einen ASP stellen Fluglinien oder Stromanbieter dar. So kann eine Fluggesellschaft dass

Reisen mittels Flugzeug kostengünstiger und effizienter anbieten als eine Einzelperson, die

sich selbst ein Flugzeug anschaffen und betreiben müsste und auch sämtliche damit

verbundenen Folgekosten zu tragen hätte. 37 ASP beschreibt folglich dieses Prinzip speziell

für den Softwaremarkt. Eine Aussage darüber, wie dies rechtlich einzuordnen wäre, kann

damit aber noch nicht getroffen werden. Zwar entsprach der vom BGH entschiedenen Fall

von ASP mietvertraglichen Regeln. Einer anderen Einordnung steht diese Entscheidung

jedoch nicht entgegen, wenn die Vertragsparteien andere Zwecke verfolgen als die Miete.

Denn Outsourcing kann in den unterschiedlichsten Ausprägungen vorkommen.

b) Unterscheidungsmöglichkeit

Eine Abgrenzung zwischen dem ASP Geschäftsmodell und SaaS fällt

zunehmend schwerer, obwohl beide Modelle jeweils andere Strategien

35 BGH NJW 2007, 2394

36 Schulz, U., IX extra 9/2007, S II

37 Beispiel aus: Brain, M., „How ASPs Work“

- 12 -


verfolgen. 38 Vieles, das heute an Begrifflichkeiten mit SaaS in

Zusammenhang gebracht wird, wurde auch schon zu Zeiten von ASP

verwendet, so z.B. der oft zitierte Vergleich des Modells zu Stromnetzen. 39

Eine Unterscheidung anhand der Mehrmandantenfähigkeit der Software

(multi tenancy) 40 kann jedenfalls genauso wenig vorgenommen werden wie

die Einordnung von ASP als Oberbegriff für SaaS. 41 In dem vom

Bundesgerichtshof konkret entschiedenen Fall wurde von dem Gericht ein

ASP Vertrag angenommen und dieser als den mietvertraglichen Regelungen

unterliegender Vertrag eingeordnet. Dies lässt nur die einzige

Schlussfolgerung zu, dass in dem entschiedenen Fall nur ein eindeutig

bestimmbarer Mietgegenstand geschuldet war, also ein ganz bestimmtes

Softwareprodukt hinsichtlich Hersteller, Version und Abfolge der

Programmbefehle. 42 Der ASP wäre somit nicht in der Lage, die Leistung zu

erfüllen, wenn er die Software austauschen würde, auch wenn damit der

Funktionsinhalt nicht geändert würde. 43 Schon eine andere Softwareversion

desselben Produkts könnte gegen eine Leistungserfüllung stehen (vor allem

ein „Downgrade“ zur einer älteren Version) auch wenn sich für den Nutzer

in der Anwendung nichts ändern würde. Auch wird der Nutzer ohne

besondere Regelung keinen Anspruch darauf haben, dass immer die aktuelle

Version eingespielt ist.

Parallelen: Auch im Wohnraummietrecht besteht kein Anspruch, dass die Wohnung in ein

Luxusappartement umgebaut wird, noch hat der Vermieter das Recht, die alte Wohnung

abzureißen und eine modernere an ihre Stelle zu setzen. Lediglich Erhaltungspflichten

bestehen.

Zumindest bei umfangreicheren Office Anwendungen, ERP Systemen

(Enterprise Resource Planning) oder CRM System (Customer-Relationship-

Management) erscheint es offensichtlich, dass ein Austausch der Software

im Rahmen des (Miet-) Vertrages unmöglich ist, auch wenn die

38

vgl.: Stanoevsak-Slabeva / Wozniak / Ristol, „Grid and Cloud Computing“, Part II 3.6.2

39

So schon im Jahr 2000: Knolmayer, Application Service Providing (ASP),

Wirtschaftsinformatik 42 (2000) 5, S. 443-446

40

so aber: Pohle, J. / Ammann, T., KuR 2009, 625, 626; Helwig, B. / Koglin, O., S. 176

41

Helwig, B. / Koglin, O., S. 176

42

Hannemann, T. / Wiegner, M., „Münchener Anwaltshandbuch Mietrecht“, A III § 8 Rn.

68: sog. essentialia negotii des Mietvertrage

43

z.B. Microsoft Office gegen Open Office

- 13 -


Funktionserfüllung dadurch nicht gefährdet würde (Bsp: Open Office statt

Microsoft Word). Ein anderes Bild entsteht jedoch, wenn man sich von

dieser softwarespezifischen Ebene entfernt und auf eine rein funktionale

Ebene begibt, wo nicht mehr die Software an sich im Vordergrund steht,

sondern die damit erzielbare Funktion.

Eine Software kann auch lediglich einer Funktionserfüllung dienen. Ihr einziger Sinn

könnte darin liegen, zwei Zahlen zu addieren oder eine Formatumwandlung vorzunehmen,

z.B. vom .doc- in das .pdf-Format (Portable Document Format). Um dieses Ziel zu

erreichen, gibt es unendlich viele Möglichkeiten und Wege, die aber zum gleichen Ziel

führen („viele Wege führen nach Rom“). Obwohl sich die Software ändern kann, muss das

Ergebnis jedenfalls am Ende gleich bleiben. Ein Nutzer einer solchen Software hat somit

nur Interesse an dem Ergebnis. Der Anbieter wird nur diese Funktion schulden wollen. Die

Annahme eines Mietvertragsverhältnisses erscheint hier zumindest abwegig, da es dem

Nutzer nicht darauf ankommt, dass nur ein ganz bestimmtes Umwandlungsprogramm

genutzt wird.

Auf einer funktionalen Ebene spielt der unterliegende Softwarebau keine

Rolle mehr, solange die Funktionserfüllung in den vorgegebenen

Parametern gewährleistet ist. Gerade bei Webanwendungen wird dies

besonders deutlich, wie z.B. die kostenlosen Webmail-Dienste. Denn dort

kann in einem gewissen Maß zwischen der Weboberfläche und der darunter

liegenden Software getrennt werden. Für den Nutzer völlig unsichtbar kann

sich die Software im Hintergrund ändern, ohne dass die auf Funktionalität

ausgerichtete Weboberfläche geändert werden muss. In diesem

Zusammenhang ist auch SaaS zu verstehen. Durch die Granulierung der

Software in funktionserfüllende Einzelbestandteile, wird diese extrem

flexibel einsetzbar und austauschbar. Dadurch füllt sie die Cloud.

Der Unterschied zwischen ASP und SaaS wird zunehmend auch darin

liegen, dass die Softwarehersteller selbst oder über Partner als Hoster

auftreten und ihre Software als Service im Rahmen von SaaS anbieten. 44

Meiner Ansicht nach steht bei SaaS nicht mehr die Bereithaltung oder

Vermietung einer bestimmten Software im Vordergrund, wie bei ASP. Bei

44 Schulz, U., IX extra 9/2007, S. IV

- 14 -


SaaS geht es darum, Lösungen zu bestimmten Problemstellungen zu liefern.

„The user pays for the functionality of the software only for the time and

intensity of each specific usage”. 45 Wie das Ergebnis berechnet wird, spielt

für den Anwender keine Rolle, solange er mit dem zur Verfügung gestellten

Angebot zu dem vereinbarten Erfolg kommt (Bsp.: Abruf der Email).

Für SaaS gibt es zurzeit viele Beispiele, die bisher nicht explizit mit SaaS in

Verbindung gebracht wurden, aber nach der hier vertretenen funktionalen

Ansicht „Software as a Service“ sind. Am bekanntesten sind wohl sog.

Freemail Dienste wie z.B. von GMX , WEB.DE oder Google Mail. Der

Hauptzweck dieser Dienste liegt in der Verwaltung der

Emailkommunikation. Über eine Weboberfläche werden hierbei

verschiedene Möglichkeiten bereitgestellt, um die eigene

Emailkorrespondenz zu organisieren. Ursprünglich wurde hierfür vom

Endnutzer ein lokal installiertes Programm genutzt. Auch diesen

Webdiensten liegt unbestreitbar eine Software zu Grunde, die kaum weniger

umfangreich sein dürfte, als bei einem lokal zu installierenden

Emailprogramm. Dennoch hätte man Probleme damit, die Nutzung dieser

Software, also des Webmail Dienstes, als Mietvertrag einzuordnen. Dies

wohl deswegen, weil die Nutzer solcher Dienste keine Verfügungs- oder

Entscheidungsgewalt über die Software haben. Jeder Nutzer nutzt den

Dienst und somit auch die zugrunde liegende Software, um seine Emails

verwalten zu können. So lange dies möglich ist, ist man glücklich. Auch

Änderungen im Design werden hingenommen. Meist ist man auch froh,

wenn das Design ständig aktualisiert wird und somit dem Stand der Technik

entspricht. 46

Ein anderes Beispiel aus dem kostenlosen Segment sind sog. Onlinevideorecorder. Auch

hier greift der Nutzer wieder per Webbrowser auf das System zu. Dort wird ihm eine

Übersicht über das aktuelle und zukünftige Fernsehprogramm geboten und der Nutzer

erhält die Möglichkeit, Sendungen aufzeichnen zu lassen. Ist dies geschehen, erhält der

Nutzer die Sendung in einem gängigen Videoformat bereitgestellt. Bei diesem Service geht

es dem Nutzer hauptsächlich darum, von ihm bestimmte Sendungen in einem gängigen

Videoformat aufzuzeichnen, so dass er sich die Sendung später anschauen kann. Will man

45 Stanoevsak-Slabeva / Wozniak / Ristol, „Grid and Cloud Computing“, S. 43

46 Kramer, A. / König, P., c’t 23/2008, S. 118

- 15 -


die gleichen Ergebnisse am eigenen Rechner erzielen, ist eine Fernsehkarte notwendig und

eine Software, die das aufzunehmende Fernsehprogramm in einem gängigen komprimierten

Videoformat speichert. Eine reine Softwareinstallation reicht also nicht mehr aus. Auch

diesem Webservice liegt unbestreitbar eine Software zugrunde, die den Zugriff über das

Web ermöglicht und die Videoaufnahmen vornimmt. Aber auch hier hat der Kunde keinen

direkten Einfluss auf die genaue Gestalt der Software. Er wird dies auch nicht wollen. Der

Kunde ist glücklich, wenn er am Ende des Prozesses die aufgenommene Sendung in den

„Händen“ hält.

Zwar sind dies bisher alles Dienste, die überwiegend kostenlos und für

private Anwender bestimmt sind. Es sind aber immer die gleichen

Strukturen erkennbar. Es ist davon auszugehen, das SaaS Dienste zukünftig

vermehrt genutzt werden um alte Techniken zu ersetzen (z.B. den eigenen

Videorecorder). Zum anderen werden sie auch zunehmend im B2B Bereich

angeboten und ermöglichen es, bestimmte Unternehmensaufgaben (z.B.

Kundenverwaltung CRM) ohne Rückgriff auf eine bestimmte Software zu

erledigen. Dabei bleibt der rote Faden erkennbar: Wie bei den oben

genannten Beispielen will der Kunde nur, dass bestimmte Funktionen erfüllt

sind. Dem Kunden ist es gleichgültig, wie dies erreicht wird.

Bisher spielte die vertragliche Einordnung kaum eine Rolle, da die meisten

Dienste kostenlos zu Verfügung gestellt wurden. Somit musste dieses

Vertriebsmodell auch nicht rechtlich bewertet werden. Das wird sich

zukünftig ändern, wenn SaaS zunehmend im B2B Bereich eingesetzt wird

oder sich durch zunehmende Verbreitung Abhängigkeiten entwickeln. Wer

interessengerechte Verträge gestalten will, muss zwischen dem ASP

Geschäftsmodell und dem SaaS Geschäftsmodell zwingend unterscheiden

können. Wird dies nicht getan, sind Fehler und Konflikte vorprogrammiert.

c) Scheitern des ASP Modells

Warum und ob das ASP Modell überhaupt als gescheitert angesehen werden

kann, ist fraglich. Geht man mit der hier vertretenen Ansicht davon aus, dass

SaaS gerade nicht lediglich „alter Wein in neuen Schläuchen“ 47 ist, wird

47 Schüler, P., c’t 23/2008, S. 132

- 16 -


ASP auch zukünftig noch eine Rolle spielen. Nämlich dann, wenn nicht nur

eine Softwarefunktionalität gewünscht ist, sondern der Betrieb und die

Pflege einer ganz bestimmten Software über Netzwerke durch einen Service

Provider.

Zwar haben die inzwischen überwundenen technischen Hürden, wie geringe

Bandbreite, nicht angepasste Systemarchitektur aber auch eine noch

unausgereifte ASP-Architektur 48 die kaum zu Kosteneinsparungen führte,

das Wachstum von ASP abgeschwächt. 49 Nachdem diese Probleme aber als

überwunden angesehen werden dürfen, wird ASP auch zukünftig eine

Rechtfertigung haben, allerdings neben SaaS.

4. Chancen und Risiken von SaaS

Die Chancen von SaaS als eine Form des Outsourcings liegen auf der Hand.

Insgesamt wird der zu betreibende notwendige Aufwand des Benutzers

gesenkt und durch das pay-per-use-Prinzip die Kostenstruktur der

Unternehmens-IT einfacher und planbarer. 50 Dazu kommt, dass durch die

Flexibilität dieser Systeme eine Über- und Unterlizenzierung an Software

verhindert wird, da der Nutzungsbedarf quasi on-time angepasst werden

kann. Eine Unter- oder Überversorgung an IT-Ressourcen wird hierdurch

vermieden. 51 Da die IT-Ressourcen auf Abruf zu Verfügung stehen, bedarf

es zusätzlich keiner langfristigen Beschaffungsplanung. 52 SaaS ermöglicht

zudem die Konzentration auf die Kernaufgaben, da eine eigene IT-

Abteilung nicht mehr betrieben werden muss.

Durch SaaS entsteht eine unbekannte Möglichkeit an Flexibilität bei der

Auswahl der Software. Der Nutzer ist nicht mehr auf einen

Programmanbieter festgelegt, sondern kann bei Bedarf die gleichen

Funktionen auch mit der Software eines anderen Anbieters erhalten oder

48

z.B. Betrieb einer mandantenindividuelle Servicinstanz, Single Tenancy Betrieb

49

Pohle, J. / Ammann, T., KuR 2009, 625

50

Schüler, P., c’t 23/2008, S. 132

51

Schulz, C. / Rosenkranz, T., ITRB 2009, 232, 233

52

Schulz, C. / Rosenkranz, T., ITRB 2009, 232, 233

- 17 -


aufgrund der Modularisierung seinen Softwarebedarf individuell

zusammensetzen. Im Gegensatz zum Lizenzgeschäft, kann der Wechsel

vorher einfach getestet werden, da keine Lizenzen erworben werden müssen

So könnte der Unternehmer ein Interesse daran haben, dass die Urlaubsverwaltung auf

mobilen Endgeräten oder per Telefonleitung in Form einer Spracheingabe möglich ist.

Wenn die bisher eingesetzte Software dies nicht unterstützt, könnte der Unternehmer diesen

Service von einem weiteren SaaS Anbieter problemlos hinzukaufen.

Durch SaaS entsteht aber auch eine neu gewonnene Unabhängigkeit des

Softwareanbieters. Da dieser nicht mehr die Software an sich schuldet,

sondern nur die Softwarefunktionen, behält er die volle Kontrolle über sein

Softwareprodukt. Er kann diese ohne Rückfrage mit den Nutzern verändern,

optimieren oder große Teile neu überarbeiten. Im Rahmen von ASP war

dies aufgrund der mietvertraglichen Einordnung nicht ohne weiteres

möglich. Somit erhält der SaaS Anbieter eine neue Flexibilität im Umgang

mit seiner Software. Es ist auch möglich, Dritte zur Vertragserfüllung

heranziehen, z.B. wenn die eigenen Rechnerressourcen aufgrund einer

Spitzenlast aufgebraucht sind. 53

Beispielsweise könnte bei einer Textverarbeitung die Rechtschreibprüfung von einem

Dritten Anbieter genutzt werden. Man wäre nicht mehr auf die Software zur Prüfung der

Rechtschreibung des Textverarbeitungsprogramms angewiesen. Aber auch der Hersteller

einer Textverarbeitung könnte die Rechtschreibprüfung on-demand durch einen Dritten

durchführen lassen und sich somit auf die eigenen Kernaufgaben konzentrieren.

Versionssprünge braucht es ebenso wenig, denn die Aktualisierung der

Software ist fließend und geschieht quasi „on-the-fly“ während des Betriebs.

Dadurch entfällt auch der Zeitdruck, der bisher oft zu Lasten der Qualität

ging, wenn eine neue Softwareversion angekündigt wurde.

Die Chancen sind aber zugleich auch die Hauptrisiken bei SaaS. Durch das

Auslagern von Softwarefunktionen entstehen Defizite bei der

Gewährleistung von Vertraulichkeit, Integrität und Authentizität der Daten.

Damit geht ein Kontrollverlust über die Software und die Daten einher, da

53 Grohamm, W., „Von der Software zum Service“, S. 59

- 18 -


die Software nicht mehr zentral an einem Ort gesteuert wird. Zwar können

auch bei SaaS Abhängigkeiten entstehen. Diese gab es allerdings auch

schon zuvor, wenn ein Unternehmen sich für ein bestimmtes

Softwareprodukt entschieden hat.

Da die Software nicht mehr Inhouse genutzt wird, ist der Nutzer jederzeit

davon abhängig, dass er Zugriff auf die Software hat. Allerdings ist dies

kein spezifischer Nachteil von SaaS. Denn auch Inhouse Lösungen fallen

regelmäßig aus und die Wartung kann zeitaufwendig sein, wenn keine

eigene IT-Abteilung vorhanden ist und auf externe IT-Betreuer

zurückgegriffen werden muss.

5. Die Vision

Manchmal lohnt es sich einen Blick nach Vorne zu wagen, um die aktuellen

Entwicklungen zu fokussieren und die Zielrichtung zu bestimmen. Dies gilt

auch für die Entwicklungen im Bereich SaaS, wenn man sich hierunter

zunehmend die softwareseitige Lösung von speziellen Problemen und

Aufgaben vorstellt.

Führt man den begonnenen Gedanken des „Datenoutsourcings“ fort, wird

man unweigerlich zu dem Ergebnis gelangen, dass an einem Punkt

sämtliche Geschäftsprozesse und Unternehmensdaten, von den

Personaldaten bis zu den Produktionsdaten, in eine Unternehmensdatenbank

ausgelagert werden könnten.

54

- 19 -

Ob die Verwaltung dieser

Unternehmensdatenbank letztendlich bei dem Unternehmen selbst bleiben

soll oder ausgelagert wird, muss individuell entschieden werden. Die

Gesamtheit dieser Daten sollte sich jedenfalls zentral, in einer hochsicheren

Datenbank mit klar abgestimmten Zugriffsrechten befinden und in

standardisierter Form vorliegen. In einem solchen Fall käme es zu einer

vollkommenen Trennung von Daten und Anwendung (Software). Da die so

gespeicherten Daten in einem standardisierten Datenformat abgelegt werden,

entsteht eine hohe Flexibilität bei der Nutzung der Anwenderprogramme mit

54 Herrmann, W., „Grundlagen des Cloud Computing“, S. 3


der Folge, dass jede Software sofort ohne Datenmigration mit den Daten

arbeiten kann.

Mit den losgelösten und verselbständigten Unternehmensdaten, die von

einer Software unabhängig existieren, lässt sich nun nach Belieben arbeiten.

Dies könnte wie bisher durch eine lokal installierte Software geschehen, die

die Unternehmensdaten aus der zentralen Datenbank liest und die

Ergebnisse zurück schreibt. Es könnten aber auch externe Softwareanbieter

die Aufgaben einer herkömmlichen Inhouse Software übernehmen. Hierzu

würde dem SaaS Anbieter ein individueller und beschränkter Zugang auf

die zentrale Datenbank gewährt. Dabei würden nur die Informationen, die

der Anbieter zu Funktionsausübung seiner Software benötigt,

herausgegeben, ähnlich der Herausgabe von Unternehmensdaten an ein

Steuerschätzungsbüro. Mit diesen Daten könnte die Software des SaaS

Anbieters nun ausgeführt werden.

Dabei kann dies eine simple Berechnung sein, die keine sichtbare Eingabeoberfläche

benötig da der Dateninput per API direkt an die Software erfolgt. Mit der Software kann

aber auch eine Eingabemaske im Internet erstellt werden, z. B. zur Eingabe von

Urlaubsanträgen.

Das Ergebnis der Software wird am Ende wieder in standardisierter Form in

die Datenbank geschrieben oder auf andere Weise in der Realität abgebildet,

(z. B. durch Versendung von Mahnbescheiden).

Eine solche Vorgehensweise hätte erhebliche Vorteile. Der Anwender

würde hierdurch unabhängig von einem Softwareanbieter und einem

Softwareprodukt. Einzige und wichtigste Voraussetzung hierbei wäre, dass

die Daten in einem standardisierten Format (wie XML) vorlägen und in

diesem Format beibehalten würden. 55

Es liegt auf der Hand, dass bei dieser Methode, der Datenstandardisierung

und Datenzentralisierung Software nur noch einem Werkzeug ähnlich

55 hierzu: Lundblad, in: Sjöberg, C., „Legal Management of Information Systems“, S. 399

ff.

- 20 -


angewendet wird. Der Softwarehersteller schuldet somit nur noch den

Verarbeitungserfolg, so wie er vereinbart wurde. Dadurch wird Software

zum Service.

6. Ergebnis

SaaS ist nicht ein neuer Aufguss von ASP und schon gar nicht kann hierbei

von altem Wein in neuen Schläuchen gesprochen werden. Um das SaaS

Prinzip verstehen zu können, muss man das Umfeld betrachten und

verstehen, in dem SaaS zu finden ist. Wer SaaS nutzen will, hat auch ein

verändertes Vertragsziel im Sinn, welches vom Erfolgscharakter geprägt ist.

SaaS bleibt Outsourcing von Geschäftsbereichen, kann aber nicht mit ASP

in einen Hut geworfen werden.

ASP ist vergleichbar einer Reise von A nach B in einem ganz bestimmten Reisegefährt

(Flugzeug, nicht Zug). SaaS ist vergleichbar einer Reise von A nach B, wo das Reisegefährt

jedoch irrelevant ist und es lediglich darauf ankommt, dass man das Ziel erreicht. Wer

hierbei dennoch komfortabel und schnell reisen will, muss dies vertraglich im Vorfeld

regeln, in sog. Service-Level-Agreements.

Auch in datenschutzrechtlicher Hinsicht macht das SaaS Geschäftsmodell

Sinn. Die immer höher werdenden Anforderungen an den Datenschutz im

Umgang mit personenbezogenen Daten verlangen von den Betreibern von

Datenverarbeitungsanlagen immer sicherere technische und organisatorische

Schutzmaßnahmen. Dies führt zwangsläufig zu höheren Kosten. Die

Auslagerung von Unternehmensaufgaben ist somit nur folgerichtig, wenn

auch die Fragen nach einem vertraulichen, sicheren und ungestörten Zugang

zu den Unternehmensdaten beantwortet werden können. Aus diesem Grund

sind SaaS und Datenschutz nicht zwingend ein Widerspruch.

- 21 -


II. Vertragstypologische Einordnung

1. Einführung

In diesem Abschnitt soll nun die rechtliche Einordnung von SaaS untersucht

werden. Dabei soll gezeigt werden, dass SaaS kein Softwaremietvertrag ist,

weil damit den Interessen der Parteien nicht gedient werden kann.

Erst wenn die Frage nach der vertraglichen Einordnung sinnvoll geklärt ist,

kann in einem nächsten Schritt die Überlegung nach notwendigen

Vertragsinhalten und somit nach den notwendigen Service Level

Agreements vorgenommen werden. Da die Gerichte regelmäßig versuchen

einen Vertrag den gesetzlichen Vertragstypen zuzuordnen, ist man gut

beraten, sich schon bei dem Vertragsentwurf hierzu einige Gedanken zu

machen. Im Ergebnis hängt es jedenfalls nicht davon ab, ob die Beteiligten

den SaaS Vertrag als Mietvertrag deklarieren. 56 Denn die vertragliche

Einordnung zu einem der vom Gesetz vorbestimmten Vertragstypen

bestimmt sich nach dem vertraglichen Gegenstand, also dem Inhalt der

zugrunde liegenden Willenserklärungen und nicht nach der

Vertragsüberschrift. 57 Dies wird vor allem dann wichtig, wenn die Parteien

eine Regelung übersehen haben, die durch das Gesetz gefüllt werden muss

oder wo eine Vereinbarkeit mit AGB Recht bestehen muss.

Nicht übersehen werden darf auch, dass die vertragliche Umsetzung im

Rahmen von SaaS Anwendungen in der Praxis eigenen Regeln folgt und die

theoretische Behandlung dieses Themas meist zu abstrakt und praxisfern

erfolgt. 58 Da technisches Neuland meistens in den USA zuerst betreten wird,

bestehen dort schon vertragliche Formulierungen, die zu einem späteren

Zeitpunkt durch eine deutsche Rechtsabteilung angepasst werden müssen. In

diesem Fall werden die amerikanischen Standardformulierungen als Vorlage

benutzt, welche in Absprache mit dem Mutterkonzern in den USA in das

56 Weidenkaff, in: Palandt, BGB, Vor. § 433, Rdnr. 3

57 Weidenkaff, in: Palandt, BGB, Vor. § 433, Rdnr. 3

58 dies konnte der Autor in einem Gespräch mit der Rechtsabteilung eines großen

Softwarehauses erfahren.

- 22 -


ausländische Recht transformiert werden. 59 Probleme entstehen dann

zumeist bei der Vereinbarkeit mit dem deutschen AGB Recht, welches in

den USA als unbekannt gelten darf. Ebenfalls unbekannt ist in den USA die

deutsche Unterscheidung der verschiedenen Vertragstypen durch das

Gesetz. 60 Aus diesem Grund wird in amerikanischen Verträgen das Thema

SaaS als eine Art Dienstvertrag eingeordnet, ohne dass hiermit das deutsche

Dienstvertragsrecht berücksichtigt würde. Bei der Übersetzung der Verträge

in das deutsche Recht werden die einzelnen abgrenzbaren Leistungen je

nach ihrem Zweck dem jeweiligen deutschen Vertragstyp zugeordnet, so

dass ein zusammengesetzter Vertrag entsteht. 61

Probleme entstehen insbesondere auch bei der Vereinbarkeit mit dem

deutschen oder europäischen Datenschutzrecht. So erfolgt in der Praxis

teilweise der Zugriff auf ein SaaS Angebot über Server, die weiterhin in den

USA stehen. Bleibt es hierbei und werden die Angebote nicht auf Servern

innerhalb der EU abgelegt, ist bei der Übersetzung der Verträge in das

deutsche Recht das „Safe Harbour Prinzip“ anzuwenden und vertraglich zu

regeln, bevor personenbezogene Daten in die USA übertragen werden. Bei

der Anpassung der Verträge sind nunmehr insbesondere auch die

Anforderungen von § 11 BDSG zu berücksichtigen.

In den USA scheint zudem eine große Skepsis bei dem Thema der

Vertragsstrafen zu bestehen. 62 Regelungen über Vertragsstrafen werden nur

ungern oder überhaupt nicht in die Verträge aufgenommen. Lediglich bei

guten Gründen, die der Nutzer vorbringen muss, wird über Vertragsstrafen

verhandelt. In den Standardformulierungen bleiben diese jedoch

überwiegend unberücksichtigt.

Eine Regelung zur Verfügbarkeit des Systems, die sog. System availability,

besteht nur in dem bekannten und allgemein gängigen Umfang. Eine

Vereinbarung von genau definierten Messpunkten, wie Reaktionszeiten des

59

zu dieser Problematik: Söbbing, T. / Limbacher, S., MMR 7/2009, S. XXIX

60

Wulf, D., NJW 2000, 1451

61

so die Mitteilung aus einem Telefongespräch.

62

Rückschluss aus Telefoninterview

- 23 -


Systems, wird skeptisch betrachtet, da dies zu einer nicht mehr

kontrollierbaren Haftung des SaaS Anbieters führen kann.

Zugegeben, vieles was in der Rechtswissenschaft diskutiert wird, erscheint

für die Kautelarpraxis zu sperrig und schlecht handhabbar. Allerdings

können Probleme nur gelöst werden, wenn zuvor darüber diskutiert wurde.

Deswegen soll im Folgenden rechtswissenschaftlich vorgegangen werden

und an geeigneter Stelle der Bezug zur Praxis gezogen werden. Aus diesem

Grund soll zunächst in der notwendigen Kürze auch das Thema zur

Sachqualität von Software angerissen werden.

2. Sachqualität von Software

Das die Sachqualität von Software gegeben ist, kann wohl als heute

herrschende Meinung in Rechtsprechung und Literatur gelten. 63 Dies auch

deswegen, weil der BGH schon jede noch so entfernt liegende Verbindung

der Software mit einem Speichermedium ausreichen lässt, um die

Sachqualität anzunehmen. 64 Da jede Software zum Abspielen irgendwo

materialisiert sein muss, verbietet sich hiernach schon die Annahme,

Software nicht als Sache zu betrachten.

Diese Diskussionen werden jedoch meist nur dann geführt, wenn es um eine

vertragliche Einordnung als Miet- oder Kaufvertrag geht. 65 Sie können

außer Betracht bleiben, wenn der zugrunde liegende Vertrag ein Dienst-

oder Werkvertrag ist. 66 Denn dort wird nicht eine Sache geschuldet.

Im Rahmen von SaaS Verträgen kann für die weitere Betrachtung an dieser

Feststellung festgehalten werden, zumal in der Rechtspraxis eine andere

Meinung kaum mehr vertretbar ist. Nimmt man für SaaS Verträge jedoch

63

für viele: BGH NJW 2007, 2394; Redeker, H., NJOZ 2008, 2917; Sedlmeier, T. / Kolk,

D., MMR 2002, 75

64

BGH NJW 2007, 2394

65

Redeker, H., NJOZ 2008, 2917, 2922

66

nicht jedoch bei einem Werklieferungsvertrag gem. § 651 BGB

- 24 -


keine Softwaremiete mehr an, wie noch bei ASP Verträgen, spielt die

Sachqualität von Software ohnehin keine Rolle mehr.

3. Typengemischter Vertrag

Der typengemischte Vertrag in seiner Form als Typenkombinationsvertrag

zeichnet sich dadurch aus, dass die Parteien mehrere gleichwertige

Hauptleistungen schulden, die mehreren unterschiedlichen Vertragstypen

entsprechen. 67 Der Typenkombinationsvertrag kann in seiner Gesamtheit

einem einheitlichen Vertragstyp zugeordnet werden, wenn eine Leistung

prägend für den gesamten Vertrag wirkt oder sich ein Schwerpunkt

ermitteln lässt. Kann eine solche Einordnung aufgrund der

Verschiedenartigkeit der einzelnen Leistungen nicht vorgenommen werden,

ist für jeden Vertragsteil auf den Vertragstypus abzustellen, der den

rechtlichen oder wirtschaftlichen Schwerpunkt bildet. 68

Auch der SaaS Vertrag wird neben der Bereitstellung der Softwarefunktion

weitere, gleichwertige Leistungen umfassen. Geht man davon aus, dass

neben der reinen Softwarefunktion auch noch Help Desk Leistungen und

Speicherplatz bereitgestellt werden, wird aufgrund der Verschiedenartigkeit

dieser Leistungen eine Schwerpunktbildung nicht möglich sein. Die

Nutzung der Funktionen einer Software im Rahmen eines SaaS Vertrages

kann also nicht einfach den Regeln eines anderen Leistungsversprechens des

Vertrages untergeordnet werden. Zudem wird es auch Angebote geben, die

nur die Softwarefunktion bereitstellen, ohne weitere Zusatzleistungen

anzubieten. Aus diesen Gründen wird man in der Zukunft nicht um eine

rechtliche Einordnung der Softwarenutzung im Rahmen von SaaS vorbei

kommen. Es muss also geklärt werden, wie die Bereitstellung von

Softwarefunktionen rechtliche einzuordnen ist und ob Unterschiede zu den

bisherigen Erscheinungsformen des Softwarevertriebs bestehen. Aus diesem

Grund soll unabhängig von der Einbettung in einen typengemischten

67 Stadler, in: Jauernig, 13. Aufl. 2009, § 31, Rn. 31; Bohne/Müller, in: Hoeren, T. / Sieber,

U., Handbuch Multimedia - Recht, Teil 12.3, Rn. 68

68 Grüneberg, in: Palandt, BGB, 68. Aufl. 2009, vor § 311 Rn. 25 f.

- 25 -


Vertrag eine eigene vertragstypologische Einordnung von SaaS in den

folgenden Abschnitten vorgenommen werden.

4. Mietvertrag

Eine überwiegende Anzahl der Autoren, die das Thema SaaS ansprechen,

vertreten die Auffassung, dass der SaaS Vertrag mietvertraglichen

Regelungen zu unterwerfen sei, weil das SaaS Geschäftsmodell das Gleiche

oder nur eine Weiterentwicklung des ASP Geschäftsmodells sei und der

ASP Vertrag vom BGH als Softwaremietvertrag eingestuft wurde. 69 Hierbei

wird aber übersehen, dass es sich bei der Entscheidung um eine

Einzelfallentscheidung handelte, die nur eine ganz bestimmte technische

Ausprägung einer Softwaredistribution als Grundlage hatte. Deswegen kann

aber nicht die Schlussfolgerung gezogen werden, dass das Mietrecht stets

bei ASP- oder ASP ähnlichen Verträgen anzuwenden ist. 70 In dem vom

BGH entschiedenen Fall ging es in der Tat um eine ganz spezielle

Buchhaltungs- und Warenwirtschaftssoftware, die zur Nutzung auf den

Servern des Anbieters ausgelagert wurde. Dreh- und Angelpunkt des

zwischen den Parteien vereinbarten Leistungsspektrums war somit jene

eindeutig bestimmte Software (Abfolge von Computerbefehlen) und nicht

irgendeine Software, die ebenso gut Lösungen zur Buchhaltungs- und

Warenwirtschaft hätte erbringen können. Da das SaaS Modell jedoch eine

technische Neuheit ist, muss auch rechtlich eine Neubewertung erfolgen und

man muss die Frage beantworten, was hierbei konkret geschuldet wird.

a) Charakterisierung

Der Mietvertrag zeichnet sich dadurch aus, dass der Mietgegenstand ganz

genau bestimmt ist. 71 Die mietrechtlichen Regelungen gehen also davon aus,

dass das Mietobjekt eindeutig bestimmbar ist, also einer physischen Sache

zugeordnet werden kann. Es ist also immer ein reales Abbild notwendig.

69

BGH NJW 2007, 2394; Schulz, C. / Rosenkranz, T., ITRB 2009, 232, 233; Niemann, F. /

Paul, J., KuR 2009, 444, 447

70

Müller-Hengstenberg, C. / Kirn, S., NJW 2007, 2370

71

Gennen, K. / Völkel, A., Recht der IT-Verträge, Rn. 187

- 26 -


Zwar kamen im Zuge der IT erste Probleme auf als es darum ging, den

Softwarevertrieb rechtlich einzuordnen. Denn der Software an sich fehlt

gerade der Bezug zu einer physischen Sache. Der BGH nahm allerdings als

Bezugspunkt das physische Medium, auf dem die Software beim Betrieb

immer abgelegt werden muss. 72 Die mietvertragliche Einordnung hat aber

zur Folge, dass weder Mieter noch Vermieter das Mietobjekt während der

Mietzeit ohne ausdrückliche Vereinbarung ändern dürfen. 73 Zwar besteht

einerseits die Möglichkeit im Rahmen der allgemeinen Erhaltungspflichten

Änderungen vorzunehmen (z.B. schließen von Sicherheitslöchern) oder

andererseits mittels explizit eingeräumter Rechte, Maßnahmen die über die

Erhaltungspflicht hinausgehen, zu gestatten (z.B. automatische Updates). 74

Wobei Letzteres aber gegen § 307 Abs. 2 Nr. 2 BGB verstoßen könnte,

wenn die Vereinbarung dem AGB Recht unterliegt. 75 Eine beliebige

Änderung im Sourcecode oder der vollständiger Ersatz der Software, wie

der Austausch eines Textverarbeitungssystems gegen ein anderes, ist aber

ausgeschlossen. 76 Das Gleiche wird wohl auch bei einem Versionssprung

zur nächst höheren Softwareversion gelten müssen, da eine solche

Änderungen gewöhnlich erhebliche Abänderungen im Programmcode mit

sich bringt. Für den SaaS Anbieter kann diese Beschränkung aber zu

erheblichen Problemen führen, da er hierdurch an einer stetigen

Weiterentwicklung seiner Software gehindert wird und bei jeder Änderung

das Einverständnis der Nutzer einholen müsste bzw. für jeden Nutzer die

Softwareversion ständig bereithalten müsste, die zum Zeitpunkt des

Vertragsschlusses vorlag. Auch könnten notwendige Änderungen in der

Darbietung der Benutzerschnittstellen, z.B. die Umplatzierung eines

Eingabefeldes, mietrechtlich nicht erlaubt sein. Ebenso könnte es

problematisch sein, wenn bestimmte Softwarefunktionen ausgelagert

werden sollten, was wiederum erhebliche Änderungen im Programmcode

mit sich bringen würde.

72 BGH, NJW 2007, 2394

73 Redeker, H., IT-Recht, Rn. 600

74 Redeker, H., IT-Recht, Rn. 991

75 Redeker, H., IT-Recht, Rn. 600

76 Gennen, K. / Völkel, A., Recht der IT-Verträge, Rn. 752

- 27 -


) SaaS = Softwaremiete?

Wie kann etwas den mietrechtlichen Regelungen unterworfen werden, wenn

das Ziel eines Vertrags nicht einen eindeutig bestimmten Mietgegenstand

umfasst, dieser darüber hinaus nur virtuell existiert und der SaaS Anbieter

die Software nach belieben austauschen kann ohne dadurch in

Leistungsverzug zu kommen? Diese Frage muss gestellt werden, wenn man

an SaaS denkt.

Um diese Frage beantworten zu können, ist erneut ein Blick in das Umfeld

zu werfen, aus dem die SaaS Idee stammt, also die vom Cloud Computing

umfassten Modelle IaaS und PaaS, die zum einen greifbarer erscheinen.

Zum anderen müssen die rechtlichen Ergebnisse zueinander auch stimmig

sein, da die technischen Ziele die gleichen sind. Dabei erscheint das IaaS

Angebot über die Bereitstellung von virtuellem Speicherplatz besonders

prägnant. 77 Wie schon erwähnt geht es hierbei um die optimale Ausnutzung

von örtlich verteilten und sich ständig ändernden Ressourcen, indem diese

durch Virtualisierung so zusammengefasst werden, dass sie als eine virtuelle

Einheit gegenüber dem Nutzer auftreten und dadurch nutzbar werden. 78

Es erscheint schon fraglich bei der Bereitstellung von virtuellen Hard-, oder

Software-Infrastrukturen von einem mietvertraglichen Gegenstand

auszugehen. 79 Zwar mag es Lösungen geben bei denen das zugrunde

liegende Steuerungsprogramm jeder virtuellen Komponente stets eine

genaue physische Ressource zuweist, was den mietvertraglichen Charakter

unterstützen würde. 80 Allerdings sollten hierbei zwei Dinge nicht unbeachtet

bleiben. Zum einen bringt es die Virtualisierungstechnik mit sich, dass der

Anwender selbst nur mit der virtuellen Komponente interagiert. Werden

ganze Rechnersystem virtualisiert wird der Anwender und vor allem die von

Ihm benutzte Software, die auf diese Komponenten zugreift, keinen

Unterschied feststellen können, ob die Komponente virtuell oder real ist.

77 z.B. Amazons S3 Cloud Storage

78 vgl. Stanoevsak-Slabeva / Wozniak / Ristol, „Grid and Cloud Computing“, Part II,

4.3.2.1; Bierekoven, C. ITRB 2010, 42

79 so aber: Schulz, C. / Rosenkranz, T., ITRB 2009, 232, 233

80 Pohle, J. / Amman, T., CR 2009, 273, 275

- 28 -


Die virtuelle Umgebung, in der sich der Anwender aufhält, ist für Ihn so real

wie eine physisch existierende Komponente. Der Anwender wird auch

niemals direkt mit der physischen Komponente interagieren können, denn er

hat keine Kontrolle darüber, wie diese genutzt wird. Somit fehlt es im

Grunde schon an der mietrechtlichen Nutzung der real existierenden

physischen Ressource. Denn diese wird ja nur durch den Anbieter direkt

und vollumfänglich genutzt.

Zum anderen wird beim Cloud Computing nicht mehr davon ausgegangen

werden können, dass die virtuelle Komponente genau einer physischen

Komponente zugeordnet ist, sondern mehreren. 81 Dies bringt es mit sich,

dass reale Komponenten ständig hinzugefügt oder herausgenommen werden

können. Nur der Anbieter entscheidet, wie die Rechnerressourcen genutzt

werden. Der Nutzer der virtuellen Komponenten hat darauf keinen Einfluss.

Er interagiert nur mit der virtuellen Einheit, was vergleichbar mit einem

Serviceschalter eines Postunternehmens ist, der die Anfragen

entgegennimmt und im Hintergrund die Bearbeitung und Weitersendung

selbst und eigenständig übernimmt.

Bsp: Amazon bietet den Speicherplatz an, der auf den Servern von Amazon liegt. Der für

das starke Weihnachtsgeschäft notwendig vorzuhaltende Speicherplatz kann somit auch

außerhalb der Spitzenzeiten genutzt werden und liegt nicht brach. Die Daten selbst liegen

dezentral verteilt und werden nur virtuell zusammengefügt und dem Nutzer zugänglich

gemacht. Der Nutzer mietet somit nicht eine bestimmte Festplatte, sondern nutzt das

gesamte Netzwerk. Theoretisch denkbar ist auch, dass bei Leistungsspitzen weiterer

Speicherplatz von Dritten hinzugekauft werden kann, damit Amazon gegenüber seinen

Kunden die Leistungspflichten erfüllen kann. Die sich dem Nutzer darstellende

Speichereinheit existiert somit nur virtuell.

Da sich auch das SaaS Geschäftsmodell diese Virtualisierungstechnik

zunutze macht, erhält der Nutzer ebenso keinen direkten Zugriff auf eine

bestimmte Softwarelösung, sondern nur auf die hierdurch erzielbare

Funktionalität. 82 Er ist nicht „Herr der Software“, wie noch bei ASP. 83 In

einem sehr fortgeschrittenen Stadium würde gegenüber dem Endkunden

sogar nur ein Solution Provider auftreten, welcher selbst für die angestrebte

81 Söbbing, T., MMR 2008, XII, XIV; Schmitz, L., Computerwoche 9/2007, 20

82 so ähnlich Redeker, in: Redeker, H., IT-Recht, Rn. 989

83 Sedlmeier, T. / Kolk, D., MMR 2002, 75, 77

- 29 -


Lösung die notwendigen Softwaredienste in der Cloud zusammenstellt und

anbietet, also nur als Vermittler auftritt. 84 Dem Nutzer steht also nicht mehr

eine von vornhinein genau zu bestimmende Software zur Verfügung.

Ein weiteres Beispiel für SaaS wäre die Umwandlung eines Dokumentformates in das

portable .pdf Format. 85 Dies kann durch auf dem eigenen Rechner installierte Software oder

aber auch als Service über eine Webseite geschehen, bei welcher das Dokument nach dem

Upload umgewandelt wird und im .pdf Format wieder zur Verfügung gestellt wird. Bei

letzterem ist nur das Ergebnis relevant und ein mietvertragliches Verhältnis kaum

anzunehmen. Der Anbieter entscheidet im Moment der Nutzung, wie er das Ergebnis

erreicht. Selbstverständlich kann dieser Service auch in eine weitere Arbeitsumgebung

integriert werden, z.B. einem Webmail-Dienst. Dann wird der Nutzer die dahinter liegende

Software gar nicht mehr beeinflussen können.

Auch unter dem Gesichtspunkt des Leistungsziels kann im Rahmen von

SaaS Verträgen keine Softwaremiete mehr angenommen werden. Zwar

arbeitet für den Anwender eine Software am anderen Ende der Leitung, aber

der Leistungsschwerpunkt liegt nicht im Überlassen von Computer-

programmen, sondern im Zugänglichmachen von Funktionalität, ähnlich

den Webangeboten wie etwa die bekannten Webmail Services. 86 Dies tritt

dann deutlich hervor, wenn man bedenkt, dass der SaaS Anbieter die

Software komplett austauschen kann (z.B. bei einem Release-Wechsel) oder

auch in einer anderen Programmiersprache anbieten kann, ohne dass der

Benutzer hiervor etwas bei der Anwendung merkt.

- 30 -

87

Unter

mietvertraglichen Regelungen müsste die Möglichkeit eines Release-

Wechsels hingegen vertraglich vereinbart werden. 88

Das eine Änderung des Softwareunterbaus im Rahmen von SaaS von Zeit

zu Zeit notwendig wird, ohne dass dadurch die eigentliche Funktionalität

des Service verändert würde, zeigen die gängigen SaaS Beispiele aus den

Bereichen Webmailing oder Social Networking. Darin liegt aber gerade der

Vorteil. Das Angebot bleibt stets aktuell und auf dem Stand der Technik.

84

vgl. Stanoevsak-Slabeva / Wozniak / Ristol, „Grid and Cloud Computing“, S. 94, Fig. 6.4

85

Kramer, A. / König, P., c’t 23/2008, S. 118 ff.

86

so auch Koch, F., ITRB 2007, 71, 73

87

vgl. Koch, F., ITRB 2007, 71, 73

88

vgl. Schulz, in: Köhler-Schute, C., „Software as a Service“, S. 94


Aus Sicht des Anbieters ist es sicherlich nicht gewollt, sich mit dem SaaS

Vertrag auf eine bestimmte Software für die ganze Vertragslaufzeit

festzulegen, zumal gerade im Rahmen von Cloud Computing Teile der

Software oder Unteralgorithmen auf Dritte ausgelagert werden können,

wenn dadurch Kosten eingespart werden.

Hierzu ein Beispiel: Gerade bei umfangreichen Berechnung kann es sinnvoll sein, freie

oder günstigere Rechnerkapazitäten eines anderen Anbieters zu benutzen. Mathematisch

gesehen müssen hierzu lediglich die Variablen, mit denen gerechnet werden soll,

übertragen werden, z.B. Kundennamen und zugehörige Daten. Der Rechenalgorithmus

selbst wird vom Drittanbieter zur Verfügung gestellt. Da es in der Mathematik viele Wege

gibt, um ein Ergebnis zu berechnen, ist auch nicht bekannt, wie die Software des

Drittanbieters programmiert wurde. Sobald die Berechnung fertig ist, wird das Ergebnis

zurück geliefert. Somit bleibt das Rechenergebnis im Ende zwar das Gleiche, der

Softwareunterbau war jedoch ein gänzlich anderer. Aus Sicht des SaaS Anbieters ist diese

Freiheit, die Software auszutauschen, notwendig und gewünscht. Im Rahmen des

Mietrechts kann er dies aber nicht eigenständig vornehmen.

c) Ergebnis

SaaS kann nicht über ASP definiert werden. SaaS ist über die Begriffe

Cloud Computing, IaaS und PaaS zu definieren. Dann aber gelangt man zu

dem Ergebnis, dass Softwareverträge, die Leistungen nach dem SaaS

Modell umfassen, nicht mietvertraglichen Regelungen unterliegen. Denn

schon aufgrund des hohen Maßes an Virtualisierung fehlt es an einem

bestimmten Mietgegenstand, der vermietet werden könnte. Im

fortschrittlichsten Fall besteht die Software aus vielen Einzelkomponenten,

die sich nur virtuell gegenüber dem Nutzer als eine Einheit darstellen. Dem

Kunden selbst wird es aber gleichgültig sein, welche konkrete Software auf

welchem Rechner er nutzt, solange nur die Funktionen wie vereinbart erfüllt

werden. 89 Das Mietrecht ist ausgelegt für körperliche Sachen. Bei Software

im Allgemeinen hat der Bundesgerichtshof noch die Sachqualität und damit

das Mietrecht anwenden können. Für virtuelle Lösungen, die losgelöst von

Ort und Zeit sind, versagen aber die mietrechtlichen Regelungen.

89 vgl. Redeker, in: Redeker, H., IT-Recht, 989

- 31 -


5. Werkvertrag

Da die Einordnung eines gängigen SaaS Vertrages als Mietvertrag nach hier

vertretener Auffassung nicht in Betracht kommt, ist zu prüfen, ob das SaaS

Vertriebsmodell als Werkvertrag oder auch als Dienstvertrag angesehen

werden kann. Bekanntermaßen soll es sich um einen Werkvertrag handeln,

wenn ein Leistungserfolg geschuldet ist. 90 Ein Dienstvertrag ist dagegen

anzunehmen, wenn nur eine Tätigkeit (ein Tätigwerden) geschuldet wird.

Die Abgrenzung beider Vertragstypen ist aufgrund vieler Gemeinsamkeiten

schwierig, kann aber hinsichtlich der unterschiedlichen Rechtsfolgen

notwendig werden. 91 Gerade in wichtigen Fragen zur Mängelhaftung haftet

der Unternehmer im Rahmen des Werkvertrages gem. § 634 ff. BGB bei

Mängeln des Werkes. Da der Dienstverpflichtete hingegen keinen Erfolg

schuldet, sondern nur die versprochenen Dienste mit Sorgfalt zu leisten hat,

trifft ihn eine solche Mängelhaftung nicht. 92 Während Vorschriften zur

Beendigung des Vertragsverhältnisses durch Kündigung im Dienstvertrag

einen Niederschlag gefunden haben, wird das Kündigungsrecht im

Werkvertrag lediglich durch die §§ 649, 650 BGB geregelt.

Zur genauen Typologie des SaaS Vertrages spielen die Interessen der

Parteien eine wichtige Rolle. Ein Interesse entsteht hierbei durch eine hohe

Abhängigkeit des Nutzers vom SaaS Anbieter. Denn der Nutzer kann seine

Berechnungen nicht mehr mit der eigenen Software vornehmen, sondern ist

darauf angewiesen, dass der SaaS Anbieter die gewünschten

Computerberechnungen mit seiner Software durchführt und die Ergebnisse

zurückliefert. Der Service des Anbieters muss somit ständig abrufbar sein,

indem die API’s oder HMI’s 93, 94 seiner Software jederzeit aufrufbar sind,

um Nutzerdaten eingeben zu können. Zudem müssen die Ergebnisse

entsprechend zeitnah geliefert werden. Somit steht die Abrufbarkeit der

Softwarefunktionen im Vordergrund und in diesem Sinne die Herbeiführung

90 Sprau, in: Palandt, BGB, Einf. v. § 631, Rn. 1

91 Busche, in: Münchener Kommentar, § 631, Rn. 8

92 Busche, in Münchener Kommentar, § 631, Rn. 9

93 Human Machine Interfaces, also die Möglichkeit zur Eingabe von Daten in den

Programmprozess durch den Menschen (dies sind z.B. die gewöhnlichen Eingabemasken in

einer Webseite)

94 vgl.: http://de.wikipedia.org/wiki/Benutzerschnittstelle

- 32 -


eines „Erfolges“ und nicht ein bloßes Tätigwerden. Dem SaaS Nutzer ist

wenig geholfen, wenn der Anbieter lediglich ein Bemühen schuldet. 95 Die

Erreichbarkeit des Systems gewinnt hingegen einen so hohen Stellenwert,

dass sie nur noch in der Herbeiführung eines geschuldeten Erfolges

sichergestellt werden kann. Da die Unterscheidung zwischen geschuldetem

Erfolg und reinem Tätigwerden zuweilen Schwierigkeiten macht, ist im

konkreten Fall immer eine genaue Feststellung der Interessen notwendig.

Ein weiteres Beispiel zur Verdeutlichung liefert die Nutzung einer Software zur

Rechtschreibprüfung. Auf den ersten Blick erscheint hier ein Dienstvertrag näher zu liegen,

als ein Werkvertrag (Bemühen der Fehlererkennung). Wegen der Komplexität solcher

Aufgaben erscheint es nicht sachgerecht von einem Erfolgsversprechen auszugehen. Näher

liegt daher die Einordnung als Dienstvertrag, also ein Bemühen bei der Korrektur von

Rechtschreibfehlern in einem Dokument. Anders könnte es aber zu beurteilen sein, wenn

die Vereinbarung nicht die Korrektur aller vorhandenen Rechtschreibfehler umfasst,

sondern eine Quote vereinbart wird, die nicht unterschritten werden darf. Dadurch hätte das

Problem Rechtschreibprüfung wieder einen messbaren und erreichbaren Erfolg, wodurch

die Einordnung des Vertrages als Werkvertrag wieder sinnvoll erscheinen würde.

Auf der anderen Vertragsseite möchte der SaaS Anbieter eine

Wertschöpfung aus der Software für den Kunden ziehen, indem er seine

Software dazu nutzt, aus den Kundendaten ein Ergebnis zu berechnen und

zu präsentieren. Diese Wertschöpfung ist aber ein konstitutives Element des

Werkvertrages. 96

In seiner neuesten Entscheidung zur Rechtsnatur von Internet-System-

Verträgen entschied sich der Bundesgerichtshof ebenso aufgrund des

Erfolgscharakters für die Einordnung als Werkvertrag. 97 Bleibt der BGH bei

dieser Ansicht und rückt auch bei SaaS Verträgen die Abrufbarkeit im Sinne

einer Erfolgsschuld in den Vordergrund, ist mit einer Einordnung des SaaS

Vertrages als Werkvertrag zu rechnen.

95 so im Rahmen des ASP Vertrages: Sedlmeier, T. / Kolk, D., MMR 2002, 75, 78

96 vgl. Sedlmeier, T. / Kolk, D., MMR 2002, 75, 77

97 BGH, NJW 2010, 1449 [26]

- 33 -


6. Dienstvertrag

Zwar wird nach Dienstvertragsrecht nur eine Tätigkeit geschuldet und kein

Leistungserfolg. Dennoch besteht die Möglichkeit, die Leistungsschuld um

qualifizierende Merkmale der Leistung zu erweitern. Dies erscheint

notwendig, da der Dienstverpflichtete grundsätzlich nur eine Leistung von

mittlerer Art und Güte zu leisten hat. 98 Deswegen ist die Leistung genauer

zu konkretisieren, wenn eine bestimmte Qualität notwendig ist und eine

mittlere Art und Güte nicht ausreicht. Praktisch kann dies durch die

Ausgestaltung von Service Level Agreements vorgenommen werden. Zwar

wird hierdurch noch immer nur eine Tätigkeit geschuldet. Jedoch wird das

Qualitätsniveau angehoben, ab welchem erst von einer Leistungserfüllung

ausgegangen werden kann.

Trotzdem begegnet diese Vorgehensweise rechtlichen Bedenken, da die

gesetzlichen Regelungen einen Erfolgsbezug wie beim Werkvertrag in

Dienstverträgen nicht vorsehen. Dadurch besteht die Gefahr, dass mit den

spezifizierenden Regeln von wesentlichen Grundgedanken des

Dienstvertragsrechts abgewichen wird und ein Konflikt mit § 307 Abs. 2

BGB entsteht. Die besseren Gründe sprechen, wie oben schon beschrieben,

für eine Einordnung als Werkvertrag.

7. Ergebnis

Die Situation von SaaS scheint einem Beförderungsvertrag ähnlich zu sein:

Man steigt ein und will an einem bestimmten Ziel wieder aussteigen.

Manchmal soll die Fahrtzeit einen bestimmten Wert nicht überschreiten

oder man will erster Klasse reisen, was dann durch SLA vereinbart werden

kann. Auch bei SaaS gibt man die zu bearbeitenden Daten ein und will ein

bestimmtes Ergebnis erzielen.

98 Heinrichs, in: Palandt, BGB, § 243, Rn. 1

- 34 -


Der Beförderungsvertrag wurde jedenfalls zu Recht als Werkvertrag

eingeordnet. 99 Auch bei SaaS muss man sich die Frage stellen, was

geschuldet wird. Ist es die Software in der Form der Anordnung der

Computerbefehle oder die Erfüllung ganz bestimmter Aufgaben und

Funktionen mittels Software, aber unabhängig von einem ganz bestimmten

Programmalgorithmus? Die Beantwortung dieser Frage entscheidet über den

mietrechtlichen Charakter des Vertrages. Als nächstes ist dann zu fragen, ob

ein Tätigwerden geschuldet wird oder ein ganz bestimmter Erfolg. Es ist

also zu entscheiden zwischen dem werkvertraglichen und

dienstvertraglichen Charakter von SaaS.

Auch wenn nach der hier vertretenen Ansicht eine Einordnung als

Mietvertrag ausgeschlossen ist, bleibt es weiter bei vielen Unsicherheiten.

Denn damit ist noch nicht die Frage geklärt, ob ein gemischter Vertrag, ein

atypischer Vertrag, ein Werk- oder Dienstvertrag vorliegt. 100 Allerdings gibt

es auch Stimmen, die die Frage nach der dienst- oder werkvertraglichen

Einstufung als wenig ergiebig ansehen, da im Bereich der

Softwareentwicklung ein Erfolg immer möglich sei und folglich auch bei

dienstvertraglicher Einstufung die Leistungspflicht so lange bestehe, bis der

Erfolg erreicht wird. 101 Dem ist beizustimmen. Aus diesem Grund erscheint

es wichtiger, unabhängig von der Suche nach der einzig korrekten

dogmatischen Einordnung, die wechselseitigen vertraglichen Rechte und

Pflichten sowie die Sanktionen und den sanktionsfreien Verfehlungsbereich

für alle Beteiligten klar und unmissverständlich zu definieren. 102 Aus

diesem Grund soll der folgende Schwerpunkt unabhängig von der

vertraglichen Einordnung bei der Gestaltung der SLA liegen.

99 Sprau, in: Palandt, BGB, vor § 631, Rn. 17a

100 Helwig, B. / Koglin, O., S. 179

101 so auch Bartsch, M., NJW 2002, 1526

102 Helwig, B. / Koglin, O., S. 179

- 35 -


III. Service Level Agreements

1. Einführung

Wie im vorherigen Abschnitt schon festgestellt, bleiben bei der genauen

vertraglichen Einordnung von SaaS Verträgen erhebliche

Auslegungsschwierigkeiten. Um diesen zu begegnen ist eine genaue

Leistungsbeschreibung der Leistungsschuld notwendig. 103 Zudem werden

durch die Auslagerung von Geschäftsprozessen auf Dritte neue Risiken

erzeugt, denen durch vertragliche Absprache begegnet werden muss. Hinzu

kommt, dass meist wesentliche Geschäftsprozesse des Unternehmens

betroffen sind, auf die ständig und zuverlässig zugegriffen werden muss.

Schon aus diesem Grund ist es notwendig, die ausgelagerte Leistung so weit

zu spezifizieren, dass die Leistungserfüllung in gleichem Maße erfolgt, als

wenn die Prozesse weiterhin wie eine Inhouse Lösung betrieben würden.

Zudem macht es die gesetzliche Regelung notwendig, die Qualität der

Leistung eindeutig festzulegen, da sonst nur eine Leistung von mittleren Art

und Güte geschuldet wird. 104 Durch vertragliche Vereinbarungen können die

Risiken wieder gerechter verteilt werden und der Prozess des Outsourcing

beherrschbar gemacht werden.

Aus diesen Gründen hat sich die Einführung von Service Level Agreements

etabliert, um die ausgelagerte Leistungserbringung in ein enges Korsett zu

zwängen und dadurch die verloren gegangenen Kontrollmöglichkeiten

wiederzugewinnen. 105 Durch die SLA kann der genaue Leistungsumfang,

die Qualität der Leistung, deren Verlässlichkeit bzw. Verfügbarkeit, die

Gewährleistung und sonstige Zusatzleistungen geregelt werden. 106

Der folgende Abschnitt versucht das Institut der SLA näher zu beschreiben,

Strategien zu deren Gestaltung aufzuzeigen und Beispiele für typische oder

notwendige Service Levels zu geben.

103

Helwig, B. / Koglin, O., S. 179

104

Schumacher, V., MMR 2006, 12

105

Schumacher, V., MMR 2006, 12; Braun, H., „Die Zulässigkeit von Service Level

Agreements“, 1

106

Braun, H., „Die Zulässigkeit von Service Level Agreements“, S. 2

- 36 -


2. Rechtsnatur von SLA

a) Begriffsbestimmung

Der Begriff der Service Level Agreements unterliegt keiner

allgemeingültigen Definition und kann aufgrund des großen

Anwendungsgebietes nicht umfassend beschrieben werden. 107 Während im

amerikanischen Sprachraum der Begriff der SLA als allgemeine

Leistungsbeschreibung gesehen wird, steht der Begriff der SLA hierzulande

für eine Beschreibung der geschuldeten Qualität der Leistung. 108 Fest steht

jedenfalls, dass die gesetzlichen Regelungen schon lange nicht mehr

ausreichen, um den Anforderungen der IT-Branche gerecht zu werden.

Deswegen verfolgen SLA den Zweck, durch detaillierte Vereinbarungen die

gegenseitigen Rechte und Pflichten genau zu bestimmen. 109 Nach Braun 110

zeichnen sich SLA durch folgende typische, aber nicht notwendige

Funktionen innerhalb des Vertrages aus:

- Festlegung der Qualität und Quantität der Hauptleistung

- Schaffung von Kontrollmöglichkeiten der Leistungsqualität und -

quantität

- Vereinbarung von Supportleistungen

- Vereinbarungen über das Störungsmanagement

- Vereinbarungen über die Mean-Time-To-Repair (MTTR) 111

- Vereinbarung eines Sanktionssystems

Die SLA können somit Vereinbarungen über die Haupt-, Neben-, und

Zusatzleistungen enthalten. Als technische Leistungsbeschreibung von

laufenden Services erhalten die SLA hierbei regelmäßig konkrete Werte

(sog. Key Performance Indicators, KPI’S) über die Verfügbarkeit der

Leistung oder Anforderungen an einen Help Desk Service. 112

107

Braun, H., „Die Zulässigkeit von Service Level Agreements“, S. 3, Niemann, F. / Paul,

J., KuR 2009, 444, 447

108

vgl. Niemann, F. / Paul, J., KuR 2009, 444, 447

109

Söbbing, T., ITRB 2004, 257

110

Braun, H., „Die Zulässigkeit von Service Level Agreements“, S. 3

111 mittlere Reparaturzeit

112 Helwig, B. / Koglin, O., S. 181

- 37 -


In einem Vertrag erfüllen die SLA somit ganz bestimmte Zwecke. 113 Zum

einen definieren sie die vereinbarte Leistung wie sie von dem Nutzer

erwartet wird damit sich die Software, auf die zugegriffen wird, optimal in

die Betriebsvorgänge beim Nutzer integriert. Dies ist wichtig, da jede

Störung in der Softwarenutzung auch mit Störungen im eigenen

Betriebsablauf des Unternehmens einhergehen würde. Zum anderen soll mit

den SLA die Leistung messbar werden. Denn es wird kaum ausreichen,

lediglich den Zugriff auf eine bestimmte Softwarefunktion zu vereinbaren,

da dies zu viel Spielraum, beispielsweise in den Antwortzeiten des

Programms, zulässt. Als Nebeneffekt entsteht durch die Gestaltung von

SLA gleichzeitig auch eine Art von Qualitätssicherung.

Als ein gutes Beispiel in diesem Zusammenhang können Zulieferverträge von Einzelteilen

oder Rohostoffen im Rahmen von Just-in-time Verträgen gelten. Auch hier reicht die

Vereinbarung über die Lieferung bestimmter Materialien oft nicht aus, da diese zu einem

fest definierten Zeitpunkt in einer fest vorgegebenen Qualität und Quantität eintreffen

müssen, damit nicht der ganze Produktionsablauf zum Erliegen kommt. 114 In das SaaS

Modell übertragen bedeutet dies, dass jeder Lieferant der Just-in-time Kette einer ganz

bestimmten Softwarefunktion entspricht. Erst im Zusammenwirken aller einzelnen

Funktionen entsteht das Softwareprogramm, wie es sich dem Endnutzer darstellt.

Die SLA haben somit in der Folge auch den Zweck einer

Anspruchsgrundlage, da sie sowohl den Anbieter wie auch den Nutzer auf

die vertraglich vereinbarte Anspruchserfüllung verweisen können. 115 Da die

SLA somit wesentliche Vertragsaufgaben erfüllen, sind hohe

Anforderungen an die Qualität der SLA zu stellen. Da mit den SLA der

technische Sachverhalt exakt abgebildet werden muss, ist ein technisches

Grundverständnis von der zu regelnden Materie unumgänglich. 116

Letztendlich dienen SLA somit auch der Konfliktvermeidung, dem

Risikomanagement, der Absatzförderung und der Kundenzufriedenheit. Sie

dienen dem Kunden auch als entscheidendes Argument bei der

113 Braun, H., „Die Zulässigkeit von Service Level Agreements“, S. 4 ff.

114 Grundewalt, B., NJW 1995, 1777

115 Braun, H., „Die Zulässigkeit von Service Level Agreements“, S. 4

116 Helwig, B. / Koglin, O., S. 181; vgl. Söbbing, T., ITRB 2004, 257

- 38 -


Entscheidung über das Outsourcing von IT-Leistungen. 117 Denn nur wenn

der Kunde dem System vertraut, wird er sich für die Systemauslagerung

entscheiden. Dies betrifft insbesondere auch datenschutzrechtliche Aspekte,

die zur Vertrauensbildung umfassend geregelt werden sollten.

b) Rechtliche Qualifizierung

Durch die Service Level Agreements wird die Qualität der Leistung

detailliert festgelegt. Dabei liegt es im Interesse beider Vertragsparteien, die

Leistung so genau wie möglich zu beschreiben, um spätere Konflikte zu

vermeiden. 118 Liegt zudem eine detaillierte Leistungsbeschreibung nicht vor,

wird gem. § 243 BGB eine Leistung mittlere Art und Güte geschuldet.

Teilweise entsteht vor allem im Rahmen von Vereinbarungen über

Verfügbarkeitsklauseln Streit darüber, ob diese SLA eine Leistungs-

beschreibung oder eine Einschränkung der Gewährleistung darstellen, was

mit Auswirkungen bei der AGB Kontrolle verbunden ist. 119 Denn nur eine

Leistungsbeschreibung entzieht sich der Kontrolle nach den Vorschriften

der AGB (§ 307 Abs. 3 S. 1 BGB).

Gegen eine Einordnung der SLA als Gewährleistungseinschränkung spricht,

dass es bei der Erbringung von IT-Leistungen keinen wirklichen allgemein-

gültigen mittleren IT-Standard gibt, der als Grundlage für das Leistungsver-

sprechen herangezogen werden könnte. 120 Somit würde sich bei einer

Einordnung der SLA als Einschränkung der Gewährleistung die Frage

stellen, von welchem Ausgangspunkt diese Einschränkung aus erfolgt. Denn

würde man den SLA einen einschränkenden Charakter zuschreiben wollen,

hieße dies ja im Umkehrschluss, dass man von einer höheren oder gar 100-

prozentigen Leistungserbringung ausgehen würde. Dies wäre aber bei der

Erbringung von Leistungen im Rahmen von SaaS genauso wenig realistisch,

wie die Annahme, dass eine Inhouse IT-Lösung ständig störungsfrei

117 Söbbing, T., „Handbuch IT-Outsourcing“, S. 22

118 Söbbing, T., „Handbuch IT-Outsourcing“, S. 300

119 BGH, CR 2001, 181

120 Rath, M., KuR 2007, 362, 363; keine Standards beim Cloud Computing: Niemann, F. /

Paul, A., KuR 2009, 444, 447

- 39 -


funktionieren müsste. Zudem würde man den Parteien dadurch eine

Vereinbarung über die Leistung unterstellen, die sie niemals getroffen haben

und aus technischer oder betriebswirtschaftlicher Sicht auch niemals hätten

treffen wollen. Gerade im kommunikationstechnischen Bereich erscheint

ein Leistungsversprechen, dass eine uneingeschränkte Verfügbarkeit

umfasst, unrealistisch. 121 Deswegen werden Leistungen nur mit einer

niedrigeren Qualität als 100 Prozent angeboten, was sich im Gegenzug aber

auch in einem „bezahlbaren“ Preis niederschlägt. Die Rechtsprechung kann

deswegen eine von den Parteien getroffenen Regelung über den

Leistungsumfang nicht von sich aus dahingehend auslegen, dass eine

Einschränkung der Gewährleistung des Leistungsversprechens vorliegt.

Denn dies würde diametral den Interessen der Parteien entgegenstehen, da

sie sich bei Vertragsschluss ja darüber bewusst waren, dass eine volle

Leistungsqualität technisch nicht erbracht werden kann. Hinzu kommt, dass

Umfang und Gegenwert einer bestimmten Leistung den freien Marktkräften

und somit den Vertragsparteien obliegt. 122 Den Gerichten steht nicht die

Kompetenz zu, selbst den Leistungsumfang, die Leistungsqualität und den

hierzu gerechten Preis zu bestimmen. 123 Wenn eine Leistung nicht im vollen

Umfang des theoretisch Möglichen angeboten werden kann oder die

Leistungserbringung in diesem Fall unbezahlbar würde, muss den Vertrags-

parteien die Möglichkeit obliegen, die Leistung in einer bezahlbaren, aber

eingeschränkten Qualität anbieten zu können. Aus diesen Gründen ist es

nicht gerechtfertig, die Vorschrift § 307 Abs. 3 S. 1 BGB restriktiv anzu-

wenden (also in jeder AGB anstatt eine Leistungsbeschreibung vornehmlich

eine von den Rechtsvorschriften abweichende oder diese ergänzende

Regelungen zu sehen) um möglichst viele AGB-Regelungen einer

Inhaltskontrolle zu unterwerfen. 124 Dies würde eine unverhältnismäßige

Einschränkung der Vertragsfreiheit bedeuten. 125

121 OLG Düsseldorf, NJW-RR 1997, 374, 378; Komarnicki in: Hoeren, T. / Sieber, U.,

Handbuch Multimedia - Recht, Teil 12.2, Rn. 58

122 vgl. Braun, H., „Die Zulässigkeit von Service Level Agreements“, S. 60

123 vgl. Braun, H., „Die Zulässigkeit von Service Level Agreements“, S 61 Abschn. cc)

124 vgl Braun, H., „Die Zulässigkeit von Service Level Agreements“, S. 58 ff.

125 vgl. Braun, H., „Die Zulässigkeit von Service Level Agreements“, S. 61 Abschn. bb)

- 40 -


Nur wenn sich allgemeine Qualitätsstandards durchgesetzt haben und eine

Partei bei Vertragsabschluss auch von diesem Standard ausging oder

ausgehende durfte, besteht m. E. die Möglichkeit nach § 305c BGB die

entsprechende Regelung wegen ihrer überraschenden Wirkung für

unwirksam zu erklären. In diesem Fall müsste aber das Bestehen eines

allgemeingültigen Qualitätsstandards nachgewiesen werden. Braun geht

darüber hinaus und will zumindest bei Verbraucherverträgen Regeln über

die Leistungsqualität (Verfügbarkeitsklauseln) einer Inhaltskontrolle schon

dann unterwerfen, wenn diese nicht am Wettbewerb der Anbieter

teilnehmen, also für den Kunden keine Entscheidungsrelevanz beim

Abschluss des Vertrages hatten. 126 Dies wäre z.B. der Fall bei

Vereinbarungen über Verfügbarkeiten im Bereich des Internetzugangs. Für

den Kunden spielten bei der Auswahl der Angebote nur Vereinbarungen

über Geschwindigkeiten und Preis eine Rolle. Über die Verfügbarkeit

würden sich keine Gedanken gemacht werden. Somit stünden in diesem Fall

Vereinbarungen über die Verfügbarkeit nicht im Wettbewerb zueinander

und wären keine Vereinbarung über den Leistungsumfang und fielen somit

nicht in den Bereich der Vertragsfreiheit. Deswegen wäre eine

Inhaltskontrolle gerechtfertigt. Braun geht also davon aus, dass die

Kontrollfreiheit der Leistungsbeschreibungen sich nur dadurch rechtfertigen

lässt, wenn diese den Kräften von Markt und Wettbewerb ausgesetzt sind

und von dem Kunden in seine Abschlussentscheidung mit einbezogen

werden. 127

Festzuhalten ist, dass die rechtliche Problematik in diesem Bereich

weiterhin bestehen bleibt, solange keine klärenden obergerichtlichen

Entscheidungen getroffen wurden. 128 Wo die durch die Vertragsfreiheit

geschützte Leistungsvereinbarung endet und eine Regelung über die

Einschränkung der Gewährleistung anzunehmen ist, ist schwer vorhersagbar.

Es geht jedenfalls auch um die Frage, was der Kunden nach Gegenstand

und Zweck des Vertrages erwarten darf. Im Bereich der Kommunikations-

technik kann der Kunde m. E. zurzeit jedenfalls keine Verfügbarkeit von

126 Braun, H., „Die Zulässigkeit von Service Level Agreements“, S. 111 Abschn. aa) a.E.

127 Braun, H., „Die Zulässigkeit von Service Level Agreements“, S. 126

128 Braun, H., „Die Zulässigkeit von Service Level Agreements“, S. 127

- 41 -


100 Prozent erwarten. Bei technischem Neuland, wo keine Erfahrungen

bestehen und vieles noch erprobt wird, dürfen m. E. sogar keine

Erwartungen bestehen, so dass jede Regelung über die Leistungsqualität der

Inhaltskontrolle entzogen sein muss. Es handelt sich um eine von der

Vertragsfreiheit umfasste Leistungsbeschreibung. Nach der hier vertretenen

Ansicht handelt es sich somit im Rahmen von SaaS Verträgen bei den

Verfügbarkeitsklauseln um eine Konkretisierung der Leistungsqualität, also

um eine Leistungsbeschreibung, die einer Inhaltskontrolle entzogen ist. 129

Durch die Beschreibung der Leistung wird weder von Rechtsvorschriften

abgewichen noch werden diese ergänzt (§ 307 Abs. 3 S. 1 BGB). 130

Aufgrund der vielen rechtlichen Unwägbarkeiten kann nur dazu geraten

werden, die Leistungsbeschreibung so genau wie möglich vorzunehmen, um

nicht Gefahr zu laufen, dass ein Gericht hier doch eine Einschränkung der

Gewährleistung sieht.

3. Gestaltung eines SLA

Es versteht sich von selbst, dass ein Service Level Agreement nicht

willkürlich erstellt werden kann. Zu jedem Service Level Agreement gehört

immer ein eindeutiger Prozess der Leistungserfüllung, der in dem SLA

abgebildet wird. 131 Umfasst die vertragliche Vereinbarung einen

technischen Sachverhalt, sollte die technische Seite durch entsprechende

Service Levels abgebildet und eingegrenzt werden. Dazu ist es erforderlich,

die technischen Vorgänge bei der Vertragsabwicklung gedanklich zu

erfassen und notwendige Regelungen dort zu treffen, wo ein technischer und

rechtlicher Rahmen unabdingbar ist, um das vereinbarte Ziel zu erreichen

und Unsicherheiten zu vermeiden.

129 Niemann, F. / Paul, J., KuR 2009, 444, 447

130 Niemann, F. / Paul, J., KuR 2009, 444, 447

131 Söbbing, T., ITRB 2004, 257, 258

- 42 -


a) Standardangebote und individuelle Gesamtlösungen

Bei der Gestaltung von Service Level Agreements ist zu unterscheiden, ob

lediglich Standardleistungen (z.B. Webmaildienste) angeboten werden,

quasi von der Stange, oder ob individuelle und vor allem umfangreichere

Systemlösungen angeboten werden, die Platz für individuelle

Anforderungen lassen. Bei ersterem werden in der Regel die SLA durch den

Anbieter vorgeben.

Bei individuellen, zumeist auch umfangreicheren SaaS Angeboten, die

ganze Geschäftsprozesse abdecken (sog. Business-Process-Outsourcing 132 ),

ist ein Handlungsspielraum über die Ausgestaltungen der Service Levels

vorhanden, weil sich Anbieter und Nutzer regelmäßig gegenüber sitzen. In

diesem Fall obliegt es also dem Nutzer, sich zu entscheiden, welche

Qualitätsstandards für ihn unabdingbar sind und auf welche verzichtet

werden kann. Um dies entscheiden zu können, muss eine Ist-Analyse über

die bisherige Inhouse-Lösung vorgenommen werden und über einen

längeren Zeitraum hinweg die Qualität des eigenen Systems dokumentiert

werden. 133 Nur so kann der eigene Bedarf ermittelt werden und eine

sinnvolle Gestaltung der Service Levels vorgenommen werden. In einem

iterativen Prozess müssen sich Anbieter und Nutzer bei der Ausgestaltung

der Service Levels mit ihren Ansprüchen näher kommen. 134

Bei Standardlösungen wird meist kein Spielraum mehr für Verhandlungen

über die Ausgestaltung der SLA zwischen den Parteien bestehen. Der

Anbieter selbst wird unter den Bedingungen der eigenen Leistungsfähigkeit

und der wirtschaftlichen Attraktivität seines Angebots die SLA

ausformulieren und im Rahmen von Allgemeinen Geschäftsbedingungen im

Vertrag stellen. Gestaltungsprinzipien von SLA, die z.B. einen iterativen

und kontinuierlichen Prozess zwischen den Parteien vorsehen, um einen

optimalen Ausgleich zwischen den Kundenanforderungen auf der einen

Seite und der Leistungsfähigkeit des Anbieters auf der anderen Seite

132 Glossner, in: Bräutigam, P., „IT-Outsourcing“, Teil 3, Rdnr. 75

133 vgl. Hörl, B. / Häuser, M., CR 2003, 713, 714

134 vgl. Trienekens / Bouman / van der Zwan, Software Quality Journal, 12, 2004, S. 43, 47

- 43 -


herzustellen, finden somit grundsätzlich nur einseitig statt (dazu

sogleich). 135 Der größte Anreiz wird für den Anbieter darin liegen, durch

eigene Anstrengung sich den Kundenanforderungen zu nähern, um dadurch

sein Angebot auf einem freien Markt attraktiver zu machen. 136 Hierzu wird

er sich zumindest gedanklich in die Situation der Nutzer versetzen müssen,

um deren Ansprüche und Wünsche herausfinden zu können. Zumindest

ansatzweise sollte der Anbieter hierbei die Ausarbeitung der SLA nach den

gleichen Methoden zur Gestaltung von SLA vornehmen, wie wenn sich

Anbieter und Nutzer gegenüber stünden. Denn nur so kann erreicht werden,

dass die vom Anbieter gestellten SLA auch für den Nutzer attraktiv sind und

angenommen werden. Blendet der Anbieter hingegen die Nutzerinteressen

aus, riskiert er die Gestaltung von einseitigen, nur zu seinen Gunsten

bestimmten Service Level Agreements. Der Konflikt ist dadurch

vorprogrammiert, das Angebot verliert womöglich an Attraktivität. 137

b) Methodik

Bei kleineren Projekten mag ein unstrukturiertes Vorgehen zur Bestimmung

der Service Level noch möglich sein, indem die Anforderungen mittels

eines Brainstormings herausgearbeitet werden. Strebt man umfangreichere

Projekte an oder sollen diese angeboten werden, wird man an einer

strukturierten Herangehensweise nicht vorbei kommen. Genaue und

allgemeingültige Anleitungen zur Vorgehensweise, z.B. genau definierte

Schemas, wird man in der Literatur kaum finden, so dass der Erfahrung der

Verantwortlichen ein hoher Stellenwert zukommt. Lediglich aus Fallstudien

kann man die jeweiligen Entwurfsprozesse ablesen und als Vorlage für die

eigene Arbeit verwenden. Die mehrheitliche Literatur, die sich mit Service

Level Agreements beschäftigt, umschreibt deswegen nur allgemeine Ziele,

die bei dem Entwurf der SLA anzustreben sind und gibt Auskunft über

mögliche Fehlerquellen in der Entwurfsphase. Darüber hinaus findet man

viele Hinweise über einzelne Regelungsinhalte in den SLA’s.

135 vgl. Trienekens / Bouman / van der Zwan, Software Quality Journal, 12, 2004, S. 43, 47

136 m.w.N. Braun, H., „Die Zulässigkeit von Service Level Agreements“, S. 6, Abschn. II. 2.

g); Beyer, J., ITRB 2006, 20 Abschn. II.

137 Beyer, J., ITRB 2006, 20 Abschn. II.

- 44 -


Trienekens, Bouman und van der Zwan wenden drei Schritte bei der

Herangehensweise an, um die SLA zu spezifizieren (Continuity in SLA

specification, pit-shel principle und service process & service object

quality). 138 Im ersten Schritt geht es um die Definition der Anforderungen

an das System. Hierbei müssen der Anbieter und Nutzer zusammenarbeiten,

wobei hierfür aber nicht ein einziger linearer Schritt ausreicht, sondern die

Anforderungen in einem iterativen und sich wiederholenden Prozess

konkretisiert werden. Im nächsten Schritt werden die Leistungen bestimmt

(im Falle von SaaS die notwendigen Softwarefunktionen sowie

Anforderungen, damit die Software im normalen Betrieb nutzbar wird),

wobei die verschiedenen Leistungsbereiche, wie Help-Desks, Software-

funktionalität, Datenspeicherung und -sicherung, in einem „Statement of

work“ beschrieben werden können. 139 Hierzu müssen alle Beteiligten

frühzeitig gehört werden, vor allem auch das technische Personal. In einem

dritten Schritt erfolgt die qualitative Spezifizierung, wie die Bestimmung

der genauen Werte für die Verfügbarkeit der Software oder z.B. die Erreich-

barkeit des Help-Desks. Hierbei entstehen auch schon die konkreten Service

Levels, die abschließend noch vertraglich ausgearbeitet werden müssen.

In der deutschsprachigen Literatur begegnet man häufig Zielbeschreibungen,

die bei der Ausgestaltung von SLA erreicht werden müssen. Hiernach ist es

wichtig, wie schon mehrfach beschrieben, bei der Gestaltung von SLA

möglichst genaue und weit reichende Regelungen aufzunehmen. 140 Denn

aus ihnen ergibt sich der genaue Leistungsumfang der zu erbringen ist und

den der Kunde erwarten kann. Unklare und unvollständige Regelungen sind

zu vermeiden, da im Nachhinein oft nicht mehr festgestellt werden kann,

von welchen Leistungen die Parteien ausgegangen sind. 141 Nur so können

anschließende Auseinandersetzungen eingeschränkt oder vermieden

werden. 142 Zur Erreichung dieses Ziels ist es also zuvor notwendig, eine

„Due Diligence“-Prüfung durchzuführen. Es ist also eine sorgfältige

138 Trienekens / Bouman / van der Zwan, Software Quality Journal, 12, 2004, S. 43

139 so Heymann, T., CR 2005, 706, 707

140 Bräutigam, in: Bräutigam, P., „IT-Outsourcing“,Teil 11, Rdnr. 402

141 vgl Trienekens / Bouman / van der Zwan, Software Quality Journal, 12, 2004, S. 43, 45

142 Heymann, T., CR 2005, 706, 709

- 45 -


Analyse, Prüfung und Bewertung der Leistungen vorzunehmen. Dies kann

oft bis zu einem Monat in Anspruch nehmen und ist entsprechend zu

berücksichtigen. 143

Als ein wichtiges Ziel bei der Gestaltung von SLA gilt u.a., spätere

Vertragsänderungen und -anpassungen (sog. Change-Requests) so gering

wie möglich zu halten. 144 Hierbei spielt es eine besondere Rolle, dass sich

der Nutzer häufig in eine Abhängigkeit zum SaaS Anbieter begibt, wenn er

seine IT-Leistungen zu diesem auslagert. Somit wird er bei künftigen

Change-Requests weniger Druckmittel haben, als sein Anbieter. Zwar

besteht das SaaS Prinzip darin, dass eine Fixierung auf einen bestimmten

Softwareanbieter keine Rolle mehr spielen soll, weil ein Anbieterwechsel

schnell durchgeführt werden kann und zeitintensive Neuinstallationen an

der eigenen IT nicht mehr vorgenommen werden müssen. Dies setzt aber

voraus, dass weitere Anbieter mit genau der gleichen Softwarefunktion

kurzfristig zur Verfügung stehen und alle Unternehmensdaten standardisiert

abgelegt wurden, so dass eine Datenmigration zu dem neuen Anbieter

keinen erheblichen Aufwand mehr darstellt. Solche theoretischen

Bedingungen werden aber auch in naher Zukunft wohl kaum erreichbar sein.

Liegt darüber hinaus noch ein Business-Process-Outsourcing vor, indem der

SaaS Anbieter eine Art Gesamtpaket angeboten hat, wird die Suche nach

einer vergleichbaren Alternative auf noch größere Schwierigkeiten stoßen.

Folglich wird es auch im Rahmen von SaaS zu Abhängigkeiten kommen,

die einen Wechsel erschweren. Das hat aber zur Folge, dass

Vertragsänderungen nur schwer durchzusetzen sind oder aber nur unter

erheblichen Nachforderungen seitens der Anbieter. Aus diesem Grund sollte

zuvor eine Marktanalyse vorgenommen werden, aus der sich ergibt, ob

kurzfristige Wechsel zu anderen SaaS Anbietern möglich sind.

Entsprechend diesem Ergebnis sollten die Planung weit in die Zukunft

gehen und schon zum Zeitpunkt des Entwurfs der SLA die späteren

möglichen Entwicklungen in die Planung mit einbezogen werden.

143 http://www.computerwoche.de/management/it-services/1906289/index4.html

144 Heymann, T., CR 2005, 706, 710

- 46 -


Bsp.: Wer ein SaaS Angebot nutzt, das nur triviale Rechenoperationen ausführt, wird

möglicherweise viele Alternativanbieter auch kurzfristig finden können. Wer ein

komplettes Paket von einem Anbieter nutzt, wie etwa ein CRM oder ein Emailsystem, wird

möglicherweise keine gleichwertigen Alternativen finden können. Dann sollte man

bedenken, dass man für längere Zeit an seinen Anbieter gebunden ist.

Unproblematisch sollte jedenfalls eine Volumenänderung 145 sein, da dies

zur grundlegenden Natur von SaaS gehört. Da SaaS nach dem „pay-as-

use“ Prinzip angeboten wird, können je nach Bedarf Ressourcen

hinzugekauft werden.

c) Strafrechtliche Einflüsse bei der Vertragsgestaltung

Die Nutzung von SaaS hat die Auslagerung von (privaten)

Unternehmensdaten zum Gegenstand, die einer softwaremäßigen

Bearbeitung unterzogen werden sollen. Da hierdurch persönliche Daten in

der Regel an Dritte weitergegeben werden, erlangt der Vorgang auch

strafrechtliche Relevanz. Bei der Ausgestaltung der SLA ist deswegen vor

allem auch an § 203 StGB zu denken.

Nach der Vorschrift ist strafbar, wer ein fremdes Geheimnis, das ihm als

Angehöriger einer der in § 203 StGB genannten Berufgruppen anvertraut

oder sonst bekannt geworden ist, unbefugt offenbart. Die strafrechtlich

relevante Handlung des Offenbaren umfasst hierbei jede Mitteilung über die

geheim zu haltende Tatsache an einen Dritten, dem diese bisher verborgen

war. Ferner mit jedem Zugänglichmachen, das ohne Weiteres die

Kenntnisnahme ermöglicht. 146 Es versteht sich von selbst, dass diese

Vorschrift zu weit führen würde, wenn die geschützten Informationen auch

nicht an die eigenen engen Mitarbeiter weitergegeben werden dürften. Denn

dann wäre ein sachgemäßer Bürobetrieb nicht mehr denkbar. Aus diesem

Grund wird der Kreis der zur Geheimhaltung berufenen Personen durch

§ 203 Abs. 3 S. 1 StGB auf die berufsmäßig tätigen Gehilfen erweitert.

145 vgl. Heymann, T., CR 2005, 706, 710

146 BGH NJW 1995, 2915, 2916; Fischer, Strafgesetzbuch, § 203, Rdnr: 30 ff.

- 47 -


Nach allgemeiner Ansicht ist der Tatbestand nicht erfüllt, wenn das

Geheimnis gegenüber diesen Berufsgehilfen offenbart wird. 147

Es stellt sich somit die Frage, ob der SaaS Anbieter oder auch seine

Subunternehmer berufsmäßige Gehilfen des Nutzers nach dieser Vorschrift

sind.

148

Denn die Meinungen, welche Personen unter diese

Ausnahmevorschriften fallen, gehen weit auseinander. So wird der Begriff

des Gehilfen denn auch gewöhnlich auf solche Personen beschränkt, die

innerhalb des von § 203 Abs. 1 StGB erfassten beruflichen

Wirkungsbereichs eines Schweigepflichtigen eine auf dessen berufliche

Tätigkeit bezogene Unterstützung ausüben, die die Kenntnis fremder

Geheimnisse mit sich bringt oder ohne Überwindung besonderer

Hindernisse ermöglicht. 149 Damit sind folglich nur Personen, wie

Arzthelferinnen, Bürokräfte oder Rechtsanwaltsfachangestellte gemeint, die

unmittelbar im Einflussbereich des Wissensträgers tätig sind und dessen

unmittelbarer Kontrolle unterliegen. Der SaaS Anbieter ist in diesem Sinne

jedoch ein kaum zu kontrollierender Außenstehender. Ob diese traditionelle

Auffassung jedoch noch gerechtfertigt ist, erscheint fraglich. Denn zum

einen sollten auch zukünftige Entwicklungen weiterhin möglich sein,

solange der Zweck der Vorschrift weiter gewahrt wird. Und zum anderen

kann eine solche Beschränkung aus dem Wortlaut nicht gelesen werden, so

dass sich der Gehilfenbegriff an den Zweck der Vorschrift zu orientieren hat.

Diesen Weg geht auch Heghmanns, wenn er sich der effektiven

Steuerungsmacht als entscheidendes Kriterium zuwendet. 150 Da durch

§ 203 StGB das Persönlichkeitsrecht des Geheimnisträgers in seiner

Ausgestaltung als informationelles Selbstbestimmungsrecht geschützt wird,

bestünde für dieses Recht kein Risiko, wenn der Schweigepflichtige (also

der SaaS Nutzer) über eine hinreichende Steuerungsmacht (im Sinne einer

effektiven Kontrolle) hinsichtlich des beauftragten Dienstleistungs-

unternehmens, also dem SaaS Anbieter, verfügt. 151 Denn der Schutz des

147 m.w.N. Heghmanns, M. / Niehaus, H., NStZ 2008, 57, 58

148 zur Problematik beim CloudComputing: Niemann, F. / Paul, A., KuR 2009, 444, 451

149 vgl. Heghmanns, M. / Niehaus, H., NStZ 2008, 57, 58

150 Heghmanns, M. / Niehaus, H., NStZ 2008, 57, 61

151 Heghmanns, M. / Niehaus, H., NStZ 2008, 57, 61 f.

- 48 -


Allgemeinen Persönlichkeitsrechts wird nicht dadurch gewährleistet, dass

die Daten örtlich bei den zum Wissen Berufenen angesiedelt sind, sondern

allein durch die getroffenen Vorkehrungen in technischer und

betriebsorganisatorischer Art. Das heißt, wenn diese Voraussetzungen zum

Schutz der persönlichen Daten vorliegen, ist der Ort der Daten entgegen der

traditionellen Auffassung nicht mehr ausschlaggebend.

Dieser Ansicht ist in vollem Umfang beizupflichten. 152 Da der Schutzzweck

der Vorschrift in dem Schutz des persönlichen Lebens- und Geheimbereich

besteht, liegt keine Gefahr vor, wenn die Daten durch entsprechende

(vertragliche) Vorsichtsmaßnahmen geschützt werden können. Dies gilt

auch, wenn Dritte mit den Daten umgehen. Es ist auch zu bedenken, dass

die Technisierung der Büros und der Verwaltung seit dem Entwurf der

Vorschrift erheblich zugenommen haben. Es kann nicht Sinn und Zweck der

Vorschrift sein, diese Entwicklung zu verhindern. Zudem ist zu bedenken,

dass durch die fortgeschrittene Bürotechnisierung erhebliche neue Gefahren

entstanden sind, wie z.B. das unrechtmäßige Eindringen in die Computer-

systeme. Für den gewöhnlichen Büromitarbeiter sind diese Gefahren kaum

mehr zu überblicken und zu bewältigen. Deswegen wäre dem

Sicherheitsinteresse mehr geholfen, wenn gefährdete Daten zu einem

sicheren Anbieter ausgelagert werden könnten.

Um die Verantwortung des zur Geheimhaltung Berufenen nicht gänzlich aus

der Hand zu geben, muss dieser eine hinreichende Steuerungsmacht

behalten. Diese bestimmt sich im Wesentlichen durch die Ausgestaltung des

Vertragsverhältnisses zwischen dem Nutzer und dem Anbieter. Heghmanns

schlägt deswegen vor, dass ein Mindestmaß an vertraglichen Kriterien, die

der Vertrag aufzuweisen habe, vorliegen sollte, damit von einer

hinreichenden Steuerungsmacht ausgegangen werden kann. Hierbei

verweist er auf die vom Gesetzgeber bereits geregelten Kriterien in

§ 11 BDSG. 153 Dort habe der Gesetzgeber bereits Regelungen getroffen, bei

deren Einhaltung eine Verletzung des Persönlichkeitsrechts des

152 ebenso: Niemann, F. / Paul, A., KuR 2009, 444, 451

153 Heghmanns, M. / Niehaus, H., NStZ 2008, 57, 62

- 49 -


Geheimnisträgers nicht vorliege. Dieser Gedanke soll auf den Tatbestand

des § 203 StGB übertragbar sein.

Diese Vorgehensweise erscheint sehr sinnvoll, um mit den gesetzlichen

Regeln auch weiterhin den technischen Fortschritt interessensgerecht

gestalten zu können. Aus diesem Grund sollten die vertraglichen Regeln

sorgfältig ausgearbeitet werden, bevor dem SaaS Anbieter persönliche und

private Daten zur Bearbeitung übermittelt werden. Auch sollten Regelungen

über den Standort der Software getroffen werden (z.B. nur innerhalb von

Europa).

4. Einzelne Klauseln und ihre rechtliche Bewertung bei

SaaS

Bei der Gestaltung von Service Level Agreements im Zusammenhang mit

SaaS bestimmen einige Schlagworte die Fachdiskussion. Diese sind:

Verfügbarkeit, Vertraulichkeit, Integrität, Authentizität sowie Flexibles

Accounting, dynamische Lizenzierungsmodelle, automatisierte

Bestellprozesse. 154 Die erst genannten Schlagworte umfassen dabei den

Umgang mit persönlichen Daten und die Sicherstellung des Datenschutzes.

Die anderen befassen sich spezifisch mit den Strukturen von SaaS. Im

folgenden Abschnitt sollen mögliche Inhalte für einzelne Klausen zu den o.g.

Schlagworten untersucht werden, die in der Fachpresse regelmäßig

Erwähnung finden, aber auch im Rahmen der Bearbeitung dieser Arbeit für

regelungsbedürftig gehalten wurden.

a) Regelungen über die Systemerreichbarkeit

In diesem Abschnitt werden solche Regelungen behandelt, die die

Erreichbarkeit der Software im Rahmen eines SaaS Vertrags regeln.

154 Köhler-Schute, C., „Software as a Service“, S. 66; Weßelmann, B., iX extra 3/2010 IV,

VI; Schulz, C. / Rosenkranz, T., ITRB 2009, 232, 233 f.

- 50 -


(1) Verfügbarkeitsklausel

Wer die Softwareverwaltung außer Haus gibt, eröffnet ein zusätzliches

Risiko: Die Erreichbarkeit. Denn im Unterschied zur Inhouse Lösung hat

der Nutzer keinen direkten Zugriff mehr auf die Software. Mit vertraglichen

Vereinbarungen kann dieses Risiko begrenzt werden.

(a) Beschreibung

Unter dem Begriff der Verfügbarkeit versteht man die tatsächliche

Nutzungsmöglichkeit der bereitgestellten Leistung, welche durch den

Nutzer abgerufen werden kann. 155 Die Verfügbarkeit wird dabei häufig

durch eine Quotenregelung ausgedrückt, die die Nutzungsmöglichkeit der

Leistung in einem bestimmten Zeitraum spezifiziert (z.B. 98,5 % im

Jahresmittel, was umgerechnet bedeutet, dass dem Kunden die Leistung an

359,5 Tagen zur Verfügung steht). 156 Da IT Leistungen immer dann sofort

zur Verfügung stehen müssen wenn sie gebraucht werden, kommt der

Regelung über die Verfügbarkeit oftmals ein hoher Stellenwert bei der

Gestaltung von SLA zu. 157 Dies gilt erst Recht im Rahmen von Software as

a Service Angeboten. Denn im gleichem Maße, wie dem Anwender bei

einer eigenen Inhouse-Lösung der ständige Zugriff auf die

Softwarefunktionen zur Verfügung steht, sollte der ständige Zugriff auf die

ausgelagerten Softwarefunktionen gewährleistet werden. Ansonst riskiert

man, dass das Outsourcing zum Flaschenhals bei der Erfüllung der

Unternehmensaufgaben wird. Die Festlegung angemessener

Verfügbarkeitsquoten, sog. Key Performance Indicator (KPI), erzeugt

darüber hinaus Vertrauen in die Verlässlichkeit der Nutzbarkeit der

Software. Daneben verhindert der Anbieter, dass er eine Verfügbarkeit von

100 Prozent schuldet, was angesichts der Komplexität von Computersystem

kaum machbar wäre (s.o.). 158

Oftmals werden diese einfachen Verfügbarkeitsquoten nicht ausreichen, um

den besonderen Anforderungen von SaaS gerecht zu werden. Aus

155 Peter, S., CR 2006, 404, 407

156 Peter, S., CR 2006, 404, 407

157 Schumacher, V., MMR 2006, 12, 13

158 Helwig, B. / Koglin, O., DSRI Tagungsband 2009, S 183

- 51 -


Anwendersicht ist die sachgerechte Regelung der Bezugsgröße wichtig. 159

Das heißt, dass der zeitliche Rahmen (Stunden/Tage/Monat/Jahr), indem die

Verfügbarkeit gewährleistet wird, bekannt sein muss. 160 Denn es macht

einen erheblichen Unterschied, ob sich die Verfügbarkeit auf ein Jahr, eine

Woche oder gar auf eine Stunde bezieht. Wird der Zeitraum zu großzügig

gewählt, ist eine ununterbrochene Nichtverfügbarkeit des Systems von bis

zu mehreren Tagen möglich, ohne dass darin eine Leistungsstörung zu

erblicken ist. So erlaubt eine Verfügbarkeitsquote von 98,5 % in einem Jahr

einen Ausfall des Systems von maximal 5,5 aufeinander folgenden Tagen.

Hier wird erkennbar, dass ein solcher durchgehender Ausfall von wichtigen

Softwarefunktionen für ein Unternehmen wirtschaftlich untragbar wäre. Aus

diesem Grund ist der Bezugszeitraum entsprechend zu verringern oder es

sind weitere Regelung zu treffen, die den maximalen ununterbrochenen

Systemausfall begrenzen (z.B. eine maximale Ausfallzeit von 6 Stunden am

Stück).

Zu Beachten ist, dass neben den allgemeinen Verfügbarkeitsregelungen

spezielle Zeiten für Wartungsarbeiten vereinbart werden sollten. Denn

könnte sich der SaaS Anbieter bei jedem Ausfall auf die Behauptung von

notwendig gewordenen (aber planbaren) Wartungsarbeiten zurückziehen,

würde dies jede Quotenregelung entwerten. 161 Somit sind beide Regelungen

strikt zu trennen und gesonderten Vereinbarungen zu unterziehen (hierzu

später).

Bei der Gestaltung der SLA ist es notwendig, sich an dem technischen

Ablauf genau zu orientieren um für jeden Schritt die notwendigen oder

gewünschten Anforderungen zu bestimmten. 162 Nur so können die

Stellschrauben entdeckt und Konflikte vermieden werden. Meines

Erachtens ist es deswegen sinnvoll, sich an der Arbeitsweise von Software

zu orientieren, die nach dem EVA-Prinzip 163 abläuft. Für jeden dieser

Schritte müssen dann die Anforderungen an die Verfügbarkeit

159 Schumacher, V., MMR 2006, 12, 13

160 Schumacher, V., MMR 2006, 12, 14; m.w.N. Helwig, B. / Koglin, O., S. 184

161 Hörl, B. / Häuser, M., CR 2003, 713, 715

162 Helwig, B. / Koglin, O., DSRI Tagungsband 2009, S. 181

163 Eingabe-Verarbeitung-Ausgabe; http://de.wikipedia.org/wiki/EVA-Prinzip

- 52 -


herausgearbeitet werden. Es gilt also, sich über die Anforderungen bei

Eingabe, Verarbeitung und Ausgabe der Daten bewusst zu werden. Da die

Eingabe auch ein leerer Wert sein kann, beschränkt sich der erste Schritt in

diesem Fall folglich nur auf den Programmaufruf. Im Rahmen der

Verfügbarkeitsklausel sollten also zunächst Regelungen über die

Erreichbarkeit der aufzurufenden Softwarefunktion getroffen werden. Dies

kann, wie schon beschrieben, durch die Angabe von Verfügbarkeitsquoten

geschehen. 164 Sinnvoll erscheint aber auch ein zeitlicher Bezugspunkt, bis

zu dem die Software bereit sein muss um Anfragen zu akzeptieren. 165 Denn

eine Erreichbarkeit von 100 Prozent macht wenig Sinn, wenn der

Aufrufende minutenlang warten muss, bis die Software geladen und für die

Dateneingabe bereit ist.

Dieser Gedanke beruht darauf, dass auch eine Software, die durchschnittlich erst nach einer

Minute vollständig auf dem Bildschirm des Nutzers erscheint, eine Erreichbarkeit von 100

Prozent hat, da ja kein Totalausfall vorliegt. Deswegen erscheint es mir sinnvoll, zuzüglich

zur allgemeinen Erreichbarkeit auch eine zeitliche Komponente aufzunehmen. Ist dies nicht

möglich, sollte jedenfalls eine unverzügliche Erreichbarkeit vereinbart werden.

Die anschließenden Schritte „Verarbeitung“ und „Ausgabe“ können

zusammengefasst werden, da es dem SaaS Nutzer überwiegend darauf

ankommen wird, ein zügiges Ergebnis der Berechnungen zu erhalten, was

sich aber am Endergebnis misst. Die Ausgabe kann hierbei in der Rückgabe

des Rechenergebnisses liegen oder in der Speicherung des Ergebnisses in

einer Datenbank oder einem sonstigen Speicherplatz. Dem Benutzer wird es

jedenfalls darauf ankommen, dass er nach der Eingabe nicht minutenlang

auf ein Ergebnis warten muss, sondern zügig weiterarbeiten kann. Auch hier

erscheint eine zeitliche Angabe sinnvoll, zumindest aber eine

schnellstmögliche Verarbeitung, die ein normales Arbeiten des Benutzers

noch gewährleistet.

Wer mit zeitlichen Begrenzungen arbeitet sollte jedoch bedenken, dass nicht

bei jedem Aufruf die zeitlichen Werte eingehalten werden können. Aus

164 Schumacher, V., MMR 2006, 12, 13

165 vgl. Helwig, B. / Koglin, O., S. 184

- 53 -


diesem Grund sollte eine zeitliche Angabe immer mit einer Prozentangabe

verknüpft werden, in der der zeitliche Wert zugesichert wird. Da die

Antwortzeiten jedoch erheblich von der speziellen Anfrage oder dem

speziellen Auftrag abhängen, ist eine Pauschalisierung mit Vorsicht zu

genießen, so dass immer die konkreten Leistungsmöglichkeiten zu

untersuchen sind. 166

Beispiel: „Sobald der Programmaufruf das Rechenzentrum des SaaS Anbieters erreicht,

wird das aufgerufene Programm in 99 Prozent der Fälle dem Nutzer innerhalb von 10 ms

zur Verfügung gestellt und eine Benutzereingabe per API oder HMI ist möglich. Die

Programmfunktion wird in 99 Prozent der Fälle innerhalb von X ms ausgeführt und das

Ergebnis zurückgegeben.“ 167

(b) Rechtliche Einordnung und AGB Bezug

Zur rechtlichen Einordnung der Verfügbarkeitsklausel als

Leistungsbeschreibung oder Gewährleistungsbeschränkung gilt das oben

Gesagte entsprechend. 168 Eine Besonderheit ergibt sich jedoch aus einer

BGH Entscheidung zur klauselmäßigen Zugangsbeschränkung beim Online-

Banking. 169 In diesem Urteil stellte der BGH klar, dass Klauseln in

Allgemeinen Geschäftsbedingungen, die das Hauptleistungsversprechen

einschränken, ausgestalten oder modifizieren, der Inhaltskontrolle

unterliegen. 170 In der streitgegenständlichen Vertragsbestimmung erkannte

der BGH eine solche Einschränkung des Hauptleistungsversprechens. 171

Allerdings konnte das Gericht nur aufgrund der „unglücklichen“

Formulierung der Bestimmung zu diesem Schluss kommen. Denn eine

Verfügbarkeitsquote über die Bankleistungen wurde in dem konkreten Streit

gerade nicht vereinbart. Deswegen kam der BGH zu dem Schluss, dass eine

„rund um die Uhr“ geschuldete Leistungsverpflichtung vereinbart war, die

nachträglich durch die in den AGB enthaltene Klausel wieder eingeschränkt

166

vgl. Söbbing, T., ITRB 2004, 257, 259

167

hier zeigt sicht, dass eine genaue zeitliche Angabe im Millisekundenbereich wohl nicht

immer im Interesse der Parteien liegt, da sie nicht genügend Spielraum lässt oder auch nicht

kontrollierbar ist.

168

siehe S. - 39 -, Abschnitt B.III.2.b)

169

BGH, CR 2001, 181

170

BGH, CR 2001, 181

171

zum genauen Wortlaut der Klausel: vgl. BGH, CR 2001, 181

- 54 -


wurde. 172 Keine Einschränkung, Ausgestaltung oder Modifizierung des

Hauptleistungsversprechens liegt aber dann vor, wenn durch eine Klausel

Art, Umfang oder Güte der Leistung festgelegt wird. Eine solche

Leistungsfestlegung erfolgt aber gerade durch die Verwendung von

Verfügbarkeitsquoten, da mit ihnen die Leistung nach Art, Umfang und

Güte bestimmt wird. Bei entsprechender Ausgestaltung solcher Klauseln

sollte folglich kein Auslegungsspielraum mehr für eine anderweitige

Einordnung bleiben, mit der Folge, dass eine Unwirksamkeit nach AGB-

Recht ausgeschlossen ist. 173

Es stellt sich weiterhin die Frage, ob die Benutzung von

Verfügbarkeitsquoten gegen das Transparenzgebot verstößt (§ 307 Abs. 1

Satz 2 BGB). 174 Denn durch die Regelung bleibt der Nutzer im Ungewissen,

wann genau ihm die Leistung nicht zur Verfügung stehen wird. Der BGH

vertritt die Meinung, dass der Verwender von AGB entsprechend den

Grundsätzen von Treu und Glauben gehalten ist, Rechte und Pflichten

seines Vertragspartners möglichst klar und durchschaubar darzustellen. 175

Er vertritt aber auch die Meinung, dass dieses Gebot nur im Rahmen des

Möglichen gilt. 176 Aus diesem Grund kann es eine Verpflichtung zu einer

weitergehenden Transparenz nicht geben. 177 Denn bei technisch komplexen

Systemlösungen gibt es bei der Bereitstellung immer Unsicherheiten, die

nicht kontrollierbar sind. Dies gilt auch im Rahmen einer Vereinbarung von

Verfügbarkeitsklauseln. Durch deren Vereinbarung wird der Versuch

unternommen, ein Gleichgewicht zwischen dem Leistungsinteresse des

Nutzers, der Bezahlbarkeit der Leistung und der Leistungsfähigkeit des

Anbieters zu schaffen. In diesem Verhältnis spielt eine Rolle, dass der

Anbieter bei komplexen Computersystemen eine Verfügbarkeit von 100 %

nicht leisten kann oder nicht zu einem bezahlbaren Entgelt. Auf der anderen

Seite besitzt der Nutzer selbst gar nicht den Anspruch eine solche Leistung

172 BGH, CR 2001, 181, 182; ebenso Peter, S., CR 2006, 404, 408

173 ebenso Peter, S., CR 2006, 404, 408 ff.

174 vgl. Peter, S., CR 2006, 404, 411

175 BGH MDR 2001, 1057; BGH MDR 1998, 90

176 BGH NJW 1998, 3214, 3116; BGH NJW 1993, 2052

177 a.A. Spindler, G., CR 2003, 203, 208; der eine Verfügbarkeit auf 1 Jahr bezogen als ein

Verstoß gegen das Transparenzgebot sieht.

- 55 -


zu erhalten. Denn auch bei herkömmlichen Inhouse Lösungen gibt es keine

Verfügbarkeit der Systeme zu 100 Prozent.

Man könnte sogar die Behauptung aufstellen, dass die meisten betriebseigenen

Computersystem eine schlechtere Verfügbarkeit haben, da eine Wartung der System nicht

mit der gleichen Qualität erfolgen kann, wie bei einem IT Outsourcer, der viele Spezialisten

beschäftigt. Auch ist davon auszugehen, dass bei Inhouse Lösungen nicht ständig

Fachpersonal zur Verfügung steht, um Fehler zu beseitigen. Dies verlängert am Ende die

Ausfallzeiten.

Der Nutzer wird sich deswegen qualitativ wohl nicht verschlechtern, wenn

er seine Systeme auslagert und hierbei nur eine unwesentlich geringere

Verfügbarkeit als 100 Prozent erhält. Allgemein lässt sich sagen, dass

Regelungen über die Verfügbarkeit keinen umfassenderen Besonderheiten

unterstehen, als bei anderen Software-Outsourcing Projekten auftreten, wie

etwa ASP. 178 Allerdings sollte eines beachtet werden: Wenn sich der SaaS

Anbieter Subunternehmen bedient, welche bestimmte Funktionen des

Programms übernehmen und diese ebenfalls wieder Subunternehmer

einsetzen können, besteht die Gefahr, dass sich aufgrund dieses

sequentiellen Ablaufs die Erreichbarkeit des Gesamtsystem am Ende

verlangsamt. Gleiches gilt auch für den Ausfall des Gesamtsystems, der

jedes Mal auftreten könnte, wenn ein Subsystem gestört ist.

(2) Wartungsklauseln

Mit den Wartungsklauseln (der sog. „scheduled downtime“) werden solche

Zeiträume umfasst, in denen das System etwa wegen Wartungsarbeiten,

Softwareinstallationen oder auch wegen der Durchführung von Backups

geplant nicht operativ zur Verfügung steht. 179 Nicht umfasst werden dürfen

allerdings Wartungsarbeiten, die durch grobe Fahrlässigkeit des Providers

verursacht wurden, da diese Klauseln einen Schadensersatzanspruch

implizit ausschließen würden, was gegen § 309 Nr. 7 b BGB verstoßen

würde. 180 Die in den Wartungszeiten fehlende Verfügbarkeit des Systems

wird nicht als Ausfall bewertet und somit nicht von den Regeln der

178 Schuster, F. / Reichl, W., CR 2010, 38

179 vgl. Bräutigam, P., CR 2004, 248, 252, Spindler, G., CR 2004, 203, 205

180 Spindler G., CR 2004, 203, 209

- 56 -


Verfügbarkeit umfasst. 181 Andererseits darf der Anbieter planbare

Wartungen auch nicht außerhalb dieser Zeiten vornehmen. In diesem Fall

würde dies trotzdem zu Lasten der allgemeinen Verfügbarkeit gehen.

b) Regelungen zum Datenumgang

Im Rahmen von SaaS entsteht, wie auch allgemein im Rahmen von Cloud

Computing, ein besonderer Regelungsbedarf im Umgang mit den Daten, die

zur Bearbeitung an die Software übergeben werden. In diesem Teil sollen

Regelungen aufgezeigt werden, die den Datenaustausch betreffen.

(1) Datenschutz

Noch mehr als bei ASP Verträgen ist das Thema des Datenschutzes bei

SaaS zu berücksichtigen. Geht man davon aus, das durch SaaS eine

erhebliche Virtualisierung der Softwarearchitektur folgt, aufgrund dessen

Teile der Softwarefunktionen auch auf Dritt ausgelagert werden können, ist

es mögliche, dass Daten zukünftig in einem Umfang ausgetauscht werden,

der bisher kaum vermutet werden konnte. Deswegen ist im Vorfeld zu

klären, wie die Daten des Nutzers verwendet werden dürfen (z.B.

Speicherung nach erfolgter Aufgabenerfüllung) und ob eine Weiterleitung

an Subunternehmen erfolgen darf. Es geht also auch um die Freiheit der

Leistungserbringung, nach welcher der Anbieter frei darin ist, wie er das

vereinbarte Ziel erreicht. 182 Diese Freiheit ist im Rahmen von SaaS

Angeboten noch höher, als bei herkömmlicher Software. Denn wie die

Wassertropfen in einer Wolke frei in ihrer Bewegung sind, kann der

Anbieter mittels SaaS seine Software ständig umgestalten (örtlich wie

strukturell). Das größte Problem liegt aber darin, Funktionsteile der

Software durch Dritte erbringen zu können (Bsp. Rechtschreibprüfung,

Erstellung von Gehaltsabrechnungen etc.). Gründe hierfür gibt es viele (z.B.

Spezialisierung oder erschöpfte Ressourcen). Aufgrund des SaaS Prinzips

wird der Nutzer hiervon kaum etwas mitbekommen. Jedenfalls ist damit zu

181 vgl. Bräutigam, P., CR 2004, 248, 252 f.

182 Heymann, T., CR 2005, 706, 709

- 57 -


echnen, dass in diesem Fall erhebliche Datenmengen an Dritte weitergeben

werden können.

Anmerkung: Wer kann heute schon sagen, ob sämtliche Funktionen, die ein Webmail

Anbieter bereitstellt, sich auch auf seinen Servern befinden oder innerhalb seiner Software

durchgeführt werden. Die Speicherung der Emails könnte in einem ganz anderen Land

erfolgen, als die visuelle Aufbereitung für die Weboberfläche.

Diese neuen Möglichkeiten müssen erkannt und datenschutzkonformen

Regelungen unterworfen werden.

In technischer Hinsicht ergibt sich bei der Nutzung von SaaS eine weitere

Besonderheit, die bei IaaS, wie z.B. dem CloudStorage, weitgehend nicht

auftritt. Dies betrifft die Möglichkeit der Datenverschlüsselung. Da bei

IaaS-Angeboten grundsätzlich keine Berechnungen mit den Daten

durchgeführt werden, können diese in verschlüsselter Form „in die Wolke

abgegeben“ werden. Folglich ist es möglich, Belangen des Datenschutzes

sehr leicht nachzukommen. Bei SaaS Anwendungen wird mit den Daten in

der Regel gerechnet, so dass eine Verschlüsselung der Daten von vornherein

ausgeschlossen ist. Dies bedeutet, dass die Daten nur unverschlüsselt in die

Cloud gegeben werden können, da eine „voll homorphe“ Verschlüsselung

jedenfalls zur Lösung dieses Problems noch nicht existiert. 183 Als

Alternative verbleibt somit nur die Anonymisierung der Daten, um

datenschutzrechtlichen Belangen beim Datenaustausch zu begegnen.

Aufgrund der umfangreichen datenschutzrechtlichen Besonderheiten wird

dieses Thema in einem gesonderten Abschnitt später umfassender behandelt.

(2) Datenmigration und Datenstandardisierung

Nach einer Risikoanalyse der European Network and Information Security

Agency (ENISA) 184 besteht bei CloudComputing, zu dem auch SaaS zu

183 dies ist die Möglichkeit mit Daten auch in verschlüsselter Form zu rechnen und dabei

dennoch die richtigen Ergebnisse zu erzielen. Siehe:

http://www.heise.de/newsticker/meldung/Voll-homomorphe-Verschluesselung-in-der-

Cloud-1021361.html

184 Catteddu, D. / Hogben, G., „Cloud Computing Risk Assessment“

- 58 -


zählen ist 185 , das Risiko einer verschärften Abhängigkeit vom SaaS Anbieter,

wenn die Portabilität der ausgelagerten Daten nicht gewährleistet ist.

Hierbei betrifft die Portabilität der Daten sowohl deren Rückholung wie

auch deren Vorliegen in einem standardisierten Format. Auch wenn die

Grundidee von SaaS dahin geht, dass Softwarefunktionen auch von anderen

Anbietern angeboten werden können und ein Wechsel problemlos möglich

sein soll (genauso wie der Wechsel zu einem anderen Telefonanbieter), wird

diese Idealvorstellung so schnell wohl kaum erreichbar sein. Solange nicht

einheitliche Datenformate von jedem Anbieter benutzt werden (z.B. XML),

wird es für die Nutzer erforderlich, eigene Programmroutinen zu entwerfen,

welche die Daten aus dem ursprünglichen Format extrahieren und in das

zukünftige Format importieren. 186 Dadurch wird ein Wechsel zu einem

anderen Anbieter erheblich schwieriger und er ist mit einem hohen

Aufwand an Zeit und Geld verbunden. 187 Neu ist diese Problem zwar nicht,

sollte aber nunmehr in den Blickpunkt einer Fachdiskussion gebracht

werden, zumal sich mit SaaS die Gelegenheit bietet, von Insellösungen

abzukommen.

Anmerkung: Im Grunde ist es nachvollziehbar, dass sich die ersten SaaS Lösungen dort

entwickelt haben, wo schon gemeinsame Standards bestanden. So konnte die

Emailkorrespondenz schon frühzeitig vom eigenen lokal installierten Emailclient auf

entsprechende Webservices ausgelagert werden. Denn das Emailprotokoll unterliegt

zwingenden Standards (z.B. SMTP, POP oder IMAP). Selbst der Aufbau einer Email ist

standardisiert. 188 Das IMAP Protokoll standardisierte sogar die Emailablage und den

Zugriff. Der Wechsel von einem Anbieter zu einem anderen ist heute grundsätzlich

problemlos möglich. Lediglich wenn Zusatzfunktionen benutzt werden (etwa

Kalenderfunktionen) können erneut Probleme auftreten, da hierfür meist Standards fehlen.

Bei Unternehmensfunktionen hingegen, wie CRM oder ERP, bestehen kaum Standards bei

der Datenablage. Dies erschwert meines Erachtens die Einführung von webbasierten SaaS

Lösungen.

Aus diesem Grund ist es notwendig die neu entstandenen Risiken bei SaaS

verstärkt in den Verträgen zu regeln um sie dadurch beherrschbar zu

185 Catteddu, D. / Hogben, G., „Cloud Computing Risk Assessment“, S. 15

186 Catteddu, D. / Hogben, G., „Cloud Computing Risk Assessment“, S. 26

187 Schulz, C. / Rosenkranz, T., ITRB 2009, 232, 234

188 Jede Email besteht aus einem Header und einem Body, der die Nachricht enthält. Der

Header selbst enthält wieder Attribute für Herkunft, Ziel, Zeit oder Betreff.

- 59 -


machen. 189 Hierzu gehören eben auch Regelungen zur Datenmigration. 190

Dies bedeutet, dass die Form der Daten möglichst standardisiert akzeptiert

werden und bei einem späteren Vertragsende in einem standardisierten

Format dem Unternehmen zurückgegeben werden. Bleiben diese Fragen

ungeklärt, entsteht eine schwerwiegende Abhängigkeit. Ein Wechsel zu

einem anderen Anbieter wird kostspielig, wenn dieser die vorhandenen

Daten nicht problemlos in sein System migrieren kann. Selbst eine

Rückkehr zu einer Inhouselösung wird erschwert, wenn die Daten vorher

wieder mühsam für das hauseigene System angepasst und integriert werden

müssen. 191 Ohne einen standardisierten Umgang mit den Daten werden viele

Vorteile von SaaS neutralisiert und man muss sich die Frage stellen, ob

nicht doch eine ganz bestimmte Softwarelösung eines großen

Softwarehauses vorteilhafter ist als eine SaaS Lösung. Um den Wechsel

zwischen verschiedenen Anbietern zu erleichtern, sollte auch über die

Möglichkeit eines direkten Datenaustausches zwischen den Anbietern einer

Regelung unterworfen werden. Auf jeden Fall sollte der SaaS Anbieter

verpflichtet werden, die angefallenen Daten in einem brauchbaren Format

zurückzugeben, wenn der Vertrag beendet wird

Darüber hinaus sollten auch die zeitlichen Aspekte der Datenmigration nicht

unbeachtet bleiben. Denn es hat keinen Zweck auf eine SaaS Lösung

umzusteigen, wenn die Altdaten nicht in kurzer Zeit vollständig im neuen

System zur Verfügung stehen. Der Anbieter selbst kann sich auf die

Migration vorbereiten indem er gängige Datenformate akzeptiert, aber auch

seine eigenen Datenstrukturen offen legt, so dass der Nutzer sich hierauf

vorbereiten kann indem er z.B. seine Daten rechtzeitig anpasst.

(3) Datenrückholung

In Konfliktsituationen können Probleme entstehen, die den SaaS Anbieter

möglicherweise dazu veranlassen, die bei ihm gespeicherten Daten

zurückzuhalten (§§ 273, 320, 322 BGB). 192 Ein Zurückbehaltungsrecht kann

189 Weßelmann, B., iX extra 3/2010 IV

190 vgl. Heymann, T., CR 2005, 706, 707

191 Weßelmann, B., iX extra 3/2010 IV, VI

192 hierzu DStR 2009, 2700

- 60 -


aber nur an solchen Daten bestehen, die bei dem Anbieter gespeichert sind.

Allerdings besteht die Hauptleistungspflicht bei SaaS nicht im Speichern der

Daten, so dass diesbezüglich auch kein Zurückbehaltungsrecht ausgeübt

werden kann. Diese kann somit nur aus weiteren Nebenabreden entstehen,

welche die Datenspeicherung betreffen. Beide Leistungen sind aber in der

Regel eng miteinander verflochten.

Werden schon im Vorfeld Regelungen in diesem Bereich getroffen, können

später in einem Konfliktfall klare Linien gezogen werden und der SaaS

Nutzer muss nicht befürchten, dass er seine existenziellen

Unternehmensdaten nicht mehr zurückerhält oder nur mit Verzögerung.

Schon zur Vertrauensförderung für diese neue Technik macht es Sinn, auf

das Zurückhaltungsrecht weitgehend zu verzichten. Rechtliche Bedenken

hiergegen wegen AGB Vorschriften bestehen nicht, da § 309 Nr. 2 BGB

nicht anwendbar ist, wenn dieser Ausschluss gegenüber einem Unternehmer

verwendet wird (§ 310 Abs. 1 BGB). Darüber hinaus besteht die

Möglichkeit die Ausübung des Zurückbehaltungsrechts durch

Sicherheitsleistung abzuwenden (§ 273 Abs. 3 S. 1 BGB). Ferner kann auch

ein treuwidriges Verhalten darin liegen, wenn die Zurückhaltung der Daten

gegen Treu und Glauben verstößt (§ 242 BGB). Wann diese angenommen

werden kann ist kaum vorhersehbar. Auch dürfte regelmäßig schon zu viel

Zeit bis zur Klärung des Sachverhalts vergehen, in der auf den Zugriff der

Daten nicht verzichtet werden kann. Aus diesem Grund sollten Regelungen

schon im Vorfeld getroffen werden.

(4) Regelungen über den Softwarestandort

Regelungen über den Softwarestandort, also dem Serverstandort, gewinnen

besonders unter datenschutzrechtlichen Gesichtspunkten an Bedeutung und

werden deshalb in einem späteren Abschnitt eingehender untersucht.

Grundsätzlich stehen sich Regelungen über den Softwarestandort im

Rahmen von Cloud Computing diametral gegenüber. Denn wie das Internet

verfolgt das Cloud Computing eine dezentrale Strategie, die sich die

weltweite Vernetzung von Rechnern zunutze macht. Da Entfernungen keine

- 61 -


Rolle mehr spielen, können die Server an jedem Ort der Welt stehen. 193 Da

hierbei jedoch erheblich datenschutzrechtliche Bedenken und

Befürchtungen über die Sicherheit bestehen, haben sich sog. EU-Clouds

entwickelt. 194 Dies sind vertragliche Vereinbarungen darüber, dass die

angebotenen Leistungen nur mittels Server zur Verfügung gestellt werden,

die sich in der EU befinden. Es ist vorstellbar, dass solche Regelungen auch

jede andere lokale Begrenzung beinhalten können.

c) Compliance und Auditfähigkeit

Das Gesetz schreibt vor allem im unternehmerischen Umfeld diverse

Regelungen vor, welche die Verantwortung der Unternehmensleitung oder

die Bereithaltung von Daten zwecks Herausgabe an Behörden strengeren

Anforderungen unterstellen. 195 So regelt z.B. § 257 Abs. 1 HGB die Pflicht

zur Bereithaltung der zu führenden Bücher für zehn Jahre. Aus § 146 Abs. 2

AO folgt eine Aufbewahrungspflicht für Bücher und sonst erforderlichen

Aufzeichnungen der Buchhaltung. Solche gesetzlichen Anforderungen sind

auch im Rahmen von SaaS Leistungen zu berücksichtigen. Allerdings

betreffen sie weniger die durch SaaS zu erbringende Leistung, als vielmehr

die meist in diesem Zusammenhang zusätzlich vereinbarte Speicherung der

Daten, die unabhängig von der Erbringung der Softwarefunktionen ist. Denn

die eigentliche SaaS Leistung endet grundsätzlich mit der Berechnung und

der Rückgabe der Ergebnisse an den Nutzer. Die rechtliche Problematik ist

folglich bei den Abreden über Speicherpflichten zu berücksichtigen.

d) Sanktionsmechanismen

Zu Recht heißt es, dass die Gestaltung von SLA unvollständig wäre, wenn

Sanktionsmechanismen für den Fall fehlen würden, dass der Anbieter seine

geschuldete Leistung nicht erfüllt. 196 Zwar unterwirft sich der Anbieter

hierbei einem zusätzlichen Haftungsregime, das neben die gesetzlichen

193 Söbbing, T., MMR 2008, XII, XIV

194 Niemann, F. / Paul, A., KuR 2009, 444, 449

195 hierzu: Niemann, F. / Paul, A., KuR 2009, 444, 450 ff.

196 vgl. Schumacher, V., MMR 2006, 12, 14

- 62 -


Regelungen tritt. Es muss aber erkannt werden, dass das gesetzliche

Haftungsregime für komplexe IT-Verträge oftmals nicht weiter hilft, so dass

der Anbieter, wie auch der Nutzer, mit einer unklaren Rechtslage

konfrontiert werden, die keinem weiter hilft. 197 Außerdem muss beachtet

werden, dass mit SaaS erhebliche betriebsinterne IT-Strukturen nach außen

gelagert werden, die wichtig für die Existenz eines Unternehmens sind und

ein hohes Maß an Vertrauenswürdigkeit erfordern. In diesem

Zusammenhang wirkt es sehr vertrauensbildend, wenn sich der SaaS

Anbieter dieser Lage bewusst ist und durch entsprechende Haftungsregime

zum Ausdruck bringt. Dadurch zeigt er, dass er sich der neuen Risiken

bewusst ist und hierfür sichere Lösungen anbieten kann. Für die weitere

erfolgreiche Entwicklung des SaaS Geschäftsfelds erscheint mir dies sehr

wichtig, da noch sehr viel Misstrauen in diese Art der Auslagerung von

Geschäftsprozessen besteht. 198

Als Sanktionsmechanismen kommen u.a. Vergütungsminderungen, Ver-

tragsstrafen, pauschalierte Schadensersatzzahlungen, Bonus/Malus Systeme

und Kündigungsmöglichkeiten in Betracht. 199 Diese können in einem

Stufenmodell zur Anwendung kommen. Auf den ersten Stufen, die nur

geringfügige Verfehlungen betreffen (und für den Kunden lediglich lästig

sind) erfolgt eine Minderung. Die zweite Stufe, welche erhebliche

Unterschreitungen der Service Levels umfasst, hält Vertragsstrafen und

pauschalierte Schadensersatzansprüche bereit. Auf der dritten Stufe werden

Kündigungsrechte für besonders schwerwiegende Verletzungen der Service

Levels bereitgehalten. 200 Zwar werden diese Haftungsregelungen zuweilen

nur für Schlechtleistungen bei der Leistungsverfügbarkeit vorgenommen.

Meines Erachtens sollte aber auch darüber nachgedacht werden, besondere

Vertragsstrafen für den Fall von Sicherheitsverletzungen einzuführen.

Dadurch könnte ein erheblicher Vertrauensgewinn für die Integrität der

Systeme des SaaS Anbieters erreicht werden.

197 Schumacher, V., MMR 2006, 12, 14

198 hierzu: Catteddu, D. / Hogben, G., „Cloud Computing Risk Assessment“

199 Schuster, F., CR 2009, 205, 208; Schumacher, V., MMR 2006, 12, 15

200 Braun, H., „Die Zulässigkeit von Service Level Agreements“, S. 18 f.

- 63 -


(1) Vergütungsminderung

Werden die vereinbarten Service Levels nicht erreicht können je nach Grad

der Schwere Minderungen des Leistungsentgeltes vereinbart werden.

Teilweise wird ein Stufenmodell empfohlen, welches auf der ersten Stufe

die Minderung von dem Ausmaße der Unterschreitung des jeweiligen

Service Level abhängig macht. 201 Je nachdem ob ein einfacher Fall oder ein

schwerwiegender Fall (z.B. bei langfristigen oder wiederholten Ausfällen)

der Schlechtleistung vorliegt, erfolgt eine prozentuale Minderung, die bei

der monatlichen Rechnung geltend gemacht wird. 202 Bei SaaS Leistungen

kann dies z.B. darin liegen, dass das System gar nicht verfügbar ist (also

schon nicht erreichbar ist) oder nur mit erheblichen zeitlichen

Verzögerungen abläuft (z.B. ständiges Warten bei der Aufgabenerfüllung).

Ebenfalls können solche Ausfälle bei der Datenmigration auftreten, wenn

diese nicht in dem vereinbarten Zeitpunkt durchgeführt wurde. Eine

Vergütungsminderung bietet sich evtl. auch dann an, wenn zu häufig

Änderungen an der Benutzerschnittstelle (Weboberfläche) vorgenommen

werden, so dass sich die Nutzer immer wieder neu darauf einstellen müssen.

Bisher verärgerten „Redesigns“ vor allem Nutzer von kostenlosen SaaS-

Angeboten, die aber meist ohne Konsequenzen für die Anbieter blieben. 203

Eine Vereinbarung von Vergütungsminderungen mit AGB Recht wird

allgemein als unproblematisch gesehen. Lediglich in den Fällen, in denen

die Leistung dem Dienstleistungsvertragsrecht unterfallen würde, könne ein

Verstoß gegen § 307 Abs. 1 Nr. 2 BGB entstehen, da das Minderungsrecht

dem wesentlichen Grundgedanken der gesetzlichen Regelung

entgegenstehen würde.

204

Dies deswegen, weil den miet- und

werkvertraglichen Regelungen Minderungsrechte bekannt sind, dem

Dienstvertragsrecht jedoch nicht. Wird der SaaS Vertrag mit der hier

201 Schumacher, V., MMR 2006, 12, 15; Hörl, B. / Häuser, M., CR 2003, 713, 717

202 Schumacher, V., MMR 2006, 12, 15

203 z.B. Facebook: Riegler, Birgit, in: http://derstandard.at/1263706798746/Neues-

Facebook-Layout-spaltet-Community (Stand: 04.07.2010)

204 Schumacher, V., MMR 2006, 12, 15; Schuster, F., CR 2009, 205, 209; Bräutigam, P.,

CR 2004, 248, 251

- 64 -


vertretenen Ansicht als Werkvertrag angesehen, sollten keine rechtlichen

Probleme aufkommen.

(2) Vertragsstrafen und pauschalierter Schadensersatz

Durch die Vertragsstrafe (Pönale) verspricht der Leistungserbringer eine

gewisse Geldsumme für den Fall, dass er seine Leistung nicht oder nicht in

der versprochenen Güte erbringen konnte. 205 Durch sie soll die Erfüllung

der Leistung gesichert werden. 206 Der pauschalierte Schadensersatz soll

hingegen den Schadensbeweis ersparen und somit als Beweiserleichterung

dienen, indem er den Nachweis der Schadenshöhe überflüssig macht. 207 Im

Bereich der Vertragsstrafe sieht Schuster sogar erhebliche Probleme bei der

Anwendung von § 340 BGB in IT-Verträgen. 208 Diese Vorschrift sei

abzubedingen, da die Parteien in der Regel bei einer Unterschreitung der

Service Level eine „mangelhafte Leistung“ erkennen würden und keine

Nicht-Leistung. Somit wäre allein § 341 BGB die einschlägige Norm, was

hierdurch nochmals klar gemacht werden würde. Dem kann soweit

zugestimmt werden, da im Falle von Streitigkeiten ein Auslegungsspielraum

für das Gericht entsteht. 209 Rein deklaratorisch sollte auch § 341 Abs. 3

abgedungen werden. 210 Der Nutzer wird den Mangel erst bei der

Softwarenutzung erkennen. Dann könnte aber die Gefahr bestehen, dass die

Leistung als angenommen gilt, wenn der Nutzer die Softwarefunktionen

auch mit Verzögerung ausgeführt hatte.

(3) Vertragsstrafen bei Sicherheitsverletzungen

Das Thema Vertragsstrafen kann bei großen Anbietern teilweise als „heißes

Eisen“ angesehen werden. Bevor sich der SaaS Anbieter unvorhersehbaren

Haftungsregime aussetzt, verzichtet er lieber gleich darauf. 211 In der

Literatur wird dieses Thema weniger skeptisch betrachtet. Sanktionen für

die Nichteinhaltung von Service Levels werden als eine gute Regelung

205 vgl. Bräutigam, P., CR 2004, 248, 251; Schuster, F., CR 2009, 205, 209

206 Schuster, F., CR 2009, 205, 209

207 Schuster, F., CR 2009, 205, 209; Bräutigam, P., CR 2004, 248, 251

208 Schuster, F., CR 2009, 205, 208

209 Grüneber, in: Palandt, BGB, § 340, Rdnr. 2

210 vertiefend: Schuster, F., CR 2009, 205, 208 f.

211 Dies konnte der Autor in Gesprächen erfahren.

- 65 -


gesehen, die die Parteien möglichst umfassend und abschließend vertraglich

regeln sollten. 212 Begründet wird dies mit den kaum zu befriedigenden

Ergebnissen führenden gesetzlichen Regelungen. 213 Darüber hinaus können

Vertragsstrafen aber auch eine Maßnahme zur Vertrauensförderung sein.

Bedenkt man, dass viele Unternehmen den Schritt zu SaaS deswegen

scheuen weil sie Sicherheitsbedenken haben, könnte es hilfreich sein

Vertragsstrafen besonders für den Fall von Sicherheitsverletzungen zu

vereinbaren. 214 Dadurch würde der Nutzer zumindest das Gefühl erhalten,

dass alles Mögliche getan wird, um Sicherheitsverletzungen zu verhindern.

Meines Erachtens stellen Sicherheitsaspekte einen Dreh- und Angelpunkt

dar, wenn Unternehmen sich im Rahmen von SaaS für das Outsourcing

entscheiden. Die Sicherheit von Unternehmensdaten hat einen hohen

Stellenwert. Nicht jeder will und nicht jeder darf sich bei seinen Geschäften

in die Karten schauen lassen. Dadurch, dass Systeme ausgelagert werden,

entsteht ein ganz neues Sicherheitsrisiko und nicht lediglich eine

Verlagerung von der Inhouse Lösung zur SaaS Lösung. Dieses zusätzliche

Risiko muss vertraglich abgesichert werden. Wenn die SaaS Anbieter mit

Sicherheit werben, sollten sie sich auch beim Wort nehmen lassen und

entsprechende Vertragsstrafen akzeptieren. Ansonst könnte das SaaS

Modell sehr schnell unglaubwürdig werden.

(4) Außerordentliche Kündigung

Bei schweren Verstößen gegen die Leistungspflicht oder bei wiederholten

Störungen gegen die vereinbarten Service Levels kann und sollte eine

Regelung zur außerordentlichen Kündigung getroffen werden. 215 Zwar sieht

§ 314 BGB ein gesetzlich geregeltes Kündigungsrecht vor, allerdings lässt

dies einen erheblichen Beurteilungsspielraum zu, der im Falle einer

Konfliktsituation zu viele unbeherrschbare Variable zulässt und den

Gerichten zu viel Entscheidungsspielraum überlässt. Daher sollten sich die

Parteien nicht auf die gesetzliche Regelung mit dem auslegungsbedürftigen

212 Hörl, B. / Häuser, M., CR 2003, 713, 717

213 Hörl, B. / Häuser, M., CR 2003, 713, 717

214 Catteddu, D. / Hogben, G., „Cloud Computing Risk Assessment“

215 Schumacher, V., MMR 2006, 12, 16; Bräutigam, P., CR 2004, 248, 252

- 66 -


Tatbestand des „wichtigen Grundes“ verlassen. 216 Stattdessen sollten die

Kündigungsgründe genau geregelt werden, so dass für beide Parteien

vorhersehbar wird, wann ein zur Kündigung berechtigender Vorfall

eingetreten ist. Denn werden die Kündigungsregeln nicht spezifiziert, läuft

der die Kündigung erklärende Partner immer Gefahr, dass die Kündigung zu

Unrecht erklärt wurde. Dies kann gegen ihn Schadensersatzansprüche

auslösen, wenn er aufgrund der Kündigung seine Leistungspflicht nicht

mehr erfüllt. Bei der Spezifizierung ist auch auf die besondere Schwere

einer Pflichtverletzung zu achten. Denn ein Systemausfall zur Nachtzeit ist

weniger gravierend, als zur Hauptgeschäftszeit. 217 Auch werden zu häufige

Änderungen an der Benutzerschnittstelle nicht unbedingt einen

Kündigungsgrund darstellen. Da die Kündigung die größtmögliche

Konsequenz im Stufensystem ist, sollte sie deswegen nur bei besonders

gravierenden Verletzungen oder der Verletzung wichtiger Service-Levels

erfolgen. 218

e) Service Level Management

Service-Levels und Sanktionsregime wären wirkungslos, wenn die

gefundenen Service Levels nicht überwacht würden und die Ergebnisse in

sog. Reportings den Vertragsparteien mitgeteilt würden. 219 Auch kann die

Überwachung selbst wieder Ausgangssituation für Konflikte sein, wenn es

darum geht, die aufgetretenen Mängel auf der Grundlage der durchgeführten

Messmethoden anzuerkennen. Ob eine Erlaubnis zum Besuch der

Betriebsstätte des Anbieters zur Durchführung einer Kontrolle sinnvoll ist,

erscheint allerdings im Rahmen von SaaS fraglich. 220 Denn zum einen wird

die räumliche Distanz zwischen Anbieter und Nutzer, die gerade durch SaaS

ermöglicht wird, eine zu große Hürde darstellen, um regelmäßige

Untersuchungen vor Ort durchführen zu können. Zum anderen ist evtl. nicht

eine einzige Betriebsstätte der Server ausfindig zu machen. Der Sinn einer

216 vgl. Schumacher, V., MMR 2006, 12, 16

217 Bräutigam, P., CR 2004, 248, 252

218 Bräutigam, P., CR 2004, 248, 252

219 Schumacher, V., MMR 2006, 12, 16

220 so aber: Schumacher, V., MMR 2006, 12, 16 f.

- 67 -


solchen Regelung wäre folglich fraglich. Darüber hinaus stellt jeder Besuch

der Betriebsstätten ein zu hohes Sicherheitsrisiko dar, da die gleichen

Systeme im Rahmen von SaaS auch von anderen Kunden genutzt werden.

Das Sicherheitsrisiko für deren Daten würde hierdurch massiv erhöht.

Soweit technisch machbar, wäre die Nutzung einer sog. Service-Level

Management Software vorteilhafter. Diese Software könnte mittels

vordefinierter Parameter beim SaaS Nutzer vor Ort eingesetzt werden und

mittels Simulation eines normalen Zugriffs auf das SaaS System die

Leistungsfähigkeit des Systems überprüfen und protokollieren. Die

Ergebnisse könnten als Grundlage für das weitere Vorgehen genutzt werden.

f) Sonstiges

(1) Systemverantwortung

Aufgrund von Virtualisierung und den Möglichkeiten der

Modularisierungen können im Rahmen von SaaS grundsätzlich

verschiedene Anbieter einzelne Softwarefunktionen übernehmen, welche

dann durch einen Hauptanbieter koordiniert und zu einer virtuellen Software

zusammengefügt werden (Bsp: Rechtschreibprüfung und Ausgabe von .pdf

Dateien im Rahmen eines Office-Programms). Fällt hierbei ein Subsystem

aus, folgen auf die Haftungsfragen unweigerlich Fragen nach der

Systemverantwortung, also der Verantwortlichkeit hinsichtlich des

Gesamtsystems. 221 Eine Systemverantwortung des Anbieters wird sich

hierbei im Rahmen von SaaS oftmals durch eine organisatorische und

wirtschaftliche Verbindung ergeben. Denn die einzelnen

Softwarefunktionen gewinnen in ihrer Zusammengehörigkeit einen neuen,

meist viel höheren Wert und es erfolgt eine einheitliche Preisbildung (Bsp.

CRM System, welches aus verschiedenen Subroutinen besteht, die von

dritten Anbietern im Rahmen des einheitlichen Angebots zur Verfügung

gestellt werden). 222 Des Weiteren ergibt sich die Zusammengehörigkeit

meist aufgrund einer organisatorischen Verbindung, da die einzelnen

221

hierzu: Heussen, B., NJW 1988, 2441; Intveen, M. / Lohmann, L., ITRB 2002, 210, 212

222

Heussen, B., NJW 1988, 2441, 2444

- 68 -


Softwarefunktionen so eng miteinander verzahnt sind, dass sie für den

Anwender als Einheit aufgefasst werden (siehe hierzu eben genanntes

Beispiel einer SaaS Office Anwendung, die zwar aus Einzelteilen

zusammengesetzt sein kann, aber von dem Nutzer regelmäßig nur als eine

Einheit (Software) erkannt wird). Zudem wird der SaaS Nutzer regelmäßig

kein Interesse daran haben, neben dem SaaS Anbieter mit weiteren

Subunternehmern in Kontakt treten zu müssen. Es sprechen somit schon

neben den oben genannten objektiven Kriterien 223 auch subjektive

Kriterien 224 für eine einheitliche Leistung, die allein durch den SaaS

Anbieter erbracht wird. Somit trifft allein den SaaS Anbieter bei

Leistungsstörungen die Systemverantwortlichkeit gegenüber seinem

Kunden. Er muss folglich durch vertragliche Regelungen dafür Sorge tragen,

dass die von ihm eingeschalteten Subunternehmer ihre Leistungspflicht

ständig und zuverlässig erbringen, bzw. im Falle der Schlechtleistung für

die entstandenen Schäden aufkommen.

Zwar besteht die Möglichkeit durch sog. Trennungsklauseln die

Systemverantwortlichkeit wieder einzuschränken, indem ausdrücklich keine

Haftung des Anbieters für solche Teile des Systems übernommen wird, die

durch andere Anbieter bezogen werden. 225 Rechtliche Probleme werden

wohl aber dann auftreten, wenn Allgemeine Geschäftsbedingungen

vorliegen. Dann werden die Trennungsklauseln möglicherweise

überraschend sein (§ 305c BGB) oder eine unangemessene Benachteiligung

darstellen (§ 307 Abs. 2 BGB), da sie wesentliche Rechte und Pflichten des

Nutzer gefährden, indem sie die Hauptleistung unzulässig aushöhlen. 226

(2) Gestaltungsanforderungen der Weboberfläche

Wenn SaaS als eine Komplettlösung (sog. Business Process Outsourcing)

angeboten wird und der Zugriff auf die Funktionen der Software durch eine

Weboberfläche erfolgt, stellt sich die Frage nach der Gestaltung und

Konsistenz dieser Schnittstelle. Da dem Nutzer lediglich die Funktion der

223 Heussen, B., NJW 1988, 2441, 2443 (Abschn. V Nr. 3)

224 hierzu: Heussen, B., NJW 1988, 2441, 2445 (Absch. V Nr. 4)

225 Heussen, B., NJW 1988, 2441

226 vgl. Heussen, B., NJW 1988, 2441, 2444 (Abschn. V Nr. 3 e)

- 69 -


Software angeboten wird, behält der SaaS Anbieter grundsätzlich den vollen

Gestaltungsspielraum bei dem Softwareunterbau. Der SaaS Nutzer wird

Änderungen kaum verhindern können, solange die vereinbarte Funktions-

erfüllung sichergestellt bleibt. Es ist diese Besonderheit von SaaS, die es

grundsätzlich auch zulässt, dass die Weboberfläche durch den Anbieter an

den Stand der Technik angepasst wird und damit einer ständigen Änderung

unterliegt. Hierüber sollten vertragliche Rahmenbedingungen getroffen

werden, da künftige Änderungen dieser Art häufig Schwierigkeiten

bereiten. 227

Bei SaaS ist anzunehmen, dass zukünftige Änderungen eine (kostenlose)

Anpassung im Rahmen des abgegebenen Leistungsversprechens bedeuten

und keine vergütungspflichtige Erbringung einer zusätzlichen Leistung. 228

Denn zum einen erwartet der SaaS Kunde, dass er mit der Nutzung der

Software eine bestimmte Funktion / Aufgabe erfüllen kann. Zum anderen

wird der Kunde, der sich für diese Art der Softwarenutzung entschieden hat,

erwarten, dass er jederzeit eine möglichst optimale und aktuelle

Leistungserfüllung erhält, dadurch aber Anpassungen an der

Benutzerschnittstelle seitens des Anbieters voraussetzt.

Werden Emailsysteme als SaaS genutzt, wie die bekannten kostenlosen Webmaildienste,

geht der Nutzer regelmäßig nicht davon aus, dass sich das System oder die

Zugriffsschnittstelle im Laufe der Nutzungszeit nicht mehr ändern. Vielmehr werden

Anpassungen an aktuelle Entwicklungen und Bedürfnisse erwartet.

Für den SaaS Nutzer kann dies aber auch zu einem Ärgernis werden, muss

er sich möglicherweise zu oft an die geänderte Gestaltungen gewöhnen. 229

Werden hierbei auch noch wesentliche Funktionen an andere Orte auf dem

Bildschirm oder in Untermenus verlagert, beginnt die große Suche. 230 Zwar

ist der SaaS Anbieter gut beraten nicht zu häufig Änderungen in solchem

227

vgl. Heymann, T., CR 2005, 706, 707

228

vlg. Heymann, T., CR 2005, 706, 709

229

http://www.nzz.ch/blogs/nzz_blogs/betablog/ist_facebook_ein_pferd_oder_ein_kamel_

1.2276636.html (Stand: 04.07.2010)

230

so geschehen bei der Designänderung von Facebook:

http://www.zeitjung.de/KULTUR/artikel_detail,5237,Das-neue-Facebook:-Was--sich-

%C3%A4ndert.html

- 70 -


Ausmaß an seinem Design vorzunehmen, um nicht seine Kunden zu

verlieren, von Zeit zu Zeit werden Änderungen aber nicht zu vermeiden sein.

Aus diesem Grund sollte diese Problematik zuvor vertraglich geregelt

werden.

Im Bereich des üblichen Softwarekaufs spielen diese Besonderheiten kaum eine Rolle.

Zwar gibt es dort regelmäßig erhebliche Änderungen bei Versionssprüngen (z. B. zwischen

den verschiedenen Versionen der Betriebssystems Microsoft Windows). Da hier aber meist

ein völlig neues Produkt verkauft wird, besteht auch kein Anspruch auf Kontinuität

zwischen den Softwareversionen.

(3) Ressourcenanpassung

Obwohl für SaaS als eines der grundlegenden Prinzipien die Flexibilität

beim Ressourcenbedarf genannt wird, sollte dies auch vertraglich Eingang

finden.

Wer seine Software auslagert verliert auch die Möglichkeit, diese seinem

Nutzerbedarf selbständig entsprechend anzupassen. Es ist dadurch nicht

mehr möglich, durch den Zukauf eines neuen Arbeitspatzrechners die

Ressourcen auszubauen. Deshalb wäre es sehr nachteilig, wenn eine solche

Anpassung nicht möglich wäre oder der SaaS Anbieter diese im

Bewusstsein der Abhängigkeit nur verteuert anbieten würde. Deswegen

sollten solche Entwicklungen schon bei Vertragsbeginn beachtet und gleich

zu Beginn geregelt werden, um nicht später eine nachteilige Abänderung

im Rahmen einer Vertragsanpassung (Change-Requests) vornehmen zu

müssen. 231 Bestenfalls sollte geregelt sein, dass eine unbestimmte Anzahl

von neuen Nutzern an das System angeschlossen werden kann, wie viel Zeit

die Nutzereinrichtung in Anspruch nimmt und zu welchen Preisen dies

erfolgen wird. In diesem Zusammenhang kommen auch nebenvertragliche

Abreden in Betracht, wie z.B. die Softwareeinweisung von neuen Nutzern.

In gleichem Maße sind Regeln über Löschungsmodalität von Nutzerkonten

erforderlich. Dies betrifft vor allem den Umgang mit den noch vorhandenen

Daten des Nutzer (z.B. Emails). Auch hier macht ein zeitlicher Aspekt Sinn,

231 Heymann, T., CR 2005, 706, 710

- 71 -


da es Situationen geben kann in denen einen Nutzer unverzüglich vom

System auszuschließen ist, vor allem wenn ein Zugriff auch von außerhalb

des Unternehmens möglich ist und dadurch das System leicht dem

Missbrauch ausgesetzt ist.

(4) Force Majeure Klauseln

Force Majeure Klauseln regeln Haftungsfragen, die sich bei dem Eintreffen

von Umständen der höheren Gewalt ergeben. Sie begrenzen oder schließen

die Haftung der Vertragsparteien aus, wenn die Vertragsverletzung auf

Ursachen beruht, die außerhalb des Einflussbereiches der Parteien liegt und

somit auch außerhalb des Verantwortungsbereichs. 232 In IT-Verträgen

finden sich solche Klauseln immer häufiger.

- 72 -

233

Neben den

Haftungsausschlüssen enthalten viele Force Majeur Klauseln auch

Kündigungsregeln oder die Pflicht zur Schadensminderungen. 234 Ob hierfür

nach der Schuldrechtsreform noch ein Bedürfnis besteht ist fraglich. Denn

in § 313 BGB existiert eine gesetzliche Regeln, die eine Kündigung für den

Fall erlaubt, dass sich Umstände unvorhersehbar schwerwiegend geändert

haben, also wenn ein Fall einer Force Majeur Situation vorliegt. Ebenso

kennt das deutsche Recht eine Schadensminderungespflicht, so dass einer

zusätzlichen Regelung nur eine konkretisierende Wirkung zukommen kann.

Im Rahmen von SaaS Verträgen dürfte eine Reglung über die

Verantwortlichkeit für Unterauftragsnehmer Sinn machen, wenn einzelne

Softwarefunktionen nicht direkt vom SaaS Anbieter erbracht werden,

sondern durch Dritte. Hierbei kann es zu Verzögerungen der Hauptleistung

kommen, wenn Subunternehmer ihrerseits die Leistung verzögern oder nicht

erbringen. Dann stellt sich die Frage nach der Haftung für den SaaS

Anbieter. Sinnvoll erscheint eine Klarstellung, dass die Umstände von dem

SaaS Anbieter selbst nicht zu beeinflussen waren, dass aber auch der

eingeschaltete Subunternehmer keinen Einfluss auf diese Umstände nehmen

konnte. 235

232 vgl. Lejeune, M., ITRB 2009, 189

233 Lejeune, M., ITRB 2009, 189

234 Lejeune, M., ITRB 2009, 189, 190

235 vgl. Lejeune, M., ITRB 2009, 189, 190


IV. Datenschutzrecht

Da bei der Ausgestaltung von Service Level Agreements dem

Datenschutzrecht eine besondere und häufig diskutierte Stellung zukommt,

soll dieses Thema im folgenden Abschnitte gesondert untersucht werden. 236

Die hier aufkommenden Aspekte sind bei der Gestaltung der SLA zu

berücksichtigen.

1. Einführung

Der Trend zur Auslagerung von Office Lösungen, E-Mail, ERP 237 , CRM 238 ,

Supply Chain Management, Informations- und Ressourcenmanagement

sowie Business Intelligence im unternehmerischen Bereich verschärft die

datenschutzrechtliche Problematik. 239 Denn im Zuge dieser Entwicklung

geht es nicht mehr nur um Daten der privaten Kommunikation, sondern um

sensible personenbezogene Daten, die in unternehmerischen

Geschäftsprozessen anfallen können. Durch das Outsourcing auf SaaS

verliert das Unternehmen die klassischen Kontrollmechanismen eines

Administrators.

2. Unterschied Auftragsdatenverarbeitung vs.

Funktionsübertragung

Eine datenschutzrechtliche Berücksichtigung nach dem BDSG kommt nur

in Betracht, wenn personenbezogene Daten erhoben, verarbeitet oder

genutzt werden (§ 2 Abs. 1 i. V. m. § 3 Abs. 1 BDSG). Werden die Daten

anonymisiert (§ 3 Abs. 6 BDSG), spielen datenschutzrechtliche

Erwägungen keine weitere Rolle. Alternativ besteht auch die Möglichkeit,

die Daten zu pseudonymisieren (§ 3 Abs. 6a BDSG). Dadurch wird der

Bezug der Daten zu einer Person nicht vollständig aufgehoben, sondern er

236

u.a. Roth, B., ITRB 2010, 60; Weßelmann, B., iX extra 3/2010 IV; Helbing, T.,

“Datenschutz bei Software as a Service (SaaS)”; Spies, A., MMR 2009, XI

237

Enterprise Resource Planning

238

Customer Relationship Management

239

vgl. Weßelmann, B., iX extra 3/2010 IV; zum besonderen Fall des Datenschutz beim

Anwaltsgeheimnis siehe: Härting, N., ITRB 2009, 138 ff.

- 73 -


leibt für denjenigen rekonstruierbar, der über den Zuordnungsschlüssel

verfügt. Für die empfangende Stelle können hierdurch aber anonymisierte

Daten entstehen, so dass für die Übertragung der Daten an den SaaS

Anbieter das BDSG keine Rolle spielt. Hierbei muss aber sichergestellt

werden, dass der SaaS Anbieter auch nicht über Umwegen die Möglichkeit

erhält, die Daten wieder einer Person zuordnen zu können.

Liegen personenbezogene Daten beim Nutzer vor, liegt die erste

datenschutzrechtlich relevante Handlung in der Übermittlung dieser Daten

an den SaaS Anbieter. Übermitteln ist das Bekanntgeben gespeicherter oder

durch Datenverarbeitung gewonnener personenbezogener Daten an einen

Dritten durch Weitergabe, Einsicht oder Ermöglichung der Abrufbarkeit

(§ 3 Abs. 4 Nr. 3 BDSG). Wenn die Daten folglich an den SaaS Anbieter

übermittel werden stellt sie dich Frage, ob der SaaS Anbieter „Dritter“ im

Sinne des Gesetzes ist. Denn davon hängt es ab, welche rechtlichen

Anforderungen zu erfüllen sind. Das Gesetz selbst unterscheidet hierbei

zwischen der Funktionsübertragung auf Dritte und der Auftragsdaten-

verarbeitung durch Personen und Stellen, die nicht Dritte sind. 240

Eine „Funktionsübertragung“ kann vorliegen, wenn nicht nur die

Verarbeitung von Daten sondern auch die Aufgabe, zu deren Erfüllung die

Verarbeitung der Daten notwendig ist, übertragen wird. 241 Das heißt, dass

der Dritte bei der Datenverarbeitung weitgehend selbständig ist und bei der

Erledigung der ihm übertragenen Aufgaben keiner vertraglichen

Weisungsgebundenheit oder Abhängigkeit dem Auftraggeber gegenüber

untersteht. Liegt ein solcher Fall vor, kommt es zur Anwendung von § 4

Abs. 1 BDSG, der die Datenübermittlung nur zulässt, wenn eine Vorschrift

des BDSG oder eine andere Rechtsvorschrift dies erlaubt oder anordnet oder

der Betroffene eingewilligt hat. Hierbei dürfte es regelmäßig zur

Anwendung der Vorschriften des § 28 BDSG oder § 29 BDSG kommen, die

durch ähnlichen Wortlaut aber unterschiedlichem Zweck die Übermittlung

der Daten an den Dritten regeln.

240 Gola, P. / Schomerus, R., „BDSG“, § 11, Rdnr. 3

241 Gola, P. / Schomerus, R., „BDSG“, § 11, Rdnr. 9

- 74 -


Personen und Stellen, die personenbezogene Daten im Auftrag erheben,

verarbeiten oder nutzen (sog. Auftragsdatenverarbeitung), sind dagegen

nicht Dritte i. S. d. gesetzlichen Vorschrift (§ 3 Abs. 8 S. 3 BDSG). Dass

man hierbei im gängigen Sprachgebrauch den Auftragsnehmer gewöhnlich

als Dritten bezeichnet, darf dabei nicht weiter verwirren. Der beauftragte

Datenverarbeiter, hier also der SaaS Anbieter, bleibt nach dem Verständnis

des Gesetzes im Umgang mit den Daten weisungsgebunden und somit

abhängig von der verantwortlichen Stelle, also dem SaaS Nutzer. 242 Im

Rahmen der Auftragserteilung fungiert der Auftragnehmer als „verlängerter

Arm“ oder als ausgelagerte Abteilung des Auftraggebers. Er, der

Auftraggeber, bleibt also „Herr der Daten“ und behält somit die volle

Verfügungsgewalt. 243 Diese Konstruktion hat rechtlich zur Folge, dass eine

Datenübertragung zwischen SaaS Nutzer und SaaS Anbieter keine

Datenübermittlung im rechtlichen Sinne des BDSG ist (§ 3 Abs. 4 Nr. 3

BDSG). 244 Folglich kommt es nicht mehr darauf an, dass die Daten-

übertragung auf den SaaS Anbieter durch eine Vorschrift oder durch die

Einwilligung des Betroffenen gestattet ist (§ 4 Abs. 1 BDSG).

Das BDSG geht also grundsätzlich von zwei verschiedenen Situationen aus, wenn es zu

einer Übertragung der Daten kommt. In der einen Situation werden die Daten an einen

selbständigen Außenstehenden weitergeben und mit dieser Weitergabe wird auch die

Verantwortung bezüglich des Datenschutzes übertragen. Die herausgebende Stelle hat

hierbei keine Weisungsbefugnisse mehr. In der zweiten Situation behält die herausgebende

Stelle die volle Verantwortung, was sich dadurch rechtfertigt, dass sie weisungsbefugt

gegenüber dem Empfänger ist. Diese Situation ist vergleichbar mit dem Datenaustausch

zwischen den einzelnen Abteilungen in einem Unternehmen.

Die Abgrenzung zwischen beiden Varianten ist fließend. 245 In gewissem

Umfang können die Parteien durch die Ausgestaltung der Verträge selbst

bestimmen, ob eine Auftragsdatenverarbeitung oder eine Funktionsüber-

tragung vorliegen soll. 246 Die meisten cloud-basierten Services werden wohl

242 Gola, P. / Schomerus, R., „BDSG“, § 11, Rdnr. 3

243 vgl. Gola, P. / Schomerus, R., „BDSG“, § 11, Rdnr. 3

244 Gola, P. / Schomerus, R., „BDSG“, § 11, Rdnr. 4

245 Grützemacher, M., ITRB 2007, 183, 185

246 Grützemacher, M., ITRB 2007, 183, 185

- 75 -


aber als Auftragsdatenverarbeitung ausgestaltet sein. 247 Dies müsste auch im

Rahmen von SaaS Verträgen anzunehmen sein. Denn der SaaS Anbieter

übernimmt gerade nicht die Aufgabenerfüllung des Nutzers, sondern nur die

Softwarefunktionen, welche die beim Nutzer verbleibende

Aufgabenerfüllung gewährleisten können. Da der SaaS Anbieter nur

Werkzeuge zur Verfügung stellt, hat er nicht die Erlaubnis die ihm

übersandten Daten in einer anderen Weise zu nutzen, als die, die für die

Aufgabenerfüllung vereinbart wurde. Viel mehr ist sein Kontakt mit den

Daten nur darauf beschränkt, eine bestimmte Rechenoperation auszuüben

und das Ergebnis zurückzugeben. Eine darüber hinausgehende

Nutzungserlaubnis ist dem SaaS Anbieter gerade nicht gegeben und auch

nicht gewollt. Nimmt man die bekannten Webmail Dienste als Beispiel,

wird dies besonders deutlich. Denn jede Reaktion, welche durch den

Anbieter vorgenommen wird erfordert eine explizite Aktion des Nutzers.

Sei es z. B. durch die Aktivierung einer Schaltfläche oder die Festlegung

bestimmter Sortier- und Löschregeln. Ohne vorherige Aufforderung wird

der Webmailanbieter keine Aktionen weisungsfrei durchführen dürfen.

Somit dienen die Webmaildienste dem Nutzer lediglich als Werkzeuge, um

die eigene Emailkorrespondenz online im Internet verwalten zu können.

Ermessenspielräume verbleiben somit keine. 248 Zu erwähnen ist in diesem

Zusammenhang auch, dass durch die Auslagerung von Softwarefunktionen

gerade keine Änderungen im Betriebsablauf erfolgen sollen. Dort, wo zuvor

die auf eigenen Servern installierte Software durch die Mitarbeiter benutzt

werden sollte, sollen die gleichen Aufgaben durch die Mitarbeiter nun

lediglich im Rahmen von SaaS gelöst werden. Somit ist die

datenschutzrechtliche Situation vergleichbar mit dem Outsourcing im

Rahmen von ASP.

3. Compliance Anforderungen § 11 BDSG

Da es sich, wie soeben festgestellt, bei SaaS Verträgen überwiegend um

eine Auftragsdatenverarbeitung handelt, ist § 11 BDSG einschlägig für den

247

vgl. Schulz, C. / Rosenkranz, T., ITRB 2009, 232, 235; Pohle, J. / Amman, T., CR 2009,

273, 275

248

vgl. Grützemacher, M., ITRB 2007, 183, 185

- 76 -


Umgang mit den personenbezogenen Daten. Die Vorschrift hält eine Liste

mit Compliance Anforderungen bereit, die bei der Auftragsvergabe in den

Verträgen zu berücksichtigen sind. Teilweise haben diese Anforderungen

jedoch schon zuvor im Rahmen der allgemeinen Gestaltung der SLA

Berücksichtigung gefunden. Das BDSG dient somit nochmals als Kontrolle;

fehlende Regelungen sind notwendigerweise zu ergänzen.

a) 10-Punkte Katalog

Seit dem 01.09.2009 wurden neue Anforderungen im Rahmen der

Auftragsdatenverarbeitung in das BDSG aufgenommen. 249 Hierzu zählt

auch die Änderung von § 11 BDSG, der nunmehr in Absatz 2 einen nicht

abschließenden 10-Punkte Katalog mit Regelungsgegenständen enthält, die

in einem schriftlichen Vertrag zur Auftragsdatenverarbeitung zwingend

umzusetzen sind. 250 Dies kann auch im Rahmen der Vereinbarung über die

SLA erfolgen. Jedenfalls sind sowohl der SaaS Anbieter, wie auch der

Nutzer gehalten, diese Vorschrift umzusetzen und entsprechende Regeln in

ihre Verträge aufzunehmen. Denn nach § 43 Abs. 1 Nr. 2b BDSG kann die

fehlerhafte oder unvollständige Auftragsdatenverarbeitung eine

Ordnungswidrigkeit darstellen, die mit einer Geldbuße bis zu fünfzigtausend

Euro geahndet werden kann (§ 43 Abs. 2 BDSG).

b) Sorgfalts-, Auswahl- und Überwachungspflichten

Eine weitere Anforderung aus § 11 BDSG, die aber schon vor der BDSG

Novelle bestand, sind Sorgfalts-, Auswahl- und Überwachungspflichten des

Auftraggebers, also des SaaS Nutzers (§ 11 Abs. 2 S. 1 und 4 BDSG). 251

Dies bedeutet unter anderem dafür Sorge zu tragen, dass der Auftragnehmer

in der Lage und willens ist, die erforderlichen Sicherungsmaßnahmen

auszuführen (§ 9 BDSG). 252 Schwierigkeiten, wie sie Grützemacher

249 hierzu: Söbbing, T., ITRB 2010, 36

250 Söbbing, T., ITRB 2010, 36, 37

251 Gola, P. / Schomerus, R., „BDSG“, § 11, Rdnr. 21 ff.

252 vgl. Gola, P. / Schomerus, R., „BDSG“, § 11, Rdnr. 21

- 77 -


eispielsweise bei der Erstellung von Berechtigungskonzepten sieht, 253

dürften allerdings im Rahmen des SaaS Konzepts weniger problematisch

sein. Da zumeist schon fertige, standardisierte Software angeboten wird, die

technische Umsetzung also schon abgeschlossen ist, dürfte der SaaS

Anbieter schon von Beginn an ein mit dem BDSG verträgliches stimmiges

Berechtigungskonzept fertig gestellt haben, in welches der Nutzer nur noch

einsteigen muss. Dem Nutzer bleibt vor dem Einstieg in die vertragliche

Bindung nur die Überprüfung, ob das Angebot den Anforderungen an das

BDSG gerecht wird. Wenn dies nicht der Fall ist, wäre er schon selbst

aufgrund seiner Sorgfalts- und Auswahlpflicht daran gehindert, das SaaS

Angebot anzunehmen. Als Faustformel kann jedenfalls gelten, dass der

SaaS Anbieter die gleichen Datenschutzvorkehrungen zu treffen hat, die

auch der SaaS Nutzer erfüllen müsste, wenn er die Daten nach

herkömmlichem Prinzip in eigener Verantwortung verarbeiten würde. 254 Die

Vorschrift selbst verlangt aber nur, dass der SaaS Nutzer sich von der

Erfüllung dieser Voraussetzungen überzeugt. Er muss also keine Vor-Ort

Begutachtung durchführen. Somit entsteht für den Nutzer zwar eine

Prüfungspflicht, eine Duldungspflicht seitens des Anbieters hinsichtlich

einer örtlichen Begehung gibt es aber nicht. 255 Dies muss folglich

vertraglich gesondert vereinbart werden und kann z.B. durch die Duldung

von Stichproben erfolgen. Ebenfalls kann eine Regelung getroffen werden,

dass die Kontrollen von Dritten durchgeführt werden können. 256 Zu den

Problematiken einer Besichtigung der Serverräume wurde allerdings oben

schon Stellung genommen. Bei den Überwachungspflichten darf auch nicht

die Dokumentationspflicht übersehen werden (§ 11 Abs. 2 S. 5 BDSG).

Eine Regelung in den SLA, die diese Pflicht nochmals kurz festlegt,

erscheint angemessen. Sinnvoll erscheint auch eine Regelung, wonach die

Dokumentation und die Ergebnisse dem SaaS Anbieter zur Kenntnisnahme

überlassen werden müssen, da dies der Verbesserung der Leistungsqualität

253 Grützemacher, M., ITRB 2007, 183, 185 f. - Berechtigungskonzepte könnten aus

praktischen Erwägungsgründen erst dann ausgearbeitet werden, wenn der Vertrag schon

geschlossen ist. Das Gesetz verlangt diese aber schon zum Zeitpunkt des Vertragsschlusses.

254 vgl. Gola, P. / Schomerus, R., „BDSG“, § 11, Rdnr. 21

255 Gola, P. / Schomerus, R., „BDSG“, § 11, Rdnr. 22

256 Grützemacher, M., ITRB 2007, 183, 186

- 78 -


dienen kann und Probleme mit dem Datenschutz im Vorfeld gelöst werden

können.

c) Besondere Pflichten des SaaS Anbieters

Durch § 11 Abs. 2 BDSG werden auch dem Auftragnehmer besondere

Pflichten auferlegt. Danach darf er die Daten nur im Rahmen der

Weisungen des Auftraggebers erheben, verarbeiten oder nutzen. Eine

besondere Pflicht ist die unverzüglich Mitteilung an den Auftraggeber,

wenn er der Ansicht ist, das Weisungen gegen datenschutzrechtliche

Regelungen verstoßen (§ 11 Abs. 2 S. 2 BDSG). Eine Konkretisierung der

Mitteilungspflicht sollte in den SLA vereinbart werden. Eine Vereinbarung,

dass den Weisungen immer Folge zu leisten ist, auch wenn sie gegen

datenschutzrechtliche Regelungen verstoßen, ist aber nicht möglich ist. 257

d) Subunternehmer

Sehr wichtig ist die Regelung über die Möglichkeit zur Beauftragung von

Subunternehmern. Nach der BDSG Novelle muss hierüber eine Regelung

getroffen werden (§ 11 Abs. 2 S. 2 Nr. 6 BDSG). Wie schon dargestellt

bietet sich das SaaS Model geradezu an, das Softwareprodukt durch

Modularisierung auf verschiedene Anbieter aufzuspalten. Zwar werden

soweit ersichtlich zurzeit SaaS Lösungen hauptsächlich aus einer Hand

angeboten. Es spricht aber nichts dagegen, dass bestimmte Funktionen

zukünftig auf weitere Anbieter mit freien Ressourcen übertragen werden

(z.B. die Umwandlung bestimmter Dateiformate in das .pdf-Format). Sobald

sich der entsprechende Markt hierfür entwickelt hat, werden verschiedene

Dienstleister die gleichen Softwarefunktionen anbieten können.

4. Internationale Aspekte

SaaS ist Cloud Computing und Cloud Computing basiert auf der

Internettechnologie. Es liegt also sehr nahe, dass die genutzten

257 Gola, P. / Schomerus, R., „BDSG“, § 11, Rdnr. 25

- 79 -


Softwarefunktionen von jedem Punkt auf der Welt angeboten werden

können. Vor allem bei Standorten mit sehr niedrigen Lohn- und

Betriebskosten können dadurch erhebliche Kostenvorteile erzielt werden, da

dies auch die Kosten der zur Verfügung stehenden Ressourcen senkt. 258 Das

es aber nicht sehr vertrauensbildend ist, wenn z.B. der Geschäftsbrief

zwecks Rechtschreibprüfung in ein unbekanntes Drittland übermittelt wird,

liegt neben den weiteren datenschutzrechtlichen Problemen auf der Hand.

Aus diesen Gründen ist eine Regelung über die Standorte der Software

zwingend notwendig.

Das BDSG nimmt bezüglich der Auslandsproblematik schon eine Regelung

auf der ersten Stufe vor, nämlich dort, wo im Rahmen der

Auftragsdatenverarbeitung die Fiktion des § 3 Abs. 8 S. 3 BDSG getroffen

wird, also schon der Tatbestand der Übermittlung entfällt. 259 Hintergrund

der gesetzlichen Konstruktion ist, dass nach dem Gesetz eine Übermittlung

nur an einen außenstehenden Dritten erfolgen kann. Werden Daten nur an

einen „internen Dritten“ weitergeleitet, liegt nach dem Gesetz keine

Übermittlungshandlung vor. Dritter ist nach dem BDSG jede Person oder

Stelle außerhalb der verantwortlichen Stelle (§ 3 Abs. 8 S. 2 BDSG). Der

Sinn der Vorschrift ist, dass z.B. innerhalb eines Unternehmens die Daten

zwischen den Abteilungen frei ausgetauscht werden können, ohne den

Restriktionen des BDSG unterworfen zu sein. Dadurch, dass das BDSG

bestimmt wer Dritter ist und wer nicht, kann es für ganz bestimmte Fälle die

datenschutzrechtlichen Restriktionen aufheben. Nicht-Dritte sind nach der

gesetzlichen Vorschrift nur Personen und Stellen, die im Inland, in einem

anderen Mitgliedstaat der Europäischen Union oder in einem anderen

Vertragsstaat des Abkommens über den Europäischen Wirtschaftsraum

personenbezogene Daten im Auftrag erheben, verarbeiten oder nutzen.

Daraus folgt, dass bei einer Verlagerung der Services in einen anderen als

die genannten Staaten grundsätzlich eine „Übermittlung“ im Sinne von

§ 3 Abs. 4 S. 2 Nr. 3 BDSG darstellt, unabhängig davon, ob die

Datenverarbeitung im Rahmen einer Auftragsdatenverarbeitung erfolgt. Es

findet also eine Bevorzugung der Auftragsdatenverarbeitung im Inland und

258 Grohamm, W., „Von der Software zum Service“, S. 59

259 siehe S. - 73 - Abschn. II

- 80 -


im Raum der EU und des EWR statt. Somit gelten auch im Falle einer

Auftragsdatenverarbeitung die §§ 4b und 4c des BDSG uneingeschränkt,

wenn Daten in andere Staaten als den genannten übertragen werden. 260 Dies

hat zur Folge, dass die Übermittlung im Grundsatz nur zulässig sein kann,

wenn ein angemessenes oder ggf. durch Vertrag zu schaffendes

ausreichendes Datenschutzniveau erreicht wird. 261 Vorraussetzung für die

Übermittlung ist also, dass ein Ausgleich der sich widerstreitenden

Interessen erreicht wird. Dies ist nicht der Fall, wenn bei den sich im

Ausland befindenden Stellen ein angemessenes Datenschutzniveau nicht

gewährleistet ist (§ 4b Abs. 2 S. 2 BDSG). Dieses Problem besteht zurzeit

grundsätzlich bei Übermittlungen von personenbezogenen Daten in die

USA.

262

Sind die Vorraussetzungen eines angemessenen

Datenschutzniveaus erfüllt, bedarf es bei einer Übermittlung im konkreten

Fall aber zusätzlich noch einer Rechtfertigung nach § 28 Abs. 1 BDSG. 263

Die Prüfung der Erlaubnistatbestände endet also noch nicht. Allerdings ist

anzunehmen, dass eine Übermittlung der Daten gerechtfertigt sein wird,

wenn die Interessen des Betroffenen gewahrt werden. Dies wird aller

Wahrscheinlichkeit dann der Fall sein, wenn die Verlagerung der Daten in

einen Drittstaat ähnlich ausgestaltet ist, wie die Auftragsdatenverarbeitung,

wenn also die gleichen vertraglichen Schutzmaßstäbe gelten. 264 Für diese

Annahme sprechen die von der EU erarbeiteten Musterklauseln für die

Übermittlung personenbezogener Daten an Auftragsdatenverarbeiter in

Drittländern. 265 Ein ausreichendes Datenschutzniveau (und in der Folge die

Erlaubnis zur Übertragung der Daten in ein Drittland) kann somit durch die

Vereinbarung von „Binding Corporates Rules“, „EU Model Clauses“ oder

mittels des „Safe Harbour“ Prinzips erreicht werden. 266 Letzteres ist aber

eine besondere Regelung, die nur den Datenaustausch in die USA betrifft.

260 nochmals zur Verdeutlichung: Liegt eine Auftragsdatenverarbeitung vor und gelangen

die Daten hierdurch an eine andere Stelle im Inland, der EU oder dem EWR, liegt per

Definition keine Übermittlung vor, so dass die Regeln der BDSG weitgehend nicht

anwendbar sind.

261 vgl. Grützemacher, M., ITRB 2007, 183, 186

262 Pohle, J. / Amman, T., CR 2009, 273, 277

263 vgl. Grützemacher, M., ITRB 2007, 183, 186

264 Grützemacher, M., ITRB 2007, 183, 186

265 vgl. m. w. N. Grützemacher, M., ITRB 2007, 183, 186 f.;

266 vgl Niemann, F. / Paul, J., KuR 2009, 444, 449; Grohamm, W., „Von der Software zum

Service“, S. 60 f.

- 81 -


Eine Alternative besteht darin, das SaaS Leistungen nur innerhalb einer

speziellen EU- (oder EWR) Cloud erbracht werden. Somit bleibt der SaaS

Anbieter zumindest innerhalb dieser Grenzen frei den Leistungsort nach

wirtschaftlichen Gesichtspunkten festzulegen, da er für die Datenüber-

mittlung an Dritte im Rahmen der Auftragsdatenverarbeitung keine

Erlaubnisnorm braucht. 267

Der Vollständigkeit halber sei auch der Fall erwähnt, wenn eine

Datenübermittlung in einen anderen Mitgliedstaat der Europäischen Union

oder in einen anderen Vertragsstaat des Abkommens über den Europäischen

Wirtschaftsraum erfolgt, ohne dass eine Auftragsdatenverarbeitung i. S. v. §

3 Abs. 8 S. 3 BDSG vorliegt. Da Art. 1 Abs. 2 der EU-DatSchRL den

Mitgliedstaaten eine Beschränkung des Verkehrs personenbezogener Daten

zwischen den Mitgliedstaaten aus Gründen des Datenschutzes verbietet, ist

die Zulässigkeit der Datenübermittlung allein an die das Verbotsprinzip

durchbrechenden Erlaubnistatbestände geknüpft, die auch für die

Übermittlung im Inland gelten. 268 Somit gelten foglich überwiegend die

Erlaubnistatbestände des § 28 BDSG bei der Übermittlung von Daten in

eines dieser Länder (§ 4b Abs. 1 BDSG).

5. Sensitive Daten

Ein weiteres spannungsreiches Feld ergibt sich, wenn sensitive Daten

anfallen. Sensitive Daten (ein in der Fachdiskussion verwendeter Begriff 269 )

sind besondere Arten personenbezogener Daten die Angaben über die

rassische und ethnische Herkunft, politische Meinungen, religiöse oder

philosophische Überzeugungen, Gewerkschaftszugehörigkeit, Gesundheit

oder Sexualleben beinhalten (§ 3 Abs. 9 BDSG). Für den Umgang mit

diesen Daten gelten besondere Voraussetzungen. Dies sind eine

ausdrückliche Einwilligung in die Datenverarbeitung oder ein besonderer

Zweck, der sich aus § 28 Abs. 6, 7, 8, 9 BDSG ergeben kann. Im Rahmen

267 vgl. Gola, P. / Schomerus, R., „BDSG“, § 4b, Rdnr. 5

268 Gola, P. / Schomerus, R., „BDSG“, § 4b, Rdnr. 2 f.

269 Gola, P. / Schomerus, R., „BDSG“, § 13, Rdnr. 13

- 82 -


einer Auftragsdatenverarbeitung können aber auch diese Daten ohne

Beschränkungen weitergegeben werden.

V. Urheberrechtliche Aspekte

Die vertragstypologische Einordnung von SaaS hat grundsätzlich keine

Auswirkung auf urheberrechtliche Belange. 270 Es wäre sogar möglich, dass

die Bedeutung des Urheberrechts durch SaaS im Softwaremarkt

zurückgedrängt wird. Denn die Software in Form des Programmcodes

gelangt durch SaaS schon nicht mehr nach Außen. Der SaaS Nutzer kann

zwar per Webinterface mit der Software arbeiten, er gelangt jedoch niemals

in ihren Besitz, noch erwirbt er besondere Rechte an der Software. Dies

folgt aus der Eigenart von SaaS, wonach eine bestimmte softwaremäßige

Funktionserfüllung geschuldet wird und nicht die Software selbst. Ich gehe

davon aus, dass aus diesen Gründen das Thema der „Raubkopien“ ebenfalls

an Bedeutung verliert. Denn wenn der Nutzer schon keinen Besitz am

Programmcode erlangen kann, besitzt er auch nichts, was er rechtswidrig

kopieren kann. Für den Softwaremarkt könnte hier ein Lösungsansatz der

bisherigen Probleme liegen und SaaS in Zukunft einen nicht unerheblichen

Entwicklungsschub geben. Da das SaaS Modell sich auch sehr für einen

Direktvertrieb über das Internet eignet, kann der Softwarehersteller seine

Software auch unmittelbar selbst anbieten. Entweder direkt an den

Endkunden oder als Subunternehmer an ein weiteres Softwarehaus. Folglich

wird sich durch SaaS der Umgang mit dem Urheberrecht ändern. Auf diese

Aspekte soll im folgenden Abschnitt eingegangen werden und auf mögliche

Auswirkungen im Rahmen der Gestaltung der Service Level Agreements.

1. Territorialprinzip

Das Urheberrecht unterliegt dem Territorialprinzip. Folglich verleiht jeder

Staat individuell die urheberrechtlichen Ausschließlichkeitsrechte innerhalb

seines Territoriums. Durch das Schutzlandprinzip folgt, dass das

270 Grützemacher, M., ITRB 2001, 59

- 83 -


Urheberrecht nur durch eine im Inland begangene Handlung verletzt werden

kann und auch nur dort verfolgt werden kann. 271 Da SaaS eine typische

Anwendung des Internets ist, sieht man sich der Problematik der weltweiten

Abrufmöglichkeit gegenüber. Es muss folglich für jede urheberrechtliche

Fragestellung eine staatsspezifische Betrachtung vorgenommen werden. Für

das deutsche Urheberrecht entstehen hierbei im Rahmen des SaaS Betriebs

ungewohnte Vorteile, wenn Software im Rahmen von SaaS angeboten wird

(hierzu sogleich im Anschluss).

2. Lizenzverhältnis zwischen SaaS-Anbieter und

Softwarehersteller

Sollte der Fall eintreten, dass der SaaS Anbieter nicht der Softwarehersteller

ist, muss er die urheberrechtlichen Befugnisse besitzen, um die Software im

Rahmen von SaaS anbieten zu dürfen. Dem Hersteller stehen dabei die in

§ 69c UrhG genannten ausschließlichen Rechte zu.

Installiert der SaaS Anbieter die Software auf seinen Computern, um sie

danach zur Verfügung zu stellen, ist dadurch immer das

Vervielfältigungsrecht des Herstellers betroffen, so das die Einräumung

einer entsprechenden Lizenz notwendig ist (§ 69c S. 1 Nr. 1 UrhG). 272

Anders ist der Fall aber dann zu bewerten, wenn der Softwarehersteller

selbst dem SaaS Anbieter den Zugriff nur im Rahmen des SaaS Modells

gewährt, der Anbieter also im Rahmen seines Programms die

Softwarefunktionen des Herstellers über eine Internet-API nutzt.

Bietet der SaaS Anbieter die Software seinen Kunden an, könnte darin eine

Verbreitung i. S. v. § 69c Nr. 3 UrhG liegen. Eine Verbreitung kann durch

Veräußerung, Verschenkung, Vermietung oder Verleihen erfolgen. 273 Da

das Programm jedoch nicht veräußert oder verschenkt wird, könnte es nur

vermietet oder verliehen werden. Aber auch eine Vermietung oder Leihe ist

nicht anzunehmen. Denn nach der hier vertretenen Auffassung liegt schon

271 vgl. Nägele, T. / Jacobs, S., ZUM 2010, 281, 284

272 Nägele, T. / Jacobs, S., ZUM 2010, 281, 286

273 Nägele, T. / Jacobs, S., ZUM 2010, 281, 286

- 84 -


eine Vermietung nach vertragstypologischer Einordnung nicht vor, da nicht

die Software an sich den Gegenstand der Leistung darstellt, sondern die aus

der Software erwachsende Funktion. 274 Zwar unterscheidet sich die

urheberrechtliche Einordnung der Miete von der vertragstypologischen, da

eine Miete im urheberrechtlichen Sinn eine körperliche Überlassung

voraussetzt und nicht, wie der BGH entschieden hat, die Gebrauchs-

überlassung mittels Fernzugriff ausreicht. 275 Da aber durch SaaS, wie auch

durch ASP, schon keine körperliche Überlassung der Software vorliegt, liegt

im urheberrechtlichen Sinne in keinem Fall eine Miete vor.

Fraglich ist weiter, ob das Recht der öffentlichen Wiedergabe (§ 69c Nr. 4)

tangiert wird. Denn der SaaS Anbieter überträgt keine Zeile des Programm-

codes, lediglich die Benutzeroberfläche wird per Webbrowser übertragen

und ermöglicht dadurch die Interaktion mit den Programmfunktionen.

Es besteht aber auch die Möglichkeit, dass nicht einmal eine Benutzeroberfläche übertragen

wird. Das ist der Fall, wenn das Programm ganz bestimmte Funktionen zu erfüllen hat, die

automatisch mit dem Aufruf oder der Übergabe der Daten an das Programm ausgeführt

werden. In diesem Fall stellt sich die Frage der öffentlichen Wiedergabe gar nicht.

Da nur die von der Software erzeugte Benutzeroberfläche übertragen wird

stellt sich die Frage, ob dies noch eine öffentliche Wiedergabe darstellt. Da

die Benutzeroberfläche ein urheberrechtlich geschützter Teil der Software

ist, soll nach einer Ansicht eine öffentliche Wiedergabe auch dann vorliegen,

wenn zwar kein Programmcode, aber die Benutzeroberfläche übertragen

wird. 276 Richtigerweise wird dagegen auch die Auffassung vertreten, dass

die Benutzeroberfläche als ein eigenständiges urheberrechtliches Werk zu

behandeln sei, soweit eine entsprechende Gestaltungshöhe vorliegt. 277

Hierfür sprechen auch die Erwägungsgründe der Richtlinie über den

Rechtsschutz von Computerprogrammen (91/250/EWG). Diese besagen,

dass „die Ideen und Grundsätze, die irgendeinem Element des Programms

einschließlich seiner Schnittstellen zugrunde liegen, im Rahmen dieser

274 siehe oben: S. - 21 -, Nr. 6

275 Nägele, T. / Jacobs, S., ZUM 2010, 281, 286

276 OLG Karlsruhe ZUM 1995, 143

277 m. w. N. Nägele, T. / Jacobs, S., ZUM 2010, 281, 287

- 85 -


Richtlinie nicht urheberrechtlich geschützt sind.“ Dabei heißt es zuvor:

„Teile des Programms, die eine solche Verbindung und Interaktion

zwischen den Elementen von Software und Hardware ermöglichen sollen,

sind allgemein als "Schnittstellen" bekannt.“ Da auch die

Benutzeroberfläche nur eine Schnittstelle (HMI) ist, über die der Benutzer

mit dem Programm in Verbindung treten oder operieren kann, ist sie

folglich durch die Richtlinie nicht urheberrechtlich geschützt. Hinzu kommt,

dass die Benutzeroberfläche lediglich ein Ergebnis von Berechnungen des

Programms ist und somit eine Ausgabe des Programms ist. Diese

Programmausgabe kann aber genauso wenig urheberrechtlichen Schutz

genießen, wie das Ergebnis einer Addition mehrerer Zahlen, die ebenfalls

von dem Programm berechnet und ausgegeben wurden. Somit liegt nach

hier vertretener Ansicht keine öffentliche Wiedergabe der Software im

Rahmen von SaaS vor. 278

3. Lizenzverhältnis zwischen SaaS-Anbieter und –Nutzer

In diesem Verhältnis finden grundsätzlich keine urheberrechtlich relevanten

Handlungen statt. Da der Nutzer schon nicht in den Kontakt mit dem

Programmcode kommt, es findet überhaupt keine Übertragung in Richtung

des Nutzer statt, kann der Nutzer auch keine zustimmungsbedürftige

Handlung (§ 69c UrhG) vornehmen. 279

4. SaaS als eigene Nutzungsart gem. §§ 31 ff. UrhG

Nach § 31 Abs. 4 UrhG a. F. war die Einräumung von Nutzungsrechten für

noch nicht bekannte Nutzungsarten sowie Verpflichtungen hierzu

unwirksam. Diese Vorschrift wurde nach Inkrafttreten der Neuregelung am

1. 1. 2008 (zweiter Korb) aufgehoben und in § 31a UrhG neu geregelt.

Danach ist es nunmehr möglich, einen Vertrag zu schließen, durch den der

Urheber Rechte für unbekannte Nutzungsarten einräumt oder sich zur

Rechteeinräumung verpflichtet. Allerdings legt das Gesetz hierfür

278 ebenso: Nägele, T. / Jacobs, S., ZUM 2010, 281, 287

279 im Ergebnis gleich: Nägele, T. / Jacobs, S., ZUM 2010, 281, 289

- 86 -


Formvorschriften fest und räumt Widerrufsrechte ein. Für Altverträger wird

auch für umfassende Rechteeinräumungen vor Inkrafttreten der

Neuregelung die Einräumung neuer Nutzungsrechte fingiert. 280

Allerdings spielt das Thema der neuen Nutzungsarten im SaaS Bereich

keine Rolle. Denn technisch ist es nicht denkbar oder nur schwer

realisierbar, dass eine nicht für den SaaS Betrieb geschriebene Software

ohne umfangreiche Änderungen im Programmablauf SaaS tauglich gemacht

werden kann. Zumeist wird die Software explizit für den Einsatz als SaaS-

Lösung entwickelt, also speziell für den Betrieb in Datennetzen ausgestattet,

weshalb sie von Natur aus internetfähig ist und Interaktionen mit dem

Benutzer und anderen Programmen über Datennetze zulässt. 281 Deswegen

muss schon beim Softwareentwurf die SaaS Nutzung bekannt gewesen sein,

so dass keine neue Nutzungsart vorliegt. Hierin liegt auch der Unterschied

zu ASP. Denn nach diesem Modell kann auch eine herkömmliche Software

für den ASP Betrieb eingesetzt werden, da lediglich die Bildschirmausgabe

der Software, vom Programmablauf unbemerkt, über ein Datennetz vom

Serverstandort zum Nutzer übertragen wird. Die Kommunikation über das

Netzwerk unternimmt dann nicht die Software, sondern eine spezielle

Programmumgebung. Eine Änderung im Programmcode ist nicht notwendig,

so dass die Software direkt in den ASP Betrieb überführt werden kann.

Diese Entwicklung konnte aber in früheren Lizenzverträgen nicht

vorausgesehen werden. Dadurch war diese Nutzungsart nicht vorhersehbar

und neu. 282

5. Ergebnis

Wie gesehen, ist nicht mit urheberrechtlichen Besonderheiten zu rechnen.

Im Verhältnis zwischen SaaS - Anbieter und - Nutzer ergeben sich nach der

hier vertretenen Auffassung sogar keine dem urheberrecht unterfallenden

Handlungen. 283 Zwischen Softwarehersteller und SaaS Anbieter sind die

280 Dreier, T. / Schulze, G., Urheberrechtsgesetz Kommentar, § 31a, Rdnr. 3

281 Thome, R., „SaaS - ASP - interessanter Hintergrund zu modernen ERP-Systemen“, S. 6

282 Bettinger, T. / Scheffelt, M., CR 2001, 729, 735

283 ebenso: Niemann, F. / Paul, J., KuR 2009, 444, 448

- 87 -


üblichen urheberrechtlichen Fragestellungen zu beantworten. Die

Einräumung des Rechts zur Nutzung im SaaS Betrieb ist eine denklogische

Voraussetzung, da die Software explizit nur für diese Verwendung

ausgelegt ist. Eine öffentliche Wiedergabe findet im Rahmen des SaaS

Betriebs nicht statt. Letztendlich gelangt der Softwarehersteller zudem in

die komfortable Situation, das Thema der rechtswidrigen Softwarekopien

(Raubkopien) endlich in den Griff zu bekommen.

C. Zusammenfassung der Ergebnisse

SaaS ist neu. SaaS ist CloudComputing. SaaS ist nicht ASP! Mit dieser

Arbeit sollte erreicht werden, etwas Licht in das neue Software-

Vertriebsmodell SaaS zu werfen. Aufgrund der Virtualisierungstechniken

bleibt SaaS revolutionär und wird die Softwarelandschaft auch weiterhin

nachhaltig verändern. Mit SaaS wird der Softwarevertrieb nicht mehr dem

Bild entsprechen, das wir bisher hatten. Wir erwerben nicht mehr die

bestimmte Software, die sich durch die Abfolge ihrer Befehle identifiziert,

sondern wir erwerben eine erfolgsbasierte Problemlösungsmöglichkeit, die

wir überwiegend über Webinterfaces bedienen können. Was seinen Anfang

bei webbasierten Emaillösungen nahm 284 , über webbasiertes Social

Networking 285 ging und nun webbasierte Videorecorder 286 betrifft, wird sich

immer schneller weiter entwickeln und immer mehr Bereiche assimilieren.

Vor allem wird sich diese Entwicklung zunehmend von der kostenlosen und

ungezwungen „Spaßebene“ entfernen und sich zur scharf kalkulierten und

kostenträchtigen Anwendungsebene entwickeln, die starke Abhängigkeiten

im B2B wie auch im B2C Bereich erzeugen wird. Schon heute erreicht die

webbasierte Emailkommunikation gegenüber der Nutzung von lokal

installierten Emailclients mehr als die Hälfte der Nutzer. 287 Man kann die

hierbei entstehende Abhängigkeit nur erahnen, wenn zukünftig die

Emailkommunikation den normalen Postversand vollständig ersetzt.

284 Bsp. GMX, WEB.DE, Google Mail

285 Bsp. Facebook, StudiVZ, WKW

286 shift.tv, safe.tv

287 http://fingerprintapp.com/email-client-stats (Stand: 12.07.2010) - lokale Clients in dieser

Liste sind: Outlook, Thunderbird und Lotus Notes

- 88 -


Bisherige Softwarelösungen kann man als Insellösungen verstehen, die sich

überwiegend durch eigene Datenformate isolieren. SaaS kann seine ganzen

Stärken nur dann ausspielen, wenn die hierbei anfallenden Daten auch

standardisiert werden, so dass sie leicht von anderen Anwendungen

mitbenutzt werden oder im Falle eines Anbieterwechsels zu anderen

Anbietern übertragen werden können. XML ist hierfür die richtige Richtung.

Ein weiteres Ergebnis dieser Arbeit sollte sein, dass SaaS

vertragstypologisch nicht als Mietvertrag eingeordnet werden kann. Denn

das Mietrecht kennt nur eindeutig bestimmte Mietgegenstände, auf die der

Mieter auf die eine oder andere Weise Einfluss zu vernehmen mag, vor

allem kann er willkürliche Änderungen an der Mietsache verhindern. Dies

war auch bei ASP der Fall. Bei SaaS hingegen ist dies nicht mehr möglich.

Die dem Angebot zugrunde liegende Software kann von dem Anbieter

willkürlich verändert, angepasst oder weiterentwickelt werden.

Schließlich sollte gezeigt werden, auf welche Punkte bei der Gestaltung der

SLA besonders Wert gelegt werden muss. Dabei sind vor allem die

datenschutzrechtlichen Punkte zu beachten, wie auch das sich aus der

Abhängigkeit zum SaaS Anbieter ergebende Konfliktpotential. Zwar ist es

nicht einfach, eine von der konkreten Fallgestaltung losgelöste Betrachtung

der Problempunkte vorzunehmen. Allerdings sollte eine Sensibilisierung auf

wichtige Rahmenbedingungen bei SaaS möglich gewesen sein, so dass der

Vertragsjurist im konkreten Fall von einer guten Poleposition aus starten

kann.

- 89 -

Ähnliche Magazine