Jusletter IT

Standardsoftware oder Individualsoftware – Kaufvertrag oder Werkvertrag – Eine Checkliste für Softwarehersteller

  • Author: Markus Knasmüller
  • Category: Articles
  • Region: Austria
  • Field of law: IP Law, IP-Law
  • Collection: Tagungsband IRIS 2014
  • Citation: Markus Knasmüller, Standardsoftware oder Individualsoftware – Kaufvertrag oder Werkvertrag – Eine Checkliste für Softwarehersteller, in: Jusletter IT 20 February 2014
Während Standardsoftware für viele Anwender zur gleichartigen Verwendung entwickelt wird, wird Individualsoftware entsprechend den individuellen Wünschen eines einzelnen Kunden implementiert. Diese Unterscheidung scheint prinzipiell relativ einfach, dennoch verschwimmt diese Grenze immer mehr. Standardsoftware wird häufig auch mit individuellen Anpassungen eingesetzt und somit stellt sich auch die Frage, ob es sich dann noch um eine Standardsoftware oder schon um eine Individualsoftware handelt. Die Frage ist weniger aus technischer Sicht relevant, sondern vielmehr aus rechtlicher Sicht. Nachdem auf diese Unterschiede eingegangen wird, wird in diesem Artikel anhand von Praxisbeispielen eine Checkliste, die dazu dienen soll, zu entscheiden, ob es sich um individuelle Adaptierungen einer Standardsoftware oder aber um eine Individualsoftware handelt, vorgestellt. Aspekte dabei sind u.a. das Ausmaß der Individualisierung, deren Art, aber auch deren Herauslösbarkeit.

Inhaltsverzeichnis

  • 1. Begriffsdefinitionen Standardsoftware oder Individualsoftware
  • 1.1. Standardsoftware
  • 1.2. Individualsoftware
  • 1.3. Überschneidungen
  • 2. Auswirkungen
  • 2.1. Kaufvertrag oder Werkvertrag
  • 2.2. Steuerliche Auswirkungen
  • 2.3. Verwertungsrechte
  • 3. OGH und EUGH-Rechtsprechung
  • 4. Fallbeispiele
  • 4.1. Customizing
  • 4.2. Individuelle Programmverbesserungen
  • 4.3. Individuelle «Add-ons»
  • 4.4. Individuelle Anpassungen
  • 5. Schlussfolgerungen

1.

Begriffsdefinitionen Standardsoftware oder Individualsoftware ^

[1]
Sowohl «Standardsoftware» als auch «Individualsoftware» sind gängige Begriffe, die in der Softwarebranche in vielen Angeboten und Aufträgen aufscheinen. So einfach die Begriffe erklärbar sind, so deutlich wird es doch, dass es Überschneidungen gibt.

1.1.

Standardsoftware ^

[2]
Standardsoftware ist eine fertig konzipierte Software, die von jedem beliebigen Käufer erworben und verwendet werden kann. Im Regelfall besichtigt der Käufer die Software, etwa bei einer Vorführung, und bestätigt mit der Bestellung die Kenntnis des Leistungsumfanges der bestellten Programme. Die Leistungsbeschreibung ist dabei alleine Aufgabe des Verkäufers, im Regelfall also des Herstellers der Standardsoftware. In einer Vielzahl von Fällen kommt es nicht einmal zu einer Besichtigung, weil die Software einfach als Paket im Handel oder aber als Download im Internet erworben wird. Eine Abnahme ist im Regelfall nicht vorgesehen. Beispiele dafür sind etwa Computerspiele, Textverarbeitungsprogramme aber auch etwa Buchhaltungsprogramme oder sogar einfache ERP-Systeme.

1.2.

Individualsoftware ^

[3]
Dagegen wird Individualsoftware immer für einen bestimmten Kunden und dessen Anwendungsfall entwickelt. Der Kunde selbst legt fest, welche Funktionen die Software aufweisen sollte und erstellt oft sogar selbst die Leistungsbeschreibung. Auch in dem Falle, in dem die Leistungsbeschreibung nicht von ihm selbst erstellt wird, wird sie auf jeden Fall aufbauend auf seine Informationen, Unterlagen und Hilfsmittel erstellt und muss von ihm bestätigt werden. Erst nach Vorlage dieser Leistungsbeschreibung kann die Entwicklung der Individualsoftware erfolgen. Wesentlich ist, dass individuell erstellte Software im Regelfall auch einer Abnahme bedarf. Beispiele für derartige Individualsoftware sind oft sehr spezielle Programme für Produktionsabläufe.

1.3.

Überschneidungen ^

[4]
Der wesentliche Unterschied, der sich aus den beiden vorangestellten Definitionen ableiten lässt, ist, dass in dem einen Fall die Leistungsbeschreibung vom Hersteller der Software kommt, im anderen vom Anwender. Diese theoretisch klare Trennung ist in der Praxis oft nicht so eindeutig. Gerade etwa im ERP-Bereich, also dort, wo eine komplexe Anwendungssoftware zur Unterstützung der Ressourcenplanung eines gesamten Unternehmens entwickelt wird, ist eine vollständige Individualsoftware aus Kostengründen kaum möglich. Andererseits sind doch viele Firmen zumindest zu einem gewissen Grade speziell, so dass auch eine Standardsoftware nicht zu 100% einsetzbar ist. Die Lösung ist häufig die Verwendung einer Standardsoftware, bei der aber individuelle Adaptierungen vorgenommen werden.

2.

Auswirkungen ^

[5]
Im Falle einer solchen Überschneidung ist es dann häufig nicht mehr eindeutig, ob es sich um eine Standard- oder eine Individualsoftware handelt. Dies ist aber nicht nur ein theoretisches Problem, sondern hat sehr praktische Auswirkungen, da im Falle der Standardsoftware ein Kaufvertrag vorliegt, im Falle der Individualsoftware aber ein Werkvertrag. Aber auch aus steuerlicher Sicht ist die Unterscheidung von Bedeutung. Im Extremfall kann es sogar Auswirkungen auf die Verwertungsrechte haben.

2.1.

Kaufvertrag oder Werkvertrag ^

[6]

Während bei einem Kaufvertrag eine Sache um eine bestimmte Summe Geldes einem Andern überlassen wird1, wird bei einem Werkvertrag die Herstellung eines Werkes gegen Entgelt übernommen2. Eine genaue Unterscheidung zwischen Kaufvertrag oder Werkvertrag würde an dieser Stelle zu weit führen. Eine wesentliche Auswirkung ist, dass für einen Werkvertrag die Sonderregeln über den Handelskauf und damit die Untersuchungs- und Rügepflicht des § 377 Abs. 1 UGB nicht zur Anwendung kommen.

[7]

Zwar sieht § 381 Abs. 2 UGB vor, dass diese Sonderregeln auch auf Werkverträge über die Herstellung körperlich beweglicher Sachen Anwendung finden, aber es ist strittig, ob es sich bei Software (insbesondere wenn sie nicht auf Datenträger geliefert wird) um eine körperlich bewegliche Sache handelt. So fehlt – zumindest nach Wissen des Autors – noch OGH-Sprechung, die in diesem Zusammenhang explizit auf das «körperlich» eingeht, auf jeden Fall würde aber der Rechtssatz RIS-Justiz RS01201203 eher dafür sprechen, dass diese Sonderregeln nicht gelten. Der deutsche BGH hat zwar im Zusammenhang mit einem ASP-Vertrag auch ein flüchtiges (stromabhängiges) Speichermedium als Datenträger angesehen4, zitiert dabei aber ausdrücklich Standardsoftware.

2.2.

Steuerliche Auswirkungen ^

[8]

Die Umsatzsteuerrichtlinie regelt, dass beim Verkauf von Standard-Software mittels körperlichen Datenträgern eine Lieferung vorliegt5. In diesem Zusammenhang wird auch eine Definition von Standard-Software geliefert:

[9]
Standard-Software sind serienmäßige hergestellte Gegenstände in Standardform, die von jedem beliebigen Käufer erworben und verwendet werden können. Hiezu gehören z.B. Software für Heimcomputer, Computerspiele und Standardpakete.
[10]

Bei Überlassung einer individuellen Software liegt hingegen eine sonstige Leistung vor. Diese Unterscheidung zwischen Lieferung und sonstiger Leistungen ist besonders relevant bei einer Lieferung an einen Unternehmer im Ausland. Denn in diesem Fall liegt eine in Österreich steuerbare Lieferung vor, welche unter den Voraussetzungen des § 7 UStG bzw. des Art. 7 BMR steuerfrei gestellt werden kann 6. Insbesondere ist daher für solche Lieferungen auch ein Ausfuhr- oder Beförderungsnachweis und Versendungs- sowie ein Buchnachweis entsprechend den gesetzlichen Bestimmungen zu erbringen.

[11]
Anzumerken ist dabei aber, dass die Umsatzsteuerrichtlinie auch dann, wenn eine vorhandene Software den Bedürfnissen des Anwenders individuell angepasst wird, von einer sonstigen Leistung ausgeht.
[12]

Sogar dann, wenn für die Software selbst und die Anpassung – wie normalerweise üblich – getrennte Preise ausgewiesen werden, ist die Unterscheidung nicht eindeutig, da der EuGH, in der Rs. «Levob»7 die Überlassung von (auf Datenträger gespeicherter) Standardsoftware und deren Anpassung, wobei darunter sogar die Installation verstanden wird, als einheitliche Leistung ansah. Dementsprechend ist also entscheidend, welcher Teil der Leistung überwiegt, um die steuerliche Beurteilung vornehmen zu können.

[13]
Der EuGH geht dabei von einer Dienstleistung aus, wenn die Anpassung aufgrund ihres Umfangs, ihrer Dauer und der Kosten einen entscheidenden Teil der Leistung ausmacht.

2.3.

Verwertungsrechte ^

[14]
Dieses Thema kann sehr weit gefächert sein und eine umfassende Abhandlung würde den Umfang dieses Artikels deutlich sprengen. Je nachdem wie detailliert im Falle einer Individualsoftware die Vorgaben des Kunden waren, könnte es sogar sein, dass die Urheberrechte (und ohne weitere Vereinbarung damit auch die Verwertungsrechte) bei diesem liegen. Aus Erfahrung kann aber gesagt werden, dass derartig detaillierte Pflichtenhefte, bei denen dann wirklich nur mehr eine Codierung vorliegt, wohl kaum vorkommen werden. Je nach Qualität der Vorgaben kann es aber durchaus sein, dass eine Miturheberschaft von beiden vorliegt.
[15]
Sinnvoll ist es daher auf jeden Fall aus Sicht des Softwareherstellers entsprechende vertragliche Vereinbarungen vorzusehen, damit es sicher gestellt ist, dass die Verwertungsrechte an den vereinbarten Leistungen (Programme, Dokumentationen, usw.) ausschließlich beim Auftragnehmer liegen.

3.

OGH und EUGH-Rechtsprechung ^

[16]

Der Autor hat eine umfassende Untersuchung der OGH-Urteile zu diesem Thema vorgenommen. Das derzeit vorliegende aktuellste Urteil zu diesem Thema8 behandelt dabei den Verkauf einer Warenwirtschaftssoftware, die an die speziellen Bedürfnisse der Beklagten angepasst wurde und liefert auch umfassende Unterscheidungskriterien:

[17]
Zur Qualifikation des Vertrags über den Erwerb von Computer-Software liegt bereits ausreichend Rechtsprechung des Obersten Gerichtshofs vor. Während die dauerhafte Überlassung einer auf Datenträgern verkörperten Standardsoftware gegen einmaliges Entgelt als Kaufvertrag qualifiziert wird (RIS-Justiz RS0108702), ist die Lieferung von Individualsoftware, also einer solchen, die speziell auf die besonderen Bedürfnisse und individuellen Umstände und Wünsche eines Bestellers ausgerichtet ist, als Werkvertrag zu beurteilen (2 Ob 668/84 EvBl 1985/79; 2 Ob 625/90 WBl 1991, 270; 9 Ob 81/04h SZ 2005/109). Da die von der Klägerin angebotene Standardsoftware als klassische Warenwirtschaftssoftware (für Ein- und Verkauf von Waren, Lagerhaltung etc.) für die Bedürfnisse der Beklagten als Büro für sicherheitstechnische und medizintechnische Überprüfungen nicht geeignet war, sondern es eines erheblichen Aufwands bedurft hätte, sie für die Bedürfnisse der Beklagten und die besonderen Anforderungen ihres Betriebs zu entwickeln, wobei ihr die Klägerin auch einen entsprechenden Erfolg zusagte, ist die Beurteilung – auch wenn zwischen den Parteien nicht die Herstellung einer Spezialsoftware vereinbart war – nach den Regeln des Werkvertragsrechts vorzunehmen, weil aus einem bereits bestehenden Softwareprodukt mit erheblichem Aufwand durch Anpassungen und Erweiterungen eine in dieser Form bisher nicht existierende, auf die besonderen Bedürfnisse der Erwerberin zugeschnittene Individualsoftware herzustellen war.
[18]
Auch das oben erwähnte EuGH-Urteil «Levob» geht in ähnlicher Weise von einer Einstufung als Dienstleistung aus, wenn die fragliche Anpassung weder unbedeutend noch nebensächlich, sondern vielmehr von ausschlaggebender Bedeutung ist; das ist insbesondere dann der Fall wenn diese Anpassung angesichts von Umständen wie ihrem Umfang, ihren Kosten oder ihrer Dauer entscheidend dafür ist, dass der Erwerber eine auf ihn zugeschnittene Software nutzen kann.
[19]
Wesentliche Kriterien sind daher:
  • Erheblicher Aufwand in Bezug auf Umfang, Kosten oder Dauer
  • In dieser Form bisher nicht existierende Software
  • Auf besondere Bedürfnisse der Erwerberin zugeschnitten
[20]
Entscheidend für die Nutzung

4.

Fallbeispiele ^

[21]
Im Folgenden werden am Beispiel der Einführung einer ERP-Software einige Fallbeispiele kurz analysiert.

4.1.

Customizing ^

[22]
Umso größer und spezieller ein Betrieb ist, desto spezieller sind auch die Anforderungen an die ERP-Software. Gute und vielfältig einsetzbare Produkte tragen dem Rechnung, indem es eine Vielzahl von Parametern gibt, die im Rahmen eines Einführungsprojektes entsprechend gesetzt werden müssen. Beispiele dafür sind etwa die Art der Lagerführung, Zahlungskonditionen oder die Notwendigkeit verschiedenster Prüfungen (beispielsweise Mindestbestellwert, Kreditlimit, …).
[23]
Diese Einstellungen können durchaus sehr aufwendig sein und sind häufig eine umfassende Dienstleistung, die damit einen erheblichen Aufwand bedeuten kann. Das Customizing ist auch sicherlich entscheidend für die Nutzung und auf die besonderen Bedürfnisse der Erwerberin zugeschnitten. Damit ist es – abhängig vom Aufwand – durchaus denkbar, dass entsprechend dem oben zitierten EuGH-Urteil «Levob» – es sich aus steuerlicher Sicht um eine einheitliche Leistung handelt.
[24]
Was aber wesentlich ist, ist, dass damit keine in dieser Form bisher nicht existierende Software geschaffen wird. Die Software hat in dieser Form schon existiert, es wurden keine Änderungen an ihr vorgenommen, da keine einzige Quellcodezeile geändert werden musste, nur vorhandene Funktionalitäten der bestehenden Software wurden genutzt. Daher wurde auch kein neues Werk geschaffen, wodurch Rechte an diesem begründet werden könnten.

4.2.

Individuelle Programmverbesserungen ^

[25]
Häufig gibt es bei Einführungsprojekten die Thematik, dass der Kunde verschiedene Verbesserungsvorschläge zur Software vorbringt, die dann vom Lieferanten auch umgesetzt werden. Beispiele dafür wären etwa komfortablere Eingaben, zusätzliche Anzeigen oder auch (minimale) Laufzeitoptimierungen.
[26]
Die Umsetzung findet dabei in einer Art und Weise statt, dass die Änderungen in den Auslieferungsstandard des Lieferanten übergehen und dann auch von anderen Kunden genutzt werden können. Vielfach werden diese Adaptierungen auch ohne Verrechnung von Aufwand durchgeführt, teilweise aber auch Kostenbeiträge verrechnet. Etwaige Kostenbeiträge sind in vielen Fällen durchaus auch berechtigt, da etwa Umpriorisierungen stattfinden müssen.
[27]
Wesentlich ist dabei aber, dass diese Punkte nicht entscheidend für die Nutzung sind, der Kunde könnte die Software auch sonst, eventuell zwar mit weniger Komfort, nutzen. Daher sind diese Leistungen von untergeordneter Natur.

4.3.

Individuelle «Add-ons» ^

[28]
Viele ERP-Softwareprodukte geben auch die Möglichkeit, dass individuelle «Add-ons» programmiert werden können. Dabei wird nicht das Programm verändert, sondern es werden neue vollkommen unabhängige Bausteine dazu programmiert. Diese tauschen über Schnittstellen Daten mit der ERP-Software aus. Beispiele dafür wären etwa «Apps», die eine Online-Erfassung von Leistungszeiten ermöglichen, die dann mittels Schnittstelle importiert werden können. Aber auch Makros, also kleine Programmfragmente, die etwa Prüfungen vornehmen oder Hinweise anzeigen können, sind Beispiele dafür.
[29]
Wesentlich bei diesen individuellen «Add-ons» ist, dass diese eigenständige Werke sind, dennoch bleiben aber angesichts der oben erarbeiteten Kriterien einige Fragezeichen, denn sie können durchaus entscheidend für die Nutzung sein. Etwa könnte eine Anforderung sein, dass eine Online-Erfassung notwendig ist und nur durch das entwickelte App ist diese gewährleistet. Auch ist sie auf die besonderen Bedürfnisse der Erwerberin zugeschnitten und hat in dieser Form bisher nicht existiert. Sofern es sich also um einen erheblichen Aufwand handelt, wird es sich aus steuerlicher Sicht sicherlich um eine einheitliche Leistung handeln und auch die Diskussion über Werkvertrag und Kaufvertrag bzw. auch um etwaige erworbene Rechte am Werk, könnte durchaus in Richtung Werkvertrag gehen.
[30]
Eine klare Trennung könnte aber bei derartigen «Add-ons» auch sein, dass die beiden Werke durch verschiedene Lieferanten geliefert werden. Da es etwa für die Erstellung von Makros nicht notwendig ist den gesamten Quellcode zu kennen (und zu compilieren), kann auch ein Dritter der gar keinen Zugang zu diesem Quellcode braucht, die Erweiterungen liefern. Damit würde eine klare Trennung erreicht werden und es wären wohl unzweifelhaft zwei getrennte Verkaufsfälle, ein Kaufvertrag für die Software und ein Werkvertrag für die Erweiterung. Natürlich wäre es aus Kundensicht aber vorteilhaft nur einen Verkäufer zu haben, alleine schon, weil dann bei etwaigen Inkompatibilitäten oder Fehlern nicht erst geklärt werden muss, wer diese vertreten muss, womit sich durch eine derartige Trennung zwar eine klare rechtliche Situation in Bezug auf Unterscheidung Kauf- und Werkvertrag, aber auch ein Wettbewerbsnachteil ergibt.

4.4.

Individuelle Anpassungen ^

[31]
Tatsächlich werden in vielen ERP-Projekten aber Änderungen an der ERP-Software selbst vorzunehmen sein, da der Kunde Anforderungen hat, die bislang die Software so nicht lösen kann. Beispiele dafür wären spezielle Abläufe oder Branchenspezifika, die bislang noch nicht umgesetzt wurden.
[32]
In diesem Falle würde auf jeden Fall eine bisher nicht existierende Software, die auf besondere Bedürfnisse der Erwerberin zugeschnitten ist, geschaffen. Auch werden die Änderungen entscheidend für die Nutzung sein. Somit wird aber nicht nur der neu geschaffene Teil, sondern die gesamte Software unter Umständen zu einer Individualsoftware, sofern auch das Kriterium erheblicher Aufwand erfüllt ist.
[33]

