PHP Compilado, bytecode o similar?

[mamcx]

Este articulo (no lo encuentro en español) articula muy buen el tema:

http://www.codeproject.com/Articles/...ntional-Wisdom

Both large and small companies usually offer knee jerk reactions. Such reactions are contrary to conventional wisdom and generally counterproductive.

Que dice: La respuesta *emocional* ante la posibilidad de la pirateria es generalmente contraproductiva, las "soluciones" que a todos se le ocurren joden la vida de los usuarios buenos y solo seran, si acaso, una pequeña barrera contra los malos, y es mejor invertir en las cualidades *que son imposibles de piratear* como: Buen soporte, calidad progresiva, actualizaciones frequentes, etc...

Este es otro ejemplo al respecto (es un software relativamente facil de piratear):

https://blogs.balsamiq.com/product/2...ftware-piracy/

------

Vamos al punto clave:

¿Cómo se puede evitar que el cliente se apropie del código u lo evoluciones por su cuenta y perdamos nuestro valor?

Que *clase de cliente* haria eso?

A- Un programador, mediocre
B- Un cliente que es tan "inteligente" que cree que se va ahorrar mucha pasta porque ya no te pagara a ti, y que contratara a otro(s) programadores pa que le sigan haciendo cambios
C- Un tipo que cree que se tapara en la plata con tu idea

NINGUNO DE ELLOS TE CONVIENE, y es mejor que te "roben" y sigan su camino.

ES MUY POCO PROBABLE QUE TENGAN EXITO.

Y te estarás re-esforzando por gente asi?

Hay un solo caso semi-positivo:

D- Un cliente ingenuo que intenta hacer un cambio o que le pasa la app a otro que cree que la necesita, pero no piensa muy bien el tema.

Eso eventualmente se convierte en un cliente de pago. Seguro. Es solo que tomara un tiempo en que note el efecto.

-----

Haz notado como en seguridad, con solo un archivo pequeñito se protege todo un sistema? El iOS de apple se basa en firnma digital, que si acaso son un Kilobytes, y basado en eso se tiene un OS seguro.

La seguridad es mas asimetrica de lo que piensas.

Te doy un ejemplo de lo que haciamos hace años en una app que casi todos nos pirateaban (y nostros: CONTENTOS!).

Era un app en FoxPro, y para manejar colegios. No haciamos ninguna de las tonterias de "proteger el codigo". Recuerda lo que enseño el padre del PASCAL:

Programa = Algoritmo + Datos

A todos se le olvidan que la parte de "Datos" esta ahi!

Asi que solo encriptabamos UN SOLO CAMPO de toda la BD. Ese campo era el nombre de la empresa. Del cual se nece4sita pa' imprimir reportes.

Si la app la pirateaban, la podian usar todo lo que quisieran, pero eventualmente tenian que llamar para que les saliera su propio nombre de empresa.

Esa era toda la "seguridad" que le poniamos.

----
Asi que en vez de pensar: Como protego TODO el codigo, piensa: Cual es el DATO mas importante, y solo protege eso. SI lo haces *bien*, no debe molestar en lo absoluto a tus clientes buenos, no te cuesta mucho en soporte y no te importara mucho si te "roban" las ideas.

[[Al González]]

Mi pregunta era porque yo no conozco los detalles de la licencia de PHP.

[roman]

Empezado por Al González

Mi pregunta era porque yo no conozco los detalles de la licencia de PHP.

Por eso me llamó la atención la pregunta. Es decir, no creo que ningún desarrollador de un lenguaje pudiera imponer la restricción de que el software producido con él sea abierto, más allá de la licencia del lenguaje en sí.

LineComment Saludos

[[Al González]]

Delphius: Comparto lo dicho por Román.

Y agrego, ¿cuántos de nosotros estaríamos mejor o habríamos llegado menos raspados a donde estamos si no hubiésemos sufrido la constante metralla de prejuicios de gente que anda por ahí escupiendo rencor?

Un abrazo al Marcelo bueno que yo conozco.

[[Delphius]]

Empezado por roman

He de confesar que no entiendo casi ni pío de lo que escribiste, pero me llama la atención esto. ¿Por qué podría ser ilegal? Al igual que se entrega un ejecutable sin código fuente, se entregaría el byte code sin el código fuente. Máxime que la propia documentación de PHP menciona que el objetivo del bcompiler es distribuir software propietario.



Caray, pues no conozco a rabata2001, no tengo idea del tipo de sotware que haga o la experiencia que tenga. Me sería difícil aventurar un juicio de valor sobre su trabajo.

LineComment Saludos

Si no entiendes te invito entonces a que curses la cátedra de Legislación Informática. Lo que he dicho se dicta en esa materia, y hay más temas que se tratan en esta. No es sólo sobre derechos de autor y de marcas, y uso de licencias. Incluye sobre teletrabajo, delitos informáticos, ley de Software (al menos en el caso de Argentina, tenemos una ley exclusiva dedica al tema), y otros que ya se me estan quedando en el tintero. Pronto tendremos que incluir temas de robótica, y derecho aplicados a esto (Tengo entendido que Japón ya ha empezado a estudiar el tema para empezar a regularlo en los próximos 5 años).

Puede ser ilegal por el hecho de que con tal de proteger su código puede llegar a aplicar herramientas o prácticas contrarias a la buena fe.
Si para garantizar tu trabajo vas a tener que estar instalando una aplicación externa, o incluso la propia aplicación hace uso de técnicas contrarias a la buena fe, a la moral y/o que puede perjudicar o afectar el propio derecho del cliente estás incurriendo en un delito.
Por mencionar ejemplos:
1. Cifrar datos que el propio usuario genera con la aplicación y que para recuperlo se obligue a usar la misma. En caso de vencimiento o cancelación de contrato y servicio, el usuario debe poder recuperar la información original si pasar nuevamente por caja. Existe una ley de protección de datos y como tal ésta garantiza que si bien el software pertenece a una empresa, más bien son los datos los que pertenecen a la contratante, o quien haga uso de dicha aplicación.
2. Puerta trasera. Sea para espiar, recabar información, etc. Es una actividad ilegal. Podría llegar a emplearse esta vía con tal de controlar que nada se haga a nuestro trabajo.
3. Instalar aplicaciones externas sin el concentimiento del usuario. Si lo combinamos con 1 y/o 2... puff.

Lo cierto es que nuestros desarrollos deben limitarse a lo que concierne y nada más. No hace falta recurrir a medidas extremas y "por fuera" para hacer que las cosas se hagan bien.
Si en la licencia se estipula que el cliente no puede ni tiene derecho a modificar el software, ya está. Lo que sigue es confiar en la buena fe. Y es ahí donde choca y se arman los problemas.
Si vas a estar dudando de tus clientes, mejor haz otra cosa. Si el cliente ya te paga, ¿para que va a tomarse la molestia de alterarlo? Si en verdad lo que está "vendiendo" es el servicio, el sistema pasa a un plano más secundario. ¡Ya te tiene a ti para que en el futuro le sigas dando soporte!

Estamos en un nuevo mundo, en donde lo que vale más ya no es el sistema sino más bien lo que puedas aportarle algo extra: soporte de mantenimiento, atención personalizada, acceso temprano a nuevas versiones, etc.

Empezado por Al González

Delphius: Comparto lo dicho por Román.

Y agrego, ¿cuántos de nosotros estaríamos mejor o habríamos llegado menos raspados a donde estamos si no hubiésemos sufrido la constante metralla de prejuicios de gente que anda por ahí escupiendo rencor?

Un abrazo al Marcelo bueno que yo conozco.

Quiero que quede claro que mi intención no es prejuzgar a rafata2001, sino de hacer notar una durísima realidad.
Todos queremos que nuestro producto sea masivo, que lo usen todos... todos creemos que hemos dado en el clavo y tenemos el "gran producto". Y no... ¡No es así! El mercado está tan saturado de aplicaciones que es prácticamente imposible pretender sobresalir por los demás. En el mundo de las aplicaciones de gestión (ERP, semi-ERP, stock, facturación y/o símiles) no hay diferencias significativas entre ellas. Ya no queda espacio que probar como para que una se destaque. Intentar pretender en la misma medida "proteger" ese bien "innovador" es fútil.

Voy de nuevo: si uno quiere hacer un software propietario y pone en su licencia que no está permitido alterar el software (ya sea que con él se incluya o no el código fuente. SI: es posible y concebible software propietario con código fuente) ya está protegido legalmente.
Si luego el desarrollador o empesa desarrolladora se entera de dicha violación, y tiene las pruebas adquiridas en forma legal y transparente (*), puede iniciar acciones legales para hacer valer su trabajo.

(*) Al menos en Argentina no son admitidas las pruebas obtenidas fuera del circuito legal. En especial si la prueba es digital. La ley de Delitos Informáticos y la del Software en nuestro país dentro de todo, a pesar de sus errores, es bastante fuerte y viene mejorándose año a año. Hace tiempo que no sigo sus modificatorias... la última a la que tuve algo de noción data del 2010. Ya hemos tenido casos que sentaron jurisprucencia al respecto.

EDITO:
Ha... y para tener en cuenta: Es fácil hacer una licencia de software, pero es mucho más fácil hacer una muy mala licencia ¡Y sin que nos demos cuenta!

Saludos,

[[Al González]]

Yo ahora sí te entendí y agradezco la aclaración, Marcelo.

Concuerdo contigo en esto:

Empezado por Delphius

Lo cierto es que nuestros desarrollos deben limitarse a lo que concierne y nada más. No hace falta recurrir a medidas extremas y "por fuera" para hacer que las cosas se hagan bien.
Si en la licencia se estipula que el cliente no puede ni tiene derecho a modificar el software, ya está. Lo que sigue es confiar en la buena fe. Y es ahí donde choca y se arman los problemas.
Si vas a estar dudando de tus clientes, mejor haz otra cosa. Si el cliente ya te paga, ¿para que va a tomarse la molestia de alterarlo? Si en verdad lo que está "vendiendo" es el servicio, el sistema pasa a un plano más secundario. ¡Ya te tiene a ti para que en el futuro le sigas dando soporte!

Como en todo, la agresividad de palabras aleja al oyente o al lector. Y eso a veces hace que no tomemos muy en serio tus comentarios, en los cuales, en contraste, casi siempre hay buenos puntos más que rescatables. La esperanza está en palpar hoy que esa agresividad va disminuyendo para dar paso a las palabras que de verdad tienen valor.

Un abrazo.

Al González.

[roman]

Empezado por Delphius

Por mencionar ejemplos:
1. Cifrar datos que el propio usuario genera con la aplicación y que para recuperlo se obligue a usar la misma. En caso de vencimiento o cancelación de contrato y servicio, el usuario debe poder recuperar la información original si pasar nuevamente por caja. Existe una ley de protección de datos y como tal ésta garantiza que si bien el software pertenece a una empresa, más bien son los datos los que pertenecen a la contratante, o quien haga uso de dicha aplicación.
2. Puerta trasera. Sea para espiar, recabar información, etc. Es una actividad ilegal. Podría llegar a emplearse esta vía con tal de controlar que nada se haga a nuestro trabajo.
3. Instalar aplicaciones externas sin el concentimiento del usuario. Si lo combinamos con 1 y/o 2... puff.

Perdón, pero es que tú estás presuponiendo demasiadas cosas. Por supuesto que lo que dices puede ser ilegal, pero no sé de dónde concluyes que alguien, por el sóo hecho de querer no mostrar su código fuente, puede tener una intención perversa.

Delphi no muesra el código de muchas de sus partes y no por eso concluimos que hace algo ilegal.

Creo que hay que tener cidado en la forma e que se hacen recomendaciones, con las que puedo estar de acuerdo y pueden ser útiles, pero que resultan ofensivas para las personas.

LineComment Saludos

[mamcx]

Empezado por roman

por el sólo hecho de querer no mostrar su código fuente, puede tener una intención perversa.

Pero en este caso es distinto. Esta hablando de *encriptar* los datos a los que tenga derecho el usuario, sin un medio de recuperarlos luego:

