[PHP] Je source protecten op iemand anders z'n server

[Icheb]

Ik moet een vrij groot project gaan maken, alleen ik zit met een vrij groot probleem, de persoon eist dat het gehele project draait vanaf hun eigen server, natuurlijk vrij logisch is, maar doordat het deze mensen vrij veel kost ben ik eigenlijk bang dat ze de beveiliging eruit laten halen en na 1 jaar of zo alles opzeggen...

Hoe kan ik mijn source het beste beschermen ?
Hoe doen jullie dit soort problemen allemaal oplossen ?


(ben ik gewoon te paranoïde ? )

[OxiMoron]

Icheb schreef op 25 maart 2003 @ 09:04:
(ben ik gewoon te paranoïde ? )

Wat vind je zelf?

Anyway.. het lijkt me onmogelijk om je source te "beschermen" als het op hun server komt te staan.

Wat je zou kunnen doen is zoeken naar een scrambler, die alle variabele namen hernoemt naar niet begrijpelijke namen. Maar verder...

[drm]

Justitieel beschermen, bedoel je? Je hebt zelf auteursrecht (hier in Nederland), tenzij je bij verkoop van je software anders vermeldt, afaik...

En anders heb je pech. De superuser van de server kan toch altijd jouw sourcecode wel lezen, dus als ze het echt willen hebben, kunnen ze 't toch van je lezen.

Een mogelijkheid is je source te Zend encoden.

edit:
iets beter linkje

edit:
Apache

[ Voor 14% gewijzigd door drm op 25-03-2003 09:26 ]

[ET]

Of Ion-cube encoden (voor 50 Dollarcent ofzo)
http://www.ioncube.com/online_encoder.php

[Kama]

Tja, je moet op de 1 of andere manier zorgen dat je kunt meten of ze het na een jaar nog gebruiken, of bijv. afspreken (in een overeenkomst) dat als ze het niet verlengen, je de code weer verwijdert van hun systeem.

Als ze het dan blijkt dat ze het toch nog gebruiken en ze hebben niets betaald, dan stuur je een rekening, aanmaning t/m deurwaarder.

Maarreh, is het voor hun ook niet veel goedkoper om jou te betalen dan om zelf dure uren te besteden om hun mensen het te laten "hacken"?

[Apache]

drm schreef op 25 March 2003 @ 09:09:
...
De enige mogelijkheid is je source te Zend encoden.
...

http://www.ioncube.com/sa_encoder.php
http://www.rssoftlab.com/phpenc.php4

en er zijn er nog een shitload, er waren zelfs gratis versie's ergens

[drm]

[alienfruit]

Kon je hem met PHP Accelerator ook niet zowel versnellen als "compileren" ?
Maar wat als de administrator van die server al die Zend e.d. software niet wilt draaien.... Zit je nog steeds met het probleem

[ Voor 50% gewijzigd door alienfruit op 25-03-2003 09:43 ]

[Verwijderd]

Voor zover ik weet zit de Zend decoder standaard bij php, dus het is wel een hele erge zeikerd als hij dat er uit gehaald heeft.
Dat is dan ook gelijk een groot voordeel van Zend, het werkt standaard gewoon.

Ook kan je bij Zend een verloop datum opgeven (werkt uiteraard wel op systeemdatum).

[ACM]

"de Zend decoder"
Sinds wanneer is er een decoder bij de encoder? De zendoptimiser kan idd de gecodeerde/gecompileerde sources uitvoeren, php zelf niet zonder die optimiser en die is niet standaard meegeleverd. Maar ik denk niet dat ie in staat is het te decoderen tot php-code, iig heb ik nog niet van zulke projecten gehoord

[djluc]

Waarom wil je de php zo graag op de andere server?

[Roa]

Tja, maar als ik het zo begrijp, betalen ze jou al om de code te maken, en volgens mij ook niet echt weinig. Maar jij houdt soweiso het auteursrecht, dus als ze geen contract verlegen oid, breken ze die, wat hierboven ookalstond.

Maar waar gaat het eigenlijk om? We hebben het niet over een formule die het toelaat dat auto's op regenwater rijden, maar om een script. Je kan er wel heel veel werk in hebben zitten, en op dat moment wil je eigenlijk dat niemand jou werk gaat gebruiken voor andere doeleinde, maar als ze dit echt willen, doen ze dit toch wel. Daarnaast, de essentie van internet is toch ook wel 'delen'. Hoevaak heb jij in je begin jaren niet de bron uitvoerig bestudeerd, gekopierd en aangepast. Je leert er het meeste van, en aangezien maar een paar mensen toegang hebben tot de eigenlijk php files...

