Eigene Routinensammlung ohne Quellcode

[OlafSt]

Hallo Freunde,

ich bin noch neu auf dem Gebiet der Software-Entwicklung in "eigener Klitsche". Nun stellt sich mir hier ein kleines Problem.

Ich programmiere schon 30 Jahre und natürlich haben sich dabei eine ganze Menge netter Routinen angesammelt, die man in- und auswendig kennt und quasi wie Sprachelemente mitbenutzt. Natürlich werden diese Routinen immer wieder auf ihren Nutzen überprüft und wachsen mit den Compilergenerationen mit.

Nun habe ich hier ein Projekt abzuwickeln, das einen erheblichen Nutzen aus diesen Routinen zieht. Kopfschmerzen macht mir dabei aber der vertragliche Passus "Übergabe des Quellcodes". Denn natürlich will ich nicht, das mein Know-How das Unternehmen verläßt. Der Kunde wiederum besteht darauf, "jederzeit sein Programm selbst übersetzen zu können".

Nun... Das ließe sich machen, indem ich ihm einfach einen Satz DCUs mitgebe (jeweils für Win32/64 und Debug/Release). Dann kann er kompilieren, so viel er will. Paßt dem Kunden natürlich nicht, er besteht auf Quelltexten.

Wie formuliere ich in einem Werkvertrag, das diese Sourcen nicht Bestandteil des Projektes sind (die VCL-Sourcen oder .NET-Sourcen bekommt er ja auch nicht) ?

Danke für die Hilfe,

Olaf

[Union]

Mach eine zweite Firma auf von der Du diese Libraries bzw. Komponenten lizensierst.

[Bernhard Geyer]

Wenn er Quellcode will dann musst du:

1, Deinen Preis erhöhen
2, Einen Passus schreiben das er nur die Sourcen Hausintern verwenden darf und keine Recht erhält die Sourcen weiterzukaufen. Ähnlich wie es auch die Komponentenhersteller wie LMD und Co. machen.


Oder notfalls einfach den Auftrag ablehnen.

Aber google einfach mal nach "Werkvertrag Quellcode". Du bist nicht der erste.

[Bernhard Geyer]

Zitat:

Zitat von Union (Beitrag 1250172)

Mach eine zweite Firma auf von der Du diese Libraries bzw. Komponenten lizensierst.

Bringt nix. Dann wird der Kunde das nur annehmen wenn die zweite Firma ihm auch eine Lizenz mit Quellcode anbietet.

[Sir Rufo]

Eine weitere Alternative ist es den Quellcode bei einem Treuhänder zu hinterlegen.
Die Häufigkeit (jede Version oder jedes Major-Release) bestimmt der Kunde, trägt dafür aber auch die Kosten.

Wann der Kunde auf diese Quellen zugreifen darf ist dann in dem Treuhandvertrag geregelt.

[OlafSt]

Das war ein sehr interessanter Ausflug in das Chaos, das unsere Bundesregierung mit neuen Technologien (und 1970 waren das neue Technologien, auch wenn das erst 1993 im Gesetz gelandet ist) so anrichtet.

Ich sehe da für meinen Fall nur 3 Optionen:

1. Kunde akzeptiert den Passus im Vertrag, das Teile der Software mit Bibliotheken erstellt werden, die nicht im Rahmen dieses Werkvertrags erzeugt wurden und somit nicht direkter Bestandteil der Quellcodes sind
2. Ich entwickle die ganzen Routinen noch einmal, aber diesmal im Rahmen des Vertrages. Das wird natürlich die Kosten nicht zu knapp erhöhen
3. Der Auftrag wird abgelehnt

Danke für den Schubser in die richtige Richtung !

[jaenicke]

Ein wichtiger Aspekt ist dabei ja auch, dass die kompilierten Units nur mit exakt der passenden Delphiversion nutzbar sind. Insofern sind die nicht viel wert, wenn man diese später mal für Weiterentwicklungen benötigt.

Deshalb kaufen wir Komponenten usw. auch ausschließlich mit komplettem Quelltext.

[himitsu]

Man könnte die Funktionen aber auch als kompilierte DLL oder via ActiveX-Komponente mitliefern, inkl. einer Schnittstellendefinition, bzw. einer PAS für die importierten Funktionen.
Da gibt es das Compilerproblem dann nicht mehr.

