Mehrfacheinsatz einer Datenbank unterbinden

[Alexander 28]

Hallo zusammen. Ich grübel nun schon einige Tage über einem Problem wofür ich noch nicht wirklich die richtige Lösung gefunden habe.

Ich beabsichtige eine Datenbank an einen Kunden auszuliefern, muss aber irgendwie technisch überprüfen oder unterbinden können, dass er Kopien dieser Datenbank - zum Beispiel für weitere Zwecke - auf seinem Domino Server angelegt. Ein möglicher Weg wäre vielleicht die Replik ID als fixen Wert für die Berechnung des Lizenzschlüssels zu verwenden, so dass er nur die Version die er von mir ausgeliefert bekommt einsetzen muss.

Wenn dann aber aus technischen Gründen irgendwann einmal eine neue Kopie erstellt werden muss, ist auch die Replik ID eine andere und der Lizenzschlüssel müsste neu berechnet werden. Hat vielleicht jemand eine andere, clevererererere Idee, wie man so etwas lösen könnte?

Vielen Dank schon einmal im Voraus. Sollte mir selbst noch was besseres einfallen, werde ich es selbstverständlich hier Posten.

[umi]

Hallo

Ich denke, dass es keinen besseren Weg gibt um sicher zu verhindern, dass die DB Mehrfach kopiert wird.

Wenn aus technischen Gründen eine Kopie erstellt werden muss, pech. Wie gross ist die Wahrscheinlichkeit, dass aus "technischen" Gründen eine neue Kopie erstellt werden muss?

[koehlerbv]

Hallo Alexander,

ich finde Deine Frage etwa schräg: Ich lese da "Kunde" und"Lizenz" und dann direkt "Geld!". Da sträuben sich mir natürlich die Nackenhaare (wir verkaufen Kunden entweder eine Lösung, die er in x Datenbanken anwenden kann oder wir sorgen dafür, dass das nur mit einer designierten Datenbank funktioniert. Und in das Funktionieren beider Varianten haben wir - wie auch alle anderen hier, die sowas können - investiert!).

Ich will Dich trotzdem nicht so im Regen stehen lassen: Deine Idee mit der ReplicaID ist schon mal nicht die schlechteste (wenn auch vollkommen unbrauchbar) - aber über den eindeutigen Schlüssel für die DB (den DU lieferst) kommst Du weiter 

Nachtrag: Ich habe so eine Lösung noch niemals einem Kunden angedreht. Auf Basis einer gelieferten Schablone und seiner Lizenz (und des dazugehörigen Schlüssels) kann der Kunde treiben, was er will. Wenn uns mal jemand mal ansprechen würde, ob eine wirkliche "Eine-Datenbank-Lösung" billiger wäre, dann würde ich über o.g. Prinzip nachdenken, aber vermutlich würde unsere Antwort "nein" lauten, da der Aufwand gegenüber dem Kundenutzen nicht verringert wäre.
Viel interessanter ist doch, per LicenseKey die Verwendung in anderen Os oder OUs zu verhindern oder darüber den erlaubten Server für entscheidende Dinge zu beschränken 

Bernhard

[Alexander 28]

koehlerbv, du hast es genau auf den Punkt gebracht. Das Problem ist, dass die Anwendung aufgrund ihrer Struktur für unzählige verschiedene Zwecke benutzt werden könnte. Dafür gibt es einen festen Preis. Jetzt habe ich aber schon mehrfach die Diskussion mit Kunden gehabt, dass sie die Anwendung ja nicht für x verschiedene Einsatzzwecke nutzen möchten, sondern nur für einen einzigen - und dafür möchten sie nicht "so viel" Geld ausgeben.

Nun überlege ich natürlich, wie ich den Kunden entgegenkommen kann und eine "Ein-Kopie-Datenbanklösung" zu einem erheblich günstigeren Preis anbieten kann. Das ist der Hintergrund meiner Frage.

Ich selbst finde eine solche Lösung ebenfalls äußerst unpraktikabel und hätte sie aus eigenen Stücken wahrscheinlich nie in Betracht gezogen, da es wahrscheinlich tatsächlich nur über Krücken möglich sein wird, eine einigermaßen funktionierende Verwendungsüberprüfung zu implementieren.

Werde dann mal schauen, ob ich mit der Replik ID der Datenbank weiterkomme ....

[Tode]

