Hacker News Reader

Comment by jillesvangurp | Hacker News Reader

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.

View on HN

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

> 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

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

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), or even with any CI/CD server solutions.

> 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

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.

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.)

> 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

Reply on news.ycombinator.com