Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Caddy Commercial Licenses

caddyserver.com

Post reply on HN
Print view View original

31–40 of 295 posts

Re: Announcing Caddy Commercial Licenses

#31

Post by Whitestrake »

jimangel wrote: post #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 c…

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

It's insignificant. Multi-stage Dockerfiles mean you can build from the Golang image, pull mholt/caddy, compile to a binary, then distribute the result in a tiny Alpine image.

I believe the maintainer of the current most popular Caddy image will be going source-compiled, too, so you might not even need to roll your own Dockerfile.

Re: Announcing Caddy Commercial Licenses

#32

Post by unkown-unknowns »

mholt wrote: post #11
winter_blue wrote: post #4

Key Quote: To be clear, this EULA applies only to Caddy binaries you download; it does not apply to the source code. Caddy is still open source, and the source code is under the same Apache 2.0 license. Doesn't this mean that you can simply compile Caddy from source, and avoid having to pay for commercial use? Most Caddy users are likely going be comfortable with compiling stuff, so what benefits does paying bring be…

You're right, you can build from source under the Apache license. Keeping the project truly open source is really important to us, because the community is such a great part of using Caddy. Commercial licenses would only cost hundreds of thousands of dollars per year if your organization has at least 160 instances in use. Keep in mind that modifying the source is required to plug in any plugins, which people tend not…

> Keep in mind that modifying the source is required to plug in any plugins, which people tend not to want to bother with.

I've only ever used Caddy without plugins, so I'm not familiar with how it works but do you mean that plugins in general must be enabled or that the specific set of plugins I want must be compiled in? If the latter then I think they are not so much plugins as some kind of extension.

Please clarify, thanks.

Re: Announcing Caddy Commercial Licenses

#33

Post by mholt »

stavros wrote: post #19

I've been trying to get Caddy more widely deployed at work, and this move is going to alienate commercial customers (at least us) even more than Caddy already does. Not only do they not have repositories, essentially doubling the effort to keep machines up to date (we have to have one process to upgrade everything else , and one process to upgrade just Caddy ), but now we can't even download precompiled binaries to d…

> Not only do they not have repositories, essentially doubling the effort to keep machines up to date (we have to have one process to upgrade everything else, and one process to upgrade just Caddy)

Cory's working on this, actually. If we can get it working, we should be able to offer official Caddy packages to all our customers, customized just how they need it to be, so your 'apt upgrade' could upgrade Caddy as well, with just the plugins you want.

> I could have put up with Caddy not being as mature as nginx for some low-volume deployments, and barely put up with the lack of debs, but having to compile my own binaries across the company isn't worth the integrated TLS certs.

Until we have official apt repos, you're welcome to use getcaddy.com which automates builds and installations of Caddy. True, it's not "apt install" but it's pretty close, until we can get apt repos and others available.

Re: Announcing Caddy Commercial Licenses

#34

Post by ash »

> We now require declaring a license when requesting a download: > /?license=personal" rel="nofollow">https://caddyserver.com/download//?license=persona... > The value for the license variable can be either personal or commercial. > … > We require the license parameter because we feel it's important for the license to be deliberate, not assumed. To ease the transition into this, though, we'll allow the current syntax (no license parameter) to work for at least 30 more days, and a personal license will be assumed.

I think this warning should be more prominent. Lot's of CI builds would mysteriously fail after 30+ days.

Re: Announcing Caddy Commercial Licenses

#35

Post by stephenr »

Copied comment from the other HN thread:

$50 dollars a MONTH PER INSTANCE for a piece of software that wouldn't even start a few months ago because LetsEncrypt was down.

I get that software takes time and people need to eat, but holy shit on a stick.

Edit: Oh, and I forgot the part where it also doesn't handle FQDN's properly either.

Previous discussion, from when LE was down for a day https://news.ycombinator.com/item?id=14375022

Re: Announcing Caddy Commercial Licenses

#36

Post by StavrosK »

codebeaker wrote: post #27
jimangel wrote: post #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 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.

Yeah, I have a bunch of side projects that collectively make ~$2/mo. Good thing I didn't replace nginx with Caddy on that server.

Re: Announcing Caddy Commercial Licenses

#37

Post by andkenneth »

StavrosK wrote: post #30
mholt wrote: post #28

Earlier quoted context omitted.

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?

I think the headers are there so they can see if commercial sites are using the personal version and get them to pony up.

Re: Announcing Caddy Commercial Licenses

#38

Post by lol768 »

mholt wrote: post #28
lol768 wrote: 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…

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

I dislike this for a few reasons. Firstly, it honestly comes across as petty. I'm using the server for personal reasons, it's for a non-commercial site which I don't make money off. I don't display ads, and suddenly I'm now being forced to serve ads to my visitors. The medium of delivery is utterly irrelevant to me.

Secondly, it makes it more difficult to take steps to make it less obvious which web server is being used. I'd do this to make it slightly more difficult for script kiddies looking to exploit recent vulnerabiltiies - not because I think security through obscurity is a good idea.

> 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?

No. The point is, you've annoyed someone who liked your software, used it for personal use (costing you nothing) and would've happily recommended it to colleagues.

Re: Announcing Caddy Commercial Licenses

#39

Post by mholt »

unkown-unknowns wrote: post #32
mholt wrote: post #11

Earlier quoted context omitted.

You're right, you can build from source under the Apache license. Keeping the project truly open source is really important to us, because the community is such a great part of using Caddy. Commercial licenses would only cost hundreds of thousands of dollars per year if your organization has at least 160 instances in use. Keep in mind that modifying the source is required to plug in any plugins, which people tend not…

> Keep in mind that modifying the source is required to plug in any plugins, which people tend not to want to bother with. I've only ever used Caddy without plugins, so I'm not familiar with how it works but do you mean that plugins in general must be enabled or that the specific set of plugins I want must be compiled in? If the latter then I think they are not so much plugins as some kind of extension. Please clarif…

It involves adding an import, and the plugin registers itself. Extension/plugin/addon -- call them what you will, I guess. We chose the term "plugin" before Go 1.8 had its experimental plugin package that, on Linux, allows dynamic linking of libraries. (There are a lot of limitations with that, for now.) In Caddy, all plugins are statically linked and compiled in.

Re: Announcing Caddy Commercial Licenses

#40

Post by Xunxi »

What are the key differences between Caddy and Centminmod? I would like to know the comparative speeds, use cases and disadvantages if any.

Also congrats to you Holt for taking this bold step to sustain development. Quite recently WangGuard became a victim of freebies and the nonreciprocal donation from users. I hope this endeavor pays off

Post reply on HN