Imaginons que je mette en place un service web, super sympa, révolutionnaire et tout. Dans ma grande mansuétude, je veux en faire bénéficier tout le monde gratuitement (via soap, rest, http, tout quoi).
Mais comme je suis libriste, je voudrais que toute les implémentations de clients, consommatrices de ce service, soient "open source" , donc empêcher la réalisation d'un programme proprio se servant de mes données...
Suffirait il, pour réaliser mon objectif, que je publie un fichier source nommé "chiffre_magique" sous licence GPL v3 contenant un chiffre magique (genre 123456789) nécessaire pour se connecter au service ?
En effet, pour implémenter un client, il faudrait forcément connaitre ce chiffre magique, donc utiliser des données présentes dans le fichier "chiffre_magique" , et la viralité de la GPL v3 ferait que le reste du code doit être releasé en gpl v3...
Qu'en pensez-vous? Est ce que ça "marche" ? Est ce que ça vous inspire..?
Forum général.général Un peu capillotracté mais...
26
nov.
2009
# comme ça, non
Posté par gaaaaaAab . Évalué à 2.
Jette un oeil sur l'AGPL (Affero GPL), ça pourrait p-e te convenir (mais j'ai l'impression que ça couvre un autre problème en fait).
Concernant l'accès au service, techniquement, je ne vois pas comment tu peux forcer l'utilisation d'une implémentation GPL (ou autre licence libre) d'un client.
A priori, tu publieras un protocole que les clients devront implémenter pour interagir avec le serveur.
Ensuite, vu que l'intégralité des échanges client/serveur sera défini dans ce protocole, il sera techniquement rigoureusement impossible de distinguer un client libre d'un client proprio à partir du moment ou ils implémentent tous les deux correctement le protocole.
Tu peux éventuellement favoriser (mais pas garantir) l'émergence de clients libres en proposant des API en affero GPL.
Sinon, dans ton commentaire, quand tu parles de logiciels proprios, on pense tout de suite à la méchante boite parasite qui se goinfre sur le dos des gentils développeurs de LL (ou alors c'est juste moi, possible que je souffre d'un biais sémantique :)
mais si quelqu'un chez lui implémente ce protocole dans un soft qu'il utilise chez lui et qu'il ne redistribue à personne, c'est aussi une implémentation propriétaire.
Pour finir, est-ce vraiment bloquer l'utilisation de logiciels proprios que tu veux ? ou simplement fermer l'utilisation à tout logiciel à visée commerciale ?
[^] # Re: comme ça, non
Posté par Grunt . Évalué à 6.
Et c'est aussi une implémentation libre, de façon triviale: tous les utilisateurs (y'en a qu'un) de cette implémentation disposent des quatre libertés. Ce n'est lorsque l'implémentation sort de chez lui que la question libre/propriétaire se pose.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: comme ça, non
Posté par gaaaaaAab . Évalué à 2.
Effectivement, tant qu'il n'y a pas de redistribution, y a pas de question.
[^] # Re: comme ça, non
Posté par fredoche . Évalué à 1.
Si on ne peut pas protéger un nombre, on peut visiblement protéger une chaîne de caractères (du code source qui contient des printf, des new, des instructions)... Et ce code ne peut être copié/collé dans un soft sous une licence "privative" (j'aime pas ce terme) sans violer la gplv3.
Par conséquent, j'imaginais qu'une donnée (au sens large), nécessaire pour se connecter au service, licenciée en gplv3, s'apparentait à du code source et donc ne pouvait être "fermée".
Pour finir, est-ce vraiment bloquer l'utilisation de logiciels proprios que tu veux ? ou simplement fermer l'utilisation à tout logiciel à visée commerciale ?
Pour le moment je ne veux rien du tout, c'est simplement un égarement de pensée, mais le débat m'intéresse, et ça peut peut être aboutir à une conclusion sur un effet de bord sympa de la gplV3.
[^] # Re: comme ça, non
Posté par gaaaaaAab . Évalué à 2.
Par conséquent, j'imaginais qu'une donnée (au sens large), nécessaire pour se connecter au service, licenciée en gplv3, s'apparentait à du code source et donc ne pouvait être "fermée".
sauf qu'en droit, y a pas beaucoup de place pour l'imagination (ni pour l'imprécision d'ailleurs).
"Une donnée s'apparentant à du code source", j'avoue avoir du mal à cerner ce que ça veut dire :)
Le code source est protégé, pas ce qu'il fait (il n'y a pas de brevets logiciels en Europe). Du coup, réimplémenter un algorithme utile à une interaction avec du soft GPL n'en fait pas (à mon avis) une violation de la GPL.
Pour finir, en dehors du fait qu'on peut s'interroger sur ce que signifie le mot libre dans un tel contexte, à part des conditions d'utilisations strictes, l'enregistrement de tous les utilisateurs, des mécanisme techniques (pas très fiables) pour détecter les violations des conditions et des mécanismes de fermeture de compte, je ne vois pas trop.
Mais là, ça sort du cadre de la technique.
[^] # Re: comme ça, non
Posté par Grunt . Évalué à 3.
C'est ce qui fait qu'il est légal d'utiliser un client libre obtenu par rétro-ingénieurie pour se connecter à (par exemple) MSN ou ICQ.
On peut parfaitement imaginer que, si un service demande une "clef" qui serait sous licence libre, un éditeur de logiciels propriétaire invoque ce droit à l'intéropérabilité en proposant une implémentation propriétaire qui contienne la clef sous licence GPL, par exemple dans un fichier à part.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: comme ça, non
Posté par GTof . Évalué à 2.
Hum ... interressant comme question ... Tu pourrais demander au client d'envoyer des captures d'écran. Et si c'est pas un client reconnu comme libre alors tu hadopises. Autre solution, tu pourrais envoyer au client un fichier source contenant une fonction d'authentification. Le client devrait se recompiler avec ce fichier pour pouvoir se connecter. Si le fichier source est sous GPL, ca force même le client à l'être aussi. Hoho j'en ai une autre: tu demandes à l'utilisateur d'uploader le clent sur ton serveur, tu verifies que le client est bien libre et tu permet à l'utilisateur d'utiliser le client via ssh -X ou vnc depuis ton serveur. J'en ai bien une dernière mais elle ne protège pas de l'obfuscation de code: tu crés un langage spécialisé pour ton serveur. A chaque fois qu'un utilisateur veut se connecter, tu envoies un interprete différent pour ce langage. L'utilisateur devra faire tourner le client avec l'interprete pour se connecter. Malheureusement rien n'empêche d'écrire un client dans un autre langage puis de le compiler pour ton langage sans donner les sources originelles.
Finalement c'était pas si difficile que ca :D
[^] # virus
Posté par Octabrain . Évalué à 2.
[^] # Re: virus
Posté par GTof . Évalué à -1.
[^] # Re: comme ça, non
Posté par gaaaaaAab . Évalué à 2.
je peux t'envoyer des captures d'écran d'un logiciel ... et en utiliser un autre.
Et ta fonction d'authentification, quelle est son rôle ? S'il s'agit simplement d'encapsuler la valeur magique dans une fonction, y a encore moins de doute qu'avec un simple chiffre magique. Il suffit de réimplémenter sa propre fonction d'authentification, d'utiliser la valeur magique récupérée du fichier téléchargé, et cest plié.
(sachant qu'il n'y a déjà pas de doute sur un simple nombre, cf DeCSS)
S'il faut que j'upload mon client SOAP pour l'appeler ensuite en SSH, reconnais que ça perd une partie de son intérêt.
Et puis, comment vérifies-tu que le programme uploadé en SSH est bien libre ?
Si le fichier source est sous GPL, ca force même le client à l'être aussi.
Juridiquement oui, techniquement, c'est beaucoup moins certain ;)
Finalement c'était pas si difficile que ca :D
Ah, voilà une conclusion qui va faire plaisir à nos amis industriels du disque, du cinéma et des jeux vidéos, parce que pour l'instant, ils y arrivent pas =)
(ok, ils veulent le faire dans l'autre sens, mais c'est une problématique symétrique de ce point de vue là)
[^] # Re: comme ça, non
Posté par GTof . Évalué à 1.
je peux t'envoyer des captures d'écran d'un logiciel ... et en utiliser un autre.
Alors disons que pour se connecter, l'utilsateur doit avoir un compte. Qu'on autorise qu'une seule session par compte. Le client doit envoyer une capture d'écran toutes les secondes au serveur qui les envoie à RMS pour examen et validation. Si la capture n'est pas du gout de notre vénéré gourou, le site enverra les coordonnées complète de l'utilisateur a RMS pour que le fautif réponde pleinement de ses actes.
C'est mieux?
Et ta fonction d'authentification, quelle est son rôle ?
Quand le l'utilisateur veut se connecter, le serveur lui envoie la fameuse fonction d'authentification générée pseudo-aléatoirement. Là l'utilisateur dispose de 3 minutes pour compiler le client et se connecter avec. Le role de la fonction c'est qu'elle doit être réputé très difficile a analyser et réimplémenter en 3 minutes. Donc l'utilisateur ne pourra en 3 munites n'utiliser que celle là.
Bon biensur faut un ordi qui tienne le coup mais tout le monde sait que les vrais libristes auditent et compilent eux même chaque bout de code qui tourne sur leur machine ;) . Ce qui suppose qu'ils disposent forcément d'un tel matériel.
J'ajouterait qu'il reste un problème. On pourrait compiler ce fichier avec non pas le client mais un code glue. Ce code glue ferait le lien entre le client et la fonction, par exemple via une socket. Or même si le code glue devrait être en GPL car compilé avec le fichier envoyé, le client n'aurait plus à être compiler avec le dit fichier dont pourrait être propriétaire. Pour remédier a ca, la fameuse fonction pourrait s'assurer en permanance que ce code avec qui elle a été compilée :
- ne communique qu'avec le serveur et X (suffit de surveiller les sockets ouvertes)
- n'est lié qu'avec des bibliothèques qui sont dans une liste blanche
Si tel n'est pas le cas, la fonction enverrait une alerte au serveur qui prendrait les mesures adéquates.
S'il faut que j'upload mon client SOAP pour l'appeler ensuite en SSH, reconnais que ça perd une partie de son intérêt.
La liberté n'a pas de prix!
Et puis, comment vérifies-tu que le programme uploadé en SSH est bien libre ?
Encore une fois, RMS est la solution.
Ah, voilà une conclusion qui va faire plaisir à nos amis industriels du disque, du cinéma et des jeux vidéos, parce que pour l'instant, ils y arrivent pas =)
Normal, ils n'ont pas RMS!
[^] # Re: comme ça, non
Posté par gaaaaaAab . Évalué à 1.
En mettant de côté le "petit" problème opérationnel avec RMS (le clônage n'existe pas ;-), envisageons un logiciel pas libre qui forge des captures d'écran de logiciel libre et qui les envoie toutes les secondes (au lieu d'une seule fois).
Quand l'utilisateur veut se connecter, le serveur lui envoie la fameuse fonction d'authentification générée pseudo-aléatoirement. Là l'utilisateur dispose de 3 minutes pour compiler le client et se connecter avec. Le role de la fonction c'est qu'elle doit être réputée très difficile a analyser et réimplémenter en 3 minutes. Donc l'utilisateur ne pourra en 3 munites n'utiliser que celle là.
Je pense qu'en quelques dizaines de connexion, un attaquant aura suffisamment de billes pour distinguer les quelques classes de ces fonctions (vu comme c'est déjà pas simple d'en fabriquer ne serait-ce qu'une seule, je ne suis pas convaincu que ça soit très faisable d'en générer pleins à la volée), analyser tranquillement et écrire du code pour gérer tous les cas.
Sinon, pas la peine de s'embêter, suffit de s'en servir une fois dans un client libre dans la plage des 3 min, en espionnant la mémoire ou les traces réseaux, et les quelques informations utiles sont accessibles.
Vu tout ce que tu lui demandes de faire à cette fameuse fonction, c'est plus une fonction, c'est un logiciel ! Ce qui nous ramène au cas précédent. Il suffit de comprendre le protocole entre cette fonction et le serveur pour la ré implémenter sans l'utiliser.
Le problème fondamental, c'est que tu dois donner au client des moyens pour se connecter, et, tu peux essayer tout ce que tu veux pour essayer d'obscurcir le mécanisme d'authentification, in fine, la machine cliente dispose toujours des informations nécessaires à la connexion. Du coup, ça sera toujours contournable par quelqu'un d'expérimenté (cf toutes les majs d'Itunes).
La liberté n'a pas de prix!
En même temps, il me semblait que pour la GPL, l'idée, c'était de protéger les liberté tant des développeurs que des utilisateurs. Si on ne s'occupe de protéger la liberté que d'un point de vue dogmatique (il faut que ça doit libre parce qu'il faut que ça soit libre), ça perd un peu de son sens.
En fait, on mélange un peu deux choses dans ce débat j'ai l'impression : la liberté du code et l'ouverture d'un service. Et là, on n'essaie de calquer les notions de liberté (qu'on a l'habitude de voir pour le code) sur un hybride code/service, et amha, ça marche pas bien :)
[^] # Re: comme ça, non
Posté par benoar . Évalué à 2.
# Vision du libre
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 10.
Vraiment sympa ta vision du libre !
Tu veux pas non plus interdire l'accès au gens qui ont installé ndiswrapper, les drivers nvidia, et qui sont petits et laids ?
Tu veux pas non plus faire une recette de gâteau qui utilise l'ADN des gens pour empêcher les Chinois de réussir à préparer ce dessert ?
Le mouvement libre, c'est la liberté pour tous. BSD, GPL ou autre, on veut tous l'interopérabilité. Si tu veux interdire au propriétaire d'interagir avec ton « libre », alors tu n'es pas libriste, tu es privateur, comme le logiciel propriétaire…
(Sans compter le fait qu'un logiciel BSD, privatisé et amélioré par une société pour son usage interne ne sera plus compatible alors que la base qui sert à se connecter à ton service n'aura pas forcément changé)
[^] # Re: Vision du libre
Posté par GTof . Évalué à 1.
Tu veux dire un peu comme la GPL qui prive de la liberté de ne pas redistribuer les sources?
PS: On est vendredi a Sydney
[^] # Re: Vision du libre
Posté par fredoche . Évalué à -1.
J'ai pas de vision particulière, mais le cas que je présente peut se poser. Par exemple, je comprendrais que les gars qui fournissent Ubuntu One ne soient pas enclins à voir d'autre clients se mettre à exister, sauf si ceux ci sont ouverts, toujours dans une optique qui incite au partage de la connaissance, en l'occurrence du code.
Pour le reste, je vois vraiment pas le rapport avec les Chinois.
(Sans compter le fait qu'un logiciel BSD, privatisé et amélioré par une société pour son usage interne ne sera plus compatible alors que la base qui sert à se connecter à ton service n'aura pas forcément changé)
Je proposais justement la gpl v3.
# Conditions d’utilisation du service
Posté par nicoastro . Évalué à 4.
« 5.3 Vous acceptez de ne pas accéder (ou de ne pas tenter d’accéder) à tout ou partie des Services par tout moyen autre qu'à travers l'interface fournie par Google, sauf si vous y avez été expressément autorisé par Google dans le cadre d’un accord distinct. »
D’un point de vue technique je ne vois pas trop comment on pourrait l’interdire.
[^] # Re: Conditions d’utilisation du service
Posté par Octabrain . Évalué à 3.
D'autre part, une licence qui dit "vous n'avez le droit d'accéder au service que si la licence est soit GPL/BSD/WTFPL" est du même acabit, et mérite le même traitement.
# c'est toi qui est non-libre
Posté par Octabrain . Évalué à 2.
# Libre
Posté par el_gringo . Évalué à -1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.