I was excited about it and had it in my "check it out for next project" list. Then saw that they were adding "ads" or some arbitrary junk to headers to annoy users into considering a paid tier. I never bothered to look at it again. I saw that the ads thing was removed, but the project lost that bit of trust to be considered seriously after that. It may be a wonderful thing that I am missing out on. But, just saying how my thought process went.

I will perhaps try it for some toy projects. But, I will have to watch the words with oil in eyes before using it in any serious projects. If I don't have the time to do that diligence, then this thing will not be considered.... This is the cost of losing trust with potential users.

The "ads" were a simple Caddy-Sponsors header being sent on every HTTP response, containing the string "This free web server is made possible by its sponsors: Minio, Uptime Robot, and Sourcegraph". It could be removed (legally, the license allows it) by compiling from source. This whole thing was largely a non-issue, and overblown.

The bigger issue that came with it was a website redesign that was fairly misleading (it looked like Caddy was going to be closed source), but when it was pointed out, it was clarified to clearly point out that Caddy is a Free and Open Source Software. To me, this reinforced my trust in the project. They went the wrong way, people didn't like it, they fixed it.

The fact that, in today's world, a single misstep generates an immediate and irrevocable loss of trust, even when that misstep is quickly corrected and apologies are issued, is incredibly weird to me. It pushes people to hide their mistakes instead of being open about them...

Disclaimer: I'm a happy user of Caddy, using self-built binaries. I'll take this chance to thank the developers behind Caddy. You have made my life a lot easier :).

> The fact that, in today's world, a single misstep generates an immediate and irrevocable loss of trust, even when that misstep is quickly corrected and apologies are issued, is incredibly weird to me. It pushes people to hide their mistakes instead of being open about them...

This happened in the past too. What people did in the past was "move to another town", but in the age of the Internet you can't really run away from your public gaffes.

In this particular case, it's commendable that Caddy reversed course on the ads. However, many people's first exposure to Caddy was this ad story and it is extremely hard to change first impressions.

Hi. I did not mean to judge the software itself. It probably is very good. I was only airing my concern when a mistake of this kind was made. It is not this specific thing that was reverted that prompted several people to voice their concern - it is this category of mistake. If the author thinks it is okay to pin up an ad to the headers, what other silly and immature things would the author like to do in future?! That is the line of thought that puts me off.

This is not to say people don't correct their mistakes. I will of course take this software on its merit, but as I said in my original comment, I will now be extra careful before choosing this software for anything I care deeply about, and if I don't have such time, I simply will take the hard way and use something else.

A mistake like this does not provoke irrevocable loss of trust to me. This category of mistake warrants a big red beware sign in front of the product. I don't think that's bad.

IIRC it's generally a bad practice if your HTTP responses reveal what your tech stack looks like. Not great for security.

There are plenty of other ways to fingerprint an HTTP server other than relying on a customisable `Server` header.

Security through obscurity won't help you when someone actually wants to know which server you're using.

Security only through obscurity won't help you much, yes. No need to make things any easier though.

Exactly. Why take an unnecessary risk?

Very important excerpt:

> Beginning today, commercial licenses are no longer required for commercial use of any Caddy binaries.

> Now that version 1.0 is tagged, we will see about working on integrations with Digital Ocean, various Linux distros and package managers, and making an official Docker container.

So it seems that if you use the Docker container or an APT repository, there is no need for a subscription. However if you pull from their infrastructure you need to pay. Interesting way to muddy the waters and extract money from those who don't understand the situation.

That's not correct. To clarify the facts:

- You can always build from source, and you could have always built from source, for free, for commercial use, since the source code is and has always been Apache licensed.

- 3rd-party distribution channels such as Digital Ocean images, Linux package managers, Docker, etc, have nothing to do with commercial or free use.

- Using our official download page (or getcaddy.com) for commercial purposes requires a subscription.

The Caddy source code is hosted on GitHub, not on your infrastructure AFAICT. If that changed, then what you wrote is different from what I wrote. Otherwise, nothing written in the previous comment differs from what you just wrote.

