Header has been removed in upstream

[emersion]

See https://github.com/mholt/caddy/pull/1866

[lol768]

Thanks, @emersion. Just caught up on the notifications on my PR there.

Whilst I'm happy to see the ads gone (though I'm incredibly surprised Matt didn't get explicit consent from the sponsors before doing this), it's unfortunate it took a sponsor pulling out for this to happen. As I've mentioned before, I do like Caddy and want it to succeed going forward.

The issue of the binaries and the restrictive EULA on those binaries remains, I guess. The fact that Mozilla contributed $50k to Caddy under MOSS leaves a bit of a bad taste in my mouth in light of all of the restrictions that are now being applied. I'm of the belief that everyone (regardless of technical ability) should be able to easily set-up HTTPS, whether it's for a personal blog, a sole trader's webstore, a small business or a huge corporation. Forcing all commercial users regardless of nature/size to purchase a license is detrimental to the goal of getting HTTPS deployed everywhere. As an example, if I were to add Google Ads to my blog to try and cover my $5 DigitalOcean droplet costs would I then need to pay over $1000 a year just to be able to use the webserver? Isn't it easier to just not bother, use Apache and keep it being served in plaintext?

With that said, the header was what annoyed me the most here (as I explained on HackerNews). This fork would become redundant if the Caddy folks allowed for unofficial builds to be distributed under the Caddy name - but they've made it clear that they're intending to enforce their trademark once it is registered.

