Les licenses autorisées sont choisies pour permettre l'intégration dans les sources fermées, les sources ouvertes mais aussi les applications commerciales. La seule limitation est que les crédits doivent rester dans les sources. Pour la LGPL, la license nécessite en plus que toutes les modifications au code source doivent être mises aussi sous LGPL.

De plus en plus, des personnes se plaignent de l'utilisation de paquets PEAR sous la license PHP dans du code GPL. Dans une discussion sur ce sujet, le créateur de PHP, Rasmus Lerdorf, a exprimé le sentiment suivant :

Tout dépend de ce que signifie le liage. La license PHP est très proche de la license Apache et ainsi, vous ne pouvez lier de la même façon du code GPL à Apache...
Voir http://www.apache.org/licenses/LICENSE-1.1.
La license PHP a été choisie pour correspondre à la license Apache car Apache et PHP sont trop fermés l'un l'autre.
L'arrachage de cheveux sur le liage et ces dérivations est présent depuis le début. Ma position est que vous pouvez fournir des composants PEAR sous license PHP sur le même CD ou dans le même fichier compressé que du code GPL car je le vois comme du travail d'agrégat. Ceci change si vous prenez du code PEAR, que vous le modifiez et que vous le copiez/collez directement dans votre propre code. Alors, ce travail passe d'un travail d'agrégat vers un travail dérivé. Mais le but des composants PEAR est d'être utilisés sous une forme d'agrégat. La license PHP vous autorise de l'utiliser aussi sous une forme dérivée mais alors, vous devez choisir une autre license que GPL pour ce travail.
La FSF a une FAQ sur l'agrégation ici : http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation
Ce texte traite de la compilation de logiciel, des exécutables et des espaces mémoires qui ne peuvent pas vraiment s'appliquer ici. Si vous ne désirez pas utiliser un composant PEAR comme agrégation, alors il est logique que vous ne pouvez pas non plus faire des appels à Apache dans votre code, donc, vous devez stipuler que personne ne peut utiliser votre code avec Apache. Je pense que c'est une extrème interprétation que quasi-personne ne partage ici...
En résumé, je ne vois pas d'issue ici. À suivre...

Notez que pour les extensions PECL qui sont liées à PHP, la licence utilisée doit être compatible avec la licence PHP. Cela signifie que vous ne pouvez pas rendre une extension PECL GPL sans violer la GPL. Notez aussi que si vous développez une extension qui lie une libraire GPL, vous violerez la GPL. Si vous devez utiliser une librairie GPL, demandez à son auteur l'autorisation d'utiliser sa bibliothèque sous une license compatible.

La license de tous les paquets PEAR/PECL peut être trouvée en haut de chaques fichiers du code source, sous la balise <license> du fichier de description du paquet (package.xml) mais aussi sur la page d'acceuil du paquet.

Pourquoi le standard de codage PEAR insiste sur l'indentation sur un seul espace ?

Utiliser des espaces et éviter les tabulations est la seule façon de s'assurer que les parties de codes seront affichées de la même manière sur tous les éditeurs ou visionneuses. De nombreux éditeurs associent la tabulation à 4 espaces mais d'autres terminaux ou visionneuses les associent à 8 espaces. Exemple:

printf("%s",
$arg);

Ici, il y a 7 espaces avant "$args". Si ce code a été écrit dans un éditeur pour qui une tabulation représente 4 espaces, il sera stocké en tant qu'une tabulation et 3 espaces. Maintenant, si un autre développeur édite le même fichier dans un éditeur pour qui une tabulation représente 8 espaces, il ressemblera à cela :

printf("%s",
$arg);

De même, considérer ce code écrit avec une tabulation représentant 8 espaces :

    if ($foo &&
        $bar) {
    }

Si vous le visualisez dans un éditeur pour qui une tabulation représente 4 espaces, il ressemblera à ceci :

    if ($foo &&
    $bar) {
    }

La communauté PEAR étant composée de très nombreuses personnes utilisant une multitude de systèmes et éditeurs, l'utilisation des tabulations n'est tout bonnement pas adaptée. L'utilisation des espaces est quant à elle plus universelle.

Jamie Zawinski a également écrit un article à ce sujet..

Il existe également un outil nommé Astyle qui convertit votre code au bon format.

FAQ (Previous)

(Next) FAQ Documentation/traduction

Download Documentation	Last updated: Sun, 29 Jun 2008
Do you think that something on this page is wrong? Please file a bug report or add a note.
User Notes:
There are no user contributed notes for this page.