Protéger un script

[Merwin]

Bonjour à tous,

J'aimerais savoir s'il existe un moyen de permettre aux utilisateur
d'éxecuter un script bash, mais pas de le dire ?

L'idée étant que je ne souhaite pas qu'ils puissent consulter la source
de mon script, mais qu'ils puissent l'éxécuter.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@...
En cas de soucis, contactez EN ANGLAIS listmaster@...

[Basile Starynkevitch]

Merwin wrote:
> Bonjour à tous,
>
> J'aimerais savoir s'il existe un moyen de permettre aux utilisateurs
> d'éxecuter un script bash, mais pas de le dire ?
>
> L'idée étant que je ne souhaite pas qu'ils puissent consulter la source
> de mon script, mais qu'ils puissent l'éxécuter.

Et pourquoi donc? C'est l'intérêt des scripts, d'être facilement lu par
des humains.

Sinon, on peut toujours coder en C le petit programme "wrapper" qui
englobe l'appel au shell. On pourrait aussi dans certains cas et avec
certains shells, s'amuser avec les permissions.

Mais moi je ne vois pas l'intérêt de cacher des choses à l'utilisateur.
La philosophie du logiciel libre, c'est bien de le montrer à qui veut!

Et si ce script contient des mots de passe ou autre il y a aura des
malins qui arriveront à le lire.

Cordialement.

--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: [phone]
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@...
En cas de soucis, contactez EN ANGLAIS listmaster@...

[Kevin Hinault]

Le 27 octobre 2009 17:33, Basile STARYNKEVITCH
<basile@...> a écrit :

> Merwin wrote:
>>
>> Bonjour à tous,
>>
>> J'aimerais savoir s'il existe un moyen de permettre aux utilisateurs
>> d'éxecuter un script bash, mais pas de le dire ?
>>
>> L'idée étant que je ne souhaite pas qu'ils puissent consulter la source de
>> mon script, mais qu'ils puissent l'éxécuter.
>
> Et pourquoi donc? C'est l'intérêt des scripts, d'être facilement lu par des
> humains.
>
> Sinon, on peut toujours coder en C le petit programme "wrapper" qui englobe
> l'appel au shell. On pourrait aussi dans certains cas et avec certains
> shells, s'amuser avec les permissions.
>
> Mais moi je ne vois pas l'intérêt de cacher des choses à l'utilisateur. La
> philosophie du logiciel libre, c'est bien de le montrer à qui veut!
>
> Et si ce script contient des mots de passe ou autre il y a aura des malins
> qui arriveront à le lire.

Comme le fait remarquer Basile, ce n'est pas dans l'esprit du Logiciel
Libre de fournir des binaires sans les sources à côté.

Cependant c'est possible et Gangan avait fait un billet sur ce sujet
il y a quelque mois :
http://www.system-linux.eu/index.php?post/2009/01/17/Compiler-script-shell

--
Kévin
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
http://identi.ca/khi - http://twitter.com/kh_i - http://system-linux.eu
Nick IRC : khi sur irc.mozilla.org - irc.debian.org - irc.freenode.net

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@...
En cas de soucis, contactez EN ANGLAIS listmaster@...

[Merwin]

Kevin Hinault a écrit :

> Le 27 octobre 2009 17:33, Basile STARYNKEVITCH
> <basile@...> a écrit :
>  
>> Merwin wrote:
>>    
>>> Bonjour à tous,
>>>
>>> J'aimerais savoir s'il existe un moyen de permettre aux utilisateurs
>>> d'éxecuter un script bash, mais pas de le dire ?
>>>
>>> L'idée étant que je ne souhaite pas qu'ils puissent consulter la source de
>>> mon script, mais qu'ils puissent l'éxécuter.
>>>      
>> Et pourquoi donc? C'est l'intérêt des scripts, d'être facilement lu par des
>> humains.
>>
>> Sinon, on peut toujours coder en C le petit programme "wrapper" qui englobe
>> l'appel au shell. On pourrait aussi dans certains cas et avec certains
>> shells, s'amuser avec les permissions.
>>
>> Mais moi je ne vois pas l'intérêt de cacher des choses à l'utilisateur. La
>> philosophie du logiciel libre, c'est bien de le montrer à qui veut!
>>
>> Et si ce script contient des mots de passe ou autre il y a aura des malins
>> qui arriveront à le lire.
>>    
>
>
> Comme le fait remarquer Basile, ce n'est pas dans l'esprit du Logiciel
> Libre de fournir des binaires sans les sources à côté.
>
> Cependant c'est possible et Gangan avait fait un billet sur ce sujet
> il y a quelque mois :
> http://www.system-linux.eu/index.php?post/2009/01/17/Compiler-script-shell
>
>  

Merci à vous deux, ce n'est pas dans un but purement égoiste, mais si
j'offre un service à mes clients qui ont un accès SSH sur la machine, je
ne souhaite pas que ce script se retrouve par inadvertance chez un
concurrent ;-)

C'est vraiment un cas exceptionnel!

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@...
En cas de soucis, contactez EN ANGLAIS listmaster@...

[Basile Starynkevitch]

Kevin Hinault wrote:

> Le 27 octobre 2009 17:33, Basile STARYNKEVITCH
> <basile@...> a écrit :
>> Merwin wrote:
>>> Bonjour à tous,
>>>
>>> J'aimerais savoir s'il existe un moyen de permettre aux utilisateurs
>>> d'éxecuter un script bash, mais pas de le dire ?
>>>
>>> L'idée étant que je ne souhaite pas qu'ils puissent consulter la source de
>>> mon script, mais qu'ils puissent l'éxécuter.

>> Sinon, on peut toujours coder en C le petit programme "wrapper" qui englobe
>> l'appel au shell. On pourrait aussi dans certains cas et avec certains
>> shells, s'amuser avec les permissions.

