Re: Architectures distribuées et GPL

Jean-Marie Gouarné <[email protected]> Thu, 26 May 2005 18:28:23 +0200
Newsgroups gmane.org.aful.law
Organization GENICORP
Message-ID <[email protected]>
Le jeudi 26 Mai 2005 17:56, Robert Viseur a =E9crit=A0:
> Bonjour,
>
> On m'a r=E9cemment interrog=E9 sur l'impact de la GPL (ou de la LGPL) dan=
s le
> cadre d'architecture distribu=E9e.
>
> J'ai essay=E9 de r=E9fl=E9chir sur un syst=E8me J2EE (je ne suis pas sp=
=E9cialiste de
> ce syst=E8me, ce qui handicape ma r=E9flexion).
>
> Imaginons donc un serveur d'application J2EE sous licence GPL. Ou s'arr=
=EAte
> l'effet copyleft dans ce cas ?
>
> J'ai notamment r=E9fl=E9chi sur base du sch=E9ma pr=E9sent=E9 ici :
> http://wwww.commentcamarche.net/j2ee/j2ee-intro.php3
>
> Sachant que les EJB utilis=E9s font partie du serveur d'application, y a-=
t-il
> propagation de la licence du serveur d'application vers les EJB ?
>
> Doit-on consid=E9r=E9 que le serveur d'application =E9tant un environneme=
nt
> d'ex=E9cution (comme un OS), il n'y a pas plus de propagation que pour Li=
nux
> (GPL) vis-=E0-vis des logiciels (libres ou propri=E9taires) tournant dess=
us ?
>
> Par contre, y aurait-il propagation d'un EJB =E0 un autre (si l'on souhai=
tait
> m=E9langer des EJB sous diff=E9rentes licences) ? Pourquoi ?
>
> Dans un autre cadre : Que pr=E9voient les =E9volutions de la GPL pour des
> applications communiquant par SOAP ou REST par exemple ? Pourrait-on
> consid=E9rer que deux applications =E9changeant par SOAP ne font qu'une et
> qu'il y a donc une propagation de la GPL aux deux applications (un peu
> comme l'on pourrait =E9tendre la notion de distribution =E0 l'ASP comme p=
our la
> licence Afero pour refl=E9ter l'=E9volution des usages en informatique) ?
>

Pour moi, il ne devrait pas y avoir propagation. En effet, dans un syst=E8m=
e=20
distribu=E9 =E0 couplage l=E2che, tel que J2EE et fortiori SOAP, les diff=
=E9rents=20
composants logiciels communiquent et inter-agissent par =E9change de messag=
es =E0=20
travers un middleware. Chaque composant publie son interface (sous une form=
e=20
parfois appel=E9e "contrat") et masque son impl=E9mentation. Chaque =E9l=E9=
ment d'une=20
telle architecture peut donc =EAtre consid=E9r=E9 comme un programme ex=E9c=
utable, ou=20
un groupe de programmes ex=E9cutables, autonome. L'utilisation d'un composa=
nt=20
(EJB ou service web) par un autre n'entra=EEne aucune inclusion de code.

Un serveur d'application peut en effet =EAtre consid=E9r=E9 comme une plate=
=2Dforme=20
d'ex=E9cution, au m=EAme titre qu'un syst=E8me d'exploitation. Un EJB fonct=
ionnant=20
dans l'environnement d'un serveur d'application n'en fait pas partie. On pe=
ut=20
parfaitement d=E9velopper un EJB (propri=E9taire ou libre) et l'installer d=
ans un=20
serveur d'application. L'EJB est un programme d'application dont le regime =
de=20
licence est ind=E9pendant de celui du serveur d'application. Sauf si l'EJB=
=20
lui-m=EAme a =E9t=E9 d=E9velopp=E9 en incluant du code fourni avec le serve=
ur=20
d'application (=E0 =E9viter autant que possible).

L'existence d'une d=E9pendance fonctionnelle entre deux composants logiciel=
s=20
dont aucun n'est une oeuvre d=E9riv=E9e de l'autre ne devrait entra=EEner a=
ucune=20
d=E9pendance de licence.

=2D-=20
Jean-Marie Gouarn=E9
Directeur technique
GENICORP - 156 boulevard Haussmann 75008 Paris
01.45.61.43.14
http://www.genicorp.fr