Hacker News Reader

Comment by egeozcan | Hacker News Reader

So now the free official binary distribution doesn't allow commercial use but you can build it yourself from the source (which is licensed under Apache 2.0) and use it commercially for free:

"""

Q: Which license do I need?

A: If your company uses official Caddy binaries internally, in production, or distributes Caddy, a commercial license is required. This includes companies that use Caddy for research. The personal license is appropriate for academic research, personal projects, websites that aren't for profit, and development at home.

Q: Is Caddy open source?

A: Yes, it is. Caddy's source code is licensed under Apache 2.0, which requires attribution and stating changes made to the code when forking it, using it in your own projects, or distributing it. This website distributes official, compiled Caddy binaries, which are licensed differently.

"""

View on HN

https://caddyserver.com/download not once mentions the fact that the server is open source or could be compiled from source for free. The entire page is structured to give the impression that commercial uses require a paid license. Other servers like nginx have separate websites for the open source and paid versions (http://nginx.org/ open source, https://www.nginx.com/ plus)

There's a link to GitHub right at the top...

Github != open source. There are plenty of proprietary software products like HighCharts that distribute with GitHub and have a clear commercial license (https://github.com/highcharts/highcharts/) -- merely saying GitHub is not enough to communicate the license terms.

We communicate the license terms by using the license (and the website, and the FAQ, and the Terms of Service, etc), not the link to GitHub. :)

I just realized the GitHub link goes away on mobile (for lack of horizontal space) but, there are many other places on the website where it mentions that the project is open source.

AIUI, Debian can put Caddy in the main section because it is Apache 2.0. Patches to upstream can happen.

The big question: will any Debian maintainer want to invest time in this, when at any moment LightCode Labs can say "next version will not have an open license"?

Probably it's enough. That's the situation that nginx is in, anyway.

Assuming that one day there will reproducible builds, how will they ever tell apart the legal use from the illegal use of the (bit-for-bit identical) binary?

By ensuring the proprietary builds are NOT the same.

Ouch! Then we have the choice between a community-provided binary that is cross-validated by multiple build servers of multiple distros, and a vendor-provided binary which is deliberately different and has legal restrictions. Which one would we consider to be more trustworthy?

Code signing maybe? Not entirely sure otherwise.

How would that work? The signature of the official binary would be also valid for the "other" binaries.

Code signing involves attaching a certificate from the author which nobody else can reproduce unless a CA is compromised. Think SSL certs to some degree. This only proves identity of person signing it. This would differentiate the binary enough I would think.

If the rest of the binary is bit-for-bit identical, you can just tack the signature on to the OSS binary.

This is the case. Sort of how RedHat does things, though they charge for support instead afaik.

Reply on news.ycombinator.com