>> Et si ce script contient des mots de passe ou autre il y a aura des malins
>> qui arriveront à le lire.
>
>
> Comme le fait remarquer Basile, ce n'est pas dans l'esprit du Logiciel
> Libre de fournir des binaires sans les sources à côté.
>
> Cependant c'est possible et Gangan avait fait un billet sur ce sujet
> il y a quelque mois :
> http://www.system-linux.eu/index.php?post/2009/01/17/Compiler-script-shell

Oui, mais la protection fournie est illusoire. Un shell ça organise
surtout des tas d'appels systèmes, qu'on peut tracer par des outils
comme strace ou ltrace.

Moi je voudrais comprendre quand même ce que Merwin croit cacher dans ce
script. Mon intuition, c'est qu'il se fait de grosses illusions sur la
pseudo-sécurité d'une telle approche.

Rendre le code source d'un shell script illisible par un utilisateur ne
suffit pas à cacher ce que fait ce script.

J'insiste pour Merwin: s'il ne prend pas d'autres précautions, sa
protection ne sert à rien. Il faudrait donc qu'il explique un peu plus
ce qu'il cherche à cacher.

Merwin explique vaguement:

> Merci à vous deux, ce n'est pas dans un but purement égoïste, mais si j'offre un service à mes clients qui ont un accès SSH sur la machine, je ne souhaite pas que ce script se retrouve par inadvertance chez un concurrent ;-)

La protection contre ce genre de piratage est de nature légale (un
copyright, une licence, un contrat) ou sociale, pas technique. Et je ne
crois pas trop qu'un concurrent prenne la peine de voir ce script.

En plus, le fait que Merwin envisage de cacher juste un script me fait
méchamment penser qu'il ne maîtrise pas toutes les subtilités de la
sécurité d'un système (autrement il n'aurait pas formulé sa question
telle qu'il l'a initialement fait). Donc sa concurrence n'a pas intérêt
à copier la mauvaise solution de Merwin, mais à faire mieux donc autrement.

Si on veut restreindre l'accès par SSH il est préférable d'utiliser un
shell restreint pour ça. http://en.wikipedia.org/wiki/Restricted_shell
mais c'est difficile à configurer correctement.

De manière plus générale, le fantasme de la sécurité par l'obscurité
reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre
à ses clients, c'est qu'il est un bon commercial, pas forcément un bon
technicien. http://en.wikipedia.org/wiki/Security_through_obscurity

Librement

--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: [phone]
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@...
En cas de soucis, contactez EN ANGLAIS listmaster@...

[Vera Mickael]

> De manière plus générale, le fantasme de la sécurité par l'obscurité
> reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre
> à ses clients, c'est qu'il est un bon commercial, pas forcément un bon
> technicien. http://en.wikipedia.org/wiki/Security_through_obscurity

Je ne vois pas le rapport entre le besoin initial et les
divagations de Basile ?

L'objet de la question initiale est de protéger la source
d'un travail facturé à un client. Il est légitime qu'un
client ne souhaite pas qu'un travail qu'il a financé profite
aussi à ses concurrents.

L'obscurcissement des sources est une solution à moindre
coût qui peut apporter satisfaction. Je ne juge pas par
contre de la qualité de la solution shc.

Quel est le rapport avec la sécurité par l'obscurcissement
qui vise à protéger un système des attaques? Je ne vois pas?

Je rappelle que les premières questions à se poser quand on
veut mettre en place de la sécurité sont:

- qui est susceptible de m'attaquer
- quelle est la valeur de ce que je protège
- quelles moyens suis-je prêt à mettre en oeuvre

Protéger un script qui a demandé une semaine de
développement contre un prestataire qui pourrait venir
intervenir sur la machine ne nécessite pas un degré de
protection élevé contrairement à un système militaire qui
est susceptible de se faire attaquer par une centaine de
spécialistes de la CIA.

Le prestataire sera vite découragé si il n'arrive pas à
récupérer la source au bout de 2h. Je pense qu'une solution
par l'obscurcissement est satisfaisante dans pas mal de cas.

Mickaël

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@...
En cas de soucis, contactez EN ANGLAIS listmaster@...

[Yves Rutschle]

On Wed, Oct 28, 2009 at 12:18:41PM +0100, Vera Mickael wrote:
> Quel est le rapport avec la sécurité par l'obscurcissement qui vise à
> protéger un système des attaques? Je ne vois pas?

Bah, on cherche à protéger le code source (ou le script,
j'ai pas très bien compris) contre la copie.

Il vient de me venir une idée d'ailleurs: faire tourner le
script derrière une fifo, et donner aux utilisateurs une
autre commande qui écrit dans la fifo. On peut alors garder
le script totalement invisible pour l'utilisateur. Ça pose
par contre d'autres problèmes (comment le script sait-il que
l'utilisateur a le droit d'executer le script, comment
sait-il s'il se fait passer pour un autre utilisateur...)

Y.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@...
En cas de soucis, contactez EN ANGLAIS listmaster@...

[Kevin Hinault]

Mode vendredi ON.

Le 28 octobre 2009 12:18, Vera Mickael <vera.mickael@...> a écrit :
>>
>> De manière plus générale, le fantasme de la sécurité par l'obscurité reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre à ses clients, c'est qu'il est un bon commercial, pas forcément un bon technicien. http://en.wikipedia.org/wiki/Security_through_obscurity
>
> Je ne vois pas le rapport entre le besoin initial et les divagations de Basile ?
>
> L'objet de la question initiale est de protéger la source d'un travail facturé à un client. Il est légitime qu'un client ne souhaite pas qu'un travail qu'il a financé profite aussi à ses concurrents.
>

Je ne suis pas d'accord avec cette affirmation qui est exactement
celles que les éditeurs de logiciels privateurs avancent pour
justifier la privation de liberté.
La création d'une source n'a pas de cout direct, c'est plutôt un
investissement : celui du temps passé à la création du logiciel. Et
contrairement à ce que notre société nous dicte, le temps ce n'est pas
de l'argent. Dans le monde du logiciel libre, le développeur fait le
plus souvent don de son temps à la communauté en désirant juste que
l'on garde la paternité de son travail. L'investissement est le pari
que le client reviendra vers lui.

Je ne dit pas que logiciel libre doit être gratuit mais que son cout
de reproduction est nul et donc qu'il sort de l'économie de la rareté
imposé par notre monde physique pour entrer dans l'économie de
l'abondance.
S'il désire vendre sa création, rien ne l'en empêche. S'il désire le
protéger, les licences existent.

Si n'importe qui désire vendre du logiciel libre, il le peut. C'est
malhonnête mais possible.
C'est tout autant malhonnête de vendre des milliers de clones (sans
cout de fabrications) de ce qui a été créé une seule fois. La solution
économique au logiciel libre n'est donc pas dans le logiciel mais dans
la valeur ajouté par le créateur : le support, le service rendu.

>
> L'obscurcissement des sources est une solution à moindre coût qui peut apporter satisfaction. Je ne juge pas par contre de la qualité de la solution shc.
>
> Quel est le rapport avec la sécurité par l'obscurcissement qui vise à protéger un système des attaques? Je ne vois pas?
>

Basile parlait de sécurité non pas au sens sécurité anti-intrusion
mais au sens d'empêcher quelqu'un de voir comment fonctionne le
script. Il parle de sentiment de sécurité du développeur.

>
> Protéger un script qui a demandé une semaine de développement contre un prestataire qui pourrait venir intervenir sur la machine ne nécessite pas un degré de protection élevé contrairement à un système militaire qui est susceptible de se faire attaquer par une centaine de spécialistes de la CIA.
>
> Le prestataire sera vite découragé si il n'arrive pas à récupérer la source au bout de 2h. Je pense qu'une solution par l'obscurcissement est satisfaisante dans pas mal de cas.
>

Ce n'est pas acceptable, ce n'est que de la dépendance forcé. Le jour
où le client n'est plus le client et qu'il veut faire évoluer son
système, il sera juste bloqué parce que lui et personne  ne pourra
améliorer le script qu'il a pourtant acheté et qui donc lui
appartient. Le logiciel libre va a l'encontre de cette idée de prise
en otage des clients.

Ne pas comprendre tout ça c'est pas passer à côté de l'essentiel dans
le logiciel libre et c'est aussi un grand manque de respect envers les
développeurs dans le monde du logiciel libre. C'est prendre
égoïstement Debian parce que c'est gratuit en se moquant du temps
qu'ils ont passés et pourquoi ils l'ont fait.

Mode Vendredi Off

--
Kévin
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
http://identi.ca/khi - http://twitter.com/kh_i - http://system-linux.eu
Nick IRC : khi sur irc.mozilla.org - irc.debian.org - irc.freenode.net

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@...
En cas de soucis, contactez EN ANGLAIS listmaster@...

[Merwin]

Kevin Hinault a écrit :

> Mode vendredi ON.
>
> Le 28 octobre 2009 12:18, Vera Mickael <vera.mickael@...> a écrit :
>  
>>> De manière plus générale, le fantasme de la sécurité par l'obscurité reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre à ses clients, c'est qu'il est un bon commercial, pas forcément un bon technicien. http://en.wikipedia.org/wiki/Security_through_obscurity
>>>      
>> Je ne vois pas le rapport entre le besoin initial et les divagations de Basile ?
>>
>> L'objet de la question initiale est de protéger la source d'un travail facturé à un client. Il est légitime qu'un client ne souhaite pas qu'un travail qu'il a financé profite aussi à ses concurrents.
>>
>>    
>
> Je ne suis pas d'accord avec cette affirmation qui est exactement
> celles que les éditeurs de logiciels privateurs avancent pour
> justifier la privation de liberté.
> La création d'une source n'a pas de cout direct, c'est plutôt un
> investissement : celui du temps passé à la création du logiciel. Et
> contrairement à ce que notre société nous dicte, le temps ce n'est pas
> de l'argent. Dans le monde du logiciel libre, le développeur fait le
> plus souvent don de son temps à la communauté en désirant juste que
> l'on garde la paternité de son travail. L'investissement est le pari
> que le client reviendra vers lui.
>
> Je ne dit pas que logiciel libre doit être gratuit mais que son cout
> de reproduction est nul et donc qu'il sort de l'économie de la rareté
> imposé par notre monde physique pour entrer dans l'économie de
> l'abondance.
> S'il désire vendre sa création, rien ne l'en empêche. S'il désire le
> protéger, les licences existent.
>
> Si n'importe qui désire vendre du logiciel libre, il le peut. C'est
> malhonnête mais possible.
> C'est tout autant malhonnête de vendre des milliers de clones (sans
> cout de fabrications) de ce qui a été créé une seule fois. La solution
> économique au logiciel libre n'est donc pas dans le logiciel mais dans
> la valeur ajouté par le créateur : le support, le service rendu.
>
>  
>> L'obscurcissement des sources est une solution à moindre coût qui peut apporter satisfaction. Je ne juge pas par contre de la qualité de la solution shc.
>>
>> Quel est le rapport avec la sécurité par l'obscurcissement qui vise à protéger un système des attaques? Je ne vois pas?
>>
>>    
>
> Basile parlait de sécurité non pas au sens sécurité anti-intrusion
> mais au sens d'empêcher quelqu'un de voir comment fonctionne le
> script. Il parle de sentiment de sécurité du développeur.
>
>  
>> Protéger un script qui a demandé une semaine de développement contre un prestataire qui pourrait venir intervenir sur la machine ne nécessite pas un degré de protection élevé contrairement à un système militaire qui est susceptible de se faire attaquer par une centaine de spécialistes de la CIA.
>>
>> Le prestataire sera vite découragé si il n'arrive pas à récupérer la source au bout de 2h. Je pense qu'une solution par l'obscurcissement est satisfaisante dans pas mal de cas.
>>
>>    
>
> Ce n'est pas acceptable, ce n'est que de la dépendance forcé. Le jour
> où le client n'est plus le client et qu'il veut faire évoluer son
> système, il sera juste bloqué parce que lui et personne  ne pourra
> améliorer le script qu'il a pourtant acheté et qui donc lui
> appartient. Le logiciel libre va a l'encontre de cette idée de prise
> en otage des clients.
>
> Ne pas comprendre tout ça c'est pas passer à côté de l'essentiel dans
> le logiciel libre et c'est aussi un grand manque de respect envers les
> développeurs dans le monde du logiciel libre. C'est prendre
> égoïstement Debian parce que c'est gratuit en se moquant du temps
> qu'ils ont passés et pourquoi ils l'ont fait.
>
> Mode Vendredi Off
>
> --
> Kévin
> Membre de l'April - « promouvoir et défendre le logiciel libre » -
> http://www.april.org
> http://identi.ca/khi - http://twitter.com/kh_i - http://system-linux.eu
> Nick IRC : khi sur irc.mozilla.org - irc.debian.org - irc.freenode.net
>
>  

