Eigene Routinensammlung ohne Quellcode

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

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

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

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.