rodrigo escribió: > El 17/04/05 22:49:14, Guillermo O. Burastero escribió: > [...] > >> Como información adicional, la licencia de cualquiera de las >> versiones de BK, impedía a cualquier usuario participar en el >> desarrollo de un software competitivo del mismo (otro SCM) hasta un >> año después de haber dejado de usar BK. Un poco excesiva no ? Creo >> que ni M$S tiene una cláusula así en sus licencias. > > > supongo que esto se aplica explicitamente al los que firman, ¿o los > que mandan un parche tambien quedan condenados? > Según H.V.B., en otro post de esta lista sobre este tema, la restricción de no intervenir en ningún desarrollo similar alcanzaba no solo a los usuarios de BK sinó también a los empleados de la firma usuaria. Una verdadera exageración IMHO. Es como si por usar MS-Word no podrías participar en ningún desarrollo de un procesador de textos. O por acceder como cliente del DBMS MS-SQL no podés hacerlo con tu propio cliente, con un protocolo conocido y público, y para peor, tampoco podés participar en ningún desarrollo de una base de datos.
> [...] > >> ... Esto lo hizo sin >> acceder al programa BK y menos a su código (por lo tanto no está >> alcanzado por su restringida licencia al no ser usuario del mismo), > > > ¿como pudo probar que lo que hacia funcionaba, sin acceder al programa? Porque lo que estaba tratando de hacer primero era un cliente del repositorio BK, no el servidor BK. De entrada solo aspiraba a conectarse con él. Es como si usas una base de datos propietaria, donde guardas datos tuyos y la interfaz de conexión para acceder a esos datos solo está, sin ninguna documentación, en un programa binario cliente que es del mismo proveedor de esa base de datos. Lo que intentó o logró hacer Tridgell es poder acceder a ese servidor BK desentrañando el protocolo y API que BK usa para esto y crear un programa cliente FOSS. Esto es lo que se llama interoperabilidad y, que yo sepa, siempre fue un argumento y objetivo deseable contra los productos monopólicos. > > [...] > >> Linus, a mi entender en forma muy injusta, se alineó con su amigo >> McVoy y cargó toda la responsabilidad de este problema sobre >> Tridgell, pero yo me pregunto: ¿Por qué está bien que se halla >> desarrollado SAMBA así, estudiando el protocolo SMB de MS -un >> programa "propietario" o no libre- y no está bien que se haga lo > > > ¿SMB no fue hecho en una mezcla IBM-MS? > No, extraigo del artículo que refiero abajo: "el protocolo que Samba implementa fue primero inventado por Barry Feigenbaum de IBM en 1983, lo llamó originalmente "BAF" (sus iniciales), pero luego cambió a SMB antes de su primera versión oficial. El término CIFS o "Common Internet File System" fue acuñado por MS en 1996 como un ejercicio de marketing en un intento de combatir la amenaza percivida por parte de Sun Microsystems después de su anuncion del WebNFS. El termino "pegó", y ahora el protocolo SMB es frecuentemente llamado CIFS. Los dos nombres se refieren al mismo protocolo, como es fácilmente desmostrado conectando un cliente actual Microsoft CIFS a un servidor Samba SMB de 1992." La implementación de SMB por parte de MS era secreta, no estaba documentada para terceros. Sugiero leer para mayores precisiones: "Myths About Samba" by Andrew Tridgell en http://www.groklaw.net/article.php?story=20050205010415933 y "How Samba was Written" (También conocido como "The French Cafe Description" en http://samba.org/ftp/tridge/misc/french_cafe.txt >> mismo con otro programa propietario (BK) ? También muchoS drivers >> propietarios de "analizan" o se hace ingeniería reversa de los mismo >> y a ninguno (que yo sepa) se le ocurre que eso está mal. > > > [...] > > Si los de BK no quieren que la gente que use el programa trabaje por > un anho en proyectos similares, sera por que puede que los usuarios > le cuenten a otros como funciona el programa: capaz que cada vez que > ocupan una funcion, el programa chorree su codigo fuente ... > > y si no quieren que se sepa como funciona su protocolo, ¿por que no > ocupan un protocolo encriptado? por lo menos asi queda bien claro que > no quieren compartir con los demas... > El protocolo encriptado, si es robusto y está bien implementado, solo hace privado el intercambio de datos para terceros que intentan analizar, y aun hacer criptoanalisis, accediendo solo a la información encriptada, tipicamente fizgoneando en el canal de comunicación. Si el proceso de encriptación no se hace desde un hardware inviolable (temperproof), en donde resida por ejemplo la clave privada que se utiliza para generar la clave criptográfica simétrica temporaria que se usará durante la sesión criptográfica, esta clave privada debe necesariamente estar de algún modo en la memoria del procesador durante la ejecución y antes en el código ejecutable del programa cliente y de cualquier manera usando técnicas típicas de la ingeniería reversa de software como debuggers, desensambladores y otras herramientas de análisis de código objeto para inpeccionar directamente el código ejecutable, se podrá llegar a conocer la clave privada y por lo tanto desencriptar el protocolo cifrado. Lo que está fallando acá es el modelo de seguridad y no el algoritmo criptográfico que bien puede ser muy robusto y seguro. De este modo se quebró el sistema de protección de contenidos de los videos en DVD, llamado Content Scrambling System (CCS). El hacker que lo hizo, creo que en 1999, analizó un programa reproductor de DVD para Windows que contenía la clave de descifrado (hay unas 400 posibles claves que funcionan, no me pregunten para qué, ya que vasta con conocer cualquiera de ellas para poder desencriptar cualquier DVD cifrado con CCS) y luego escribió un programa que llamó DCCS con código público, para felicidad de todos los usuarios de Linux que no podían ver en su querido sistema sus DVD favoritos o bien hacer un backup de los DVD -legítimamente adquiridos, por supuesto-, etc. Y ese fue el fin de la eficacia de la protección de contenidos CCS por el cual la industria del entretenimiento había gastado millones de dólares. -- Guillermo O. Burastero - Linux Counter User 84879, http://counter.li.org Córdoba 171 - B8000IFC - Bahía Blanca - Buenos Aires - Rep. Argentina Tel +54 (291) 454-6132 - ICQ 97148268 - email: [EMAIL PROTECTED]