Da diese Funktionennicht diret zum Programm gehören, kannst du versuchen die auch extra zu verkaufen.
entweder die bekommen (fast) gratis nur die DCUs oder sie kaufen deren Quellcode halt extra. (ohne Erlaubnis den weiterzugeben usw.)
Ersteres mit der Option später immernoch die Quellcodes zu kaufen oder gegen bissl Geld eine "aktuelle" Version der DCUs zu erhalten.

[Furtbichler]

Dein Kunde handelt sehr umsichtig und hat eine berechtigte Forderung, im Extremfall von Dir unabhängig zu sein: Es ist üblich (und imho zwingend), Quellcode zusammen mit dem Werk auszuliefern. Der Kunde muss in der Lage sein, das Werk auch Dich, den Ersteller weiter zu verwenden. Normalerweise würde Der Quellcode bei einem Notar (oder escrow) hinterlegt und im Falle von Streitigkeiten (Du nutzt dein Exklusivwissen und forderst überhöhte Preise, gehst Pleite, stirbst, gewinnst im Lotto etc.) herausgegeben. Dein Kunde wäre total am Arm, wenn Du nicht mehr zur Verfügung stündest. Um hier Kosten zu sparen, kann man das Zeugs aber auch dem Kunden in die Hand drücken.

Da im Quellcode normalerweise das Kundenwissen verankert ist, hat er auch ein Recht auf die Exklusivität des Quelltextes. D.h. Du bist zwar Urheber, aber Eigentümer des Quelltextes ist der Kunde, denn Du hast das Werk in seinem Auftrag erstellt. Maßgeblich ist hier, dass das Programm wirklich eine Exklusivarbeit ist (Ein angepasstes Standardprodukt ist kein Werk). Wäre denkbar, das ihr etwas anderes vereinbart habt, aber da dies zum Schaden des Kunden wäre, wäre dies anfechtbar.

Was Du nicht darfst: Code in deine Bibliothek übernehmen, wenn dieser im Rahmen des Auftrages erstellt wurde oder Kundenwissen beinhaltet (Formeln, Prozesse o.ä.). Weiterhin darfst Du Code nicht zurückhalten, denn es ist nun mal nicht deiner.

Was Du darfst: Dein Eigentum behalten, also deine Toolsammlung, die es (nachweislich!) schon vorher gab. Das ist deins. Du kannst diesen Quellcode zusammen mit dem Werk ausliefern, und sofern die einschlägigen Copyrightvermerke im Code hinterlegt sind, ist damit alles gesagt.

Eure Geschäftsbeziehung basiert auf Vertrauen, denn der Kunde vertraut Dir, das Du das Kundenwissen nicht an die Konkurrenz verkaufst und Du vertraust dem Kunden, das er deinen Quelltext nicht unter der Hand weitervertickt. Beides ist durch entsprechende Vertragsklauseln zu vereinbaren.

Um es auf den Punkt zu bringen: Dein Kunde muss in der Lage sein, das Produkt/Werk ohne dich weiterzuentwickeln. Wie er das schafft, ist zu klären. Er bekommt ja schließlich die VCL-Quelltexte auch nicht von Dir. Eigentlich ist das eine sehr einfache Geschichte. Man muss sich nur einigen. Und das geht nur dann, wenn man sein Gegenüber versteht.

[OlafSt]

Die Idee mit einer DLL ist interessant, die behalte ich mal im Auge.

@Furtbichler: Ich verstehe, worauf du hinaus willst. Denselben Gedankengang habe ich auch gemacht, als ich mich auf Kundenseite "geschlagen" habe und einfach mal so tat, als wäre ich der Kunde. Der Kunde kommt in meinem Fall auch immer wieder mit dem Totschlag-Argument "was ist, wenn du dich mal um nen Baum wickelst". Dafür IST Sorge getragen, abgesichert mit mehreren Ebenen. Er ist nicht der erste Kunde, der damit kommt, aber der einzige, der sich so anstellt. Selbst ein Großkonzern war mit meiner Absicherung zufrieden...

Fakt ist, das die Toolsammlung komplett außerhalb jedes bisherigen Angestelltenverhältnisses und auch außerhalb jeglicher Auftragsarbeit entstand. Sie ist also zu 100% "mein Mist". Somit ist dieser Programm-Code nicht im Zusammenhang mit dem Auftrag entstanden und ist nicht dem Auslieferungszwang unterworfen. Mit dem Ausliefern der Sourcen im Rahmen des Auftrags habe ich auch überhaupt kein Problem, nur eben diese Toolsammlung will ich nicht mitgeben.

