Opale: noyau multithreadé pour TI-68k - Page 4

Je te le souhaite bien va

ExtendeD, rien ne t'empecherais de le faire aussi si opale etant en LGPL hein, donc bon, argument en mousse

- Pour faire du business, il faut aller sur d'autres plateformes que TI
- Il faudra modifier la lib pour l'adapter
- J'ai pas envie de redistribuer sous LGPL la nouvelle version, je vais être le seul à profiter des revenus

Moi je suis plutôt LGLP mais je vais pas pleurer non plus si c'est du BSD.
D'ailleurs je m'y connais pas trop en liscence mais Ximoon publie ca sous BSD, Extended doit pouvoir distribuer sa version modifiée sous LGPL non?

Probablement.
(pour les autres plateformes, il devrait être facilement portable, mais bon l'intérêt me semble limité )

Uther>
ben oui, surtout si il s'appelle KK ^^

mais bon, je vois pas le problème que des vilains capitalistes aient la possibilité d'en profiter, parce qu'à moins que tu aies l'intention de leur vendre et te faire de l'argent avec ou que tu croies que le produit {nombre de personnes comptant faire des contributions significatives} x {probabilité que la personne en question décide de changer toute sa licence pour utiliser ton truc plutôt que d'aller voir ailleurs} soit suffisamment élevé pour compenser les problèmes liés aux incompatibilités de licence, ça va surtout faire chier le monde...

C'est quoi les risque d'incompatibilité avec la LGPL?

(y'en a pas)

Mais sinon, y'a eu des modifs depuis la release initiale ou pas ?
(Sur le projet, pas sur la licence)

spectras :
(y'en a pas)

Ben si, si on veut inclure du code avec une licence incompatible avec la GPL (par exemple si on veut mettre CC *dans* Opale c pas possible ). Disons que si on veut ajouter une dépendance à Opale, y a toujours la tentation d'envoyer chier la LGPL en disant "c'est externe à Opale, je peux en faire ce que je veux et lui mettre la licence que je veux", mais si la version d'Opale modifiée a *besoin* de cette dépendance pour fonctionner correctement, alors ce n'est plus une dépendance "externe", et l'inclure est tout simplement une violation de l'esprit (et sans doute aussi de la lettre) de la LGPL...


Après, la question c'est de savoir si on peut envisager des contributions significatives à Opale : si personne n'aura envie de rajouter par exemple des bouts d'une lib tierce partie (comme APR, sous licence Apache donc incompatible GPL), et qu'on veut juste autoriser des petits patchs créés juste pour Opale, alors la LGPL suffit. Mais il ne faut pas dire que ça ne risque pas de poser pb...

Ben c'est une question de point de vue. Si Ximoon, en tant qu'auteur de Opale, la place sous LGPL, ça note un désir que Opale reste libre, même si il est utilisé dans des projets non libres. Du coup y inclure une dépendance à un truc non libre va à l'encontre de ce désir, les utilisateurs de la version avec cette dépendance ne pouvant plus en faire ce qu'ils veulent.

La question quand tu définis la license, c'est pas "quel problème ça va poser aux utilisateurs" mais "comment je vois l'avenir de mon projet". La limitation n'est pas un problème, elle est le but principal de cette licence. Si ce n'est pas ce qui est souhaité, c'est que ce n'est pas la licence appropriée.

en tout cas, une chose est sûre, l'avenir d'un programme sous GPL, c'est d'être forké en _nostub

spectras :
Ben c'est une question de point de vue. Si Ximoon, en tant qu'auteur de Opale, la place sous LGPL, ça note un désir que Opale reste libre, même si il est utilisé dans des projets non libres. Du coup y inclure une dépendance à un truc non libre va à l'encontre de ce désir, les utilisateurs de la version avec cette dépendance ne pouvant plus en faire ce qu'ils veulent.

La question quand tu définis la license, c'est pas "quel problème ça va poser aux utilisateurs" mais "comment je vois l'avenir de mon projet". La limitation n'est pas un problème, elle est le but principal de cette licence. Si ce n'est pas ce qui est souhaité, c'est que ce n'est pas la licence appropriée.

- Déjà le problème c'est que ça n'interdit pas que les licences non-libres, mais aussi les licences non-compatibles GPL. Il y a tout un paquet de licences libres non compatibles GPL, et je te souhaiterais bien du courage pour construire une distrib Linux pas trop ridicule qui soit entièrement sous GPL... (même en comptant les trucs relicenciables en GPL)

- Pour ton deuxième point : exactement, c'est bien pour ça que je précise que s'il fait le choix de la LGPL, ça n'est pas sans inconvénients. C'est un choix qui se défend si, pour lui, c'est *très* important que personne n'en fasse des dérivés non-libres, mais il faut bien voir que ça va aussi mettre des bâtons dans les roues de certaines personnes qui ne font que du logiciel libre et qui auraient bien aimé pouvoir utiliser Opale. Il faut comprendre les deux aspects avant de pouvoir faire un choix éclairé (et c'était le but de ./96)

je te souhaiterais bien du courage pour construire une distrib Linux pas trop ridicule qui soit entièrement sous GPL...

...ou compatible. Ca s'appelle Debian
...si tu n'utilises pas les repository non-free, évidemment, ainsi que 2 ou trois gros logiciels comme apache. Mais à part ça tout le reste est bon.

pour le 2), on est d'accord sur le résultat mais pas sur l'interprétation. Si ça met des bâtons dans les roues, c'est que le quelqu'un ne faisait pas que du logiciel libre, sinon il aurait pas eu de problème. Dès qu'il y a une dépendance à quelque chose de non libre, c'est l'ensemble qui ne correspond plus à la définition, puisque tu ne peux pas faire ce que tu veux sur la totalité du projet. Le projet dans sa globalité devient donc non libre, même si la majorité de ses composants le sont.

pour le 2), on est d'accord sur le résultat mais pas sur l'interprétation. Si ça met des bâtons dans les roues, c'est que le quelqu'un ne faisait pas que du logiciel libre, sinon il aurait pas eu de problème. Dès qu'il y a une dépendance à quelque chose de non libre, c'est l'ensemble qui ne correspond plus à la définition, puisque tu ne peux pas faire ce que tu veux sur la totalité du projet. Le projet dans sa globalité devient donc non libre, même si la majorité de ses composants le sont.

Non car comme le dit pollux, si tu fait su "logiciel libre" mais que tu VEUX utiliser une licence qui est imcompatible GPL/LGPL, mais qui reste une licence "libre", ça pose problème

spectras
:

je te souhaiterais bien du courage pour construire une distrib Linux pas trop ridicule qui soit entièrement sous GPL...

...ou compatible. Ca s'appelle Debian
...si tu n'utilises pas les repository non-free, évidemment, ainsi que 2 ou trois gros logiciels comme apache. Mais à part ça tout le reste est bon.

C'est exactement de ça dont je parlais... (et non pas de non-free qui, comme son nom l'indique, n'est pas libre)
Linux sans OpenSSL, sans serveur web, sans PHP, sans LaTeX, etc..., ça suxerait énormément ^^

Bah OpenSSL....pas besoin, gnutls est un remplacement sous lgpl
Serveur web....il en existe d'autres
PHP...compatible GPL (le moteur Zend est distribué sous licence BSD)
tetex....un peu trouble parce qu'il a des extensions sous des licences dont j'ai la flemme de vérifier la compatibilité. Mais le moteur et les modules principaux sous sous GPL et LGPL.

Donc à part apache ? On est quand même loin d'une distrib linux ridicule hein s'il manque que apache

(dans tetex le moteur par défaut c'est tex et c'est pas sous licence compatible GPL. pdftex est sous GPL mais je crois que ce n'est pas encore le moteur par défaut même si ça a des chances de le devenir. Quant aux modules principaux ils sont sous LPPL si je ne m'abuse, mais bon je crois que la dernière version de la LPPL est considérée comme compatible GPL.)

spectras :
Mais sinon, y'a eu des modifs depuis la release initiale ou pas ?
(Sur le projet, pas sur la licence)

Rien de significatif, j'avais fait l'ébauche d'une surcouche graphique mais ça n'a pas dépassé le stade papier.

Elle ferait quoi cette surcouche ?

spectras
: La question quand tu définis la license, c'est pas "quel problème ça va poser aux utilisateurs" mais "comment je vois l'avenir de mon projet"

Enfin l'un et l'autres sont pas complètement indépendants non plus

Sinon une solution pour ces problèmes d'incompatibilité peut être quelque chose comme fait MySQL : http://www.mysql.com/company/legal/licensing/foss-exception.html

Elle ferait des fenêtres/menus/toussa aussi moches qu'inutiles, gèrerait un curseur, etc, etc, de manière évênementielle et threadée.
Encore une fois, je ne suis pas convaincu de l'utilité finale, mais ça m'a occupé pendant mon stage, aux heures creuses. Quoique, j'avais dans l'idée de faire un viewer de texte qui parserait le texte en arrière plan en chargeant dynamiquement les parties proches de ce qui est en cours de visionnage, mais #flemme# (sans parler de la version multithread de Rubix #trivapor#²)
En fait je pensais plus faire une lib s'appuyant sur Opale qu'étendre le noyau existant.

Pollux
: je te souhaiterais bien du courage pour construire une distrib Linux pas trop ridicule qui soit entièrement sous GPL... (même en comptant les trucs relicenciables en GPL)

Ca existe, ça s'appelle Emacs

C'est pas seulement parceque c'est un topic qui me concerne hein, Moumou, mais une fois de plus ton humour pourri et ton flood débile sont malvenus.
Oh et puis merde

z'en avez pas marre de dériver sur vos trolls de licences au lieu de parler de noyaux et de multithread sur TI?

Xi: tu pense qu'Opale pourrait etre portable sur autre chose que du 68k ?

squalyl^2 :
z'en avez pas marre de dériver sur vos trolls de licences au lieu de parler de noyaux et de multithread sur TI?

t'en as pas marre de raconter n'importe quoi à propos de discussions qui ont plus d'un mois ? (surtout que là, le "troll" en question, il aura duré une demi-page en tout et pour tout, que ça n'avait manifestement pas l'air de trop déranger Ximoon, et que quoi que tu en penses c'est important pour n'importe quel projet de faire attention à ne pas avoir une licence plus restrictive que ce dont on a réellement envie, dans la mesure où c'est susceptible de plus faire chier les utilisateurs que par exemple un bug...)

D'autant plus que c'est MON topic que que j'ai lancé moi-même le débat sur les licences (et je pense que j'aurais été en mesure d'arrêter le "troll" (que je n'ai pas vu en dehors du post de Moumou) au besoin).
Quand au portage d'Opale vers un autre proc, j'aurais tendance à dire pourquoi pas, mais je pense qu'il serait plus rapide et plus intéressant d'en réécrire un nouveau. Après, si c'est s'inspirer des algos et mécanismes, pourquoi pas.

