Announcing Caddy Commercial Licenses
caddyserver.com
caddyserver.com
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
> 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?
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?
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?
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.
pfSense, Ceph (prior to RH purchase) and OpenNebula off the top of my head.
We aren't putting popups on your site. :P
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.
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 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.
> 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.
Bad form.
We as users don't believe that's your choice to make.
> And if it becomes common to hide or remove the Server header for Caddy instances, then guess what becomes its new signature?
This only applies if Caddy is the only server that does this, which is not the case.
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?
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).
My issue with this is that there isn't an affordable license for small non-profit websites (like a person's personal website). I'd gladly pay if it were affordable, but it is not. So now I have to choose between incurring the wasted bandwidth of this header to my users, or choosing a different web server.
If you need a commercial license, contact us at sales@lightcodelabs.com and we'll see about working something out for you!
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.
is time the right word here?
I read HN on my own time.
So long as you organise all your code according to GOPATH. You can't just compile it in your Downloads folder.
Can you attach a concrete number to this? I think I found the example header and it's around 91 bytes, right?
How many requests do you need to service before this becomes a real issue?
You could also just build it from source...
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)
thanks_sponsors false
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.
Edit: I have been corrected. For the record, I still think this is a braindead move from Caddy.
> 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.
This statement reads to me that you _cannot_ remove it.
It also combines with freedom 3, if you can't distribute your modified version.
The code in the GitHub repository is open-source; but the binary builds from the Caddy website are not.
3. Restrictions
3.1 You SHALL NOT, and shall not allow any third party, to:
(a) decompile, disassemble, or otherwise reverse engineer the Software or attempt to reconstruct or discover any source code, underlying ideas, algorithms, file formats or programming interfaces of the Software by any means whatsoever (except and only to the extent that applicable law prohibits or restricts reverse engineering 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}}> The open source code of this Software is licensed under the terms of the Apache License Version 2.0 and not under this EULA.
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.
EDIT: I’ll refer to this historical case: https://en.wikipedia.org/wiki/SAS_Institute_Inc_v_World_Prog...
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.
I'm not excited about it as much anymore :\
[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]
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.
The EULA specifically states that this isn't permitted.
It's been working beautifully for me with full HTTP2 features, including server push. (NGINX doesn't have HTTP/2 server push for free users.)
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]
1: https://en.wikipedia.org/wiki/List_of_generic_and_genericize...
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."
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.
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.
They're going to search for commercial sites sending this header and then hit them up for money.
This is DRM.
that right would seem to preclude forcing the forked version to change the name
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."
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.
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.
>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?
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?
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.
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.
Now, simply by clicking "Fork" -- and doing nothing else (i.e. modifying the source code), I am now violating their trademark? That's bullshit.
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.
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.
I'm interested why you wouldn't have to take any of the actions listed at https://www.apache.org/licenses/LICENSE-2.0#redistribution
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.
I get the need to monetize, but the way this has been done and the responses by them to the criticism in this thread has soured the project for me.
What I really appreciated about Caddy was the lack of friction in getting started with it. This has, IMO, thrown a huge gotcha in the way.
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.
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.
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.
Yep and Caddy was, $50.000 in 2016 from Mozilla
https://blog.mozilla.org/blog/2016/06/22/mozilla-awards-3850...
If you use Caddy but don't pay for it or contribute to it's development then your criticism of the developers should reflect that imbalance.
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.
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.
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.
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.
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.
> I think it pretty much covers the case.
I think it pretty much doesnt.
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.
There is a fork without the adware now, so the smart company will use the fork to get rid of the stupid ads.
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.
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
Mholt got $50.000 from Mozilla to maintain an open source project as well. It should factor into the discussion.
https://blog.mozilla.org/blog/2016/06/22/mozilla-awards-3850...
The only generous people here is Mozilla, especially when they financed a commercial project with open source grants.
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.
It's a huge shame, because I used to recommend Caddy for how easy it was to get TLS to work.
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.
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".
Your "worldview" doesn't seem to extend past the end of your own nose.
what is your startup going to do to generate money if you perpetuate the belief that no one should pay for anything?
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.
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.
why not?
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.
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.
That is, keep Caddy as it was and get sponsorships/memberships for a "Caddy Plus".
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. :(
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.
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;
}
30 2 * * 1 /bin/certbot -a webroot --webroot-path=/var/www/example renew --renew-hook "systemctl restart nginx"
mkdir -p /var/www/example
certbot certonly --webroot -w /var/www/example/ -d www.example.com
include ssl_common.conf
https://www.guyrutenberg.com/2017/01/01/lets-encrypt-reload-...
http://nginx.org/en/docs/beginners_guide.html
Basically `reload` should have the external appearance of 0 downtime.
Thanks for keeping it open source. I'm very interested in how this business model will work, glad to see people trying different approaches.
OpenOffice -> LibreOffice
Gnome -> Mate
Caddy -> ?
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.
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.
I feel like maybe you don't know what apt does, or how it's used, if you think that shell script is "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.
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.
So, tell me again who their target market is?
And I guess it'll never enter Debian/main now, unless a maintainer forks it in order to build Free binaries :/
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?
Of course they'll do something user hostile and ass backwards!
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?
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.
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.
> 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.
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.
https://oasis.sandstorm.io/shared/McS6o5vxJ6U4TDjB8jntoVZUtm...
https://source.heropunch.io/relax/gridpkgs/tree/latest/repo/...
I think this warning should be more prominent. Lot's of CI builds would mysteriously fail after 30+ days.
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.
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.
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.
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.
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
sed -ie '/Header().Set("Caddy-Sponsors/d' ../caddyhttp/httpserver/server.goDoesn'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?
Think Red Hat Linux.
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'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.
Please clarify, thanks.
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 pricing is on our pricing page: 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.
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.
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.
But adware? that's a crap move.
> 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.
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.
Personally for me Caddy is (was) good because of how easy it is to set it up.
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!
It was a hypothetical.
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.
Can we at least get the base package sorted before? I really don't need custom with any plugins.
So now there will be ads even in the HTTP headers.
Coming soon, ads in the tcp headers ...
caddy-sponsors - This free web server is made possible by its sponsors: Minio, Uptime Robot, and Sourcegraph
The author has claimed that prices will rise after an "introductory period":
$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
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.
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.
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 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.
We'll be optimizing Caddy more over time. You can also use the http.cache plugin to help with performance: https://caddyserver.com/docs/http.cache
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..., nor in merged pull requests.
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...
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 name == "Caddy-Sponsors" || name == "-Caddy-Sponsors" {
// see EULA
continue
}
@mholt has made the entire process so unbelievably easy that the whole process takes literally minutes...
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.
https://blog.mozilla.org/blog/2016/06/22/mozilla-awards-3850...
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.
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 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 ?
Which servers?
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.
https://www.gnu.org/philosophy/open-source-misses-the-point....
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/).
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.)
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.
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.
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.
> 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.
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.
They got $50.000 from Mozilla, AKA free software foundations financing commercial software with grants, but what is your opinion on this Mr Burke?
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.
They didn't.
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
I am also sad about how the opensource version of Caddy project no longer has a website and being ignored. -ab
Open source developers NEVER owe users anything. Never.
Stop being so entitled.