> Ca semble être une interprétation des gens de la FSF sur la licence GPL
En même temps, c'est eux qui l'ont écrite, ils savent peut-être mieux que toi ou moi ce que signifie la GPL. Sinon, le bout de texte en question fait partie de la licence, c'est la notice d'utilisation, même l'OSI l'a reprise ... http://www.opensource.org/licenses/gpl-2.0.php
Tes exemples sont faux.
1. Tu passes par une couche d'abstraction en l'occurence JDBC, et tu n'es strictement lié qu'à celui-ci. Par contre, tu n'as pas le droit de distribuer ton pilote JDBC sous GPL avec ton programme mais l'utilisateur final peut les associer si il le souhaite.
Pour montrer que ton exemple est daubé, prenons le cas du pilote JDBC MySQL® Connector/J sous licence GPL. MySQL Labs précise que si tu ne veux pas être soumis à la GPL, tu dois leur acheter une licence.
Commercial licenses for either version can also be purchased from MySQL AB, for those who don't wish to be bound by the GPL. http://www.mysql.com/products/connector/j/
2. Là, c'est du grand n'importe quoi. On te parle de lien dans le sens informatique du terme (http://fr.wikipedia.org/wiki/%C3%89dition_de_liens). Là, aucun lien n'est réalisé, tu récupéres la sortie d'un autre programme et tu l'introduit dans l'entrée d'un autre programme, c'est le principes des pipes.
Si je fais cat mon_fichier.txt | mon_programme_proprio_ala_con, si j'utilise GNU cat, mon_programme_proprio_ala_con n'a pas à passer sous GPL !
Pour te prouver que les notions de "travaux dérivés" et de "lien" ne sont pas opposé, un extrait de la FAQ GPL.
If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?
---------
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.
If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case.
En gros, dès que ton code devient intime avec du code sous GPL (même processus, partage de structure, appels de fonctions etc ...), ton code constitue un "travail dérivée" et doit être licencié sous une licence compatible GPL.
[^] # Re: Explication dans les commentaires
Posté par GeneralZod . En réponse au journal VMware et la GPL. Évalué à 3.
En même temps, c'est eux qui l'ont écrite, ils savent peut-être mieux que toi ou moi ce que signifie la GPL. Sinon, le bout de texte en question fait partie de la licence, c'est la notice d'utilisation, même l'OSI l'a reprise ...
http://www.opensource.org/licenses/gpl-2.0.php
Tes exemples sont faux.
1. Tu passes par une couche d'abstraction en l'occurence JDBC, et tu n'es strictement lié qu'à celui-ci. Par contre, tu n'as pas le droit de distribuer ton pilote JDBC sous GPL avec ton programme mais l'utilisateur final peut les associer si il le souhaite.
Pour montrer que ton exemple est daubé, prenons le cas du pilote JDBC MySQL® Connector/J sous licence GPL. MySQL Labs précise que si tu ne veux pas être soumis à la GPL, tu dois leur acheter une licence.
Commercial licenses for either version can also be purchased from MySQL AB, for those who don't wish to be bound by the GPL.
http://www.mysql.com/products/connector/j/
2. Là, c'est du grand n'importe quoi. On te parle de lien dans le sens informatique du terme (http://fr.wikipedia.org/wiki/%C3%89dition_de_liens). Là, aucun lien n'est réalisé, tu récupéres la sortie d'un autre programme et tu l'introduit dans l'entrée d'un autre programme, c'est le principes des pipes.
Si je fais cat mon_fichier.txt | mon_programme_proprio_ala_con, si j'utilise GNU cat, mon_programme_proprio_ala_con n'a pas à passer sous GPL !
Pour te prouver que les notions de "travaux dérivés" et de "lien" ne sont pas opposé, un extrait de la FAQ GPL.
If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?
---------
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.
If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case.
http://www.fsf.org/licensing/licenses/gpl-faq.html
En gros, dès que ton code devient intime avec du code sous GPL (même processus, partage de structure, appels de fonctions etc ...), ton code constitue un "travail dérivée" et doit être licencié sous une licence compatible GPL.