Quellcode dem Auftraggeber herausgeben? Wie...?

[Luckie]

Projektordner zippen und übergeben. Ind er Doku schreiben welche Fermdkomponenten und in welcher Version benötigt werden zum kompilieren und fertig. Alles weiter ist Problem des Auftraggebers.

[Perlsau]

Genau so mache ich das auch ... mit dem Hinweis, daß er vermutlich nichts damit anfangen kann und ein anderer Delphi-Entwickler etliches an Mühe und Zeit, die bezahlt werden wollen, investieren müßte, um sich in den Code einzuarbeiten. Wenn's den Kunden glücklich macht, kein Problem. Probleme hab ich allerdings mit Auftraggebern, die selbst in Delphi programmieren und vor dem Bezahlen der letzten Rechnung plötzlich den Quellcode verlangen ... und dann mit der Begründung, der Auftragnehmer würde die Mitarbeit verweigern, plötzlich nichts mehr zahlen ... nattürlich erst, nachdem sie den Quellcode bekommen haben, so nach dem Motto: "Den Rest kann ich auch selber fertigstellen, das kommt billiger, als den zu bezahlen. Der hat ja eh kein Geld für Prozeßkosten, da hab ich nichts zu befürchten". Und vorher einen auf nett und freundlich und verständnisvoll machen ... und am besten gleich duzen, das schafft Vertrauen ... aber das ist eine, nein das sind mehrere andere Geschichten ...

[MrSpock]

Ich packe auch den Quellcode in ein Archiv und schreibe dazu, welche Delphi Version ich benutzt habe und welche Fremdkomponenten.

[Captnemo]

Das der Source ausgehändigt und die Quellen der eingesetzten Fremdkomponenten genannt, bzw. schriftlich hinterlegt werden können, ist ja keine Schwierigkeit und sollte auch bei entsprechden Auftragsarbeiten möglich sein. Schließlich wird dieses auch in den Auftragsbedingungen vorher so festgelegt und ist somit auch Bestandteil der Lieferung.

Es gibt nur 3 Punkte an denen es etwas schwierig wird:
1. Einsatz von eigenen Komponenten, die nicht erst zum Zweck der Erfüllung des Auftrags erstellt wurden und somit nicht Bestandteil des Auftrags sind, die aber nicht öffentlich sind und auch nicht als Komponenten im Markt erhältlich sind.

Da kann es schnell zum Steitpunkt kommen. Wenn nun der Auftraggeber sich im Streit mit dem Auftragnehmer trennt, kann der Auftragnehmen auf diese Fremdkomponenten nicht verzichten und will für diese ggf. auch nicht noch bezahlen, der Auftragnehmen will diese aber nicht mehr zur Verfügung stellen oder sehr viel Geld dafür haben.

2. Einsatz von zugekauften Komponenten, die der Auftragnehmer bereits vor dem Auftrag im Bezitz und/oder in Verwendung hatte, die aber ggf. vom Aufgraggeber im Handel käuflich erworben werden können. Hier ist eine Weitergabe nicht ohne weiteres möglich. Und im Falle, dass auf Auftraggeber und Auftragnehmen auseinander gehen, wieder ein Kostenfaktor für Auftraggeber, der so nicht bestandteil des Auftrags war.

3. Einsatz einer zugekauften Komponente, die nach Abschluss des Auftrags und Trennung von Auftaggeber und Auftragnehmer auch nicht mehr im Handel zur Verfügung steht (vlt. weil der Anbieter diese zurückgezogen hat, oder aus welchem Grund auch immer)

Das sind alles Punkte, die es VOR Auftragserteilung zu klären gilt, und die im Vertrag auch schriftlich eindeutig definiert sein sollten.