[ASM]

Zitat:

Zitat von Furtbichler (Beitrag 1250186)

Eigentlich ist das eine sehr einfache Geschichte.

Aber nicht derart und keinesweg so einfach, wie Du das hier erklärst. Die - auch vom BGH bestätigte - Rechtsprechung sieht erheblich anders.

Zitat:

Zitat von Furtbichler (Beitrag 1250186)

Man muss sich nur einigen. Und das geht nur dann, wenn man sein Gegenüber versteht.

Sicherlich und wünschenswert, steht aber auf einem ganz anderen Blatt.

[sx2008]

Du kannst dir auch mal die Frage stellen: ist die Toolsammlung für irgendjemand (ausser dir) eigentlich von besonderem Wert?
Also meine Toolsammlung unfasst ca 100 Units aus allen möglichen Bereichen (Mathematik, Stringverarbeitung, Internet, Netzwerke, XML, Datenbanken, Excel, Barcodes, ...).
Für mich ist diese Sammlung sehr nützlich denn wiederkehrende Aufgaben lassen sich damit schnell lösen - insbesondere deshalb weil ich genau weiß welche Units, Klassen und Funktion ich wie verwenden muss.
Für eine 3. Person wäre der Wert relativ gering.
Gut, er könnte ein Paar Rosinen rauspicken, aber Geld verdienen/sparen kann er damit nicht.
Im Übrigen habe ich schon einigen Code (insbesondere Stringverarbeitung) in die Tonne geworfen weil ich Äquivalentes oder Besseres in der Jedi Code Library gefunden habe.

Wenn in deiner Toolsammlung kein Code enthalten ist der wirklich einzigartig ist dann würde ich den Code einfach mitgeben.

[himitsu]

Zitat:

Zitat von Furtbichler (Beitrag 1250186)

Um es auf den Punkt zu bringen: Dein Kunde muss in der Lage sein, das Produkt/Werk ohne dich weiterzuentwickeln.

Delphi-Quellcode:

Müssen

muss hier niemand was.
Es kommt aber auf den Vertrag drauf an.

Wenn ich mir MS Office kaufe, dann doch auch ohne Quellcode.

Wenn man jemandem ein Programm schreibt, dann kann es auch ohne Quellcode sein.
Genauso kann man auch viele Delphi-Komponenten oftmals auch mit oder ohne Quellcode kaufen.

[Perlsau]

Ich würde mir hier ganz einfach folgende Fragen stellen:

1. Schade ich mir selbst, wenn ich den Code meiner Tool-Units mitliefere?

Ich könnte mir jetzt auf Anhieb kein glaubwürdiges Schadens-Szenario vorstellen.

2. Wie würde ein solcher Schaden aussehen?

Ein Schaden könnte mir ja nur dann entstehen, wenn mir jemand aufgrund dieser Toolsammlung Kunden wegschnappt, an denen sonst ich selbst verdient hätte. Ist aber eher unwahrscheinlich ...

3. Was würde ich ohne diese Tool-Units tun?

Ich würde die benötigten Methoden immer wieder neu progammieren müssen.

4. Wie sieht der Nutzen aus, den mir die Verfügbarkeit über meine Toolsammlung verschafft?

Ich muß bereits entwickelte Methoden, die ich immer wieder benötige, nicht ständig neu programmieren und spare dadurch Zeit, die ich dem Kunden dennoch berechnen kann, da ja diese bereits vor der Auftragserteilung entwickelten Methoden auch Zeit und Aufwand gekostet haben, die ich dem Kunden natürlich nicht schenken will. Oder ich berechne diese Zeiten nicht und erlange dadurch eventuell einen Wettbewerbsvorteil, da ich schneller entwickle als meine Konkurrenten, die vielleicht keine solche Sammlung besitzen.

[himitsu]

Zitat:

Zitat von OlafSt (Beitrag 1250194)

Fakt ist, das die Toolsammlung komplett außerhalb jedes bisherigen Angestelltenverhältnisses und auch außerhalb jeglicher Auftragsarbeit entstand..

Angestelltenverhältnisses?

Wobei man das eigentlich besser vorher hätte reggeln müssen.
Du hättets das Projekt ja auch ohne diese Routinen entwickeln können (dauert womöglich länger) oder es hätte hallt geregelt werden müssen, wie das mit diesen Routinen dann aussieht, also ob die mitgekauft werden oder nicht.

[Perlsau]

Zitat:

