201720.03.

Einziehung und Abfindung in der GmbH Satzung

Gründen mehrere Gesellschafter gemeinschaftlich eine GmbH oder ein UG, so ist häufig vorgesehen, dass sich auch alle Gesellschafter mit ihrer vollen Arbeitskraft in der GmbH einbringen sollen. Der Beitrag eines Gesellschafters kann zwar auch rein finanzieller Natur sein. Immer häufiger schließen sich jedoch auch verschiedene Unternehmer zusammen, um gemeinsam ein neues Geschäft zu entwickeln. Der persönliche Beitrag der Gesellschafter in Form der eigenen Arbeitsleistung spielt daher neben der Bar- oder Sacheinlage ins Stammkapital eine immer wichtigere Rolle.

Im Umkehrschluss bedeutet dies für viele, dass das Anrecht zur Partizipation am Erfolg des Unternehmens auch zwingend daran geknüpft sein sollte, dass sich jeder Mitgesellschafter auch tatsächlich in die Gesellschaft einbringt. Scheidet einer der Mitgesellschafter dagegen aus der Mitarbeit im Unternehmen aus, so wünschen sich viele, dass dieser auch aus seiner Rolle als Gesellschafter verlieren soll. Ein solcher Ausschluss eines Gesellschafters ist zwar grundsätzlich möglich, hat jedoch auch erhebliche Konsequenzen sowohl für den ausgeschlossenen Gesellschafter, als auch für die Gesellschaft.

In diesem Beitrag möchten wir einige grundsätzliche Fragestellungen im Zusammenhang mit einem solchen Ausschluss beleuchten.

Grundsätzliches

Ist in einer „personalistisch strukturierten“ GmbH vorgesehen, dass alle Gesellschafter mitarbeiten, dann ist es grundsätzlich möglich, für den Fall des Ausscheidens eines Gesellschafters als Geschäftsführer oder Mitarbeiter eine Einziehung seiner Anteile im Gesellschaftsvertrag vorzusehen. Dies kann auch gegen den Willen des betroffenen Gesellschafters erfolgen. Da es sich dabei aber um einen schwerwiegenden Eingriff in die Rechte des Gesellschafters handelt, muss bei der Gestaltung und Durchführung der Einziehung stets die Verhältnismäßigkeit im Blick behalten werden, um die Wirksamkeit der entsprechenden Klauseln nicht zu gefährden. Der Bundesgerichtshof („BGH“) hat für viele Fragen der Einziehung Grenzen aufgezeigt oder festgehalten, welche Eingriffe als noch verhältnismäßig zu bewerten sind. Es muss aber darauf hingewiesen werden, dass diese Entscheidungen regelmäßig die Frage der Verhältnismäßigkeit nur für bestimmte Fallkonstellationen klären können. Die Ergebnisse sind nicht zwingend auf andere Konstellationen übertragbar. Ferner ist anzumerken, dass viele Grundsatzentscheidungen mehrere Jahrzehnte zurückliegen. Daher könnte es vorkommen, dass Gerichte heute zu einer anderen Bewertung kommen. Es verbleibt daher das Risiko, dass einzelne Regelungen aufgrund fortentwickelter Rechtsprechung in Zukunft als sittenwidrig und damit nichtig eingestuft werden.

Die wichtigsten Risikofaktoren im Hinblick auf die Wirksamkeit einer Einziehungsklausel halten wir hier noch einmal fest:

Einziehungsgründe:

Der BGH hat sehr strenge Anforderungen für den Ausschluss eines Gesellschafters durch andere Gesellschafter aufgestellt. In der Regel ist immer ein „wichtiger Grund“ für den Ausschluss erforderlich:

„Eine gesellschaftsvertragliche Vereinbarung, die der Gesellschafterversammlung das Recht einräumt, Gesellschafter aus der Gesellschaft auszuschließen, berechtigt allenfalls dann zur Ausschließung ohne wichtigen Grund, wenn sich dies unzweideutig aus dem Gesellschaftsvertrag ergibt.

Die gesellschaftsvertragliche Bestimmung, durch Gesellschafterbeschluß könne ein Gesellschafter ohne Vorliegen eines wichtigen Grundes aus der Gesellschaft ausgeschlossen werden, ist nur dann zulässig, wenn für eine solche Regelung wegen außergewöhnlicher Umstände sachlich gerechtfertigte Gründe bestehen.“

BGH, Urteil vom 20. 1. 1977 – II ZR 217/75

Einen solchen wichtigen Grund sieht der BGH ausnahmsweise dort, wo die Mitarbeit des Gesellschafters in der Gesellschaft durch die Satzung vorgesehen ist und der Ausschluss dann erfolgt, wenn der Gesellschafter als Mitarbeiter ausscheidet:

„In einer auf die Mitarbeit aller Gesellschafter angelegten GmbH kann die Satzung bestimmen, daß die Beendigung der Mitarbeit ein Ausschließungsgrund ist.“

„In einer personalistisch ausgerichteten, auf die Mitarbeit aller Gesellschafter angelegten GmbH kann die Satzung ohne weiteres den Ausschluß eines Gesellschafters vorsehen, der nicht mehr mitarbeitet. Das Ende der Mitarbeit ist ein sachlicher Grund, den Gesellschafter am künftigen Erfolg des Unternehmens nicht mehr zu beteiligen. Allerdings nehmen BerGer. und Revision zutreffend an, daß das nicht ausnahmslos gelten kann. Beendet die Gesellschaft das Arbeitsverhältnis ohne sachlichen Grund willkürlich, wäre der Ausschluß – falls keine anderen Gründe vorliegen – sachlich nicht gerechtfertigt, sondern ebenfalls willkürlich und deshalb nichtig. Dieses von der Gesellschaft willkürlich herbeigeführte Ende der Mitarbeit deckt die Satzung nicht. Legt man diese aber insoweit einschränkend aus, läßt sich nichts dagegen einwenden, daß ein Gesellschafter ausgeschlossen wird, weil er nicht mehr mitarbeitet.“

BGH, Urteil vom 20.06.1983 – II ZR 237/82

Allerdings muss angemerkt werden, dass sich der BGH, soweit ersichtlich, in keiner anderen Entscheidung so weit hervorgewagt hat, wie hier. In anderen Konstellationen mussten in der Regel stets weitere Gründe hinzutreten, um für einen Ausschluss auszureichen.

Abfindungshöhe:

Ein zentraler Punkt im Zusammenhang mit der Einziehung von Anteilen ist die zu zahlende Abfindung. Grundsätzlich ist der Gesellschafter zum vollen Verkehrswert seines Anteils abzufinden. Allerdings kann in der Satzung auch ein anderer Wert angesetzt werden. Regelmäßig wird in der Literatur empfohlen, zum Schutz des Fortbestands der Gesellschaft (insbesondere zum Erhalt der Liquidität) eine niedrigere Abfindung vorzusehen. Auch wenn dem Bestandsschutz der Gesellschaft in der Satzung regelmäßig eine große Bedeutung beizumessen ist, sind Abfindungsbeschränkungen aber nicht schrankenlos zulässig. Eine Abfindungsklausel gilt als sittenwidrig (und ist damit nach § 138 BGB nichtig), „wenn sie den Abfindungsanspruch in einem Maße beschränkt, das außer Verhältnis zu der Beschränkung steht, die erforderlich ist, um im Interesse der verbleibenden Gesellschafter den Fortbestand der Gesellschaft und die Fortführung des Unternehmens zu sichern“:

„Die Abfindung […] weicht von dem Verkehrswert dann in vollkommen unangemessener Weise ab, wenn das an dem gesellschaftlichen Zweck ausgerichtete Interesse der verbleibenden Gesellschafter an dem Fortbestand der Gesellschaft und des Unternehmens eine derart weitgehende Beschneidung des Abfindungsrechtes nicht erforderlich erscheinen läßt und der an dem Unternehmenswert auszurichtende volle wirtschaftliche Anteilswert den Nennwert erheblich übersteigt, möglicherweise ein Vielfaches des Nennwertes ausmacht. Unter dieser Voraussetzung stellt sich die Beschränkung des Abfindungsrechts als willkürlich und bar jeder sachlichen Rechtfertigung dar. Ist das der Fall, erscheint die Abfindung zum Nennwert unangemessen und damit sittenwidrig.“

BGH, Urteil vom 16.12.1991, Aktenzeichen II ZR 58/91, Juris Rn. 39

Diverse Gerichtsentscheidungen beschäftigen sich mit der Frage, ob in den jeweils vorgelegten Sachverhalten Nennwertklauseln, Buchwertklauseln oder Klauseln, die eine Abfindung nach dem Verkehrswert abzüglich eines Abschlags vorsehen, zulässig sind. Allerdings handelt es sich auch hierbei wieder um Einzelfallentscheidungen, die nur schwer zu verallgemeinern sind.

Die Angemessenheit einer Abfindung ist letztlich an dem tatsächlichen Unternehmenswert sowie an der konkreten finanziellen Situation des Unternehmens zu messen. Hierbei ist auch zu berücksichtigen, welche Abfindung das Unternehmen stemmen kann, ohne dass die Fortführung des Unternehmens gefährdet wird.

Rechtsfolgen bei zu niedriger Abfindungshöhe:

Bei einer in der Satzung zu niedrig festgelegten Abfindung hängt die Rechtsfolge davon ab, ob die Abfindung bereits von Anfang an (also bei Einführung der Klausel in die Satzung) zu niedrig war oder ob sie erst nachträglich (z.B. bei einer Wertsteigerung des Unternehmens wegen sehr guter Geschäftsentwicklung) den tatsächlichen Wert des Unternehmens zu stark unterschreitet.

Ist die Vereinbarung zur Abfindung als von Anfang an sittenwidrig einzustufen, dann ist sie nichtig. Anstelle der vereinbarten Abfindung tritt dann eine Abfindung zum vollen Verkehrswert. Zum Teil wird vertreten, dass mit einer salvatorischen Klausel eine Abfindung zum niedrigsten noch zulässigen Wert ermöglicht werden kann. Eine solche Klausel sollte daher in jedem Fall vorsorglich in die Satzung aufgenommen werden. Wird die Nichtigkeit nicht innerhalb der Dreijahresfrist des § 242 Abs. 2 Aktiengesetz geltend gemacht, so kann sich niemand mehr auf die Nichtigkeit berufen und es tritt nach einer in der Literatur vertretenen Auffassung eine „Heilung“ der Nichtigkeit ein. Allerdings ist dann mit ergänzender Vertragsauslegung gleichwohl ein angemessener Abfindungsbetrag zu ermitteln (wie nachfolgend für die nachträgliche Sittenwidrigkeit beschrieben).

Anders liegt der Fall, wenn zum Zeitpunkt der Satzungsänderung die Abfindungsregelung noch angemessen ist und erst später durch die wirtschaftliche Entwicklung des Unternehmens ein grobes Missverhältnis zwischen Abfindung nach der Satzung und dem tatsächlichen Verkehrswert entsteht:

 „Eine ursprünglich unwirksame [sic – gemeint ist dem Kontext nach aber wohl: „eine ursprünglich wirksame“], zunächst weder nach § 138 BGB zu beanstandende noch das Kündigungsrecht der Gesellschafter entgegen § 723 III BGB faktisch beeinträchtigende Abfindungsklausel wird nicht dadurch nichtig, daß sich – insbesondere bei wirtschaftlich erfolgreichen Unternehmen – Abfindungsanspruch und tatsächlicher Anteilswert im Laufe der Jahre immer weiter voneinander entfernen. Die vertragliche Regelung bleibt vielmehr als solche wirksam. Die Frage ist nur, welchen Inhalt sie unter Berücksichtigung der Grundsätze von Treu und Glauben hat und ob sie gegebenenfalls im Hinblick auf die geänderten Verhältnisse zu ergänzen ist.

Letztlich geht es um eine die beiderseitigen Interessen im Hinblick auf die Änderung der tatsächliche

201714.02.

Beitragsreihe: Verträge für agile Softwareprojekte – Vertragstypologische Abgrenzungen in der Rechtsprechung

Teil V – Vertragstypologische Abgrenzungen in der Rechtsprechung

Die Beitragsreihe “Verträge für agile Softwareprojekte” setzt sich mit den schuld- und urheberrechtlichen Aspekten der agilen Softwareentwicklung auseinander. Unter der Prämisse, dass agile Verträge als Lösungsansatz auch für deutsche Unternehmen zunehmend Relevanz erlangen, diese Thematik bisher jedoch nur rudimentär aufgearbeitet wurde, wird anhand von Rechtsprechung und Literatur die gegenwärtige Rechtslage veranschaulicht. Schlussendlich werden Empfehlungen zu vertraglichen Regelungen ausgesprochen, die sich mit Blick auf die Vielzahl von Problemen und Risiken ergeben, die bei agilen Softwareentwicklungsprojekten zu erwarten sind.

Zurück zu Teil IV: Unsere Empfehlung: Agile “Time and Material”-Projekte

Vertragstypologische Abgrenzungen in der Rechtsprechung

Wird der Vertrag nicht deutlich genug zugeordnet oder befinden sich die Beteiligten in einem Rechtsstreit und machen Unklarheiten geltend, kann es letztlich den Gerichten obliegen eine vertragstypologische Zuordnung vorzunehmen. Um diesen Fällen durch geeignete inhaltliche Regelungen vorzubeugen, ist zunächst ein Überblick der Rechtsprechung zu vergleichbaren Fällen erforderlich.

Kauf- oder Werkvertragsrecht

Mit der für die Abnahme besonders wichtigen Abgrenzung vom Werklieferungsvertrag bei individuellen Programmierleistungen hat sich der BGH bereits vor der Schuldrechtsmodernisierung befasst.[1] Die Beklagte, ein Softwareentwickler, wurde von der Klägerin beauftragt, eine Standardsoftware in eine andere Programmiersprache zu übertragen und mit weiteren Betriebssystemen kompatibel zu machen. Der Senat führte hierzu aus, die Absprachen der Parteien beträfen keinen Werklieferungsvertrag im Sinne des § 651 BGB a.F, sondern stellten sich rechtlich als Werkvertrag dar. Maßgeblich für die Abgrenzung sei, ob die Leistungspflicht die Herstellung eines Werkes aus vom Schuldner zu beschaffenden Programmen und Programmteilen, oder wie hier Arbeiten an einem zur Verfügung gestellten Programm und dessen Umgestaltung, und somit nur noch individuelle Programmierleistungen als Gegenstand der Vereinbarung umfasse. Insofern wurde bereits hier auf den Schwerpunkt der vertraglichen Vereinbarung zwischen den Parteien abgestellt und eine eindeutige Zuordnung ermöglicht.

Die Schuldrechtsmodernisierung änderte den Wortlaut des § 651 BGB jedoch dahingehend, dass nunmehr Kaufrecht Anwendung finden soll, wenn der Vertrag die Lieferung herzustellender oder zu erzeugender beweglicher Sachen zum Gegenstand hat.

Leistungsschwerpunkt

Ob und inwiefern weiterhin Werkvertragsrecht auf Verträge über individuelle Programmierleistungen anzuwenden ist, ist infolgedessen nicht mehr eindeutig.[2] Der BGH umriss die Voraussetzungen für die Anwendung von Werkvertrags- oder Werklieferungsrecht bei Verträgen über die Lieferung von herzustellenden beweglichen Sachen nach dem neuen Schuldrecht unlängst in einem Fall aus der analogen Welt.[3] Die Klägerin verlangte von der Beklagten die Nacherfüllung aus einem Vertrag über die Errichtung einer Siloanlage mit vom Schuldner herzustellenden und zu liefernden Bauteilen. Das Gericht musste in diesem Zusammenhang prüfen, ob eine kaufrechtlich bestehende Untersuchungs- und Rügepflicht  gem. §§ 377, 381 Abs. 2 BGB für die Klägerin bestand, der sie nicht nachgekommen wäre. Zur Anwendung des § 651 BGB führte der zuständige Senat aus, eine Überprüfung der grundsätzlichen Anwendbarkeit sei allenfalls dann in Betracht zu ziehen, wenn die Planungsleistungen so dominieren, dass sie den Schwerpunkt des Vertrages bilden und deshalb die Anwendung des Werkvertragsrechts erfordern. Dahingegen könnten solche Planungsleistungen, die nur eine Vorstufe für die schwerpunktmäßige Herstellung von zu liefernden Sachen darstellen, nicht berücksichtigt werden.

Die Subsumtion von klassischen Softwareentwicklungsverträgen unter diese Voraussetzungen erweist sich als schwierig. Zumindest für agile Softwareentwicklungsverträge lässt sich aus dieser Rechtsprechung eine werkvertragliche Einordnung ableiten, die sich bereits aus der gesteigerten Bedeutung und Häufigkeit von planerischen Tätigkeiten bei iterativen Entwicklungsmethoden ergibt. Der fortlaufende Anpassungsprozess, der die Entwicklung in allen Phasen begleitet, ist das wesentliche Merkmal, das die zugrundeliegenden Verträge bestimmt und definiert.

Werk- oder Dienstvertragsrecht

Aufgrund der fehlenden rechtlichen Aufarbeitung dieser Thematik bietet sich ausweichend eine Betrachtung von ähnlichen Vertragsmodellen an. Mit der vertragstypologischen Einordnung eines mit agilen Softwareentwicklungsverträgen vergleichbaren Forschungs- und Entwicklungsvertrages hat sich der BGH in einem Fall befasst, in dem die Klägerin die Beklagte unter Zugrundelegung eines Arbeitsplans mit der Erforschung und Herstellung von Antigenen beauftragt hatte. Im Arbeitsplan wurden sechs „Meilensteine“ definiert und dabei für jeden Meilenstein ein Termin angegeben. Die Klägerin verlangte die Rückzahlung von bisherigen Leistungen. Maßgeblich für die rechtliche Würdigung war die Bewertung des Verhältnisses nach Werk- oder Dienstvertragsrecht. Forschungs- und Entwicklungsleistungen könnten Gegenstand eines Dienstvertrags wie auch eines Werkvertrags sein. Für das Vorliegen eines Werkvertrages spreche die konkrete Festlegung der zu erledigenden Aufgaben und deren Umfang. Auch eine erfolgsabhängige Vergütung sei ein Indiz. Die vertragliche Beschreibung eines Ziels sei allein aber kein hinreichendes Indiz für die Annahme eines Werkvertrags. Zwar sei die konkrete Beschreibung des zu erreichenden Erfolgs ein typisches Merkmal eines Werkvertrags, aber auch bei Dienstverträgen könne die geschuldete Leistung der Erreichung eines bestimmten Ziels dienen. Die konkrete Beschreibung eines Ziels im Vertragstext sei dann lediglich ein Mittel zur Konkretisierung der zu erbringenden Tätigkeit im Rahmen des Weisungsrechts.

[1] BGH, Urteil v. 9. Oktober 2001 – Az. X ZR 58/00.
[2] Witte in Redeker, Handbuch der IT-Verträge,  Teil 1.4 (Rz. 12).
[3] BGH, Urteil v. 23. Juli 2009 – Az. VII ZR 151/08.

RA Bilal Abedin
Wiss. Mit. Burak Zurel

201731.01.

Beitragsreihe: Verträge für agile Softwareprojekte – Unsere Empfehlung: Agile “Time and Materials”-Projekte

Vertragliche Regelungen bei agilen Time and Material Projekten

Teil IV – Unsere Empfehlung: Agile “Time and Material”-Projekte


Die Beitragsreihe “Verträge für agile Softwareprojekte” setzt sich mit den schuld- und urheberrechtlichen Aspekten der agilen Softwareentwicklung auseinander. Unter der Prämisse, dass agile Verträge als Lösungsansatz auch für deutsche Unternehmen zunehmend Relevanz erlangen, diese Thematik bisher jedoch nur rudimentär aufgearbeitet wurde, wird anhand von Rechtsprechung und Literatur die gegenwärtige Rechtslage veranschaulicht. Schlussendlich werden Empfehlungen zu vertraglichen Regelungen ausgesprochen, die sich mit Blick auf die Vielzahl von Problemen und Risiken ergeben, die bei agilen Softwareentwicklungsprojekten zu erwarten sind.

Zurück zu Teil III: Konventionelle Vertragsmodelle

Agile Time and Materials-Projekte

Unsere Empfehlung für agile Projekte ist der Dienstvertrag mit definierten Prozessen und Sollbruchstellen. Die Risikoverschiebung des konventionellen Dienstvertrags zu Lasten des Auftraggebers wird durch dieses Konzept mit entsprechenden vertraglichen Regelungen aufgefangen. Diese Regelungen bieten bessere Kontroll- und Steuerungsmöglichkeiten, ermöglichen die frühzeitige Erkennung und effektive Lösung von Problemen, versprechen die vollständige Ausnutzung von Verbesserungs- und Einsparpotentialen und halten im Zweifel Sicherheitsmaßnahmen bereit, um durch Sollbruchstellen und ein geordnetes Exit Management eine einvernehmliche Trennung in beiderseitigem Interesse zu ermöglichen.

Die vertraglichen Regelungen sollten zuvorderst der klaren Definition der Arbeitsprozesse gelten. Die agile Softwareentwicklung am Beispiel des Scrum hat in der Praxis Arbeitsschritte entwickelt, die sich als produktiv erwiesen haben.[1] So empfiehlt es sich, Sprint Planning, Daily Scrum, Sprint Review, Sprint-Retrospective und Backlog Planning & Refinement als fortlaufendende Prozesse, bei denen sich Product Owner und Dienstleister oder das Entwicklerteam untereinander über die konkrete Gestaltung des Produkts austauschen und eine Bewertung der eigenen Leistungen und des derzeitigen Standes des Produkts vornehmen, als vertragliche Verpflichtung vorzusehen.

Scrum Prozesse

Scrum Prozesse


Im Vertrag sollte auch die Rolle des Product Owners als Vertreter des Auftraggebers geregelt werden.[2] Dem Product Owner sollten im Vertrag Entscheidungsbefugnisse übertragen werden, aus der sich seine Verantwortung für das Projekt ableiten lässt. Seine Verfügbarkeit sollte ebenso vertraglichen Regelungen unterliegen wie der Einsatz eines Proxy Product Owners[3] und Rechtsfolgen von Verzögerungen auf Seiten des Product Owners.

Die Rolle des Product Owners

Die Rolle des Product Owners


Die personelle Konsistenz des Entwicklerteams ist ein weiteres wichtiges Anliegen. Jegliche persönliche Änderung geht mit einem Verlust von spezifischem Wissen oder der notwendigen Einarbeitung eines neuen Mitglieds einher. Da sich dies stets negativ auf die Projektkosten und -dauer auswirkt, sollte ein definierter Anteil des Teams gleich bleiben müssen. Gleichwohl sollte ein Verfahren vorgesehen werden, um besonders wichtige Teammitglieder bei ihrem Ausscheiden aus dem Team mit vergleichbar qualifizierten Mitarbeitern zu ersetzen. Dies erlaubt es dem Auftraggeber, trotz der Beauftragung eines externen Dienstleisters, weitgehend die Kontrolle über die Zusammensetzung des Entwicklerteams zu behalten und die Erfolgswahrscheinlichkeit des Projekts zu erhöhen.

Exit Management

Durch ein Exit Management im Vertrag soll der Auftraggeber in die Lage versetzt werden, bei vorzeitigem Abbruch des Projekts mit dem bisherigen Dienstleister, also im worst case scenario, ohne Übergabe-Problematik möglichst nahtlos einen neuen Dienstleister beauftragen zu können. Dies erfordert Sollbruchstellen im Projekt, die bei übermäßiger Belastung der Geschäftsbeziehung oder einem sich abzeichnenden Misserfolg ein einvernehmliches Loslösen vom Vertrag erlauben. In diesem Zusammenhang sollten auch die Kündigungsfristen so bestimmt werden, dass beide Parteien genug Zeit für Abschlussvorbereitungen erhalten, um beispielsweise die Dokumentation vervollständigt übergeben zu können. Besonders bei Festpreismodellen ist eine Übergaberegelung hinsichtlich der bereits geleisteten Arbeitsleistung vorzusehen. So kann sich die zu leistende Zahlung anteilsmäßig auf den Prozentsatz der vervollständigten Arbeit oder auf die anteilige Auftragsdauer beziehen.

Sollbruchstellen & Exit Management

Sollbruchstellen & Exit Management


Abschließend sollte im Vertrag zu Art und Umfang der Dokumentation ausgeführt werden, welche Projektarchitektur vorgesehen ist, ob die Dokumentation im Code vorhanden sein soll oder Clean Code mit eigenem Handbuch bevorzugt wird. Die „Definition of Done“ als Kriterienkatalog[4], um ein Feature als fertig implementiert erachten zu dürfen, sollte ebenso nicht dem beliebigen Empfinden der Vertragsparteien unterliegen, sondern möglichst eindeutig im Vertrag zu finden sein.

Dokumentation

Dokumentation


Weiter zu Teil V: Die Rechtsprechung

[i] Schwaber/ Sutherland, The Scrum Guide, S. 9 ff.
[ii] Schwaber / Sutherland, The Scrum Guide, S. 5.
[iii] s. hierzu: Pichler, Agile Product Management with Scrum, S. 41.
[iv] ScrumAlliance, Scrum, S. 9.

RA Bilal Abedin
Wiss. Mit. Burak Zurel

201710.01.

Beitragsreihe: Verträge für agile Softwareprojekte – Konventionelle Vertragsmodelle

Agile Softwareentwicklung - Konventionelle Vertragsmodelle

Agile Softwareentwicklung – Teil III


Die Beitragsreihe “Verträge für agile Softwareprojekte” setzt sich mit den schuld- und urheberrechtlichen Aspekten der agilen Softwareentwicklung auseinander. Unter der Prämisse, dass agile Verträge als Lösungsansatz auch für deutsche Unternehmen zunehmend Relevanz erlangen, diese Thematik bisher jedoch nur rudimentär aufgearbeitet wurde, wird anhand von Rechtsprechung und Literatur die gegenwärtige Rechtslage veranschaulicht. Schlussendlich werden Empfehlungen zu vertraglichen Regelungen ausgesprochen, die sich mit Blick auf die Vielzahl von Problemen und Risiken ergeben, die bei agilen Softwareentwicklungsprojekten zu erwarten sind.

Zurück zu Teil II: Risiken konventioneller Verträge

Konventionelle Vertragsmodelle

Die Vertragsgestaltung ermöglicht es, den vorher genannten Gefahren entgegenzutreten und die Verantwortlichkeit durch eine einvernehmliche Verlagerung in beiderseitigem Interesse gleichmäßig zu verteilen. Das passende Vertragsmodell hängt hierbei von den individuellen Anforderungen und Bedürfnissen der Parteien ab, es gibt also keine universelle Lösung für alle Sachverhalte der agilen Softwareentwicklung. In Betracht kommen zunächst die konventionellen Vertragsmodelle, also der Werkvertrag, der Dienstvertrag, aber auch kombinierte Verträge mit dienst- und werkvertraglichen Elementen.

Der klassische Werkvertrag bildet hierbei das Ausgangsmodell. Beim Werkvertrag schuldet der Dienstleister die Erstellung eines mangelfreien Werks, gemessen auf Grundlage einer konkreten Spezifikation, die vor Arbeitsbeginn einmalig vereinbart wurde. Die Vergütung erfolgt über einen Festpreis und Änderungen an oder der Austausch von Features erfolgt im Rahmen von Change-Requests mit Preissteigerungen auf der Basis von Time and Materials. Der klassische Werkvertrag sieht somit eine Kostensicherheit bei gleichbleibender Spezifikation, die Verantwortung des Auftragnehmers bei Mängeln und dadurch eine Vorhersehbarkeit für Auftraggeber und Auftragnehmer vor. Dies bedeutet zugleich, dass Änderungen stets Nachverhandlungen erfordern, mit nicht-einkalkulierten Kosten verbunden sind und es bedingt Anreize für den Arbeitnehmer gibt, über Verbesserungen im Sinne des Arbeitgebers nachzudenken. Der klassische Werkvertrag ist in der Gesamtbetrachtung für einfache Projekte in unveränderlichen Umgebungen geeignet.


Der Dienstvertrag scheint demgegenüber eher auf die Bedürfnisse der agilen Projektleitung zugeschnitten zu sein. Beim Dienstvertrag schuldet der Dienstleister kein definiertes Ergebnis (Werk) sondern lediglich seine Arbeitsleistung in Form der Tätigkeit. Dadurch verschiebt sich das Erfolgsrisiko zu Lasten des Auftraggebers. Innerhalb des Projekts würde die Software in sogenannten Sprints entwickelt, bei denen jeweils einzelne User-Stories entwickelt und implementiert werden. Ein Sprint ist ein abgeschlossener Zeitrahmen innerhalb dessen vorher bestimmte Entwicklungsziele verwirklicht werden und auf den sofort der nächste Sprint folgt.[1] Die Vergütung erfolgt nach Aufwand, also Time and Materials. Dadurch bietet der Dienstvertrag eine völlige Flexibilität im Hinblick auf den Vertragsgegenstand und eine wirtschaftliche Sicherheit für den Auftragnehmer. Die Projektkosten können für den Auftraggeber jedoch nicht abschließend bestimmt werden, und so bleiben Zeit und Kosten unvorhersehbar. Die Mängelbeseitigung durch den Auftragnehmer führt unweigerlich zu Zusatzkosten für den Auftraggeber. Im Ergebnis ist der Dienstvertrag eher für kleinere Projekte für die Entwicklung von Einzelkomponenten geeignet, die im Rahmen einer bereits eingespielten Zusammenarbeit verwirklicht werden soll.


Einen Kompromiss versucht der Rahmenvertrag mit einzelnen, untergeordneten Werkverträgen darzustellen. Der Rahmenvertrag regelt hierbei die Beziehung von Auftragnehmer und Auftraggeber und fasst einen Großteil des Verhandlungsumfangs einmalig ab. Für jeden Sprint vereinbaren die Parteien sodann einen präzisen Scope mit umzusetzenden User-Stories zu einem festen Preis nach werkvertraglichem Charakter. Die Mängelbeseitigung erfolgt nach jeder Teilabnahme im Rahmen der gesetzlichen Gewährleistung. Dieses Modell erreicht eine hohe Flexibilität, ohne Kostensicherheit bei gleichbleibender Spezifikation zu gefährden und bietet durch die Teilabnahmen und die gesetzliche Gewährleistung einen hervorragenden Ausgleich in der Qualitätssicherung. Jedoch ist jeder Sprint mit einem Verhandlungsaufwand verbunden und die beabsichtigte Agilität, also Änderungen im Scope, führen zu Kostenunsicherheiten. Der Rahmenvertrag mit einzelnen Werkverträgen ist demnach besonders gut für komplizierte Projekte geeignet, an denen ohne Zeitdruck gearbeitet werden kann.


