Articles : Oracle achète Innobase / InnoDB
Posté par Cyril PIERRE de GEYER (page perso, ). Modéré le 12 octobre 2005.
Oracle a annoncé, le 7 octobre 2005, le rachat de la société finlandaise Innobase Oy basée à Helsinki.
Innobase Oy est la société qui développe le moteur de stockage transactionnel InnoDB.
InnoDB est l'un des moteurs de MySQL, on peut donc se demander ce qu'il va se passer par la suite.
Le code d'innoDB est sous deux licences comme celui de MySQL : vous pouvez l'utiliser gratuitement en respectant la licence GPL ou acheter une licence propriétaire sinon.
MySQL a un contrat pour utiliser InnoDB pendant encore plus d'un an donc à court terme rien ne change. Par contre on peut supposer que MySQL investira moins dans InnoDB par la suite.
NdM : merci à Victor STINNER et Rodolphe pour avoir également proposé la news.
NdM2 : Oracle est contributeur de logiciel libre.
Innobase Oy est la société qui développe le moteur de stockage transactionnel InnoDB.
InnoDB est l'un des moteurs de MySQL, on peut donc se demander ce qu'il va se passer par la suite.
Le code d'innoDB est sous deux licences comme celui de MySQL : vous pouvez l'utiliser gratuitement en respectant la licence GPL ou acheter une licence propriétaire sinon.
MySQL a un contrat pour utiliser InnoDB pendant encore plus d'un an donc à court terme rien ne change. Par contre on peut supposer que MySQL investira moins dans InnoDB par la suite.
NdM : merci à Victor STINNER et Rodolphe pour avoir également proposé la news.
NdM2 : Oracle est contributeur de logiciel libre.
Annonce par Oracle (397 hits)
Réaction de MySQL (819 hits)
Site officiel de InnoDB sur lequel on peut lire l'annonce (339 hits)
Oracle (165 hits)
Journal posté par jean-philippe p : Oracle rachete innoDB ! (257 hits)
> Lire la dépêche (31 commentaires, moyenne: 2,6).
Vous avez demandé le commentaire #637713.




