[jessermeyer]

Large web companies like Google implement their own encryption stack anyway.

On the BSD's I've used, LibreSSL is a standard kernel configuration option. I'll note on FreeBSD, LibreSSL lacks the in-kernel fast path, last I checked.

[woodruffw]

> Large web companies like Google implement their own encryption stack anyway.

Google uses BoringSSL[1], which is another OpenSSL fork. I believe AWS uses a mix of OpenSSL and Boring SSL (someone can correct me!).

So it's "their own encryption stack," but that stack is at least originally comprised of OpenSSL's code. They've probably done an admirable job of refactoring it, but API and ABI constraints still apply (it's very hard to change the massive body of existing code that assumes OpenSSL's APIs).

[1]: https://boringssl.googlesource.com/boringssl/

[arianvanp]

AWS maintains their own TLS stack: https://github.com/aws/s2n-tls

[seadan83]

Is this an argument for GPL?

Seems like the big players came, saw, borrowed, and then did their own thing without contributing back.

If this were my project, I would be inclined to archive it and do a GPL fork.

[woodruffw]

None of what happened with OpenSSL or its forks is incompatible with the GPL.

[seadan83]

Forgive my ignorance, but all of these forks are also still open source? My impression was that patches and improvements were made in closed source, private repositories to the benefit of the companies without paying anything back.

Otherwise, couldn't some openssl contributors just crib fixes from the forks?

[woodruffw]

As far as I know, all of the major ones are. I don't believe anybody has attempted to make a closed fork of OpenSSL, at least not one that has gained any real traction.

> Otherwise, couldn't some openssl contributors just crib fixes from the forks?

They do! But I assume it gets balanced with their own feature development time, and it becomes harder as the codebases drift. OpenSSL probably hasn't done itself many favors with the recent (3.x) "providers" refactor.