Announcing Caddy Commercial Licenses

&gt; 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 present in those binaries.<p>Really not a fan of this, guess I&#x27;ll be compiling my own builds from now on.<p>Don&#x27;t get me wrong, I think charging for commercial licenses (which come with proper support) is a good business model, but my personal site shouldn&#x27;t suddenly become an advertising outlet. The fact that the headers aren&#x27;t seen by most non-technical users is moot.<p>I find this practice pretty obnoxious to the point of looking at NGINX Plus for commercial use instead.<p>Edit: Here&#x27;s my fork <a href="https:&#x2F;&#x2F;github.com&#x2F;WedgeServer&#x2F;wedge" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;WedgeServer&#x2F;wedge</a><p>Second edit: Accusation of trademark violation within an hour of the fork, classy! <a href="https:&#x2F;&#x2F;github.com&#x2F;WedgeServer&#x2F;wedge&#x2F;issues&#x2F;2" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;WedgeServer&#x2F;wedge&#x2F;issues&#x2F;2</a>

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.<p>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 &quot;Personal&quot; version is for only personal use and you need to pay for the commercial version. There&#x27;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&#x2F;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.<p>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.<p>This is a really obnoxious change. I was thinking about switching from Nginx to Caddy but this news is nailing that door shut.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;WedgeServer&#x2F;wedge&#x2F;issues&#x2F;2" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;WedgeServer&#x2F;wedge&#x2F;issues&#x2F;2</a>

@mholt is being exceedingly generous to the whingers on this thread, on top of the generosity he&#x27;s shown in writing Caddy to start with.<p>It&#x27;s not 2005 any more, Sun Microsystems is long gone. You won&#x27;t raise any money from a business model that gives away your best work or selling support contracts alone.<p>Caddy is a real innovation, and brings web server defaults bang up to date - it makes loads of complex configuration easy. It&#x27;s already distributed in the finest tradition of free software - a liberal source code license with no restrictions. You can do what you want with it.<p>Like GNU in the 80s and OpenBSD in the 90s, Matt is <i>selling</i> the most convenient package and yeah - if that&#x27;s the one you used and relied on for your infrastructure, you&#x27;ve got to pay, and not very much.<p>Matt has clearly worked hard at making that payment support as much as possible in terms of convenient corporate deployment. I really hope that works out well, and am glad it&#x27;s a business model that supports Free software without any compromises.

Well, I guess I&#x27;m moving switching from Caddy to NGINX then.<p>I like Caddy, it&#x27;s been great, but I have no interest in paying for support, and I&#x27;m certainly not going to pay to remove a HTTP header.<p>Yes, I could spend time setting everything up to build custom versions of Caddy without the header, but it&#x27;ll be quicker and easier to switch to NGINX.<p>Whilst I really appreciate all the work that has gone into Caddy, I am extremely annoyed that it&#x27;s now going to cost me at least an afternoon to move away from.<p>If you&#x27;re an existing Caddy user and don&#x27;t want to (or can&#x27;t) pay, your options are either don&#x27;t upgrade, server ads for Caddys sponsors, or spend a significant amount of time configuring your own build process&#x2F;switching to something else.<p>I can&#x27;t help but feel this move is going to be bad for Caddys adoption.

Congratulations on the launch, and good luck finding a sustainable means of funding Caddy. It&#x27;s a uniquely ergonomic webserver.<p>That said, the unalterable Caddy-Sponsors HTTP header <i>feels bad,</i> and cheapens my overall impression of Caddy as a quality product. Now, instead of paying for a license to gain access to enterprise features or support, I&#x27;m <i>paying to remove ads.</i> From my webserver. Which now has a custom license that I have to read, remember, and figure out how to comply with.<p>I give up. I&#x27;m an individual running 8 little caddy containers on a $5&#x2F;mo VPS. The cognitive load simply isn&#x27;t worth it, and I hope you&#x27;ll reconsider. Otherwise, it&#x27;s back to cobbling things together with nginx and haproxy. :(

To everyone saying that Caddy made it simple for automated LE; I agree, but also, it&#x27;s not that difficult to setup with NGINX:<p>Edit &#x2F;var&#x2F;nginx&#x2F;ssl_common.conf<p><pre><code> ssl_certificate &#x2F;etc&#x2F;letsencrypt&#x2F;live&#x2F;&lt;site&gt;&#x2F;fullchain.pem; ssl_certificate_key &#x2F;etc&#x2F;letsencrypt&#x2F;live&#x2F;&lt;site&gt;&#x2F;privkey.pem; location ^~ &#x2F;.well-known&#x2F;acme-challenge&#x2F; { default_type &quot;text&#x2F;plain&quot;; allow all; root &#x2F;var&#x2F;www&#x2F;example; auth_basic off; } </code></pre> Edit crontab, add:<p><pre><code> 30 2 * * 1 &#x2F;bin&#x2F;certbot -a webroot --webroot-path=&#x2F;var&#x2F;www&#x2F;example renew --renew-hook &quot;systemctl restart nginx&quot; </code></pre> Make the cert<p><pre><code> mkdir -p &#x2F;var&#x2F;www&#x2F;example certbot certonly --webroot -w &#x2F;var&#x2F;www&#x2F;example&#x2F; -d www.example.com </code></pre> In your NGINX HTTPS server blocks add:<p><pre><code> include ssl_common.conf </code></pre> That should be it...

<i>Beginning today, all official Caddy binaries come with an End User License Agreement (EULA) that designates them either for Personal (non-commercial) or Commercial use. 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.</i><p>Thanks for keeping it open source. I&#x27;m very interested in how this business model will work, glad to see people trying different approaches.

I&#x27;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.<p>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 <i>everything else</i>, and one process to upgrade <i>just Caddy</i>), but now we can&#x27;t even download precompiled binaries to deploy on the servers without paying.<p>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&#x27;t worth the integrated TLS certs.

I completely understand this direction, and really appreciate the work mholt and team has put into Caddy, but I&#x27;m disappointed at the same time. I looked forward to spinning up my dumb ideas tied with commerce using Caddy (on a 0 budget).<p>I&#x27;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 can generate money - but nothing that would allow me to swing $100&#x2F;mo.<p>I understand that I can compile the source and remain compliant, however, part of the charm was the simplicity once paired with docker for rapid dev&#x2F;deployment.<p>Does anyone know if there&#x27;s significant pain in maintaining a docker image that compiles source code like Caddy on rebuild?

&gt; We now require declaring a license when requesting a download: &gt; <a href="https:&#x2F;&#x2F;caddyserver.com&#x2F;download&#x2F;&lt;os&gt;&#x2F;&lt;arch&gt;?license=personal" rel="nofollow">https:&#x2F;&#x2F;caddyserver.com&#x2F;download&#x2F;&lt;os&gt;&#x2F;&lt;arch&gt;?license=persona...</a> &gt; The value for the license variable can be either personal or commercial. &gt; … &gt; We require the license parameter because we feel it&#x27;s important for the license to be deliberate, not assumed. To ease the transition into this, though, we&#x27;ll allow the current syntax (no license parameter) to work for at least 30 more days, and a personal license will be assumed.<p>I think this warning should be more prominent. Lot&#x27;s of CI builds would mysteriously fail after 30+ days.

Came back to this thread during lunch, and a few things I&#x27;m seeing have me more worried about Caddy than I originally was. Originally it just seemed like a very minor misstep, but now it seems more likely to be the start of something worse.<p>Can I ask - what exactly is Light Code Labs? The page really doesn&#x27;t say much. It almost seems like some 3rd year Computer Engineering student at BYU came along and talked Matt Holt into creating a business of Caddy? I can&#x27;t see anything about business expertise, and in the wedge fork trademark issue the other co-founder just responded that he was &quot;part owner of Light Code Labs&quot; and nothing about development. On the site it just says this person &quot;recently got into web development...[and] wants technology to be more intuitive for people to use&quot;.<p>It might just be my dislike of fluffy BS, but it seems like red flags to me.

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.<p>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 team behind caddy are the people who love it the most and care about its future the most, so I trust they will keep pushing forward.<p>For people who find it difficult to build caddy from source, here is an example, provided you have Go installed and configured:<p><pre><code> go get github.com&#x2F;mholt&#x2F;caddy go get github.com&#x2F;caddyserver&#x2F;builds cd &quot;$GOPATH&#x2F;src&#x2F;github.com&#x2F;mholt&#x2F;caddy&#x2F;caddy&quot; # Enable cors, prometheus plugins. cat &lt;&lt;EOF&gt;caddymain&#x2F;plugins.go package caddymain import ( _ &quot;github.com&#x2F;captncraig&#x2F;cors&#x2F;caddy&quot; _ &quot;github.com&#x2F;miekg&#x2F;caddy-prometheus&quot; ) EOF go get -u -v -f ... || echo &quot;Updated dependencies&quot; go run build.go </code></pre> <i>Edit: updated with the latest build procedure</i>

Key Quote: <i>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.</i><p>Doesn&#x27;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 besides private plugin hosting?

&gt; If you use Caddy for personal, academic, or non-profit purposes, not much is different. Caddy-Sponsors HTTP Header<p>&gt; If you use or distribute official Caddy binaries at work, or as part of a product&#x2F;service, you will need a commercial license<p>If I have some personal project which I want to incorporate I need to worry about the license.<p>Oh, time to switch back to NGINX. Thanks for automated HTTPS while it lasted.

This is all great, I hope this turns into a viable business. But I am just not sure about the approach here.<p>Maybe this is a good moment for someone to finally fork Caddy, remove the Sponsors header, and distribute proper RPMs and DEBs.<p>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.

&gt; If you use Caddy for personal, academic, or non-profit purposes, not much is different. Just a new response header that gives tribute to our sponsors.<p>So now there will be ads even in the HTTP headers.<p>Coming soon, ads in the tcp headers ...

caddyserver.com emits those headers if you want to see them in action: <a href="https:&#x2F;&#x2F;urlscan.io&#x2F;result&#x2F;8093833b-8ac7-4d18-8f20-a02373f577a1#transactions" rel="nofollow">https:&#x2F;&#x2F;urlscan.io&#x2F;result&#x2F;8093833b-8ac7-4d18-8f20-a02373f577...</a> Go to the first transaction, click the show button and click &quot;Show headers&quot;. Right now it says:<p><pre><code> caddy-sponsors - This free web server is made possible by its sponsors: Minio, Uptime Robot, and Sourcegraph </code></pre> Personal opinion: I&#x27;ve never understood the appeal of Caddy except for the builtin Let&#x27;s Encrypt &#x2F; TLS automagic support. nginx is very powerful and at the same time pretty easy to configure, and I think they split the features between the Open Source and commercial version pretty reasonably.

Just when you thought you knew what&#x27;s going on.<p>The author has claimed that prices will <i>rise</i> after an &quot;introductory period&quot;:<p><a href="https:&#x2F;&#x2F;mobile.twitter.com&#x2F;mholt6&#x2F;status&#x2F;908007933115375616" rel="nofollow">https:&#x2F;&#x2F;mobile.twitter.com&#x2F;mholt6&#x2F;status&#x2F;908007933115375616</a>

Copied comment from the other HN thread:<p>$50 dollars a MONTH PER INSTANCE for a piece of software that wouldn&#x27;t even start a few months ago because LetsEncrypt was down.<p>I get that software takes time and people need to eat, but holy shit on a stick.<p>Edit: Oh, and I forgot the part where it also doesn&#x27;t handle FQDN&#x27;s properly either.<p>Previous discussion, from when LE was down for a day <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14375022" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14375022</a>

If Caddy had focused on providing commercial support to companeis that need it, this would have been a good day.<p>As it is, they are adding artificial roadblocks for open source users while providing minimal benefits to commercial users.<p>Someone didn&#x27;t think this through or is out of touch with how to make money with open source.

Just wanted to add that we&#x27;ve experimented with Caddy awhile back and, while it didn&#x27;t suit our needs at the time, the first impression was a good one and I&#x27;ve since kept the project in the back of my mind.<p>However, the responses from the Caddy folks here and at <a href="https:&#x2F;&#x2F;github.com&#x2F;WedgeServer&#x2F;wedge&#x2F;issues&#x2F;2" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;WedgeServer&#x2F;wedge&#x2F;issues&#x2F;2</a> have been abysmal and without a clear change in course I&#x27;d feel embarrassed to recommend it to colleagues.<p>It&#x27;s not even about the licenses, as others have said, this is just bad form.

Caddy is OK, easy to setup on a personal machine, but nginx&#x27;s performance trumped it completely in our testing. Particularly when requesting large numbers of files concurrently.<p>I genuinely don&#x27;t know why a business would use Caddy over nginx, especially given the new commercial licensing scheme. nginx really isn&#x27;t that hard to setup.

My first thought upon finding out that Caddy&#x27;s source was still under an open source license was &quot;can that change, too?&quot;<p>As far as I can tell, the answer is &quot;not unilaterally,&quot; as I don&#x27;t see any requirements for copyright assignment in the contributing guidelines <a href="https:&#x2F;&#x2F;github.com&#x2F;mholt&#x2F;caddy&#x2F;blob&#x2F;master&#x2F;.github&#x2F;CONTRIBUTING.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mholt&#x2F;caddy&#x2F;blob&#x2F;master&#x2F;.github&#x2F;CONTRIBUT...</a>, nor in merged pull requests.

Didn&#x27;t Caddy got like $50.000 from Mozilla to work on the open source version?<p>Is Mozilla OK with this? Maybe Mozilla should give money on free software projects that plan on remaining free instead next time...<p><a href="https:&#x2F;&#x2F;blog.mozilla.org&#x2F;blog&#x2F;2016&#x2F;06&#x2F;22&#x2F;mozilla-awards-385000-to-open-source-projects-as-part-of-moss-mission-partners-program&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.mozilla.org&#x2F;blog&#x2F;2016&#x2F;06&#x2F;22&#x2F;mozilla-awards-3850...</a>

I don&#x27;t know why people are freaking out about this so much. It&#x27;s one header.<p>Also, it&#x27;s been made painfully clear that the source code is not covered by the EULA and is still licensed under Apache 2.0, so if you build from source yourself you can use it without any change, just like before this announcement.<p>It&#x27;s not like this is some ungodly C project where you need to gather all your dependencies together and debug the build process when it doesn&#x27;t work on your machine. The project is written in Go and has no external dependencies so building from source is literally just:<p><pre><code> - Install Go if you don&#x27;t have it already - Run `go get -u github.com&#x2F;mholt&#x2F;caddy&#x2F;caddy` - cd to $GOPATH&#x2F;src&#x2F;github.com&#x2F;mholt&#x2F;caddy&#x2F;caddy - Run `go install` - Use the resulting caddy.exe file for free like you always have done </code></pre> If you don&#x27;t like the Caddy-Sponsors header then you can just edit the `github.com&#x2F;mholt&#x2F;caddy&#x2F;caddyhttp&#x2F;header&#x2F;header.go` file and comment out the lines:<p><pre><code> if name == &quot;Caddy-Sponsors&quot; || name == &quot;-Caddy-Sponsors&quot; { &#x2F;&#x2F; see EULA continue } </code></pre> Then build the project, except now you can remove the sponsor header with `-Caddy-Sponsors` in your Caddyfile. If you need a plugin then just download the plugin you want from github and import it before building: <a href="https:&#x2F;&#x2F;github.com&#x2F;mholt&#x2F;caddy&#x2F;wiki&#x2F;Extending-Caddy" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mholt&#x2F;caddy&#x2F;wiki&#x2F;Extending-Caddy</a><p>@mholt has made the entire process so unbelievably easy that the whole process takes literally minutes...

i personally like how one of the first contact bits from caddy to a fork of it is a thinly veiled legal threat: <a href="https:&#x2F;&#x2F;github.com&#x2F;WedgeServer&#x2F;wedge&#x2F;issues&#x2F;2" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;WedgeServer&#x2F;wedge&#x2F;issues&#x2F;2</a>

I always find it funny when the announcement of a new, pay for software, especially a web server leads to 503. Especially when it looks like an HTML page.

1. I applaud this effort.<p>2. Ive been researching sustainable funding models for open source. Will the maintainers be blogging about the progress and results? Would be useful to learn about what they discover.

Site is currently down.<p>We&#x27;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.<p>Edit: it&#x27;s back, but damage done, I think.

