SCM: Linus Torvalds (Linux),
Larry McVoy (BitKeeper) and Andrew Tridgell (Samba, rsync, etc.)
Horst von Brand
vonbrand en inf.utfsm.cl
Dom Abr 17 21:07:04 CLT 2005
"Guillermo O. Burastero" <linux.gb en gmail.com> 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
Más información sobre la lista de distribución Linux