Hacker News Reader

Comment by lol768 | Hacker News Reader

> As of version 0.10.9, Caddy emits an HTTP response header, Caddy-Sponsors, which is similar to the Server header that Caddy already has, except that this one credits our sponsors who make it possible to keep Caddy free for personal use. This header cannot be removed by the Caddyfile, and its presence is required by the non-commercial EULA. This requirement is waived by the commercial license, so the header is not present in those binaries.

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

Don't get me wrong, I think charging for commercial licenses (which come with proper support) is a good business model, but my personal site shouldn't suddenly become an advertising outlet. The fact that the headers aren't seen by most non-technical users is moot.

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

Edit: Here's my fork https://github.com/WedgeServer/wedge

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

View on HN

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.

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

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 :\

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

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

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.

> This is just like Red Hat. He's put a lot of work into his product, whether free or not, so don't use trademarked name.

Unfortunately when you fork a repository, it does copy the entire source tree. I can't type that fast, so there was a short period when the original README was still there.. there's also probably 400 other repositories on GitHub with the same problem. I knew this needed to be resolved, and it was within a timely manner.

I'll also note Caddy is not a registered trademark.

> Don't do that. If you're going to copy it, change the name.

When I created the repository I deliberately chose a different name and deliberately opened up the issue tracker and created an issue to track the work in renaming e.g. the README references. I created this issue before the "you're violating our (unregistered) trademark!" issue was created.

My intentions were good from the start, please don't talk to me as if that was not the case.

> there's also probably 400 other repositories on GitHub with the same problem.

As I said in a sibling thread, it's not just that it was forked, it's that it was forked and then intended/was advertised as competition. Forking and keeping the name Caddy for private use isn't a problem, so I doubt many of those other repositories are actually a problem.

> I created this issue before the "you're violating our (unregistered) trademark!" issue was created.

If this situation arises again, it may be better to wait until the name issue is resolved before advertising it to a forum of people. Regardless of what your future intentions were, you were competing at that point, and you hadn't dealt with the naming yet. I understand the desire to both capitalize on the issue and help those that feel the same as you about this, but doing so here stepped on the rights of another individual or group.

> My intentions were good from the start, please don't talk to me as if that was not the case.

I think the intentions of the people with claim to the Caddy trademark that contacted you were good as well. The difference is that you noted the claim here and also editorialized it with a sarcastic "classy!". Really, it's that last bit which spurred the tone in my response, since it implies bad behavior on their part for what is essentially protecting what they consider theirs (and something they are legally required to do if they want to keep it). Without that, you might have gotten a more measured reply, or none at all as others might have been sufficient. Your intentions might have been good from the start, but they could have been a little better when deciding the wording for that announcement.

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?

> 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 think the headers are there so they can see if commercial sites are using the personal version and get them to pony up.

Wouldn't they already know who their customers are?

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?

If you do build it yourself, you don't fall under the commercial license, so it's correct if those are not detected.

It's enough if nobody but the site maintainers will see them, that's what can annoy them into upgrading.

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

Ad headers isn't an extended feature, it's a nag screen.

Removal of ad headers surely counts as a feature then?

No, it counts as a bugfix.

There's a difference between "extended features for commercial versions" and "adware". Usually the open source version includes core features that solve a basic set of problems, and the commercial versions add additional features to solve other and/or larger problems. At no point is there an explicit crippling of the open source.

What's particularly frustrating is the burying of the lede here. The summary of the page intentionally omits the fact that you can build from source and use it in commercial contexts. And the section discussing the Apache license is factually incorrect: "Remember that building Caddy from source is still subject to the Apache 2.0 license which requires attribution and stating changes." -- that is only true if you are selling on-prem software that ships with the program. If you are using it in the normal course of your SaaS, no attribution is required.

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

> 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 does have commercial offering though netgate...

Netgate sells service, hardware and certification, not extra features.

Doesn’t gold membership include extra features?

Looking at it again, it seems their cloud configuration backup service has special client code and could qualify as such. But the primary thing seems to be access to information, the devs and an officially certified VM for AWS.

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

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.

> Why's that? (And even among your technical visitors, how many of them actually inspect the response headers?)

I dislike this for a few reasons. Firstly, it honestly comes across as petty. I'm using the server for personal reasons, it's for a non-commercial site which I don't make money off. I don't display ads, and suddenly I'm now being forced to serve ads to my visitors. The medium of delivery is utterly irrelevant to me.

Secondly, it makes it more difficult to take steps to make it less obvious which web server is being used. I'd do this to make it slightly more difficult for script kiddies looking to exploit recent vulnerabiltiies - not because I think security through obscurity is a good idea.

