Je ne répondais pas au journal mais au commentaire précédent.
Que cela puisse avoir une utilité pour la boîte qui l’exige, oui, bien sûr.
Mais que cela soit propice au logiciel ou au développement d’une communauté, c’est une autre affaire.
OpenOffice.org exigeait la signature d’un CA, ainsi que l’écriture de spécifications pour les nouvelles fonctionnalités. C’était assez procédurier.
Le build était réputé compliqué sur Linux et super chiant sur Windows.
Ajoutons à cela que le code d’OOo était typique du plat de spaghettis difficile à démêler (et que pas grand-chose n’était fait pour y remédier).
Rien n’était fait pour faciliter les contributions extérieures au code, et Sun y semblait même réticent. Remonter des patchs upstream, c’était lent et compliqué, semble-t-il. Ce n’est pas pour rien qu’il y avait un fork nommé Go-OO.
Sun/Oracle ne sont jamais allés aussi loin que ce que décrit le journal, mais on était dans une situation intermédiaire où il y avait une volonté forte de garder la mainmise sur le produit en limitant les contributions au code (mais pas sur le reste).
Donc, pour citer le journal, rien de simple pour ceux qui avaient «besoin de modifier ces logiciels tiers, pour gérer un cas spécifique». Et c’était voulu.
À la naissance de LibreOffice, les premières choses faites ont été :
— supprimer le Contributor Agreement (à la place on spécifie juste la licence du patchs et la plupart des dévs déclarent que tous leurs patchs présents et à venir sous la licence de LO),
— oublier l’exigence d’écrire des spécs,
— simplifier les procédures de build,
— simplifier le code (procédure qui a pris des années, des millions de lignes de code supprimées).
Apache aussi a fait de même pour OpenOffice (dans une moindre mesure, faute d’un nombre suffisant de contributeurs).
Le code d’OOo a fait l’objet d’une guerre larvée entre Sun/Oracle, Novell, IBM, avec des intentions affichées pas toujours très claires, guerre qui s’est poursuivie dans une certaine mesure entre TDF et Apache. (C’est IBM qui a poussé Oracle à publier OOo sous licence Apache, après son abandon par Oracle, suite au fork LibreOffice. IBM, pour rappel, produisait un fork d’OOo nommé Lotus Symphony, mais a toujours été réticent à reverser les patchs upstream à Sun, pour les raisons qu’on devine. On peut présumer que la licence Apache convenait mieux à IBM pour produire un fork payant sans avoir nécessairement à reverser les sources.)
[^] # Re: HS CLA
Posté par Olivier . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 5.
Je ne répondais pas au journal mais au commentaire précédent.
Que cela puisse avoir une utilité pour la boîte qui l’exige, oui, bien sûr.
Mais que cela soit propice au logiciel ou au développement d’une communauté, c’est une autre affaire.
OpenOffice.org exigeait la signature d’un CA, ainsi que l’écriture de spécifications pour les nouvelles fonctionnalités. C’était assez procédurier.
Le build était réputé compliqué sur Linux et super chiant sur Windows.
Ajoutons à cela que le code d’OOo était typique du plat de spaghettis difficile à démêler (et que pas grand-chose n’était fait pour y remédier).
Rien n’était fait pour faciliter les contributions extérieures au code, et Sun y semblait même réticent. Remonter des patchs upstream, c’était lent et compliqué, semble-t-il. Ce n’est pas pour rien qu’il y avait un fork nommé Go-OO.
Sun/Oracle ne sont jamais allés aussi loin que ce que décrit le journal, mais on était dans une situation intermédiaire où il y avait une volonté forte de garder la mainmise sur le produit en limitant les contributions au code (mais pas sur le reste).
Donc, pour citer le journal, rien de simple pour ceux qui avaient «besoin de modifier ces logiciels tiers, pour gérer un cas spécifique». Et c’était voulu.
À la naissance de LibreOffice, les premières choses faites ont été :
— supprimer le Contributor Agreement (à la place on spécifie juste la licence du patchs et la plupart des dévs déclarent que tous leurs patchs présents et à venir sous la licence de LO),
— oublier l’exigence d’écrire des spécs,
— simplifier les procédures de build,
— simplifier le code (procédure qui a pris des années, des millions de lignes de code supprimées).
Apache aussi a fait de même pour OpenOffice (dans une moindre mesure, faute d’un nombre suffisant de contributeurs).
Le code d’OOo a fait l’objet d’une guerre larvée entre Sun/Oracle, Novell, IBM, avec des intentions affichées pas toujours très claires, guerre qui s’est poursuivie dans une certaine mesure entre TDF et Apache. (C’est IBM qui a poussé Oracle à publier OOo sous licence Apache, après son abandon par Oracle, suite au fork LibreOffice. IBM, pour rappel, produisait un fork d’OOo nommé Lotus Symphony, mais a toujours été réticent à reverser les patchs upstream à Sun, pour les raisons qu’on devine. On peut présumer que la licence Apache convenait mieux à IBM pour produire un fork payant sans avoir nécessairement à reverser les sources.)