Live data from Hacker News

Announcing Caddy Commercial Licenses

caddyserver.com

81–90 of 295 posts

Re: Announcing Caddy Commercial Licenses

#81
post #72

Earlier quoted context omitted.

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.

>its presence is required by the non-commercial EULA This statement reads to me that you _cannot_ remove it. It also combines with freedom 3, if you can't distribute your modified version.

The EULA does not apply to the source code. The source code is Apache licensed.

Re: Announcing Caddy Commercial Licenses

#82
post #73

Earlier quoted context omitted.

dists/EULA: 3. Restrictions 3.1 You SHALL NOT, and shall not allow any third party, to: (a) decompile, disassemble, or otherwise reverse engineer the Software or attempt to reconstruct or discover any source code, underlying ideas, algorithms, file formats or programming interfaces of the Software by any means whatsoever (except and only to the extent that applicable law prohibits or restricts reverse engineering res…

Remember this only applies to official binaries. The EULA itself states it doesn't apply to the source code.

Is that specified somewhere? I mean, I see this in the EULA `READ IT CAREFULLY BEFORE COMPLETING THE INSTALLATION PROCESS AND USING OFFICIAL CADDY BINARIES AND RELATED SOFTWARE COMPONENTS ("Software").` But is there something that specifically says the EULA only applies to official binaries and not the source code or self compiled binaries?

Re: Announcing Caddy Commercial Licenses

#83
post #70

Well, 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…

Caddy is still open source, Apache licensed. You can certainly build from source as long as you give attribution and state your changes.

Matt, I really do appreciate the work you and others have put into Caddy - it's a fantastic piece of software which has served me well for the past year and a bit.

Having said that, this change has put me in a position where I have to invest either time or money into a solution for a problem which I didn't have yesterday, and switching to NGINX seems like the path least likely to cause issues in the future.

Having to build my own version of Caddy for every update is a cost I'm not willing to pay. Since I'm being forced to invest in something, it may as well be NGINX, and I suspect I'm not alone in this.

Re: Announcing Caddy Commercial Licenses

#84
post #68

Earlier quoted context omitted.

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.

One of the things we're hoping to offer soon are official distro packages that can be customized with the plugins you want/need.

Thanks Matt, this is DESPERATELY needed for any reasonably sized rollouts(and even my own single personal rollout). Admins don't want to be manually installing software on machines like we're back in the days of compiling everything from source.

Can we at least get the base package sorted before? I really don't need custom with any plugins.

Re: Announcing Caddy Commercial Licenses

#86
post #75
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.

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!

Re: Announcing Caddy Commercial Licenses

#87
I said further below that this makes Caddy nonfree, but I was corrected - you can still build Caddy from source, remove the bullshit, and distribute your changes and compiled binaries under Apache 2.0.

However, after examining the website more I feel the need to write another comment expressing how poorly this is being handled. The website is very misleading - on the download page, it now asks you to pick a license, and says that the "Personal" version is for only personal use and you need to pay for the commercial version. There's no indication until you click through to the full pricing page that the open source version even exists. On that page, you have the same personal/commercial breakdown, also stating that the personal version is strictly for non-commercial use, but with a sidebar mentioning open source. It assumes you understand the Apache 2.0 license and makes no attempt to clarify that businesses can use the open source version.

The authors are also wasting no time in going after forks[1] to complain about trademark infringement, so if you want to distribute your own patched Caddy builds you can expect to hear from their lawyers. Absolutely devoid of class.

This is a really obnoxious change. I was thinking about switching from Nginx to Caddy but this news is nailing that door shut.

[1] https://github.com/WedgeServer/wedge/issues/2

Re: Announcing Caddy Commercial Licenses

#88
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…

Wow, in the course of this HN thread I went from learning about Caddy, to deciding against using it. Definitely not cool to immediately threaten legal action almost instantly after forking. Definitely not cool to force a header. I'll be sticking with nginx.

Re: Announcing Caddy Commercial Licenses

#89
post #70

Earlier quoted context omitted.

Caddy is still open source, Apache licensed. You can certainly build from source as long as you give attribution and state your changes.

Matt, I really do appreciate the work you and others have put into Caddy - it's a fantastic piece of software which has served me well for the past year and a bit. Having said that, this change has put me in a position where I have to invest either time or money into a solution for a problem which I didn't have yesterday, and switching to NGINX seems like the path least likely to cause issues in the future. Having to…

I don't think a small nudge to actually pay for the thing that benefits you, or have a small note somewhere that you're not paying for it that someone might--gasp!--see, is as big a deal as the histrionics throughout this thread suggest. You don't have a problem because there's an HTTP header, you have a problem because this makes you feel uncomfortable and you want to hide it, and that strikes me as a very different thing.

You can also pay-the-man. That's an option, too. Personally, if I "really [did] appreciate the work [mholt] and others have put into Caddy," I'd be doing that long before I go switch web server stacks, because wow that's not a lot of money if I'm doing anything where I actually care about a HTTP header, but I prioritize not freeloading where I can so that's probably "just a worldview thing".

Re: Announcing Caddy Commercial Licenses

#90
post #42

Earlier quoted context omitted.

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

To give commercial users an incentive to pay for the open source software they use. Can you name an open source project that does not offer extended features for commercial versions and that sells? Because I can't

There's a difference between "extended features for commercial versions" and "adware". Usually the open source version includes core features that solve a basic set of problems, and the commercial versions add additional features to solve other and/or larger problems. At no point is there an explicit crippling of the open source.

What's particularly frustrating is the burying of the lede here. The summary of the page intentionally omits the fact that you can build from source and use it in commercial contexts. And the section discussing the Apache license is factually incorrect: "Remember that building Caddy from source is still subject to the Apache 2.0 license which requires attribution and stating changes." -- that is only true if you are selling on-prem software that ships with the program. If you are using it in the normal course of your SaaS, no attribution is required.

Post reply on HN