"Guillermo O. Burastero" <[EMAIL PROTECTED]> dijo: > 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, Supongo habra firmado el contrato por el pituto en OSDL... > no es ni fue usuario de BK Claro que si. Para hacer lo de ingenieria reversa /tiene/ que haberlo estado usando. Para ello (igual que en el caso de GPL!) la unica opcion era que aceptara la licencia del caso. > y > tampoco es EMPLEADO de OSDL, Si trabajas para mi temporalmente, eres (temporalmente) empleado mio. > solo fue consultor temporario y, por si > fuera poco, fue nombrado ahà como "Open Source Development Labs Fellow", ... con lo cual supongo se hace parte de esa organizacion... > compartiendo este tÃtulo solo con el creador de Linux, Linus Torvalds. Lamentable eleccion de OSDL. Probablemente la persona que /mas/ dan~o ha hecho a Linux y codigo abierto en el ultimo tiempo. > > [...] > >> 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? No. Explicitamente bk da una amplia gama de posibilidades de acceder a la informacion relevante en el repositorio. BitMover se dio la lata de armar y alojar un gateway a CVS. Etc. [...] > > ¿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) Ver arriba. > > [...] > 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. Las "algunas diferencias incrementales perdidas" resulta que era un 5% de la informacion del orden exacto en que se habian hecho los cambios. Claro que una sarta de fanaticos insistia en que se perdia un 80% de la informacion. Es relevante eso, dados los cambios propiamente tales? Me parece que no. [...] > > lo que quise decir es que por lo menos si no quieren interoperar, que > > pongan un cartel bien grande que lo diga La licencia no es suficiente? [...] > 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. Segun la legislacion yanqui relevante, si eran legales esas restricciones. LMcV se dio el trabajo de verificarlo con sus abogados, no simplemente quedarse con la opinion de unos legos de "es que asi (no) me gusta, asi que debe ser (i)legal" > 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. Hay diferencias... se "supone" que SMB es publico (claro que buena parte esta en exactamente cuales de las alternativas usan, y como), que /no/ hay otras opciones de acceder a la informacion que no sea via ingenieria reversa, que los derechos sobre el cuento no son exclusivos de MSFT, y /pagaste/ por Hasefroch, lo que hace que entre a tallar una serie de doctrinas legales de "con lo que adquirio legalmente para su uso puede hacer lo que se le venga en gana". > > P.D.: > > si el programa es tan bueno, y no lo tenian comprado, supongo era por > > que estaban aprovechando la caridad... BitMover dio permiso de uso gratuito a cambio de la ayuda en el disen~o de paquete que dieron Linus y sus principales secuaces (y parte de la motivacion de desarrollar bk fue precisamente disminuir la presion sobre Linus, que estaba a punto de reventar). Bajo ciertas condiciones. Condiciones que "la comunidad" se dedico a violar sistematicamente. No, no les tengo ninguna simpatia a esos "proceres". Si, ya se que LMcV es bastante aspero a veces, porfiado como mula y con sus ideas demasiado marcadas para su propio bien. Pero eso no justifica como lo trataron. No hay "caridad" involucrada. [...] > > 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/ ). La "una herramienta que lo substituye" es una coleccion de programas de bajo nivel /muy/ cruda que maneja (parece) razonablemente bien un repositorio del taman~o del kernel. Tiene varios problemas extremadamente serios (el repositorio es gigantesco, hay operaciones naturales (basicas incluso) para SCM que no maneja para nada). Esto es simple triunfalismo. Calculo que seran unos 6 meses de trabajo duro antes que sea un producto realmente usable. -- 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] Tue Apr 19 09:51:24 2005 From: [EMAIL PROTECTED] (Ricardo Mun~oz A.) Date: Tue Apr 19 10:41:07 2005 Subject: Finalizada traduccion de Unofficial Fedora FAQ In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> El lun, 18-04-2005 a las 18:18, Christian González G escribió: [...] > La version final de la FAQ estara en > http://llfica.cmcc.ufro.cl/gruluf/fedorafaq (espero que prontamente > podamos conseguir una direccion mas corta; algun ofrecimiento?). http://www.tux.cl/fedorafaq/ -- Ricardo Mun~oz A. Usuario Linux #182825 (counter.li.org)
