so the move to apache2 appears to be an overall loosening of
restrictions, not making things worse (the older license was
incompatible with even GPLv3 also, yuck). So it's an improvement over
the current state of play, no?
That said, I also would have liked something that is GPLv2-compatible in
addition to GPLv3-compatible.
Yes I believe any GPLv2 users have been relying on a license exception. I'm
not sure the license exception in the GPL software I'm using would be
sufficient if calls to OpenSSL are made from the GPL'd code:
"As a special exception, if other files instantiate templates or use macros or
inline functions from this file, or you compile this file and link it with
other works to produce a work based on this file, this file does not by itself
cause the resulting work to be covered by the GNU General Public License.[...]"
If my own (non-GPL) code calls OpenSSL, that seems fine. But what if I have
modified the GPL'd (with exception) code to call OpenSSL?
> That said, I also would have liked something that is GPLv2-compatible in
> addition to GPLv3-compatible.
Re: [openssl-announce] OpenSSL Versioning and License
This was discussed around when OpenSSL first talked about the project. You might find it worth reading the various blog entries (and comment/responses) https://www.openssl.org/blog/blog/categories/license/ One thing to note is that cryptography can be a patent minefield, and the patent protections in the Apache license were important to the project at the time we decided which license to move to.
Not everyone will be happy, and we knew that at the time. Overall, however, we felt that this was the best way to go.
> On 28/11/18 21:41, Daniel Kahn Gillmor wrote:
>> On Wed 2018-11-28 19:54:34 +0000, Jonathan Larmour wrote:
>>> On 28/11/18 17:02, Matt Caswell wrote:
>>>> Please see the following blog post about OpenSSL Versioning and License:
>>>> https://www.openssl.org/blog/blog/2018/11/28/version/ >>> :-(
>>> The Apache license is incompatible with GPLv2:
>>> https://www.apache.org/licenses/GPL-compatibility.html >>>
>>> Those of us using GPLv2 code in products will no longer be able to use
>>> OpenSSL. For many of us, GPLv3 is not an option.
>> The existing OpenSSL license is arguably incompatible with GPLv2 anyway,
>> in some analyses:
>> https://people.gnome.org/~markmc/openssl-and-the-gpl.html > Yes I believe any GPLv2 users have been relying on a license exception. I'm
> not sure the license exception in the GPL software I'm using would be
> sufficient if calls to OpenSSL are made from the GPL'd code:
> "As a special exception, if other files instantiate templates or use macros or
> inline functions from this file, or you compile this file and link it with
> other works to produce a work based on this file, this file does not by itself
> cause the resulting work to be covered by the GNU General Public License.[...]"
> If my own (non-GPL) code calls OpenSSL, that seems fine. But what if I have
> modified the GPL'd (with exception) code to call OpenSSL?
That's not the exception used for OpenSSL using software, that looks
more like the exception used when some software that should have been
LGPL was annoyingly marked as GPL instead.
The OpenSSL exceptions exist in very specific software packages and mention
"OpenSSL" or "The OpenSSL license" by name. The problem (besides such an
exception only applying if all the used GPL code has it) is that such an
exception, depending on its wording, might not apply to an Apache-licensed
OpenSSL, and it may be very hard to track down every GPL copyright holder
and get them to sign off on a reworded exception that doesn't extend to
other large Apache-licensed code bases.
Another exception sometimes used is the "OS exception" (in the text of
itself) applies only to an OS-bundled copy of OpenSSL, and only if the
code is not bundled with the OS. For example if using the specific
OpenSSL distributed by Debian and RedHat, a GPLv2 program not packaged by
those systems can use that specific version of OpenSSL.
>> That said, I also would have liked something that is GPLv2-compatible in
>> addition to GPLv3-compatible.
> Yes, that would have made things unambiguous.
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded