Publish/Subscribe Lib for Python?

[Adrian B.]

Does anyone know of a framework or library that will enable me to use
publish/subscribe comms? I want to create a server (using Python)
running on a Unix box that will accept client connections (from GUIs
built with wxPython) and publish realtime data updates to them. Any
advice on where to start?

Thanks.
A.B.

[Ville Vainio]

Re: Publish/Subscribe Lib for Python?

>>>>> "Adrian" == Adrian B <borg@swirve.co m> writes:

Adrian> Does anyone know of a framework or library that will
Adrian> enable me to use publish/subscribe comms? I want to
Adrian> create a server (using Python) running on a Unix box that
Adrian> will accept client connections (from GUIs built with
Adrian> wxPython) and publish realtime data updates to them. Any
Adrian> advice on where to start?

This is easy w/o any special libraries, if it is indeed all you have
to do.

Some options:

- Clients open TCP socket to server as a "subscripti on", server dumps
all the changes to all the connected TCP sockets.

- Clients register their host, port addrs with server, server sends
updates to all the subscribed clients in UDP packets.

- UDP broadcasts might work too, haven't tried it.

Or, you could use something like CORBA (omniORB) for more complicated
scenarios.

Googling also revealed:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/81614

But beware: OSE, which that recipe relies on, seems to be licensed
under QPL.

--
Ville Vainio http://tinyurl.com/2prnb

[Mike C. Fletcher]

Re: Publish/Subscribe Lib for Python?

Look to Twisted Matrix or possibly Spread (with Python). Quick google
search for either should help.

Enjoy,
Mike

Adrian B. wrote:
[color=blue]
>Does anyone know of a framework or library that will enable me to use
>publish/subscribe comms? I want to create a server (using Python)
>running on a Unix box that will accept client connections (from GUIs
>built with wxPython) and publish realtime data updates to them. Any
>advice on where to start?
>
>Thanks.
>A.B.
>
>[/color]
_______________ _______________ _________
Mike C. Fletcher
Designer, VR Plumber, Coder

http://members.rogers.com/mcfletch/

[tcronj]

Re: Publish/Subscribe Lib for Python?

Adrian B. wrote:[color=blue]
> Does anyone know of a framework or library that will enable me to use
> publish/subscribe comms? I want to create a server (using Python)
> running on a Unix box that will accept client connections (from GUIs
> built with wxPython) and publish realtime data updates to them. Any
> advice on where to start?
>
> Thanks.
> A.B.[/color]

http://ose.sourceforge.net/

[Irmen de Jong]

Re: Publish/Subscribe Lib for Python?

Adrian B. wrote:[color=blue]
> Does anyone know of a framework or library that will enable me to use
> publish/subscribe comms?[/color]

Pyro's Event Service. http://pyro.sourceforge.net

--Irmen

[Ng Pheng Siong]

Re: Publish/Subscribe Lib for Python?

According to Adrian B. <borg@swirve.co m>:[color=blue]
> Does anyone know of a framework or library that will enable me to use
> publish/subscribe comms? I want to create a server (using Python)
> running on a Unix box that will accept client connections (from GUIs
> built with wxPython) and publish realtime data updates to them. Any
> advice on where to start?[/color]

Just choose any blogging library that takes your fancy.


--
Ng Pheng Siong <ngps@netmemeti c.com>

http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL

[Graham Dumpleton]

Licensing of wrappers around C/C++ code under more restrictive licensing.

Ville Vainio <ville@spammers .com> wrote in message news:<du7ishrmq sv.fsf@amadeus. cc.tut.fi>...[color=blue]
> Googling also revealed:
>
> http://aspn.activestate.com/ASPN/Coo...n/Recipe/81614
>
> But beware: OSE, which that recipe relies on, seems to be licensed
> under QPL.[/color]

That it is currently under the QPL means nothing if you aren't intending
to redistribute your own code. Ie., if you are developing a system for in
house or personal use, the contentious parts of the QPL don't actually
kick in and it should be safe to use. Much the same as the GPL really,
where things only apply if you intend to redistribute.

The next version of OSE will try to address this issue by allowing use of
the Python wrappers under a BSD or Python style license, provided that
the C++ layer underneath is left as is. Change the C++ layer underneath
and the QPL will apply up through the Python code as well.

In other words, there will be an attempt to build a wall between the QPL
licensed C++ code and the Python code. It may turn out that this is not
a practical thing to do and even if possible, it may still not satsify the
GPL license clause about other licenses placing additional restrictions
beyond those implied by the GPL. Ie., you still might not be able to
validly use the stuff in an application where you also use Python code
under the GPL.

I would really like to hear other peoples ideas about how to address
licensing where the Python code is actually a wrapper around a C/C++
library under a QPL or GPL type license. Some people seem to believe
that the use of the scripting language implies a line is drawn when
people go to use it and thus what the library underneath is licensed
under doesn't matter. Linking of the library still occurs though, so I
don't believe this is necessarily the case.

So, how can one cast the licensing so as to provide an exception that
provided the underlying C/C++ library isn't changed, that the Python
wrappers can be used under a less restrictive license. I have control of
the licensing on both so can stipulate exceptions, but what is the
best way of doing it?

Comments?

[Mike C. Fletcher]

Re: Licensing of wrappers around C/C++ code under more restrictivelice nsing.

Graham Dumpleton wrote:
....
[color=blue]
>I would really like to hear other peoples ideas about how to address
>licensing where the Python code is actually a wrapper around a C/C++
>library under a QPL or GPL type license. Some people seem to believe
>that the use of the scripting language implies a line is drawn when
>people go to use it and thus what the library underneath is licensed
>under doesn't matter. Linking of the library still occurs though, so I
>don't believe this is necessarily the case.
>
>[/color]
(I'm not a lawyer, just someone who seems to get lectured at about
licenses a lot :) ).

If I understand correctly, copyright law does not directly grant one the
right to restrict distribution of *someone else's* copyrighted works
merely because they refer to one's own work. So, if your distributable
does not include any code created by someone else, then the other party
has no right to restrict its distribution based on copyright. So, if
your package connects to anything installed on the system which happens
to implement a given API but does not include any GPL code itself, you
can likely simply point to the fact that you haven't included any of the
GPL-licensed code and be fine.

The FSF peoples seem to have a different interpretation, as, last I
heard, they suggest that software that links to any GPL software, even
at run-time constitutes an infringement (regardless of your not having
distributed the GPL code yourself, and the end-user having a perfectly
valid license to link the two for personal use). Depending on a Free
Software Foundation owned library (i.e. one to which the author has
assigned their copyright to the FSF) in this type of scenario would
likely then be a little risky.

The question becomes murkier when you start to introduce, for instance,
the use of header files from a GPL program to create a SWIG .i file.
There are apparently cases where the use of headers for allowing
interoperabilit y with commercial software was considered a fair-use
infringement (i.e. it is technically a copyright violation, but is
likely to be considered valid should it be brought before a court).
Apparently other cases suggest that the necessary functional
specification isn't actually copyrightable. The question comes down to
what is expression, and what is merely mechanics.
[color=blue]
>So, how can one cast the licensing so as to provide an exception that
>provided the underlying C/C++ library isn't changed, that the Python
>wrappers can be used under a less restrictive license. I have control of
>the licensing on both so can stipulate exceptions, but what is the
>best way of doing it?
>
>[/color]
Sounds like what you really want is the LGPL for the C/C++ library?
That would keep the GPL-like restrictions for the C/C++ library, but
allow linking it into proprietary Python software. It would *not*
however restrict based on whether it's a Python or C/C++ application
doing the linking. It would also explicitly *not* prevent changes to
the C/C++ library (the whole point of Open Source licenses, particularly
GPL and LGPL being to allow the user to fix bugs and change operation of
the software).

You could add a clause to your license doing something silly like
requiring that a Python DLL be linked into the process to enable the
less restrictive license, but doing that means that you've suddenly got
a non-standard license, which requires everyone to hire a lawyer to
explain it to them, check for incompatibiliti es with other software, ad
nauseam.

Of course, the point of the GPL license (among other things) is to
strongly encourage others to use the license in order to give to users
access to ever-more GPL'd code. The so-called "viral" effects are
intentional. If I understand correctly, the QPL is basically a dual
license encouraging you to either pay Trolltech or GPL your software.
Finding ways *around* these licenses (I'm assuming that the QPL is being
inherited by including Qt or the like) might be considered rude at the
least if the license involves code which is not your own.

So, my suggestion would be (assuming this is possible (you own *all*
copyrights involved)):

* Ditch QPL, license the C/C++ library as LGPL, license the Python
library as BSD/MIT or LGPL.
* Distribute the Python wrapper (with none of the C/C++ project's
code) as a separate project.
o Anyone who uses the C/C++ library is still bound by GPL rules.
o Anyone who combines and redistributes it will be bound by
the GPL, so they can't bundle it with proprietary code.
o The more permissive MIT/BSD license is GPL compatible, so
the wrapper itself can be bundled with the GPL code if desired.
o The wrapper can be bundled with the proprietary code so that
the user can simply install the C/C++ project using it's
installer and the proprietary code can find it at run time.
o Users must combine the system with any proprietary code
themselves. This can be fairly inconvenient.
* Descend into a morass of trying to legally define what it means to
"use" the Python-based interface and try to integrate that into
some Open Source license.
o Is someone allowed to use both interfaces under the less
restrictive license, or only the Python interface?
o Is someone allowed to call the Python interpreter from C/C++
solely to access the functionality?
o Figure out how to cripple the "modify as you wish" focus of
most of these licenses in the case of use of the Python
interface.
* Build your own license using your own high-priced lawyers :) .

The thing, IMO, to keep in mind, is that creating yet another Open
Source license is probably *not* a good idea, despite the fact that it
acts as a make-work project for copyright attorneys, who are obviously
needing more BMWs these days. Choosing one of the existing well
understood and fairly clear licenses (not, e.g. the PSF Python license,
which is an agglomeration of other licenses), such as MIT, BSD, GPL, or
LGPL is probably the best approach for minimising headache and effort.

Good luck,
Mike (again, so not a lawyer it's funny)

_______________ _______________ _________
Mike C. Fletcher
Designer, VR Plumber, Coder

http://members.rogers.com/mcfletch/

[Graham Dumpleton]

Re: Licensing of wrappers around C/C++ code under more restrictivelice nsing.


On 29/02/2004, at 4:09 PM, Mike C. Fletcher wrote:
[color=blue]
> Graham Dumpleton wrote:[color=green]
>> So, how can one cast the licensing so as to provide an exception that
>> provided the underlying C/C++ library isn't changed, that the Python
>> wrappers can be used under a less restrictive license. I have control
>> of
>> the licensing on both so can stipulate exceptions, but what is the
>> best way of doing it?
>>[/color]
> Sounds like what you really want is the LGPL for the C/C++ library?
> That would keep the GPL-like restrictions for the C/C++ library, but
> allow linking it into proprietary Python software. It would *not*
> however restrict based on whether it's a Python or C/C++ application
> doing the linking. It would also explicitly *not* prevent changes to
> the C/C++ library (the whole point of Open Source licenses,
> particularly GPL and LGPL being to allow the user to fix bugs and
> change operation of the software).
>
> You could add a clause to your license doing something silly like
> requiring that a Python DLL be linked into the process to enable the
> less restrictive license, but doing that means that you've suddenly
> got a non-standard license, which requires everyone to hire a lawyer
> to explain it to them, check for incompatibiliti es with other
> software, ad nauseam.
>
> Of course, the point of the GPL license (among other things) is to
> strongly encourage others to use the license in order to give to users
> access to ever-more GPL'd code. The so-called "viral" effects are
> intentional. If I understand correctly, the QPL is basically a dual
> license encouraging you to either pay Trolltech or GPL your software.
> Finding ways *around* these licenses (I'm assuming that the QPL is
> being inherited by including Qt or the like) might be considered rude
> at the least if the license involves code which is not your own.
>
> So, my suggestion would be (assuming this is possible (you own *all*
> copyrights involved)):
>
> * Ditch QPL, license the C/C++ library as LGPL, license the Python
> library as BSD/MIT or LGPL.
> ...[/color]

Thanks for the comments. It gives me more things to think about.

As far as ditching the QPL for the C/C++ library and using the LGPL, I
am not sure
that I can. The whole situation is made more complicated for me,
because although
I wrote all the code, it was originally developed while I worked for a
specific
company. I did obtain a license from that company to continue to
develop the code
and to distribute the result, including being able to sub-license
others to also
distribute the code, but the language of that license may well prevent
me from
applying a license such as the LGPL. This is because with the LGPL,
someone could
cherry pick code out of the library and use it in something else to the
extent that
the LGPL allows. At least I don't believe the LGPL would stop this
although the
application or library which used the "cherry picked" code would itself
have to be
LGPL or GPL I would imagine.

The reason why the QPL is working for me so far is that the QPL
essentially restricts
someone to distributing it as is. That is, any changes must be
distributed as a
separate patch. This in effect means that someone can't just cherry
pick code from
it and use it separately. To that end I believe I am working within the
spirit of
my original license obtained from the company who I was originally
working for as
the manner in which I am licensing it and distributing it preserves the
integrity
of the package and people in the main have to use it as distributed.
They can still
make changes if they need to, but if distributing it further, these
would have to
be as a patch.

I'll have to look more at my license for using the original code, but I
think I would
be pushing it to release my current C++ code, based on the original
code, under a
license that allows a free for all. My Python wrappers don't have this
problem as
such because I developed them all on my own time and by itself it
doesn't include
any of the original code. Now one may say that I should have negotiated
a better
license on the original code, but this was back in 1993 before Open
Source took
off to the extent that it has. It wasn't necessarily possible back then
to anticipate
how things would change

Thanks again.

[Roger Binns]

Re: Licensing of wrappers around C/C++ code under more restrictive licensing.

> The next version of OSE will try to address this issue by allowing use of[color=blue]
> the Python wrappers under a BSD or Python style license, provided that
> the C++ layer underneath is left as is. Change the C++ layer underneath
> and the QPL will apply up through the Python code as well.[/color]

I can tell you that I immediately ruled out OSE for my open source project
http://bitpim.sf.net licensed under the Artistic License because of the
license of OSE.

Roger

[Graham Dumpleton]

Re: Licensing of wrappers around C/C++ code under more restrictivelice nsing.


On 29/02/2004, at 4:09 PM, Mike C. Fletcher wrote:
[color=blue]
> Graham Dumpleton wrote:
> ...
>[color=green]
>> So, how can one cast the licensing so as to provide an exception that
>> provided the underlying C/C++ library isn't changed, that the Python
>> wrappers can be used under a less restrictive license. I have control
>> of
>> the licensing on both so can stipulate exceptions, but what is the
>> best way of doing it?
>>[/color]
>
> ...
>
> If I understand correctly, the QPL is basically a dual license
> encouraging you to either pay Trolltech or GPL your software.[/color]

I presume you actually meant to say "QPL" and not "GPL" in this
sentence.

Anyway, have been looking at the QPL again, and as far as I can see, it
doesn't force you to make any code you write which links with the QPL'd
library available explicitly under the QPL. What it says is:

6. You may develop application programs, reusable components and other
software items that link with the original or modified versions of the
Software. These items, when distributed, are subject to the following
requirements:

a. You must ensure that all recipients of machine-executable forms of
these items are also able to receive and use the complete
machine-readable source code to the items without any charge beyond the
costs of data transfer.

b. You must explicitly license all recipients of your items to use and
re-distribute original and modified versions of the items in both
machine-executable and source code forms. The recipients must be able
to do so without any charges whatsoever, and they must be able to
re-distribute to anyone they choose.

c. If the items are not available to the general public, and the
initial developer of the Software requests a copy of the items, then
you must supply one.

Thus, as far as I can tell, it would be quite okay to make the Python
wrappers themselves available under a BSD/MIT type license as opposed
to the QPL license.

Overall though, this probably doesn't make much difference however
as anyone using the Python wrappers still in effect has to wear the
underlying conditions of the QPL licensed code. That is, the end
application still has to be made available under terms in line with
the Open Source model if distributed. The only Open Source license
you definitely wouldn't be able to use is the GPL since it regards
the QPL as incompatible.

If you agree with Open Source, that the QPL license is still used
for the C++ code in the runtime loadable component shouldn't be an
issue. We are therefore back to simply not satisfying those who don't
want to pay money for an alternative license if they want to make
money off there own application by selling it.

To meet other requirements I have, if I wanted to not restrict use
in for sale software, I almost need a LGPLish version of the QPL.
Noting that the reason I couldn't use the LGPL was because I need
the control enforced by the following clauses of the QPL.

3. You may make modifications to the Software and distribute your
modifications, in a form that is separate from the Software, such as
patches.

That is, need to be able to say that the original package must always
be redistributed as is, ie., in the form provided, with any changes
being in a distinct package, such as a patch. I believe this should
also prevent a free for all as far as people taking/stealing just bits
of the package and reusing it in other things, but then in practice
that is almost impossible to enforce. :-(

If one had a LGPLish variant of the QPL which doesn't transfer
conditions on linking, problem may be solved. I don't however now
of any Open Source license which does that. Does anyone else?

IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient.

[Andrew Koenig]

Re: Licensing of wrappers around C/C++ code under more restrictive licensing.

"Mike C. Fletcher" <mcfletch@roger s.com> wrote in message
news:mailman.1. 1078031359.2143 9.python-list@python.org ...
[color=blue]
> The FSF peoples seem to have a different interpretation, as, last I
> heard, they suggest that software that links to any GPL software, even
> at run-time constitutes an infringement (regardless of your not having
> distributed the GPL code yourself, and the end-user having a perfectly
> valid license to link the two for personal use).[/color]

Can you provide evidence to support this claim?

[Paul Rubin]

Re: Licensing of wrappers around C/C++ code under more restrictive licensing.

"Andrew Koenig" <ark@acm.org> writes:[color=blue][color=green]
> > The FSF peoples seem to have a different interpretation, as, last I
> > heard, they suggest that software that links to any GPL software, even
> > at run-time constitutes an infringement (regardless of your not having
> > distributed the GPL code yourself, and the end-user having a perfectly
> > valid license to link the two for personal use).[/color]
>
> Can you provide evidence to support this claim?[/color]

http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL

[Graham Dumpleton]

Re: Licensing of wrappers around C/C++ code under more restrictive licensing.

"Roger Binns" <rogerb@rogerbi nns.com> wrote in message news:<9tt9h1-h1d.ln1@home.ro gerbinns.com>.. .[color=blue][color=green]
> > The next version of OSE will try to address this issue by allowing use of
> > the Python wrappers under a BSD or Python style license, provided that
> > the C++ layer underneath is left as is. Change the C++ layer underneath
> > and the QPL will apply up through the Python code as well.[/color]
>
> I can tell you that I immediately ruled out OSE for my open source project
> http://bitpim.sf.net licensed under the Artistic License because of the
> license of OSE.[/color]

I am surprised you even went as far as looking at the license for OSE as
in looking at "bitpim", not sure that what OSE had to offer in the way
of functionality would even have made it appropriate for what you were
doing.

Anyway, interesting you mention the "Artistic License" as I have been
looking at that as an alternative license to use instead of QPL. On first
glance it may not conflict with the license I have from the company
where I worked when first developing OSE and which allows me to
continue to develop it and redistribute it.

The next version of OSE was in effect going to come in two variants
anyway, a standard version and an extended version. The standard
version is more or less what is out there now, but the extended version
has extra C++ stuff, only usable through C++ and not used in Python
wrappers, which gives additional value add. The standard version
could be switched from QPL to the Artistic License perhaps, especially
since that will pretty well stay static now since all new work being done
in the extended version anyway. The extended version would be strictly
non commercial use only unless a separate paid license was obtained.
I would like to make a bit of money from the 14 years of work that I
have put into all of this. :-)

[Mike C. Fletcher]

Re: Licensing of wrappers around C/C++ code under more restrictivelice nsing.

Andrew Koenig wrote:
[color=blue]
>"Mike C. Fletcher" <mcfletch@roger s.com> wrote in message
>news:mailman.1 .1078031359.214 39.python-list@python.org ...
>
>
>[color=green]
>>The FSF peoples seem to have a different interpretation, as, last I
>>heard, they suggest that software that links to any GPL software, even
>>at run-time constitutes an infringement (regardless of your not having
>>distributed the GPL code yourself, and the end-user having a perfectly
>>valid license to link the two for personal use).
>>
>>[/color]
>
>Can you provide evidence to support this claim?
>
>[/color]
Mmm, evidence, always fun to research...

A quick search didn't turn up any statements which are black and white
on the particular issue of a "scripting language" API. As noted in the
paragraph above, I was going by other people's statements. Closest
thing I could find were these:


What is the difference between "mere aggregation" and
"combining two modules into one program"?
<http://www.fsf.org/licenses/gpl-faq.html#TOCMer eAggregation>

Mere aggregation of two programs means putting them side by side on
the same CD-ROM or hard disk. We use this term in the case where
they are separate programs, not parts of a single program. In this
case, if one of the programs is covered by the GPL, it has no effect
on the other program.

Combining two modules means connecting them together so that they
form a single larger program. If either part is covered by the GPL,
the whole combination must also be released under the GPL--if you
can't, or won't, do that, you may not combine them.

What constitutes combining two parts into one program? This is a
legal question, which ultimately judges will decide. We believe that
a proper criterion depends both on the mechanism of communication
(exec, pipes, rpc, function calls within a shared address space,
etc.) and the semantics of the communication (what kinds of
information are interchanged).

If the modules are included in the same executable file, they are
definitely combined in one program. If modules are designed to run
linked together in a shared address space, that almost surely means
combining them into one program.

By contrast, pipes, sockets and command-line arguments are
communication mechanisms normally used between two separate
programs. So when they are used for communication, the modules
normally are separate programs. But if the semantics of the
communication are intimate enough, exchanging complex internal data
structures, that too could be a basis to consider the two parts as
combined into a larger program.

Also:

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.

The difference between this and "incorporat ing" 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.

And:

If the program dynamically links plug-ins, and they make function
calls to each other and share data structures, we believe they form
a single program, so plug-ins must be treated as extensions to the
main program. This means that linking the GPL-covered plug-in with
the main program would violate the GPL. However, you can resolve
that legal problem by adding an exception to your program's license
which gives permission to link it with the non-free main program.

Which is from the GNU.org FAQ. here:

http://www.fsf.org/licenses/gpl-faq.html

Now, the first two quotes don't explicitly state that, in the event that
you let *someone else* distribute the GPL software, you are okay with
using direct and intimate communication (which the Python module being
discussed would, I think, qualify as). However, that is the image that
arises. That is, if you are not distributing the GPL software you might
be okay, if not for that third paragraph.

The first two quotes suggest that, if your software links "intimately "
with the GPL software and you distribute both pieces of software (even
though only "alongside" one another, (such as two download links from a
web-site?)), though, then your package is a derivative work and thus
GPL-requiring.

The third quote, however, goes much farther. A plug-in, presumably
downloaded entirely separately from an application (hence plug-in) is
somehow able to violate the license of the plug-in merely by being
loaded by the proprietary application, effectively by being "linked in"
by the user. In the situation we are describing, a GPL library with an
arguably more intimate linking (the Pythonic interface) is being loaded
into a proprietary application, we would seem to have met all of the
conditions outlined in that third paragraph (and more).

To make that work, the using application somehow has to be a derivative
work of the plug-in, which, particularly in the case of a plug-in API,
makes no sense, after all, the plug-in API is from the application and
almost certainly has no code specific to the GPL-licensed plug-in. What
would stop a user from using the plug-in with the application?

How this works, (other than wishful thinking) I don't know, as it had
been my impression that the unmodified use of GPL software on your own
computer wasn't affected by the GPL. The strange thing about the third
quote is that, from the GPL section 0 (the FAQ has no legal weight AFAIK):

Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the
Program is covered only if its contents constitute a work based on
the Program (independent of having been made by running the
Program). Whether that is true depends on what the Program does.

which seems to allow the *end user* to combine proprietary code with
unmodified GPL-licensed software for their own use.

As mentioned in the earlier message, I don't think there's been too much
case law saying that you can claim copyright on something which doesn't
include any of your code, the LGPL even explicitly states (section 5),
if there's no LGPL code in the given element, then it is not a
derivative work. Still, there must be some logic which makes the
application above somehow a derivative of its plug-in. Though again, I
was under the impression that, for personal use, you could create
derivatives which linked against proprietary code (even intimately)...

Anywho, hope that's sufficient, must be off to write now.
Mike

(In case anyone is silly enough to think I were... "I am not a lawyer")

_______________ _______________ _________
Mike C. Fletcher
Designer, VR Plumber, Coder

http://members.rogers.com/mcfletch/