Das Vertragsmodell des agilen Festpreises ist die Fortentwicklung und Anpassung des Werkvertrages mit Werkzeugen, die durch die agile Arbeitsweise selbst bereitgestellt werden. Hierbei werden im Rahmen einer Testphase Referenz-Userstories festgelegt, anhand derer dann allen User-Stories Storypoints zugewiesen werden. Die Parteien vereinbaren einen Festpreis für eine bestimmte Anzahl von Storypoints, die in den jeweiligen Sprints vom Auftraggeber genutzt flexibel genutzt werden können. Die Haftung des Auftragnehmers für Mängel ergibt sich aus den werkvertraglichen Regelungen. Durch dieses Modell wird eine hohe Flexibilität in der Ausgestaltung der Arbeitsleistung vorgesehen, ohne die Haftung des Auftragnehmers für die eigene Arbeitsleistung zu berühren. Change-Requests und Änderungen des Scope unterliegen klaren Prozessen, die im Vertrag beschrieben sind. Die Erforderlichkeit der Testphase und die Möglichkeit, Zeit und Kosten erst nach der Durchführung dieser Testphase bestimmen zu können, verursachen bei den Beteiligten dahingegen einen unproduktiven, möglicherweise sogar vergeblichen Aufwand. Das agile Festpreismodell ist für eingespielte Teams aus Auftragnehmern und Auftraggebern geeignet, insbesondere bei hausinterner Softwareentwicklung.

Weiter zu unserer Empfehlung Teil IV: Agile “Time and Materials”-Projekte

[1] Schwaber/ Sutherland, The Scrum Guide, S. 7.

RA Bilal Abedin
Wiss. Mit. Burak Zurel

201613.12.

Beitragsreihe: Verträge für agile Projekte – Risiken konventioneller Vertragsmodelle

Agile Softwareentwicklung - Risiken von Softwareentwicklungsverträgen

Agile Softwareentwicklung – Teil II


Die Beitragsreihe “Agile Softwareentwicklung” setzt sich mit den schuld- und urheberrechtlichen Aspekten der agilen Softwareentwicklung auseinander. Unter der Prämisse, dass agile Verträge als Lösungsansatz auch für deutsche Unternehmen zunehmend Relevanz erlangen, diese Thematik bisher jedoch nur rudimentär aufgearbeitet wurde, wird anhand von Rechtsprechung und Literatur die gegenwärtige Rechtslage veranschaulicht. Schlussendlich werden Empfehlungen zu vertraglichen Regelungen ausgesprochen, die sich mit Blick auf die Vielzahl von Problemen und Risiken ergeben, die bei agilen Softwareentwicklungsprojekten zu erwarten sind.

Zurück zu Teil I: Ausgangssituation

Risiken bei Softwareentwicklungsprojekten

Softwareentwicklungsprojekte bergen für alle Beteiligten Risiken, die sich stets direkt oder indirekt in den Projektkosten niederschlagen. Beim Wasserfallmodell muss der Auftraggeber beispielsweise in der Preisgestaltung einen tendenziell überhöhten Sicherheitsaufschlag in Kauf nehmen. Durch den regelmäßig vereinbarten Festpreis wird eine vermeintliche Sicherheit für das Projekt geschaffen, die weder Qualität noch Adäquanz der Software gewährleisten kann, gleichwohl diese für den Auftraggeber eine größere Relevanz als die Herstellungskosten haben.[1] Durch die phasenweise notwendigen Nachverhandlungen und die aufwendige, meist akribische, zeit-intensive Erstellung von Lastenheften und Pflichtenheften wird die eigentliche Arbeit blockiert und die beabsichtigte Fertigstellung verzögert. Letztlich schlägt sich die Überforderung des Dienstleisters negativ auf das gesamte Projekt nieder, ohne ein frühzeitig eingreifendes Korrektiv dafür zu haben.

Bei agilen Softwareentwicklungsverträgen, die auf Vertrauen, Teamwork und auf ein möglichst unbestimmtes Ziel ausgerichtetes Vorgehen aufbauen, können sich Gefahren insbesondere wegen der komplizierteren Sachverhalte verwirklichen. So werden durch ein Festpreismodell viele Kostenrisiken für den Auftragnehmer nicht erfasst, die sich aufgrund der erschwerten ex-ante Schätzung des Arbeitsaufwandes ergeben. Andererseits ist der Auftraggeber an dem Erfolg interessiert und kann die Risiken deshalb nur begrenzt auf den Auftragnehmer abwälzen. Im Problemfall werden auch Schadensersatzansprüche nicht geeignet sein, den tatsächlich entstehenden Schaden ausreichend zu kompensieren. Denn auch der beste, für die eine Seite günstigste Vertrag wird zu keiner Lösung verhelfen können, wenn die Erfüllung dem anderen unmöglich oder nicht zuzumuten ist. Zuletzt verbleibt auch das Insolvenzrisiko auf beiden Seiten.

Agile Softwareentwicklung - Risiken Veranschaulichung


Erst durch die Gegenüberstellung der beiden Projektkonzipierungsmodelle werden die Vorteile der agilen Arbeitsweise gegenüber dem Wasserfallmodell deutlich. Die konkret geleistete Arbeit des Dienstleisters orientiert sich durch die stärkere Einbeziehung bei agilen Projekten an flexiblen Vorgaben des Auftraggebers und stellt so eine effizientere Ausrichtung an den Wünschen und Anforderungen des Kunden und eine größere Zufriedenheit dessen mit dem Ergebnis sicher. Treten während der Entwicklungsarbeit Probleme auf, können sie frühzeitig erkannt und adressiert werden. Dadurch werden beiderseits Einspar- und Optimierungspotentiale gänzlich ausgeschöpft.

Weiter zu Teil III: Konventionelle Vertragsmodelle

[1] Oesterreich, Der Agile Festpreis und andere Preis- und Vertragsmodelle, S.1.

RA Bilal Abedin
Wiss. Mit. Burak Zurel


201608.12.

Beitragsreihe: Verträge für agile Softwareprojekte – Ausgangssituation

Agile Softwareentwicklung - Intro Ausgangssituation

Agile Softwareentwicklung – Teil I


Die Beitragsreihe “Verträge für agile Softwareprojekte” setzt sich mit den schuld- und urheberrechtlichen Aspekten der agilen Softwareentwicklung auseinander. Unter der Prämisse, dass agile Verträge als Lösungsansatz auch für deutsche Unternehmen zunehmend Relevanz erlangen, diese Thematik bisher jedoch nur rudimentär aufgearbeitet wurde, wird anhand von Rechtsprechung und Literatur die gegenwärtige Rechtslage veranschaulicht. Schlussendlich werden Empfehlungen zu vertraglichen Regelungen ausgesprochen, die sich mit Blick auf die Vielzahl von Problemen und Risiken ergeben, die bei agilen Softwareentwicklungsprojekten zu erwarten sind.

