Libertonia || Comments || Driver GPL para TCPA


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

Driver GPL para TCPA | 20 comentarios (20 temáticos, editoriales, 0 ocultos)

¿Esto es bueno? (3.00 / 2) (#1)
por nac a las Thu Jan 30th, 2003 at 09:15:57 AM CET
(Información Usuario)

No entiendo mucho de estas cosas, aunque he leido muchos post sobre estos engendros (TCPA y Palladium).

Palladium sabemos de que pie cojea.

Pero si TCPA trae un driver GPL, ese driver se podra modificar y que actue en beneficio de los usuarios.

Incluso esos rumores de que TCPA iba a impedir la instalación de Linux. ¿Esta teoría se cae por su peso?

Entonces ¿TCPA es bueno para los usuarios?

Haber si se crea un debate interesante y los "poco listos" como yo, nos enteramos mejor.

¿No quieres especulaciones? (4.00 / 4) (#3)
por jorginius ("jorginius" en Google Mail) a las Thu Jan 30th, 2003 at 11:08:25 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Pues ahí van unas cuantas más :-)

Incluso esos rumores de que TCPA iba a impedir la instalación de Linux. ¿Esta teoría se cae por su peso?

Esa teoría se caía por su propio peso antes. Se desmiente en el faq de TCPA y en las propias especificaciones.

Ya se habló antes de TCPA por aquí. En esta noticia de SegFault y en el Diario de jcantero.

Entonces ¿TCPA es bueno para los usuarios?

El problema de TCPA es que prevee una segunda llave de respaldo, a la que no tiene acceso el usuario y que serviría para mostrar a un tercero que nuestra máquina es confiable (es conforme a TCPA). Le mostraríamos una firma y él podría ver que concuerda con una firma del fabricante de nuestro chip.

... Y aquí es donde empieza la paranoia:

Como ya digo, esa llave sería generada por el fabricante, que dispondría de su propia copia. Como hay una llave de respaldo por chip y por fabricante, a partir de ella se podría identificar unequívocamente nuestra máquina en todas las operaciones "seguras".

Si se ofrecen servicios de telebanca, venta por Internet, etc. Autenticando al comprador por TCPA (autenticando con la llave de respaldo, puesto que es la única que el otro extremo sabe que no ha podido ser manipulada y que corresponde con una máquina concreta), entonces "alguien" con una relación "llaves->usuarios" (facilitada por los propios fabricantes) podría trazar todas las transacciones seguras en Internet: qué y cuándo compramos, cuál es nuestra entidad bancaria, con quien charlamos en privado, etc.

Como ves, es la pesadilla de todo paranoico, sobre todo si tiene en mente la fallida politica al respecto de la administración Clinton y el "key escrow" del FBI.

Por otro lado, resulta que aunque TCPA contempla esa segunda llave, no es obligatoria incluirla (en el caso de que así sea, se puede desactivar). Por lo que se lee en el documento de la noticia, IBM no la incluye porque "ninguno de sus clientes se lo ha pedido" :-).

Con la segunda llave inexistente o desactivada, puedes seguir accediendo sin problemas al resto de funcionalidades (útiles y beneficiosas para el usuario a priori) del chip, pero ahora el problema es el de siempre: si la autenticación en Internet por medio de TCPA llega a ser un estándar, o bien te tragas tu paranoia y activas esa segunda llave o bien estás condenado al ostracismo, a no poder autenticarte en esos servicios.

[ Padre ]

Alto, que nadie me salte al cuello (3.00 / 2) (#4)
por jorginius ("jorginius" en Google Mail) a las Thu Jan 30th, 2003 at 11:26:03 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

El problema de TCPA es que prevee una segunda llave de respaldo, a la que no tiene acceso el usuario y que podría servir para mostrar a un tercero que nuestra máquina es confiable

Evidentemente, el objetivo principal de una llave de respaldo no es servir de identificador, sino de llave de emergencia (esto es, de respaldo :-)).

