Consider LibreSSL as default OpenSSL provider again
gitlab.alpinelinux.org
gitlab.alpinelinux.org
The text of the system library exception in GPLv2:
> However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
Emphasis on unless that component itself accompanies the executable. There's a long history of discussions of this clause, and many of them make the point that this exception is designed to allow FOSS projects to distribute software for proprietary OSes (e.g. link to proprietary Windows or UNIX libraries), but not for the OS distributors themselves to be able to distribute FOSS code alongside their proprietary OS.
(Note that the GPLv3 broadened this exception, and no longer limits it on the basis of "unless that component itself accompanies the executable". So it's entirely possible that OpenSSL could be considered a system library for the purposes of GPLv3, while not being considered a system library for the purposes of GPLv2.)
1. If you distribute source code you need to retain the copyright notice, the license conditions, and the disclaimer
2. If you distribute binaries you must include those in the documentation
3. (sometimes) You can't use the contributors to promote your software (e.g. "Powered by the fantastic LibreSSL library!")
An example may be illustrative. If your GPL project uses a BSD-licensed single-header-file library, and you distribute that library's source with your source, downstream users are free to take that library from your source repository and use it for their own purposes without abiding by the GPL. Nor may you change the license and copyright notice in the header file in order to claim that the library is GPL, because if you do so you will be violating the conditions of the BSD license, leaving you with no right to use or distribute the software at all.
If I'm writing a program under GPL, and I want to incorporate a component with a BSD license, I can do that and continue to license the entire program to my users under the GPL.
If I'm writing a program under BSD, and I want to incorporate a component with a GPL license, I can't do that and continue to license the entire program to my users under the BSD. That's the difference, and surely that's what the OP is referring to.
Suppose someone comes along and finds my program, and wants to modify it and release it without providing the source. Before, when I could license the whole program as BSD, they could do that. After I incorporated a single file's worth of GPL code, they can't do that. Because it's no longer possible for me to license my program as BSD.
Also, note that there's absolutely no guarantee that users can "take that library from your source repository and use it for their own purposes without abiding by the GPL". I am under no obligation to provide a BSD-licensed copy of the original library. If I make modifications to the library before I push it to my repository, I do still have to keep the copyright notice intact, but I am not providing anyone with a BSD library. My modified version of it is only GPL.
This is not a situation that anyone is discussing.
What is being said is that I can take a piece of BSD code, modify it as I see fit, and relicense the assemblage as GPL (or as my personal property for that matter) as long as I include the BSD license and acknowledgements when I redistribute it. I cannot take a piece of GPL code, modify it as I see fit, and relicense it as BSD. If you disagree with this, explain why, but don't bring up some situation that is as vanishingly rare as to possibly have never happened. If you're desperate for a piece of BSD code, and the only place to get it is within the repo of a GPLed piece of software that includes it untouched, nobody is going to claim that code becomes GPLed from being distributed alongside GPLed software. But if I go through that code and add the prefix "GPLisbetter-" to every variable name, can you use it under BSD?
It's exactly the situation that was articulated. Or at least the most plausible version of what was said.
> What is being said is that I can take a piece of BSD code, modify it as I see fit, and relicense the assemblage as GPL
That is probably false. The BSD code itself cannot be relicensed, since nothing grants you that permission. Courts have not expanded the idea of compilation copyright to software linking, so far as I know, so that is an open question. However, even if the "whole assemblage" had a compilation copyright separate and apart from its independent components, it would not change the fact that the BSD-licensed component is BSD-licensed.
> if I go through that code and add the prefix "GPLisbetter-" to every variable name, can you use it under BSD?
Yes. We call this kind of thought process "jailhouse lawyering" and it is almost universally disastrous for the proponent. Courts readily see through arrogant people's attempts to outsmart their own common sense. CTRL+H will not provide you the magical ability to relicense a copyrighted work you do not own.
That's correct, as far as I know. But it completely misses the point. I'm not required under the BSD to provide anyone with access to the original, BSD licensed code. That's the whole reason people can distribute modified closed source BSD code as they see fit. If I modify a BSD licensed source file and include it in my program, I am free to license the whole thing to anyone as GPL. This does not "change" the licensing of the original component - but I am not providing the original component.
Of course, most of the interest is in going the other direction. If I include a GPL licensed source file in my program, the entire program becomes GPL even if I don't want it to be. Unless the recipient of the software painstakingly removes all GPL components, they must abide by the GPL's requirements for the whole of the software.
This is what you’re getting wrong. You can “distribute GPL software that includes BSD components” but this is a misstatement of what actually happens. You are distributing your own software as GPL code and at the same time distributing the BSD components. The license to those components (or their source code) does not change. You absolutely can’t blanket apply the GPL to the whole thing.
> This does not "change" the licensing of the original component - but I am not providing the original component.
You absolutely are. If I ship a book full of Sci Fi stories I wrote, and happen to include some classic Philip K Dick stories, I have absolutely included the original. The fact that I wrapped it in my own work changes nothing.
You can continue to offer your work to users under a BSD license, you just also have to offer the complete work to them under the GPL as well if they want - ie. your work can be "Dual BSD/GPL" license. Obviously this doesn't make other authors GPL bits you've used BSD - if someone wants to make use of rights reserved under copyright law in respect to those parts, they still need a valid license from the original author who is presumably only offering GPL.
The "as well" is where your comment introduces a slight inaccuracy, because it suggests that you could offer the whole work under BSD if you wanted to. You can not. The whole reason that people who prefer permissive licenses do not use GPL code is that they want to be able to license the whole work under a permissive license, in order to be able to provide their licensees with additional freedoms.
- The parts you've written can continue to be available under the permissive license (as can any parts you've copied from elsewhere under a permissive license);
- The GPL code you didn't write can't be re-licensed by you and continues to be available under the GPL;
- The complete derived work has to be made available by you under the terms of the GPL.
(By "as well" I mean "as well as offering the code you wrote under whatever other license you would like").
If “the entire program” includes the BSD component, then this is not correct. You cannot change the license for a work if you do not hold the copyright for that work. Your license applies only to the code you hold the copyright to.
I agree with torstenvl here. This is not a meaningless distinction. You can distribute BSD components with your GPL software but they retain their own license and you must abide by the license (hence all the attribution notes you’ll find in software that uses others’ components).
I'm not taking sides here, the OpenBSD developers have famously stopped supporting hardware when the vendors did not supply documentation under acceptable conditions. They obviously are very serious about the "Open" part.
They included gcc for convenience in some architectures.
I'm fairly confident that gcc is still available in the ports collection.
On architectures that clang doesn't support, it's (likely) still gcc.
Yes, gcc is still available through ports/packages, but the point was if it's okay to distribute GPL code as part of the base system if the base as a whole is BSD/MIT licensed.
There is so much truth contained in this one line... and it's been that way with every OpenSSL release.
Being funded by Red Hat comes with a price that users sometimes end up paying. LibreSSL has zero corporate involvement but remains in very active development, with arguably much better coding practices and a very consistent release schedule that follows OpenBSD. You won't find every new or obscure feature rushed into the codebase, but (perhaps as a result of that) I have a lot more confidence in it personally.
Most of the compatibility issues they had with LibreSSL before have been solved with the integration of the OpenSSL 1.1 API, which is in the newest stable version.
What funding are you referring to?
https://www.openssl.org/support/acks.html
Which links to a "thanks" page:
https://www.openssl.org/community/thanks.html
which says the following:
We'd like to thank the following individuals and organizations who contribute to the OpenSSL project. [...] The following organizations who contribute staff time to work on the project (alphabetically): Akamai, Cryptsoft, Google, Oracle, Red Hat, Siemens, and Softing.
kaniini, same as Ariadne Conill who posted the issue in the linked GitLab instance, opened a issue about a regression. They felt the response from the OpenSSL team wasn't as fast as expected, and created the text that this submission is linking to.
Seems expectations of a quick fix was never told about in the GitHub repository for OpenSSL, and instead the author chose to write on Twitter and in AlpineLinux GitLab about the frustrations.
I can't help but to see this as a personal reaction to these events, and unsure about the merit to change it out so hastily. But, I'm not super up-to-date about things in LibreSSL/OpenSSL land so I could be wrong, it has happened before.
I'll quote the section:
"Given that the OpenSSL 3 migration had an outcome where our contingency plan came into effect, I believe it to be the most prudent course of action to evaluate all possible options before committing to trying the OpenSSL 3 migration again, such an evaluation would be required by the TSC anyway."
The Alpine project operates independently from OpenSSL, so it's no surprise they published their own report to discuss their own timelines. I'm not sure I can attest to this being a "personal" reaction from my interpretation. Instead, this seems rather like the Alpine project's reaction to their own internal deadlines. Tossing out OpenSSL may appear flippant from a distance, but getting SSL correct for their own releases and finding projects that want to work alongside them (as LibreSSL is supposedly responsive towards doing) should be a priority if you're in charge of getting this work ticket over the line.
Of course, the wording and general attitude towards OpenSSL developers can be interpreted however you want, but I don't see this as outright hostility or a personal reaction so much as "this ticket was left for over a month, and our project needs to make forward progress."
> Seems like this stems from https://github.com/openssl/openssl/issues/16660 which contains the full backstory and some more information.
I wouldn't call that the "full backstory", since it is only about a single issue outlined in this proposal. Though she does explain that fact in that GitHub thread too, and also why they're looking into alternatives:
> Given that the OpenSSL 3 migration had an outcome where our contingency plan came into effect, I believe it to be the most prudent course of action to evaluate all possible options before committing to trying the OpenSSL 3 migration again, such an evaluation would be required by the TSC anyway.
> and instead the author chose to write on Twitter and in AlpineLinux GitLab about the frustrations.
Eh, I wouldn't read too much into short twitter vents. As for the Alpine Linux GitLab, well, she's the head of Alpine's security team and a member of the TSC, so coming up with proposals as for what should be investigated w.r.t. security critical packages is one of the things she's supposed to be doing.
Void, for example, started on OpenSSL, moved to LibreSSL, and then moved back [1].
Gentoo has always been OpenSSL by default, had serious motion towards enabling LibreSSL as a first class citizen, and then backed out of that effort [2].
And now Alpine is looking at their second switch from OpenSSL to LibreSSL.
I'm a little bit amazed this hasn't caused even more stress than it has for cases like building V8/Chromium; this back and forth stuff is going to get hard to keep track of (for application developers, at least).
[1] https://voidlinux.org/news/2021/02/OpenSSL.html [2] https://www.gentoo.org/support/news-items/2021-01-05-libress...
Distros seem to have shifted towards using bundled libraries for browsers. In this case, Chromium uses BoringSSL.
It's too much effort to diverge from the upstream browsers. Besides, security teams for browsers tend to be better staffed than for distros.
It's not a perfectly logical argument, but kernels get patched and upgraded more often then almost any other software.
The only ssl libs that I'm aware of that support kTLS are OpenSSL, and a hack I did to golang (modeled on https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-1...).
edit: Maybe the developers would be amenable to a patch, but it sounds like a substantial undertaking.
https://mailman.nginx.org/pipermail/nginx/2021-November/0611...
I'm happily using BoringSSL with nginx-quic but this might be enough for me to give quictls a brief look; I'm a sucker for seeing just how much perf I can squeeze out of a static file server without compromising too much on security, and this could be neat.
The only other TLS lib I know of with kTLS 1.3 support is wolfSSL.
For static content (videos, large images, etc) that live on disk, sendfile() will bring them into the kernel page cache, and then send them on to the network. This involves 2 memory accesses: DMA DISK->RAM, DMA RAM->NIC).
To serve that content with a userspace SSL library, you now have to copy the content to userspace, encrypt in userspace, and then copy the content back into the kernel. So you add copy KERN->USER, encrypt USER->USER, copy USER->KERN. So you now have essentially 3 more memory accesses.
By using ktls, you eliminate the KERN->USER and USER->KERN copies by encrypting KERN->KERN.
With SW ktls, we see something like a 2.5 to 3.x speedup for static content on the Netflix CDN.
For inline HW kTLS, you're back to the 2 memory access case, since inline HW kTLS NICs encrypt the TLS records as the traffic is sent on the wire. So it boils down to what's essentially the unencrypted case. That's another 2x speedup, roughly.
I suppose the other way to do it would be a user space network stack?
Ed: i know alpine is popular as (docker) container images - but that typically doesn't include the kernel. I suppose in theory a docker container might leverage kTLS via the host kernel (but not without library support..). How many run alpine on bare metal with 10gbe+ networking?
Instead, we chose to fund the known-bad project, as if just throwing money at a problem was going to solve it.
Now, we have hindsight. Perhaps it is not too late to switch?
OpenBSD (which maintain LibreSSL) have had my trust for a long time already.
As almost everybody else, I do rely on a lot of projects they maintain, and they have yet to disappoint me.
> For standard WPA networks which use pre-shared keys (PSK), keys are configured using the "wpakey" option. [1]
I think the article is saying that the new OpenSSL is the library that breaks, or makes it hard to use, MD4.
* Cameron snorts
After thinking for a while and seeing the battles and their outcomes I have concluded that GPL is in fact a liability, not a license.
Every IP lawyer I've talked to since has looked at GPL and said something pretty similar. "It's just too confusingly worded to understand as a defensible license"
https://en.wikipedia.org/wiki/BusyBox#GPL_lawsuits
https://www.pillsburylaw.com/images/content/1/6/v2/1655/A9A2...
It's often substantially cheaper to settle lawsuits than go to trial. This says more about our legal system and the American rule[0] than anything else.
[0] https://en.wikipedia.org/wiki/American_rule_(attorney's_fees)
But not a single example.
Rhetoric, huh.