Traduction de l'article de B.Perens sur le code montré par SCO
118 réponses
Xavier Brochard
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).
Tiens, on en revient au problème de la validité de la GPL en France.
Pas qu'en France, puisque à priori dans le cadre de contrats internationaux seulement trois licences sont valables.
Sam Hocevar
On Fri, 22 Aug 2003 13:50:48 +0000 (UTC), wrote:
Tu dis que le noyau Linux + JFS est dérivé de JFS, ce que personne ne contestera, évidemment. Mais en fait les gens de la FSF vont beaucoup plus loin, ils prétendraient assez aisément (tout comme SCO) que JFS tout seul, bien qu'il ait été écrit à 100% par IBM, est un produit dérivé disons de Linux (SCO dirait de Unix) sous le prétexte que à lui tout seul il ne fait rien tant qu'on ne le combine pas au reste du noyau. En tous cas ils disent certainement celà si la fonctionnalité ne peut être obtenue sans lier le code en question à du code GNU (par exemple il n'existe pas de code concurrent compatible).
C'est en effet la position de la FSF, et honnêtement je suis plutôt d'accord avec eux.
Par contre dans le reste de ton analyse tu éludes complètement le fait qu'un travail dérivé est au pire une oeuvre collective ; donc si le créateur de l'oeuvre originale peut par exemple tout à fait légiti- mement imposer des conditions à la rediffusion de l'oeuvre (ce qui est en gros le comportement FSF, en exigeant que l'oeuvre dérivée soit distribuée sous GPL si elle est distribuée), il ne peut en aucun cas s'approprier l'oeuvre dérivée dans son intégralité (ce qui serait la position de SCO, qui prétend posséder l'oeuvre dérivée). En législation française par exemple, c'est régi entre autres par les articles L-113 du CPI [1].
Il n'y a pas que SCO ou la FSF pour estimer que le link dynamique ou l'utilisation de headers est un produit dérivé. On peut noter par exemple Apple, qui a déjà profité d'une situation du genre en interdisant la réalisation d'un plugin p2p pour iTunes [2].
obligés de dire que l'argument de SCO n'est pas sans fondement, puisque l'Unix d'origine était distribué avec une clause virale analogue à celle de GPL. Mon opinion est que la clause virale est scandaleuse, et qu'elle consiste en une appropriation et un vol du travail d'autrui.
Ce n'est pas du tout une appropriation puisqu'il n'y a pas transfert de propriété (ou alors seulement dans les rêves de SCO). Après on pourra toujours contester cette viralité, il y aura probablement d'un côté ceux qui estiment que la liberté est avant tout celle du programmeur (à la BSD), et de l'autre ceux qui disent que c'est le programme qui doit rester libre (à la GPL), et on aura une énième discussion sur ce sujet éternel, chacun campera sur sa position, refusera d'admettre que pour certains bouts de code l'une ou l'autre solution a des avantages diffé- rents, et on finira par se traiter de jésuites. Ça nous manquait.
En tout cas je trouve très hypocrite de se plaindre de la viralité de la GPL en ces termes de vol. Les clauses sont écrites noir sur blanc dès le début. Si ça ne plait pas, ben on ne code pas pour cette API et on ne vient pas se plaindre 10 ans plus tard.
Tu le vois avec évidence dans l'action en justice de SCO, mais tes yeux restent fermés devant la chose exactement identique que prétend la FSF.
Ben pour résumer ma vision des choses, ce qu'on reproche à l'action de SCO est moins le fait qu'un module pour un OS soit une oeuvre déri- vée que leur interprétation selon laquelle il y aurait renonciation de droits lors de la création de l'oeuvre dérivée, et ça c'est véritable- ment du vol.
Sam. [1] http://www.celog.fr/cpi/lv1_tt1.htm#c3 [2] http://news.com.com/2100-1040-981147.html?tag=prntfr -- Sam Hocevar <http://sam.zoy.org/> free DVD and multimedia player for Linux, Unix, OS X, Windows, BeOS, etc.: VideoLAN <http://www.videolan.org/>
On Fri, 22 Aug 2003 13:50:48 +0000 (UTC), talon@lpthe.jussieu.fr wrote:
Tu dis que le noyau Linux + JFS est dérivé de JFS, ce que
personne ne contestera, évidemment. Mais en fait les gens de la FSF vont
beaucoup plus loin, ils prétendraient assez aisément (tout comme SCO) que
JFS tout seul, bien qu'il ait été écrit à 100% par IBM, est un produit dérivé
disons de Linux (SCO dirait de Unix) sous le prétexte que à lui tout seul il
ne fait rien tant qu'on ne le combine pas au reste du noyau. En tous cas ils
disent certainement celà si la fonctionnalité ne peut être obtenue sans lier
le code en question à du code GNU (par exemple il n'existe pas de code
concurrent compatible).
C'est en effet la position de la FSF, et honnêtement je suis plutôt
d'accord avec eux.
Par contre dans le reste de ton analyse tu éludes complètement le
fait qu'un travail dérivé est au pire une oeuvre collective ; donc si
le créateur de l'oeuvre originale peut par exemple tout à fait légiti-
mement imposer des conditions à la rediffusion de l'oeuvre (ce qui est
en gros le comportement FSF, en exigeant que l'oeuvre dérivée soit
distribuée sous GPL si elle est distribuée), il ne peut en aucun cas
s'approprier l'oeuvre dérivée dans son intégralité (ce qui serait la
position de SCO, qui prétend posséder l'oeuvre dérivée). En législation
française par exemple, c'est régi entre autres par les articles L-113
du CPI [1].
Il n'y a pas que SCO ou la FSF pour estimer que le link dynamique ou
l'utilisation de headers est un produit dérivé. On peut noter par exemple
Apple, qui a déjà profité d'une situation du genre en interdisant la
réalisation d'un plugin p2p pour iTunes [2].
obligés de dire que l'argument de SCO n'est pas sans fondement, puisque
l'Unix d'origine était distribué avec une clause virale analogue à celle
de GPL. Mon opinion est que la clause virale est scandaleuse, et qu'elle
consiste en une appropriation et un vol du travail d'autrui.
Ce n'est pas du tout une appropriation puisqu'il n'y a pas transfert
de propriété (ou alors seulement dans les rêves de SCO). Après on pourra
toujours contester cette viralité, il y aura probablement d'un côté ceux
qui estiment que la liberté est avant tout celle du programmeur (à la
BSD), et de l'autre ceux qui disent que c'est le programme qui doit
rester libre (à la GPL), et on aura une énième discussion sur ce sujet
éternel, chacun campera sur sa position, refusera d'admettre que pour
certains bouts de code l'une ou l'autre solution a des avantages diffé-
rents, et on finira par se traiter de jésuites. Ça nous manquait.
En tout cas je trouve très hypocrite de se plaindre de la viralité de
la GPL en ces termes de vol. Les clauses sont écrites noir sur blanc dès
le début. Si ça ne plait pas, ben on ne code pas pour cette API et on ne
vient pas se plaindre 10 ans plus tard.
Tu le vois avec évidence dans l'action en justice de SCO, mais tes
yeux restent fermés devant la chose exactement identique que prétend
la FSF.
Ben pour résumer ma vision des choses, ce qu'on reproche à l'action
de SCO est moins le fait qu'un module pour un OS soit une oeuvre déri-
vée que leur interprétation selon laquelle il y aurait renonciation de
droits lors de la création de l'oeuvre dérivée, et ça c'est véritable-
ment du vol.
Sam.
[1] http://www.celog.fr/cpi/lv1_tt1.htm#c3
[2] http://news.com.com/2100-1040-981147.html?tag=prntfr
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
free DVD and multimedia player for Linux, Unix, OS X, Windows, BeOS, etc.:
VideoLAN <http://www.videolan.org/>
Tu dis que le noyau Linux + JFS est dérivé de JFS, ce que personne ne contestera, évidemment. Mais en fait les gens de la FSF vont beaucoup plus loin, ils prétendraient assez aisément (tout comme SCO) que JFS tout seul, bien qu'il ait été écrit à 100% par IBM, est un produit dérivé disons de Linux (SCO dirait de Unix) sous le prétexte que à lui tout seul il ne fait rien tant qu'on ne le combine pas au reste du noyau. En tous cas ils disent certainement celà si la fonctionnalité ne peut être obtenue sans lier le code en question à du code GNU (par exemple il n'existe pas de code concurrent compatible).
C'est en effet la position de la FSF, et honnêtement je suis plutôt d'accord avec eux.
Par contre dans le reste de ton analyse tu éludes complètement le fait qu'un travail dérivé est au pire une oeuvre collective ; donc si le créateur de l'oeuvre originale peut par exemple tout à fait légiti- mement imposer des conditions à la rediffusion de l'oeuvre (ce qui est en gros le comportement FSF, en exigeant que l'oeuvre dérivée soit distribuée sous GPL si elle est distribuée), il ne peut en aucun cas s'approprier l'oeuvre dérivée dans son intégralité (ce qui serait la position de SCO, qui prétend posséder l'oeuvre dérivée). En législation française par exemple, c'est régi entre autres par les articles L-113 du CPI [1].
Il n'y a pas que SCO ou la FSF pour estimer que le link dynamique ou l'utilisation de headers est un produit dérivé. On peut noter par exemple Apple, qui a déjà profité d'une situation du genre en interdisant la réalisation d'un plugin p2p pour iTunes [2].
obligés de dire que l'argument de SCO n'est pas sans fondement, puisque l'Unix d'origine était distribué avec une clause virale analogue à celle de GPL. Mon opinion est que la clause virale est scandaleuse, et qu'elle consiste en une appropriation et un vol du travail d'autrui.
Ce n'est pas du tout une appropriation puisqu'il n'y a pas transfert de propriété (ou alors seulement dans les rêves de SCO). Après on pourra toujours contester cette viralité, il y aura probablement d'un côté ceux qui estiment que la liberté est avant tout celle du programmeur (à la BSD), et de l'autre ceux qui disent que c'est le programme qui doit rester libre (à la GPL), et on aura une énième discussion sur ce sujet éternel, chacun campera sur sa position, refusera d'admettre que pour certains bouts de code l'une ou l'autre solution a des avantages diffé- rents, et on finira par se traiter de jésuites. Ça nous manquait.
En tout cas je trouve très hypocrite de se plaindre de la viralité de la GPL en ces termes de vol. Les clauses sont écrites noir sur blanc dès le début. Si ça ne plait pas, ben on ne code pas pour cette API et on ne vient pas se plaindre 10 ans plus tard.
Tu le vois avec évidence dans l'action en justice de SCO, mais tes yeux restent fermés devant la chose exactement identique que prétend la FSF.
Ben pour résumer ma vision des choses, ce qu'on reproche à l'action de SCO est moins le fait qu'un module pour un OS soit une oeuvre déri- vée que leur interprétation selon laquelle il y aurait renonciation de droits lors de la création de l'oeuvre dérivée, et ça c'est véritable- ment du vol.
Sam. [1] http://www.celog.fr/cpi/lv1_tt1.htm#c3 [2] http://news.com.com/2100-1040-981147.html?tag=prntfr -- Sam Hocevar <http://sam.zoy.org/> free DVD and multimedia player for Linux, Unix, OS X, Windows, BeOS, etc.: VideoLAN <http://www.videolan.org/>
talon
Sam Hocevar <sam+ wrote:
Ben pour résumer ma vision des choses, ce qu'on reproche à l'action de SCO est moins le fait qu'un module pour un OS soit une oeuvre déri- vée que leur interprétation selon laquelle il y aurait renonciation de droits lors de la création de l'oeuvre dérivée, et ça c'est véritable- ment du vol.
Je suis à peu prés d'accord avec toi, sauf sur ce point. Si une entité (comme la FSF) peut imposer des conditions sur l'oeuvre dérivée (par exemple qu'elle soit sous GPL) c'est qu'elle s'est appropriée l'oeuvre dérivée. Seul le propriétaire est libre de disposer à sa guise des conditions de distribution de l'oeuvre. Ma position c'est que celui qui écrit le logiciel est le seul propriétaire, et donc parfaitement libre de le mettre sous la licence qu'il veut, y compris propriétaire. A partir du moment où on décide que ce logiciel séparé (je ne parle pas de l'ensemble formé par ce logiciel plus celui dont il est censé dériver) est un produit dérivé d'un autre, ce qui permet de lui imposer des contraintes, on a volé l'auteur de ses droits sur son travail. C'est exactement ce que SCO essaye de faire avec JFS et XFS.
-- Michel Talon
Sam Hocevar <sam+news@zoy.org> wrote:
Ben pour résumer ma vision des choses, ce qu'on reproche à l'action
de SCO est moins le fait qu'un module pour un OS soit une oeuvre déri-
vée que leur interprétation selon laquelle il y aurait renonciation de
droits lors de la création de l'oeuvre dérivée, et ça c'est véritable-
ment du vol.
Je suis à peu prés d'accord avec toi, sauf sur ce point. Si une entité
(comme la FSF) peut imposer des conditions sur l'oeuvre dérivée (par
exemple qu'elle soit sous GPL) c'est qu'elle s'est appropriée l'oeuvre
dérivée. Seul le propriétaire est libre de disposer à sa guise des conditions
de distribution de l'oeuvre. Ma position c'est que celui qui écrit le logiciel
est le seul propriétaire, et donc parfaitement libre de le mettre sous la
licence qu'il veut, y compris propriétaire. A partir du moment où on décide
que ce logiciel séparé (je ne parle pas de l'ensemble formé par ce logiciel
plus celui dont il est censé dériver) est un produit dérivé d'un autre, ce qui
permet de lui imposer des contraintes, on a volé l'auteur de ses droits sur
son travail. C'est exactement ce que SCO essaye de faire avec JFS et XFS.
Ben pour résumer ma vision des choses, ce qu'on reproche à l'action de SCO est moins le fait qu'un module pour un OS soit une oeuvre déri- vée que leur interprétation selon laquelle il y aurait renonciation de droits lors de la création de l'oeuvre dérivée, et ça c'est véritable- ment du vol.
Je suis à peu prés d'accord avec toi, sauf sur ce point. Si une entité (comme la FSF) peut imposer des conditions sur l'oeuvre dérivée (par exemple qu'elle soit sous GPL) c'est qu'elle s'est appropriée l'oeuvre dérivée. Seul le propriétaire est libre de disposer à sa guise des conditions de distribution de l'oeuvre. Ma position c'est que celui qui écrit le logiciel est le seul propriétaire, et donc parfaitement libre de le mettre sous la licence qu'il veut, y compris propriétaire. A partir du moment où on décide que ce logiciel séparé (je ne parle pas de l'ensemble formé par ce logiciel plus celui dont il est censé dériver) est un produit dérivé d'un autre, ce qui permet de lui imposer des contraintes, on a volé l'auteur de ses droits sur son travail. C'est exactement ce que SCO essaye de faire avec JFS et XFS.
-- Michel Talon
Stephane TOUGARD
Shmurtz wrote:
http://www.linuxfrench.net/article.php?id_article43 Tiens, on en revient au problème de la validité de la GPL en France.
Pas qu'en France, puisque à priori dans le cadre de contrats
internationaux seulement trois licences sont valables.
Rien que le fait que la GPL ne soit qu'en anglais a toujours ete suffisant pour l'invalider dans de nombreux pays, dont la France. Ce n'est pas un secret et on n'a pas attendu cet article pour le savoir.
Idem pour les problemes de garantie, ou d'autres articles, comme si il etait possible de monter une license aussi complexe valable avec toutes les lois de tous les pays du monde. Le grand tord de la FSF est de ne jamais avoir accepte une regionalisation de ses licenses et de tomber dans de l'americanisme primaire en pensant que :
- tout le monde parle l'anglais (l'americain), - tout le monde est sous le coup des lois americaines, - tout le monde est americain.
C'est quand meme con d'avoir des representants en Europe et meme en France et de ne pas avoir une license pour les defendre qui soit Europeene et meme Francaise.
Mais entre nous, les cons dans l'affaire, c'est pas la FSF dont le siege est en Amerique et dont on peut comprendre l'Americanisme primaire. Les cons c'est nous de ne pas avoir su monter une license Francaise en proposant a tous les auteurs a travers le monde que leur logiciels prennent automatiquement sous cette double license lorsqu'ils sont distribues sur notre territoire et que celle ci soit automatiquement appliquee si la GPL est invalidee par une loi locale.
Nous pouvons appliquer 10 licenses a un code si tel est le desir de l'auteur, il ne parait pas dur de realiser autant de licenses qu'il y a de pays. Allez, si quelqu'un a des connaissances en droit et veut bien participer, je veux bien m'y mettre aussi. Il nous faut du monde pour rentrer en contact avec les auteurs pour leur proposer le mecanisme de la double license.
Allez les beaux parleurs, il y en a qui veulent participer ?
-- Stephane TOUGARD
Unix et programmation - http://www.unices.org Stations Unix en occasions. - http://yellow.epernon.net
Shmurtz wrote:
http://www.linuxfrench.net/article.php?id_article43
Tiens, on en revient au problème de la validité de la GPL en France.
Pas qu'en France, puisque à priori dans le cadre de contrats
internationaux seulement trois licences sont valables.
Rien que le fait que la GPL ne soit qu'en anglais a toujours ete
suffisant pour l'invalider dans de nombreux pays, dont la France. Ce
n'est pas un secret et on n'a pas attendu cet article pour le savoir.
Idem pour les problemes de garantie, ou d'autres articles, comme si il
etait possible de monter une license aussi complexe valable avec toutes
les lois de tous les pays du monde. Le grand tord de la FSF est de ne
jamais avoir accepte une regionalisation de ses licenses et de tomber
dans de l'americanisme primaire en pensant que :
- tout le monde parle l'anglais (l'americain),
- tout le monde est sous le coup des lois americaines,
- tout le monde est americain.
C'est quand meme con d'avoir des representants en Europe et meme en
France et de ne pas avoir une license pour les defendre qui soit
Europeene et meme Francaise.
Mais entre nous, les cons dans l'affaire, c'est pas la FSF dont le siege
est en Amerique et dont on peut comprendre l'Americanisme primaire. Les
cons c'est nous de ne pas avoir su monter une license Francaise en
proposant a tous les auteurs a travers le monde que leur logiciels
prennent automatiquement sous cette double license lorsqu'ils sont
distribues sur notre territoire et que celle ci soit automatiquement
appliquee si la GPL est invalidee par une loi locale.
Nous pouvons appliquer 10 licenses a un code si tel est le desir de
l'auteur, il ne parait pas dur de realiser autant de licenses qu'il y a
de pays. Allez, si quelqu'un a des connaissances en droit et veut bien
participer, je veux bien m'y mettre aussi. Il nous faut du monde pour
rentrer en contact avec les auteurs pour leur proposer le mecanisme de
la double license.
Allez les beaux parleurs, il y en a qui veulent participer ?
--
Stephane TOUGARD
Unix et programmation - http://www.unices.org
Stations Unix en occasions. - http://yellow.epernon.net
http://www.linuxfrench.net/article.php?id_article43 Tiens, on en revient au problème de la validité de la GPL en France.
Pas qu'en France, puisque à priori dans le cadre de contrats
internationaux seulement trois licences sont valables.
Rien que le fait que la GPL ne soit qu'en anglais a toujours ete suffisant pour l'invalider dans de nombreux pays, dont la France. Ce n'est pas un secret et on n'a pas attendu cet article pour le savoir.
Idem pour les problemes de garantie, ou d'autres articles, comme si il etait possible de monter une license aussi complexe valable avec toutes les lois de tous les pays du monde. Le grand tord de la FSF est de ne jamais avoir accepte une regionalisation de ses licenses et de tomber dans de l'americanisme primaire en pensant que :
- tout le monde parle l'anglais (l'americain), - tout le monde est sous le coup des lois americaines, - tout le monde est americain.
C'est quand meme con d'avoir des representants en Europe et meme en France et de ne pas avoir une license pour les defendre qui soit Europeene et meme Francaise.
Mais entre nous, les cons dans l'affaire, c'est pas la FSF dont le siege est en Amerique et dont on peut comprendre l'Americanisme primaire. Les cons c'est nous de ne pas avoir su monter une license Francaise en proposant a tous les auteurs a travers le monde que leur logiciels prennent automatiquement sous cette double license lorsqu'ils sont distribues sur notre territoire et que celle ci soit automatiquement appliquee si la GPL est invalidee par une loi locale.
Nous pouvons appliquer 10 licenses a un code si tel est le desir de l'auteur, il ne parait pas dur de realiser autant de licenses qu'il y a de pays. Allez, si quelqu'un a des connaissances en droit et veut bien participer, je veux bien m'y mettre aussi. Il nous faut du monde pour rentrer en contact avec les auteurs pour leur proposer le mecanisme de la double license.
Allez les beaux parleurs, il y en a qui veulent participer ?
-- Stephane TOUGARD
Unix et programmation - http://www.unices.org Stations Unix en occasions. - http://yellow.epernon.net
BokLM
In article <bi75tk$qkj$, wrote:
Je suis à peu prés d'accord avec toi, sauf sur ce point. Si une entité (comme la FSF) peut imposer des conditions sur l'oeuvre dérivée (par exemple qu'elle soit sous GPL) c'est qu'elle s'est appropriée l'oeuvre dérivée. Seul le propriétaire est libre de disposer à sa guise des conditions de distribution de l'oeuvre. Ma position c'est que celui qui écrit le logiciel est le seul propriétaire, et donc parfaitement libre de le mettre sous la licence qu'il veut, y compris propriétaire. A partir du moment où on décide que ce logiciel séparé (je ne parle pas de l'ensemble formé par ce logiciel plus celui dont il est censé dériver) est un produit dérivé d'un autre, ce qui permet de lui imposer des contraintes, on a volé l'auteur de ses droits sur son travail. C'est exactement ce que SCO essaye de faire avec JFS et XFS.
Pas du tout, l'auteur garde tous les droits sur son code, et peux si il le veux le reutiliser dans un logiciel proprietaire par exemple. On ne lui vole pas ses droits, on lui demande juste de laisser quelques droits sur son code aux utilisateurs du logiciel en GPL.
-- BokLM Linux is a Weapon of Microsoft's Destruction.
In article <bi75tk$qkj$1@rose.lpthe.jussieu.fr>, talon@lpthe.jussieu.fr wrote:
Je suis à peu prés d'accord avec toi, sauf sur ce point. Si une entité
(comme la FSF) peut imposer des conditions sur l'oeuvre dérivée (par
exemple qu'elle soit sous GPL) c'est qu'elle s'est appropriée l'oeuvre
dérivée. Seul le propriétaire est libre de disposer à sa guise des conditions
de distribution de l'oeuvre. Ma position c'est que celui qui écrit le logiciel
est le seul propriétaire, et donc parfaitement libre de le mettre sous la
licence qu'il veut, y compris propriétaire. A partir du moment où on décide
que ce logiciel séparé (je ne parle pas de l'ensemble formé par ce logiciel
plus celui dont il est censé dériver) est un produit dérivé d'un autre, ce qui
permet de lui imposer des contraintes, on a volé l'auteur de ses droits sur
son travail. C'est exactement ce que SCO essaye de faire avec JFS et XFS.
Pas du tout, l'auteur garde tous les droits sur son code, et peux si il le
veux le reutiliser dans un logiciel proprietaire par exemple. On ne lui
vole pas ses droits, on lui demande juste de laisser quelques droits sur
son code aux utilisateurs du logiciel en GPL.
--
BokLM
Linux is a Weapon of Microsoft's Destruction.
Je suis à peu prés d'accord avec toi, sauf sur ce point. Si une entité (comme la FSF) peut imposer des conditions sur l'oeuvre dérivée (par exemple qu'elle soit sous GPL) c'est qu'elle s'est appropriée l'oeuvre dérivée. Seul le propriétaire est libre de disposer à sa guise des conditions de distribution de l'oeuvre. Ma position c'est que celui qui écrit le logiciel est le seul propriétaire, et donc parfaitement libre de le mettre sous la licence qu'il veut, y compris propriétaire. A partir du moment où on décide que ce logiciel séparé (je ne parle pas de l'ensemble formé par ce logiciel plus celui dont il est censé dériver) est un produit dérivé d'un autre, ce qui permet de lui imposer des contraintes, on a volé l'auteur de ses droits sur son travail. C'est exactement ce que SCO essaye de faire avec JFS et XFS.
Pas du tout, l'auteur garde tous les droits sur son code, et peux si il le veux le reutiliser dans un logiciel proprietaire par exemple. On ne lui vole pas ses droits, on lui demande juste de laisser quelques droits sur son code aux utilisateurs du logiciel en GPL.
-- BokLM Linux is a Weapon of Microsoft's Destruction.
Emmanuel Florac
Dans article , disait...
Allez les beaux parleurs, il y en a qui veulent participer ?
Je suis entièrement d'accord mais je ne connais que pouic au droit...
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <slrnbke706.h66.stephane@goliath.kirch>, stephane@unices.org
disait...
Allez les beaux parleurs, il y en a qui veulent participer ?
Je suis entièrement d'accord mais je ne connais que pouic au droit...
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Allez les beaux parleurs, il y en a qui veulent participer ? Je suis entièrement d'accord mais je ne connais que pouic au droit...
Je pense que pour commencer, il faudrait deja partir d'une traduction de la GPL et de toutes les FAC associees.
-- Stephane TOUGARD
Unix et programmation - http://www.unices.org Stations Unix en occasions. - http://yellow.epernon.net
Stephane TOUGARD
wrote:
licence qu'il veut, y compris propriétaire. A partir du moment où on décide que ce logiciel séparé (je ne parle pas de l'ensemble formé par ce logiciel plus celui dont il est censé dériver) est un produit dérivé d'un autre, ce qui permet de lui imposer des contraintes, on a volé l'auteur de ses droits sur son travail. C'est exactement ce que SCO essaye de faire avec JFS et XFS.
Euh, la notion de derivation pour la GPL est quand meme plus claire que tu sembles le sous entendre et elle est sans surprise.
-- Stephane TOUGARD
Unix et programmation - http://www.unices.org Stations Unix en occasions. - http://yellow.epernon.net
talon@lpthe.jussieu.fr wrote:
licence qu'il veut, y compris propriétaire. A partir du moment où on décide
que ce logiciel séparé (je ne parle pas de l'ensemble formé par ce logiciel
plus celui dont il est censé dériver) est un produit dérivé d'un autre, ce qui
permet de lui imposer des contraintes, on a volé l'auteur de ses droits sur
son travail. C'est exactement ce que SCO essaye de faire avec JFS et XFS.
Euh, la notion de derivation pour la GPL est quand meme plus claire que
tu sembles le sous entendre et elle est sans surprise.
--
Stephane TOUGARD
Unix et programmation - http://www.unices.org
Stations Unix en occasions. - http://yellow.epernon.net
licence qu'il veut, y compris propriétaire. A partir du moment où on décide que ce logiciel séparé (je ne parle pas de l'ensemble formé par ce logiciel plus celui dont il est censé dériver) est un produit dérivé d'un autre, ce qui permet de lui imposer des contraintes, on a volé l'auteur de ses droits sur son travail. C'est exactement ce que SCO essaye de faire avec JFS et XFS.
Euh, la notion de derivation pour la GPL est quand meme plus claire que tu sembles le sous entendre et elle est sans surprise.
-- Stephane TOUGARD
Unix et programmation - http://www.unices.org Stations Unix en occasions. - http://yellow.epernon.net
Richard Delorme
Emmanuel Florac wrote:
Allez les beaux parleurs, il y en a qui veulent participer ? Je suis entièrement d'accord mais je ne connais que pouic au droit...
Je pense que pour commencer, il faudrait deja partir d'une traduction de la GPL et de toutes les FAC associees.
A priori, c'est en cours : http://fsffrance.org/gpl/gpl.fr.html
-- Richard
Emmanuel Florac wrote:
Allez les beaux parleurs, il y en a qui veulent participer ?
Je suis entièrement d'accord mais je ne connais que pouic au droit...
Je pense que pour commencer, il faudrait deja partir d'une traduction de
la GPL et de toutes les FAC associees.
A priori, c'est en cours :
http://fsffrance.org/gpl/gpl.fr.html
Allez les beaux parleurs, il y en a qui veulent participer ? Je suis entièrement d'accord mais je ne connais que pouic au droit...
Je pense que pour commencer, il faudrait deja partir d'une traduction de la GPL et de toutes les FAC associees.
A priori, c'est en cours : http://fsffrance.org/gpl/gpl.fr.html
-- Richard
Manuel Leclerc
[...] A partir du moment où on décide que ce logiciel séparé (je ne parle pas de l'ensemble formé par ce logiciel plus celui dont il est censé dériver) est un produit dérivé d'un autre, ce qui permet de lui imposer des contraintes, on a volé l'auteur de ses droits sur son travail. C'est exactement ce que SCO essaye de faire avec JFS et XFS.
Pas du tout, l'auteur garde tous les droits sur son code, et peux si il le veux le reutiliser dans un logiciel proprietaire par exemple. On ne lui vole pas ses droits, on lui demande juste de laisser quelques droits sur son code aux utilisateurs du logiciel en GPL.
Droit qui rendent concrètement impossible la vente de la version proprio.
manuel leclerc
[...] A partir du moment où on décide que ce logiciel
séparé (je ne parle pas de l'ensemble formé par ce
logiciel plus celui dont il est censé dériver) est un
produit dérivé d'un autre, ce qui permet de lui imposer
des contraintes, on a volé l'auteur de ses droits sur
son travail. C'est exactement ce que SCO essaye de faire
avec JFS et XFS.
Pas du tout, l'auteur garde tous les droits sur son code,
et peux si il le veux le reutiliser dans un logiciel
proprietaire par exemple. On ne lui vole pas ses droits,
on lui demande juste de laisser quelques droits sur son
code aux utilisateurs du logiciel en GPL.
Droit qui rendent concrètement impossible la vente de la
version proprio.
[...] A partir du moment où on décide que ce logiciel séparé (je ne parle pas de l'ensemble formé par ce logiciel plus celui dont il est censé dériver) est un produit dérivé d'un autre, ce qui permet de lui imposer des contraintes, on a volé l'auteur de ses droits sur son travail. C'est exactement ce que SCO essaye de faire avec JFS et XFS.
Pas du tout, l'auteur garde tous les droits sur son code, et peux si il le veux le reutiliser dans un logiciel proprietaire par exemple. On ne lui vole pas ses droits, on lui demande juste de laisser quelques droits sur son code aux utilisateurs du logiciel en GPL.
Droit qui rendent concrètement impossible la vente de la version proprio.