J'interviens pour expliquer le pourquoi du comment, je loue des shells à
des utilisateurs, ils ont donc accès des ressources sur la machine, en
plus de ça je mets à leurs disposition des scripts bash fais par mes
soins permettant pour eux l'automatisation de certaines taches, comme
l'insatallation, la compilation automatique d'un logiciel X.

Je ne souhaite pas que d'autres concurrents utilisent mes scripts pour
fournir le même service à leurs utilisateurs.

Si c'est contre le logiciel je m'en excuse et je suis bien entendu prêt
à changer ma façon de faire,

Cordialement


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@...
En cas de soucis, contactez EN ANGLAIS listmaster@...

[François TOURDE-5]

Le 14545ième jour après Epoch,
Vera Mickael écrivait:

>> De manière plus générale, le fantasme de la sécurité par l'obscurité
>> reste un fantasme, et n'est pas la réalité. Si Merwin arrive à le
>> vendre à ses clients, c'est qu'il est un bon commercial, pas
>> forcément un bon
>> technicien. http://en.wikipedia.org/wiki/Security_through_obscurity
>
> Je ne vois pas le rapport entre le besoin initial et les divagations
> de Basile ?

Il est trivial pourtant: "cacher" un shell est relativement illusoire,
car il sera toujours possible de voir quelles sont les commandes que ce
shell lance (strace), et éventuellement en déduire ensuite les grandes
lignes de ce que ça fait.

> L'objet de la question initiale est de protéger la source d'un travail
> facturé à un client. Il est légitime qu'un client ne souhaite pas
> qu'un travail qu'il a financé profite aussi à ses concurrents.

Mais il est pourtant possible que le client paye pour un logiciel, sans
que ce logiciel soit forcément privateur. C'est exactement ce que j'ai
pû faire durant ces 2 dernières années. Le logiciel est libre,
accessible, et pourtant en grande partie financé par un client.

Dans son esprit (le client), il a payé pour le logiciel, mais surtout
pour l'expérience acquise, la possibilité d'avoir un support pointu, et
la pérennité du logiciel comparé à la pérennité de la société qui l'a
développé.

> Quel est le rapport avec la sécurité par l'obscurcissement qui vise à
> protéger un système des attaques? Je ne vois pas?

Pourtant c'est la même chose. Sécuriser des choses en les cachant est un
mauvais moyen en général. On ne "protège" pas ssh en le faisant écouter
sur un autre port. On ne fait qu'éventuellement augmenter le temps que
va mettre l'attaquant à trouver le bon port.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@...
En cas de soucis, contactez EN ANGLAIS listmaster@...

[Jean-Yves F. Barbier-2]

Kevin Hinault a écrit :
> Mode vendredi ON.

et même Vendredi matin

>
> Le 28 octobre 2009 12:18, Vera Mickael <vera.mickael@...> a écrit :
>>> De manière plus générale, le fantasme de la sécurité par l'obscurité reste un
>>> fantasme, et n'est pas la réalité. Si Merwin arrive à le vendre à ses clients,
>>> c'est qu'il est un bon commercial, pas forcément un bon technicien.
>>> http://en.wikipedia.org/wiki/Security_through_obscurity
>> Je ne vois pas le rapport entre le besoin initial et les divagations de Basile ?
>>
>> L'objet de la question initiale est de protéger la source d'un travail facturé à
>> un client. Il est légitime qu'un client ne souhaite pas qu'un travail qu'il
>> a financé profite aussi à ses concurrents.

houlà, ça c'est un modèle qui date du moyen âge (pgm s/s ZX-81 peut-être)
le modèle actuel est que le client paye le dev, puis que ledit dev est
en Gal reversé en tant que contribution à la communauté; ce qui permet,
entre autres avantages, débugging/amélioration/etc par la communauté
(la programmation, c'est comme le fric, la bagnole et le reste: il-y-en
a toujours un qui en a plus que toi...)

>
> Je ne suis pas d'accord avec cette affirmation qui est exactement
> celles que les éditeurs de logiciels privateurs avancent pour
> justifier la privation de liberté.
> La création d'une source n'a pas de cout direct, c'est plutôt un
> investissement : celui du temps passé à la création du logiciel. Et
> contrairement à ce que notre société nous dicte, le temps ce n'est pas
> de l'argent. Dans le monde du logiciel libre, le développeur fait le
> plus souvent don de son temps à la communauté en désirant juste que
> l'on garde la paternité de son travail. L'investissement est le pari
> que le client reviendra vers lui.

je plussois
 
> Je ne dit pas que logiciel libre doit être gratuit mais que son cout
> de reproduction est nul et donc qu'il sort de l'économie de la rareté
> imposé par notre monde physique pour entrer dans l'économie de
> l'abondance.

c'est ausi en Gal un juste retour des choses: on "prend" à la communauté,
et on lui "rend" par la mise à disposition d'un travail (correctement exécuté,
s'entend.)

> S'il désire vendre sa création, rien ne l'en empêche. S'il désire le
> protéger, les licences existent.

et il-y-en a pour tous les goûts des licenses; .

> Si n'importe qui désire vendre du logiciel libre, il le peut. C'est
> malhonnête mais possible.

heureusement, les diverses associations libres veillent de plus en plus
au grain, et l'on sent pointer une reconnaissance certaine des licenses
type GPL un peu partout en europe.

> C'est tout autant malhonnête de vendre des milliers de clones (sans
> cout de fabrications) de ce qui a été créé une seule fois. La solution
> économique au logiciel libre n'est donc pas dans le logiciel mais dans
> la valeur ajouté par le créateur : le support, le service rendu.

wai, c'est exactement comme de dire qu'un d'jeun va regretter les photos
d'une fête arrosée mises en ligne: y'a que les vieux cons pour penser que
c'est le reflet de toute sa vie et surtout _juger_ une personne là-dessus.

>> L'obscurcissement des sources est une solution à moindre coût qui peut
>> apporter satisfaction. Je ne juge pas par contre de la qualité de la solution shc.

c'est faux: depuis que le monde est monde, dès qu'un type a voulu se garder
quelque chose sans partager, il-y-en a toujours eu un autre, en Gal plus brillant,
qui regardait par-dessus son épaule et "libérait" le savoir (fausse monnaie,
reverse engineering, cracking des protections, contournement logiciel des dongles
hardware, ...)
c'est juste une question de temps et de compétence (cf, par exemple, la dissection
du fonctionnement intime de skype, en son temps, par des spécialistes de la sécurité)

>> Quel est le rapport avec la sécurité par l'obscurcissement qui vise à protéger
>> un système des attaques? Je ne vois pas?
>>
>
> Basile parlait de sécurité non pas au sens sécurité anti-intrusion
> mais au sens d'empêcher quelqu'un de voir comment fonctionne le
> script. Il parle de sentiment de sécurité du développeur.
>
>> Protéger un script qui a demandé une semaine de développement contre
>> un prestataire qui pourrait venir intervenir sur la machine ne nécessite
>> pas un degré de protection élevé contrairement à un système militaire
>> qui est susceptible de se faire attaquer par une centaine de spécialistes de la CIA.

la CIA n'a pas les services idoines: ce sont le FBI et la NSA qui font ce type de boulot.
et la plupart du temps, les réseaux militaires très sensibles US sont carrément totalement
déconnectés de l'Internet (et passent par leurs propres fibres/cuivres.)

>> Le prestataire sera vite découragé si il n'arrive pas à récupérer la source au
>> bout de 2h. Je pense qu'une solution par l'obscurcissement est satisfaisante
>> dans pas mal de cas.
>>
>
> Ce n'est pas acceptable, ce n'est que de la dépendance forcé. Le jour
> où le client n'est plus le client et qu'il veut faire évoluer son
> système, il sera juste bloqué parce que lui et personne  ne pourra
> améliorer le script qu'il a pourtant acheté et qui donc lui
> appartient. Le logiciel libre va a l'encontre de cette idée de prise
> en otage des clients.

vi, un simple exemple: le client n'a qu'un binaire, le dev meurt, le client
se retrouve dans la merde (ça fait aussi partie d'un service au client de
qualité que de prévoir ce genre de situation.)

> Ne pas comprendre tout ça c'est pas passer à côté de l'essentiel dans
> le logiciel libre et c'est aussi un grand manque de respect envers les
> développeurs dans le monde du logiciel libre. C'est prendre
> égoïstement Debian parce que c'est gratuit en se moquant du temps
> qu'ils ont passés et pourquoi ils l'ont fait.

il existe aussi un modèle assez viable, utilisé lorsque le dev a vraiment coûté
très cher: on met une license restrictive, on vend le module, et lorsque le dev
est remboursé, on repasse le tout en libre & gratuit (OpenERP faisait ça un
moment); mais le tout reste dans un cadre dans lequel le client a les sources,
juste au cas où...

> Mode Vendredi Off

ptêt pas :D

perso j'ai vu le cas de ce type de PB (pas de sources) au niveau des cinémas d'arts
et d'essais: la boîte d'origine a mis la cabane sur le chien, et comme l'ancien
gérant faisait de la résistance (les source, c'est $$$), il a fallu une décision
de justice pour que ces sources réapparaissent; une autre entreprise a repris le
tout et a intégralement réécrit le soft en java et en GPL pour que tout soit portable
(les gros cinémas sont en *ix, les petits en w$) et que cette situation ne se reproduise plus.

étant donné la technicité qui est nécessaire pour mettre en oeuvre cette solution,
la mise en GPL n'a pas altérée les subsides de l'entreprise qui se paye sur les
prestations de service; et assure une grande sécurité aux clients en cas de chasse.

--
What did Mickey Mouse get for Christmas?
A Dan Quayle watch.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@...
En cas de soucis, contactez EN ANGLAIS listmaster@...

[Jean-Yves F. Barbier-2]

François TOURDE a écrit :
...

>
> Mais il est pourtant possible que le client paye pour un logiciel, sans
> que ce logiciel soit forcément privateur. C'est exactement ce que j'ai
> pû faire durant ces 2 dernières années. Le logiciel est libre,
> accessible, et pourtant en grande partie financé par un client.
>
> Dans son esprit (le client), il a payé pour le logiciel, mais surtout
> pour l'expérience acquise, la possibilité d'avoir un support pointu, et
> la pérennité du logiciel comparé à la pérennité de la société qui l'a
> développé.

Sans oublier non plus le fait que le soft colle *exactement* aux
besoins/désirs du client!

--
Other than that, Mrs. Lincoln, how did you like the play?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@...
En cas de soucis, contactez EN ANGLAIS listmaster@...

[Vera Mickael]

Je ne pensais déclencher tant de réactions avec mon mail :-)

Le logiciel libre est bien entendu un concept intéressant,
je suis le premier utilisateur ET contributeur à l'occasion
dans le cadre de mon travail.

Autant l'objectif des sources libres est très attrayant,
aujourd'hui le modèle économique du logiciel libre ne permet
pas d'envisager tous les développements avec un retour sur
investissement garanti.

