« Option Libre » : compatibilité entre contrats

Mémoire effectué dans le cadre du
Master II Recherche — Droit des Créations Immatérielles
sous la direction du Professeur Michel Vivant 
année 2005 — 2006

Par Benjamin Jean

Ce mémoire fut celui soutenu le 31 août 2006 à Montpellier, auquel certaines modifications — principalement de forme — furent apportées ;
Celui-ci, s'il fut le fruit d'une implication importante, ne prétend néanmoins pas à l'exhaustivité. Encore moins à la perfection... Ainsi, tout commentaire sera bienvenu et pourra être pris en compte dans une version ultérieure ;
Par ailleurs, à la recherche d'un partenaire professionnel pour pouvoir réaliser une thèse sous convention cifre, je reste ouvert à toute piste ou proposition ;
Pour tout ceci, vous pouvez à tout moment me contacter à optionlibre@venividilibri.org.

Remerciements sincères :

•	Au Professeur Michel Vivant, qui a permis à cette aventure de se concrétiser, et, de façon plus générale, a fourni en cette année les outils nécessaires à la construction du futur ;
•	à Maître Gilles Vercken, pour m'avoir permis de me plonger dans des conflits de licences bien réels, situation idéale pour commencer une telle étude ;
•	à Maître Florence Gaullier, pour l'accueil qui me fut réservé et le temps accordé ;
•	à l'équipe de l'Ercim et du Master de Recherche, pour m'avoir accompagné durant cette année, et pour le temps passé à m'écouter parler de libre et d'open source ;
•	à l'équipe du Service Partenariat et Valorisation du CNRS de Montpellier, grâce à qui j'ai pu me plonger dans les subtilités contractuelles des licences libres et open source ;
•	à l'équipe Veni, Vidi, Libri avec qui je travaille actuellement dans l'objectif de diffuser les licences libres auprès des développeurs ;
•	à Richard Stallman ainsi qu'à tous les acteurs du libre pour avoir répondu à mes questions nombreuses, et m'avoir aidé dans cette entreprise ;
•	à tous les musiciens qui m'insufflèrent de nouvelles forces quand j'en eus besoin...

Sommaire
Introduction	5
Appréhension juridique du contrat de licence FLOS	8
Les différentes licences FLOS	11
Les conflits au sein des licences FLOS	14
Partie I - Une compatibilité classique lors de la coexistence des contrats	17
Chapitre I - La notion de distribution comme point de départ à l'effet des contrats	17
La notion de distribution comme envisagée par les licences FLOS	18
Les effets contraignants des licences FLOS déclenchés par la distribution	23
Chapitre II - La notion d'« œuvre dérivée » comme dernière limite à l'effet des contrats	28
La notion d'« œuvre dérivée » comme envisagée par les licences FLOS	29
Les confrontations entre licences lors de la création d'une « œuvre dérivée »	33
Partie II - Une compatibilité spéciale lors du cumul des contrats	42
Chapitre I - La technique logique pour déterminer la compatibilité d'une licence	42
Une licence compatible accordant au moins autant de droits que la licence absorbante	43
Une licence compatible n'imposant pas plus d'obligations que la licence absorbante	47
Chapitre II - Les techniques contractuelles pour ajuster la compatibilité d'une licence	50
Les techniques actuellement utilisées pour résoudre les conflits entre licences	51
Quelques pistes de réflexion sur les incompatibilités entre licences	58
Table des matières	64
Bibliographie	66
Annexes	72
Licences de contenu	98

Introduction

« Mais à travers eux s'avança à larges enjambées, avec des rugissements de bêtes, une grande compagnie de trolls des montagnes de Gorgoroth. Plus grands et plus larges que les Hommes, ils n'étaient vêtus que d'un réseau très ajusté d'écailles cornées, ou peut-être était-ce leur hideux cuir, mais ils portaient d'énormes boucliers ronds et noirs, et ils brandissaient de lourds marteaux dans leurs mains noueuses. » (J.R.R. Tolkien, Le Seigneur des Anneaux, livre V) .

        1 –	 Le juriste : un Troll ? La description, l'illustration bien en tête, et n'en déplaise aux juristes et à leur ego, voici l'image qui est la nôtre au sein de la communauté libre et open source. Sur Internet, le terme de Troll désigne un individu qui persiste à lancer des discussions sur des sujets qui fâchent, voire ses messages eux-mêmes. En raison du double visage revêtu par la communauté du libre, tout à la foi système et idéologie, celui qui pointe du doigt une de ses faiblesses déclenche invariablement pléthore de réactions défensives. Ainsi, si la liberté d'expression est proclamée sur le réseau des réseaux, elle a certaines limites qui ne doivent pas être dépassées ; cherchant à déclencher des polémiques improductives et maintes fois ressassées, le Troll est donc « hors-la-. Sans mauvais jeux de mots, il est dès lors très fréquent pour un juriste d'être « hors-la-Netiquette »... Ne serait-ce que pour ne pas être « hors-la-loi ». Voici une présentation, certes peu élogieuse, de l'accueil qui peut nous être fait ; la précision est utile en ce qu'elle permet de comprendre, et d'anticiper les réactions que nous sommes amenés à rencontrer.
        2 –	Le juriste : un contributeur ? Tout problème a son spécialiste, pourquoi empêcher un juriste de réfléchir sur des questions de licences lorsqu'il s'agit d'un domaine qui est le sien, et que ses interrogations soulèvent de difficultés lourdes de conséquences — causes d'insomnie pour certains, et d'indifférence pour d'autres ? Le rôle du juriste ne remplace en aucun cas celui des acteurs déjà existants et se cumule au contraire parfaitement ; les licences libres et open source relient ainsi de nombreux spécialistes autour d'un défi les concernant tous, a fortiori les développeurs et les praticiens du droit. Elles imaginent un système de développement et de propriété complètement différent de celui connu jusqu'ici. Enfin, faisant de l'exception une généralité, elles utilisent avec perfection les anciens comme les nouveaux rouages contractuels afin de créer des toiles de licences triviales, mais complexes à analyser... S'il fallait encore se justifier, dirions-nous que si nos questions se focalisent fréquemment sur des points sensibles et polémiques de la communauté — ou de son mode de fonctionnement —, ce n'est qu'un moyen de rattraper un train déjà lancé. La tâche revient finalement au juriste lui-même de convaincre de son rôle à jouer, une attitude positive que malheureusement beaucoup semblent négliger...
        3 –	Le Droit et le Libre. Une fois cette attitude dénoncée, il est juste d'admettre que cette étude n'a pu se réaliser qu'en raison de l'écho favorable qu'elle suscita auprès de certains acteurs du libre, de leurs conseils, renseignements et articles. Elle cherche donc à clarifier des situations parfois hautement complexes où de multiples licences — libres ou non —, en enveloppant une même œuvre, aboutissent à créer des situations inextricables, où droits et obligations se cumulent, s'annulent, s'ajoutent ou s'opposent. Souvent, à ce stade un professionnel est appelé, tenu alors d'effectuer un véritable travail d'orfèvre pour tirer les bonnes conclusions : à savoir, le plus souvent, une impossibilité de créer du libre par du libre. Selon nous, cette faute peut être imputée aux communautés libres et open source, non pas car ne trouvent pas de solutions, mais parce qu'elles ne les cherchent pas. De telles questions sont pourtant à leur charge : l'intérêt de la communauté libre et open source dans son ensemble doit passer avant celui de chaque communauté qui la compose. Les développements auxquels nous nous sommes adonnés tentent de répondre, de la façon la plus exhaustive possible, aux questions qui se posent lors de la recherche d'une compatibilité entre diverses licences.
        4 –	Une « option libre ». S'il apparaît évident que l'auteur d'une oeuvre ait la faculté de choisir la distribution ou l'exploitation qu'il désire en faire, la dénomination employée — « option libre » — revêt une signification qu'il convient de souligner : de simple excentricité, le mode de développement coopératif apparaît aujourd'hui comme une solution crédible, apte à séduire autant les particuliers que les professionnels. Le nombre de licences ne cessant de s'accroître, l'utilisation d'une notion commune — FLOS — permet de les rassembler par leurs caractères communs. Cet acronyme s'inspire évidemment de son homologue FLOSS, signifiant Free Libre Open Source Software, qui a le mérite de reprendre l'ensemble des désignations sans en privilégier aucune, tout en les désignant chacune. Ainsi, ne s'appuyant sur des cas concrets que lorsque nécessaire, nous privilégions une perception globale qui constitue à notre sens la meilleure base pour un travail en profondeur.
        5 –	La notion d'œuvre. Par ailleurs, la dénomination de l'objet desdites licences FLOS sera systématiquement celle d'œuvre, préférée aux notions plus vagues d'ouvrage, de document, contenu, etc.. Seul le droit d'auteur sur une œuvre permet d'utiliser le mécanisme des licences FLOS pour la diffuser, inutile donc de songer à d'autres appellations. En effet, la spécificité du droit d'auteur tient en ce qu'un contrat est nécessaire pour permettre certains usages, alors qu'en l'absence de droit d'auteur ce contrat serait nécessaire pour restreindre certains usages. Corollairement, la première hypothèse permettra de diffuser largement avant même de décider de céder certains droits, tandis que la seconde imposera de s'engager contractuellement avant de diffuser — avec une politique de secret à l'égard des non-contractants (puisque tiers non liés par le contrat). Pour finir, nous ne nous intéressons qu'aux situations où le donneur de licence possède l'intégralité des droits, tous conflits mettant en opposition auteurs et titulaires de droits voisins ne sont pas abordés et sont soumis aux mêmes prédicats qu'en matière de multiplicité d'auteurs : une licence ne peut valablement assortir une œuvre qu'autant que le donneur de licence détienne tous les droits.
        6 –	Compatibilité ou incompatibilité ? La notion d'incompatibilité dont nous parlerons tout au long de cette étude doit bien sûr être définie. Les licences FLOS permettent expressément aux licenciés la création de nouvelles œuvres dérivées en leurs conférant les droits ad hoc, c'est même leur l'objectif premier que de multiplier les œuvres ainsi disponibles pour en permettre la création de nouvelles. Cette politique du « pot commun » fut néanmoins malmenée par la multiplication des licences FLOS : en conditionnant — légitimement — leurs droits à quelques obligations à la charge du licencié, celui-ci se trouve fréquemment dans la situation délicate de ne pas pouvoir respecter l'ensemble des obligations contradictoires auxquelles il est soumis, abandonnant ainsi tout projet de création. L'incompatibilité se retrouve ainsi dès que deux licences assujettissent conjointement un même licencié de telle façon qu'il ne puisse pas les exécuter toutes deux simultanément. L'étude aurait ainsi pu s'arrêter à débusquer les incompatibilités et donner les clés pour les éviter. Notre ambition est plus large, en envisageant la compatibilité nous pointons la spécificité majeure des licences FLOS : leur susceptibilité à être compatibles entre elles, et ceci dans une mesure inédite.
	Avant de rentrer dans le vif du sujet et sans pour autant perdre notre temps dans « du réchauffé », certains éclaircissements apparaissent nécessaires pour la suite. Après avoir délimité juridiquement le contrat de licence FLOS (Section I), nous préciserons les spécificités des différentes licences FLOS (Section II) afin de mieux comprendre les conflits qui existent au sein des communautés FLOS (Section III).
Section I - 	Appréhension juridique du contrat de licence FLOS
        7 –	Les licences FLOS sont des contrats de droits d'auteur. Même si certains auteurs américains contestent la qualification de contrat aux licences FLOS, cette question suscite peu d'intérêt dans notre système juridique où une telle distinction n'existe pas. Dans le domaine du droit, lors de l'apparition d'un nouvel outil — d'un nouveau contrat —, les juristes cherchent systématiquement à le qualifier et le classifier, afin de lui appliquer un ensemble de dispositions déjà adaptées. L'exemple des licences de logiciels libres est édifiant : on a pu parler de ventes, de louages d'ouvrage, de louages de choses incorporelles, de prêts à usage, commodat, voire de contrat sui generis. De fait, la jurisprudence a qualifié le contrat de licence de logiciel de vente.
        8 –	Une qualification trop rapide. Cette qualification est loin d'être neutre puisqu'elle influe sur la validité de certaines clauses. Toutes ces réflexions ont envisagé le logiciel comme un bien matériel quelconque, ceci alors même qu'en tant que création originale, nous sommes en présence d'une création immatérielle, une création saisie par le droit d'auteur !
	Le préambule de la GNU GPL le stipule lui même, il y a une cession de droit — que nous qualifierons assez facilement de licence non exclusive de droit d'auteur (B) —, mais qu'il faut distinguer du contrat que l'on appellera de « mise à disposition du logiciel » (A).
I - 	Un contrat de mise à disposition distinct du contrat de licence 
        9 –	La double nature des œuvres utilitaires. Le logiciel a la spécificité de présenter une double nature en ce qu'il est une œuvre, mais aussi un outil. Les juristes qui l'appréhendent tendent à négliger cette distinction alors que la propriété matérielle est ici aussi importante que celle immatérielle. En effet, il est parfaitement possible d'avoir la jouissance matérielle d'une création sans avoir de droits — au sens de la propriété intellectuelle — sur celle-ci, et disposer réciproquement de droits sur une oeuvre que l'on ne possède pas matériellement. Par comparaison, on s'aperçoit que dans le fonctionnement des licences propriétaires, le contrat de licence est très souvent inclus dans celui de mise à disposition, alors que les licences FLOS les distinguent expressément. Dans le mécanisme des licences FLOS, le contrat conférant les droits sur une œuvre est attaché à son support tandis qu'un autre contrat est nécessaire à sa mise à disposition. Ainsi, si la pratique nous a habitués à n'en voir qu'un seul, la rigueur impose cette dichotomie lors de la qualification juridique de ces deux contrats, portant chacun sur un objet différent : le logiciel en tant que création (sur la forme) et le logiciel en tant qu'outil (par la fonction exécutée).
        10 –	Le contrat de mise à disposition. L'une des caractéristiques des licences FLOS est de permettre expressément tout type de contrat de mise à disposition puisque l'une des libertés offertes à l'utilisateur est le droit de distribuer comme il l'entend, commercialement ou non. Ainsi, contrairement à une confusion fréquente due à la traduction du terme free, la distribution n'est pas nécessairement gratuite. Somme toute, beaucoup d'entreprises ont choisi de «vendre du libre», faisant le pari de rendre leur produit intéressant à acquérir pour sa valeur ajoutée, ou de fournir des services annexes sur celui-ci. De fait, la plupart des critiques formulées à l'encontre des licences FLOS  ne trouvent plus à s'appliquer en l'absence de vente.
II - 	Une licence FLOS, un contrat de cession non exclusive de droit d'auteur 	
        11 –	Une simple utilisation de ses prérogatives par l'auteur. Dans une licence FLOS, l'auteur ne fait qu'user de ses prérogatives patrimoniales en se déclarant titulaire de droit, afin de les céder très largement par la suite au profit du possesseur du support de l'œuvre sur laquelle porte la licence. Pour cette mise à disposition, il peut aussi choisir de conditionner ses droits à certaines obligations ; c'est dans cet équilibre, entre droits et obligations, que les licences FLOS diffèrent principalement. En matière de logiciels notamment, la « philosophie libre » qui imprègne leurs licences FLOS tend à ce que le recours aux simples notions classiques de droit d'auteur ne suffit plus à encadrer la volonté exacte des parties : les droits d'utilisation, d'exploitation, de modification et de distribution devant être mis en relation avec ceux plus traditionnels de reproduction et représentation ainsi que le stipule l'article L122-6 du CPI.
        12 –	Les questions soulevées par l'extension des licences aux œuvres dérivées. Les contraintes qui enserrent les œuvres dérivées soulèvent différentes questions relatives à leur étendue. Certaines licences, dites copyleft, contraignent le licencié qui a fait acte créatif en modifiant l'œuvre originale, à diffuser l'œuvre dérivée sous une licence identique. Il est tentant de voir ici une atteinte à ses droits d'auteurs (notamment son droit de divulgation), mais la réalité est plus simple : le licencié peut, soit respecter la licence et donc diffuser son œuvre ainsi qu'il lui est demandé, soit perdre sa qualité de licencié et renoncer à distribuer l'œuvre dérivée sans l'accord exprès de l'auteur de l'œuvre originaire. Finalement, rien de si injuste dans cette obligation de réciprocité qui n'est qu'une condition à l'autorisation indispensable de l'auteur — voire même une mise en œuvre de celle-ci —, sans laquelle l'œuvre dérivée ne peut être distribuée. Choix réalisé de surcroît in fine, lors de la distribution, l'auteur est donc libre puisque les seuls droits conditionnés sont ceux d'autrui, et non les siens.
        13 –	Un mécanisme de licences croisées. Dans la majorité des licences, chaque auteur conserve ses droits sur ses créations originales, et les cède systématiquement aux autres licenciés en rendant disponible la nouvelle œuvre dérivée assortie d'une licence FLOS. Donc, même l'auteur initial n'est que très rarement titulaire de l'ensemble des droits sur l'œuvre sous licence FLOS, et s'il veut exploiter son œuvre d'une autre façon, il ne pourra le faire qu'à concurrence de sa création initiale et de ses apports propres. Ensuite, soit le contrat de licence autorise le sous licenciement, et dans ce cas le licencié dispose des droits qui lui ont été cédés plus ses propres droits patrimoniaux sur l'œuvre ; soit le sous licenciement est interdit, et le licencié cède en son nom ses propres droits, et agit au nom de chaque autre auteur ou grâce à la stipulation pour autrui. Pour résumer, on se trouve ici dans une situation contractuelle qui permet peu ou prou de rendre la création quasiment autonome, appartenant à tous, voire à personne.
        14 –	L'existence d'analyse légale. L'analyse légale des licences FLOS a pu faire l'objet de nombreuses études exhaustives. Si elle peut comporter des questions extrêmement intéressantes, nous nous pencherons principalement sur celles contractuelles et renvoyons donc le lecteur à notre bibliographie pour satisfaire sa curiosité en la matière.
Section II - 	Les différentes licences FLOS
        15 –	Des appellations différentes. Les différentes appellations recouvertes par la notion de licence FLOS nous laissent deviner qu'il existe, derrière ce regroupement sémantique, des spécificités relatives à chaque catégorie. Adopter deux angles de vue différents permet de mieux envisager les licences FLOS : l'appréhension classique (2) permettant d'envisager leur étendue est complétée par celle historique (1) permettant de mieux les interpréter.
I - 	L'approche historique de la notion de licence FLOS
        16 –	Les licences GNU. Précurseur en la matière, Richard Matthew Stallman est le fondateur du mouvement pour le logiciel libre. Chercheur au MIT, il démissionne pour se consacrer exclusivement au développement d'une alternative logicielle viable face aux systèmes propriétaires se développant. Fondant la Free Software Foundation en 1984, et concevant lui-même les premiers outils GNU, il utilise pour son logiciel Emacs la première licence libre de type copyleft : la GNU Emacs General Public License. Ce n'est qu'en 1989, après avoir réitéré les licences de ce type sur le GNU Debugger (GDB) et la GNU Compiler Collection (GCC), que la première mouture de la GNU General Public License (GNU GPL) apparaît, modifiée par la suite en 1991, et actuellement sujette à un projet de nouvelle version. Très vite, une licence plus permissive devient nécessaire pour faciliter l'usage de certains programmes : la GNU Library General Public License (GNU LGPL) voit le jour en 1991. Une troisième licence, la GNU Free Documentation License (GNU FDL ou GFDL), rejoint finalement la famille pour permettre un licenciement des documentations de programmes plus adapté que celui des licences GNU GPL ou LGPL. En général, le langage de ces licences est très proche de celui des développeurs, est empreint d'une intention forte et d'une portée parfois complexe à définir. Elles s'opposent à toute réappropriation du code grâce à leur clause copyleft qui impose que tout logiciel dérivé — basé sur, ou constituant un tout avec le logiciel sous licence GNU GPL — soit lui-même soumis à cette même licence. Les grandes sociétés intéressées par l'alternative FLOS sont en général hésitantes à recourir à l'utilisation de ces licences aux implications extensives parfois incertaines.
        17 –	Les licences académiques. Elles sont en large partie à l'origine du développement de l'infrastructure d'Internet. Pour exemple, le système de nom de domaine BIND, le protocole TCP-IP et Sendmail sont tous des standards de facto, issus de ces licences permissives. On y retrouve l'idée d'un partage des connaissances « sans condition » par les universités américaines. Les licences académiques sont courtes — souvent trop — et claires. Elles consistent le plus souvent en l'énumération de la totalité des droits conférés, une obligation de respecter la paternité de l'oeuvre, et une exclusion de responsabilité et de garantie. Un des exemples les plus fréquents est celui de la licence BSD, pour Berkeley Software Distribution.
        18 –	Les licences communautaires. Elles sont principalement issues de projets FLOS qui, devenus populaires, choisissent de rédiger leur propre licence. Très spécifiques puisqu'intimement liées à un projet et son vécu, elles sont parfois susceptibles d'une interprétation assez floue. Les deux principales sont la licence Artistic et la licence Apache. Elles sont essentiellement des licences permissives, mais que leurs spécificités rendent difficiles — voire impossibles — à concilier avec la plupart des licences copyleft.
        19 –	Les licences institutionnelles. Introduites par des sociétés intéressées par le développement coopératif de leur produit, les premières licences de ce style furent la Netscape Public License (NPL) et la Mozilla Public License (MPL), rédigées par la firme Netscape pour la libération du code de son navigateur. Ces licences sont précises, ont une étendue souvent très circoncise, et sont fortement rattachées au mouvement open source. Pour faire simple, en terme contractuel, ce sont sûrement les licences les mieux rédigées.
        20 –	Les licences de culture libre. Ce sont des licences diverses qui s'appliquent à transposer à d'autres formes d'œuvres le mécanisme des licences FLOS, un exemple remarquable est celui de la licence française Art Libre. L'apparition de nouvelles licences opère actuellement une scission au sein de ce mouvement, entre ceux fidèles aux préceptes FLOS, et ceux désirant s'émanciper — comme les licences Creative Commons ou la licence IANG.
II - 	L'approche classique des licences FLOS
        21 –	Les licences permissives. Les licences de type permissif sont principalement les licences académiques et communautaires, elles confèrent un maximum de droits au licencié et ne lui imposent que peu d'obligations. Celles-ci se limitent au code source originaire, et non aux modifications qui peuvent lui être faites, coexistant ainsi sans anicroche entre elles. La redistribution du code n'est pas soumise à une licence spécifique, et le licencié peut ainsi valablement cacher ses modifications s'il décide d'accorder moins de droits. Le statut de ces œuvres est souvent proche de celui du domaine public puisqu'elles n'imposent parfois que le respect de la paternité et une clause d'exclusion, ou limitation, de garanties et de responsabilité.
        22 –	Les licences copyleft. Elles interdisent toute reprise propriétaire du code, et pour ceci contraignent le licencié à utiliser la même licence lorsqu'il redistribue l'œuvre, modifiée ou non. Ceci grâce à une clause que nous appellerons indifféremment de réciprocité ou de copyleft, se divisant elle-même en deux branches : copyleft fort et copyleft standard. Le copyleft standard s'applique à la redistribution de l'œuvre et de ses modifications, tandis que le copyleft fort s'étend aussi à la combinaison d'œuvres. Comme précisé, cette clause n'est pas d'application automatique et le licencié peut parfaitement décider de ne pas distribuer l'œuvre s'il ne désire pas être tenu par la licence, disposant donc d'un choix qu'une licence propriétaire ne lui donnerait pas.
		
Tableau 1: Représentation des différentes licences (A'B'C'D' composants du programme d'origine, Y'X' d'un autre)
Section III - 	Les conflits au sein des licences FLOS
	Les conflits que génère la rencontre de plusieurs licences non compatibles trouvent en partie leur source dans l'absence de cohésion globale (I), celle-ci nuisant au développement de la communauté FLOS (II).
I - 	Une absence de cohésion globale
        23 –	Des communautés aux moyens similaires, mais aux objectifs différents. Cette affirmation peut sembler osée tant il est difficile en parlant de communauté libre de ne pas penser à RMS ou à Linus Torvalds. D'autres personnalités revêtent aussi cette image emblématique, tels Eben Moglen, Eric S. Raymond ou Bruce Perens, mais finalement aucune ne semble emporter l'unanimité au sein de la communauté. De nombreuses visions différentes du libre et du développement coopératif en général, se rassemblent néanmoins auprès de ces quelques acteurs plus importants. La Fondation pour le Logiciel Libre (FSF) est la représentante incontestable du mouvement libre antipropriétaire, son but étant la diffusion du libre, envisagée comme une finalité pour laquelle un « emploi agressif » de ses licences est conseillé. L'association américaine SPI (Software in the Public Interest) et les projets qu'elle soutient sont aussi des acteurs de poids dans le monde du libre. Ces organisations, si elles soutiennent ouvertement la GNU GPL, restent néanmoins indépendantes et définissent elles-mêmes leurs critères. Debian, par exemple, n'a pas hésité à s'opposer à l'utilisation de certaines licences qu'elle considère comme non libres, comme l'AGPL ou la GFDL, pourtant soutenues par la FSF. L'Open Source Initiative est née d'une scission avec la FSF, afin de labelliser les licences réunissant les critères de la « définition open source ». Ceux-ci étant centrés sur les méthodes de développement de logiciel à code ouvert où le service reprend le pas sur le produit lui-même. Pour simplifier, là où le choix d'un logiciel propriétaire est une solution sous optimale pour l'O.S.I., la FSF y voit une atteinte à la liberté des utilisateurs qui doit être combattue. Les deux définitions sont assez proches, et les logiciels conformes à l'une le sont quasi systématiquement à l'autre.
