Pour ceux que ça intéresse, il y a en ce moment plusieurs débats
dans debian-legal et linux.kernel sur la notion d'oeuvres dérivée,
toussa. J'y ai lu des arguments assez forts, je trouve (mais JNSPA),
comme quoi l'effet copyleft est, au moins en partie, une foutaise
juridique (je parle du cas d'un programme utilisant une bibliothèque
GPL).
Exemple tiré de debian-legal:
http://lists.debian.org/debian-legal/2004/06/msg00376.html
<quote>
To quote Title 17 Sec. 101:
A ''derivative work'' is a work based upon one or more preexisting
works, such as a translation, musical arrangement, dramatization,
fictionalization, motion picture version, sound recording, art
reproduction, abridgment, condensation, or any other form in which a
work may be recast, transformed, or adapted. A work consisting of
editorial revisions, annotations, elaborations, or other
modifications which, as a whole, represent an original work of
authorship, is a ''derivative work''
[...]
A ''compilation'' is a work formed by the collection and assembling
of preexisting materials or of data that are selected, coordinated,
or arranged in such a way that the resulting work as a whole
constitutes an original work of authorship. The term ''compilation''
includes collective works.
</quote>
Si j'utilise une bibliothèque, sans en changer une seule ligne,
j'ai l'impression d'être dans le cas "compilation", et non
oeuvre dérivée. Or la GPL dit :
http://www.gnu.org/licenses/gpl.txt
<quote>
The "Program", below, refers to any such program or work, and a
"work based on the Program" means either the Program or any
derivative work under copyright law: that is to say, a work
containing the Program or a portion of it, either verbatim or
with modifications and/or translated into anotherlanguage.
(Hereinafter, translation is included without limitation in
the term "modification".)
</quote>
On dirait qu'il y une sorte de problème avec le bout de
phrase "any derivative work under copyright law" et le
bout de phrase "that is to say, a work containing the
Program".
J'ai aussi trouvé :
http://lists.debian.org/debian-legal/2004/06/msg00379.html
<quote>
http://digital-law-online.info/lpdi1.0/treatise6.html discusses the
differences between derivative works and compilations, and quotes a
congressional report that elaborates:
Between them the terms "compilations" and "derivative works" which
are defined in section 101, comprehend every copyrightable work that
employs preexisting material or data of any kind. There is
necessarily some overlapping between the two, but they basically
represent different concepts. A "compilation" results from a process
of selecting, bringing together, organizing, and arranging
previously existing material of all kinds, regardless of whether the
individual items in the material have been or ever could have been
subject to copyright. A "derivative work," on the other hand,
requires a process of recasting, transforming, or adapting "one or
more preexisting works"; the "preexisting work" must come within the
general subject matter of copyright set forth in section 102,
regardless of whether it is or was ever copyrighted. {FN31:
H.R. Rep. No. 94-1476 at 57}
See also http://www.copyright.gov/circs/circ14.html, which remarks
both that the whole of the derivative work must represent an original
work of authorship, rather than an arrangement of distinct works, and
that mechanical (non-creative, ergo non-copyrightable) transformation
of the original does not make a derivative.
<quote>
Finalement, je suis tombe sur ça :
http://www.rosenlaw.com/html/GL18.pdf
Pour conclure : le législateur (américain ?), dans sa grande
sagesse, a su préserver les libertés individuelles et l'intérêt
collectif, même si ce n'est pas toujours agréable pour certains
auteurs.
Mon avis : un auteur qui distribue une bibliothèque sous GPL
ne peut pas m'empècher de redistribuer son oeuvre _inchangée_
en tant que composant d'une de mes oeuvres.
Plus sérieusement, la question, au fond, est "qu'est ce qu'un
auteur a le droit d'écrire dans une licence ?" Le rédacteur
de la GPL a-t-il le droit de dire "cette licence SIGNIFIE que
vous DEVEZ mettre votre programme sous GPL si vous utiliser
readline, quelque soit ce que peut dire la loi sur le copyright ?
--
I'll have to insist that you stop using readline unless
you make the program free.
--Richard Stallman
"Manuel Leclerc" , dans le message <40d2e4fd$, a écrit :
J'avais oublié que tu avais cette position un peu étrange.
Ma position n'a rien d'étrange, elle s'appuie sur deux points très simples :
- le binaire produit par un programme contenant des #include comporte du code venant de ces headers ;
A ceci prés qu'il a été jugé dans le procés entre ATT et l'université de Berkeley que le simple fait d'utiliser des headers n'était pas en soi constitutif de violation de copyright, que c'était du "fair use". Tu remarqueras que SCO a ressorti la même chose contre Linux, et a été débouté quasi immédiatement. Il suffit de toute façon de réécrire le header, comme Linus a dit l'avoir fait, quitte à reprendre exactement la même chose puisqu'il n'y a pas moyen de faire autrement pour assurer l'interopérabilité.
--
Michel TALON
Nicolas George <george@clipper.ens.fr> wrote:
"Manuel Leclerc" , dans le message <40d2e4fd$1@neottia.net>, a écrit :
J'avais oublié que tu avais cette position un peu étrange.
Ma position n'a rien d'étrange, elle s'appuie sur deux points très
simples :
- le binaire produit par un programme contenant des #include comporte du
code venant de ces headers ;
A ceci prés qu'il a été jugé dans le procés entre ATT et l'université de
Berkeley que le simple fait d'utiliser des headers n'était pas en soi
constitutif de violation de copyright, que c'était du "fair use".
Tu remarqueras que SCO a ressorti la même chose contre Linux, et a été
débouté quasi immédiatement. Il suffit de toute façon de réécrire le
header, comme Linus a dit l'avoir fait, quitte à reprendre exactement la
même chose puisqu'il n'y a pas moyen de faire autrement pour assurer
l'interopérabilité.
"Manuel Leclerc" , dans le message <40d2e4fd$, a écrit :
J'avais oublié que tu avais cette position un peu étrange.
Ma position n'a rien d'étrange, elle s'appuie sur deux points très simples :
- le binaire produit par un programme contenant des #include comporte du code venant de ces headers ;
A ceci prés qu'il a été jugé dans le procés entre ATT et l'université de Berkeley que le simple fait d'utiliser des headers n'était pas en soi constitutif de violation de copyright, que c'était du "fair use". Tu remarqueras que SCO a ressorti la même chose contre Linux, et a été débouté quasi immédiatement. Il suffit de toute façon de réécrire le header, comme Linus a dit l'avoir fait, quitte à reprendre exactement la même chose puisqu'il n'y a pas moyen de faire autrement pour assurer l'interopérabilité.
--
Michel TALON
talon
Hubert Figuiere wrote:
La FSF a toujours dit trés clairement qu'elle n'était pas d'accord avec cette position telle que décrite par L. Rosen, et que pour elle, lier une librairie sous GPL (telle que readline) que ce soit de façon statique ou dynamique constituait une dérivation. Il est fort possible qu'elle ait soutenu cette position sans aucune base juridique.
La FSF soutient la position de RMS qui est comme telle. Pour le reste, c'est dans un tribunal que ca peut se régler.
Oui, mais la position prise par un tribunal d'un pays ne lie pas du tout un tribunal d'un autre pays, donc autant dire que c'est un problème insoluble si les gens ne parviennent pas à un consensus raisonnable.
Hub
--
Michel TALON
Hubert Figuiere <hub@free.fr> wrote:
La FSF a toujours dit trés clairement qu'elle n'était pas d'accord avec
cette position telle que décrite par L. Rosen, et que pour elle, lier
une librairie sous GPL (telle que readline) que ce soit de façon
statique ou dynamique constituait une dérivation. Il est fort possible
qu'elle ait soutenu cette position sans aucune base juridique.
La FSF soutient la position de RMS qui est comme telle. Pour le reste,
c'est dans un tribunal que ca peut se régler.
Oui, mais la position prise par un tribunal d'un pays ne lie pas du tout
un tribunal d'un autre pays, donc autant dire que c'est un problème
insoluble si les gens ne parviennent pas à un consensus raisonnable.
La FSF a toujours dit trés clairement qu'elle n'était pas d'accord avec cette position telle que décrite par L. Rosen, et que pour elle, lier une librairie sous GPL (telle que readline) que ce soit de façon statique ou dynamique constituait une dérivation. Il est fort possible qu'elle ait soutenu cette position sans aucune base juridique.
La FSF soutient la position de RMS qui est comme telle. Pour le reste, c'est dans un tribunal que ca peut se régler.
Oui, mais la position prise par un tribunal d'un pays ne lie pas du tout un tribunal d'un autre pays, donc autant dire que c'est un problème insoluble si les gens ne parviennent pas à un consensus raisonnable.
Hub
--
Michel TALON
Manuel Leclerc
J'avais oublié que tu avais cette position un peu étrange.
Ma position n'a rien d'étrange, elle s'appuie sur deux points très simples :
- le binaire produit par un programme contenant des #include comporte du code venant de ces headers ;
- pour distribuer ce code, il faut l'autorisation explicite du titulaire du copyright sur ces headers.
Le binaire est une suite de transformations mécaniques des sources suivi d'une agrégation. Que ce processus consiste à CREER une oeuvre dérivée se discute. Il n'y a pas de modification/adaptation de l'oeuvre d'origine (sous GPL). Cette même oeuvre d'origine m'a été distribué AVEC l'autorisation explicite de re-distribution sans modification.
Il me semble que les distinctions entre link statiques ou dynamiques sont inutiles pour déterminer qu'une oeuvre est dérivée ou bien que c'est une oeuvre constituée de deux oeuvres indépendantes. Je veux dire que la réponse devrait être la même dans les deux cas. L'auteur d'une bibliothèque doit s'attendre à ce que sa bibliothèque soit utilisée. S'il autorise copie/distribution de version non modifiée, alors je ne vois pas au nom de quoi il devrait avoir un droit de regard sur un programme appelant la version non modifiée de sa bibliothèque. Existe-t-il un texte du droit français qui définit les différences entre oeuvre dérivée, anthologie, agrégation etc. ? Et la jurisprudence ?
En termes de « derivative work », le code source n'en est pas, mais le binaire en est un : il y a bien eu traduction (dans le compilateur) du matériel copyrighté par un tiers pour produire le binaire résultant.
Cette simple traduction/agrégation est-elle suffisante pour parler d'oeuvre dérivée ?
Je trouve les deux pages de Lawrence Rosen, sobrement intitulé "Derivative Works" nettement plus logiques.
Ça me semble en grande partie du wishful thinking.
Ce n'est pas l'impression que j'ai eue en le lisant.
-- I have systematically eliminated all references to "software", because some people disagree about what it means. --Andrew Suffield
J'avais oublié que tu avais cette position un peu étrange.
Ma position n'a rien d'étrange, elle s'appuie sur deux points
très simples :
- le binaire produit par un programme contenant des #include
comporte du code venant de ces headers ;
- pour distribuer ce code, il faut l'autorisation explicite
du titulaire du copyright sur ces headers.
Le binaire est une suite de transformations mécaniques des
sources suivi d'une agrégation. Que ce processus consiste
à CREER une oeuvre dérivée se discute. Il n'y a pas de
modification/adaptation de l'oeuvre d'origine (sous GPL).
Cette même oeuvre d'origine m'a été distribué AVEC
l'autorisation explicite de re-distribution sans modification.
Il me semble que les distinctions entre link statiques ou
dynamiques sont inutiles pour déterminer qu'une oeuvre est
dérivée ou bien que c'est une oeuvre constituée de deux
oeuvres indépendantes. Je veux dire que la réponse devrait
être la même dans les deux cas. L'auteur d'une bibliothèque
doit s'attendre à ce que sa bibliothèque soit utilisée. S'il
autorise copie/distribution de version non modifiée, alors
je ne vois pas au nom de quoi il devrait avoir un droit de
regard sur un programme appelant la version non modifiée
de sa bibliothèque. Existe-t-il un texte du droit français
qui définit les différences entre oeuvre dérivée, anthologie,
agrégation etc. ? Et la jurisprudence ?
En termes de « derivative work », le code source n'en est
pas, mais le binaire en est un : il y a bien eu traduction
(dans le compilateur) du matériel copyrighté par un tiers
pour produire le binaire résultant.
Cette simple traduction/agrégation est-elle suffisante pour
parler d'oeuvre dérivée ?
Je trouve les deux pages de Lawrence Rosen, sobrement
intitulé "Derivative Works" nettement plus logiques.
Ça me semble en grande partie du wishful thinking.
Ce n'est pas l'impression que j'ai eue en le lisant.
--
I have systematically eliminated all references to "software",
because some people disagree about what it means.
--Andrew Suffield
J'avais oublié que tu avais cette position un peu étrange.
Ma position n'a rien d'étrange, elle s'appuie sur deux points très simples :
- le binaire produit par un programme contenant des #include comporte du code venant de ces headers ;
- pour distribuer ce code, il faut l'autorisation explicite du titulaire du copyright sur ces headers.
Le binaire est une suite de transformations mécaniques des sources suivi d'une agrégation. Que ce processus consiste à CREER une oeuvre dérivée se discute. Il n'y a pas de modification/adaptation de l'oeuvre d'origine (sous GPL). Cette même oeuvre d'origine m'a été distribué AVEC l'autorisation explicite de re-distribution sans modification.
Il me semble que les distinctions entre link statiques ou dynamiques sont inutiles pour déterminer qu'une oeuvre est dérivée ou bien que c'est une oeuvre constituée de deux oeuvres indépendantes. Je veux dire que la réponse devrait être la même dans les deux cas. L'auteur d'une bibliothèque doit s'attendre à ce que sa bibliothèque soit utilisée. S'il autorise copie/distribution de version non modifiée, alors je ne vois pas au nom de quoi il devrait avoir un droit de regard sur un programme appelant la version non modifiée de sa bibliothèque. Existe-t-il un texte du droit français qui définit les différences entre oeuvre dérivée, anthologie, agrégation etc. ? Et la jurisprudence ?
En termes de « derivative work », le code source n'en est pas, mais le binaire en est un : il y a bien eu traduction (dans le compilateur) du matériel copyrighté par un tiers pour produire le binaire résultant.
Cette simple traduction/agrégation est-elle suffisante pour parler d'oeuvre dérivée ?
Je trouve les deux pages de Lawrence Rosen, sobrement intitulé "Derivative Works" nettement plus logiques.
Ça me semble en grande partie du wishful thinking.
Ce n'est pas l'impression que j'ai eue en le lisant.
-- I have systematically eliminated all references to "software", because some people disagree about what it means. --Andrew Suffield
ol.g+news
Nicolas George wrote:
Michel Talon, dans le message <caulkh$1i15$,
Argument qui n'a pas de force aussi probante que tu crois, car on peut trés bien distribuer un binaire du programme en question, sans la librairie GPL. A l'exécution, le programme charge la dite librairie, mais à aucun moment l'auteur du logiciel "dérivé" n'a distribué une oeuvre contenant en tant que telle un morceau sous GPL.
Ça dépend comment c'est programmé. Si le code source fait un #include <machin.h>, alors le code produit comporte bien des petits bouts de la bibliothèque. Si tout est fait avec des dlopen, alors il n'y a rien à redire.
Ce qui n'est pas du tout l'opinion de la FSF. La phrase clé est sans doute "if the semantics of the communication are intimate enough, exchanging complex internal data structures".
<http://www.gnu.org/licenses/gpl-faq.html>
"What is the difference between "mere aggregation" and "combining two modules into one program"?
Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program.
Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL--if you can't, or won't, do that, you may not combine them.
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).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
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."
Et d'ailleurs si la dépendance est là simplement à cause d'un include machin, on est carrément dans le copyright d'interface.
Ol. -- Olivier Gutknecht
Nicolas George <george@clipper.ens.fr> wrote:
Michel Talon, dans le message <caulkh$1i15$2@asmodee.lpthe.jussieu.fr>,
Argument qui n'a pas de force aussi probante que tu crois, car on peut
trés bien distribuer un binaire du programme en question, sans la
librairie GPL. A l'exécution, le programme charge la dite librairie,
mais à aucun moment l'auteur du logiciel "dérivé" n'a distribué une
oeuvre contenant en tant que telle un morceau sous GPL.
Ça dépend comment c'est programmé. Si le code source fait un
#include <machin.h>, alors le code produit comporte bien des petits
bouts de la bibliothèque. Si tout est fait avec des dlopen, alors il n'y
a rien à redire.
Ce qui n'est pas du tout l'opinion de la FSF. La phrase clé est sans
doute "if the semantics of the communication are intimate enough,
exchanging complex internal data structures".
<http://www.gnu.org/licenses/gpl-faq.html>
"What is the difference between "mere aggregation" and "combining two
modules into one program"?
Mere aggregation of two programs means putting them side by side on the
same CD-ROM or hard disk. We use this term in the case where they are
separate programs, not parts of a single program. In this case, if one
of the programs is covered by the GPL, it has no effect on the other
program.
Combining two modules means connecting them together so that they form
a single larger program. If either part is covered by the GPL, the whole
combination must also be released under the GPL--if you can't, or won't,
do that, you may not combine them.
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).
If the modules are included in the same executable file, they are
definitely combined in one program. If modules are designed to run
linked together in a shared address space, that almost surely means
combining them into one program.
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."
Et d'ailleurs si la dépendance est là simplement à cause d'un include
machin, on est carrément dans le copyright d'interface.
Argument qui n'a pas de force aussi probante que tu crois, car on peut trés bien distribuer un binaire du programme en question, sans la librairie GPL. A l'exécution, le programme charge la dite librairie, mais à aucun moment l'auteur du logiciel "dérivé" n'a distribué une oeuvre contenant en tant que telle un morceau sous GPL.
Ça dépend comment c'est programmé. Si le code source fait un #include <machin.h>, alors le code produit comporte bien des petits bouts de la bibliothèque. Si tout est fait avec des dlopen, alors il n'y a rien à redire.
Ce qui n'est pas du tout l'opinion de la FSF. La phrase clé est sans doute "if the semantics of the communication are intimate enough, exchanging complex internal data structures".
<http://www.gnu.org/licenses/gpl-faq.html>
"What is the difference between "mere aggregation" and "combining two modules into one program"?
Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program.
Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL--if you can't, or won't, do that, you may not combine them.
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).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
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."
Et d'ailleurs si la dépendance est là simplement à cause d'un include machin, on est carrément dans le copyright d'interface.
Ol. -- Olivier Gutknecht
Gilles-Claude Rajaobelina
Olivier Gutknecht a écrit:
Nicolas George wrote:
Michel Talon, dans le message
Argument qui n'a pas de force aussi probante que tu crois, car on peut trés bien distribuer un binaire du programme en question, sans la librairie GPL.[...]
Ça dépend comment c'est programmé. [...] Si tout est fait avec des dlopen, alors il n'y a rien à redire.
Ce qui n'est pas du tout l'opinion de la FSF.[...]
<http://www.gnu.org/licenses/gpl-faq.html>
"What is the difference between "mere aggregation" and "combining two modules into one program"?
[...]
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).
<?> patented mouse clicks </?>
[...]
Et d'ailleurs si la dépendance est là simplement à cause d'un include machin, on est carrément dans le copyright d'interface.
Ol.
-- | Mon 1er est bête, l' horreur si sale ou méchant, fait pitié si n' | | est que pauvre. Mon 2ème l' est aussi, mais plutôt benêt. Mon 3ème | | adore les trous de serrure. Mon tout, bien ciblé, achète n' importe | | quoi, surtout si c' est cher. ^<>^ http://rajao.dyndns.org |
Olivier Gutknecht a écrit:
Nicolas George <george@clipper.ens.fr> wrote:
Michel Talon, dans le message
Argument qui n'a pas de force aussi probante que tu crois, car on
peut trés bien distribuer un binaire du programme en question, sans
la librairie GPL.[...]
Ça dépend comment c'est programmé. [...] Si tout est fait avec des
dlopen, alors il n'y a rien à redire.
Ce qui n'est pas du tout l'opinion de la FSF.[...]
<http://www.gnu.org/licenses/gpl-faq.html>
"What is the difference between "mere aggregation" and "combining two
modules into one program"?
[...]
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).
<?>
patented mouse clicks
</?>
[...]
Et d'ailleurs si la dépendance est là simplement à cause d'un include
machin, on est carrément dans le copyright d'interface.
Ol.
--
| Mon 1er est bête, l' horreur si sale ou méchant, fait pitié si n' |
| est que pauvre. Mon 2ème l' est aussi, mais plutôt benêt. Mon 3ème |
| adore les trous de serrure. Mon tout, bien ciblé, achète n' importe |
| quoi, surtout si c' est cher. ^<>^ http://rajao.dyndns.org |
Argument qui n'a pas de force aussi probante que tu crois, car on peut trés bien distribuer un binaire du programme en question, sans la librairie GPL.[...]
Ça dépend comment c'est programmé. [...] Si tout est fait avec des dlopen, alors il n'y a rien à redire.
Ce qui n'est pas du tout l'opinion de la FSF.[...]
<http://www.gnu.org/licenses/gpl-faq.html>
"What is the difference between "mere aggregation" and "combining two modules into one program"?
[...]
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).
<?> patented mouse clicks </?>
[...]
Et d'ailleurs si la dépendance est là simplement à cause d'un include machin, on est carrément dans le copyright d'interface.
Ol.
-- | Mon 1er est bête, l' horreur si sale ou méchant, fait pitié si n' | | est que pauvre. Mon 2ème l' est aussi, mais plutôt benêt. Mon 3ème | | adore les trous de serrure. Mon tout, bien ciblé, achète n' importe | | quoi, surtout si c' est cher. ^<>^ http://rajao.dyndns.org |
