3 ms·

> 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

by jraph 3y ago

> 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 the SQLite team agreed to write this code themselves. I wonder what was the SQLite team's motivation behind this cooperative work.

jillesvangurp 3y ago
https://www.sqlite.org/copyright.html 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 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.
- jraph 3y ago
  > 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 https://news.ycombinator.com/item?id=36054521#36055014
- mehdix 3y ago
  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.
- tarruda 3y ago
  > 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 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
- hitekker 3y ago
  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 https://news.ycombinator.com/item?id=33099222 and https://news.ycombinator.com/item?id=33081159 https://news.ycombinator.com/item?id=33081159
- KronisLV 3y ago
  > 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). The Fossil VCS actually has a page explaining why it was created, instead of just using Git: https://sqlite.org/whynotgit.html https://sqlite.org/whynotgit.html Honestly, a lot of those points make sense, especially how Git is perhaps a little bit more complex and tricky to wrap one's head around than it should be, making you think more about the VCS than just what you want to do. To that end, I'd actually suggest that people have a brief look at Fossil, it even comes with a built in web interface and some common functionality out of the box (vs most folks needing to setup Gitea/GitLab or use GitHub/Bitbucket etc. separately): https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki Of course, realistically, Fossil will be dead in the water for most, given that it's still niche and won't have integrations with any graphical software that some might want to use (e.g. SourceTree, GitKraken, Git Cola exist, but I'm not aware of a rich ecosystem of solutions for Fossil, something like Fuel seems dead https://fuel-scm.org/fossil/brlist https://fuel-scm.org/fossil/brlist), or even with any CI/CD server solutions.
- gorgoiler 3y ago
  From an administrative stance, I’m sure any project would happily consider a patch if you emailed it to them. For local work, you can easily dump a codebase into your favourite version control system, work on it, then generate the final patch using your VCS’s tooling. Iterating towards a working change is as easy (or as hard) as exchanging patches between the feature developer and the committer of the upstream project. It’s a bit old school, but it’s a good workflow to become comfortable with. I regularly patch my own private projects from my work account by emailing patches to my personal address. Once you compress and base64 a change it’s also humbling how little content goes into a piece of work! (This isn’t a rebuttal to the parent post — more a call to arms that patch juggling isn’t as awful as others might think it is.)

by jraph 3y ago

jillesvangurp 3y ago

https://www.sqlite.org/copyright.html 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 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.

jraph 3y ago
> 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 https://news.ycombinator.com/item?id=36054521#36055014
mehdix 3y ago
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.
tarruda 3y ago
> 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 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
hitekker 3y ago
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 https://news.ycombinator.com/item?id=33099222 and https://news.ycombinator.com/item?id=33081159 https://news.ycombinator.com/item?id=33081159
KronisLV 3y ago
> 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). The Fossil VCS actually has a page explaining why it was created, instead of just using Git: https://sqlite.org/whynotgit.html https://sqlite.org/whynotgit.html Honestly, a lot of those points make sense, especially how Git is perhaps a little bit more complex and tricky to wrap one's head around than it should be, making you think more about the VCS than just what you want to do. To that end, I'd actually suggest that people have a brief look at Fossil, it even comes with a built in web interface and some common functionality out of the box (vs most folks needing to setup Gitea/GitLab or use GitHub/Bitbucket etc. separately): https://fossil-scm.org/home/doc/trunk/www/index.wiki https://fossil-scm.org/home/doc/trunk/www/index.wiki Of course, realistically, Fossil will be dead in the water for most, given that it's still niche and won't have integrations with any graphical software that some might want to use (e.g. SourceTree, GitKraken, Git Cola exist, but I'm not aware of a rich ecosystem of solutions for Fossil, something like Fuel seems dead https://fuel-scm.org/fossil/brlist https://fuel-scm.org/fossil/brlist), or even with any CI/CD server solutions.
gorgoiler 3y ago
From an administrative stance, I’m sure any project would happily consider a patch if you emailed it to them. For local work, you can easily dump a codebase into your favourite version control system, work on it, then generate the final patch using your VCS’s tooling. Iterating towards a working change is as easy (or as hard) as exchanging patches between the feature developer and the committer of the upstream project. It’s a bit old school, but it’s a good workflow to become comfortable with. I regularly patch my own private projects from my work account by emailing patches to my personal address. Once you compress and base64 a change it’s also humbling how little content goes into a piece of work! (This isn’t a rebuttal to the parent post — more a call to arms that patch juggling isn’t as awful as others might think it is.)