wedge

Wait'll you hear about: - https://github.com/WedgeServer/wedge - https://github.com/tmpim/casket Both forks of Caddy...

> The docs were brilliant for v1, it wouldn't surprise me if they were the spec for a great user experience and the code came second. I agree with this, v1 was an excellent user experience, I actually ran it on my servers for way too long. There was also the Wedge fork which might have helped with the EOL but sadly it didn't go anywhere: https://github.com/WedgeServer/wedge > Despite v2 supporting a very similar config file, the documentation doesn't emphasise that and tries to steer you towards its API, confusing JSON config syntax etc. Others responded to this a bit more, but while I agree that different config types are a confusing experience, at the same time I appreciate that they support something like that in the first place. I might not use it often, but it's nice that you can.

I actually really like Caddy, though some of its defaults at least historically have been odd, such as responding with 200 where other web servers would respond with a 502 or something similar: https://caddy.community/t/why-does-caddy-return-an-empty-200... Also, this is a bit of a personal preference, but v1 Caddy felt like maybe a bit easier to get started with than v2 Caddy, though sadly was abandoned. I'm sure that there were good reasons for doing it, but the few forks that started out from it with the intent to maintain it never really went everywhere, so v2 is the only possibility nowadays, unless you want to maintain it yourself or like dead software: https://github.com/WedgeServer/wedge Of course, that's not a criticism of Caddy itself, just how we as an industry sometimes need rewrites and that makes us keep up with the churn.

This is not the first contentious decision for caddy, and it does already have a fork: https://github.com/WedgeServer/wedge On top of that, "fast, automatic TLS HTTP2 capable web server" is not some complex feat in Go. HTTP2 is already baked into the stdlib, and you can add automatic TLS via LE in a few lines of code: https://godoc.org/golang.org/x/crypto/acme/autocert. A few alternatives: https://github.com/labstack/armor https://github.com/containous/traefik

Have we forgotten about Mozilla/Debian [0,1] already? A hypothetical -- but certainly possible -- scenario: $distro (e.g. Debian, RHEL, Ubuntu) takes the Caddy source, removes the controversial header, builds a binary package, and distributes it as "caddy" via their standard repositories. Light Code Labs doesn't approve of this and asks/demands that $distro stop using the trademark. $distro now has to make a choice: remove the "unapproved" changes from their package, stop distributing their package, or rebrand the software under a different name. (That potentially could have happened here [2,3] but it was quickly resolved well before it got to that point.) I don't think "it doesn't" is correct -- at least not for 100% of cases. [0]: https://en.m.wikipedia.org/wiki/Mozilla_software_rebranded_b... [1]: https://bugs.debian.org/cgi-bin/bugre

> The company that goes and builds this themselves instead of paying a small fee for it, would be a pretty stupid company haha... There is a fork without the adware now, so the smart company will use the fork to get rid of the stupid ads. https://github.com/WedgeServer/wedge

> Second edit: Accusation of trademark violation within an hour of the fork, classy! https://github.com/WedgeServer/wedge/issues/2 This is just like Red Hat. He's put a lot of work into his product, whether free or not, so don't use trademarked name. CentOS has the same restrictions about not using Red Hat in their distribution. This is just like someone releasing a book for free, and getting mad at someone that decides to sell (or give it away) under the same name when they've trademarked the name. Don't do that. If you're going to copy it, change the name. Also, keep in mind a trademark is only good as long as you enforce it. If you don't enforce your trademark, it can be seen as (and argued in court as) having become a generic name, and you lose it.[1] 1: https://en.wikipedia.org/wiki/List_of_generic_and_genericize...

Just wanted to add that we've experimented with Caddy awhile back and, while it didn't suit our needs at the time, the first impression was a good one and I've since kept the project in the back of my mind. However, the responses from the Caddy folks here and at https://github.com/WedgeServer/wedge/issues/2 have been abysmal and without a clear change in course I'd feel embarrassed to recommend it to colleagues. It's not even about the licenses, as others have said, this is just bad form.

Wedge. https://github.com/WedgeServer/wedge

i personally like how one of the first contact bits from caddy to a fork of it is a thinly veiled legal threat: https://github.com/WedgeServer/wedge/issues/2

I said further below that this makes Caddy nonfree, but I was corrected - you can still build Caddy from source, remove the bullshit, and distribute your changes and compiled binaries under Apache 2.0. However, after examining the website more I feel the need to write another comment expressing how poorly this is being handled. The website is very misleading - on the download page, it now asks you to pick a license, and says that the "Personal" version is for only personal use and you need to pay for the commercial version. There's no indication until you click through to the full pricing page that the open source version even exists. On that page, you have the same personal/commercial breakdown, also stating that the personal version is strictly for non-commercial use, but with a sidebar mentioning open source. It assumes you understand

> As of version 0.10.9, Caddy emits an HTTP response header, Caddy-Sponsors, which is similar to the Server header that Caddy already has, except that this one credits our sponsors who make it possible to keep Caddy free for personal use. This header cannot be removed by the Caddyfile, and its presence is required by the non-commercial EULA. This requirement is waived by the commercial license, so the header is not present in those binaries. Really not a fan of this, guess I'll be compiling my own builds from now on. Don't get me wrong, I think charging for commercial licenses (which come with proper support) is a good business model, but my personal site shouldn't suddenly become an advertising outlet. The fact that the headers aren't seen by most non-technical users is moot. I find this practice pretty obnoxious to the point of looking