¿Cómo evitar la reventa de la fuente PHP? [cerrado]

Question

¿Tienes una estrategia para esto? Si vendo un sistema web a un cliente y de conformidad con el acuerdo legal, el cliente no puede venderlo a otros, ¿cómo puedo estar seguro de que no lo hace de todos modos?

Mi primera idea es algún tipo de clave que debe estar en el directorio raíz, y ese archivo solo es válido para ese dominio específico.

¿Otras ideas?

ACTUALIZACIÓN 1 Estoy de acuerdo en que esto es principalmente un problema legal. Pero los hechos son: tengo un cliente que me compra este sistema para venderlo a otros. Y quiere que este sistema funcione para que le resulte fácil obtener ganancias. La capacidad de empaquetar el servidor web y venderlo es parte de la especificación.

ACTUALIZACIÓN 2 Otro punto de vista es esto . En ese caso, es difícil demostrar cuánto del software revendido proviene de mi sistema original.

ACTUALIZACIÓN 3 Ofuscarme no es una opción para mí, realmente lo odio.

Answer 1

Algunos usan un ofuscador como Zend Guard pero sinceramente creo que las soluciones técnicas para este tipo de problema están tan condenados como DRM para contenido de audio y video. Básicamente, lo que les está dando debe funcionar, por lo que es solo un problema técnico hacer que funcione de la manera que no desea.

Sus recursos aquí son (en mi humilde opinión) legales, no técnicos. Tiene un contrato con el cliente que establece lo que puede y no puede hacer. Tienes un buen abogado que redacta ese contrato. Si no lo acatan, entonces tienes que llevarlos a los tribunales.

No cuente con ningún tipo de ofuscación o protección de copia como ningún tipo de garantía.

Esto es particularmente un problema para los lenguajes de secuencias de comandos porque (a pesar de Zend), son fundamentalmente métodos de distribución de texto sin formato. Java y .Net y otros lenguajes compilados de bytecode tienen un poco más de protección, pero también se pueden desmontar en código intermedio (pero la ofuscación es más útil aquí). Los lenguajes verdaderamente compilados (por ejemplo, c, C ++) tienen la mayor protección de todos, ya que desmontar un binario de 50 meg en el código ensamblador generalmente no es tan útil.

Incluso entonces no hay garantías. Si no se siente cómodo con eso, debe seleccionar cuidadosamente a sus clientes, vivir con el posible incumplimiento de contrato (y la posible aplicación que podría obligarlo a seguir) o encontrar otra línea de trabajo.

Answer 2

Creo que la única manera de estar seguro es ofrecer su producto como una solución alojada para que el cliente nunca tenga acceso al código. Si lo construye con este objetivo en mente, aún puede tener revendedores y dejarlos pelar el sistema para que se vea como su propio producto.

Esto funciona bien donde yo trabajo, en teoría, los clientes pueden licenciar el código para que se ejecute en su propia infraestructura, pero tiene un precio a un nivel tal que solo las grandes empresas están preparadas para pagar, y las grandes empresas en general están más preocupadas con sutilezas legales, por lo que es menos probable que simplemente se escapen con su trabajo.

La gente está muy preparada, feliz de ir con soluciones alojadas si el precio es correcto y puede tener beneficios para todos. El cliente no tiene que preocuparse por configurar todo y también tiene la seguridad de saber que si algo necesita ajustes, nosotros (los desarrolladores) estamos allí para hacerlo.

Answer 3

Este es un problema social, no técnico. Tienes derecho de autor de tu lado; No se necesita más. (Todas y cada una de las soluciones técnicas equivaldrían a DRM, que es inherentemente ineficaz).

Con respecto a su actualización: Entonces, básicamente, se convierte en un proveedor de DRM para este cliente suyo. Entonces: ¿El cliente entiende que DRM no es efectivo? Intente educarlos antes de perder tiempo en la implementación.
Si el cliente se mantiene firme, analizaría detenidamente lo que están haciendo los proveedores actuales de DRM. P.ej. mucha mano, algo de ofuscación y, erm ... no sé ... ¿qué más hacen? De cualquier manera, puede estar seguro de que cualquier solución que implemente se deshacerá en menos del 10% del tiempo que le llevó implementarla, por lo que debe dedicarle la menor cantidad de tiempo posible. (Antes de que se editara, escribió "Está en la especificación" acerca de "estar seguro de que el sistema no se vende": esto podría significar que ha aceptado construir algo que es técnicamente imposible (nunca puede ser seguro ), y requeriría que pases una cantidad infinita de tiempo construyendo algo que se acerque ...)

