
OpenSSL versioning and license changes - sethvargo
https://www.openssl.org/blog/blog/2018/11/28/version/
======
lucb1e
Summary:

\- Next version will be 3.0.0 which is major.minor.patch (v2 was used for
OpenSSL FIPS). The letter will not be used anymore.

\- Next version will be under the Apache 2.0 license instead of "Apache
License 1.0 and 4-clause BSD License"[1].

The main difference between Apache License version 1 and 2 is that v2 is
compatible with GPLv3. There are some other changes like clarifications and
requiring a patent if you contribute code that would infringe a patent that
you own. For an overview of Apache2, see [2].

Overall, doesn't sound like a large change.

[1]
[https://en.wikipedia.org/wiki/OpenSSL](https://en.wikipedia.org/wiki/OpenSSL)

[2]
[https://choosealicense.com/licenses/apache-2.0/](https://choosealicense.com/licenses/apache-2.0/)

~~~
xorcist
Too bad they couldn't find a way to allow linking GPLv2 code with OpenSSL.

As it stands every author has to add an OpenSSL exception to their licensing,
which benefits nobody. It all seems a bit outdated and unnecessary.

I guess that means OpenBSD can't use OpenSSL going forward either? They have
previously excluded Apache 2.0 licensed software.

~~~
protomyth
_I guess that means OpenBSD can 't use OpenSSL going forward either? They have
previously excluded Apache 2.0 licensed software._

They've switched to LibreSSL in base, but Apache 2.0 is fine in ports. I guess
it might affect adding patches from OpenSSL.

~~~
loeg
There's also some dispute over whether OpenSSL has the right to relicense all
of its codebase to Apache 2.0; they didn't require a copyright transfer from
individual authors and don't have 100% authorial consent.

------
evilgjb
Regarding this text in the announcement:

"In practical terms our “letter” patch releases become patch numbers and “fix”
is dropped from the concept. In future, API/ABI compatibility will only be
guaranteed for the same MAJOR version number. Previously we guaranteed API/ABI
compatibility across the same MAJOR.MINOR combination."

Does this mean 3.0.0, 3.0.1, 3.1.0 and 3.1.1 will all be ABI/API compatible?

This reads a bit ambiguously at face value in the announcement.

~~~
dimman
>Does this mean 3.0.0, 3.0.1, 3.1.0 and 3.1.1 will all be ABI/API compatible?

Just to clarify (given my assumption that semver apply): 3.1.0 might contain
new features compared to 3.0.z, those won’t be backported, but code
written/compiled against 3.0.0 will continue to work fine on 3.y.z

~~~
wolfgang42
_> given my assumption that semver apply_

Per the post, "we are not at this stage directly adopting semantic
versioning," though from the sounds of it they're going to try to make the
version numbers at least closer to what's expected of semver.

------
cyphar
This is nice that it in theory removes the need for the OpenSSL exception,
_except_ that Apache 2.0 is still incompatible with GPLv2 so many projects
will still need the OpenSSL exception. I wonder whether the common OpenSSL
exception wording will cause problems with older projects that cannot update
their exception (in particular the "modified versions with the same license as
OpenSSL" section).

------
jgtrosh
Why “the Holy Hand Grenade of Antioch”?

~~~
justincormack
Because the release version will be 3, not 2 or 1. Monty Puthon reference.

~~~
mhandley
"neither count thou two, excepting that thou then proceed to three."

------
mkj
So they had to get rid of all the original Eric Young code?

Interesting that a reason it couldn't "just" be relicensed maybe dates back to
RSA patent issues.
[https://lwn.net/Articles/428666/](https://lwn.net/Articles/428666/) comment
from eay

