Chris DiBona, Google : « Chaque fois que vous utilisez Google, vous exploitez une machine qui exécute Linux. »

Quels sont les projets open source les plus importants que vous gérez ?
Le noyau, les compilateurs, GCC, l'interpréteur Python. Python est très important pour nous. Google App Engine, par exemple, n'est ni plus ni moins qu'un système d'hébergement en Python. Java est également très important pour nous, et passe aussi en open source maintenant. Nous avons des spécialistes aguerris de Java qui travaillent pour nous, comme Josh Block ou Neil Gafter ; ils connaissent parfaitement bien cette technologie.

Outre ces trois projets (les compilateurs, les langages et le noyau), nous avons les bibliothèques. Pour nous, il s'agit d'OpenSSL, zlib et PCRE. MySQL est primordial pour nous. En dehors de cela, les autres projets ont une ampleur nettement moindre.

L'ouverture du code source de Java a-t-elle changé quoi que ce soit pour vous ?
Pas vraiment. Je pense que l'impact a été plus grand sur le monde extérieur que pour nous. Java est un langage relativement mature à présent. Nous l'utilisons depuis longtemps. Autrefois, il y avait le JCP (Java Community Process, une organisation créée pour coordonner l'évolution de Java) qui s'intéressait au facteur d'ouverture. Mais l'ouverture n'a jamais été aussi marquée qu'aujourd'hui. Des questions se posent sur ce que l'open source implique vis-à-vis de Java, notamment J2ME (l'édition mobile de Java pour des appareils tels que les téléphones cellulaires) et le TCK (le kit de compatibilité des technologies).

Utilisez-vous un noyau Linux ultrapersonnalisé ou plutôt la version standard ?
Je ne crois pas que les noyaux Linux personnalisés existent encore. Le noyau est tellement flexible, il intègre tellement d'architectures différentes... Je pense que le noyau Linux à proprement parler est déjà ultrapersonnalisé.

Mais procédez-vous à de nombreuses personnalisations en interne ?
Pas vraiment. Google a l'occasion de découvrir du matériel intéressant avant le reste du monde. Alors en interne, nous allons tester du code pour ce matériel. À ce stade, on peut parler de personnalisation. Mais ce code finit par être livré au reste du monde. Nous avons financé des activités avec un groupe de développeurs de l'université de Berkeley, baptisé Xorp, pour intégrer des fonctionnalités de carte réseau Broadcom haut débit dans Linux. Il n'est pas dans notre intérêt d'en exercer le contrôle nous-mêmes. Alors peut-on parler de personnalisation ? Absolument. Mais une personnalisation importante ? À mon avis, pas autant que ce que vous pourriez croire.

Est-il exact que vous utilisez toujours des noyaux 2.4 ?
Oui, à certains endroits.

Dans quelle proportion, pour le produit de recherche principal ?
Je ne sais pas comment il est partitionné. Lorsque vous pensez à Google, vous pensez à la recherche qui repose sur un noyau qui est statique. Il n'en va pas toujours ainsi. Les choses sont différentes pour les centres de traitement de données. Je pense néanmoins que la version 2.6 est prédominante.

Quelles sont vos licences favorites ?
Nous publions généralement sous la licence Apache, plus précisément Apache 2. Nous pensons qu'elle est, parmi les licences, la plus juste. La licence GPL nécessite beaucoup de gestion, plus que le temps dont nous disposons pour exécuter un projet correctement sous cette licence (flux des correctifs, etc.). Apache 2 encourage les utilisateurs à s'approprier le code. C'est ce que nous recherchons lorsque nous publions du code, que ce soit pour que les gens adoptent les technologies que nous aimons vraiment ou pour des exemples d'API. Cela dit, nous avons publié des choses sous les licences GPL, LGPL, GPL version 3 et BSD. Mais par défaut, nous optons pour la licence Apache.

Vous utilisez beaucoup l'open source en interne. Étudiez-vous au préalable les questions de propriété intellectuelle ?
Effectivement, et nous procédons de deux manières différentes. Quand quelqu'un veut amener du code venant de l'extérieur (open source ou commercial), il doit le mettre dans un répertoire spécial que nous appelons « tiers ». Il doit également y mettre un fichier appelé « readme.google », qui décrit où il a trouvé ce logiciel, les modalités de licence et à quelle catégorie appartient cette licence. Nous n'acceptons que ce qui a une origine sûre. Il existe des projets qui ont une provenance douteuse en matière de propriété intellectuelle, et nous les connaissons, nous connaissons les personnes qui les exécutent, et nous veillons à ne jamais les utiliser.