This is a huge win. The incompatibility between OpenSSL and the GPL has been one of the most notable license incompatibilities regularly encountered in practice. With this change, OpenSSL will become compatible with GPLv3, which also makes it compatible with software licensed "version 2 or later". People will no longer need to choose and port to another crypto library for license reasons.
It is also (according to the OpenBSD mailing list) a huge loss for LibreSSL and OpenBSD because they can no longer take patches from openssl.
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).
You also need the permission of all the authors of the code those patches are based on, because almost all new patches are inevitably derived work of the existing codebase.
It's not practical unless you can maintain a near-100% approval rate from all OpenSSL contributors that their patches are dual-licensed.
This isn't relevant to LibreSSL and so isn't ported: no problem.
Then someone else realizes that the foo2 change should also apply to foo1:
foo1():
bar()
+ baz()
While this patch will apply cleanly to LibreSSL, the idea that after calling bar() you should call baz() is something they figured out in OpenSSL, and is plausibly a derivative work of OpenSSL.
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.
"Permissive" is a spectrum on many dimensions. This relicensing is less permissive than the old license in some ways (like patent requirements for developers) and more permissive in others (the advertising clause).
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.
"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".
A dual license as done with mbed TLS or other similar projects would be huge win for both parties.
ASL 2.0 only is a huge loss for LibreSSL and OpenBSD. It's even an outragious death threat to them.
OpenSSL could, starting tomorrow, drop the 4-clause BSD dual license and only keep the Apache v1 license. And they could do so without the approval of any of the copyright holders. In fact that's all that is being asked of the copyright holders---to drop an advertising clause that doesn't even mention their name.
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.
""Permissive" is a spectrum on many dimensions. This relicensing is less permissive than the old license in some ways (like patent requirements for developers) and more permissive in others (the advertising clause).
"
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)
Though worth noting that ASLv2 is not compatible with straight GPLv2 (the "or later" part of "version 2 or later" is crucial). This is why some projects dual-license as MIT/ASLv2, because MIT is compatible with GPLv2.
LLVM's proposed switch included a provision to make it explicitly compatible with GPLv2. That seems like a nice precedent to follow for other projects that are considering Apache 2 as their license.
I'd say that works for LLVM only because Apple can afford lawyers who can argue that provision if it ever came to that (not that I think it ever would). AFAICT, ASLv2 is superior to BSD/MIT in all practical respects except for the GPLv2 compatibility, and if it were so trivially easy to make a version of ASLv2 that didn't have that downside, then I feel like some company would have already done that and instantly created The One Permissive License To Rule Them All (and in the eyes of the law, bind them).
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.
AFAICT this is overstating the patent-related aspects of ASL. It doesn't require a patent grant or nullify any parents you hold, or even prevent you from suing others over misuse of those patents. All it does is provide mutually assured destruction: if you sue someone over the use of your patent within this software, then you forfeit any legal protection from others who have patents within this software. This is extremely company-friendly, because companies are the ones who tend to go around suing over patents, and also the ones who feel compelled to stock up on patents to use defensively.
Dual MIT/ASLv2 is how Rust achieves GPLv2 compatibility while requiring contributions to be under the superior (to MIT) ASLv2 language, too. ASLv2/GPLv2 dual would achieve the GPLv2 compat goal without potential unintended other consequences arising from the MIT part.
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.
I wasn't thinking of OpenSSL specifically but rather as a general question. E.g. why is Rust ASL2/MIT licensed (my guess is that it's just what Graydon originally chose for whichever reasons and nobody cares enough to change it)?
A "huge win" being enacted by a complete disregard for the copyright holders who were kind enough to contribute to the project. I find this behavior utterly unacceptable. If more projects attempted this bullshit the whole world would be a mess. What's to stop someone from relicensing a GPL program to closed-source, and assuming that anyone who might object would have spoken up? This is breathtakingly idiotic.
> A "huge win" being enacted by a complete disregard for the copyright holders who were kind enough to contribute to the project.
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)
They're daring you to sue them, in which case you would be required to provide a list of the parts of the code that you claim copyright over, which they could then attempt to excise via black-box reimplementation. It's one of those "ask forgiveness rather than permission" things, and is pretty much how every large project relicensing operates (the exceptions being those projects that require copyright assignment via signed CLA).
> They're daring you to sue them, in which case you would be required to provide a list of the parts of the code that you claim copyright over, which they could then attempt to excise via black-box reimplementation
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.
Well, in the unlikely event the contributor chose to register their copyright on a timely basis, statutory damages would apply, independent of actual loss.
Of course, since it's a permissive license, you've also got potential downstream commercial infringement to which the unauthorized relicensing is contributory.
What happens if the Author dies? Are they and their heirs still the copyright holders? I always assumed anything licensed under the GPL would contain that license post mortem.
In USA the copyright holder (which might be the late author's estate) owns the IP for 70 years after death of the original author. After the 70 years have elapsed the work enters the public domain.
Those are new works. The old works are supposed to pass to the public domain.
And of course, Disney takes heavily FROM the public domain (Aladdin, Pocahontas, Beauty and the Beast, Hunchback of Notre Dame, Hercules, Tarzan, Snow White...)
They have trademarked it, but not copyrighted it. The trademark is a bit overstepping - no-one else can market something as Snow White - but anyone can do the Snow White story, as long as Ms White doesn't look like the Disney artwork.
The estate will own it for a time period.
Copyright law has a reclamation period after 35 years where, in a bunch of circmustances, you can terminate all exclusive and non-exclusive licenses and take it back
I would guess that if only a small number of contributors disagree, they'll follow-up by asking those contributors which parts they claim a copyright interest in. Then it can be determined if it's feasible to go forward without those contributions or not.
> What's to stop someone from relicensing a GPL program to closed-source.
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.
The Rust replacement for OpenSSL is coming along well.[1] It's available under Apache License version 2.0.. the MIT license, or the ISC license. That should be the future direction.
Is rustls actually a replacement though?
I can compile existing applications with rustls in stead of OpenSSL without altering the code of those applications?
Wow. Apache 2 has a patent license section that BSD style licenses are missing. At first glance, this looks like this change is being done in bad faith.
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)
So what if you hold a patent on an extended version of the algorithm, but release a limited version for free? If someone extends the limited version to include the patented work, does the virality of the licence, and it being a derivative of your work, mean that you have no legal recourse?
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.
> Contributing to apache 2 software potentially grants universal licenses for relevant patents ...
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'm the developer, I accidentally lose my patent, or (accidentally) misrepresent my employers intention not to license the patent, so I get hauled into court.
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 don't think that your Yahoo scenario is correct. The license you are granted is perpetual and irrevocable. Yahoo transferring the patent to another party is one of an entire universe of things that cannot revoke your license to use it. It doesn't matter whether the other party decides they'd prefer you not use it -- you still own that license.
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.
My argument isn't about apache 2 vs bsd. It is about the terrible legal issues relicensing other people's code without explict permission will create.
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.
One really wonders why they wouldn't go for ISC. Both without context, and in the context of LibreSSL being around, I just can't see why they would go for Apache 2.0.
So, the major question getting asked (and theo is trolling about elsewhere) is what happens if you don't respond to the emails.
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?
The email can state all it wants, but from a legal point of view, assuming consent merely by absence of dissent is nonsense -- at least in the jurisdictions I'm familiar with. There are exceptions to this, but this is not one of those cases.
Just assuming that the email has been read is already a far stretch.
Ah. In those cases, it appears that the overwhelming majority (>= 95%) of developers explicitly agreed to the relicensing, with the remaining minority at least not objecting.
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.
If so, that's uh, yeah, remarkably stupid.
I would guess they meant "don't object to the plan in general".
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.
Seems like OpenSSL should focus on fixing their code instead of risking the alienation of past contributors. I wonder if this is to satisfy some of the big donors who want to fix OpenSSL but won't until the license is changed. I know I'd be pissed if I had contributed and then got an email saying no response implies agreement.
I think with any larger scale open source project looking to change license they basically have to assert that no response implies agreement because of the amount of people that have contributed over time and things that this leads to, such as the probability that at least one of them might have died or otherwise have become unreachable since when they contributed.
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 they don't do it, and just take the code someone else contributed to the project under a different copyright notice and put it under Apache 2.0, does that mean I can fork, say, Firefox or gcc and slap an MIT copyright on the source code if not all of the contributors reply to my email asking them if they agree to it?
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?
Anyone with a potential copyright claim on the source can take legal action if they believe that their rights have been violated. If you object to OpenSSL relicensing and have contributed to it, you can sue them if they go through with it. Likewise, if you violate the license of any other software project, that project can sue you. OpenSSL is betting that the vast majority of contributors will agree, and that the rest will either not care or won't sue, and if someone does sue they're hoping that person's contributions are minimal enough that they can be removed from the codebase.
The problem is that this can happen at anytime. As a user of OpenSSL, I have no guarantee that a contributor won't, at some point in the future, decide to sue over this. Once that happens, I would have to remove their contributions from my copy [0], or risk being sued. Further, if enough time passes, and there are contributions under the new license, I would have to comply with both licences (which are incompatible).
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.
Although I personally think matching the OpenBSD libressl license would have been better, I still have to regard the move towards using one of the mainstream, modern standard open source licenses for such a widely used and critical software component a Good Thing. I do, however, also agree with those voicing skepticism about the "silence gives consent" bit - this is important enough to be worth doing without adding a (very) questionable practice like that to the mix. I'd suggest instead setting up some sort of "relicensing coverage" report, and use the yay/nay/no-answer status of various diffs to figure out a price tag for re-writing the bits that can't be relicensed.
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...)
I don't think there's an if. Some people will have moved to other address, some employee addresses will be gone, some company domains won't exist anymore, some developer may not be alive anymore.
They choose to see that as implicit agreement. Hope they consulted with lawyers on that one.
Take a look at the code they've attributed to him. I don't think he's overly concerned, not about that anyway. The overreaching attempt at re-licencing others work on the other hand...
That's not going to fly if someone gets testy. Perhaps they should have talked to a project that's done it before like the Squeak folks. They really had to know how the OpenBSD contributors would react to the Apache license.
Squeak guy here - I did a lot of prodding around the relicensing and it was pretty much the same situation. An old code base and a license that was "open source" at heart but had problematic language. It's impossible to reach everybody - Squeak has code going back to 1978 I think :-). We got the thumbs up from the main contributors (Kay and friends - in fact, I think it was Alan who started pushing for this), we got the thumbs up from Apple (that took a while but they were very cooperative and nice), we decided that Disney didn't own any of the code (that was a big relief ;-)), and then when we didn't get any objections from major contributors we went ahead and hoped for the best. Law is not mathematics, it's a human endeavour and that makes the application of the rules, however precise they're written, often more messy than we techies are comfortable with. 90% of my encounters with legal stuff is "what are the trade-offs". Ditto here - you trade off the burden of having a shitty license against the vanishingly small risk that some contributor will want to retract its code and live with the decision - if you can show you did your due diligence the impact should be low.
If not everyone responds, or some people decline, then the code they contributed will have to be rewritten. It's a pain, but pretty much the only way to ensure all code is compliant. I assume there is some tool that combines a blame line with a licence.
I don't know if a rewrite for the sake of license compliance because of an actively litigating party has ever happened in OSS. In practice, we just don't know how far someone would go to prove ownership over individual characters in a source file.
"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.)"
I have no doubt that there are projects that have rewritten code because of the hypothetical threat of imagined future legal action, but I don't actually know of real legal action that has happened because of a relicensing, and the pressing question is what sort of form that copyright claim would take (which we won't know without a dedicated prosecutor, but can probably guess at).
Presumably this depends on how many don't respond (or respond in the negative) and the extent of their contributions. If the contributions are small and most people are for, it may be possible to rewrite some code. They may also find that a lot of the contributors' code has since been deleted, and therefore that they do not need their permission. It will be interesting to see, to be sure.
I don't think that'd be as easy as you'd think. They would need brand new contributors to make those changes. There'd be no way to prove that existing contributors hadn't been tainted by reading the source under the previous license - especially problematic if they've contributed changes to any affected source files.
Is there a legal source (i.e., not a hacker-folklore source) for the claim that a "clean room" reimplementation needs to be from someone who is not mentally contaminated by awareness of the old implementation?
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.
> Is there a legal source (i.e., not a hacker-folklore source) for the claim that a "clean room" reimplementation needs to be from someone who is not mentally contaminated by awareness of the old implementation?
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.
The "no mental contamination" thing, including nature of interaction, "cooldown" periods etc, is how this was described to me by lawyers in two of the companies I worked at. So they at least took it seriously, but I don't know about the source they were basing their guidelines on.
IANAL, so I can't give you an educated response here. Not being a lawyer, I tend to act with an abundance of caution in these areas.
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).
Right, but that's an idea or a design or an architecture (the realm of, if anything, patents), not a creative presentation (the realm of copyright). And the fact that I can go work for a competitor for my current employer and not have to worry about copyrights, just about NDAs and non-competes, makes me think that the copyright worry about clean-room reimplementation is bogus.
