W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: Berkeley DB license (was Re: Points of order on this WG)

From: Chris Anderson <jchris@apache.org>
Date: Tue, 7 Jul 2009 14:59:04 -0700
Message-ID: <e282921e0907071459p79d44aabm4f8a533f80efb050@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>, public-webapps WG <public-webapps@w3.org>, Jeremy Orlow <jorlow@chromium.org>, "L. David Baron" <dbaron@dbaron.org>
On Fri, Jun 26, 2009 at 5:36 PM, Maciej Stachowiak<mjs@apple.com> wrote:
> On Jun 26, 2009, at 3:46 PM, Nikunj R. Mehta wrote:
>> FWIW, I came across two pieces about Oracle's open source licensing of
>> Berkeley DB that might help clear the air around the licensing issues.
>> First, Oracle's license [1] is word-for-word identical to the erstwhile
>> SleepyCat license [2]. Secondly, SleepyCat license "qualifies as a free
>> software license, and is compatible with the GNU General Public License."
>> [3]. Thirdly, the license is OSI approved [4].
>> I am not sure if this resolves issues. It would help if you had comments
>> on the above so that I can keep that in my context while discussing with our
>> legal staff.
> The issue I see with using Berkeley DB for implementation (which I think is
> only a side issue to design of the spec itself) is as follows: Clause 3 of
> the first license (the one with the Oracle copyright notice) appears to have
> stricter source release requirements than LGPL. It's not clear to me what
> exactly the scope of the requirement is, but it doesn't seem to have the
> dynamic linking or relinkable object file exceptions of LGPL. That would be
> a problem for projects like WebKit or Gecko that don't want to impost any
> constraints that go beyond the LGPL in their license terms.

Probably speaking out of turn, but on the larger point that there are
non-BDB implementations that are well suited for the browser
environment. For example, Tokyo Cabinet is a C library for B-tree
databases, licensed under the LGPL.


TC is far from the only clearly licensed storage-engine with lots of
users. Any of them (including BDB) would make a good foundation for
implementing a CouchDB-like replication system in JavaScript. As a
web-developer I would really get a lot out of serious native B-tree
API. The nice thing is that a B-tree API is so simple it'd be easy for
vendors to use any number of engines and still achieve the same spec.


> I don't want to start a huge debate over this, I just wanted to clarify the
> issue I see.
> Regards,
> Maciej

Chris Anderson
Received on Tuesday, 7 July 2009 21:59:44 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:17 UTC