Die 10 wichtigsten rechtlichen Fragen bei Individualsoftware

Die 10 wichtigsten rechtlichen Fragen bei Individualsoftware

Nutzungsrechte am Quellcode, Vertragsgestaltung, DSGVO, AI-generierter Code – die rechtlichen Fragen vor einem Softwareprojekt sind mindestens so wichtig wie die technischen. Ein Überblick aus der Praxis, keine Rechtsberatung.

Vor jedem Softwareprojekt werden technische Fragen gründlich besprochen: Welche Funktionen brauchen wir? Welche Technologie setzen wir ein? Wie sieht der Zeitplan aus? Die rechtlichen Fragen kommen oft erst zur Sprache, wenn es zu spät ist. Etwa wenn nach Projektende unklar ist, wer den Quellcode nutzen darf. Oder wenn der Dienstleister insolvent wird und niemand an den Code herankommt.

Dieser Artikel beantwortet die zehn Fragen, die in unserer Projekterfahrung am häufigsten relevant sind. Er ersetzt keine Rechtsberatung, sondern gibt eine Orientierung auf Basis praktischer Erfahrung. Für Ihren konkreten Fall sollten Sie sich rechtlich beraten lassen.

1. Wem gehören die Nutzungsrechte am Quellcode?

Die Antwort hängt von der Vertragsform ab. Bei einem Werkvertrag schuldet der Dienstleister ein konkretes Ergebnis, und die Nutzungsrechte gehen in der Regel an den Auftraggeber über. Bei einem Dienstvertrag schuldet er Arbeitszeit, und die Rechte am Ergebnis bleiben ohne ausdrückliche Vereinbarung beim Ersteller.

Bei Software, die auf einem modularen Baukasten basiert, ist die Antwort differenzierter als bei reiner Individualentwicklung. Die Anwendung besteht typischerweise aus zwei Schichten, für die unterschiedliche Rechte gelten.

Die Plattform- und Baukasten-Module, also Benutzerverwaltung, Authentifizierung, Dashboard-Funktionen und ähnliche Basisfunktionalität, werden vom Dienstleister projektübergreifend eingesetzt und weiterentwickelt. Der Kunde erhält daran ein nicht-ausschließliches Nutzungsrecht. Er darf die Module nutzen, anpassen und betreiben, aber der Dienstleister behält das Recht, dieselben Module auch in anderen Projekten einzusetzen. Das ist vergleichbar mit einer Framework-Lizenz.

Die kundenspezifisch entwickelten Teile, also die individuelle Geschäftslogik und maßgeschneiderte Integrationen, werden ausschließlich für diesen einen Kunden gebaut. Hier ist ein ausschließliches Nutzungsrecht möglich, das dem Auftraggeber erlaubt, diesen Code zu verwenden, zu verändern und weiterzuentwickeln, auch durch Dritte. Individuelle Absprachen je nach Individualisierungsgrad sind aber typisch: Wenn eine Funktion nicht im Baukasten verfügbar ist, aber durchaus auch in diesen einfließen könnte, käme ein Preisnachlass mit einem nicht-ausschließliches Nutzungsrecht in Frage.

Bei uns erhalten Sie den vollständigen Quellcode beider Schichten und haben jederzeit vollen Zugriff auf Ihre Daten. Es gibt keinen Vendor Lock-in. Sie können die gesamte Anwendung selbst betreiben oder zu einem anderen Anbieter migrieren. Der Unterschied liegt nicht im Zugriff, sondern in den Verwertungsrechten: Die Plattform-Module dürfen wir für andere Kunden weiter nutzen, Ihren individuellen Code nicht.

2. Was sollte im Vertrag stehen?

Ein Software-Entwicklungsvertrag sollte mindestens die folgenden Punkte regeln: den Leistungsumfang (Was wird gebaut?), die Abnahmekriterien (Wann gilt das Projekt als abgeschlossen?), das Vergütungsmodell (Festpreis, Time & Material oder eine Mischform), die Nutzungsrechte am Ergebnis, die Gewährleistung und Haftung, Regelungen zu Vertraulichkeit und Datenschutz sowie den Umgang mit Änderungen am Leistungsumfang.

Die Beschreibung des Leistungsumfangs kann unterschiedliche Formen annehmen. Ein klassisches Pflichtenheft definiert Funktionen detailliert vorab. User Stories beschreiben das gewünschte Verhalten aus Nutzersicht. In der Praxis hat sich eine Kombination bewährt: Ein übergreifendes Dokument, das den Scope und die Kernfunktionen beschreibt, ergänzt durch User Stories, die in der Entwurfsphase konkretisiert werden.

3. Wie bildet man agile Entwicklung vertraglich ab?

Agile Entwicklung und klassische Werkverträge passen nicht gut zusammen. Ein Werkvertrag setzt voraus, dass das Ergebnis bei Vertragsschluss definiert ist. Agile Entwicklung lebt davon, dass sich Anforderungen im Projektverlauf verändern und präzisieren.

Ein bewährtes Modell ist ein Rahmenvertrag plus Sprint-Vereinbarungen. Der Rahmenvertrag regelt die allgemeinen Bedingungen: Stundensätze, Nutzungsrechte, Vertraulichkeit, Haftung. Die Sprint-Vereinbarungen definieren jeweils den Scope für den nächsten Entwicklungszyklus. So hat der Auftraggeber nach jedem Sprint ein abgenommenes Teilergebnis und kann entscheiden, ob und wie es weitergeht.

4. Was passiert bei Insolvenz des Entwicklers?

Eine berechtigte Sorge, insbesondere bei kleineren Dienstleistern. Die klassische Absicherung ist eine Quellcode-Hinterlegung (Escrow): Der aktuelle Quellcode wird regelmäßig bei einem neutralen Treuhänder hinterlegt und im Insolvenzfall an den Auftraggeber herausgegeben.

Eine einfachere Lösung ergibt sich, wenn der Auftraggeber den Quellcode ohnehin laufend erhält. Wenn die Codebasis in einem Repository liegt, auf das der Kunde Zugriff hat, ist ein Escrow-Verfahren überflüssig. Bei Prowedo ist das der Standard: Der Kunde hat jederzeit vollen Zugriff auf den Quellcode.

Bei Baukasten-Software ist ein zusätzlicher Punkt relevant: Die nicht-ausschließliche Lizenz für die Plattform-Module sollte vertraglich als insolvenzfest vereinbart sein. Der Kunde muss die Anwendung auch dann weiterbetreiben und warten können, wenn der Dienstleister nicht mehr existiert.

5. Wie sichert man sich bei Verzögerungen ab?

Verzögerungen in Softwareprojekten sind häufig, und ihre Ursachen liegen nicht immer beim Dienstleister. Fehlende Zuarbeit auf Kundenseite, verspätete Entscheidungen oder nachträgliche Anforderungsänderungen tragen ebenso dazu bei.

Vertragliche Instrumente zur Absicherung sind Meilensteine mit definierten Terminen, Pönalklauseln bei Überschreitung und Eskalationsmechanismen. In der Praxis sind transparente Sprint-Reviews und regelmäßige Budget-Checks oft wirksamer als Vertragsklauseln, weil sie Probleme sichtbar machen, bevor sie eskalieren. Der Artikel Ihr Softwareprojekt: So läuft es ab beschreibt diesen Prozess im Detail.

6. Was muss die Software in Bezug auf die DSGVO können?

Software, die personenbezogene Daten verarbeitet, muss den Grundsatz Privacy by Design umsetzen. Das bedeutet, dass Datenschutzanforderungen nicht nachträglich ergänzt werden, sondern von Beginn an in die Architektur einfließen. Konkret betrifft das die Möglichkeit, Daten zu löschen oder zu anonymisieren (Recht auf Löschung), die Fähigkeit, personenbezogene Daten in einem maschinenlesbaren Format zu exportieren (Datenportabilität), eine saubere Rechte- und Rollenverwaltung, die den Zugriff auf personenbezogene Daten einschränkt, und die Protokollierung von Zugriffen auf sensible Daten.

Wenn der Dienstleister im Rahmen des Projekts Zugriff auf personenbezogene Daten hat, ist in der Regel ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO erforderlich. Dieser regelt, welche Daten verarbeitet werden, zu welchem Zweck und welche Schutzmaßnahmen der Dienstleister ergreift.

7. Brauche ich eine formale Abnahme?

Eine formale Abnahme schützt beide Seiten und ist dringend zu empfehlen. Für den Auftraggeber bestätigt sie, dass das Gelieferte den Anforderungen entspricht. Für den Dienstleister markiert sie den Zeitpunkt, ab dem die Gewährleistung beginnt und die Schlusszahlung fällig wird.

Ohne formale Abnahme bleibt unklar, wann das Projekt abgeschlossen ist. Das führt häufig dazu, dass der Dienstleister immer weitere Nacharbeiten durchführt, ohne dass eine Grenze definiert ist, oder dass der Auftraggeber nach Monaten Mängel reklamiert, die bei einer strukturierten Abnahme aufgefallen wären.

In agilen Projekten bietet sich eine Abnahme pro Sprint an. Jedes Teilergebnis wird formal abgenommen, bevor der nächste Sprint beginnt. So entsteht keine große Abnahmehürde am Ende des Projekts.

8. Was kostet Wartung, und was ist darin enthalten?

Wartung umfasst typischerweise Fehlerbehebung, Sicherheitsupdates, Anpassungen an neue Systemumgebungen und kleinere Funktionserweiterungen. Branchenüblich liegen die Kosten bei 10 bis 15 Prozent der ursprünglichen Entwicklungskosten pro Jahr.

Ein Wartungsvertrag sollte die folgenden Punkte regeln: den Umfang der enthaltenen Leistungen (Was ist Wartung, was ist Weiterentwicklung?), die Reaktionszeiten bei Störungen (SLA), die Verfügbarkeit des Supports und die Laufzeit und Kündigungsfristen.

Bei Prowedo ist die Wartung im Fixpreis enthalten, wenn die Anwendung über unser Hosting läuft. Dieses Paket umfasst Security-Patches, PHP-Updates, Backups und den laufenden Betrieb in deutschen Rechenzentren. Weiterentwicklungen, also neue Funktionen oder größere Anpassungen, werden separat vereinbart und berechnet.

9. Darf der Entwickler das Projekt als Referenz nutzen?

Das hängt von der vertraglichen Vereinbarung ab. Ohne ausdrückliche Regelung gibt es keine generelle Erlaubnis, ein Kundenprojekt als Referenz zu verwenden. Umgekehrt gibt es auch kein automatisches Verbot.

Eine sinnvolle Regelung liegt in der Mitte: Der Dienstleister darf den Kunden und die Art des Projekts nennen, zeigt aber keine Screenshots, keine technischen Details und keine vertraulichen Informationen. Diese Regelung sollte explizit im Vertrag stehen, zusammen mit dem Recht des Auftraggebers, die Verwendung als Referenz jederzeit zu widerrufen.

10. Was gilt für AI-generierten Code?

Die Frage, wem AI-generierter Code gehört, ist juristisch noch nicht abschließend geklärt. Das deutsche Urheberrecht setzt eine persönliche geistige Schöpfung voraus. Code, der von einer KI erzeugt wurde, erfüllt dieses Kriterium möglicherweise nicht, was bedeuten könnte, dass er nicht urheberrechtlich geschützt ist.

In der Praxis stellt sich die Frage differenzierter. AI-gestützte Entwicklung, wie wir sie einsetzen, bedeutet nicht, dass eine KI das gesamte Programm eigenständig schreibt. Der Entwickler formuliert Anforderungen, steuert die Architektur, überprüft und überarbeitet den generierten Code. Das Ergebnis ist ein Werk, das durch menschliche Auswahl, Anordnung und Korrektur geprägt ist, auch wenn Teile maschinell erzeugt wurden.

Eine pragmatische vertragliche Regelung legt fest, dass der Auftraggeber unabhängig von der Entstehungsweise die Nutzungsrechte am gelieferten Code erhält, also ausschließliche Rechte am kundenspezifischen Code und nicht-ausschließliche an den Plattform-Modulen, wie in Frage 1 beschrieben. Das umgeht die offene Urheberrechtsfrage und schafft für beide Seiten Klarheit.

Checkliste: Fünf Punkte vor Projektstart

Bevor ein Softwareprojekt beginnt, sollten mindestens diese fünf Punkte geklärt sein.

Erstens, die Nutzungsrechte am Quellcode. Wer bekommt den Code, wer darf ihn verändern, wer darf ihn weitergeben? Zweitens, die Vertragsform. Werkvertrag, Dienstvertrag oder Rahmenvertrag mit Sprint-Vereinbarungen? Drittens, der Umgang mit Änderungen. Wie werden neue Anforderungen bewertet und abgerechnet? Viertens, die Wartungsvereinbarung. Was ist enthalten, was kostet es, wie lange läuft der Vertrag? Fünftens, der Datenschutz. Ist ein AVV erforderlich, und sind Privacy-by-Design-Anforderungen in der Spezifikation berücksichtigt?

Fazit

Rechtliche Fragen sind kein Anhang zum Projektvertrag, den man am Ende noch schnell klärt. Sie sind Teil der Projektplanung und sollten vor dem ersten Sprint geregelt sein. Wer die zehn Fragen in diesem Artikel für sich beantwortet hat, ist gut vorbereitet.

Zum konkreten Projektablauf und zur Kostenkontrolle während der Entwicklung finden Sie Orientierung im Artikel Ihr Softwareprojekt: So läuft es ab und so bleiben die Kosten im Griff. Einen Überblick über Preisrahmen und Kostentreiber bietet der Artikel Was kostet Individualsoftware?.

Bei Prowedo klären wir diese Fragen in jedem Projekt von Anfang an. Wenn Sie ein Projekt planen und sich vorab orientieren möchten, sprechen Sie mit uns.