> Je pense que je peux très bien faire un dlopen sur une bibliothèque et un dlsym sur une fonction, et distribuer le tout dans une autre licence que la GPL sans être en infraction
Tu te trompes, la seule exception est la ligature aux API système. Pour permettre le développement d'applications non compatible GPL sous GNU/Linux, certaines bibliothèques GPL possèdent une exception de liens (GNU libc, libstdc++, Java Classpath).
Rien ne t'interdit d'exécuter ton binaire mais dans tout les cas, la distribution d'une application sous une licence incompatible avec la GPL et d'un plugin/bibliothèque GPL est strictement interdite.
Certes, on peut ruser en séparant la distribution séparée de l'exécutable, ça marcherait pour un plugin, pour une bibliothèque optionnelle mais pas si c'est indispensable au bon fonctionnement de l'application. La distribution source est possible, mais tu connais beaucoup d'applications propriétaires le faisant ?
> C'est similaire à faire un fork()+exec() sur un processus GPL..
Non, tout est exécuté dans un même processus dans un cas, dans deux processus différents dans l'autre.
> Là où la GPL peut se propager c'est lors de la liaison des bibliothèques à la compilation.
Ce n'est pas l'interprétation de la FSF, d'où l'existence d'une exception de lien.
> Les codecs (plugins) gstreamer ne sont pas dans ce cas de figure.
Encore raté, GStreamer est sous licence LGPL et ils expliquent très bien pourquoi sur cette page. http://gstreamer.freedesktop.org/documentation/licensing.htm(...)
Pour ce qui nous intéresse directement!
If you do decide that you want to allow for non-free plugins to be used with your application you have a variety of choices. One of the simplest is using licenses like LGPL, MPL or BSD for your application instead of the GPL. Or you can add a exceptions clause to your GPL license stating that you except GStreamer plugins from the obligations of the GPL.
> je ne vois aucune raison pour qu'un navigateur web qui passe simplement le flux vidéo (sans regarder son format probablement) à gstreamer peut être en infraction.
Primo, le code décodant le flux sera chargé dans le processus du navigateur ce qui en fait un lecteur donc une cible pour le MPEG
Secundo, combien d'utilisateurs de GStreamer sous GNU/Linux utilisent les codecs Fluendo et pas gstreamer-ugly ?
> Pourtant il peut décoder du XYZ si le codec C1 ou C2 est présent sur le système.
Et il serait en infraction selon le MPEG, hein, le codec en question est pas apparu comme par magie sur ta machine.
Supposons que ton lecteur basé sur GStreamer soit ok niveau réglementation au départ, tu télécharges le codec Fluendo ---> tu restes OK vis à vis du MPEG.
Tu télécharges gstreamer-ugly ---> tu n'es plus OK d'après le MPEG encore une fois. Mais par un élan de bonté, ils te fichent la paix à toi et au développeur de ton lecteur. Et que se passe-t-il pour les développeurs de GStreamer ?
On peut s'amuser pendant très longtemps à refiler le problème aux autres mais il est toujours là.
[^] # Re: M
Posté par GeneralZod . En réponse au journal Pourquoi H264 ne doit pas devenir le codec du web (par le MPEG). Évalué à 3.
Tu te trompes, la seule exception est la ligature aux API système. Pour permettre le développement d'applications non compatible GPL sous GNU/Linux, certaines bibliothèques GPL possèdent une exception de liens (GNU libc, libstdc++, Java Classpath).
Rien ne t'interdit d'exécuter ton binaire mais dans tout les cas, la distribution d'une application sous une licence incompatible avec la GPL et d'un plugin/bibliothèque GPL est strictement interdite.
Certes, on peut ruser en séparant la distribution séparée de l'exécutable, ça marcherait pour un plugin, pour une bibliothèque optionnelle mais pas si c'est indispensable au bon fonctionnement de l'application. La distribution source est possible, mais tu connais beaucoup d'applications propriétaires le faisant ?
> C'est similaire à faire un fork()+exec() sur un processus GPL..
Non, tout est exécuté dans un même processus dans un cas, dans deux processus différents dans l'autre.
> Là où la GPL peut se propager c'est lors de la liaison des bibliothèques à la compilation.
Ce n'est pas l'interprétation de la FSF, d'où l'existence d'une exception de lien.
> Les codecs (plugins) gstreamer ne sont pas dans ce cas de figure.
Encore raté, GStreamer est sous licence LGPL et ils expliquent très bien pourquoi sur cette page.
http://gstreamer.freedesktop.org/documentation/licensing.htm(...)
Pour ce qui nous intéresse directement!
If you do decide that you want to allow for non-free plugins to be used with your application you have a variety of choices. One of the simplest is using licenses like LGPL, MPL or BSD for your application instead of the GPL. Or you can add a exceptions clause to your GPL license stating that you except GStreamer plugins from the obligations of the GPL.
> je ne vois aucune raison pour qu'un navigateur web qui passe simplement le flux vidéo (sans regarder son format probablement) à gstreamer peut être en infraction.
Primo, le code décodant le flux sera chargé dans le processus du navigateur ce qui en fait un lecteur donc une cible pour le MPEG
Secundo, combien d'utilisateurs de GStreamer sous GNU/Linux utilisent les codecs Fluendo et pas gstreamer-ugly ?
> Pourtant il peut décoder du XYZ si le codec C1 ou C2 est présent sur le système.
Et il serait en infraction selon le MPEG, hein, le codec en question est pas apparu comme par magie sur ta machine.
Supposons que ton lecteur basé sur GStreamer soit ok niveau réglementation au départ, tu télécharges le codec Fluendo ---> tu restes OK vis à vis du MPEG.
Tu télécharges gstreamer-ugly ---> tu n'es plus OK d'après le MPEG encore une fois. Mais par un élan de bonté, ils te fichent la paix à toi et au développeur de ton lecteur. Et que se passe-t-il pour les développeurs de GStreamer ?
On peut s'amuser pendant très longtemps à refiler le problème aux autres mais il est toujours là.