Proposal: Permanently change all proprietary licensing to open source

[mholt]

We (Light Code Labs in partnership with Ardan Labs) have decided that we would like to make all Caddy code open source and permanently remove all proprietary licensing within the project, effective as soon as this proposal is accepted.

We would like the community's feedback on these plans, which are as follows:

• Reaffirm that Caddy is an Apache 2.0-licensed open source project (this is unchanged)
• All Caddy binaries remain open source, Apache 2.0-licensed
• All official, enterprise-only v2 plugins that were to be reserved for business customers be
  released under the same open source license and moved into open repositories
• Drop plans for "Caddy Enterprise" branding
• Invite the community to collaborate in the development of all of Caddy, including former-Enterprise-only features
• Drop all build server subscriptions, startup packages, and private plugin hosting

With regards to the website, our plans are:

• Remove all use case restrictions from the build server (download page and getcaddy.com)
• Eliminate all mentions of products, business licensing, and subscriptions from the website
• Move the current website to caddyserver.com/v1 with redirects for most URLs
• Put up a v2 website at caddyserver.com that reflects the values, features, and benefits of the new Caddy project
• Add a Support/Contact link for companies who require support
• Add Ardan Labs' logo to broadcast our close relationship with Ardan Labs, and to make it clear that this open source project is backed by a trusted company

With Ardan Labs as our official partner for the Caddy project, we are ready to support the enterprise use cases. Ardan Labs is world-renowned for their Go training and support in the enterprise setting. We are confident that businesses will love using Caddy 2 once they try it, and we look forward to supporting their production use cases.

Our plans for businesses are:

• Light Code Labs will continue supporting our current v1 customers until their subscriptions expire
• Leverage Ardan Labs expertise to serve our clients with what they require -- whether it be 24/7 on-call support, custom feature development, training, and/or installation help or consultation
• Light Code Labs may seek sponsorships to help back the ongoing, full-time open source development of the project
• Light Code Labs will reach out to our current customers to let them know about these changes and help them understand these improved support options

With regards to Caddy v2, our plans are:

• Release a new beta version approximately every Monday
• Release RC1 by the end of the year
• Release stable 2.0 in Q1 2020

We want the world to know that Caddy:

1. is open source for good
2. is not a toy project
3. has corporate backing
4. can be used without hassle or worry in both small business and enterprise environments
5. can support enterprise use

We hope these changes will make this vision for the new Caddy project a reality.

What do you think?

Please submit your votes and feedback in this issue, and share it as widely as you can because this is the culmination of many years' efforts from ourselves and many of you! Thank you to everyone involved!

[jungle-boogie]

Hi,

Congratulations on your partnership with Ardan Labs. This seems like a great fit for you, your company, Caddy, and the greater Caddy community. Really awesome to see the eagerness of wanting to completely open source Caddy and the timetable of releases of caddy v2.

In an effort to tell the world about all of this, I'd recommend another FLOSS Weekly interview. You were last on November 2015! https://twit.tv/shows/floss-weekly/episodes/364 So long ago.

Since I am not an enterprise user of Caddy, I have no objections to your proposal and I'm anxious to see what's next for you.

[PSUdaemon]

This is great and I commend you on the effort. My only question would be why not take it the extra step and put Caddy into the Apache Incubator? That way it would exist in a trusted non-profit that has a proven track record at fostering open source communities.

They also have some experience with HTTP servers I've heard...

[ConsoleTVs]

This was my major concern before digging into caddy. This is a yes from me.

[brennanfee]

This is great. I have had a number of clients wave off and not use Caddy simply because it wasn't fully open source. This is an excellent turn of events.

[steveoc64]

Thank you !

Thats a yes from me

[hairyhenderson]

Wow! This is excellent news! This will certainly help increase adoption. 👍

[kivutar]

It will help increase adoption.

[jleclanche]

This is fantastic news @mholt. Congratulations, looking forward to all this.

[mholt]

Thank you everyone, for your feedback so far -- we are reading all of it.

@jungle-boogie - good to hear from you again!

In an effort to tell the world about all of this, I'd recommend another FLOSS Weekly interview. You were last on November 2015! https://twit.tv/shows/floss-weekly/episodes/364 So long ago.

Yes, we'd love to go on. I would love it if @ardan-bkennedy would go on with me.

@PSUdaemon

My only question would be why not take it the extra step and put Caddy into the Apache Incubator?

We can look into it.

---

It seems like this proposal will overwhelmingly pass. Our immediate focus will be getting the website updated along with accelerating v2 development.

By the way, if you're just joining us, have a look at what v2 has to offer here: https://github.com/caddyserver/caddy/tree/v2 with docs here ("Version 2" pages): https://github.com/caddyserver/caddy/wiki#version-2 -- We fully expect that v2 will be competitive replacement for other web servers/proxies as it reaches maturity, with all the added benefits Caddy has to offer.

So please, try out v2 as soon as you are able, and get involved with your feedback, issues, pull requests -- the sooner we can spread out more of this to the community, the faster it will come together and the better it will be. Plus, it'll be fun.

[sandstrom]

@mholt Great news! I've followed Caddy for several years, but have hesitated to switch because of lock-in fears. This will certainly drive adoption!

Out of curiosity, what prompted this change in focus? 😄

[elimisteve]

@mholt Congratulations! Interesting new approach to funding open source: get acquired and let them figure it out! 😄

[tomhatzer]

Great news! Thank you very much for all your efforts you are putting into the project! 👍🏻

[ibakirov]

Great initiative!

[didil]

Fantastic news. If this proposal passes I will give Caddy a try in production and will look for opportunities to contribute to the project.

[BenOvermyer]

This is a pleasant and very welcome surprise!

This change will remove the only barrier remaining for me to recommend Caddy to all my clients.

[zoobab]

Go for Copyleft, not a permissive license.

[paride]

This is good news and a choice that will definitely drive adoption! The new licensing model will allow the full Caddy server to be packaged in GNU/Linux distributions. Not having a native package in Debian/Ubuntu has been a blocker in some potential use cases I encountered.

[raatti]

This is good news! I also think getting caddy to EPEL or such package would speed up adoption, getting caddy to be easy as apt/yum install package will help a lot. Also caddy needs its own SELinux rules for Enterprise operating systems.

[Conan-Kudo]

This is fantastic! I'm looking forward to the future with caddy!

[Henrocker]

This is good news and a choice that will definitely drive adoption! The new licensing model will allow the full Caddy server to be packaged in GNU/Linux distributions. Not having a native package in Debian/Ubuntu has been a blocker in some potential use cases I encountered.

This 👆. I think Caddy 2 can be brought to the masses when there's a package available for the distros and that'd be awesome! :-)

[Conan-Kudo]

@carlwgeorge, I think this will be very good for the future of the Fedora packaging for caddy. 🥇

[carlwgeorge]

@raatti Caddy is packaged in Fedora and EPEL. I recently updated it to v1 for Fedora 31. It also integrates correctly with SELinux.

[rubyFeedback]

I am not involved with the project in any way; but I hope you can find/use a clear licence to use specifically (I am not making any recommendations, that is up to you of course, but it should ideally be clear and understandable for downstream users too, in particular if there are any exceptions to this, so I hope the transition will also include all necessary details IF there are exceptions that is).

[mholt]

Okay, proposal officially accepted and in motion.

I've drafted PR #2799 which (when finished) will bring all the enterprise code into this repo as open source. Almost all these features were already documented on the wiki, so you can learn how to use them from there.

Individual commit messages have some details on each feature, but I'll summarize them here:

• API: New /config/ and /id/ endpoints: As you know, Caddy 2 receives configuration through a REST API. Previously you just had the /load endpoint to POST a new config to it, but now there is /config/ and /id/ as well:

  • /config/ accepts only Caddy's native JSON structure; however, you can traverse into the structure using the URL path and make changes to only certain parts of the config, for example, to change a listener address:
    PATCH /config/apps/http/servers/demo/listen/0 ":8081"
  • /id/ shortcuts into a specific part of the config so your paths can be shorter, using "@id" tags in your JSON. (This is documented on the wiki.) If you had tagged the demo server in the previous example with a label of demo, your request becomes much simpler:
    PATCH /id/demo/listen/0 ":8081"
    This makes a difference with deeply nested structs, especially when you're manually making changes!
  • You can now export the current configuration live with a GET /config/ (and of course, you can limit the scope of what is returned by using the path).
  • By contrast, the /load endpoint does not let you traverse the config, but it does accept any format using config adapters. So you can POST a Caddyfile or JSON-C or TOML or NGINX config to /load. I made it so that /load simply wraps the /config/ endpoint after adapting the config.

• HTTP: Distributed cache (WIP): A high-speed, distributed, in-memory HTTP cache powered by groupcache. It works, but it's still in very early stages as a promising proof-of-concept. Would anyone like to help develop it? This could be a lot of fun but will be challenging -- not recommended for beginners.

• Reverse proxy: Circuit breaker: This is a basic but effective "circuit-breaker" that will mark a backend as down before it actually goes down, in an effort to keep it up, by measuring latency over a sliding window.

• TLS: PEM loader: This allows you to embed PEM certs and keys directly into the JSON config. This is useful to reduce dependence on external storage but more especially to avoid writing sensitive keys to potentially unsecured storage, if that is important to your threat model.

• TLS: Distributed STEK: This is an advanced feature for improving TLS connection performance in a cluster by coordinating the rotation of TLS session ticket keys so that clients don't have to renegotiate the TLS connection when they get load balanced to a different backend. (Twitter hacked something together that does this, now Caddy does it natively.)

• TLS: Custom certificate selection: If more than one certificate is qualified to complete a TLS handshake, you can customize the logic to choose which certificate is used for a specific handshake based on other factors. Again, a very niche feature but useful in some corporate settings, as it turns out.

• Starlark: This is Caddy's embedded scripting language. I haven't gotten this pushed at time of writing, but will be soon. An embedded script gives you the power of an imperative config where you need it, without the trouble that NGINX's "evil" if statement introduced. Starlark is also very efficient as it does not use a VM: all evaluations are native Go, so it performs quite well. In some early tests we suspect that it can surpass NGINX+Lua performance by 2x-4x if we do it right. That will take some time, and this will be a feature that is in development for a while, but it is really cool for dynamic connection handling, for instance.

Anyway, that's what is around the corner with this next beta release.

As for the other objectives, namely the website:

• The new homepage is almost done
• We'll be stripping out the old products pages and enterprise branding stuff
• And then hopefully deploy the changes next week

Thanks for your input, everyone!

Along with caching and embedded scripts, we also would like to add modules for:

• Raft consensus (this might require some core integration)
• Rate limiting
• Blocking / firewalling (at scale - basically replace WAF)
• Monitoring / metrics (like, a prometheus exporter)

Feel free to take a look at the code and get involved, especially on the many unfinished or desired modules. (Always open an issue to discuss your plan in detail before spending lots of time on a PR.)

This should be fun!!

[Conan-Kudo]

@mholt After this change, do we need to continue having the CLA requirement? The CLA only makes it easy for relicensing to proprietary, and if we're switching to pure open source, it's not needed anymore...

[elcore]

@Conan-Kudo Caddy, like many open-source projects, is using the Developer's Certificate of Origin to make sure that contributors have the right to push changes into the Caddy project. This is not a CLA per definition, it's widely recognized, and respected by the open-source community.

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

[Conan-Kudo]

