From: | Rick Gigger <rick(at)alpinenetworking(dot)com> |
---|---|
To: | Chad <chadzakary(at)hotmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: I see this as the end of BDB in MySQL without a doubt. |
Date: | 2006-02-15 22:56:36 |
Message-ID: | 3331EA6E-1798-4234-8EF9-F6C5C88D282B@alpinenetworking.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Why doesn't mysql just forget the whole dual licensing of the server
thing and just tell everyone to use the GPL versions of everything.
Then dual license the client libraries which I would think they
already own outright. I think this is what forces most people to
need a commercial license. Do most of their customers really need to
modify the server?
The other thing that most of their customers probably need is just a
support contract in case something goes wrong and to keep the bosses
happy. And that is not really something that oracle can interfere
with (unless they try to buy off all of their employees individually).
Of course they should all just switch to postgres anyway but that is
another story. :)
Rick
On Feb 15, 2006, at 10:05 AM, Chad wrote:
> I am not concerned about Sleepycat revoking their open source license
> for future versions of BDB. I am less concerned about them revoking
> licenses for current and older releases. That would be impossible.
> However this "deal" troubles me and I cant quite put my finger on why.
> I'll try to tease it out. Please bear with me.
>
> As I understand it Sleepycat make most of their money by selling
> commercial licenses to companies who use their stuff but who don't
> want
> to open source their own code. Companies such as these will in the
> future be required to talk to Oracle to negotiate a new license. So
> far
> nothing sinister about this.
>
> However, I see MySQL as the future losers here. I cannot see why else
> Oracle would buy both of the MySQL storage engines other than to
> effectively remove both of them from the MySLQ product suite in future
> releases, thereby weakening it. Im just wondering how they are
> going to
> achieve it though. According to Olson, BDB will still be available
> under the dual license. Lets assume for the moment that at least the
> open source license will still be available. Happy days, unless of
> course the product you own is called "MySQL". Do MySQL or any MySQL
> customers need a commercial license for BDB? I think not. MySQL does
> not as all its code is open source. As for MySQL customers, unless
> they
> are making direct API calls into BDB (which most don't) I don't think
> they are categorized as BDB Api users and so can keep their code
> proprietary without having to answer to Sleepycat/Oracle for a
> commercial license.
>
> Therefore I see only the following mechanisms for Oracle to remove BDB
> from MySQL
> 1. Discontinue BDB
> 2. "Change their mind" about free licensing and start charging
> exorbidant fees for use of BDB, regardless of the type of application
> 3. And I feel if 1 and 2 do not happen then this is the highly
> probably: use a non-compete clause in the BDB license to effectively
> prevent companies like MySQL ever licensing BDB again. Sleepycat
> have a
> similar clause in their own license to prevent companies releasing
> products using BDB which could be seen to compete with Sleepycat. This
> clause will change to refer to Oracle instead of Sleepycat. I
> hasten to
> add this non-compete clause only refers to non-open source
> applications
> today. This will signal the end of relationship between MySQL and BDB.
> Question is: can they put non-compete clauses into open source
> licenses? I dont think so. Maybe Oracle will just proceed with step 2,
> first. Either way there is no way Oracle will allow to continue the
> situation where MySQL gets to use BDB, a world class storage engine
> for
> FREE, as they happily steal customers from Oracle the very company
> that
> now owns said engine.
>
> As of today I consider myself to be an EX-Berkeley DB user/developer.
> What we need now is an open source DB with clean APIs into various
> places in the software stack (eg we need a Berkeley DB kind of API
> under the hood into something like Postgres) A full bells and whistles
> relational DB with these low level ACCESS APIs will be a powerfull
> thing in the future. PostgreSQL take note. If you don't already
> have it
> you should begin exposing such a thing today in my humble opinion.
>
> Being part of a big company changes you. This deal may stifle
> innovation in BDB going forward. If so there is an opportunity to fill
> that gap. I turn to the PostgreSQL community to rise to the challenge.
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-02-15 23:09:37 | Re: Multiple-index optimization not working for = ANY operator |
Previous Message | Jimmy Choi | 2006-02-15 22:56:05 | Multiple-index optimization not working for = ANY operator |