RE: Free Software en España ... temas legales
> -----Mensaje original-----
> De: npardo@ctv.es [SMTP:npardo@ctv.es]
> Enviado el: miércoles 28 de julio de 1999 16:28
> Para: Tejada Lacaci, Antonio
> Asunto: RE: Free Software en España [Era: Re: Perdonar pero no me
> aclaro]
>
Por cierto, esta tanda de mensajes (no sólo el tuyo) me ha llegado
sin la cabecera
Content-Transfer-Encoding: quoted-printable
de manera que se ve todo fatal (bueno, todo, todo no, sólo las cosas
con acentos y demás ;) )
¿Sólo me ha pasado a mí o le ha pasado también a alguien más?
¿alguien ha estado hurgando con el soft de la lista?
> ::::: El d=EDa Wed, 28 Jul 1999 08:27:41 +0200, "Tejada Lacaci, Antonio=
> "
> <atejada@bancamarch.es> contaba:
>
>
> :: Si te das cuenta, todo esto no alude a algoritmos o formatos,
> :: sino a procedimientos (que s=ED son patentables, del mismo modo
> :: que lo son los dispositivos f=EDsicos de decodificaci=F3n de mp3=
> ).
>
> Tejada:: =09%-# =BFy la diferencia entre un algoritmo y un
> Tejada:: procedimiento es? :-?
>
>
> Toma lo que sigue con cierta reserva, al menos hasta que compruebe si
> existe jurisprudencia o doctrina sobre el tema. (Por cierto, que la
> pregunta es muy, muy interesante :)
.. seguro que no tanto como tus respuestas ;D
> Hasta donde yo s=E9, el algoritmo es un procedimiento matem=E1tico. La=
> Ley de Patentes no utiliza de hecho el t=E9rmino `algoritmo' (mea culpa=
> :), sino que dice ``m=E9todo matem=E1tico''. En mi opini=F3n, de lo qu=
> e se trata es de que sea un m=E9todo _intr=EDnsecamente matem=E1tico_.
>
> En el caso del mp3, los algoritmos sirven para implementar un
> procedimiento que se basa en la manipulaci=F3n no matem=E1tica de los
> datos. Quiero decir que no se trata de que hayan encontrado una forma
> de guardar los mismos datos en menos espacio con la aplicaci=F3n de una=
> f=F3rmula de transformaci=F3n, o de que hayan encontrado una forma nuev=
> a de codificar sonido y en eso consista todo, sino que parten de un
> principio f=EDsico (para el o=EDdo humano una buena parte del sonido es=
... espera, que me voy a patentar la "compresión por diccionario"
(aquella en la que se traducen los datos a codificar por entradas o índices
a un diccionario o tabla, que puede ir o no incluído en los datos finales) y
voy a hacerme rico (el LZW, el bzip y gzip son "algoritmos" que emplean el
"procedimiento" "compresión por diccionario").
¿Pero eso no es una locura? ... es decir, sería mucho más sensato
patentar el algoritmo concreto, no la "idea" sobre el algoritmo. ¿Quieres
decir que la patente sobre la "idea" rige sobre todos los algoritmos que se
desarrollen y empleen esa idea como base? :-?
Bajo mi punto de vista, eso se contradice bastante con que sí se
pueda patentar el dispositivo físico (que es la "implementación" física de
"una idea" o procedimiento). El dispositivo físico sería análogo a una
implementación software concreta.
O mejor aún, voy a patentar un procedimiento por el cual un
"engendro se comunica vía impulsos eléctricos y permite la ejecución de
patrones de órdenes".
Ya supongo que habrá un límite a lo abstracto que pueda ser la
definición de lo que patentes, pero eso implica que está sujeto a
valoraciones subjetivas, por lo que a saber qué te dejan patentar y qué no!
.... ¡por probar que no quede!.
[...]
> No estoy seguro de estarme explicando con claridad (no porque no se
> pueda, sino porque posiblemente a m=ED me falta habilidad para ello; si=
> tienes problemas lo intentar=E9 de nuevo, h=E1zmelo saber :).
... creo que sí que lo entiendo, pero me parece bastante peligroso
lo que entiendo. Eso de que se pueda patentar la idea ... pffff .... es una
locura. Ya te digo que comprendo más que se pueda patentar el algoritmo
concreto antes que la idea genérica :-m ... claro, que entonces lo de
patentar el algoritmo sería muy específico y quizás ese mismo algoritmo con
un pequeño cambio ya no sería afectado por la patente original :-m
> La pregunta siguiente (al menos eso me parece) es la de si los dem=E1s
> m=E9todos de compresi=F3n no podr=EDan considerarse tambi=E9n como
> procedimientos f=EDsicos con expresi=F3n matem=E1tica. Creo que no, au=
> nque seguramente t=FA puedes decidirlo con mucho m=E1s conocimiento de
> causa=
> :)
Pues ya te digo, parece que eso que tú explicas como procedimiento
no es más que la idea genérica de la que luego parten algoritmos
específicos.
[...]
> Otra cosa ser=EDa jpeg, aunque no estoy seguro en=
> lo m=E1s m=EDnimo (por indicaciones creo que suprime datos en una
> transacci=F3n calidad-tama=F1o de fichero, pero no lo s=E9 de cierto y
> habr=EDa que comprobar si es una simple p=E9rdida de calidad que result=
> a aceptable al ojo humano o se ha tenido en cuenta el funcionamiento de
> =E9ste a la hora de dise=F1ar el procedimiento y la p=E9rdida).
Ya que estoy, te suelto el rollo ;_) : El jpeg se basa en que el ojo
de los seres humanos es más sensible a la luminancia que al resto de valores
de la escala luminancia/crominancia (o saturación)/contraste y en la
relación de "continuidad lumínica" que tiene una imagen fotorrealista (por
eso no funciona bien con dibujos animados, p.ej.).
Lo primero tiene que ver con la relación entre bastoncillos y conos
que tiene el ojo humano (los dos tipos de "sensores" de color o de luz, por
eso a los gatos no les gustan las imágenes comprimidas con jpeg ;D). Ello
implica que los colores con menor luminancia (azules....) son "maltratados"
por el algoritmo de compresión jpeg, que se basa también en cuantización,
análisis de Fourier (FFT):
El mapa de bits se divide en regiones de 8x8 (de ahí el "mosaico"
que sale si te pasas con el factor de pérdida) se toman esas regiones de 8x8
como una señal de 64 valores a lo largo del tiempo, se pasa esa señal al
"dominio frecuencial" (tú una señal o función puedes verla "en función del
tiempo" o si se repite con el tiempo, puedes verla en función de la
frecuencia con que se repite) y se emplea un método para poder extraer de
esa señal sus componentes fundamentales (la transformada de Fourier y los
coeficientes de Fourier), despreciando así componentes no fundamentales
(aquí es donde entra la pérdida de calidad, según cuántos componentes
desprecies). Luego además hay una ponderación de componentes según una
matriz, y una postcompresión de la lista de componentes definitiva según
Huffmann, pero massomenos es como te he contado (que ya me sabía mal que tú
me contases tantas cosas y yo nada a ti ;D).
> Espero que esto aclare algo. Si encuentro jurisprudencia, te lo har=E9=
> saber.
gracias! :)
> Un saludo.
>
> -- =20
>
> RESET
>
>
Antonio Tejada Lacaci atejada@bancamarch.es
Depto. Análisis y Programación
Banca March S.A.
Reply to: