Philosophical difference between SQLite and TH3 source code
(1) By martin2020 on [link] [source]
Hi, I am curious about the philosophy of SQLite regarding free software. I learned that the developers of TH3 have not freed its code, which surprised me, given the commitment to keeping SQLite in the public domain. Is there a philosophical difference between TH3 code and the SQLite code regarding free software? Will TH3 ever be released into the public domain? Thanks.
(2) By Roger Binns (rogerbinns) on in reply to 1 [link] [source]
The SQLite developers do have to eat, have somewhere to live, get healthcare, and all the other things relevant to life. That means they have to charge for something. TH3 is a very good choice.
To be clear - you and all users of SQLite benefit from TH3. Any issue it finds is fixed for everyone with no delay or charge.
A minority want the higher levels of reassurance that the C code really does handle all possible conditions, especially when subsets of SQLite is used. They want proof, and they want to pay to ensure that is the case. Everybody wins.
(3) By martin2020 on in reply to 2 [link] [source]
Of course, SQLite developers should make a good living for their work. SQLite benefits a very large number of people, both developers and end-users of software containing SQLite.
I am under the impression that there is some philosophical underpinning to SQLite being in the public domain. That is, I doubt that Mr. Hipp 100% optimized for profit-generation in his approach to creating SQLite. Instead, I suspect that his values guided him to put SQLite into the public domain.
Is that incorrect? Maybe it is just projection of my own worldview. If not, what about TH3? I believe you are saying that the line needs to be drawn somewhere (in order to make a living), and TH3 is a relatively good choice. But I am curious about the values that inform that decision. For example, some people (e.g. Stallman) uncompromisingly set all of their code free (as far as I know), while others set none of their code free (perhaps by the justification that they need to make a living). The SQLite developers are somewhere in the middle, it seems. So, what free-software-related values are the developers of SQLite committed to, if any, and why do they not apply to TH3?
(6) By Roger Binns (rogerbinns) on in reply to 3 [source]
I am under the impression that there is some philosophical underpinning to SQLite being in the public domain.
I'll refer you to the top of the sqlite3.h
/*
** 2001-09-15
**
** The author disclaims copyright to this source code. In place of
** a legal notice, here is a blessing:
**
** May you do good and not evil.
** May you find forgiveness for yourself and forgive others.
** May you share freely, never taking more than you give.
SQLite and TH3 didn't happen at the same time. Scroll all the way to the end of https://www.sqlite.org/changes.html to see what happened over time. Going entirely on my memory which is almost certainly wrong, SQLite was already thoroughly tested, and TH3 was added in ~2009 duplicating test effort and the folks wanting that paid for it.
(4.1) By martin2020 on edited from 4.0 in reply to 1 [link] [source]
To avoid an XY problem (e.g., https://xyproblem.info/), I should explain what my goal is (EDIT:) led me to look into SQLite testing (END).
I am starting a C project and would like to have unit tests. So, I thought SQLite might offer a great example of how to test. But perhaps TH3 is mostly specific to SQLite3 anyway and wouldn't be useful to me?
I will try to read some of the SQLite TCL tests that are in the public domain, and maybe that will give me some insight on how to write my tests.
(5) By Simon Slavin (slavin) on in reply to 4.1 [link] [source]
I can't answer your specific question, but I'll write around it a little.
As you can see from
https://www.sqlite.org/testing.html
TH3 is just one of the ways SQLite is tested. A lot of the testing code is published using the same terms as SQLite itself – in fact, it's part of the full SQLite download. TH3 is highly specific to SQLite itself. Other test are more general and could be applied to any SQL implementation.
It's worth saying that the set of tests mentioned on the above page are almost as important as the source code for SQLite itself. They include tests for bugs which appeared in previous versions of SQLite but have been fixed. This allows the devs to check that bugs don't get 'unfixed'. The fuzzing tests check for ways to crash SQLite and thereby crash anything calling SQLite. These things have helped fix countless bugs at source by people who understand the code, rather than the extremely inefficient process of taking incomplete bug reports from users with other priorities.
With regard to the 'open source' nature of SQLite, it's not the same as most open source projects. SQLite does not expect (and usually won't accept) code contributions from people outside the developer team. This is to ensure, among other things, that the whole codebase is free of legal complications, because none of it is derived from trammelled code. The reason for SQLite being open is to allow users to understand unexpected behaviour and figure out things they think may be bugs. It also allows companies to state that they have full access to the source for everything they use, which means they can accept certain contracts with government and military users. It is for these reasons that SQLite is Open Source, not because the developers are looking for code contributions.
(7) By Roger Binns (rogerbinns) on in reply to 4.1 [link] [source]
I am starting a C project and would like to have unit tests. So, I thought SQLite might offer a great example of how to test. But perhaps TH3 is mostly specific to SQLite3 anyway and wouldn't be useful to me?
Since you are just starting you have the luxury of design and implementation for testing up front. Test driven development is a development approach where the primary focus is on testability, and then the implementation code, not the other way round.
Your biggest problem won't be tests, but actually completing your project and having it still be relevant.