Puede investigar que la aplicación se ponga en contacto con algún registro central cuando se ejecute por primera vez (con huella digital incorporada, diferente para cada venta, para que sepa quién transmitió su código). De esa manera, su cliente puede averiguar dónde se ejecuta la aplicación y tiene la posibilidad de contactar a quienes la usan sin permiso. (Potencialmente convirtiéndolos en nuevos clientes que pagan.) ¿Tal vez dar a dicho repositorio central la capacidad de enviar una señal de cierre? Sin embargo, eso da realmente miedo, y las preocupaciones de responsabilidad serían enormes; evitar si es posible.

Answer 4

Ofuscar la fuente es más problema de lo que vale, en mi experiencia, a menos que esté tratando de mantener en secreto algún algoritmo complicado.

Sugeriría hacer lo siguiente:

1. Asegúrese de que usted y su cliente y sus abogados entiendan y estén de acuerdo con su contrato.
2. Inserte una breve declaración de copyright como comentario en cada archivo fuente.
3. Inserte avisos de derechos de autor en las páginas web generadas (a través de plantillas de página o código php) como comentarios HTML, por lo que una 'fuente de visualización' demostrará que su código se encuentra en una aplicación sin licencia.

Si está realmente preocupado, y esta no es una aplicación exclusiva de la intranet, puede ampliar (3) e insertar texto oculto único en las páginas que Google ve pero no los usuarios.

Nada de esto detendrá a un ladrón determinado, pero ayudará a disuadir y detectar "accidental". robos.

Answer 5

La forma correcta de prohibir la reventa de su software es a través de restricciones legales, no técnicas. Haga que su cliente firme un contrato donde acuerde no revenderlo.

Las medidas técnicas de prevención universalmente empeoran el producto, también en el sentido técnico, y eso disminuye el valor para los clientes. Cuanto más fuerte sea la protección técnica, mayor será la molestia.

Por ejemplo, suponga que el cliente legítimamente quiere cambiar su nombre de dominio. ¿Deberían comprar una nueva copia? Yo creo que no. Si les dice cómo cambiar el archivo de claves para que coincida con su nuevo dominio, pueden usar esa información para permitirles revender. Sin embargo, la protección legal se aplica independientemente de los trucos técnicos que se les ocurran.

Answer 6

Pero un problema es cuando no tienes miedo de que el cliente revenda lo que has hecho, listo para usar, que los abogados pueden rastrear. El problema puede ser que el cliente lo esté refactorizando. Quiero decir, tomar mis muchas horas de trabajo y cambiar un par de cosas y llamarlo suyo ... Véndelo por una pequeña cantidad más barata y gana el negocio ...

Es por eso que estoy buscando soluciones técnicas para proteger mi trabajo. Posiblemente también me ayudará a mantener al mínimo la facturación de los abogados, lo que es una gran cantidad de cambio de tenerlo para proteger mi trabajo.

Answer 7

  

    

¿Cómo puedo estar seguro de que no hace eso de todos modos?

  

No puedes evitarlo ... punto. Si alguien tiene la fuente, no hay forma de detenerlo ... solo puede recurrir a castigarlo si lo tiene.

Tal vez su contrato, además de prohibirles revenderlo, tenga un precio asociado con la reventa, es decir, algo como 10x o 20x de lo que pagaría normalmente, más los gastos legales, si es necesario, para que paguen ... De todos modos, si eligen hacerlo de todos modos, tienen un buen pedazo de papel, con su firma que ya tiene un buen precio preestablecido que deben pagar si continúan vendiéndolo.

Answer 8

No he visto mención de Ioncube y me preguntaba si hay una razón para no usarlo.

Sí, cuesta dinero configurarlo y sí, requiere que se instale una biblioteca del lado del servidor (me atrevo a decir que la mayoría de los hosts en estos días ya lo tienen en funcionamiento) pero sí permite restricciones de dominio y restricciones basadas en el tiempo.

¿Quizás incluso podría usarlo junto con PHPAudit?