Zitat von himitsu (Beitrag 1250217)

Wenn man jemandem ein Programm schreibt, dann kann es auch ohne Quellcode sein.

Sehe ich auch so: Bislang haben fast alle Endkunden, die ich mit Anwendungen beglücken durfte, weder Quellcode von mir erworben noch erhalten (mit einer Ausnahme, dem hab ich meinen Quellcode quasi nachträglich geschenkt). Das waren ja auch keine Programmierer, sondern sozusagen Endverbraucher. Was anderes ist es, wenn ich für einen anderen Programmierer arbeite, dann macht das natürlich nur Sinn, wenn ich ihm den Quellcode, den ich in seinem Auftrag entwickelt habe, überlasse.

[BUG]

Wenn du Kompromisse suchst:
Der Kunde könnte vermutlich etwas mit einer genauen Dokumentation der nicht ausgelieferten Funktionen und ausführlichen Testfällen anfangen. Du gibst nicht den Code heraus, aber eine Beschreibung wie die Funktionen im Programm verwendet werden und eine genaue Beschreibung (Prosa + Tests). Damit könnte ein anderer Entwickler im Notfall das Programm wieder zum Laufen bekommen, ohne den Bibliotheks-Code zu kennen.

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1250217)

Wenn ich mir MS Office kaufe, dann doch auch ohne Quellcode.

Wüsste nicht das Microsoft eine kundenspezifische Office-Lösung per Werkvertrag anbietet.

Der Office-Fall zeigt aber eine Lösung auf (wenn der Kunde mitspielt). Statt das per Werkvertrag als kundenspezifische Lösung zu verkaufen, wird das als Lizenz/Feature einer Standardlösung verkauft. Bei Standardlösung bekommt man ja auch keinen Quellcode geliefert.

[Furtbichler]

Zitat:

Zitat von ASM (Beitrag 1250212)

Zitat:

Zitat von Furtbichler (Beitrag 1250186)

Eigentlich ist das eine sehr einfache Geschichte.

Aber nicht derart und keinesweg so einfach, wie Du das hier erklärst. Die - auch vom BGH bestätigte - Rechtsprechung sieht erheblich anders.

Ich meine, das die Auslieferung mit Quellcode eine sehr einfache Geschichte ist. Welche 'auch vom BHG bestättigte' Rechtsprechung sieht denn 'erheblich anders' aus?

Zitat:

Zitat von himitsu (Beitrag 1250217)

Delphi-Quellcode:

Müssen

muss hier niemand was.
Es kommt aber auf den Vertrag drauf an.

Deshalb rede ich ständig vom 'Werk'. Und da muss der Kunde in der Lage sein bla bla.

Zitat:

Wenn man jemandem ein Programm schreibt, dann kann es auch ohne Quellcode sein.

Weil das kein Werkvertrag ist.

Zitat:

Zitat von OlafSt (Beitrag 1250194)

Die Idee mit einer DLL ist interessant, die behalte ich mal im Auge.

oder einfach die DCU mitliefern. Allerdings sind diese imho bei einem Delphi-Versionswechsel nicht mehr kompilierbar.

Zitat:

nur eben diese Toolsammlung will ich nicht mitgeben.

. Ich würde einfach die Optionen auflisten:
1. DCU zur aktuellen Delphi-Version
2. DLL (Delphi-unabhängig)
3. Verkauf des Quelltextes.

Die werden die Kröte schon schlucken.

Zitat:

Zitat von BUG (Beitrag 1250227)

Der Kunde könnte vermutlich etwas mit einer genauen Dokumentation der nicht ausgelieferten Funktionen und ausführlichen Testfällen anfangen.

Ich gebe doch die Systemdoku von meinem DevExpress auch nicht an den Kunden. Soll er sich die Teile doch kaufen, wenn er selbst programmieren will.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1250262)

Der Office-Fall zeigt aber eine Lösung auf (wenn der Kunde mitspielt). Statt das per Werkvertrag als kundenspezifische Lösung zu verkaufen, wird das als Lizenz/Feature einer Standardlösung verkauft. Bei Standardlösung bekommt man ja auch keinen Quellcode geliefert.

Das grenzt dann schon an Betrug/Kundenverarsche. Aber wenn er so blöd ist... ;-)

[Bernhard Geyer]

Zitat:

Zitat von Furtbichler (Beitrag 1250296)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1250262)

