There is no explicit mention of tools like OpenSSH that are part of OpenBSD, but are more widely distributed. I don't know enough details to know if they are impacted or not (but would love to hear from someone that does know).
Apache 2.0 is a permissive license; they could certainly take patches from OpenSSL and ship them under that license.
They might choose not to, of course. But that's the choice of the downstream project.
If the relicensing was done with the requirements of the whole open source community in mind, they would have dual-licensed or just removed the advertising clauses (and whatever else is GPL incompatible).
Why not turn the tables and relicense OpenSSL under the AGPL? Current users couldn't accept security patches unless they "chose" not to release a bunch of unrelated proprietary code under the AGPL, including things they don't have copyright to.
The only real difference is that service provider's rights would be trampled instead of developer's rights.
From https://www.gnu.org/licenses/license-list.en.html#apache2 :
"Please note that this license is not compatible with GPL version 2, because it has some requirements that are not in that GPL version. These include certain patent termination and indemnification provisions. The patent termination provision is a good thing, which is why we recommend the Apache 2.0 license for substantial programs over other lax permissive licenses."
It's clear that keeping the patent clause was more important to them than keeping GPLv2 compatibility, because otherwise they could have just gone with MIT.
OpenSSL's license is _already_ incompatible with the GPL. The Apache license would make it compatible with the GPLv3, and thus with anything that is GPLv2 "or any later version".
So the supposed death that to LibreSSL that the license change constitutes is nothing but a red herring, or at least it's a red herring to tie it to the license change.
This represents a pretty severe misunderstanding of the practical legal views of both BSD and Apache 2.
"If the relicensing was done with the requirements of the whole open source community in mind, they would have dual-licensed or just removed the advertising clauses (and whatever else is GPL incompatible)."
Dual licensing doesn't actually fix your problems (since anyone using it has to choose one of the licenses. It's not the union of the good features of both licenses, it's "choose your poison), and "or just removed the advertising clauses (and whatever else is GPL incompatible)" represents another severe misunderstanding of what makes apache incompatible with gplv2 (which is pretty much the parts that make it a good license)
It's not practical unless you can maintain a near-100% approval rate from all OpenSSL contributors that their patches are dual-licensed.
OpenSSL:
foo1():
bar()
foo2():
bar()
LibreSSL:
foo1():
bar()
foo2():
bar()
+ baz()
Then someone else realizes that the foo2 change should also apply to foo1:
foo1():
bar()
+ baz()
The more copy-and-pasty the change is, the easier it is to be in a situation where a patch that would apply cleanly to pre-fork code would actually be dependent on post-fork code.
Until such an exceptional provision becomes established precedent, I'd suggest that small projects stick to vetted licenses rather than pitching in with anything novel.
Not for the companies. Many prefer MIT over ASL precisely because they don't want any sort of patent grants.
Likewise, LGPL/GPL/MPL is pointless because LGPL already allows you to take the work and relicense it under the GPL.
The old Mozilla tri-license had both LGPL and GPL to relieve recipients from following the (impractical) letter of LGPLv2.1 when choosing to do the LGPLv2.1 to GPLv2 step.
Nothing, but it doesn't retroactively affect anyone who already has a copy of the software under the GPL. What might stand in the way is a copyright holder refusing to go along with the relicensing.
Uh, no. That's not how this works.
OpenSSL cannot change the license without say-so from all of the contributors, unless a CLA was signed. They do have a CLA, but just one granting a license, not one transferring ownership (and the right to relicense). At least, doesn't look like it.
OpenSSL emailed everyone with commits on the project (e.g. me) a link to a page where you could say yes/no on this. In most cases this isn't a vote, it's all-or-nothing, though the choices of people with extremely minor (non copyrightable) contributions can be excluded IIRC.
IANAL.
(There is some discussion below about "if you don't reply we take that as a yes" being okay, though)
That's like saying if you don't reply, you owe me $1mil. Makes no sense how the OpenSSL folks think this is remotely acceptable.
It sounds pretty dodgy on several grounds.
https://en.wikipedia.org/wiki/List_of_countries'_copyright_l...
And of course, Disney takes heavily FROM the public domain (Aladdin, Pocahontas, Beauty and the Beast, Hunchback of Notre Dame, Hercules, Tarzan, Snow White...)
Reimplementing after you are sued for copyright violation doesn't get you off the hook for the past violations, including enhanced damages for willful infringement, for which this would seem to be an open and shut case.
Of course, since it's a permissive license, you've also got potential downstream commercial infringement to which the unauthorized relicensing is contributory.
If we do not hear from you, we will assume that you have no objection.
(...which is not quite we take that as a yes, but almost.)
An article where Rich Salz cites "expert legal counsel" in response to de Raadt questing whether that's legal: https://www.theregister.co.uk/2017/03/24/openssl_asks_contri...