Je decouvre le monde Python et quelques questions me taraudes :
Est-il possible d'executer un byte-code Python sur un serveur web (apache) ?
Oui.
Des tas de solutions depuis le simpliste mode CGI jusqu'à Zope.
Dans la négative, est-il possible d'executer un byte-code a partir d'un script Python ?
??? Python exécute systématiquement du byte-code ! En fait Python compile à la volée.
Enfin, existe-t-il un package similaire à DBI sous Perl ?
http://www.python.org/sigs/db-sig/
Merci d'avance pour vos réponses
A+, Laurent.
Laurent
In article <41c22763$0$10203$, Gilles Lenfant wrote:
Est-il possible d'executer un byte-code Python sur un serveur web (apache) ?
Oui.
Des tas de solutions depuis le simpliste mode CGI jusqu'à Zope.
Dans la négative, est-il possible d'executer un byte-code a partir d'un script Python ?
??? Python exécute systématiquement du byte-code ! En fait Python compile à la volée.
Merci de tes reponses.
En fait, je cherche a savoir s'il y a moyen de faire executer un .pyc ou un .pyo plutot que d'executer un .py Le but est de proteger le code (bien sur, ça n'empechera pas le Revers Engineering) et d'accelerer le temps de reponse du CGI
A+
In article <41c22763$0$10203$8fcfb975@news.wanadoo.fr>,
Gilles Lenfant <nospam@bigfoot.com> wrote:
Est-il possible d'executer un byte-code Python sur un serveur web
(apache) ?
Oui.
Des tas de solutions depuis le simpliste mode CGI jusqu'à Zope.
Dans la négative, est-il possible d'executer un byte-code a partir d'un
script Python ?
??? Python exécute systématiquement du byte-code ! En fait Python
compile à la volée.
Merci de tes reponses.
En fait, je cherche a savoir s'il y a moyen de faire executer un .pyc ou
un .pyo plutot que d'executer un .py
Le but est de proteger le code (bien sur, ça n'empechera pas le Revers
Engineering) et d'accelerer le temps de reponse du CGI
In article <41c22763$0$10203$, Gilles Lenfant wrote:
Est-il possible d'executer un byte-code Python sur un serveur web (apache) ?
Oui.
Des tas de solutions depuis le simpliste mode CGI jusqu'à Zope.
Dans la négative, est-il possible d'executer un byte-code a partir d'un script Python ?
??? Python exécute systématiquement du byte-code ! En fait Python compile à la volée.
Merci de tes reponses.
En fait, je cherche a savoir s'il y a moyen de faire executer un .pyc ou un .pyo plutot que d'executer un .py Le but est de proteger le code (bien sur, ça n'empechera pas le Revers Engineering) et d'accelerer le temps de reponse du CGI
A+
Gilles Lenfant
In article <41c22763$0$10203$, Gilles Lenfant wrote:
Est-il possible d'executer un byte-code Python sur un serveur web (apache) ?
Oui.
Des tas de solutions depuis le simpliste mode CGI jusqu'à Zope.
Dans la négative, est-il possible d'executer un byte-code a partir d'un script Python ?
??? Python exécute systématiquement du byte-code ! En fait Python compile à la volée.
Merci de tes reponses.
En fait, je cherche a savoir s'il y a moyen de faire executer un .pyc ou un .pyo plutot que d'executer un .py Le but est de proteger le code (bien sur, ça n'empechera pas le Revers Engineering) et d'accelerer le temps de reponse du CGI
A+
Il y a un moyen d'exécuter directement les .pyc ou .pyo, c'est ce que fait py2exe. En cherchant sur google... Cependant, si tu espères une amélioration spectaculaire des perfs, tu te fourres le doigt dans l'oeil :)
Autrement, pour protéger le code source, les directives de configuration Apache pour CGI permettent de déclarer certains types comme "exécutables" coté serveur et empêcher leur téléchargement sur le poste client.
http://httpd.apache.org/docs/howto/cgi.html
-- Gilles
In article <41c22763$0$10203$8fcfb975@news.wanadoo.fr>,
Gilles Lenfant <nospam@bigfoot.com> wrote:
Est-il possible d'executer un byte-code Python sur un serveur web
(apache) ?
Oui.
Des tas de solutions depuis le simpliste mode CGI jusqu'à Zope.
Dans la négative, est-il possible d'executer un byte-code a partir d'un
script Python ?
??? Python exécute systématiquement du byte-code ! En fait Python
compile à la volée.
Merci de tes reponses.
En fait, je cherche a savoir s'il y a moyen de faire executer un .pyc ou
un .pyo plutot que d'executer un .py
Le but est de proteger le code (bien sur, ça n'empechera pas le Revers
Engineering) et d'accelerer le temps de reponse du CGI
A+
Il y a un moyen d'exécuter directement les .pyc ou .pyo, c'est ce que
fait py2exe. En cherchant sur google... Cependant, si tu espères une
amélioration spectaculaire des perfs, tu te fourres le doigt dans l'oeil :)
Autrement, pour protéger le code source, les directives de configuration
Apache pour CGI permettent de déclarer certains types comme
"exécutables" coté serveur et empêcher leur téléchargement sur le poste
client.
In article <41c22763$0$10203$, Gilles Lenfant wrote:
Est-il possible d'executer un byte-code Python sur un serveur web (apache) ?
Oui.
Des tas de solutions depuis le simpliste mode CGI jusqu'à Zope.
Dans la négative, est-il possible d'executer un byte-code a partir d'un script Python ?
??? Python exécute systématiquement du byte-code ! En fait Python compile à la volée.
Merci de tes reponses.
En fait, je cherche a savoir s'il y a moyen de faire executer un .pyc ou un .pyo plutot que d'executer un .py Le but est de proteger le code (bien sur, ça n'empechera pas le Revers Engineering) et d'accelerer le temps de reponse du CGI
A+
Il y a un moyen d'exécuter directement les .pyc ou .pyo, c'est ce que fait py2exe. En cherchant sur google... Cependant, si tu espères une amélioration spectaculaire des perfs, tu te fourres le doigt dans l'oeil :)
Autrement, pour protéger le code source, les directives de configuration Apache pour CGI permettent de déclarer certains types comme "exécutables" coté serveur et empêcher leur téléchargement sur le poste client.
http://httpd.apache.org/docs/howto/cgi.html
-- Gilles
Rakotomandimby (R12y) Mihamina
( Fri, 17 Dec 2004 20:43:34 +0100 ) Laurent :
Je ne sais pas vers ou placer le follow-up alors je reste ici
Le but est de proteger le code ...
Quelles sont, de nos jours, les motivations possible qui justifient la volonté de "proteger un code source" ?
On voit bien de nos jours la qualité des programmes open source, ... -- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
( Fri, 17 Dec 2004 20:43:34 +0100 ) Laurent :
Je ne sais pas vers ou placer le follow-up alors je reste ici
Le but est de proteger le code ...
Quelles sont, de nos jours, les motivations possible qui justifient la
volonté de "proteger un code source" ?
On voit bien de nos jours la qualité des programmes open source, ...
--
ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance
Unofficial FAQ fcolc - http://faq.fcolc.eu.org/
Linux User Group sur Orléans et alentours.
Tél: + 33 2 38 76 43 65 (France)
Je ne sais pas vers ou placer le follow-up alors je reste ici
Le but est de proteger le code ...
Quelles sont, de nos jours, les motivations possible qui justifient la volonté de "proteger un code source" ?
On voit bien de nos jours la qualité des programmes open source, ... -- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
Laurent
In article <41c3e1af$0$10241$, Gilles Lenfant wrote:
En fait, je cherche a savoir s'il y a moyen de faire executer un .pyc ou un .pyo plutot que d'executer un .py Le but est de proteger le code (bien sur, ça n'empechera pas le Revers Engineering) et d'accelerer le temps de reponse du CGI
A+
Il y a un moyen d'exécuter directement les .pyc ou .pyo, c'est ce que fait py2exe. En cherchant sur google... Cependant, si tu espères une amélioration spectaculaire des perfs, tu te fourres le doigt dans l'oeil :)
py2exe ne fonctionne que pour un seul OS (window$). Donc, cette solution n'est pas recevable pour moi. Arfff... Ca soulagera au moins un peu l'interpreteur, du moins j'espere.
Autrement, pour protéger le code source, les directives de configuration Apache pour CGI permettent de déclarer certains types comme "exécutables" coté serveur et empêcher leur téléchargement sur le poste client.
http://httpd.apache.org/docs/howto/cgi.html On ne parle pas de la meme chose. Mes CGIs Python s'executent bien et le
code ne peut etre visible cote client web car il est correctement interprete. Je suis habitue à l'utilisation de CGI ;)
Si le script n'est pas un executable, il sera affiche comme du texte classique. Les CGI ne peuvent etre que des executables, que ce soient des scripts ou bien des binaires. Pour un script CGI (suivant l'OS), c'est la première ligne du script qui va indiquer quel interpreteur utiliser, ou alors son extension. Or, les bytecode ne contiennent pas cette ligne et sous Linux ca pose un probleme. Sous apache il y a donc deux solutions (a ma connaissance) pour faire executer Python :
- Utilisation du mod_python : Probleme, on se trouve dans une configuration type PHP, JSP, ASP ; script embarqué dans une page HTML avec interpretation cote serveur. Donc, le code est lisible. Sauf si un Python peut charger un .pyc ou un .pyo et l'executer. Dans ce cas, la page peyt faire office de wrapper.
- Le CGI : idem, le code est en claire. Ici, meme chose : faire un wrapper.
Quand à Zope, si je dis pas de betise, je dirais qu'il est à Python ce que Tomcat est à Java.
Le wrapper serait alors un Controler. Bien evidement, je ne sais pas non plus si Python sait faire de l'import de .pyc ou .pyo, ce qui resoudrait mon probleme car dans ce cas, mon controler pourrait etre un CGI Python ou un Script via mod_python (qui du coup serait "similaire" un à JSP où les .class sont du bytecode).
Je cherche a empecher l'edition du code et a rendre possible un deploiement de logiciel en .pyc ou .pyo au niveau web. Bref ! Est-ce que sur ce point Python est plus ouvert que Java sans etre oblige de sortir la grosse artillerie.
A+, et merci.
In article <41c3e1af$0$10241$8fcfb975@news.wanadoo.fr>,
Gilles Lenfant <nospam@bigfoot.com> wrote:
En fait, je cherche a savoir s'il y a moyen de faire executer un .pyc ou
un .pyo plutot que d'executer un .py
Le but est de proteger le code (bien sur, ça n'empechera pas le Revers
Engineering) et d'accelerer le temps de reponse du CGI
A+
Il y a un moyen d'exécuter directement les .pyc ou .pyo, c'est ce que
fait py2exe. En cherchant sur google... Cependant, si tu espères une
amélioration spectaculaire des perfs, tu te fourres le doigt dans l'oeil :)
py2exe ne fonctionne que pour un seul OS (window$). Donc, cette solution
n'est pas recevable pour moi.
Arfff... Ca soulagera au moins un peu l'interpreteur, du moins j'espere.
Autrement, pour protéger le code source, les directives de configuration
Apache pour CGI permettent de déclarer certains types comme
"exécutables" coté serveur et empêcher leur téléchargement sur le poste
client.
http://httpd.apache.org/docs/howto/cgi.html
On ne parle pas de la meme chose. Mes CGIs Python s'executent bien et le
code ne peut etre visible cote client web car il est correctement
interprete. Je suis habitue à l'utilisation de CGI ;)
Si le script n'est pas un executable, il sera affiche comme du texte
classique.
Les CGI ne peuvent etre que des executables, que ce soient des scripts
ou bien des binaires. Pour un script CGI (suivant l'OS), c'est la
première ligne du script qui va indiquer quel interpreteur utiliser, ou
alors son extension. Or, les bytecode ne contiennent pas cette ligne et
sous Linux ca pose un probleme.
Sous apache il y a donc deux solutions (a ma connaissance) pour faire
executer Python :
- Utilisation du mod_python : Probleme, on se trouve dans une
configuration type PHP, JSP, ASP ; script embarqué dans une page HTML
avec interpretation cote serveur. Donc, le code est lisible. Sauf si un
Python peut charger un .pyc ou un .pyo et l'executer. Dans ce cas, la
page peyt faire office de wrapper.
- Le CGI : idem, le code est en claire. Ici, meme chose : faire un
wrapper.
Quand à Zope, si je dis pas de betise, je dirais qu'il est à Python ce
que Tomcat est à Java.
Le wrapper serait alors un Controler. Bien evidement, je ne sais pas non
plus si Python sait faire de l'import de .pyc ou .pyo, ce qui resoudrait
mon probleme car dans ce cas, mon controler pourrait etre un CGI Python
ou un Script via mod_python (qui du coup serait "similaire" un à JSP où
les .class sont du bytecode).
Je cherche a empecher l'edition du code et a rendre possible un
deploiement de logiciel en .pyc ou .pyo au niveau web. Bref ! Est-ce que
sur ce point Python est plus ouvert que Java sans etre oblige de sortir
la grosse artillerie.
In article <41c3e1af$0$10241$, Gilles Lenfant wrote:
En fait, je cherche a savoir s'il y a moyen de faire executer un .pyc ou un .pyo plutot que d'executer un .py Le but est de proteger le code (bien sur, ça n'empechera pas le Revers Engineering) et d'accelerer le temps de reponse du CGI
A+
Il y a un moyen d'exécuter directement les .pyc ou .pyo, c'est ce que fait py2exe. En cherchant sur google... Cependant, si tu espères une amélioration spectaculaire des perfs, tu te fourres le doigt dans l'oeil :)
py2exe ne fonctionne que pour un seul OS (window$). Donc, cette solution n'est pas recevable pour moi. Arfff... Ca soulagera au moins un peu l'interpreteur, du moins j'espere.
Autrement, pour protéger le code source, les directives de configuration Apache pour CGI permettent de déclarer certains types comme "exécutables" coté serveur et empêcher leur téléchargement sur le poste client.
http://httpd.apache.org/docs/howto/cgi.html On ne parle pas de la meme chose. Mes CGIs Python s'executent bien et le
code ne peut etre visible cote client web car il est correctement interprete. Je suis habitue à l'utilisation de CGI ;)
Si le script n'est pas un executable, il sera affiche comme du texte classique. Les CGI ne peuvent etre que des executables, que ce soient des scripts ou bien des binaires. Pour un script CGI (suivant l'OS), c'est la première ligne du script qui va indiquer quel interpreteur utiliser, ou alors son extension. Or, les bytecode ne contiennent pas cette ligne et sous Linux ca pose un probleme. Sous apache il y a donc deux solutions (a ma connaissance) pour faire executer Python :
- Utilisation du mod_python : Probleme, on se trouve dans une configuration type PHP, JSP, ASP ; script embarqué dans une page HTML avec interpretation cote serveur. Donc, le code est lisible. Sauf si un Python peut charger un .pyc ou un .pyo et l'executer. Dans ce cas, la page peyt faire office de wrapper.
- Le CGI : idem, le code est en claire. Ici, meme chose : faire un wrapper.
Quand à Zope, si je dis pas de betise, je dirais qu'il est à Python ce que Tomcat est à Java.
Le wrapper serait alors un Controler. Bien evidement, je ne sais pas non plus si Python sait faire de l'import de .pyc ou .pyo, ce qui resoudrait mon probleme car dans ce cas, mon controler pourrait etre un CGI Python ou un Script via mod_python (qui du coup serait "similaire" un à JSP où les .class sont du bytecode).
Je cherche a empecher l'edition du code et a rendre possible un deploiement de logiciel en .pyc ou .pyo au niveau web. Bref ! Est-ce que sur ce point Python est plus ouvert que Java sans etre oblige de sortir la grosse artillerie.
A+, et merci.
Wilk
Laurent writes:
Je cherche a empecher l'edition du code et a rendre possible un deploiement de logiciel en .pyc ou .pyo au niveau web. Bref ! Est-ce que sur ce point Python est plus ouvert que Java sans etre oblige de sortir la grosse artillerie.
Python sait lancer directement des pyc ou pyo, et même des modules (option -m du 2.4). Ton problème ne vient pas de python mais d'unix/apache, il faut que tu regarde de ce côté, y a plusieurs solutions... binfmts du côté linux par ex
Au pire, si tu n'y arrive pas, tu peux très bien lancer un cgi classique qui fasse un import de ton script (qui pourrait être dans un zip en prime).
-- William - http://flibuste.net
Laurent <statikit@free.fr> writes:
Je cherche a empecher l'edition du code et a rendre possible un
deploiement de logiciel en .pyc ou .pyo au niveau web. Bref ! Est-ce que
sur ce point Python est plus ouvert que Java sans etre oblige de sortir
la grosse artillerie.
Python sait lancer directement des pyc ou pyo, et même des modules
(option -m du 2.4). Ton problème ne vient pas de python mais
d'unix/apache, il faut que tu regarde de ce côté, y a plusieurs
solutions...
binfmts du côté linux par ex
Au pire, si tu n'y arrive pas, tu peux très bien lancer un cgi classique
qui fasse un import de ton script (qui pourrait être dans un zip en
prime).
Je cherche a empecher l'edition du code et a rendre possible un deploiement de logiciel en .pyc ou .pyo au niveau web. Bref ! Est-ce que sur ce point Python est plus ouvert que Java sans etre oblige de sortir la grosse artillerie.
Python sait lancer directement des pyc ou pyo, et même des modules (option -m du 2.4). Ton problème ne vient pas de python mais d'unix/apache, il faut que tu regarde de ce côté, y a plusieurs solutions... binfmts du côté linux par ex
Au pire, si tu n'y arrive pas, tu peux très bien lancer un cgi classique qui fasse un import de ton script (qui pourrait être dans un zip en prime).
-- William - http://flibuste.net
Laurent
In article , "Rakotomandimby (R12y) Mihamina" wrote:
( Fri, 17 Dec 2004 20:43:34 +0100 ) Laurent :
Je ne sais pas vers ou placer le follow-up alors je reste ici
Le but est de proteger le code ...
Quelles sont, de nos jours, les motivations possible qui justifient la volonté de "proteger un code source" ?
On voit bien de nos jours la qualité des programmes open source, ...
Tout simplement, la vente d'un framework soit avec achat des sources, soit avec contrat de maintenance.
Meme avec l'open source, ce type de business existe encore. Il y a nombre d'entreprise qui ne souhaites pas investir sur de l'open source ou sur un logiciel qui pourrait etre maintenu par leur equipe informatique.
La protection des sources sert surtout à ne pas encourager le developpement specifique et donc a preserver l'integriter du framework pour ne pas rendre plus complexe la maintenance.
A+
In article <pan.2004.12.18.09.53.13.192325@mail.rktmb.org>,
"Rakotomandimby (R12y) Mihamina" <mihamina@mail.rktmb.org> wrote:
( Fri, 17 Dec 2004 20:43:34 +0100 ) Laurent :
Je ne sais pas vers ou placer le follow-up alors je reste ici
Le but est de proteger le code ...
Quelles sont, de nos jours, les motivations possible qui justifient la
volonté de "proteger un code source" ?
On voit bien de nos jours la qualité des programmes open source, ...
Tout simplement, la vente d'un framework soit avec achat des sources,
soit avec contrat de maintenance.
Meme avec l'open source, ce type de business existe encore. Il y a
nombre d'entreprise qui ne souhaites pas investir sur de l'open source
ou sur un logiciel qui pourrait etre maintenu par leur equipe
informatique.
La protection des sources sert surtout à ne pas encourager le
developpement specifique et donc a preserver l'integriter du framework
pour ne pas rendre plus complexe la maintenance.
In article , "Rakotomandimby (R12y) Mihamina" wrote:
( Fri, 17 Dec 2004 20:43:34 +0100 ) Laurent :
Je ne sais pas vers ou placer le follow-up alors je reste ici
Le but est de proteger le code ...
Quelles sont, de nos jours, les motivations possible qui justifient la volonté de "proteger un code source" ?
On voit bien de nos jours la qualité des programmes open source, ...
Tout simplement, la vente d'un framework soit avec achat des sources, soit avec contrat de maintenance.
Meme avec l'open source, ce type de business existe encore. Il y a nombre d'entreprise qui ne souhaites pas investir sur de l'open source ou sur un logiciel qui pourrait etre maintenu par leur equipe informatique.
La protection des sources sert surtout à ne pas encourager le developpement specifique et donc a preserver l'integriter du framework pour ne pas rendre plus complexe la maintenance.
A+
Laurent
In article , Wilk wrote:
Laurent writes:
Je cherche a empecher l'edition du code et a rendre possible un deploiement de logiciel en .pyc ou .pyo au niveau web. Bref ! Est-ce que sur ce point Python est plus ouvert que Java sans etre oblige de sortir la grosse artillerie.
Python sait lancer directement des pyc ou pyo, et même des modules (option -m du 2.4). Ton problème ne vient pas de python mais d'unix/apache, il faut que tu regarde de ce côté, y a plusieurs solutions... binfmts du côté linux par ex
Je vais aller voir de ce cote. Car c'est en effet la relation bytecode/lanceur qui est problematiaue. Si toute fois quelqu'un avait une parade sous apache...
Au pire, si tu n'y arrive pas, tu peux très bien lancer un cgi classique qui fasse un import de ton script (qui pourrait être dans un zip en prime).
Un import de script ne me pose pas de contrainte, mais je prefererais une option plus "elegante" un peu a la manière du "loadsclass" de java.
Merci.
In article <874qijhnfh.fsf@chat.blakie.riol>,
Wilk <wilk-ml@flibuste.net> wrote:
Laurent <statikit@free.fr> writes:
Je cherche a empecher l'edition du code et a rendre possible un
deploiement de logiciel en .pyc ou .pyo au niveau web. Bref ! Est-ce que
sur ce point Python est plus ouvert que Java sans etre oblige de sortir
la grosse artillerie.
Python sait lancer directement des pyc ou pyo, et même des modules
(option -m du 2.4). Ton problème ne vient pas de python mais
d'unix/apache, il faut que tu regarde de ce côté, y a plusieurs
solutions...
binfmts du côté linux par ex
Je vais aller voir de ce cote. Car c'est en effet la relation
bytecode/lanceur qui est problematiaue. Si toute fois quelqu'un avait
une parade sous apache...
Au pire, si tu n'y arrive pas, tu peux très bien lancer un cgi classique
qui fasse un import de ton script (qui pourrait être dans un zip en
prime).
Un import de script ne me pose pas de contrainte, mais je prefererais
une option plus "elegante" un peu a la manière du "loadsclass" de java.
Je cherche a empecher l'edition du code et a rendre possible un deploiement de logiciel en .pyc ou .pyo au niveau web. Bref ! Est-ce que sur ce point Python est plus ouvert que Java sans etre oblige de sortir la grosse artillerie.
Python sait lancer directement des pyc ou pyo, et même des modules (option -m du 2.4). Ton problème ne vient pas de python mais d'unix/apache, il faut que tu regarde de ce côté, y a plusieurs solutions... binfmts du côté linux par ex
Je vais aller voir de ce cote. Car c'est en effet la relation bytecode/lanceur qui est problematiaue. Si toute fois quelqu'un avait une parade sous apache...
Au pire, si tu n'y arrive pas, tu peux très bien lancer un cgi classique qui fasse un import de ton script (qui pourrait être dans un zip en prime).
Un import de script ne me pose pas de contrainte, mais je prefererais une option plus "elegante" un peu a la manière du "loadsclass" de java.
Merci.
Wilk
Laurent writes:
In article , "Rakotomandimby (R12y) Mihamina" wrote:
( Fri, 17 Dec 2004 20:43:34 +0100 ) Laurent :
Je ne sais pas vers ou placer le follow-up alors je reste ici
Le but est de proteger le code ...
Quelles sont, de nos jours, les motivations possible qui justifient la volonté de "proteger un code source" ?
On voit bien de nos jours la qualité des programmes open source, ...
Tout simplement, la vente d'un framework soit avec achat des sources, soit avec contrat de maintenance.
Meme avec l'open source, ce type de business existe encore. Il y a nombre d'entreprise qui ne souhaites pas investir sur de l'open source ou sur un logiciel qui pourrait etre maintenu par leur equipe informatique.
Pourquoi utiliser des logiciels open source dans ce cas ? C'est assez contradictoire...
La protection des sources sert surtout à ne pas encourager le developpement specifique et donc a preserver l'integriter du framework pour ne pas rendre plus complexe la maintenance.
Tu pourrais détailler ton raisonnement ?
-- William - http://flibuste.net
Laurent <statikit@free.fr> writes:
In article <pan.2004.12.18.09.53.13.192325@mail.rktmb.org>,
"Rakotomandimby (R12y) Mihamina" <mihamina@mail.rktmb.org> wrote:
( Fri, 17 Dec 2004 20:43:34 +0100 ) Laurent :
Je ne sais pas vers ou placer le follow-up alors je reste ici
Le but est de proteger le code ...
Quelles sont, de nos jours, les motivations possible qui justifient la
volonté de "proteger un code source" ?
On voit bien de nos jours la qualité des programmes open source, ...
Tout simplement, la vente d'un framework soit avec achat des sources,
soit avec contrat de maintenance.
Meme avec l'open source, ce type de business existe encore. Il y a
nombre d'entreprise qui ne souhaites pas investir sur de l'open source
ou sur un logiciel qui pourrait etre maintenu par leur equipe
informatique.
Pourquoi utiliser des logiciels open source dans ce cas ? C'est assez
contradictoire...
La protection des sources sert surtout à ne pas encourager le
developpement specifique et donc a preserver l'integriter du framework
pour ne pas rendre plus complexe la maintenance.
In article , "Rakotomandimby (R12y) Mihamina" wrote:
( Fri, 17 Dec 2004 20:43:34 +0100 ) Laurent :
Je ne sais pas vers ou placer le follow-up alors je reste ici
Le but est de proteger le code ...
Quelles sont, de nos jours, les motivations possible qui justifient la volonté de "proteger un code source" ?
On voit bien de nos jours la qualité des programmes open source, ...
Tout simplement, la vente d'un framework soit avec achat des sources, soit avec contrat de maintenance.
Meme avec l'open source, ce type de business existe encore. Il y a nombre d'entreprise qui ne souhaites pas investir sur de l'open source ou sur un logiciel qui pourrait etre maintenu par leur equipe informatique.
Pourquoi utiliser des logiciels open source dans ce cas ? C'est assez contradictoire...
La protection des sources sert surtout à ne pas encourager le developpement specifique et donc a preserver l'integriter du framework pour ne pas rendre plus complexe la maintenance.
Tu pourrais détailler ton raisonnement ?
-- William - http://flibuste.net
Laurent
In article , Wilk wrote:
Pourquoi utiliser des logiciels open source dans ce cas ? C'est assez contradictoire...
Pour ne pas s'appuyer sur une couche logiciel propietaire en evitant ainsi un sur-cout du produit.
Les projets qui s'appuient sur de l'open source ne sont pas tous obligatoirement open source.
La protection des sources sert surtout à ne pas encourager le developpement specifique et donc a preserver l'integriter du framework pour ne pas rendre plus complexe la maintenance.
Tu pourrais détailler ton raisonnement ?
C'est simple : Une entreprise qui achete les sources est libre de les modifier à sa guise. Si elle n'achete pas les sources, elle n'a pas le droit de les modifier. Cependant, avec un script "en clair" la tentation peut etre grande de vouloir faire la modification soit meme, car suivant les clauses contractuelles, la maintenance peut aussi avoir un cout. Et bien sur, cette modification ne sera pas repertoriee. Cerise sur le gateau, en cas de livraison d'une nouvelle version, ces modifications risquent fort d'etre ecrassees et nous voila face a une regression sans que personne ne sache pourquoi. Ca peut sembler delirant, mais c'est encore pire quand ca arrive. Et devine qui est en tort dans ce cas la ?
A+
In article <87652zzfg4.fsf@chat.blakie.riol>,
Wilk <wilk-ml@flibuste.net> wrote:
Pourquoi utiliser des logiciels open source dans ce cas ? C'est assez
contradictoire...
Pour ne pas s'appuyer sur une couche logiciel propietaire en evitant
ainsi un sur-cout du produit.
Les projets qui s'appuient sur de l'open source ne sont pas tous
obligatoirement open source.
La protection des sources sert surtout à ne pas encourager le
developpement specifique et donc a preserver l'integriter du framework
pour ne pas rendre plus complexe la maintenance.
Tu pourrais détailler ton raisonnement ?
C'est simple : Une entreprise qui achete les sources est libre de les
modifier à sa guise. Si elle n'achete pas les sources, elle n'a pas le
droit de les modifier. Cependant, avec un script "en clair" la tentation
peut etre grande de vouloir faire la modification soit meme, car suivant
les clauses contractuelles, la maintenance peut aussi avoir un cout. Et
bien sur, cette modification ne sera pas repertoriee. Cerise sur le
gateau, en cas de livraison d'une nouvelle version, ces modifications
risquent fort d'etre ecrassees et nous voila face a une regression sans
que personne ne sache pourquoi. Ca peut sembler delirant, mais c'est
encore pire quand ca arrive. Et devine qui est en tort dans ce cas la ?
Pourquoi utiliser des logiciels open source dans ce cas ? C'est assez contradictoire...
Pour ne pas s'appuyer sur une couche logiciel propietaire en evitant ainsi un sur-cout du produit.
Les projets qui s'appuient sur de l'open source ne sont pas tous obligatoirement open source.
La protection des sources sert surtout à ne pas encourager le developpement specifique et donc a preserver l'integriter du framework pour ne pas rendre plus complexe la maintenance.
Tu pourrais détailler ton raisonnement ?
C'est simple : Une entreprise qui achete les sources est libre de les modifier à sa guise. Si elle n'achete pas les sources, elle n'a pas le droit de les modifier. Cependant, avec un script "en clair" la tentation peut etre grande de vouloir faire la modification soit meme, car suivant les clauses contractuelles, la maintenance peut aussi avoir un cout. Et bien sur, cette modification ne sera pas repertoriee. Cerise sur le gateau, en cas de livraison d'une nouvelle version, ces modifications risquent fort d'etre ecrassees et nous voila face a une regression sans que personne ne sache pourquoi. Ca peut sembler delirant, mais c'est encore pire quand ca arrive. Et devine qui est en tort dans ce cas la ?
