Résumé

  • La politique de mars 1993 maintenait la gratuité pour les établissements d’enseignement supérieur et les associations à but non lucratif qui donnaient librement accès à leurs informations, tout en prévoyant des licences négociées pour certains usages commerciaux du logiciel universitaire.
  • Dans le même message, l’équipe distinguait ces conditions du protocole documenté et rappelait que d’autres clients et serveurs Gopher existaient déjà ou pouvaient être développés.

Analyse historique

La note du 11 mars se lit comme une grille de cas, pas comme une interdiction générale. Les établissements d’enseignement supérieur et les associations sans but lucratif qui mettaient leurs informations gratuitement à disposition sur Internet ne devaient rien changer à leurs pratiques. Pour les entreprises qui utilisaient Gopher en interne, l’équipe estimait qu’une licence payante était justifiée, mais n’avait fixé aucun montant : elle souhaitait négocier au cas par cas et envisager une échelle adaptée à la taille de l’entreprise. Un serveur vendant ses informations aurait pu payer une petite part de ses ventes.

Enfin, un serveur commercial librement accessible se situait dans une zone grise : son exploitant pouvait défendre l’utilité publique de son contenu et demander une licence gratuite.

Le mot important était donc moins « tarif » que « négociation ». La Minnesota Gopher Team reconnaissait qu’une liste de prix identique pour une petite société et un grand groupe pouvait être injuste. Mais elle ne publiait pas non plus de critères automatiques permettant de bénéficier de la gratuité. Dans le cas d’un service commercial ouvert au public, l’entreprise devait faire valoir que ses ressources apportaient un bénéfice collectif plutôt qu’un avantage direct à sa seule activité. La décision revenait à l’Université.

Cette politique concernait l’utilisation du logiciel de l’University of Minnesota. Elle ne créait pas de péage pour chaque connexion Gopher et ne retirait pas aux organisations le droit de publier des informations commerciales. Le texte sépare explicitement la question du logiciel de celle du protocole. Il indique que le protocole Internet Gopher est documenté, qu’un RFC informatif est presque terminé, et que d’autres équipes ont écrit des clients et des serveurs. Le RFC publié en mars, RFC 1436, se présente comme informatif, et non comme une norme Internet. Sa diffusion est illimitée ; il décrit le protocole et les grandes lignes permettant de développer de nouvelles implémentations.

Cette distinction ne rend pas le programme universitaire accessoire. Une spécification publique ne paie pas les personnes qui portent un logiciel vers plusieurs systèmes, corrigent les défauts, répondent aux utilisateurs ou font évoluer le produit. Mais elle permet d’identifier le périmètre de l’autorité : Minnesota pouvait définir les conditions d’emploi du logiciel dont elle détenait les droits; elle ne pouvait pas, par cette seule politique, imposer les mêmes conditions à toutes les implémentations du protocole. La spécification, le code de l’Université et l’équipe qui le maintenait étaient trois réalités liées, mais non interchangeables.

La justification avancée était institutionnelle. L’Université réduisait ses budgets, expliquait l’équipe, et il devenait difficile de défendre des moyens croissants pour Gopher sans retombées pour l’établissement. Un serveur apportant des informations utiles à l’Internet pouvait aussi enrichir les ressources accessibles à la communauté universitaire. À l’inverse, un service commercial fermé ou conçu d’abord pour générer des revenus était plus difficile à financer sur fonds universitaires.

La politique cherchait à faire contribuer les usages dont le bénéfice semblait privé tout en préservant les cas éducatifs, associatifs et publics qu’elle jugeait collectifs.

Le calendrier invite à rapprocher ce débat de celui du Web. Le 30 avril 1993, le CERN a placé le logiciel du World Wide Web dans le domaine public, puis a diffusé une version sous licence ouverte. Ce contraste entre décisions de diffusion est réel. Il ne démontre pas que la licence de Minnesota a fait décliner Gopher ou que le choix du CERN explique à lui seul l’essor du Web. Le CERN parlait de son logiciel Web; le message de Minnesota portait sur les conditions d’usage d’une implémentation universitaire précise et prévoyait des licences gratuites dans certains cas.

Ni l’un ni l’autre de ces actes ne constitue, à lui seul, une mesure des déploiements.

En 2001, Mark McCahill, qui dirigeait l’équipe Gopher, est revenu sur l’épisode dans un entretien d’histoire orale du Charles Babbage Institute. Il se souvient de budgets universitaires serrés, d’une équipe de cinq ou six personnes et d’un besoin de récupérer une partie des dépenses engagées pour un travail presque à plein temps. Il dit aussi que plusieurs licenciés commerciaux ont contribué à maintenir le développement. Dans le même entretien, il évoque d’autres pressions : Mosaic déplaçait l’attention vers le navigateur de bureau, tandis que les démonstrations publiques et les conférences prenaient du temps de programmation. C’est un témoignage rétrospectif, pas une série statistique d’adoption; il rend toutefois peu crédible une explication monocausale selon laquelle « la licence a tué Gopher ».

Les documents établissent une politique de licence négociée et la justification que l’équipe lui donnait. Ils ne disent pas combien les entreprises ont payé, combien de serveurs ont été concernés, si l’usage de Gopher a baissé après mars 1993, ni si un client a changé de technologie à cause d’un contrat précis. L’existence d’implémentations alternatives ne prouve pas non plus qu’une migration était facile.

La conclusion étayée est plus étroite : Minnesota voulait obtenir une contrepartie pour l’usage commercial de son propre logiciel, tout en maintenant la gratuité pour certains services publics ou associatifs et en reconnaissant que le protocole pouvait être implémenté ailleurs.

La frontière compte pour l’histoire des infrastructures. Une spécification peut laisser les choix futurs aux opérateurs; encore faut-il qu’une autre équipe puisse écrire, déployer et entretenir une solution fonctionnelle. Une licence sur un programme modifie l’économie de cette mise en œuvre sans fermer nécessairement le protocole. Pour savoir si cette séparation a protégé l’interopérabilité en pratique, il faudrait des données sur les déploiements, la portabilité et la maintenance, que l’annonce de 1993 ne fournit pas.

Sources