Bug#539384: anjuta: Linked with OpenSSL, seems to be a GPL violation

[Adrian Bunk]
> > > It might be enough to change the libneon build dependency
> > > to libneon27-gnutls-dev.

You don't need a libneon build dependency at all, as I explained in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482512#10 .  I even
wrote a patch.  (It was easy, it was just ripping out unnecessary
stuff.)


> That seems to come through libserf.
> 
> It seems GPL'ed software without an OpenSSL licence exception linked 
> against libsvn is a candidate for my next batch of GPL violation RC bugs...
> 
> @Peter:
> How important is the libserf usage in SVN, and are you aware of this problem?

Usage?  It is not used at all by default.  But I will not remove it
without very good reason, as some people need it.

I think you have to stretch your logic pretty far to make it a GPL
violation, though.  Consider:

  anjuta-subversion.plugin uses libsvn_client
  libsvn_client uses libsvn_ra
  libsvn_ra can be configured to use libsvn_ra_serf
  libsvn_ra_serf uses libserf
  libserf uses the dreaded openssl

These layers are pretty, well, layered.  From a copyright perspective,
you can't possibly argue that openssl had any influence on how anjuta
was written.  That is,

  libsvn_ra had little or no influence on the copyrightable bits of 
anjuta-subversion.plugin
  libsvn_ra_serf had little or no influence on the copyrightable bits of 
libsvn_client
  libserf had little or no influence on the copyrightable bits of libsvn_ra
  openssl had little or no influence on the copyrightable bits of libsvn_ra_serf

The only way you could argue that they are at all related is that they
share an address space at runtime.  It is a far cry from software that
calls the openssl API directly.

If I must, I can enable the libsvn_ra loadable module interface, so
that it doesn't even _load_ libsvn_ra_serf at all, unless you enable it
in ~/.subversion/servers.  That will keep the dirty libssl.so.0.9.8
away from our pretty GPL code.  Or at least 'ldd' won't see it.  But so
far I haven't seen any reason to do this.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx