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.
Announcing Caddy Commercial Licenses
81–90 of 295 posts
Re: Announcing Caddy Commercial Licenses
#82Earlier 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.
Re: Announcing Caddy Commercial Licenses
#83Well, 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.
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
#84Earlier 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.
Can we at least get the base package sorted before? I really don't need custom with any plugins.
Re: Announcing Caddy Commercial Licenses
#85Re: Announcing Caddy Commercial Licenses
#86Earlier 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.
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
#87However, 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.
Re: Announcing Caddy Commercial Licenses
#88> 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…
Re: Announcing Caddy Commercial Licenses
#89Earlier 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…
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
#90Earlier 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
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.