Agile Programmierung, u.a. mit der Methode „Scrum“, entwickelt sich zunehmend zu dem Standard der IT-Welt. Die dadurch gebotene dynamische und offene Herangehensweise bei der Umsetzung von Projekten bildet einen Kontrast zum typischen Ansatz der Juristen ab, die eine relative Sicherheit durch die vertragliche Dokumentation der wechselseitigen Leistungspflichten schaffen wollen. Zahlreiche Beiträge haben sich bereits mit der Frage beschäftigt, welchem gesetzlich vordefinierten Vertragstypus ein agiles Projekt zuzuordnen sei. Wir wollen diese Thematik dagegen aus der Perspektive der Entwickler und Auftraggeber betrachten. Das Schuldrecht bietet einen weiten Gestaltungsspielraum und damit ausreichend Möglichkeiten, spezifischen Risiken in einem agilen Projekt vertraglich zu adressieren und mit Regelungen solche Risiken adäquat aufzufangen.

Ausgangssituation

Seit Beginn des digitalen Zeitalters befindet sich unsere Gesellschaft in einem fortdauernden, ökonomischen Umbruch. Aufgrund seiner starken Auswirkungen auf den unternehmerischen Wettbewerb beauftragen die Teilnehmer zunehmend externe, hochspezialisierte Dienstleister mit der Entwicklung von innovativer Software, die durch einen hohen Grad der Anpassung an die eigenen Anforderungen besonders effizienzsteigernd in den eigenen Betrieb integriert werden können.

Die klassische Arbeitsmethode ist hierbei das sogenannte Wasserfallmodell, das sich durch eine klare Definitionen von Prozessen und umfassende Vertragsverhandlungen auszeichnet.[1] Das Ergebnis dieser Verhandlungen ist ein starrer Vertragsgegenstand, der sich aus detaillierten Anforderungskatalogen ergibt und eine isolierte, eigenständige Entwicklung durch den Auftragnehmer vorsieht. Die niedrige Erfolgsquote von Softwareentwicklungsprojekten[2] drängt die Parteien jedoch dazu, sich alternativen Gestaltungsmodellen zuzuwenden, die eine höhere Erfolgswahrscheinlichkeit versprechen und die Möglichkeit einer flexibleren, beiderseitigen Einflussnahme auf das Projekt bieten.

Ein alternatives Gestaltungsmodell ist hierbei die agile Arbeitsmethode, die lediglich eine grobe Skizze einer Produktvision vorsieht, einen offenen und dadurch veränderbaren Vertragsgegenstand hat und aufgrund dessen eine kontinuierliche Zusammenarbeit von Auftraggeber und Auftragnehmer erfordert.[3] Die Arbeit wird hierbei in kurzen inkrementellen Zyklen geleistet und setzt auf Interaktion, Teamwork und Vertrauen zwischen den Parteien. Durch das offene Vertragsziel und der intensiven Kooperation verheißt dieses Modell bessere Aussichten für die Fertigstellung des Projekts.[4]

Agile Softwareentwicklung

Agile Projekte stellen Unternehmer und Juristen aber auch vor neue Herausforderungen, sowohl in der Vertragsgestaltung, als auch in der Problemlösung. Für die adäquate Beratung und Entscheidungsfindung ist es unentbehrlich, sich mit den verschiedenen Modellen auseinanderzusetzen und dadurch nicht nur eine fachliche Kompetenz zu verwirklichen, sondern auch die Kommunikation durch konzeptionelles Verständnis zu verbessern.

Weiter zu Teil II: Risiken koventioneller Vertragsmodelle

[1] McManus/ Wood-Harper, Information Systems Project Management: Methods, Tools and Techniques, S. 77 ff.
[2] Buchermöhle/ Eekhoff/ Josko, Erfolgs- und Misserfolgsfaktoren bei der Durchführung von Hard- und Software-Entwicklungsprojekten in Deutschland.
[3] Beck, Manifesto for Agile Software Development.
[4] OOSE-Group, . o. Kirsch, Die werkvertragliche Abnahme bei agilen IT-Projekten, S. 1.

RA Bilal Abedin
Wiss. Mit. Burak Zurel


201605.09.

Hexagon kauft Apodius GmbH: Wir bedanken uns bei Alabon für die erfolgreiche Zusammenarbeit

Pressemitteilung der Alabon Business Developement GmbH vom 01.09.2016

Alabon berät die Aachener Apodius GmbH beim Verkauf an die Hexagon AB


Apodius wurde 2012 in Aachen gegründet und bietet Erstausrüstern (OEM) als auch Zulieferern in der Automobil-, Luft- und Raumfahrt- sowie Elektronik- und Hausgerätebranche Entwicklungs-, Produktions- und Integrationsleistungen für Messlösungen im Bereich faserverstärkter Kunststoffe.


Mit der Übernahme durch Hexagon AB sichert die Apodius GmbH für seine Kunden die messtechnische Weiterentwicklung der erfolgreichen AVS-Sensorfamilie sowie die weltweite Wachstumsstrategie. Das Tagesgeschäft bleibt dabei zur Gänze erhalten und wird global ausgebaut.


Die beiden Apodius-Geschäftsführer Alexander Leutner und Jonathan Roberz sind sich sicher: „Die Hexagon-Lösungen liefern hochpräzise Positionsdaten und passen daher perfekt zu unseren Sensoren. Darüber hinaus ist das Zusammengehen mit Hexagon eine großartige Gelegenheit, Verbundwerkstoff-Fertigungslinien weltweit mit unserer Technologie zu versorgen.


Der Spezialist für Unternehmernachfolge Alabon Business Developement GmbH war bei dieser Transaktion exklusiver M&A Berater der Apodius GmbH. Juristisch begleitet wurden die Vertragsverhandlungen durch die im internationalen IP/IT Recht erfahrene Kanzlei Abedin & Schwiering.

Weitere Informationen finden Sie auf der Internetseite der Apodius.

201602.06.

Aachen digitalisiert! Crowdfunding für Digital HUB Aachen erfolgreich

digihub_aspvrDie Initiative Aachen digitalisiert! schmiedet eine Koalition aus Wirtschaft, Wissenschaft und Politik, um eine „Aachen Area“ als digitales Innovationsland zu schaffen (siehe Blogartikel dazu). Am 01.06.2016 konnte die Initiative nun vermelden, dass die erforderlichen 1.5 Millionen Euro Eigenmittel eingesammelt und der Förderantrag für das digitalHUB beim Land NRW eingereicht wurde.