@elcore Ah, that's fine. I assumed it was different since you were using SAP's CLA Assistant bot (the terms weren't loading for me...)

[elcore]

@Conan-Kudo Yeah... Sometimes it takes some time to load, you probably have closed the tab too fast 😅

[mholt]

@Conan-Kudo

After this change, do we need to continue having the CLA requirement?

Yes. The CLA verifies that you have the right to submit the change. We use the Linux Foundation's DCO. Without a signature on each contribution, companies like Google were unable to use Caddy.

@tobya

I think the CLA is important as it assigns copyright to the project

Our CLA does not assign copyright. The original author retains the copyright over their original work, but licenses it for use according to the project's open source license (Apache 2.0 in our case).

---

I've finished pushing the rest of the code. The Starlark middleware needs more work to bring it up to speed with the current Caddy 2 architecture. Like with the caching module, contributions are welcomed here as well.

[joepie91]

Without a signature on each contribution, companies like Google were unable to use Caddy.

It's worth emphasizing here that it's not that they're unable to use Caddy without it, but rather that they're unwilling to use it. There's no legal requirement for it; this is just a risk reduction demand on Google's part. Whether that's something the project should accommodate is a separate discussion, of course, but I think it's important to be clear about where the requirement comes from.

---

@mholt Please do be careful not to make the same mistake as the Linux Foundation and various other projects; namely, to demand that "real names" be used in the DCO. There's really no legal value to that, and all it does is scare off people who have very legitimate reasons not to want to put their government-registered name on their work, eg. because they belong to an at-risk minority of some sort.

[mholt]

@joepie91

Relax.

It's worth emphasizing here that it's not that they're unable to use Caddy without it, but rather that they're unwilling to use it. There's no legal requirement for it; this is just a risk reduction demand on Google's part.

I think it's obvious that we want large companies using Caddy.

And I say "unable" because the red tape that is needed to circumvent or change those requirements becomes practically impossible at companies like Google.

@mholt Please do be careful not to make the same mistake as the Linux Foundation and various other projects; namely, to demand that "real names" be used in the DCO.

Are we demanding that? I've never heard of this.

[joepie91]

I'm perfectly calm, just pointing out a few things of note :)

Are we demanding that? I've never heard of this.

I don't know if the Caddy project does, but I do know that the Linux project does (and there's been a kerfuffle over this on a mailing list, IIRC). This wasn't an accusation, rather a heads-up, since this consequence of a 'real-name policy' tends to get missed a lot when projects consider whether to institute such a policy or not.

[mholt]

@joepie91

I don't know if the Caddy project does

We don't.

[joepie91]

That's good to hear!

[daiaji]

Reasonable commercialization is always a good thing. It's surprising that a stable version of Addy V2 will be released in Q1 2020.
Proprietary agreements are really annoying.

[whalehub]

This is very exciting news! I can't wait to try out Caddy v2.

[ptman]

@whalehub you don't have to wait: https://github.com/caddyserver/caddy/tree/v2

[mholt]

Update for the week:

All the code that has been open-sourced is now available in the beta 6 pre-release: https://github.com/caddyserver/caddy/releases/tag/v2.0.0-beta6

Hoping to get the updated website released this week, followed by the WIP Kubernetes ingress controller. (We'll want the community's help to finish that, by the way!)

We're also actively working on Docker, Debian/etc, RedHat/etc, DigitalOcean, AWS, and other official distros/images. This part is especially a community effort, so if you have chops packaging up Go programs for any distribution channels, let us know and we'd love your help! (See relevant issues)

[lpellegr]

What a great update! Is there any plan to support invalidation with the cache layer? support for surrogate keys would be a killer feature (e.g. https://docs.fastly.com/en/guides/purging-api-cache-with-surrogate-keys) that could bring a lot of users!

[mholt]

@lpellegr Yes, the caching handler is a WIP. Please feel free to open a new issue to discuss how that can be done. Thanks!

[lpellegr]

@mholt Done: #2820.

[mholt]

Final update on this

We've recently released the work-in-progress Caddy Kubernetes ingress controller and the NGINX config adapter.

This concludes our transition to fully open source licensing. Thank you, everyone!

In addition, our community has made significant strides in publishing official images/distributions for:

• Docker
• DigitalOcean (Link TBA)
• Fedora/RedHat COPR and RPM

We are still looking for experienced volunteers to work on Debian/Ubuntu packages. If you would like to help us publish official Debian/Ubuntu packages, please let me know!

We also need help finishing the NGINX adapter and Kubernetes ingress controller. We can help coordinate efforts, just start getting involved on the repositories and we'll take note. You can also post on our forums if you have questions. Thanks!