Caddy: 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! :smile:

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

[danlsgiga]

That was one of my main concerns on considering Caddy over other solutions out there. Definitely support this move and grateful for the awesome work done so far in this project.

[tracker1]

Just curious, what is the advantage of Apache license over something simpler with similar permissiveness (such as MIT/ISC)?

[Conan-Kudo]

Just curious, what is the advantage of Apache license over something simpler with similar permissiveness (such as MIT/ISC)?

Mainly ASL 2.0 provides an explicit patent grant.

[tobya]

I am greatly in favour of this plan. I think Caddy has a bright future with widespread adoption. Hopefully it will pull more contributors and maintainers into the project. Great job as always

[mholt]

Thanks everyone, we'll work on putting this into effect immediately.

@sandstrom

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

Our focus is the same -- build a great web server that everyone loves. We had to make this change to get that "everyone loves" part right.

@elimisteve

get acquired and let them figure it out! 😄

There have not been any acquisitions (i.e. transfer of ownership), except that I now work on Caddy full-time through employment with Ardan Labs. Light Code Labs still technically owns the Caddy brand (trademark) and all v1 code, but Ardan Labs is our trusted partner in helping to bring something new (v2) to fruition. We're both figuring it out together, and with the community.

@rubyFeedback

I hope you can find/use a clear licence to use specifically

(and /cc @zoobab) We will continue to use the standard Apache 2.0 open source license: https://github.com/caddyserver/caddy/blob/master/LICENSE.txt

---

We've started work on a new website and are making a plan to bring the enterprise plugins into the open source repos soon.

All of the features currently listed as "🏢 Enterprise" in the temporary v2 docs in our wiki will be made open source soon.

In the mean time, would anyone want to collaborate on these things?

• Finishing up the Kubernetes ingress controller (it's mostly working, and we will publish it soon).
• Making official distro packages and a Docker image. I admit I personally do not have much experience with this. We're able and willing to maintain official distributions, but I'm asking for your help to make them!

If we collaborate on these things, they'll be ready much sooner. :+1:

[jleclanche]

Making official distro packages

Happy to help get caddy into Arch Linux more officially. :)

[KopfKrieg]

@mholt

Making official distro packages and a Docker image.

Oh, yesss, please <3

I admit I personally do not have much experience with this. We're able and willing to maintain official distributions, but I'm asking for your help to make them!

Right now if someone wants to use Caddy in a docker container they usually use this image. Maybe ask him/her for help? As an alternative, the team behind linuxserver.io has a lot of experience building and maintaining docker images. I'm sure they'd be happy to help. I also got a bit of experience with building docker images, but I'm just starting, not sure if I'd be of much help.

[carlwgeorge]

@mholt

Making official distro packages

Do you mean official from the distro or official from the Caddy project? In other words, are you referring to packages in distro default repositories, or apt/yum repositories maintained by the Caddy project?

[mholt]

@carlwgeorge

Do you mean official from the distro or official from the Caddy project? In other words, are you referring to packages in distro default repositories, or apt/yum repositories maintained by the Caddy project?

Ideally, we'd like to have packages in distro default repositories which we can update at will; if that's not possible, then maybe it's best to maintain our own apt/yum repositories. Maybe both!

So, I guess what we need help with is:

• Official Docker image
• Official apt and yum repositories
• Official brew formula
• Other official packages (which distros/platforms?)
• Finishing Kubernetes ingress controller

@abiosoft - can you help us make an official Docker image? Should be pretty simple if we use yours as a starting point, right?

@jleclanche Would definitely appreciate your help getting it in arch repos.

What is needed to make apt/yum/arch/<etc> packages?

For anyone who would like to begin on these, we can:

• Make a new issue to discuss the implementation and make sure it's good
• Then make repos in this GitHub org and give you access to it

[Ilyes512]

Can I ask how the binaries are being built at the moment? I would like to suggest a combination of Github Actions and goreleaser. Goreleaser can also take care of homebrew and a couple of other custom linux package managers.

I can also help with the Docker images.

[hairyhenderson]

What is needed to make apt/yum/arch/<etc> packages?

A possible starting point could be the Alpine package that exists: https://git.alpinelinux.org/aports/tree/community/caddy?h=master - there's an init file in there that may be useful

[NoSkillzEngineer26]

I have never heard of your company (don't mind me, still learning), however, I fully support this. Why more companies don't embrace Open-Source Software is beyond me. If it's got the support and it's got people legitimately, actively furthering development....why wouldn't a software company want their code to improve and become more prevalent? (Too bad Autodesk isn't more like that)

Idk what you do, but ima look into you now just because of this move! 👌 you're okay in my book! Good luck!

[hairyhenderson]

• Official Docker image

If by "official" you mean in the DockerHub "standard library" (so you can just docker run caddy), there's some documentation here on how to get started: https://github.com/docker-library/official-images#contributing-to-the-standard-library - I think this is good to aim for, as it would give Caddy parity with other official web server images (like nginx and httpd).

