Urheberrecht auf Datenbank und Softwaredesign

[Faxe]

Interessant wäre noch, wie die Datenbank lizensiert ist.
Bei "Named User" wird mit solchen zusätzlichen HTML-Lösungen eventuell "geschlampt".

[Bernhard Geyer]

Zitat von Faxe:

Interessant wäre noch, wie die Datenbank lizensiert ist.
Bei "Named User" wird mit solchen zusätzlichen HTML-Lösungen eventuell "geschlampt".

Das ist aber kein Problem des Fragestellers - außer er würde die Datenbank als Dienstleistung vermieten.

[himitsu]

Oder er macht es wie Skype mit seinen Daten (Netzwerk) ... Man baut intern regelmäßig alles um und schon gucken die mit ihrer eigenen Anbindung in die Röhre.

Vielleicht auch noch bissl die Namen der Tabellen und Spalten obfuskieren und die Datenbank verschlüsseln.

Zitat von Dejan Vu:

Man muss nur aus der Gewährleistung draußen sein. Sonst hat er TE nun das Problem, as die andere SW vielleicht Murks speichert und seine SW dafür verantwortlich gemacht wird bzw. wäre er dann in der Nachweispflicht, das bei ihm alles ok ist. Äh, das gilt -glaube ich- nur, wenn es eine Auftragsarbeit ist.

Sicher, daß es nicht andersrum ist?

Immerhin haben die sich ja in die DB gehackt und verändern wild die Daten (nicht nur "harmloses" Auslesen).
Sollen die erstmal beweisen, daß sie da nichts kaputt gemacht haben, bevor sie die Schuld auf den Entwickler der DB und dessen Programm schieben.

[Captnemo]

Was ggf. noch relevant sein könnte, wäre Referenzdaten in der Datenbank die dem Kunden zur vertraglich eingeschränkten Nutzung überlassen werden. Das gibt es in vielen Branchen, in denen die Softwarelieferanten in ihren DB's Datenbestände mit ausliefern (z.B. in einer KFZ-Software KBA-Nummern, Teilekataloge oder Arbeitswerte).
Diese Daten sind mitunter auch nur zugekauft und unterliegen meist auch bestimmten Nutzungsbedingungen. Allerdings darf dann der Softwarelieferant diese dann auch dem Kunden nicht frei zugänglich machen (hängt natürlich von dem Vertrag ab, mit dem er die Daten eingekauft hat).

Wenn du z.B. PLZ-Verzeichnis mit drin hast, und das zugekauft hat, müsstest du auch mal in die Nutzungsbedingungen schauen.

[Perlsau]

Zwar schon 11 Jahre alt, aber lesenswert:
Softwarepatent auf Datenbankstrukturen

Auszug:
Die neunzigseitige Patentschrift hebt insbesondere die Datenstruktur der Software hervor, die eine riesige Anzahl zusammenhängender Dateneinträge beherrscht und deren Extraktion aus der Datenbasis mittels so genannter Queries ermöglicht. Start- und Enddaten bezüglich eines Eintrags indizieren dabei dessen Gültigkeitsdauer.

Ähnliche Meldungen:
Schutzanspruch auf Kontextmenü ist "Softwarepatent des Monats" (2006)
Neue Vorstöße gegen Trivialpatente in Großbritannien und USA (2006)
Patent-Pools für Open Source unter schwerem Beschuss (2005)
... und weitere ...

Zitat von himitsu:

Immerhin haben die sich ja in die DB gehackt und verändern wild die Daten (nicht nur "harmloses" Auslesen).
Sollen die erstmal beweisen, daß sie da nichts kaputt gemacht haben, bevor sie die Schuld auf den Entwickler der DB und dessen Programm schieben.

Man kann doch in den Vertrag, den der Entwickler mit dem Kunden abschließt, eine Klausel über Gewährleistungspflicht und Nachbesserungsfälle einfügen: Wenn der Kunde mit anderen Anwendungen als der vom Entwickler bereitgestellten Daten in der DB verändert, erlischt die Gewährleistungspflicht des Entwicklers und Korrekturen/Reparaturen werden kostenpflichtig. Überwachen kann man das mit einer Logtabelle, die man bei solchen Projekten sowieso stets anlegen sollte. Dort hinein schreibt die "legale" Anwendung alle Aktionen, die von ihr an der DB vorgenommen wurden: Timestamp, BenutzerId, AktionsId etc. und einen daraus erzeugten Hash. Das macht dann so schnell keiner mit irgend einem PHP-Gewurstel nach

[Dejan Vu]

Es wurden schon vorgeschlagen, aber trotzdem: Ein zusätzliches Feld in allen wichtigen Tasbellen, welches eine Prüfsumme über die Daten des Datensatzes enthält, würde zuverlässig unbefugtes Verändern erkennen.

Das, zusammen mit dem ActionLog, wäre doch ziemlich brauchbar.

Zitat von himitsu:

Zitat von Dejan Vu:

...aus der Gewährleistung draußen ... bzw. wäre er dann in der Nachweispflicht...

Sicher, daß es nicht andersrum ist? ...Immerhin haben die sich ja in die DB gehackt...

Ziemlich sicher, denn sie können sich hinstellen und behaupten:"Wir waren das nicht". Innerhalb der Gewährleistung musst Du die Daten in Ordnung bringen (außer Du kannst beweisen, das die das waren). Außerhalb der GWL können die das zwar immer noch behaupten, aber jetzt kannst Du für die 'Reparatur' Geld verlangen.

[Uwe Raabe]

Nur mal so ins Blaue:

Man könnte jede Tabelle mit einem Hashfeld erweitern. Die eigene Anwendung erzeugt beim Schreiben jedes Records den Hashwert mit einem privaten Schlüssel. Ändert jemand anders die Daten oder erzeugt zusätzliche Records, passt der Hashwert nicht ohne Kenntnis des Schlüssels und des Hash-Algorithmus.

Im eigenen Programm wird dann beim Lesen jedes Records (zumindest sporadisch) der Hashwert überprüft und das Programm meldet eine manipulierte Datenbank. Andere Reaktionen sind denkbar (z.B. automatische Rücksicherung der letzten Datensicherung ).

Damit ist die Datenbank immer noch für alle anderen Anwendungen lesbar, aber eine unerlaubte Manipulation der Daten wird zumindest bemerkt.

[sh17]

Zitat von himitsu:

Immerhin haben die sich ja in die DB gehackt und verändern wild die Daten (nicht nur "harmloses" Auslesen).
Sollen die erstmal beweisen, daß sie da nichts kaputt gemacht haben, bevor sie die Schuld auf den Entwickler der DB und dessen Programm schieben.

Das würde ich mal vertiefen, insbesondere in Bezug auf die Gewährleistung/Haftung.

Zumal sie ja nicht nur die Struktur der Datenbank nutzen, sondern in der Theorie auch ein
reverse engineering durchgeführt haben müssen. "Wenn ich x anlege muss auch y angelegt werden, Wert z ist Pflicht, etc)

[Dejan Vu]

Hallo? Ich schaue mir eine Datenbank an. Großartige Hürden musste ich als Kunde offensichtlich nicht überwinden (wenn ja, wäre das ein Ansatzpunkt). Jeder Erstsemesterstudent kann eine Datenbank verstehen (sofern er den Kurs belegt hat). Wenn die DB nicht vollkommen obskur ist oder gemacht wurde, hat sie schöne Tabellen- und Feldnamen sowie Foreign Keys und Primary Keys. Von 'reverse engineering' kann da keine Rede sein.

Wenn die Daten korrupt sind, kann der Kunde behaupten, was er will. Er kann auch behaupten, er hätte gar kein eigenes Programm, das die Daten verändert und alles läge nur an der Software vom TE. Wer ist nun hier in der Beweispflicht? Der Dumme ist der TE (falls der Kunde ein A***loch ist).

[sh17]

Ich weiss ja nicht wie komplex die DB des TE ist. Aber ohne Doku in einer großen DB-Struktur die Zusammenhänge fehlerfrei zu erkennen halte ich für schwierig.
Der TE weiss jetzt sogar, das der Kunde Software-Externe Änderungen vornimmt. Da würde ich keinen Finger krum machen, wenn etwas dabei schief geht, oder für einen
ordentlichen Lohn. Und nachweißen kann der TE schon, wenn da Daten fehlen, die gar nicht fehlen können, wenn die DB mit der Software des TE bearbeitet wurde.