DLFP - Entrées de forums de Mben

Quelques précisions terminologiques, notamment GPListique :

null@linuxfr.org (Mben) — Fri, 21 Apr 2006 08:50:51 +0200

J’ai quelques doutes sur ma bonne appréhension/distinction : lien statique/dynamique et module externe/interne.
Si j’ai bien compris, la différence entre un module externe et interne c’est que dans le premier les deux process ne communiquent pas entre eux lors du runtime. Tandis qu’un module interne repose sur l’existence d’un lien dynamique qui les lie entre eux, enclenchant dès lors la clause de réciprocité de la GPL ?

J’ai aussi lu les définitions de la licence Cecill :
-Un Module Externe est un module non dérivé du logiciel, tel que ce module et le Logiciel s’exécutent dans des espaces d’adressages différents, l’un appelant l’autre au moment de son exécution.
- Un Module Interne désigne tout module lié au Logiciel de telle sorte qu’ils s’exécutent dans le même espace d’adressage.

Et du coup, je ne suis plus sûr de comprendre, puisque la définition donnée pour le module externe semble comporter l’existence d’un lien dynamique entre les 2…
Rentre ici la notion d’appel exec() qui permettrait a priori d’empêcher une telle liaison, mais je suis encore moins sur de moi…

Par la même occasion, est-ce quelqu’un pourrait me conseiller des bouquins « de base » en programmation qui me permettraient de mieux appréhender les différentes façons dont des logiciels peuvent coexister, et leurs implications au niveau des licences auxquels ils sont soumis. Je n’ai pour l’instant pas réussi à trouver un ouvrage qui ne soit pas exclusivement technique ou juridique…

Mysql AB is GPL...

null@linuxfr.org (Mben) — Wed, 19 Apr 2006 15:31:33 +0200

Quelques questions aux sujets des implications de la GNU GPL sur l'utilisation de Mysql.
Si un logiciel, ne bénéficiant pas de l'exception FLOSS, nécessite mysql pour fonctionner (recherche dans Base de Données), est-ce que la licence GPL - via sa "clause de réciprocité" va le contraindre à le licencier.
Ou est-ce que, en distribuant le logiciel sans MysqL, le logiciel peut s'en dédouaner, via l'exception ad hoc de la GPL? Sachant qu'il ne fonctionnera qu'à la condition que l'utilisateur ait de son côté Mysql?

Ou vaut il mieux utiliser les anciennes versions de Mysql sous LGPL ?

Hierarchie au sein des développeurs?

null@linuxfr.org (Mben) — Sat, 15 Apr 2006 12:35:43 +0200

Bonjour à tous,

Désolé pour la question de débutants, mais c'est la rubrique qui veut ça...

Est-ce que quelqu'un pourrait me dire où trouver une explication de la hiérarchie entre développeurs, le statut de chacun et leur action sur le logiciel?
J'ai vu passer plusieurs fois le terme d'upstream, mais je ne suis pas sûr d'en percevoir tous les sens... ça serait une sorte de développeur-fondateur d'un logiciel qui aurait le pouvoir de décider de ce qui est intégré directement dans la distribution du logiciel et ce qui ne l'est pas?

Merci d'avance,

Ben

Liaison dynamique ou non?

null@linuxfr.org (Mben) — Fri, 14 Apr 2006 09:04:53 +0200

Bonjour,

N’étant que pseudo programmeur, mais par contre vrai juriste, j’aurai aimé demander quelques précisions sur des alternatives qui ont pu être trouvées afin de lier des éléments programmes entre eux alors qu’ils sont sous licences différentes, et incompatibles.

Un exemple qui me parle bien est celui de KScope, j’ai trouvé une discussion qui avait eu lieu sur un problème d’incompatibilité entre KScope (BSD License) dynamiquement lié avec KDE (LGPL?), Qt (GPL) et graphviz (CPL).
Au final, je pense que pour KDE et Qt, le choix a été de passer tout sous GNU GPL, mais en ce qui concerne la Common Public License de graphviz, ils ont utilisé une combine qui consistait à utiliser ‘dot’ de la command-line=20 au lieu d’utiliser une liaison dynamique avec graphviz.

Cette solution semble avoir résolu les problèmes de licences, mais j’ai du mal à percevoir la différence qui découle de la manipe, et en quoi une telle manipe permet d’éviter l’effet d’une clause de réciprocité ?
Si quelqu’un à des réponses, ou d’autres exemples…
J'aimerai bien essayer d'écrire un article là-dessus une fois que j'aurai mieux cerné le sujet, afin d'éviter justement ce genre de questions...

BEn

Pourrait-on alléger la clause de copyleft pour envers les autres licences libres

null@linuxfr.org (Mben) — Wed, 12 Apr 2006 12:24:56 +0200

C'est ici une question qui m'est en partie venu en répondant à un commentaire de forum, mais que j'essaye ici de réexposer plus clairement.

Lorsque l’on veut utiliser dans un projet sous licence copyleftée des codes sous même licence ou licences « plus libres », pas de problème le tout est sous la première licence (opération courante type intégration de lignes sous BSD dans un travail en GNU GPL . Ça correspond ici à la logique d’un fond commun du libre ou chacun peu puiser librement.

Mais lorsque l’on veut pouvoir profiter sous une licence « plus libre » (type BSD ou MIT) de ligne sous GNU GPL , il faut tout balancer sous GNU GPL . C’est la logique de dire, on ne veut pas accorder plus de droit à l’utilisateur par crainte qu’il propriétarise. Selon moi, dans cette situation la licence copyleftée aboutit au même résultat qu’une licence propriétaire (surtout si le projet GNU GPL et un fork du projet BSD ) puisque le projet sous BSD ne peut rien utiliser s’il veut garder sa licence intacte.

C'est peu être une bonne chose puisque ça permet d'éviter le plagiat entre projet, mais du coup on retrouve presque une logique de propriétaire entre libre. Enfin il me semble.

Je me demande donc s'il n'y aurait pas moyen de contourner plus ou moins ses difficultés.

Est-ce que l'on ne pourrait pas imaginer que la clause de réciprocité, de la GNU GPL par ex., ne s'applique pas dans le cas d'utilisation dans un travail globale sous licence libre, mais retrouverait toute sa vigueur en cas de propriétarisation?

Sorte de "clause de malléabilité" : la licence de GNU GPL reste latente mais peu réapparaitre suivant l’usage de l’½uvre globale : laissant alors le choix d’écarter les lignes sous GNU GPL ou de demander l’accord de son auteur.
Avantages : permet l'incorporation de ligne de code sous GNU GPL , tout en laissant aux autres contributeurs de l’½uvre globale leur travail sous licence type-BSD .
Inconvénients : Transforme plus ou moins la licence libre type BSD en licence quasi-GNU GPL , et surtout crée un imbroglio de licence qui sera dur à démêler par les utilisateurs... D’autant que si des modifications seraient faites aux codes sous GNU GPL elles seraient elles aussi sous GNU GPL .

Finalement il s’agirait de désactiver l’effet réciprocité (ou viral) en cas d’intégration à une ½uvre libre plus grosse, mais pas si c’est l’½uvre GNU GPL elle-même qui est intégrée par une autre oeuvre libre.

Ce n'est ici que du supputatif, mais j'aimerai bien avoir des remarques et commentaires d'autres personnes. Je fais des travaux de recherche justement sur ces incompatibilités est toute suggestion est bienvenue.

Compatibilité entre licences

null@linuxfr.org (Mben) — Sun, 09 Apr 2006 14:55:33 +0200

Objet : travail de synthèse

Je réalise cette année, dans le cadre de mon DEA droit des Créations Immatérielles, un travail sur les multiples licences qui existent dans l'optique d'une diffusion « libre » (« libre » au sens de la FSF ou « open content » au sens de l'OSI). Que ce soit logiciels libres (GNU GPL, Cecill, X, BSD, NPL, ZPL, etc.) ou autres (CC, art libre, IANG, OCL, etc.) : voir comment mieux cerner les problèmes d'incompatibilités issus de cette prolifération de licences, et essayer de donner un cadre et de faire des propositions.

Même si ce travail est en grande partie personnel, il a vocation à trouver des solutions, ou au moins une meilleure compréhension de l'ambriglio juridique en ce qui concerne l'option « libre », et je veux donc croire qu'il touche aussi la communauté du libre.

Ce post a pour dessein de provoquer le maximum de commentaires, questions, témoignages et idées, car je suis sûr que certains aspects de la question qui ont pu m'échapper seront ici très vite soulevés.

Je ne sais pas quels sont les points qui seront les plus intéressants à aborder ici, mais je suis dès à présent à partager ceux qui m'ont déjà retenu : dans le désordre,

- La qualification juridique du contrat de licence (permettant ainsi de le séparer du contrat de mise à disposition du contenu et donc de régler les problèmes du droit de la consommation et l'obligation de garantie par exemple)
-L'adaptation des droits conférés au monde d'internet
-Les différentes motivations conduisant aux licences libres (on les retrouve dans l'OSI et la FSF, mais ça devient plus flou dans le cas des licences touchant aux autres créations), celles-ci entraînant souvent des situations inéluctables.
-La coexistence des oeuvres sous licences, au sein d'une autre oeuvre, ou simple compilation
-Les conditions d'application de la clause copyleft (surtout les détails plus techniques que je maîtrise moins)
-Les techniques de mise en compatibilité des licences (double licenciement, clause expresse envers les licences ultérieures ou d'autres licences)
-Essayer d'établir une sorte de hiérarchie entre licences dès lors que c'est possible, pou recherche les cas de compatibilité ascendante.
-Des exemples d'incompatibilités.

Je sais que le sujet est parfois litigieux, mais j'espère que vous ne considérerait pas ce message comme un troll, car même s'il à pour destination de s'intéresser à des problèmes parfois encore inexistant, ce n'est que pour mieux les contenir...

Merci,

Ben