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

[strk at refractions.net]

The GPL license is *designed* to forbid it's use in proprietary software.
Looking for workarounds doesn't sound ethical to me.
The problem is in Bizgres, not postgis.
GPL *is* business friendly, as long as your business is human friendly.
(ie: doesn't rely on information hiding).

--strk;

On Sat, Sep 23, 2006 at 12:20:46PM +0200, 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

-- 

 /"\    ASCII Ribbon Campaign
 \ /    Respect for low technology.
  X     Keep e-mail messages readable by any computer system.
 / \    Keep it ASCII.