So, at present I'm undecided on what to do. I'd like to see less restrictive terms on the binaries, so that may mean developing a tool that offers "free as in freedom" Wedge binaries (because I can't use the Caddy name) to everyone but with no support. At the same time I'm conscious this undermines what Matt and Cory are trying to do with restricting the binaries.

[mr-tcan]

Just like you, I liked Caddy. But this situation leaves a bit of a bad taste in my mouth, as you sad. Can you maintain this project, make it an official fork and build a community arround it?

Do you know Owncloud? They were forked by Nextcloud and now people use Nextcloud instead Owncloud.

I think we could do the same.

[bugrakoc]

This header and EULA incident is what made me aware of Caddy in the first place. It is particularly useful for low traffic applications. However Caddy is unusable in its current form. With the performance being much behind Nginx and Lighttpd, and the EULA limiting its use, I'd be better off sticking to Lighttpd for small servers. Caddy's only advantage is its ease of use, so building it from source to work around the EULA also doesn't make sense.

That being said, Wedge can overcome this problem by providing usable clean binaries. Nextcloud-Owncloud example of @tscangussu might be far fetched, however you can at least make Wedge like CentOS-RHEL.

[lol768]

Caddy's only advantage is its ease of use, so building it from source to work around the EULA also doesn't make sense. That being said, Wedge can overcome this problem by providing usable clean binaries.

I think we could do the same.

Agreed. I've talked this over with a few people and the state of the binaries and EULA is far from ideal and in my opinion, detrimental to a goal of getting HTTPS deployed everywhere. Let's do it.

Here's a long overdue update on things:

---

@SirCmpwn has been a great help with the build automation side of things. I've started work on a site for the project (FOSS of course, code available here: https://github.com/WedgeServer/website) which will soon be live on wedgeserver.co.uk. Aim is to make the binaries easily obtainable - tick some checkboxes and get a free (as in freedom) binary to deploy with no strings attached. It's also important to me that a copyable/curlable URL is exposed too to aid in automating updates. The website will handle caching builds, interfacing with the build service (see below) and currently contains information on the nature of the project.

Builds will take place on @SirCmpwn's infrastructure and this aspect of the work is still in progress. Happy to report that it's successfully managed to build Wedge already for a variety of platforms :smile: Next step is plugin support and the deployment/plumbing with the site to make things work nicely.

[scalp42]

Any updates on this @lol768 do you know if it still behind maintained?

Trying to prevent more forks.

Thanks in advance!

[Raboo]

The header is gone, so one doesn't need to have a forked project. And it already appears that Wedge is lagging behind. Yes, the binaries and EULA is still a problem. So one can build binaries from the official Caddy code and distribute those freely according to Apache 2.0.

So some sort of automated builder that will host compiled Caddy binaries that doesn't fall under the EULA from https://caddyserver.com/. So just like on https://caddyserver.com/ but without the EULA.

One difficulty would be to get and keep a updated list of available plugins. But I did find this project which seems to have a nice way to get a list of available plugins, https://github.com/abiosoft/caddyplug one could use a similar approach to get a list of plugins.

But then there's still the problem of creating a on-demand compiling backend and a front-end web ui for it.. But it would be a cool project.

[ddevault]

The offer of free infrastructure for builds still stands.

[lol768]

And it already appears that Wedge is lagging behind.

Indeed. I started consulting work a few months back which impacted my ability to work on this and other projects. I still think the licensing situation is not ideal and it'd be great to see a working plugin frontend for this - but I don't anticipate being able to implement this.

[Raboo]

I e-mailed the author behind https://github.com/abiosoft/caddyplug. Perhaps he can help with making a Caddy Builder. If he decides to make the back-end, we can probably cook up a frond-end for it.

[abiosoft]

I think it is better to respond here than to the email.

Caddyplug was an experiment for Go plugins and it actually works but Go plugins are very much unstable. I don't know if the case is different now, I haven't monitored it since then.

With regards to build server, I already made a generic cross platform Caddy binary builder https://github.com/abiosoft/caddy-docker/blob/master/BUILDER.md which leverages Docker. It works for any combinations of plugins and supports all architecture that Go supports. The only limitation it has is that it only builds off master branch of the plugin repositories. The stable version info of plugins are exclusive to caddyserver.com.

I have to be honest here and let you guys know I have been very much involved with Caddy since its early days. So obviously, I have a bias for Caddy over any fork of it. However, I do not mind if any of my tools are beneficial to this project, just like the Caddy project itself is. I am also open to making anything new that works for Caddy and in turn Wedge, as long as it improves the experience of the users.

That being said, if I may ask, what is the goal of this project? The main reason this fork was created has been reversed. I may be wrong but I think the effort in maintaining this fork can be diverted into still having a community managed build server but for Caddy. Core Caddy contributors are still small in numbers and would benefit from the creative thinking happening here.

[ddevault]

The marketing website is still really misleading and employs dark patterns to get people to buy the paid product.

[Raboo]

@abiosoft I can't answer for @lol768 in my opinion I would say that the priorities have shifted, it's no longer interesting have a fork of Caddy.. Just a nice way to build binaries like caddyserver.com without the commercial EULA.

And having free Caddy binaries would be beneficial to Caddy, but perhaps not to the author or company behind Caddy as it would go against their vision.. It's beneficial in the way that people tend to choose the path of least resistance. Last week at work I was setting up a small webserver to host some static assets. I was going to use Caddy, but since I saw it was forbidden to use binaries from caddyserver.com without opening your wallet I went with nginx. So it's beneficial that more people use Caddy as it results in more plugins, bug reports, mentions, Github stars etc.

And the fact that their EULA change pisses me off. A big part of Caddys success is because it is Open Source and it had a free and easy way to download Caddy like most Open Source projects. It has resulted in that people wrote plugins, mentioned it in blogs, etc. I don't believe for one second that there would be so many plugins to Caddy if it weren't for that.

[lol768]

@abiosoft I can't answer for @lol768 in my opinion I would say that the priorities have shifted, it's no longer interesting have a fork of Caddy.. Just a nice way to build binaries like caddyserver.com without the commercial EULA.

You can't answer for me, but our opinions are very similar :smile:

Wedge (the Caddy fork) served its purpose in removing mandatory advertisements - which the advertisers never even consented to! - from a previously pretty decent piece of software.

As long as such anti-features aren't reintroduced, the necessity of a fork is decreased and the EULA is the only issue. However I would warn anyone considering an alternative plugin/build service to think very carefully about branding. I think #2 illustrates the sort of kneejerk reaction you can expect here very well.

[Raboo]

However I would warn anyone considering an alternative plugin/build service to think very carefully about branding. I think #2 illustrates the sort of kneejerk reaction you can expect here very well.

I believe Apache 2.0 License protects us

Caddy plugin makers should pick a license that prohibits distribution of commercial binaries. That would be fun. Forcing them to build Caddy without certain plugins.

[Raboo]

..or a license that requires commercial distribution to provide a 25% kickback of the price. Plugin makers have equal rights to make profit on caddyserver.com binaries.