entregar programas con el codigo

[DarkByte]

Yo todavía no he hecho ninguna aplicación que haya vendido, pero yo estaría deacuerdo excepto si:

-El programa requiere pago cada X tiempo.
-El código fuente pudiese ser peligroso en malas manos (ej. el troyano que tiene nuestro amigo delphi.com.ar en su web).

[marcoszorrilla]

He votado que sí, aunque pienso que no. Vaya lío no. Pues es muy simple, si negociamos con el cliente por el motivo que fuere, por ejemplo que la empresa tiene un programador que posteriormente desea hacer modificaciones sin contar con nosotros, que quiere ponerse a salvo de una ruptura y que le dejemos literalmente tirado ante nuevos cambios que deseen.....

En conclusión programa ejecutable precio: xxxxxxx
Programa ejecutable + fuentes Precio: xxxxxx + yyyyy

En estos momentos me encuentro haciendo un mantenimiento de unos programas unos hechos en Clipper y otros en VB, porque los adquirieron con el código Fuente y luego hubo ruptura.

Problema, por ejemplo en Clipper hay una serie de funciones que se encuentran en una biblioteca y no hay código fuente, esto te lleva a hacer un montón de pruebas para poder eludir la llamada a dichas funciones y construir otras equivalentes.

Por lo tanto lo del código de fuente aun estando en posesión del mismo sino está suficientemente documentado y no se utilizan funciones propias desprovistas del mismo permite mantener la aplicación sin muchos problemas.

Un Saludo.

[jachguate]

Yo regularmente invierto mucho tiempo en la creación de bibliotecas de funciones. Regularmente estas bibliotecas contienen el producto de cientos de horas de investigación, ensayos, pruebas, en fin... mis mas geniales ideas

Cuando un cliente quiere un sistema con código fuente, tendrá el código fuente de su aplicativo, con vínculos a mis bibliotecas, de las cuales nunca he revelado el código fuente. La razón...... podria llamarse "celos" profesionales. Eso si... nunca encierro la funcionalidad real del programa en estas bibliotecas... aunque si mucha parte del procesamiento de datos a bajo nivel (procesamiento de cadenas y otros tipos de datos, alguna interacción con bases de datos (digamos para hacer un lookup programático, etc.).

Hasta la fecha, siempre he hecho mi mejor esfuerzo porque haya documentación disponible sobre estas rutinas para los programadores que eventualmente le puedan dar mantenimiento al sistema, evitando que sean "Cajas negras" de las que se ignore el comportamiento. Es una forma de encapsular la funcionalidad, darle al cliente lo que necesita (independencia) y proteger de alguna forma ciertas ideas.

Una cuestión que siempre me ha preocupado en este sentido, es perfeccionar un contrato que efectivamente "cierre" las puertas legales para la explotación no autorizada de estos fuentes. Lease, un programador inescrupuloso que se adueña de los fuentes para su beneficio personal, o un empresario que contrata programadores para adaptar los sistemas y usarlos en otras compañias (sin que esto esté previsto en el trato original).

Es un asunto que hay que tener en cuenta al revelar los fuentes... pues allí ya no hay mecanismos de seguridad "cerrados" que nos protejan de la piratería...

Hasta luego.

[haron]

hola.

lo que mas puede fastidiar a un escritor, programador, cientifico, etc... no creo que sea que otras personas puedan usar sus conocimientos y descubrimientos, sino que no se les reconozca su trabajo.

en particular creo que la informacion es como el aire o el agua, un derecho del ser humano, no un privilegio.

pero debe siempre reconocerse la autoria de los creadores. eso es para mi proteger la propiedad intelectual del autor. yo siempre que utilizo una funcion que no es mia indico de donde me la baje y el autor, y me gustaria que fuese asi si alguien utiliza un trozo de codigo mio.

una curiosidad:

he estado mirando los programas OpenSource de mi nuevo sistema operativo RedHat y en casi todo ellos viene la opcion 'creditos', indicando quienes participaron en la aplicacion (traductores, programadores, etc...)

no pasa lo mismo con windows.