Pijul – A free and open source distributed version control system

The case is simply that the authors probably have a different view of licensing, and wish that their code remains free software even when integrated in other products. It probably wouldn't help that much in the case of something like Github because Github uses their own version of git.

Depending on the outlook, AGPL is simply there to fix a loophole in the GPL, and rightly so.

Honest question, although on a bit different topic I guess.

Does AGPL prevents some company creating Github like services for Pijul?

Git (and mercurial, and a few others) are snapshot-based. That means that they think of the world as states, with changes between them.

Darcs, and pijul, are patch-based. That means that they think of the world as an ordering of patches. Patches aren't the same as commits: commit orderings, for example, are fixed, whereas patch orderings are computed. They can change when you e..g merge a "branch". Branching is similarly "simpler": a branch is just a collection of patches, not just a single commit with an implicit DAG attached to it.

Math itself isn't necessarily intuitive in every case, but I think their point is this: if their system follows the simplest (i.e. most general) mathematical model, things will be more intuitive (i.e. more special cases == more difficult to reason about).

Let's look at example from math: integers and addition. Addition is pretty general -- there aren't, say, weird special cases when one operand is even, or the current date during calculation is Friday the 13th. Addition is associative and commutative, so I can evaluate a long summation in any order I want, or I could chunk up the calculation and have multiple computers evaluate parts thereof, all without any coordination/locking. It's easy to reason about, because the rules are so general, and generalization is what math is all about.

Now let's look at software: packaging. What are the semantics for package installation for your language/OS? If you install package A and then B, do you end up with the same result as you would by installing B and then A (i.e. is installation commutative)? Many (if not most) package managers can only support one installed version of a package at a time, and thus installation can not be commutative: installing a package will pull in dependencies that will influence package constraint resolution in subsequent installations, so order does matter. Now you have to be careful not to fuck that up when you set up your cluster's configuration management (or, hell, just get what you need installed on your laptop so you can work on a new assigned project). Now, if the package manager in question supported multiple installed versions of a given package (and had a way of "activating" only a subset of all packages for a given project/application), installation would be commutative, freeing you of the burden of installing things just the right way and in just the right order. This is how Nix (OS pkg manager) and the latest Cabal (Haskell pkg manager) work.

So, yes, coming up with a simple, consistent mathematical model for the semantics of your target system will definitely make things more intuitive. It's precisely because most developers are terrible at mathematical reasoning that so much software is so difficult to reason about -- there are tons of unnecessary special cases, when hidden inside all the tangled logic there's secretly a simple set of axioms and theorems that lend themselves to intuitive composition.

If you buy a macOS machine today, it ships with bash3.2 by default. That's the last version that was GPLv2. It is a decade old by now. Some companies most definitely care.