Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

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

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.

View on HN

Didn't OpenBSD fork Apache 1.3 over this exact issue?

http://apache.org/foundation/license-faq.html#PatentScope

My understanding is that they did, which is why they had such an old version for such a long time.

They could also just ask the authors of individual patches to contribute them under LibreSSL's license too.

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.

If the patch is applicable to the LibreSSL codebase, then that implies it's only derived from the pre-fork code.

Let's say you have:

    OpenSSL:
      foo1():
        bar()

      foo2():
        bar()

    LibreSSL:
      foo1():
        bar()

Then someone realizes foo2 needs to call baz:

        foo2():
          bar()
     +    baz()

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.

> just removed the advertising clauses (and whatever else is GPL incompatible)

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.

> keeping GPL compatibility

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)

Reply on news.ycombinator.com