Il y a plus de trois ans déjà le célèbre constructeur d’ordinateurs Dell avait ouvert le site IdeaStorm qui invitait les internautes à soumettre des idées à la société.

Et quelle est la demande qui arriva loin devant ?

Je vous le donne en mille : pouvoir également acheter des machines avec GNU/Linux pré-installé dedans.

Dell, qui se veut à l’écoute de ses clients, a bien été obligé de s’exécuter et s’est donc mis à vendre en ligne des ordinateurs avec la distribution Ubuntu dedans.

Nous nous en étions fait l’écho dans ses deux articles : De la difficulté du Linux inside chez Dell et ailleurs par Mark Shuttleworth d’Ubuntu et Dell + GNU/Linux Ubuntu : Un mariage assumé et médiatisé qui m’émeut.

Le problème c’est que Dell n’a jamais véritablement assumé ce choix en enfouissant l’offre dans les tréfonds de son site et ne la proposant que sur un nombre restreints et peu puissants de modèles. C’est ce que vient nous rappeler ce blogueur américain ci-dessous qui demande à Dell de cesser l’hypocrisie.

Espérons que la prochaine imminente sortie de la version 10.4 Lucid Lynx LTS d’Ubuntu sera l’occasion d’être entendu. Parce que si l’on se restreint à la rubrique actuelle Ubuntu du site francophone de Dell, c’est vrai que c’est plus que décevant.

On est d’abord accueilli par un bandeau au slogan étrange : « Ubuntu, restez le meilleur ! ». Je n’avais déjà pas envie d’être le meilleur en utilisant des logiciels libres alors je ne vois pourquoi je voudrais le rester ! (en fait, je crois surtout qu’il s’agit d’une horrible traduction de « Ubuntu, keeps getting better! »)

Et puis tout de suite cette première phrase très anxiogène : « Ubuntu est-il fait pour vous ? ». S’ensuit alors une explication assez peu convaincante ma foi avec ce lien Windows ou Ubuntu ? où il est conseillé noir sur blanc de « choisir Windows si vous êtes novice dans le domaine informatique ».

Vous me direz que Dell ne fait sans doute que répondre à la perplexité de ses clients (qui pourraient effectivement se tromper). Vous me direz peut-être également qu’il ne faut pas faire la fine bouche et que personne n’oblige Dell à s’intéresser à GNU/Linux sachant que d’autres constructeurs continuent de l’ignorer royalement. Vous me direz enfin qu’il existe certainement des accord commerciaux confidentiels entre Dell et Microsoft qui nous échappent. Certes mais je reste tout de même d’accord avec notre blogueur : soit on décide de proposer enfin une réelle offre GNU/Linux, soit on laisse tomber.

Parce qu’en l’état actuel des choses, on en vient même à se demander si cette opération ne fait pas plus de tort que de bien à GNU/Linux, Ubuntu et Dell réunis.

Lettre ouverte à Dell concernant Ubuntu, ou « faites-le en grand ou bien lâchez l’affaire »

An open letter to Dell regarding Ubuntu, or “go big or go home”

Trent – 2 mars 2010 – The Linux Critic
(Traduction Framalang : Simon Descarpentries, Étienne et Mathieu Adoutte)

Cher Dell,

Jusqu’à présent vous n’avez offert qu’une poignée dérisoire d’options Ubuntu, et je confesse que je ne comprends pas bien pourquoi vous vous êtes donné cette peine.

À l’exception des deux ultra-portables qui vous proposez, je n’ai pas encore vu quoi que ce soit d’autre qui puisse indiquer que vous ayez l’intention de faire d’Ubuntu une véritable option pour vos clients.

Oh je sais… pendant un temps vous proposiez Ubuntu sur vos portables Inspirons 15n, et même sur vos XPS M1330 pendant un courte période, sur votre site web.

Mais ils étaient tous deux très limités en terme d’options de configuration matérielle (CPU, RAM). De même, le poste de travail que vous proposiez pendant un temps était un veau impotent comparé à ce qui est disponible ailleurs sur Dell.com

Et maintenant ? Eh bien maintenant il n’y a presque plus rien à commenter concernant Ubuntu sur Dell.com.

Pour citer ce que je vois sur votre page Ubuntu : « Une sélection de modèles peut désormais être livrée avec Ubuntu 9.10 ».

Par « Une sélection » vous entendez la liste suivante, basée sur ce qui est trouvable sur le site :

• Nos deux ultra-portables cités précédemment ;
• Le Vostro V13, un impuissant demi-portable qui, franchement, est une blague ;
• Le Latitude 2100, qui est également un ultra-portable.

C’est tout ? Vraiment ?

« Mais il n’y a pas tant de demande que ça pour Ubuntu », vous entends-je presque répliquer.

Voyons cela. Vous enterrez ça sur votre site. Vous ne proposez que des épaves disponibles sous Ubuntu (comparé aux machines disponibles sous Windows).

Pas étonnant que vos ventes de machines sous Ubuntu soient faibles. En fait, je serais même surpris que vous vendiez quoi que ce soit vu comment vous vous y prenez.

Voici ce que je vous conseille. Cela risque de paraître un peu élitiste, mais j’ai acheté des ordinateurs récemment et ça m’a mis d’humeur taquine.

Comme je vois les choses, vous avez deux options :

1. Lâchez l’affaire

Sérieusement. Vous n’impressionnez personne avec ces offres Linux minables. Ceux qui s’intéressent suffisamment à Linux pour chercher (et trouver) les produits Ubuntu enterrés dans votre site se sentent insultés par ce qu’ils y trouvent, et vont simplement voir ailleurs, là où on ne leur proposera pas avec force langue de bois des ordures que la plupart des utilisateurs de Windows ne s’embêteraient pas à regarder de plus près (du point de vue du matériel).

2. Proposez Ubuntu sur des ordinateurs comparables à vos machines sous Windows 7

Faites-le en grand, ou bien lâchez l’affaire les gars. Votre micro-marketing pour une niche d’utilisateurs bernés niveau matériel est un échec, mais si vous joignez vraiment le geste à la parole, vous gagnerez les coeurs et les esprits, et vous éviterez la plupart des critiques venant de la communauté Open Source, pour ce que ça vaut.

De plus, en l’absence de la Taxe Windows, un ordinateur sous Ubuntu devrait permettre aux acheteurs de constater qu’un ordinateur, à matériel égal, vendu sans Windows, coûte quelque centaines d’euro MOINS cher, ce qui signifie qu’ils seront plus enclin à acheter des accessoires parmi ceux sur lesquels vous insistez lourdement, sur votre site.

Sérieusement, ce qu’il y a jusqu’ici sur votre site est tout simplement insultant. Abandonnez Ubuntu complètement ou bien passez aux choses sérieuses.

Désolés les gars, mais quelqu’un se devait de vous le dire. Vous ne vous rendez pas service, ici.

En vous remerciant,

Trent

Si vous avez le malheur de développer un projet « open source » au sein de votre entreprise alors vous courrez le risque de voir arriver une « communauté » qui peut à tout moment s’agréger autour du code source de votre logiciel et en menacer sa bonne gouvernance.

Heureusement le développeur Josh Berkus est là pour vous expliquer point par point comment faire pour être certain de ruiner et dissoudre toute velléité communautaire (au cours d’une intervention donnée il y a un mois à la Linux.Conf.au et relatée ici par Jonathan Corbet)^[1].

Un article évidemment ironique (qui détourne les howto), mais qui donne à réfléchir sur les relations subtiles et complexes qui peuvent exister entre les communautés et les entreprises qui œuvrent sur un même projet.

Pas toujours facile de se comprendre en effet quand les uns disent plutôt « logiciel libre » et les autres plutôt « open source » (voire même parfois carrément « fauxopen source »).

Et puis, c’est pratique, puisqu’on dispose ainsi de tout ce qu’il ne faut pas faire pour réussir un projet communautaire.

On notera que Josh Berkus avait la société Sun Microsystems en tête lorsqu’il a énoncé son propos (Sun soutient notamment MySQL et OpenOffice.org). Mais comme il le précise lui-même a posteriori sur son blog, cela peut s’appliquer à n’importe quelle « corporate open source » et de citer alors entre autres Red Hat, Microsoft, IBM, Cisco, SugarCRM, Novell, Compiere, Borland, Google, ou encore Apple. « Si vous avez à faire à une compagnie qui possède un projet open source, vous pouvez être sûr à 95% qu’elle suit au moins un des dix points mentionnés ci-dessous »

Et de conclure positivement sur la nécessité de cultiver l’un des mots clés les plus importants de la communauté : la confiance.

Comment détruire votre communauté : mode d’emploi

How to destroy your community

Jonathan Corbet – 18 janvier 2010 – LWN.net
(Traduction Framalang : Olivier, Daria et Don Rico)

Le réputation de Josh Berkus en tant que hacker de PostgreSQL n’est plus à faire, mais ce n’est pas sa seule compétence, puisqu’il a aussi acquis une précieuse expérience durant sa pige au « Laboratoire de Destruction des Communautés », plus connu sous le nom de Sun Microsystems. Il y a suivi « l’enseignement breveté en 10 étapes » pour apprendre à débarrasser un projet de toute ingérence de la communauté.

La présentation très dynamique qu’a donnée Josh à la Linux.Conf.au sur le sujet était la première discussion de la miniconf L’économie de l’open source ; l’audience lui a réservé un accueil chaleureux.

Si vous êtes développeur dans une grosse entreprise, vous vous rendrez rapidement compte que les communautés de développement des logiciels libres sont une plaie. Dites adieu à vos plans marketing, par exemple, car elle se chargera d’introduire le logiciel dans des pays où vous êtes absents et pour lesquels vous n’avez pas de plan. Ils flanqueront par terre vos prévisions produits en sortant des innovations non-prévues, en implémentant des fonctionnalités des années avant ce que vous aviez planifié, ou pire encore, des fonctionnalités qui devaient être réservées à la version propriétaire de votre logiciel. Les communautés de logiciels libres sont d’éternelles insatisfaites, elles n’ont de cesse de vouloir améliorer les choses. Elles ont tendance à redéfinir les relations avec vos partenaires et vos clients, et vos commerciaux ne savent plus à quel saint se vouer. Et sans arrêt elles vous dérangent : un e-mail par ci, une conférence à laquelle vous devriez assister par là, etc.

Mais heureusement, des solutions existent pour vous débarrasser de la menace que représente cette communauté. Il suffit d’appliquer une ou plusieurs des étapes suivantes.

1. Rendez le projet dépendant d’outils complexes

Il a remarqué qu’en général, les entreprises n’ont pas de problème avec cette technique puisqu’elles aiment s’appuyer sur leurs propres outils. Pour les projets où la communauté n’est pas la bienvenue, il faut par exemple employer des systèmes singuliers qu’on ne trouve nulle part ailleurs. Un système de contrôle de version propriétaire (NdT : version control system) est absolument obligatoire. Mieux encore, un outil de suivi des problèmes (NdT : issue tracking system) avec un nombre limité de licences, afin que tout le monde doive s’y connecter avec le même compte.

N’oubliez pas de mettre en place un site Web qui respecte la parité : 50% du temps planté, 50% du temps opérationnel. Ne pas mettre de site à disposition ne suffira pas : dans de telles situations, la communauté a la fâcheuse habitude de créer le sien. Avec un site bancal, en revanche, vous vous en prémunirez et vous assurerez que l’information restera bien cachée.

2. Attirez les participants nocifs et optimisez les dégâts qu’ils peuvent engendrer

Ce cas particulier nécessite quelques étapes :

1. Prenez sur vous et engagez-vous dans de longs débats avec ces personnes et dénoncez-les sur les listes du projet.
2. Au bout d’un certain temps, bannissez-les par décret ; évitez à tout prix tout processus communautaire.
3. Les gens bannis déverseront leur bile ailleurs. Vous devez les suivre et poursuivre votre débat sur ces sites externes.
4. Enfin, la communauté se plaindra de ce comportement. Votre réponse sera simple : réintégrez les enquiquineurs à la communauté. Reprenez à la première étape et recommencez.

D’après Josh, un casse-pieds bien pris en main peut annihiler une communauté de plusieurs centaines de membres.

3. Ne fournissez pas de documentation

Aucune information utile ne devrait être disponible, ni pour le code, ni sur les méthodes de compilation, rien sur le processus de soumission de correctif, ni sur le processus de sortie, rien de rien. Puis, quand on demandera de l’aide, répondez « Lis la notice, bordel ! » (NdT : RTFM pour Read the fucking manual)

4. Prenez les décisions relatives au projet en petit comité

Pour bien commencer, vous pouvez organiser vos réunions en ligne en ne prévenant les participants que très peu de temps à l’avance. Pour que cette technique soit vraiment efficace, prévoyez ces réunions à des heures incompatibles avec le fuseau horaire commun à la plupart des membres de la communauté.

Le mieux est encore de tout faire en visioconférence : vous exclurez de fait environ un tiers de la planète pour qui elle se déroule de nuit, de plus, les gens ont un boulot, tant pis pour eux aussi. Mais le must reste encore d’organiser les réunions en personne au siège de la société.

5. Sortez la grosse artillerie juridique

S’impliquer dans le projet devrait rimer avec accords de participation alambiqués, contrats de licence protégeant le contenu du site Web, accords de confidentialité, marques déposées, etc. Pour ne pas faire les choses à moitié, tous ces documents devraient être modifiés en catimini à peu près tous les deux mois.

6. Choisissez avec soin l’agent de liaison avec la communauté

Votre meilleur candidat : quelqu’un de solitaire, quelqu’un qui n’a pas d’amis et qui n’apprécie pas vraiment les autres. Si vous n’en avez pas sous la main, prenez le membre de votre équipe qui a le plus de travail, quelqu’un avec des responsabilités en développement et en gestion, et qui travaille déjà au minimum 70 heures par semaine. Dans ce cas, il est primordial de ne pas le décharger de la moindre de ses responsabilités.

Quelqu’un qui ne maîtrise pas la technologie fera aussi l’affaire. Prenez un spécialiste de Java pour assurer la liaison dans un projet en Perl. Ou, si vraiment ces solutions ne sont pas possibles, laissez simplement la place vacante pendant des mois.

7. Rendez opaques les prises de décision

Les entreprises réfractaires aux communautés devraient, d’après Josh, s’inspirer des Nations Unies et créer des processus longs et complexes. Personne ne doit savoir qui prend réellement les décisions, c’est très bon pour transformer les contributeurs en éléments nocifs. Il va de soi que les règles devraient être immuables ou presque.

8. Faites n’importe quoi avec les licences

Les membres de la communauté étant souvent à cheval sur la question des licences, modifiez la licence et vous avez de bonnes chances de les faire fuir. Évoquer des changements de licence sans jamais vraiment rien modifier peut se révéler encore plus efficace : vous faites fuir les contributeurs actuels qui apprécient la licence choisie sans pour autant en attirer d’autres, adeptes eux de la future licence supposée.

9. N’accordez jamais, au grand jamais, l’accès au commit à quelqu’un d’extérieur à l’entreprise

Ce devrait être une règle (tacite évidemment) : seuls les employés peuvent avoir les droits de commit (NdT : avoir ces droits revient à avoir accès et contrôle sur le code source du dépôt officiel du logiciel). Vos réponses doivent être évasives, « problèmes légaux, on y travaille » est une bonne carte à jouer. Afin que cette mesure prenne tout son effet, choisissez un employé qui n’écrit pas de code et confiez lui l’accès au commit sur le projet.

10. Réfugiez-vous dans le silence

Laissez les questions sans réponse, ne dites rien. Maîtriser cette technique peut rendre, à elle seule, toutes les autres inutiles. C’est le meilleur moyen de détruire une communauté qui existe.

En conclusion, Josh ajoute que grâce à Sun, il peut témoigner de l’efficacité de toutes ces techniques. Mais Sun est loin d’être la seule entreprise dans cette situation. Un ancien du X Consortium a avoué à Josh qu’eux aussi avaient un jour recouru à chacune de ces méthodes. Ces compétences de destruction de communauté sont monnaie courante dans l’industrie du logiciel.

Mais que faire si votre entreprise veut au contraire se bâtir une communauté ?

Il paraît évident qu’elle devrait alors s’employer à appliquer à l’inverse les méthodes énumérées ci-dessus. Mais d’après Josh, la clé de voûte du système reste la confiance. À l’instar du mariage, développer une communauté peut prendre des années, mais une seule infidélité détruira la confiance qui en constitue le socle. Ainsi, une entreprise peut perdre la moitié de sa communauté en un week-end. Pour ne pas connaître ce triste sort, il faut avoir confiance en la communauté et agir de sorte que cette confiance soit réciproque.

Rien à faire, la culture propriétaire est dans l’ADN de Microsoft.

Quand bien même, avec sa nouvelle Microsoft Biology Foundation, la société décide de montrer a priori patte blanche, ou plutôt « patte open source » à une communauté scientifique (ici la bio-informatique) de plus en plus consciente de ce qui est bon pour elle.

Espérons du coup qu’elle ne sera pas dupe. C’est ce qui vient nous rappeler avec causticité Glyn Moody sur son blog^[1].

Les implants biologiques de Microsoft

Microsoft’s Biological Implants

Glyn Moody – 6 novembre 2009 – Open…
(Traduction Framalang : Julien et Cheval boiteux)

Microsoft se montre à la hauteur de ses vieilles ficelles consistant à offrir de jolies babioles aux naïfs avec la Microsoft Biology Foundation :

La communauté bio-informatique a développé une solide tradition de développement ouvert, de partage de code et de support multi-plateforme, et un certain nombre de boîtes à outils (NdT : toolkits) spécifiques à chaque langage sont désormais disponibles. Ces boîtes à outils sont précieuse à la la communauté, en promouvant le partage du code et en établissant des standards de fait.

La Microsoft Biology Foundation (MBF) est une boîte à outils générique pour la bio-informatique construite comme une extension pour le framework .NET. Actuellement, il met en oeuvre une gamme d’analyseurs syntaxiques pour les formats de fichiers communs dans la bio-informatique ; une série d’algorithmes permettant de manipuler des séquences d’ADN, d’ARN et de protéines; et un ensemble de connecteurs à des services Web de biologie comme NCBI BLAST. MBF est disponible sous une licence open source, et les exécutables, le code source, les applications de démonstration ainsi que la documentation sont téléchargeables gratuitement depuis le lien ci-dessous.

J’aime beaucoup la transition de « solide tradition de développement ouvert, de partage de code et de support multi-plateforme » à « tenez, allez faire mumuse avec ces joujoux du framework .NET remplis de brevets ».

Le problème étant, évidemment, qu’une fois que vous avez consciencieusement installé le framework .NET, avec tous les brevets que Microsoft prétend détenir dessus, et que vous vous y retrouvez enfermé par les usages et habitudes qui y sont liés, vous faites partie de l’écosystème contrôlé par Microsoft. Et vous allez probablement y rester, étant donné que Microsoft n’essaye même pas de promettre que cette camelote sera portée sur d’autres plateformes.

Parce que, sous le titre trompeur « multi-plateforme et interopérabilité », il est dit :

MBF fonctionne bien sur le système d’exploitation Windows et avec un éventail de technologies Microsoft.

Ouais ? Et qu’en est-il des technologies et systèmes d’exploitation non-Microsoft ?

Nous avons l’intention de travailler avec la communauté de développeurs pour profiter de l’extensibilité de MDF et supporter un nombre croissant d’outils Microsoft et non-Microsoft à mesure que le projet se développe.

Bien, mais ça n’a aucun rapport avec le fait d’être multi-plateforme : ils disent juste que ça va fonctionner avec d’autres outils – la belle affaire.

Si j’étais un biologiste, je me sentirais insulté par cette tentative à peine déguisée de faire rentrer de tels logiciels remplis de brevets au sein de la communauté bio-informatique, qui a une longue et glorieuse tradition d’usage et de soutien au logiciel libre, qui est réellement libre et réellement multi-plateforme, ce qui signifie tenter d’enfermer l’une des communautés les plus florissantes et dynamiques du monde logiciel.

Paint.NET^[1] est un très bon logiciel libre de retouches d’images pour Windows. De l’avis de beaucoup, bien plus « sexy » et accessible au grand public que Gimp par exemple.

Sauf qu’il possède deux défauts, un petit et un bien plus grand, éliminatoire même. Il nécessite, comme son nom l’indique, l’implémentation préalable du framework .NET de Microsoft, mais surtout il a très vite été un logiciel libre contesté qui n’avait en fait de logiciel libre que le nom, ou plutôt « que » la licence (en l’occurrence la licence MIT).

Contrôle du code, communauté inexistante et absence des dernières version des sources à télécharger, faisaient en effet de ce logiciel un exemple emblématique de « fauxpen source ». De l’aveu même de Rick Brewster, son unique développeur : « le code source était publié mais il n’a jamais été question d’un projet ouvert et collaboratif qui acceptait des soumissions de code non sollicitées ». Il appelle d’ailleurs cela un logiciel « released sources ».

Aujourd’hui les choses sont clarifiées. Rick Brewster a décidé il y a un mois de changer la licence pour en faire un vrai logiciel propriétaire gratuit (ou freeware). « You may not modify, adapt, rent, lease, loan, sell, or create derivative works based upon the Software or any part thereof », peut-on lire sur l’article de son blog qui annonce la nouvelle.

Cette nouvelle n’est pas forcément bonne (un logiciel qui quitte la lumière pour rejoindre le côté obscur de la force) mais elle est logique et cohérente vue l’évolution de l’application. Il nous a cependant semblé intéressant de traduire cet article, d’abord pour mieux comprendre les motivations de cette migration à contre-courant, mais aussi parce que les arguments avancés sont autant de justifications plus ou moins convaincantes qui vous feront peut-être réagir dans les commentaires.

Une nouvelle licence pour Paint.NET 3.5

A new license for Paint.NET v3.5

Rick Brewster – 9 novembre 2009 – Blog personnel
(Traduction Framalang : Jimbo)

Au fil des années, j’ai été obligé de me battre avec un certain nombre de personnes, et de sociétés, qui tentaient de plagier Paint.NET en recompilant le programme sous une dénomination commerciale différente et en insérant leur propre nom dans les crédits. Parfois, ils se faisaient payer pour ce service. J’ai même créé mon propre terme pour désigner cela : un « backspaceware » (NdT : en français cela donnerait quelque-chose comme « effaciciel », le backspace étant la touche « retour en arrière », qui permet d’effacer le dernier caractère tapé). En outre, de temps en temps, on trouve Paint.NET en vente sur eBay.

Et, comme beaucoup d’entre vous le savent, Paint.NET était open source. Ou plutôt, il était « released sources » (NdT : C’est-à-dire « sources publiées ») : le code source était publié mais il n’a jamais été question d’un projet ouvert et collaboratif qui acceptait des soumissions de code non-sollicitées. J’aimais publier le code source, parce qu’il me semblait bon de permettre à d’autres de l’étudier. Il y a environ un an, fatigué de voir ces versions plagiées de Paint.NET et j’ai décidé de retirer le code source du site Web. Cependant le code source était toujours dans la nature en différents endroits d’Internet (ce qui n’est guère illégal). Même sans le code source, une personne maline et douée pouvait probablement encore décompiler, modifier puis recompiler le programme, afin de lui faire dire ou faire ce qu’elle voulait.

Le plus gros problème était que, même si ces actions déplorables manquaient clairement d’éthique, le licence MIT autorisait tout cela. Ou, du moins, dans certains cas particuliers, ce qu’elle interdisait n’était pas clair. Donc, d’un point de vue juridique, ce qui pouvait précisément être entrepris à ce sujet n’était pas clair. Je ne suis pas juriste et je ne voulais pas dépenser des milliers de dollars pour avoir une explication de tout cela. Quelques personnes ont affirmé que j’avais choisi la mauvaise licence et, avec le recul, c’est sans aucun doute exact.

En outre, tout ceci va plus loin que le plagiat ou ma propre tension artérielle. La publication de copie dérivées de Paint.NET est source de confusion et perturbe la plupart des utilisateurs. J’ai reçu des e-mail de personnes troublées parce qu’elles pensaient que Paint.NET avait été renommé et que des fonctions manquaient dans « la nouvelle version ». Ces copies dérivées provoquent du désordre puisque souvent elles désinstallent le vrai Paint.NET (avec la même interface graphique que pour l’installation Windows) tout en conservant le système de mise à jour d’origine. Ce qui signifie que lorsque vous installez une telle copie dérivée, elle supprime Paint.NET, et puis lorsque Paint.NET est mis à jour, il désinstalle la version dérivée et la remplace par Paint.NET, etc… Ou la version modifiée plante, et le rapport de bugs indique à l’utilisateur de l’envoyer à mon adresse mail. Il y a aussi a risque réel de trojans et de virus.

Tout est désormais fini.

Pour la version finale de Paint.NET 3.5, qui ne devrait plus tarder, j’ai modifié la licence. Pour la plupart des utilisateurs, cela n’aura aucun impact. C’est toujours un freeware. Il n’y a toujours aucune prétention sur les fichiers créés, ouverts ou sauvés avec Paint.NET. Vous pouvez toujours établir un miroir du fichier zippé à télécharger sur votre site web (par exemple Betanews, Download.com, etc.) sans en demander la permission. Vous pouvez toujours vendre des trucs que vous créez avec Paint.NET (pour autant que vous ayez le droit de le faire bien sûr). Vous pouvez continuer à utiliser dans un contexte commercial, et à l’installer sur autant de machines que vous le désirez.

Cependant, la licence spécifie que vous ne pouvez plus modifier Paint.NET lui-même, ou créer une œuvre dérivée basée sur le logiciel Paint.NET (c’est-à-dire un logiciel dérivé). Vous ne pouvez pas non plus le vendre. Je ne pense pas que cela aura un impact sur quiconque d’autre que ceux qui désirent plagier ou détrousser Paint.NET. Je ne vais implémenter aucune restriction quant au reverse engineering ou la décompilation, par exemple à l’aide de Reflector. Je pense que ce serait bête, et je crois encore de tout mon cœur qu’il est bon qu’on soit capable d’étudier le code de Paint.NET, quand bien même il ne s’agit que du démontage approximatif fourni par Reflector. Toutefois, vous n’êtes pas autorisé à modifier et recompiler une nouvelle version de Paint.NET à partir de ce démontage.

Cette décision créera à n’en pas douter de la confusion. Par exemple, « Est-ce que les plugins sont autorisés ? ». Oui, absolument: le programme est conçu pour accepter ces dernier et ils ne constituent pas une modification de Paint.NET lui-même. Je devrai certainement mettre la FAQ à jour sur cette question, comme sur d’autres.

Je m’attends à ce qu’il y ait une minorité bien en voix qui condamne ce changement de licence. Avant de vous exprimer, veuillez vous poser cette question : cela vous touche-t-il réellement ? Comptiez vous vraiment faire quelque chose que cette nouvelle licence interdit ? Je parie que la réponse est « non », mais, je vous en prie, postez un commentaire si la réponse est un véritable oui. Beaucoup de personnes ont condamné ma décision de supprimer le code source mais après enquête, il s’est avéré que c’était une pure question de principe : elles n’avaient jamais téléchargé le code source, jamais rencontré quelqu’un qui l’avait téléchargé, et jamais prévu de faire quoi que ce soit qui tirerait profit ou dépendrait de l’accès au code source. Je comparerai cela à être contrarié par le fait que votre passeport vous interdit de voyager en Antarctique : comptiez-vous vraiment vous rendre là-bas un jour ?^[2]

L’autre décision que je compte prendre est de publier le code source de portions de Paint.NET 3.5, probablement sous une licence de type MIT ou BSD. Les développeurs de plugins gagneraient en effet beaucoup à disposer du code source des effets graphiques et de certaines commandes relatives à l’interface WinForms. La meilleure façon de résumer les choses est de dire que la nouvelle licence (NdT : Voir les termes de la nouvelle licence sur l’article d’origine) couvre les « binaires », c’est-à-dire « ce que vous venez de télécharger et d’installer ». Je peux toujours créer des paquets à télécharger qui sont couverts par d’autres termes de licence. D’un point de vue de la philosophie, c’est peut-être déroutant, mais je suis prêt à en payer le prix.