Re: postgresql vs mysql performance comparison

On Tue, 8 Mar 2005, Scott Marlowe wrote:

> On Tue, 2005-03-08 at 09:06, Shelby Cain wrote:
>> --- Howard Cole <howard(dot)cole(at)selestial(dot)com> wrote:
>>>
>>> Although not appropriate for a speed comparison, you
>>> might want to note
>>> that the use of Mysql versions 4.0 upward now
>>> require commercial license
>>> for clients, which are no longer LGPL, whereas
>>> Postgres is free (BSD
>>> license). This makes transactions per dollar an
>>> interesting statistic
>>> when comparing the Postgres and MySql!
>>>
>>
>> Reading over their site that doesn't appear true for
>> every case. The client libraries are under the GPL
>> and thus any application that links to them would also
>> be covered under the GPL. No commercial license is
>> required unless the terms of the GPL (ie: if you
>> distribute a binary to someone you must also be
>> willing to distribute your source code if asked) a
>> problem.
>
> There have been some statements from MySQL in the past that implied they
> might be taking a narrower view of what "distribution" meant than what
> the GPL was saying. Also, it was impossible for PHP to be packaged with
> MySQL libs due to incompatibilities with the GPL'd mysql connection
> libs. It seems MySQL AB has clarified both on these pages:
>
> http://www.mysql.com/company/legal/licensing/
> http://www.mysql.com/company/legal/licensing/foss-exception.html
> http://www.mysql.com/company/legal/licensing/faq.html
>
> However, Fedora Core 2 still includes MySQL V 3.xx.yy because of the
> issues wth V4.xx.yy's licensing. However, Suse does include the latest
> version. So there's some difference of opinion on the issue from
> different distros.

Or different policies.

One of the biggest problem of their dual licencing policy is that
no one in really interested in provinding them with patches. In other
words, they cannot accept third party contributions so easily.

_My_ patches are going to be, likely, GPL-only. So they can't use
them in their commercial product, unless they make two different
lines (which they claim they don't), or they get a (commercial) licence
from _me_ allowing _them_ to sell a work including _my_ patches.
So in order to accept patches from me, they need a lot of paperwork
(not to mention money, they're gonna pay for being able to sell my
work). Not pratical.

This is not the case of truly GPL software, such as the Linux kernel.
Patches, being a derived work, are GPL and they can include them
anytime.

Note that client libraries are optional. As long the protocol is
openly defined (we have open specs), you can write your own
client layer, and still connect to the GPL server. Which is _the_
thing. Protecting the client library (switching the licence
from LGPL to GPL) makes little sense, IMHO. It greatly reduces
the number of potential users, and protects little value.

If want to develop a commercial application that:
- runs under Linux - I can;
- uses HTTP as protocol, and connects to a GPL-ed web server - I can;
- uses MySQL as a database backend - I can't, unless I rewrite the
client library, or buy a commercial licence from them. Why?

With PostgreSQL you don't have to thing about these issues. A big win.

.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo(at)ESI(dot)it