It looks like the actual library to read/write an encrypted SQLite DB is licensed separately from the open source SQLite[1], so even if you have the encryption key, you can't access the encrypted format:

1: https://www.sqlite.org/see/doc/release/www/readme.wiki

> I'm not going to hold "encrypting a file format so that people can't easily reverse engineer it" against folks who are trying to sell software.

I think I'd mostly disagree. Selling an application is one thing, but the data itself is usually customers' and holding their data hostage is not a proper thing to do.

That's a tenuous argument at best, heavily relying on the application in question not offering any way to export your data, which many applications do come with. Just because the file format is locked, doesn't mean the data in it is locked. You just need the application to unlock it.

This is self contradictory.

Listen to what you're saying: the data isn't locked, you just need the... application, to... unlock it.

That's beyond tenuous, it's invalid.

Almost as if different clauses can impart different context to the same word. The data is not locked, provided you have the application that manages that data. If you want to call it "locked" then "the application itself turns it into unlocked data for you".

That argument that a proprietary file format "locks" data ignores the fact that it's the pair {application, file} that determines whether your data is locked away or not. For instance: Microsoft Word data? not locked. You can trivially export it in quite a lot of ways. Can you easily get it from a traditional .doc file? Hell no, but that doesn't mean the data itself is inaccessible. Instead of using sqlite, or xslt, or PERL, or whatever, you use word.

You can say it's invalid but it's the fact of the matter, the reality, and since the data in question is only in the app because the owner of the data has access to the app it means that the data is not locked away from the owner, because they have access to the export function.

I guess he/she meant that the extension that encrypts the database is proprietary. I believe that was the only option for a while but now there is an open source alternative.

Is the open-source alternative bidirectionally interoperable with the closed-source version (i.e. it can decrypt the proprietary encryption and the proprietary version can decrypt the FOSS version)? If so, then that's handy.

The "officially blessed" (my wording) encryption for SQLite is SEE (proprietary):

https://www.sqlite.org/see/doc/release/www/index.wiki

There are third party encryption approaches for SQLite. One of the most popular is SQLCipher:

https://github.com/sqlcipher/sqlcipher/

Those two don't have compatible file formats. eg no interoperability

Not sure if any others do, but yeah it would be handy if there are.