On: SQLite: QEMU All over Again?

[mmastrac]

Has sqlite been forked before? This is the first true fork and re-license attempt that's caught my eye. The others I've seen are "ports" and "modifications", but always pointing people back upstream.

It's possible that the appetite for a SQLite fork is there, but nobody has provided it.

[gaius_baltar → mmastrac]

> Has sqlite been forked before?

There is a fork called SQLCipher with native encryption. Probably lots of others too, but this one is the one that I remember.

[vhanda → mmastrac]

I do remember the author of LMDB [0] porting some parts of sqlite to use lmdb instead, and then talking about the results. A quick googling doesn't seem to give me a result though.

[0] - http://www.lmdb.tech/doc/

[acrispino → vhanda]

https://github.com/LMDB/sqlightning

https://github.com/LumoSQL/LumoSQL

[cryptonector → mmastrac]

TFA lists forks. rqlite comes to mind.

[otoolep → cryptonector]

rqlite[1] author here. I wouldn't consider rqlite a fork in any sense, just so we're clear. That rqlite uses plain vanilla SQLite is one of its key advantages IMHO. Users have no concerns they're not running real SQLite source.

That said, there are some things that would be much easier to do with some changes to the SQLite source. But I think the message that rqlite sits on top of pure SQLite makes is still the right choice.

[1]: https://github.com/rqlite/rqlite

[cryptonector → otoolep]

My mistake. Thanks for the correction!

[yellowapple → cryptonector]

Is rqlite a fork? It strikes me more as an application that uses SQLite as a dependency, rather than a fork of SQLite itself.

[otoolep → yellowapple]

Nope, as explained in my other comment. It is, as you say, built on top of SQLite.