Vieux pots, meilleures soupes, toussa

Mais ces histoires d'oeuvre dérivées sont décidément un sacré sac
de noeud. Vivement que je ne sais qui se décide à faire un vrai
procès qu'on sache à quoi s'en tenir une fois pour toute.

Ouais. Je crois que la GPL 3 essaiera d'être plus claire sur le
sujet, enfin on peut l'espérer.

Le draft2 de la v3 :

- suppression de la notion d'oeuvres dérivées, et donc aussi de la
définition merdique de la GPLv2.

- remplacement par la notion de "based on", avec pour définition :
si tu fais une oeuvre qu'un détenteur de copyright peut théoriquement
t'interdire de faire alors ce que tu fais est "based on".

Pour les cas classiques du plugin proprio prévu pour un programme GPL
et du programme proprio utilisant une librairie GPL, on en revient aux
questions fondamentales sur la signification du copyright. La façon
dont je vois les choses, c'est que le but premier du copyright, sa
justification donc, c'est de permettre le contrôle des profits. Il
concerne donc d'abord, comme son nom l'indique, la copie de l'oeuvre.
Par extension immédiate, il couvre aussi des "variantes" de l'oeuvre,
sans quoi il serait pour une grande part inopérant. Mais il me semble
qu'il n'a pas à couvrir des oeuvres utilisant ou nécessitant une
autre oeuvre (sous réserves que ces nouvelles oeuvres ne
"contiennent" pas l'oeuvre d'origine). Cela serait étendre le
"contrôle" au delà de ce qui est justifié/justifiable.

C'est le discours, maintenant ancien, de ceux qui combattent le
"copyright d'interface".

Car enfin, le détenteur du copyright d'une implémentation doit-il
pouvoir interdire le distribution de tout programme dialoguant avec
cette implémentation ? Si on n'est pas d'accord avec les brevets
logiciels, il me semble qu'on doit aussi ne pas être d'accord avec
cette interprétation étendue du copyright, non ?

Pour en revenir au draft actuel de la v3, il me semble qu'il n'y
a pas de changements significatifs. Même si les histoires de liaisons
dynamiques, de "complex data communication" et autres "control flow"
sont maintenant explicitement cités dans le texte de la licence, il
s'agit toujours de savoir si oui ou non le détenteur d'un copyright
GPL a le DROIT de m'interdire patin couffin.

Évidemment ça ne règlera pas le sort des 42 zillions de softs déj à
publiés en GPL 2.

Dont un certain KERNEL DE MES DEUX. A ce propos, j'ai récemment
découvert ça http://kororaa.org/static.php?page=gpl
Bizarre qu'on est pas trollé la dessus dans fcold :-)

Tant que j'y suis, je signale un autre sujet de troll, ma
foi d'un fort beau gabarit :
http://groups.google.com/group/linux.kernel/browse_frm/thread/41135002359b0 ea3
Résumé : le 2.6.19 est une grosse merde et la façon dont la gestion
de la VM est développée/maintenue FAIT PEUR. Si j'étais IBM ou je
ne sais quel autre gros joueur, je m'attellerais à essayer de mettre
un peu d'ordre dans ce foutoir d'amateur.

Je le trouve un peu flou, Linus. Au fond, il déteste RMS et la FSF,
mais il tient beaucoup à ce qu'il soit clair qu'un driver soit
considéré comme devant être sous GPL.

Ce en quoi il a raison. Je ne mange absolument pas l'argument foireux
d'Ubuntu [...]

Je ne parlais pas des raisons pragmatiques qui pourraient pousser
à autoriser les drivers proprios, je parlais de la _légalité_ des
drivers proprios. Le fait est que Linus fait partie de ceux qui
disent que le détenteur d'un copyright sur le kernel peut
théoriquement interdire la distribution d'un driver non GPL.

Normalement, les drivers ont vocation à être dans le noyau. C'est
cette intégration qui fait 99% de la robustesse de Linux dans son
ensemble,

Bof. 99% de la robustesse c'est la qualité du code et les tests,
et ces deux points sont totogonaux avec "être dans le noyaux"

le fait de refuser les drivers codés on ne sait comment
par on ne sait qui. Du coup et selon cette logique, la compatibilité
binaire on n'en a absolument rien à foutre; les drivers sont dans
le noyau, on change de noyau, on change de drivers.

A ce propos, et toujours pour rester en charte, un développeur donne
son point de vue sur cette histoire "les drivers ont vocation à être
dans le noyau" :
http://groups.google.com/group/linux.kernel/msg/d7a42fd2e84f6ac7

Pour la question plus générale des ABI [...]

Pour ma part je trouve que c'est bien géré et cohérent, quoi. Ça se
calmera quand ils ne sauront plus trop quoi changer ;)

Il y a manifestement une volonté délibérée de faire exprès de
casser ce qu'il faut pour compliquer la vie des mainteneurs
de modules binaires. Un jour ou l'autre, ce côté "on fait joujou
avec nos internals" ne sera plus tenable.

L'idée est d'une simplicité transcendantale : si j'ai acquis
légalement une copie d'un machin, j'ai le droit de vendre/donner ce
machin à qui je veux : "fair use", à condition qu'il n'y est pas de
contrat. La GPL se prétend une licence, pas un contrat. Donc, je
download, j'agrège avec autre chose comme je veux, et je donne le
résultat à qui je veux, alors que je n'ai jamais accepté la GPL.
Marrant, non ? (encore super plus marrant, avec diverses façons de
comprendre "j'agrège")

Ce n'est pas vraiment comme ça que je l'ai compris au premier coup
d'oeil, mais plutôt sur le fait que si je ne lie pas (avec ld) les obje ts
GPL avec d'autres "incompatibles", je peux revendre l'ensemble, et
laisser au destinataire final le soin d'assembler le tout qui n'est pas
redistribuable GPL-ment, et ne tombe pas sous le coup de la GPL
puisqu'il n'a pas été redistribué en tant que tel stricto sensu.

Nous ne parlons pas de la même chose. L'usage "créatif" du concept
de "fair use" me permet de redistribuer un assemblage contenant du
GPL alors que je n'ai pas "accepté" la licence GPL (qui n'est pas un
contrat)

Par ailleurs, je signale que le point de vue que tu résumes là n'est
manifestement pas celui de la FSF et de Linus. Si un module non
GPL est une oeuvre dérivée, sa simple distribution TOUT SEUL
est déjà illégale.

D'un autre côté, je suppose que le juge est autorisé à juger la
mauvaise foi ( à l'oeuvre dans ce cas théorique ) en tant que telle, et
la rejeter. Mais je n'en sais rien...

Et qui est autorisé à juger à quoi s'applique le copyright
et à quoi il ne s'applique pas ?
Mais si une jurisprudence "les modules sont dérivés" devait
s'établir, même la distribution sur un site séparé avec assemblage
par l'utilisateur serait menacée.
En fait je suis d'accord avec toi au sujet de la mauvaise foi :
dans l'hypothèse ou seule la distribution "as a whole" déclencherait
la GPL, ceux qui disent "c'est pas nous, c'est l'utilisateur qui lance
un script qui fait le café (et qui charge le module par effet de
bord)" se trouveraient en mauvaise posture. Ceci dit, ça ferait un
tel bordel dans le monde des distributions que je n'y crois pas
trop. Il y a un bel ensemble de "fermage de gueule, faites pas
de vagues"

--
Concernant la distribution, celle-ci devra offrir des garanties de
pérennité et assurer une ouverture dans son utilisation à grande
échelle sur les postes de travail, ce qui exclut a priori les
distributions non commerciales (du type Debian ou similaires)

Le Fri, 29 Dec 2006 05:00:18 -0800, Manuel Leclerc a écrit :

- suppression de la notion d'oeuvres dérivées, et donc aussi de la
définition merdique de la GPLv2.

PLutôt bien, non?

- remplacement par la notion de "based on", avec pour définition : si tu
fais une oeuvre qu'un détenteur de copyright peut
théoriquement t'interdire de faire alors ce que tu fais est "based on".

Ça laisse peu ou prou la décision aux lois du pays et au tribunal qui
juge le cas. Est-ce gérable, je ne sais...

C'est le discours, maintenant ancien, de ceux qui combattent le
"copyright d'interface".

Oui.

Car enfin, le détenteur du copyright d'une implémentation doit-il
pouvoir interdire le distribution de tout programme dialoguant avec
cette implémentation ? Si on n'est pas d'accord avec les brevets
logiciels, il me semble qu'on doit aussi ne pas être d'accord avec
cette interprétation étendue du copyright, non ?

Je pense aussi. Le copyright d'interface n'est clairement pas une bonne
idée. Il se peut que la FSF l'ait instrumentalisé à un moment, sans y
croire pour autant. Purement politique, quoi.

Évidemment ça ne règlera pas le sort des 42 zillions de softs déjà
publiés en GPL 2.

Dont un certain KERNEL DE MES DEUX. A ce propos, j'ai récemment
découvert ça http://kororaa.org/static.php?page=gpl Bizarre qu'on est
pas trollé la dessus dans fcold :-)

