Jean-Philippe Garcia Ballester a écrit 1104 commentaires

ta propension à discerner la malhonnêteté partout.

C'est faux, si tu relis bien ses commentaires, il commence par dire qu'il ne sait pas si l'auteur est malhonnête ou non, puis face à la réaction de l'auteur, dit que cette réaction le fait pencher pour la seconde hypothèse, mais il n'est à aucun moment péremptoire en disant que l'auteur est sciemment malhonnête.

vous êtes les parasites d'un beau mouvement auquel vous n'avez définitivement rien compris

Demander qu'une œuvre non-libre ne soit pas appeler libre, c'est parasiter le mouvement du libre ?

Demander de ne pas faire l'amalgame entre « libre diffusion » et « libre », c'est parasiter le mouvement du libre ?

Demander poliment les raisons qui ont conduit à choisir cette licence plutôt qu'un autre, en en montrant les inconvénients, afin de simplement comprendre, ou bien d'essayer de changer les choses sans que personne ne soit lésé, c'est du sectarisme ?

Tu noteras que les questionnements sur les intentions de l'auteur ne se sont faits qu'après que l'auteur ait esquivé les questions courtoises.

Dommage que les fautes d'orthographe ne soient pas illégales…

Et avec --no-install-recommends ?

Et encore un peu plus loin, on peut lire :
J'ai dit qque part que ca n'existait pas ? On me demande quoi utiliser pour comparer l'usage de ressources, je reponds. J'ai jamais dit que Linux n'avait pas ces features.

Si tu ne sais pas ce que c'est, c'est que tu n'en as pas besoin.

Il en a connaissance, chaque fichier source doit contenir un entête avec explicitement la licence de celui-ci.

Je vais encore me répéter, mais c'est écrit où dans la loi que chaque fichier source doit contenir une en-tête avec la licence ?

Mais tes ajouts n'ont aucunement changé la licence du code déjà présent dont tu n'es pas l'auteur (qui t'en donne le droit ? la GPL ne concerne que la distribution).

Ce que j'avais compris, mais c'est peut-être faux, c'est que la licence c'est le contrat que tu passes avec la personne qui te le distribue. Donc sous cette hypothèse, autoriser la redistribution sous une autre licence, c'est autoriser à changer la licence du code.

J'ai bien compris ce que tu veux dire, mais ce n'est pas parce que tu le ré-expliques de trois manières différentes que c'est vrai.

Alors je vais reposer ma question autrement : qu'est-ce qui dans les textes de lois, te permet de dire ça ?

Parce que si je comprends bien ce que tu dis, alors toujours dans l'exemple où A, l'auteur d'un logiciel, distribue à B un logiciel sous GPLv2+, et B rediffuse le logiciel à C sous GPLv3, alors C passe en fait un contrat GPLv3 avec A pour le tout, plus un contrat GPLv2+ par fichier avec A ?

En particulier, il est possible, en acceptant la GPLv3 que B distribue, que C passe des contrats dont il n'a pas connaissance des clauses (GPLv2+).

Je tiens ça du fait que seul l'auteur du code peut en changer la licence...

Je vais répéter ma question, mais ça vient d'où ça ?

Oui et ce contrat c'est entre toi et *l'auteur* du dit code...

Ça veut dire que l'auteur peut passer un contrat avec quelqu'un sans en avoir connaissance ? (A passe un contrat avec B, B redistribue à C, donc A passe un contrat avec C).

D'ailleurs wikipédia me dit : « en droit, une licence est un type de contrat (exemple : licence libre) ».

Il obtient du code qui est licencié en GPLv2+ et redistribué en GPLv3, le fait que tu le redistribue en v3 ne change pas que le code que tu distribues avec (hors patch GPLv3 ajouté par toi lors de la redistribution) est en GPLv2+...

Et tu tiens ça d'où ? C'est en contradiction avec ce que je croyais : une licence est un contrat entre deux entités.

Contrat avec A sous GPLv2+, tu choisis de distribuer l'ensemble sous v3 comme la licence t'y autorise (ca rajoute des restrictions supplementaires pour toi qui redistribue par exemple). C recoit l'ensemble sous v3, mais le code est toujours sous GPLv2+ (la licence n'a pas change!).

Pourquoi ? Le contrat que passe C avec moi, c'est la GPLv3. Si C n'obtient pas une copie du code de A, pourquoi aurait-il le droit d'appliquer un contrat qu'il n'a pas passé ?

C reprend alors le code (eventuellement le repackage et vire les parties v3 only si tu as fait des ajouts) et redistribue sous la licence initiale (GPLv2+). Donc voila, C applique le contrat passe avec A, parce que la licence du code l'autorise a le faire!

De ce que je comprends, si A ne distribue plus le code (ni personne sous GPLv2+), C ne peut pas faire ça. La licence qu'il a eu, c'est la GPLv3, et elle ne l'autorise pas à redistribuer le code en GPLv2.

Bien sur que si, tu n'as pas le droit de changer la licence que tu reprends. Le seul truc que tu peux faire c'est mixer ton code (tes ajouts/modifs), sous ta licence, avec la licence du code que tu as repris, sachant que les morceaux originaux restent sous la licence originale.

Et pourquoi ? Je passe un contrat avec une entité A (la licence). Si ce contrat m'autorise à redistribuer sous un autre contrat, lorsque que je passe un contrat plus restrictif avec C sur ce code, pourquoi aurait-il le droit d'appliquer le contrat que j'ai passé avec A ?

Dans tous les cas, il faut retenir que tu ne peux pas changer la licence du code/documentation que tu reprends. Tu peux redistribuer l'ensemble sous une licence compatible

Je n'ai jamais compris la différence entre relicencier et redistribuer sous une autre licence. De ce que j'en avais compris, la licence n'est pas intrinsèque au code, mais c'est un contrat passé entre deux entités.

Si par exemple une entité A développe un logiciel, et le distribue à B sous licence WTFPL. Alors B peut le redistribuer à C sous licence GPL, parce que la redistribution sous une autre licence est autorisé par la WTFPL, et C ne pourra pas appliquer les droits conférés par la WTFPL mais seulement ceux de la GPL. Pour que C puisse avoir le code sous WTFPL, il faut qu'elle obtienne une copie donné par A sous licence WTFPL, même si la copie est identique.

J'ai bon, ou j'ai rien compris ?

On étudie Balzac ou Zola à l'école, mais pas Barjavel.

C'est faux.

De l'éducation ?

Avec RoR, je n'ai jamais eu que des galères pour l'installer et les packageurs Debian s'en plaignent car c'est impaquetable, inmaintenable, …

Si tu parles de http://pkg-ruby-extras.alioth.debian.org/rubygems.html, c'est quand même pas auusi noir que tu le laisses entendre...

Surtout que depuis que passenger existe (et il est dans Debian), déployé une appli rails est devenu un jeu d'enfant.

Pas vraiment. @classmethod, comme tous les autres décorateurs, c'est une méthode qui prend en paramètre une méthode et dont la valeur de retour (la méthode modifiée) est affectée à la place de la méthode d'origine.

C'est donc nettement moins souple qu'une méthode qui prend en paramètre une classe. Par exemple, je veux créer une méthode qui prenne en paramètre une classe et une chaîne de caractère, et crée plusieurs méthodes dans la classe, dont le code est basé sur la chaîne.

D'autre part, si un décorateur n'est rien d'autre qu'un appel de méthode, pourquoi n'est-ce pas la syntaxe d'un appel de méthode. Pour moi, et c'est très subjectif bien sûr, je trouve ça incohérent. Ça me gonfle d'avoir à apprendre quinze concepts et syntaxes pour faire des choses qui sont intrinsèquement la même notion.

C'est un détail jusqu'au jour où tu cherches pendant longtemps pourquoi ça marche pas… Et ça ne m'est pas arrivé qu'à moi…

Au temps pour moi sur ce point, j'ai toujours pas réussi à intégrer ce truc.

Je n'ai pas dit que ce n'était pas possible, j'ai dit que c'était galère (ce que tu viens de me confirmer), et que c'était incohérent dans le sens ou si tout est objet, rajouter une méthode de classe ou rajouter une méthode à un objet, c'est finalement la même chose, mais ça s'écrit pas du tout pareil.

Un autre exemple pour s'amuser : une méthode dont le nom commence par __ est privé, sauf si le nom se termine aussi par __. C'est tellement cohérent et intuitif qu'on dirait une règle de grammaire du français.

stripatublu% python
Python 2.5.4 (r254:67916, Nov 19 2009, 22:14:20)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Plop:
... def __plop(self):
... pass
... def __plop__(self):
... pass
...
>>> plop = Plop()
>>> plop.__plop()
Traceback (most recent call last):
File "", line 1, in
AttributeError: Plop instance has no attribute '__plop'
>>> plop.__plop__()
>>>


Les plus trolleurs auront remarqué le message d'erreur très explicite.

Si tout est objet, cela veut dire que chaque instruction s'execute dans le contexte d'un objet, et donc self doit être défini. Quand tu ouvres un interpréteur ruby, self et définit dès le départ (et est une instance de type ObjectSpace).

Quand je crées une nouvelle classe, je ne fais qu'instancier un objet de type Class. Lorsque je la définis, je suis dans le constructeur de cet objet, et donc self est bien défini, et représente l'instance que je suis en train de définir.

Je ne trouve pas ceci cohérent avec le principe « tout est objet » :

stripatublu% python
Python 2.5.4 (r254:67916, Nov 19 2009, 22:14:20)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Plop:
... pass
...
>>> Plop().__class__
<class __main__.Plop at 0x7f82a55b36b0>
>>> Plop.__class__
Traceback (most recent call last):
File "", line 1, in
AttributeError: class Plop has no attribute '__class__'


En ruby, une classe est objet, tu peux créer une classe en appelant le constructeur de Class, et dont le scope n'est pas global. Ça, c'est cohérent avec le principe « tout est objet ».

À appeler des méthodes qui s'executent sur une classe (pour créer des méthodes par exemple).

Ensuite, à partir du moment où tu commences à définir ta classe, elle existe, tout comme le fait qu'un objet existe avant que le constructeur soit terminé. Parce que étant donné qu'on peut rajouter des méthodes à la volée, même si c'est plus galère et/ou moche en Python qu'en Ruby, ta classe n'est jamais complètement définie (au sens ou les méthodes des objets de la classe ne sont jamais figés).

Par exemple, en Ruby, si tu fais
def monobjet.manouvellemethode
…
end

tu crées une méthode qui n'existera que sur l'objet monobjet, et pas sur tous les objets de la même classe. Pour créer une méthode de classe, tu utilises exactement le même concept : tu crées une méthode sur la classe que tu es en train de définir.

De même, créer une classe anonyme se fait simplement en instanciant un objet de type class. Quoi de plus logique ?

Un exemple pour étayer ton argument ?

Ce que j'aime bien dans Ruby que je n'ai pas retrouvé en Python, c'est la cohérence. Il y a très peu de principes à savoir en Ruby, et lorsqu'on les a saisis, on devine facilement comment va se comporter le langage dans un cas inconnu.

Un exemple pour étayer mon propos : self n'est pas défini lors de la définition de la classe en Python. On a aucun moyen d'accéder à l'objet qu'on est en train de définir.