[ Padre ]

Nope, en el otro comentario ibas mejor (3.50 / 2) (#5)
por Envite a las Thu Jan 30th, 2003 at 12:06:38 PM CET
(Información Usuario)

The only time a certificate is needed is if you want to be able to prove to a third party that you have an approved TCPA chip. Most applications do not have this need, and this certification is not currently supported with IBMs chips. If you want to do an application that needs such a certificate, the TCPA has an endorsement key that can be used to get a suitable certificate. The only way this can work is if someone, like the manufacturer, has recorded a given TCPA chips public endorsement key, and can use this knowledge to certify identity keys from the given TCPA chip. This is not required, and software access to the endorsement key can be disabled. [...] The only private key that cannot be cleared and arbitrarily loaded by the owner is the endorsement public key pair, which possibly is created on the chip at manufacture time, and the public part recorded by the manufacturer. It does not make any sense for the user to delete or replace the endorsement key, as only the original endorsement key recorded by the manufacturer can be used for this endorsement. If you want endorsement, you have to have that key. If you dont want endorsement, you can disable all access to the key. All other keys can be arbitrarily loaded and deleted. Note that IBM does not currently, and never has, recorded any endorsement keys, anyway, because no customers have asked for it.
O traducido:
Cuando unico se necesita un certificado es si quieres ser capaz de demostrar a una tercera parte que tienes un chip TCPA aprobado. La mayor parte de las aplicaciones no tienen esta necesidad, y esta certificacion no esta soportada por los chips IBM. Si quieres hacer una certificacion que necesite tal certificado, el TCPA tiene una clave de respaldo que se puede usar para obtener un certificado usable. La unica manera de que esto pueda funcionar es si alguien, como el fabricante, ha grabado las claves publicas de los chips TCPA y puede usar estas claves para certificar las claves de identidad de los chips TCPA. Esto no se requiere, y el acceso de los programas a la clave de respaldo puede ser deshabilitado. [...] La unica clave privada que no puede ser borrada y arbitrariamente recargada por el usuario es el par de claves publicas de respaldo, que posiblemente sea creado en el chip durante su fabricacion, y la parte publica guardada por el fabricante. No tiene ningun sentido para el usuario borar o modificar esta clave, ya que solo la clave original guardada por el fabricante puede ser utilizada para este respaldo. Si quieres certificacion, debes tener esta clave. Si no lo quieres, puedes deshabilitar todo acceso a esta clave. Notese que IBM no graba, ni ha grabado nunca, ninguna clave de respaldo, porque ninguno de sus cliente se lo ha pedido nunca.
No estoy de acuerdo con lo que dices, pero defenderé con mi vida tu derecho a decirlo.
Voltaire
[ Padre ]

¿Decimos lo mismo? (3.00 / 2) (#6)
por jorginius ("jorginius" en Google Mail) a las Thu Jan 30th, 2003 at 12:14:58 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Si quieres hacer una certificacion que necesite tal certificado, el TCPA tiene una clave de respaldo que se puede usar para obtener un certificado usable.

Pues eso, que no poseso :-). Hay un llave de respaldo que puede usarse como llave de respaldo (valgamé la rebuznancia) y además podría servir para certificar que nuestra máquina es confiable según TCPA.

[ Padre ]

Esteeeeeeeeeee, no (none / 0) (#7)
por Envite a las Thu Jan 30th, 2003 at 03:35:14 PM CET
(Información Usuario)

Creo que no decimos lo mismo. La clave esa que llaman de respaldo, en realidad de respaldo no tiene nada (cosas de la traduccion). Es simplemente una pareja clave mas, con la particularidad de que es de fabrica y no se puede borrar. En cuanto a que sirva para certificados, eso es solo en teoria. Todos los Thinkpad que se han vendido hasta ahora llevan el chip TCPA incluido, pero la clave de esos chips no se puede usar para obtener un certificado porque IBM no guardo las partes publicas correspondientes.
No estoy de acuerdo con lo que dices, pero defenderé con mi vida tu derecho a decirlo.
Voltaire
[ Padre ]

Tienes razón y "aliased ID" (2.00 / 1) (#8)
por jorginius ("jorginius" en Google Mail) a las Thu Jan 30th, 2003 at 04:47:25 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Se refiere a que la llave "respalda a la plataforma" (la identifica como conforme a TCPA), no es que "respalde la identidad del usuario" (afirme que la clave del usuario salió de tal máquina), que era lo que yo pensaba: que las claves generadas por el usuario se firmaban con la de respaldo.

Suponía que el receptor podría cercionarse como último recurso de que una clave cualquiera era realmente nuestra comprobando la firma del fabricante de nuestro chip. Esto tendría utilidad como prueba en un tribunal de que realmente fulanito escribió tal cosa (o al menos que se escribió en su ordenador), por ejemplo.

Por cierto, ¿alguien sabe como funciona lo de la generación de identificadores en TCPA?. Parece ser que en las transacciones en Internet, para identificarnos no se usa la firma de nuestra clave de respaldo, sino que se genera un "ID" siempre distinto a partir de ella. Por lo que leo en la documentación, a partir de ese ID no se puede saber quien se está autenticando realmente contra el servicio (según parece, lo más que se puede saber es que es una máquina TCPA confiable).

Si se usan ID distintos, ¿cómo hacen para saber qué somos nosotros otra vez?. Si por ejemplo nos suscribimos al PlayBoy digital y cada vez que nos conectamos al servicio lo hacemos con un ID distinto. ¿Cómo saben que somos nosotros, que ya hemos pagado la suscripción, u otro usuario?.

Si hay relación entre los ID, digo yo que se podría trazar nuestro perfil de la misma manera que si usásemos nuestra firma. Basta que "el gobierno" (consparanoia al canto) tengo uno de nuestros ID (con el que presentamos la Renta) y vaya buscando los relacionados por ahí.

¿Se usa un ID por servicio?, ¿y dónde se almacenan esos ID?, ¿en disco???

[ Padre ]

¿Y Europa? (2.00 / 1) (#9)
por nac a las Fri Jan 31st, 2003 at 11:37:56 AM CET
(Información Usuario)

Y digo yo.

La UE querrá preguntar que utilidad tiene esa llave de respaldo y el uso que se va ha hacer.

Lo digo por el caso reciente de la investigación del Passport de Microsoft. A MS parece que le toca modificarlo para que sea legal en la UE.

Aunque bueno. Todo esto es política y veremos lo que ocurre.....

[ Padre ]

Qué lío :-) (3.50 / 2) (#10)
por jorginius ("jorginius" en Google Mail) a las Fri Jan 31st, 2003 at 01:08:25 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

La UE querrá preguntar que utilidad tiene esa llave de respaldo y el uso que se va ha hacer.

Creo que mi comentario te ha dejado más confundido que antes.

La llave (la pareja de llaves) de respaldo puede usarse por el usuario normalmente para firmar y des/cifrar. La peculiaridad que tiene respecto a las normales que podemos generar es que esa llave es propia de la plataforma y no se puede sacar del chip, ni fisicamente ni por software, en teoría al menos.

Es la "llave de la máquina", que respalda (en la nomenclatura oficial del consorcio trustedcomputing) que nuestra máquina es un "TrustedPC" TCPA.

En definitiva, es una pareja de llaves como cualquier otra, que puede usarse como las demás con la particularidad de que, al ser exclusiva de una máquina concreta, también podría servir para certificarnos.

Leyendo lo que he escrito (sobre todo la aclaración/confusión :-)) parece que doy a entender se trata de una llave con la que se podría leer lo que cifremos con otras claves generadas por el TPM (como una llave maestra). Esto no es así: es una pareja de llaves independiente. ni siquiera se firman las nuevas claves con esa (a menos que lo hagamos a mano).

El problema está en que sólo esa llave sería confiable en una transacción (es la única que nos asegura que la operación se está llevando a cabo desde un PC concreto), y cómo cada fabricante guarda una relación de llaves públicas (espero que sólo de las públicas :-)) quizás se podría trazar todas las operaciones apoyadas en TCPA.

[ Padre ]

Conspiraciones (3.00 / 1) (#12)
por musg0 a las Sun Feb 2nd, 2003 at 12:40:57 PM CET
(Información Usuario) http://helvete.escomposlinux.org

El problema está en que sólo esa llave sería confiable en una transacción (es la única que nos asegura que la operación se está llevando a cabo desde un PC concreto)

No encuentro ningún uso legítimo que pueda tener cualquier empresa en internet para necesitar saber que el ordenador que está al otro lado es uno en concreto.

En caso de policías, fbi y organizaciones del estilo es normal que tengan que asegurarse que el que llama es quien dice ser, pero en comunicaciones normales con el banco o una tienda no entiendo la necesidad que puede haber de que la transacción se haga desde un PC concreto.

tiene que haber algo oculto en todo esto si nos quieren obligar a que firmemos siempre desde el mismo ordenador y denegarnos la entrada en caso contrario.

Además con los medios actuales creo que es posible verificar casi al 99% que el ordenador cliente o servidor son el que dicen ser sin necesidad de meter una clave única y controlable por terceros de fábrica.

[ Padre ]

Usos (3.00 / 1) (#13)
por jorginius ("jorginius" en Google Mail) a las Sun Feb 2nd, 2003 at 01:58:32 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

No encuentro ningún uso legítimo que pueda tener cualquier empresa en internet para necesitar saber que el ordenador que está al otro lado es uno en concreto.

Tienes ejemplos de uso de TCAP en la web de trustedcomputing (PDF). En concreto, el caso 3 trata ese uso: nos habla de una máquina accediendo a los datos de las nóminas de una empresa, basando su identificación en TCPA.

Las IP se pueden falsear, una identificación por MAC, aparte de ser un coñazo para el admin, también es atacable, los certificados se pueden robar al igual que las claves de los usuarios, etc. Pero la llave privada TCPA no puede ser extraída del TPM por ningún medio, así que el atacante está obligado a tener acceso al PC del administrador para acceder a la información sensible.

En el terreno comercial, de la misma forma TCPA puede servir para que una tienda en Internet sepa que el que compra (o quien alquila sus contenidos) es quien dice ser y no otra persona que le ha robado su contraseña. O para reclamar: si el usuario contrata un servicio y después incumple el pago ya no puede decir que "él no sabe nada, no firmó nada", puesto que está registrado que la petición se hizo desde su PC.

También a la inversa: el usuario que compra por Internet puede certificar que lo que tiene al otro lado es quien dice ser, antes de enviar sus datos bancarios por ejemplo.

Evidentemente, ahora mismo hay mecanismos que permiten hacer todo eso pero por lo general necesitan de un tercero, una entidad de certificación, que garantice que los interlocutores son quienes dicen ser. Un usuario puede obtener un certificado personal de Verisign, por 14.95 $ anuales, pero no es habitual. TCPA pretende, entre otras cosas, identificar a las dos partes, saltándose esas entidades certificadoras.

Otro uso interesante de esa identificación por máquina sería como medida antipiratería. Muchos fabricantes licencian sus productos para un solo puesto: si el software pide que la máquina se identifique para funcionar, se podría reducir la copia ilegal de programas. Este método anticopia es más cómodo y fiable que los discos llave, más seguro que los números de serie, y más barato que las mochilas específicas, como las HASP.

[ Padre ]

Aclarado el tema. (2.00 / 1) (#11)
por nac a las Fri Jan 31st, 2003 at 03:19:26 PM CET
(Información Usuario)

Gracias por tu aclaración y la de otros compañeros.

El FAQ de TCPA/Palladium y comentarios de gente me tenía muy confuso. Ahora creo tener las cosas un poco más claras.

[ Padre ]

Te repito (none / 0) (#14)
por Envite a las Wed Feb 5th, 2003 at 08:21:23 PM CET
(Información Usuario)

IBM (al menos de momento) no guarda las claves publicas de los TCPA que ya vende.
No estoy de acuerdo con lo que dices, pero defenderé con mi vida tu derecho a decirlo.
Voltaire
[ Padre ]

¿Y :-)? (3.00 / 1) (#15)
por jorginius ("jorginius" en Google Mail) a las Wed Feb 5th, 2003 at 09:38:40 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

IBM (al menos de momento) no guarda las claves publicas de los TCPA que ya vende.

Terrible deja vù (¿no es lo que se dice en los enlaces de la noticia?).

¿Me he perdido?. En este hilo estamos hablando de posibles usos que se le podría dar a TCPA, no de los usos que se le puede dar ahora o con la implementación específica de IBM.

Si te pones así, hay muchos detallitos que tiran por tierra mis ejemplos de casos, además del hecho de que IBM dice que no guarda las claves.

Por ejemplo, a día de hoy no hay nadie aún que oferte servicios basados en TCPA ni que haya anunciado darlos en un futuro, el software que lo usa, si existe, es absolutamente marginal (incluso en Windows), los TrustedPC se pueden contar con los dedos de una mano, etc. Estos son problemas insalvables para poner en marcha mis ejemplos, el que supuestamente los fabricantes no guarden las claves no tendría por qué ser crítico... Pero aunque no fuera necesario, esto no impide que no puedan hacerlo, y de ahí el matiz paranoico.

Puede que te fies de IBM y cía, pero algún futuro legislador preclaro podría dictaminar que es obligatorio registrar todas las claves de PC (de cara a identificarlos en robos, por ejemplo. Como se hace con los automóviles y el número de bastidor del motor) y con esas relaciones de claves parece que se podrían rastrear todas nuestras transacciones TCPA. Eso es un problema, tal y como lo veo yo.

Por otro lado, ahora desde luego no, pero pienso que en un futuro mis casos de ejemplo de uso podrían ser factibles. ¿En qué me baso?: en los ejemplos del documento "interoperatividad creible" para transacciones confiables (aquí (PDF)) y en los "modelos de uso" (el enlace (PDF)).

[ Padre ]

Registrar las claves (none / 0) (#16)
por Envite a las Wed Feb 5th, 2003 at 11:47:16 PM CET
(Información Usuario)

Si mi proveedor TCPA registrara las claves, simplemente no usaria la clave maestra TCPA para nada. Hay esquemas mucho m'as seguros hoy en dia. Por ejemplo, solo yo puedo firmar con mi clave privada GPG.
No estoy de acuerdo con lo que dices, pero defenderé con mi vida tu derecho a decirlo.
Voltaire
[ Padre ]

Pero esa clave no es "confiable" (4.00 / 1) (#17)
por jorginius ("jorginius" en Google Mail) a las Thu Feb 6th, 2003 at 12:41:00 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

...Y hay muchos posibles usos de TCPA que obligarían a usar una llave confiable. Por ejemplo, si alguna empresa de software diseña un sistema anticopia o de distribución de contenidos basado en TCPA, usará evidentemente la clave del TPM ya que el usuario no la puede extraer (y así no puede instalar/ejecutar el software en otra máquina). También se usaría esta llave para implementar un control de acceso para ciertas máquinas a recursos sensibles.

Por otro lado, nunca podrías estar seguro al 100% de que el fabricante no guarda las llaves. Incluso si hubiera una ley que prohibiese hacer las copias, no tendrías forma de saber si se cumple o no.

Hay esquemas mucho m'as seguros hoy en dia. Por ejemplo, solo yo puedo firmar con mi clave privada GPG.

GPG no es equivalente a TCPA en funcionalidades (este último es, salvando las distancias, como tener parte de OpenSSL implementado en hardware), pero ya que sacas el tema, ten en cuenta de que la seguridad con GPG tiene un punto flaco, que es la (falta de) confianza. ¿Quién respalda que la clave pública que acabo de recibir es tuya (de tu máquina) y no de otra persona que dice ser tú?. Para que GPG funcione, necesita al final de un canal de distribución para la llave pública que sea confiable (e.j: de mano en mano, mostrando el DNI), de otra manera la gente no firmará (o no debería firmar) tu clave. Sin firmas no hay anillo de confianza y GPG casi se vuelve inútil.

Por mucho que tu firmes con tu privada, si no me has dado en mano tu pública (o esta no ha sido firmada por X personas de mi total confianza, a las que tendrás que haber mostrado tu clave con anterioridad), no puedo saber si realmente eres tú el que firma.

TCPA tampoco es comparable a GPG en sus objetivos: GPG no provee de mecanismos para que el software "se asegure" de que está corriendo en el hardware donde debería correr y no sobre un ICE o sobre un PC no autorizado. Por ahí esta añadiendo un grado más de paranoia.

Mira, un uso que se me acaba de ocurrir de TCPA y que no podría realizarse con GPG (o por software). Coges el compilador y lo modificas de tal forma de que, al realizar una llamada anidada, introduzca código para que saque el resumen de la dirección de retorno antes de meterla en la pila y al final de la llamada, cuando nos preparamos para retornar, haga de nuevo el hash de la dirección y compruebe si ambos resúmenes cuadran. Si no es así, aborta el proceso. ¿Qué se consigue con esto?: virtualmente acabar con todos los buffer overflows 8-), y como es una solución hardware, el rendimiento no se resiente demasiado y es muy difícil de atacar.

Esquemas de seguridad informática (tarjetas inteligentes, biometría, controladoras de disco "cifradoras", etc) hay un montón, y seguro que muchos de ellos son tanto o más seguros que TCPA, pero éste tiene la ventaja de que será barato, más que nada porque vendrá de serie.

[ Padre ]

Opinamos distinto, pero es lo bonito de Libertonia (none / 0) (#18)
por Envite a las Thu Feb 6th, 2003 at 10:01:23 AM CET
(Información Usuario)

"Amos" a ver... lo primero, lo de la direccion de retorno y tal, creo que lo entiendo, pero no soy informatico, y programando no voy mas abajo de C (y gracias, que eso ya es sumergirme, mi nivel de superficie es matlab/basic).
Pero bueno. A lo que "ibanos". Si una empresa diseña un sistema anticopia o de distribución de contenidos basado en TCPA, me obliga a utilzar esos contenidos en un solo PC. Eso es DRM, que no es uno de los objetivos de TCPA, aparte de que puede ser ilegal. Yo tengo derecho a utilizar mis programas y mis contenidos en cualquier PC, siempre que lo haga en un solo PC a la vez (uno por licencia, claro). En realidad el unico valor claro de acceso de maquina confiable a recursos sensibles lo encuentro dentro de una oficina, donde se suponga que el ordenador del administrador de cuentas solo lo puede usar el administrador de cuentas, por ejemplo. Y en ese caso no hace falta que el fabricante te certifique las claves, lo puede hacer el sysadmin, ya que tiene acceso a la maquina que se va a considerrar "confiable" a partir de ese momento.
En cuanto a que no se puede confiar en que el fabricante no guarde las claves, precisamente por eso no me gusta la idea de usar la clave hardware de TCPA (llamemosla asi) para nada.
En cuanto a la seguridad de GPG (de OpenPGP en general), es evidente que tiene ese punto flaco que comentas, pero es el unico sistema (u otros semejantes) que permite comprobar la identidad de una persona, no de un PC. Y si yo, al registrarme en un servicio, doy mi clave publica (como una lista de correo), pueden estar seguros de que solo yo escribo correo y solo yo lo leo. El unico problema es si menti al registrarme, pero eso tambien puede pasar con los servicios basados en la clave hardware TCPA. Por ejemplo, yo doy mi clave publica GPG al registrarme, por correo-e, en mi grupo de usuarios de Linux. A partir de ese momento puedo incluso participar en votaciones por correo, ya que solo yo puedo emitir ese voto que va con mi firma. En cuanto a si me registre con mi propio nombre o no, es lo de menos, Para eso pago la cuota.
Bueno, en una cosa si estoy totalmente de acuerdo contigo, GPG y TCPA no solo son cosas distintas sino con objetivos distintos. Solo trato de "demostrar" que no es necesario, para ningun uso legal, usar la clave hardware TCPA.

A mandar
No estoy de acuerdo con lo que dices, pero defenderé con mi vida tu derecho a decirlo.
Voltaire
[ Padre ]

De acuerdo con tu comentario (3.00 / 1) (#19)
por jorginius ("jorginius" en Google Mail) a las Thu Feb 6th, 2003 at 04:28:31 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Pero añado una aclaración de algo que has dicho que, aunque no tiene mucho que ver con el tema, se me antoja incorrecto.

Yo tengo derecho a utilizar mis programas y mis contenidos en cualquier PC, siempre que lo haga en un solo PC a la vez (uno por licencia, claro).

Me temo que ese "derecho" depende de las condiciones de uso del software. No es un derecho inalienable ni nadie te lo garantiza "por ley".

En el caso de la CLUF de Microsoft se especifica claramente que la licencia es para una única máquina. Aunque tengamos dos PC y no vayamos a usar los dos a la vez, necesitamos sendas licencias (o bien instalar/desinstalar continuamente el software: surrealista pero cierto :-)).

También prohibe expresamente "compartir" las licencias (por ejemplo, instalar el software en un servidor central y acceder mediante terminal server, o simplemente ceder tu asiento a un compañero para que trabaje con tu ordenador: ambos necesitais una licencia para hacerlo).

Te pongo el ejemplo de Microsoft por ser quizás el más conocido, pero hay muchas otras empresas que van más allá. Por ejemplo, es habitual que te cobren las instalaciones: te licencian el programa para una sola máquina (se aseguran de que no funciona en otra) y, si cambias tu hardware, tienes que pagar a un técnico de la empresa de desarrollo para que te visite, inhabilite la copia antigua y te instale otra en el nuevo PC.

TCPA no es un "refuerzo" para el cumplimiento de las licencias y quizás tampoco sea uno de sus objetivos serlo... Pero podría usarse para eso también. Es un posible uso más, entre otros muchos.

[ Padre ]

Toy de acuerdo (none / 0) (#20)
por Envite a las Tue Feb 11th, 2003 at 01:47:04 AM CET
(Información Usuario)

pos eso
No estoy de acuerdo con lo que dices, pero defenderé con mi vida tu derecho a decirlo.
Voltaire
[ Padre ]

Yo estoy igual (3.00 / 2) (#2)
por Navegant a las Thu Jan 30th, 2003 at 10:25:08 AM CET
(Información Usuario)

Tengo mis dudas y después de leer el artículo de Bulma "Preguntas Frecuentes sobre TCPA y Palladium" me dio la sensación que ambas cosas "eran parte del mismo proyecto" (ya leo que no).

¿Algún otro enlace en castellano para "listos" como yo? Una aclaración tal vez :-)

Creo que el tema es lo suficientemente importante como para no dejarlo correr (digo yo)

Saludoss

[ Padre ]

Driver GPL para TCPA | 20 comentarios (20 temáticos, editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda