IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La FSF trouve insuffisantes les promesses de Microsoft sur C# et CLI
Qu'en pensez-vous ?

Le , par Annaelle32

0PARTAGES

1  0 
Microsoft : C# et CLI donnés aux développeurs
Microsoft vient d’annoncer qu’il appliquera sa Community Promise sur son langage C# et son Common Language Infrastructure (CLI), ce qui devra mettre tous les développeurs à l’abri des éventuelles poursuites que Microsoft pourrait engager pour cause de violation de propriété intellectuelle.

Ce geste est plutôt rassurant. En effet, elle a prise la décision de faire bénéficier aux implémentations de C# et de CLI (Common Language Infrastructure), des éléments de Mono, son programme Community Promise. Ainsi Microsoft promet de n’engager aucune poursuite ou encore de demander plus tard des droits d’auteurs sur la vente, l’utilisation, ou la distribution de C# et CLI. Cette déclaration aura l’avantage de faire descendre de plusieurs crans les inquiétudes des développeurs quant à l’intégration des produits Microsoft dans leurs produits.

ECMA
Le 6 juillet, Peter Galli, manager de la communauté open-source de Microsoft, déclarait que la Community Promise sera appliquée aux ECMA et ECMA 335. Selon toujours ce manager, si la spécification ECMA 334 préparait l’interprétation des programmes écrits avec C#, le standard 335 élabore le Common Language Infrastrucure (CLI).

Cette infrastructure permettra aussi à plusieurs applications conçues sous différents langages, de tourner dans divers environnements, sans qu’il soit indispensable de les réécrire, ces applications pouvant alors s’harmoniser automatiquement avec les caractéristiques de leurs environnements.

Un point très important de cette promesse de Microsoft, c’est que les développeurs seront désormais dispensés de signer un quelconque contrat de licence avec Microsoft.

Community Promise

Cette promesse de Microsoft stipule que dorénavant il n’est plus exigé à qui que ce soit un engagement écrit avant de réaliser un cahier de charges. Le développeur peut, également, mettre en vente son logiciel sans qu’il ait une obligation quelconque de faire apparaître le nom de Microsoft dessus. Tout un chacun peut désormais utiliser ces spécifications en combinaison avec sa technologie, son code ou ses solutions sans qu’il y ait à établir un contrat de licence avec Microsoft. Il suffirait de respecter les conditions d’utilisation.

Parallèlement, Microsoft décrit sa Communauté Promise destinée aux développeurs d’une manière qui se veut rassurante. Microsoft promet de bannir tout Microsoft Necessary Claims et cessera toute poursuite donc, contre celui qui fabrique, qui utilise, qui vend ses C# et CLI. Galli, de Microsoft, précise que l’open-source, à l’instar des modèles de licence LGPL ou GPL, n’est pas exclu de cette promesse.

Novell
Miguel de Icaza, de Novell et fondateur du projet Mono, affirme qu’il est indirectement l’un des artisans de cette somptueuse promesse de Microsoft en faisant pression sur Microsoft. En effet, quelques mois auparavant il aurait approché deux responsables de Microsoft, Bob Mublia, au Server Tolls Business et Brian Glodfarb, au développement des plateformes, pour les inciter à « clarifier » l’octroi de licences relatives aux normes ECMA. Dans la foulée, il n’a pas attendu longtemps pour annoncer qu’il tiendra compte de cette promesse dans un avenir très proche.

Malgré cette nouvelle promesse de Microsoft, les mémoires n’ont pas encore oubliées les menaces de Microsoft contre Linux en l’accusant de violation de brevets. Alors faut-il percevoir dans cette promesse un semblant de geste d’excuse ? Qu'en pensez vous?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Bebeoix
Nouveau membre du Club https://www.developpez.com
Le 08/07/2009 à 9:13
Il faut de toute façon distribué le .Net FrameWork en même temps qu'on distribue notre application...
Donc bon c'est quand même encore lourd.

En plus, j'ai remarquer dernierement, quand ton application utilise la dll Oracle pour se connecter à une BDD, faut aussi que l'utilisateur installe le client Oracle... En fin de compte toute les technos .Net sont dépendante malgré qu'on donne les dll avec :/
1  0 
Avatar de ash.ice.loky
Membre éprouvé https://www.developpez.com
Le 08/07/2009 à 10:26
Le problème vient de la guerre des gangs.
microsoft tourne le dos à oracle.
plus de support de la JVM, plus de support de oracle en .NET

Donc pour se prévenir et profiter des nouveautés de .NET => utiliser SqlServer
1  0 
Avatar de yoyo88
Membre chevronné https://www.developpez.com
Le 09/07/2009 à 20:25
très bonne nouvelle!
1  0 
Avatar de gorgonite
Rédacteur/Modérateur https://www.developpez.com
Le 20/07/2009 à 19:35
Réponse de la FSF : ces promesses sont insuffisantes !!!

Reconforté par le récent procès de Microsoft à l'encontre de TomTom au sujet d'une violation d'un brevet sur le système de fichiers FAT, la FSF répond à la promesse de Microsoft de libérer une partie de C# et de la CLI dans le cadre de la Community Promise. Ainsi selon eux, bien que Microsoft se soit engagé à ne pas attaquer en justice, ni à réclamer le paiement de royalties pour l'utilisation, la vente et/ou la distribution de n'importe quelle implémentation de C# et CLI (cela concerne donc une partie du projet Mono), la FSF répond que certains blocs constituant Mono, mais n'étant pas spécifié dans les normes ECMA 334 et 335, ne sont pas protégés par cette Community Promise, et constitue encore un danger potentiel pour ses utilisateurs.

source http://www.fsf.org/news/2009-07-mscp-mono
1  0 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 21/07/2009 à 18:59
Ben en gros, Microsoft en a juste fait assez pour clairement démontrer qu'il y a un problème, quoi. Si là Debian ne flaire pas le piège, c'est qu'ils sont vraiment stupides !
1  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 27/07/2009 à 0:05
Citation Envoyé par Bebeoix Voir le message
Il faut de toute façon distribué le .Net FrameWork en même temps qu'on distribue notre application...
Donc bon c'est quand même encore lourd.
Ben c'est comme en Java... si une application utilise un framework spécifique (par exemple .NET ou le JRE), il faut bien que ce framework soit présent. D'ailleurs .NET est inclus dans Windows depuis pas mal de temps (mais pas la dernière version malheureusement)
Mais bon, de toutes façons je vois pas le rapport avec la news

Citation Envoyé par Bebeoix Voir le message
En plus, j'ai remarquer dernierement, quand ton application utilise la dll Oracle pour se connecter à une BDD, faut aussi que l'utilisateur installe le client Oracle... En fin de compte toute les technos .Net sont dépendante malgré qu'on donne les dll avec :/
le provider ADO.NET Oracle de Microsoft n'a pas évolué depuis .NET 2.0, donc ce n'est pas "dernièrement", ça a toujours été comme ça...

Citation Envoyé par ash.ice.loky Voir le message
microsoft tourne le dos à oracle.
plus de support de la JVM, plus de support de oracle en .NET
Concernant la JVM, c'est depuis le procès que Sun a intenté à Microsoft que MS ne fournit plus sa propre JVM. Donc MS n'y est pour rien sur ce coup là...
Pour Oracle, MS a décidé d'arrêter le support de son provider ADO.NET, parce qu'il n'est pas à la hauteur des autres implémentations (il reste disponible mais n'est plus maintenu). Je vois pas où est le problème, tu peux toujours utiliser le provider fourni par Oracle (qui est gratuit), ou celui d'un autre éditeur. Mais de toutes façons, on ne peut pas raisonnablement demander à MS de développer et maintenir des providers pour chaque SGBD du marché, c'est aux éditeurs de ces SGBD de le faire. Et je dirais que c'est plutôt Oracle qui tourne le dos à MS : depuis le temps qu'on attend, on a toujours pas vu la couleur de leur support pour Entity Framework...

Citation Envoyé par ash.ice.loky Voir le message
Donc pour se prévenir et profiter des nouveautés de .NET => utiliser SqlServer
Ben oui, c'est un peu logique qu'ils mettent en avant leur propre SGBD plutôt que celui du concurrent...
Mais encore une fois, c'est un peu hors sujet par rapport à la news
1  0