Sinspin - Do 18.11.10 16:54
Titel: Absichern von Quelltext gegen unerlaubtes kopieren

---

Hallo,

wir wollen Teile unserer Projekte von einem externen Entwicklerteam, bzw. externen Entwicklern erweitern lassen.
Dabei möchten wir sicherstellen das die Entwickler unsere bereitgestellten Quelltexte, also unser Framework auf dem sie aufbauen müssen, zwar verwenden können aber nicht in der Lage sind die Quelltexte einfach zu kopieren und zu verkaufen oder damit eine eigene Firma aufzumachen.

Bisher sieht die Planung dafür so aus das die Entwickler von uns einen Remotezugang zu einer VM auf unserem Server bereitgestellt bekommen in der die IDE läuft und alle Komponenten und deren Hilfen, etc. installiert sind die benötigt werden. Zum Testen stellen wir entsprechende Verzeichnisse innerhalb der VM bereit.
Den Zugriff aufs Internet können wir leider nicht vollständig verhindern da zum Testen auf Webserver zugegriffen werden muss.

Was für Möglichkeiten kennt ihr um an den Quelltext zu kommen und wie könnte man den Zugriff verhindern? Zu 100% sicher geht es nicht, das ist klar. Und wenn dann die letzte Möglichkeit ranzukommen nur darin besteht den Quelltext abzufotografieren bin ich eigentlich schon ganz zufrieden.

E: Vorläufig geht es uns nur um Delphiprojekte. C# / .Net Schnittstellen machen wir selber.

Crosspost [http://www.delphipraxis.net/156068-absichern-von-quelltext-gegen-unerlaubtes-kopieren.html#post1062387]

Burgwart - Do 18.11.10 17:07

---

Hallo,

bei uns läuft das so. Es wird ein Pflichtenheft erstellt mit einer Schnittstellenbeschreibung. Der Entwickler (Freiberufler) erzeugt eine *.dll und bekommt von uns eine *.exe die sein Teil aufruft. So kann er es mit der Software testen. Die Endabstimmung ist immer bei uns im Hause. Und wenn es Probleme gibt muss er auch zu uns ins Haus kommen. Auf diese Art und Weise ist bei uns noch nie etwas passiert.

Gruß Burgwart

jasocul - Do 18.11.10 17:11

---

Alle Sourcen, die nicht von den Externen bearbeitet werden, werden nur in kompilierter Form bereit gestellt.

Hidden - Do 18.11.10 17:20

---

Moin!

Burgwarts Lösung sieht für mich ganz vernünftig aus, Remote-Zugriff ist wackelig und unschön zum dauerhaften Arbeiten? Da würde ich als ehrlicher Mitarbeiter der Fremdfirma lieber mit Compillat und guter Doku zu den relevanten Verknüpfungsstellen arbeiten :nixweiss:

Soll euer Quelltext durch die Fremdfirma denn etwa bearbeitet werden? Wenn nein, fällt mit dem Schreibzugriff auch die Notwendigkeit des Lesezugriffs weg, und was bleibt ist eine Beschreibung des Moduls von außen - Doku.

Wenn es Abschnitte im Quelltext gibt, in denen kein großer Wert liegt, die aber für die Weiterentwicklung von Nutzen seien können, könnte man auch mal darüber nachdenken, deren Implementierung der Dokumentation beizulegen.
Das gleiche gilt gegebenenfalls für Formulardateien, Recources, etc.

lg,

ThoMa - Do 18.11.10 17:21

---

Als Hinweis am Rande:

Bitte nicht vergessen, dass in die MSIL "kompiliert" wird und eine Rückführung auf den Originalsourcecode relativ trivial ist. Auch Obfuscation bietet hier nur begrenzt Schutz.

Es gibt entsprechende Ansätze Ideen und Software zu schützen (Application Bags & Co.). Aber dieses Knowledge muss auch erst einmal vorhanden sein um es nutzen zu können.

jaenicke - Do 18.11.10 17:52

---

ThoMa hat folgendes geschrieben :

Bitte nicht vergessen, dass in die MSIL "kompiliert" wird und eine Rückführung auf den Originalsourcecode relativ trivial ist.

Ich denke einmal hier geht es um Delphi und dort gilt das nicht. ;-)

Der Off Topic Bereich ist im C#-Bereich und dem Delphi-Bereich des Forums der selbe. ;-)

Und zum Thema:
Ich sehe auch keine Notwendigkeit für den Zugriff auf den Quelltext selbst. Und wenn das aus irgendeinem Grund so sein soll, dass der Quelltext angeschaut wird, lässt sich auch nicht verhindern, dass er angeschaut (und damit ggf. abgeschrieben) wird.

Sinspin - Do 18.11.10 18:08

---

Danke für eure Antworten :zustimm:
Testanwendung von uns und Dll vom Entwickler ist schon die Richtung die uns auch vorschwebt, allerdings lößt das eben nicht das Problem das die Module auf die Datenbank zugreifen müssen und dafür unser Framework bzw. unsere Komponenten verwendet werden sollen (müssen). Schon um Änderungen am Framework zu verhindern und die Quellen zu schützen sind dcu's eine gute Idee.
Arbeiten auf einem von uns Remote bereitgestellten System hätte halt den Vorteil das wir die erstellten Quelltexte von Anfang an verfügbar hätten um derem Qualität jederzeit prüfen könnten.
Ein Gegenargument für remote Zugriff ist natürlich die Frage nach der Stabilität des Zugriffs und der Bandbreite die wir bereitstellen müssen. Upstream ist teuer.

jaenicke - Do 18.11.10 18:12

---

Sinspin hat folgendes geschrieben :

Arbeiten auf einem von uns Remote bereitgestellten System hätte halt den Vorteil das wir die erstellten Quelltexte von Anfang an verfügbar hätten um derem Qualität jederzeit prüfen könnten.

Dennoch müssen eure Quelltexte auf eben diesem Remotesystem ja auch nicht liegen. Auch dort reichen die einkompilierbaren DCUs.

Und dort ist es umso einfacher, weil ihr das alles entsprechend einrichten könnt mit den Pfaden usw., so dass die Entwickler die Units direkt nutzen können.

Burgwart - Do 18.11.10 18:45

---

Hallo,

also wenn das Programm und die Daten nur für intern sind, dann ein vpn - Server über den Ihr den Zugriff auf die Datenbank steuern könnt. Der Entwickler ist bei Euch quasi im Netz. Sollte es verkauft werden, oder von extern genutzt werden, so empfiehlt sich ein Server, wo eine API - Schnittstelle definiert ist. Die Anfragen entgegen nimmt, kontrolliert und nur das Ergebnis zurück gibt. Also kein direckten Zugriff auf den SQL - Server.

Gruß Burgwart

Nersgatt - Fr 19.11.10 08:30

---

Also ich weiß ja nicht. Wenn man etwas basierend auf einem Framework entwicklen soll, von dem man den Quellcode nicht hat, dann muss das Framework extrem gut dokumentiert sein. Und manchmal ist es halt wirklich einfacher, eben in den Quellcode einer Funktion zu schauen, was intern denn wirklich passiert, um einen Fehler im eigenen Code zu finden.
Nicht umsonst kann man bei sehr vielen kommerziellen Komponenten den Quellcode dazukaufen. Wir haben z.B. die DevExpresskomponenten gekauft inkl. Quellcode. Auch wenn wir nichts dran ändern wollen, ist es bei Debuggen sehr hilfreich (obwohl die Doku vom DevExpress auch sehr gut ist).

Jens