Foro - Perl en Español

Me encuentro en un pequeño desafío.

Un señor se acercó a mí y me pidió para que le hiciera un programa de Control Stock de mercaderías. Nada muy complejo, solamente entrada-salida, reportes, informes, con cosas básicas.

Le había consultado a un amigo, y me dijo que para eso están los otros lenguajes y plataformas, como Visual FoxPro (casi obsoleto), Visual .NET, Delphi, etc., es porque se puede compilar, crear el ejecutable y demás archivos para que no se pueda obviamente modificar el código fuente por el cliente, ya que se trata de un programita comercial como cualquiera descargada de Internet y usarlo sin ningún problema.

Pensé en dos alternativas:
1. Usar Gtk o, algún otro módulo o soporte para hacerlo de manera 'Visual' a Perl, para después empaquetarlo con el módulo PAR y protegerlo con Armadillo.
2. Crear un pequeño servidor local (localhost); para que el cliente lo maneje desde el navegador, que obviamente implicaría un poco del uso de JavaScript en mi codificación.

¿Pero cómo podría proteger el código fuente?

Es porque, para mí, aprender un nuevo lenguaje me cuesta tiempo y dinero.

¿Existe alguna otra alternativa?

Gracias.

El código fuente es de tu cliente, porque por eso te paga. Que firme un contrato por el cual el código fuente es de su entera propiedad y con él puede hacer lo que quiera.

Si quieres quedarte con la propiedad intelectual del código fuente, entonces lo que le estás vendiendo al cliente es una licencia de uso, por lo que el precio será más bajo. Entonces, deberéis firmar un contrato por el cual él reconoce que la propiedad del código es tuya y por lo tanto no le das permiso más que para usar el programa, pero no distribuirlo ni modificarlo. Y te comprometes a darle mantenimiento gratuito frente a fallos de programación durante dos años (normativa europea).

Si no cumple las clausulas, pues os subrogáis a lo que diga el juez correspondiente.

Búscate un modelo de contrato de servicios de programación de software.

Y todo esto es independiente del lenguaje.

Aprender lenguajes y destreza informática no es coste: es inversión.
Cuanto más sepas, más puedes cobrar.

Gracias explorer.

Sí, es cierto, es una inversión. También he visto en algunos hilos que un programador todoterreno encaja en cualquier parte.

Por otra parte, por aquí, la Justicia no es robusta ni sólida. Al menos para Derechos de Propiedad Intelectual, pero Gracias a Dios espero que esté cambiando.

Ahora, supongamos que lo hice. Al cliente le gustó y quedó conforme con el programa. Pero con el correr de los tiempos, otra persona (tal vez empresario) lo vio y le gustó. Y me propone para hacerlo para su minimercado y más adelante supermercado. Para estos dos últimos: ¿cuál de las dos alternativas que había mencionado anteriormente me convendría empezar? ¿Existe otra?.

Aquí en mi país no existe leyes que rigen sobre código abierto pero sí proyectos de ley. Pero cuando hay problema el que gana es aquel que tiene más plata (hablando de pequeños percances o alborotos). Es por eso que la gente de aquí al hacer este tipo de trabajos (mencionado anteriormente) no hacen con código abierto. "Se piensa" que es menos problemático por causa de las leyes. Todos optan por compilarlo. Y eso sin contar que las grandes empresas como los supermercados contratan programadores de otro país, como Brasil y Argentina.

Y más aún cuando ellos miran a Perl como un lenguaje extraño: Una orquídea rara.

Si la justicia no es buena, debes reducir la complejidad de la relación contractual, para evitar problemas futuros. Por eso, le convences al cliente de que le vas a cobrar 5 veces más caro el desarrollo del programa, pero a cambio le cedes el código fuente, como propiedad.

Desde el punto de vista del cliente, le estás demostrando que no quieres que sea un cliente cautivo (busca la palabra cautiverio en la página Mapa estratégico de Wikipedia). Si no lo ve, se lo explicas. Le cuentas que no le estás obligando a nada para el futuro.

A cambio, tu eres libre de hacer otra aplicación para otras empresas. No podrás usar el mismo código fuente... pero siempre hay que hacer modificaciones para ajustarlas a cada cliente... todo consiste en dar una solución muy ajustada a cada uno de ellos, de tal manera que no sean fácilmente trasladables. No te podrán acusar de vender la misma aplicación. Aparte, de lo que has aprendido en hacer una, al hacer la siguiente le incorporarás lo que hayas aprendido hasta entonces.

Dar una buena imagen es importante.

