Bonjour Claire et tous,
Le 08/09/2020 à 14:41, Ocleyr2lalune a écrit :
Bonjour
Le mardi 08 septembre 2020 à 12:09 +0200, sophi a écrit :
Bonjour Thierry,Le 08/09/2020 à 10:28, Thierry Jeanneret a écrit :
Bonjour Claire,
Je ne vais pas reprendre point par point.
Moi non plus, je saute donc au modèle économique :
Merci de revenir à ce point.
Justement, je n'arrive pas à voir ce qu'implique concrètement
d'accorder une licence d'utilisation de la marque pour les entreprises
de l'écosystème ?
Cela signifie-t-il que le code restant ouvert, pour republier en tant
que LibreOffice, il faut une licence d'utilisation ? Est-ce raccord
avec les licences actuelles de LibreOffice ?
Il faut distinguer la marque du code. Pour essayer d'expliquer
simplement : La marque LibreOffice est déposée et appartient donc à TDF.
Le code de LibreOffice est sous les licences MPL/LGPL et est donc ouvert
et réutilisable sous les conditions de ces licences, mais la compilation
de ce code fournie par TDF ne peut pas s'appeler LibreOffice s'il est
compilé ou modifié par une autre entreprise.
L'exception c'est lorsqu'il y a un agrément d'utilisation du nom de la
marque entre TDF et l'entreprise. Comme c'est le cas pour CIB et Collabora.
Cela ne favoriserait-il pas le développement de fork (bien/pas bien ?)
pour ceux qui n'ont pas cette licence d'utilisation ?
S'il n'y a pas d'agrément d'utilisation de la marque entre TDF et
l'entreprise qui fournit une suite LibreOffice, alors c'est un autre
produit qui doit porter un autre nom. Cela ne pause pas de problèmes si
c'est un fork assumé (chacun vit sa vie de son côté) c'est plus un
problème quand on utilise la notoriété de LibreOffice alors que la
version fournie n'a pas la même couverture fonctionnelle ou la même
vigilance sur la sécurité.
Comment les entreprise de l'écosystème vont réaliser ces
développementssans nouvelle version et sans être financées par leurs
clients ?Pourquoi les clients paieraient pour la correction de
bugs/régressionsqu'ils ne rencontrent pas ?
Cela me fait penser à la question du support étendu (ou LTS).
Aujourd'hui c'est bien la 6.4 qui peut être déployée en entreprise,
mais on est en revanche quasi au bout des mises à jour correctives pour
la 6.4.
L'intérêt du support étendu que ces entreprises pourraient assurer
(grâce à la licence d'utilisation ?) serait que leurs clients
pourraient bénéficier de correctifs sur une 6.4 pendant plus longtemps
(correctifs demandés par les dits clients).
Il me semble nécessaire de définir la durée max de ce support étendu
(n'est-ce pas déjà le cas, d'ailleurs ?)
Cela devrait aussi impliquer (via la licence d'utilisation de la marque
?) que ces correctifs, soient également portés dans les versions plus
récentes s'ils ne le sont pas déjà. Dans ce cas, les travaux pour les
clients des entreprises parties prenantes LibreOffice, bénéficieraient
à tous, dans la logique de l'open source.
Enfin, quand un client demanderait un ajout de fonctionnalité, cela
pourrait être en revanche conditionné à la mise en place sur une
version récente (par exemple aujourd'hui la 7).
Pour répondre à toutes ces questions, c'est effectivement ce qui se
passe si l'on prend l'exemple de Collabora. Ils fournissent un support
LTS sur 3 ans qui peut être étendu à 5 ans. Les corrections apportées
sont reversées au tronc commun (TDF/LibreOffice). Les nouvelles
fonctionnalités (telles que le caviardage par exemple) ne peuvent être
implémentées que sur une version majeure (7.0 par exemple, la branche
6.4.x n'acceptant pas de nouvelles fonctionnalités, que des patchs
correctifs).
Cela éviterait de cantonner les entreprises de l'écosystème à une
maintenance de vieille version, et donnerait de l'intérêt à tous.
Cela pourrait aussi aider sur la prise en charge de vieilles anomalies
pas prise en charge car il y a un différentiel entre la version
déployable en entreprise et celle qui fait l'objet de la majorité des
développements à un moment t.
Sauf que cela ne fonctionne pas parce qu'il n'y a pas assez
d'entreprises autour de LibreOffice qui participent comme Collabora. Et
donc le support se fait sur ce dont a besoin leur client et cela laisse
toute une cargaison de bugs et de régressions de côté. Les entreprises
qui corrigent des bugs uniquement pour leurs clients, sans reverser au
tronc commun rendent leur client, TDF et l'écosystème perdants.
Les utilisateurs donnent à la Fondation et pas suffisemment aux
entreprises de l'écosystème.
C'est la réflexion qui est menée actuellement via le plan marketing. Et
les questions que j'ai posées à Thierry sont pour appeler de vraies
réponses. Ce modèle que nous avons construits depuis 10 ans montre des
dysfonctionnements. La communauté ne va pas les laisser ainsi, nous
tenons tous à la fondation et à ses valeurs.
Mais il faut partir de la réalité de la fondation et de ses statuts, de
LibreOffice et de l'environnement économique qui est autour. Tout en
continuant de développer la communauté, en laissant assez de liberté aux
contributeurs tout en les accompagnant, etc.
Autant les changements de versions correctives doivent être assez
"simple" à déployer en entreprise, autant un changement de version
demande un peu plus de vigilance, il doit donc être moins fréquent.
Sauf qu'ici on ne parle pas du tiroir caisse de TDF mais de celui
deceux qui écrivent le code de LibreOffice. Quelle solution pour
obligerces entreprises à travailler pour TDF/LibreOffice plutôt que
pour leursclients ?
Il y a l'idéal et la réalité, mais tu sous entend qu'on arrive à la
situation ou le développement est quasi exclusivement porté par ces
entreprises (et donc qu'il faut les "obliger" à travailler pour
LibreOffice) ?
Oui, environ 80% du développement est fait par Collabora et CIB. Les 20%
restant étant d'autres entreprises, des bénévoles ou Google Summer of
Code. Il n'y a pas de code écrit par TDF (ou très peu et pas directement
dans le coeur de LibreOffice comme les unit tests par exemple).
Même si je l'ai lu attentivement le doc en question que tu as fourni il
y a quelques jours, je suis restée sceptique, sur cette nouvelle entité
"TDC". J'ai du mal avec le commercial à but non lucratif, le
reversement, et les interactions décrites...
Pourquoi faut-il une entité distincte pour gérer les applicatifs TDF
(visionneuse Impress, Applis smartphone...) ?
Il y a plusieurs raisons à cela. TDF a de l'argent (voir les détails
dans le rapport d'activité
https://nextcloud.documentfoundation.org/s/LEat3j6nepdggNk#pdfviewer).
TDF a l'obligation de dépenser dans les deux ans l'argent qui entre.
L'une des raisons déjà évoquée est la difficulté à mener des appels
d'offres par TDF : difficulté techniques de formulation, difficulté
parce que conflits d'intérêts, difficulté d'évaluation finale, etc.
Une autre est la structure légale même des stores qui vient en conflit
avec les statuts (je n'ai pas tous les détails en tête) et qui empêche
de publier.
TDF a déjà une société attachée pour certaines opérations commerciales,
mais elle ne suffit pas. D'où le besoin de trouver une structure
indépendante de la fondation, qui soit quand même sous le contrôle de la
fondation. La structure juridique de cette société n'est pas encore
décidée. Ce ne sera visiblement pas une coopérative, d'autres statuts
sont à l'étude comme cette Société à Impact Sociétal au Luxembourg.
Comment se place DLP(Liberation Project...) là dessus ? Car c'est un
projet moins connu, mais travailler sur l'interopérabilité, ce n'est
pas rien, et les entreprises et particulièrement les administrations
clientes pourraient justement avoir un intérêt sérieux sur le sujet....
Document Liberation Project est un projet de TDF tout comme l'est
LibreOffice. La différence c'est que ce sont des bibliothèques qui sont
produites et non des binaires. L'intérêt est surtout pour les autres
communauté open source afin d'intégrer les bibliothèques à leur produit,
les utilisateurs directs sont très peu concernés.
En espérant avoir apporté quelques éclaircissements sur le
fonctionnement de TDF et du projet LibreOffice ainsi que son avenir.
À bientôt
Sophie
--
Sophie Gautier sophi@libreoffice.org
GSM: +33683901545
IRC: sophi
Foundation coordinator
The Document Foundation
--
Envoyez un mail à discuss+unsubscribe@fr.libreoffice.org pour vous
désinscrire
Les archives de la liste sont disponibles à
https://listarchives.libreoffice.org/fr/discuss/
Privacy Policy: https://www.documentfoundation.org/privacy