foreign key
La fin des foreign key dans MySQL?
[^]Re: foreign key
Pas vraiment, les FK sont prévus dans le format MyISAM pour la verison 5.1... (Ok la 5.0 est encore en RC).
W-Fenec : Webzine rock/métal/indus
[^]Re: foreign key
J'ai assez souvent discuté avec David Axmark, le leader de MySQL. La dernière fois, c'était aux RMLL à Dijon. Je lui parle toujours des contraintes d'intégrité que j'apprécie et utilise avec Postgresql et il me répond depuis 5 ans que c'est l'un de ses soucis.
MySQL n'a pas mis tous ses ½ufs dans le même panier (voir http://linuxfr.org/2003/05/27/12602.html(...) ) : SAPDB, le moteur de base de données de SAP est géré maintenant par MyQL.
David m'a dit qu'il voulait faire converger MySQL de SAPDB de façon à ne faire plus qu'un seul produit. Mais il lui faudra plusieurs années pour y arriver. Je crois qu'il m'avait parlé de 5 ans.
[^]Re: foreign key
SAPDB, le moteur de base de données de SAP est géré maintenant par MyQL.
C'est bien ce qui m'inquiéte dans ce rachat. Il ressemble fort à une nouvelle attaque de Oracle sur SAP. Oracle n'a rien a faire de InnoDB, il veut juste porter des coups à SAP. SAP est son plus gros rival sur un des marchés que Oracle veut dominer depuis longtemps sans y parvenir à savoir les applications de gestion d'entreprise.
[^]Re: foreign key
non, un fork d'innodb est possible... le problème c'est que si oracle décide de ne pas renouveler la collaboration innodb/mysql, il sera impossible pour mysql de fourguer des licences non-gpl du moteur innodb...
... et je vois mal mysql abandonner sa version non-libre...
[^]Re: foreign key
A ce que j'ai pu comprendre on peut s'attendre a ce que MySQL créé son propre moteur.
Mais c'est encore trop tôt pour savoir.
Co auteur du livre PHP 5 avancé
http://www.amazon.fr/exec/obidos/ASIN/2212121679/
[^]Re: foreign key
"L'interêt" de la version non libre de MySQL est de contourner la GPL. Le client peut donc inclure et distribuer MySQL avec son produit sans avoir à distribuer son code source.
Le but de MySQL est d'être ainsi utilisé chez des clients potentiels au niveau support et/ou formation.
[^]Re: foreign key
Pourtant je me suis relu ...
"Le but de MySQL est d'être ainsi utilisé chez des clients potentiels afin de leur vendre du support et/ou des formations."
C'est plus clair ?
[+] [^]Re: foreign key
non, sans blagues?
mais où veux-tu en venir?
[^]Re: foreign key
Mysql revend surtout sa technologie sous une autre license que le gpl pour que des sociétés commerciales puissent intégrer le système db de mysql dans leurs produits sans avoir à publier leur code en gpl.
Le fait d'avoir un moteur de db de mysql qu'ils ne peuvent plus revendre sous license propriétaire entraînerait vraissemblablement le rejet de ce module de l'arbre de développement officiel de mysql puisqu'ils ne pourraient plus le diffuser via une license propriétaire.
Et je ne vois toujours pas où tu voulais en venir.
[^]Re: foreign key
En fait je crois que ce que je voulais dire, c'est que les $$$ que MySQL essaye de se faire, ils le font sur le support et la formation bien plus que sur la licence.
Cette double licence n'est là que pour empêcher le "rejet" comme tu dis par les "grands comptes" qui sont les gros clients pour les services (supports & formations).
[^]Re: foreign key
Bon, ok, un cours de lecture s'imposepour toi, je n'ai jammais parlé de "rejet" par des grands comptes...
Pour ce qui est de la formation, ce n'est absolument pas lié à l'achat d'une license commerciale de mysql, va voir sur le site de mysql ab au lieu de raconter n'importe quoi.
Il est vrai que chez mysql, le fonctionnement de la license commerciale semble obscure depuis leur site, toutefois, on peut y lire
Donc on voit bien que la license commerciale a un but premier qui est la redistribution d'application commerciales tierces sous une license non-libre. InnoDB fait pareil, et pour que MySQL AB puisse vendre des licenses non libres de MySQL, il faut que tous les composants puissent être redistribués sous les termes de la license non libre. Si du jour au lendemain Innobase/Oracle décide de ne plus vendre de license commerciale à Mysql AB, MySQL AB se retrouve dans l'impossibilité de sous-licensier InnoDB dans la version non-libre de Mysql.
Pour les entreprises qui ne sont que utilisatrices de mysql, un produit sous gpl est parfaitement acceptable, tant qu'il y a du support.
Par contre, pour une société qui prend la license commerciale pour revendre mysql dans une application commerciale, c'est un vrai problème, surtout si ils utilisaient innodb. Pour ces clients là, Mysql AB est obligé de remplacer InnoDB au plus vite par quelque-chose de compatible avec la license non-libre.
[^]Re: foreign key
> Pour ce qui est de la formation, ce n'est absolument pas lié à l'achat
> d'une license commerciale de mysql, va voir sur le site de mysql ab
> au lieu de raconter n'importe quoi.
Je n'ai pas dit que la vente était lié, on se retrouve au cours de lecture ?
Je dis juste, et désolé si je ne suis pas ultra-limpide, que le pourcentage du chiffre d'affaire de MySQL AB que représente la vente de licence non libre est inférieur (nettement) au pourcentage que représente la vente de service.
Pour le reste on est d'accord, y a pas de soucis ragoutoutou !
Ils pourront *evidemment* continuer à vendre du support aux entreprises qui utilisent MySQL sans le redistribuer ou l'inclure dans leurs produits.
Je veux juste mettre en avant que ce n'est pas la vente de licence non libre qui fait vivre MySQL AB.
[^]Re: foreign key
Pour commencer, tu as écrit celà, ce qui a peu de sens dans le contexte où ça a été écrit...
puis tu as rectifié
Ce qui reste à côté de la plaque par rapport au sujet puisque on parlait de la disparition possible d'innodb de l'arbre de développement de MySQL si innodb n'y avait plus de license compatible avec la licence non-libre...
Le fait que MySQL AB se fasse des thunes avec la consultance ou la formation n'a aucun rapport avec le sujet. C'est presque comme si je disais "Le dernier asterix n'est pas bon du tout, il serait temps qu'il reprenne un vrai scénariste où qu'il arrète" et que toi tu me répondais "Oui mais Uderzo a mangé un steak ce midi" puis, après que je t'ai demandé le rapport, tu me répondais "ce que je voulais dire c'est que le steak c'est bon".
Petit problème de logique, plus que de lecture donc...
[^]Re: foreign key
Ecoute Gérard, si je suis tellement à coté de la plaque, t'es pas obligé de me répondre. Tu cliques sur "inutile" dans la phrase "Ce commentaire est-il pertinnent ou inutile" et basta.
MySQL se fait de la thune avec des services (bien plus qu'avec les licences). Pour vendre ces services à des gens qui ont besoin de ne pas utiliser la GPL (et qui sont de gros clients), ils vendent aussi MySQL en licence propriétaire. C'est bien ça leur logique ? Si ils ne peuvent plus inclure InnoDB dans MySQL version propriétaire, ils perdent ces clients qui n'achèteront plus ni la licence ni les services Effectivement c'est ballot pour MySQL ! C'est tout, je voulais juste en rajouter une couche sur ce que tu dis ... Ca va dans le *même* sens que ce que tu disais ! (Si si je t'assure, mais c'est pas grave si t'en es pas convaincu ...)
Pour nous autres utilisateurs de la version GPL, on s'en bat, on peut toujours utiliser InnoDB tel quel, ou un fork éventuel ... On peut juste s'inquiéter de la santé (financière) de MySQL AB.
(Et ton analogie avec Asterix est pour le moins bancale ...)