Hacker News Reader

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

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

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

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.

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.

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

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?

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

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.

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

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.

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.