Empezado por Delphius

1. Cifrar datos que el propio usuario genera con la aplicación y que para recuperlo se obligue a usar la misma.

Y para lo de los binarios:

Empezado por Delphius

Voy de nuevo: si uno quiere hacer un software propietario y pone en su licencia que no está permitido alterar el software (ya sea que con él se incluya o no el código fuente. SI: es posible y concebible software propietario con código fuente) ya está protegido legalmente.

-----

Basicamente, la ley siempre se pondra del lado del consumidor (y de las grandes empresas!) asi que lo que no se especifica en los contratos siempre se presume de acuerdo a como se interpreta la ley, no a como *creen* las partes que es.

Tambien hay ideas como el obrar de buena o mala fe, el de probar las cosas y otros asuntos que lo hacen escabroso... es por eso que toda empresa de software -incluyendo las organizaciones open source- TIENEN QUE TENER asesoría legal, porque la ley esta hecha pa' joder a a quien no la conoce...

-----

Si hay algo que discutir seria esto:

Empezado por Delphius

El mercado está tan saturado de aplicaciones que es prácticamente imposible pretender sobresalir por los demás. En el mundo de las aplicaciones de gestión (ERP, semi-ERP, stock, facturación y/o símiles) no hay diferencias significativas entre ellas. Ya no queda espacio que probar como para que una se destaque. Intentar pretender en la misma medida "proteger" ese bien "innovador" es fútil.

En el momento en que se cumple esta condición:

no hay diferencias significativas entre -las opciones del mercado-

Es una señal inequívoca de que el mercado esta "pulpito" para una tecnología disruptiva:

https://es.wikipedia.org/wiki/Tecnol...ADa_disruptiva

Se definen como tecnologías disruptivas o innovación disruptiva aquellas tecnologías o innovaciones que conducen a la desaparición de productos, servicios que utilizan preferiblemente una estrategia disruptiva frente a una estrategia sostenible, a fin de competir contra una tecnología dominante buscando una progresiva consolidación en un mercado.

Lo que si es cierto, que dice Delphious y que creo que concordaríamos todos, es que por regla general la gente se enfoca en los aspectos errados, ignora otros muy importantes o sobredimensiona la importancia de sus aportes, cuando si acaso, son ideas innovadoras... conocidas de hace mucho.

O su ejecución es pobre.

-----

El problema de hacer una VERDADERA innovación es que es difícil de predecir realmente como es. Y ademas, sera en parte "similar" a lo anterior (porque nada se construye de cero), pero tendra unos cuantos parametros que cambien de forma radical la ecuación.

Uno de los ejemplos mas recientes es el iPhone. Cuando entro, estaba la misma ecuación:

no hay diferencias significativas entre -las opciones del mercado-

Y era uno de los mercados mas duros de penetrar. Casi todos en ese entonces dudaban - con muy buenos argumentos- que Apple no hiba a lograr nada.

Pa' rematar, superficialmente el iPhone no *parecia* tan innovador, al fin casi todo lo propuesto ya existia de una u otra forma en el mercado, y su concepto era conocido mas de una decada antes...

Lo mortal de las disrupciones es que su aspecto definitorio es "invisible" para quien esta demasiado embeido en la forma actual de ver las cosas... al grado que aun hoy, años después, habra quien le achaque esto al "marketing" y que Apple se aprovecha de idiotas...

En fin.

------

Yo si creo que hay mucho que hacer e innovar en el mercado de la IT tradicional, y de hecho, ya se esta viviendo muchos aspectos disruptores.

El mas notable y sonado ahora, es la nube.

El que le sigue y esta creciendo, es el "BIG DATA".

Pero aun no se ha dado la llegada de un producto tipo "iPhone".

Como sera esa innovacion?

No se!

Sera parecida a lo que hay ahora? Seguro. Lo dificil es saber cual es el angulo disruptor que esta traera...

-----

Y mientras tanto, ya que la mayoría de las apps son mediocres, hacer lo mismo de siempre, pero bien, es mas que suficiente pa' mantener a flote a cualquier desarrollador.