SCM: Linus Torvalds (Linux), Larry McVoy (BitKeeper) and Andrew Tridgell (Samba, rsync, etc.)

[Guillermo O. Burastero]

    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.

    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.).

    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.

    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. 
Pero solo la versión comercial de BK, (L.T. tenía una por cortesía de 
McVoy) podía acceder a esta información. El resto de los desarrolladores 
del kernel Linux que no habían comprado la versión comercial de BK, 
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.

    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.

    Ante esta limitación Andrew Tridgell, autor de SAMBA, que está 
trabajando (por ahora) en OSDL (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), 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.

    Al enterarse Larry McVoy del trabajo de Tridgell, decidió suspender 
la versión "gratis" para los desarrolladores del kernel, ocasionando un 
verdadero contratiempo al desarrollo del mismo e impulsando que OSDL 
despida injustamente (IMHO) a Andrew Tridgell.

    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 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.

    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. 
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. 
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".

    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.

--
Guillermo O. Burastero    - Linux Counter user 84879 
(http://counter.li.org)
Córdoba 171 - B8000IFC - Bahía Blanca  - Prov. de Buenos Aires - Rep. 
Argentina 
Tel +54 (291) 454-6132  - ICQ 97148268 - email: linux.gb en gmail.com