Zur Weitergabe der Lizenz: So kann man, je nach Projektgröße, auch vereinbaren, dass alle Lizenzen vom Auftraggeber angeschafft und dem Entwickler zur Verfügung gestellt werden müssen.
So kann eine Delphi-Lizenz (muss möglichweise nicht unbeding Architect sein), ein Windows-Lizenz und auch alle Lizenzen von verwendeten Fremdkomponenten beim Kunden hinterlegt werden, so dass diese zur Weiterentwicklung durch einen anderen Auftragnehmer ebenfalls zur Verfügung stehen.
Die zum Projekt erstellen, neuen Komponenten sind eigentlich Bestandteil des Projekts und gehören auch zu diesem. Aber auch das kann man vorher vereinbaren.
Bei den verwendeten eigenen Komponenten, die bereit in der Bibliothek des Auftragnehmers waren, muss natürlich eine gesonderte Vereinbarung getroffen werden.

Wenn es einen Vertrag und / oder eine Auftragbetätigung gibt, die entsprechende Detailiert alle notwenigen Parameter festlegt, dann sollte während und nach dem Auftrag auch zu keinen Mißverständnissen kommen. Wer ohne oder nur mit sehr oberflächlichen Verträgen/Auftragsbestätigungen arbeitet, der muss im schlimmsten Fall auch mit Verlusten rechnen.

Ein kleines Beispiel aus einer anderen Branche: Jeder von euch bringt sein Auto auch regelmäßig in die Werkstatt. Hier wird meist nur mündlich die notwendigen Arbeiten besprochen. Es gibt immer noch Werkstätten, die auf eine Auftragsbestätigung verzichten, oder aber, wenn nach durchsicht doch weitere Mängel auftauchen, sich auch diese Arbeiten vom Kunden als Auftrag unterschreiben lassen. Das geht zu 99% auch immer gut. Aber in den Fällen, in denen dann der Kunden die Bezahlung der nicht im Auftrag aufgeführten Leistungen verweigert, endet es vor Gericht oft so, dass die Werkstatt das nachsehen hat. Denn der Beweiß, dass der Kunde den Reparaturen mündlich zugestimmt hat, ist fast immer nicht zu erbringen.

[himitsu]

Zitat von MrSpock:

Ich packe auch den Quellcode in ein Archiv und schreibe dazu, welche Delphi Version ich benutzt habe und welche Fremdkomponenten.

Noch ein bissl Obfuscation .... ähhh, ein eigenartiger Programmierstil ... und schon isses egal, ob die den Code haben, oder nicht.

Vielleicht gibt es auch noch einen Codedeformatter mit Derefactoring, falls man das selber nicht hinbekommt.



Und die wollen doch "nur" den Quellcode? Oder warum reden hier Viele gleich von einem voll funktionsfähigem Entwicklungssystem?

[mensch72]

Zitat von himitsu:

Und die wollen doch "nur" den Quellcode? Oder warum reden hier Viele gleich von einem voll funktionsfähigem Entwicklungssystem?

Weil ein Quellcode ohne Entwicklungssystem auf einem bestimmten Konfigurationsstand kaum etwas nützt. Ich sichere ja selbst deshalb immer die Quelltexte samt des dazu passenden Entwicklungssystem als VM, weil es das einfachste ist und eh schon die ganze Zeit so per VM entwickelt wurde.

Wenn ich samt Firma nicht mehr da bin, sind die Lizenzkosten für denjenigen der in diesem Fall vom Notar die BackupVMs bekommt das kleinere Problem. Wenn es nur um einen Streifall geht und ein Gutachter die VM nur als Beweis das es so damals geliefert wurde benutzt, sind die Lizenzen wurscht, weil ja in dem Fall das Realsystem noch bei mir lizensiert läuft.

Wenn ein Kunde von Anfang an Source will, dann beschafft und stellt auch der Kunde das Entwicklungssystem mit allen Komponenten(meist auch als/auf Notebook, weil ich ja teils auch nicht alle Komponenten selbst als Lizenz besitze) und hat dies zusätzlich bei sich im Haus per Remote/SVN auf aktuellem Stand.

[Dejan Vu]

Bei einigen Kommentaren denke ich mir immer, das der Kunde als Feind behandelt wird, der einem Böses will.

Im Werkvertrag war es -zumindest früher- Usus, den Quelltext für den Kunden unter bestimmten Voraussetzungen zugänglich zu machen. Nämlich wenn.

