31–40 of 106 posts
Earlier quoted context omitted.
“Deprecated” need not mean “insecure”.
Are you willing to take the risk? Deprecated might mean: There are known weaknesses. Or: Less reviewed code path.
Earlier quoted context omitted.
Doesn't "GPLv2 or later" specifically allow you to fork into "GPLv2 only"? How can a license be incompatible with only the latter then?
IANAL, but “GPLv2 or later” allows you (the recipient of the license) to choose either GPLv2 or GPLv3 (i.e. the one that’s more convenient to you) but does not allow you to prevent others (the recipients of your modified version) from having the same choice. This goes both ways, “GPLv2 or later” cannot be changed to either GPLv2 or GPLv3 only without permission from everybody that has ever contributed to the codebase…
What? Of course it can be changed to either. It literally says so in the license name.
Earlier quoted context omitted.
The openbsd people behind libressl hate the apache 2.0 license, so they won't be able to copy such code from the openssl project any longer. I'm sure they're happy they have a TLS library with a license they like (new contributions are licensed under the openbsd license) and they can continue developing. As for gnutls, apache 2.0 license is still incompatible with (L)GPL 2.x, so projects under those licenses without…
Why do they hate APL?
The original Apache license was similar to the Berkeley license, but source code published under version 2 of the Apache license is subject to additional restrictions and cannot be included into OpenBSD. In particular, if you use code under the Apache 2 license, some of your rights will terminate if you claim in court that the code violates a patent.
A license can only be considered fully permissive if it allows use by anyone for all the future without giving up any of their rights. If there are conditions that might terminate any rights in the future, or if you have to give up a right that you would otherwise have, even if exercising that right could reasonably be regarded as morally objectionable, the code is not free.
In addition, the clause about the patent license is problematic because a patent license cannot be granted under Copyright law, but only under contract law, which drags the whole license into the domain of contract law. But while Copyright law is somewhat standardized by international agreements, contract law differs wildly among jurisdictions. So what the license means in different jurisdictions may vary and is hard to predict.
I worry that this is going to break so many programs and scripts in the same way that the switch from Linux 2.6 did..
One of the major improvements here: this finalizes the license change to Apache 2.0, which makes OpenSSL finally GPL-compatible. That removes one of the major reasons people had to avoid it. (Specifically, OpenSSL is now compatible with anything licensed "GPLv3", "GPLv3 or later", or "GPLv2 or later". It's not compatible with "GPLv2 only", but that's a relatively small amount of software.) Other major improvements: T…
Doesn't "GPLv2 or later" specifically allow you to fork into "GPLv2 only"? How can a license be incompatible with only the latter then?
Your parent comment said no such thing. It says, that you need GPL v3 to be compatible with Apache 2. "Or later" clause on GPL 2-licensed project offers you a way to re-license the project under GPL v3.
On Linux if I go to system provided 1.2.x openssl version and try to build against that my code breaks with thousands of mysterious errors about undefined types (in openssl headers).
I mean Openssl solves a big problem but from engineering perspective the library is one giant problem. And I haven't even remarked on the horrible API design yet.
As important as openssl is for many projects I find the engineering quality of it to be lackluster. My project is still on an older version and I wanted to upgrade. I tried to build approximately 7 versions for windows using msvs 2017 and msvs 2019. None even build but fail with compiler errors or linker errors! On Linux if I go to system provided 1.2.x openssl version and try to build against that my code breaks wit…
On one hand, I absolutely hate a library which breaks its API (I think lack of stability in interfaces is one of the bigger bane of the software industry and causes numerous issues down the line).
But in the specific case with OpenSSL, the breakages are legitimate imho. Most of the breakages I have seen are to clean-up interfaces and have a clear boundary between OpenSSL internals and items controlled by third party apps.
Concretely, they are switching from an API which exposed the internal structures directly to a getter/setter pattern.
Example in from one of my project:
old:
ts_response->tst_info->serial
TS_TST_INFO_get_serial(TS_RESP_get_tst_info(ts_response))
As important as openssl is for many projects I find the engineering quality of it to be lackluster. My project is still on an older version and I wanted to upgrade. I tried to build approximately 7 versions for windows using msvs 2017 and msvs 2019. None even build but fail with compiler errors or linker errors! On Linux if I go to system provided 1.2.x openssl version and try to build against that my code breaks wit…
I've mixed opinions over the recent breakages I've witnessed in OpenSSL. On one hand, I absolutely hate a library which breaks its API (I think lack of stability in interfaces is one of the bigger bane of the software industry and causes numerous issues down the line). But in the specific case with OpenSSL, the breakages are legitimate imho. Most of the breakages I have seen are to clean-up interfaces and have a clea…
Smaller projects that aim for minimalism and robustness probably suffer from a lack of peer review with a more niche community backing them. Trade-offs trade-offs. I also wish I understood where they compete:
OpenSSL WolfSSL mbedtls