"Guillermo O. Burastero" <[EMAIL PROTECTED]> dijo:
> rodrigo escribió:
> > El 17/04/05 22:49:14, Guillermo O. Burastero escribió:
> > [...]
> >> 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.
> > supongo que esto se aplica explicitamente al los que firman,
A los que usan la version libre, IIRC. Es condicion para usar sin pagar.
> > ¿o los
> > que mandan un parche tambien quedan condenados?
Puedes perfectamente integrar parches generados con diff(1) en bk, y
exportar cambios como parches. No tienes para que usar bk para poder
interactuar con un grupo que si lo usa. Puedes extraer lo que hay en
un repositorio bk con una herramienta codigo abierto. Al no
/requerirse/ bk para trabajar, las restricciones a ingenieria reversa
son legalmente validas, AFAIU. IANAL &c.
> 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.
Son las condiciones para uso gratuito. Las tomas o las dejas.
> Es como si por usar MS-Word no podrÃas
> participar en ningún desarrollo de un procesador de textos.
No, es mejor: Tienen patentada la (inconcebiblemente novedosa) idea de
usar XML como formato de archivos para un procesador de texto (notese
que XML es un derivado de SGML, que es un lenguaje... para describir
como formatear texto).
> O por
> acceder como cliente del DBMS MS-SQL no podés hacerlo con tu propio
> cliente, con un protocolo conocido y público,
EL protocolo en este caso no es "conocido y publico", y la idea era
precisamente mantenerlo en secreto (cosa que legalmente pueden hacer
al no existir necesidad de ingenieria reversa para poder interactuar
legalmente con bk; notese que en el caso de SMB la situacion era
diferente en este aspecto, en que el protocolo esta parcialmente
documentado (y se supone es "publico") y no habia manera de
interactuar legalmente sin ingenieria reversa). Si no son capaces de
cumplir con esa peticion a cambio del permiso de usarlo...
> y para peor, tampoco podés
> participar en ningún desarrollo de una base de datos.
Revisa la licencia de tu Oracle, etc que tienes a la mano. Veras que
tambien restringen una lista de actividades.
> > [...]
> >> ... 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),
> > ¿como pudo probar que lo que hacia funcionaba, sin acceder al programa?
> Porque lo que estaba tratando de hacer primero era un cliente del
> repositorio BK, no el servidor BK.
Y el repositorio bk sale del aire?
> De entrada solo aspiraba a conectarse
> con él.
Hay un programa codigo abierto que hace exactamente eso. Para que molestarse?
> 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.
Si fuera esa la situacion, lo apoyaria 100%. El punto es que /no/ es
la situacion, en lo absoluto:
- Los datos de los archivos estan en SCCS (hay herramientas adecuadas
en cssc del proyecto GNU)
- Hay posibilidad de exportar a parches y directorios completos, si se
requiere
- Hay un cliente codigo abierto que permite rescatar los datos
- Hay gateways (mantenidos por BitMover) hacia CVS para quienes no
quieren/no pueden usar bk con el nucleo
> 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.
... con lo cual directamente contravenia las condiciones de uso de bk...
> Esto es lo que se llama interoperabilidad y, que yo sepa,
> siempre fue un argumento y objetivo deseable contra los productos
> monopólicos.
Explica como bk era monopolico en esta area... las condiciones que
imponia LMcV son inusuales, pero no ilegales. Y que le molesten a la
comunidad OSS es otro tema, pero nada tiene que ver aca.
--
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
From [EMAIL PROTECTED] Mon Apr 18 13:49:00 2005
From: [EMAIL PROTECTED] (Alejandro Barros)
Date: Mon Apr 18 13:49:38 2005
Subject: Cambio de Nombre de Mandrake a Mandriva
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Horst von Brand escribió:
> Alejandro Barros <[EMAIL PROTECTED]> dijo:
>
>>Mensaje citado por Luis Eduardo Vivero Peña <[EMAIL PROTECTED]>:
>
>
> [...]
>
>
>>Yo soy un mankekero hace varios años y la verdad es que su
>>evolución no me gusta mucho,
>
>
> Detalles?
Lo que no me gusta es que antes de la fusión estaba bastante claro el
modelo de evolución, esta fusión genera entropía adicional y no veo un
gran aporte de Conectiva a Mandrake, por lo que creo es más ruido que
aporte real.
>
>
>> estoy pensando en Suse, como ven me
>>gustan las distribuciones europeas,
>
>
> Razones?
Eso sería para desatar la guerra santa, prefiero dejarlo ahí. En todo
caso veo un modelo más jugado por el OSS en Europa más que en otras
latitudes.
>
>
>> más que gringas (espero que
>>esto no desate una guerra santa)
>
>
> Tux te escuche.
Alejandro Barros
e.nable
From [EMAIL PROTECTED] Mon Apr 18 13:58:45 2005
From: [EMAIL PROTECTED] (Horst von Brand)
Date: Mon Apr 18 13:58:47 2005
Subject: SCM: Linus Torvalds (Linux),
Larry McVoy (BitKeeper) and Andrew Tridgell (Samba, rsync, etc.)
In-Reply-To: Your message of "Mon, 18 Apr 2005 11:04:33 -0400."
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Jens Hardings <[EMAIL PROTECTED]> dijo:
> >El 18/04/05, Guillermo O. Burastero<[EMAIL PROTECTED]> escribió:
[...]
> >Time is money.. de seguro que Linus debe haber pensado en eso..la
> >gente que desarrolla el kernel,me imagino que sera gente muy ocupada
> >.no puede perder el tiempo o me equivoco?
> Me parece que hay dos extremos:
>
> A) Utilizar la herramienta que ofrece la mejor solución técnica y
> económica, mirado solamente en el corto plazo.
O incluso el largo plazo.
> B) Seguir los principios éticos y morales detrás del Software Libre a
> toda costa.
> Y hay un equilibrio, que es bastante cercano a lo que hace Linus, IMHO.
> Pero en general es muy difícil verlo con claridad.
Si fuera facil...
> En el caso de BitKeeper, era una herramienta que existía.
En buena parte, fue disen~ada/desarrollada segun las especificaciones
de Linus y varios de sus tenientes mas importantes, por un personaje
que tiene una larga trayectoria en desarrollo de software de sistemas
(cosillas menores como lmbench como codigo abierto) y que participo
activamente en el desarrollo de Linux hasta que comenzo con su
aventura BitMover.
> No se tenía
> certeza que fuera a funcionar bien con el modelo de desarrollo del
> kernel, pero valía la pena un intento (desarrollar a esa altura una
> versión 100% libre para solamente averiguar si funciona habría sido un
> costo demasiado alto).
Y desarrollarla como codigo propietario tambien, solo que de esa forma
se financiaba el desarrollo...
> Ahora se tiene certeza que hay varios aspectos de
> BK son muy deseables para el desarrollo del kernel (y probablemente para
> otros proyectos con características similares), y que si se cuenta con
> una herramienta 100% libre eso va a traer muchos beneficios en el
> mediano/largo plazo. Es entonces buen momento para asumir un costo ahora
> que se recuperará con creces.
Nodz.
> Si seguimos principio A), nos quedaríamos con BK haciendo cada
> vez más concesiones, porque el costo en el corto plazo de generar
> una alternativa libre es demasiado alto. Pero si seguimos
> exclusivamente el principio B), estaríamos dejando de lado todo
> el aporte que hace una parte importante de la industria del
> software, duplicando esfuerzos y por ende agregando trabas a la
> innovación. (En un caso extremo, no podríamos utilizar los
> computadores de hoy en día, ya que primero debiéramos
> desarrollar una BIOS libre).
Y seguir con los firmware de un cuantohay, de tarjetas de video y
modems hasta discos duros. No olvidar los microprogramas de las CPUs
actuales...
Y nunca entendi porque el /software/ tenia que ser de especificaciones
(codigo fuente) libremente disponible, pero el /hardware/ no (si, p.ej.
hay especificaciones completas para una CPU SPARC, "cualquiera" puede
hacerse la suya).
--
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
From [EMAIL PROTECTED] Mon Apr 18 14:06:43 2005
From: [EMAIL PROTECTED] (Jens Hardings)
Date: Mon Apr 18 14:09:31 2005
Subject: SCM: Linus Torvalds (Linux), Larry McVoy (BitKeeper) and Andrew
Tridgell (Samba, rsync, etc.)
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Horst von Brand wrote:
>>Me parece que hay dos extremos:
>>
>>A) Utilizar la herramienta que ofrece la mejor solución técnica y
>>económica, mirado solamente en el corto plazo.
>>
>>
>
>O incluso el largo plazo.
>
>
Es que ahí ya dejaría de ser extremo ;-)
>>B) Seguir los principios éticos y morales detrás del Software Libre a
>>toda costa.
>>
>>
Saludos,
--
Jens.
