Logiciel sous licence GPL et logiciel commerciale.

"Tintin92" , dans le message
<1151511062.176034.288730@i40g2000cwc.googlegroups.com>, a écrit :

Ai-je le droit de lancer ce logiciel depuis mon logiciel commercial ?
Ai-je le droit d'exploiter les résultats fournis par ce logiciel dans
mon logiciel commercial ?
Ai-je le droit de fournir dans un même packaging d'installation mon
logiciel et ce logiciel GPL ?

Oui, pour peu qu'à la dernière question, ça reste bien des binaires séparés.

Oui, pour peu qu'à la dernière question, ça reste bien des binaires séparés.

Merci de la réponse.

Tintin92

Tintin92 <tintin922006-google@yahoo.fr> wrote:

Bonjour,

Soit un logiciel de statitiques sous licence GNU GENERAL PUBLIC LICENSE
comme celui-ci :
http://www.r-project.org/

Ai-je le droit de lancer ce logiciel depuis mon logiciel commercial ?

Oui

Ai-je le droit d'exploiter les résultats fournis par ce logiciel dans
mon logiciel commercial ?

Oui

A supposer évidemment que tu lances R comme un processus indépendant,
tu lui fournis des entrées tu lis les sorties à partir de ton logiciel,
mais jamais tu ne cherches à mettre des libariries de R avec ton
logiciel dans un même exécutable.

Ai-je le droit de fournir dans un même packaging d'installation mon
logiciel et ce logiciel GPL ?

Oui, c'est "mere aggregation".

Comment obtenir une réponse formelle sur ces questions ?

Sur le site Web de la FSF tu as des réponses précises à ces questions.
Le problème de la clause virale se pose d'aprés eux quand on utilise
des parties sous GPL dans un ensemble qui fonctionne dans le même
espace d'adressage, autrement dit, en pratique, quand on utilise des
librairies, y compris dynamiques, y compris chargées dynamiquement
(plugins) sous GPL. Alors l'ensemble est "dérivé" de la partie ce qui t'oblige
en cas de redistribution à redistribuer sous licence GPL. Autant que je sache
la définition précise de ce qu'est une oeuvre dérivée dans ce domaine n'a en
fait jamais été posée par la justice américaine, et à fortiori chez nous.
Donc quelles que soient les déclarations de la FSF à ce sujet il subsiste un
flou. Le fameux procés de SCO contre IBM reposait sur l'idée que Linux est
"dérivé" de Unix dans un sens large et donc que SCO a des droits dessus.
Jusqu'à présent il semble que ce raisonnement n'ait pas réussi à SCO!

Merci.

Tintin92

--

Michel TALON

Autant que je sache
la définition précise de ce qu'est une oeuvre dérivée dans ce dom aine n'a en
fait jamais été posée par la justice américaine, et à fortiori chez nous.
Donc quelles que soient les déclarations de la FSF à ce sujet il subs iste un
flou.

Pourquoi ? C'est bien la FSF qui a utilisé le terme "oeuvre dérivée"
a été employé dans la GPL par la FSF, non? Qu'est-ce qui l'empêche
de préciser ce qu'est pour elle une "oeuvre dérivée" ?

totof01 <cdesquesnes@ifrance.com> wrote:

Autant que je sache
la définition précise de ce qu'est une oeuvre dérivée dans ce domaine n'a en
fait jamais été posée par la justice américaine, et à fortiori chez nous.
Donc quelles que soient les déclarations de la FSF à ce sujet il subsiste un
flou.

Pourquoi ? C'est bien la FSF qui a utilisé le terme "oeuvre dérivée"
a été employé dans la GPL par la FSF, non? Qu'est-ce qui l'empêche
de préciser ce qu'est pour elle une "oeuvre dérivée" ?

Ce n'est pas la FSF qui définit la notion d'oeuvre dérivée c'est la justice.
La FSF se contente de l'utiliser telle qu'elle est. C'est pour ça que la CDDL
spécifie de façon précise la portée de l'application de sa licence, pour
qu'elle ne s'applique pas aux oeuvres dérivées en général. Il est clair que se
reposer sur une définition de justice c'est se reposer sur une définition
fluctuante au cours du temps, fluctuante d'une juridiction à l'autre aux états
unis et à fortiori encore plus entre des juridictions d'états différents.
La portée de l'application de la CDDL est beaucoup plus restreinte que celle
de la GPL -si on en croit la définition d'oeuvre dérivée telle qu'expliquée
sur le site de la FSF.



--

Michel TALON

Bonjour,

D'abord merci de tes réponses.

Sur le site Web de la FSF tu as des réponses précises à ces questio ns.

Je suis allé voir là :
http://www.fsfeurope.org/index.fr.html

Mais je suis un peu perdu sur ce site.
Pouvez-vous être plus prècis en me disant ou je peux trouver des
infos.

Encore merci.

Tintin92

Le problème de la clause virale se pose d'aprés eux quand on utilise
des parties sous GPL dans un ensemble qui fonctionne dans le même
espace d'adressage, autrement dit, en pratique, quand on utilise des
librairies, y compris dynamiques, y compris chargées dynamiquement
(plugins) sous GPL. Alors l'ensemble est "dérivé" de la partie ce qui t'oblige
en cas de redistribution à redistribuer sous licence GPL. Autant que je sache
la définition précise de ce qu'est une oeuvre dérivée dans ce dom aine n'a en
fait jamais été posée par la justice américaine, et à fortiori chez nous.
Donc quelles que soient les déclarations de la FSF à ce sujet il subs iste un
flou. Le fameux procés de SCO contre IBM reposait sur l'idée que Linu x est
"dérivé" de Unix dans un sens large et donc que SCO a des droits dess us.
Jusqu'à présent il semble que ce raisonnement n'ait pas réussi à SCO!

Merci.

Tintin92

--

Michel TALON

Tintin92 <tintin922006-google@yahoo.fr> wrote:

Mais je suis un peu perdu sur ce site.
Pouvez-vous être plus prècis en me disant ou je peux trouver des
infos.

La "philosophie" de la FSF:
http://www.fsf.org/licensing/essays/free-sw.html
http://www.fsf.org/licensing/essays/pragmatic.html
http://www.fsf.org/licensing/essays/free-software-for-freedom.html

Les licences:
http://www.fsf.org/licensing/licenses/index_html

Dans tout celà et je n'ai pas trouvé grand chose d'autre, j'ai effectivement
l'impression que la FSF a restructuré son site pour faire disparaître les
choses précises qu'il y avait autrefois et les remplacer par un vague brouet
qui plait à tout le monde et ne dit rien de clair. Je dois donc m'excuser pour
avoir cité la fsf comme une source de renseignements précis, ou en tout cas je
ne sais pas où ils sont. Je suis certain d'y avoir vu des choses bien plus
précises, en particulier sur la distinction entre "derivative work" et
"mere aggregation".

J'ai trouvé une discussion que j'aime mieux ici:
http://en.wikipedia.org/wiki/Copyleft
En particulier:
"
Additionally, some popular copyleft licenses such as the GPL have an
"at-arms-length" clause specifying that copyleft components can interact with
non-copyleft components as long as the communication is relatively simple,
such as executing a command-line tool with a set of switches. As a
consequence, even if one module of an otherwise non-copyleft product is placed
under the GPL, it may still be legal for other components to communicate with
it in a limited fashion.
"

Tu peux aussi regarder ceci:
http://www.wxwidgets.org/wiki/index.php/Developers_Notebook-Definition_Of_Derived_Work
et ceci:
http://www.digital-law-online.info/lpdi1.0/treatise27.html
"
With dynamically-linked libraries, the application program being distributed
is no longer a compilation that includes the library. Because the library is
not being distributed with the application program, no permission is needed
from the copyright owner of the library for the distribution to users. Users
must, of course, be authorized to use the library, but if they are owners of a
copy of the library, under Section 117 they can make any adaptations of the
library necessary to use it with the application program.

Some have claimed that an application program that needs a library for its
operation is a derivative work of that library. They take that position
because the application program is based on the library because it was written
to use the subroutines and other aspects of the library.

Such a position is misplaced. Even though the definition of a derivative work
contained in Section 101 seems to support such a reading when it talks about a
derivative works being based upon one or more preexisting works, the examples
all illustrate derivative works where the original work is somehow
incorporated or recast in the derivative work:

A derivative work is a work based upon one or more preexisting works, such as
a translation, musical arrangement, dramatization, fictionalization, motion
picture version, sound recording, art reproduction, abridgment, condensation,
or any other form in which a work may be recast, transformed, or adapted. A
work consisting of editorial revisions, annotations, elaborations, or other
modifications which, as a whole, represent an original work of authorship, is
a derivative work.
"

dont tu peux tirer des conclusions inverses de celles que tire la FSF. Bref
cette affaire du copyleft est un véritable champ de mines.





--

Michel TALON

Michel Talon <talon@lpthe.jussieu.fr> wrote:

ne sais pas où ils sont. Je suis certain d'y avoir vu des choses bien plus
précises, en particulier sur la distinction entre "derivative work" et
"mere aggregation".

En fait ça doit être ici:
http://www.gnu.org/licenses/gpl-faq.html

"
Does the GPL require that source code of modified versions be posted to the
public?
The GPL does not require you to release your modified version. You are
free to make modifications and use them privately, without ever releasing
them. This applies to organizations (including companies), too; an
organization can make a modified version and use it internally without ever
releasing it outside the organization.

But if you release the modified version to the public in some way, the GPL
requires you to make the modified source code available to the program's
users, under the GPL.

Thus, the GPL gives permission to release the modified program in certain
ways, and not in other ways; but the decision of whether to release it is up
to you.
Can I have a GPL-covered program and an unrelated non-free program on the same
computer?
Yes. The "mere aggregation" clause in the GPL makes this permission
explicit, but that only reinforces what we believe would be true anyway.
"
"
What is the difference between "mere aggregation" and "combining two modules
into one program"?
Mere aggregation of two programs means putting them side by side on the
same CD-ROM or hard disk. We use this term in the case where they are separate
programs, not parts of a single program. In this case, if one of the programs
is covered by the GPL, it has no effect on the other program.

Combining two modules means connecting them together so that they form a
single larger program. If either part is covered by the GPL, the whole
combination must also be released under the GPL--if you can't, or won't, do
that, you may not combine them.

What constitutes combining two parts into one program? This is a legal
question, which ultimately judges will decide. We believe that a proper
criterion depends both on the mechanism of communication (exec, pipes, rpc,
function calls within a shared address space, etc.) and the semantics of the
communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are
definitely combined in one program. If modules are designed to run linked
together in a shared address space, that almost surely means combining them
into one program.

By contrast, pipes, sockets and command-line arguments are communication
mechanisms normally used between two separate programs. So when they are used
for communication, the modules normally are separate programs. But if the
semantics of the communication are intimate enough, exchanging complex
internal data structures, that too could be a basis to consider the two parts
as combined into a larger program.
"




--

Michel TALON

Merci encore de cette réponse détaillée.

Tintin92