"Guillermo O. Burastero" <[EMAIL PROTECTED]> dijo: > Hace unos 3 años como SCM (Source Code Management Tool) Linus > Torvalds (LT) adoptó el programa no libre BitKeeper (BK) de Larry McVoy > para la gestión de desarrollo del kernel Linux.
Y el resultado fue aumentar la productividad del proceso en unas 3 veces, /sin/ enloquecer a los cabecillas en el proceso. > Su decisión, contraria a la opinión de muchos e importantes > referentes de la comunidad del software libre como Richard M. Stallman, > Bruce Perens, etc., se basó ante todo en criterios pragmáticos: era, > según L.T., el mejor programa en su tipo y las alternativas FOSS que en > ese entonces habÃa ni siquiera podÃan hacerle sombra (CVS, etc.). CVS no se hace sombra ni a si mismo. Y las demas alternativas codigo abierto hasta hoy (incluso con el impulso que el uso de bk dio a algunos) andan a an~os luz de lo que se requiere (Linus quiere un sistema que le da la posibilidad de integrar un parche en algo como un segundo, las alternativas codigo abierto que son contendores (por soportar un modelo de desarrollo distribuido) andan por el cuarto de hora...). > Pues bien, parece que el problema explotó recientemente y las > ominosas advertencias de quienes se opusieron a la elección de BK se > hicieron realidad. Sip. La gota que rebalso el vaso fue un imbecil se puso a trabajar en ingenieria reversa de bk, en contra del compromiso del caso para usar bk sin pagar. La lista previa de tales "inteligentes" fue larga, la primerisima version de bk se distribuia en codigo fuente con la condicion de no hacer ciertos tipos de modificaciones, eso se acabo en cuanto comenzaron a aparecer versiones modificadas ilegalmente. > La arquitectura de BK está basada en repositorios centrales > (servidores) donde se registran todas las modificaciones (datos) del > árbol de desarrollo del kernel como asà también metadatos como ser > diferencias incrementales, control de autorÃa de parches y > colaboraciones, capacidad de recupero de versiones intermedias, etc. bk usa un repositorio por desarrollador (incluso varios), y cualquier par de repositorios pueden intercambiar parches libremente. Asi, aca tengo 3: Copia del de Linus y del de IPW (tarjetas WiFi de intel), y una combinacion local de ambos (de donde compilo mi nucleo). El uso gratuito era para proyectos codigo abierto, con la condicion que los changelogs se publicaran en servidores ad hoc (cosa que para codigo abierto no es problema). > Pero solo la versión comercial de BK, (L.T. tenÃa una por cortesÃa de > McVoy) Linus /no/ tiene una licencia comercial, y se niega terminantemente a obtener una. > podÃa acceder a esta información. La version comercial es identica a la gratuita, solo difieren en que con la licencia comercial no registra los changelogs publicamente > El resto de los desarrolladores > del kernel Linux que no habÃan comprado la versión comercial de BK, ... que no necesitaban para nada, salvo algunos pocos que trabajan en empresas que adquirieron las licencias del caso por otras razones... > usaban una versión "gratis" mucho más restringida en la cual solo podÃan > enviar parches y bajar el árbol con la última versión del kernel. La unica cosa vagamente similar a lo que indicas es un programa codigo abierto que se libero hace cosa de un mes, que permitia unicamente bajar arboles de repositorios bk. Habian versiones de los arboles importantes en CVS (desarrolladas y manejadas por BitMover!) para quienes no querian usar bk. El resultado fueron quejas interminables sobre que no representaban la historia completa en bk (cosa imposible, bk maneja situaciones imposibles para CVS). > 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. Esas son las ultimas versiones de la licencia, luego de lo anterior. > Ante esta limitación Andrew Tridgell, autor de SAMBA, que está > trabajando (por ahora) en OSDL Fue consultor de OSDL en un proyecto particular. > (donde trabja L.T. et al en el desarrollo > del kernel Linux) como parte de su año sabático como empleado de IBM, > empezó a desentrañar el protocolo de BK estudiando sus comunicaciones de > red, de un modo análogo a como hizo para revelar el protocolo SMB de MS > y hacer SAMBA. 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), El problema es que la licencia no es solo restringe al usuario, sino a todos los empleados de la firma usuaria. > por lo que dudo que su acción pueda llamarse > ingenierÃa reversa cuando solo en mi opinión es recrear funcionalidad a > fin de escribir un programa cliente de BK libre (FOSS) para que todos > los desarrolladore pudieran usar los repositorios de BK en forma > completa, sin las limitaciones de la versión "gratis" de BK que usaban. > En útlima instancia es poder acceder libremente a información por ellos > creada. Y que ese alto fin justifique tan bajos medios te parece bien? Que si el proximo alto fin sea crear una version segura de Hasefroch via copiar partes del codigo de Linux? > Al enterarse Larry McVoy del trabajo de Tridgell, decidió suspender > la versión "gratis" para los desarrolladores del kernel, ... a partir de julio, dando facilidades para una migracion suave a una alternativa... > ocasionando un > verdadero contratiempo al desarrollo del mismo ... dado que Linus decidio terminar de usar bk inmediatamente y construir una alternativa adecuada ya que ninguna de las existentes sirve... > e impulsando que OSDL > despida injustamente (IMHO) a Andrew Tridgell. ... que entiendo habia terminado su asesoria, por lo que malamente podian despedirlo. > Linus, a mi entender en forma muy injusta, se alineó con su amigo > McVoy y cargó toda la responsabilidad de este problema sobre Tridgell, Mira ambos lados de la moneda, quieres? > 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 mismo con otro programa propietario > (BK) ? Porque la licencia de Hasefroch no restringe de forma similar? Porque aunque lo hiciera, al adquirir un programa comercialmente /no/ es legal poner condiciones sobre ingenieria reversa? Porque las restricciones sobre no impedir ingenieria reversa son para evitar cazar a la gente con una opcion, y BitMover puso a disposicion de la gente herramientas codigo abierto suficientes para no verse cazados? (Si, hay discusion sobre si lo que dieron era o no suficiente, pero el animo estaba). > 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. Porque hay maneras de hacer las cosas legalmente tambien... > Algunos sostienen que la actitud de McVoy es justa, ya que él no > está en el negocio de ayudar a crear programas competitivos con el suyo > y que fue "generoso" al permitir todo este tiempo que los > desarrolladores del kernel usaran su versión limitada "gratuita" de BK. No es limitada. > Pero también es cierto que su programa adquirió fama, reputación y un > rico "feedback" para mejorarlo precisamente por su adopción por los > desarrolladore de Linux que en su mayorÃa, siguiendo a L.T., lo usaron. Y ambos ganaron. Cual es el problema? > También los distribuidores de droga dan al principio droga "gratis" con > tal de tener luego un cliente adicto drogradependiente de por vida y no > por eso decimos que son "generosos". Me parece una comparacion muy odiosa. > Bueno, espero que pronto los desarrolladores del kernel Linux > encuentren un SCM FOSS adecuado y que si el mismo no está a la altura de > BK por el momento, la comunidad FOSS pueda llevarlo al nivel que se > requiere, de modo de no volver a tener un problema similar, con los > contratiempos que trae aparejado al proceso de desarrollo del kernel. Y > como dice un viejo dicho (El que se quemó con leche ve una vaca y llora) > saquemos la moraleja que de esta situación emerge: No usar para nada > importante software "No libre" o no FOSS. Exacto. O sea, no usar tarjetas de video con aceleracion 3D (se acabaron los juegos!). Aunque pensandolo bien, tampoco puedes usar tu modem (si, gran parte implementada en software). Pero revisando mas, esta BIOS de tu PC, y cosas menores como los firmware de tus controladoras SCSI, e incluso de tus discos duros (si, hoy contienen CPUs y programas bastante extensos). Las ultimas CPUs de intel son microprogramadas, sin el microprograma propietario del caso no hacen nada. O sea, volver a papel y lapiz. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
