
Announcing Caddy Commercial Licenses - OberstKrueger
https://caddyserver.com/blog/accouncing-caddy-commercial-licenses.html
======
lol768
> 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.

Really not a fan of this, guess I'll be compiling my own builds from now on.

Don'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't
suddenly become an advertising outlet. The fact that the headers aren't seen
by most non-technical users is moot.

I find this practice pretty obnoxious to the point of looking at NGINX Plus
for commercial use instead.

Edit: Here's my fork
[https://github.com/WedgeServer/wedge](https://github.com/WedgeServer/wedge)

Second edit: Accusation of trademark violation within an hour of the fork,
classy!
[https://github.com/WedgeServer/wedge/issues/2](https://github.com/WedgeServer/wedge/issues/2)

~~~
mholt
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
difference to know that commercially-licensed Caddy builds don't have that
header?

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

~~~
bauerd
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

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

~~~
StavrosK
Exactly. I would have no issue if paid usage was for things big companies are
more likely to need, e.g. support, high-performance features, etc, like nginx
does, but this is egregious.

------
Sir_Cmpwn
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](https://github.com/WedgeServer/wedge/issues/2)

~~~
Whitestrake
> 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 in particular doesn't seem fair. Trademark really requires trademark
holders to make active efforts to preserve their trademarks as soon as they're
aware of potential breaches, or they invite risk. And this is a simple request
in the fork's issues page - no lawyers are involved yet, as far as I can tell.

~~~
Sir_Cmpwn
There's not even a registered trademark, as they stated. And simply
distributing a modified version of an open source project under that project's
name is absolutely fine and pushing against it is definitely in bad faith.

>And this is a simple request in the fork's issues page - no lawyers are
involved yet, as far as I can tell.

Well, what do you think their next step is if they refuse?

~~~
pzb
Unfortunately the "distributing a modified version of an open source project
under that project's name" can be problematic from a trademark perspective.
This has come up many times before in other projects and led Debian to not use
trademarked project names for software. If you are not familiar with the
discussions, just search for "IceWeasel".

~~~
Sir_Cmpwn
You're right, I hadn't thought of that. I still think going after a fork
within minutes of its establishment for trademark infringement is in very bad
faith, though.

~~~
Posibyte
And I think this is the crux of the issue with the trademark threats. They're
going after these forks that haven't yet had enough time to signal intent to
violate trademark, however pending it may be. You can say that they're just
protecting their mark and that's fine and valid, but to do it within minutes
of repo creation gives the uneasy feeling of them "dancing a mace in the air"
to remind people who's the big guys on the block.

------
mattbee
@mholt is being exceedingly generous to the whingers on this thread, on top of
the generosity he's shown in writing Caddy to start with.

It's not 2005 any more, Sun Microsystems is long gone. You won't raise any
money from a business model that gives away your best work or selling support
contracts alone.

Caddy is a real innovation, and brings web server defaults bang up to date -
it makes loads of complex configuration easy. It'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.

Like GNU in the 80s and OpenBSD in the 90s, Matt is _selling_ the most
convenient package and yeah - if that's the one you used and relied on for
your infrastructure, you've got to pay, and not very much.

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's a business model that supports Free software
without any compromises.

~~~
fooey
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 only market for Caddy is a fairly small niche of
people who are unwilling/unable to run NGINX or set up their own build
process.

~~~
georgebarnett
I disagree.

Big companies are where they're going to buy the licenses because in those
companies time is often more kmportnant than budget so you just buy stuff.

Another reason is that as soon as other teams become involved you get comments
like "this bug is yours because you self compiled this thing", or "we have to
buy the vendors version", etc etc. It's not logical and is basically arse
covering. Buying the vendor version is an easy way to shoot down a whole
category of stupid internal politics.

~~~
camus2
> Big companies are where they're going to buy the licenses because in those
> companies time is often more kmportnant than budget so you just buy stuff.

It doesn't work quite like that. Unless you're friend with the guy who decides
who the checks are signed to, or you are already an established brand or your
product provides a value so big it's a no-brainer, nobody in a big company
will invest in your solution. If the company can get your product for free it
will.

Caddy is trying to cash in on a product that is young, that has everything to
prove, while at the same time pissing off the people it relies on to acquire
an "audience", the users of the open source version, it never ends well.

The right way to do it is, to leave the open source version as it is, without
any license change, while creating a new product,closed source, suited for
enterprise.

> "this bug is yours because you self compiled this thing",

never heard anything like that in my life.

> Buying the vendor version is an easy way to shoot down a whole category of
> stupid internal politics.

If you have the power to do so at your business by all means. Buying into a
commercial product also require a crazy amount of politics as well, especially
if it's a recurring payment PER month PER instance at a minimum of $50, so
more than the price of a basic VM on Amazon.

~~~
BrandoElFollito
> never heard anything like that in my life.

Just yesterday I was whipping a team because they built their own version of
Apache (for dubious reasons) and broke the patch management system.

To quote myself "why the fuck didn't you use the distribution packaged
version?? Now go and fix that right now, it is your problem"

I think it pretty much covers the case.

~~~
camus2
Yes, and you don't have to pay to use a packaged distribution of Apache free
of adware.

> I think it pretty much covers the case.

I think it pretty much doesnt.

~~~
BrandoElFollito
What adware? In which packages? What kind of payment are you talking about?
Redhat?

Have you ever maintained a bunch (100 to a few thousand) machines where
everyone builds his stuff from scratch according to their under the shower
visions ? I have and now I will hit the ones who step one nanometer outside
the only true and god provided package, that is straight from the
distribution.

And yes - it does cover the case of you NEVER seeing that. Now you have seen.

------
JamesMcMinn
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
extremely annoyed that it's now going to cost me at least an afternoon to move
away from.

If you're an existing Caddy user and don't want to (or can't) pay, your
options are either don't upgrade, server ads for Caddys sponsors, or spend a
significant amount of time configuring your own build process/switching to
something else.

I can't help but feel this move is going to be bad for Caddys adoption.

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

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

~~~
eropple
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".

~~~
JamesMcMinn
Or perhaps I'm a student with no income trying to write a thesis at the same
time as bootstrap a startup, and can't afford to spend $100/month on a reverse
proxy? The new EULA states I'm not allowed to use the personal build, so I
have little choice in that matter.

Your "worldview" doesn't seem to extend past the end of your own nose.

~~~
jimjimjim
you are a student and you are using something for FREE and you are also at the
same time worried about extra stuff in the headers?

what is your startup going to do to generate money if you perpetuate the
belief that no one should pay for anything?

~~~
JamesMcMinn
The startup has extremely limited resources, it's a bootstrap, as I explained.
The licence prohibits us from using the personal licence, and there is a time
cost involved in building and maintaining our own version. $1200 a year is not
good value for us when NGINX will do the job for free.

I never claimed that no one should pay for anything, and I wish the people
working on Caddy the best of luck. I think it's a fantastic piece of software
and, as I have said several times, I am very grateful for the effort that has
been put into making the project what it is.

However the change means that I have to act or be left with an out-of-date
internet facing server. If you cannot see why I am annoyed at being given no
choice but to spend time or money on solution because Caddy has introduced a
new commercial licence, then I will not convince you of anything.

------
callahad
Congratulations on the launch, and good luck finding a sustainable means of
funding Caddy. It's a uniquely ergonomic webserver.

That said, the unalterable Caddy-Sponsors HTTP header _feels bad,_ 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'm
_paying to remove ads._ From my webserver. Which now has a custom license that
I have to read, remember, and figure out how to comply with.

I give up. I'm an individual running 8 little caddy containers on a $5/mo VPS.
The cognitive load simply isn't worth it, and I hope you'll reconsider.
Otherwise, it's back to cobbling things together with nginx and haproxy. :(

~~~
Whitestrake
> That said, the unalterable Caddy-Sponsors HTTP header feels bad, and
> cheapens my overall impression of Caddy as a quality product.

Hit the nail on the head. There's lots of reasons why this is a non-problem,
intellectually speaking, but none of the arguments for this remove the bad
taste in my mouth, emotionally speaking. The other news doesn't bother me, but
the header... disappoints me.

------
PenguinCoder
To everyone saying that Caddy made it simple for automated LE; I agree, but
also, it's not that difficult to setup with NGINX:

Edit /var/nginx/ssl_common.conf

    
    
      ssl_certificate /etc/letsencrypt/live/<site>/fullchain.pem;
      ssl_certificate_key /etc/letsencrypt/live/<site>/privkey.pem;
      
      location ^~ /.well-known/acme-challenge/ {
            default_type "text/plain";
            allow all;
            root /var/www/example;
            auth_basic off;
      }
      

Edit crontab, add:

    
    
      30 2 * * 1 /bin/certbot -a webroot --webroot-path=/var/www/example renew --renew-hook "systemctl restart nginx"
    
      

Make the cert

    
    
      mkdir -p /var/www/example
      certbot certonly --webroot -w /var/www/example/ -d www.example.com
      
     

In your NGINX HTTPS server blocks add:

    
    
      include ssl_common.conf
    

That should be it...

~~~
gshulegaard
Small improvement, but `reload` should do this while gracefully terminating
connections:

[https://www.guyrutenberg.com/2017/01/01/lets-encrypt-
reload-...](https://www.guyrutenberg.com/2017/01/01/lets-encrypt-reload-nginx-
after-renewing-certificates/)

[http://nginx.org/en/docs/beginners_guide.html](http://nginx.org/en/docs/beginners_guide.html)

Basically `reload` should have the external appearance of 0 downtime.

~~~
PenguinCoder
Thanks.

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

Thanks for keeping it open source. I'm very interested in how this business
model will work, glad to see people trying different approaches.

~~~
fortythirteen
Since you could pull yesterday's version:

OpenOffice -> LibreOffice

Gnome -> Mate

Caddy -> ?

~~~
mattl
Wedge.

[https://github.com/WedgeServer/wedge](https://github.com/WedgeServer/wedge)

------
StavrosK
I'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.

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 _everything
else_ , and one process to upgrade _just Caddy_ ), but now we can't even
download precompiled binaries to deploy on the servers without paying.

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't worth the integrated TLS
certs.

~~~
mholt
> 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 everything
> else, and one process to upgrade just Caddy)

Cory's working on this, actually. If we can get it working, we should be able
to offer official Caddy packages to all our customers, customized just how
they need it to be, so your 'apt upgrade' could upgrade Caddy as well, with
just the plugins you want.

> _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 't worth the integrated TLS
> certs._

Until we have official apt repos, you're welcome to use getcaddy.com which
automates builds and installations of Caddy. True, it's not "apt install" but
it's pretty close, until we can get apt repos and others available.

~~~
StavrosK
> it's not "apt install" but it's pretty close

It's not close, though, it's very far. With apt, I know things are going to go
in their proper place, and are going to get cleaned up afterwards (not to
mention the biggest benefit, automatic updates).

With a shell script, I don't know what sort of stuff it puts where on my
filesystem, and I can't automate the installation easily. My preferred order
of installation procedures is: "apt", "manual", and "random shell script" is a
distant last, to the point where I sometimes won't try software if the
installation procedure isn't sane.

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

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

~~~
tylersmith
After this I would bet they have it before very long.

~~~
dlsniper
You assume that they care about Caddy and that the 9 lines of how to get LE
for nginx is something they think it's hard to do for anyone that can't follow
these instructions:
[https://gist.github.com/cecilemuller/a26737699a7e70a7093d4dc...](https://gist.github.com/cecilemuller/a26737699a7e70a7093d4dc115915de8)
or use:
[https://github.com/certbot/certbot](https://github.com/certbot/certbot)

------
jimangel
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 can generate money - but nothing that would allow
me to swing $100/mo.

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

Does anyone know if there's significant pain in maintaining a docker image
that compiles source code like Caddy on rebuild?

~~~
codebeaker
I couldn't agree more. The terms seem overly restrictive.

Let's hope that they don't "go after" anyone who's not compliant and that this
is silently a scheme to force bigger companies into compliance and let the
rest of us fly under the radar.

As-is, I would owe Caddy $300/month - none of my side projects can sustain
that, so I'll be switching back to nginx and some LE cronjobs.

~~~
StavrosK
Yeah, I have a bunch of side projects that collectively make ~$2/mo. Good
thing I didn't replace nginx with Caddy on that server.

------
ash
> We now require declaring a license when requesting a download: >
> [https://caddyserver.com/download/<os>/<arch>?license=persona...](https://caddyserver.com/download/<os>/<arch>?license=personal)
> > The value for the license variable can be either personal or commercial. >
> … > We require the license parameter because we feel it's important for the
> license to be deliberate, not assumed. To ease the transition into this,
> though, we'll allow the current syntax (no license parameter) to work for at
> least 30 more days, and a personal license will be assumed.

I think this warning should be more prominent. Lot's of CI builds would
mysteriously fail after 30+ days.

~~~
mholt
I'll work on that. But the error message is very clear, so if any error
reporting is enabled, it'll be pretty obvious what to do, at least.

The fact that people were relying on volunteer-supported infrastructure for
their CI builds is a little unnerving to me, hence the move to commercial
support.

~~~
iampims
Why not upload them to GitHub?

~~~
gtirloni
Exactly, building and pushing to GitHub is a set-and-forget process. Besides,
it already needs to be done for paying customers now so what kind of work is
that saving Caddy? I don't understand.

EDIT: Additionally, it's an error to think that non-paying customers are not
contributing. It's actually a pretty basic misunderstanding for an open source
company. Users are contributing with bug reports, small fixes, testing,
marketing, etc. It amazes me we still see this feeling in 2017. I dare all
companies with open source projects to actually close them and replace non-
paying customers with QA teams, more developers, more infrastructure, etc.
Make sure to increase your budgets and raise your prices accordingly.

~~~
iampims
Answering my own question: it is now my understanding that caddy relies on a
custom build system to generate custom builds on the fly for its plugins.
Publishing all combinations on GH wouldn't make much sense given the
combination explosion for any new plugin.

~~~
gtirloni
That's excellent. Most people don't seem to use plugins so a default build is
enough for them. Those who need it have a business need now and can either
setup their own build system or pay Caddy for that. Value is generated as
opposed to being subtracted (from the current status quo).

~~~
mholt
More than 50% of Caddy downloads have at least one plugin. 1 and 2 plugins are
the most common of those that have at least one.

~~~
gtirloni
That's impressive and a sizable customer base. I hope it works for you, Caddy
is impressive and more competition is always good.

------
JosephLark
Came back to this thread during lunch, and a few things I'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.

Can I ask - what exactly is Light Code Labs? The page really doesn'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't see
anything about business expertise, and in the wedge fork trademark issue the
other co-founder just responded that he was "part owner of Light Code Labs"
and nothing about development. On the site it just says this person "recently
got into web development...[and] wants technology to be more intuitive for
people to use".

It might just be my dislike of fluffy BS, but it seems like red flags to me.

~~~
yroc92
It’s me, the other guy. That bio is pretty old, but it was accurate at the
time. Caddy required a legal entity a few years ago for several reasons, so we
went with “Light Code Labs”. LCL owns Caddy and is the legal entity through
which we do business. mholt was (and still is) very concerned about making
Caddy sustainable. I am also concerned about this, since I knew that mholt
wasn’t going to maintain the project for free forever. So he invited me to
join him and help with logistical things (money/taxes, trademarks, etc.),
along with some technical things (currently working on an API for Caddy, as
well as implementing apt-get with the build server). mholt is his own person,
and I am not in a position to coerce him into doing things he doesn’t want to.

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

For people who find it difficult to build caddy from source, here is an
example, provided you have Go installed and configured:

    
    
      go get github.com/mholt/caddy
      go get github.com/caddyserver/builds
      
      cd "$GOPATH/src/github.com/mholt/caddy/caddy"
    
      # Enable cors, prometheus plugins.
      cat <<EOF>caddymain/plugins.go
      package caddymain
      
      import (
              _ "github.com/captncraig/cors/caddy"
              _ "github.com/miekg/caddy-prometheus"       
      )
      EOF
      
      go get -u -v -f ... || echo "Updated dependencies"
      go run build.go
    

_Edit: updated with the latest build procedure_

~~~
Whitestrake
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

~~~
andmarios
Thanks, although I personally will keep it. When I was maintaining web servers
as a living I used to add a custom header here and there, so I see no harm in
the practice.

------
winter_blue
Key Quote: _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._

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

~~~
mholt
You're right, you can build from source under the Apache license. Keeping the
project truly open source is really important to us, because the community is
such a great part of using Caddy.

Commercial licenses would only cost hundreds of thousands of dollars per year
if your organization has at least 160 instances in use. Keep in mind that
modifying the source is required to plug in any plugins, which people tend not
to want to bother with.

We're also looking into adding more features for our customers.

~~~
nevi-me
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 interesting project, but guess I'll be
switching Nginx back on soon enough :(

~~~
mholt
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](https://caddyserver.com/pricing)

If your commercial venture isn't profitable yet, we will try to help you
bootstrap. Just email us, sales@lightcodelabs.com and we'll see what we can
do.

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

~~~
warrenm
>a pretty big if. The one time I had to compile the server from
source...couldn't figure out how to compile with some of the plugins

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?

------
romanovcode
> If you use Caddy for personal, academic, or non-profit purposes, not much is
> different. Caddy-Sponsors HTTP Header

> If you use or distribute official Caddy binaries at work, or as part of a
> product/service, you will need a commercial license

If I have some personal project which I want to incorporate I need to worry
about the license.

Oh, time to switch back to NGINX. Thanks for automated HTTPS while it lasted.

~~~
Whitestrake
This is incorrect, or at least only half-true.

Caddy is still Apache 2.0 licensed. You can use it for free for commercial
purposes. You just can't use the build server at caddyserver.com to download a
precompiled Caddy with plugins. Instead, you can download the source, compile
it with plugins yourself, then distribute your own binary amongst all your
hosts.

~~~
romanovcode
Yeah, I guess you're right. But then again setting up NGINX with auto SSL
would be easier so what's the point.

Personally for me Caddy is (was) good because of how easy it is to set it up.

~~~
Whitestrake
I'm not sure I agree with you there.

The most popular Docker image for Caddy, for example, should soon (if it's not
already) be compiled from source, rather than from the build server. That
means it will remain free to use, and I personally don't have to make a single
change.

If this has impacted you negatively to the point where setting up nginx is an
easier option, well - that's the beauty of choice!

~~~
tylersmith
But the software in that image will still be written by untrustworthy adware
developers. _That_ is the issue.

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

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

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

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

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

So now there will be ads even in the HTTP headers.

Coming soon, ads in the tcp headers ...

------
heipei
caddyserver.com emits those headers if you want to see them in action:
[https://urlscan.io/result/8093833b-8ac7-4d18-8f20-a02373f577...](https://urlscan.io/result/8093833b-8ac7-4d18-8f20-a02373f577a1#transactions)
Go to the first transaction, click the show button and click "Show headers".
Right now it says:

    
    
      caddy-sponsors - This free web server is made possible by its sponsors: Minio, Uptime Robot, and Sourcegraph
    

Personal opinion: I've never understood the appeal of Caddy except for the
builtin Let's Encrypt / 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.

~~~
camus2
It has a few bells and whistle and there is some work behind it, no question.
HOWEVER, the fact that it relies entirely on go std lib net/http|http2 package
implementations personally doesn't make it very useful if your developing your
application in Go directly. Caddy team didn't code all that network layer,
like Nginx or Apache teams did. You don't need Caddy to add let's encrypt to
your Go application.

------
stephenr
Just when you thought you knew what's going on.

The author has claimed that prices will _rise_ after an "introductory period":

[https://mobile.twitter.com/mholt6/status/908007933115375616](https://mobile.twitter.com/mholt6/status/908007933115375616)

------
stephenr
Copied comment from the other HN thread:

$50 dollars a MONTH PER INSTANCE for a piece of software that wouldn't even
start a few months ago because LetsEncrypt was down.

I get that software takes time and people need to eat, but holy shit on a
stick.

Edit: Oh, and I forgot the part where it also doesn't handle FQDN's properly
either.

Previous discussion, from when LE was down for a day
[https://news.ycombinator.com/item?id=14375022](https://news.ycombinator.com/item?id=14375022)

~~~
Whitestrake
I think your outburst might be rooted in a misunderstanding.

As stated in a few other places in this thread, the software remains 100%
free, including for commercial purposes.

In order to make use of the build server at caddyserver.com, you need to have
either a personal or commercial license. The build server provides precompiled
binaries with your customized selection of plugins included.

The use of the build server is in no way necessary for the deployment of Caddy
in any circumstance.

~~~
stephenr
I understand that the source is available.

My surprise is that you think anyone will pay $50 per month per instance
forever, for a build service they might use only once, and that still requires
them to actually do all the work to install it and run it as a service.

------
gtirloni
If Caddy had focused on providing commercial support to companeis that need
it, this would have been a good day.

As it is, they are adding artificial roadblocks for open source users while
providing minimal benefits to commercial users.

Someone didn't think this through or is out of touch with how to make money
with open source.

------
kradle
Just wanted to add that we've experimented with Caddy awhile back and, while
it didn't suit our needs at the time, the first impression was a good one and
I've since kept the project in the back of my mind.

However, the responses from the Caddy folks here and at
[https://github.com/WedgeServer/wedge/issues/2](https://github.com/WedgeServer/wedge/issues/2)
have been abysmal and without a clear change in course I'd feel embarrassed to
recommend it to colleagues.

It's not even about the licenses, as others have said, this is just bad form.

~~~
mikewhy
I feel like I'm taking crazy pills: the caddy folks come across fine in that
issue. In fact everyone does, except for the person who thinks everyone
working at a company are on the list of contributors of a github project.

------
donatj
Caddy is OK, easy to setup on a personal machine, but nginx's performance
trumped it completely in our testing. Particularly when requesting large
numbers of files concurrently.

I genuinely don't know why a business would use Caddy over nginx, especially
given the new commercial licensing scheme. nginx really isn't that hard to
setup.

~~~
sfifs
Running Caddy is literally copying a binary and your site over and setting up
the systemd config. LetsEncrypt works automagically out of the box.

~~~
rlonstein
> LetsEncrypt works automagically out of the box

Provided you let Caddy manage all the certs and/or permit dynamic dns updates
on that host. Went through this last night and it's underdocumented when you
want to handle it yourself with TXT records and explicit cert/key.

------
callahad
My first thought upon finding out that Caddy's source was still under an open
source license was "can that change, too?"

As far as I can tell, the answer is "not unilaterally," as I don't see any
requirements for copyright assignment in the contributing guidelines
[https://github.com/mholt/caddy/blob/master/.github/CONTRIBUT...](https://github.com/mholt/caddy/blob/master/.github/CONTRIBUTING.md),
nor in merged pull requests.

------
throwa34943way
Didn't Caddy got like $50.000 from Mozilla to work on the open source version?

Is Mozilla OK with this? Maybe Mozilla should give money on free software
projects that plan on remaining free instead next time...

[https://blog.mozilla.org/blog/2016/06/22/mozilla-
awards-3850...](https://blog.mozilla.org/blog/2016/06/22/mozilla-
awards-385000-to-open-source-projects-as-part-of-moss-mission-partners-
program/)

------
FrumpMuppet
I don't know why people are freaking out about this so much. It's one header.

Also, it'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.

It'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't work on your
machine. The project is written in Go and has no external dependencies so
building from source is literally just:

    
    
      - Install Go if you don't have it already
      - Run `go get -u github.com/mholt/caddy/caddy`
      - cd to $GOPATH/src/github.com/mholt/caddy/caddy
      - Run `go install`
      - Use the resulting caddy.exe file for free like you always have done
    

If you don't like the Caddy-Sponsors header then you can just edit the
`github.com/mholt/caddy/caddyhttp/header/header.go` file and comment out the
lines:

    
    
      if name == "Caddy-Sponsors" || name == "-Caddy-Sponsors" {
          // see EULA
          continue
      }
    

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:
[https://github.com/mholt/caddy/wiki/Extending-
Caddy](https://github.com/mholt/caddy/wiki/Extending-Caddy)

@mholt has made the entire process so unbelievably easy that the whole process
takes literally minutes...

------
xena
i personally like how one of the first contact bits from caddy to a fork of it
is a thinly veiled legal threat:
[https://github.com/WedgeServer/wedge/issues/2](https://github.com/WedgeServer/wedge/issues/2)

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

~~~
mholt
I misconfigured the machine; just raised the file descriptor limit and we
should be good now.

------
pryelluw
1\. I applaud this effort.

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.

~~~
nqzero
i've been trying to come up with a license that captures enough of the
freedoms of open source to protect the user while allowing for a non-zero
cost. my license is below - it's not open source, but if you're willing to
consider licenses that are liberal but not OS, i'd love to hear your comments

[http://db4j.org/pupl/PUPL](http://db4j.org/pupl/PUPL)

~~~
pryelluw
Thanks for posting. Ill check it out. :)

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

~~~
callahad
The 503 error page was, itself, served by Caddy. Or at least it matched the
default Caddy error pages, so those parts were evidently working just fine. :)

------
tuananh
homepage 503
[https://dl.dropboxusercontent.com/s/phh5xebd1jqj27l/2017-09-...](https://dl.dropboxusercontent.com/s/phh5xebd1jqj27l/2017-09-13%20at%208.41%20PM.png)

~~~
mholt
Ugh, I forgot to raise the file descriptor limit when I re-provisioned the
site. Leave it to me to blunder that. :)

------
nqzero
as a developer that's also struggling with finding a balance between the good
things that open source helps guarantee and a viable business plan, i'm
intrigued by this discussion

the approach that caddy has taken appears to be a bit of good cop / bad cop.
they're maintaining, at least for now, the apache license but they're also
using trademark threats to prevent forks (i believe in violation of the github
TOS)

the approach that i'm hoping to take is quite different. i'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)

[https://github.com/db4j/pupl](https://github.com/db4j/pupl)
[http://db4j.org/pupl/PUPL](http://db4j.org/pupl/PUPL)

\- you can freely copy, modify and distribute the software

\- non-production use is free, as is production use on up to 10 cores

\- prices are predictable and non-discriminatory

how would you feel about using software (in the infrastructure space) under
this license ?

------
davb
> 1/4 price of comparable servers

Which servers?

~~~
tiernano
Wondering the same thing... nginx has a commercial option, but does not force
you to use it if your using it in a business environment... iis is only
available on windows server, and that costs about 600 quid for a standard
license. That’s a one off cost... so... it might be quarter of the cost of
enterprise (3k give or take) but over the life time of the box, it would end
up being more...

~~~
Whitestrake
Caddy's new commercial licensing, like nginx, is completely optional as the
actual source license continues to be Apache 2.0.

For any business running their own web servers, compiling Caddy themselves
instead of utilizing the build server at caddyserver.com is a trivial step
that also gives them greater control over the binary they end up using anyway.

~~~
tiernano
Yea, but in the case of nginx, their binaries are Free full stop... it’s only
extras or support that need license...

------
greenbast
Obligatory link to Richard Stallman on "free vs open":

[https://www.gnu.org/philosophy/open-source-misses-the-
point....](https://www.gnu.org/philosophy/open-source-misses-the-
point.en.html)

------
jtmcmc
This was a fascinating thread of a product I would possibly have used but now
won't...

------
NuSkooler
Hi Matt! I've been using and advocating for Caddy for a while now, but I have
to say this is a huge put-off.

Don't get me wrong here, I'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 / OSS space for a variety of reasons.

I encourage you to re-consider added headers. Perhaps look at a more heavy
handed download process such as the "Pay as you want" system used by
ElementaryOS's download page
([https://elementary.io/](https://elementary.io/)).

~~~
mholt
Thanks for your comments. I think that this thread can be added to the bucket
of all the others that reveal the unhealthy expectation in the FOSS community,
and I'm not convinced that the "variety of reasons" are compelling.

It's regrettable that our announcement today is so controversial. As much as a
donation model is easy and safe, it is not a business plan. (We tried it.)

~~~
tylersmith
"the unhealthy expectation in the FOSS community"

Nobody is "expecting" you to make good software, we're just saying that now
that you've turned a formally mostly decent piece of software into adware with
an untrustworthy author there's no reason to not just use better software.
Software that doesn't molest your traffic. I wish you luck with your business
but don't know why anybody would pay for software written by you two ever
again.

~~~
kyledrake
You don't think you're being a little melodramatic here? We're talking about a
change to a _Server header_. Nginx doesn't let you remove their server header
either, and _their_ business model is to restrict access to important
functionality on nginx now. Do you think that's a morally better approach?

~~~
tylersmith
We're talking about adware modifying traffic to pester you into licensing. The
nginx model of selling additional features is in fact much better.

~~~
kyledrake
It only advertises to people hitting your site with curl or looking at the
HTTP headers, so basically sysops guys curious about what your stack is.
Actual end users will almost never see it. So what?

We switched to OpenResty lately for our nginx bundle and it changes the nginx
Server header to OpenResty, and I cared so little I didn't even bother to put
a sed command in our install script to change it. It could say Diet Pepsi Uh
Huh It's The One.. who cares? Maybe I'm going to do that with the next update
just to make a point. The only reason anybody would even notice is because I
told them about it.

FOSS is in serious trouble right now because the funding model is in shambles,
and the only way we get anything good funded now is if the megacorps decide to
fund something. We need to find better ways for the little guys to put food on
their tables, or we're doomed as a community. We tried direct payments to FOSS
devs, and that went up in flames. These guys came up with a clever and
unintrusive way to advertise (really just to show sponsors, which isn't really
even advertising) to tech people, and instead of being supportive of a novel
way to fund their project everybody screams bloody murder at them.

If the FOSS community wants to continue to exist as a venue for quality
software, the first step it needs to take is to stop chewing its own arms off.
Please have a perspective here and understand that these developers are just
trying to make a living, just like all of us are. The only thing worse than
starving to death making something free for other people is doing it while
they sit there and hate you for trying to figure out how to put food on the
table. All the quality people will leave FOSS forever, and we'll be stuck with
a bunch of random unmaintained garbage and bizarro overengineered UI crap
Facebook wants to publish to status compete with Google's bizarro
overengineered UI crap, and we'll all be worse off for it.

~~~
tylersmith
> It only advertises to people hitting your site with curl or looking at the
> HTTP headers, so basically sysops guys curious about what your stack is.
> Actual end users will almost never see it. So what?

Injecting any data into network traffic is unacceptable.

> Please have a perspective here and understand that these developers are just
> trying to make a living, just like all of us are.

Sure. I also work on an open source project for a living. But modifying
network traffic should not be an accepted form of DRM IMO. I fully support a
pricing model. If this change hadn't prompted me to rip out Caddy and replace
with nginx I would have paid the Caddy team instead of paying nginx which I do
now.

They have the right to do it, but it was a foolish mistake if their goal is to
get and retain customers.

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

------
tylersmith
I fully understand commercial licensing, and would willingly pay for it, but I
am certainly not paying for software that thinks it's reasonable to inject
headers into requests as a form of licensing control.

I'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'm seriously bummed this is
the route Matt has taken things. What a shockingly awful surprise to wake up
to.

------
kevinburke
I'm excited that Caddy has taken steps to ensure its long term survival. Sad
people can't be bothered to pay for software they like.

~~~
throwa34943way
> Sad people can't be bothered to pay for software they like

They got $50.000 from Mozilla, AKA free software foundations financing
commercial software with grants, but what is your opinion on this Mr Burke?

------
Xunxi
What are the key differences between Caddy and Centminmod? I would like to
know the comparative speeds, use cases and disadvantages if any.

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

------
unlocksmith
@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 "Minio" from the header.

I am also sad about how the opensource version of Caddy project no longer has
a website and being ignored. -ab

------
vbtechguy
Matt's response [https://caddy.community/t/the-realities-of-being-a-foss-
main...](https://caddy.community/t/the-realities-of-being-a-foss-
maintainer/2728/)

~~~
warrenm
Yep - where he goes into insulting more-or-less everyone who has criticized
him and the project

------
memiux
Everything is getting expensive.

------
jimjimjim
Such amazing hostility.

Open source developers NEVER owe users anything. Never.

Stop being so entitled.

~~~
jazoom
I'd agree with you except this is a bait and switch. They're allowed to do it,
but it's rude. 30 days is also minimal notice.

