libsql

The next blog post can be about how to submit the change to libSQL [1], so other people can take advantage of it. [1] https://github.com/libsql/libsql

From the README in https://github.com/libsql/libsql: > Could SQLite be embedded in the Linux kernel? Choosing to license the fork under Apache-2.0 ensures that this will not happen (via this fork, at least), as the license is considered incompatible with the kernel's GPL-2.0-only license.

> Rejoin core SQLite if its policy changes > We are strong believers in open source that is also open to community contributions. If and when SQLite changes its policy to accept contributions, we will gladly merge our work back into the core product and continue in that space. If libSQL is going Apache-2.0¹ rather than public domain, that seems extremely unlikely. The public domain nature of SQLite is rather important for its deployments. And in fact licensing is a rather important part of why SQLite is closed to contributions (though with some administrative overhead it could be opened to contributions from people from some countries). The fact that this announcement and project documentation seems to make absolutely no mention of the licensing situation perplexes me. —⁂— ¹ As they state in the text; but https://github.com/libsql/libsql/

I don't like how the 'manifesto' presents SQLite's code of ethics as nefarious: We take our code of conduct seriously, and unlike SQLite, we do not substitute it with an unclear alternative. We strive to foster a community that values diversity, equity, and inclusion. We encourage others to speak up if they feel uncomfortable. It seems in bad faith to imply that SQLite is some sort of toxic, anti-diversity space. It's not. it's just a closed-to-contributions open source project. Richard is pretty friendly guy and I'm not certain if efforts have been made to reach out to him here. https://github.com/libsql/libsql/blob/main/README.md

Whether or not this succeeds, I think it's a great effort. SQLite not taking any outside contributions is of course their prerogative. But it would also be cool to see what could happen with a more open development model. And their (libsql) plans around io_uring and Rust for future code both sound like a good start. The way they're going about this fork (described in the repo [0] readme) seems healthy enough for both projects as well. Maybe the biggest challenge though is recreating SQLite's private/proprietary test suite [1]. [0] https://github.com/libsql/libsql [1] https://www.sqlite.org/th3.html