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

[Guillermo O. Burastero]

Horst von Brand escribió:

>"Guillermo O. Burastero" <linux.gb en gmail.com> dijo:
>  
>
>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. 
>
Si te estás refiriendo al Dr. Andrew Tridgell como un imbécil, me parece 
un poco fuerte tu calificación y la verdad que no lo comparto
Fue uno de los desarrolladores de SAMBA, rsync, el programa de ajedrez 
KnightCap, etc. El compromiso no lo adquirió él ya que no es usuario de 
BK, y las obligaciones de la licencia solo alcanzan a los usuarios de 
BK. Tampoco, según se sabe, tuvo acceso al código de BK ya sea fuente o 
ejecutable, solo analizó la comunicación generada por BK para construir 
un modelo libre de similar funcionalidad que la versión comercial del 
cliente BK. No veo nada de inmoral o ilegal en eso.

>>    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.
>  
>
Supongamos que es así como tú dices, que la licencia no solo restringe a 
los usuarios de BK sino también a todos los empleados de la firma 
usuaria (lo cual a mi entender configuraría un evidente abuso de 
derecho). Entonces, como tú bien dices arriba, Andrew Tridgell "Fue 
CONSULTOR de OSDL en un proyecto particular" o sea que NO ES EMPLEADO de 
OSDL ni tampoco usuario de BK, por lo tanto no está alcanzado por las 
restricciones de su licencia.

>>                           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?
>  
>
Si Andrew Tridgell no está violando compromiso alguno asumido por él, 
(caso contrario sería alcanzable legalmente, ya que los derechos se 
ejercen no se declaman), por qué dices que empleó medios tan bajos. O 
acaso lo que hizo es ilegal ? La ingeniería reversa, que no creo que sea 
este el caso, incluso es legal en muchos estados. Si lo que hizo A.T. 
con el protocolo de BK es ilegal o inmoral, también debería serlo lo que 
hizo con SAMBA por ejemplo, y no he sentido a NADIE de la comunidad FOSS 
criticarlo por eso.

>Mira ambos lados de la moneda, quieres?
>
>  
>
Eso trato. Y yo, como la mayoría de los miembros de esta lista  y casi 
todos los usuarios de Linux, reconocemos el inmenso aporte que al FOSS 
Linus Torvalds ha hecho como creador y hacker principal del kernel Linux 
y sobre todo por el gran liderazgo que supo demostrar, no inferior 
(IMHO) a su solvencia técnica. No tengo la suerte de conocer 
personalmente a ninguno de las personas aquí mencionadas, por lo que no 
creo tener un juicio sesgado al respecto, aunque me baso en información 
de Internet que sí puede estar sesgada.. Todos somos humanos y por mucha 
que sea la admiración que tangamos por algunos de estos protagonistas, 
ésta no nos debe impedir ver alguna actitud de ellos que no compartimos.

>>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...
>
>  
>
Ni siquiera Larry McVoy dice que lo que hizo Andrew Tridgell sea ilegal. 
Aunque seguramente no le halla gustado como a cualquiera que ve aparecer 
una situación que pueda erosionar su base de ingresos ecnonómicos.

>>    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.
>  
>
Si no tuviera ninguna limitación con la versión que tenían disponible de 
BK, más allá de no ser FOSS,  me pregunto ¿ por qué A.T. se tomaría el 
trabajo de intentar crear una versión FOSS del mimo ? ¿ Obsesión por 
hackear no mas ? Y aunque mas no fuera por ésto, está en su derecho, ¿ no ?

>>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.
>
>  
>
Puede ser odiosa, no fue mi intención que se tomara así, si no de dar un 
ejemplo claro de aparente "generosidad". Lo que si me parece odioso es 
pretender prohibirle a un desarrollador clases de programas a 
desarrollar por el solo hecho de usar un programa de esa clase. Al fin y 
al cabo casi todos los desarrollos tienen algo, aunque mas no sea ideas 
o reminiscencias, de obras  anteriores sobre los cuales avanzan (o no) o 
evolucionan. El mismo Linus Torvalds cundo inicia Linux, algo de 
inspiración habrá encontrado en Unix, Minix, etc. y una gran cantidad de 
personas que le precedieron e hicieron contribuciones valiosísimas a la 
teoría de sistemas operativos.

>>    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.
>  
>
    Me parece que se interpreta bien lo que quise decir, pero para mayor 
abundancia y precisión reescribo la moraleja anterior de la siguietne 
manera:
   
        Solo usar software propietario (no FOSS) cuando su carencia o 
funcionamiento no me pueda dejar vulnerable y causar un daño importante.

    Por ejemplo puedo usar software propietario sin riesgo en el 
firmware de "host adapters SCSI" (las controladoras SCSI suelen estar en 
el mismo dispositivo), adaptadores de video, modems, BIOS de la PC, 
micro o nanoprogramación de microprocesadores, firmware de impresoras, 
etc. En general el firmware no está sujeto al humor del fabricante 
después que salió de la fábrica y aunque pueda dejar de contar con una 
actualización, siempre puedo cambiar ese dispositivo por otro sin mayor 
contratiempo de ser necesario. Perderme una actualización del firmware 
de mi grabadora de CD no es algo que me haga perder el sueño, sobre todo 
si el que tengo funciona. He visto placas madres arruinadas por intentar 
actualizaciones de BIOS completamente innecesarias.

    Para finalizar, no pretendo iniciar con esto otra "guerra santa", 
tampoco soy un fundamentalista del FOSS que no admite el software no 
FOSS. sin embargo me pareció oportuno mencionar las importantes 
implicancias que tuvo la elección de un programa no FOSS (BK) para la 
gestión del desarrollo en un proyecto tan grande, delicado e importante 
como el kernel Linux, con sus inconvenientes y porque no, como mencionó 
el Dr. Horst von Brand, alguna de sus ventajas como ser la aceleración 
de la gestión de desarrollo del kernel. Que cada uno saque la conclusión 
que mejor le plazca, yo por mi parte no pienso subordinar los principios 
al pragmatismo (al menos en la medida de lo posible).-


-- 
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: linux.gb en gmail.com