Deux reproches sont fait à la GPL: on impose nos idées aux autres; la gestion de la GPL-compatibilité est lourdingue. En ce qui concerne la LGPL, Liberated GPL (sic), ses termes leurs paraissent flous. Mais le tableau qu'ils brossent n'est pas tout noir. Les licences copyleft ont un rôle important de catalyseur à jouer, disent-ils. Ils proposent qu'on ne considère pas le copyleft comme un choix par défaut mais qu'on l'intègre dans la stratégie de développement d'un projet. Les conclusions de l'article, sous forme de conseils sont traduites ci dessous:
- Utilisez une licence couvrant les plus petites conditions de copyleft qui conviennent à votre projet. Par exemple et par ordre croissant, nous utilisons :
* des licences sans conditions,
* la MPL avec des conditions sur les fichiers,
* la LGPL avec des conditions sur les bibliothèques,
* et la GPL avec des conditions sur les exécutables. - Si le copyleft est nécessaire, placez le uniquement sur la partie spécifique de votre code. Par exemple, si le code d'une table de hachage ou d'un socket wrapper ne sont pas spécifiques à votre application, il pourra être réutilisé dans d'autres projets. Donc il devrait avoir moins de copyleft que ce qui fait la spécificité de votre application afin d'éviter d'imposer des conditions copyleft sur des projets où il sera réutilisé. Si vous envisagez de mettre le code sous plusieurs licences, notez que le code sous GPL ne pourra être combiné qu'avec du code sous une licence compatible avec celle ci.