j_camelet
Ca veut dire que Oracle peut petit à petit bugger MySQL et/ou le rendre moins performant

En théorie, ils peuvent le faire. En pratique, je pense que le pire qu'ils puissent vraiment faire, c'est ne plus faire évoluer la chose.
Parce que si ils s'amusent à le pourrir :
- les utilisateurs vont remarquer la dégradation, et forcément, la mettre sur le dos d'Oracle => pas bon pour l'image d'Oracle, et ceux qui abandonneraient MySQL à cause de ces dégradations auront forcément tendance à se tourner vers des concurrents d'Oracle,
- comme c'est open-source, y a forcément des gens qui vont regarder les évolutions du code, et remarquer si Oracle le dégrade volontairement.

j_camelet
La base de SQL est-elle libre auquel cas on peut voir apparaitre des projets sur SourceForge ou bien c'était une création de Sun et la license sera à Oracle uniquement ?

Initialement, c'est même pas Sun en fait. C'est MySQL AB qui a créé MySQL et là developpé pendant une douzaine d'années avant de se faire racheter par Sun l'année dernière.
Pour la licence, c'était proprio au début, mais depuis la version 3 c'est sous GPL.
Donc dans le pire des cas, si Oracle décide de foutre en l'air MySQL, ça pourra toujours être forké par la communauté pour créer un nouveau SGBD à partir de MySQL.

j_camelet
Désolé de ma question, mais en fait je sais même pas ce qu'est SQL pour être franc

SQL c'est un langage utilisé pour manipuler des bases de données. À priori, je dirais que c'est le plus utilisé, vu que MySQL est le SGBD gratuit le plus répandu, et que les gros SGBD commerciaux (Oracle, DB2, Microsoft SQL...) utilisent tous SQL.
Et MySQL donc, c'est un SGBD utilisant SQL, et qui est très répandu, entre autres parce qu'il s'entend bien avec PHP.

Si ça disparaissait, ça foutrait pas mal le bordel. Mais ça ne serait pas non plus insurmontable de le remplacer par un autre SGBD, dans la mesure où c'est du SQL, les impacts sur le code des applis cliente serait relativement limité. En gros, ça modifie la façon de se connecter au serveur de données et de lui envoyer des requêtes, mais dans la majorité des cas, ça ne modifie pas les requêtes elles-mêmes, et actuellement la plupart des applis un peu volumineuses qui ont besoin d'une BDD passent de toute façon par une couche d'abstraction, et peuvent quasiment passer d'un SGBD à un autre en un clic de souris.

Le "en un clic" est bien sûr un peu exagéré. Mais de nos jours, un éditeur un minimum sérieux ne va plus taper directement dans une BDD à partir d'une appli métier. Y a toujours une couche d'abstraction, que ça soit une couche d'assez bas niveau (ODBC, JDBC...), ou quelque chose de beaucoup plus haut niveau, éventuellement spécifique à l'application (dans ce cas, faut bien entendu développer une couche d'abstraction adaptée au nouveau SGBD, mais sans impact sur le cœur de l'appli).

Perso j'ai jamais vu une grosse appli métier qui passe pas par une couche d'abstraction, et je peux te dire que j'ai déjà vu des applications critiques (genre SI de gros opérateur télécom) passer d'un SGBD à un autre en moins d'une semaine de boulot. J'ai même déjà vu des applis qui tournent sur MySQL sur les machines de dev (pour des raisons de coût), avant de passer à DB2 sur les serveurs d'intégration et les serveurs de prod.

Ça me viendrait même pas à l'idée de développer une appli sans passer par un équivalent de ODBC/JDBC pour les accès BDD... sauf justement pour un site perso ^^

Après, quand il y a impossibilité de passer d'un SGBD à un autre, c'est souvent parce que c'est des applis liés à des SGBD offrant des fonctionnalités ne faisant pas partie des normes SQL (genre le PL/SQL d'Oracle, qu'on ne retrouve évidement pas dans DB2 ou MS SQL) ou faisant partie de normes très récentes, encore peu implémentées dans les différents SGBD SQL. Mais c'est rare d'avoir ce genre de spécificités sur des applications utilisant MySQL...