Liens connexes

Dépêche modérée par

: Viabilite économique de la GPL

Posté par Philippe Fremy (page perso, ). Modéré le 14 août 2001.
0
Voici une petite réflexion sur la viabilité économique des sociétés développant ou utilisant du logiciel libre. En exclusivité sur linuxfr. En gros, peut-on encore gagner de l'argent quand n'importe qui peut distribuer un logiciel que vous développez en GPL ?

Note du modérateur: il semblerait qu'il y ait un problème avec l'attachement, je mets un lien vers l'article complet. A lire!

> Lire les commentaires (59 commentaires, moyenne: 1,1).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

[+] pb de copier/coller ?

Posté par corn () le 14/08/2001 à 13:50. (lien). Évalué à -1.

Il me semble qu'il y a un petit problème de copier/coller dans ton texte, à la fin du III, qui repart vers le II ensuite !

C'est pas bien grave... intéressante réflexion en tout cas !

GPL et jeux

Posté par Gaël Le Mignot (page perso, ) le 14/08/2001 à 14:43. (lien). Évalué à 3.

Je ne suis pas d'accord avec l'analyse faite sur la GPL et les jeux.

Le moteur n'est pas le plus important dans un jeu, c'est les graphismes/sons/scénarios/...

Prenons un exemple concret: l'Infinity Engine (moteur de Baldur's Gate). Le même moteur a été utilisé avec très peu de modification pour un grand nombre de jeux: BG, BGII, IWD, Planscape: Torment et tous les add-on. Et tous ces jeux ont eu beaucoup de succés. Ce n'est pas le moteur qui est vendu, mais le scénario, les graphismes, les donjons, les items, ...

D'autre part, les jeux en GPL ne pèchent pas au niveau de la qualité du moteur, mais plutôt au niveau graphismes/sons/... Donc les deux approches sont parfaitement concialible. Je ne suis pas sur que BioWare aurait vendu un exemplaire de moins de ces jeux s'ils avaient diffusé l'Infinity Engine en GPL, au contraire: des ports de l'IE seraient apparus sur différentes plateformes (Linux, BeOS, consoles, MacOS, ...) et les gens auraient achetés BG II pour avoir les scénars/graphismes.

Pipeau.

Posté par core () le 14/08/2001 à 14:55. (lien). Évalué à 2.

Cet article est visiblement un essai destiné à faire l'apologie de SuSE et à pisser sur Mandrake. C'est bien joli mais ce n'est pas argumenté et fait preuve d'une méconnaissance incroyable de la façon dont se sont construites les distributions Linux. Par ailleurs, elle sous-entend que Red Hat a développé à 100% sa distribution alors que 98% d'une Red Hat est quand même développée par... la communauté. Par ailleurs, Mandrakesoft fait vivre plein de personnes qui bossent aussi sur XFree, KDE, Linux kernel etc. Avec les arguments de ce monsieur (qui ne signe même pas son essai), je peux faire exactement la même chose et démontrer que Microsoft court à sa perte dans peu de temps. En tout cas, il nous aura prouvé qu'il ne croit pas au libre. Vive le logiciel propriétaire n'est-ce pas !!

Problèmes d'accents : Pensez Réacc :)

Posté par Frédéric Lopez () le 14/08/2001 à 15:08. (lien). Évalué à 5.

"C'est un peu long et c'est sans accents (parce que ca va beaucoup plus vite a taper comme ca, je prie humblement les lecteurs que cela gene de m'excuser)."

http://www-rali.iro.umontreal.ca/Reacc/(...)

"C'est un peu long et c'est sans accents (parce que ça va beaucoup plus vite à taper comme ça, je prie humblement les lecteurs que cela gêne de m'excuser)."

Retour en arrière

Posté par Jean-Marc Saffroy () le 14/08/2001 à 15:10. (lien). Évalué à 3.

Premières remarques, sur la forme : en français, on utilise des caractères accentués, c'est peut-être un tout petit peu plus long à taper (et encore, avec de l'entraînement, la différence est vraiment minime), mais ça fait une différence au niveau du sens. On peut toujours arguer qu'on s'en sort toujours avec le contexte, le fait est que l'absence d'accents nuit à la lisibilité. Et c'est se payer la tête du lecteur que de faire celui qui s'excuse parce qu'il n'a pas pris la peine de faire un effort minimal pour être lisible. Mêmes remarques en ce qui concerne l'orthographe : d'abord on se relit, ensuite on fait relire par quelqu'un de plus calé, et ça filtre 99% des erreurs.

Maintenant sur le fond : cet article est un énorme retour en arrière. On se croirait revenu aux énormes doutes sur la viabilité des logiciels libres dans leur ensemble qu'exprimaient la plupart des gens il y a quelques années. Aujourd'hui, envers et contre tout, on trouve des logiciels libres de bonne qualité en position de sérieux concurrents de logiciels propriétaires (serveurs web, mail, bases de données, stockage, OS et développement embarqués, etc.). Et vu la complexité de ces logiciels, un marché s'est constitué permettant à ceux qui en ont la maîtrise de monnayer leurs compétences. Alors pourquoi ne pas envisager la même approche pour le domaine des jeux ? Evidemment, Rome ne s'est pas faite en un jour, il faut aussi bien changer les mentalités que valider ce modèle économique appliqué au monde du jeu, et les difficultés que rencontre Loki sont un avertissement à ne pas négliger. Mais annoncer un status quo est une attitude qui se révèle presque toujours fausse à moyen terme, surtout dans le monde de l'informatique, où l'évolution est permanente (même si elle ne se fait pas toujours à vitesse constante dans tous les secteurs).

Bref, il me paraîtrait beaucoup plus constructif de disserter sur les différentes façons dont les développeurs de jeux pourraient trouver avantage à passer certaines parties de leur code sous des licences libres, de la même façon que diverses entreprises trouvent leur intérêt à contribuer à des logiciels libres en rapport avec leur activité.

PS: ce commentaire a été relu. :p

abaisser la barriere

Posté par cornofulgur () le 14/08/2001 à 15:20. (lien). Évalué à 1.

Ce n'est peut être pas leur objectif principal, mais je pense que les logiciels libres ont systématiquement pour effet d'abaisser la barriere a l'entree.
Un logiciel libre ne sera plus a refaire. c'est quelque chose de solide sur lequel se baser. Il est preferable economiquement de contribuer a un logiciel libre plutot que de repartir a zero sur sa version proprietaire.

Les logiciels libres forment donc une base stable qui s'élargie au fur et a mesure et sur laquelle n'importe qui peut se lancer à bas coûts. D'ou le grand nombre de programmes libres qui débutent ici ou la. Le logiciel libre contribuera aussi a faire baisser le coût de developpement pour les jeux, entre autres.

Se maintenir en place est difficile. Il faut apporter autre chose que du logiciel: du service, de l'innovation ou des normes.
Je pense que les librairies s'en sortent mieux. Un programme en LGPL definie une norme ou un protocole que va defendre l'equipe de developpement, qui permettra aux utilisateurs tierces parties de construire au dessus. Ceci permet d'obtenir des retombees sonnantes et trebuchantes. L'exemple typique est TrollTech.
Il est regrettable que la FSF discrédite la LGPL au lieu de l'encourager : http://www.gnu.org/philosophy/why-not-lgpl.fr.html(...)

Le logiciel libre fabrique une vraie croissance informatique, ce qui beneficie aux utilisateurs, et il se trouve etre le gardien des normes, ce qui peut aider les entreprises a prosperer.

Ceci dit, le noyau Linux avec sa licence GPL est etonnament atypique.

« Traduction »

Posté par Anonyme () le 14/08/2001 à 15:34. (lien). Évalué à 2.

J'avoue que de mon côté ça me dérange du français
sans accent, à vrai dire, ça n'est plus du français. Mais plutôt que d'être critique, je préfère être constructif, ainsi j'ai accentué
et corrigé le texte, en essayant de rester le plus possible à la philosophie du texte. Je pense monsieur Penso que ça serait sympa d'en faire la version « officielle » en virant les corrections qui ne te plaisent pas. Ci dessous le texte corrigé:

La nouvelle du changement de licence de TuxRacer m'a poussé à mettre par
écrit quelques petites réflexions sur la GPL, le logiciel libre et l'économie,
que je voudrais partager avec vous. C'est un peu long et c'est sans accents
(parce que ca va beaucoup plus vite à taper comme ca, je prie humblement les
lecteurs que cela gêne de m'excuser
-> NdT: ça me gêne alors qu'on maltraite ainsi notre si belle langue et de plus
sans accent, ça peut porter à confusion. Alors j'ai fais une petite traduction,
en essayant de respecter le texte original tout à fait brilliant, envoyez-moi
les corrections à cgillot@free.fr si par hazard une faute se serait
malencontreusement introduite...).
J'espère que ça éclairera mieux certains comportements.



I- barrière à l'entrée
----------------------

Dans l'économie normale, si on prend un marché donné où il y a un certain
nombre d'acteurs, tout nouvel entrant rencontre une barrière à l'entrée.
Les anciens possèdent une technologie mature, de l'expérience et une base de
clients, ce qui leur permet de vendre respectivement un produit, du service et
des partenariats. C'est la difficulté à obtenir la même technologie, la même
expérience ou les mêmes clients qui détermine la barrière a l'entrée.

La barrière à l'entrée est une chose importante car elle donne une stabilité à
l'écosysteme du marché. Pour être rentable une entreprise a en effet besoin de
pouvoir affirmer qu'elle possèdera une part de marché sur une période quelques
années. Pour une société technologique de taille moyenne, cinquante à deux cent
personnes, six ou sept ans constituent une période de rentabilité raisonnable.

Si la barrière à l'entrée est élevée, cela conduit à un monopole ou à un
oligopole. Les quelques acteurs dominants se partagent le marché, qui s'il
est large, peut être très juteux.

Si la barrière à l'entrée est très élevee, cela devient difficile de
s'installer même pour les leaders. C'est le cas par exemple de l'industrie des
console. Le coût de développement d'un jeu ou d'une console est tellement
élevé que même Sony et Nintendo ne sont jamais sûr de leur operations. Sega a
renoncé et Nintendo est en train de le faire.

Le marché de la téléphonie mobile troisième génération (UMTS) est un
autre exemple de marché nouveau avec une barrière à l'entrée très élevée.
Les coûts de licences et d'infrastructures sont tellement importants que
la rentabilité n'est pas assuré, même pour un oligopole (très peu d'acteurs
sur un marché).

Notons que dans ces deux cas (UMTS et consoles), on vend à des particuliers.
C'est un marché particulièrement difficile car le comportement des particuliers
est difficile a prévoir. Achètera, achetèra pas ?

Si la barrière à l'entrée est très faible, on obtient un marché volatile et
instable. Il y a beaucoup d'acteurs qui essaient de rentrer en permanence sur
le marché. Du coup, le marché devient extrêmement divisé et perturbé, la part
de chaque acteur devient très petite et aucun des acteurs n'est rentable.
Beaucoup de sociétés disparaissent. Ceux qui arrivent à survivre aux
phases initiales restent. Au fur et à mesure que les autres tombent ceux-là
stabilisent leurs parts de marché et leur position dominante. Au final, tout
nouvel entrant aura du mal à prendre une part de marché aux gros qui ont
réussi à survivre. Il y a donc après la stabilisation du marché une barrière
d'entrée qui s'est relevée.

C'est ce qu'on a vu pour les startups. Un marché en création, avec une
barrière a l'entrée extrêmement faible (un site web) et des bénéfices potentiels
élevés. Des centaines d'acteurs se sont rués naïvement dessus et ça a donné ce
qu'on a vu. En fait, on s'aperçoit que la barrière à l'entrée n'est pas si
faible puisqu'il faut fournir un réel service, puis que les revenus eux sont
très faibles (marge sur des achats, publicité, ça ramène pas lourd) et que
donc c'est un marché difficile. Un type intelligent disait qu'il y avait de la
place pour dix acteurs dans la publicité en ligne. C'est ce qu'on a
aujourd'hui, maintenant que le marché s'est stabilisé : yahoo, voila,
boursorama, spray, etc. La barrière a l'entrée est très élevée maintenant, parce
que les acteurs se sont établis et que les marges sont très faibles. On note
encore que là-aussi, c'est un business qui vend aux particuliers, donc
difficile à prévoir.

Ce que je veux faire comprendre, c'est que la barrière à l'entrée sur un
marché est quelque chose de capital pour le succès d'une entreprise. S'il n'y
a pas de barrière à l'entrée suffisamment elevée, les entreprises n'arrivent
pas à protéger leurs acquis et ne rentabilisent donc pas leurs
investissements. Elles disparaissent, l'économie devient morose, on licencie,
il y a des plans sociaux, bref, ça va mal.




II- Business model
------------------

Le business model, qui doit bien s'appeler quelque chose comme « modèle
d'affaire » en francais bien de chez nous, c'est le truc qui décrit comment
vous gagnez de l'argent. En general, quatre paramètres interviennent dans un
business model :

- ce que vous vendez : produit ou service
- combien ca coûte à faire : un logiciel à la con, ça prend six mois de dev à
deux. Un gros logiciel, c'est trois ans, voire plus, pour une équipe de dix
personnes. C'est ce qu'on retrouve pour de très gros logiciels d'entreprise
ou pour les jeux modernes.
- combien vous en vendez : évidemment, c'est important à savoir.
- à qui vous le vendez :
. Entreprises : c'est un marché previsible : elles achètent si ça leur fait
gagner du temps ou de l'argent (ce qui revient au même). Elles ont beaucoup
d'argent donc on peut éventuellement vendre très cher à un petit nombre de
clients privilégiés.
. Particuliers : c'est un marché relativement imprévisible. Le particulier
achète si ça lui plait et si ça coûte pas trop cher.


Si un outil est indispensable à une entreprise, elle est prête à le payer
cher. Donc on peut mettre une grosse équipe pendant trois ans sur un logiciel
qu'on est sûr ensuite de vendre à plusieurs centaines de milliers de francs ou à
plusieurs centaines de milliers d'exemplaires. Pour être sûr de le vendre, il
suffit de prouver à l'entreprise qui l'achète qu'elle va gagner de l'argent
avec.

L'avantage du marché des particuliers, c'est qu'il y en a beaucoup. On peut
donc vendre un logiciel pas cher à beaucoup d'unités pour rentabiliser un gros
et long developpement (typiquement, un gros jeu). Mais le marché des
particulier est assorti d'une incertitude, on n'est jamais sûr qu'ils vont
acheter.

Dans les deux cas que je viens de citer (gros développement), la valeur
ajoutée est sur la technologie. C'est une grosse techno qui coûte cher qu'on
vend. Celle-ci constitue la barrière avec le concurrent qui devra passer
beaucoup de temps pour en avoir une similaire.

On peut aussi vendre des logiciels à faible technologie, mais dans ce cas, il
n'y a pas de barrière technologique. Si on veut empêcher un concurrent de
prendre toutes les parts du marché, il faut trouver un autre type de barrière :
un très bon contact avec le client, une relation privilégiée, un partenariat,
des services spécifiques, une image, un bon réseau de distribution.


III- Logiciel libre.
--------------------

Maintenant, regardons quels « business models » sont viables pour le logiciel
libre.

Pour gagner de l'argent, une boîte doit d'une part se protéger de ses
concurrents, et d'autre part s'en différencier.

Le gros problème lié à la commercialisation du logiciel libre (sous GPL),
c'est que quand vous livrez toutes vos sources, rien n'interdit à votre
concurrent de reprendre votre outil à son compte et de le vendre aussi. Votre
technologie n'est pas protégée. C'est agréable idéologiquement d'avoir un
logiciel en GPL, mais ça peut aussi vous faire perdre de l'argent si vous essayez de
le vendre.

La barrière à l'entrée que constitue la technologie est éliminée.
Voire même dans certains cas, elle est négative. Imaginons un gros
développement technologique qui soit livré sous GPL. Celui-ci coûte cher à son
auteur. Un nouvel entrant arrive. Tout ce qu'il a à faire, c'est récupérer le
développement fait gentiment par son concurrent, et le commercialiser. Comme
il économise sur les coûts de développement, il peut se permettre de dépenser
plus sur la commercialisation. Si le développeur original n'arrive pas à
capitaliser assez sur son expérience, il se sera fait injustement fait prendre
le fruit de ses efforts.

On a vu ça récemment avec le portage de Linux sur Itanium. Il a été fait à
quatre-vingts pourcents par Suse. Quand il fût fini, Redhat l'a recupéré, puis
packagé et vendu. C'est de l'argent facilement gagné par Redhat, facilement perdu
par Suse.

On a vu ça aussi avec la naissance de Mandrake. Au départ, Mandrake, ce
n'était qu'une Redhat pour laquelle on avait packagé Kde. Par la suite,
Mandrake a ajouté ses propres couches par dessus celles de Redhat, mais il n'en reste
pas moins que Mandrake a récuperé tout le travail de Redhat gratuitement.
Étant donné que les trois distributions se partagent aujourd'hui grosso modo
le marché à parts égales, on peut à peu près estimer de façon très simple que
Redhat a perdu cinquante pourcents de son marché.

Je vois souvent des gens critiquer le modèle du logiciel commercial en prônant
le tout-GPL. Mais il faut bien se rendre compte que dans bien des cas, le
modèle du tout-GPL n'est pas économiquement viable.

Ce qu'il faut voir, c'est d'où provient le revenu d'une société :
1. la vente d'un produit logiciel
2. la vente d'un service basé sur un logiciel
3. la vente d'une bibliothèque logicielle

Avec des développements propriétaires, les trois modèles peuvent être viables.

Attention, le modèle 1, c'est uniquement la vente d'un produit fini sans
service. Sinon, c'est le modèle 2.

Avec du logiciel GPL:
- Le 1 n'est pas viable. Votre concurrent n'aura qu'à recuperer tout votre
développement pour le vendre à votre place. Vous ne pouvez pas capitaliser
sur votre expérience puisqu'elle est déjà incluse dans votre produit. Vous
pouvez uniquement jouer sur votre image et votre relation client, ce qui
est très risqué comme unique moyen de sécuriser une position sur un marché.
On est dans le cas d'une barrière à l'entrée negative, c'est-à-dire qu'un
nouvel entrant intelligent est en meilleur position que vous, puisqu'il
recupère vos développements sans les payer.

- Le 2 est le modèle souvent prôné dans le logiciel libre. Ce sont ceux qui ont
développe le logiciel libre qui vendent du service dessus. Ils peuvent
capitaliser sur leur expérience et n'ont qu'à développer leur relation
client. En général, ça marche bien si on trouve des clients. Cependant, un
concurrent peut toujours arriver, acquérir de
l'expérience et revendre le même service. C'est ce qu'il semble se passer
dans l'affaire MySql. Si le marché trop petit, le simple fait de le
segmenter peut suffire à tuer les deux acteurs.

- Le 3 est en général viable. Avec une bibliothèque logicielle, toute entreprise
raisonnable achète du support. Comme votre bibliotheque est en GPL,
l'entreprise utilisatrice devra mettre son produit en GPL et si c'est un
produit qu'elle vend, elle ne le voudra probablement pas (parce qu'elle ne veut
pas se retrouver dans le cas 1. Donc elle achètera une licence commerciale
qui coûte cher et vous gagnerez de l'argent. C'est le modèle choisi par
Trolltech pour Qt et par l'ex-Cygnus pour Cygwin [1]. Le risque est que votre
bibliothèque soit utilisée pour un produit interne, auquel cas la GPL peut
convenir et vos clients ne vous achètent rien.

Si vous vendez votre bibliothèque en LGPL, vous vous retrouvez dans le cas 1
(donc très risqué), avec le seul espoir de vendre du service dessus. Si vous
vous retrouvez à vendre du service sur votre bibliothèque, c'est d'une part
qu'elle est difficile à utiliser donc pas géniale, d'autre part que vous êtes
dans le cas 2.

Une petite remarque tout de même. Je parle de modèle viable et non viable. On
va sûrement m'exhiber des sociétés vivant du modèle 1, alors que je viens
de le décrire comme non viable. Le terme viable ici est à prendre dans le sens
« viable à long terme », c'est-à-dire « qui ne risque pas de disparaître ». On
peut faire de l'argent en étant dans le modèle 1 pendant des années sans avoir
de soucis. Mais le jour où quelqu'un se rend compte qu'il peut se faire de
l'argent facilement avec votre technologie, vous êtes grillés. Le risque est
important. Notamment, si vous commencez à gagner beaucoup d'argent, des petits
malins vont vouloir vous en prendre et vous devriez éviter de leur donner
votre technologie.

Il y a un cas qui n'est pas traité dans cette brève présentation, c'est quand
une entreprise récupère un logiciel GPL développé bénevolement et le
commercialise. Certes, elle peut s'accomoder du modèle GPL, mais si le logiciel
est un produit, elle se retrouve dans la situation 1. Comme toute entreprise
n'aime pas prendre de risques, même quand elle n'a pas payé le developpement,
elle va plutôt essayer de récupérer les développeurs sous son aile de façon à
pouvoir changer la licence. C'est ce qui s'est passe en ce moment pour TuxRacer.
C'est ce qui est en train de se passer pour Quanta (et cela ne fait pas la joie de
tout le monde, cf http://dot.kde.org/995743381/995776534/(...)) et pour deux ou trois
autres produits de The Kompany.

Du point de vue d'un développeur libre, on est rarement content quand un
« fork » se produit, c'est-à-dire qu'un autre projet démarre à partir de votre
projet. Mais quand on est une société et qu'un concurrent récupère votre
produit principal, c'est un risque de faillite donc c'est très grave. Tout ce
qui permet de s'en prémunir est bon.


IV: Conclusions
----------------

C'est pour ça que je pense que si une société veut vendre TuxRacer sans
prendre de risque inutile, elle ne doit pas le releaser sous GPL. Certains ont
imaginé que l'on pourrait garder le moteur en GPL et ne vendre que les
graphismes. Mais le risque reste encore trop important. Une societe
concurrente peut très bien payer une équipe de trois personnes pendant
trois mois pour refaire un jeu complet à partir du moteur et vous griller
sur votre marché. Donc il faut tout passer sous une licence commerciale.

Si les gens d'Id Software avaient mis son moteur 3D sous GPL, ils seraient
beaucoup beaucoup moins riches à l'heure actuelle. Peut-être même qu'ils
auraient coulé, à cause du manque à gagner.

Il y a à Paris une boîte dont j'ai oublié le nom qui est en train de
développer un jeu dont le moteur sera sous GPL mais pas les graphismes ou les
clients (je ne me souviens plus très bien des détails). Je leur envois tous
mes voeux de réussite, mais je crois qu'ils se placent dans une position très
dangereuse d'un point de vue de rentabilité de leur société.

Les implications de cette petite démonstration vont loin. Il n'y aura
jamais à mon avis de jeux sous Linux, développé par une société, en GPL. Un jeu
ça coûte très très cher à développer (une très bonne équipe de dix personnes
pendant trois ans, à plein temps) et une société ne peut se permettre de risquer
un tel investissement. Il n'y a que deux types de jeu sous Linux pour
l'instant. Ceux qui sont sous une licence commerciale payante et ceux,
purement GPL, qui sont developpés par des bénévoles. Ces derniers étant
réalisés par des personnes non payées, sur leur temps libre, ils ont beaucoup
de mal à atteindre en qualité et en diversité les logiciels commerciaux. Le
travail d'une équipe pendant dix personne pendant trois ans, c'est dur à récuperer
sur ses week-ends et ses soirées [2].


Personellement, je rêve depuis longtemps d'être payé pour developper un
logiciel sous GPL. La découverte de ce que je viens de vous exposer m'a
fichu un coup. Alors, le GPL (à part pour mettre dans les voitures), ça sert à
rien ? En tout cas, ça ne peux pas rapporter d'argent ?

Ce qui est sûr, c'est que vendre un produit et le développer sous GPL est
incompatible. Ce qui reste possible, c'est vendre une bibliothèque sous GPL
(Bravo Trolltech !) ou vendre des services basés sur des logiciels GPL (Vive
Zope !).

Pour une société, il est également très intéressant d'utiliser des logiciels
GPL s'ils fournissent les même fonctionnalités que des logiciels payants, ça
coûte moins cher. Et si les logiciels ne sont pas tout à fait a niveau, ça
peut même être super rentable de payer les développeurs pour qu'ils
rajoutent ce qu'il faut, plutôt que d'acheter ce qui manque. En fait, c'est
un des modèles les plus intéressants pour une société. Si elle a un besoin
qu'elle pourrait couvrir par un développement, qui n'a rien à voir
avec ce dont elle tire son revenu, elle a tout interêt à s'associer avec
d'autres qui ont le même besoin et à payer une petite équipe pour faire ça en
GPL. C'est cela qui a donné naissance à Apache et à d'autres logiciels serveurs
très utilises.

Et puis si une societe montée par des fans de logiciel libre vend un produit
sous licence commercial qui marche bien, ça peut lui permettre de faire du
logiciel libre _par ailleurs_.

Je vous invite tous à réflechir à la demarche de Suse. Oui, leur outil
d'installation n'est pas sous GPL. Oui, il est interdit de copier une Suse.
Oui, elle n'est pas disponible gratos sur le net pour l'install. Mais du coup,
il n'est pas possible de faire à Suse ce que Mandrake a fait à Redhat. Suse
possède réellement sa distribution. Et certes, elle ne donne pas ses outils de
config. Mais elle est une des distributions qui paye le plus de developpeurs.
Je n'ai pas la liste detaillée, mais Suse paye au moins deux developpeurs de
XFree, tout le projet alsa, quatre ou cinq développeurs sur le noyau
Linux, cinq développeurs pour Kde, un développeur pour Gnome, des développeurs sur
la libc. Donc quand on dit que Suse ne redonne pas à la communaute, je ne suis
pas du tout d'accord. Payer des développeurs, ça me parait autrement plus
productif et utile que de mettre HardDrake sous GPL.


---
1: Et oui, peu de gens le savent mais il est écrit je ne sais plus ou que
comme la libc patchée et utilisée par cygwin est en GPL, tout programme produit
avec cygwin gcc est en GPL. Pour faire du propriétaire avec, vous devez payez
une licence de 10000 dollars !

2: Cela dit, on voit des jeux magnifiques arriver en GPL. Comme d'une part
l'industrie du jeu peine à apporter de nouveaux concepts, et d'autre part les
jeux en GPL peuvent se réutiliser les uns les autres, on va peut-être finir
par avoir un jeu de qualité commerciale sous GPL.

Peut-être.

Quand on aura des scénaristes notamment.

Mignon

Posté par Anonyme () le 14/08/2001 à 16:10. (lien). Évalué à 1.

C'est mignon de decouvrir la realite des entreprises...

Bref la societe de jeux parisienne que tu cites s'appelle Nevrax ( http://www.nevrax.com(...)
http://www.nevrax.org(...))
Elle developpe son jeux selon ce concept il me semble :
Un moteur de jeux en GPL (Nel) et un acces au jeu en reseau par abonnement.
Evidement ce principe est valable pour les jeux a monde persistant et non les quakes like.

a mon avis l'avenir du jeux se positionne sur l'abonnement d'un service (reseau etc.)
plutot que la vente d'un CD facilement piratable.

ps : commentaire sans accents :)

SHen

Comment Financer le GPL ?

Posté par philippe lhardy (page perso, ) le 14/08/2001 à 16:24. (lien). Évalué à 1.

Bon, on fait le developpement en GPL et apres on cherche a rapporter de l'argent avec...
Et pouquoi ne pas poser le probleme dans l'autre sens ?
Il y a demande, on cree une bourse de requete qui collecte des fonds pour faire des developpements en GPL. Ceux qui developpent se paient mais le logiciel final est en GPL. Lorsque le logiciel sort et bien les parties prenantes ont deja ete payees. Si les gens veulent des ameliorations et bien ils investissent sur le produit et cette argent sert a continuer le developpement.
La question que je vois venir est "comment evaluer le travail de chacun ? Comment eviter les arnaques ? etc..." Et bien je n'en sais rien sinon j'aurai deja cree ma boite :-)

PS: desole pour les accents mais mon clavier n'en dispose pas.

Constat : soyez plus indulgent envers SuSE...

Posté par Anonyme () le 15/08/2001 à 09:04. (lien). Évalué à 2.

Ok ils ne sont pas parfaits. Ok Yast et Sax sont proprios. Ok ils ont virés au moins 90 Personnes cette année.

Mais ils en font vivre au moins 480. Ils ont contribué pour Xfree, KDE , USB, Alsa. Ils ont au moins 20 personnes qui travail sur ça contre 3 pour Mandrake.

Ils ont contribué pour Itanium à 80% et Redhat et Mandrake n'ont quasiment rien fait. (Au passant, a titre de reconnaissance, ils auraient pu donner un peu aux developpeurs SuSE).

SuSE travail sur AMD hammer 64 bits.

Donc, SVP, ne souhaitez pas la mort de SuSE car sans elle on sait pas ce qui adviendrez de Linux.

Je suis fervent defenseur de la GPL et je suis pour Yast en Open Source.

Mais sachez que : Il vaut mieux avoir SuSE de son coté (GPL, Linux) que de voir mourir des société commerciales Linux mourir et voi perdurer le monopole de MS.


A+

suse est copiable

Posté par Anonyme () le 16/08/2001 à 11:12. (lien). Évalué à 0.

suse est copiable
=================


il faut rectifier : "il est interdit de copier
une Suse" car en fait seul les packages payants
sont interdits de copie puisque suse en fourni
des licences dans sa boite, ils sont isoles dans
le groupe de package nomme "payant", et donc
on peut installer autant de copie de suse qu'on
veut du moment qu'on utilise pas ce groupe de
packages... en tout cas vu que suse a isole les
packages a licence je vois mal comment ils
pourraient justifier d'interdir la copie de
logiciels qui dont clairement identifies comme
libres juste parceque l'outil d'install ne l'est
pas, et si c'est le cas ils devraient etre
obliges de placer leur outil d'install dans le
groupe payant aussi... quand meme GNU c'est
pas BSD, suse n'as pas le droit de faire
avec linux ce que apple a fait avec freebsd...

Revenir en haut de page