Der Office-Fall zeigt aber eine Lösung auf (wenn der Kunde mitspielt). Statt das per Werkvertrag als kundenspezifische Lösung zu verkaufen, wird das als Lizenz/Feature einer Standardlösung verkauft. Bei Standardlösung bekommt man ja auch keinen Quellcode geliefert.

Das grenzt dann schon an Betrug/Kundenverarsche. Aber wenn er so blöd ist... ;-)

Und wieso? Der Kunde will eine Lösung. Seine Erweiterung ist Bestandteil einer Standardlösung. Im Rahmen eines Werksvertrags müsste man ihm dann den kompletten Quellcode geben.
Wir könnten also nur sagen: "Nee, wir können als Werkvertrag keine Lösung anbieten." Der Kunde will aber (wegen Schlechter Erfahrung mit primär kundenspezifischen Lösungen) ein (erweitertes) Standardprodukt. Also wird es Lizenz verkauft. Wobei ja oft solche erstmals Kundenspezifischen Lösungen in den Standard wandern wenn sich zeigt das dies Lösung (in ähnlicher Art) öfter benötigt wird.

[OlafSt]

Danke für die zahlreichen Ansichten zum Thema, ich finde das sehr hilfreich.

Auf jeden Fall kommt eine "Standardlösung" nicht in Betracht. Zum einen ist die Software recht speziell, mehr als ein dutzend Lizenzen werden wohl kaum verkauft werden - also kein Massenprodukt. Zudem basiert die Software auf einem alten Programm, allerdings wird nur die Grundidee und Basisfunktionalität übernommen. Es ist also eine komplette Neuentwicklung, from Scratch.

Mein Auftraggeber hat zudem mit dem Outsourcing miese Erfahrungen gemacht (hat ein großes Projekt zu einem Duo in Rußland gegeben... Ich hab ihm gleich gesagt, das das schwer in die Hose gehen wird, denn die russischen Entwickler definieren Termintreue und Qualität doch leicht anders, als wir das gewohnt sind. Also ist er richtig böse auf den Arsch damit geknallt), was seine Paranoia erklärt.

Aber, wie @Furtbicler schon sagte:

Zitat:

Ich würde einfach die Optionen auflisten:
1. DCU zur aktuellen Delphi-Version
2. DLL (Delphi-unabhängig)
3. Verkauf des Quelltextes

Auf diese Optionen plus eine vierte (Das Projekt abgeben, was ich ohne mit der Wimper zu zucken machen würde) wird es herauslaufen.

Zitat:

Die werden die Kröte schon schlucken.

Sehe ich auch so.

[himitsu]

Selbst wenn sie für diese Routinen jetzt was zahlen müssen.

Ohne hätten sie es auch bezahlen müssen ... samt dem Mehraufwand und der späteren Lieferung.

[Bernhard Geyer]

Zitat:

Zitat von OlafSt (Beitrag 1250345)

Auf jeden Fall kommt eine "Standardlösung" nicht in Betracht. Zum einen ist die Software recht speziell, mehr als ein dutzend Lizenzen werden wohl kaum verkauft werden - also kein Massenprodukt.

Wenn mehr als ein Kunde damit bedient würde hättest du schon eine "Standardlösung". Dann wurde/wird die Entwicklung nicht nur speziell für einen Kunden gemacht. Wir haben auch eine "Spezielle" Lösung und hatten im ersten Jahr weniger als ein dutzend Lizenzen verkauft

[Furtbichler]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1250361)

Wenn mehr als ein Kunde damit bedient würde hättest du schon eine "Standardlösung".

Es kommt doch darauf an, wer die Entwicklung finanziert hat und nicht, wie viele Lizenzen man verkauft hat. Wenn Du ein Werk ohne Zustimmung des Auftraggebers weiter veräußerst, machst Du dich ja eh strafbar.

[OlafSt]

So sieht es aus. Ich entwickle dieses Programm im Auftrag meines Auftraggebers. Ergo "verkaufe" ich das nur ein einziges Mal. Da ich den Zielmarkt kenne (steckte selbst en paar Jahre in der Branche drin) weiß ich, das das Programm bestenfalls ein dutzend mal verkauft wird, wenn mein Auftraggeber denn Interesse daran hat, es noch anderweitig anzubieten.

However, so ganz kapiere ich den Unterschied zwischen "Werk" und "Standardlösung" eh noch nicht ;)

[Furtbichler]

(Sehr) grob gesehen:
Werk = Maßanzug.
Standard = Von der Stange.