II - 	Un contexte néfaste au développement de la communauté FLOS
        24 –	Un sentiment d'anarchie lié au bazar. Les conflits fréquents au sein des communautés FLOS ne renvoient certainement pas une vision optimum de l'alternative qui s'élève face à un paradigme bien ancré dans nos sociétés. Pour mettre à mal le fonctionnement actuel du droit d'auteur, envisagé comme le monopole d'un individu opposable au reste de la société, la communauté FLOS ne peut pas se priver de présenter un modèle irréprochable, ou pour le moins cohérent. Le premier constat est que la protection à l'encontre du modèle propriétaire est parfois si forte qu'elle affaiblit même la communauté en cloisonnant ses forces ! 
	Sans aller jusqu'à transposer le modèle de la Cathédrale, un minimum de concertation et de stratégie commune est nécessaire pour que le développement FLOS puisse franchir cette nouvelle difficulté qui se présente, et cette foi-ci de l'intérieure. Le meilleur moyen semble bien de prendre en considération les incompatibilités qui se multiplient au fur et à mesure du développement du modèle FLOS, pour présenter in fine une communauté solide, soudée et efficiente : modèle beaucoup plus apte à convaincre et à convertir.

	Après la lecture de ces quelques pages, le lecteur doit dorénavant percevoir que si la compatibilité des licences FLOS les distingue des contrats de licence « classiques », des difficultés surgissent lorsque celle-ci est mal assurée vis-à-vis d'autres licences FLOS. L'analyse nécessaire, permettant de s'assurer de la compatibilité entre contrats, son fondement et ses enjeux, doit se réaliser méthodiquement. C'est la raison pour laquelle nous l'envisageons en deux temps : pour commencer, la compatibilité « classique » lors de la coexistence des contrats (Partie I), et une fois cette tâche menée à bien, la compatibilité spéciale lors du cumul des contrats sur une même œuvre (Partie II). 

Partie I - 	Une compatibilité classique lors de la coexistence des contrats
        25 –	Rechercher la coexistence pour « vivre ensemble ». La coexistence exprime littéralement l'« existence simultanée », le fait de « vivre côte à côte en se tolérant ». Notre objectif est dans cette partie de délimiter l'étendue de chaque licence afin d'apprécier les situations où la compatibilité est assurée par cette coexistence, lorsque deux licences portent sur des œuvres bien distinctes. Une licence n'étant qu'un contrat, son objet est immatériel et parfois complexe à appréhender : c'est pourquoi il faut retenir que si elles accordent des droits, les licences FLOS soumettent cette cession à certaines obligations. Ce sont ces dernières qui composent ce que nous nommerons l'« effet contraignant des licences », ne devenant effectives que lors de la distribution de l'œuvre licenciée (Chapitre I), et pouvant s'étendre jusqu'à la limite extrême du droit d'auteur, envisagée par les licences FLOS sous la notion d'œuvre dérivée (Chapitre II).
Chapitre I - 	La notion de distribution comme point de départ à l'effet des contrats
        26 –	Définition de la notion de distribution. La notion de distribution est une notion définie assez similairement par le traité OMPI ou la directive européenne, le droit français l'incluant pour sa part dans le droit de représentation et de destination de l'auteur. Dans le cadre des licences FLOS, ce droit est systématiquement conféré au licencié, en tant que l'une des quatre libertés assurées à l'utilisateur : que ce soit en sa qualité d'auteur sur ses droits propres, ou pour autrui s'agissant des droits restants, tout licencié est libre de distribuer l'œuvre comme il l'entend. Jusqu'à cette redistribution de l'œuvre, la licence restera « suspendue » dans ses effets contraignants, compatible de ce fait avec toute autre licence. Cette sphère de « jouissance absolue » varie suivant les licences envisagées, le droit de distribuer étant envisagé de façon autonome par les licences FLOS (Section I), dans des dimensions liées à l'enjeu que représente le déclenchement de cet effet contraignant (Section II).
Section I - 	La notion de distribution comme envisagée par les licences FLOS
        27 –	Le droit de redistribuer œuvre et licence, un droit comme un autre ? L'acte de distribution fait intervenir un tiers supplémentaire au sein de l'enchevêtrement de licences liées à l'œuvre. Alors que la quasi-totalité des droits concédés est exclusivement tournée vers le licencié — dans le but de lui redonner une liberté perdue au contact des licences propriétaires —, le droit de distribuer s'oriente à l'inverse en direction des autres utilisateurs. Si les libertés d'utiliser, d'étudier et de modifier sont importantes — et peu fréquentes dans le monde propriétaire —, la possibilité offerte au licencié de distribuer à nouveau l'œuvre et surtout les droits qui portent sur celle-ci confère aux licences FLOS leur spécificité. 
	Les licences FLOS furent rédigées de façon à préserver l'équilibre de multiples intérêts lors de la distribution (I), mais certains réussirent malheureusement à trouver dans cette notion une échappatoire à l'aspect contraignant des licences (II).
I - 	La préservation d'un double intérêt lors de la distribution
	Les licences FLOS ont une vision singulière de la notion de distribution (A) qui se justifie par les pondérations différentes qu'elles assurent entre les intérêts en présence (B).
A. 	Un intérêt double
        28 –	L'intérêt des concepteurs originaires et subséquents. Que ce soit à l'égard des contributeurs originaires ou subséquents, le respect d'au moins deux obligations conditionne la redistribution, comme une sorte de « socle minimal des licences FLOS » : le respect de la paternité de l'œuvre et le maintien de la clause d'exclusion — ou de limitation — de garantie et de responsabilité.
	La reconnaissance de sa paternité sur l'œuvre est bien souvent le principal retour que recevra l'auteur pour la diffusion de sa création. Peu exigeante, l'exécution de cette obligation consiste le plus fréquemment en une obligation de ne pas retirer le copyright de l'auteur, celui ne désirant pas faire figurer son nom n'y étant évidemment pas contraint.
	L'exclusion de garantie et de responsabilité est la deuxième clause qui est obligatoirement maintenue lors de la redistribution de l'œuvre. Si elle est souvent dénoncée en France au nom du droit de la consommation, il nous semble juste qu'un auteur ne retirant aucun bénéfice direct de l'exploitation de son œuvre n'ait pas à souffrir d'une responsabilité égale à celle de celui qui vendrait son travail. En substance, ces clauses minimalistes se trouvent être l'unique substance de licences ultras permissives telle que la licence BSD ou MIT/X.
        29 –	L'intérêt des utilisateurs. Lors de la première distribution de l'œuvre sous licence FLOS, l'utilisateur — alors licencié — dispose de l'ensemble des libertés disponibles sur celle-ci. Néanmoins, s'il jouit d'un droit de distribuer, il n'en a pas pour autant l'obligation ; et s'il distribue, il peut valablement être contraint de le faire sous certaines licences uniquement. Licences copyleft ou permissives, quelle que soit celle retenue, l'œuvre originaire est vraisemblablement toujours disponible sous sa première licence FLOS — le miracle du numérique permet de la modifier et redistribuer une copie sans même toucher à l'original — et limite ainsi l'intérêt de rendre l'œuvre propriétaire, puisque tout utilisateur conservera la faculté de se procurer l'œuvre originaire avec l'intégralité des droits. La seule redistribution propriétaire n'est finalement que celle des plus-values du licencié (contributions et modifications), les licences permissives lui assurant une totale « liberté » sur son travail propre. En sommes, les œuvres sous licences FLOS resteront ainsi toujours FLOS à l'égard des utilisateurs.
B. 	La notion de distribution envisagée par les licences FLOS
        30 –	Une notion légale. En l'absence de précisions contractuelles supplémentaires, une telle notion s'apprécie en vertu de la loi applicable au contrat. Le juge étant bien sûr toujours apte à requalifier, si une autre dénomination juridique doit lui être préférée. Tout n'est donc qu'affaire de droit international privé, méritant une étude complète ; nous renvoyons ainsi aux études qui furent menées sur le sujet puisque celles-ci sortent du cadre de notre réflexion. Tout au plus pourrons-nous dire, en ce qui concerne la loi applicable au contrat, qu'en l'absence de clause contraire, le contrat sera régi « par la loi du pays avec lequel il présente les liens les plus étroits », étant fréquemment dans notre cas la loi du For — c'est-à-dire la loi française en France. Notre loi contient cette notion dans les droits de reproduction et de représentation qui se définissent, peu ou prou, comme la communication indirecte ou directe d'une œuvre au public (vente, location, don, etc.).
        31 –	L'utilisation dans une société, avec ses filiales. L'hypothèse peut vite devenir complexe : y a-t-il distribution entre sociétés mère et fille ou sociétés soeurs ? La GNU GPL se soumet à cet égard à la loi applicable, en indiquant que la loi américaine ne semble pas considérer qu'il y ait dans ce cas de distribution. En droit français, la notion d'entreprise, dépassant les clivages de simples sociétés, permettrait sans doute d'arriver à la même conclusion. Mais même dans le cas contraire, la spécificité des licences FLOS — la volonté de « libérer » les utilisateurs — rend la situation sans grands enjeux puisque si l'on considère ces entités comme n'en formant économiquement qu'une seule, alors cette dernière se voit conférer des droits qu'elle détient déjà, sorte de « distribution en circuit fermé ».
        32 –	Les accords de non-divulgation. Les licences peuvent parfaitement se conjuguer avec d'autres dispositifs contractuels. Par exemple, l'auteur d'une contribution peut s'engager à ne pas publier ses modifications, ou à ne les proposer qu'à son client. La situation est courante et ne pose pas de problème tant que la licence est respectée ; les licences copyleft emportent des effets importants qu'il faut prendre en compte. Ce n'est ici que la mise à disposition qui est altérée, et non la licence : dans le premier cas, s'il n'y a pas de distribution, l'auteur n'a pas à subir les effets contraignants de la licence (par exemple mise sous une licence identique), tandis que dans le second cas, l'auteur doit respecter la licence, et donc éventuellement livrer le logiciel sous licence copyleft — dans notre hypothèse à un client unique. Ce client disposera de tous les droits et pourra alors librement redistribuer le logiciel s'il l'entend, mais, étant lui-même soumis à celle-ci il ne pourra le faire qu'en accordant les mêmes droits aux utilisateurs. Solution logique, un licencié qui chercherait à limiter contractuellement les droits de son partenaire sans que la licence le lui permette serait dès lors en infraction avec cette dernière.
II - 	Le contournement des licences sous couvert de non-distribution
        33 –	Une volonté de contourner les licences. à l'égard du licencié, les effets contraignants de la licence ne s'enclenchent qu'au moment de la redistribution de l'œuvre, de telles obligations — il est toujours utile de le rappeler — n'existant qu'en raison des droits exorbitants cédés au licencié. L'évolution des techniques de communication aidant, certains licenciés eurent l'idée d'utiliser la fonction de l'œuvre sans distribuer cettedite œuvre.
	Pour ceci, l'expansion du réseau est une voie royale en permettant une utilisation sans distribution (A), qui rompt l'équilibre qui avait été construit au sein des licences FLOS (B).
A. 	Une utilisation sans distribution grâce au réseau
        34 –	Une technique limitée aux œuvres fonctionnelles. En protégeant uniquement la forme et non la fonction qui peut être comprise dans l'œuvre, la protection de certaines créations par le seul droit d'auteur montre ses limites dès que cette fonction peut être séparée de la forme protégée. Dans le cas d'Internet, l'utilisation d'un logiciel pour permettre la fourniture d'un service rentre dans ce schéma-là, puisque le logiciel peut ne pas être distribué lorsque sa fonction l'est : l'utilisateur va adresser au fournisseur du service une requête, celui-ci la traitera chez lui — sur ses propres ordinateurs —, et la réponse sera renvoyé in fine à l'intéressé. Au final, pour l'utilisateur, la fonction est la même, tandis que le licencié (du logiciel en question) profite des développements FLOS et évite de devoir se conformer à de quelconques obligations puisqu'à aucun moment le logiciel — dans sa forme — n'est distribué. Pour le donneur de licence, il paraît difficile de reprocher au licencié un usage scrupuleusement conforme aux licences...
        35 –	Des utilisateurs sans liberté. Finalement, les utilisateurs d'un tel service ne bénéficieront d'aucune des libertés accordées par les logiciels libres. On retrouve par ce système une utilisation propriétaire, pire même que le schéma classique puisque l'utilisation est complètement opaque à l'utilisateur : les services se payant alors au forfait ou à l'unité. La situation est aussi critiquable en ce que le licencié bénéficie du travail des autres sans respecter les obligations auxquelles leurs auteurs avaient souhaité astreindre le licencié dès qu'il sortait l'œuvre de sa « sphère privée ».
        36 –	Une importance qui s'accroît. L'évolution des technologies permet aujourd'hui, et encore plus demain, de favoriser cette migration des logiciels vers une utilisation en réseau. L'ensemble des licences FLOS actuelles n'est pas adapté à cette mutation, et le mécanisme même des licences FLOS semble réticent à trouver une réponse : l'interdiction d'un tel usage et sa soumission à condition méconnaissent entièrement les principes fondateurs des licences FLOS. Ces problèmes ne sont pas que fiction, et l'hypothèse de ces logiciels uniquement utilisés sur Internet a contraint à imaginer de nouvelles licences mieux adaptées.
B. 	Les répercussions sur les nouvelles licences : la licence Affero General Public License (AGPL), la Gnu GPL v3 et l'Open Software License
        37 –	L'Affero General Public License (AGPL). Récente — la licence date du 1r Mars 2002 —, l' AGPL fut rédigée en collaboration entre l'entreprise Affero et la FSF. Elle fut écrite afin de pallier aux manquements précités : c'est-à-dire contraindre à la distribution du code source lors d'une simple utilisation du logiciel au travers d'Internet.
	La « technique » employée est assez novatrice : si le programme en question est destiné à interagir avec les utilisateurs par le réseau, et que la version reçue donnait la possibilité à l'utilisateur de télécharger le code source, alors le licencié ne peut pas supprimer cette option. La technique est ingénieuse puisque l'application de cette clause dépend de l'évolution du logiciel : tant que le logiciel fait l'objet d'une distribution « traditionnelle », les dispositions de la licence GNU GPL trouvent à s'appliquer, et dès lors que l'un des licenciés utilise sa version sur Internet en conférant la possibilité de télécharger le code source, alors les licenciés subséquents continueront de disposer du code source dans les mêmes conditions. Dans cette hypothèse, le licencié ne dispose plus d'un droit de distribuer, mais d'une obligation dès qu'il réutilise le logiciel sur Internet, rendant ainsi ses contributions disponibles. En effet, il y a bien ensuite une distribution au sens de la GNU GPL qui s'effectue lors du téléchargement du code source : le licencié se voit imposer d'y adjoindre la licence sur l'ensemble, logiciels et œuvres dérivées. Par ce subterfuge, la distribution du logiciel se retrouve liée à son utilisation sur Internet. 
        38 –	L'AGPL, un remède lacunaire. Cette version trouvera sûrement matière à évoluer, la première version comportant certaines lacunes : limitation à la transmission par HTTP, et rédaction qui en fait une licence non-FLOS — n'en déplaise à la FSF qui la considère comme telle — puisque dès lors qu'une partie de code devient intangible, la licence contrevient à la liberté de modification de l'utilisateur. Le cas est très similaire à celui de la licence GNU FDL : conçue pour les documentations de logiciels, elle permet de désigner des sections invariables qui devront être maintenues par le licencié. Pour Richard Stallman et la FSF, cette disposition ne contrevient pas à la liberté de l'utilisateur qui doit s'interpréter différemment pour les documentations. À l'inverse, l'application scrupuleuse de la charte Debian conduit à une solution contraire par la communauté Debian, permettant de conserver une vision claire des libertés mise en avant : la licence n'est considérée comme libre qu'autant qu'elle ne contienne pas de portions invariables. Cette portion invariable étant essentielle dans l'AGPL, la qualité de licence FLOS ne devrait pas plus lui être reconnue. Cette licence n'en est pas moins applicable et remplit parfaitement la fonction à laquelle elle se destine, et si la liberté du licencié s'en trouve peut-être affaiblie, ce n'est qu'au profit de celle plus grande d'autres utilisateurs. La gymnastique est donc conforme à la philosophie de la FSF qui privilégie systématiquement utilisateurs à licenciés, les seconds étant en quelque sorte au service des premiers. Prolongement logique, une compatibilité spéciale est déjà aménagée au sein de l'AGPL pour assurer sa compatibilité avec la GNU GPL v3, la réciproque se discutant actuellement.
        39 –	Le projet de GNU GPL v3. La FSF et RMS ont expressément indiqué qu'ils désiraient inclure dans la nouvelle version de la GNU GPL, une clause permettant de contrecarrer l'utilisation propriétaire des logiciels sur Internet. Le projet — en cours d'élaboration lors de l'écriture de ces lignes — avait comme intention initiale de rédiger une clause similaire à celle présente dans la licence AGPL, mais on ne retrouve dorénavant qu'une tolérance dédiée à cette dernière. Pour conclure, dans l'état actuel des choses, la GNU GPL v3 est libre — le contraire eut été dramatique —, mais favorise la diffusion d'une licence non libre... Des situations comme celle-ci nous amènent à penser que les incompatibilités entre licences sont loin d'être résolues...	
        40 –	L'Open Software License (OSL). écrite par Lawrence Rosen, cette licence, qui présente des inconvénients qui ne nous intéressent pas ici, imagine un système intéressant en matière de distribution. La licence utilise le terme de développement externe du logiciel, qui se voit conférer les mêmes effets qu'une distribution simple. De ce fait, un logiciel utilisé sur le réseau est soumis aux effets contraignants de la licence et le licencié doit donc en fournir le code source aux utilisateurs. Il s'agit en réalité d'une méthode permettant de déplacer le « curseur distribution » à partir duquel les effets contraignants de la licence FLOS s'appliquent.
Section II - 	Les effets contraignants des licences FLOS déclenchés par la distribution
	Si tant de ruses furent imaginées pour éviter de distribuer une œuvre sous licence FLOS, ce ne fut que pour éviter les contraintes inhérentes à l'application des licences (I), la distribution simultanée d'un ensemble d'œuvres rendant celles-ci d'autant plus complexe que le nombre de licences est élevé (II).
I - 	La pleine application des licences lors de la distribution de l'œuvre licenciée
	Présentées sommairement en introduction, nous détaillerons ici les effets emportés par les licences permissives (A) ou copyleft (B).
A. 	Les effets des licences permissives à l'égard du licencié
        41 –	Les droits. Dans une telle licence, la distribution de l'œuvre par le licencié parachève l'accomplissement de tous ses droits. Il peut non seulement distribuer l'œuvre — modifiée ou non — comme il l'entend, mais aussi choisir la licence qu'il veut lui associer. Le licencié dispose donc du pouvoir de conférer des droits de façon purement arbitraire, sur ces contributions et celles des autres, au besoin grâce au mécanisme de la stipulation pour autrui.
        42 –	Les Obligations. Les obligations, que l'on a nommées jusqu'ici effets contraignants des licences, sont principalement le « socle minimal des licences FLOS » qui se décompose en une obligation de paternité et une obligation d'exclusion de garantie. D'autres modalités d'exécution conditionnant l'usage des droits par le licencié viennent parfois se greffer sur celui-ci.
	L'obligation de paternité est double : ne pas faire croire que l'on est le concepteur du travail d'un autre, ou qu'un autre est à l'origine de nos propres contributions. Elle se satisfait souvent par l'apposition d'un copyright sur chaque fichier pour distinguer les apports de tous.
	L'exclusion de garantie doit aussi être maintenue afin que le donneur de licence ne soit pas inquiété pour l'utilisation d'un code pour lequel il ne reçoit aucune contrepartie. Elle se compose en une exclusion de garantie — le plus souvent totale — devant elle aussi être apposée dans l'en-tête des fichiers. Les autres dispositions que l'on peut trouver sont pour la plupart mineures, même si quelques-unes prirent une ampleur inattendue comme les clauses de publicité ou celles interdisant l'usage de certains mots.
B. 	Les effets propres aux licences copyleft à l'égard du licencié
        43 –	Droits. Les droits conférés par ces licences sont identiques à ceux énoncés précédemment, à l'exception — de taille — du choix final de la licence assujettissant l'œuvre licenciée et ses œuvres dérivées. Même s'il ne s'agit que d'une modalité à l'exercice d'un droit, c'est une contrainte pour le licencié et elle doit donc être considérée à ce titre.
        44 –	Obligation. On retrouve ici les obligations que dans les licences permissives, mais se rajoute l'obligation pour l'œuvre licenciée d'être continuellement redistribuée sous la même licence aux utilisateurs subséquents. Les licences copyleft se subdivisent en deux catégories, suivant leur interprétation faite de l'œuvre dérivée : les licences copyleft standard ou les licences copyleft fort. Enfin, certaines licences ne font qu'une application conditionnelle du copyleft, permettant une distribution propriétaire en l'absence du code source et avec un lien vers les sources de l'œuvre de base, et la distribution de type copyleft si le code source est fourni. Quant à la responsabilité, les licences copyleft ne contenant qu'une simple limitation de garantie et de responsabilité sont assez peu fréquentes, certaines envisageant même une responsabilité différente suivant si la distribution est commerciale ou non.
II - 	La distribution d'une « œuvre de compilation »
        45 –	La distribution. Il n'y a pas de définition exacte du terme de compilation — mere aggregation en langue shakespearienne —, tout au plus pouvons-nous nous inspirer du sens commun pour l'envisager comme un rassemblement d'œuvres distinctes, sous licence FLOS ou non, sur un même support, et pour une même distribution. Il peut être intéressant de remarquer que le droit d'auteur français peut protéger une telle compilation dès lors qu'elle est originale et reflète la personnalité de son auteur ; même s'il est concessible qu'il n'est pas fréquent de remplir en l'espèce la condition d'originalité (les critères étant éminemment techniques).
	Du point de vue des œuvres compilées, la distribution revient à cumuler les obligations envers le distributeur (A), aboutissant à quelques situations délicates pour ce dernier (B).
A. 	Le cumul des obligations de chaque licence
        46 –	Le respect de chaque licence. Il paraît logique que le distributeur soit contraint de respecter chacune des licences pour lesquelles il a la qualité de licencié. En aucun cas, le respect des stipulations d'une licence ne pourrait le dispenser de respecter celles des autres licences, même si cela peut arriver incidemment lorsque deux obligations sont identiques et non exclusives... Dans le cadre des licences FLOS, chaque œuvre doit conserver son indépendance, et il faut qu'elle puisse librement, et conformément à la licence, être séparée de la compilation. Une œuvre qui n'est libre qu'au sein de la compilation n'est ainsi pas une licence FLOS. Il en va du bon sens, mais il est peut-être utile de préciser que si le distributeur est aussi l'unique auteur de l'une des œuvres sous licence, il peut très bien s'« alléger » la procédure, avec comme seul impératif « logique » que les futurs licenciés aient la faculté de respecter la licence par la suite.
        47 –	Le cas des licences multiples. Certaines oeuvres se présentent parfois au licencié sous plusieurs licences, grâce à un mécanisme que l'on nommera le multilicenciement. Le licencié qui distribue une telle œuvre n'est pas soumis aux obligations de l'ensemble des licences, mais seulement à celles attachées aux droits qu'il utilise. Ainsi, il peut distribuer l'œuvre comme il l'entend dès lors qu'il le fait en respectant au moins une des licences attachées, et ceci, pour tout droit utilisé. Il s'agit donc d'une situation confortable pour le distributeur qui choisit selon quelle licence il entend distribuer.
        48 –	Le cas des conséquences directes sur la distribution. L'exemple fut abordé précédemment : certaines clauses ont des effets directs sur la distribution. Ainsi, en est-il des clauses de publicité, à l'égard des œuvres et de leurs créateurs, qui conditionnent les droits sur une œuvre à un acte sur la distribution même. Ces clauses, bénignes à leur origine, deviennent lourdes de conséquences lorsque leurs effets se cumulent ou s'accroissent. Ainsi en est-il lors de la multiplication de clauses de publicité, la plus renommée pour sa dégénérescence étant celle de la licence BSD. Elle contraignait à citer le donneur de licence dans toute publicité relative au logiciel ou à son utilisation, provoquant de lourds problèmes lorsque les contributeurs choisirent d'utiliser cette licence en modifiant la citation en leur faveur : la multiplication des citations devint rapidement extrêmement fastidieuse et gênante. Cas contraire, une obligation de ne pas faire peut à l'identique devenir incommode : par exemple par la multiplication de clauses interdisant l'emploi de certains mots, tels quels ou dans un ensemble plus grand. C'est justement pour cette raison que ces licences sont considérées comme non libre par certains, preuve en est le long débat concernant la licence PHP dans debian-legal.
        49 –	Le cas des conséquences indirectes sur la distribution. C'est l'hypothèse de clauses qui ne sont contraignantes qu'à l'égard de l'œuvre sur laquelle elle porte, mais qui limitent indirectement la distribution dans son ensemble. Tel est le cas des licences comportant une clause interdisant la commercialisation, même si ces licences ne sont pas à proprement parler des licences FLOS puisqu'elles limitent la liberté d'utilisation et de distribution (c'est une disposition que l'on retrouve dans les licences de contenu libre comme les licences Creative Commons expressément non commerciales '– NC'). Si l'on peut ici déplorer la restriction apportée, force est de constater que les intérêts en présence sont différents et qu'un nouvel équilibre est établi.
	D'autres sont moins visibles : les clauses d'attribution de compétence d'une juridiction d'une loi ajoutent à la complexité de la distribution si en cas de litiges sur l'ensemble de la compilation, les actions se trouvent devoir être jugées devant des juridictions différentes et selon des lois différentes. Ce n'est néanmoins ici qu'affaire de droit international privé.
        50 –	Une harmonisation nécessaire. Pour conclure, si les cas précités ne révèlent pas d'incompatibilités au sens formel du terme, ils mettent en évidence une incompatibilité de facto entre des licences qui poursuivent des buts différents et qui ignorent les effets pervers issus du foisonnement des obligations. Ces situations sont encore plus paradoxales lorsque sont distribuées plusieurs œuvres imbriquées les unes dans les autres, sous des licences différentes, car si l'une des licences n'est pas libre alors le tout non plus.
        51 –	Un effet limité à chaque licence. Notion incluse dans la GNU GPL, le Contrat Social Debian ou l'OSD, les licences FLOS ne doivent pas avoir de répercussions sur les œuvres séparées et indépendantes à côté desquelles elles sont distribuées. Néanmoins, certaines licences FLOS considèrent que la distribution simultanée de deux œuvres indépendantes et séparées, mais qui agissent entre elles lors de leur exécution conduit à considérer l'ensemble comme un tout soumis à une seule et même licence.
