Eigene Routinensammlung ohne Quellcode

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

[Bernhard Geyer]

Zitat von Furtbichler:

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

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.