Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SQLite builds for WASI since 3.41.0

wasmlabs.dev

Post reply on HN
Print view View original

11–20 of 49 posts

Re: SQLite builds for WASI since 3.41.0

#11

Post by fastball »

aargh_aargh wrote: post #2

What would you use this for? I don't get the whole picture and the article doesn't talk about it.

The goal of WASI is to add a standardized system API to WebAssembly, allowing you to access underlying systems (filesystem, networking, etc) in a homomorphic and secure way.

In practice, this means that you can compile your Rust/C++/etc code to WASM + WASI, and that code will run anywhere you have a WebAssembly VM. So the same code that accesses the "filesystem" in a browser context can also access the filesystem in a desktop/mobile/edge/etc environment.

You could also think of it as an attempt to turn WebAssembly into a fully-fledged JVM alternative. Compile once, run anywhere (including browser).

For this specifically, it means that SQLite can integrate with WASI APIs (instead of only Web APIs as before) so that an SQLite Wasm build can run in other contexts besides browsers.

Re: SQLite builds for WASI since 3.41.0

#12

Post by jraph »

foota wrote: post #9
raybb wrote: post #5

> For legal reasons, we could not contribute directly (their patches) What were the legal reasons?

Looks like this: https://www.sqlite.org/copyright.html Kind of weird, couldn't they use a CLA?

It's not enough to guarantee the code has not been copied from somewhere / can be released in the public domain. The only way to have this guarantee is to write it yourself.

Re: SQLite builds for WASI since 3.41.0

#13

Post by x-complexity »

jraph wrote: post #10
raybb wrote: post #5

> For legal reasons, we could not contribute directly (their patches) What were the legal reasons?

Most likely what is documented at https://sqlite.org/copyright.html > SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept pa…

This is the one case where NIH syndrome is warranted: Entangled legal issues & legal dependencies are no fun for anyone.

Re: SQLite builds for WASI since 3.41.0

#14

Post by est31 »

foota wrote: post #9
raybb wrote: post #5

> For legal reasons, we could not contribute directly (their patches) What were the legal reasons?

Looks like this: https://www.sqlite.org/copyright.html Kind of weird, couldn't they use a CLA?

A CLA only covers the things you wrote, and while you ensure in the CLA that you only contribute things you wrote and are allowed to license to them, it is possible that you lie, so there is the danger (although a small one), that contributors might upload proprietary code written by others. IANAL

Re: SQLite builds for WASI since 3.41.0

#15

Post by jillesvangurp »

jraph wrote: post #8

> For legal reasons, we could not contribute directly, but we could discuss the required changes with someone from the SQLite team and then iterate with them by testing or commenting. Ah, here's the catch! I knew SQLite didn't accept code contributions, I was suprised they managed to contribute anyway, and then this sentence clarified the situation. So they indeed did not manage to contribute their code itself, but t…

https://www.sqlite.org/copyright.html

To summarize, instead of using one of the OSS licenses, the copyright holders simply declare the source to be in the public domain. In order to preserve that status they don't accept patches unless you submit some signed document that you agree with that.

To make things more complicated, they also use their a relatively niche version management system instead of git. Which would complicate making contributions (if they accepted them).

There's a popular fork that fixes all of these issues: https://github.com/libsql/libsql It is MIT licensed, on Github, and open for contributions.

Kind of a weird legal situation for a popular project like this that so many people depend on to have. Not judging; but it is odd. Seems like a lot of wasted efforts between users, would be contributors, and the people that forked this thing to address all that.

Re: SQLite builds for WASI since 3.41.0

#16

Post by aargh_aargh »

fastball wrote: post #11
aargh_aargh wrote: post #2

What would you use this for? I don't get the whole picture and the article doesn't talk about it.

The goal of WASI is to add a standardized system API to WebAssembly, allowing you to access underlying systems (filesystem, networking, etc) in a homomorphic and secure way. In practice, this means that you can compile your Rust/C++/etc code to WASM + WASI, and that code will run anywhere you have a WebAssembly VM. So the same code that accesses the "filesystem" in a browser context can also access the filesystem in…

What I don't get specifically is what's being implemented here with SQLite. Assuming WASI is an interface an application can call into for things like filesystem access, sockets, does this add SQLite as interface (analogously to sqlite.h) next to these as part of WASI? So SQLite will be "under" the interface, i.e. part of a standard runtime?

How much "batteries included" is this runtime (planned to be)? If I understood this correctly, then there would be a tradeoff with having more batteries included which would imply more functionality for applications but make porting to new targets more work.

Re: SQLite builds for WASI since 3.41.0

#17

Post by jraph »

jillesvangurp wrote: post #15
jraph wrote: post #8

> For legal reasons, we could not contribute directly, but we could discuss the required changes with someone from the SQLite team and then iterate with them by testing or commenting. Ah, here's the catch! I knew SQLite didn't accept code contributions, I was suprised they managed to contribute anyway, and then this sentence clarified the situation. So they indeed did not manage to contribute their code itself, but t…

https://www.sqlite.org/copyright.html To summarize, instead of using one of the OSS licenses, the copyright holders simply declare the source to be in the public domain. In order to preserve that status they don't accept patches unless you submit some signed document that you agree with that. To make things more complicated, they also use their a relatively niche version management system instead of git. Which would…

> To summarize, instead of using one of the OSS licenses, the copyright holders simply declare the source to be in the public domain. In order to preserve that status they don't accept patches unless you submit some signed document that you agree with that.

Yep, see also this discussion about it in this thread https://news.ycombinator.com/item?id=36054521#36055014

Re: SQLite builds for WASI since 3.41.0

#18

Post by mehdix »

jillesvangurp wrote: post #15
jraph wrote: post #8

> For legal reasons, we could not contribute directly, but we could discuss the required changes with someone from the SQLite team and then iterate with them by testing or commenting. Ah, here's the catch! I knew SQLite didn't accept code contributions, I was suprised they managed to contribute anyway, and then this sentence clarified the situation. So they indeed did not manage to contribute their code itself, but t…

https://www.sqlite.org/copyright.html To summarize, instead of using one of the OSS licenses, the copyright holders simply declare the source to be in the public domain. In order to preserve that status they don't accept patches unless you submit some signed document that you agree with that. To make things more complicated, they also use their a relatively niche version management system instead of git. Which would…

Aren't all those potential limitations, in fact their strengths? They are eating their own dogfood, which works for them. That sounds great to me.

Re: SQLite builds for WASI since 3.41.0

#19

Post by tarruda »

jillesvangurp wrote: post #15
jraph wrote: post #8

> For legal reasons, we could not contribute directly, but we could discuss the required changes with someone from the SQLite team and then iterate with them by testing or commenting. Ah, here's the catch! I knew SQLite didn't accept code contributions, I was suprised they managed to contribute anyway, and then this sentence clarified the situation. So they indeed did not manage to contribute their code itself, but t…

https://www.sqlite.org/copyright.html To summarize, instead of using one of the OSS licenses, the copyright holders simply declare the source to be in the public domain. In order to preserve that status they don't accept patches unless you submit some signed document that you agree with that. To make things more complicated, they also use their a relatively niche version management system instead of git. Which would…

> they also use their a relatively niche version management system instead of git

They use Fossil for source control: https://www2.fossil-scm.org/home/doc/trunk/www/index.wiki

It is a git-like system, but instead of storing objects on the filesystem, it uses a SQLite database.

Has some interesting features:

- Project Management

- Built-in Web Interface

- Single executable

Re: SQLite builds for WASI since 3.41.0

#20

Post by hitekker »

jillesvangurp wrote: post #15
jraph wrote: post #8

> For legal reasons, we could not contribute directly, but we could discuss the required changes with someone from the SQLite team and then iterate with them by testing or commenting. Ah, here's the catch! I knew SQLite didn't accept code contributions, I was suprised they managed to contribute anyway, and then this sentence clarified the situation. So they indeed did not manage to contribute their code itself, but t…

https://www.sqlite.org/copyright.html To summarize, instead of using one of the OSS licenses, the copyright holders simply declare the source to be in the public domain. In order to preserve that status they don't accept patches unless you submit some signed document that you agree with that. To make things more complicated, they also use their a relatively niche version management system instead of git. Which would…

Wait, when did libsql become popular? As I recall, the libsql startup burned some goodwill when they tried to publicly shame SQLite, after forking SQLite and barely changing its code[1]. Looking at the libsql repo today, it looks like the contributors are still on the payroll of that startup.

Beyond that, the insinuation that good OSS must conform to Github social norms is silly given SQLite's track record of success. The maintainers are smart to direct their limited time and resources into development and not into community management or clout-chasing.

[1]https://news.ycombinator.com/item?id=33099222 and https://news.ycombinator.com/item?id=33081159

Post reply on HN