B. 	La distribution d'œuvres indépendantes et séparées formant un tout
        52 –	Une réciprocité élargie. L'hypothèse précitée doit retenir notre attention en ce qu'elle sort du cadre présenté : deux œuvres indépendantes et séparées peuvent être considérées comme ne formant qu'une seule lorsqu'elles sont distribuées simultanément. C'est le cas des licences très philosophiquement inspirées comme les licences GNU — que ce soit la GNU GPL v2,  v3 ou la GNU LGPL — qui imposent l'application d'une licence libre unique sur un ensemble de logiciels apparaissant de façon unitaire à l'utilisateur final. Devant celles-ci, le licencié se doit d'être vigilant lors de la distribution à ce qu'il entend soumettre à la licence GNU GPL : des liens sont fréquemment mis à la disposition des utilisateurs afin qu'ils puissent eux-mêmes se procurer les autres œuvres indépendantes et séparées, utilisées par la suite de façon combinée avec l'œuvre distribuée. Victimes de leur succès, les licences GNU tendent à être utilisées à mauvais escient, ou sans en mesurer les implications qu'elles emportent. Notre analyse des licences GNU est sans conteste personnelle — mais non isolée —, et elle nous semble coller au texte des licences ainsi qu'aux déclarations de la FSF ou de RMS. Ainsi, si celle-ci peut parfois paraître trop extensive, il n'en va pas autrement, d'où l'intérêt d'utiliser des techniques contractuelles pour les réajuster à sa convenance.
        53 –	D'autres effets à l'égard de la distribution. S'il n'est pas de notre intention de rendre compte du florilège de dispositions de licences FLOS à cet égard, la licence Artistic comporte une clause assez inhabituelle, fonctionnant à l'inverse de celle de la GNU GPL. La distribution d'une œuvre sous licence Artistic dans une compilation permet de contourner l'interdiction faite de ne pas recevoir de rémunération pour la distribution de l'œuvre seule, dès que celle-ci s'inscrit dans un tout. D'aucuns prétendent qu'une telle clause autoriserait le contournement de la licence en rajoutant un unique fichier à la distribution ; il faut selon nous se conformer à la lettre de la licence qui exige bien plusieurs programmes coexistants.
Chapitre II - 	La notion d'« œuvre dérivée » comme dernière limite à l'effet des contrats
        54 –	Un renoncement au secret. Les donneurs de licences FLOS, en distribuant leurs œuvres à code ouvert, renoncent au secret et choisissent de recourir au seul droit d'auteur pour protéger leur création. Ceci alors même que les deux protections sont traditionnellement associées pour les œuvres fonctionnelles — comme les logiciels — en les distribuant dans un langage seulement compris par les machines. À partir de là, les donneurs de licence ne peuvent s'opposer qu'aux actes d'empiétements sur leur monopole, ne couvrant par ailleurs que l'aspect original de leur création. Le droit d'auteur leur permet de contrôler tout acte de représentation ou de reproduction de leur œuvre, intégrale ou non, modifiée ou non. Parlant de l'évolution d'un logiciel FLOS, Philippe Laurent la qualifie d'« une chaîne d'œuvres dérivées, dont l'analyse détaillée ne peut être correctement effectuée qu'en accomplissant un fractionnement temporel, comparable à une échelle dont chaque échelon équivaut à la création d'une œuvre dérivée ». C'est donc à chaque échelon que la licence aura vocation à jouer, c'est-à-dire à toute nouvelle distribution d'une œuvre dérivée.
	Par ce mécanisme, le droit d'auteur a vocation à encadrer la distribution de l'œuvre originaire, et celle de ses œuvres dérivées (Section I), des conflits naissant aux confins de cette extrême limite (Section II).
Section I - 	La notion d'« œuvre dérivée » comme envisagée par les licences FLOS
	Toutes les licences n'ont pas le même intérêt à qualifier une œuvre d'« œuvre dérivée » (II), mais le mécanisme de détermination reste identique (I).
I - 	Un mécanisme identique pour la détermination de l'« œuvre dérivée »
	L'expression d'« œuvre dérivée » est avant tout une notion légale (A) qui confère des droits inclus dans la licence, et dont le non-respect peut être sanctionné (B).
A. 	Une analyse légale de la notion d'« œuvre dérivée »
        55 –	Distinction entre œuvres dérivées et composites. Les deux notions sont connues pour leurs points communs et leur régime très similaire, puisque dans les deux cas l'usage des droits de reproduction et de représentation de l'auteur de ces œuvres est soumis à autorisation de l'auteur originaire. Il reste pourtant étonnant de constater comment deux notions qui sont juridiquement distinctes ont pu être regroupées en une seule et unique par la doctrine et les praticiens. Celle-ci nous sera par ailleurs fondamentale pour la suite des développements.
        56 –	L'œuvre composite. Elle est définie comme « l'œuvre nouvelle à laquelle est incorporée une œuvre préexistante sans la collaboration de l'auteur de cette dernière », « l’œuvre composite est la propriété de l'auteur qui l'a réalisée, sous réserve des droits de l'auteur de l’œuvre préexistante ». L'un des critères déterminants est la dépendance à une œuvre originaire, sans emporter pour autant modification de celle-ci.
        57 –	L'œuvre dérivée. La notion légale se déduit de son contenu : « Les auteurs de traductions, d'adaptations, transformations ou arrangements des œuvres de l'esprit jouissent de la protection instituée par le présent code sans préjudice des droits de l'auteur de l’œuvre originale. Il en est de même des auteurs d'anthologies ou de recueils d’œuvres ou de données diverses, tels que les bases de données, qui, par le choix ou la disposition des matières, constituent des créations intellectuelles ». L'apport du second auteur est différent : il crée ici une nouvelle œuvre en s'appuyant sur l'ancienne. Dans le cas des logiciels FLOS, ce serait notamment une modification du code source d'un logiciel — pour l'adapter ou corriger des erreurs par exemple — ou une traduction du code en un autre langage.
        58 –	Un cumul possible. Une oeuvre peut parfaitement être l'œuvre composite d'une œuvre dérivée, si l'oeuvre originaire est modifiée et que d'autres lui sont ajoutées. C'est une situation extrêmement fréquente au sein des logiciels, et même, plus généralement, de tout développement FLOS.
B. 	La sanction pour le non-respect des conditions associées aux licences
        59 –	Sanction de base. Le principe gouvernant le droit d'auteur est que tout ce qui n'est pas expressément permis est interdit. Le licencié sera donc contrefacteur pour tout acte réalisé sans que la licence le lui permette.
        60 –	Sanction aggravée. Sanction courante dans les licences copyleft, le licencié qui ne respecte pas une obligation perd l'ensemble des droits conférés par la licence. C'est une résiliation — les effets ne sont donc que pour le futur — et l'ancien licencié se trouvera alors rapidement contrefacteur s'il désire utiliser les droits auparavant concédés. De plus en plus de licences tentent de se prémunir contre la menace des brevets logiciels, et instaurent à cet effet des clauses prévoyant, en cas d'action en contrefaçon — par un licencié sur un des brevets licenciés —, une résiliation expresse des droits concédés.
II - 	Une absence de consensus sur le champ adapté de l'« œuvre dérivée »
        61 –	Une qualification contractuelle, donc internationale ? Nous savons dorénavant que la notion d'« œuvre dérivée » se décompose en celle d'oeuvre composite et d'oeuvre dérivée. Si la plupart des licences utilisent ce vocable, leur portée internationale semble bien indiquer qu'elles n'entendent pas limiter l'interprétation de cette notion à une qualification nationale (et encore moins française). 
	Les licences FLOS prirent le parti de délimiter elles-mêmes ce qu'elles entendaient par « œuvre dérivée »(A) dans le contrat, par des mécanismes dont il faut apprécier la valeur (B).
A. 	Une délimitation hétérogène de l'« œuvre dérivée » au sein des licences FLOS
        62 –	Un intérêt limité pour les licences permissives. Un brin de réflexion nous amène à réaliser que les licences FLOS permissives sont indifférentes aux « œuvres dérivées » sur lesquelles elles ne produisent aucun effet. Les seules contraintes restent attachées à l'œuvre originaire et se composent la plupart du temps du seul « socle minimal des licences FLOS ». Le remplacement et la modification progressive du code réduiront progressivement l'étendue de la licence qui finira probablement par s'éteindre.
        63 –	Copyleft standard et fort, œuvre dérivée et composite. La distinction opérée précédemment prend ici toute son importance : les licences FLOS avec un copyleft standard entendent imposer à toute œuvre dérivée d'être licenciée à l'identique, tandis que cette contrainte se retrouve autant à l'égard des œuvres dérivées que composites dans le cas des licences FLOS à copyleft fort. La logique des licences FLOS à copyleft standard, imposant que toutes modifications ne puissent être distribuées que sous la même licence, est celle de l'auteur qui veut permettre une amélioration de son œuvre au contact d'une communauté FLOS, sans que quiconque puisse se l'approprier. Les licences FLOS à copyleft fort sont celles qui utilisent le mieux le droit d'auteur puisqu'elles conditionnent toutes autorisations à cette réciprocité. Leur logique plutôt agressive est celle de l'auteur qui souhaite l'amélioration de son œuvre, mais aussi son développement, voire son extension. Nous assistons ensuite à un effet « boule de neige » grâce aux licences à copyleft fort : l'œuvre devient de plus en plus intéressante au fur et à mesure que l'on y participe, et attire alors de nouvelles contributions qui accentueront le mouvement. La finalité libertaire qui gouverne ce type de licences explique qu'elles cherchent à libérer — de manière plus ou moins contrainte — un maximum d'oeuvres.
        64 –	L'appréhension de l'« œuvre dérivée » par les licences FLOS. Deux techniques peuvent être utilisées conjointement au sein d'une même licence FLOS pour déterminer les « œuvres dérivées », en tant qu'oeuvres soumises à la licence. La plus simple consiste à se soumettre à la détermination légale de l'œuvre dérivée, mais, le critère étant souvent insuffisant, les contrats permettent de le compléter ou de s'y substituer. Au sein de la méthode contractuelle, nous renvoyons à l'approche historique faite en introduction pour y déceler les licences favorisant les critères objectifs ou subjectifs. Parmi celles-ci, pour leur forte utilisation et leurs spécificités, nous précisons ci-dessous l'appréhension des licences GNU.
        65 –	L'appréhension GNU. Nous l'avions indiqué, les licences de la famille GNU présentent la particularité d'être des contrats « orientés », teintés d'intention. Plus que des critères objectifs, elles contiennent une volonté particulière des parties : le logiciel est ici envisagé comme « un tout » — dans sa globalité donc —, tel qu'il apparaît à l'utilisateur. La liberté de ce dernier étant la finalité recherchée, il faut que le logiciel utilisé soit complètement libre. En ce qui concerne la GNU GPL, deux types d'œuvres sont soumis à son emprise : les œuvres basées sur l'œuvre sous licence GNU GPL, et les œuvres parties à un tout, un ensemble plus grand contenant l'œuvre sous GNU GPL. Si l'on devait appliquer les critères légaux, la première situation recouperait globalement celle d'une œuvre dérivée, la seconde celle d'une œuvre composite.
B. 	La valeur légale d'une définition contractuelle de l'« œuvre dérivée »
        66 –	La question de la prise en compte des parties. Un contrat exprime la volonté des parties, c'est « la loi des parties » à laquelle ils sont tenus. Il existe néanmoins des limites à cet engagement, que ce soit les bonnes moeurs ou l'ordre public. La question à soulever est donc de savoir si les parties peuvent librement décider de l'étendue d'application d'un droit d'auteur, ou si celui-ci leur est imposé. Les bonnes moeurs sont facilement écartées, il reste l'ordre public : est-ce que les dispositions légales délimitant l'étendue du droit d'auteur sont d'ordre public, ou ne sont-elles que supplétives ? Les licences GNU, en appréhendant le logiciel dans les fonctions qu'il exécute et non dans sa seule écriture, aboutissent à considérer comme une seule œuvre nouvelle deux œuvres pourtant indépendantes et séparées. Dès lors, cette interprétation étend bien les prérogatives de l'auteur à d'autres œuvres, et serait sans effet si le caractère d'ordre public était retenu.
        67 –	L'appréhension contractuelle de l'œuvre dérivée. Plusieurs systèmes d'appréhension différents coexistent au sein des licences FLOS. D'une part, les licences philosophiques, comme la famille des licences GNU, ont une vision proche de la vision légale, qu'elles interprètent. D'autre part, les licences académiques, comme la licence BSD, ont choisi de ne pas appréhender les œuvres dérivées et composites. Enfin, les plus récentes, les licences institutionnelles et de culture libre essayent quant à elles de simplifier les situations, soit en se soumettant sans condition aux définitions légales, soit en remodelant en prenant compte l'aspect numérique. 
        68 –	Rétablir un équilibre. Nul doute qu'un système libéral comme celui du copyright permet une telle interprétation. La question est plus complexe lorsqu'elle se pose dans notre propre système juridique, auprès d'un droit d'auteur ultra protecteur envers les auteurs, protégés surtout contre eux-mêmes. Aucune réponse légale ou judiciaire n'existe à ce jour sur cette question, il nous paraît pour notre part logique qu'une telle intention soit prise en compte en ce qu'elle n'a pour effet que de limiter les combinaisons entre logiciels propriétaires et logiciels FLOS. Il semble opportun que celui qui livre son œuvre dans l'intention d'assurer le maximum de liberté aux utilisateurs, puisse refuser de voir celui-ci utilisé au profit d'un autre logiciel, non libre. La combinaison des logiciels, que l'on suppose supérieure à l'un seulement des logiciels, serait dès lors en partie propriétaire et l'utilisateur verrait ses libertés fortement amoindries. Le contrat permet donc ici d'étendre contractuellement l'emprise du droit d'auteur.
	Une fois l'étendue des licences copyleft déterminée grâce aux notions d'œuvre dérivée et composite, il faut se pencher sur les empiétements limitrophes, fréquents en présence de deux œuvres coexistantes (Section II). 
Section II - 	Les confrontations entre licences lors de la création d'une « œuvre dérivée »
        69 –	L'« œuvre dérivée », source de conflits. L'image d'une « chaîne d'œuvres dérivées », la métaphore de la « forêt dont les branches des arbres s'entrecroisent », ainsi que la notion de « développement coopératif » mettent en exergue la création perpétuelle de nouvelles œuvres dérivées, fondement même du développement des communautés FLOS. Mais c'est aussi lors de la formation de celles-ci, quand deux œuvres — originaires ou dérivées — sont mêlées en une nouvelle, que les licences viennent à se confronter. La notion d'« œuvre dérivée » devient alors source de conflit quand plusieurs des œuvres sont sous licences copyleft, et que l'œuvre nouvelle est dérivée des deux : si les deux licences FLOS copyleft sont différentes et n'envisagent aucune concession, alors la situation devient insoluble et la distribution de l'œuvre dérivée impossible.
	Si nous pouvions jusqu'ici généraliser l'application des licences FLOS à tout type d'œuvre, il est ici opportun de prendre en considération l'objet de la licence et son support (I) afin de déterminer ensuite les œuvres dérivées, par une analyse a contrario des conditions à remplir pour qu'une œuvre échappe à cette notion  (II).
I - 	La prise en considération de l'œuvre et de son support
        70 –	Internet et le numérique. Avec l'expansion du numérique et d'Internet, nos conceptions mentales furent récemment amenées à évoluer dans nombre de domaines, nous ne devons donc pas négliger leurs impacts lors de notre appréhension des objets de droit. L'aspect fictif du numérique produit des conséquences (A) limitant l'effectivité de nos traditionnelles catégories de droit d'auteur (B).
A. 	Prise en compte du caractère fictif du numérique
        71 –	L'œuvre et les fichiers numériques. Par le numérique, l'œuvre recouvre en partie son caractère immatériel : plus que présente, elle est parfois même omniprésente. Le langage informatique, à son plus bas niveau, peut se résumer à une suite de 1 et de 0, l'utilisateur — grâce à son ordinateur — donnant ensuite vie aux informations contenues. Ainsi, une œuvre unique peut parfaitement être contenue dans plusieurs fichiers, comme un seul fichier peut contenir plusieurs œuvres séparées et indépendantes. Il faut en effet garder en tête, que celui qui agence les informations pense dans une logique qui n'est pas celle du droit d'auteur, et n'œuvre certainement pas pour simplifier le travail du juriste. Lorsqu'une œuvre est dispersée, le numérique permet de la recomposer en allant chercher les éléments requis dans certains fichiers grâce aux liens prévus entre ceux-ci.
        72 –	Le cas complexe des logiciels. Lors de la conception d'un logiciel, l'auteur-programmeur peut choisir d'utiliser d'autres logiciels de diverses manières. Le plus simple consiste à adapter sommairement le logiciel et à l'insérer — l'emboîter pourrait on dire — dans son programme. Une seconde approche, plus évolutive, consiste à inclure uniquement les commandes dans son logiciel qui lui permettront d'aller chercher les parties de code l'intéressant lors de son exécution, le résultat étant identique pour l'utilisateur.
	Pour mieux comprendre la notion de lien, utile dès lors que certaines licences requièrent la publication du code source des objets liés, il convient d'utiliser un langage ad hoc nécessaire pour préciser le fonctionnement d'un logiciel lors de son exécution. La notion de process, ou processus, intervient lors de l'exécution du logiciel dans l'environnement système, c'est un programme en cours d'exécution ou d'opération. Il est possible de transposer l'image d'un processus à celle d'un agent dans un monde réel, où celui-ci accéderait et manipulerait des données, communiquerait avec d'autres processus, les commanderait ou s'y soumettrait. Ils peuvent être nombreux simultanément pour interagir avec le système d'exploitation, ou entre eux et se regroupent alors dans plusieurs ressources partagées afin de mener à bien une tâche commune. C'est ce rassemblement de processus qui permet de reconstituer les logiciels lors de leur exécution : on pourrait parler d'une « communauté d'agents » réalisant la ou les fonctions d'un seul et unique logiciel. C'est cette réunion autour d'une fonction commune que tendent à appréhender, la licence CeCILL expressément, et la licence GNU GPL comme « présomption d'intention ».
	Il semble opportun, dans le cadre des logiciels, de rapprocher cette notion de celle de brevet de dépendance en propriété industrielle : pour pouvoir exploiter ou faire exploiter un brevet qui dépend d'un autre, il faut obtenir l'autorisation du breveté dont l'invention est contenue en tout ou partie. En matière de brevet, c'est la fonction procurée par l'invention qui est protégée, c'est pourquoi il est aisé de faire un parallèle avec les logiciels où il s'agit bien de profiter des logiciels des autres. En effet, dans le cas des logiciels FLOS, l'exemple typique est celui de l'incorporation d'un logiciel dans un ensemble plus grand — sans le modifier — dans l'optique de lui faire remplir une certaine fonction, de rajouter des fonctionnalités notamment.
        73 –	Le cas des autres œuvres. L'aspect fonctionnel des logiciels les distingue des autres œuvres, néanmoins, l'immatérialité du numérique agit tout autant pour ces dernières. Les œuvres peuvent être identiques lors de leur développement et de leur exécution, ou nécessiter cette dernière pour parfaire une œuvre qui se recompose alors. La même conclusion s'impose donc.
        74 –	L'appréhension du numérique par le droit. Beaucoup de juristes sont réticents à voir dans le numérique une raison suffisante pour infléchir leur appréhension des œuvres. Ainsi, d'éminents auteurs considèrent — avec rigueur — l'œuvre telle qu'elle est distribuée à l'utilisateur, et non comme elle lui apparaîtra une fois exécutée. Ce rendu informatique de l'œuvre est effectivement écarté de l'application du droit, car il se fait dans la sphère privée de l'utilisateur. De la même façon, l'œuvre dérivée ou composite qui serait créée lors de l'exécution du logiciel, le serait du fait de l'utilisateur, donc sans que l'auteur puisse s'y opposer. C'est l'absence d'équivalence entre le support et l'œuvre qui rend le juriste mal à l'aise, négligeant alors le rôle actif des auteurs : un licencié qui n'a qu'un droit de distribution sur une autre œuvre peut-il impunément aménager son œuvre d'une façon telle qu'elle apparaisse personnelle lors du développement, mais œuvre dérivée lors de son exécution par un ordinateur ? Le numérique serait ici la méthode parfaite pour créer des œuvres non tenues par le droit d'auteur... De plus, l'auteur du nouveau logiciel est aussi le licencié du logiciel FLOS — puisque c'est grâce aux droits conférés par cette licence qu'il a pu développer son logiciel — et devrait donc automatiquement se soumettre à la licence lors de la distribution puisqu'il s'est contractuellement engagé à licencier certaines œuvres sous une certaine licence.
B. 	Une cloison finalement peu fiable
        75 –	L'œuvre numérique, un « type d'oeuvre » unique ? L'apparition de nouvelles licences s'appliquant à tous les types d'œuvres a engendré une multiplication des conflits. Là où on considérait auparavant qu'une même la licence s'appliquait à l'œuvre ainsi qu'aux œuvres accessoires, la question se pose aujourd'hui de savoir quand est-ce qu'une licence sur une œuvre est susceptible de s'étendre aux autres œuvres de nature différente auxquelles elle est liée. Le numérique rendant leurs supports similaires ajoute à la confusion. S'il faut à notre goût adapter le droit à certaines pratiques des communautés FLOS, les catégories juridiques sont ici le plus à même de répondre à la question, ayant en quelque sorte elles-mêmes fixé quand est-ce qu'une œuvre était séparée et indépendante d'une autre. Partant, dans l'hypothèse où l'utilisation simultanée de deux œuvres n'aboutit pas à la création d'une œuvre unique nouvelle, il semble logique d'affirmer que les licences coexistent pacifiquement : pour qu'il y ait œuvre dérivée, il faut déjà qu'il y ait une œuvre... La question est plus complexe dans le domaine des « œuvres d'art pur » où deux d'entre elles peuvent fréquemment en former une nouvelle. Heureusement, quasiment toutes les licences copyleft pour contenu libre n'ont qu'un copyleft réduit et ne s'étendent donc qu'aux œuvres dérivées. Les œuvres composites étant par ailleurs expressément autorisées, l'appréciation s'en retrouve simplifiée.
II - 	Les critères de détermination du rattachement à une œuvre dérivée
	Plus technique, l'étude de cette question nous permettra d'envisager les situations délicates de réciprocité afin de déterminer les cas litigieux où une œuvre sera soumise à la licence d'une autre œuvre. Nous avons démontré que même en l'absence d'œuvre dérivée, le donneur de licence peut utiliser le contrat pour conditionner l'utilisation de son œuvre à une intention commune à laquelle le licencié doit consentir, et qui lui est donc opposable.
	De nombreux cas critiques mettant en jeu au moins une licence copyleft fort rendent perplexes autant développeurs que juristes, ce sont ceux-ci que nous étudierons (B) après avoir examiné quelques critères utilisés par les licences FLOS (A).
A. 	Les critères utilisés par les licences FLOS
        76 –	L'œuvre indépendante et séparée par les licences GNU. Formulation initiée par la licence GNU GPL, une œuvre considérée comme indépendante et séparée n'est pas soumise à la licence dès lors qu'elle est distribuée comme une œuvre distincte. Par exception, cette même œuvre distribuée dans un ensemble basé sur le logiciel licencié redevient soumise à la GNU GPL. Le projet de troisième version de la GNU GPL éclaire cette notion dans son cinquième article, en différenciant l'œuvre indépendante et séparée, distribuée séparément dans une visée autre que d'être utilisée en combinaison avec le logiciel licencié, et la même œuvre distribuée cette fois-ci de façon à être combinée avec le logiciel licencié. L'argument reste le même : si l'ensemble des programmes interagit de façon à n'en former qu'un seul, alors celui-ci — ainsi que tous ses composants — doit être licencié sous GNU GPL. L'appréhension de la GNU GPL est plus centrée sur la fonction des programmes que sur leur écriture, c'est pourquoi si plusieurs œuvres séparées et indépendantes ne peuvent rentrer dans cette qualification tant qu'elles sont distribuées séparément, il en va autrement lorsqu'elles sont distribuées comme partie d'un tout dont l'une des sections est soumise à la licence. Un argument parfois avancé à l'encontre de cette vision extensive du logiciel est que ce concept aboutirait in fine à englober aussi le système d'exploitation, mais il se trouve que la GNU GPL comporte une exception spécifique pour éviter une telle dérive. La licence GNU LGPL est moins ambitieuse, puisqu'elle permet expressément l'utilisation de l'œuvre par d'autres programmes, soulevant de ce fait moins de critiques. Néanmoins, le copyleft envisage toujours l'œuvre comme un tout et toute œuvre dérivée doit être distribuée sous la même licence alors que l'œuvre composite est autorisée — que le lien soit statique ou dynamique — tant qu'il n'y a qu'utilisation du logiciel. étant ainsi plus restrictive que la notion d'ensemble, ou de tout de la GNU GPL, le travail basé sur la GNU LGPL peut être un sous-ensemble du tout comme envisagé par la GNU GPL.
	En réalité, l'unique difficulté de ces licences est qu'il ne faut pas nécessairement chercher de critères objectifs de détachement, le contrat institue une situation où l'intention des parties, certes plus complexe à déterminer, prime le reste.
        77 –	Un espace d'adressage différent. C'est le critère choisi par la licence CeCILL pour différencier les « modules internes » — soumis à la licence — des modules externes — non soumis. Un module est interne s'il s'exécute dans le même espace d'adressage que le logiciel licencié, et externe s'il s'exécute dans un autre espace d'adressage et est appelé lors de l'exécution du logiciel. Plus objective, la notion « sacrifie » l'intention des parties à une détermination automatique de l'œuvre dérivée — notion simple et objective.
        78 –	La notion de fichiers sources. Critère mis en avant par la licence CeCILL-C, et la licence MPL, il délimite le copyleft aux seuls fichiers contenant du code sous licence. Le concept tend à la simplicité puisque chaque fichier sera couvert par une licence spécifique — unique ou multiple.
