|
|
|
|
||||||
| fr.comp.os.linux.debats Promouvoir, critiquer et troller sur Linux. |
![]() |
|
|
LinkBack | Outils de la discussion |
|
|
#1 |
|
Messages: n/a
Hébergeur: |
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 ? 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 ? Comment obtenir une réponse formelle sur ces questions ? Merci. Tintin92 |
|
|
|
#2 |
|
Messages: n/a
Hébergeur: |
"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. |
|
|
|
#3 |
|
Messages: n/a
Hébergeur: |
Nicolas George a écrit : > > Oui, pour peu qu'à la dernière question, ça reste bien des binairesséparés. Merci de la réponse. Tintin92 |
|
|
|
#4 |
|
Messages: n/a
Hébergeur: |
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 |
|
|
|
#5 |
|
Messages: n/a
Hébergeur: |
> 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" ? |
|
|
|
#6 |
|
Messages: n/a
Hébergeur: |
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 |
|
|
|
#7 |
|
Messages: n/a
Hébergeur: |
Bonjour,
D'abord merci de tes réponses. Michel Talon a écrit : > > Sur le site Web de la FSF tu as des réponses précises à ces questions. 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 quit'oblige > en cas de redistribution à redistribuer sous licence GPL. Autant que jesache > 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 |
|
|
|
#8 |
|
Messages: n/a
Hébergeur: |
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/...r-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....f_Derived_Work et ceci: http://www.digital-law-online.info/l...reatise27.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 |
|
|
|
#9 |
|
Messages: n/a
Hébergeur: |
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 |
|
|
|
#10 |
|
Messages: n/a
Hébergeur: |
Merci encore de cette réponse détaillée.
Tintin92 |
|
![]() |
| Outils de la discussion | |
|
|