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

Graham Dumpleton grahamd at dscpl.com.au
Tue Mar 2 00:30:27 EST 2004


"Roger Binns" <rogerb at rogerbinns.com> wrote in message news:<7uhch1-gev.ln1 at 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 .....



More information about the Python-list mailing list