Je crois bien qu'on en a parlé. Comme je l'ai dit, je pense que le
meilleur moyen d'avoir des specs de la part des constructeurs c'est de
boycotter leurs matos et leurs drivers par la même occasion.
De toute façon toutes les cartes ATi actuelles ont un driver libre
fonctionnel, donc la question est pour l'instant réglée : les gentils
libristes utilisent ATi, bouuuuh les vilains nVidious.
Moi même, j'ai acheté une Ati pour remplacer ma nVidia.

Tant que j'y suis, je signale un autre sujet de troll, ma foi d'un fort
beau gabarit :
http://groups.google.com/group/linux.kernel/browse_frm/thread/41135002359b0ea3
Résumé : le 2.6.19 est une grosse merde et la façon dont la gestion
de la VM est développée/maintenue FAIT PEUR. Si j'étais IBM ou je ne
sais quel autre gros joueur, je m'attellerais à essayer de mettre un
peu d'ordre dans ce foutoir d'amateur.

Faut pas oublier que la fameuse histoire "il n'y a pas de version de dév"
est une légende. Il y a une version de dév, mais on raconte à qui veut
l'entendre qu'elle est stable :)
En pratique, depuis le 2.6.17 ça délire assez copieusement. J'ai
moi-même à regretter un incident grave :( J'ai compris la
leçon, je vais en rester au 2.6.16.34 qui lui est méchamment bétonné,
les versions ultérieures c'est juste pour jouer. En tout cas pour le
moment.

Je ne parlais pas des raisons pragmatiques qui pourraient pousser à
autoriser les drivers proprios, je parlais de la _légalité_ des
drivers proprios. Le fait est que Linus fait partie de ceux qui disent
que le détenteur d'un copyright sur le kernel peut théoriquement
interdire la distribution d'un driver non GPL.

Auquel cas il est personnellement justifié à le refuser. Maintenant dans
quelle mesure un driver est un travail dérivé de l'OS cible? Ça dépend
de l'implémentation, de la structure des headers... Est-ce qu'un driver
pour un système à micronoyau est aussi concerné? J'ai peur que la
limite soit forcément arbitraire.

Normalement, les drivers ont vocation à être dans le noyau. C'est
cette intégration qui fait 99% de la robustesse de Linux dans son
ensemble,

Bof. 99% de la robustesse c'est la qualité du code et les tests, et ces
deux points sont totogonaux avec "être dans le noyaux"

Pas tout à fait. Les drivers intégrés au noyau sont aussi intégrés
dans les tests unitaires et les validations du code. Si le noyau respecte
un certain niveau de qualité, les drivers intégrés aussi. A contrario,
un nombre incroyable de drivers proprios sont manifestement écrit avec
les pieds par des macaques sous acide, et ont sans doute beaucoup à voir
avec la piètre stabilité de certains systèmes de Redmond.

A ce propos, et toujours pour rester en charte, un développeur donne
son point de vue sur cette histoire "les drivers ont vocation à être
dans le noyau" :
http://groups.google.com/group/linux.kernel/msg/d7a42fd2e84f6ac7

Ah ça, les débats sur la façon dont on doit écrire le code... D'un
autre côté et pour les drivers que j'ai un peu suivi, c'est souvent
l'affaire d'une paire de macros et d'un script perl, de modifier le code
pour qu'il suive les guidelines du noyau.
Si le driver a un code si étranger au code du noyau qu'il est
inenvisageable de l'intégrer, on peut légitimement se poser des
questions sur la nature et la qualité du driver...

Pour la question plus générale des ABI [...]

Pour ma part je trouve que c'est bien géré et cohérent, quoi. Ça se
calmera quand ils ne sauront plus trop quoi changer ;)

Il y a manifestement une volonté délibérée de faire exprès de
casser ce qu'il faut pour compliquer la vie des mainteneurs de modules
binaires. Un jour ou l'autre, ce côté "on fait joujou avec nos
internals" ne sera plus tenable.

Il n'y a pas de transformation si terrible depuis quelques révisions. Il
y a eu une grosse réécriture au 2.6.17 qui a pété des tas de trucs qui
marchaient très bien, libres ou pas libres... Puis la VM bousillée du
2.6.19...
Par contre il y a quand même une version "stable", la 2.6.16.
Heureusement...

Nous ne parlons pas de la même chose. L'usage "créatif" du concept de
"fair use" me permet de redistribuer un assemblage contenant du GPL
alors que je n'ai pas "accepté" la licence GPL (qui n'est pas un
contrat)

Je ne vois pas bien comment on pourrait agréger un truc GPL avec un truc
autre sans avoir implicitement accepté la GPL.

Par ailleurs, je signale que le point de vue que tu résumes là n'est
manifestement pas celui de la FSF et de Linus. Si un module non GPL est
une oeuvre dérivée, sa simple distribution TOUT SEUL est déjà
illégale.