Bon, je profite d'une nouvelle bêta (avec quelques modifications pour corriger un comportement erroné, pour moins bloquer les interruptions, etc) pour mettre (enfin) une licence digne de ce nom, à savoir, comme annoncé, une BSD.
Ceci dit, je ne pense pas que ça intéresse réellement grand monde

Doc mise à jour: http://mapage.noos.fr/cmolon/opale/
Beta 3: http://mapage.noos.fr/cmolon/opale/Opale-beta3-13-05-2006.zip

si, moi, pour comprendre le fonctionnement du changement de contexte entre les threads

en tout cas même si je risque pas de l'utiliser directement, je trouve ce projet très intéressant, et ce serait génial de le voir intégré dans une ROM l'utilisant en natif pour permettre un vrai multitasking transparent pour l'utilisateur.

Je ne sais pas si c'est une bonne référence pour comprendre le multitasking (hum j'avais promis un article sur le sujet y'a un an, faudrait que je m'y mette ), mais je l'avais écrit justement dans le but de mettre en pratique la théorie que j'avais étudiée

Pour la ROM, je peux pas dire que j'y ai pas pensé, mais ça m'a semblé un peu trop gros à faire pour le moment

ça me fait penser que j'ai des projet a avancer moi

Faudra que je (re)regarde les sources