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.

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

[Bernhard Geyer]

Zitat von Union:

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.

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