Protéger un script

Le
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@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Basile STARYNKEVITCH
Le #20435381
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: +33 6 8501 2359
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
En cas de soucis, contactez EN ANGLAIS
Kevin Hinault
Le #20439711
Le 27 octobre 2009 17:33, 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 sou rce 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 englo be
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'utilisat eur. 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 malin s
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
En cas de soucis, contactez EN ANGLAIS
Merwin
Le #20439701
Kevin Hinault a écrit :
Le 27 octobre 2009 17:33, 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.





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
En cas de soucis, contactez EN ANGLAIS
Basile STARYNKEVITCH
Le #20439791
Kevin Hinault wrote:
Le 27 octobre 2009 17:33, 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.







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: +33 6 8501 2359
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
En cas de soucis, contactez EN ANGLAIS
Vera Mickael
Le #20439931
> 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
En cas de soucis, contactez EN ANGLAIS
Kevin Hinault
Le #20440791
Mode vendredi ON.

Le 28 octobre 2009 12:18, Vera Mickael

De manière plus générale, le fantasme de la sécurité par l'obs curité 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_ob scurity



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

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 pa s
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 l e
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 solut ion
é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 peu t apporter satisfaction. Je ne juge pas par contre de la qualité de la so lution 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 contr e un prestataire qui pourrait venir intervenir sur la machine ne nécessit e pas un degré de protection élevé contrairement à un système mil itaire qui est susceptible de se faire attaquer par une centaine de spéci alistes de la CIA.

Le prestataire sera vite découragé si il n'arrive pas à récupér er 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 da ns
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
En cas de soucis, contactez EN ANGLAIS
Merwin
Le #20440801
Kevin Hinault a écrit :
Mode vendredi ON.

Le 28 octobre 2009 12:18, 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.





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
En cas de soucis, contactez EN ANGLAIS
fra-duf-no-spam
Le #20441301
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 gr andes
lignes de ce que ça fait.

L'objet de la question initiale est de protéger la source d'un trava il
facturé à un client. Il est légitime qu'un client ne souha ite 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 libr e,
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 poin tu, 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 fais ant é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
En cas de soucis, contactez EN ANGLAIS
Jean-Yves F. Barbier
Le #20441291
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
En cas de soucis, contactez EN ANGLAIS
Jean-Yves F. Barbier
Le #20441261
Kevin Hinault a écrit :
Mode vendredi ON.



et même Vendredi matin


Le 28 octobre 2009 12:18, 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.





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
En cas de soucis, contactez EN ANGLAIS
Publicité
Poster une réponse
Anonyme