[ACM]

Je hebt helemaal gelijk dat het auteursrecht en de gebruikslicentie helemaal volgens contract geregeld is en dus een strafbaar feit vormt als ze dat na een jaar de beveiliging eruit slopen ofzo.

En doorgaans zal een bedrijf ook niet zo gauw beveiligingen slopen en rechtzaken riskeren. Anderzijds is het niet onverstandig het een en ander in te dekken en dus ook de code te encoderen, om allerlei ongein te voorkomen.

Je uitleg van "essentie van het internet is delen" vind ik onzin trouwens, die essentie was wellicht delen. Maar tegenwoordig geldt dat er ook met internet geld kost en dat die kosten op een of andere manier terugverdiend worden en liefst zo veel mogelijk beperkt blijven.

Dat er nog steeds dingen "gratis" weggegeven worden is lovenswaardig, maar als alles zomaar als gratis behandeld werd zouden er toch aardig wat bedrijven het hoofd niet meer boven water kunnen houden.

[snoopy]

Een goede oplossing is idd. de source coderen met Zend Encoder (of de Zend Safeguard Suite). Hierbij is het ook mogelijk een einddatum voor de licentie op te geven en zelfs op welke machines het mag draaien.

Kost wel wat, maar dan heb je ook wat.

[Roa]

Je uitleg van "essentie van het internet is delen" vind ik onzin trouwens, die essentie was wellicht delen. Maar tegenwoordig geldt dat er ook met internet geld kost en dat die kosten op een of andere manier terugverdiend worden en liefst zo veel mogelijk beperkt blijven.

Tja, hier heb je (helaas) gelijk in, maar eigenlijk ben je met die auteursrechten al ingedekt, bouw eventueel een functie in die je informeerd als je script gebruikt word na een bepaalde datum oid, zoiets moet te maken zijn, alhoewel ook makkelijk te omzeilen

[djluc]

Nogmaals, is het niet gewoon mogelijk om de scripts op een host van jou, weet niet of je een eigen domein hebt, of een gratis host oid te plaatsen?

[chem]

Roa schreef op 25 March 2003 @ 21:35:
[...]


Tja, hier heb je (helaas) gelijk in, maar eigenlijk ben je met die auteursrechten al ingedekt, bouw eventueel een functie in die je informeerd als je script gebruikt word na een bepaalde datum oid, zoiets moet te maken zijn, alhoewel ook makkelijk te omzeilen

Gelijk hebben, en gelijk halen is iets heel anders... heeft de topicstarter wel de financieele middelen om een advocaat in te schakelen voor een kort geding? Of voor een rechtszaak?