homepage 503 <a href="https:&#x2F;&#x2F;dl.dropboxusercontent.com&#x2F;s&#x2F;phh5xebd1jqj27l&#x2F;2017-09-13%20at%208.41%20PM.png" rel="nofollow">https:&#x2F;&#x2F;dl.dropboxusercontent.com&#x2F;s&#x2F;phh5xebd1jqj27l&#x2F;2017-09-...</a>

as a developer that&#x27;s also struggling with finding a balance between the good things that open source helps guarantee and a viable business plan, i&#x27;m intrigued by this discussion<p>the approach that caddy has taken appears to be a bit of good cop &#x2F; bad cop. they&#x27;re maintaining, at least for now, the apache license but they&#x27;re also using trademark threats to prevent forks (i believe in violation of the github TOS)<p>the approach that i&#x27;m hoping to take is quite different. i&#x27;m interested in any feedback (my software is a database engine that in some ways is more convenient than existing dbms for java developers, but similar to caddy in that many good alternatives exist and are free)<p><a href="https:&#x2F;&#x2F;github.com&#x2F;db4j&#x2F;pupl" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;db4j&#x2F;pupl</a> <a href="http:&#x2F;&#x2F;db4j.org&#x2F;pupl&#x2F;PUPL" rel="nofollow">http:&#x2F;&#x2F;db4j.org&#x2F;pupl&#x2F;PUPL</a><p>- you can freely copy, modify and distribute the software<p>- non-production use is free, as is production use on up to 10 cores<p>- prices are predictable and non-discriminatory<p>how would you feel about using software (in the infrastructure space) under this license ?

&gt; 1&#x2F;4 price of comparable servers<p>Which servers?

Obligatory link to Richard Stallman on &quot;free vs open&quot;:<p><a href="https:&#x2F;&#x2F;www.gnu.org&#x2F;philosophy&#x2F;open-source-misses-the-point.en.html" rel="nofollow">https:&#x2F;&#x2F;www.gnu.org&#x2F;philosophy&#x2F;open-source-misses-the-point....</a>

This was a fascinating thread of a product I would possibly have used but now won&#x27;t...

Hi Matt! I&#x27;ve been using and advocating for Caddy for a while now, but I have to say this is a huge put-off.<p>Don&#x27;t get me wrong here, I&#x27;m in full support of a commercial version... but as you can see from the feedback here, this kind of thing is really frowned upon in the personal &#x2F; OSS space for a variety of reasons.<p>I encourage you to re-consider added headers. Perhaps look at a more heavy handed download process such as the &quot;Pay as you want&quot; system used by ElementaryOS&#x27;s download page (<a href="https:&#x2F;&#x2F;elementary.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;elementary.io&#x2F;</a>).

Can projects (for example, Arch Linux) legally create and distribute binaries compiled from source that&#x27;s modified to remove the header? That&#x27;s unclear to me.

I fully understand commercial licensing, and would willingly pay for it, but I am certainly not paying for software that thinks it&#x27;s reasonable to inject headers into requests as a form of licensing control.<p>I&#x27;ve been using Caddy as my default web server for a long time but this is prompting me to switch everything over to nginx. I&#x27;m seriously bummed this is the route Matt has taken things. What a shockingly awful surprise to wake up to.

I&#x27;m excited that Caddy has taken steps to ensure its long term survival. Sad people can&#x27;t be bothered to pay for software they like.

What are the key differences between Caddy and Centminmod? I would like to know the comparative speeds, use cases and disadvantages if any.<p>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

@mholt It does not matter if Caddy is open source or proprietary. Showing advertisements in the HTTP response header field is an annoyance. Please remove &quot;Minio&quot; from the header.<p>I am also sad about how the opensource version of Caddy project no longer has a website and being ignored. -ab

Matt&#x27;s response <a href="https:&#x2F;&#x2F;caddy.community&#x2F;t&#x2F;the-realities-of-being-a-foss-maintainer&#x2F;2728&#x2F;" rel="nofollow">https:&#x2F;&#x2F;caddy.community&#x2F;t&#x2F;the-realities-of-being-a-foss-main...</a>

Everything is getting expensive.

Such amazing hostility.<p>Open source developers NEVER owe users anything. Never.<p>Stop being so entitled.