> It's good to know that price isn't the bottleneck, then. Does it make any difference to know that commercially-licensed Caddy builds don't have that header?

No. The point is, you've annoyed someone who liked your software, used it for personal use (costing you nothing) and would've happily recommended it to colleagues.

> No. The point is, you've annoyed someone who liked your software, used it for personal use (costing you nothing) and would've happily recommended it to colleagues.

This is worth keeping in mind. Personally, this change is putting me off Caddy to the point that I might stop using it for personal sites. The big feature for me - instant LetsEncrypt TLS certificates - can be done on other servers now fairly simply. So the end result might be that I no longer use Caddy, which means I'll no longer have it in mind for commercial projects I work on.

I have pretty much the same reaction. I was considering moving some stuff to Caddy, but looking at this, I'd need to create my own build pipeline to keep rubbish like this out. No thanks. I'll use tools that give me the options of turning things like this on/off without having to compile my own copy.

I was pleasantly surprised at how quickly I was able to rip out Caddy and replace it with nginx and Traefik (in different cases), even with the LE automation. It shouldn't be much of a burden to move your person projects I don't think.

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.

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

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

> I thought about this as well, but I'm not convinced that hiding the Server header or anything like unto it is really that beneficial. Most exploits are automated anyway.

It probably doesn't help much but it can't hurt. Some servers send back a "Server" header that tells you the OS being used with the Apache and PHP version up to the minor version number for example. There's no benefit to leaking this information and it's potentially useful to an attacker even if only marginally so why risk it?

> It probably doesn't help much but it can't hurt ... There's no benefit to leaking this information and it's potentially useful to an attacker even if only marginally so why risk it?

Actually, it can hurt. One really good reason to note it is that for the same reason an attacker might want to know the version, a defender (such as an employee) might want to as well. I've noted exploitable versions of software found to other divisions of the company I was working at before. For the attacker, it's really not much of an issue anyway, they'll just throw every exploit at it anyway (my webserver logs were always filled with random exploit attempts such as for wordpress and IIS).

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?

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.

Thanks for your feedback. You could build from source, that's free.

If you need a commercial license, contact us at sales@lightcodelabs.com 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.

you don't have time to recompile a software package but you do have time to read hackernews?

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.

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.

Yes I think the GOPATH is bullshit but it's also not hard to move files from one directory to another.

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

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)

I think the biggest issue is that you've shown you're willing to modify traffic for license control. If you'd simply released commercial support for $500/mo/instance I'd have gladly paid for it in my products and think many others would have too. Showing such obtrusive forms of DRM makes me not want to ever use any of your software again. I've spent the past couple of hours migrating from Caddy to nginx and I've contacted them about buying support. I guess the silver lining was the nginx was was easy to migrate to.

I've dealt with similar-ish situations before and would suggest that you consider (I am not recommending, merely suggesting) adding a config option -

    thanks_sponsors false

then people who really hate that header can disable it but it's clear what they're doing with the software they're paying no money for. If people complain about that well, that's their issue IMO. And they have to be explicit about how they're behaving.

This has worked well for me in the past. If you'd be interested chatting about how/why reply and I'll drop you an email.

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.

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.

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

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.

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

The EULA only applies to precompiled binaries

The EULA does not apply to the source code. The source code is Apache licensed.

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.

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.

I get that a project want to sell licenses - but as a sibling comment states, Caddy appears to no longer be Free software, breaking freedom 1 (modify), 3 (distribute modified copies).

[ed: it appears I misunderstood, only the binaries are under eula - so Caddy is in the (somewhat) unique position of distributing non-free binaries and Free source code. Kind of like a gpled iOS program I guess.]

In addition, I'd consider this a (small) security vulnerability: the presence of the ad header effectively screams Caddy to fingerprinting tools. There's a reason apache and friends have a "prod" header config/setting.

[ed: seems a bit cruel to force the most resourceresource-limited users to advertise details about their stack; presumably those that know enough to compile themselves might also have more resources to keep up to date on security issues etc]

Synergy, the app that allows a computer to share its mouse and keyboard over the network to other computers, did a more aggressive move a few years ago. It's still technically GPL because you can compile it yourself, but they charge $20 for a binary license and to enable certain features.

I have similar concerns. I practice good security but I also enjoy security through obscurity. I prefer to prevent my users from knowing what web server is serving their content. Now unless I start compiling from scratch, everyone will know I use Caddy and I don't like that.

Alternative is to run Caddy behind HAProxy or Nginx or something similar that can strip those headers out.

I think it's time to just rebuild and use Nginx again and try to get QUIC and automatic LetsEncrypt working.

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

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

i found the github faq that i remembered:

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:

        (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}}

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.

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.

How can this be compatible with the Apache License?

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

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

Reply on news.ycombinator.com