Mailing List Archive: ClamAV: users

Licensing & DLLs

Index | Next | Previous | View Threaded

paul at pscs

May 14, 2012, 8:55 AM

Post #1 of 12 (790 views)
Permalink

Licensing & DLLs

OK, I know this will probably have come up over and over, but I couldn't
find anything in the archives.

We produce a commercial mail server (not GPLed) which has a defined DLL
interface to allow people to create plugins to integrate with virus
scanners (I'll call that an 'AV plugin DLL'). It's not specifically
designed for ClamAV, but for any 'reasonable' virus scanner, and that
interface has been . Also, you don't need a virus scanner at all to use
our software, although, obviously without one, messages won't be scanned
for viruses - so it adds optional functionality. This AV plugin DLL
functionality has been in our software for about 8 years, so it's not
something we've added specifically to try to get around GPL.

If we made our software link directly with libclamav, then, as far as I
can see we'd need to GPL our software, which isn't desirable

What if another person made an AV plugin DLL to link our software with
libclamav? I presume that by doing so, their DLL would have to be
released under the GPL, but I also presume that wouldn't force us to GPL
our software even though our software is now linking with (their) GPL
software.

What if WE made an AV plugin DLL to link our software with libclamav?

(At the moment we're thinking of making an AV plugin DLL which execs
clamdscan, which, AFAICS is totally 'safe' for our licensing, but it
would be much more efficient (on Windows) to have it link directly with
libclamav - we don't mind releasing the source to the AV plugin DLL - it
could be a useful example for our more technical customers)

_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml

michael at orlitzky

May 14, 2012, 9:35 AM

Post #2 of 12 (776 views)
Permalink

Re: Licensing & DLLs [In reply to]

On 05/14/12 11:55, Paul Smith wrote:
>
> If we made our software link directly with libclamav, then, as far as I
> can see we'd need to GPL our software, which isn't desirable

Yup.

> What if another person made an AV plugin DLL to link our software with
> libclamav? I presume that by doing so, their DLL would have to be
> released under the GPL, but I also presume that wouldn't force us to GPL
> our software even though our software is now linking with (their) GPL
> software.

Are they distributing this DLL to anyone? If not, it doesn't matter. If
they are, they're bound by the GPL. If you link to it, you're bound by
the GPL too.

> What if WE made an AV plugin DLL to link our software with libclamav?

http://www.clamav.net/doc/latest/html/node35.html

> (At the moment we're thinking of making an AV plugin DLL which execs
> clamdscan, which, AFAICS is totally 'safe' for our licensing, but it
> would be much more efficient (on Windows) to have it link directly with
> libclamav - we don't mind releasing the source to the AV plugin DLL - it
> could be a useful example for our more technical customers)

If you link to something that links to libclamav, you are bound by the
GPL. Otherwise, it would be possible to insert a dummy layer in front of
a GPL library and avoid the license.

Using clamdscan or communicating directly with clamd over a socket is
fine. (Or maybe you can buy a commercial license these days?)

_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml

cswiger at mac

May 14, 2012, 10:21 AM

Post #3 of 12 (774 views)
Permalink

Re: Licensing & DLLs [In reply to]

On May 14, 2012, at 8:55 AM, Paul Smith wrote:
> We produce a commercial mail server (not GPLed) which has a defined DLL interface to allow people to create plugins to integrate with virus scanners (I'll call that an 'AV plugin DLL'). It's not specifically designed for ClamAV, but for any 'reasonable' virus scanner, and that interface has been . Also, you don't need a virus scanner at all to use our software, although, obviously without one, messages won't be scanned for viruses - so it adds optional functionality. This AV plugin DLL functionality has been in our software for about 8 years, so it's not something we've added specifically to try to get around GPL.

You've written a generic plugin API for your software. It's license agnostic.

> If we made our software link directly with libclamav, then, as far as I can see we'd need to GPL our software, which isn't desirable

You'd need to license your software under a GPL-miscible license in order to redistribute the combination. If your proprietary/commercial license isn't currently GPL-miscible, then you could not redistribute the combination.

> What if another person made an AV plugin DLL to link our software with libclamav? I presume that by doing so, their DLL would have to be released under the GPL, but I also presume that wouldn't force us to GPL our software even though our software is now linking with (their) GPL software.

Nothing done by someone else would require you to "GPL your software". Having end-users assemble the combination themselves via the AV plugin DLL would leave the responsibility up to them; if the licenses are not compatible, they would not be able to redistribute the combination, but they could still use it.

[. This is a fair description of the case where proprietary binary drivers from nVidia or ATI/AMD get linked via a GPL'ed shim into a Linux kernel, and is why such linking is done by the end-user, and not shipped as part of a distribution. ]

> What if WE made an AV plugin DLL to link our software with libclamav?

If your software license isn't GPL-miscible, then you should not redistribute the combination of your software, the plugin, and ClamAV.

> (At the moment we're thinking of making an AV plugin DLL which execs clamdscan, which, AFAICS is totally 'safe' for our licensing, but it would be much more efficient (on Windows) to have it link directly with libclamav - we don't mind releasing the source to the AV plugin DLL - it could be a useful example for our more technical customers)

Invoke ClamAV / clamd via a socket...?

Regards,
--
-Chuck

_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml

linux at thehobsons

May 14, 2012, 12:02 PM

Post #4 of 12 (770 views)
Permalink

Re: Licensing & DLLs [In reply to]

Chuck Swiger wrote:

> > What if WE made an AV plugin DLL to link our software with libclamav?
>
>If your software license isn't GPL-miscible, then you should not
>redistribute the combination of your software, the plugin, and
>ClamAV.

Isn't this a case where the component they've linked with (in this
case) ClamAV would need to be GPL, but the other component it talks
to doesn't need to be ?
I'm assuming these are separate units - ie there's the closed main
system, and the GPL plugin code linked with ClamAV.

The fact that the closed main system is distributed alongside the GPL
code doesn't mean it has to be GPL - provided they are clear in the
documentation etc which parts are closed, and which are GPL. Very
much a flip round of the case where software uses non-free libraries
(http://www.gnu.org/licenses/gpl-faq.html#FSWithNFLibs)

Also,
http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
says :

>However, in many cases you can distribute the GPL-covered software
>alongside your proprietary system. To do this validly, you must make
>sure that the free and non-free programs communicate at arms length,
>that they are not combined in a way that would make them effectively
>a single program.

It then goes on to say :

>The difference between this and "incorporating" the GPL-covered
>software is partly a matter of substance and partly form. The
>substantive part is this: if the two programs are combined so that
>they become effectively two parts of one program, then you can't
>treat them as two separate programs. So the GPL has to cover the
>whole thing.

My interpretation of this would be that in the case the OP asked
about, provided he makes the plugin a distinctly separate program
(and GPLs any code he adds to the GPLd code to make it work with his
API) then it would qualify. It would require the plugin to be
separate and optional - but i see no reason it can't be shipped on
the same disk.

The GPL is actually not as all encompasing and restricted as many
believe - it *IS* possible to combine GPL and non-free software in a
system if you do it right, and using GPL software does *NOT*
automatically mean the entire system has to be GPL. Perpetuating
these myths doesn't do anyone any good.

If in doubt, the OP could always as FSF who I'm sure would be quite
happy to have someone ask them rather than make assumptions and/or
get it wrong. I dare say they'd be happier if the whole lot was GPLd,
but Rome wasn't built in a day.

--
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml

cswiger at mac

May 14, 2012, 12:57 PM

Post #5 of 12 (769 views)
Permalink

Re: Licensing & DLLs [In reply to]

On May 14, 2012, at 12:02 PM, Simon Hobson wrote:
> Chuck Swiger wrote:
>>> What if WE made an AV plugin DLL to link our software with libclamav?
>>
>> If your software license isn't GPL-miscible, then you should not redistribute the combination of your software, the plugin, and ClamAV.
>
> Isn't this a case where the component they've linked with (in this case) ClamAV would need to be GPL, but the other component it talks to doesn't need to be ?

Yes, if "talks to" means an external connection to a network port or local filesystem socket, then the other component doesn't need to be GPL-miscible. If the other component gets linked into a single program, then the GPL folks claim that makes them a single work which needs to be licensed under GPL-compatible terms.

> I'm assuming these are separate units - ie there's the closed main system, and the GPL plugin code linked with ClamAV.
>
> The fact that the closed main system is distributed alongside the GPL code doesn't mean it has to be GPL - provided they are clear in the documentation etc which parts are closed, and which are GPL. Very much a flip round of the case where software uses non-free libraries (http://www.gnu.org/licenses/gpl-faq.html#FSWithNFLibs)

That's right. Mere aggregation on storage media does not imply a licensing relationship (see prolog to GPLv2 clause 3, and similar in GPLv3 clause 6).

Regards,
--
-Chuck

_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml

jesler at sourcefire

May 14, 2012, 1:01 PM

Post #6 of 12 (768 views)
Permalink

Re: Licensing & DLLs [In reply to]

On May 14, 2012, at 11:55 AM, Paul Smith wrote:

> OK, I know this will probably have come up over and over, but I couldn't find anything in the archives.
>
> We produce a commercial mail server (not GPLed) which has a defined DLL interface to allow people to create plugins to integrate with virus scanners (I'll call that an 'AV plugin DLL'). It's not specifically designed for ClamAV, but for any 'reasonable' virus scanner, and that interface has been . Also, you don't need a virus scanner at all to use our software, although, obviously without one, messages won't be scanned for viruses - so it adds optional functionality. This AV plugin DLL functionality has been in our software for about 8 years, so it's not something we've added specifically to try to get around GPL.
>
> If we made our software link directly with libclamav, then, as far as I can see we'd need to GPL our software, which isn't desirable
>
> What if another person made an AV plugin DLL to link our software with libclamav? I presume that by doing so, their DLL would have to be released under the GPL, but I also presume that wouldn't force us to GPL our software even though our software is now linking with (their) GPL software.
>
> What if WE made an AV plugin DLL to link our software with libclamav?
>
> (At the moment we're thinking of making an AV plugin DLL which execs clamdscan, which, AFAICS is totally 'safe' for our licensing, but it would be much more efficient (on Windows) to have it link directly with libclamav - we don't mind releasing the source to the AV plugin DLL - it could be a useful example for our more technical customers)

Sorry it's taken me this long to chime in on this thread.

If you are interested in doing something like this, I suggest you contact me offlist so I can put you in touch with our legal team. They are the experts on this kind of thing and should handle this type inquiry.

--
Joel Esler
Senior Research Engineer, VRT
OpenSource Community Manager
Sourcefire

_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml

paul at pscs

May 14, 2012, 2:26 PM

Post #7 of 12 (768 views)
Permalink

Re: Licensing & DLLs [In reply to]

On 14/05/2012 20:57, Chuck Swiger wrote:
> On May 14, 2012, at 12:02 PM, Simon Hobson wrote:
>> Chuck Swiger wrote:
>>>> What if WE made an AV plugin DLL to link our software with libclamav?
>>> If your software license isn't GPL-miscible, then you should not redistribute the combination of your software, the plugin, and ClamAV.
>> Isn't this a case where the component they've linked with (in this case) ClamAV would need to be GPL, but the other component it talks to doesn't need to be ?
> Yes, if "talks to" means an external connection to a network port or local filesystem socket, then the other component doesn't need to be GPL-miscible. If the other component gets linked into a single program, then the GPL folks claim that makes them a single work which needs to be licensed under GPL-compatible terms.
>
Actually it seems a bit wooly even to the GPL folks...

http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#NFUseGPLPlugins

What we have is a DLL with essentially 3 functions, 'init', 'shutdown'
and 'scan(memoryblock)'. (to use with ClamAV,the DLL has to save the
memory block to a temporary file and scan that).

This seems to fall into this category:

"If the program dynamically links plug-ins, but the communication
between them is limited to invoking the 'main' function of the plug-in
with some options and waiting for it to return, that is a borderline case."

It doesn't say what happens in that case, but even the GPL folks see it
as a 'borderline' case, not a clear-cut case.

(BTW - There are plugins listed on the ClamAV wiki for Exchange &
Communigate, so how are those 'legal'?)

We could talk to clamd using TCP/IP, but since the clamd protocol
doesn't seem to be clearly documented, that would involve reverse
engineering clamdscan and rewriting it.

We have considered making our own GPL daemon based on clamscan which
communicates with our software using a socket or named pipe using our
own protocol. While that would seem to meet the letter of the license
(as we won't be linking non-GPL software with clamav directly), it seems
to me to be more against the spirit of it than linking in using the
standard API...

(We've actually tried to contact SourceFire to start investigating
whether a commercial licence would be possible, but had no response so
far - I'll get in touch with Joel Essler about it,since he seems to know
the right person to talk to...)

_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml

edwin at clamav

May 14, 2012, 11:49 PM

Post #8 of 12 (767 views)
Permalink

Re: Licensing & DLLs [In reply to]

On 05/15/2012 12:26 AM, Paul Smith wrote:
>
> We could talk to clamd using TCP/IP, but since the clamd protocol doesn't seem to be clearly documented, that would involve reverse engineering clamdscan and rewriting it.

The protocol is described in: man 8 clamd

--Edwin
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml

ged at jubileegroup

May 15, 2012, 4:14 AM

Post #9 of 12 (760 views)
Permalink

Re: Licensing & DLLs [In reply to]

Hi there,

On 05/15/2012 12:26 AM, Paul Smith wrote:

> We could talk to clamd using TCP/IP, but ... that would involve
> reverse engineering clamdscan and rewriting it.

Reverse engineering????

Just download the source.

--

73,
Ged.
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml

michael at orlitzky

May 15, 2012, 8:11 AM

Post #10 of 12 (758 views)
Permalink

Re: Licensing & DLLs [In reply to]

On 05/15/12 07:14, G.W. Haywood wrote:
> Hi there,
>
> On 05/15/2012 12:26 AM, Paul Smith wrote:
>
>> We could talk to clamd using TCP/IP, but ... that would involve
>> reverse engineering clamdscan and rewriting it.
>
> Reverse engineering????
>
> Just download the source.
>

Thankfully, you can't read the source of a GPLed program and use that
knowledge to write your own closed-source implementation.
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml

uhlar at fantomas

May 24, 2012, 5:56 AM

Post #11 of 12 (701 views)
Permalink

Re: Licensing & DLLs [In reply to]

>> On 05/15/2012 12:26 AM, Paul Smith wrote:
>>> We could talk to clamd using TCP/IP, but ... that would involve
>>> reverse engineering clamdscan and rewriting it.

>On 05/15/12 07:14, G.W. Haywood wrote:
>> Reverse engineering????
>>
>> Just download the source.

On 15.05.12 11:11, Michael Orlitzky wrote:
>Thankfully, you can't read the source of a GPLed program and use that
>knowledge to write your own closed-source implementation.

I think you can do that, but you must not copy the code. The safe ways
to avoit such legal problems is to have two groups of people, one that
reads, tries to understand how does the stuff work, and explains to
another one, that will build code based on those informations.

However, the clamd protocol is afaik documented and you _can_ use that
knowledge to build your SW
--
Matus UHLAR - fantomas, uhlar [at] fantomas ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fucking windows! Bring Bill Gates! (Southpark the movie)
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml

michael at orlitzky

May 24, 2012, 8:55 AM

Post #12 of 12 (698 views)
Permalink

Re: Licensing & DLLs [In reply to]

On 05/24/12 08:56, Matus UHLAR - fantomas wrote:
>
> I think you can do that, but you must not copy the code. The safe ways
> to avoit such legal problems is to have two groups of people, one that
> reads, tries to understand how does the stuff work, and explains to
> another one, that will build code based on those informations.
>
> However, the clamd protocol is afaik documented and you _can_ use that
> knowledge to build your SW

You're referring to clean room reverse engineering[1], but the first
person is the one who reverse engineers the system by observing its
behavior in response to various inputs. He doesn't get to read the code.

You can use the man page, of course, but the existence of documentation
doesn't mean you can skirt the GPL even though the end result is the same.

[1] http://en.wikipedia.org/wiki/Clean_room_design
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads