By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,584 Members | 1,803 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,584 IT Pros & Developers. It's quick & easy.

Publish/Subscribe Lib for Python?

P: n/a
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.
Jul 18 '05 #1
Share this Question
Share on Google+
18 Replies


P: n/a
>>>>> "Adrian" == Adrian B <bo**@swirve.com> 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 "subscription", 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/Coo...n/Recipe/81614

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

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #2

P: n/a
Look to Twisted Matrix or possibly Spread (with Python). Quick google
search for either should help.

Enjoy,
Mike

Adrian B. wrote:
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.

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

Jul 18 '05 #3

P: n/a
Adrian B. wrote:
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.


http://ose.sourceforge.net/
Jul 18 '05 #4

P: n/a
Adrian B. wrote:
Does anyone know of a framework or library that will enable me to use
publish/subscribe comms?


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

--Irmen
Jul 18 '05 #5

P: n/a
According to Adrian B. <bo**@swirve.com>:
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?


Just choose any blogging library that takes your fancy.
--
Ng Pheng Siong <ng**@netmemetic.com>

http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL
Jul 18 '05 #6

P: n/a
Ville Vainio <vi***@spammers.com> wrote in message news:<du*************@amadeus.cc.tut.fi>...
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.


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?
Jul 18 '05 #7

P: n/a
Graham Dumpleton wrote:
....
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.

(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
interoperability 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.
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?

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 incompatibilities 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/

Jul 18 '05 #8

P: n/a

On 29/02/2004, at 4:09 PM, Mike C. Fletcher wrote:
Graham Dumpleton wrote:
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?

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 incompatibilities 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.
...


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.
Jul 18 '05 #9

P: n/a
> 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.


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
Jul 18 '05 #10

P: n/a

On 29/02/2004, at 4:09 PM, Mike C. Fletcher wrote:
Graham Dumpleton wrote:
...
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?


...

If I understand correctly, the QPL is basically a dual license
encouraging you to either pay Trolltech or GPL your software.


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.

Jul 18 '05 #11

P: n/a
"Mike C. Fletcher" <mc******@rogers.com> wrote in message
news:ma************************************@python .org...
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).


Can you provide evidence to support this claim?
Jul 18 '05 #12

P: n/a
"Andrew Koenig" <ar*@acm.org> writes:
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).


Can you provide evidence to support this claim?


http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
Jul 18 '05 #13

P: n/a
"Roger Binns" <ro****@rogerbinns.com> wrote in message news:<9t************@home.rogerbinns.com>...
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.


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.


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. :-)
Jul 18 '05 #14

P: n/a
Andrew Koenig wrote:
"Mike C. Fletcher" <mc******@rogers.com> wrote in message
news:ma************************************@pytho n.org...
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).


Can you provide evidence to support this claim?

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#TOCMereAggregation>

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 "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.

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/

Jul 18 '05 #15

P: n/a
Graham Dumpleton wrote:

On 29/02/2004, at 4:09 PM, Mike C. Fletcher wrote:
Graham Dumpleton wrote:
...
If I understand correctly, the QPL is basically a dual license
encouraging you to either pay Trolltech or GPL your software.

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


I had, actually, meant GPL, referring to the effect, rather than the
particular license, though it turns out I'd misunderstood the non-viral
nature of the QPL.
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:
True, it doesn't appear to require QPL licensing of linked works, only
"Open Sourcing" of the works.
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.
Looks that way.
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. :-(
Sure, a patch that deletes 99% of the original (leaving just copyright
notices) is pretty easy to create...
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?


Not me. I stick to BSD licenses as much as is practical. Makes
everything simpler :) . That said, and modulo the annoyance of having
another license to have to read, dropping the 6a and 6b clauses (on the
advice of a lawyer, not me ;) ) would seem to have the desired effect
(no effect on linked code, other than requiring that they be willing to
give the changes back to you). You'd likely want to stipulate "in
source-code form", though.

Anyway, far too much time on this thread tonight. Have fun,
Mike

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

Jul 18 '05 #16

P: n/a
Paul Rubin <http://ph****@NOSPAM.invalid> wrote in message news:<7x************@ruckus.brouhaha.com>...

[Quoting someone else]
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).
"Andrew Koenig" <ar*@acm.org> writes:

Can you provide evidence to support this claim?


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


The question is pretty vague, though: "Does the fact that I link with
your program mean I have to GPL my program?" What that could mean is
that in situations where such linking is certain to take place (ie.
where you also distribute the GPL'd program with the intent that the
two function together), you would need to provide your own program
under the GPL.

I don't believe that there's anything stopping anyone from releasing
their own program separately under their own choice of licence,
although it would be a decent compromise (if not virtually compulsory)
to mention your offer to license that program under the GPL in the
event that the user combines it with the GPL'd program in their own
environment. I'd certainly like to hear of a more substantial
rationale (plus precedents) which contradicts my interpretation.

Paul
Jul 18 '05 #17

P: n/a
> 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.
I am putting in an XML-RPC over SSL interface to allow the BitPim software
and the cell phone to be on different machines. OSE was attractive
because of the SOAP support as well. (I think it would have later
been ruled out due to lack of SSL anyway).

Note section 7 of the Artistic License:

7. C or perl subroutines supplied by you and linked into this Package
shall not be considered part of this Package.
I would like to make a bit of money from the 14 years of work that I
have put into all of this. :-)


Very understandable :-) If only monetizing open source software was
easy!

Roger
Jul 18 '05 #18

P: n/a
"Roger Binns" <ro****@rogerbinns.com> wrote in message news:<7u************@home.rogerbinns.com>...
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.
I am putting in an XML-RPC over SSL interface to allow the BitPim software
and the cell phone to be on different machines. OSE was attractive
because of the SOAP support as well. (I think it would have later
been ruled out due to lack of SSL anyway).


Yep, no SSL support. The SOAP support is pretty basic as well, and is even
a bit broken compared to XML-RPC. This is because the SOAP interface
can't handle empty dictionaries, nor can it handle keys in dictionaries
which aren't valid XML element names. These are problems with the SOAP
XML encoding format, not with the ZSI SOAP toolkit used. The issue of
keys in dictionaries being valid XML names is solved with some encoding
mechanism in later SOAP versions, but am not sure if OSE automatically
picks up the code changes in ZSI for that if present. I know of no solution
to the empty dictionary problem. The basic problem is that at the other
end it will decode as an empty string instead.

Overall, OSE is better if your focus is actually C++ rather than Python and
you want the Python wrappers for gluing stuff together and for add ons. If
only using Python, you do get lumbered with a lot of extra baggage you
don't really need.
Note section 7 of the Artistic License:

7. C or perl subroutines supplied by you and linked into this Package
shall not be considered part of this Package.


You might want to look at the Artistic License 2.0. Its version of this
clause is somewhat better written. Also, the Original Artistic License
does get a lot of criticism because it has loopholes and is not actually
deemed as being GPL compatible nor really a free software license. It
only appears in the list of free software licenses because the criteria
was relaxed in a certain way such that it was acceptable. There was
conjecture that in time the criteria would be tightened and as a result
the Original Artistic License would not longer be classifiable as a free
software license.

People will probably start to wonder what bullshit I am talking here and
I may well be. I can't remember where, but I saw comments to this
effect in my browsing in the last day when trying to find commentaries
on the Artistic License 2.0.

Unfortunately I still don't quite know what the idea of 4 (c) as an option
in clause 4 is mean't to be at:

4 (c) permit and encourage anyone who receives a copy of the Modified
Version permission to make your modifications Freely Available in
some specific way.

I see the Artistic License 2.0 as being possibly a good choice for what I
do, but that one only has to satsify ONE of the parts of each of clause 4
and 6 worries me a bit as I feel that some of the choices really let people
off very easily and may cause me conflict with other licenses I have to
satisfy. I even saw one comment by someone which I am not at all sure
about, which suggest that the Artistic License 2.0 was worded in such
a way that it didn't prevent someone taking what you had done and then
relicensing it under the GPL. If that is possible, that would not be good
for me as you have lost any gaurantees of being able to preserve the
intergrity of the overall package. So damn confusing at times, but then
one shouldn't trust what people on the net say anyway on such things.
I would like to make a bit of money from the 14 years of work that I
have put into all of this. :-)


Very understandable :-) If only monetizing open source software was
easy!


I'd say it is nigh on impossible if what you are providing is nuts and bolts
components. Yes it may be possible if what you have is an end user
application, but if it is just glue .....
Jul 18 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.