C'est d'autant plus clair avec l'objectif que tu met en valeur ici. J'ai trouvé ce document remarquablement bien réalisé, clair et agréable à lire. Cela fait plaisir de voir ce type de document (et que syntec y soit associé est une bonne chose, ça évitera le pillage de code que j'ai pû constater parfois [vendredi inside un peu, mais pas trop] en permettant aux ssii et pme/pmi d'avoir une vision clair des enjeux).
Ce qu'il manque (à mon goût) ce sont des pistes sur la mise en pratique de ces bonnes pratiques :) Certes les outils usuels sont cités (blackduck) mais tout semble rose bombon au pays des fleurs... Or ce n'est pas le cas, il me semble important de souligner également les difficultés liés à ces enjeux, et parfois le coût en terme de temps que peux représenter une bonne gouvernance opensource au sein d'une entreprise. Alors oui bien sûr on est très loin de la *mertitude* des serveurs de licences, mais il y a quant même, ou du moins il peut y avoir, des difficultés en prendre en compte.
Je prends l'exemple de RPM.
Actuellement rpm gère les licences sous la forme d'une simple déclaration unique. Si on fait sale, on colle tout sur une ligne et basta. Si on fait un peu plus propre on va utiliser la possibilité de création de rpm multiples avec un seul spec, et ainsi avoir une granularité plus fine des licences. Très bien. Mais il reste de nombreux cas où ni l'un ni l'autre ne convient. Exemple courant : un projet totalement libre inclu des fichiers sous license apache, une biblio en lgpl, deux futurs binaires en gplv2 strict, et un peu de doc sous gfdl. Ok. Mais tout ceci ne constituera qu'un paquetage unique au final, il n'y a pas d'intérêt à en créer de séparer (mettons que le doc ne soit pas doxy... [dredi])...Là, RPM n'est pas actuellement capable de répondre à cette problématique. En fait, pour être plus précis, il s'en fiche c'est pas son problème. Mais cela peux causer des soucis à la gouvernance OpenSource pour -au moins- faciliter la compatibilité et le suivi des licences utilisées.
Ca fait enculeur de mouche, mon exemple, mais c'est pourtant un exemple très courant. Et perso il ne me semble pas pertinent que la gouvernance OpenSource au sein de l'entreprise commence par un "point. libre" en mélangeant allègrement licence de type bsd et gpl.
Il est donc peut être nécessaire, à des fins externes aux paquetages et au système eux mêmes, d'avoir une meilleure granularité directement dans le fichier spec de RPM, permettant de lier avec précison chaque licence de chaque brique. (sinon bonjour le binz pour parser une à une les licences, alors que cela serait très simple et certainement utile, d'avoir cela directement dans le spec sous une forme plus précise que Licences : gplv2, bsd Mais plutot Licence Doc : gfdl Licence lib : lgpl Licence bin gplv2 etc etc).
Mes deux cents.
Donc clairement pour moi ce document fût un régal à lire. Reste à voir comment les entreprises appliquant les recommandations (à mon avis ça ne cible pas que les pme/pmi, si?) vous pouvoir faire du "demerdes toi" au quotidien. Ou si, sous la même impulsion que celle qui a donnée naissance à ce doc, elles pourront disposer d'un outil fin et efficace de gestion des licences OpenSource et de leur interaction. Bref savoir si cela restera un "whitepaper" ou bien si cela sera suivi d'effet, pour par exemple participer aux reflexions actuellement menées au sein de la Linux fondation à ce sujet...
[^] # Re: Ouh là !
Posté par bubar🦥 . En réponse à la dépêche Le Syntec Informatique publie son Guide Open Source. Évalué à 3.
Ce qu'il manque (à mon goût) ce sont des pistes sur la mise en pratique de ces bonnes pratiques :) Certes les outils usuels sont cités (blackduck) mais tout semble rose bombon au pays des fleurs... Or ce n'est pas le cas, il me semble important de souligner également les difficultés liés à ces enjeux, et parfois le coût en terme de temps que peux représenter une bonne gouvernance opensource au sein d'une entreprise. Alors oui bien sûr on est très loin de la *mertitude* des serveurs de licences, mais il y a quant même, ou du moins il peut y avoir, des difficultés en prendre en compte.
Je prends l'exemple de RPM.
Actuellement rpm gère les licences sous la forme d'une simple déclaration unique. Si on fait sale, on colle tout sur une ligne et basta. Si on fait un peu plus propre on va utiliser la possibilité de création de rpm multiples avec un seul spec, et ainsi avoir une granularité plus fine des licences. Très bien. Mais il reste de nombreux cas où ni l'un ni l'autre ne convient. Exemple courant : un projet totalement libre inclu des fichiers sous license apache, une biblio en lgpl, deux futurs binaires en gplv2 strict, et un peu de doc sous gfdl. Ok. Mais tout ceci ne constituera qu'un paquetage unique au final, il n'y a pas d'intérêt à en créer de séparer (mettons que le doc ne soit pas doxy... [dredi])...Là, RPM n'est pas actuellement capable de répondre à cette problématique. En fait, pour être plus précis, il s'en fiche c'est pas son problème. Mais cela peux causer des soucis à la gouvernance OpenSource pour -au moins- faciliter la compatibilité et le suivi des licences utilisées.
Ca fait enculeur de mouche, mon exemple, mais c'est pourtant un exemple très courant. Et perso il ne me semble pas pertinent que la gouvernance OpenSource au sein de l'entreprise commence par un "point. libre" en mélangeant allègrement licence de type bsd et gpl.
Il est donc peut être nécessaire, à des fins externes aux paquetages et au système eux mêmes, d'avoir une meilleure granularité directement dans le fichier spec de RPM, permettant de lier avec précison chaque licence de chaque brique. (sinon bonjour le binz pour parser une à une les licences, alors que cela serait très simple et certainement utile, d'avoir cela directement dans le spec sous une forme plus précise que Licences : gplv2, bsd Mais plutot Licence Doc : gfdl Licence lib : lgpl Licence bin gplv2 etc etc).
Mes deux cents.
Donc clairement pour moi ce document fût un régal à lire. Reste à voir comment les entreprises appliquant les recommandations (à mon avis ça ne cible pas que les pme/pmi, si?) vous pouvoir faire du "demerdes toi" au quotidien. Ou si, sous la même impulsion que celle qui a donnée naissance à ce doc, elles pourront disposer d'un outil fin et efficace de gestion des licences OpenSource et de leur interaction. Bref savoir si cela restera un "whitepaper" ou bien si cela sera suivi d'effet, pour par exemple participer aux reflexions actuellement menées au sein de la Linux fondation à ce sujet...