> La création d'une source n'a pas de cout direct, c'est plutôt un
> investissement : celui du temps passé à la création du logiciel. Et
> contrairement à ce que notre société nous dicte, le temps ce n'est pas
> de l'argent. Dans le monde du logiciel libre, le développeur fait le
> plus souvent don de son temps à la communauté en désirant juste que
> l'on garde la paternité de son travail. L'investissement est le pari
> que le client reviendra vers lui.

Je ne suis pas d'accord pour dire que la création d'une
source n'a pas de coût direct. Comment peut-on dire cela? Ma
société développe un logiciel qui cumule aujourd'hui 25
années hommes de développement, je te laisse faire le calcul
du coût. Bien entendu pour financer le développement nous
vendons ce produit.

Effectivement le coût de reproduction est nul. C'est bien
pourquoi rendre un logiciel libre c'est prendre le risque
que quelqu'un reprenne le développement à son compte.

> cout de fabrications) de ce qui a été créé une seule fois. La solution
> économique au logiciel libre n'est donc pas dans le logiciel mais dans
> la valeur ajouté par le créateur : le support, le service rendu.

Le risque c'est qu'une société investisse des millions
d'euros (c'est le coût d'un gros logiciel) et qu'une autre
société vende du conseil sans avoir besoin de rentabiliser
l'investissement. Qui va investir si cela se passe comme ça?

> Basile parlait de sécurité non pas au sens sécurité anti-intrusion
> mais au sens d'empêcher quelqu'un de voir comment fonctionne le
> script. Il parle de sentiment de sécurité du développeur.

Le lien qu'il a envoyé discutait de l'impact sur la sécurité
de l'obscurcissement du système ce qui me semble est hors
sujet, c'est pour cela que j'ai réagi.

> Ce n'est pas acceptable, ce n'est que de la dépendance forcé. Le jour
> où le client n'est plus le client et qu'il veut faire évoluer son
> système, il sera juste bloqué parce que lui et personne  ne pourra
> améliorer le script qu'il a pourtant acheté et qui donc lui
> appartient. Le logiciel libre va a l'encontre de cette idée de prise
> en otage des clients.

Tu fais un raccourci. Tu peux très bien fournir au client
les sources et un moyen de protéger son script lorsqu'il
l'installe. C'est très courant, j'ai travaillé sur plusieurs
systèmes qui fonctionnent comme cela avec une clé à
brancher. (Peu m'importe la fiabilité de la protection).

> Ne pas comprendre tout ça c'est pas passer à côté de l'essentiel dans
> le logiciel libre et c'est aussi un grand manque de respect envers les
> développeurs dans le monde du logiciel libre. C'est prendre
> égoïstement Debian parce que c'est gratuit en se moquant du temps
> qu'ils ont passés et pourquoi ils l'ont fait.

Cette vision est simpliste et ne prend pas en compte les
milliards d'euros qui sont investis dans les entreprises
tous les ans pour développer des logiciels.

Perso si je développe un générateur de gallerie web de
photos sur ton mon temps libre j'ai tout intérêt à le
diffuser. Si une société d'aviation développe un protocole
réseau pour ses besoins, elle a tout intérêt à le rendre
libre, cela ne va pas directement profiter à ses
concurrents. Idem pour les labos de recherche.

Mais maintenant si une entreprise qui construit des voitures
développe pour des millions d'euros un logiciel qui permet
d'analyser les bruits parasites dans une voiture elle
espèrera rentabiliser son investissement en vendant des
voitures moins bruyantes que ses concurrents. Si elle rend
son logiciels libre, tous ses concurrents vont utiliser le
logiciel sans avoir à amortir le coût de l'investissement.
C'est l'entreprise qui a investi qui va le moins vendre
puisque ses voitures seront plus chères.

Je ne défends pas le monde de la concurrence et toutes ses
dérives. Je fais un constat et j'en déduis que le modèle
économique du logiciel libre ne permet pas il me semble
aujourd'hui d'envisager de gros investissements.

J'ai beaucoup de respect pour les développeurs du monde
libre et on ne peut que les remercier de leurs
contributions. Cependant je pense qu'on trouvera facilement
un passionné de photo ou de 3D pour développer des
applications sur leur temps libre parce que justement cela
les passionne. Moi le premier j'ai passé des mois à
développer un logiciel de gestion de course à pied parce que
cela m'amusait. Trouver un développeur qui sur son temps
libre va s'amuser à produire un logiciel pour effectuer des
calculs de câblage dans une machine à laver je pense que
cela sera plus dur. Ceux-là il faudra les payer et il faudra
rentabiliser l'investissement.

Simplement dire l'investissement sera rentabilisé par du
conseil autour du produit, c'est ignorer le coût du
développement des gros systèmes.

Je te rejoins sur un point, je trouve dommage que une fois
qu'un logiciel a été développé il ne puisse pas être
librement utilisé. Idem pour les disques. C'est du gâchis de
ne pas pouvoir écouter une musique parce que l'on n'a pas
les moyens de se payer des centaines de disques.

Ce que je ne vois pas aujourd'hui dans notre monde actuel,
c'est comment financer les développement puis les rendre libres.

Mickaël

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@...
En cas de soucis, contactez EN ANGLAIS listmaster@...

[Vera Mickael]

> houlà, ça c'est un modèle qui date du moyen âge (pgm s/s ZX-81 peut-être)
> le modèle actuel est que le client paye le dev, puis que ledit dev est
> en Gal reversé en tant que contribution à la communauté; ce qui permet,

C'est ton avis perso et non argumenté ;-)

Je connais des sociétés pour qui ce modèle fonctionne bien,
Oracle, IBM, Microsoft, BEA, ...

Et je connais aussi beaucoup de clients, EDF, SNCF,
Administrations, fabricants de voitures et d'avions qui
fonctionnent avec ce modèle.

> c'est faux: depuis que le monde est monde, dès qu'un type a voulu se garder
> quelque chose sans partager, il-y-en a toujours eu un autre, en Gal plus brillant,
> qui regardait par-dessus son épaule et "libérait" le savoir (fausse monnaie,
> reverse engineering, cracking des protections, contournement logiciel des dongles
> hardware, ...)

Ca ne regarde que toi de considérer qu'un faux monnayeur ou
un pirate est quelqu'un de plus brillant qu'un inventeur ;-)

