C'est justement l'inverse. Vu qu'avec le logiciel proprio tu ne donnes les sources a personne, tu ne risques pas de donner des sources qui ne t'appartiennent pas.
Dans un sens, tu n'as pas tout à fait tort : tu ne "donnes" pas les sources aux simples utilisateurs. Mais à tes partenaires commerciaux, contractants, stagiaires, employés qui vont passer quelques mois plus tard à la concurrence, etc...
L'histoire des Unix commerciaux en est l'exemple le plus flagrant. Des bouts de code sont passé d'une entreprise à l'autre dans tous les sens, sans contrôle exact. Et hop, un petit graphique pour les incrédules : http://www.levenez.com/unix/history.html#08(...)
Un exemple simple : A achète du code à B, pour l'intégrer dans le module M du produit P, qui va vivre plusieurs versions. Quand A revend une partie du code de (P-M) à C, il y a parfois des restes de code de B, par copier-coller du module M ou autre, etc... Bref, embrouillamini total.
Comme le dit Michell Galle un peu plus haut : A ma connaissance, les seules sociétés informatiques qui ont évité des années de procès sur un produit sont celles qui ont soigneusement isolé leur code source de toute influence extérieure (au sens : aucun accord croisé avec une autre entreprise, aucun usage de brevet sous licence, aucun "achat" de code externe, etc). c'est rare.
Or même Microsoft a racheté et intégré du code d'autres entreprises, par exemple pour le DOS (il y a plein d'exemples plus récents aussi). Est-ce que tous ces bouts de code étaient la propriété entière des vendeurs ? Pas forcément, même s'ils étaient de bonne foi et ont fait des contrôles stricts.
Le logiciel propriétaire n'a qu'un seul avantage de ce point de vue : on peut cacher plus longtemps que du code a été copié illégalement.
Pour les LL, ca peut arriver qu'un développeur indélicat copie du code de sa boîte sans autorisation (avec la même probabilité qu'il copie du code du module M dans le reste du produit P, d'ailleurs !), mais dès que l'entreprise le découvre, on peut retracer l'origine, qui est responsable, et les codeurs du LL se feront un plaisir d'éradiquer les lignes en question, pour les remplacer par du vrai code libre. Et en pratique, ca fonctionne très bien comme ca.
Quant au problème du manque de documentation, il est valable pour tout le monde. J'ai bossé sur des projets propriétaires avec peu, pas, ou de la très mauvaise, documentation. Rien de meilleur ni de pire dans l'ensemble, ca dépend de la politique de l'entreprise. La tienne a une politique dans ce sens, la mienne aussi et c'est bien. Mais il y a des projets libres qui sont très bien documentés aussi.
Et pour Mozilla, tu as pris pile le mauvais exemple : il y a quelques années, comme tu dis, le code du projet venait tout de Netscape, propriétaire à 100%. Le manque de docu et la mauvaise qualité du code sont entièrement de leur faute. Tu n'espérais quand même pas qu'en quelques mois, les développeurs libres fassent tout le (sale) boulot de réécriture et de docu par miracle ?
[^] # Re: Clarifications diverses et rapides.
Posté par Security__Watch . En réponse à la dépêche L'accord à l'amiable entre BSDi et USL (AT&T) enfin public.. Évalué à 7.
Dans un sens, tu n'as pas tout à fait tort : tu ne "donnes" pas les sources aux simples utilisateurs. Mais à tes partenaires commerciaux, contractants, stagiaires, employés qui vont passer quelques mois plus tard à la concurrence, etc...
L'histoire des Unix commerciaux en est l'exemple le plus flagrant. Des bouts de code sont passé d'une entreprise à l'autre dans tous les sens, sans contrôle exact. Et hop, un petit graphique pour les incrédules : http://www.levenez.com/unix/history.html#08(...)
Un exemple simple : A achète du code à B, pour l'intégrer dans le module M du produit P, qui va vivre plusieurs versions. Quand A revend une partie du code de (P-M) à C, il y a parfois des restes de code de B, par copier-coller du module M ou autre, etc... Bref, embrouillamini total.
Comme le dit Michell Galle un peu plus haut : A ma connaissance, les seules sociétés informatiques qui ont évité des années de procès sur un produit sont celles qui ont soigneusement isolé leur code source de toute influence extérieure (au sens : aucun accord croisé avec une autre entreprise, aucun usage de brevet sous licence, aucun "achat" de code externe, etc). c'est rare.
Or même Microsoft a racheté et intégré du code d'autres entreprises, par exemple pour le DOS (il y a plein d'exemples plus récents aussi). Est-ce que tous ces bouts de code étaient la propriété entière des vendeurs ? Pas forcément, même s'ils étaient de bonne foi et ont fait des contrôles stricts.
Le logiciel propriétaire n'a qu'un seul avantage de ce point de vue : on peut cacher plus longtemps que du code a été copié illégalement.
Pour les LL, ca peut arriver qu'un développeur indélicat copie du code de sa boîte sans autorisation (avec la même probabilité qu'il copie du code du module M dans le reste du produit P, d'ailleurs !), mais dès que l'entreprise le découvre, on peut retracer l'origine, qui est responsable, et les codeurs du LL se feront un plaisir d'éradiquer les lignes en question, pour les remplacer par du vrai code libre. Et en pratique, ca fonctionne très bien comme ca.
Quant au problème du manque de documentation, il est valable pour tout le monde. J'ai bossé sur des projets propriétaires avec peu, pas, ou de la très mauvaise, documentation. Rien de meilleur ni de pire dans l'ensemble, ca dépend de la politique de l'entreprise. La tienne a une politique dans ce sens, la mienne aussi et c'est bien. Mais il y a des projets libres qui sont très bien documentés aussi.
Et pour Mozilla, tu as pris pile le mauvais exemple : il y a quelques années, comme tu dis, le code du projet venait tout de Netscape, propriétaire à 100%. Le manque de docu et la mauvaise qualité du code sont entièrement de leur faute. Tu n'espérais quand même pas qu'en quelques mois, les développeurs libres fassent tout le (sale) boulot de réécriture et de docu par miracle ?
Le projet a eu besoin de plusieurs années pour repartir sur de bonnes bases, et arriver aux versions actuelles de Mozilla et Firefox, considérées de qualité acceptable (ou plus). Si tu veux de la docu pour comprendre et développer sur le projet, en voilà !
http://www.mozilla.org/docs/(...)
http://www.mozilla.org/hacking/(...)
http://www.mozilla.org/contribute/writing/(...)