La solution est maintenue, malgré les progrès de la version 2.0 de la licence Apache : ce n'est pas une licence compatible au terme de la GNU GPL.
Même si la fondation Apache prône pour la compatibilité, la réponse de la FSF me semble sans appel :
. Pour qu'une licence soit compatible avec la GPL, il faut qu'elle puisse « inclure » cette dernière, c'est-à-dire qu'elle confère au moins autant de droits et surtout pas plus d'obligation.
. La licence Apache contient une procédure de résiliation des licences de brevets en cas de plainte à l'égard de l'un des donneurs de licence. Cette clause n'est pas incluse dans la GNU GPL.
. Si la GNU GPL venait à couvrir le code sous Apache, alors le donneur de licence perdrait cette prérogative, puisque n'importe qui pourrait ressortir la partie du code qui l'intéresse et l'utiliser sous GNU GPL.
. Une double licence permet à quiconque d'utiliser l'une ou l'autre des licences, pas d'appliquer les deux simultanément (même si ça peut être au cas par cas). Puisque c'est le licencié qui choisit, il est certain qu'il choisira de ne pas appliquer cette obligation incluse dans la licence Apache.
Une Solution ? Peut-être bien la clause 7 de la GPL v3, qui organise justement un système de compatibilité en cas de licence imposant uniquement certaines obligations en plus... à suivre...
Journal Ce qui rend la licence Apache incompatible avec la GNU GPL
8
juil.
2006
# mais euh
Posté par Gniarf . Évalué à 6.
[^] # Re: mais euh
Posté par Sylvain Sauvage . Évalué à 6.
[^] # Re: mais euh
Posté par Benjamin Jean (site web personnel) . Évalué à 3.
Les codes de l'une de peuvent ni être repris, ni combiner avec ceux de l'autre, c'est tout de même dommage, non ?
Bon, désolé, j'ai dû me tromper de site, je considère tout de même le sujet comme vraiment important, ça ne sert à rien que le libre s'étende si tout ce qui est développé dans une communauté doit l'être de nouveau dans une autre...
http://www.gnu.org/licenses/license-list.fr.html
http://mail-archives.apache.org/mod_mbox/incubator-harmony-d(...)
Cordialement,
(désolé pour le gras, je ne le referai pas)
[^] # Re: mais euh
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
Tu as parfaitement, et j'ai trouvé tes journaux intéressants. Le problème, c'est qu'il n'y pas vraiment de débat possible (tu sembles avoir raison, et il n'y a pas de question ouverte).
Donc continues à poster des journaux, le nombre de commentaires ne reflète pas forcément l'intérêt des lecteurs.
Ce n'est pas grave que deux grosses communautés libres fassent bande à part sans pouvoir combiner leur force ?
Les codes de l'une de peuvent ni être repris, ni combiner avec ceux de l'autre, c'est tout de même dommage, non ?
Certes, c'est dommage, mais tout le monde n'a pas la même vision du libre, les mêmes attentes, ce qui conduit à la diversité des licences et à leurs incompatibilités. L'intérêt, c'est que chacun peut mettre son travail sous la licence qui lui plaît, et ça permet toujours de troller sur BSD et GPL ;)
Ceci dit, les incompatibilités de licences empêchent de reprendre du code, pas de distribuer différents programmes qui s'utilisent conjointement.
Et sinon, pire que l'incompatibilité entre Apache et GPL, il y a l'incompatibilité GPL dans BSD...
[^] # Re: mais euh
Posté par Benjamin Jean (site web personnel) . Évalué à 2.
C'est vrai, mais au moins, les développements BSD peuvent être repris sur GPL, ce n’est pas le cas avec Apache...
Le problème est que dès qu'une des licences est copyleft, elle peut considérer de manière assez large l'oeuvre dérivée qui est soumise à sa licence... La LGPL permet à un autre programme de l'utiliser, pas la GNU GPL qui exigera que celui-ci soit aussi sous GPL s'il est basé sur le premier ou s'il forme un tout avec celui-ci (not. par le biais de lien dynamique).
Merci pour les commentaires, je commençais à croire que le site était définitivement fermé aux non-développeurs qui s'intéressent au libre ;)
[^] # Re: mais euh
Posté par BAud (site web personnel) . Évalué à 3.
Je pense à l'empilage de couches permettant de fournir une application :
- apache / mod_php / ...
- pear / ADOdb / smarty : des frameworks (pour simplifier, canevas en français pour les inconditionnels)
- MySQL ou PostgreSQL pour la base
- une appli web tel que tiki-wiki
La question subsidiaire étant : sous quelle(s) licence(s) distribuer le paquet global d'installation de l'applciation ?
Si tu as besoin des liens vers ces divers éléments, je te les chercherai (avec leurs licences respectives) mais google est aussi ton ami ;-)
[^] # Re: mais euh
Posté par Benjamin Jean (site web personnel) . Évalué à 0.
[^] # Re: mais euh
Posté par BAud (site web personnel) . Évalué à 4.
alors apache sert les pages, les mod_ interprètent le langage utilisé, les framework fournissent les fonctions pour donner l'accès à la base ou la représentation visuelle, la base bin c'est le contenu elle est up, et l'appli bin c'est les php initiaux appelés...
tu as des notions de programmation ?
en bref
http://tikiwiki.org implique :
- apache sert la page et redirige vers index.php
- mod_php exécute index.php (en langage php)
- index.php se connecte à MySQL via ADOdb et smarty prend le résultat des requêtes et les remet en forme (via php) pour l'affichage
- tikiwiki c'est http://tikiwiki.org un wiki pourri de fonctionnalités (je n'ai pas retrouvé la licence immédiatement, tu auras plus de chance que moi)
il y a deux modes de fonctionnement :
- installation indépendante des modules : je suppose que la licence de chacun est ainsi respectée
- la distribution d'un tout en tar.gz qui permettrait de le faire fonctionner (ce qui n'est pas fait actuellement mais peut exister avec d'autres projets)
après tu peux regarder le static vs dynamic (.so) mais c'est un autre exercice... exemple à trouver (les jeux sont un bon exemple).
[^] # Re: mais euh
Posté par Gniarf . Évalué à 2.
* la couche tcp/ip du serveur, parce que ce n'est pas Apache qui va écrire directement sur la carte réseau,
* la quincaillerie qui a permis de transformer le nom du site en adresse ip, une partie peut se trouver sur cette machine.
c'est de moins en moins simple, n'est-ce pas ?
[^] # Re: mais euh
Posté par Benjamin Jean (site web personnel) . Évalué à 2.
GNU GPL
On va considérer la licence 2 puisque c'est celle qui nous intéresse (incompatible GPL)
Je fais simple, disons PHP license dans sa dernière version (3.01) (incompatible GPL)
MySQL : GPL ac exception FLOSS (donc copyleft faible vis-à-vis de toutes les autres licences présentes)
PostgreSQL : BSD
Pear semble être ss PHP, on va dire la dernière (incompatible GPL)
ADOdb semble être BSD/LGPL (double licence totalement inutile)
smarty semble être ss LGPL
Puisque tous les logiciels ne font que s'ajouter, il faut regarder du côté des copylefts forts. En l'occurrence, le seul qui peut poser problème, c'est ton cher wiki.
Toutes les licences sont respectées puisque logiciels indépendants et séparés, et non distribués comme un tout
Dur de dire la même chose, si tu distribues le tout, je pense que tu peux facilement tomber dans la seconde partie liée à la distribution disant que lorsque l'on distribue des modules séparés et indépendants avec le logiciel sous GPL, comme un tout, alors la licence s'applique.
Puisqu'il y a problème pour que la GPL couvre le code sous PHP (clause supplémentaire liée au nom PHP) et Apache (Brevet resiliation), ça bloque.
Oui, non là je pense qu'il ne faut pas pousser la GPL trop loin non plus, j'ai du mal à y voir un logiciel comme un tout... De plus, niveau lien dynamique, c'est pas ça non puisque s'il y a communication, elle se fait uniquement par renvoi, pas de mémoire partagée et compagnie.
(je n’ai aucun problème avec les cas concrets, mais autant qu'ils soient un peu plus concrets alors ;) )
[^] # Re: mais euh
Posté par BAud (site web personnel) . Évalué à 3.
Pour moi, dans le tar.gz chaque composant reste tout de même dans son arborescence. La GPL s'applique sur tiki-wiki dans une sous arborescence, en quoi pourrait-elle influer sur les autres composants qui sont dans leur propre répertoire ?
J'ai aussi vu des distribution en tar.gz contenant un tar.gz pour chaque composant, je n'ai jamais trop compris ce qui pouvait justifier cette lubie (peut-être une séparation plus claire par licence ?).
Après, pour déterminer la licence globale du tar.gz, hum bin, dire que chaque licence de chaque composant s'applique à chaque composant et non au tout :/
Il y a le cas hypothètique, pour du php (je n'ai pas d'exemple sous la main :/ si quelqu'un trouve), où tout serait compilé et lié statiquement, genre du php compilé : dans ce cas, pear (licence php) serait intégré au code de tiki-wiki (licence GPL), sous forme "compilée" la GPL s'applique là au tout, ce qui est effectivement plus gênant... la licence GPL ne pouvant s'appliquer au composant pear inclus (comme quoi, il faut bien choisir ses composants libres au démarrage du projet...).
ah oui sinon j'ai retrouvé la sortie de la licence php v3.0 reconnue par l'osi https://linuxfr.org/2003/09/04/13830.html
c'est ballot d'avoir mis dans la licence la non utilisation du nom PHP dans un soft sous licence PHP :/
AMHA, IANAL (vu que JNSPJ ça rend vachement moins bien en français :p), cela relève plutôt du droit des marques que du droit d'auteur, autant ne pas le mettre dans la licence : c'est ce qu'a fait la fondation mozilla pour firefox par exemple et en protégeant activement sa marque : d'où les noms de paquets mozilla-firefox et non firefox tout court :/ et (surtout) la non inclusion du logo officiel dans pas mal de distributions...
[^] # Re: mais euh
Posté par Benjamin Jean (site web personnel) . Évalué à 1.
Au terme de la GPL, pour moi, la solution est bien que, même si indépendant et séparé, mais faisant parti d'un tout final, la GPL s'applique.
AMHA, c'est encore plus clair dans le draft.
Je pense qu'il vaut mieux pour un tel Soft de donner l'url de tikiwiki à l'utilisateur, qui se sert lui même. Ou alors, s'arranger pour le distribuer, mais pas de telle façon qu'il puisse être vu comme le composant d'un logiciel plus grand...
Pour la clause PHP, je pense que ce qui la motive, c'est les frais de dépôt de marque à l'echelle planétaire. Un pays pour un produit, c'est cher, mais si tu multiplie...
[^] # Re: mais euh
Posté par Gniarf . Évalué à 1.
Les codes de l'une de peuvent ni être repris, ni combiner avec ceux de l'autre, c'est tout de même dommage, non ?
renseigne toi mieux, beaucoup mieux.
les gens de l'église BSD n'ont pas reécrit gcc ni la plupart des outils GPL qui existaient.
les adeptes de la secte GNU n'ont pas reécrit Apache et compagnie (ce n'est pas comme si ils n'y ont pas pensé, hein). bon, ça a engendré des pantomimes et des pignolades sans fin pour finalement décider que oui, finalement les licences BSD et quelques autres sont effectivement plus ou moins acceptables, avaient le droit de vivre...
en fait, seuls quelques rares bidules ont effectivement été écrits "deux fois" pour des histoires de licences.
à ce niveau, il faut prendre un petit peu de recul et constater qu'il y a eu par exemple bien plus de cas de duplication d'efforts pour des éditeurs de texte (pico/nano, joe, les 3 versions de vi...) ou quand un fork survit finalement assez longtemps (GNU Emacs vs XEmacs).
je ne parlerai même pas des distributions Linux, on en a bien 200 en circulation, alors que 4 ou 5 suffiraient certainement pour couvrir tous les usages possibles. c'est fou, non ?
vouloir "reprendre et combiner avec ceux de l'autre" est aussi incongru que vouloir mettre une chaussure gauche sur le pied droit, ça traduit une grave méconnaissance de cet écosystème. c'est presque touchant de naïvité, en fait, ça serait vouloir supprimer les dauphins et les baleines parce que la place des mammifères c'est Sur Terre, et les chauves-souris parce que il n'y a que les oiseaux qui ont le Droit de Voler.
oui, c'est sûr, ça serait plus propre et mieux rangé comme ça. on pourrait même croire que c'est potentiellement plus efficace et plus performant avec moins de bouts inutiles.
mais bon si tu fais un parallèle avec euh Abraham dans le rôle du Libre, et les juifs et les arabes pour les deux licences dont on cause ici, tu comprendras peut-être leur dualité et que tu auras du mal à les réconcilier après toutes ces années...
[^] # Re: mais euh
Posté par Benjamin Jean (site web personnel) . Évalué à 1.
Le message aurait été plus court, je n'aurai pas répondu, mais là, je me dis qu'il le mérite. Même si sur le fond, je ne le trouve pas très utile.
C'est drôle, on a l'impression que tu t'emportes et que tu t'énerves. J'espère que ce n'est pas le cas.
Ce que tu dis est vrai. Forcement, tu me dis ce qui s’est passé. Je suis donc d'accord.
Maintenant, dire : 1) ça c'est passé, donc ça marche ; 2) ça marche, donc il ne faut pas changer. Je trouve que c'est limité comme raisonnement.
Tu parles de *BSD* et de la *GNU GPL*, je crois que le cas est différent de *Apache* et de cette même *GNU GPL*. Dans le second cas, il ne peut y avoir aucun échange, dans les deux sens.
Tu vas sûrement me répondre que ça marche très bien ainsi, je te répondrai que, heureusement, d'autre pense différemment et tente de pondre une nouvelle version de la GPL qui permettra de faire le lien (il y a eu des pressions chez Apache aussi, mais sans concession).
Si pour toi, parler d'un problème qui existe (et je suis sûr que tu en connais d'autres), c'est MAL. Et bien heureusement que tout le monde n'est pas comme toi.
Cordialement,
BEn
[^] # Re: mais euh
Posté par Gniarf . Évalué à 1.
ça tombe bien, je n'ai pas dit ça. note au passage que la stabilité est une valeur souvent appreciée en informatique, et pas seulement au niveau d'un système ou d'une application en train de tourner. Debian parle aussi de "stable", par exemple
Tu parles de *BSD* et de la *GNU GPL*, je crois que le cas est différent de *Apache* et de cette même *GNU GPL*. Dans le second cas, il ne peut y avoir aucun échange, dans les deux sens.
de quels échanges tu veux parler ? le reste de tes réponses me laisse à penser que tu te veux te contenter d'un point de vue théologique ou juridique sans savoir de quoi il en retourne. est-ce que tu conçois concrètement ce que seraient ces "échanges" ? en terme de code ou d'API, de rapport entre les gens, les projets ?
quand je relis cette ligne "Toutes ces appli fonctionnent ensemble (même espace d'adressage, lien dynamique, etc) ?" par exemple, je m'inquiète.
le reste de ton message ne mérite pas de commentaire, mis à part qu'il ne sent vraiment pas très bon.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.