Je voudrais virer les exemples sur SenderID ASF et Samba alors que les objectifs et intérêt de MS ne sont pas du tout les mêmes. C'est un exemple parfait de comparaison foireuse pour conclure sur autre chose.
Et pourquoi les objectifs et intérêts ne sont pas les mêmes ? Qu'est-ce que tu en fais ? Le Sender-ID est typiquement comparable à la partie normalisée de .NET. C'est un standard qui n'a d'intérêt que s'il est utilisé par le plus grand nombre, MS l'apporte (en partie) dans une discussion ouverte de l'IETF (encore plus ouvert que l'ECMA et l'ISO) et boum, la licence royalty free proposée est incompatible avec une implémentation open source. Je ne comprends pas la différence avec .NET.
Pour Samba, le parallèle est justifié pour les bibliothèques "serveur" de .NET, nous sommes d'accord sur ce point. Et la comparaison avec Java n'est pas flatteuse pour .NET puisque que c'est justement sur l'aspect serveur que Java est le plus ouvert.
Je voudrais que tu conclues en disant que le vrai problème est dans l'utilisation des API spécifiques à Microsoft non normalisés, que c'est cette partie que MS cherchera à protéger. Cela enlèvera à Mono un atout : la compatibilité avec de nombreux API MS. D'où l'idée de n'encourager l'utilisation que des parties normalisées et des API spécifiques à Mono.
Mais c'est totalement incomplet ! Le vrai problème c'est qu'on n'a pas d'engagement à valeur légale de MS sur la partie standardisée et que les engagements du passé sur d'autres technologies sont soit incompatible avec toutes les licences libres, soit incompatibles avec la GPL.
[^] # Re: héhé
Posté par boubou . En réponse au journal Java, .NET et les logiciels libres. Évalué à 2.
Et pourquoi les objectifs et intérêts ne sont pas les mêmes ? Qu'est-ce que tu en fais ? Le Sender-ID est typiquement comparable à la partie normalisée de .NET. C'est un standard qui n'a d'intérêt que s'il est utilisé par le plus grand nombre, MS l'apporte (en partie) dans une discussion ouverte de l'IETF (encore plus ouvert que l'ECMA et l'ISO) et boum, la licence royalty free proposée est incompatible avec une implémentation open source. Je ne comprends pas la différence avec .NET.
Pour Samba, le parallèle est justifié pour les bibliothèques "serveur" de .NET, nous sommes d'accord sur ce point. Et la comparaison avec Java n'est pas flatteuse pour .NET puisque que c'est justement sur l'aspect serveur que Java est le plus ouvert.
Je voudrais que tu conclues en disant que le vrai problème est dans l'utilisation des API spécifiques à Microsoft non normalisés, que c'est cette partie que MS cherchera à protéger. Cela enlèvera à Mono un atout : la compatibilité avec de nombreux API MS. D'où l'idée de n'encourager l'utilisation que des parties normalisées et des API spécifiques à Mono.
Mais c'est totalement incomplet ! Le vrai problème c'est qu'on n'a pas d'engagement à valeur légale de MS sur la partie standardisée et que les engagements du passé sur d'autres technologies sont soit incompatible avec toutes les licences libres, soit incompatibles avec la GPL.