Dann viel Erfolg... Aus Erfahrung raus kann ich Dir sagen, dass Kunden, die so um den Preis feilschen, dazu tendieren, insgesamt nicht sonderlich "fair" zu sein... Wenn Du das nicht absolut Wasserdicht hinbekommst (und dazu reicht es wahrscheinlich nicht, nur ein paar Script- Libraries zu verstecken, sondern dann musst Du wahrscheinlich das ganze Design verstecken), dann wird irgendwo plötzlich eine weitere Kopie auftauchen...

Für uns geht es in unseren Kundenbeziehungen um Vertrauen: Was wir für den Kunden entwickeln, das ist immer Quelloffen und wenn wir vereinbaren, dass der Kunde es nur einfach einsetzt, dann vertrauen wir darauf, dass der Kunde das auch macht....
Und auch wir haben Applikationen, die wir zum reduzierten Preis quasi als "Runtime" zu einer bestimmten Datenbank dazu geben, die aber auch leicht für andere Datenbanken benutzt werden könnte. Die "Runtime" hat da keinerlei Beschränkungen diesbezüglich...

Wir wünschen uns von unseren Kunden, dass sie uns vertrauen (was könnte man sonst nicht alles böses mit Code in einer versteckten Library machen...), und das selbe bringen wir ihnen entgegen.

Damit sind wir bisher immer gut gefahren.
Just my 50cent

[koehlerbv]

Werde dann mal schauen, ob ich mit der Replik ID der Datenbank weiterkomme ....

Genau davor hatte ich Dir in meinem Beitrag abgeraten ...

Bernhard

[Pyewacket]

Wir hatten früher mal ein Tool im Einsatz, ACL-Commander, da
war die Lizenzierung (Anzahl der DB welche je Server bearbeitet werden können)
an die Replik-ID gebunden. Unsere Version ist von 2000, irgendwann danach
ist die Herstellerfirma verschwunden.

[Alexander 28]

@Pyewacket

ja, genau so etwas habe ich mir auch vorgestellt. bernhard meint aber, dass sei der falsche weg !?!?!

[Peter Klett]

...irgendwann danach ist die Herstellerfirma verschwunden.

ja, genau so etwas habe ich mir auch vorgestellt.

War das jetzt ein Ausdruck innerlicher Kündigung, oder habe ich das falsch verstanden?

Ich bin mir nicht ganz sicher, worauf Bernhard sein Missfallen stützt. Aber: Wenn Du den Lizenzschlüssel ausschließlich an der ReplikID festmachst, kann die Datenbank auf beliebigen Servern genutzt werden, solange man sie (auf Betriebssystemebene) kopiert. Sollten dann die unterschiedlichen Server unerwartet doch einmal miteinander replizieren (weil man z.B. die DB netterweise den Kollegen einer befreundeten Firma "ausgeliehen" hat und Jahre später mit denen fusioniert) ist das Chaos perfekt.

Genausogut könnte die DB sowohl in einem Test- als auch in einem Produktivumfeld genutzt werden, wogegen sicherlich auch von Eurer Seite nichts zu sagen ist. Dann muss sie aber die gleiche ReplikID haben. Und auch da passiert irgendwann das nie geahnte, dass der Testserver mit dem Produktivserver repliziert (natürlich, sowas kommt NIE vor).

Ich denke, einen 100%igen Schutz gibt es nicht. Und das Schlimmste wäre, wenn der Schutzmechanismus dazu führt, dass der Kunde bei dem rechtmäßigen Einsatz der Datenbank aufgrund des "Schutzes" Probleme bekommt (z.B. weil es eine lebenswichtige Datenbank ist, die am Freitag Abend aus irgendwelchen technischen Gründen - oder einem administrativem Fehler - kopiert wird, dann nicht mehr läuft und vor Montag niemand von Euch im Support erreichbar ist, während beim Kunden am Samstag der "Laden steht").

Ideal wäre m.E., wenn für die Datenbank eine zentrale (Konfigurations-)Datenbank mitspielt, die die Anzahl der eingesetzten Datenbanken wirklich zuverlässig überwachen kann. Ansonsten würde ich es auch sein lassen und lieber dem Kunden vertrauen (siehe Todes Beitrag). Ein klarer Vertrag mit sauber definierten Sanktionen im Falle des Verstoßes ist mehr Wert als ein wackeliger programmatischer Versuch.

[Alexander 28]

Hi Peter. Danke für deine umfangreichen Ausführungen,  denen ich mich uneingeschränkt anschließen kann. Vermutlich hast du recht und ich werde es auf einer vertraglicher Basis mit dem Kunden regeln.

Auch vielen Dank an die Beiträge aller anderen Beteiligten!