> 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.
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.
Which is frustrating, because Caddy is a great product, especially from a solo operator standpoint. Configuration is simple and the defaults are sane. The humans behind Caddy are nice people.
And while this move has somewhat soured my opinion of the project, I'm not so much angry as I am... sad. I want to use Caddy. I am using Caddy. But I don't want to use this Caddy, at the moment.
For example: You might know that all domain names are in the root zone, named ".", so any domain actually is resolved to e.g. news.ycombinator.com. And if you enter the domain with the dot, it is the same DNS name, and should give you the same result. Apache does that, Nginx does that, Google’s cloud does that, Amazon’s cloud does that, all major sites do that...
Caddy considers it irrelevant, and something users should add manually for all of their rules if they want it. Ignoring all the RFCs, because of personal ideals.
Exactly. I've heard raving reviews of how amazing Caddy is, but as I said earlier in this thread, the threat of filing trademark violations before even giving time for intent to be reasonably argued feels like a power play to scare the forks. It also makes their "We love Open Source!" claims feel much less genuine.
This is just like Red Hat. He's put a lot of work into his product, whether free or not, so don't use trademarked name. CentOS has the same restrictions about not using Red Hat in their distribution. This is just like someone releasing a book for free, and getting mad at someone that decides to sell (or give it away) under the same name when they've trademarked the name. Don't do that. If you're going to copy it, change the name.
Also, keep in mind a trademark is only good as long as you enforce it. If you don't enforce your trademark, it can be seen as (and argued in court as) having become a generic name, and you lose it.[1]
> This is just like Red Hat. He's put a lot of work into his product, whether free or not, so don't use trademarked name.
Unfortunately when you fork a repository, it does copy the entire source tree. I can't type that fast, so there was a short period when the original README was still there.. there's also probably 400 other repositories on GitHub with the same problem. I knew this needed to be resolved, and it was within a timely manner.
I'll also note Caddy is not a registered trademark.
> Don't do that. If you're going to copy it, change the name.
When I created the repository I deliberately chose a different name and deliberately opened up the issue tracker and created an issue to track the work in renaming e.g. the README references. I created this issue before the "you're violating our (unregistered) trademark!" issue was created.
My intentions were good from the start, please don't talk to me as if that was not the case.
> there's also probably 400 other repositories on GitHub with the same problem.
As I said in a sibling thread, it's not just that it was forked, it's that it was forked and then intended/was advertised as competition. Forking and keeping the name Caddy for private use isn't a problem, so I doubt many of those other repositories are actually a problem.
> I created this issue before the "you're violating our (unregistered) trademark!" issue was created.
If this situation arises again, it may be better to wait until the name issue is resolved before advertising it to a forum of people. Regardless of what your future intentions were, you were competing at that point, and you hadn't dealt with the naming yet. I understand the desire to both capitalize on the issue and help those that feel the same as you about this, but doing so here stepped on the rights of another individual or group.
> My intentions were good from the start, please don't talk to me as if that was not the case.
I think the intentions of the people with claim to the Caddy trademark that contacted you were good as well. The difference is that you noted the claim here and also editorialized it with a sarcastic "classy!". Really, it's that last bit which spurred the tone in my response, since it implies bad behavior on their part for what is essentially protecting what they consider theirs (and something they are legally required to do if they want to keep it). Without that, you might have gotten a more measured reply, or none at all as others might have been sufficient. Your intentions might have been good from the start, but they could have been a little better when deciding the wording for that announcement.
Note: If you publish your source code in a public repository on GitHub, according to the Terms of Service, other GitHub users have the right to view and fork your repository within the GitHub site. If you have already created a public repository and no longer want users to have access to it, you can make your repository private. When you convert a public repository to a private repository, existing forks or local copies created by other users will still exist. For more information, see "Making a public repository private."
It's not about forking, it's about forking with the intent to compete (which this was, as it was advertised as an alternative here). In that respect, regardless of the Github.com terms of service says, federal trademark law is likely to supercede it.
> 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?
> Why's that? (And even among your technical visitors, how many of them actually inspect the response headers?)
I dislike this for a few reasons. Firstly, it honestly comes across as petty. I'm using the server for personal reasons, it's for a non-commercial site which I don't make money off. I don't display ads, and suddenly I'm now being forced to serve ads to my visitors. The medium of delivery is utterly irrelevant to me.
Secondly, it makes it more difficult to take steps to make it less obvious which web server is being used. I'd do this to make it slightly more difficult for script kiddies looking to exploit recent vulnerabiltiies - not because I think security through obscurity is a good idea.
> 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?
No. The point is, you've annoyed someone who liked your software, used it for personal use (costing you nothing) and would've happily recommended it to colleagues.
> No. The point is, you've annoyed someone who liked your software, used it for personal use (costing you nothing) and would've happily recommended it to colleagues.
This is worth keeping in mind. Personally, this change is putting me off Caddy to the point that I might stop using it for personal sites. The big feature for me - instant LetsEncrypt TLS certificates - can be done on other servers now fairly simply. So the end result might be that I no longer use Caddy, which means I'll no longer have it in mind for commercial projects I work on.
I have pretty much the same reaction. I was considering moving some stuff to Caddy, but looking at this, I'd need to create my own build pipeline to keep rubbish like this out. No thanks. I'll use tools that give me the options of turning things like this on/off without having to compile my own copy.
I was pleasantly surprised at how quickly I was able to rip out Caddy and replace it with nginx and Traefik (in different cases), even with the LE automation. It shouldn't be much of a burden to move your person projects I don't think.
> Secondly, it makes it more difficult to take steps to make it less obvious which web server is being used. I'd do this to make it slightly more difficult for script kiddies looking to exploit recent vulnerabiltiies - not because I think security through obscurity is a good idea.
I thought about this as well, but I'm not convinced that hiding the Server header or anything like unto it is really that beneficial. Most exploits are automated anyway. And if it becomes common to hide or remove the Server header for Caddy instances, then guess what becomes its new signature?
> used it for personal use (costing you nothing)
This unfortunately isn't true. It costs a LOT of time and effort to maintain the build infrastructure and the Caddy project itself, even if its users don't make a profit from it.
> I thought about this as well, but I'm not convinced that hiding the Server header or anything like unto it is really that beneficial. Most exploits are automated anyway.
It probably doesn't help much but it can't hurt. Some servers send back a "Server" header that tells you the OS being used with the Apache and PHP version up to the minor version number for example. There's no benefit to leaking this information and it's potentially useful to an attacker even if only marginally so why risk it?
> It probably doesn't help much but it can't hurt ... There's no benefit to leaking this information and it's potentially useful to an attacker even if only marginally so why risk it?
Actually, it can hurt. One really good reason to note it is that for the same reason an attacker might want to know the version, a defender (such as an employee) might want to as well. I've noted exploitable versions of software found to other divisions of the company I was working at before. For the attacker, it's really not much of an issue anyway, they'll just throw every exploit at it anyway (my webserver logs were always filled with random exploit attempts such as for wordpress and IIS).
> This unfortunately isn't true. It costs a LOT of time and effort to maintain the build infrastructure and the Caddy project itself, even if its users don't make a profit from it.
Yes - it is true.
The incremental cost for every additional Caddy install is 0 (or, as close to 0 as you can calculate for bandwidth charges).
So ... no. It does not cost you anything for an additional user to run Caddy. It is a sunk cost for any given new development - whether one person runs it, or millions.
But instead of realizing this, you've now put-off a vast swath of potential users.
> 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?
Really? I don't see it as any different than an unregistered document editor saving "created with an unregistered version of X" in the comment section of saved documents that it edits. Stuff like that has been going on for decades.
Sure. Some people are fine with using free-as-in-beer software if the "cost" of that is the maker gets some free advertising. Some people -- like many in this thread -- are not ok with that. Both positions are perfectly valid.
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.
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.
Looking at it again, it seems their cloud configuration backup service has special client code and could qualify as such. But the primary thing seems to be access to information, the devs and an officially certified VM for AWS.
commercial sites have the easy ability to go to https://github.com/mholt/caddy; download the source; remove the header from header.go and server.go; compile; run
i'd venture to guess many build the binary themselves already. so they can add their own tweaks.
how would anyone be able to prove a website is being ran by caddy if the server doesn't announce that it is caddy?
I think the biggest issue is that you've shown you're willing to modify traffic for license control. If you'd simply released commercial support for $500/mo/instance I'd have gladly paid for it in my products and think many others would have too. Showing such obtrusive forms of DRM makes me not want to ever use any of your software again. I've spent the past couple of hours migrating from Caddy to nginx and I've contacted them about buying support. I guess the silver lining was the nginx was was easy to migrate to.
I've dealt with similar-ish situations before and would suggest that you consider (I am not recommending, merely suggesting) adding a config option -
thanks_sponsors false
then people who really hate that header can disable it but it's clear what they're doing with the software they're paying no money for. If people complain about that well, that's their issue IMO. And they have to be explicit about how they're behaving.
This has worked well for me in the past. If you'd be interested chatting about how/why reply and I'll drop you an email.
peronally, while totally leaving my life unaffected, it'd be one of those thoughts in the back of my head, both knowing that there is some random text being output (need to optimize everything!), and that there is something intentionally uncontrollable there, and to a lesser degree, something there to intentionally bother me.
Can I ask who came up with the idea, and what other alternatives were discussed? Was this requested by the sponsors?
edit: as a further question, if this results in a fork (well, I guess thats a bit late but) or an increase in the number of from-source builds, would you seek to make those two options more difficult? (e.g. legal pressure, or mangling the codebase in some way with hard to acquire dependencies)
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.
Even the time required to negotiate a custom commercial license costs more than the license is worth (and/or more than the switching cost) for most personal users.
I was using Caddy because I don't have time in my day to configure Nginx; but I also don't have time in my day to build Caddy from source to repackage+deploy it to my infrastructure. So back to Nginx it is.
What I would have time in my day for is a standardized one-time PayPal payment in exchange for a commercial license authorizing me to use Caddy for a site with traffic not exceeding [X amt any commercial site would quickly hit]. You know, like buying an SMB license of any other on-prem web-service software.
My job pays me units of money in exchange for a finite time per day spent dedicated to advancing their goals. There are more potential things to do for the company than fit into the time they pay me to spend; and I'm not going to work for free past that time just to fit all those things in. Therefore, I have to optimize—to choose which things are most worth the company's time. Compiling and configuring software packages are rather low on that list (which shouldn't be surprising, given that I'm a programmer, not an ops person.)
In the time it probably took you to type that comment, I compiled caddy from source. I've never even used it before, but in general Go programs are very easy to build.
Personally, I prefer viewing HTTP headers in the comfort and privacy of my Secret Mountain Laboratory, with my fluffy cat on my lap, usually in the middle of the night, and often in complete silence. That Caddy has chosen to interrupt what to me is a sacred space with advertisements, while burning additional bandwidth, all day every day, for no good reason at all because only weirdos like me are going to see it is beyond obnoxious. In my view if this doesn't cross the line into being antisocial, then it walks right up to that line. Do what you want with your code, and due to the MIT license, so will the rest of the Internet. And PS using a Trademark in a product comparison is covered by fair use. You all really should familiarize yourselves with the Streisand Effect and fundamentals of public relations.
What if, instead of adding headers, you did something more like mobaxterm where there are games that can only be removed by paying for the commercial version. Like all personal caddy servers respond to /nethack?
> 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.
..with regard to the distributed binaries only. The source code that you can compile yourself has no such restrictions and is still Apache 2.0. Dual licensing like this is common.
I get that a project want to sell licenses - but as a sibling comment states, Caddy appears to no longer be Free software, breaking freedom 1 (modify), 3 (distribute modified copies).
[ed: it appears I misunderstood, only the binaries are under eula - so Caddy is in the (somewhat) unique position of distributing non-free binaries and Free source code. Kind of like a gpled iOS program I guess.]
In addition, I'd consider this a (small) security vulnerability: the presence of the ad header effectively screams Caddy to fingerprinting tools. There's a reason apache and friends have a "prod" header config/setting.
[ed: seems a bit cruel to force the most resourceresource-limited users to advertise details about their stack; presumably those that know enough to compile themselves might also have more resources to keep up to date on security issues etc]
Synergy, the app that allows a computer to share its mouse and keyboard over the network to other computers, did a more aggressive move a few years ago. It's still technically GPL because you can compile it yourself, but they charge $20 for a binary license and to enable certain features.
I have similar concerns. I practice good security but I also enjoy security through obscurity. I prefer to prevent my users from knowing what web server is serving their content. Now unless I start compiling from scratch, everyone will know I use Caddy and I don't like that.
Alternative is to run Caddy behind HAProxy or Nginx or something similar that can strip those headers out.
I think it's time to just rebuild and use Nginx again and try to get QUIC and automatic LetsEncrypt working.
Note: If you publish your source code in a public repository on GitHub, according to the Terms of Service, other GitHub users have the right to view and fork your repository within the GitHub site. If you have already created a public repository and no longer want users to have access to it, you can make your repository private. When you convert a public repository to a private repository, existing forks or local copies created by other users will still exist. For more information, see "Making a public repository private."
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 restrictions);
(b) distribute, sell, sublicense, rent, lease or use the Software for time sharing, hosting, service provider or like purposes, except as expressly permitted under this Agreement;
(c) redistribute the Software or Modifications other than by including the Software or a portion thereof within your own product or service, which must have substantially different functionality than the Software or Modifications and must not allow any third party to use the Software or Modifications, or any portions thereof, without a proper license to account for its use;
(d) redistribute the Software as part of an "appliance", "consumer device", or "virtual server";
(e) redistribute the Software on or to any machine which is not directly under your control or management;
(f) remove any product identification, proprietary, copyright, or other notices contained in the Software;
(g) modify any part of the Software, create a derivative work of any part of the Software (except as permitted in Section 4), or incorporate the Software, except to the extent expressly authorized in writing by the Company;
(h) publicly disseminate performance information or analysis (including, without limitation, benchmarks) from any source relating to the Software;
(i) utilize any equipment, device, software, or other means designed to circumvent or remove any form of copy protection in place by the Company in connection with the Software;
(j) use the Software to develop a product which is similar to or competitive with any of the Company's product or service offerings;
(k) share, distribute, or publish authorization codes, URLs, keys, or any other data provided by the Company that is intended exclusively for your account and not others, otherwise the Company reserves the right to terminate your Subscription without notice;
(l) violate the Terms of Service as posted on the Company's website;
{{- if eq .Type "personal"}}
(m) use or distribute the Software commercially, including to, for, or within a company or for business purposes;
(n) use or distribute the Software as any part of a formal or informal profitable venture, or as part of a product or service being sold either directly or indirectly;
(o) block, hide, obscure, modify, or remove the promotional header field named "Caddy-Sponsors" (and any case variants) from HTTP responses;
{{- end}}
I don't understand. It's still open source. I mean I realize it's boiler plate stuff to keep people from just changing the binaries to remove stuff they don't want, but it's open source. You can just recompile it.
Boiler plate stuff like this really makes me question their commitment to open source.
They really should have just created a commercial or enterprise version, with new features geared towards large businesses available as plugins only for that version (AD/LDAP auth, single signon, more complicated stats, etc. etc.)
It's like they didn't learn from the 90s. Don't start charging for what was free; add new features to the paid version, or for OSS companies, up your commercial support and custom offerings.
Prohibiting reverse engineering of the binaries is a standard restriction. If prevents not-well-formed copies of the source code being distributed, and as you said, they can just download the source from the repository. :)
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?
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.
> 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 absolutely operating in bad faith here. The summary at the top completely omits the case of commercial users building from source, and the language confusion between "use Caddy" vs "use or distribute official Caddy binaries" intentionally tries to confuse the matter.
> Remember that building Caddy from source is still subject to the Apache 2.0 license which requires attribution and stating changes.
This is incorrect. Building Caddy from source and using it in your infrastructure requires no disclosure according to Apache 2. It is only when you decide to embed it in an on-premises version that you sell to customers (who run it on their infrastructure) does the disclosure requirement kick in.
> Building Caddy from source and using it in your infrastructure requires no disclosure according to Apache 2.
You have to follow the terms of the license whenever you distribute it to someone. Unless you are a single-person shop, that might include employees who have access to the binaries but aren't actually interested in the source. You still have to appropriately disclose changes and keep the attribution notices.
You don't have to notify users who just access the server over the network, but the statement isn't factually incorrect: Apache 2.0 still applies.
Apache 2 license applies, the question is whether attribution and disclosure are required. And the answer is "Building Caddy from source and using it in your infrastructure requires no disclosure according to Apache 2." Disclosure is required when selling on-premises software that includes the project in question
Are you saying that installing the software on your infrastructure or checking the code into source control doesn't constitute redistribution, even when others have access to these? IANAL, but it seems to me that the license requires you to give each recipient appropriate notice, no matter what your relationship with the recipient is.
Let's take a simple example of deploying Caddy on a digital ocean droplet that you are paying for. The end user in that case is you, not the people who access web pages served by Caddy since they are not receiving a copy of Caddy in the course of using your site.
To tie back to the original comment:
> It is only when you decide to embed it in an on-premises version that you sell to customers (who run it on their infrastructure) does the disclosure requirement kick in.
In that situation, when dealing with an on-premises deployment with another person or organization, the end user is the counterparty. You are required to disclose to them, but they are not required to disclose to users of their web site.
Note: this type of scenario is why AGPL emerged in the first place.
Now what happens when you have a colleague who logs into your droplet to configure the Caddy server. Have you distributed the binary to them? Are they entitled to seeing the original NOTICE file?
No. This is a simple case of someone else using software on your machine. Similarly, You aren't distributing "Windows" every-time someone logs into do remote tech support.
> 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.
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?
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".
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.
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.
> Well, what do you think their next step is if they refuse?
A valid point, and one we both know the answer to - I won't try to argue otherwise.
While I think their statement on the issue page was not handled very well, and I would have tried to avoid the implicit threat... Do you think they should have just left it alone without saying anything once they were made aware of it?
Yeah, they could have got away with waiting, maybe even a few days for everything to settle before making contact.
But they're here in this thread, paying attention to the discussion, and people have wasted no time in making the fork in the first place.
At the very least, I think the "absolutely devoid of class" comment is uncalled for. I don't think it's unreasonable, not even in terms of time frame, even if I disagree with the manner in which it was done.
> Yeah, they could have got away with waiting, maybe even a few days for everything to settle before making contact.
What frustrated me was that I'd already turned on the issue tracker and created an issue to monitor progress on removing links and references to Caddy.
So let's say I fork the project on GitHub, as others have done, and have not modified it. The APL permits redistribution of the source code, of course, so this is permitted.
Now, simply by clicking "Fork" -- and doing nothing else (i.e. modifying the source code), I am now violating their trademark? That's bullshit.
@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.
Eh. Still kind of shitty to have had access and then have it removed, and then say 'nothing has really changed, guys!'.
If they rephrased it to admit they're moving to a Red Hat model of "pay for binary", the news would have fared better. More straightforward, with a direct comparison to a current, successful brand.
Let's face it: They realized their product was popular, took advantage of tons of interest and documentation/blogs/hype in the community, then decided to charge for binary distribution. It's a bit of a burn.
> Let's face it: They realized their product was popular, took advantage of tons of interest and documentation/blogs/hype in the community, then decided to charge for binary distribution. It's a bit of a burn.
Or another way of looking at it: Open source has to be subsidized (either through free time or commercial backing) in order to continue to contribute to open source. The amount of time and effort to maintain a popular open source product is insane. They are creating a business model to continue to subsidize their open source contributions. Whats the alternative? Burnout and stagnation which would just result in forks and fracturing of the community if they are lucky.
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.
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.
> 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.
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.
> > > "this bug is yours because you self compiled this thing",
> never heard anything like that in my life.
Off the top of my head, Google requires you to own any new third-party dependencies you pull into the source tree. Therefore, Google engineers think very carefully about their dependencies.
Also, anecdotally, once my team (at a $100M start-up) decided vanilla Rails/ActiveResource didn't fully support our needs and we'd have to fork/extend it, then we needed an owner. That guy was me. Before I took on ownership, we'd simply file issues with the ActiveResource team and offer changesets if we had the free time to debug. When we brought it in internally, I was required to field all support. It definitely cost our company more, obviously, and it would've been much more convenient and possibly much cheaper to rely on a third-party vendor.
> Off the top of my head, Google requires you to own any new third-party dependencies you pull into the source tree. Therefore, Google engineers think very carefully about their dependencies.
And I doubt the same Google would just download some random executable on the net and use it in production instead of doing a extensive source code review and building the executable themselves if they can. My point exactly.
> The bigger the company is, the more likely they are to go with just building Caddy themselves instead of paying for it.
That's not true at all. Big companies pay for software, not small shops. If J Developer says to their boss, "Well, I'd really like to use this thing, but it costs $X" and $X is sufficiently small, companies will frequently just go for it. No technical manager worth their salt is going to argue for their engineers who cost $X0,000 per month to be spending time managing a bespoke build pipeline to get out of paying somebody.
> 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.
The auto-TLS aspect (among many other niceties such as simple configuration) is really quite nice for a large swath of users.
> No technical manager worth their salt is going to argue for their engineers who cost $X0,000 per month to be spending time managing a bespoke build pipeline to get out of paying somebody.
Any technical manager worth their salt won't be letting developers make ops decisions.
Oh right, it's devops so you don't have ops, you have developers who think this is a good deal
> Or just pay the person who worked hard on the project and not be a selfish prick.
and got granted $50.000 to maintain an open source project. Maybe that person who "worked hard" should give back the money, instead of being a dishonest "prick". And let's be frank, caddy is a fucking mashup. the great majority of its functionalities come from Go std lib or 3rd party libs, maybe caddy should give money back to them and all its contributors as well.
Absolutely! I really think that should be payed forward as well, I'd love to do the same with my projects since they lean heavily on other work, but ultimately you have to become sustainable first or there isn't much to give back.
The only alternative is to do the typical VC route, have some startup that makes zero revenue and just hacks on OSS, which is a bigger drain on the economy and I don't believe produces better work anyway.
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.
Yeah, I'm in the same position now. As you mention, NGINX is reasonably straightforward to set up if you're remotely technical or hell, if you can follow a tutorial.
It's a huge shame, because I used to recommend Caddy for how easy it was to get TLS to work.
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.
In terms of cash, $1200 a year is a lot to me personally, I'm a student, I have no income, and I'm trying to bootstrap a startup. $1200 could feed me for a year. Even when I had my PhD stipend, $1200 was a months stipend.
I originally chose to use Caddy over NGINX because it made https easy: just download, configure, run. If I have to remove the sponsor code and build it myself, it loses the advantage it had over NGINX because now I've got to spent time creating a build script and updating it whenever Caddy makes changes. With NGINX, sure, I'll have to configure it and letsencrypt, but I'll only ever have to do that once.
What on earth bootstrapped startup needs ~24 Caddy licenses? If you're operating at that scale and not generating revenue, your business won't last long anyway...
I do love the HN community sometimes, that's two people who've told me my startup will fail because I've decided Caddy's commercial licence isn't a sensible option for me, yet neither has actually understood the details of the change.
It's $100/month for 2 instances, you can only pay annually, so $1,200 is the minimum you can pay and it nets you two instances, not 24.
If it was $100 for a year and included 5 license to cover live and dev environments, I'd probably have just bitten the bullet and paid for it. I don't really care for the "basic email support" being offered, I just want to serve web traffic.
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".
> 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,
The problem with the HTTP header is that it reveals details about which www server you're running to the user, who may be a potential attacker. This makes it easier for a potential attacker to select tools with which to attack you. Apache and Nginx (and most likely other web servers) offer config settings which disable emitting information about the software and version in use. There are other ways to guess the software/version but it becomes harder.
This is an actual security problem, not some issue of feelings.
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.
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.
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. :(
> 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.
There are a variety of docker containers available which integrate letsencrypt and nginx. Personally I use the linuxserver.io letsencrypt container to proxy my personal projects. You specify the domain names you need a certificate for at container startup via an environment variable and it takes care of getting the certificate issued and renewing as needed. Restarting with additional names added or names removed will result in the previous certificate being revoked and a new one issued as appropriate. This replaced my use of caddy for my personal projects about 3 weeks ago. A decision I debated before making and am now glad I made.
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.
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.
> 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.
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.
Separation of concerns (serving http/s content and registering/renewing tls certificates) is a feature. Combining them is an appeasement for devs who think they don't need ops.
caddy wants $1200 a year minimum, for 2 instances. For $1200 I'll give you a setup script for HAProxy/Certbot that will work on infinite servers, and will keep working next year without you paying me.
This is like the weird "SaaS all the things" model taken to the extreme.
Caddy performs worse, has crazy defaults (seriously, won't start when LetsEncrypt is down!?) and wants to charge you FOREVER to use their build service, even if you only use it once and never update.
Given the .. unusual... plugin module (compile one caddy build per plugin-set x arch combo), I don't see ohw that could possibly translate into proper apt/whatever packages.
If, during the install, it's compiling caddy, that's probably not what people want.
How will it actually work, given plugins are determined at build-time and there's a phenomenally large matrix of plugin X arch combos?
You forget that these are the same developers who thought it makes sense to refuse to start with a cached,valid tls certificate because LE's ACME API was unavailable.
Of course they'll do something user hostile and ass backwards!
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?
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.
If the current pricing is too restrictive for your business, feel free to build from source (Caddy source code is Apache licensed)!
Or contact us, sales@lightcodelabs.com, if you need a commercial license but your startup / side project has a constrained budget. We'll see if we can work something out for you.
> Does anyone know if there's significant pain in maintaining a docker image that compiles source code like Caddy on rebuild?
Yes, Cory specifically is looking into the ability to get custom distro packages and containers through our website for our customers.
Totally understand about bootstrapping a business and the costs there. Feel free to contact us: sales@lightcodelabs.com since your business is just starting out and doesn't have any revenue yet, and we'll see about a custom plan that fits you better.
Thanks! While I appreciate the offer to work with sales, it really abstracts the simplicity of Caddy (ex: grab this binary, add these couple lines, and BAM you have a site).
I want to shout from the rooftops about Caddy and how awesome it is to effectively roll out side projects. If I had to create a blog post saying "contact sales if you're just starting out" at the end, it would leave a bad taste in my mouth.
An amazing part of the open source tech community is the ability to read a blog post, put the concepts together, and see the light (or not). I've grown so much as a professional by reading blogs, forums, etc and I'd love to give back. Before today, Caddy stripped away the complexities of maintaining a webserver and allowed entrepreneurs to focus on what matters. This move appears to add the complexity back in for those who want to still use it as open source.
Once again, love the work you've done on the project and understand the desire to make money. IMHO a model similar to nginx or an "honor system" (companies generating more than X revenue need to purchase a license) would be better.
> Does anyone know if there's significant pain in maintaining a docker image that compiles source code like Caddy on rebuild?
It's insignificant. Multi-stage Dockerfiles mean you can build from the Golang image, pull mholt/caddy, compile to a binary, then distribute the result in a tiny Alpine image.
I believe the maintainer of the current most popular Caddy image will be going source-compiled, too, so you might not even need to roll your own Dockerfile.
actually yes. i just opened a ticket to base the build on a freedom respecting fork. i've been using this docker build for a while to serve a bunch of sites that i host. i'm in the process of setting up a new build system, but i do push to the docker hub repo regularly.
> We now require declaring a license when requesting a download:
> https://caddyserver.com/download/<os>/<arch>?license=persona...
> 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.
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.
There are better ways to structure a business around an open source project.
Besides comprehensive support plans, you could actually pursue dual licensing (if you own the copyright to all contributions, I couldn't find a CLA), consulting services, etc. This is all in the playbook followed by nginx, Red Hat and others.
I think even the dreaded "open core" model would give yours users less friction than what you're implementing.
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.
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.
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).
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.
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.
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
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.
This only helps until they start injecting data in different places. Maybe soon they'll add HTML comments or JavaScript to popup a notification. Now that they've shown they don't care about users' data security I don't know why anybody would expect them to stop here.
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?
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.
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 :(
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.
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.
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.
>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?
Loads of incredibly tech folks on HN (and that would be interested in Caddy to start with). Yet most of us explicitly do not "build from source" most of the time: it's too susceptible to breakage; doesn't play nicely with `yum upgrade`; etc.
Can we "build from source"? Sure.
But why should we have to to avoid something you've added - apparently - just to assuage your sponsors?
Charge for it. That's cool - I pay for quality stuff.
> Keep in mind that modifying the source is required to plug in any plugins, which people tend not to want to bother with.
I've only ever used Caddy without plugins, so I'm not familiar with how it works but do you mean that plugins in general must be enabled or that the specific set of plugins I want must be compiled in? If the latter then I think they are not so much plugins as some kind of extension.
It involves adding an import, and the plugin registers itself. Extension/plugin/addon -- call them what you will, I guess. We chose the term "plugin" before Go 1.8 had its experimental plugin package that, on Linux, allows dynamic linking of libraries. (There are a lot of limitations with that, for now.) In Caddy, all plugins are statically linked and compiled in.
AFAIK you have to specify plugins at compile time in the source code. Don't know if the installation scripts/endpoints that spit out the official binaries are open source, though.
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.
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!
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.
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.
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.
The issue is not forking. It is the build infrastructure to produce all the builds for each OS, architecture, and the desired plugins. This is added value that Caddy adds.
It would be great for a replicated infrastructure to materialize. If it is well maintained it is even likely to overtake Caddy in terms of users, because it would be free software.
> 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.
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.
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.
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.
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.
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 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.
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.
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.
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.
The business use case isn't just about performance; businesses also get private plugin hosting, basic email support, and in the future, other amenities as well.
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
@mholt has made the entire process so unbelievably easy that the whole process takes literally minutes...
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.
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.
> 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.
Well, just ask $50.000 from Mozilla for an "open source project" grant "like" Caddy got and you're settled for at least a year.
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
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. :)
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)
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...
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.
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/).
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.)
Maybe there is no big enough market for what Caddy is offering right now. Have you considered pursuing other directions, make it really diverge from nginx, apache features and stand out? Maybe more into an out of the box security solution with integrated scraping protection, ddos protection, vulnerability scanning protection, exploit protection, overload protection, xss/csrf protection, WAF features, full-page caching. Or even into an edge infrastructural solution for hosting companies and such, with dns management and everything.
To be clear, I'm not advocating for a donation model instead of a free personal use vs paid commercial. I'm suggesting to remove the header and urge personal users to donate a bit.
> and I'm not convinced that the "variety of reasons" are compelling.
I really don't want to be a jerk here, but you don't need to be convinced. If the general community feels a certain way, and you wish for said community to favor you, you must abide.
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.
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?
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.
> 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.
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.
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.
Lots of us (myself, certainly) do pay for software we like
This argument doesn't really hold water: there are for-pay editions of all kinds of tools out there - Caddy easily could have taken one of those routes.
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
@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
It's not $25-100/mo, it's effectively $50/mo per instance of Caddy, including your local development machine: https://caddyserver.com/pricing
Running three static sites in their own containers, plus a fourth Caddy as a reverse proxy, and your laptop? That's $250/mo. Is a buddy of yours also working on one of those sites? Oops, now you're at the $500/mo (10 license) tier.
Sure, but individuals can just use the OSS version, or something like Netlify which is ideal for static anyway. Pricing that seems expensive to individual developers is pennies for any real business.
I regret to inform people, but the world isn't free. Open source is great because it's a low barrier for people getting started with a business or project, but if a company benefits from it they should pay.
This sort of duel license fragmentation is unfortunately the only option for people like us trying to make a living from OSS.
You're absolutely correct, but it's still frustrating. :(
It's totally within rights, and the rates are completely reasonable for funded or profitable ventures. I'm just bummed that I can't quickly grab a Caddy binary and toss it in a container to help host, e.g., a little Bugzilla dashboard / frontend without worrying that I'm violating the "business use" or "internal company use" clauses.
I've used Apache, Lighttpd, Cherokee, and Nginx over the years, and this is the first time that an open source webserver has asked me to make a commercial/noncommercial distinction when using the core software. And while I could compile the OSS version, switching back to Nginx is a lower friction, simpler option.
On the upside, these decisions are mutable, and Caddy is excellent software produced by really great, reasonable people. I'm sure the kinks will get worked out eventually.
I think for anyone interested there'll be lots of docker containers and forks that keep up to date with upstream and simplify getting the binaries.
I feel kind of bad for the authors here, the rollout of this hasn't been perfect. Right now they're suffering the wrath of folks angry at what they perceive as a bait and switch. (Although I think that's a little harsh also, given that you can compile your own for free)
It seems like they would probably have been better selling it as a commerical venture from the get-go as a niche premium version of nginx.
Of course, then it's harder to gain ground that way.
Well, everyone's opinion is valid and useful as feedback.
The good part is, if you can't justify the price, surely you can justify the time to write a bash script to compile it yourself? Further up this comments page is one fantastic example. There's still plenty of options, really, not much has changed.
For sure, but I think a lot of people have to realize they're not the target market for this kind of thing. You simply cannot make a living from people trying to run their side projects for < $5/m.
Seeing people complain about paying for software is just annoying. They should work for free then, if that's their mentality.
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
Second edit: Accusation of trademark violation within an hour of the fork, classy! https://github.com/WedgeServer/wedge/issues/2