views:

501

answers:

4

I always get confused with licenses, I'm reading up again, but I'm sure someone out there already understands this and may be able to explain it more clearly.

I'm trying to get my company to use geodjango, and being a typical large enterprise company they don't want to open-source the resulting project. And therefore opposed to touching anything stamped "GPL".

Looking at the geodjango stack with the recommended postgresql the licenses are:

Django - BSD license

Postgresql - BSD license

PostGIS - GPL

GEOS - LGPL

PROJ.4 - MIT license

GDAL - MIT/X license

psycopg2 - GPL

The wikipedia entry on gpl says the following:

Many of the most common free software licenses, such as the original MIT/X license, the BSD license (in its current 3-clause form), and the LGPL, are "GPL-compatible". That is, their code can be combined with a program under the GPL without conflict (the new combination would have the GPL applied to the whole).

From wikipedia's GPL entry, "Compatibility and multi-licensing": http://en.wikipedia.org/wiki/Gpl

Does using psycopg2/PostGIS components with geodjango, make the resulting project's license GPL? If so, what are the alternatives?

UPDATE

psycopg2 has a clause to specifically address how GPL is applied, thanks piquadrat.

+2  A: 

Foreward: You need to ask your company's lawyers about this. Few of us are qualified to answer. Another option is to ask the owners of each of these projects what is and is not an acceptable use.

That out of the way, the license of your project is only affected by the licenses of works from which it is derived. A good test for this is how easily the supposed origin work could be substituted for an alternative.

PostGIS is gpl, but as it turns out, geodjango has support for MySQL and Oracle. If these other databases can work for your project, even if that causes some minor loss of functionality, ("queries are slow!?"), you are probably ok. Since psycopg2 is your interface to PostgreSQL, then if you substitute another db, you also are substituting psycopg2 for something else as well.

On the other hand, your project is likely to integrate rather tightly with Django. fortunately, the BSD license allows you create derivative works, so long as you follow some fairly friendly requirements.

TokenMacGuy
Yes, it comes down to internal review, but I'd like to get a feel what the common belief is, to see if it's worth even approaching them.
monkut
+3  A: 

You might ask Justin Bronn, the creator of GeoDjango, directly. He is also a lawyer that specializes in intellectual property.

http://djangopeople.net/jbronn/

ordord00
+1  A: 

Concerning psycopg2, the situation seems clear. From its LICENSE file:

Note that the GPL was chosen to avoid proprietary adapters based on psycopg code. Using psycopg in a proprietary product (even bundling psycopg with the proprietary product) is fine as long as:

  1. psycopg is called from Python only using only the provided API (i.e., no linking with C code and no C modules based on it); and

  2. all the other points of the GPL are respected (you offer a copy of psycopg2's source code, and so on.)

piquadrat
Ok, thanks, that's one that I might be able to squeeze through the approval process. Any similar conditions for PostGIS? (I couldn't find any...)
monkut
+4  A: 

Disclaimer: the following is my opinion and not intended to be legal advice -- consult a licensed attorney for that.

In general, using psycopg2/PostGIS with your GeoDjango project does not make it subject to the GPLv2. I'll speak about PostGIS since others have already addressed the question as it relates to psycopg2.

Unlike the other geospatial libraries that it uses, GeoDjango does not 'link' to PostGIS. PostgreSQL is what is linked to the PostGIS library (liblwgeom.so), and in doing exposes a wide selection of SQL functions. GeoDjango calls the SQL functions and uses their output to do what it does. Let's examine term 0 of the GPLv2:

This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language.

...

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.

Because GeoDjango is just running PostGIS (by calling its public SQL API functions), and the output of PostGIS is geospatial data and/or numeric values (not source code based on PostGIS) it's clear to me that GeoDjango (or an app built with it) is not covered by the GPL because it is not copying, modifying, distributing, nor a derivative work of GPL code.

Notice I said "in general" at the beginning. If you are distributing your GeoDjango application including psycopg2 and PostGIS, then your code may be subject to the GPL. For web applications this is typically not a problem, because the code is almost never distributed to others like traditional shrink-wrapped software. The code is running on your server, and the only thing your distributing is output of your program (e.g., HTML) to the users (sidebar: this is why I avoid GPL-licensed JavaScript libraries like the plague). This is how Google can keep their heavily-modified Linux kernel to themselves, because their modifications never leave the servers at Google.

Bottom-line: if you are actually selling/distributing a GeoDjango application to end-users (they get a copy of the application), then do not include the GPL-licensed prerequisites to avoid triggering the licensing requirements on your proprietary code. In other words, install those libraries on-site so that you cannot be considered to be "distributing" GPL source/object code with your closed-source application.

Thanks for the clarification this helps a lot. I'll go forward with the internal approval process, and update here with the result.
monkut