wertvolle Scripte schützen

[Guido]

Hier mal noch ein Beispiel einer phpinfo.php

<?php //0259

// Hier steht eigentlich der Code zum Prüfen, ob
// der IonCube-Loader in der php.ini steht
// oder ob direkt im Projekt-Verzeichnis, z.B.
//     ./myproject/ioncube/ 
// existiert
// 
// Alles was jetzt folgt, ist die kompilierte phpinfo-Funktion
?>
ƒ(¼?ÿ`¸•#a…Duãe§l¼K"Žh§§#kèãeÁ#¼¸WdPj˜ØøŠšà®|¬Ô8—JDÑ
†ôd+S¼(á
æ2Ô¿
çÛøßMc`ˆozõÙ¨kb[ô´•óu™1@

[goth]

Siehst Du ... das meine ich: ... die Menge macht's nur wenn der Markt groß genug ist ... erst denken ... dann schreiben ... !

[mchashi]

naja

ist aber auch keine gute lösung, wenn du z.b. ein Script an einen User verkaufst, der seinen webspace bei puretec (einsundeins) hat. der kann ja keine einstellungen ändern.

[TobiaZ]

sowas macht man auch nicht bei nem gästebuch. aber bei comunity oder so machst sinn.

Ich machs einfach open Source (Siehe Linkliste).

[tj99de]

Im Artikel von BlobBanana war ein Link auf dieses Tool http://pobs.mywalhalla.net/ drin.
Wenn man kein Geld für die kommerziellen Produkte ausgeben will/kann und/oder beim User keine zusätzlichen Anforderungen stellen will, kann man sich vielleicht damit behelfen. Ist nur die Frage, was der Kunde dazu sagt, wenn man Dateien wie in den Beispielen des Tools ausliefert. Einige Firmen wollen schließlich die Möglichkeit haben selber Anpassungen am Code vornehmen zu können. Also ich würde mit so einem Code nicht arbeiten wollen.
Wie man sicherstellt, daß das Script nur auf einem Server läuft, muß man sich dann selber überlegen.
cu tj99de

[Viper1985]

@mchashi

wenn du denkst, es gäbe kein produkt das "perfekt" ist für dich, dann schreib doch selber eins!!!!!

[Guido]

Einige Firmen wollen schließlich die Möglichkeit haben selber Anpassungen am Code vornehmen zu können.

Das ist mit IonCube auch möglich!
Dort gibt es Schalter zum excludieren von Dateien oder Verzeichnissen, die nicht kompiliert werden sollen. Diese werden dann nur kopiert oder gänzlich ignoriert (wie man will).
Aber vor allem ist es doch eine ganze Menge preiswerter als der Zend-Encoder.

Also ich würde mit so einem Code nicht arbeiten wollen.

Ein Kunde, der eine teure Software kauft, soll auch nur da was machen können, was das Gewährleistungsrecht (im Volksmund Garantie) nicht ausser Kraft setzt.
Hin zu kommt:
Entweder ich verkaufe einen Elektro-Baukasten, ein paar Metallröhrchen und ein Glasbläser-Set oder eine fertige Kaffeemaschine. Und hier scheint es ja um den Verkauf fertiger und gut durchdachter Internet-Software zu gehen, wie es sich für anständige teure kommerzielle Produkte gehört.

[tj99de]

Das hält viele Unternehmen trotzdem nicht davon ab, daß sie vollen Zugriff auf den Quellcode haben wollen. Damit sollen Abhängigkeiten von anderen Unternehmen möglichst vermieden werden und die Möglichkeit bestehen bleiben, daß die eigene IT-Anbieter oder ein Drittanbieter das bestehende Produkt erweitern oder zu einem späteren Zeitpunkt noch nachträglich weiter customizen kann.
Dadurch können natürlich auch Lizenz- oder Garantieprobleme entstehen ...

[Guido]

Vielleicht sollte mal eine Umfrage gestartet werden, ob und wann ein Entwickler Encodieren für gut hält.
Z.B. mit Kundenabsprache etc.
Mal ein "fieses" Beispiel:
Wir haben für einen Kunden einen Kopierschutz für Java-basierte Live-Cams programmiert, da der LiveCam-Provider die Streams ungenügend schützt (Die LiveCams kann ich mir sogar als Desktop-Hintergrund einstellen - sehr unterhaltsam ).
Der Kunde hat dafür zwar nicht viel aber immerhin bezahlt.
Wenn nun der Provider, auf dessem Server neben dessen Streams auch der kleine Schutz liegt, den Code nun in die Verzeichnisse aller Kunden kopiert und anpasst, hat der Kunde den Zonk und die Kosten, aber der Webmaster wurde für seine Schlampigkeit belohnt.

Übrigens kann man so gut wie jeden LiveCam-Stream, der mit AnfyCam läuft, klauen.

[TobiaZ]

Um das Beispiel mit der Kaffeemaschine aufzugreifen: (umgewandelt)

Wenn jetzt AEG ne Kaffeemaschiene ausliefert. Dann kann sich Krups das ding kaufen. Da Krups was davon versteht, kann Krups die auch "kopieren". Und auch weiterverkaufen. Der normale Konsument hat jedoch keine Chance. Da was zu ändern/nachzubauen. Und wenn er's doch macht, lohnt es sich nicht.

Bei den Scripts ist es eigentlich das gleiche.

Deshalb hat man von der Verlüsselung wenig. Da wie bereits erwähnt wurde, in der Branche die Anpassung gewährleistet werden muss.

Was macht ein Unternehmen, wenn sein Dienstleister Pleite geht, Anpassungen nur zu überteuerten Preisen macht, etc, pp.
Auf sowas lässt man sich nicht ein.

[mchashi]

informiert mich

wenn ihr von einer methoden (programm oder so) was erfahrt, was ungefähr so ist, wie ich es beschrieben habe, meldet euch unbedingt bei mir, wäre euch sehr dankbar.

ohne ein auffäliges Posten wäre auch ok.

Mal sehen wann's so weit ist.


Gruß
Sven.

[Guido]

Also, meiner Meinung nach gibt es sicher tausende Gründe für den einen, seinen Quellcode ganz oder z.T. zu schützen und ebenso viele, dies zu lassen.
Aber gerade Entwickler kommerzieller Software (dazu zähle ich auch komplette PHP-Anwendungen) haben oft genug Gründe, so scheint es zumindest, wenn man entsprechend im Internet sucht:
siehe hier http://www.phpbuilder.com/news/item.php?id=356
oder
bei Google

Wenn jetzt AEG ne Kaffeemaschiene ausliefert. Dann kann sich Krups das ding kaufen. Da Krups was davon versteht, kann Krups die auch "kopieren". Und auch weiterverkaufen.

Aber mit eigenen oder selbst eingekauften Teilen und eigenen Entwicklungskosten, um soviel zu verändern, dass das Urheberrecht gewahrt bleibt

Deshalb hat man von der Verlüsselung wenig. Da wie bereits erwähnt wurde, in der Branche die Anpassung gewährleistet werden muss.

Wir arbeiten mit CVS und haben in unserem Support-Bereich ein Script, welches unseren registrierten Kunden die aktuellste Version aus CVS holt, diese kompiliert und einen tarball erstellt.
Auch bei unkompilierten Lösungen greift der Kunde letztendlich auf uns zurück, wenn er Anpassungen benötigt.
Wir haben also die selbe Arbeit und er erhält das selbe Produkt.

Letztendlich ist es bei uns dem Programmierer überlassen, welche Dateien er durch den Encoder jagt.
Das kann zum Beispiel auch eine einzige Include-Datei sein, in der lediglich die erlaubte Domain/IP/etc. geprüft wird, die das Script ausführen darf.

Einige Programme encodieren wir auch nur in der Testversion, um die Laufzeit (z.B. 30 Tage) zu garantieren.
Das ermöglicht uns Kundenbindung. Die Verkaufserfolge bei kommerziellen Lösungen haben sich dadurch bei uns vervielfacht, der Kunde kann bereits erste Anpassungen vornehmen (schließlich kann man ja sagen, dass man nur globale Funktionen etc. encodiert) und dann erhält er bei Kauf den originalen Quellcode.

Was macht ein Unternehmen, wenn sein Dienstleister Pleite geht, Anpassungen nur zu überteuerten Preisen macht, etc, pp.
Auf sowas lässt man sich nicht ein.

Ein Encoder hat mit unternehmerischer Seriösität wohl wenig zu tun.
Unsere Kunden lassen sich schon drauf ein. Weil wir zum einen auch für nachträgliche Anpassungen normale Preise nehmen, teils sogar per Support-Pauschale oder, wenn's ein guter Kunde ist, auch mal mit guten Rabatten.
Und sollte es uns so schlecht gehen, dass wir weg sind, treten wir den Quellcode an den Kunden ab. Das ist jeweils vertraglich festgelegt und wird zum Teil auch angewendet, wenn wir die Entwicklung eines Produktes einstellen.

[TobiaZ]

Ein Encoder hat mit unternehmerischer Seriösität wohl wenig zu tun.
Unsere Kunden schon. Weil wir zum einen auch für nachträgliche Anpassungen normale Preise nehmen, teils sogar per Support-Pauschale oder, wenn's ein guter Kunde ist, auch mal mit guten Rabatten.
Und sollte es uns so schlecht gehen, dass wir weg sind, treten wir den Quellcode an den Kunden ab. Das ist jeweils vertraglich festgelegt und wird zum Teil auch angewendet, wenn wir die Entwicklung eines Produktes einstellen.

Seriösität habe ich nicht angezweifelt. Aber ansonsten hast auch wieder recht. Es gibt immer irgendwo mittel und wege, oder Vereinbarungen.

Ich für meinen Teil halte meine Scripts frei. Bei uns handelt es sich i.d.R. um individuelle, ganz spezielle Programme, wo kaum ein anderer was mit anfangen kann. Daher können wir darauf verzichten.

Hast ja selbst gesagt, dass es sonne und sonne gibt

Also, meiner Meinung nach gibt es sicher tausende Gründe für den einen, seinen Quellcode ganz oder z.T. zu schützen und ebenso viele, dies zu lassen.

Bin Meinung, dass die Leute, die ein Script umcode können, genauso gut selbst anfangen können. Und die eigentliche Zielgruppe (die die keine Ahnung haben) sehen eh nur Bahnhof.
Muss aber eingestehen, dass ein Kunde (noob) das Script an einen/ mit einem Profi verkaufen könnte.

Bleibt wahrscheinlich von Fall zu Fall abzuwägen.

Für indiv. Scripts bau ich, wenns sich Lohnt ne kleine Hürde ein. Ansonsten entwickle ich sowieso für ASP, da brauch ich das alles ja nicht.

[mchashi]

keine ahnung von asp

Hi,

kann bei asp den code nicht sehen ?
ist die sprache sehr empfehlenswert zu lernen, denn wenn ja, würde ich mir ein buch holen. stärker wie php oder wie würdest du es einschätzen? bitte auch um kurze info, ob man den code usw. sehen kann.

gruß
sven.

[Abraxax]

wenn ich mich nicht irre, laufen asp-dateien NUR auf masosoft-webservern.

ich kann mich aber auch irren

[color=#DDDDDD]*) masosoft => microshit => microsoft[/color]