Voor $295 (zie hier http://www.zend.com/store/products/zend-smallbiz.php ) heb je de encoder etc. te pakken als klein bedrijf. Als dat bedrag een substantieel deel uitmaakt van je totale inkomsten, dan vraag je of te weinig, of je overschat de waarde van je project

[ACM]

djluc schreef op 25 March 2003 @ 22:07:
Nogmaals, is het niet gewoon mogelijk om de scripts op een host van jou, weet niet of je een eigen domein hebt, of een gratis host oid te plaatsen?

Icheb schreef op 25 March 2003 @ 09:04:
alleen ik zit met een vrij groot probleem, de persoon eist dat het gehele project draait vanaf hun eigen server, natuurlijk vrij logisch is

De topicstart lezen is ook een kunst

[Stewie!]

Apache schreef op 25 maart 2003 @ 09:14:
[...]


http://www.ioncube.com/sa_encoder.php

die ziet er goed uit. Maar je moet dus altijd die Loader installen of includen?

[djluc]

Waarom willen ze dit zo graag op hun eigen server, je kunt toch gewoon zeggen dat je speciale serversoftware oid gebruikt, die ze zelf niet hebben oid? Of dat het goedkoper is in verband met beheer van het script? Tis zomaar een idee he.

[alienfruit]

Of op contract basis bepalen dat deze script alleen om servers mag draaien die onder jouw beheer vallen

[ Voor 12% gewijzigd door alienfruit op 26-03-2003 11:50 ]

[ACM]

Waarom nou zo'n moeite doen te proberen te overtuigen dat het op je eigen server moet??
Wat als ie geen eigen server heeft of niet de capaciteit. Of het is een pakket dat een aanvulling is op iets anders?

Ik moet er niet aan denken om na het afmaken van een of ander pakket ook nog lastig gevallen te worden met support omdat ik zo nodig het ding lokaal moest draaien ipv bij de klant zelf. Soms heeft het voordelen hoor, maar zeker niet altijd.

[alienfruit]

waz maar een suggestie

[Verwijderd]

Er zijn vast wel wat leuke dingen te verzinnen om te zorgen dat ze je scripts niet kunnen inzien, maar waarom zou je dat doen, volgens mij ben je gewoon aan het doordraaien, heb een beetje vertrouwen in de medemens.

En trouwens, maarom maak je het niet gewoon op server A en zet je het later om naar de echte server, kunnen ze in de tussentijd niet kloten en op server A kun je een rezerve kopie houden.

[Verwijderd]

Verwijderd schreef op 26 maart 2003 @ 21:00:
Er zijn vast wel wat leuke dingen te verzinnen om te zorgen dat ze je scripts niet kunnen inzien, maar waarom zou je dat doen, volgens mij ben je gewoon aan het doordraaien, heb een beetje vertrouwen in de medemens.

En trouwens, maarom maak je het niet gewoon op server A en zet je het later om naar de echte server, kunnen ze in de tussentijd niet kloten en op server A kun je een rezerve kopie houden.

Dat jij een reservekopie hebt, veranderd nog niets aan het feit dat de klant dan een kopie van de code zou kunnen maken en zelf ook gebruiken.....

[Verwijderd]

al gedacht aan asp / dll / isapi ?
ok het is geen php maarja..

[ Voor 32% gewijzigd door Verwijderd op 26-03-2003 21:30 ]

[ycode]

Dit soort dingen zijn altijd een probleem. Ik zou zeggen dat je dit juridisch dicht moet timmeren, en verder heb je met PHP alleen de encode methode om te beveiligen.
Hetzelfde geldt eigenlijk voor Java applicaties, daarvan is ook de code te krijgen en zoiets is (moeilijk) af te vangen.

Wat je ook nog als optie zou kunnen zien, is het verkopen van de broncode, dus het auteursrecht komt bij de klant te liggen, maar dan zal je verkoopprijs een stuk hoger liggen.

Als je de klant niet vertrouwd, kun je ook nog altijd een backdoor inbouwen waardoor de software niet meer werkt als ze niet betalen

[ACM]

* ACM vraagt zich trouwens af waarom de topicstarter verder niet meer gereageerd heeft na zijn vraag.
Toch jammer dat allerlei mensen proberen te helpen...

[esf]

Anders schrijf je gewoon de code en als je het bij hen upload, zorg je ervoor dat je alle newline characters en andere onderdelen waardoor de code gemakkelijk is te lezen er uit zodat een zeer brakke code ontstaat die wel werkt. Als jij nu nog wat wilt editen gebruik je gewoon je eigen, nog goed leesbare, source bestanden maar als zij iets willen editen, stuiten zij op een brij van code die niet te doorgronden is en waar ze uiteindelijk jou voor nodig hebben of waar ze meer tijd voor kwijt zijn om alles netjes over te typen dan dat ze zelf opnieuw beginnen met een script..

[drm]

esf:
Anders schrijf je gewoon de code en als je het bij hen upload, zorg je ervoor dat je alle newline characters en andere onderdelen waardoor de code gemakkelijk is te lezen er uit zodat een zeer brakke code ontstaat die wel werkt. Als jij nu nog wat wilt editen gebruik je gewoon je eigen, nog goed leesbare, source bestanden maar als zij iets willen editen, stuiten zij op een brij van code die niet te doorgronden is en waar ze uiteindelijk jou voor nodig hebben of waar ze meer tijd voor kwijt zijn om alles netjes over te typen dan dat ze zelf opnieuw beginnen met een script..

beetje code uitlijnen is zo gebeurd, hoor. Replace een { door \n{\n en } door \n}\n function door \n\nfunction etcetera. Dat is dus een manier van niks Er zijn ongetwijfeld ook wel beautifiers te vinden voor PHP.

[esf]

drm schreef op 27 March 2003 @ 11:20:

[...]
beetje code uitlijnen is zo gebeurd, hoor. Replace een { door \n{\n en } door \n}\n function door \n\nfunction etcetera. Dat is dus een manier van niks Er zijn ongetwijfeld ook wel beautifiers te vinden voor PHP.

Oke je hebt gelijk, maar het was een ideetje... Dan moeten ze in ieder geval meer doen dan helemaal niets.