Jean Gabes a écrit 459 commentaires

Merci beaucoup. J'ai corrigé la version chinoise traditionnelle, mais il reste la version allemande si quelqu'un connait cette langue.

Hum c'est rajouter une propriété dans un tableau. Techniquement c'est simple, mais l'implication est loin d'être anodine. Est-ce que ça compte?

Sinon il y a d'autres points assez facile à traiter, mais genre 30minutes plutôt qu'une poignée de minutes.

Oui, mais j'espère tout de même une réponse de la FSF avant l'année prochaine tout de même :)

Je me demande si ce serait si gênant que ça la GPLv2 car leur solution est livrée sous forme de VM. Livrée donc ils donnent les sources de cette partie avec la GPLv2.

Dans un cadre plus global les utilisateurs seront atteint dans leurs libertés, mais concernant XI, que le cœur soit GPLv2 ou AGPL ça ne va pas changer grand chose je pense.

Ah bah quelqu'un est déjà passé sur Wikipedia. Le modèle d'édition communautaire c'est vraiment rapide.

En effet, j'ai admin l'inspiration pour une partie très limitée du code (une fonction en fait), chose qui va être réglée par la FSF quitte à faire réécrire cette partie cette partie après avoir documenté ce qu'il faut pour que la personne n'ait pas besoin du code de Nagios pour cela.

Je préfère un règlement à l'amiable tout de même. J'ai suffisamment confiance dans mon projet pour ne pas avoir à me mettre à dos le projet initial.

Ensuite je lui laisse la possibilité de lister le code en question et même une solution simple : prendre part à la licence avec un simple patch de 5minutes. Il peut sortir la tête haute sans aucun soucis ni rancune.

Il ne faut pas oublier non plus que s'il sort des arguments tirés par les cheveux sur ce genre de choses il a aussi un outil très fortement lié à Nagios et non sous licence GPLv2. Mais bon, la guerre des licences, je la laisse aux avocats des sociétés impliquées.

C'est tout à fait exact. Aller hop, gogo édition un peu partout.

Oui, le mot fork semble l'énerver, et compatible avec sera bien mieux adapté en effet. Une pierre deux coups.

Pour l'incompatibilité c'est surtout sur la zone grise du "derivated work" pas des licences qui sont clairement pas compatibles.

On verra bien ce que cela donne.

C'est possible. Mais alors demander le changement de licence n'a pas de sens autre que le fud non? J'ai encore espoir que ce n'était pas dans ce sens.

Il ne peux pas changer la licence se Nagios, mais sa solution XI se base sur Nagios (c'est une interface web à la Centreon, mais en closed source).

Donc à part vouloir faire chuter Shinken, si c'est de ça qu'il a peur, alors oui, il a des raisons d'avoir peur. Car je ne considèrerai XI pas autrement que Tivoli ou HPOV et je fournirai à la communauté toutes les fonctionnalités que je peux. Mais je n'ai pas sa force de développements non plus.

Ensuite il peut très bien réussir sans avoir à flinguer les autres projets open source. Il lui suffit d'être meilleur qu'eux et d'utiliser autant que possible la force de la communauté pour ça. C'est tout ce que je lui souhaite en fait.

Heureusement, j'ai pris un algo (celui que j'avais proposé à Nagios en fait...) et le reste j'ai fait les miens car l'algorithmie c'est marrant je trouve, et recopier un algo sans réellement le comprendre, c'est trop dangereux s'il y a un bug dedans.

J'ai regardé dans la documentation ce que c'était censé faire et c'était parti pour une bonne partie de dialogue avec emacs.

De plus, une adaptation ligne à ligne entre du C et du Python, ça donne du mauvais code Python, mais là on sort du sujet :)

Merci, ton mail me fait chaud au cœur :)

Si le fait de ne pas avoir un concurrent fermé en face de lui lui fait peur, ça peut se régler de suite : il me propose quelques patchs mineurs ou pas que j'inclus de suite dans le projet. Comme ça il aura un contrôle sur la licence qui ne pourra pas devenir fermée.

Je vais lui proposer tient.

Je viens d'envoyer une réponse sur la mailing list. Je ne suis pas contre quelques retours sur sa forme/son fond. Je pense avoir été ouvert au dialogue.

Bon ensuite vu mon anglais, j'ai peut être dit tout le contraire que j'aurais souhaité bien sûr...

Je parle pour les utilisateurs en effet. Les dev sont à leur service, la licence ce n'est pas pour faire plaisir à un développeur, mais pour aider au mieux l'utilisateur à mon sens.

Oui tu as raison, les réponses à chaud je devrais éviter. Pour la licence oui, je pense qu'elle est plus adaptées pour les utilisateurs que la GPL standard.

J'attends la réponse de la FSF, mais même si je suis dans mon droit, je vais tout de même expliquer les points qu'il pense litigieux, car le fud sur les licences ce n'est pas bon sur le long terme.

Concernant la non possibilité d'une version privatrice : je signe pour! :)

Par contre je pense être dans mon droit, je me suis inspiré pour une petite partie du code sur la reconnaissance des formats des datas car ce n'était tout simplement pas documenté, je n'avais donc pas trop le choix, mais de plus je ne pensais pas avoir ce genre de soucis par la suite.

Et si changer amène les utilisateurs à avoir moins de liberté, ça m'embête vraiment.

Merci de vos réponses. J'ai déjà envoyé une demande à la FSF et à RMS. J'espère une réponse rapide. Ensuite je regarderai comment faire pour arranger les deux parties.

Si la demande est justifiée et que c'est juste une perte de libertés pour les entreprises supervisées et que je dois passer une partie du code en GPLv2 soit, pas de soucis. Mais si la demande est là juste pour faire du FUD, ça m'embêterai vraiment.

Oui, on va voir comment ça peut se régler à l'amiable et qu'ils donnent des exemples précis de ce qui doit être changé. A mon avis ça va être rapide mais bon.

Le choux était simple : la supervision est parfois faire par une société extérieure et je pense qu'une société monitorée doit pouvoir avoir accès aux sources qui la supervisent, tout simplement.

Oui c'est le nom des katanas les plus coupants. Ceci illustre la fonctionnalité première le l'outil : découper la configuration pour la dispatcher sur des daemons.

Pour moi un projet qui peux devenir close source et donc enlever des libertés aux utilisateurs n'est pas un choix qui me convient. Si d'autre le font c'est leur choix, mais le code que j'écris n'enlèvera pas des libertés aux utilisateurs. Ensuite c'est sujet à discutions bien sûr vu que personne n'est d'accord sur ce point lorsque l'on parle de licences...

Oui mais là c'est un problème d'interprétation, donc jugement et compagnie.

Merci beaucoup pour ces éclaircissements.

3.1 : non, en aucun cas.
3.2 : la documentation dans un autre répertorie est issue de Nagios, donc elle est en GPLv2.
3.3 : vu que pas de code en commun, pas de soucis (enfin c'est ce que j'aurais cru au départ...).

Ah non, si ça part dans du close source là il courrir longtemps. Non, si ça fait du GPL à l'ancienne mode Nagios (donc toute les inovations dans le code libre, et non dans la partie privatrice) là oui.

Je suis si mauvais que ça en communication? Je savais que le marketing ce n'était pas pour moi, mais à ce point là :p

Sincèrement je n'avais pas l'impression d'être si odieux avec eux, juste de répondre avec mon propre style (un poil décalé parfois...).

Bref, passons.

S'il faut que je passe en GPLv2 bah j'y passerai, mais je me demande juste ce qui va se passer après.

*Nagios le réintègre et joue le jeu de l'open source : ok, je signe de suite!
*il l'intègre, vire quelques parties pour en remettre d'autres sous licence fermée : là je vais être moins d'accord...

En fait je n'ai pas grand chose à perdre au final avec le passage GPLv2. Je ne vois pas de sénarios où la communauté y perds en fait (sans le cas numéro2, je fork le code python pour remettre les parties supprimées...).

Très intéressant, merci ça y ressemble bien en effet.

S'il pleure mais que c'est justifié, après tout il aura eu raison. Après pour une réintégration pure et simple le problème c'est que ce que propose Shinken en open est ce qu'il voulait proposer en closed source.

S'il est d'accord pour que Nagios reste ouvert avec le code Shinken, passer de AGPL à GPL sera un petit sacrifice que je consentirai sûrement à faire.