Ça a été expliqué publiquement, tu trouvera les discussions à ce sujet dans les archives de la mailing-list misc@. Entre autres raisons:
- C'est un projet BSD, celà signifie qu'il privilégie les licences les moins contraignantes possible. La licence d'apache 1.3 était très acceptable pour la communauté BSD, mais celle d'apache 2.x impose des contraintes plus strictes (raison aussi de la décision d'abandonner, à peut près à la même époque, XFree86 pour x.org).
- En outre les devs d'Open n'aiment pas les licences longues et compliquées, et préfèrent maintenant les licences à la MIT/X11/ISC (plus facile à comprendre sans ambiguité, surtout pour des non-juristes).
- L'apache inclus dans leur système avant le changement de licence était déjà largement modifié pour sécurisation (révocation des privilège plus stricte, chroot par défaut des processus fils etc.) et convenait suffisament bien au projet et à ses utilisateurs.
- Certainsdeveloppeurs d'OpenBSD attendaient une bonne occasion pour ne plus avoir a suivre l'évolution d'apache (merger les nouvelles versions), pour avoir la latitude de faire de plus grosses modifications dans l'arbre des sources, comme: virer les wrappers ap_* afin de faciliter l'audit et la relecture du code, assainir le traitement des chaines et des signaux etc ... toujours dans l'objectif d'améliorer la sécurité du serveur httpd.
Les résultats concrets sont déjà visibles. Par exemple leur version d'apache n'était pas affectée par la récente faille CAN-2004-0700, ce bug ayant été corrigé bien avant dans l'arbre des sources d'OpenBSD lors d'une série d'audits/renforcements/nettoyages de routine sur le traitement des chaines dans apache (cf. le commit sur ssl_engine_ext.c qui corrige cette faille: revision 1.10, date: 2003年06月01日 15:53:41; author: deraadt; "various format string cleanups; tedu ok"). Il y a d'autres exemples de ce type.
Bref, maintenir une fork d'apache 1.3 (sans casser l'API, pour rester compatible avec les modules externes) était la solution la plus pertinente étant donné leurs priorités (préférences pour les logiciels aux licences très permissives, priorité à la sécurité et l' "auditabilité" stricte du codeplutôt qu'aux fonctionnalités amenées par la version 2) de la même façon que de nombreux admins préfèrent apache 1.3 pour sa robustesse éprouvée.
[^] # Re: La license d'Apache 2
Posté par herodiade . En réponse à la dépêche Sortie de Apache 2.2.0. Évalué à 10.
- C'est un projet BSD, celà signifie qu'il privilégie les licences les moins contraignantes possible. La licence d'apache 1.3 était très acceptable pour la communauté BSD, mais celle d'apache 2.x impose des contraintes plus strictes (raison aussi de la décision d'abandonner, à peut près à la même époque, XFree86 pour x.org).
- En outre les devs d'Open n'aiment pas les licences longues et compliquées, et préfèrent maintenant les licences à la MIT/X11/ISC (plus facile à comprendre sans ambiguité, surtout pour des non-juristes).
- L'apache inclus dans leur système avant le changement de licence était déjà largement modifié pour sécurisation (révocation des privilège plus stricte, chroot par défaut des processus fils etc.) et convenait suffisament bien au projet et à ses utilisateurs.
- Certainsdeveloppeurs d'OpenBSD attendaient une bonne occasion pour ne plus avoir a suivre l'évolution d'apache (merger les nouvelles versions), pour avoir la latitude de faire de plus grosses modifications dans l'arbre des sources, comme: virer les wrappers ap_* afin de faciliter l'audit et la relecture du code, assainir le traitement des chaines et des signaux etc ... toujours dans l'objectif d'améliorer la sécurité du serveur httpd.
Les résultats concrets sont déjà visibles. Par exemple leur version d'apache n'était pas affectée par la récente faille CAN-2004-0700, ce bug ayant été corrigé bien avant dans l'arbre des sources d'OpenBSD lors d'une série d'audits/renforcements/nettoyages de routine sur le traitement des chaines dans apache (cf. le commit sur ssl_engine_ext.c qui corrige cette faille: revision 1.10, date: 2003年06月01日 15:53:41; author: deraadt; "various format string cleanups; tedu ok"). Il y a d'autres exemples de ce type.
Bref, maintenir une fork d'apache 1.3 (sans casser l'API, pour rester compatible avec les modules externes) était la solution la plus pertinente étant donné leurs priorités (préférences pour les logiciels aux licences très permissives, priorité à la sécurité et l' "auditabilité" stricte du codeplutôt qu'aux fonctionnalités amenées par la version 2) de la même façon que de nombreux admins préfèrent apache 1.3 pour sa robustesse éprouvée.