B. 	Les résolutions de conflits complexes
        79 –	L'application de la licence aux œuvres issues d'un logiciel sous licence copyleft. Cette question revient à se demander si l'œuvre issue d'un logiciel peut être qualifiée d'œuvre dérivée, ou basée sur celui-ci. La réponse est heureusement négative : l'œuvre est produite par la fonction programme, extérieure à la forme de celui-ci. Un bémol cependant, puisque certains programmes incluent une partie de leur code dans les œuvres qu'ils génèrent, celles-ci peuvent donc valablement être qualifiées d'œuvres dérivées et soumises en ce nom à la licence copyleft. La situation doit être nuancée en ce que ces logiciels prévoient fréquemment une exception dans leur licence permettant à l'utilisateur de disposer « librement » de sa création. Néanmoins, d'autres utilisent ce « copyleft déloyal » afin de rendre attractive une licence commerciale par ailleurs proposée. Par exemple, lors d'une compilation par EiffelStudio, les binaires contiennent du code soumis à la GNU GPL et doivent alors se conformer à la licence. Situation paradoxale où les binaires sont soumis à la licence pour un simple runtime en GNU GPL, alors que les fichiers sources seuls ne le seraient pas.
        80 –	La liaison entre une bibliothèque et un autre logiciel. Les bibliothèques logicielles se distinguent des logiciels programmes en ce qu'elles sont utilisées par ces derniers pour leur fournir un code assistant. Plus généralement, peut être rapproché à cette situation, tout logiciel qui n'aurait pas vocation à s'exécuter par soi-même, mais à être utilisé par un autre. Si dans le cas d'une liaison statique, la qualification d'« œuvre dérivée » ne fait pas de doute, la liaison dynamique ne doit pas recevoir de réponse différente : la seule variable étant la période où le logiciel sera complet, le développement dans le premier cas et l'exécution dans le second.
	La notion de liaisons dynamiques que nous avons essayé de présenter est en vérité plus complexe dans son appréhension par les licences FLOS, et l'image d'une communauté de processus interagissant dans un but commun nous permet de limiter l'application de cette clause de réciprocité, non pas à tous les processus présents, mais à ceux qui participent effectivement au fonctionnement du logiciel vu comme un tout. Certaines divergences existent sur l'application effective de cette clause, notamment entre la FSF et Lawrence Rosen. Nous retiendrons pour notre part qu'il est essentiel de considérer l'intention des auteurs, afin de comprendre dans quelles mesures les logiciels s'imbriquent et s'utilisent mutuellement, pour d'envisager une sorte d'exception d'utilisation minimaliste. L'argument de Linus Torvalds qui consiste à prendre en considération l'intention des parties semble être la meilleure ligne de conduite, même c'est la plus difficile à mettre en œuvre et si beaucoup de licenciés n'en ont pas conscience. Dans une telle hypothèse, c'est le juge qui tranchera en déduisant l'intention du comportement.
	La licence CeCILL, par son critère purement objectif lève l'incertitude : tous les modules s'exécutant dans le même espace d'adressage sont liés au logiciel et donc soumis à sa licence, ainsi la liaison d'une bibliothèque oblige le passage à la licence CeCILL.
        81 –	Plug-ins et drivers de périphériques. Il semble qu'il faille ici transposer la démarche précédente puisqu'il s'agira le plus souvent d'une liaison dynamique entre le plug-in et le logiciel. Les drivers sous GNU GPL posent des questions plus simples puisque lorsqu'ils communiquent avec des systèmes d'exploitation, ceux-ci bénéficient d'une exception expresse qui les dispense de la distribution du tout. À l'opposé, si c'est le système d'exploitation qui est sous GNU GPL l'effet devrait être contraire, mais l'interprétation apportée par Linus Torvalds vient alors réduire la portée du copyleft de son kernel. C'est pourquoi, dans le cas de développement de logiciels « en grappe » — par l'accumulation de plug-ins —, il est conseillé d'utiliser une licence avec un copyleft standard, ou de rajouter une exception à un copyleft fort. Dans le cas contraire, la GNU GPL pour sa part n'y verra qu'une seule oeuvre, l'existence d'un module propre à un logiciel faisant quasi systématiquement supposer une intention de lier les deux en un tout.
        82 –	Les programmes clients. Qu'en est-il des programmes qui utilisent un logiciel sous GNU GPL, par exemple ? Une situation que l'on retrouve dans la création d'une interface graphique pour gérer la base de données MySQL. La réponse de MySQL est que tout logiciel utilisant la base de données doit se conformer à la licence GNU GPL ; ses avocats ont même pu préciser que si un logiciel nécessite la base de données pour fonctionner, alors les deux logiciels doivent être distribués ensemble et respecter la licence GNU GPL.
        83 –	Les sous-classes. Lorsqu'une classe est sous licence FLOS copyleft, toute sous-classe est une œuvre dérivée, soumise à l'obligation de réciprocité. La justification découle en réalité des développements précédents puisque l'utilisation de classes parentes (ou surclasses) et de sous-classes n'est qu'une utilisation optimale des liaisons entre programmes : par défaut toutes les classes dérivées héritent de toutes les méthodes et propriété de ses super classes. On assiste ici à une ramification où chaque nouvelle sous-classe ajoute de nouvelles fonctionnalités au tronc commun.
        84 –	Conclusion de partie. Pour conclure, voici en quelques phrases les notions clés soulevées dans le chapitre précédent :
•	Afin de s'assurer de respecter plusieurs contrats auxquels un licencié est simultanément soumis, il suffit de rechercher l'étendue de chaque licence pour vérifier si leurs objets se recoupent.
•	Le licencié n'est soumis à aucun effet contraignant tant qu'il ne distribue pas les œuvres licenciées : ces effets sont alors suspendus. Par exception, certaines licences assimilent l'utilisation du logiciel sur le réseau à cette distribution.
•	Il faut, au sein des licences FLOS, distinguer les licences permissives, qui n'ont pour objet que l'œuvre d'origine sans tenir compte des contributions, et les licences copyleft qui s'étendent aux « œuvres dérivées », génératrices de conflits.
•	La notion d'« œuvre dérivée » comprend en réalité deux dénominations légales : celle d'œuvre dérivée et celle d'œuvre composite.
•	Les licences FLOS avec un copyleft standard couvrent l'œuvre initiale et ses œuvres dérivées, tandis que les licences avec un copyleft fort couvrent aussi les œuvres composites ; des techniques contractuelles viennent néanmoins parfaire cette distinction.
•	Certaines licences sont très imprégnées de la volonté des parties, l'intention de ceux-ci étant alors l'un des facteurs déterminants à la qualification d'« œuvre dérivée ».	

	Après avoir envisagé la situation complexe, mais classique, où plusieurs licences coexistent, il faut s'attarder sur celle bien plus originale où plusieurs licences se cumulent et se concurrence sur un même objet (Partie II).

Partie II - 	Une compatibilité spéciale lors du cumul des contrats
        85 –	À la recherche d'une résolution des conflits. Comment un licencié, tenu à respecter deux licences pour une seule oeuvre, peut-il remplir ses obligations ? Cette situation se rencontre dès lors qu'au moins une des licences est copyleft, englobant les contributions additives qui lui sont faites, quelle que soit leur licence originaire. Très souvent, il ne pourra pas respecter simultanément les deux licences — notamment si elles sont toutes deux copyleft —, ce sont alors des occurrences logiquement insolubles qui nécessitent l'intervention de techniques contractuelles pour ajuster leur compatibilité (Chapitre II). À l'inverse, d'autres situations permettent au licencié de distribuer l'œuvre sous une licence finale qui est conforme aux stipulations des deux licences en conflit. La licence copyleft devant être maintenue, l'action consiste à rechercher si la seconde licence se soumet à celle-ci — étant dès lors qualifiées de « compatibles ». Cette compatibilité de facto, sans arrangements nécessaires, doit s'analyser in concreto ; la théorie des ensembles est le meilleur outil pour déterminer lorsqu'une licence peut être comprise dans une autre (Chapitre I).
Chapitre I - 	La technique logique pour déterminer la compatibilité d'une licence
        86 –	Une licence globale par œuvre. Chaque œuvre, même si soumise à plusieurs licences, voire à des exceptions sur celles-ci, est sujette à un ensemble de droits et d'obligations qui forme une licence globale les englobant tous. Facile à comprendre, cette réunion de tous les droits et obligations au sein d'une même licence, permet d'examiner plus simplement la compatibilité de celle-ci vis-à-vis d'autres licences (pouvant n'être elles aussi qu'un regroupement fictif de toutes les licences assujettissant l'œuvre).
        87 –	La théorie des ensembles.  À l'aune des licences FLOS, il convient de préciser qu'une licence est compatible avec une autre dès lors que cette dernière lui est incluse, c'est-à-dire qu'elle est telle que le licencié peut conformément à celle-ci redistribuer l'œuvre dans des conditions identiques à celles d'une autre licence. Notre étude consiste donc à rechercher à quelles conditions le surensemble de la licence compatible A peut inclure le sous-ensemble de la licence absorbante B, inclusion stricte puisque les deux licences sont — par hypothèse — différentes (l'une B disposant d'un copyleft que l'autre n'a pas A). Par ailleurs, cette technique qui nous permet de rechercher la compatibilité des licences pour résoudre des conflits, est de portée générale et permet de déterminer à l'identique toutes les autres licences qui peuvent être utilisées pour distribuer une œuvre sous licence FLOS.
        88 –	Règle. En extrapolant, nous posons la règle suivante qui sera explicitée par la suite : si l'on considère les licences A et B comme des ensembles se composant de la réunion de deux autres (un ensemble de droits et un ensemble d'obligations), alors la licence A est compatible avec la licence B si et seulement si l'ensemble des droits de la licence B est inclus dans celui des droits de la licence A, et que l'ensemble des obligations de la licence B inclut l'ensemble des obligations de la licence A.

Tableau 2: Licence A compatible avec licence B
	Plus juridiquement, cette condition est atteinte si l'ensemble des droits accordés par la licence absorbante B est inclus dans l'ensemble des droits conférés par la licence compatible A (Section I) et que l'ensemble des obligations imposées par la licence compatible A est inclus dans l'ensemble des obligations imposées par la licence absorbante B (Section II).
Section I - 	Une licence compatible accordant au moins autant de droits que la licence absorbante
	Après un bref exposé des motifs de cette affirmation (I), nous envisagerons en pratique son incidence (II).
I - 	Les fondements de cette règle
        89 –	La source des droits des licences FLOS. Une licence FLOS est une cession non exclusive de droit d'auteur par le concédant au licencié. Le licencié peut ensuite distribuer lui-même les droits qu'il a reçus (A), quitte à choisir de créer des licences « moins libres » (B).
A. 	La distribution de droits et la théorie des ensembles
        90 –	Nemo plus juris ad alium transferre potest quam ipse habet. Dans la majorité des licences classiques, le licencié ne dispose pas de prérogatives suffisantes pour redistribuer l'œuvre et ne peut ainsi qu'en disposer pour lui-même. Les licences FLOS sont beaucoup plus souples puisqu'elles lui confèrent le pouvoir de redistribuer librement à autrui, à condition d'exercer ses droits conformément aux contrats en présence. La théorie des ensembles permet alors d'envisager les droits reçus comme un ensemble de droits parmi lesquels le licencié peut piocher pour redistribuer par la suite à de nouveaux utilisateurs : l'ensemble des droits conférés est donc nécessairement inclus dans l'ensemble des droits reçus, tout droit conféré n'étant qu'un droit reçu.
        91 –	Des droits parfois imprécis. Le licencié est contraint de choisir une licence qui contient des droits identiques à ceux conférés, mais licences FLOS négligent fréquemment d'inclure expressément des droits qu'elles confèrent néanmoins. En réponse à ce problème, il est souvent avancé qu'il faut « s'imprégner de l'esprit du libre » et de sa philosophie, sans être tatillon sur les licences telles qu'elles sont écrites. Et si les lacunes sont parfois incontestables, nous pensons qu'il faut effectivement jouer d'une bonne dose d'interprétation pour comprendre les licences FLOS, fruits d'une construction souvent peu juridique. Plutôt que de chercher à contester la validité de la plupart des licences FLOS, nous tenterons d'apprécier largement les droits conférés lorsqu'ils sont sous-tendus par le caractère de licences FLOS.
B. 	La compatibilité, un pouvoir de rendre moins libre ?
        92 –	Liberté envers les utilisateurs et licenciés. Le titre, délibérément provocateur pointe le doigt sur un point sensible — un nouveau troll dira-t-on — très présent au sein des licences FLOS : une licence est-elle plus, ou moins libre, si elle permet qu'un travail devienne moins libre ? Les partisans des licences GNU, centrées sur une philosophie de liberté — presque libertaire —, soutiennent qu'une licence est vraiment libre quand et seulement quand elle assure au donneur de licence que son œuvre restera indéfiniment libre. Les tenants des licences permissives BSD, dans une vision beaucoup plus universitaire, tournée vers le partage, soutiennent qu'une licence qui conditionne la redistribution n'est pas réellement une licence libre puisqu'elle lui ôte une partie de sa liberté.
        93 –	Liberté envers le développeur.  Dans le cas présent, quoi que puissent en dire les inconditionnels du copyleft, les licences permissives assurent une plus large liberté aux développeurs en les autorisant à utiliser plus facilement ces œuvres au sein d'autres plus grandes et en évitant les perpétuels conflits de licences. D'autres diront qu'un tel système ne bénéficie pas de contributions qui auraient dû être cédées, ce à quoi nous répondrons que la plupart des développeurs qui n'ont pas cédé leurs contributions, ne les auraient probablement pas distribuées s'ils y avaient été contraints. De plus, même si une œuvre vient à être licenciée différemment, elle n'en devient pas moins libre en ce qu'elle existe aussi toujours dans la même forme que précédemment, et sous la même licence, mais sans les dernières contributions. La même œuvre sera donc disponible sous plusieurs licences, à différents endroits.
	Il est en réalité sûrement impossible de trancher entre ces deux courants — chacun ayant fait leur preuve —, leurs objectifs (assurer une liberté égale à tous les utilisateurs, ou assurer une liberté quasi totale aux développeurs) sont louables et l'enjeu doit donc consister à les articuler au mieux.
II - 	Transposition pratique de la théorie des ensembles
	Les licences FLOS accordent généralement deux types de droit, tous étant redistribuables : droit d'auteur principalement (A) et licences sur les brevets quand il y a lieu (B). Par ailleurs, certaines licences confèrent plus de garanties aux licenciés que d'autres (C).
A. 	Les droits d'auteur sur l'œuvre
        94 –	Le « socle de base des licences FLOS ». Les licences FLOS ne sont qualifiées comme telles qu'autant qu'elles confèrent un certain nombre de droits au licencié : droit d'utiliser, d'étudier, de contribuer et de distribuer. Le droit de distribuer emportant celui d'attribuer les mêmes droits aux utilisateurs, les contient donc en son sein. Ainsi, aucun conflit entre licences FLOS ne devrait apparaître sur ce seul socle commun.
        95 –	Atténuation de droit, de leur étendue. La distribution des droits peut limiter les droits qu'elle remet, comme elle peut limiter leur étendue. Beaucoup de licence propriétaire ne confèrent qu'un seul droit d'utilisation, auquel peut éventuellement se rajouter un droit de distribution, très encadré dans l'hypothèse d'un freeware. Ainsi, la licence absorbante peut valablement être une licence qui accorde moins de droits, perdant de ce fait sa qualité de licence FLOS. La deuxième option qui se présente, consistant à limiter l'étendue des droits — comme celui d'utiliser et de distribuer dans un contexte non commercial —, ne supprime pas automatiquement la qualité de licence libre. Dès lors qu'une telle limitation ne supprime pas l'efficience des autres droits — comme la clause copyleft rattachée au droit de distribution — alors, la licence doit être considérée comme libre.
B. 	Les droits sur les brevets
        96 –	Accroissement de clauses expresses. En réaction à une politique « tout brevet » menée aux états-Unis, en Asie, mais aussi en Europe, de plus en plus de licences cherchent à paralyser l'effet dévastateur que pourraient avoir les brevets sur les licences FLOS. Basées sur le copyright ou le droit d'auteur, elles ne confèrent par défaut aucun droit sur les brevets qui sont susceptibles de limiter leur effectivité. La démarche actuellement la plus fréquente est d'imposer en sus une licence sur les brevets visant la contribution. Par ce biais, l'utilisateur est assuré de ne pas se voir opposer de droits sur l'œuvre puisque tous les droits d'auteur et de brevet lui sont conférés sur celle-ci.
        97 –	Un ensemble compris dans l'ensemble des droits de la licence compatible. Il n'y a aucune raison de ne pas appliquer un traitement identique à ces droits portants sur les brevets. Le licencié peut donc choisir de céder moins de droits, ou de limiter leur étendue lors de la redistribution de l'œuvre, tant que ceux-ci restent inférieurs à ceux reçus.
        98 –	Une licence de brevet implicite ? Tout juriste spécialisé en droit des brevets se doit de monter aux créneaux, mais certains commentateurs estiment qu'il existe une licence implicite de brevet dans des licences aussi permissives que la licence BSD ou MIT. Ce n'est plus souvent qu'affaire d'interprétation, mais l'usage des termes use et grant semble le leur assurer.
C. 	La garantie offerte au licencié
        99 –	Une clause rarissime. Même si c'est l'exception, certaines licences n'excluent pas directement toute responsabilité ou toute garantie de la part du donneur de licence. La vague consumériste expliquant certainement cette stipulation dans les licences se voulant les plus exhaustives et juridiques. En effet, n'étant plus limitées à un milieu professionnel, les licences libres sont dorénavant utilisées par les consommateurs, spécificité qu'il faut intégrer. De fait, la clause d'exclusion de responsabilité et de garantie fait l'objet de critiques virulentes, et certaines législations retiendront tout de même la responsabilité du donneur de licence dans quelques hypothèses précises où il ne pourra pas s'éclipser derrière le contrat. En se cantonnant au champ contractuel, dans une telle hypothèse, le donneur de licence pourra choisir de limiter plus strictement sa responsabilité et celle de son donneur de licence à l'égard des utilisateurs futurs.
Section II - 	Une licence compatible n'imposant pas plus d'obligations que la licence absorbante
        100 –	Une grande diversité. Contrairement au consensus de fait sur les droits, les licences FLOS font preuve d'une diversité beaucoup plus grande en matière d'obligations. La « règle » selon laquelle l'ensemble des obligations de la licence compatible doit être inclus dans l'ensemble des obligations de la licence absorbante mérite que nous l'approfondissions (I), avant de transposer cette théorie à la pratique des licences (II).
I - 	Les fondements de cette « règle »
        101 –	Une « règle » liée à la précédente. La théorie des ensembles appliquée aux obligations n'est en réalité que le versant miroir de son application aux droits conférés (A), les intérêts « personnels » de chaque licence desservant ici plus la compatibilité que ce n'était le cas en matière de droit (B).
A. 	La théorie des ensembles appliquée aux obligations des licences, un versant miroir de son application aux droits ?
        102 –	Un distributeur aussi licencié. Tenu par le contrat, le licencié ne peut se passer de respecter les obligations auxquelles il est soumis. Cette contrainte a pour corollaire de le contraindre à obliger ses propres licenciés que dans des termes aux moins égaux, afin que le donneur de licence ne puisse pas se retourner contre lui.
        103 –	Une qualité de licence FLOS liée aux obligations. Nous avons montré que le donneur de licence peut jouer sur l'étendue des droits qu'il confère, comme il peut aussi agir sur les obligations adjointes aux droits cédés. Bien sûr, pour que la licence FLOS ne perde pas son caractère, il faut que la licence absorbante ne fasse que définir des modalités d'exercice différentes, plus contraignantes pour le licencié. Que les droits assurant la liberté soient mis en œuvre, mais pas mis en cause.
        104 –	Une théorie des ensembles globale. Nous avons parlé initialement d'une licence absorbante (sous-ensemble) incluse dans une licence compatible (surensemble). Nous avons ensuite séparé cet ensemble en deux autres, en affirmant qu'il fallait que les droits de la licence absorbante soient inclus dans ceux de la licence compatible, et que les obligations de la licence compatible soient incluses dans celles de la licence absorbante. Néanmoins, en rattachant systématiquement une obligation à un droit, il est possible d'envisager seulement deux ensembles se composant de droits assortis d'obligations. À cette hypothèse, qui nous semble le plus correspondre à la réalité, se verra préférer la simplification initiale qui permet une analyse au cas par cas plus précise.
B. 	Les obligations comme source d'incompatibilité
        105 –	Le copyleft. Le copyleft est déjà en soi une source d'incompatibilité puisque c'est la première source d'empoignades. En voulant accroître l'emprise de la licence aux œuvres dérivées et composites subséquentes, cette licence copyleft va s'imposer à des œuvres soumises par ailleurs à une licence imposant elle aussi son lot d'obligations à respecter. D'autant que la présence d'un copyleft exprime un rattachement fort à une licence considérée comme idyllique, suggérant ainsi des dispositions très spécifiques qui limitent d'autant la compatibilité.
        106 –	Des obligations spécifiques. Cet attachement se traduit notamment par des obligations spécifiques à la charge du licencié, spécificité motivant la conception même de cette nouvelle licence. En effet, s'il arrive qu'une licence copyleft soit la copie d'une autre, il est extrêmement préjudiciable que celle-ci se réalise sans qu'il n'y ait de modifications substantielles apportées à la licence. Sans celles-ci, deux communautés vont se ressembler, par les droits et obligations auxquelles elles sont soumises, sans pouvoir pour autant échanger leurs contributions. La création d'une telle licence ne peut donc se justifier que par l'ignorance de son auteur, ou par la volonté extrêmement préjudiciable de sectoriser le libre. Il existe néanmoins un aspect « positif » qu'il convient d'exposer : une telle prolifération basée sur une licence unique facilitera la comparaison entre cesdites licences, créant ainsi une « famille de facto » de licence.
        107 –	Une licence absorbante plus contraignante. Sans reprendre les développements relatifs à la limitation des droits, notre analyse démontre qu'une licence absorbante ne peut être que plus contraignante qu'une licence compatible puisque le licencié doit a minima respecter les obligations de son donneur de licences, et peut ensuite définir de nouvelles obligations. En toute hypothèse, il convient d'exhorter à limiter cet usage par le licencié qui doit préférer une analyse globale de développement de l'œuvre, aux simples profits plus directs auxquels il pourrait être tenté de céder.
II - 	Transposition pratique de la théorie des ensembles
        108 –	Étude selon la division classique. Il suffit ici de reprendre la division du Code civil, classant les obligations en trois catégories : Obligations de faire (A), obligation de ne pas faire (B), et obligation de donner (C).
A. 	Les obligations de faire au sein des licences
        109 –	Distribution sous une licence identique. Nous l'avons évoqué à maintes reprises, voici l'obligation imposée par le copyleft. C'est, dans le cas d'un cumul, l'une des obligations qui sont obligatoirement transférées à la licence compatible, perdant dès lors cette qualité. Il existe différentes modalités concernant la distribution des sources, mais les licences compatibles n'étant logiquement pas copyleft, il n'y a pas lieu de les approfondir.
        110 –	Formalités diverses. Parmi les plus courantes au sein des licences FLOS, nous pouvons citer l'obligation d'apposer un copyright sur ses contributions. D'autres, moins courantes, peuvent aussi brièvement être présentées, comme l'obligation de tenue d'un fichier récapitulatif des plaintes adressées aux licenciés celui-ci étant ensuite distribué avec les sources). Même s'il ne s'agit pas à proprement parler d'une obligation de faire, certains délais — comme ceux relatifs à la résolution de la licence — peuvent être réduits ; l'action au contentieux peut aussi se retrouver encadrée par des clauses aménageant juridiction compétente et loi applicable qui peuvent être réajustées en faveur du donneur de licence.
B. 	Les obligations de ne pas faire au sein des licences
        111 –	Un simple rappel des dispositions légales. Certaines obligations de ne pas faire ne sont en réalité que des redites de dispositions légales impératives, qui se seraient donc tout de même appliquées. Il s'agit en quelque sorte d'un rappel des obligations au licencié afin qu'il n'ait pas à consulter les conventions internationales de lui-même. Par exemple, les obligations de ne pas retirer le copyright des autres contributeurs, de ne pas utiliser le nom de l'auteur ainsi que sa marque s'imposent de plein droit. Doublons à la Convention de Berne, il n'est pas utile que la licence absorbante les reprenne puisqu'elles sont dès lors déjà assurées, de telle sorte qu'il peut valablement être avancé qu'une licence ne comportant pas expressément de telles clauses, les contient implicitement.
        112 –	Créations d'une protection sui generis. Certaines licences interdisent l'usage de certains mots, souvent dénués d'originalité, ni même déposés à titre de marque. S'il faut émettre des réserves sur cette pratique qui est à la source d'atteinte importante à la liberté de l'utilisateur quand elle se multiplie et se cumule, une justification peut être avancée, consistant à dire que dans l'espace de promiscuité d'Internet la protection de certains droits de propriété industrielle n'est pas appropriée du fait de leur application territoriale. À l’évidence, pour bénéficier de la protection par les marques, le donneur de licence est astreint à multiplier dépôts et coûts ; interdire simplement l'utilisation de son nom à ses licenciés lui permet à moindres frais de se prévenir des confusions qu'engendrerait l'arrivée d'un licencié concurrent, exploitant un produit très identique sous un nom très similaire. Ces obligations doivent bien sûr être maintenues.
C. 	Les obligations de donner au sein des licences
        113 –	Assurer la liberté de l'utilisateur final. Privilégiant la liberté de tous à celle d'un seul, les licences imposent fréquemment au licencié de fournir lors de la distribution de l'œuvre : la licence, mais aussi le code source et une exonération totale de garantie, et voire encore, d'autres informations. Dans la même veine — nous l'avions évoqué précédemment —, la licence absorbante peut parfaitement exiger une réciprocité sur les licences de brevet aux licenciés successifs. Il s'agit indéniablement d'un droit supplémentaire pour les utilisateurs, mais c'est aussi une contrainte pour les licenciés, et elle ne peut donc pas à ce titre être révoquée.
        114 –	Assurer un retour à l'auteur initial. Certains donneurs de licence peuvent choisir de se faire conférer des prérogatives exorbitantes. C'est l'exemple de la licence NPL qui permet au donneur de licence de réutiliser les contributions au sein d'une distribution propriétaire. La BIPL en est un autre exemple, en imposant au licencié une licence sur leur brevet alors même qu'elle ne leur en consent aucune.
        115 –	CONCLUSION. Nous avons, dans cette section, cernées quelles étaient les conditions par lesquelles une licence pouvait être déclarée compatible — ou non — avec une autre. Deux licences très utilisées sont actuellement en conflit et permettent d'appliquer cette règle : la licence Apache et la licence GNU GPL. La première est une licence permissive qui comporte deux dispositions relatives aux brevets : une licence obligatoire et une résiliation automatique de toutes les licences en cas d'action en contrefaçon contre un brevet contenu dans la licence. La licence GNU GPL, si elle reprend la plupart des dispositions, ne contient pas cette hypothèse de résiliation de brevet, et ne peut donc pas couvrir une partie du code sous Apache. En effet, si elle venait à le faire, n'importe qui pourrait alors réutiliser le code sous GNU GPL sans être tenu par cette épée de Damoclès qu'est la résiliation de brevet. Le code source ne pouvant être repris dans la version actuelle de la GNU GPL tout en respectant les obligations exigées par le donneur de licence, c'est ipso facto que la licence Apache fut qualifiée d'incompatible aux yeux de la FSF.
	Après avoir envisagé les compatibilités « logique » ou « naturelle » des licences, il faut se pencher sur les techniques contractuelles permettant d'aménager ces compatibilités (Chapitre II).
Chapitre II - 	Les techniques contractuelles pour ajuster la compatibilité d'une licence
        116 –	Assurer la compatibilité. Ayant déterminé les critères permettant la reprise d'une œuvre sous licence compatible par une licence « absorbante », nous sommes obligés d'admettre que cet examen peut parfois être long et fastidieux. Par chance, si les licences permissives n'éprouvent que très rarement le besoin de se rendre contractuellement compatibles, les licences copyleft développèrent ce mécanisme. Nous envisageons ainsi les techniques contractuelles actuellement utilisées pour assurer la compatibilité entre diverses licences (Section I), proposant par la suite quelques pistes de réflexion pour résoudre ces problèmes récurrents (Section II).
Section I - 	Les techniques actuellement utilisées pour résoudre les conflits entre licences
        117 –	Règlement de litige. Comme pour tout contrat, un différend peut se résoudre ab initio (II), lors de la conclusion du contrat, ou — et c'est la majeure partie du temps le cas — au moment même où le problème se présente (I).
I - 	La résolution de problèmes de compatibilité lors de leur survenance 
        118 –	L'autorisation de l'auteur. Solution de premier ordre, la plus simple et souvent l'unique, l'autorisation du donneur de licence — transgressant sa propre licence — permettra de résoudre des situations très disparates. Mais si des compromis peuvent ainsi être obtenus (B), le nombre et la dispersion des contributeurs restent un écueil notable (A).
A. 	La difficulté pour joindre l'ensemble des titulaires de droit
        119 –	Une création plurale. Nous avons jusqu'ici évité de discuter de la qualification légale d'une œuvre FLOS à laquelle plusieurs contributeurs participent. Si la qualification d'œuvre collective peut parfois être retenue, d'autres qualifications sont envisageables comme celle d'œuvre de collaboration ou même de catégorie sui generis : elles ne sont finalement pas alternatives et se cumuleront certainement au grès des contributions successives. Œuvre de collaboration ou « chaîne d'œuvre dérivée », ces appellations ont en commun de poser le problème de la réunion de la totalité des consentements, pourtant nécessaire à un changement de licence ou à toute altération de celle-ci. Le nombre de contributeurs, qui peut aller de moins d'une dizaine à plusieurs milliers, leur anonymat ainsi que leur dispersion géographique sont parfois des obstacles infranchissables pour cette entreprise ; l'absence de consentement d'un seul interdisant toute décision concernant l'œuvre dans son ensemble, le seul échappatoire reste alors de supprimer les contributions pour lesquelles manque l'autorisation. Certains développeurs ou organismes, comme la FSF, proposent aux contributeurs d'un projet de leur céder leur copyright, une telle centralisation facilite grandement la prise de décision, la gestion, et la défense de l'œuvre. Dans notre cas, cette concentration simplifie aussi notablement le changement de licence.
        120 –	Des situations de blocage. Un exemple typique est la volonté de changement de licence du contenu du site de Debian, au profit d'une licence compatible avec la GNU GPL. Outre le problème posé par le choix de la nouvelle licence, s'ajoute la difficulté de la réunion des consentements de tous les concepteurs. Semblablement, la décision fut prise de changer la licence du navigateur Mozilla afin de passer de la simple licence MPL à une triple licence MPL/LGPL/GPL. La conversion viendrait seulement de se finir à l'issu d'un long processus de quatre années... Un dernier exemple, d'actualité, est celui du licenciement du noyau Linux — sous licence GNU GPL, limitée expressément en sa version 2 —, la réplique avancée pour le cas d'un changement de licence, est qu'une substitution serait faite de tous les codes pour lesquels le changement de licence ne pourra pas être obtenu. Mais cette conjecture est difficilement transposable et ne reste possible que pour certains projets, à condition qu'ils réunissent une communauté dense et active. Bref, nous l'avions avancé, le problème est bien réel sans se limiter à cette phase, puisqu'une fois les titulaires de droit d'auteur réunis il faut trouver un terrain d'entente avec, et entre, ceux-ci.
B. 	La résolution des problèmes de compatibilité par la conclusion d'un compromis avec le donneur de licence
        121 –	Un compromis avec le donneur de licence absorbante. Lors du problème d'incompatibilité provenant principalement de la licence absorbante copyleft qui impose la redistribution du tout sous ses propres termes, une bonne approche consiste à limiter l'étendue de ces licences. Plusieurs conduites peuvent être proposées au donneur de licence.
	Le dénouement le plus borné, mais qui permet au projet de n'être que très peu affecté, consiste, pour le donneur de licence, à consentir une exception expresse indiquant à quel logiciel il entend ne pas étendre sa licence. Celle-ci serra contenue le plus souvent dans un fichier supplémentaire distribué avec le logiciel et sa licence. Il faut noter que cette exception peut être spéciale, mais aussi beaucoup plus générale — la difficulté consistant alors à délimiter précisément son étendue. Partant, le donneur de licence renonce à une partie substantielle de son copyleft, ce qui en fait une méthode assez proche du choix d'une nouvelle licence tout en restant plus simple à mettre en œuvre et en ayant des répercussions plus visibles.
	Le second dénouement possible consiste à faire consentir une nouvelle licence plus appropriée, avec un copyleft moins large par exemple. Le risque demeure toutefois plus préjudiciable au projet basé sur l'ancienne licence, car un développement parallèle sous la seconde licence est probable (surtout qu'elle risque d'être plus compatible et donc réunir plus de contributeurs).
        122 –	Un compromis avec le donneur de licence incompatible. Étant soumise à la licence absorbante, la licence incompatible n'a pas d'autre choix que d'être remplacée par une autre, compatible : le plus souvent en supprimant simplement quelques obligations (copyleft, ou toutes autres non reprises). Le choix est limité, et les conséquences aussi importantes que pour le changement de la licence absorbante si le projet se scinde en deux par la création d'une fork.
        123 –	L'interprétation des licences par les donneurs de licences. Nous ne ferons ici que soulever rapidement une interrogation qui nécessite davantage de réflexions. À savoir : quelle est la portée d'une interprétation réalisée sur la licence par le donneur de licence ? En réponse aux questions, il est fréquent de voir les auteurs donner leurs visions relatives aux points litigieux, en rédigeant une FAQ ou en réagissant aux messages. À de rares exceptions près, ces documents n'ont aucune valeur juridique, ainsi qu'ils le stipulent eux-mêmes, car seulement les contrats devraient lier les parties. Nous pouvons toutefois avancer valablement qu'un juge pourrait en tenir compte, suivant leur visibilité. En effet, un contrat n'unit les parties qu'en ce qu'elles ont entendu convenir lors de leur accord et il serait absurde de chercher à appliquer à la lettre des dispositions complexes et sujettes à différentes interprétations, surtout dans ces contrats imprégnés d'une forte intention. Au sujet des réponses par courriels, nous conseillons vivement aux licenciés de joindre une copie de ceux-ci à la licence lors de la distribution de l'œuvre. Si l'interprétation est connue de tous dès les premières contributions, il y a de très fortes chances pour qu'elle soit suivie par le juge, car rattachées au contrat. Enfin, un exemple déjà cité, Linus Torvalds qualifie l'exception à laquelle il a assorti la GNU GPL v2 d'interprétation, en précisant ce qui pour lui constitue ou non une œuvre dérivée. Transitoire, on voit bien que cette technique n'est pas à omettre, surtout à l'égard d'auteurs peu intéressés par les histoires de propriété intellectuelle et de licences : il leur suffit brièvement de préciser leur compréhension de la licence utilisée.
II - 	Les techniques contractuelles assurant ab initio la compatibilité entre licences
        124 –	L'existence de trois techniques. Il y a, à notre sens, trois techniques qui permettent d'étendre la compatibilité d'une licence : l'existence d'une clause expresse de compatibilité (A), la modification d'une licence à l'aide d'exceptions (B) et enfin le multilicenciement (C).
A. 	Les clauses expresses de compatibilité
        125 –	Une solution simple et efficace. Voici selon nous la résolution la plus simple de conflits entre licences : l'une se soumet expressément à l'autre. Les exemples sont nombreux et nous ne les envisagerons évidemment pas de façon exhaustive. La clause expresse de la GNU LGPL permettant de contourner le copyleft au profit de la GNU GPL est probablement la plus connue : elle envisage effectivement, en son troisième article, que cette dernière puisse lui être substituée (une telle action étant irréversible).
        126 –	Une solution de compromis. Un autre exemple peut nous montrer la difficulté qu'a pu avoir une nouvelle licence à s'intégrer. Soucieux de proposer une licence compatible, le CEA, le CNRS et l'INRIA rédigèrent une licence conforme au droit français et aux spécificités des administrations : la licence CeCILL. Mais afin de permettre son acceptation par la communauté FLOS — d'autant plus réticente qu'il s'agit d'une licence avec un copyleft fort —, ses auteurs ont décidé in fine de la soumettre à la licence GNU GPL. Si nous apprécions le souci de compatibilité, nous déplorons la limitation ainsi apportée aux acquis qui étaient les siens, ainsi que la perte de crédibilité qui s'en est suivie. Ces clauses de compatibilité sont à manier avec prudence et intelligence, et c'est pour cette raison que nous les conseillons au sein des familles de licences ou de licences copyleft basées sur les mêmes droits et obligations.
	De très bons exemples d'utilisation se retrouvent au sein de la famille des licences GNU (GNU LGPL et GNU GPL) et CeCILL (CeCILL, CeCILL-B et CeCILL-C).
        127 –	Des compatibilités différentes. Deux principales techniques nous semblent devoir être mises en avant : Les clauses actives qui permettent de licencier l'œuvre lors de sa redistribution sous une licence différente, et les clauses passives qui envisagent la compatibilité différemment : en cas de cumul avec certaines autres licences, elles limitent ou excluent une partie de leurs obligations pour se rendre compatibles.
B. 	La modification de la licence à l'aide d'une exception
        128 –	Une rédaction délicate. Le principe est ici de restructurer une licence en lui adjoignant, dès la première distribution de l'œuvre, une exception qui modifie sa portée. Il est nécessaire d'être prudent dans son élaboration, cette technique étant susceptible de ne pas conserver de compatibilité avec la licence préexistante suivant l'usage qui en est fait. Elle se rapproche par ailleurs des interprétations qui peuvent être faites à la licence, à la différence que celles-ci tendent à modifier les critères subjectifs, propres à précisions, là où les exceptions portent principalement sur les critères objectifs. Nous renvoyons le lecteur au développement qui fut écrit sur la théorie des ensembles pour préciser rapidement que si l'exception ne fait que rajouter des droits ou réduire des obligations, alors, l'ensemble « licence plus exception » envisagé comme un tout est une licence compatible avec la licence d'origine, par hypothèse plus restrictive. Dans le cas contraire, le résultat est à bannir, puisqu'il rajoute une licence copyleft quasi identiques à celle d'origine mais incompatible avec cette dernière.
        129 –	Des résultats excellents. Cette pratique des exceptions permet d'adapter une licence à un logiciel spécifique, pour ses développeurs ou ses utilisateurs. Linus Torvalds utilisa ce procédé pour encourager le développement de logiciels sur son système d'exploitation. Cette exception permet de réduire efficacement la portée d'un copyleft, en lui fixant une étendue différente ou en excluant plusieurs logiciels — ou une catégorie entière — de celle-ci.
        130 –	Une nouvelle existence pour la GNU LGPL ? Ayant pu, in extremis, prendre connaissance du projet de la troisième version de la GNU LGPL, il convient d'en dresser un rapide tableau : celle-ci perd son autonomie vis-à-vis de la GNU GPL en devenant une sorte d'« exception d'utilisation » puisqu'elle se greffe sur cette dernière pour lui apporter des droits supplémentaires. Cette modification, si elle est conforme aux volontés dernières de la FSF de restreindre son utilisation, retire à la GNU LGPL sa qualité de licence autonome en n'en faisant qu'une exception susceptible. Par ce biais, tout licencié peut y renoncer librement lors d'une éventuelle redistribution, démarche donc défavorable à un maintien sous LGPL où le licencié devait faire la démarche active de changer la licence. Par ailleurs, ce projet semble éloigner cette version des précédentes, ce qui est pourtant contraire à la limite qui peut être opposée à la FSF quant à la création de nouvelles versions.
C. 	Les multilicenciements
        131 –	Une technique simple et efficace. Contrairement à ce que beaucoup semble croire, le multilicenciement se trouve être une technique simple et efficace. Il consiste pour le(s) titulaire(s) des droits à consentir plusieurs licences non exclusives sur une même œuvre : technique habituelle au sein des licences classiques que rien n'interdit de transposer aux licences FLOS, pour les cumuler ou les rendre alternatives.
        132 –	Le cumul de plusieurs licences FLOS. Nous parlons ici de cumul en ce que les droits conférés par chaque licence s'ajoutent au profit du licencié, celui-ci pouvant utiliser ses droits en conformité à l'une ou l'autre des licences. Plusieurs avantages peuvent être mis en avant :
	Le contenu sous licence est dès lors compatible avec la totalité des licences qui lui sont adjointes, auxquelles se rajoutent les licences avec lesquelles elles sont déjà elles-mêmes compatibles. Malgré sa précarité, le dispositif assure donc une meilleure compatibilité. En effet, une faille existe cependant : si des contributions lui sont apportées sous l'une seule des licences, alors l'œuvre nouvelle devra limiter sa licence à celle-ci seule. Ainsi, un tel mécanisme n'est viable qu'autant que l'ensemble des contributions se fasse sous licence multiple, quitte à ce que le donneur de licence s'inspire d'éventuelles contributions ultérieures pour les réécrire lui-même dans son œuvre.
	Le licencié dispose de beaucoup plus de droits dès lors qu'ils sont contenus dans au moins une des licences, même s'il est souvent adjoint d'une obligation et qu'il faut alors se conformer à celle-ci pour disposer du droit.
        133 –	L'inutilité de certaines licences multiples. Par soucis de compatibilité, certains développeurs ont tendance à cumuler les licences pour un même projet. Aussi louable que soit l'intention, une simple analyse logique nous permet d'affirmer que les licences multiples sont véritablement utiles que si elles permettent d'associer plusieurs licences qui sont originairement incompatibles. Dans le cas contraire, la licence compatible « contenant » déjà la seconde licence, la réunion des deux ne confère ainsi aucune prérogative spéciale au licencié : la réunion d'un ensemble avec un autre qui lui est inclus est égale au premier ensemble.
	L'atout des licences multiples est en revanche indéniable lorsqu'il s'applique à plusieurs licences incompatibles tendant au même but. Les communautés peuvent alors ajouter leur force pour développer un logiciel en commun, le travail de l'une profitant à l'autre : c'est en quelque sorte un retour aux sources du libre, en construisant des ponts pour relier deux communautés qui se sont éloignées.  
        134 –	Le cumul de licence FLOS et non-FLOS. Différent mais impossible à passer sous silence, le cumul de licences FLOS et non-FLOS tend à se multiplier grâce au succès remporté par quelques grandes entreprises conceptrices de logiciels. La technique consiste à allier les atouts des licences libres pour permettre le développement des logiciels, tout en proposant aussi des licences commerciales à ceux qui désirent dépasser les limitations et obligations des licences FLOS. S'il y en a trois sociétés à citer, ce serait : MySQL AB, Sleepycat Software Inc. et TrollTech AS. MySQL AB est récemment passée de la GNU LGPL à la GNU GPL. Loin d'être neutre, ce changement de licence revient à imposer à tout programme auparavant non soumis à la GNU LGPL de se soumettre à la GNU GPL s'il désire bénéficier des versions postérieures. Dès lors, les titulaires de logiciels propriétaires acquièrent des licences commerciales pour échapper à la réciprocité. D'un autre côté, la licence envisage une exception spéciale à la GNU GPL : l'exception FLOSS, qui permet aux autres logiciels FLOS de se lier au programme sans avoir à passer en GNU GPL, ce qui aurait posé problème dans le cas de licences incompatibles. Bénéficiant d'un produit libre, la communauté FLOS permet le débogage du logiciel, ainsi que la soumission de contributions, intégralement réécrites par MySQL. Titulaire de l'ensemble des droits sur son œuvre, elle peut conserver la double licence, et de cette façon les partisans de systèmes propriétaires bénéficient, mais pas indûment — car sous forme de licence commerciale, permettant de financer d'autres contributions — d'un logiciel performant. Sleepycat Software Inc. développe pour sa part BerkleyDB (BSB), sous une licence spécifique qui ne permet son usage libre que si les logiciels l'utilisant distribuent aussi leur code source. L'utilisation de la double licence GNU GPL/QPL pour la bibliothèque TrollTech AS ne nécessite pas plus de développement, le fonctionnement étant toujours le même.

Tableau 3: Différentes techniques appliquées à une même licence 1 (Copyleft fort)
Section II - 	Quelques pistes de réflexion sur les incompatibilités entre licences
        135 –	Une conséquence logique de l'étude. Une telle étude ne peut pas s'achever — surtout lorsqu'elle consiste à mettre en évidence des problèmes — sans que soient suggérées quelques pistes sur les remèdes propices à aider la communauté FLOS à surmonter les difficultés que nous présentâmes. Nous allons ainsi discuter les points permettant de prévenir les incompatibilités entre licences (I), ou de les résoudre (II).
I - 	Quelques considérations permettant de prévenir les incompatibilités entre licences
        136 –	Des solutions tirées de l'étude. L'examen réalisé sur les incompatibilités et leur origine permet de tirer quelques enseignements utiles à une meilleure compatibilité : la nécessité de favoriser le cumul entre licences FLOS grâce à une unification des termes (A), et leur coexistence grâce à une réduction de la portée des licences copyleft (B).
A. 	Une unification des termes pour une simplification du cumul
        137 –	L'absence d'un développement coopératif pour les licences. La situation peut sembler paradoxale si l'on compare le développement des œuvres au sein des communautés FLOS à celui de leur licence. Le premier est un exemple de transparence, discussion, et débogage, alors que le second n'est souvent que le résultat d'une concertation en un groupe restreint, ne prenant en compte ni licences préexistantes, ni éventuels commentaires qui pourraient lui être adressés.
        138 –	Le choix des termes de la licence. Les licences seraient beaucoup plus simples à comprendre pour les développeurs et les juristes si elles parvenaient à utiliser un vocabulaire commun, et non des définitions différentes pour des termes identiques ou des termes identiques pour des définitions différentes. Il est parfois navrant de voir de nouvelles licences s'inspirer de vieilles licences maladroites ou imprécises, plutôt que d'autres plus récentes et mieux écrites. Nul doute que le principal obstacle à l'usage de la théorie des ensembles telle que nous l'avons présentée est celui de la disparité des termes : comment savoir si un droit et son obligation sont repris tels quels par une licence lorsque leurs rédactions sont différentes ? En effet, pour être certain de la compatibilité, il faudrait réécrire une licence compatible pour chaque nouvelle œuvre dérivée, ce qui s'éloigne de l'objectif d'une compatibilité étendue. Ainsi, une formulation identique pour les mêmes droits et obligations dans chaque licence rendrait alors leur compréhension plus rapide et leur compatibilité beaucoup plus simple : uniquement logique et mathématique.
B. 	Une réduction de la portée des licences copyleft pour favoriser la coexistence entre licences FLOS
        139 –	Supprimer la crainte de l'appropriation au sein de la communauté FLOS. Le copyleft est sans conteste d'une utilité et d'une efficience sans égale pour s'assurer de la liberté d'une oeuvre. Mais son application, si elle empêche d'utiliser des licences propriétaires, fait obstacle à toute utilisation conjointe avec d'autres licences FLOS qui ne seraient pas compatibles. Si ce mécanisme ne présentait originairement pas de défaut majeur lorsque n'existait qu'une licence copyleft, son maintien en l'état est aujourd'hui extrêmement préjudiciable au développement coopératif depuis que d'autres licences FLOS ont pris le même credo. Il est impossible de nier qu'il était auparavant opportun de faire « feu de tous bois » sur les autres licences — alors toutes propriétaires —, mais la logique doit être revue quand d'autres licences garantissent elles-mêmes les quatre libertés fondamentales à l'utilisateur. Il est inutile de vouloir rendre libre une œuvre qui l'est déjà, et à partir de là, il n'y a pas de raison objective de préférer une licence à une autre. Les intérêts de chacune, que ce soit l'ouverture du code ou la liberté des utilisateurs, devraient à notre avis conduire à une plus grande tolérance lorsqu'ils peuvent aussi être atteints par une autre licence. Le cloisonnement ainsi effectué peut économiquement être qualifié de sous-optimal en ce qu'il divise ces mêmes travaux contributifs qui faisaient la force du développement FLOS.
        140 –	L'exemple de l'exception FLOS de MySQL. L'exception de MySQL nous semble être un exemple parfait de clause qui pourrait s'insérer au sein d'autres licences FLOS. Par ce stratagème, la licence conserve un copyleft fort à l'encontre des développeurs propriétaires, mais ne soumet qu'à un simple copyleft standard les logiciels sous licence FLOS. Cette technique qui consiste ponctuellement à réduire l'application du copyleft nous semble être un accommodement heureux puisqu'il permet de préserver la compatibilité de la licence à l'égard de la myriade de licences FLOS embrassée par la GNU GPL classique. L'inclusion systématique de cette exception dans chaque licence disposant d'un copyleft fort permettrait à coup sûr l'essor de nombreux projets, jusqu'alors bloqués par ces incompatibilités. Ce procédé ne doit pas s'étendre aux licences disposant d'un copyleft standard, car elles permettent déjà l'utilisation conjointe de licences, et qu'il n'abouterait qu'à affaiblir la licence à vis-à-vis de licences à copyleft fort qui n'auraient pas opté pour l'exception. 
        141 –	L'exemple du brouillon de la GNU GPL v3. La clause de compatibilité envisagée par la GNU GPL v3 doit être envisagée dans ces deux brouillons consécutifs :
	Draft 1- L'article 7 du brouillon de la GNU GPL v3 autorise les contributeurs, auteurs de code soumis à la licence GNU GPL, à utiliser certaines licences plus restrictives que la GNU GPL : en joignant une simple exception, ou en reprenant une licence identique à laquelle se rajoutent ces obligations. Cette clause « lève » le copyleft au contact d'autres licences plus strictes, pour en faire une licence compatible. En soi, cette clause semble être une bonne chose puisqu'elle permet notamment le cumul avec des licences comme l'Affero General Public License, ou la licence Apache. Malheureusement, on se rend compte que cette technique permet uniquement d'utiliser des licences durcies, calquées sur la GNU GPL. Surtout, la GNU GPL envisage que ces codes ne seront soumis à cette exception qu'autant qu'ils ne sont pas modifiés et remplacés par de nouveaux, c'est-à-dire que la GNU GPL v3 refuse même un simple copyleft standard à ces contributions.
	Draft 2- L'article 7, nommé « 7. Additional Terms. », paraît beaucoup plus intéressant. Il envisage l'ajout de droits et d'obligations, les droits n'étant pas limités tandis que les obligations sont limitativement énumérées. La technique décrite par la suite quant à l'évolution de ces exceptions est conforme à notre règle des ensembles, en fixant un minimum qui est celui de la licence GNU GPL. Pour conclure, la compatibilité semble s'envisager dans des expressions de plus en plus efficaces, mais n'est pas réellement atteinte ici puisqu'elle ne l'est que pour certaines licences permissives ou compatibles avec la GNU GPL qui contiendraient des obligations supplémentaires (Apache, Eclipse, AGPL, etc.). Les deux dispositions ne sont finalement que deux expressions d'une même idée, sûrement plus complète dans le second brouillon.
II - 	Quelques procédures permettant de résoudre les incompatibilités entre licences
        142 –	Une démarche qui prend du temps. Contrairement à une modification des licences avec un copyleft fort par leur auteur, d'autres solutions plus longues existent. Les auteurs et développeurs de logiciels FLOS peuvent parvenir à unifier les différentes communautés s'ils créent suffisamment de ponts pour que n'existe aucun clivage. À cette fin, une méthode emporte notre préférence, qui est de licencier avec une meilleure gestion des compatibilités (A), et, pour faciliter cette entreprise, regrouper l'ensemble des acteurs concernés au sein d'une seule communauté FLOS (B).
