I’d like to make people aware of something my colleague Daf pointed out to me: one cannot use Python’s SSL code (this also applies to other Python projects such as M2Crypto) in a GPL licensed application because it uses OpenSSL.

The problem resides in OpenSSL’s license which requires :

3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
“This product includes cryptographic software written by
Eric Young (eay@cryptsoft.com)”
The word ‘cryptographic’ can be left out if the routines from the library
being used are not cryptographic related :-).

and (because of its dual license)

3. All advertising materials mentioning features or use of this
software must display the following acknowledgment:
“This product includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit. (http://www.openssl.org/)”

This requirement as been marked as GPL incompatible.  Therefore, any GPL application using it is in license violation. While the OpenSSL FAQ stipulates that you can use it with GPL applications, this opinion is not shared by everyone. This is a quite big unadvertised licensing problem.

Now, I am not a lawyer but I can point to some existing solutions to this problem:

1. Fix Python to not use such a poisonous (to GPL) licensed library.
2. Do not use Python’s SSL code and use other implementations such as python-gnutls.  This solution less appealing as replacement libraries often don’t completely cover python’s API.
3. Relicense your GPL application to “GNU GPL  with the OpenSSL special
   exemption.” (as wget did) and add mentions to OpenSSL in your advertising materials. This solution is sometimes hard to implement as you have to contact all past contributors.

I am proud to announce the release of libchamplain 0.3, the first development release toward 0.4.  libchamplain is a map widget.  It is the work of many months (as far as November) and many contributors since FOSDEM.  Here is a short list of what you get:

• Support for proxies
• Support for custom map sources
• A way to list the available map sources
• Support for 2 new built-in map sources: Cycle Map and Osmarender
• A bunch of new function to allow more control on the UI
• A nicer, more flexible Marker API
• Nicer default markers: they are now grey, have rounded corners and cast a shadow!
• Notification when the view is loading content and when it’s done
• Support for locking down available zoom levels
• A more intelligent cache that can be purged
• Bindings (in the works): Perl, Python, C# and C++

Of course being a development release, the API isn’t entirely stable yet.  For instance, the code surrounding the ChamplainMapSourceDesc introduced this weekend is subject to be reviewed in the next weeks.

Yet, this release is a big step forward introducing a lot of the desired features while leaving some for an upcoming release (such as the ability to draw lines on the map).

You can grab the tarball or clone the source code.  You can read the NEWS or read about the API.

On a side note, libchamplain as been officially proposed as an external dependency for GNOME 2.28.

I’ve got to share what I just found about gtk-doc.  I’ve been using it for months now to document libchamplain’s API.  It was complex to setup but the result is worth it.  Here is my experience about how to get your properties and signals to show up:

• Is my_object_get_type listing in the .types file?
• Is the section correctly identified in your doc and -docs.sgml?
• And today’s discovery: is your object struct declared as a typedef?

To make that last point explicit:

typedef struct
{
  GObject parent;
} MyObject;

will produce minimalistic documentation while

typedef struct _MyObject MyObject;

struct _MyObject
{
  GObject parent;
};

will produce complete documentation with properties, signals and object hierarchy.

Consider yourself warned!