Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Caddy Commercial Licenses

caddyserver.com

Post reply on HN
Print view View original

131–140 of 295 posts

Re: Announcing Caddy Commercial Licenses

#131

Post by jefurii »

eropple wrote: post #89
JamesMcMinn wrote: post #83

Earlier quoted context omitted.

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…

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…

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

Re: Announcing Caddy Commercial Licenses

#132

Post by TheDong »

mholt wrote: post #33
stavros wrote: post #19

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 d…

> 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…

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?

Re: Announcing Caddy Commercial Licenses

#133

Post by TAForObvReasons »

yorwba wrote: post #127
TAForObvReasons wrote: post #123

Earlier quoted context omitted.

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://w…

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.

Re: Announcing Caddy Commercial Licenses

#134

Post by iampims »

mholt wrote: post #44
ash wrote: post #34

> We now require declaring a license when requesting a download: > / ?license=personal" rel="nofollow">https://caddyserver.com/download/ / ?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 syn…

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.

Why not upload them to GitHub?

Re: Announcing Caddy Commercial Licenses

#135

Post by Whitestrake »

andmarios wrote: post #112

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 tea…

To compile without the `Caddy-Sponsors` header, include this line before the plugin comment:

    sed -ie '/Header().Set("Caddy-Sponsors/d' ../caddyhttp/httpserver/server.go

Re: Announcing Caddy Commercial Licenses

#136

Post by tiernano »

Whitestrake wrote: post #25
tiernano wrote: post #16

Earlier quoted context omitted.

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.

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

Re: Announcing Caddy Commercial Licenses

#139

Post by yorwba »

TAForObvReasons wrote: post #133
yorwba wrote: post #127

Earlier quoted context omitted.

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://w…

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 inf…

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?

Re: Announcing Caddy Commercial Licenses

#140

Post by stephenr »

TheDong wrote: post #132
mholt wrote: post #33

Earlier quoted context omitted.

> 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…

Given the .. unusual... plugin module (compile one caddy build per plugin-set x arch combo), I don't see ohw that could possibly translate into proper apt/whatever packages. If, during the install, it's compiling caddy, that's probably not what people want. How will it actually work, given plugins are determined at build-time and there's a phenomenally large matrix of plugin X arch combos?

You forget that these are the same developers who thought it makes sense to refuse to start with a cached,valid tls certificate because LE's ACME API was unavailable.

Of course they'll do something user hostile and ass backwards!

Post reply on HN