[postgis-devel] Re: [Bizgres-general] Bizgres MPP and PostGIS

[Paul Ramsey]

A number of issues here:

- Is PostGIS a "patch" to PostgreSQL? No, it is a separate extension,  
which is added at run-time via PostgreSQL type extension mechanism.   
There is no patching to PostgreSQL required to run PostGIS.  PostGIS,  
on the other hand, does require access to a few PostgreSQL header  
files to compile, so there is a dependency, but it runs one way:  
PostGIS depends on PgSQL, not vice versa.

- Is PostGIS available for re-licensing to something other than GPL?   
The answer is probably no.  We have never asked for copyright  
assignment from contributors, and contributors have made their  
contributions on the basis that the project is GPL.  Going back and  
getting assignment for the purpose of re-licensing and addition to a  
proprietary PostgreSQL derivative is not likely to be successful.   
Doing so for some more "idealistic" purpose, like joining OSGEO for  
example, would probably be more feasible.

- Can PostGIS be added to proprietary PostgreSQL distributions?  The  
answer is "yes", within some technical and distribution limitations.   
PostGIS can only be added as a run-time add-on, otherwise as a  
compile-time patch the patched PostgreSQL is clearly a "derived  
product" and would be subject to GPL.  Even as a run-time add-on, it  
is important that PostGIS be distributed separately, not as part of  
the proprietary product offering.  EnterpriseDB has been including  
PostGIS with their offerings on this basis, and that's fine with us.

- Can BizgresMPP do what EnterpriseDB is doing?  The Bizgres folks  
would have to answer, but the technical limitations they point out on  
their web site (no 'C' function definitions, etc) would seem to  
indicate that their parallel enhancements to PostgreSQL have made run- 
time type extension via mechanisms like PostGIS difficult/chancy.  If  
they have maintained the ability to do run-time extension in their  
MPP product, then they could redistribute PostGIS in the same manner  
as EnterpriseDB, as a separate add-on to their proprietary core.

Hope this clarifies,

Paul

On 23-Sep-06, at 3:20 AM, Markus Schaber wrote:

> Hi, Luke,
>
> I'm CC'ing this mail to PostGIS-Devel, as I think that Strk, Paul and
> others may enlighten this discussion with their standpoints.
>
> @postgis-devel: The discussion was about legal (GPL vs. proprietary
> extensions) and technical (Multithreaded backends) problems of running
> PostGIS under Bizgres / Bizgres MPP.
>
> As far as I can see, Bizgres itsself does not impose any problems (as
> it's pure BSD license like PostgreSQL itsself), but MPP has  
> proprietary
> extensions.
>
> Luke Lonergan wrote:
>
>> The complication as I understand it is that Postgres goes through  
>> a patch
>> process to get the PostGIS functionality into it.
>
> As far as I understand the current build process, recent PostGIS
> versions being build against recent PostgreSQL servers using recent
> toolchains only needs the pg_config output, and the "official" headers
> served by pg_config.
>
> The last "patches" against the server I heard from were changed linker
> flags during Postmaster compilation, due to deficiencies in the build
> tools. It was needed to link explicitly against libstdc++, because
> PostGIS pulls libgeos as a dependency (which is in C++). However, the
> dynamic loaders in current GCC/glibc environments can cope with that
> without any patches.
>
>> At that point, there is
>> PostGIS source code in the merged entity, which transfers the GPL
>> restrictions to the source.  At this point, any compiled product  
>> is subject
>> to those restrictions, which force the inclusion of the source  
>> code and the
>> inability to charge for the resulting binaries.
>
> No, there is no inability to charge for resulting binaries. You can
> charge as much as you want.
>
> And there are alternatives to directly including the source with the
> binary.
>
> One can argue about the GPl, and it clearly has its serious flaws, but
> please don't circulage false Myths about the GPL.
>
>> I think that this doesn't preclude an arrangement with the holder  
>> of the GPL
>> license for a special version that we could incorporate into  
>> Bizgres MPP.
>
> AFAICs, several people contributed to PostGIS, not all of them  
> having a
> contract with refractions. And there's no "copyright assignment"
> process, unlike e. G. the GNU projects. So you'll have to find at  
> least
> all substantial contributors, and ask them for permission.
>
> Most of them should be noted in the file headers / copyright notices,
> but nobody will want to guarantee that.
>
>> We are interested in supporting PostGIS with MPP because the  
>> operations it
>> performs would likely benefit greatly from the parallelism of the MPP
>> kernel.
>
> I agree with that.
>
> However, most of the PostGIS code is not even thread safe from my
> knowledge, and far from explicitly parallelized.
>
>> The main impediment so far has been our limited development
>> personnel - all are focused on features desired by our data  
>> warehousing
>> customers.
>
> I see. And as long as you don't have hordes of potential PostGIS
> customers knocking on your door, that won't change. :-)
>
>> There are a couple of ways we can proceed if we have enough demand  
>> for
>> PostGIS MPP:
>> A) We can make a side arrangement with the PostGIS developers to  
>> support a
>> bundle, perhaps even have them do the porting work.
>
> Such an arrangement may be possible.
>
>> B) Perhaps we can perform a service that compiles the code for  
>> each PostGIS
>> MPP customer, places the source code in escrow and we charge an  
>> annual
>> maintenance fee.  I'm not sure if this is still compatible with  
>> GPL, but it
>> seems similar to RedHat and other's approaches.
>
> Maintainance fees are (as well as fees for the binary) completely  
> legal
> under the GPL. That's not what the GPL wants to restrict.
>
>> The biggest difference is
>> that the source code is not made available to the general public  
>> as it is
>> with RedHat, but only to the support customers through the limited
>> conditions of an escrow.
>
> Here's a problem. Due to the GPL, you may not hinder your customers  
> from
> redistributing the source. They must have at least the rights the GPl
> guarantees them, including redistribution under GPL.
>
> One possible idea to workaround this is a binary compatible interface.
> As long as MPP and PostgreSQL are binary compatible, it could be
> possible to dynamically link a Bizgres/PostgreSQL-compiled PostGIS  
> into
> an MPP backend at the customers site.
>
> In my eyes, this is the same case as proprietary applications runnign
> under glibc/Linux, or GPLed applications under Windows / commercial
> unices. However, IANAL.
>
>> Of these two, I far prefer (A).  Even better would be to have the  
>> PostGIS
>> people change their license to LGPL or BSD.
>
> As far as I know some of the main PostGIS developers, they're unlikely
> to agree to such a step, and I personally (and my employer who founded
> my small contributions) tend to see LGPL as acceptable, but not BSD  
> license.
>
> Another possibility could be to add an explicit linking exception
> permitting linkage against non-GPL compatible backend extensions to  
> the
> PostGIS license, as some other projects (including libgcc) have. (Note
> that this is different from the LGPL.)
>
> Thanks,
> Markus
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel