Wie kann ich Python-Code schützen?
Ich entwickle eine Software in Python, die an die Kunden meines Arbeitgebers verteilt werden soll. Mein Arbeitgeber möchte die Nutzung der Software mit einer zeitlich begrenzten Lizenzdatei einschränken.
Wenn wir die .py-Dateien oder sogar .pyc-Dateien verteilen, wird es einfach sein, den Code, der die Lizenzdatei prüft, zu (dekompilieren und) zu entfernen.
Ein weiterer Aspekt ist, dass mein Arbeitgeber nicht möchte, dass der Code von unseren Kunden gelesen wird, da er befürchtet, dass der Code oder zumindest die "neuen Ideen" gestohlen werden könnten.
Gibt es eine gute Möglichkeit, dieses Problem zu lösen? Vorzugsweise mit einer Lösung von der Stange.
Die Software wird auf Linux-Systemen laufen (also glaube ich nicht, dass py2exe den Trick machen wird).
Python ist als bytecode-kompilierte, interpretierte Sprache sehr schwer zu fixieren. Selbst wenn Sie einen Exe-Packager wie py2exe verwenden, ist das Layout der ausführbaren Datei bekannt, und die Python-Byte-Codes werden gut verstanden.
Normalerweise muss man in solchen Fällen einen Kompromiss eingehen. Wie wichtig ist es wirklich, den Code zu schützen? Enthält er echte Geheimnisse (z. B. einen Schlüssel für die symmetrische Verschlüsselung von Banküberweisungen), oder sind Sie einfach nur paranoid? Wählen Sie die Sprache, mit der Sie das beste Produkt am schnellsten entwickeln können, und seien Sie realistisch, was den Wert Ihrer neuen Ideen angeht.
Wenn Sie entscheiden, dass Sie die Lizenzprüfung wirklich sicher durchsetzen müssen, schreiben Sie sie als kleine C-Erweiterung, so dass der Code für die Lizenzprüfung besonders schwer (aber nicht unmöglich!) zurückzuentwickeln ist, und lassen Sie den Großteil Ihres Codes in Python.
Ist Ihrem Arbeitgeber bewusst, dass er alle Ideen, die andere aus Ihrem Code gewinnen, "stehlen" kann? Ich meine, wenn sie Ihre Arbeit lesen können, können Sie ihre auch lesen. Vielleicht wäre es sinnvoller, zu überlegen, wie Sie von der Situation profitieren können, als zu befürchten, wie viel Sie verlieren könnten.
[EDIT] Antwort auf Nicks Kommentar:
Nichts gewonnen und nichts verloren. Der Kunde hat, was er will (und er hat dafür bezahlt, da er die Änderung selbst vorgenommen hat). Da er die Änderung nicht freigibt, ist es so, als ob sie für alle anderen nicht geschehen wäre.
Wenn der Kunde nun die Software verkauft, muss er den Urheberrechtsvermerk ändern (was illegal ist, so dass Sie klagen können und gewinnen werden -> einfacher Fall).
Wenn er den Urheberrechtsvermerk nicht ändert, werden die Kunden der zweiten Ebene bemerken, dass die Software ursprünglich von Ihnen stammt, und sich fragen, was los ist. Die Chancen stehen gut, dass sie sich mit Ihnen in Verbindung setzen und Sie so von dem Weiterverkauf Ihrer Arbeit erfahren.
Wieder haben wir zwei Fälle: Der ursprüngliche Kunde hat nur ein paar Kopien verkauft. Das bedeutet, dass er sowieso nicht viel Geld verdient hat, also warum sich die Mühe machen. Oder er hat eine große Menge verkauft. Das bedeutet, dass Sie bessere Chancen haben, zu erfahren, was sie tun, und etwas dagegen zu unternehmen.
Aber letztendlich versuchen die meisten Unternehmen, sich an die Gesetze zu halten (wenn ihr Ruf erst einmal ruiniert ist, ist es viel schwieriger, Geschäfte zu machen). Sie werden Ihre Arbeit also nicht stehlen, sondern mit Ihnen zusammenarbeiten, um sie zu verbessern. Wenn Sie also den Quellcode mitliefern (mit einer Lizenz, die Sie vor dem einfachen Weiterverkauf schützt), ist die Wahrscheinlichkeit groß, dass sie die Änderungen, die sie vorgenommen haben, einfach wieder zurücknehmen, da dies sicherstellt, dass die Änderungen in der nächsten Version enthalten sind und sie sie nicht mehr pflegen müssen. Das ist eine Win-Win-Situation: Sie bekommen die Änderungen und sie können die Änderungen selbst vornehmen, wenn sie sie wirklich dringend brauchen, auch wenn Sie nicht bereit sind, sie in die offizielle Version aufzunehmen.
Sie sollten sich einmal ansehen, wie die Jungs von getdropbox.com das für ihre Client-Software, einschließlich Linux, machen. Es ist ziemlich knifflig zu knacken und erfordert eine recht kreative Disassemblierung, um die Schutzmechanismen zu umgehen.