Live data from Hacker News

Announcing Caddy Commercial Licenses

caddyserver.com

21–30 of 295 posts

Re: Announcing Caddy Commercial Licenses

#21
I completely understand this direction, and really appreciate the work mholt and team has put into Caddy, but I'm disappointed at the same time. I looked forward to spinning up my dumb ideas tied with commerce using Caddy (on a 0 budget).

I've been a Caddy evangelist ever since discovering the powers (auto HTTPS, git webhooks, simple config, etc.), I had plans to write blogs about simple sites for simple ideas that can generate money - but nothing that would allow me to swing $100/mo.

I understand that I can compile the source and remain compliant, however, part of the charm was the simplicity once paired with docker for rapid dev/deployment.

Does anyone know if there's significant pain in maintaining a docker image that compiles source code like Caddy on rebuild?

Re: Announcing Caddy Commercial Licenses

#22
> If you use Caddy for personal, academic, or non-profit purposes, not much is different. Just a new response header that gives tribute to our sponsors.

So now there will be ads even in the HTTP headers.

Coming soon, ads in the tcp headers ...

Re: Announcing Caddy Commercial Licenses

#23
> 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 at NGINX Plus for commercial use instead.

Edit: Here's my fork 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

Re: Announcing Caddy Commercial Licenses

#24

> If you use Caddy for personal, academic, or non-profit purposes, not much is different. Caddy-Sponsors HTTP Header > If you use or distribute official Caddy binaries at work, or as part of a product/service, you will need a commercial license If I have some personal project which I want to incorporate I need to worry about the license. Oh, time to switch back to NGINX. Thanks for automated HTTPS while it lasted.

This is incorrect, or at least only half-true. Caddy is still Apache 2.0 licensed. You can use it for free for commercial purposes. You just can't use the build server at caddyserver.com to download a precompiled Caddy with plugins. Instead, you can download the source, compile it with plugins yourself, then distribute your own binary amongst all your hosts.

Yeah, I guess you're right. But then again setting up NGINX with auto SSL would be easier so what's the point.

Personally for me Caddy is (was) good because of how easy it is to set it up.

Re: Announcing Caddy Commercial Licenses

#25
post #3

> 1/4 price of comparable servers Which servers?

Wondering the same thing... nginx has a commercial option, but does not force you to use it if your using it in a business environment... iis is only available on windows server, and that costs about 600 quid for a standard license. That’s a one off cost... so... it might be quarter of the cost of enterprise (3k give or take) but over the life time of the box, it would end up being more...

Caddy's new commercial licensing, like nginx, is completely optional as the actual source license continues to be Apache 2.0.

For any business running their own web servers, compiling Caddy themselves instead of utilizing the build server at caddyserver.com is a trivial step that also gives them greater control over the binary they end up using anyway.

Re: Announcing Caddy Commercial Licenses

#26
post #18

This is all great, I hope this turns into a viable business. But I am just not sure about the approach here. Maybe this is a good moment for someone to finally fork Caddy, remove the Sponsors header, and distribute proper RPMs and DEBs. Then those of us who want to use a truly open source project with no strings attached (special conditions re binaries, EULA, etc.) have nothing to worry about.

I've been praying for proper distribution channels for installs. For a project that is all about simplicity in setup, the installation is such a hassle. Manually creating startup entries, directories, process users, horrible.

Re: Announcing Caddy Commercial Licenses

#27

I completely understand this direction, and really appreciate the work mholt and team has put into Caddy, but I'm disappointed at the same time. I looked forward to spinning up my dumb ideas tied with commerce using Caddy (on a 0 budget). I've been a Caddy evangelist ever since discovering the powers (auto HTTPS, git webhooks, simple config, etc.), I had plans to write blogs about simple sites for simple ideas that c…

I couldn't agree more. The terms seem overly restrictive.

Let's hope that they don't "go after" anyone who's not compliant and that this is silently a scheme to force bigger companies into compliance and let the rest of us fly under the radar.

As-is, I would owe Caddy $300/month - none of my side projects can sustain that, so I'll be switching back to nginx and some LE cronjobs.

Re: Announcing Caddy Commercial Licenses

#28
post #23

> 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 p…

Thanks for your feedback. I'd like to know more.

> The fact that the headers aren't seen by most non-technical users is moot.

Why's that? (And even among your technical visitors, how many of them actually inspect the response headers?)

> I find this practice pretty obnoxious to the point of looking at NGINX Plus for commercial use instead.

It's good to know that price isn't the bottleneck, then. Does it make any difference to know that commercially-licensed Caddy builds don't have that header?

Re: Announcing Caddy Commercial Licenses

#29

Earlier quoted context omitted.

This is incorrect, or at least only half-true. Caddy is still Apache 2.0 licensed. You can use it for free for commercial purposes. You just can't use the build server at caddyserver.com to download a precompiled Caddy with plugins. Instead, you can download the source, compile it with plugins yourself, then distribute your own binary amongst all your hosts.

Yeah, I guess you're right. But then again setting up NGINX with auto SSL would be easier so what's the point. Personally for me Caddy is (was) good because of how easy it is to set it up.

I'm not sure I agree with you there.

The most popular Docker image for Caddy, for example, should soon (if it's not already) be compiled from source, rather than from the build server. That means it will remain free to use, and I personally don't have to make a single change.

If this has impacted you negatively to the point where setting up nginx is an easier option, well - that's the beauty of choice!

Re: Announcing Caddy Commercial Licenses

#30
post #28
post #23

> 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 p…

Thanks for your feedback. I'd like to know more. > The fact that the headers aren't seen by most non-technical users is moot. Why's that? (And even among your technical visitors, how many of them actually inspect the response headers?) > I find this practice pretty obnoxious to the point of looking at NGINX Plus for commercial use instead. It's good to know that price isn't the bottleneck, then. Does it make any diff…

> And even among your technical visitors, how many of them actually inspect the response headers?

I find that a bit disingenuous. You can't both include annoying headers and argue that they aren't annoying anyone because nobody will see them. If nobody will see them, why add them in the first place?

Post reply on HN