fidzu : belgium

This is the seventh installment of a series of posts about taking back control of my web presence. In Part 1 I tackle hosting, in Part 2 I do things with DNS. In Part 3 I rediscover Proxmox, in Part 4 I move Mastodon around. In Part 5 I Tunnel All The Things with Pangolin and in Part 6 I sort out where to store code.

As I detailed in my previous posts, I used Let's Encrypt. But, as the astute reader can see, I've been wanting to reduce my dependency on non-European companies.

Let's Encrypt was not high on the list of things to replace - it's free, it works and it is a force for good. It being under US jurisdiction felt mildly annoying.

I recently came across Actalis, a company based in Italy that offers a free plan where you can get unlimited SSL certificates for domain validation via ACME.

Switching my stack over was as simple as registering an account and adding this to my Caddy configuration:

email my-email-address@domain.tld
acme_ca https://acme-api.actalis.com/acme/directory
acme_eab {
  key_id XxxxxxArihquYoJxxxxxx
  mac_key yyyyyyyyKPXMgkkxxxxxxLQaIuGhHQbbbbbb
}

(You'll find both values in the Actalis console.)

After reloading Caddy, I got an error: "Obtain: base64-decoding MAC key: illegal base64 data at input byte 43". A quick search taught me that I had to remove the padding (=) from mac_key.

I also had to update my Certificate Authority Authorization (CAA) DNS records to include issue "actalis.it".

A caddy reload later, my sites were serving Actalis certificates.

12 Jul 2026 4:03pm GMT

MariaDB 13.1 Preview is full of nice things. Some are immediately visible to developers, like the new JSON operators. Some are very useful to DBAs, such as configuration validation. And some are about making security and access control easier to manage. Today, let's look at one of those: DENY, also known as negative grants. Yes, […]

12 Jul 2026 4:03pm GMT

Near the end of most Open Source licenses, usually in capital letters, sits a clause that disclaims almost everything: no warranty, no liability, use at your own risk.

For an organization that depends on that code, the clause is harsh. If the code fails and takes your data or revenue with it, the license owes you nothing. No fix, no refund, and no one to explain what went wrong.

That is the Open Source license doing its job. It makes the code available and protects the people who share it. Without that protection, sharing code could become a gift that backfires: a generous act turned into unlimited legal risk.

But the license can only answer the legal questions: who may use the code, on what terms, and what risk the authors are willing to accept. It cannot tell you what kind of Open Source project you are working with.

Some Open Source is "License-only Open Source": code released under an Open Source license, without active stewardship or any promise of ongoing care. There is no guarantee of updates, fixes, security response, or long-term support.

Other Open Source is "Stewarded Open Source": code cared for as shared infrastructure. Maintainers review contributions, fix bugs, respond to security issues, manage releases, provide long-term support, and much more. Organizations fund maintainers, support core development, donate infrastructure, and absorb costs end users never see.

Both types of projects are Open Source, but they are not the same. A weekend hobby project and business-critical software can ship under the exact same license. Legally, they look identical. Practically, they are worlds apart.

The difference is stewardship. The license makes code available; stewardship makes it dependable. And the more people or organizations depend on a project, the more stewardship it often requires.

Responsibility is the tax on relevance.

Distinguishing license-only from stewarded Open Source gives us the vocabulary to describe two very different realities that the words "Open Source" alone do not capture.

For example, the distinction becomes useful when we talk about contribution. If a company depends on Open Source, should it give back?

For license-only Open Source, the answer is simple: no one is required to contribute. The code was shared freely, without a promise of care or an expectation of return.

For stewarded Open Source, the answer is not so simple. The license may still say the software is provided as-is, used at your own risk. Legally, no one has to contribute back. But there is also an entire layer of stewardship on top of the code: security, release management, infrastructure, governance, marketing, long-term maintenance, and more. People and organizations take on responsibilities well beyond what the license requires so the software can be safer to adopt, easier to upgrade, and dependable in production.

For projects like Drupal, that layer costs millions of dollars a year, and someone pays for every piece of it. I explored this more concretely in Open Source infrastructure deserves a business model and what it costs to run Drupal's infrastructure.

When we call everything simply "Open Source", we hide the difference between code that was simply shared and infrastructure that is being cared for and de-risked. Better language will not solve the funding problem by itself, but it makes the responsibility visible. More honest conversations start there.

12 Jul 2026 4:03pm GMT