Programación Grafica

[Carlos Manuel Duclos Vergara]

Holas,

>Ahe, ahí está el asunto. ¿donde dice la LGPL que por escribir ese pedazo
>de código estas haciendo un "trabajo derivado" (usando las palabras
>dentro de la LGPL)?

de acuerdo a la secciones 5 y 6 de la LGPL si fuiste lo suficientemente 
cuidadoso y solo "usaste" la biblioteca no generas un trabajo derivado, 
el problema no esta en lo que entendamos por trabajo derivado sino 
que en la interpretacion legal de esto (que es lo que parti diciendo). 
Ademas especifica claramente que al linkear tu software con la biblioteca 
generas un binario que debe ser LGPL (notese que usar esta definido 
como que la biblioteca tiene que estar cargada en memoria y tu interaccion 
con ella se reduce solo a invocar metodos y pasar parametros). Ojo que tambien 
menciona que pasa si usas los header files de la biblioteca, mientras uses menos
de 10 lineas queda claro que no tienes problemas, pero al usar mas de 10 
lineas de codigo del header file (imaginate si necesitas usar un header file
que solo contiene una larga lista de #define..... ) quedas otra vez en
terreno de nadie. Ese es el punto que sostengo, la LGPL te deja un margen 
para interpretaciones que no se da por ejemplo con la GPL. Y donde hay 
margen para interpretaciones + espacio para poner abogados.......

>* Uso de Gtk+ desde C.
>Este caso es _idéntico_ al caso de la libc. Puedes derivar un widget,
>pero eso es sólo usar la API de Gtk+, no requiere modificar nada de
>la biblioteca original. El pasar punteros a funciones como "callbacks"
>no entra en mis libros como "modificación".

necesitas al menos usar los header correspondientes, y ya te estas
acercando a terreno peligroso. Repito el problema de la LGPL es lo que
no dice mas que lo que dice, deja muchos puntos abiertos a interpretacion
y ese es el punto.

>* Uso de Gtkmm, desde C++.
[...]
>Muchos discuten, exépto los desarrolladores. Para más remate, el 90%
>del código de Gtkmm es generado de manera automática desde los
>encabezados de Gtk+, por lo que ni siquiera los desarrolladores han
>tenido que ver mucho con las clases e interfaces.

y donde esta mencionado en la LGPL que el codigo tiene que ser escrito 
por humanos? (si suena ridiculo, pero es verdad). El hecho de que un
desarrollador no tome en cuenta esos detalles no los hacen menos
validos, ya que el problema no es la creencia sino el hecho de que llegado
el momento se haga una interpretacion legal de esos argumentos. Y dado
que la LGPL a diferencia de la GPL (que por lo demas no deja espacios a
la imaginacion, aun a costa de meter las patas en algunos casos) deja 
espacios es posible que algun iluminado se le ocurra una interpretacion
legal diferente de lo que fue la intencion inicial.


>¿Y acaso en tu ejemplo se modificó código LGPL? ¿cúal, que _no_ lo veo?
>Perdón, pero eso es FUD. Nada más ni nada menos.

para generar la clase BOTON1_EXTENDIDO requiero al menos utilizar los
header files de la biblioteca, como probablemente ocupen mas de 10
lineas ya entre a terreno donde las interpretaciones legales me pueden
jugar chueco.

INSISTO, mi punto no es atacar LGPL por atacarla, sino que hacer ver que
a diferencia de otras licencias la LGPL deja espacios abiertos a 
interpretaciones legales. Y ese es el punto que a _MI_ no me deja tranquilo,
ya que algun dia puede surgir algun iluminado con ideas novedosas y
tratar de retorcer un poco las cosas. En ese aspecto la GPL es sumamente
clara, no tiene puntos intermedios o la cumples o no.

[...]
>Acabo de escribir una función "strcpy2" que deriva de strcpy, cambiando
>ligeramente la funcionalidad. ¿es un trabajo derivado de la biblioteca?

noup, pq el prototipo de la funcion strcpy ocupa menos de 10 lineas dentro
del header file (notese que dice que tu codigo fuente no sera cubierto bajo 
LGPL pero deja claramente especificado que no se saben los alcances legales 
de esto).  Claro que aun tienes que tomar provisiones en el caso de
linkear esa funcion con el resto de la glibc...
(tu codigo objeto podria pasar a ser LGPL)

Xhau