> vi, un simple exemple: le client n'a qu'un binaire, le dev meurt, le client
> se retrouve dans la merde (ça fait aussi partie d'un service au client de
> qualité que de prévoir ce genre de situation.)

Les entreprises se prémunissent contre ces désagréments,
vous connaissez mal les contrats qui unissent les éditeurs
de logiciel et leurs client. En général les éditeurs
s'engagent à rendre les sources libres si le logiciel meurt.

Mickaël

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@...
En cas de soucis, contactez EN ANGLAIS listmaster@...

[thveillon.debian]

Vera Mickael a écrit :
> Je ne pensais déclencher tant de réactions avec mon mail :-)
>
> Le logiciel libre est bien entendu un concept intéressant, je suis le
> premier utilisateur ET contributeur à l'occasion dans le cadre de mon
> travail.
>
> Autant l'objectif des sources libres est très attrayant, aujourd'hui le
> modèle économique du logiciel libre ne permet pas d'envisager tous les
> développements avec un retour sur investissement garanti.


Hum, explique ça à RedHat, ça va bien les faire rire !

>> La création d'une source n'a pas de cout direct, c'est plutôt un
>> investissement : celui du temps passé à la création du logiciel. Et
>> contrairement à ce que notre société nous dicte, le temps ce n'est pas
>> de l'argent. Dans le monde du logiciel libre, le développeur fait le
>> plus souvent don de son temps à la communauté en désirant juste que
>> l'on garde la paternité de son travail. L'investissement est le pari
>> que le client reviendra vers lui.
>
> Je ne suis pas d'accord pour dire que la création d'une source n'a pas
> de coût direct. Comment peut-on dire cela? Ma société développe un
> logiciel qui cumule aujourd'hui 25 années hommes de développement, je te
> laisse faire le calcul du coût. Bien entendu pour financer le
> développement nous vendons ce produit.
>
> Effectivement le coût de reproduction est nul. C'est bien pourquoi
> rendre un logiciel libre c'est prendre le risque que quelqu'un reprenne
> le développement à son compte.
>
>> cout de fabrications) de ce qui a été créé une seule fois. La solution
>> économique au logiciel libre n'est donc pas dans le logiciel mais dans
>> la valeur ajouté par le créateur : le support, le service rendu.
>
> Le risque c'est qu'une société investisse des millions d'euros (c'est le
> coût d'un gros logiciel) et qu'une autre société vende du conseil sans
> avoir besoin de rentabiliser l'investissement. Qui va investir si cela
> se passe comme ça?

Il y a de très grosses sociétés qui investissent dans le développement
de logiciels libre, et des états également. Tu devrais peut-être te
documenter un peu sur le sujet...

>> Basile parlait de sécurité non pas au sens sécurité anti-intrusion
>> mais au sens d'empêcher quelqu'un de voir comment fonctionne le
>> script. Il parle de sentiment de sécurité du développeur.
>
> Le lien qu'il a envoyé discutait de l'impact sur la sécurité de
> l'obscurcissement du système ce qui me semble est hors sujet, c'est pour
> cela que j'ai réagi.
>
>> Ce n'est pas acceptable, ce n'est que de la dépendance forcé. Le jour
>> où le client n'est plus le client et qu'il veut faire évoluer son
>> système, il sera juste bloqué parce que lui et personne  ne pourra
>> améliorer le script qu'il a pourtant acheté et qui donc lui
>> appartient. Le logiciel libre va a l'encontre de cette idée de prise
>> en otage des clients.
>
> Tu fais un raccourci. Tu peux très bien fournir au client les sources et
> un moyen de protéger son script lorsqu'il l'installe. C'est très
> courant, j'ai travaillé sur plusieurs systèmes qui fonctionnent comme
> cela avec une clé à brancher. (Peu m'importe la fiabilité de la
> protection).
>
>> Ne pas comprendre tout ça c'est pas passer à côté de l'essentiel dans
>> le logiciel libre et c'est aussi un grand manque de respect envers les
>> développeurs dans le monde du logiciel libre. C'est prendre
>> égoïstement Debian parce que c'est gratuit en se moquant du temps
>> qu'ils ont passés et pourquoi ils l'ont fait.
>
> Cette vision est simpliste et ne prend pas en compte les milliards
> d'euros qui sont investis dans les entreprises tous les ans pour
> développer des logiciels.
>
> Perso si je développe un générateur de gallerie web de photos sur ton
> mon temps libre j'ai tout intérêt à le diffuser. Si une société
> d'aviation développe un protocole réseau pour ses besoins, elle a tout
> intérêt à le rendre libre, cela ne va pas directement profiter à ses
> concurrents. Idem pour les labos de recherche.
>
> Mais maintenant si une entreprise qui construit des voitures développe
> pour des millions d'euros un logiciel qui permet d'analyser les bruits
> parasites dans une voiture elle espèrera rentabiliser son investissement
> en vendant des voitures moins bruyantes que ses concurrents. Si elle
> rend son logiciels libre, tous ses concurrents vont utiliser le logiciel
> sans avoir à amortir le coût de l'investissement. C'est l'entreprise qui
> a investi qui va le moins vendre puisque ses voitures seront plus chères.
>
> Je ne défends pas le monde de la concurrence et toutes ses dérives. Je
> fais un constat et j'en déduis que le modèle économique du logiciel
> libre ne permet pas il me semble aujourd'hui d'envisager de gros
> investissements.

Là tu est mûr pour utiliser Winchose ou MacOS. C'est Novell, RedHat, IBM
et bien d'autres qui doivent soudain être pris d'une angoisse terrible :
ils viennent de découvrir que leur modèle économique n'est pas viable,
et ne permet pas de gros investissements... Zut alors. ;-)

>
> J'ai beaucoup de respect pour les développeurs du monde libre et on ne
> peut que les remercier de leurs contributions. Cependant je pense qu'on
> trouvera facilement un passionné de photo ou de 3D pour développer des
> applications sur leur temps libre parce que justement cela les
> passionne. Moi le premier j'ai passé des mois à développer un logiciel
> de gestion de course à pied parce que cela m'amusait. Trouver un
> développeur qui sur son temps libre va s'amuser à produire un logiciel
> pour effectuer des calculs de câblage dans une machine à laver je pense
> que cela sera plus dur. Ceux-là il faudra les payer et il faudra
> rentabiliser l'investissement.
>
> Simplement dire l'investissement sera rentabilisé par du conseil autour
> du produit, c'est ignorer le coût du développement des gros systèmes.
>
> Je te rejoins sur un point, je trouve dommage que une fois qu'un
> logiciel a été développé il ne puisse pas être librement utilisé. Idem
> pour les disques. C'est du gâchis de ne pas pouvoir écouter une musique
> parce que l'on n'a pas les moyens de se payer des centaines de disques.

Tu as des doutes au sujet du logiciel libre, mais du piratage non...
Vive la liberté temps qu'elle me profite exclusivement...

>
> Ce que je ne vois pas aujourd'hui dans notre monde actuel, c'est comment
> financer les développement puis les rendre libres.

Heureusement d'autres ont trouvé la solution.

> Mickaël
>

Bonne chance dans tes activités.

Bise à tes collègues.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@...
En cas de soucis, contactez EN ANGLAIS listmaster@...

[Vera Mickael]

>> Autant l'objectif des sources libres est très attrayant, aujourd'hui le
>> modèle économique du logiciel libre ne permet pas d'envisager tous les
>> développements avec un retour sur investissement garanti.
>
>
> Hum, explique ça à RedHat, ça va bien les faire rire !
>

1 - je pense que TOUS les développements ne sont possibles
sur le mode du libre. Je ne dis pas qu'il n'existe pas des
développements possible sur le modèle du libre. Tu ne
démontres rien avec cet exemple.

2 - Merci pour cet exemple, il va exactement dans le sens de
ce que j'avance. En comparaison du volume des softs qu'il
inclue dans sa distribution, Red-Hat n'a pratiquement rien
développé. Donc Red-Hat n'a rien investi mais il tire des
bénéfices du travail de bénévoles qui eux ne toucheront rien
du tout. Ceci dit le travail fourni par Red-Hat est tout à
fait intéressant et louable. Ma société est aussi partenaire
de Red-Hat je ne vais pas cracher dans la soupe :-)

Si Red-Hat avait dû financer le développement de l'ensemble
de sa distribution il n'aurait pas les moyens de rembourser
cet investissement.

> Il y a de très grosses sociétés qui investissent dans le développement
> de logiciels libre, et des états également. Tu devrais peut-être te
> documenter un peu sur le sujet...

Je ne dis pas le contraire de ce que tu dis. Tu ne fais pas
avancer le débat. Je n'oppose pas libre et marché des
éditeurs, je pense qu'il y a des domaines plus adaptés à
l'un ou à l'autre.

Pour ton information, notre produit est aussi financé par
les administrations. Les administrations ne financent pas
uniquement les logiciels libres. Et les administrations
développent parfois elles aussi des logiciels non libres.

D'ailleurs certaines administrations sont réticentes aux
logiciles libres et tu auras du mal à leur faire remplacer
leur Oracle/IBM/Sun par du Postgres/Jboss/Linux.

>> Je ne défends pas le monde de la concurrence et toutes ses dérives. Je
>> fais un constat et j'en déduis que le modèle économique du logiciel
>> libre ne permet pas il me semble aujourd'hui d'envisager de gros
>> investissements.
>
> Là tu est mûr pour utiliser Winchose ou MacOS. C'est Novell, RedHat, IBM
> et bien d'autres qui doivent soudain être pris d'une angoisse terrible :
> ils viennent de découvrir que leur modèle économique n'est pas viable,
> et ne permet pas de gros investissements... Zut alors. ;-)

Désolé mais je ne te suis pas, on ne se comprend pas ?

Il me semblait qu'IBM était avant tout un éditeur qui vend:
- du système
- de la base de données
- des serveurs d'application
- de nombreux autres outils ...

Même si IBM a financé de l'open source (eclipse) peut-être
avec de très mauvaises intentions, comme par exemple mettre
des bâtons dans les roues à son grand concurrent Sun
(Eclipse / Sun). IBM reste un éditeur qui vend du logiciel
non libre.

Quand IBM éditeur de logiciels se sera écroulé, on pourra
éventuellement reprendre l'exemple d'IBM pour tenter
d'affirmer que le modèle économique des éditeurs de
logiciels n'est plus viable. Aujourd'hui je pense qu'IBM se
porte relativement bien.

>> Je te rejoins sur un point, je trouve dommage que une fois qu'un
>> logiciel a été développé il ne puisse pas être librement utilisé. Idem
>> pour les disques. C'est du gâchis de ne pas pouvoir écouter une musique
>> parce que l'on n'a pas les moyens de se payer des centaines de disques.
>
> Tu as des doutes au sujet du logiciel libre, mais du piratage non...
> Vive la liberté temps qu'elle me profite exclusivement...

Encore une fois je ne te comprends pas ? Tu comprends ce que
tu as envie de comprendre. Je ne défends pas le piratage et
je ne vois pas ce qui peut te le faire penser.

J'affirme juste que peu de gens ont les moyens aujourd'hui
de se payer de centaines de disques et que du coup il sont
privés de les écouter alors que ces disques existent. Je
fais le rapprochement avec les logiciels non libres.

>> Ce que je ne vois pas aujourd'hui dans notre monde actuel, c'est comment
>> financer les développement puis les rendre libres.
>
> Heureusement d'autres ont trouvé la solution.
>

Mais ce n'est pas toi qui m'en auras convaincu.

Mickaël

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@...
En cas de soucis, contactez EN ANGLAIS listmaster@...