Journal Ce qui rend la licence Apache incompatible avec la GNU GPL

Posté par  (site web personnel) .
Étiquettes : aucune
0
8
juil.
2006
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...
  • # mais euh

    Posté par  . Évalué à 6.

    quel est le problème ?
    • [^] # Re: mais euh

      Posté par  . Évalué à 6.

      Les mots en gras qui gênent la lecture ?
      • [^] # Re: mais euh

        Posté par  (site web personnel) . Évalué à 3.

        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 ?

        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  (site web personnel) . Évalué à 5.

          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...

          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  (site web personnel) . Évalué à 2.

            Et sinon, pire que l'incompatibilité entre Apache et GPL, il y a l'incompatibilité GPL dans BSD...


            C'est vrai, mais au moins, les développements BSD peuvent être repris sur GPL, ce n’est pas le cas avec Apache...

            cela dit, les incompatibilités de licences empêchent de reprendre du code, pas de distribuer différents programmes qui s'utilisent conjointement.


            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  (site web personnel) . Évalué à 3.

          dans le cas de apache, ça vaudrait le coup de prendre un exemple concret tout de même...
          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  (site web personnel) . Évalué à 0.

            Toutes ces appli fonctionnent ensemble (même espace d'adressage, lien dynamique, etc. ?)
            • [^] # Re: mais euh

              Posté par  (site web personnel) . Évalué à 4.

              oula...
              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  . Évalué à 2.

                et pour la forme, on a négligé :

                * 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  (site web personnel) . Évalué à 2.

                  Disons que la plupart du temps, ce qu'on me donne, c'est plusieurs logiciels, distinct ou non — ça reste souvent à vérifier, mais pas juste des composants qui peuvent revêtir plusieurs licences suivant la version que l'on utilise...

                  - 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)
                  GNU GPL

                  apache
                  On va considérer la licence 2 puisque c'est celle qui nous intéresse (incompatible GPL)

                  mod_php exécute index.php
                  Je fais simple, disons PHP license dans sa dernière version (3.01) (incompatible GPL)

                  MySQL ou PostgreSQL pour la base

                  MySQL : GPL ac exception FLOSS (donc copyleft faible vis-à-vis de toutes les autres licences présentes)
                  PostgreSQL : BSD

                  pear / ADOdb / smarty

                  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.

                  installation indépendante des modules : je suppose que la licence de chacun est ainsi respectée

                  Toutes les licences sont respectées puisque logiciels indépendants et séparés, et non distribués comme un tout

                  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)

                  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.


                  * 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.

                  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  (site web personnel) . Évalué à 3.

                    je ne vois pas précisément en quoi la distribution en un seul tar.gz est gênante (si un peu quand même, vu que j'ai choisi ce cas, mais c'est à des fins de précision).

                    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  (site web personnel) . Évalué à 1.

                      These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.


                      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.

                      These requirements apply to the modified work as a whole. If identifiable sections of that work, added by you, are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works for use not in combination with the Program. But when you distribute the same sections for use in combination with covered works, no matter in what form such combination occurs, the whole of the combination must be licensed under this License, whose permissions for other licensees extend to the entire whole, and thus to every part of the whole. Your sections may carry other terms as part of this combination in limited ways, described in section 7.


                      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  . Évalué à 1.

          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 ?


          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  (site web personnel) . Évalué à 1.

            Bonjour,

            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  . Évalué à 1.

              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.

              ç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.