Pourquoi la FSF, Linux et autres ne font pas un barouf de tous les
diables, alors? nVidia, LSI et bien d'autres distribuent depuis des
années et des années des drivers proprios.

Et qui est autorisé à juger à quoi s'applique le copyright et à quoi
il ne s'applique pas ?
Mais si une jurisprudence "les modules sont dérivés" devait
s'établir, même la distribution sur un site séparé avec assemblage
par l'utilisateur serait menacée.

Oui, et pour l'instant on en est loin.

En fait je suis d'accord avec toi au sujet de la mauvaise foi : dans
l'hypothèse ou seule la distribution "as a whole" déclencherait la
GPL, ceux qui disent "c'est pas nous, c'est l'utilisateur qui lance un
script qui fait le café (et qui charge le module par effet de bord)" se
trouveraient en mauvaise posture. Ceci dit, ça ferait un tel bordel
dans le monde des distributions que je n'y crois pas trop. Il y a un bel
ensemble de "fermage de gueule, faites pas de vagues"

Oui, c'est bien ce que je ne comprends pas :)

--
That ideas should freely spread from one to another over the globe,
for the moral and mutual instruction of man, and the improvement of his
conditions, seems to have been peculiarly and benevolently designed by
nature, when she made them, like fire, expansible over all space,
without lessening their density in any point, and like the air in which
we breathe, move, and have our physical being, incapable of confinement
of exclusive appropriation. Inventions then cannot, in nature, be a
subject of property.
Thomas Jefferson.

Emmanuel Florac <eflorac@imaginet.fr> wrote:

Je t'ai entendu soutenir énergiquement le contraire.
En fait comme il dit plusieurs choses, je suis d'accord avec certaines (on

devrait pouvoir linker un binaire à une lib en GPL sous certaines
conditions, sans en faire un travail dérivé) mais pas avec d'autres (la

Je parlais spécifiquement de ça. On a eu une longue discussion initiée
par moi même sur ce point précisément, et la nature virale de la GPL, et
tu étais d'avis que la plus petite contamination du plus petit plugin
justifiait d'imposer au développeur l'usage de la GPL.

FSF c'st rien qu'un tas de malhonnêtes qui ont volontairement mis la
merde). Je pense que les arguments de Linus sont recevables, mais qu'il

Là je suis aussi d'accord avec toi, les gens de la FSF sont des gens
honnêtes et lucides, les gens qui soutiennent les licences BSD aussi.
Le but recherché dans les deux cas n'est pas le même. La licence GPL
cherche à garantir le maximum de droits à l'utilisateur, la licence BSD
au développeur, toutes deux dans le cadre de logiciels libres et open
source. Les laius de Stallman sur ce point sont parfaitement clairs,
explicites et lucides. Evidemment la moitié des gens n'entravent pas un
mot de ce qu'il dit simplement parcequ'ils sont bouchés à l'émeri.

fait l'impasse sur les évolutions de la FSF sur 20 ans, les difficultés

Je pense que Linus n'a aucune lucidité ni aucune vision ni sur les
licences, ni sur les points techniques de l'informatique. Si Linux
marche bien aujourd'hui ce n'est certainement pas grace à lui. C'est
essentiellement parceque des gens beaucoup plus forts que lui l'ont mis
sur la touche. Chaque fois qu'il l'ouvre c'est pour dire une connerie.
A la rigueur son seul intérêt c'est que beaucoup de gens pas très
brillants peuvent s'identifier à lui et croire qu'ils sont capables de
grandes choses. Ca attire les gogos. C'est comme la StarAc, ça fait
croire aux minables qu'ils peuvent devenir riches et célèbres.

a moins qu'il considere que se servir de la technologie
comme alibi pour faire de la politique
est un tantinet peu adapte

ou si tu preferes une histoire de couil..


c'est comme les drm cela doit etre a mon sens un choix de societe
plutot qu'une contrainte technique recuperee detournee et utilisee
pour adapter une approche politique a une contrainte temporelle


ah il y avait longtemps que je n'avais pas aligne 2 3 mots qui ne
veulent rien dire


et quant a ta vision des gogos et de la star Ac de l'informatique
je m'en remets les yeux ouverts a ton expertise

qui si je te comprends bien linux est une emanation des grandes ecoles
et du domaine universitaire

super ...

j'avais surtout cru que c'etait un hobby d'etudiant qui avait
fait boule de neige au sein de cette categorie
ô combien respectable

il n'y a que les etudiants qui sont capables de passer
plusieurs jours sur un pb a la con...

maintenant les profs sont peut etre presents dans le developpement
de linux mais il ne doit pas y en avoir beaucoup

et j'aime bien les reproches que tu fais au gogo

et au fait tu as pisse quoi comme code....


ah, j'oubliais BONNE ANNEE

REMY