Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Permanently change all proprietary licensing to open source #2786

Open
mholt opened this issue Oct 3, 2019 · 68 comments

Comments

@mholt
Copy link
Member

commented Oct 3, 2019

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!

@mholt mholt added the discussion label Oct 3, 2019
@mholt mholt added this to the 2.0 milestone Oct 3, 2019
@jungle-boogie

This comment has been minimized.

Copy link
Contributor

commented Oct 3, 2019

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.

@mholt mholt pinned this issue Oct 3, 2019
@PSUdaemon

This comment has been minimized.

Copy link

commented Oct 3, 2019

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 comment has been minimized.

Copy link

commented Oct 3, 2019

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

@brennanfee

This comment has been minimized.

Copy link

commented Oct 3, 2019

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

This comment has been minimized.

Copy link

commented Oct 3, 2019

Thank you !

Thats a yes from me

@hairyhenderson

This comment has been minimized.

Copy link

commented Oct 4, 2019

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

@kivutar

This comment has been minimized.

Copy link

commented Oct 4, 2019

It will help increase adoption.

@jleclanche

This comment has been minimized.

Copy link

commented Oct 4, 2019

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

@mholt

This comment has been minimized.

Copy link
Member Author

commented Oct 4, 2019

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

This comment has been minimized.

Copy link

commented Oct 4, 2019

@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

This comment has been minimized.

Copy link

commented Oct 4, 2019

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

@tomhatzer

This comment has been minimized.

Copy link

commented Oct 4, 2019

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

@ibakirov

This comment has been minimized.

Copy link

commented Oct 4, 2019

Great initiative!

@didil

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2019

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 comment has been minimized.

Copy link

commented Oct 4, 2019

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

This comment has been minimized.

Copy link

commented Oct 4, 2019

Go for Copyleft, not a permissive license.

@paride

This comment has been minimized.

Copy link

commented Oct 4, 2019

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 comment has been minimized.

Copy link

commented Oct 4, 2019

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 comment has been minimized.

Copy link

commented Oct 4, 2019

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

@Henrocker

This comment has been minimized.

Copy link

commented Oct 4, 2019

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

This comment has been minimized.

Copy link

commented Oct 4, 2019

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

@carlwgeorge

This comment has been minimized.

Copy link

commented Oct 4, 2019

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

@rubyFeedback

This comment has been minimized.

Copy link

commented Oct 4, 2019

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

@Mohammed90

This comment has been minimized.

Copy link
Collaborator

commented Oct 7, 2019

@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

This comment has been minimized.

Copy link

commented Oct 7, 2019

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

mholt added a commit that referenced this issue Oct 10, 2019
This integrates a feature that was previously reserved for enterprise
users, according to #2786.

The /config and /id endpoints make granular config changes possible as
well as the exporting of the current configuration.

The /load endpoint has been modified to wrap the /config handler so that
the currently-running config can always be available for export. The
difference is that /load allows configs of varying formats and converts
them using config adapters. The adapted config is then processed with
/config as JSON. The /config and /id endpoints accept only JSON.
mholt added a commit that referenced this issue Oct 10, 2019
This migrates a feature that was previously reserved for enterprise
users, according to #2786.

The cache HTTP handler will be a high-performing, distributed cache
layer for HTTP requests. Right now, the implementation is a very basic
proof-of-concept, and further development is required.
mholt added a commit that referenced this issue Oct 10, 2019
This migrates a feature that was previously reserved for enterprise
users, according to #2786.

The local circuit breaker is a simple metrics counter that can cause
the reverse proxy to consider a backend unhealthy before it actually
goes offline, by measuring recent latencies over a sliding window.

Credit to Danny Navarro
mholt added a commit that referenced this issue Oct 10, 2019
This migrates a feature that was previously reserved for enterprise
users, according to #2786.

The PEM loader allows you to embed PEM files (certificates and keys)
directly into your config, rather than requiring them to be stored on
potentially insecure storage, which adds attack vectors. This is useful
in automated settings where sensitive key material is stored only in
memory.

Note that if the config is persisted to disk, that added benefit may go
away, but there will still be the benefit of having lesser dependence on
external files.
mholt added a commit that referenced this issue Oct 10, 2019
This migrates a feature that was previously reserved for enterprise
users, according to #2786.

TLS session ticket keys are sensitive, so they should be rotated on a
regular basis. Only Caddy does this by default. However, a cluster of
servers that rotate keys without synchronization will lose the benefits
of having sessions in the first place if the client is routed to a
different backend. This module coordinates STEK rotation in a fleet so
the same keys are used, and rotated, across the whole cluster. No other
server does this, but Twitter wrote about how they hacked together a
solution a few years ago:
https://blog.twitter.com/engineering/en_us/a/2013/forward-secrecy-at-twitter.html
mholt added a commit that referenced this issue Oct 10, 2019
This migrates a feature that was previously reserved for enterprise
users, according to #2786.

Custom certificate selection policies allow advanced control over which
cert is selected when multiple qualify to satisfy a TLS handshake.
mholt added a commit that referenced this issue Oct 10, 2019
@mholt

This comment has been minimized.

Copy link
Member Author

commented Oct 10, 2019

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

@mholt mholt added the in progress label Oct 10, 2019
@Conan-Kudo

This comment has been minimized.

Copy link

commented Oct 10, 2019

@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

This comment has been minimized.

Copy link
Collaborator

commented Oct 10, 2019

@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

This comment has been minimized.

Copy link

commented Oct 10, 2019

@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

This comment has been minimized.

Copy link
Collaborator

commented Oct 10, 2019

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

mholt added a commit that referenced this issue Oct 10, 2019
This migrates a feature that was previously reserved for enterprise
users, according to #2786.

The Starlark integration needs to be updated since this was made before
some significant changes in the v2 code base. When functional, it makes
it possible to have very dynamic HTTP handlers. This will be a long-term
ongoing project.

Credit to Danny Navarro
@mholt

This comment has been minimized.

Copy link
Member Author

commented Oct 10, 2019

@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

This comment has been minimized.

Copy link

commented Oct 10, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Oct 10, 2019

@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

This comment has been minimized.

Copy link

commented Oct 10, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Oct 10, 2019

@joepie91

I don't know if the Caddy project does

We don't.

@joepie91

This comment has been minimized.

Copy link

commented Oct 10, 2019

That's good to hear!

@daiaji

This comment has been minimized.

Copy link

commented Oct 11, 2019

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 comment has been minimized.

Copy link
Contributor

commented Oct 14, 2019

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

@ptman

This comment has been minimized.

Copy link

commented Oct 14, 2019

@mholt

This comment has been minimized.

Copy link
Member Author

commented Oct 14, 2019

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

This comment has been minimized.

Copy link

commented Oct 18, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Oct 18, 2019

@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

This comment has been minimized.

Copy link

commented Oct 18, 2019

@mholt Done: #2820.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.