Unternehmen aus der Region Aachen bis Heinsberg, Düren und Euskirchen sowie dem Dreiländereck helfen mit ihren Zusagen, der Region Aachen einen Platz auf der digitalen Landkarte zu sichern. Mit dem digitalHUB, einem regionalen Digitalisierungszentrum, bewirbt sich die Initiative jetzt auf die öffentliche Ausschreibung des Landes NRW zu den „Digitale Wirtschaft NRW – Hubs“. Hier sollen bis zu fünf Regionen in NRW als Leuchttürme für Digitalisierung ausgelobt werden, die Kooperationen bei der Zusammenarbeit von digitalen Startups, Mittelstand und Industrie fördern. Voraussetzung dafür ist, dass die Regionen selbst ein Eigenkapital von 1,5 Millionen Euro aufbringen. Den Betrieb des Hubs unterstützt das Land NRW dann durch Aufstockung der Mittel auf insgesamt 3 Millionen Euro durch Fördermittel.

Neben der Region Aachen bewerben sich auch die Städte Düsseldorf, Köln, Bonn, Essen/Ruhrgebiet, Münster und Paderborn als Mitbewerber auf die Ausschreibung. Das Alleinstellungsmerkmal der Aachener Initiative ist dabei aber die breite Unterstützung aus allen Bereichen der Wirtschaft mit vielen Startups und Mittelständlern, sodass eine Digitalisierung von unten heraus – „bottom-up“ – getrieben wird.

201611.05.

Aachen digitalisiert! Wir sind dabei!

digihub_aspvrDie Initiative Aachen digitalisiert! schmiedet eine Koalition aus Wirtschaft, Wissenschaft und Politik, um eine „Aachen Area“ als digitales Innovationsland zu schaffen (siehe Blogartikel dazu).

Ziel der Initiative ist die Gründung des Vereins digitalHUB Aachen e.V., der nachhaltig zur Stärkung der Zukunftsfähigkeit der Region sowie der Förderung und Befähigung der Digitalisierung der Wirtschaft dienen soll. Durch eine Koalition aus regionaler Wirtschaft, Wissenschaft und Politik sollen im digitalHUB Aachen digitale Anwender aus Industrie und Wirtschaft (sog. User), Startups und IT-Mittelstand (sog. Enabler) sowie Region und Wissenschaft (sog. Supporter) an einem Ort zusammengebracht werden. Der HUB soll so konkrete Hilfe bei der Digitalisierung, der Ergänzung und Entwicklung digitaler Geschäftsmodelle und somit zur Verbesserung der Geschäftssituation führen.

Wir freuen uns das Projekt als Mitglied in den Rollen der Enabler und Supporter zu unterstützen und möchten Unternehmer aus der Region ermutigen, sich der Initiative ebenfalls anzuschließen.

Weitere Informationen erhalten Sie hier.

201511.03.

Lizenzverträge mit Großkunden verhandeln – aus der Beratungspraxis

Viele kleine und mittelständische Unternehmen sind stark abhängig von Aufträgen und Ausschreibungen, die von Großunternehmen vergeben werden. Gerade wenn es um IT- oder technologieverwandte Produkte geht, spielen hierbei Lizenzen eine zentrale Rolle. Es kann sich dabei sowohl um Softwarelizenzen als auch um Nutzungsrechte für urheberrechtlich, markenrechtlich oder patentrechtlich geschützte Werke handeln.

In Verhandlungen treten aus Anwaltssicht immer wieder die gleichen Fragestellungen auf. Großkunden versuchen in der Regel eine umfangreiche Übertragung von Nutzungsrechten aufzuzwingen. Hier gilt jedoch besondere Vorsicht, sowohl aus Sicht des Lieferanten als auch aus Sicht des Kunden. Denn was in anderen Bereichen selbstverständlich ist, ist hier oft nur auf den zweiten Blick als Problem zu erkennen: Man kann als Lieferant nicht mehr Rechte übertragen, als man selber hat.

Daher sollten aus Anwaltssicht immer dann die Alarmglocken läuten, wenn in einer Ausschreibung oder in einem Vertrag die Übertragung eines „ausschließlichen“ oder eines „inhaltlich unbeschränkten“ Nutzungsrechts gefordert wird.

Oft enthalten die eigenen Produkte nicht ausschließlich Eigenentwicklungen. Ein banales Beispiel hierfür sind Anbieter technischer Systeme und Anlagen. Regelmäßig beinhalten solche Produkte auch Standardsoftware von Dritten, zum Beispiel wenn es um Betriebssysteme, Datenbanken oder User-Interfaces geht.

Wenn der Kunde nun eine Übertragung einer Lizenz am finalisierten Endprodukt fordert, dann kann im Hinblick auf die enthaltene Drittanbietersoftware nur so viel an Nutzungsrechten übertragen werden, wie der Lieferant selbst von diesem Dritten erworben hat. Hier ist auch allgemein sicherzustellen, dass diese Nutzungsrechte überhaupt an den Kunden übertragen werden dürfen. Auch kann es sein, dass bei der Übertragung Besonderheiten aus den Lizenzbedingungen zu beachten sind.

Diese Grundsätze gelten nicht nur für Software sondern auch regelmäßig bei Hardware Produkten. Vom Mobiltelefon bis zur Industrieanlage enthalten technische Produkte in der Regel patentrechtlich geschützte Komponenten von Dritten. Hier ist gerade bei individuell maßgeschneiderten Produkten stets zu beachten, dass sämtliche Vorgaben und Lizenzbedingungen der ursprünglichen Rechteinhaber streng eingehalten werden müssen. Diese könnten zum Beispiel fordern, dass Produkte nur in einem bestimmten Kontext oder nur in einem begrenzten Umfang genutzt werden. Technologielizenzverträge in der Industrie bestimmen in der Regel unter anderem, was genau und wieviel mit der lizenzierten Technologie hergestellt oder bearbeitet werden darf. Hiervon kann die Lizenzgebühr abhängig sein.

In jedem Fall kann ein Lieferant nie mehr an Nutzungsrechten versprechen oder verschaffen, als er selber erworben hat. Daher muss, egal wie stark oder schwach die Verhandlungsposition des Lieferanten ist, dieser immer die Lizenzbedingungen genau prüfen und einen angemessenen Umfang vorgeben. Letztlich ist dies auch im Interesse des Kunden. Denn der Lieferant kann keine Rechte einräumen, die er nicht besitzt. Der Kunde muss sich aber darauf verlassen können, dass er den genauen Umfang seiner Nutzungsrechte kennt. Nur so kann sich auch der Kunde vor Ansprüchen Dritter schützen.