Personnellement, je ne pense pas que ce soit le cas, ou alors c'est vraiment restreindre son marché et ne voir qu'une toute petite partie du problème comme tu sembles le faire.
Même pour quelqu'un développant un logiciel sous licence libre, la compatibilité des licences Open Source/libre entre elles peut tourner au cauchemar. En fonction de la licence sous laquelle tu distribues ton projet, tu ne pourras pas forcément réutiliser du code open source sous une autre licence incompatible. Et réciproquement, les composants que tu réutilises peuvent fortement conditionner le choix de ta licence. Voici un post pris (presque) au hasard sur StackOverflow d'un développeur libriste dans ce cas.
quand on recherche la compatibilité entre licences, on arrive toujours à trouver une réponse (ou à peu près) dès que cette compatibilité concerne la GPL. Après, ca devient du sport de haut niveau ! Qu'en est-il de la compatibilité de la MPL avec l'EPL, avec l'Apache v2 ? avec l'EuPL, avec CeciLL ? etc, Doctorat de droit requis, avec options droit international, droit de la PI et art divinatoires indispensables
certains projets changent de licence avec des implications non négligeables. pas la peine de chercher plus loin que Samba qui est passé de la GPLv2 à la v3
.
Le cas est tout aussi valable pour les industriels qui souhaitent réutiliser, modifier, distribuer du code libre. Avec toute la meilleure volonté du monde, ils pourraient tout de même se retrouver dans un imbriglio concernant la compatibilité des licences. On en arrive à faire des architectures juridiques… Certains ont déjà du mal à avoir un état des lieux à peu près précis de leurs applications en interne, alors imagine le fait d'avoir à maintenir une base de composants FLOSS utilisés, où, dans quel contexte, distribués ou non, dans quelle version, quelle licence applicable, etc. Et ensuite de déterminer les actions à entreprendre pour être en conformité avec les licences : mettre à disposition le code source (sous quelle forme ? où ? etc.), inclure les mentions légales (pareil : sous quelle forme ? où ? etc.), etc.
De la même manière qu'il existe des outils d'aide à l'analyse et la revue de code pour les aspects de qualité, performance, sécurité, etc., ce type de base (Antepédia) et d'outils (Antelink, Blackduck, Palamida, Protecode, etc.) permettent d'aider à gérer les problématiques liées aux licences FLOSS et justement profiter du libre tout en le respectant.
[^] # Re: Défendez-vous contre la contamination du logiciel libre.
Posté par Florent Zara (site web personnel, Mastodon) . En réponse à la dépêche Concours de développement autour de SourceSquare. Évalué à 3. Dernière modification le 31 mai 2012 à 00:22.
Personnellement, je ne pense pas que ce soit le cas, ou alors c'est vraiment restreindre son marché et ne voir qu'une toute petite partie du problème comme tu sembles le faire.
Même pour quelqu'un développant un logiciel sous licence libre, la compatibilité des licences Open Source/libre entre elles peut tourner au cauchemar. En fonction de la licence sous laquelle tu distribues ton projet, tu ne pourras pas forcément réutiliser du code open source sous une autre licence incompatible. Et réciproquement, les composants que tu réutilises peuvent fortement conditionner le choix de ta licence. Voici un post pris (presque) au hasard sur StackOverflow d'un développeur libriste dans ce cas.
Pour te donner une (petite) idée du problème,
Mais d'ailleurs, que veut dire compatible ?
Le cas est tout aussi valable pour les industriels qui souhaitent réutiliser, modifier, distribuer du code libre. Avec toute la meilleure volonté du monde, ils pourraient tout de même se retrouver dans un imbriglio concernant la compatibilité des licences. On en arrive à faire des architectures juridiques… Certains ont déjà du mal à avoir un état des lieux à peu près précis de leurs applications en interne, alors imagine le fait d'avoir à maintenir une base de composants FLOSS utilisés, où, dans quel contexte, distribués ou non, dans quelle version, quelle licence applicable, etc. Et ensuite de déterminer les actions à entreprendre pour être en conformité avec les licences : mettre à disposition le code source (sous quelle forme ? où ? etc.), inclure les mentions légales (pareil : sous quelle forme ? où ? etc.), etc.
De la même manière qu'il existe des outils d'aide à l'analyse et la revue de code pour les aspects de qualité, performance, sécurité, etc., ce type de base (Antepédia) et d'outils (Antelink, Blackduck, Palamida, Protecode, etc.) permettent d'aider à gérer les problématiques liées aux licences FLOSS et justement profiter du libre tout en le respectant.
Deux lectures que je conseille :