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

261–270 of 295 posts

Re: Announcing Caddy Commercial Licenses

#261

Post by bschwindHN »

Touche wrote: post #75
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…

Hi mholt, I have used Caddy almost since you started it. Great product! My issue with this is that there isn't an affordable license for small non-profit websites (like a person's personal website). I'd gladly pay if it were affordable, but it is not. So now I have to choose between incurring the wasted bandwidth of this header to my users, or choosing a different web server.

> incurring the wasted bandwidth of this header to my users

Can you attach a concrete number to this? I think I found the example header and it's around 91 bytes, right?

How many requests do you need to service before this becomes a real issue?

You could also just build it from source...

Re: Announcing Caddy Commercial Licenses

#262

Post by bschwindHN »

derefr wrote: post #214
jimjimjim wrote: post #180

Earlier quoted context omitted.

you don't have time to recompile a software package but you do have time to read hackernews? is time the right word here?

My job pays me units of money in exchange for a finite time per day spent dedicated to advancing their goals. There are more potential things to do for the company than fit into the time they pay me to spend; and I'm not going to work for free past that time just to fit all those things in. Therefore, I have to optimize—to choose which things are most worth the company's time. Compiling and configuring software packa…

In the time it probably took you to type that comment, I compiled caddy from source. I've never even used it before, but in general Go programs are very easy to build.

Re: Announcing Caddy Commercial Licenses

#263

Post by stephenr »

StavrosK wrote: post #168
djvdorp wrote: post #164

Earlier quoted context omitted.

My thoughts exactly. And I am afraid we are moving even further away from packages with this move..

Yeah... What I don't understand is why nginx doesn't have built-in LetsEncrypt cert fetching yet.

Separation of concerns (serving http/s content and registering/renewing tls certificates) is a feature. Combining them is an appeasement for devs who think they don't need ops.

caddy wants $1200 a year minimum, for 2 instances. For $1200 I'll give you a setup script for HAProxy/Certbot that will work on infinite servers, and will keep working next year without you paying me.

This is like the weird "SaaS all the things" model taken to the extreme.

Caddy performs worse, has crazy defaults (seriously, won't start when LetsEncrypt is down!?) and wants to charge you FOREVER to use their build service, even if you only use it once and never update.

So, tell me again who their target market is?

Re: Announcing Caddy Commercial Licenses

#264

Post by stephenr »

zenlikethat wrote: post #226
fooey wrote: post #213

Earlier quoted context omitted.

What I think is interesting, is the licensing model is basically reverse whaling The bigger the company is, the more likely they are to go with just building Caddy themselves instead of paying for it. So, the only people who need to run the commercial binaries are the situations where the licensing costs actually matter. Maybe I'm underestimating the size of the demographic they're targeting, but it seems to me that…

> The bigger the company is, the more likely they are to go with just building Caddy themselves instead of paying for it. That's not true at all. Big companies pay for software, not small shops. If J Developer says to their boss, "Well, I'd really like to use this thing, but it costs $X" and $X is sufficiently small, companies will frequently just go for it. No technical manager worth their salt is going to argue for…

> No technical manager worth their salt is going to argue for their engineers who cost $X0,000 per month to be spending time managing a bespoke build pipeline to get out of paying somebody.

Any technical manager worth their salt won't be letting developers make ops decisions.

Oh right, it's devops so you don't have ops, you have developers who think this is a good deal

Re: Announcing Caddy Commercial Licenses

#265

Post by lol768 »

kbenson wrote: post #216
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…

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

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

Unfortunately when you fork a repository, it does copy the entire source tree. I can't type that fast, so there was a short period when the original README was still there.. there's also probably 400 other repositories on GitHub with the same problem. I knew this needed to be resolved, and it was within a timely manner.

I'll also note Caddy is not a registered trademark.

> Don't do that. If you're going to copy it, change the name.

When I created the repository I deliberately chose a different name and deliberately opened up the issue tracker and created an issue to track the work in renaming e.g. the README references. I created this issue before the "you're violating our (unregistered) trademark!" issue was created.

My intentions were good from the start, please don't talk to me as if that was not the case.

Re: Announcing Caddy Commercial Licenses

#266

Post by joepie91_ »

diggan wrote: post #72
ddevault wrote: post #47

Earlier quoted context omitted.

With that statement, Caddy is officially nonfree software. It breaks freedom 1. Edit: I have been corrected. For the record, I still think this is a braindead move from Caddy.

Hm, I don't think so (but I'm no expert) > The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this. Even with or without the above statement, this freedom is not broken by Caddy. You are still allowed to download the source and remove the headers, just as before.

The binary build from the Caddy website and the GitHub repository are effectively two separate products, as they are covered by different licenses.

The code in the GitHub repository is open-source; but the binary builds from the Caddy website are not.

Re: Announcing Caddy Commercial Licenses

#267

Post by folago »

JosephLark wrote: post #57
lol768 wrote: post #38

Earlier quoted context omitted.

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

> 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. This is worth keeping in mind. Personally, this change is putting me off Caddy to the point that I might stop using it for personal sites. The big feature for me - instant LetsEncrypt TLS certificates - can be done on other servers now fairly simply. So…

Seconded. This is also how I felt reading the news.

Re: Announcing Caddy Commercial Licenses

#268

Post by pepa65 »

Whitestrake wrote: post #31
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…

Where can we find the current most popular Caddy image?

Re: Announcing Caddy Commercial Licenses

#269

Post by pepa65 »

st3fan wrote: 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.

The issue is not forking. It is the build infrastructure to produce all the builds for each OS, architecture, and the desired plugins. This is added value that Caddy adds. It would be great for a replicated infrastructure to materialize. If it is well maintained it is even likely to overtake Caddy in terms of users, because it would be free software.

Re: Announcing Caddy Commercial Licenses

#270

Post by shakna »

bschwindHN wrote: post #262
derefr wrote: post #214

Earlier quoted context omitted.

My job pays me units of money in exchange for a finite time per day spent dedicated to advancing their goals. There are more potential things to do for the company than fit into the time they pay me to spend; and I'm not going to work for free past that time just to fit all those things in. Therefore, I have to optimize—to choose which things are most worth the company's time. Compiling and configuring software packa…

In the time it probably took you to type that comment, I compiled caddy from source. I've never even used it before, but in general Go programs are very easy to build.

> but in general Go programs are very easy to build.

So long as you organise all your code according to GOPATH. You can't just compile it in your Downloads folder.

Post reply on HN