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

[Guillermo O. Burastero]

rodrigo escribió:

> El 18/04/05 14:17:14, Guillermo O. Burastero escribió:
>
> [...]
>
>> 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.
>
>
> si se firma no hay mas que hacer...

Precisamente eso, Tridgell no firmó nada, no es ni fue usuario de BK y 
tampoco es EMPLEADO de OSDL, solo fue consultor temporario y, por si 
fuera poco, fue nombrado ahí como "Open Source Development Labs Fellow", 
compartiendo este título solo con el creador de Linux, Linus Torvalds.

>
> [...]
>
>> 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.
>
>
> ¿la licencia decía explicitamente que solo se puede acceder al BK con  
> programas BK?

Si así fuera el caso, probablemente esa cláusula configuraría lo que se 
llama jurídicamente "abuso de derecho" y en tal caso sería 
insanablemente nula e insostenible en un estrado judicial. La 
legislación comercial en general trata de favorecer la interoperabilidad 
para reducir los abusos que se derivan de una situación de monopolio 
(único o pocos proveedores de un bien o servicio).  Si tienes una 
licencia por el todo, también la tienes sobre una parte de ese todo. Si 
comprás un camión con acoplado, no te pueden legalmente exigir que lo 
conduzcas siempre con ese acoplado enganchado, se entiende. Es tu 
derecho usar ese camión sin el acoplado o con un acoplado de otra marca.

> ¿Era posible evacuar todo el trabajo desde BK a otro sistema sin 
> violar  alguna licencia? (si es asi, entonces es mas facil y 
> legalmente seguro  inverntar un nuevo protocolo y sistema de control 
> de versiones que  tratar de conectarse al existente, si no es dificil 
> cambiarse, no hay  excusa para no cambiarse... lo mismo deberia 
> aplicarse a cualquier  formato propietario, si hay problemas legales 
> con el mp3, en el lado  OSS debe simplemente deshecharse ese formato y 
> usar ogg, y solo  batallar por que la conversion mp3->ogg sea 
> legalmente facil)
>
> [...]

Creo haber leido que algunos metadatos (control de autoría, etc) y 
algunas diferencias incrementales no estaban disponibles para todos. Voy 
a tratar de confirmar esto.

>
> (criptoanalisis, temperproof, clave criptográfica simétrica, sesión  
> criptográfica.... mi cabeza embieza a dar vueltas...)
>
> lo que quise decir es que por lo menos si no quieren interoperar, que  
> pongan un cartel bien grande que lo diga (puede que la cripto. no sea  
> de lo mejor, pero deja bien en claro que lo que guarda es privado y  
> debe respetarse). dejar el protocolo asi no mas es como salir a la  
> calle y exigir que nadie me vea...
>
En este análisis, no se trata de si el autor quiere o no quiere que 
interoperen con su programa, se trata de que no tiene derecho a impedir 
que otros lo hagan aunque lo haya puesto en la licencia.

Si solo de querer se tratara, hace rato que MS habría actuado legalmente 
para prohibir la conexión de Unix, Linux, etc con SAMBA a sus servidores 
SMB-CIFS. Como dije en otro post, los derechos se ejercen no se declaman.

> P.D.:
> si el programa es tan bueno, y no lo tenian comprado, supongo era por  
> que estaban aprovechando la caridad... 

MS también "regala" a veces copias de Windows a escuelas o bibliotecas: 
no está haciendo caridad por favor, sinó sembrando futuros usuarios de 
licencias pagas, haciendo publicidad, descontando sumas de los impuestos 
a las ganancias, etc. McVoy al permitir el uso de su software BK gratis 
por los desarrolladores del kernel Linux, obtuvo fama, reconocimiento y 
prestigio además de un valioso feedback tecnológico. Los desarrolladores 
del kernel obtuvieron por un tiempo una herramienta SCM eficiente 
conjuntamente con un problema, por muchos anticipado, que ahora hace 
eclosión. No me interesa abrir un juicio sobre ese balance ni entrar en 
el terreno de la especulación histórica analizando que hubiera pasado si 
en el momento de elejir a BK se hubiera decidido desarrollar una 
herramienta similar (aunque conjeturo que algo similar o superior a BK 
se habría logrado desarrollar y que por lo tanto este problema no habría 
ocurrido).

> y si no hay alternativa que se  le compare, no queda otra que 
> comprarlo...
>
Me extraña mucho que digas esto, como si la alternativa de un desarrollo 
FOSS estuviera tecnológicamente vedada precisamente a  uno de los 
equipos de programadores y desarrolladores más capaces del mundo. Tengo 
entendido que en unas semanas Linus Torvalds, abocado al problema de 
reemplazo de BK, programó una herramienta que lo sustituye (por ahora en 
parte y en modo no gráfico) y la llamó git (ver también 
http://pasky.or.cz/~pasky/dev/git/ ).

Si como dicen BK es sobresaliente y único en su tipo (SCM), entonces con 
más razón es necesario que se cree una alternativa FOSS, que no solo 
será aprovechada por los desarrolladores del kernel Linux, sinó también 
por otros en proyectos de similares necesidades de gestión. Esto sería 
muy bueno, por lo mismo que apreciamos OO, Samba, Gimp, Linux, Apache, 
PostgreSQL, etc.: por su tecnología, por ser FOSS, porque con la 
competencia ganamos todos y porque no nos gustan los monopolios.

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