Your comment does not qualify "need to pay", which is only required for commercial users.

If Caddy is as unpopular as HN makes it look, then that's probably nobody. Right?

Just to be clear: it seems that the same exact binaries distributed via a docker image or through standard distro packages managers are free for commercial use. The difference is that obtaining it from you directly costs money. This is a part of the business model that HN users would likely find distasteful. You're charging people who aren't technically competent enough to realize that other places offer the same exact binaries for free. Why even permit the side channels in the first place?

That's also an incorrect characterization. Those 3rd-party channels do not give you the power to customize Caddy the way our build infrastructure does. Try customizing Caddy with plugins through apt or DO images and let us know if you find a way to do that!

I understand other projects have similar compilation requirements but now you're just spinning a technical difficulty as a feature.

The fact people are still having trouble understanding your licensing terms should give you pause.

No ads, that's been long gone, but there's still a "Server: Caddy" header. That's easily removed with "header / -Server" in your Caddyfile. Note that it isn't removed from redirects from HTTP to HTTPS, which is an edgecase, if you're concerned about that (you shouldn't be, honestly).

It's a shame that I only learned when they added the ads and not when they removed them.

Merci

Yeah, it's a shame that the bad publicity gets more visibility than the good on HN sometimes.

That's not only on HN, it's everywhere and should be quite expected as a fact of life.

That's why companies are usually careful about damaging their reputations (just like humans): earning points is much harder.

After customers have written your company off, it'll take much more resources to bring them back.

Big news! Very exciting to see Caddy push forwards.

This is great news!

Thank you Matt, and everyone else who has contributed to such an amazing project :)

Really happy to read that OS packages will be available. Thanks for responding to feedback!

All of these changes look great.

What does Caddy offer over truly open source projects like Traefik?

I'm ready to answer your question, but define "truly open source" for me first.

FOSS, in the sense of freedom of speech as much as beer. Hinky enterprise license requirements for builds, their previous banner on non-enterprise versions, etc are not truly free, just a different kind of cost.

The enterprise license requirement for Caddy 1.0 is for using their build infrastructure, not for using the build. The banner was something that could trivially be removed (if it was even present this way) by compiling from source.

FOSS doesn't meant the company doesn't deserve to seek a business model. In fact, I applaud Caddy's approach towards finding a business model without interfering with the FOSS nature of the project itself. If you want to avoid Caddy's business model entirely, just build from source.

Which brings me back to my original query - why bother with that nonsense when I can just use Traefik?

If they're fussing with licenses to make money, what's to keep them making future license tweaks that do affect the source?

Traefik also has enterprise licenses. I'm not sure what your point is.

Literally the only thing Caddy has done that has impacted non-enterprise customers was that sponsor header that they removed pretty quickly when the community told them they didn't want it. And enterprise customers have always had the option of compiling from source if they don't want to buy a license.

It sounds like Caddy 2 will be open core. I'm not a fan.

I've been perfectly happy with with the Free Software offerings from NGINX, HAProxy, Redis, and GitLab, despite all of those operating what sounds likely to be a similar business model for enterprise customers.

Probably best to withhold judgment until there's actually something to judge, right?

What are your reservations with such a model? Just curious.

Not OP. Inevitably, most time/development is spent NOT on the core. Cool new features are not added to the core. I understand the business model and why, but it's not something end users like to see.

See Elasticsearch for an example of this. "Oh, you actually want auth on that otherwise entirely public cluster? Oh, well, now you better cough up some money for an enterprise subscription..."

Which is just fine if they weren't taking free contributions from anywhere. Once you start talking about a community building this great thing, your moral bar should much higher for how you treat users.

I'm not aware of it needing root unless somebody else can fill me in?

Ports under 1024, of course, need either root or setcap but that's not specific to caddy.

https://gist.github.com/kennwhite/bcb9e7a5726a74102cc8cae570...

To my knowledge it never had to run as root. On Linux you just give it permission to bind to low ports: https://stackoverflow.com/a/414258

No program needs to run as root. What are you referring to?

Probably because it'll bind to low ports. setcap would fix it for OP.