Igor, Happy to help. :) First IANAL and what I'm about to say is a GROSS simplification of intricate intellectual property law so with that in mind. The Sleepycat License basically says, "anything that includes/uses/calls-into Sleepycat Licensed software (in this case Berkeley DB) and is redistributed to a 3rd party must itself be software made available under and open source license (or be in the public domain)." If you write a proprietary application and use the BDB libraries then before you redistribute it to a 3rd party you will need a license to do so. That's the dual license in a nutshell, that's how we make money on BDB products.
Over time the minor differences identified by Roger Binns and others (Mike Owens for instance) will be smoothed out to be as close to SQLite-standard (bug-for-bug, feature-for-feature, behavior-for-behavior) identical except where we are trying to bring new value to SQLite. The goal is for a SQLite programmer or program to switch to BDB SQL and find instant benefit in certain use cases. This is like what happened to MySQL with its various storage engines. Most of the time you just swapped out one for the other and had different storage features available but sometimes there was a bit more leg work to be done. MySQL and SQLite serve different communities, we don't ever expect them to seriously overlap. There is a lot of new storage, data, and processing power in applications on devices that don't do well running a client/server database with a DBA. That's the market for BDB 11gR2 (read: BDB+SQLite). That's how we draw the line, I hope it makes sense to you. Oracle's mobile and embedded database of choice is Berkeley DB 11gR2 (read: BDB+SQLite). We believe that it has the right balance of features/functionality for those environments. The environments being a) in devices, b) in applications needing structured local storage, c) in other places where small+SQL is a win. In all those cases we hope to bring benefit by allowing synchronization of data from SQLite or BDB 11gR2 (read: BDB+SQLite) databases back to Oracle Database datacenters. SAP bought Sybase for their mobile platform which was a mistake when you consider that there is a better/equivalent/low-cost mobile database (which now has an enterprise app management and data sync server) out there that is far more popular and pervasive. This is not an embrace/extend play, we're joining into a successful ecosystem and working to improve it in ways that enterprise customers require (which isn't always the primary focus of SQLite development, and for good reason). We are a good friend and partner to open source project communities. This is a strong and sensible mobile database strategy. If you're not on the steamroller, you're part of the asphalt - right? -greg > -----Original Message----- > From: Igor Sereda [mailto:[email protected]] > Sent: Wednesday, June 23, 2010 8:44 AM > To: [email protected] > Subject: Re: [sqlite] Oracle joins the SQLite Consortium > > > Greg, > > Thanks for the explanation. So it's Sleepycat license, ok, but we still > can't use it in an application with proprietary code, right? > > It would be interesting to track the progress of SQLite/BDB. Roger > Binns has > noted some important issues, but granted those are solved, would you > say > SQLite/BDB is going to be an acceptable solution as an in-process > server-side database? > > Is there a vision how BDB, now with SQLite, fits into the family of > Oracle's > products? Clearly it's far from Oracle Database, but do you foresee > competition with MySQL team? Just asking :) > > Igor > > > > Gregory Burd-2 wrote: > > > > Hello, > > > > My name is Greg, I'm one of the product managers within Oracle > working on > > the Berkeley DB products. I joined Oracle when Sleepycat was > acquired but > > I've been working on BDB for nearly nine years now. I was the one > who > > pushed hard to integrate SQLite and BDB, I think the two products go > well > > together without damaging either one. I am also the guy responsible > for > > most of the messaging on the Oracle.com website (with a lot of > editing > > oversight and marketing input), so if you want to question something > there > > please just email me. > > > > We here in the Berkeley DB team within Oracle's Embedded Database > group > > are thrilled to have Oracle join the SQLite Consortium. Today and in > the > > past our goal with open source collaborations has been to work > closely > > together, help each other out, keep things informal-yet-formal, and > give > > credit where credit is due. The SQLite product is excellent, we > don't > > want or need to fork it. The SQLite3 ANSI C API is like the BDB ANSI > C > > key/value API, de-facto standards in their respective spaces. From > our > > view this combination is like chocolate and peanut butter, two great > > products that go well together. Some will like this combo and find > value > > in it, others won't. That's okay, in fact it's the way it should be. > We > > are thrilled to be joining this community, we're not the enemy or the > > competition. > > > > Clearly there are going to be many questions, I'm here to help answer > them > > as best I can. > > > > > > License: Oracle Berkeley DB is not licensed under the GPL. Berkeley > DB is > > released under the terms of the Sleepycat License. The Sleepycat > License > > is significantly different from the GPL, take a look. > > http://en.wikipedia.org/wiki/Sleepycat_License > > > > Compatibility: "... [the] application-level behavior of the two > products > > is identical..." Okay, this is a bit of an overstatement at this > point > > and I freely admit that. This is our long-term goal, so I think it's > fair > > to put have it on our site. Basically we're telling people that we'd > like > > to be as close to 100% drop-in compatible as possible while still > > providing the unique value of Berkeley DB as a btree storage engine. > For > > our first release, I think you'll have to admit that we are very > close to > > the mark. We're already nearing a patch release and it is even > closer. > > This will evolve, both SQLite and BDB's SQL will benefit along the > way. > > > > Comparison: "... improved performance, concurrency, scalability, and > > reliability." Fundamentally, we are faster because we don't lock the > > entire database on writes as SQLite's btree does. BDB is designed > for > > concurrent multi-process/thread access, this gives us a speed > advantage > > when there is any concurrency in the system. Single-threaded > performance > > is a more apples-to-apples comparison and this is more evenly > matched. > > The product is evolving fast, we're constantly finding ways to use > > advanced features in BDB for special cases in SQLite. Again, we're > only > > just in release 1 of the combined product and we're already in very > good > > shape to be faster in general. > > > > MVCC: We're going to add in support for MVCC (snapshot isolation), > it's > > not there in the first release. This will continue to help speed up > > concurrent access and prevent deadlocks. > > > > HA: Clearly we're going to integrate (in a SQLite-friendly way) > support > > for HA/replication. It's not there in this release. If you have > ideas > > for how to properly make this fit into the product let us know! > Should it > > be a PRAGMA? Should it be C-functions? Something else? Speak up > now. > > > > Compaction: We punted on compaction in the first release because we > wanted > > to do it using BDB's built-in compaction code (which can compact the > > database and optimize the btree while it's being used, it can even do > this > > a little bit at a time so as not to be overly disruptive). We didn't > get > > this into the code line in time for the first release, it's coming > very > > soon. > > > > Compression: BDB has support for compression of things stored in the > > database, this is something we hope to integrate into the SQL API > very > > soon. > > > > Encryption: Again, we are hard at work on this. BDB already supports > > encrypted databases, so it won't be hard to do. > > > > > > We are also working on a comparison paper with Mike Owens (of "The > > Definitive Guide to SQLite" fame). We hope to get this finished very > soon > > and make it available for comment. Mike is doing a great job of > really > > providing a critical view of our combined product, which is exactly > what > > we want. > > > > There is a lot more we're working on, we're focused on a number of > > improvements in BDB itself and in our adaptor layer between BDB and > > SQLite. What's great about this is that for fifteen years we had > avoided > > SQL and just focused on being the best transactional storage engine > around > > and I'd say we did a pretty good job of that. Now we can happily > join > > forces with a great community focused on the SQL piece. SQLite does > an > > amazing job of providing the features of a relational database and > SQL92 > > in a stunningly small package, we hope to add our world-class btree > > storage layer and experience to that package. > > > > We believe that this is good news for everyone, I hope you feel that > way > > too. > > > > -greg > > > > Gregory Burd | Product Manager > > Oracle Database Engineering - Embedded Products, Berkeley DB > > [email protected] or follow me on Twitter or Identi.ca as > @gregburd > > http://blogs.oracle.com/berkeleydb/ > > > -- > View this message in context: http://old.nabble.com/Oracle-joins-the- > SQLite-Consortium-tp28947200p28971317.html > Sent from the SQLite mailing list archive at Nabble.com. > > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