A. 	Inciter à une meilleure gestion des compatibilités par les donneurs de licences
        143 –	Forcer le cumul grâce au multilicenciement. Il s'agit en réalité d'aménager, voire forcer, un cumul dès la soumission originelle aux multiples licences FLOS. La compatibilité d'une œuvre sous licence multiple est assurée puisqu'elle peut être reprise sous l'une des licences qui la composent, et ceci, plus sûrement qu'avec n'importe quelle clause de compatibilité. De plus, le multilicenciement permet de limiter le copyleft global qui s'applique à l'œuvre par cela même que, le licencié pouvant utiliser tout droit compris dans l'une au moins des licences, ce sont les dispositions de la licence la plus permissive qui l'emportent. Aussi, si l'une des licences devait être annulée par une juridiction nationale, le licencié pourrait toujours revendiquer les droits conférés par l'autre. Pour finir, cette stratégie — à laquelle certains pouvaient préférer une licence très permissive comme la licence BSD — à l'avantage de cumuler copyleft et compatibilité. 
        144 –	Les atouts des exceptions FLOS. Le rappel est ici rapide et ciblé, la technique ayant déjà été examinée. Ce qu'il faut comprendre, c'est la nécessité d'une coexistence des licences, et si celle-ci peut être envisagée grâce à un cumul ab initio de plusieurs licences, elle peut aussi consister à aménager la coexistence ab initio de ces licences. L'essentiel est dans les deux cas de prévenir toute incompatibilité future. La généralisation d'une sorte d'exception FLOS, part laquelle la licence avec un copyleft diminuerait celui-ci à l'égard des autres licences, permettrait d'assurer une appréhension paisible des licences au sein des communautés et agressive à l'extérieur.
        145 –	Une utilisation massive. Pour avoir un impact, nous conseillons de multiplier ces dispositions. Utiliser doubles, triples et quadruples licences lorsque chacune d'elle est incompatible avec les autres, ou bien encore aménager leur compatibilité. Au lieu d'hésiter entre deux licences copyleft : choisir les deux. Et dans tous les cas où l'on choisit une licence copyleft quelconque, lui adjoindre toutes les autres licences copyleft similaires au moins aussi copyleft. Ainsi, l'étendue du copyleft global n'en sera pas affectée, mais la compatibilité s'en trouvera grandement renforcée. Pour ceux que la complexité effraie, la procédure est identique à toute licence : pour le multilicenciement, indiquer dans l'en-tête des fichiers les licences auxquelles ils sont soumis et distribuer l'ensemble des licences avec les codes sources, et simplement adjoindre l'exception à la licence. Un simple fichier texte expliquant les avantages des multilicenciements devrait permettre aux licenciés de comprendre ses droits et obligations. De plus, la compatibilité comme envisagée par le GNU GPL est d'ores est déjà plus complexe, pour un effet plus limité...
        146 –	Le rôle des contributeurs. Si ce sont les auteurs qui choisissent initialement les licences, ce sont les contributeurs qui les maintiennent en participant sous ces mêmes licences. C'est la raison pour laquelle cette méthode peut ne pas sembler viable, les projets sous licences multiples voyant très rapidement leurs licences se réduire en incorporant d'autres éléments sous licence simple. L'exemple de la licence BSD, compatible avec tous, mais utilisée pour des projets entiers, nous fournit un premier contre exemple. Ensuite, si nous prônons le multilicenciement, nous sommes bien conscients que de nombreuses situations limiteront cette possibilité et replongeront les projets au coeur du problème des incompatibilités. Malgré cela, en utilisant une telle licence multiple tant que cela est possible, l'accumulation de contenu sous licences multiples permettra in fine de construire des projets entiers sur ce modèle. Ces projets sont d'autant plus ambitieux qu'ils pourront ensuite être repris pas l'ensemble des communautés, les incitant dès lors à proposer aussi leurs contributions sous de multiples licences. Au bout du compte, un tel regroupement des licences pourra ne plus être utile, lorsque l'ensemble des codes sera compatible. Il sera alors temps de supprimer toute licence inutile, au besoin en modifier des existantes, pour maintenir ce système de développement plus vaste et moins divisé : regrouper les forces pour mieux les canaliser.
	Un premier argument qui pourrait nous être opposé est la complexité de l'entreprise proposée, ce à quoi nous répondrons que les efforts nécessaires à l'harmonisation de la compatibilité sont autrement moins importants que ceux dépensés à recréer ce qui existe déjà. De plus, une plus grande coexistence des licences risque effectivement de mettre en exergue l'hétérogénéité des licences, mais ce problème était jusque-là latent, l'opération permettant peut-être d'en sensibiliser les rédacteurs. L'ouvrage principal sera de conscientiser les utilisateurs et licenciés, par un travail de synthèse et surtout de transparence autour des licences existantes, pour qu'ils comprennent l'intérêt de disposer d'une communauté FLOS vraiment large.
B. 	Le regroupement dans une communauté unique plus vaste
        147 –	Un regroupement centré sur les licences. Il ne s'agit pas en premier lieu de demander à l'ensemble des communautés FLOS de travailler ensemble, mais seulement de leur donner les outils pour le faire. La licence est en effet le principal instrument à la disposition du développeur pour permettre la circulation et l'évolution du développement de son œuvre au sein d'une communauté FLOS. Il suffit donc de lui fournir des instruments efficaces. L'initiative proposée consiste à favoriser les échanges entre les auteurs de licence des diverses communautés afin de leurs permettre l'harmonisation des rédactions de licence, et surtout de mettre en place un schéma clair et simple de compatibilité entre les licences afin que les licenciés sachent exactement quelles licences valablement employer. Pour ceci, un simple listing de l'ensemble des licences, de la compatibilité de chacune d'elle avec les autres licences, devrait suffire. Ce regroupement pourrait aussi, dans la ligne directrice du point précédent, proposer des paquets de licence aux développeurs en indiquant les droits et obligations finalement contenus. De même, une autre idée, loin d'être incongrue et à notre avis intéressante, consisterait à chercher à créer un consensus sur le vocabulaire et les définitions des licences. Ceux-ci seraient ainsi plus précis et fiables, et surtout assureraient une compatibilité beaucoup plus facile entre des licences qui — tout en restant distinctes — ont opté pour cette uniformisation. Ces initiatives donneraient un élan fort au mouvement d'harmonisation autour d'une compatibilité des licences.
	De surcroît, il serait intéressant de permettre que le dialogue entre ces protagonistes aboutisse à la rédaction collaborative de nouvelles licences, ainsi qu'à une discussion sur des sujets primordiaux comme la définition du libre face au développement des moyens de communication et de l'informatique. Il serait en effet inutile d'essayer de standardiser des définitions dépassées et de ne pas prendre en compte les évolutions futures. Ce serait sans aucun doute un gage de crédibilité et de prévisibilité qui rejaillirait forcément sur les communautés FLOS dans leur ensemble.

        148 –	Conclusion de Chapitre. Pour conclure, voici en quelques phrases les notions clés soulevées dans le chapitre précédent :
•	Dans l'hypothèse où plusieurs licences viennent à se cumuler pour la création d'une œuvre dérivée, le licencié doit impérativement respecter chacune d'entre elles.
•	La combinaison de multiples licences — ou les exceptions à celles-ci — sur une même œuvre peut être envisagée telle une licence globale reprenant tous les droits et obligations. C'est sur celle-ci qu'il faut se baser pour déterminer la compatibilité.
•	Une licence A est dite compatible avec une licence B dès lors qu'elle permet la reprise de l'œuvre A sous la licence B. La compatibilité peut être logique ou contractuelle.
•	La compatibilité est dite logique lorsque l'ensemble des droits accordés par une licence est inclus dans l'ensemble des droits conférés par une deuxième, et que l'ensemble des obligations imposées par cette dernière est inclus dans l'ensemble des obligations imposées par la première.
•	La compatibilité est dite contractuelle lorsqu'elle est expressément prévue dans la licence ou peut lui être rattachée : par une clause expresse de compatibilité, une exception, une interprétation adjointe à la licence, ou grâce à une licence multiple.
•	Dans l'hypothèse d'une licence multiple, le licencié dispose de tout droit conféré par l'une au moins des licences.
•	Les principaux facteurs d'incompatibilité sont un copyleft trop fort vis-à-vis des autres licences FLOS, et une absence de concertation entre les rédacteurs de licences.
•	Une utilisation massive des exceptions FLOS sur les licences disposant d'un copyleft fort, des licences multiples et une uniformisation mesurée des termes employés assureraient une meilleure compatibilité entre les licences FLOS.	

Table des matières
Introduction	5
Section I - Appréhension juridique du contrat de licence FLOS	8
I - Un contrat de mise à disposition distinct du contrat de licence 	9
II - Une licence FLOS, un contrat de cession non exclusive de droit d'auteur  	10
Section II - Les différentes licences FLOS	11
I - L'approche historique de la notion de licence FLOS	12
II - L'approche classique des licences FLOS	13
Section III - Les conflits au sein des licences FLOS	14
I - Une absence de cohésion globale	14
II - Un contexte néfaste au développement de la communauté FLOS	15
Partie I - Une compatibilité classique lors de la coexistence des contrats	17
Chapitre I - La notion de distribution comme point de départ à l'effet des contrats	17
Section I - La notion de distribution comme envisagée par les licences FLOS	18
I - La préservation d'un double intérêt lors de la distribution	18
A. Un intérêt double	18
B. La notion de distribution envisagée par les licences FLOS	19
II - Le contournement des licences sous couvert de non-distribution	20
A. Une utilisation sans distribution grâce au réseau	20
B. Les répercussions sur les nouvelles licences : la licence Affero General Public License (AGPL), la Gnu GPL v3 et l'Open Software License	21
Section II - Les effets contraignants des licences FLOS déclenchés par la distribution	23
I - La pleine application des licences lors de la distribution de l'œuvre licenciée	24
A. Les effets des licences permissives à l'égard du licencié	24
B. Les effets propres aux licences copyleft à l'égard du licencié	24
II - La distribution d'une « œuvre de compilation »	25
A. Le cumul des obligations de chaque licence	25
B. La distribution d'œuvres indépendantes et séparées formant un tout	27
Chapitre II - La notion d'« œuvre dérivée » comme dernière limite à l'effet des contrats	28
Section I - La notion d'« œuvre dérivée » comme envisagée par les licences FLOS	29
I - Un mécanisme identique pour la détermination de l'« œuvre dérivée »	29
A. Une analyse légale de la notion d'« œuvre dérivée »	29
B. La sanction pour le non-respect des conditions associées aux licences	30
II - Une absence de consensus sur le champ adapté de l'« œuvre dérivée »	30
A. Une délimitation hétérogène de l'« œuvre dérivée » au sein des licences FLOS	31
B. La valeur légale d'une définition contractuelle de l'« œuvre dérivée »	32
Section II - Les confrontations entre licences lors de la création d'une « œuvre dérivée »	33
I - La prise en considération de l'œuvre et de son support	34
A. Prise en compte du caractère fictif du numérique	34
B. Une cloison finalement peu fiable	36
II - Les critères de détermination du rattachement à une œuvre dérivée	36
A. Les critères utilisés par les licences FLOS	37
B. Les résolutions de conflits complexes	38
Partie II - Une compatibilité spéciale lors du cumul des contrats	42
Chapitre I - La technique logique pour déterminer la compatibilité d'une licence	42
Section I - Une licence compatible accordant au moins autant de droits que la licence absorbante	43
I - Les fondements de cette règle	43
A. La distribution de droits et la théorie des ensembles	44
B. La compatibilité, un pouvoir de rendre moins libre ?	44
II - Transposition pratique de la théorie des ensembles	45
A. Les droits d'auteur sur l'œuvre	45
B. Les droits sur les brevets	46
C. La garantie offerte au licencié	46
Section II - Une licence compatible n'imposant pas plus d'obligations que la licence absorbante	47
I - Les fondements de cette « règle »	47
A. La théorie des ensembles appliquée aux obligations des licences, un versant miroir de son application aux droits ?	47
B. Les obligations comme source d'incompatibilité	48
II - Transposition pratique de la théorie des ensembles	48
A. Les obligations de faire au sein des licences	49
B. Les obligations de ne pas faire au sein des licences	49
C. Les obligations de donner au sein des licences	50
Chapitre II - Les techniques contractuelles pour ajuster la compatibilité d'une licence	50
Section I - Les techniques actuellement utilisées pour résoudre les conflits entre licences	51
I - La résolution de problèmes de compatibilité lors de leur survenance 	51
A. La difficulté pour joindre l'ensemble des titulaires de droit	51
B. La résolution des problèmes de compatibilité par la conclusion d'un compromis avec le donneur de licence	52
II - Les techniques contractuelles assurant ab initio la compatibilité entre licences	53
A. Les clauses expresses de compatibilité	54
B. La modification de la licence à l'aide d'une exception	54
C. Les multilicenciements	55
Section II - Quelques pistes de réflexion sur les incompatibilités entre licences	58
I - Quelques considérations permettant de prévenir les incompatibilités entre licences	58
A. Une unification des termes pour une simplification du cumul	58
B. Une réduction de la portée des licences copyleft pour favoriser la coexistence entre licences FLOS	59
II - Quelques procédures permettant de résoudre les incompatibilités entre licences	60
A. Inciter à une meilleure gestion des compatibilités par les donneurs de licences	60
B. Le regroupement dans une communauté unique plus vaste	62
Bibliographie	66
Annexes	72
Licences de contenu	98

Bibliographie
•	

➢	Mémoires	66
➢	Manuels, traités, précis, mémentos et ouvrages divers	67
➢	Articles, chroniques, communications à des colloques	67
➢	Études, rapports, conférences	69
➢	Internet @	69
➢	Licences 	70
➢	Wiki	71
➢	Mailling List 	71

    Cette bibliographie se veut volontairement plus complète que celle qui fut indiquée lors des développements. Elle se compose en effet de l'ensemble des lectures que nous fîmes pour appréhender la matière. Du fait de la spécificité de celle-ci, nous conseillons fortement à toute personne travaillant avec de telles licences de se plonger dans ces milliers de pages ; celles-ci constituent une part essentielle de la littérature relative au libre en général.
   De nombreux documents référencés sont en langue anglaise, l'explication vient de ce que les licences étant elles-mêmes souvent uniquement en cette langue – du moins dans leur version 'officielle' - et la doctrine américaine étant souvent plus avancée sur les questions de licences FLOS, il est nécessaire de s'y intéresser.

•	Mémoires :
•	BOYER (Antoine), Étude du cyber-Mouvement du Logiciel Libre, Mémoire de Recherche en Science Politique, sous la direction de Monsieur Paul Alliès, 2003.
•	Clément-Fontaine (Mélanie), La Licence Publique Générale, mémoire de DEA sous la direction de Monsieur le Professeur Michel Vivant, Montpellier I / CNRS , 1999.
•	DI FILIPPO (Eric), LES LOGICIELS LIBRES, UNIVERSITE DE NICE-SOPHIA ANTIPOLIS, DEA DE DROIT ECONOMIQUE ET DES AFFAIRES, Mémoire sous la direction de Mme le Professeur Geneviève Gourdet, Présidente de l’Université de Nice-Sophia Antipolis, 1998-1999.
•	JOCQUEL (Grégoire), Les licences libres en droit français - Analyse comparée CeCILL — GNU GPL, DESS de Droit du Numérique et des Nouvelles Techniques Université Paris I Panthéon — Sorbonne / Université Paris XI Sud, Mémoire réalisé sous la direction du Doyen Pierre SIRINELLI , Septembre 2004.
•	LAFOND (Thierry) et TIAINEN (Miia),  La problématique juridique du logiciel libre, AUBERT DU E-COM, 2003.
•	LACKER (Julien), Les oeuvres en ligne en droit comparé : droits américain et français, Mémoire réalisé sous la direction du Professeur Pierre SIRINELLI, D.E.S.S. Droit du Numérique et des Nouvelles Techniques, Mai 2003.
•	Laurent (Philippe), Logiciels libres: "Le droit d'auteur contre le droit d'auteur", V.A.O. in intellectuele rechten, 2003.
•	Leclerq (Nicolas), Logiciel libre : une volonté de transparence, 1999.
•	LINSOLAS (Julien), « Le logiciel libre », mémoire DESS Droit du Numérique et des Nouvelles Techniques, Universités Paris I / Paris XI, 2002.
•	SOUFRON (Jean-Baptiste), « La Licence Publique Générale : un système original de protection juridique pour les créations issues des systèmes de développement coopératifs », mémoire DESS Multimédia et Systèmes d’Information, Université Strasbourg III, février 2002. 
•	 Manuels, traités, précis, mémentos et ouvrages divers :
•	Cool (Yorick), de PatouL (Fabrice), de Roy (David), et al., Les logiciels libres face au droit, Namur ; Bruxelles : Facultés universitaires Notre-Dame de la paix : Bruylant, 2005.
•	LUCAS (Andre), DEVEZE (Jean), FRAYSSINET (Jean), Droit de l'informatique, puf, 2001.
•	Smets-Solanes (J.P.) et Faucon (B.), Logiciels libres, Liberté, égalité, business, 1999 .
•	Välimäki (Mikko), The Rise of Open Source Licensing : A Challenge to the Use of Intellectual Property in the Software Industry, Turre Publishing, 2005, CC by-sa-nd 2.0.
•	Vivant (Michel), Le Stanc (Christian), et al., Lamy droit de l'informatique et des réseaux, éd 2005.
•	 Articles, chroniques, communications à des colloques :
•	Arief (Budi), Gacek (Cristina), Lawrie (Tony), « Software Architectures and Open Source Software », 2001.
•	Bailly (Yannick), « La protection juridique des logiciels libres », Droit technologie, http://www.droit-technologie.org , 16 Février 2000;
•	Brendan (Scott), « The Open Source Legal Landscape », www.opensourcelaw.biz, mars 2006.
•	Caron (Christophe), « Les licences de logiciels dits « libres » à l'épreuve du droit d'auteur français », Dalloz 2003, chron., p.1556.
•	Chang (Sau Sheong), « Copyright and Open Source Software Licensing », ExpressO Preprint Series, 2005.
•	Clément-Fontaine (Mélanie), « Les licences Creative Commons chez les Gaulois », RLDI 2005, 1, n° 20, p.33.
•	Dizon (Bong), « FOSS Charter Change ; Revising the Gnu GPL ».
•	Dulong de Rosnay (Mélanie), « Le partage créatif, un système de gouvernance de la distribution d'oeuvres en ligne », RLDI 2005, 2, n° 59, p.35.
•	Egret (Benjamin), Kaplun (Yasmine), « La nécessaire interprétation des licences relatives aux logiciels libres », RLDI 2006, 12, n° 265, p.51.
•	Franz (Michael), « Dynamic Linking of Software Components », IEEE Computer, (March 1997).
•	Gaudillère, Pascal, « Licences de logiciels libres et risques juridiques », Comm. com. électr. 2005, 4, Étude, n° 16.
•	Gomulkiewicz (Robert W.),
•	« De-bugging Open Source Software Licensing », UNIVERSITY OF PITTSBURGH LAW, REVIEW 75, 2002 ;
•	« GENERAL PUBLIC LICENSE 3.0: HACKING THE FREE SOFTWARE MOVEMENT’S CONSTITUTION ».
•	Guadamuz (Andres), « GNU General Public License v3: A Legal Analysis », SCRIPT-ed, Vol. 3, No. 2, 2006.
•	Jones (P), « The GPL Is a License, not a Contract », Linux Weekly News, 3 décembre 2003.
•	Jullien (Nicolas), Zimmermann (Jean-Benoît), «Le logiciel libre: une nouvelle approche de la propriété intellectuelle», Revue d'économie industrielle 2002, 99.
•	Le Crosnier Hervé, Le modèle du logiciel libre peut-il s’étendre aux autres activités intellectuelles ?, Sommet mondial de la société de l’information, 2003, disponible à http://vecam.org/article.php3?id_article=267.
•	Lerner (Josh), Tirole (Jean) , « The Scope of Open Source Licensing ».
•	Macrez (Franck), Rivière (Raphaël), « Les logiciels libres, l'administration et les marchés publics», Revue Lamy Droit de l'Immatériel, mai 2006.
•	Madison (Michael J.), « Reconstructing the Software licence », Loyola University Chicago Law Journal, Vol. 35, No. 275, 2003.
•	MAY (Benjamin), « Contrats informatiques : gare au charivari des licences de logiciel », JCP Aff., 3 juin 2004, n°23, p. 900.
•	McGowan (David), « Legal Implications of Open-Source Software », 2001 U. Ill. L. Rev. 241 (2001).
•	Metzger (Axel), Jaeger (Till), « Open source software and German copyright law », International Review of Industrial Property and Copyright Law, 32(1):52-74, 2001.
•	Murray (Gwyn Firth), Duncheon (Michael A.), « FREE AND OPEN SOURCE SOFTWARE:AN INTRODUCTION », Janvier 2006.
•	Nichols (David) ; Twidale (Michael), « Usability and Open Source Software », Decembre 2002.
•	Raymond (Eric Steven),
•	« The Magic Cauldron », http://www.catb.org/~esr/writings/cathedral-bazaar/magic-cauldron/, juin 1999 ;
•	« Homesteading the Noosphere », http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading , 21 novembre 1998 ;
•	« The Cathedral and the Bazaar », http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar, 21 novembre 1998.
•	ROSSI (MARIA ALESSANDRA), « Decoding the “Free/Open Source (F/OSS) Software Puzzle”a survey of theoretical and empirical contributions », Università degli Studi di Siena DIPARTIMENTO DI ECONOMIA POLITICA, n. 424, Avril 2004.
•	Rosen (Lawrence E.),
•	« Open Source Licensing : Software Freedom and Intellectual Property Law », Upper Saddle River, N.J. : Prentice Hall PTR (2004), pp. 59-66 ;
•	« Derivative Works », 2002.
•	SACEM, « Les Creative Commons », réponse à un questionnaire, Décembre 2004.
•	Stallman (Richard Matthew), « Conférence de RMS », www.linux-france.org/article/these/conf/stallman_199811.html, donnée à Paris-8, 10 novembre 1998.
•	Vercken (Gilles), Vivant (Michel), « Le contrat pour la mise en ligne d'oeuvres protégées : Figures anciennes et pistes nouvelles », Cahiers de droit de l'entreprise (supplément au JCP E) 2000 n° 2 p. 18 (voir 10.).
•	Vetter (Greg), 
•	« The Collaborative Integrity of Open-Source Software », 2004 Utah L. Rev 563 (September 2, 2004)  ;
•	« 'Infectious' Open Source Software: Spreading Incentives or Promoting Resistance? », Rutgers Law Journal, 2004.
•	VIVANT (Michel), « L'informatique dans la théorie générale du contrat », Recueil Dalloz Sirey, 1994, pp. 117-122 ler.
•	Vodjani (Isabelle), « Comparatif de licences libres : Le choix du libre dans le supermarché du libre choix », http://www.transactiv-exe.org/article.php?3id_aticle.php=95, 31 mai 2004.
•	Wéry (Etienne), « Logiciels libres et open source : quelques questions juridiques », http://www.droit-technologie.org
•	Whee (David A.), « Make Your Open Source Software GPL-Compatible. Or Else », 7 April 2004.
•	Yamagata (Hiroo), « Le pragmatiste du logiciel libre : entretien avec Linus Torvalds », traduit par Sébastien Blondeel, www.linux-france.org/article/these/interview/torvalds/pragmatist-fr.html, septembre 1997.
•	 Études, rapports, conférences :
•	ADBS, LES MODÈLES LIBRES POUR L'ACCÈS A L'INFORMATION, Journée du 10 mai 2004 Organisée par la commission « Droit de l’information ».
•	AIGRAIN (Philippe), Un cadre de réflexion pour comprendre l’impact du choix des licences “copyleft” telle que la GPL, par opposition aux licences “non-copyleft”, www.adullact.org, décembre 2002. 
•	Anonyme, 
•	Livret du Libre, 3ème edition, mai 2005 ;
•	Les licences commentées, A.L.L.E.G.E.T.I.C.E, 17 décembre 2002 ;
•	Pratiques en Ligne, CNRS, Formation BAP H Filière Partenariat et Valorisation Caen, 7 au 9 novembre 2005.
•	ATICA, Guide de choix et d’usage des licences de logiciels libres pour les administrations, décembre 2002 ;  Guide de choix et d’usage des licences de logiciels libres pour les administrations : Analyse détaillée des licences, décembre 2002.
•	Devoteam Group et Uperto, Définir une politique open source pour l'entreprise, Livre Blanc, 1r Juillet 2005.
•	Lemyre (Pierre-Paul), Willemant (Richard), Problématiques juridiques des logiciels libres et ouverts : défis et solutions pour le gouvernement du Québec (RESOLL), Rapport de projet, Montréal, Avril 2005.
•	Poupaert (Nathalie), Contrats informatiques : limiter les risques!, Rencontre INFOPOLE, 15 Juin 2005.
•	Revillard (Diane), Diermark, LIVRE BLANC ORGANISATIONS ET LOGICIELS LIBRES, Version 1.0, 6 septembre 2005 .
•	Rowland (Diane), Campbell (Andrew), Supply of Software: Copyright and contract issues, Bileta - 16th BILETA Annual Conference, 9 — 10 Avril 2001, University of Edinburgh, Scotland.
•	Thomas (John R.), Intellectual Property, Computer Software and the open source Movement, CRS Report for Congress, 11 mars 2004.
•	 Internet @ :
•	Bezroukov (Nikolai), Portraits of Open Source Pioneers, http://www.softpanorama.org/People/Stallman/index.shtml, dernière consultation le 22 Juillet 2006.
•	Db4 Object DualLicence, http://db4o.com/community/, dernière consultation le 22 Juillet 2006.
•	debian-legal Summary of Creative Commons 2.0 Licenses, http://people.debian.org/~evan/ccsummary, dernière consultation le 22 Juillet 2006.
•	Définitions du Libre et Copyleft en art, http://wiki.artlibre.org/DefinitionCopyleft, dernière consultation le 22 Juillet 2006.
•	FAQ GPL, http://www.gnu.org/licenses/gpl-faq.fr.html ou http://www.gnu.org/licenses/gpl-faq.html, dernière consultation le 22 Juillet 2006.
•	FAQ CeCILL, http://www.CeCILL.info/faq.fr.html, dernière consultation le 22 Juillet 2006.
•	FAQ Debian, http://people.debian.org/~bap/dfsg-faq, dernière consultation le 22 Juillet 2006.
•	FAQ Creative Commons, http://creativecommons.org/faq, dernière consultation le 22 Juillet 2006.
•	FAQ Gpl-violation, http://gpl-violations.org/faq/sourcecode-faq.html et http://gpl-violations.org/faq/violation-faq.html, dernière consultation le 22 Juillet 2006.
•	FAQ Free Content and Expression Definition, http://freedomdefined.org/FAQ, dernière consultation le 22 Juillet 2006.
•	FAQ Art libre, http://artlibre.org/licence/faq/, dernière consultation le 22 Juillet 2006.
•	FAQ ZPL, http://www.cs.washington.edu/research/zpl/faq/faq.html, dernière consultation le 22 Juillet 2006.
•	FAQ Apache, http://www.apache.org/foundation/faq.html, dernière consultation le 22 Juillet 2006.
•	FAQ MPL, http://geckozone.org/articles/41, dernière consultation le 22 Juillet 2006.
•	FAQ IANG, http://iang.info/fr/faq.html, dernière consultation le 22 Juillet 2006.
•	FAQ La FAQ Debian GNU/Linux, http://www.us.debian.org/doc/FAQ/, dernière consultation le 22 Juillet 2006.
•	FAQ Mozilla, http://www.mozilla.org/faq.html, Dernière consultation le 22 Juillet 2006.
•	FAQ QPL, http://www.trolltech.com/licenses/qpl-annotated, dernière consultation le 22 Juillet 2006.
•	FAQ AGPL, http://www.affero.org/oagf.html, dernière consultation le 22 Juillet 2006.
•	GNU Classpath Exception, http://www.gnu.org/software/classpath/license.html, dernière consultation le 22 Juillet 2006.
•	Kidd (Eric), Why you might want to use the Library GPL for your next library, http://linuxgazette.net/issue38/kidd.html#proprietary, dernière consultation le 22 Juillet 2006.
•	Le Contrat Social Debian, http://www.debian.org/social_contract.fr.html, dernière consultation le 22 Juillet 2006.
•	Libsupc++ exception, http://www.cs.brown.edu/~jwicks/libstdc++/html_user/exception-source.html, dernière consultation le 22 Juillet 2006.
•	Linus, échange mails, http://www.atnf.csiro.au/people/rgooch/linux/docs/licensing.txt, dernière consultation le 22 Juillet 2006.
•	Rosenlaw & Einschlag Technology Law Offices, Derivative Work, http://www.rosenlaw.com/lj19.htm, dernière consultation le 22 Juillet 2006.
•	Simons (Leo), Apache / Gnu, http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200511.mbox/%3C20051117152625.GJ85428@bali.sjc.webweaving.org%3E, dernière consultation le 22 Juillet 2006.
•	Software pluralism +, Technology Primer, http://www.law.washington.edu/lct/swp/Tech/techprimer.html, dernière consultation le 22 Juillet 2006.
•	Software pluralism +, License Type Overview, http://www.law.washington.edu/lct/swp/Law/license.html, dernière consultation le 22 Juillet 2006.
•	Software pluralism +, Derivative Works, http://www.law.washington.edu/lct/swp/Law/derivative.html, dernière consultation le 22 Juillet 2006.
•	The Apache Software Fondation, Apache License v2.0 and GPL Compatibility, http://www.apache.org/licenses/GPL-compatibility.html, dernière consultation le 22 Juillet 2006.
•	The linux-kernel mailing list FAQ, http://www.kernel.org/pub/linux/docs/lkml/, dernière consultation le 22 Juillet 2006.
•	 Licences :
•	Gpl linux, http://www.kernel.org/pub/linux/kernel/COPYING, dernière consultation le 22 Juillet 2006.
•	Brouillons des licences GNU (draft), http://gplv3.fsf.org/, dernière consultation le 30 Juillet 2006.
•	Licences FSF, http://www.gnu.org/licenses/license-list.html, dernière consultation le 22 Juillet 2006.
•	Licences OSI, http://opensource.org/licenses/, dernière consultation le 22 Juillet 2006.
•	Licences free Debian, http://www.debian.org/legal/licenses/index.fr.html, dernière consultation le 22 Juillet 2006.
•	Licences sur Freshmeat, http://freshmeat.net/faq/view/48/, dernière consultation le 22 Juillet 2006.
•	Licences musique-libre, http://www.musique-libre.org/static.php?op=copyleftLicence.html&npds=-1, dernière consultation le 22 Juillet 2006.
•	Comparaison de licences avec la licence IANG, http://iang.info/fr/comparison.html, dernière consultation le 22 Juillet 2006.
•	Licences sur Multimedia Art Research Center & Electronic Laboratories, http://www.mmmarcel.org/marcel/index.php/Contract%20Models, dernière consultation le 22 Juillet 2006.
•	Licences sur Boxon, Des licences libres à foison, http://www.boson2x.org/article.php3?id_article=6, dernière consultation le 22 Juillet 2006.
•	License center, http://www.ifross.de/ifross_html/lizenzcenter-en.html, dernière consultation le 22 Juillet 2006.
•	 Wiki:
•	Jurispedia, http://droit.jurispedia.org/.
•	Le site des commoniens, http://fr.creativecommons.org/wiki/index.php/Accueil.
•	Wikimedia Commons, http://commons.wikimedia.org/wiki/Main_Page.
•	Wikipedia, http://fr.wikipedia.org/wiki/Accueil.
•	Free Content and expression definition, http://freedomdefined.org/Definition.
•	Veni, Vini, Libri, actuellement disponible à l'adresse http://wiki.framasoft.info/VeniVidiLibri/Index et http://vvl.tolosano.info/pmwiki/, accessible dès Août à www.venividilibri.org.
•	 Mailling List :
•	discussion@fsfeurope.org.
•	debian-legal@lists.debian.org.
•	escape_l@freescape.eu.org (fermée depuis début juin 2006, archives toujours disponibles).
•	rescape-l@mail.mekensleep.com.
•	copyleft_attitude@april.org.
•	license-discuss@opensource.org.
•	fsb@crynwr.com.
•	legal@lists.gpl-violations.org.
•	april@april.org.
•	cc-fr@lists.ibiblio.org.
•	cc-community@lists.ibiblio.org.

Annexes

➢	Annexe 1 : GNU Emacs General Public License 	73
➢	Annexe 2 : The Open Source Definition	75
➢	Annexe 3 : Exception à la GNU GPL pour le kernel Linux	78
➢	Annexe 4 : MySQL FLOSS License Exception	79
➢	Annexe 5 : Comparaison des brouillons de la GNU GPL v3	81
➢	Annexe 6 : Brouillon de la LGPL version 3	91
➢	Annexe 7 : Application d'une licence logicielle	93
➢	Annexe 8 : Tableau récapitulatif non exhaustif de licences FLOS	95

GNU Emacs General Public License 

(Clarified 11 Feb. 1988) The license agreements of most software companies keep you at the mercy of those companies. By contrast, our general public license is intended to give everyone the right to share GNU Emacs. To make sure that you get the rights we want you to have, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. Hence this license agreement. 
Specifically, we want to make sure that you have the right to give away copies of Emacs, that you receive source code or else can get it if you want it, that you can change Emacs or use pieces of it in new free programs, and that you know you can do these things. 
To make sure that everyone has such rights, we have to forbid you to deprive anyone else of these rights. For example, if you distribute copies of Emacs, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must tell them their rights. 
Also, for our own protection, we must make certain that everyone finds out that there is no warranty for GNU Emacs. If Emacs is modified by someone else and passed on, we want its recipients to know that what they have is not what we distributed, so that any problems introduced by others will not reflect on our reputation. 
Therefore we (Richard Stallman and the Free Software Foundation, Inc.): make the following terms which say what you must do to be allowed to distribute or change GNU Emacs. 
Copying Policies 
1. You may copy and distribute verbatim copies of GNU Emacs source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each file a valid copyright notice "Copyright 1988 Free Software Foundation, Inc.'' (or with whatever year is appropriate); keep intact the notices on all files that refer to this License Agreement and to the absence of any warranty; and give any other recipients of the GNU Emacs program a copy of this License Agreement along with the program. You may charge a distribution fee for the physical act of transferring a copy. 
2. You may modify your copy or copies of GNU Emacs source code or any portion of it, and copy and distribute such modifications under the terms of Paragraph 1 above, provided that you also do the following: 
- cause the modified files to carry prominent notices stating who last changed such files and the date of any change; and 
- cause the whole of any work that you distribute or publish, that in whole or in part contains or is a derivative of GNU Emacs or any part thereof, to be licensed at no charge to all third parties on terms identical to those contained in this License Agreement (except that you may choose to grant more extensive warranty protection to some or all third parties, at your option). 
- if the modified program serves as a text editor, cause it, when started running in the simplest and usual way, to print an announcement including a valid copyright notice "Copyright 1988 Free Software Foundation, Inc.'' (or with the year that is appropriate), saying that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License Agreement. 
- You may charge a distribution fee for the physical act of transfer ring a copy, and you may at your option offer warranty protection in exchange for a fee. 
Mere aggregation of another unrelated program with this program (or its derivative) on a volume of a storage or distribution medium does not bring the other program under the scope of these terms. 
3. You may copy and distribute GNU Emacs (or a portion or derivative of it, under Paragraph 2) in object code or executable form under the terms of Paragraphs 1 and 2 above provided that you also do one of the following: 
- accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Paragraphs 1 and 2 above; or, 
- accompany it with a written offer, valid for at least three years, to give any third party free (except for a nominal shipping charge) a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Paragraphs 1 and 2 above; or, 
- accompany it with the information you received as to where the corresponding source code may be obtained. (This alternative is allowed only for non commercial distribution and only if you received the program in object code or executable form alone.) 
For an executable file, complete source code means all the source code for all modules it contains; but, as a special exception, it need not include source code for modules which are standard libraries that accompany the operating system on which the executable file runs. 
4. You may not copy, sub license, distribute or transfer GNU Emacs except as expressly provided under this License Agreement. Any attempt otherwise to copy, sub license, distribute or transfer GNU Emacs is void and your rights to use GNU Emacs under this License agreement shall be automatically terminated. However, parties who have received computer software programs from you with this License Agreement will not have their licenses terminated so long as such parties remain in full compliance. 
5. If you wish to incorporate parts of GNU Emacs into other free programs whose distribution conditions are different, write to the Free Software Foundation. We have not yet worked out a simple rule that can be stated here, but we will often permit this. We will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software. 
Your comments and suggestions about our licensing policies and our software are welcome! Please contact the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139. 
NO WARRANTY 
BECAUSE GNU EMACS IS LICENSED FREE OF CHARGE, WE PROVIDE ABSOLUTELY NO WARRANTY, TO THE EXTENT PERMITTED BY APPLICABLE STATE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING, FREE SOFTWARE FOUNDATION, INC, RICHARD M. STALLMAN AND/OR OTHER PARTIES PROVIDE GNU EMACS "AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE GNU EMACS PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW WILL FREE SOFTWARE FOUNDATION, INC., RICHARD M. STALLMAN, AND/OR ANY OTHER PARTY WHO MAY MODIFY AND REDISTRIBUTE GNU EMACS AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY LOST PROFITS, LOST MONIES, OR OTHER SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH PROGRAMS NOT DISTRIBUTED BY FREE SOFTWARE FOUNDATION, INC.) THE PROGRAM, EVEN IF YOU HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY ANY OTHER PARTY. 

The Open Source Definition
Version 1.9
The indented, italicized sections below appear as annotations to the Open Source Definition (OSD) and are not a part of the OSD. A plain version of the OSD without annotations can be found here.
Introduction
Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria: 
1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
Rationale: By constraining the license to require free redistribution, we eliminate the temptation to throw away many long-term gains in order to make a few short-term sales dollars. If we didn't do this, there would be lots of pressure for cooperators to defect. 
2. Source Code
The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost—preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
Rationale: We require access to un-obfuscated source code because you can't evolve programs without modifying them. Since our purpose is to make evolution easy, we require that modification be made easy.
3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
Rationale: The mere ability to read source isn't enough to support independent peer review and rapid evolutionary selection. For rapid evolution to happen, people need to be able to experiment with and redistribute modifications.
4. Integrity of The Author's Source Code
The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.
Rationale: Encouraging lots of improvement is a good thing, but users have a right to know who is responsible for the software they are using. Authors and maintainers have reciprocal right to know what they're being asked to support and protect their reputations.
Accordingly, an open-source license must guarantee that source be readily available, but may require that it be distributed as pristine base sources plus patches. In this way, "unofficial" changes can be made available but readily distinguished from the base source.
5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons.
Rationale: In order to get the maximum benefit from the process, the maximum diversity of persons and groups should be equally eligible to contribute to open sources. Therefore we forbid any open-source license from locking anybody out of the process.
Some countries, including the United States, have export restrictions for certain types of software. An OSD-conformant license may warn licensees of applicable restrictions and remind them that they are obliged to obey the law; however, it may not incorporate such restrictions itself.
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
Rationale: The major intention of this clause is to prohibit license traps that prevent open source from being used commercially. We want commercial users to join our community, not feel excluded from it.
7. Distribution of License
The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
Rationale: This clause is intended to forbid closing up software by indirect means such as requiring a non-disclosure agreement.
8. License Must Not Be Specific to a Product
The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.
Rationale: This clause forecloses yet another class of license traps.
9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
Rationale: Distributors of open-source software have the right to make their own choices about their own software.
Yes, the GPL is conformant with this requirement. Software linked with GPLed libraries only inherits the GPL if it forms a single work, not any software with which they are merely distributed.
10. License Must Be Technology-Neutral
No provision of the license may be predicated on any individual technology or style of interface.
Rationale: This provision is aimed specifically at licenses which require an explicit gesture of assent in order to establish a contract between licensor and licensee. Provisions mandating so-called "click-wrap" may conflict with important methods of software distribution such as FTP download, CD-ROM anthologies, and web mirroring; such provisions may also hinder code re-use. Conformant licenses must allow for the possibility that (a) redistribution of the software will take place over non-Web channels that do not support click-wrapping of the download, and that (b) the covered code (or re-used portions of covered code) may run in a non-GUI environment that cannot support popup dialogues.

Exception à la GNU GPL pour le kernel Linux

   NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".
 Also note that the GPL below is copyrighted by the Free Software
 Foundation, but the instance of code that it refers to (the linux
 kernel) is copyrighted by me and others who actually wrote it.
                        Linus Torvalds
----------------------------------------

Appendix K. - MySQL FLOSS License Exception
The MySQL AB Exception for Free/Libre and Open Source Software-only Applications Using MySQL Client Libraries (the “FLOSS Exception”). 
Version 0.4, 08 September 2005 
Exception Intent 
We want specified Free/Libre and Open Source Software (``FLOSS'') applications to be able to use specified GPL-licensed MySQL client libraries (the ``Program'') despite the fact that not all FLOSS licenses are compatible with version 2 of the GNU General Public License (the ``GPL''). 
Legal Terms and Conditions 
As a special exception to the terms and conditions of version 2.0 of the GPL: 
1.	You are free to distribute a Derivative Work that is formed entirely from the Program and one or more works (each, a “FLOSS Work”) licensed under one or more of the licenses listed below in section 1, as long as: 
a.	You obey the GPL in all respects for the Program and the Derivative Work, except for identifiable sections of the Derivative Work which are not derived from the Program, and which can reasonably be considered independent and separate works in themselves, 
b.	all identifiable sections of the Derivative Work which are not derived from the Program, and which can reasonably be considered independent and separate works in themselves, 
i.	are distributed subject to one of the FLOSS licenses listed below, and 
ii.	the object code or executable form of those sections are accompanied by the complete corresponding machine-readable source code for those sections on the same medium and under the same FLOSS license as the corresponding object code or executable forms of those sections, and 
c.	any works which are aggregated with the Program or with a Derivative Work on a volume of a storage or distribution medium in accordance with the GPL, can reasonably be considered independent and separate works in themselves which are not derivatives of either the Program, a Derivative Work or a FLOSS Work. 
	If the above conditions are not met, then the Program may only be copied, modified, distributed or used under the terms and conditions of the GPL or another valid licensing option from MySQL AB. 
2.	FLOSS License List 
License name	Version(s)/Copyright Date	
Academic Free License	2.0	
Apache Software License	1.0/1.1/2.0	
Apple Public Source License	2.0	
Artistic license	From Perl 5.8.0	
BSD license	"July 22 1999"	
Common Public License	1.0	
GNU Library or "Lesser" General Public License (LGPL)	2.0/2.1	
Jabber Open Source License	1.0	
MIT license	-	
Mozilla Public License (MPL)	1.0/1.1	
Open Software License	2.0	
OpenSSL license (with original SSLeay license)	"2003" ("1998")	
PHP License	3.0	
Python license (CNRI Python License)	—	
Python Software Foundation License	2.1.1	
Sleepycat License	"1999"	
W3C License	"2001"	
X11 License	"2001"	
Zlib/libpng License	—	
Zope Public License	2.0	
	Due to the many variants of some of the above licenses, we require that any version follow the 2003 version of the Free Software Foundation's Free Software Definition (http://www.gnu.org/philosophy/free-sw.html) or version 1.9 of the Open Source Definition by the Open Source Initiative (http://www.opensource.org/docs/definition.php). 
3.	Definitions 
a.	Terms used, but not defined, herein shall have the meaning provided in the GPL. 
b.	Derivative Work means a derivative work under copyright law. 
4.	Applicability: This FLOSS Exception applies to all Programs that contain a notice placed by MySQL AB saying that the Program may be distributed under the terms of this FLOSS Exception. If you create or distribute a work which is a Derivative Work of both the Program and any other work licensed under the GPL, then this FLOSS Exception is not available for that work; thus, you must remove the FLOSS Exception notice from that work and comply with the GPL in all respects, including by retaining all GPL notices. You may choose to redistribute a copy of the Program exclusively under the terms of the GPL by removing the FLOSS Exception notice from that copy of the Program, provided that the copy has never been modified by you or any third party. 
Appendix A. Qualified Libraries and Packages 
The following is a non-exhaustive list of libraries and packages which are covered by the FLOSS License Exception. Please note that this appendix is provided merely as an additional service to specific FLOSS projects wishing to simplify licensing information for their users. Compliance with one of the licenses noted under the “FLOSS license list” section remains a prerequisite. 
Package Name	Qualifying License and Version	
Apache Portable Runtime (APR)	Apache Software License 2.0	

Comparaison des brouillons de la GNU GPL v3

GPLv3, 1st discussion draft
Par johns — Dernière modification 27-07-2006 17:13 
This is not the most current draft. 
(Plain text version) 

GNU GENERAL PUBLIC LICENSE
Discussion Draft 1 of Version 3, 16 Jan 2006
THIS IS A DRAFT, NOT A PUBLISHED VERSION OF THE GNU GENERAL PUBLIC LICENSE.
Copyright (C) 2006 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. 	GPLv3, 2nd discussion draft
Par johns — Dernière modification 27-07-2006 17:15 
This is the most current draft for discussion.
•	Guide to the new drafts 
•	Revisit the 1st discussion draft 
•	See the new LGPL draft. 
Plain text 
GNU GENERAL PUBLIC LICENSE
Discussion Draft 2 of Version 3, 27 July 2006
THIS IS A DRAFT, NOT A PUBLISHED VERSION OF THE GNU GENERAL PUBLIC LICENSE.
Copyright © 2006 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. 	
Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other program whose authors commit to using it. (Some Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too. 
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. 
To protect your rights, we need to make requirements that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. 
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. 
Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License which gives you legal permission to copy, distribute and/or modify the software. 
For the developers' and author's protection, the GPL clearly explains that there is no warranty for this free software. If the software is modified by someone else and passed on, the GPL ensures that recipients are told that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. 
Some countries have adopted laws prohibiting software that enables users to escape from Digital Restrictions Management. DRM is fundamentally incompatible with the purpose of the GPL, which is to protect users' freedom; therefore, the GPL ensures that the software it covers will neither be subject to, nor subject other works to, digital restrictions from which escape is forbidden. 
Finally, every program is threatened constantly by software patents. We wish to avoid the special danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, the GPL makes it clear that any patent must be licensed for everyone's free use or not licensed at all. 
The precise terms and conditions for copying, distribution and modification follow. 	Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other program whose authors commit to using it. You can apply it to your programs, too. 
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things. 
To protect your rights, we need to make requirements that forbid anyone to deny you these rights or to ask you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it. 
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. 
Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License which gives you legal permission to copy, distribute and/or modify the software. 
For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software. For both users' and authors' sake, the GPL requires that modified versions be marked as changed, so that their problems will not be associated erroneously with the original version. 
Some computers are designed to deny users access to install or run modified versions of the software inside them. This is fundamentally incompatible with the purpose of the GPL, which is to protect users' freedom to change the software. Therefore, the GPL ensures that the software it covers will not be restricted in this way. 
Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in places where they do, we wish to avoid the special danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free. 	
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION	TERMS AND CONDITIONS	
0. Definitions.
A "licensed program" means any program or other work distributed under this License. The "Program" refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either modified or unmodified. Throughout this License, the term "modification" includes, without limitation, translation and extension. A "covered work" means either the Program or any work based on the Program. Each licensee is addressed as "you". 
To "propagate" a work means doing anything with it that requires permission under applicable copyright law, other than executing it on a computer or making private modifications. This includes copying, distribution (with or without modification), sublicensing, and in some countries other activities as well. 	0. Definitions.
In this License, each licensee is addressed as "you," while "the Program" refers to any work of authorship licensed under this License. A "modified" work includes, without limitation, versions in which material has been translated or added. A work "based on" another work means any modified version, formation of which requires permission under applicable copyright law. A "covered work" means either the unmodified Program or a work based on the Program. 
To "propagate" a work means doing anything with it that requires permission under applicable copyright law, except executing it on a computer, or making modifications that you do not share. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well. To "convey" a work means any kind of propagation that enables other parties to make or receive copies, excluding sublicensing. 
A party's "essential patent claims" in a work are all patent claims that the party can give permission to practice, whether already acquired or to be acquired, that would be infringed by making, using, or selling the work. 	
1. Source Code.
The "source code" for a work means the preferred form of the work for making modifications to it. "Object code" means any non-source version of a work. 
The "Complete Corresponding Source Code" for a work in object code form means all the source code needed to understand, adapt, modify, compile, link, install, and run the work, excluding general-purpose tools used in performing those activities but which are not part of the work. For example, this includes any scripts used to control those activities, and any shared libraries and dynamically linked subprograms that the work is designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work, and interface definition files associated with the program source files. 
Complete Corresponding Source Code also includes any encryption or authorization codes necessary to install and/or execute the source code of the work, perhaps modified by you, in the recommended or principal context of use, such that its functioning in all circumstances is identical to that of the work, except as altered by your modifications. It also includes any decryption codes necessary to access or unseal the work's output. Notwithstanding this, a code need not be included in cases where use of the work normally implies the user already has it. 
Complete Corresponding Source Code need not include anything that users can regenerate automatically from other parts of the Complete Corresponding Source Code. 
As a special exception, the Complete Corresponding Source Code need not include a particular subunit if (a) the identical subunit is normally included as an adjunct in the distribution of either a major essential component (kernel, window system, and so on) of the operating system on which the executable runs or a compiler used to produce the executable or an object code interpreter used to run it, and (b) the subunit (aside from possible incidental extensions) serves only to enable use of the work with that system component or compiler or interpreter, or to implement a widely used or standard interface, the implementation of which requires no patent license not already generally available for software under this License. 	1. Source Code.
The "source code" for a work means the preferred form of the work for making modifications to it. "Object code" means any non-source version of a work. 
The "System Libraries" of an executable work include every subunit such that (a) the identical subunit is normally included as an adjunct in the distribution of either a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the object code runs, or a compiler used to produce the object code, or an object code interpreter used to run it, and (b) the subunit (aside from possible incidental extensions) serves only to enable use of the work with that system component or compiler or interpreter, or to implement a widely used or standard interface for which an implementation is available to the public in source code form. 
The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, except its System Libraries, and except general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes scripts used to control those activities, interface definition files associated with the program source files, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by complex data communication or control flow between those subprograms and other parts of the work. 
The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances. (For instance, if the work is a DVD player and can play certain DVDs, it must be possible for modified versions to play those DVDs. If the work communicates with an online service, it must be possible for modified versions to communicate with the same online service in the same way such that the service cannot distinguish.) A key need not be included in cases where use of the work normally implies the user already has the key and can read and copy it, as in privacy applications where users generate their own keys. However, the fact that a key is generated based on the object code of the work or is present in hardware that limits its use does not alter the requirement to include it in the Corresponding Source. 
The Corresponding Source may include portions which do not formally state this License as their license, but qualify under section 7 for inclusion in a work under this License. 
The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source. 	
2. Basic Permissions.
All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the Program. The output from running it is covered by this License only if the output, given its content, constitutes a work based on the Program. This License acknowledges your rights of "fair use" or other equivalent, as provided by copyright law. 
This License gives unlimited permission to privately modify and run the Program, provided you do not bring suit for patent infringement against anyone for making, using or distributing their own works based on the Program. 
Propagation of covered works is permitted without limitation provided it does not enable parties other than you to make or receive copies. Propagation which does enable them to do so is permitted, as "distribution", under the conditions of sections 4-6 below. 	2. Basic Permissions.
All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the  unmodified Program. The output from running it is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of "fair use" or other equivalent, as provided by copyright law. 
This License permits you to make and run privately modified versions of the Program, or have others make and run them on your behalf. However, this permission terminates, as to all such versions, if you bring suit against anyone for patent infringement of any of your essential patent claims in any such version, for making, using, selling or otherwise conveying a work based on the Program in compliance with this License. 
Propagation of covered works other than conveying is permitted without limitation. Sublicensing is not allowed; section 10 makes it unnecessary. Conveying is permitted under the conditions stated below. 	
3. Digital Restrictions Management.
As a free software license, this License intrinsically disfavors technical attempts to restrict users' freedom to copy, modify, and share copyrighted works. Each of its provisions shall be interpreted in light of this specific declaration of the licensor's intent. Regardless of any other provision of this License, no permission is given to distribute covered works that illegally invade users' privacy, nor for modes of distribution that deny users that run covered works the full exercise of the legal rights granted by this License. 
No covered work constitutes part of an effective technological protection measure: that is to say, distribution of a covered work as part of a system to generate or access certain data constitutes general permission at least for development, distribution and use, under this License, of other software capable of accessing the same data. 	3. No Denying Users' Rights through Technical Measures.
Regardless of any other provision of this License, no permission is given for modes of conveying that deny users that run covered works the full exercise of the legal rights granted by this License. 
No covered work constitutes part of an effective technological "protection" measure under section 1201 of Title 17 of the United States Code. When you convey a covered work, you waive any legal power to forbid circumvention of technical measures that include use of the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing the legal rights of third parties against the work's users. 	
4.[1] Verbatim Copying.
You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all license notices and notices of the absence of any warranty; give all recipients of the Program a copy of this License along with the Program; and obey any additional terms present on parts of the Program in accord with section 7. 
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection for a fee. 	4.[1] Verbatim Copying.
You may copy and convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all license notices and notices of the absence of any warranty; and give all recipients, along with the Program, a copy of this License and the central list (if any) required by section 7. The recipients of these copies will possess all the rights granted by this License (with any added terms under section 7). 
You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.	
5.[2] Distributing Modified Source Versions.
Having modified a copy of the Program under the conditions of section 2, thus forming a work based on the Program, you may copy and distribute such modifications or work in the form of source code under the terms of Section 4 above, provided that you also meet all of these conditions: 
•	a) The modified work must carry prominent notices stating that you changed the work and the date of any change. 
•	b) You must license the entire modified work, as a whole, under this License to anyone who comes into possession of a copy. This License must apply, unmodified except as permitted by section 7 below, to the whole of the work. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. 
•	c) If the modified work has interactive user interfaces, each must include a convenient feature that displays an appropriate copyright notice, and tells the user that there is no warranty for the program (or that you provide a warranty), that users may redistribute the modified work under these conditions, and how to view a copy of this License together with the central list (if any) of other terms in accord with section 7. If the interface presents a list of user commands or options, such as a menu, a command to display this information must be prominent in the list. Otherwise, the modified work must display this information at startup--except in the case that the Program has such interactive modes and does not display this information at startup. 
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. 
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. 
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. Mere inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate. 	 5.[2] Conveying Modified Source Versions.
You may copy and convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4 above, provided that you also meet all of these conditions: 
•	a) The modified work must carry prominent notices stating that you changed the work and the date of any change. 
•	b) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License must apply, unmodified except as permitted by section 7 below, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. 
•	c) If the modified work has interactive user interfaces, each must include a convenient feature that displays an appropriate copyright notice, and tells the user that there is no warranty for the program (or that you provide a warranty), that users may convey the modified work under this License, and how to view a copy of this License together with the central list (if any) of other terms in accord with section 7. Specifically, if the interface presents a list of user commands or options, such as a menu, a command to display this information must be prominent in the list; otherwise, the modified work must display this information at startup. However, if the Program has interactive interfaces that do not comply with this subsection, your modified work need not make them comply. 
To the extent that identifiable sections of the modified 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 convey them as separate works, not specifically for use in combination with the Program. 
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate. 	
6.[3] Non-Source Distribution.
You may copy and distribute a covered work in Object Code form under the terms of Sections 4 and 5, provided that you also distribute the machine-readable Complete Corresponding Source Code (herein the "Corresponding Source") under the terms of this License, in one of these ways: 
•	a) Distribute the Object Code in a physical product (including a physical distribution medium), accompanied by the Corresponding Source distributed on a durable physical medium customarily used for software interchange; or, 
•	b) Distribute the Object Code in a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give any third party, for a price no more than ten times your cost of physically performing source distribution, a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange; or, 
•	c) Privately distribute the Object Code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only for occasional noncommercial distribution, and only if you received the Object Code with such an offer, in accord with Subsection b above. Or, 
•	d) Distribute the Object Code by offering access to copy it from a designated place, and offer equivalent access to copy the Corresponding Source in the same way through the same place. You need not require recipients to copy the Corresponding Source along with the Object Code.