Gerade dieses Kriterium ist aber ein sehr problematisches, da «erheblich» ein dehnbarer Begriff ist und auch aus den bislang vorliegenden OGH-Urteilen9 zu diesem Thema nicht wirklich ein Maßstab dafür ableitbar ist, wann Änderungen erheblich sind. Wird etwa der Preis herangenommen, sind die individuellen Änderungen oft vielfach teurer als das ERP-Programm selbst. Denn die Änderungen werden zu einem normalen Stundensatz fakturiert, während das ERP-Programm ja oft tausendfach verkauft wird und somit die Entwicklungskosten auch tausendfach geteilt werden können. Das führt auch dazu, dass mittlerweile bei vielen ERP-Softwareeinführungen der Dienstleistungskostenanteil bereits höher als der Lizenzkostenanteil ist.

[34]
Aber auch wenn der stundenmäßige Aufwand für die individuellen Änderungen betrachtet wird, wird die Entscheidung kaum eindeutig sein: Zwar werden sicherlich wenige Stunden Aufwand, was unter Umständen ja schon ausreichen könnte, eher nicht erheblich sein, aber bei 100 Stunden ist dies nicht mehr so eindeutig. Denn 100 Stunden für sich alleine wären eventuell durchaus ein erheblicher Aufwand. Wird dies im Verhältnis zum restlichen Projekt gesehen, kann aber sicherlich nicht von erheblich gesprochen werden. Denn dem stehen sicherlich etlichen Personenjahre Entwicklungsaufwand an der eigentlichen ERP-Software gegenüber. In diesem Fall fällt eine eindeutige Zuordnung also schwer und es wird im Streitfall nicht so eindeutig sein, ob die Änderungen zu einer Individualsoftware führen oder nicht. Eine unliebsame Überraschung aus Sicht des Softwareherstellers erscheint hier auf jeden Fall möglich.

5.

Schlussfolgerungen ^

[35]
Die eigentlich einfach erscheinende Unterscheidung zwischen Standard- und Individualsoftware kann in vielen Fällen gar nicht so eindeutig getroffen werden. Insbesondere dann, wenn für die Nutzung der Software Änderungen notwendig waren und diese einen erheblichen Aufwand in Bezug auf Umfang, Kosten oder Dauer aufwiesen, ist insgesamt von einer Schaffung einer Individualsoftware auszugehen. Dies sogar, wenn die Software und die Dienstleistungen getrennt ausgewiesen werden, sofern die Änderungen entscheidend für die Nutzung waren. Es ist daher auf jeden Fall sinnvoll aus Sicht des Softwareherstellers die Verträge so zu fertigen, dass auch für den Fall, dass es sich um einen Werkvertrag handeln sollte, keine Unklarheiten etwa bezüglich der Nutzungs- und Verwertungsrechte bestehen.

 

Markus Knasmüller

Allgemein beeideter und gerichtlich zertifizierter Sachverständiger sowie Leiter der Software-Entwicklung der BMD Systemhaus GmbH

Sierninger Straße 190, 4400, Steyr, AT

knasmueller@bmd.com; http://www.bmd.com

 


  1. 1 §1053 ABGB.
  2. 2 §1151 (1) ABGB.
  3. 3 Der Vertrag über die Herstellung und Lieferung von Individualsoftware allein ist kein Werklieferungsvertrag im Sinn des § 381 Abs. 2 HGB, der die Rüge- und Untersuchungsobliegenheit des § 377 Abs. 1 HGB auslösen könnte.
  4. 4 BGH 15. November 2006, CR 2007, 75 ff., 76.
  5. 5 UStR 2000 Rz. 587.
  6. 6 Mayr, Die umsatzsteuerliche Behandlung von Software im Unternehmensbereich, RWP Heft 6/2008, S. 160 (2008).
  7. 7 EuGH 27. Oktober 2005, C-41/04.
  8. 8 OGH 23. Oktober 2012, 5 Ob 111/12b.
  9. 9 OGH 15. Januar 1985, 2 Ob 668/84; OGH 10. April 1991, 2 Ob 625/90; OGH 3. August 2005, 9Ob 81/04h; OGH 2 Oktober 2012, 5 Ob 111/12b.