OpenSSL Licensing Update
openssl.org
openssl.org
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.
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.
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)
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.
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.
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.
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...)
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...
It sounds pretty dodgy on several grounds.
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.
It's a hard slog either way.
Concretely: Contributing to apache 2 software potentially grants universal licenses for relevant patents you hold to anyone that uses the apache 2 software. Courts have not decided how viral this is. (What if I start with apache 2 code, make substantial changes, and apply it in areas the patent holder objects to, for example?)
I'm not a fan of software patents, but sloppy retroactive relicensing like this will create all sorts of legal ambiguity for users and contributors.
(Also, as the openbsd thread points out, apache 2 is license incompatible with existing openssl forks and other downstream software)
The explicit patent language in Apache License 2.0 is a good thing.
Personally I'm against software patents, but as long as they're legal this seems like a backdoor reason you should never release code under Apache if you have patents in a related field.
Not potentially.
> (What if I start with apache 2 code, make substantial changes, and apply it in areas the patent holder objects to, for example?)
The plain reading of the license is that it only grants licenses to patents which are necessarily infringed by the contributions of the patent holder. As for what would happen if you heavily modify it, I suppose the court would have to decide whether it is still the same work. But that's strictly more protection than you have under BSD, so I don't really see why you would view it as a negative.
If I am the user, and use Apache 2 software Yahoo (for example) contributed to before they sold their relevant patent to a troll, I'm fine.
If that software is "Apache 2" OpenSSL, I'm totally screwed, even though the OpenSSL team's license.txt told me it's all OK while I was paying my lawyer to do due patent diligence.
I also don't have any sympathy for you if you contribute OSS code that necessarily infringes on a patent, but also want to retain your ability to enforce the patent against users of the OSS project you're contributing too. That use-case is one that has negative priority for me -- I would prefer that you be unable to contribute under those circumstances.
The timeframes created by relicensing create particularly nasty problems. Here is an ordering of events where the developer and user act in good faith, but the troll wins:
First, a dev at Yahoo contributes under the OpenSSL license.
Years later, Yahoo sells to trolls (this is bad, but no one involved in OpenSSL did it).
Even later, openssl decides to relicense as apache 2.0. Maybe the dev clicks yes on the relicense form (big mistake, since the patent is not held by the dev or yahoo anymore), maybe the dev clicks no, or maybe they don't reply. Let's go with "no reply" or "clicks yes".
In those cases, openssl will not rewrite the code, and users will see that yahoo contributed to (now) apache 2 licensed OpenSSL and assume the patent protection apache 2 implies actually exists.
Some decide to use the code, instead of some other actually unencumbered alternative.
Later, the users get sued by the troll for violating the yahoo patent by running "apache 2" software yahoo wrote while yahoo held the patent. (When the troll bought the patent rights, the code was still openssl licensed, so the apache 2 relicensing definitely does not apply)
Even without the patent sale, openssl will be misrepresenting grants of patent licenses unless they rewrite all the "no" and "no response" code, including all the derivatives of code. The repo is at least two decades old, so a "no" response from the early days is probably impossible to recover from.
Anyway, the letter says they will treat "no response" as "yes", which clearly not going to hold up in court in most legal jurisdictions.
Claiming apache 2 licensing at the end of this flawed process is simultaneously false advertising and hostile to users.
It also hurts non-apache 2 downstream projects, or anyone paying enough attention to run away screaming.
Contrast this to what would happen if they simply removed the advertising clauses, making it GPL compatible: They'd need permission from many fewer people, wouldn't break downstream, and wouldn't make false statements about patent licensing.
Having helped out with many relicensing exercises at this point, i'm not sure why people are so worried.
The usual tact taken is: If you cannot affirmatively get consent, you remove the code and, if still needed, have someone not involved rewrite it.
I have yet to see anywhere in all of this that actually says they plan on doing anything different (IE theo's trolling seems to be based not on reality). I looked at the press releases, details, and mailing lists. What am i missing?
"If we do not hear from you, we will assume that you have no objection."
Just assuming that the email has been read is already a far stretch.
* https://mailman.videolan.org/pipermail/vlc-commits/2011-Nove... (grep for "It is possible")
* https://dolphin-emu.org/blog/2015/05/25/relicensing-dolphin/...
* https://blogs.fsfe.org/ciaran/?p=58 (grep for "it is not necessary")
That is still not assent by the remaining 5%, but was apparently sufficient for relicensing of the whole work in the relevant jurisdictions.
In that context, the quote from the OpenSSL email appears to be well-phrased, as it really only assumes the absence of objections.
They certainly can't obtain legal consent to relicense this way, and anyone who told them the could pretty much has no idea what they are talking about, at least in the US.
There is a lot of citation to "lawyers in the past told them X" with no actual data or description of what those lawyers said, caselaw they relied upon, jurisdiction they are talking about, etc.
However they might have instead used some of the donor money to hire someone to do a clean-room re-implementation of the functionality for which they couldn't get the original author's blessing to change the license of. This might have been the more respectful thing to do perhaps.
If no, then what percentage of contributors need to agree? Or do I need to rewrite all of the code that I get noes for?
The core problem here is not that they are changing the license. It is that it is now not clear what license is actually in effect; and it could very possibly end up being both.
The upside to this is that no one enforces these licenses anyway.
[0] Which might be a bigger deal in other contexts, for a security library, I should be staying up to date anyway.
EDIT: Dammit, Squid is GPLv2.. It might make the situation worse due to the Patent clause.
So, potentially now.. GPLv2 programmes can't use OpenSSL. Nice.
I don't suppose the libressl folks could end up creating a 2-clause BSD implementation of the SSL/TLS stack that could divorce itself completely from its openssl origins? (Yes I know that's almost certainly impractical for such a large, complex and thorny code base and problem set, but it's a nice dream... maybe some cryptography researchers/companies/etc. looking to make a name the the industry could target and re-implement specific pieces/algorithms/etc...)
They choose to see that as implicit agreement. Hope they consulted with lawyers on that one.
> + *) Removed old DES API.
> + [Rich Salz]
"If we do not hear from you, we will assume that you have no objection"I'm confused, because they seem to have decent counsel assisting (SFLC). Jim Wright from Oracle (who is interviewed) knows his stuff too.
Even a self contained file isn't so straightforward as how would you differentiate between "new code" and simply copying the old one as a "new patch"?
"It is possible that there may be Mozilla source files containing contributed code for which the copyright holders refuse to grant permission for relicensing under the MPL/GPL/LGPL triple license. In those cases we will investigate whether the situation can be resolved by someone writing new code to replace the code which cannot be relicensed. (This may require writing a complete new source file, or simply rewriting one or more portions of an existing file.)"
https://www-archive.mozilla.org/MPL/relicensing-faq.html#per...
[1] https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....
In particular, in Oracle v. Google it turned out that Google employed the same person (Joshua Bloch) to write a bunch of Dalvik core libraries who had previously written the same Java core libraries, and that somehow was not an issue in the case. Only the nine identical lines of rangeCheck were an issue. So I'm questioning my understanding of the law here.
Exposure increases the risk that work that appears like it might be derivative will be found to derivative, but there is no legal rule about it, it's just evidence from which a trier of fact might, in combination with other evidence, conclude derivation in violation of copyright.
Clean room means that (presuming the trier of fact accepts that it was a clean room) there can be no derivation or copying, because there was no access to the source from which that could have occurred. This isn't about the legal rule directly, but about evidence from which one might conclude that a violation of the rule occurred.
Of course, given API copyrights, rewriting code to implement the API of existing code is potentially problematic even with a clean room implementation, since the API is preserved.
I worked on certain financial data models for long enough (9 years, a quarter of my life) that they're burned into my brain. Even though it's been 4 years since I've worked for that company, I could easily reproduce probably at least 90% of the data model with a fairly high degree of accuracy. That is stuff I cannot unlearn or forget. I never signed a non-compete, but I did sign an NDA that expired after a year, so I'd be in the clear if I were to re-implement something similar (I wouldn't - the data model was awful).