Eigene Routinensammlung ohne Quellcode

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