Re: postgresql vs mysql performance comparison - Mailing list pgsql-general
From | Marco Colombo |
---|---|
Subject | Re: postgresql vs mysql performance comparison |
Date | |
Msg-id | Pine.LNX.4.61.0503081726280.8418@Megathlon.ESI Whole thread Raw |
In response to | Re: postgresql vs mysql performance comparison (Scott Marlowe <smarlowe@g2switchworks.com>) |
Responses |
Re: postgresql vs mysql performance comparison
|
List | pgsql-general |
On Tue, 8 Mar 2005, Scott Marlowe wrote: > On Tue, 2005-03-08 at 09:06, Shelby Cain wrote: >> --- Howard Cole <howard.cole@selestial.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@ESI.it
pgsql-general by date: