
OpenSSL Licensing Update - JoshTriplett
https://www.openssl.org/blog/blog/2017/03/20/license/
======
JoshTriplett
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.

~~~
kibwen
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.

~~~
KenoFischer
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.

~~~
kibwen
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.

~~~
int_19h
> AFAICT, ASLv2 is superior to BSD/MIT in all practical respects except for
> the GPLv2 compatibility

Not for the companies. Many prefer MIT over ASL precisely because they don't
want any sort of patent grants.

~~~
riffraff
Why do they prefer to avoid patent grants? It seems unreasonable to me.

~~~
yarrel
It is, but it's what they want.

------
Animats
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.

[1] [https://github.com/ctz/rustls](https://github.com/ctz/rustls)

~~~
nopcode
Is rustls actually a replacement though? I can compile existing applications
with rustls in stead of OpenSSL without altering the code of those
applications?

~~~
kazagistar
Hopefully not, as one of the major problems with OpenSSL is its convoluted
surface API which is easy to misconfigure.

~~~
paulddraper
Yeah...OpenSSL's difficulties cannot be _really_ fixed unless the the API is
allowed to change.

It's a hard slog either way.

------
hedora
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)

~~~
hsivonen
Bad faith is giving someone else seemingly open code that does something you
hold a patent to and then enforcing the patent agsinst the recipient.

The explicit patent language in Apache License 2.0 is a good thing.

~~~
snovv_crash
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.

------
DannyBee
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?

~~~
4a6f656c
The email being sent out clearly states:

"If we do not hear from you, we will assume that you have no objection."

~~~
ckastner
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.

~~~
jwilk
The process raises my eyebrows, too, but apparently that's how it was done for
other projects:

* [https://mailman.videolan.org/pipermail/vlc-commits/2011-Nove...](https://mailman.videolan.org/pipermail/vlc-commits/2011-November/010353.html) (grep for "It is possible")

* [https://dolphin-emu.org/blog/2015/05/25/relicensing-dolphin/...](https://dolphin-emu.org/blog/2015/05/25/relicensing-dolphin/#a-legal-gray-area)

* [https://blogs.fsfe.org/ciaran/?p=58](https://blogs.fsfe.org/ciaran/?p=58) (grep for "it is not necessary")

~~~
ckastner
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.

------
tyingq
I didn't understand the issue with the original license well, but found
Wikipedia's overview:
[https://en.m.wikipedia.org/wiki/OpenSSL#Licensing](https://en.m.wikipedia.org/wiki/OpenSSL#Licensing)

------
kstoneman
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.

~~~
eriknstr
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.

~~~
kstoneman
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?

~~~
kibwen
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.

~~~
gizmo686
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.

------
Daviey
Finally! This should mean Debian & Ubuntu can enable SSL in Squid!

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.

------
starseeker
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...)

------
jasonkostempski
What happens if not everyone responds to the emails?

~~~
shaggyfrog
The OpenBSD team is asking that very same question:
[https://marc.info/?l=openbsd-
tech&m=149028593819547&w=2](https://marc.info/?l=openbsd-
tech&m=149028593819547&w=2)

~~~
amenghra
Now I can respond on his behalf...

~~~
notaplumber
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...

~~~
amenghra

      > +  *) Removed old DES API.
      > +     [Rich Salz]
    

I'm confused. Taking credit for other people's work?