[If the place to copy the Object Code is a network server, the Corresponding Source may be on a different server that supports equivalent copying facilities, provided you have explicitly arranged with the operator of that server to keep the Corresponding Source available for as long as needed to satisfy these requirements, and provided you maintain clear directions next to the Object Code saying where to find the Corresponding Source.] 
Distribution of the Corresponding Source in accord with this section must be in a format that is publicly documented, unencumbered by patents, and must require no special password or key for unpacking, reading or copying. 
The Corresponding Source may include portions which do not formally state this License as their license, but qualify under section 7 for inclusion in a work under this License. 	6.[3] Conveying Non-Source Forms.
You may copy and convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways: 
•	a) Convey the object code in a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange. 
•	b) Convey the object code in a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give any third party a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source. 
•	[b1) Convey the object code in a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to provide access to copy the Corresponding Source from a network server at no charge.] 
•	c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b or 6b1. 
•	d) Convey the object code by offering access from a designated place, and offer equivalent access to the Corresponding Source in the same way through the same place at no extra charge. You need not require recipients to copy the Corresponding Source along with the object code.

[If the place to copy the object code is a network server, the Corresponding Source may be on a different server that supports equivalent copying facilities, provided you have explicitly arranged with the operator of that server to keep the Corresponding Source available for as long as needed to satisfy these requirements, and provided you maintain clear directions next to the object code saying where to find the Corresponding Source.] 
•	e) Convey the object code using peer-to-peer transmission provided you know that, and inform other peers where, the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d. 
The Corresponding Source conveyed in accord with this section must be in a format that is publicly documented, with an implementation available to the public in source code form, and must require no special password or key for unpacking, reading or copying. 
A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work. 	
7. License Compatibility.
When you release a work based on the Program, you may include your own terms covering added parts for which you have, or can give, appropriate copyright permission, as long as those terms clearly permit all the activities that this License permits, or permit usage or relicensing under this License. Your terms may be written separately or may be this License plus additional written permission. If you so license your own added parts, those parts may be used separately under your terms, but the entire work remains under this License. Those who copy the work, or works based on it, must preserve your terms just as they must preserve this License, as long as any substantial portion of the parts they apply to are present. 
Aside from additional permissions, your terms may add limited kinds of additional requirements on your added parts, as follows: 
•	a) They may require the preservation of certain copyright notices, other legal notices, and/or author attributions, and may require that the origin of the parts they cover not be misrepresented, and/or that altered versions of them be marked in the source code, or marked there in specific reasonable ways, as different from the original version. 
•	b) They may state a disclaimer of warranty and liability in terms different from those used in this License. 
•	c) They may prohibit or limit the use for publicity purposes of specified names of contributors, and they may require that certain specified trademarks be used for publicity purposes only in the ways that are fair use under trademark law except with express permission. 
•	d) They may require that the work contain functioning facilities that allow users to immediately obtain copies of its Complete Corresponding Source Code. 
•	e) They may impose software patent retaliation, which means permission for use of your added parts terminates or may be terminated, wholly or partially, under stated conditions, for users closely related to any party that has filed a software patent lawsuit (i.e., a lawsuit alleging that some software infringes a patent). The conditions must limit retaliation to a subset of these two cases: 1. Lawsuits that lack the justification of retaliating against other software patent lawsuits that lack such justification. 2. Lawsuits that target part of this work, or other code that was elsewhere released together with the parts you added, the whole being under the terms used here for those parts. 
No other additional conditions are permitted in your terms; therefore, no other conditions can be present on any work that uses this License. This License does not attempt to enforce your terms, or assert that they are valid or enforceable by you; it simply does not prohibit you from employing them. 
When others modify the work, if they modify your parts of it, they may release such parts of their versions under this License without additional permissions, by including notice to that effect, or by deleting the notice that gives specific permissions in addition to this License. Then any broader permissions granted by your terms which are not granted by this License will not apply to their modifications, or to the modified versions of your parts resulting from their modifications. However, the specific requirements of your terms will still apply to whatever was derived from your added parts. 
Unless the work also permits distribution under a previous version of this License, all the other terms included in the work under this section must be listed, together, in a central list in the work. 	7. Additional Terms.
You may have received the Program, or parts of it, under terms that supplement the terms of this License. These additional terms may include additional permissions, as provided in subsection 7a, and additional requirements, as provided in subsection 7b. When you convey copies of a covered work, unless the work also permits use under a previous version of this License, it must list, in one central place in the source code, the complete set of additional terms governing all or part of the work. 
•	a. Additional Permissions.
•	Additional permissions make exceptions from one or more of the requirements of this License. A license document containing a clause that permits relicensing or conveying under this License shall be treated as a list of additional permissions, provided that the license document makes clear that no requirement in it survives such relicensing or conveying. 
•	Any additional permissions that are applicable to the entire Program are treated as though they were included in this License, as exceptions to its conditions, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional terms. 
•	b. Additional Requirements.
•	Additional requirements are terms that further constrain use, modification or propagation of covered works. This License affects only the procedure for enforcing additional requirements, and does not assert that they can be successfully enforced by the copyright holder. Only these kinds of additional requirements are allowed by this License: 
•	0) terms that require preservation of specified reasonable legal notices or author attributions; or 
•	1) terms that require that the origin of the material they cover not be misrepresented, or that modified versions of that material be marked in specific reasonable ways as different from the original version; or 
•	2) warranty or liability disclaimers that differ from the disclaimers in this License; or 
•	3) terms that prohibit or limit the use for publicity purposes of specified names of licensors or authors, or that require that certain specified trade names, trademarks, or service marks not be used for publicity purposes without express permission, other than in ways that are fair use under applicable trademark law; or 
•	4) terms that require, if a modified version of the material they cover is a work intended to interact with users through a computer network, that those users be able to obtain copies of the Corresponding Source of the work through the same network session; or 
•	5) terms that wholly or partially terminate, or allow termination of, permission for use of the material they cover, for a user who files a software patent lawsuit (that is, a lawsuit alleging that some software infringes a patent) not filed in retaliation or defense against the earlier filing of another software patent lawsuit, or in which the allegedly infringing software includes some of the covered material, possibly in combination with other software; or 
•	6) terms that are precisely equivalent in type and extent to a requirement expressly stated in this License, or that deny permission for activities that are clearly not permitted, expressly or otherwise, by this License. 
•	All other additional requirements, including attorney's fees provisions, choice of law, forum, and venue clauses, arbitration clauses, mandatory contractual acceptance clauses, requirements regarding changes to the name of the work, and terms that require that conveyed copies be governed by a license other than this License, are prohibited.
•	c. Terms Added or Removed by You.
•	When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. Some additional permissions require their own removal in certain cases when you modify the work. 
•	Additional requirements are allowed only as stated in subsection 7b. If the Program as you received it purports to impose any other additional requirement, you may remove that requirement. 
•	You may place additional permissions, or additional requirements as allowed by subsection 7b, on material, added by you to a covered work, for which you have or can give appropriate copyright permission. Adding requirements not allowed by subsection 7b is a violation of this License that may lead to termination of your rights under section 8. 
•	If you add terms to a covered work in accordance with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms. 	
8.[4] Termination.
You may not propagate, modify or sublicense the Program except as expressly provided under this License. Any attempt otherwise to propagate, modify or sublicense the Program is void, and any copyright holder may terminate your rights under this License at any time after having notified you of the violation by any reasonable means within 60 days of any occurrence. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as they remain in full compliance. 	8.[4] Termination.
You may not propagate or modify the Program except as expressly provided under this License. Any attempt otherwise to propagate or modify the Program is void. If you violate this License, any copyright holder may put you on notice by notifying you of the violation, by any reasonable means, provided 60 days have not elapsed since the last violation. Having put you on notice, the copyright holder may then terminate your license at any time. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as they remain in full compliance. 	
9.[5] Not a Contract.
You are not required to accept this License in order to receive a copy of the Program. However, nothing else grants you permission to propagate or modify the Program or any covered works. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating the Program (or any covered work), you indicate your acceptance of this License to do so, and all its terms and conditions. 	9.[5] Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing else grants you permission to propagate or modify the Program or any covered works. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating the Program (or any covered work), you indicate your acceptance of this License to do so, and all its terms and conditions. 	
10.[6] Automatic Licensing of Downstream Users.
Each time you redistribute a covered work, the recipient automatically receives a license from the original licensors, to propagate and modify that work, subject to this License, including any additional terms introduced through section 7. You may not impose any further restrictions on the recipients' exercise of the rights thus granted or affirmed, except (when modifying the work) in the limited ways permitted by section 7. You are not responsible for enforcing compliance by third parties to this License. 	10.[6] Automatic Licensing of Downstream Users.
Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License, including any additional terms introduced through section 7. You may not impose any further restrictions on the recipients' exercise of the rights thus granted or affirmed, except in the limited ways permitted by section 7. Therefore, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License. You are not responsible for enforcing compliance by third parties to this License. 
If propagation results from a transaction transferring control of an organization, each party to that transaction who receives a copy of the work also receives a license and a right to possession of the Corresponding Source of the work from the party's predecessor in interest. 	
11. Licensing of Patents.
When you distribute a covered work, you grant a patent license to the recipient, and to anyone that receives any version of the work, permitting, for any and all versions of the covered work, all activities allowed or contemplated by this License, such as installing, running and distributing versions of the work, and using their output. This patent license is nonexclusive, royalty-free and worldwide, and covers all patent claims you control or have the right to sublicense, at the time you distribute the covered work or in the future, that would be infringed or violated by the covered work or any reasonably contemplated use of the covered work. 
If you distribute a covered work knowingly relying on a patent license, you must act to shield downstream users against the possible patent infringement claims from which your license protects you. 	11. Patents.
You receive the Program with a covenant from each author and conveyor of the Program, and of any material, conveyed under this License, on which the Program is based, that the covenanting party will not assert (or cause others to assert) any of the party's essential patent claims in the material that the party conveyed, against you, arising from your exercise of rights under this License. If you convey a covered work, you similarly covenant to all recipients, including recipients of works based on the covered work, not to assert any of your essential patent claims in the covered work. 
If you convey a covered work, knowingly relying on a non-sublicensable patent license that is not generally available to all, you must either (1) act to shield downstream users against the possible patent infringement claims from which your license protects you, or (2) ensure that anyone can copy the Corresponding Source of the covered work, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means. 
Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law. 	
12.[7] Liberty or Death for the Program.
If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute the Program, or other covered work, so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute it at all. For example, if a patent license would not permit royalty-free redistribution by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution. 
It is not the purpose of this section to induce you to infringe any patents or other exclusive rights or to contest their legal validity. The sole purpose of this section is to protect the integrity of the free software distribution system. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. 	12.[7] No Surrender of Others' Freedom.
If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey the Program, or other covered work, so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you accept a patent license that prohibits royalty-free conveying by those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from conveying the Program. 	
[13.[8] Geographical Limitations.
If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.] 	[13.[8] Geographical Limitations.
If the conveying and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical limitation on conveying, excluding those countries, so that conveying is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.] 	
14.[9] Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. 
Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.	14.[9] Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. 
Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.	
15.[10] Requesting Exceptions.
If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. 	[15.[10] Requesting Exceptions.
If you wish to incorporate parts of the Program into other free programs under other licenses, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.] 	
NO WARRANTY	NO WARRANTY	
16.[11] There is no warranty for the Program, to the extent permitted by applicable law. Except when otherwise stated in writing the copyright holders and/or other parties provide the Program "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the Program is with you. Should the Program prove defective, you assume the cost of all necessary servicing, repair or correction. 	16.[11] Disclaimer of Warranty.
There is no warranty for the Program, to the extent permitted by applicable law. Except when otherwise stated in writing the copyright holders and/or other parties provide the Program "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the Program is with you. Should the Program prove defective, you assume the cost of all necessary servicing, repair or correction. 	
17.[12] In no event unless required by applicable law or agreed to in writing will any copyright holder, or any other party who may modify and/or redistribute the Program as permitted above, be liable to you for damages, including any general, special, incidental or consequential damages arising out of the use or inability to use the Program (including but not limited to loss of data or data being rendered inaccurate or losses sustained by you or third parties or a failure of the Program to operate with any other programs), even if such holder or other party has been advised of the possibility of such damages. 	17.[12] Limitation of Liability.
In no event unless required by applicable law or agreed to in writing will any copyright holder, or any other party who may modify and/or convey the Program as permitted above, be liable to you for damages, including any general, special, incidental or consequential damages arising out of the use or inability to use the Program (including but not limited to loss of data or data being rendered inaccurate or losses sustained by you or third parties or a failure of the Program to operate with any other programs), even if such holder or other party has been advised of the possibility of such damages. 	
18. Unless specifically stated, the Program has not been tested for use in safety critical systems. 		
END OF TERMS AND CONDITIONS	END OF TERMS AND CONDITIONS	

Brouillon de la LGPL version 3
GNU Lesser General Public License, 1st discussion draft
Par johns — Dernière modification 27-07-2006 16:59 
This is the most current draft for discussion.
•	Guide to the new drafts 
•	See the 2nd GPL discussion draft. 
Plain text 
GNU LESSER GENERAL PUBLIC LICENSE
Discussion Draft of Version 3, 27 July 2006 
THIS IS A DRAFT, NOT A PUBLISHED VERSION OF THE GNU LESSER GENERAL PUBLIC LICENSE. 
Copyright © 2006 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. 
This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below. 
0. Additional Definitions.
As used herein, "this License" refers to version 3 of the GNU Lesser General Public License, and the "GNU GPL" refers to version 3 of the GNU General Public License. 
"The Library" refers to the Program as defined in section 0 of the GNU GPL. An "Application" is any work that makes use of an interface provided by the Library but which is not otherwise based on the Library. Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library. A "Combined Work" is a work containing portions of the Library, produced by combining or linking an Application with the Library. 
The "Minimal Corresponding Source" for a Combined Work means the Corresponding Source for the Combined Work, excluding: 
•	a. any source code for portions of the Combined Work that, considered in isolation, are based on the Application and not on the Library; and 
•	b. any keys, other than keys that are necessary to install and/or execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Library. 
The "Corresponding Application Code" for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work. 
1. Exception to Section 3 of the GNU GPL.
You may convey a covered work under sections 3 and 4 of this License without being bound by the second paragraph of section 3 of the GNU GPL. 
2. Conveying Modified Versions.
If you modify a copy of the Library, and, in your modifications, a facility refers to a function or data to be supplied by an Application that uses the facility (other than as an argument passed when the facility is invoked), then you may convey a copy of the modified version: 
•	a. under this License, provided that you make a good faith effort to ensure that, in the event an Application does not supply the function or data, the facility still operates, and performs whatever part of its purpose remains meaningful, or 
•	b. under the GNU GPL, with none of the additional permissions of this License applicable to that copy. 
3. Object Code Incorporating Material from Library Header Files.
The object code form of an Application may incorporate material from a header file that is part of the Library. You may copy and convey such object code under any terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following: 
•	a. Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License. 
•	b. Accompany the object code with a copy of the GNU GPL and this License. 
4. Combined Works.
You may copy and convey a Combined Work under any terms of your choice that, taken together, effectively do not prohibit modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following: 
•	a. Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License. 
•	b. Accompany the Combined Work with a copy of the GNU GPL and this License. 
•	c. For a Combined Work that displays copyright notices during execution, include the copyright notice for the Library among these notices, as well as a reference directing the user to the copies of the GNU GPL and this License. 
•	d. Do one of the following: 
•	0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Library to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source. 
•	1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the version of the Library with which the Combined Work was made. 
5. Combined Libraries.
You may place library facilities that are a work based on the Library side by side in a single library together with other library facilities that are not Applications and are not covered by this License, and convey such a combined library under terms of your choice, if you do both of the following: 
•	a. Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities, conveyed under the terms of this License. 
•	b. Give prominent notice with the combined library that part of it is a work based on the Library, explaining where to find the accompanying uncombined form of the same work. 
6. Revised Versions of the GNU Lesser General Public License.
The Free Software Foundation may publish revised and/or new versions of the GNU Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. 
Each version is given a distinguishing version number. If the Library specifies that a certain numbered version of the GNU Lesser General Public License "or any later version" applies to it, you have the option of following the terms and conditions either of that published version or of any later version published by the Free Software Foundation. If the Library does not specify a version number of the GNU Lesser General Public License, you may choose any version of the GNU Lesser General Public License ever published by the Free Software Foundation

Application d'une licence logicielle :

	Voici un exemple concret d'application d'une licence, proposée par Veni, Vidi, Libri au développeur de Dékibulle lors du passage de son logiciel à une licence FLOS. Le choix de l'auteur fut une licence multiple CeCILL-C/GNU LGPL afin que celle-ci ne s'étende pas aux autres composantes, et que le logiciel puisse profiter de l'utilisation et du développement le plus large (licence compatible avec la GNU LGPL et GPL, et la CeCILL et CeCILL-C).
•	Reproduction du Fichier AUTHORS.txt :
Copyright © Frédéric MONTIN, 2006
dekibulle@free.fr
http://dekibulle.free.fr
**fr**
Ce logiciel est un programme informatique servant à lire des fichiers audio sur ordinateur.
Ce fichier est une partie de dékibulle.
Dékibulle est un logiciel libre; soumis à une double licence. 
Vous pouvez le redistribuer ainsi que le modifier dès lors que vous respectez les termes *de l'une des deux licences*
- *soit* la licence GNU Lesser General Public License comme publiée par la Free Software Foundation, dans sa version 2 ou ultérieure; 
- *soit* la licence CeCILL-C comme publiée par CeCILL, dans sa version 1 ou ultérieure.
*en**
This software is a computer program whose purpose is to listen audio files on a computer.
This file is a part of Dékibulle.
Dékibulle is a free software; subjected to a double license.
You can redistribute it and/or modify since you respect the terms of either  (at least one of the both license) :
- the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or any later version.
- the CeCILL-C as published by CeCILL; either version 1 of the License, or any later version.

**********************
*CeCILL-C (fr) NOTICE     *
**********************

Ce logiciel est régi par la licence CeCILL-C soumise au droit français et respectant les principes de diffusion des logiciels libres. Vous pouvez utiliser, modifier et/ou redistribuer ce programme sous les conditions de la licence CeCILL-C telle que diffusée par le CEA, le CNRS et l'INRIA sur le site "http://www.CeCILL.info".

En contrepartie de l'accessibilité au code source et des droits de copie, de modification et de redistribution accordés par cette licence, il n'est offert aux utilisateurs qu'une garantie limitée. Pour les mêmes raisons, seule une responsabilité restreinte pèse sur l'auteur du programme,  le titulaire des droits patrimoniaux et les concédants successifs.

A cet égard  l'attention de l'utilisateur est attirée sur les risques associés au chargement,  à l'utilisation,  à la modification et/ou au développement et à la reproduction du logiciel par l'utilisateur étant donné sa spécificité de logiciel libre, qui peut le rendre complexe à manipuler et qui le réserve donc à des développeurs et des professionnels
avertis possédant  des  connaissances  informatiques approfondies.  Les utilisateurs sont donc invités à charger  et  tester  l'adéquation  du logiciel à leurs besoins dans des conditions permettant d'assurer la sécurité de leurs systèmes et ou de leurs données et, plus généralement, à l'utiliser et l'exploiter dans les mêmes conditions de sécurité. 
Le fait que vous puissiez accéder à cet en-tête signifie que vous avez pris connaissance de la licence CeCILL-C, et que vous en avez accepté les termes.	

**********************
*CeCILL-C (en) NOTICE*
**********************

Copyright © Frédéric MONTIN, 2006

dekibulle@free.fr
http://dekibulle.free.fr

This software is governed by the CeCILL-C  license under French law and abiding by the rules of distribution of free software.  You can  use, modify and/ or redistribute the software under the terms of the CeCILL-Cl icense as circulated by CEA, CNRS and INRIA at the following URL "http://www.CeCILL.info". 
As a counterpart to the access to the source code and  rights to copy, modify and redistribute granted by the license, users are provided only with a limited warranty  and the software's author,  the holder of the economic rights,  and the successive licensors  have only  limited liability. 
In this respect, the user's attention is drawn to the risks associated with loading,  using,  modifying and/or developing or reproducing the software by the user in light of its specific status of free software, that may mean  that it is complicated to manipulate,  and  that  also therefore means  that it is reserved for developers  and  experienced professionals having in-depth computer knowledge. Users are therefore encouraged to load and test the software's suitability as regards their
requirements in conditions enabling the security of their systems and/or data to be ensured and,  more generally, to use and operate it in the same conditions as regards security. 
The fact that you are presently reading this means that you have had knowledge of the CeCILL-C license and that you accept its terms.

*****************
*GNU LGPL NOTICE*
*****************

Copyright © Frédéric MONTIN, 2006

dekibulle@free.fr
http://dekibulle.free.fr

This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA

******************************************************************
******************************************************************
DéKiBulle is made using those external components and libraries :
- Audio Tool Library   : http://mac.sourceforge.net/atl (BSD Compliant)
- CoolTrayIcon          : http://subsimple.com/delphi.asp
- HotKeyManager      : http://subsimple.com/delphi.asp
- SnapForm              : http://www.delphifr.com/article.aspx?ID=2352
- BASS                     : http://www.un4seen.com
Note : The BASS library is free for non-commercial use (see http://www.un4seen.com/bass.html#license)
Dékibulle and licenses :
--> Dékibulle           : CeCILL-C / GNU LGPL
- Audio Tool Library  : GNU LGPL
- CoolTrayIcon         : BSD Compliant
- HotKeyManager     : BSD Compliant
- SnapForm             : CeCILL-C / GNU LGPL
- BASS                    : Free For non-commercial use (see http://www.un4seen.com/bass.html#license).	

Tableau récapitulatif non exhaustif de licences FLOS
 
	Simple ébauche qui pourra par la suite être complétée, le tableau qui suit essaye de mettre en avant les spécificités de chaque licence qu'il « décortique ». Pour ceci, dès qu'une situation est prise en compte par une licence, celle-ci est colorée suivant la légende qui suit, et les termes employés ou spécificités sont indiqués par écrit : 

Légende :	
Clauses FLOS « basiques »	En noir si « interdiction formelle »	
Clauses FLOS «dérogatoires»	En blanc si la licence ne s'y étend pas	
Clauses FLOS «importantes»		

Licences de contenu

« Option libre » : compatibilité entre contrats — Copyright © 2006 Benjamin Jean, 
Copyleft : cette oeuvre est libre, vous pouvez la redistribuer et/ou la modifier selon les termes de la Licence Art Libre, GNU FDL, CC-BY-SA,OPL et IANG (avec un droit d'être informé sur sa composition et son économie pour cette dernière).
Vous trouverez un exemplaire de ces Licences sur chacun des sites afférents ainsi que sur www.venividilibri.org.
Contact : optionlibre@venividilibri.org	

•	L'étude présente (développements et tableaux) est — avec l'acceptation du Professeur Vivant, directeur de mémoire — sous licence multiple dès le 1r septembre 2006 : Licence Art Libre, licence GNU FDL, licence Creative Commons Attribution Share Alike, OPL et licence IANG.
•	Les représentations et reproductions de l'illustration « Troll » en Introduction sont gracieusement autorisées par Rafael Jiménez Mesa, dans le cadre unique de cette étude. L'auteur se réservant ainsi la discrétion d'en autoriser d'autres usages, Cover (Troll) Illustration: Copyright © Rafael Jiménez Mesa / iO-Design ™ www.io-d.net.
•	Les annexes sont pour leur part soumises à leur licence respective.
•	Les réponses de Richard Stallman sont reproduites avec son autorisation.
•	Si vous désirez un autre format de fichier (odt, etc.), envoyez moi un mail.