Announcing Caddy Commercial Licenses(caddyserver.com)
caddyserver.com
Announcing Caddy Commercial Licenses
https://caddyserver.com/blog/accouncing-caddy-commercial-licenses.html
294 comments
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.
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.
Actually, the defaults are quite insane.
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.
https://github.com/mholt/caddy/issues/1632
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.
https://github.com/mholt/caddy/issues/1632
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.
I'm not excited about it as much anymore :\
I'm not excited about it as much anymore :\
It is worth revisiting the trademark-thread, the responses of everyone involved are level-headed and civil.
> Second edit: Accusation of trademark violation within an hour of the fork, classy! https://github.com/WedgeServer/wedge/issues/2
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...
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...
> 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.
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.
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.
from the github (which hosts caddy source) faq:
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."
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.
Thanks for your feedback. I'd like to know more.
> The fact that the headers aren't seen by most non-technical users is moot.
Why's that? (And even among your technical visitors, how many of them actually inspect the response headers?)
> I find this practice pretty obnoxious to the point of looking at NGINX Plus for commercial use instead.
It's good to know that price isn't the bottleneck, then. Does it make any difference to know that commercially-licensed Caddy builds don't have that header?
> 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.
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.
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.
Seconded.
This is also how I felt reading the news.
> 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. 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. 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).
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).
>> 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.
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.
> 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.
> 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.
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.
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.
> 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?
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 know devs who use Sublime Text almost indefinitely without paying. They don't mind the little "Hey don't forget to buy" popup every once in a while.
We aren't putting popups on your site. :P
We aren't putting popups on your site. :P
No, you're injecting data into traffic. That's way worse than a text editor occasionally reminding you you haven't paid.
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.
[deleted]
[deleted]
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.
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.
> Can you name an open source project that does not offer extended features for commercial versions and that sells?
pfSense, Ceph (prior to RH purchase) and OpenNebula off the top of my head.
pfSense, Ceph (prior to RH purchase) and OpenNebula off the top of my head.
Pfsense does have commercial offering though netgate...
Netgate sells service, hardware and certification, not extra features.
I think the headers are there so they can see if commercial sites are using the personal version and get them to pony up.
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'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?
If you do build it yourself, you don't fall under the commercial license, so it's correct if those are not detected.
Wouldn't they already know who their customers are?
It's enough if nobody but the site maintainers will see them, that's what can annoy them into upgrading.
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 -
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.
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.
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)
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.
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.
> incurring the wasted bandwidth of this header to my users
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 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...
Thanks for your feedback. You could build from source, that's free.
If you need a commercial license, contact us at [email protected] and we'll see about working something out for you!
If you need a commercial license, contact us at [email protected] and we'll see about working something out for you!
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.
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.
you don't have time to recompile a software package but you do have time to read hackernews?
is time the right word here?
is time the right word here?
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.)
I read HN on my own time.
I read HN on my own time.
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.
> but in general Go programs are very easy to build.
So long as you organise all your code according to GOPATH. You can't just compile it in your Downloads folder.
So long as you organise all your code according to GOPATH. You can't just compile it in your Downloads folder.
Yes I think the GOPATH is bullshit but it's also not hard to move files from one directory to another.
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?
With that statement, Caddy is officially nonfree software. It breaks freedom 1.
Edit: I have been corrected. For the record, I still think this is a braindead move from Caddy.
Edit: I have been corrected. For the record, I still think this is a braindead move from Caddy.
Hm, I don't think so (but I'm no expert)
> The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
Even with or without the above statement, this freedom is not broken by Caddy. You are still allowed to download the source and remove the headers, just as before.
> The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
Even with or without the above statement, this freedom is not broken by Caddy. You are still allowed to download the source and remove the headers, just as before.
>its presence is required by the non-commercial EULA
This statement reads to me that you _cannot_ remove it.
It also combines with freedom 3, if you can't distribute your modified version.
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 binary build from the Caddy website and the GitHub repository are effectively two separate products, as they are covered by different licenses.
The code in the GitHub repository is open-source; but the binary builds from the Caddy website are not.
The code in the GitHub repository is open-source; but the binary builds from the Caddy website are not.
..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.
This is clearly a license enforcement measure.
They're going to search for commercial sites sending this header and then hit them up for money.
This is DRM.
They're going to search for commercial sites sending this header and then hit them up for money.
This is DRM.
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]
[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.
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.
> Alternative is to run Caddy behind HAProxy or Nginx or something similar that can strip those headers out.
The EULA specifically states that this isn't permitted.
The EULA specifically states that this isn't permitted.
i believe that when hosting source on github, you guarantee the right of others to fork the repository
that right would seem to preclude forcing the forked version to change the name
that right would seem to preclude forcing the forked version to change the name
i found the github faq that i remembered:
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."
https://help.github.com/articles/licensing-a-repository/
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."
https://help.github.com/articles/licensing-a-repository/
dists/EULA:
3. Restrictions
3.1 You SHALL NOT, and shall not allow any third party, to:
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}}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.
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.
How can 3.1a even be included? It's against the terms to discover the source code, that they themselves link to on the page you download from?
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. :)
And it’s also completely null and void under EU law anyway, so you might as well remove it.
EDIT: I’ll refer to this historical case: https://en.wikipedia.org/wiki/SAS_Institute_Inc_v_World_Prog...
EDIT: I’ll refer to this historical case: https://en.wikipedia.org/wiki/SAS_Institute_Inc_v_World_Prog...
Remember this only applies to official binaries. The EULA itself states it doesn't apply to the source code.
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?
Yes, yes, it's everywhere: the pricing page, the blog post, and the EULA itself says right near the top:
> The open source code of this Software is licensed under the terms of the Apache License Version 2.0 and not under this EULA.
> The open source code of this Software is licensed under the terms of the Apache License Version 2.0 and not under this EULA.
How can this be compatible with the Apache License?
Try the H2O server: https://h2o.examp1e.net
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.)
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.)
I said further below that this makes Caddy nonfree, but I was corrected - you can still build Caddy from source, remove the bullshit, and distribute your changes and compiled binaries under Apache 2.0.
However, after examining the website more I feel the need to write another comment expressing how poorly this is being handled. The website is very misleading - on the download page, it now asks you to pick a license, and says that the "Personal" version is for only personal use and you need to pay for the commercial version. There's no indication until you click through to the full pricing page that the open source version even exists. On that page, you have the same personal/commercial breakdown, also stating that the personal version is strictly for non-commercial use, but with a sidebar mentioning open source. It assumes you understand the Apache 2.0 license and makes no attempt to clarify that businesses can use the open source version.
The authors are also wasting no time in going after forks[1] to complain about trademark infringement, so if you want to distribute your own patched Caddy builds you can expect to hear from their lawyers. Absolutely devoid of class.
This is a really obnoxious change. I was thinking about switching from Nginx to Caddy but this news is nailing that door shut.
[1] https://github.com/WedgeServer/wedge/issues/2
However, after examining the website more I feel the need to write another comment expressing how poorly this is being handled. The website is very misleading - on the download page, it now asks you to pick a license, and says that the "Personal" version is for only personal use and you need to pay for the commercial version. There's no indication until you click through to the full pricing page that the open source version even exists. On that page, you have the same personal/commercial breakdown, also stating that the personal version is strictly for non-commercial use, but with a sidebar mentioning open source. It assumes you understand the Apache 2.0 license and makes no attempt to clarify that businesses can use the open source version.
The authors are also wasting no time in going after forks[1] to complain about trademark infringement, so if you want to distribute your own patched Caddy builds you can expect to hear from their lawyers. Absolutely devoid of class.
This is a really obnoxious change. I was thinking about switching from Nginx to Caddy but this news is nailing that door shut.
[1] https://github.com/WedgeServer/wedge/issues/2
> 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.
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.
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.
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
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
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.
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.
I wanted to throw in a comment to register a little more than just a +1 to your post.
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.
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.
> 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.
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?
>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?
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?
I think they should have waited more than a few minutes to start hassling the fork about 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.
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.
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.
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.
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.
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.
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.
> Open source has to be subsidized
Yep and Caddy was, $50.000 in 2016 from Mozilla
https://blog.mozilla.org/blog/2016/06/22/mozilla-awards-3850...
Yep and Caddy was, $50.000 in 2016 from Mozilla
https://blog.mozilla.org/blog/2016/06/22/mozilla-awards-3850...
You say that like you think they're set for life...
All I say is Mozilla granting $50.000 on the premise of a project being free software is a lot of money given to a commercial product.
They are still open source right? Or does having a commercial version invalidate what they have open sourced?
Yes, he gave you free stuff and then reduced how much free stuff he gave you. That must be very hard on you.
Your comment might have had value if you hadn't been sarcastic.
> @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.
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.
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.
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.
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.
I disagree.
Big companies are where they're going to buy the licenses because in those companies time is often more kmportnant than budget so you just buy stuff.
Another reason is that as soon as other teams become involved you get comments like "this bug is yours because you self compiled this thing", or "we have to buy the vendors version", etc etc. It's not logical and is basically arse covering. Buying the vendor version is an easy way to shoot down a whole category of stupid internal politics.
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.
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.
> never heard anything like that in my life.
Just yesterday I was whipping a team because they built their own version of Apache (for dubious reasons) and broke the patch management system.
To quote myself "why the fuck didn't you use the distribution packaged version?? Now go and fix that right now, it is your problem"
I think it pretty much covers the case.
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.
Yes, and you don't have to pay to use a packaged distribution of Apache free of adware.
> I think it pretty much covers the case.
I think it pretty much doesnt.
> I think it pretty much covers the case.
I think it pretty much doesnt.
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.
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.
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.
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.
[deleted]
> 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.
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
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
The company that goes and builds this themselves instead of paying a small fee for it, would be a pretty stupid company haha...
> The company that goes and builds this themselves instead of paying a small fee for it, would be a pretty stupid company haha...
There is a fork without the adware now, so the smart company will use the fork to get rid of the stupid ads.
https://github.com/WedgeServer/wedge
There is a fork without the adware now, so the smart company will use the fork to get rid of the stupid ads.
https://github.com/WedgeServer/wedge
[deleted]
For the curious or non-British: http://www.thefreedictionary.com/whingers
[deleted]
I agree strongly with this.
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.
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.
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.
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.
It's a huge shame, because I used to recommend Caddy for how easy it was to get TLS to work.
Caddy is still open source, Apache licensed. You can certainly build from source as long as you give attribution and state your changes.
Matt, I really do appreciate the work you and others have put into Caddy - it's a fantastic piece of software which has served me well for the past year and a bit.
Having said that, this change has put me in a position where I have to invest either time or money into a solution for a problem which I didn't have yesterday, and switching to NGINX seems like the path least likely to cause issues in the future.
Having to 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.
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 are 'not willing to pay' money or time?
why not?
why not?
Because it feels like a bad investment.
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.
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.
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".
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.
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.
Your "worldview" doesn't seem to extend past the end of your own nose.
you are a student and you are using something for FREE and you are also at the same time worried about extra stuff in the headers?
what is your startup going to do to generate money if you perpetuate the belief that no one should pay for anything?
what is your startup going to do to generate money if you perpetuate the belief that no one should pay for anything?
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.
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.
I think the Caddy developers messed up and did not follow the example of nginx.
That is, keep Caddy as it was and get sponsorships/memberships for a "Caddy Plus".
That is, keep Caddy as it was and get sponsorships/memberships for a "Caddy Plus".
They did do exactly that for couple of months. I guess it didn't work out so well.
Do you have a link that shows that attempt?
[deleted]
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. 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.
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.
To everyone saying that Caddy made it simple for automated LE; I agree, but also, it's not that difficult to setup with NGINX:
Edit /var/nginx/ssl_common.conf
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
Small improvement, but `reload` should do this while gracefully terminating connections:
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.
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.
Thanks for posting this. This is pretty much the setup I just replaced Caddy with and it's working well so far.
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.
Thanks for keeping it open source. I'm very interested in how this business model will work, glad to see people trying different approaches.
Since you could pull yesterday's version:
OpenOffice -> LibreOffice
Gnome -> Mate
Caddy -> ?
OpenOffice -> LibreOffice
Gnome -> Mate
Caddy -> ?
You can pull today's or future versions as it's still open source under the same license. Please read the above quote.
shady
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), 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.
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 "apt install" but it's pretty close
It's not close, though, it's very far. With apt, I know things are going to go in their proper place, and are going to get cleaned up afterwards (not to mention the biggest benefit, automatic updates).
With a shell script, I don't know what sort of stuff it puts where on my filesystem, and I can't automate the installation easily. My preferred order of installation procedures is: "apt", "manual", and "random shell script" is a distant last, to the point where I sometimes won't try software if the installation procedure isn't sane.
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.
My thoughts exactly. And I am afraid we are moving even further away from packages with this move..
Yeah... What I don't understand is why nginx doesn't have built-in LetsEncrypt cert fetching yet.
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.
So, tell me again who their target market is?
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?
After this I would bet they have it before very long.
You assume that they care about Caddy and that the 9 lines of how to get LE for nginx is something they think it's hard to do for anyone that can't follow these instructions: https://gist.github.com/cecilemuller/a26737699a7e70a7093d4dc... or use: https://github.com/certbot/certbot
> True, it's not "apt install" but it's pretty close
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."
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."
> True, it's not "apt install"
And I guess it'll never enter Debian/main now, unless a maintainer forks it in order to build Free binaries :/
And I guess it'll never enter Debian/main now, unless a maintainer forks it in order to build Free binaries :/
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?
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!
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'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.
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.
Yeah, I have a bunch of side projects that collectively make ~$2/mo. Good thing I didn't replace nginx with Caddy on that server.
No schemes here, just an updated business plan.
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, [email protected], 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.
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, [email protected], 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.
Thanks for your feedback. Really appreciate it.
> 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: [email protected] 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.
> 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: [email protected] 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.
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.
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.
Where can we find the current most popular Caddy image?
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.
https://oasis.sandstorm.io/shared/McS6o5vxJ6U4TDjB8jntoVZUtm...
https://source.heropunch.io/relax/gridpkgs/tree/latest/repo/...
https://oasis.sandstorm.io/shared/McS6o5vxJ6U4TDjB8jntoVZUtm...
https://source.heropunch.io/relax/gridpkgs/tree/latest/repo/...
> 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 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.
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.
Is this move the result of open source burnout?
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.
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.
Why not upload them to GitHub?
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.
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.
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:
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
To compile without the `Caddy-Sponsors` header, include this line before the plugin comment:
sed -ie '/Header().Set("Caddy-Sponsors/d' ../caddyhttp/httpserver/server.goThanks, 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?
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.
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 :(
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.
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, [email protected] and we'll see what we can do.
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, [email protected] and we'll see what we can do.
> if you build from source, you're good to go.
That's a pretty big if. The one time I had to compile the server from source (to help you test a bugfix), I had the Go toolchain installed (which not everyone does) and I still couldn't figure out how to compile with some of the plugins I wanted. I gave up after 30 minutes of not getting anywhere, IIRC.
I think this move has lost you a lot of goodwill from people.
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?
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?
> so if you build from source, you're good to go
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.
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.
> 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.
Please clarify, thanks.
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.
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.
That's often the case. The answer is priority support and developer time for bugfixes/feature requests, and potentially commercial-only features.
Think Red Hat Linux.
Think Red Hat Linux.
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.
> If you use Caddy for personal, academic, or non-profit purposes, not much is different. Caddy-Sponsors HTTP Header
> If you use or distribute official Caddy binaries at work, or as part of a product/service, you will need a commercial license
If I have some personal project which I want to incorporate I need to worry about the license.
Oh, time to switch back to NGINX. Thanks for automated HTTPS while it lasted.
> 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.
This is incorrect, or at least only half-true.
Caddy is still Apache 2.0 licensed. You can use it for free for commercial purposes. You just can't use the build server at caddyserver.com to download a precompiled Caddy with plugins. Instead, you can download the source, compile it with plugins yourself, then distribute your own binary amongst all your hosts.
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.
Yeah, I guess you're right. But then again setting up NGINX with auto SSL would be easier so what's the point.
Personally for me Caddy is (was) good because of how easy it is to set it up.
Personally for me Caddy is (was) good because of how easy it is to set it up.
I'm not sure I agree with you there.
The most popular Docker image for Caddy, for example, should soon (if it's not already) be compiled from source, rather than from the build server. That means it will remain free to use, and I personally don't have to make a single change.
If this has impacted you negatively to the point where setting up nginx is an easier option, well - that's the beauty of choice!
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!
But the software in that image will still be written by untrustworthy adware developers. _That_ is the issue.
Or use an unofficial build, like those found in Linux distro repositories.
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.
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.
One of the things we're hoping to offer soon are official distro packages that can be customized with the plugins you want/need.
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.
Can we at least get the base package sorted before? I really don't need custom with any plugins.
It does not matter if the binary restrictions and EULA are attached to those.
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.
Coming soon, ads in the tcp headers ...
So now there will be ads even in the HTTP headers.
Coming soon, ads in the tcp headers ...
caddyserver.com emits those headers if you want to see them in action: https://urlscan.io/result/8093833b-8ac7-4d18-8f20-a02373f577... Go to the first transaction, click the show button and click "Show headers". Right now it says:
caddy-sponsors - This free web server is made possible by its sponsors: Minio, Uptime Robot, and Sourcegraph
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.
Just when you thought you knew what's going on.
The author has claimed that prices will rise after an "introductory period":
https://mobile.twitter.com/mholt6/status/908007933115375616
The author has claimed that prices will rise after an "introductory period":
https://mobile.twitter.com/mholt6/status/908007933115375616
Copied comment from the other HN thread:
$50 dollars a MONTH PER INSTANCE for a piece of software that wouldn't even start a few months ago because LetsEncrypt was down.
I get that software takes time and people need to eat, but holy shit on a stick.
Edit: Oh, and I forgot the part where it also doesn't handle FQDN's properly either.
Previous discussion, from when LE was down for a day https://news.ycombinator.com/item?id=14375022
$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
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.
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.
I understand that the source is available.
My surprise is that you think anyone will pay $50 per month per instance forever, for a build service they might use only once, and that still requires them to actually do all the work to install it and run it as a service.
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.
If Caddy had focused on providing commercial support to companeis that need it, this would have been a good day.
As it is, they are adding artificial roadblocks for open source users while providing minimal benefits to commercial users.
Someone didn't think this through or is out of touch with how to make money with open source.
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.
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.
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.
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.
Running Caddy is literally copying a binary and your site over and setting up the systemd config. LetsEncrypt works automagically out of the box.
> LetsEncrypt works automagically out of the box
Provided you let Caddy manage all the certs and/or permit dynamic dns updates on that host. Went through this last night and it's underdocumented when you want to handle it yourself with TXT records and explicit cert/key.
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.
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
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
My first thought upon finding out that Caddy's source was still under an open source license was "can that change, too?"
As far as I can tell, the answer is "not unilaterally," as I don't see any requirements for copyright assignment in the contributing guidelines https://github.com/mholt/caddy/blob/master/.github/CONTRIBUT..., nor in merged pull requests.
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.
Didn't Caddy got like $50.000 from Mozilla to work on the open source version?
Is Mozilla OK with this? Maybe Mozilla should give money on free software projects that plan on remaining free instead next time...
https://blog.mozilla.org/blog/2016/06/22/mozilla-awards-3850...
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...
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:
@mholt has made the entire process so unbelievably easy that the whole process takes literally minutes...
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...
i personally like how one of the first contact bits from caddy to a fork of it is a thinly veiled legal threat: https://github.com/WedgeServer/wedge/issues/2
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.
I misconfigured the machine; just raised the file descriptor limit and we should be good now.
1. I applaud this effort.
2. Ive been researching sustainable funding models for open source. Will the maintainers be blogging about the progress and results? Would be useful to learn about what they discover.
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.
https://blog.mozilla.org/blog/2016/06/22/mozilla-awards-3850...
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...
i've been trying to come up with a license that captures enough of the freedoms of open source to protect the user while allowing for a non-zero cost. my license is below - it's not open source, but if you're willing to consider licenses that are liberal but not OS, i'd love to hear your comments
http://db4j.org/pupl/PUPL
http://db4j.org/pupl/PUPL
Thanks for posting. Ill check it out. :)
Site is currently down.
We've talked at length about the time saving things Caddy may do for you, but crashing under the weight of a static page is not a good advertisement.
Edit: it's back, but damage done, I think.
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 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. :)
Ugh, I forgot to raise the file descriptor limit when I re-provisioned the site. Leave it to me to blunder that. :)
as a developer that's also struggling with finding a balance between the good things that open source helps guarantee and a viable business plan, i'm intrigued by this discussion
the approach that caddy has taken appears to be a bit of good cop / bad cop. they're maintaining, at least for now, the apache license but they're also using trademark threats to prevent forks (i believe in violation of the github TOS)
the approach that i'm hoping to take is quite different. i'm interested in any feedback (my software is a database engine that in some ways is more convenient than existing dbms for java developers, but similar to caddy in that many good alternatives exist and are free)
https://github.com/db4j/pupl 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 ?
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 ?
[deleted]
> 1/4 price of comparable servers
Which servers?
Which servers?
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.
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.
Yea, but in the case of nginx, their binaries are Free full stop... it’s only extras or support that need license...
The most apparent comparison looks to be NGINX Plus, for which the lowest cost tier works out at over $200/month ($2,500/year) per instance.
https://www.nginx.com/products/buy-nginx-plus/
https://www.nginx.com/products/buy-nginx-plus/
[deleted]
Obligatory link to Richard Stallman on "free vs open":
https://www.gnu.org/philosophy/open-source-misses-the-point....
https://www.gnu.org/philosophy/open-source-misses-the-point....
This was a fascinating thread of a product I would possibly have used but now won't...
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/).
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.)
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.
> 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.
"the unhealthy expectation in the FOSS community"
Nobody is "expecting" you to make good software, we're just saying that now that you've turned a formally mostly decent piece of software into adware with an untrustworthy author there's no reason to not just use better software. Software that doesn't molest your traffic. I wish you luck with your business but don't know why anybody would pay for software written by you two ever again.
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?
We're talking about adware modifying traffic to pester you into licensing. The nginx model of selling additional features is in fact much better.
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.
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.
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.
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.
I'm excited that Caddy has taken steps to ensure its long term survival. Sad people can't be bothered to pay for software they like.
> Sad people can't be bothered to pay for software they like
They got $50.000 from Mozilla, AKA free software foundations financing commercial software with grants, but what is your opinion on this Mr Burke?
They got $50.000 from Mozilla, AKA free software foundations financing commercial software with grants, but what is your opinion on this Mr Burke?
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.
They didn't.
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.
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
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
I am also sad about how the opensource version of Caddy project no longer has a website and being ignored. -ab
[deleted]
Matt's response https://caddy.community/t/the-realities-of-being-a-foss-main...
Yep - where he goes into insulting more-or-less everyone who has criticized him and the project
[deleted]
Everything is getting expensive.
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