Live data from Hacker News

OpenSSL 3.0

wiki.openssl.org

101–106 of 106 posts

Re: OpenSSL 3.0

#101
post #100

Earlier quoted context omitted.

That isn't semver

What do you mean? According to https://semver.org/ : > Given a version number MAJOR.MINOR.PATCH, increment the: > MAJOR version when you make incompatible API changes, > MINOR version when you add functionality in a backwards compatible manner, and > PATCH version when you make backwards compatible bug fixes. > Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH f…

SemVer is a spec. In the same way that people for some reason think that Terraform is SemVer just because it LOOKS like it even though nothing actually claims that they are using SemVer https://github.com/hashicorp/terraform/issues/15839

The only thing that OpenSSL claims to enforce about their versioning policy is

> A change in the second (MINOR) number indicates that new features may have been added. OpenSSL versions with the same major number are API and ABI compatible. If the major number changes then API and ABI compatibility is not guaranteed.

Re: OpenSSL 3.0

#102
post #28
post #24

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…

(This is not legal advice, but I do deal with software licenses professionally.)

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

This is not the case. A dual license allows you to redistribute under one or the other license, or both. "GPLv2 or later" must necessarily allow distributing under GPLv2 or GPLv3, because otherwise it wouldn't be compatible with GPLv2 or GPLv3. You're also free to combine it with GPLv2-only code (in which case you must distribute under GPLv2-only), or GPLv3-or-later code (in which case you must distribute under GPLv3-or-later).

> The FSF requires copyright attribution from cotributors, that’s why they were able to switch their projects to GPLv3-only.

The FSF requires copyright assignment, but that's not why; any project under GPLv2-or-later may be changed to GPLv3-or-later. And new code would then be contributed under GPLv3-or-later.

Also, the FSF doesn't like to use "GPLv3 only", for the same reason they don't like to use "GPLv2 only". FSF projects under GPLv2-or-later switched to GPLv3-or-later.

Re: OpenSSL 3.0

#103
post #64

Earlier quoted context omitted.

The standard wording for a GPLv2-or-later license (as recommended by the appendix of GPLv2 itself) is: > This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. Per that notice, I have an option of distributing it under the terms of GPL…

The license is allowing you to perform specific actions . You can modify the work or redistribute it under the terms of "GPLv2 or later" without losing any of the rights the original copyright holder(s) passed on to you. For a "modify and/or redistribute" example, under this "GPLv2 or later" licensing you can modify the software and use it in a SaaS without having to distribute it (which the GPLv3 would force you to)…

> For a "modify and/or redistribute" example, under this "GPLv2 or later" licensing you can modify the software and use it in a SaaS without having to distribute it (which the GPLv3 would force you to), because you can choose to follow the terms of the GPLv2.

GPLv3 says absolutely nothing about SaaS. You're thinking of the AGPLv3. The only thing GPLv3 does in that regard is declare itself compatible with the AGPLv3, so you can combine code under those licenses.

Re: OpenSSL 3.0

#104
post #63

Earlier quoted context omitted.

Dumb question here, isn't a license already a contract in the first place?

Not a dumb question at all -- that's actually fairly controversial. Many licenses are offered as part of a contract. But in _most_ jurisdictions (albeit not the one I'm standing in, which is Scotland) in order to have a contract one must have both a meeting of the minds and consideration. Many Free licenses don't have either. So they rely on copyright law: you don't have to agree to the license terms. If all you're d…

How do shops work in those jurisdictions? Don't they usually rely on an ‘offer’ that is semi-implicitly accepted by a client? And which is afaik a form of contract? I thought that this is the mechanism that licenses use.

This seems to be the thing in English: https://en.wikipedia.org/wiki/Offer_and_acceptance

Re: OpenSSL 3.0

#105
post #45
post #40

I don't have much familiarity with OpenSSL and crypto scares me away from reading the sources. I wish someone could give a full run-down of everything that is in OpenSSL, an overview. You hear all the time about it being bloated and supporting too many things. I wish I better understood that. It's why people turn to wolfssl and mbedtls, right? Smaller projects that aim for minimalism and robustness probably suffer fr…

The documentation already has an overview: https://www.openssl.org/docs/manmaster/man7/

That goes a long way, thank you :-) One of the other comments was saying OpenSSL probably has the best support for secure elements (hardware accelerated crypto?).

Re: OpenSSL 3.0

#106
post #44
post #40

I don't have much familiarity with OpenSSL and crypto scares me away from reading the sources. I wish someone could give a full run-down of everything that is in OpenSSL, an overview. You hear all the time about it being bloated and supporting too many things. I wish I better understood that. It's why people turn to wolfssl and mbedtls, right? Smaller projects that aim for minimalism and robustness probably suffer fr…

> It's why people turn to wolfssl and mbedtls, right? I tried to use a single algorithm from OpenSSL for an embedded project and seems like it needs hacking for all the dependencies to be met. I gave up. With mbedTLS it was done within a minute (simpler to build and read IMO). There aren't many differences between mbedTLS and WolfSSL. Both are small libraries designed for embedded use. The latter supports TLS 1.3. To…

I had not considered that it may have support for hardware accelerated crypto.
Post reply on HN