In the meantime, I see that there is already an empty caddy namespace on DockerHub (https://hub.docker.com/u/caddy - assuming this is something you control, @mholt?), so pushing a caddy/caddy image would be the "next best thing". Actually I see there's also a https://hub.docker.com/u/caddyserver which contains a caddyserver/caddy image, though it's sorely out-of date 😉 (looks like that one was last updated by https://hub.docker.com/u/mandrean - @mandrean?)...

A key feature to get an official caddy image accepted would be to produce multi-platform Docker images, especially for the various 32 and 64-bit ARM variants, AMD64, and Windows/AMD64. Producing these should be pretty straightforward since Caddy can easily be cross-compiled, and the new docker buildx build command can easily produce multi-platform builds.

Instead of starting with the abiosoft Dockerfile, it may be best to start with a more bare-bones image - one that just includes the caddy binary and ca-certificates. Just my 2¢!

[abiosoft]

@abiosoft - can you help us make an official Docker image? Should be pretty simple if we use yours as a starting point, right?

@mholt yeah I can.
@hairyhenderson the primary reason the docker image builds Caddy from source is due to licensing. Since that is resolved, it can become lighter with just the binary.

[xdevs23]

I've been waiting so long for this... Please... make everything as open as possible. Disable telemetry by default and don't force businesses to use your paid licenses (or compile Caddy from source). Rather provide support subscriptions to businesses that can be used to get support for Caddy but not in a way that has effect on the source code.

I've been using Caddy for quite a long time and it has been a great experience. Thanks for all the work and I appreciate this change.

[hairyhenderson]

the primary reason the docker image builds Caddy from source is due to licensing. Since that is resolved, it can become lighter with just the binary.

@abiosoft Good point! I was looking at the php variant before I realized there was another simpler one 😅. Even still, there are a few extra packages that may not be necessary in the most basic image. Also, parent shouldn't be necessary anymore - Docker spawns containers with a default init process (tini) that seems to handle all the things parent is intended to.

[mholt]

@Ilyes512

I would like to suggest a combination of Github Actions and goreleaser. Goreleaser can also take care of homebrew and a couple of other custom linux package managers.

That looks promising. Any idea how that integration would look? Should we set up a disposable repo where you or others can experiment with it?

@hairyhenderson

If by "official" you mean in the DockerHub "standard library" (so you can just docker run caddy), there's some documentation here on how to get started: https://github.com/docker-library/official-images#contributing-to-the-standard-library - I think this is good to aim for, as it would give Caddy parity with other official web server images (like nginx and httpd).

(and everything else you suggested)

Yes, that sounds perfect. @abiosoft and can you help us with that? Let's catch up in Slack. @Ilyes512 you had mentioned you can help with Docker images, do you want an invite to Slack, too? Could be easier if we had a mostly-real-time real-time back-and-forth.

In the meantime, I see that there is already an empty caddy namespace on DockerHub (https://hub.docker.com/u/caddy - assuming this is something you control, @mholt?)

I am not aware of that, it would be nice if we could get it though.

Thanks for making the new issues @carlwgeorge -- for those packages, we'll move the discussion to them.

[hairyhenderson]

[...] caddy namespace [...]

I am not aware of that, it would be nice if we could get it though.

Hmm... That may be something to contact DockerHub support about to see if they can disclose the owner of that organization, or put them in contact with you. I'll see if I can find out how that process works.

[Ilyes512]

That looks promising. Any idea how that integration would look? Should we set up a disposable repo where you or others can experiment with it?

Sounds good.

Yes, that sounds perfect. @abiosoft and can you help us with that? Let's catch up in Slack. @Ilyes512 you had mentioned you can help with Docker images, do you want an invite to Slack, too? Could be easier if we had a mostly-real-time real-time back-and-forth.

Sure. You would need my email for the invite I guess? Or is it a public Slack workspace?

[mholt]

@hairyhenderson Ah, that would be great, if you have a contact. Thanks.

@Ilyes512 Yep, I just need an email to send the invite to.

[nklmilojevic]

These are great and very welcoming changes. Good job! :)

I can also help with building docker images.

[Ilyes512]

@Ilyes512 Yep, I just need an email to send the invite to.

I mailed to you (used the mail address mentioned on your personal site).

[jleclanche]

@mholt what's the status on plugins wrt. packaging? Last I checked the issue packaging caddy is that it can only be shipped with no plugins or all plugins enabled. Is there a way to include plugins externally to the binary now?

[mholt]

@Ilyes512 Thanks -- invite sent.

@carlwgeorge @hairyhenderson Would you like invites to our dev Slack as well? Seems like you are interested to help us make this packaging thing a reality. :)

@jleclanche

what's the status on plugins wrt. packaging? Last I checked the issue packaging caddy is that it can only be shipped with no plugins or all plugins enabled. Is there a way to include plugins externally to the binary now?

Yeah, due to limitations in these distribution platforms, the builds can't be customized: so, unfortunately, packaged binaries will have to be what we choose. We'll probably just ship the "standard" plugins or something. Oh, and if joining our Slack would help get Caddy on Arch, let me know.

[sandstrom]

@mholt Two more ideas to look at (maybe you have great processes already) are an RFC policy (https://github.com/rust-lang/rfcs) and bots (to handle/simplify the stream of issues/PRs that any popular open source project will receive).

Best of luck! 😄

[Mohammed90]

@sandstrom @mholt I can work on the bots. I considered it before, but couldn't find stuff that really requires bots at the time.

[hairyhenderson]

@mholt sure! I've e-mailed you my e-mail address for the Slack invite.

[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: https://github.com/caddyserver/caddy/issues/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!

[kgbph]

@mholt
I got a little bit confused, does this mean we can now use Caddy binaries for commercial use?
Is the proprietary licensing mentioned here different from commercial licensing ?

[tobya]

Caddy 2 is fully Apache Licenced. There is no seperate Commercial Licence

https://github.com/caddyserver/caddy/blob/v2.0.0-beta8/LICENSE

If you have further questions on licencing for V1 or V2, its best to open an issue on the Caddy.Community forum.

[mholt]

This issue is relevant to Caddy 1 which has some alternative Licencing methods.

Actually, @tobya, Caddy 1 and Caddy 2 have the exact same licensing.

This is not as complicated as people are making it out to be. Caddy is Apache-licensed just like tens of thousands of other open source projects.