Eigene Routinensammlung ohne Quellcode

[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.

[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.

[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 von OlafSt:

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.

[ASM]

Zitat von Furtbichler:

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 von Furtbichler:

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.

[Furtbichler]

Zitat von ASM:

Zitat von Furtbichler:

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 von himitsu:

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 von OlafSt:

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 von BUG:

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 von Bernhard Geyer:

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...