Si en cambio sigues haciendo lo de los demás, lo de dar el código cerrado, los clientes saben que dependen de ti para las próximas modificaciones o si aparecen errores. Al menos, por Europa, eso está cada vez más peor visto. Nadie quiere ser cliente cautivo.

Si el cliente no quiere pagar 5 veces por tener la propiedad intelectual del código, entonces le dices que tu te quedas con la propiedad del mismo y que solo le cobrarás una licencia de uso. Y además, que sepa que eres libre de licenciar de nuevo ese programa a la competencia de ese cliente

En todos los casos, en el presupuesto incluyes los posibles casos de resolución de errores debidos a ti, en un periodo de dos años. Tu pones una cláusula diciendo que le das una garantía durante ese tiempo, y el cliente lo agradecerá.

Si el cliente paga por el código fuente, se lo das en claro. Si el cliente lo quiere compilado, valora antes el trabajo a mayores que te costará realizar eso (herramientas, pruebas de instalación, tiempo, etc.).

Si el cliente solo quiere una licencia de uso, se lo das compilado (en tu país, en otros no es necesario como te he explicado antes).

Formas de proteger Perl hay unas cuantas, empezando por Acme::Bleach... por estos foros se comentan algunas.

Si las grandes empresas contratan programadores de otros países, es por la diferencia de sueldo, claro.

En cuanto a lo raro que parece que es Perl, en algunas ocasiones puede ser una ventaja: como es muy difícil encontrar programadores de Perl, de alguna forma estás creando un cliente cautivo: dependerá de ti para el futuro, incluso aunque le des el código en claro

De todas formas, piensa que si se quiere, se puede decompilar todo.

Y todo lo comentado arriba no tiene nada que ver con el código abierto.

Gracias explorer.

Ya veo todo claro. Ahora me dí cuenta que había hecho preguntas tontas acerca de compilar un código.

Por cierto, este último post tuyo, lo copié y lo guardé como un documento .doc para cuando lo necesite.

Fíjate que he encontrado un hilo en perlmonks.org al respecto. Bueno, más bien hablando de que es mejor usar PAR que perl2exe, pero que no deja de ser curioso algunos mensajes:

Parece ser que compilar el código no es por seguridad, porque, obviamente, no aumenta la seguridad; ni por un tema de licencias: los Chicos Malos no las respetarán y te copiarán el código o el programa de todas formas, mientras que los Chicos Buenos siempre respetarán tu trabajo.

Se esconde el código por vergüenza: para no enseñar el código feo y desastroso que el programador ha creado. No quiere mostrar que está vendiendo un programa mal hecho por un precio muy alto.

, y eso hablando del año 2003. Me fijé en la línea:

"For details, see the report from net-security's page."

Lo más sorprendente está en su mensaje:

"Perl programs "compiled" into EXEs with Perl2Exe can be decompiled and full, unadulterated source code extracted. "

Aún así no me convence Perl2Exe como mi main tool en sus nuevas versiones.

Por cierto explorer, se acertó en el blanco: al menos para mi territorio. Aquí hay bastantes Chicos Malos. Y eso no solamente hablando de un sobornador cercano, sino del propio cliente que quiera joderme modificando el código fuente, de manera que se ajuste a su "montaje" para así poder acusarme de cualquier problema que se presente.

Hay varias soluciones para ese tipo de clientes:

• Que no sea tu cliente. Pasa de él. Hay clientes que es mejor dárselos a la competencia
  
• Si llegas a un acuerdo con él en el tema del periodo de mantenimiento, una de las clausulas debe decir que solo tu tienes permiso para modificar el código. Si no se cumple ese punto, puedes cobrarle los gastos a mayores del arreglo. A continuación:
  
  
  • Cada vez que visites al cliente y dejes una versión nueva del programa, tomas nota del número de versión y de la suma de control de esa versión. Así sabrás, la próxima vez que le visites, si el código lo ha modificado sin tu permiso. Si no tienes facilidades para calcular la suma de control, te vale con registrar el tamaño y fecha del fichero.
    
  • Si lo ha modificado, pues ya sabes que tienes que cobrarle el arreglo.
    
  • Si no quiere pagarte por el arreglo, no hay problema. Al estar en tiempo de garantía, le dejas con la última copia que sabes que funcionaba. Sobreescribes su programa modificado, le avisas de que ya está funcionando y que la próxima vez le tendrás que cobrar por los arreglos a mayores. Te vas y punto.