• Der Auftragnehmer verstirbt, insolvent ist oder aus sonstigen Gründen seinen Pflichten nicht nachkommen kann.
• Der Auftragnehmer zu teuer wird (i.a. >20% der ortsüblichen Bezahlung, Wucher)
• Die vertraglich vereinbarte Wartung vom Auftragnehmer nicht entsprechend durchgeführt wird
• Der Auftragnehmer die Wartung und Pflege des Werkes nicht durch- bzw. fortführen will.

Die Rechtsprechung ging in eine einfache Richtung:
Auftraggeber und Auftragnehmer sind voneinander abhängig. Der Kunde (also AG) bekommt ein Werk, das mit vertretbarem Aufwand nur vom AN zu pflegen und weiterzuentwickeln ist. Der AN hat also ein Quasimonopol, aber das dar er nicht ausnutzen, indem er etwa überhöhte Preise verlangt. Er ist i.d.R. auch verpflichtet, das Werk zu pflegen (gegen Entgelt). Im Gegenzug hat der AG sein internes Firmenwissen zur Verfügung gestellt. I.d.R. besteht das Werk zwar aus Code, enthält aber genau dieses Wissen. Und insofern ist der Quellcode zumindest intellektuelles Eigentum des Kunden.

Ich finde es auch einfach nur fair, wenn ich dem Kunden im Extremfall (s.o.) Zugriff auf den Quellcode ermögliche. Vorher ist das vollkommen überflüssig, da ich ja partnerschaftlich meinen Pflichten nachkomme.

Und damit hier keine Zeifel aufkommen, kann man eben Escrow verwenden, wobei das mit dem Nachziehen der jeweils aktuellen Version so eine Sache ist.

[jfheins]

Noch eine Lösung von mir. Ich habe das Angebot ungefähr folgendermaßen formuliert:

Zitat:

Der Entwickler gewährt dem Kunden das vollständige, nicht-exklusive Verwertungsrecht an der geschaffenen
Software. Die Software wird unter der MIT-Lizenz entwickelt, der Quellcode wird dem Kunden vollständig
und uneingeschränkt in Originalform zur Verfügung gestellt.

Letzteres passiert dann in Form eines lokalen git-Repository wo das passende (öffentliche) GitHub-Repo als origin bereits eingestellt ist.

Der Kunde hat damit den Quelltext und kann quasi jederzeit jemand anderen (oder einen Internen) mit der Weiterentwicklung beauftragen. Allerdings kenne ich mich bereits mit dem Projekt aus und kann dementsprechend günstige Angebote machen.

[Der schöne Günther]

Zitat von Dejan Vu:

Bei einigen Kommentaren denke ich mir immer, das der Kunde als Feind behandelt wird, der einem Böses will.

Das dachte ich mir hier stellenweise auch, aber:

Zitat von Dejan Vu:

Die Rechtsprechung ging in eine einfache Richtung:

Das ist aber jetzt stark an die BRD gekoppelt, oder? Ich glaube schon innerhalb der EU kann man da genug Abenteuer erleben, ganz zu schweigen außerhalb!

Aber vielleicht geht es nur bei mir in der Branche schon fast wie bei mittelalterlichen Viehmärkten statt nach der sauberen Theorie was ich zu Vertragsrecht gelernt habe zu

[mquadrat]

Bei uns kann der Quelltext (auch unserer Std-Produkte) auf Kundenwunsch bei einem Escrow-Dienst oder Notar hinterlegt werden. Kosten trägt der Kunde. Bei Individualentwicklungen wird dem Kunden oft auch das Recht der Modifikation eingeräumt, aber der Verkauf bzw. die Nutzung für eine andere juristische Person als unseren Vertragspartner untersagt. Gezogen hat die Option aber bis jetzt fast keiner. Das ist ja mehr für das gute Gefühl des Kunden und einen Haken in der Spalte Risk-Management.

Wir sitzen aber auch an der anderen Seite des Tisches. Sprich wir stellen für Kunden sicher, dass die hinterlegten Daten tatsächlich im versprochenen Umfang vorliegen und entsprechend der beigelegten Dokumentation nutzbar sind.