My favorite thing about SQLite is the business model. My understanding is the product is free, but they charge for their test suite. If you build hardware that is going to use SQLite, then you should pay for the test suite, and that funds the future development. It is a tautologically perfect business model. Revenue toward a rock solid project pays to make it even more rock solid.
I don't know how much the test suite costs by itself, but it is included in Sqlite Consortium membership, which is a typical open source support-style business model. For $75k, you get almost a month of sqlite developer time and tons of support (eg their home phone numbers). Not a bad deal for companies that want deep sqlite integration or customized versions that fit on tight embedded systems.
Given that SQLite is intended as a replacement for fopen(), I'm not sure how many normal files an application uses (or should use) are (or should be) encrypted. I cannot think of a lot of use cases.
At work we need to because we are distributing map data that was licensed to use under the condition that we don't ship the data unencrypted to the clients, however nonsensical that is, given that you have to distribute the encryption key the same way.
But for use cases like Lightroom which stores its catalog in an SQLite database or Far Manager which stores the config there I very much doubt they should be encrypted by default.
> Given that SQLite is intended as a replacement for fopen(), I'm not sure how many normal files an application uses (or should use) are (or should be) encrypted. I cannot think of a lot of use cases.
SQLite has been under development for thirteen years and has hundreds of releases. I don't think the "feature X? you're doing it wrong, we're just a simple replacement for fopen()!" refrain holds a lot of water at this point.
FTR when you work in the financial industry, all kinds of files and databases get encrypted. I agree that encrypting a file or database is not extremely secure since the decryption key is sure to be nearby, but it's still an important need, there are security audits and all kinds of things that call for encryption when available.
That said, it's the financial industry. If the encryption feature is offered as a paid one, that's not so terrible.
Back in the sands in the time Sun also did this with Java. IIRC the associated license was a great cause of pain for open implementations of the JVM, since without passing the suite you couldn't call yourself Java, and with passing the suite (insert some horrible restriction here I forget)
Without passing the suite, you couldn't get the patent licences, so Sun could put you out of business if they chose to. Sun used the test suite to define what was and wasn't "Java" (you had to pass the whole test suite or you couldn't ship product) & thereby prevented anyone else from using the core language in interesting ways that Sun didn't approve of.
Google did an end-run around these restrictions by using the Dalvik virtual machine instead of the JVM where the crucial patents lurked, so Android didn't have to implement the whole of the Java library before they shipped.
