Traduction de l'article de B.Perens sur le code montré par SCO

Xavier Brochard <xavier@alternatif.org> wrote:

J'ai traduit l'article de B.Perens
sur le code montré par SCO à LasVegas.
C'est la version du 20/08,
pas la nouvelle (plus intéressante)
qu'il vient de mettre en ligne (traduc en cours).

Traduction
http://www.alternatif.org/BrucePerens/SCOCopiedCodeFR.html

Version originale
http://perens.com/Articles/SCOCopiedCode.html

Nouvelle version de Bruce Perens
http://www.perens.com/SCO/SCOSlideShow.html

En fait tout le point figure dans la "Nouvelle version" et repose sur la
notion de logiciel dérivé. Exactement de la même manière que les fanatiques
de la GPL prétendent que tout logiciel qui dérive de la manière la plus ténue
d'un logiciel GPL doit être couvert par la GPL, exactement de même SCO
prétend que tout logiciel qui touche de prés ou de loin à Unix est un produit
dérivé de Unix et donc qu'ils en possèdent la propriété.

L'exemple le plus connu du problème est évidemment la librairie readline. Les
fanatiques de GPL ont prétendu que tout logiciel qui est lié à la librairie
readline doit être couvert par la GPL, même si ceci concerne une part infime
du logiciel et si celui ci peut être compilé sans faire appel à ses facilités
d'édition en ligne de commande. Le logiciel serait paraît il exclu de cet
effet viral s'il existait une deuxième implémentation des mêmes
fonctionnalités sous une autre licence que GPL (en fait il existe maintenant
une implémentation BSD, il me semble).

Bref, avec ce genre d'argumentation scandaleuse (à mon avis), il est clair
que n'importe quel logiciel développé pour tourner sous Unix, comme par
exemple les systèmes de fichiers JFS ou XFS est un produit dérivé, car au
moment où ils ont été créés, on peut prétendre qu'il ne peut avoir sa
fonctionnalité que lié au reste du système Unix (en fait c'est vaseux pour JFS
qui est dérivé de OS/2). Or IBM, SGI, etc. étaient à l'époque des licenciés
Unix et avaient donc signé une licence remettant les produits dérivés dans la
possession de SCO.

Voilà pourquoi l'argumentation de SCO est si dangereuse. Soit les juges
américains lui donnent raison, ce qui est trés peu probable, à cause des
jugements antérieurs sur l'affaire similaire entre ATT et BSDI ainsi que les
régents de l'Université de Californie, et du coup c'est l'ensemble de la
production de logiciels, libres ou pas qui est complètement menacée, soit
ils lui donnent tort, et c'est la clause virale du GPL qui se trouve largement
vidée de sa substance. Je ne doute pas que les gens qui promeuvent ce procès
en finançant SCO (c'est à dire Sun et Microsoft, qui lui ont acheté récemment
des licences Unix pour lui donner du cash) seraient fort aise de faire
reconnaître en justice que la GPL c'est du pipot. Evidemment ils se heurtent
à IBM, et le plus probable est que IBM fera traîner le procés en longueur
indéfiniment, rendra les frais de justice assez exhorbitants pour ruiner SCO
(ce qu'il a fait quand il a été attaqué par Control Data Corporation) avant
qu'aucun jugement ne soit rendu, vu qu'il a intérêt à laisser les choses dans
le flou. Sans oublier qu'il a un tel portefeuille de brevets logiciels qu'il
peut détecter des violations de ses brevêts à peu prés n'importe où, ce qu'il
a déjà commencé à faire contre SCO (voir sa réponse à SCO).

Bonnes lectures

--
Michel Talon

L'exemple le plus connu du problème est évidemment la librairie readline. Les
[...]

effet viral s'il existait une deuxième implémentation des mêmes
fonctionnalités sous une autre licence que GPL (en fait il existe maintenant
une implémentation BSD, il me semble).

Exact, libedit, depuis pas mal d'années, qui fournit une API compatible
avec celle de libreadline.

Bref, avec ce genre d'argumentation scandaleuse (à mon avis), il est clair
que n'importe quel logiciel développé pour tourner sous Unix, comme par
exemple les systèmes de fichiers JFS ou XFS est un produit dérivé, car au
moment où ils ont été créés, on peut prétendre qu'il ne peut avoir sa
fonctionnalité que lié au reste du système Unix (en fait c'est vaseux pour JFS
qui est dérivé de OS/2). Or IBM, SGI, etc. étaient à l'époque des licenciés

Je ne sais pas qui a sorti cette grosse connerie à propos du JFS, mais
tout le monde la reprend. Le JFS d'IBM a été développé pour AIX 3 au
début des années 1990, et adapté pour OS/2 à partir de OS/2 5 en 1998.

Miod Vallat <miod@online.fr> wrote:

Je ne sais pas qui a sorti cette grosse connerie à propos du JFS, mais
tout le monde la reprend. Le JFS d'IBM a été développé pour AIX 3 au
début des années 1990, et adapté pour OS/2 à partir de OS/2 5 en 1998.

Je n'en sais strictement rien, mais c'était mentionné dans les documents cités
par l'article dont on parle. Si tu as raison, et si JFS est aussi ancien, et
si on interprète la dérivation de manière extensive (comme prétend le faire
la FSF) alors effectivement JFS est dérivé de Unix et donc SCO peut prétendre
avoir un droit dessus, même s'il n'a pas écrit une seule ligne de code dedans.
Voilà qui montre bien les aberrations de cette notion de logiciel dérivé dont
les linuxiens se gargarisaient depuis des années.
Par exemple suppose que je sois trés doué et que j'écrive un super optimiseur
de la mort qui tue susceptible de marcher avec gcc. Mais que je ne veuille en
aucun cas le mettre sous licence GPL, uniquement sous BSD. Bien entendu je ne
distribue que mon propre travail, laissant à l'utilisateur final le soin de se
démerder pour le faire marcher à l'intérieur de gcc, la manip étant bien
entendu à peu prés triviale grace au bon arrangement des choses. Je peux
toujours imaginer qu'un autre compilateur, disons Tendra, serait susceptible
de servir de frontal à cet optimiseur. Donc, dérivation ou pas dérivation?
Evidemment cet exemple est choisi pour que les Stallmaniens montent aussitôt
au front en prétendant que c'est un travail dérivé puiqu'on doit
nécéssairement se servir de gcc comme frontal dans l'état actuel des choses
pour faire marcher l'optimiseur. En conséquence, il doit être sous GPL.
Et bien, c'est exactement l'argument de SCO.



--
Michel Talon

talon@lpthe.jussieu.fr wrote:

Je n'en sais strictement rien, mais c'était mentionné dans les documents cités
par l'article dont on parle. Si tu as raison, et si JFS est aussi ancien, et
si on interprète la dérivation de manière extensive (comme prétend le faire
la FSF) alors effectivement JFS est dérivé de Unix et donc SCO peut prétendre
avoir un droit dessus, même s'il n'a pas écrit une seule ligne de code dedans.
Voilà qui montre bien les aberrations de cette notion de logiciel dérivé dont
les linuxiens se gargarisaient depuis des années.

Excuse moi, mais je ne vois pas vraiment le rapport entre les logiciels
qui entrent dans le cadre de la license GPL telle qu'elle est definie et
le fait que SCO se permette de s'approprier un code qui est rendu public
depuis longtemps.

Apres, si IBM a signe un accord qui dit que tout code porte sur Unix
n'est plus sa propriete et qu'ils ont ensuite divulgue ce code sachant
que pertinement il ne leur appartenait plus, alors IBM a fait une grosse
connerie. Mais j'en doute un peu.

Mais en tout etat de cause, la regle du jeu se fixe avant et non apres
et lorsqu'une societe divulgue un code a un temps T sous une license
donnee, que cette license est Libre, elle ne peut pas revenir sur ca,
meme si cette societe a change de direction/proprietaire/politique/...
entre temps.

Par exemple suppose que je sois trés doué et que j'écrive un super optimiseur
de la mort qui tue susceptible de marcher avec gcc. Mais que je ne veuille en
aucun cas le mettre sous licence GPL, uniquement sous BSD. Bien entendu je ne
distribue que mon propre travail, laissant à l'utilisateur final le soin de se
démerder pour le faire marcher à l'intérieur de gcc, la manip étant bien
entendu à peu prés triviale grace au bon arrangement des choses. Je peux
toujours imaginer qu'un autre compilateur, disons Tendra, serait susceptible
de servir de frontal à cet optimiseur. Donc, dérivation ou pas dérivation?
Evidemment cet exemple est choisi pour que les Stallmaniens montent aussitôt
au front en prétendant que c'est un travail dérivé puiqu'on doit
nécéssairement se servir de gcc comme frontal dans l'état actuel des choses
pour faire marcher l'optimiseur. En conséquence, il doit être sous GPL.
Et bien, c'est exactement l'argument de SCO.

Je ne vois pas pourquoi ton optimisateur devrait etre sous GPL plus que
n'importe quel autre logiciel appelant un autre sous license GPL. Tout
depend du mode d'interaction entre les deux programmes, mais si tu pars
du principe que ton super optimisateur peut parler avec d'autres compilo
que Gcc, je presume que les interfaces de communications entre les deux
programmes passent par des fichiers/fifo et il me semble qu'il a
toujours ete tres clair que dans ce cas la GPL ne s'appliquait
absolument pas (d'ailleurs, si tu es malin et que tu ne veux pas que ton
optimiseur ne soit livre sous GPL, ben tu le fais parler avec gcc via
fichier ou fifo).

Il faut que ton programme appelle specifiquement une librairie GPL ou
reprenne du code GPL pour que la license s'applique. Le fait d'utiliser
un programme GPL de facon externe n'a jamais ete une raison d'appliquer
la license. D'ailleurs, il est tout a fait possible d'ecrire des
programmes utilisant la Libc et la grande majorite des librairies de
GNU (sauf la readline) sans que ces programme ne soient impactees par la
GPL tout en sachant qu'ils tourneront parfaitement sur un systeme GNU et
peut etre meme sur un systeme GNU seulement.

Tes arguments font le jeu de SCO, Microsoft et autres agressifs contre la
license GPL. Mais cette derniere n'a jamais force personne a l'utiliser,
il suffit pour cela de respecter les regles du jeu, elles sont claires
et sans surprises.


--
Stephane TOUGARD

Unix et programmation - http://www.unices.org
Stations Unix en occasions. - http://yellow.epernon.net

Stephane TOUGARD <stephane@unices.org> wrote:

talon@lpthe.jussieu.fr wrote:
absolument pas (d'ailleurs, si tu es malin et que tu ne veux pas que ton
optimiseur ne soit livre sous GPL, ben tu le fais parler avec gcc via
fichier ou fifo).

Bien j'ai pris cet exemple exprés en supposant bien sûr que l'optimiseur était
compilé par l'utilisateur final en un seul objet incluant gcc. Ce sujet a été
discuté maintes fois sur les newsgroups de discussion GNU et la conclusion
a toujours été que dans ce cas, l'optimiseur dérive de gcc, donc doit être
sous GPL.

Or regarde bien le cas de JFS ou de XFS, c'est exactement pareil, IBM
a beau avoir écrit 100% des lignes de JFS et SGI 100% des lignes de XFS,
il n'en reste pas moins que tu dois les compiler avec le reste du noyau
pour faire un programme fonctionnel qui puisse les faire marcher, donc
avec le même argument, c'est une dérivation.

Tu me dis que SCO a mis les sources de l'Unix historique dans le domaine
public, ce qui est vrai. Ca n'enlève rien au fait que quand IBM a créé
JFS, c'était un dérivé d'Unix, donc SCO a des droits dessus, et SCO n'a
pas mis JFS dans le domaine public. En poussant des arguments à la con
indéfiniment, on peut toujours justifier absolument n'importe quoi. Le point
est qu'ici, ton opinion ou la mienne n'a aucune importance, tout ce qui compte
c'est ce qu'un juge qui n'y connait rien peut décider aprés avoir écouté les
laius d'un tas d'avocats s'entendant à noyer tous les poissons, et avoir
étendu de manière plus ou moins farfelue des analogies avec des précédents
(on est aux USA). Bref, l'incertitude la plus totale plane sur la décision
finale.

Il faut que ton programme appelle specifiquement une librairie GPL ou
reprenne du code GPL pour que la license s'applique. Le fait d'utiliser
un programme GPL de facon externe n'a jamais ete une raison d'appliquer
la license. D'ailleurs, il est tout a fait possible d'ecrire des
programmes utilisant la Libc et la grande majorite des librairies de
GNU (sauf la readline) sans que ces programme ne soient impactees par la
GPL tout en sachant qu'ils tourneront parfaitement sur un systeme GNU et
peut etre meme sur un systeme GNU seulement.

Tes arguments font le jeu de SCO, Microsoft et autres agressifs contre la
license GPL. Mais cette derniere n'a jamais force personne a l'utiliser,
il suffit pour cela de respecter les regles du jeu, elles sont claires
et sans surprises.

Non elles ne sont absolument pas claires, parceque personne ne sait ce qu'est
un logiciel dérivé. Tu peux avoir une infinité de cas de figures entre le cas
où on utilise 95% du logiciel précédent et on ajoute 5% de contribution
(auquel cas intuitivement tout le monde dira qu'il y a dérivation) et le cas
opposé où 5% de saloperies GNU prétendent teinter 95% de contributions
originales (cas typique de readline) où c'est beaucoup plus vaseux, sans
parler des fichiers de headers, des API's etc. Si tu réfléchis, il n'y a pas de
moyen sensé de placer une ligne de démarcation claire entre dérivation et
non dérivation, qui ne tombe sous des critiques évidentes dans tel ou tel cas
biscornu. A partir de là cette notion est éminemment dangereuse, ne serait
ce que à cause de l'incertitude et de l'imprévisibilité qu'elle introduit.
L'action SCO contre IBM est exactement le retour de bâton auquel il fallait
s'attendre aprés le flot de conneries que la FSF et Stallmann ont déversé
sur le pauvre monde.

--
Stephane TOUGARD

Unix et programmation - http://www.unices.org
Stations Unix en occasions. - http://yellow.epernon.net

--
Michel Talon

Dans article <bi2pr9$5kg$1@rose.lpthe.jussieu.fr>, talon@lpthe.jussieu.fr
disait...

Or IBM, SGI, etc. étaient à l'époque des licenciés
Unix et avaient donc signé une licence remettant les produits dérivés dans la
possession de SCO.

Dans le cas d'IBM j'ai lu leur plainte contre SCO, et il y est dit que le
contrat original entre IBM et AT&T invalidait tout un tas de clauses
standards de la licence Unix, en particulier celle qui dit que tout code
ajouté à Unix devient propriété (plus ou moins) d'AT&T. Donc sur ce point
précis, SCO l'a dans l'os.

--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?

Dans article <bi3627$9jj$2@rose.lpthe.jussieu.fr>, talon@lpthe.jussieu.fr
disait...

videmment cet exemple est choisi pour que les Stallmaniens montent aussitôt
au front en prétendant que c'est un travail dérivé puiqu'on doit
nécéssairement se servir de gcc comme frontal dans l'état actuel des choses
pour faire marcher l'optimiseur. En conséquence, il doit être sous GPL.

Tu débloques. Il y a tout un tas de code BSD dans les softs GNU (en
particulier celui qui a servi d'exemple à SCO, les nazes) et on comprend
rien à ce que tu dis. Et puis gnu rulez, et puis RMS est très fort, et
vive la GPL, et d'ailleurs vous pouvez m'écrire à
<eflorac(at)member.fsf.org>

--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?

Dans article <bi3ceu$b29$2@rose.lpthe.jussieu.fr>, talon@lpthe.jussieu.fr
disait...

pour faire un programme fonctionnel qui puisse les faire marcher, donc
avec le même argument, c'est une dérivation.

Tu dis n'importe quoi. Si la FSF soutenait une position pareille, ça
signifierait tout simplement que tout programme compilé avec gcc serait
en GPL. La FSF n'a jamais prétendu une chose pareille, n'en a jamais
parlé et a même créé la LGPL pour permettre la cohabitation avec le code
propriétaire. Tu devrais boire frais, maintenant, ton troll se voit trop,
tu fatigues.

--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?

Stephane TOUGARD <stephane@unices.org> wrote:

Je ne vois pas pourquoi ton optimisateur devrait etre sous GPL plus que
n'importe quel autre logiciel appelant un autre sous license GPL. Tout
depend du mode d'interaction entre les deux programmes, mais si tu pars
du principe que ton super optimisateur peut parler avec d'autres compilo
que Gcc, je presume que les interfaces de communications entre les deux
programmes passent par des fichiers/fifo et il me semble qu'il a
toujours ete tres clair que dans ce cas la GPL ne s'appliquait
absolument pas

C'est faux (FAQ GPL)

"By contrast, pipes, sockets and command-line arguments are
communication mechanisms normally used between two separate programs. So
when they are used for communication, the modules normally are separate
programs. But if the semantics of the communication are intimate
enough, exchanging complex internal data structures, that too could be a
basis to consider the two parts as combined into a larger program."

Si un super-optimisateur n'est pas en train d'échanger des 'structures
de données internes complexes' avec un frontend ou un backend de
compilateur, je me demande bien ce que ça peut couvrir comme cas. Tu es
en train d'essayer de contourner la GPL, là :-)

Il faut que ton programme appelle specifiquement une librairie GPL ou
reprenne du code GPL pour que la license s'applique.

Non, la GPL ne parle jamais d'appel de librairie en tant que tel. La GPL
est notoirement floue sur ce point. Autant il est possible de
l'interpréter d'une manière qui tient à peu près debout avec un bon
vieux link statique, autant les choses deviennent délicates dans des
situations moins banales.
Ca a été justement le noeud de l'affaire RIPEM où l'auteur a été obligé
d'implémenter une lib ayant la même API que gmp (qui était sous GPL) et
sous la même license que le programme principal pour qu'il soit possible
de linker avec l'un ou l'autre. On est là très près du copyright
d'interface et c'est très dangereux.

Tes arguments font le jeu de SCO, Microsoft et autres agressifs contre la
license GPL. Mais cette derniere n'a jamais force personne a l'utiliser,
il suffit pour cela de respecter les regles du jeu, elles sont claires
et sans surprises.

Dans ce cas, j'aimerais bien trouver un document clair et précis issu de
la FSF donnant des réponses aux points suivants :

- Statut vis à vis de la GPL d'un exécutable linkant optionnellement sur
une librairie dont l'API n'est disponible à un instant donné que par une
implémentation GPL (cas de RIPEM gmp/fgpmp, readline/editline)

- Statut vis à vis de la GPL d'un exécutable utilisant une API pouvant
être invoquée -de façon transparente pour l'exécutable- soit via un
protocole distribué, soit par un link dynamique suivi des appels de
fonctions classiques (cas de certaines implémentations d'ORB)

- Statut vis à vis de la GPL d'un exécutable appellant un exécutable
externe issu d'une implémentation GPL et dont le bon fonctionnement
repose -totalement- sur la présence dudit exécutable externe (cas
d'installeurs propriétaires évitant le gnutar ou profit de pax)

(sans parler non plus de choses comme l'applicabilité de la GPL aux
langages très dynamiques ou en langages de scripts)

Et un extrait de la FAQ GPL de la FSF, là encore:

"The difference between this and "incorporating" the GPL-covered
software is partly a matter of substance and partly form. The
substantive part is this: if the two programs are combined so that they
become effectively two parts of one program, then you can't treat them
as two separate programs. So the GPL has to cover the whole thing.

If the two programs remain well separated, like the compiler and the
kernel, or like an editor and a shell, then you can treat them as two
separate programs--but you have to do it properly."

ou encore:

"What constitutes combining two parts into one program? This is a legal
question, which ultimately judges will decide. We believe that a proper
criterion depends both on the mechanism of communication (exec, pipes,
rpc, function calls within a shared address space, etc.) and the
semantics of the communication (what kinds of information are
interchanged)."

Tout le monde interprète la GPL principalement par l'angle du link
statique, parce que c'est effectivement un cas où elle est sans
ambiguïté, mais -rien- dans la GPL la cantonne à ce domaine. Je suis
complètement d'accord avec l'analyse de Michel. Relis la GPL et sa FAQ,
les choses sont loin d'être en noir et blanc.

Ol.
--
Olivier Gutknecht

In article <MPG.19af58c17a19e72f98c812@news.free.fr>, Emmanuel Florac wrote:

Dans article <bi3ceu$b29$2@rose.lpthe.jussieu.fr>, talon@lpthe.jussieu.fr
disait...

pour faire un programme fonctionnel qui puisse les faire marcher, donc
avec le même argument, c'est une dérivation.

Tu dis n'importe quoi. Si la FSF soutenait une position pareille, ça
signifierait tout simplement que tout programme compilé avec gcc serait
en GPL. La FSF n'a jamais prétendu une chose pareille, n'en a jamais
parlé et a même créé la LGPL pour permettre la cohabitation avec le code
propriétaire. Tu devrais boire frais, maintenant, ton troll se voit trop,
tu fatigues.

Tu as oublie de quoter 3 lignes au dessus, et tu as mal compris ce qu'il
a dit. Il parle de compiler ensemble les sources de JFS et du noyau,
pour donner un seul programme. Quand tu compile un programme avec gcc
tu ne combine pas les sources de gcc avec celle du programme que tu
compile, c'est different.

Dans la faq de la GPL ils disent :
"A system incorporating a GPL-covered program is an extended version of
that program. The GPL says that any extended version of the program must
be released under the GPL if it is released at all. This is for two reasons:
to make sure that users who get the software get the freedom they should
have, and to encourage people to give back improvements that they make.

However, in many cases you can distribute the GPL-covered software alongside
your proprietary system. To do this validly, you must make sure that the
free and non-free programs communicate at arms length, that they are not
combined in a way that would make them effectively a single program.

The difference between this and "incorporating" the GPL-covered software is
partly a matter of substance and partly form. The substantive part is this:
if the two programs are combined so that they become effectively two parts
of one program, then you can't treat them as two separate programs. So the
GPL has to cover the whole thing."

http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem

--
BokLM
Linux is a Weapon of Microsoft's Destruction.