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