[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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org