Not being able to use the release binaries (even from github) for commercial purposes is a bummer but if this is the price to pay for having caddy available as open source, then it is fair. What I am afraid of, is that this friction to start with caddy (because $50 per month is way too much for most use cases) will affect its user base and as a consequence the participation in development. Of course mholt and the tea…
To compile without the `Caddy-Sponsors` header, include this line before the plugin comment: sed -ie '/Header().Set("Caddy-Sponsors/d' ../caddyhttp/httpserver/server.go
Announcing Caddy Commercial Licenses
151–160 of 295 posts
Re: Announcing Caddy Commercial Licenses
#152Site is currently down. We've talked at length about the time saving things Caddy may do for you, but crashing under the weight of a static page is not a good advertisement. Edit: it's back, but damage done, I think.
Re: Announcing Caddy Commercial Licenses
#153Earlier quoted context omitted.
I pay $149 a month for a server, I was using Nginx + nghttp2 (for gRPC), until last month when I switched to Caddy (LE benefits). I'm not familiar with Go, so I can't modify source to get the plugins I like. I read the announcement page, and can't find what the cost is, but it doesn't matter. My work doesn't count as non-x, because I want to someday make an extra income from it. I've found Caddy to be a cool and inte…
The Caddy source code is Apache licensed, so if you build from source, you're good to go. That's the point: we know there are many projects that are just a little side income here and there, so you should be able to build your own Caddy binary from source and use it. The pricing is on our pricing page: https://caddyserver.com/pricing If your commercial venture isn't profitable yet, we will try to help you bootstrap.…
Loads of incredibly tech folks on HN (and that would be interested in Caddy to start with). Yet most of us explicitly do not "build from source" most of the time: it's too susceptible to breakage; doesn't play nicely with `yum upgrade`; etc.
Can we "build from source"? Sure.
But why should we have to to avoid something you've added - apparently - just to assuage your sponsors?
Charge for it. That's cool - I pay for quality stuff.
But adware? that's a crap move.
Re: Announcing Caddy Commercial Licenses
#154Earlier quoted context omitted.
The Caddy source code is Apache licensed, so if you build from source, you're good to go. That's the point: we know there are many projects that are just a little side income here and there, so you should be able to build your own Caddy binary from source and use it. The pricing is on our pricing page: https://caddyserver.com/pricing If your commercial venture isn't profitable yet, we will try to help you bootstrap.…
> if you build from source, you're good to go. That's a pretty big if. The one time I had to compile the server from source (to help you test a bugfix), I had the Go toolchain installed (which not everyone does) and I still couldn't figure out how to compile with some of the plugins I wanted. I gave up after 30 minutes of not getting anywhere, IIRC. I think this move has lost you a lot of goodwill from people.
And there's the rub: even for as smart as lots of HN readers are (and, likely, as most Caddy users are), why are you forcing folks to do something that isn't standard? Why force people to go about awkward, ugly manual steps to avoid something that didn't even exist a few hours ago?
Re: Announcing Caddy Commercial Licenses
#155> 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…
It's been working beautifully for me with full HTTP2 features, including server push. (NGINX doesn't have HTTP/2 server push for free users.)
Re: Announcing Caddy Commercial Licenses
#156Well, I guess I'm moving switching from Caddy to NGINX then. I like Caddy, it's been great, but I have no interest in paying for support, and I'm certainly not going to pay to remove a HTTP header. Yes, I could spend time setting everything up to build custom versions of Caddy without the header, but it'll be quicker and easier to switch to NGINX. Whilst I really appreciate all the work that has gone into Caddy, I am…
That is, keep Caddy as it was and get sponsorships/memberships for a "Caddy Plus".
Re: Announcing Caddy Commercial Licenses
#157Earlier 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…
> 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. I thought about this as well, but I'm not convinced that hiding the Server header or anything like unto it is really that beneficial. Most…
We as users don't believe that's your choice to make.
> And if it becomes common to hide or remove the Server header for Caddy instances, then guess what becomes its new signature?
This only applies if Caddy is the only server that does this, which is not the case.
Re: Announcing Caddy Commercial Licenses
#158Well, I guess I'm moving switching from Caddy to NGINX then. I like Caddy, it's been great, but I have no interest in paying for support, and I'm certainly not going to pay to remove a HTTP header. Yes, I could spend time setting everything up to build custom versions of Caddy without the header, but it'll be quicker and easier to switch to NGINX. Whilst I really appreciate all the work that has gone into Caddy, I am…
I think the Caddy developers messed up and did not follow the example of nginx. That is, keep Caddy as it was and get sponsorships/memberships for a "Caddy Plus".
Re: Announcing Caddy Commercial Licenses
#159Earlier quoted context omitted.
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.
Thanks for your feedback. You could build from source, that's free. If you need a commercial license, contact us at sales@lightcodelabs.com and we'll see about working something out for you!
I was using Caddy because I don't have time in my day to configure Nginx; but I also don't have time in my day to build Caddy from source to repackage+deploy it to my infrastructure. So back to Nginx it is.
What I would have time in my day for is a standardized one-time PayPal payment in exchange for a commercial license authorizing me to use Caddy for a site with traffic not exceeding [X amt any commercial site would quickly hit]. You know, like buying an SMB license of any other on-prem web-service software.