• En cada visita que hagas, cada vez que le instales una versión del programa, debe firmarte un papel en el que diga que está conforme con el arreglo (se supone que comprobará el funcionamiento del programa). Así, te aseguras de que tienes su firma diciendo de que está de acuerdo con esa versión. Él no tiene que preocuparse de si hay más errores, porque sabe que aún está en periodo de garantía. En caso de conflicto, vais a los tribunales y tu vas con los papeles firmados. Fíjate que esto lo hacen los profesionales de mantenimiento, así que los informáticos, con más razón.
  
• Si se acaba el periodo de garantía, como está indicado en el contrato de servicio, tú ya no eres responsable de nada más. Si el cliente te llama, le ofreces un contrato de mantenimiento, que puede ser por un periodo de tiempo o por obra (un detalle o módulo cada vez). El mantenimiento anual tiene un costo fijo. El mantenimiento por obra es lo que te cueste desarrollarlo. Por cada cambio que hagas, incluyes en el precio y en el recibo de mantenimiento un periodo de garantía de 3 meses, relativo solo a la parte nueva que has tocado.
  
• Si sospechas que el cliente no te va a pagar nada por el trabajo, entramos en un terreno más divertido. En el contrato de servicio pones que te tiene que pagar el 50% del servicio, por adelantado, en concepto de previsión de gastos (tu tienes que comer todos los días). El 25% a la entrega del producto y el 25% restante una vez firmado el recibí de conformidad (el cliente firma un documento que dice que ha recibido un programa y que está de acuerdo con su funcionamiento, y que por eso abona la cantidad estipulada, sabiendo también que está cubierto por la garantía de funcionamiento de dos años a partir de la fecha de conformidad).
  
• Si el cliente no paga el 50% por adelantado, te buscas otro cliente.
  
• Si a la hora de entregar el producto, no te paga o sospechas que no va a pagar el 50% restante, le avisas de que dispone de un mes para hacerlo. Nada más.
  
• Si pasa un mes, y el cliente no te ha pagado, el programa, por sí mismo, activará una bomba lógica, borrando todas las bases de datos, todos los ficheros de configuración, todos los directorios y subdirectorios instalados y, finalmente, él mismo. Debe desaparecer todo lo relativo al programa.
  
• Si el cliente te llama y te dice que qué pasa, tu respondes que quizás haya sido un error del programa. Le comentas que llevas un mes esperando a que te pagara y que mientras tanto no has repasado el funcionamiento, por lo que quizás se te debió olvidar algo. Le dices que no se preocupe: que te abone el 50% restante y que le instalarás de nuevo el programa, funcionando bien. (*)
  
• Si el cliente sí que te paga en la fecha fijada, tienes que desactivar la bomba, pero sin que el cliente se entere. Puedes hacerlo de dos formas básicas: te pasas cualquier día antes de la fecha de explosión e instalas una nueva versión -sin bomba- del programa. Al cliente le dices que es una versión "mejorada" y "con errores arreglados". Te lo agradecerá. Otra forma es, por teléfono, pidiéndole que realice una tarea especial (puede ser elegir una serie de opciones de menús o pulsar unos botones en un orden concreto), nada frecuente, pero que, internamente, desactivará la bomba. La excusa que darás es porque quieres comprobar el funcionamiento del programa, y parece que está bien. Te lo agradecerá y tu te habrás ahorrado un viaje.

Naturalmente, jugar con bombas, no es de niños e insensatos. Debes saber qué es lo que haces. Estar muy seguro de que va a funcionar. Y de que se va a desactivar... Piensa en lo que debes hacer en caso de que no falle el procedimiento de cancelación y se pierda todo. Por eso, la primera opción (nueva versión del programa), es la más segura.

Fíjate que esto es muy parecido a como funcionan las licencias de los programas antivirus: si no pagas, dejan de funcionar.

Se pueden comentar más cosas, pero la regla es sencilla: cuanta más desconfianza, más firmas en danza.

P.D. Estas ideas no están nada ordenadas. Se deberían poner en forma de flujo, pero ahora no tengo tiempo. Es lo que recuerdo de mi experiencia acumulada... que no tiene porque ser la más idónea, desde luego.

(*) Yo he visto casos más trágicos: la bomba lógica explosionó llevándose por delante la facturación, inventario y datos de personal de dos meses de trabajo que el programa gestionaba. Y cuando el cliente llamó, chillando, el programador contestó que no sabía de que le hablaba, que él nunca le había hecho un programa, negándolo todo. Como la operación se realizó sin papeles ni contrato, y la bomba borró todo, el cliente no pudo demandarle por no tener pruebas. El cliente era un conocido caradura de la ciudad. Aprendió una lección y al resto de programadores nos respetó más a partir de ese momento.