> It is also the opinion of the Alpine license review community that the OpenSSL 1.x license was already compatible with both GPLv2 and GPLv3 due to the system library exception: it is generally not possible to install an Alpine system without having an OpenSSL implementation, so it clearly qualifies as a system library.
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.)
OpenBSD won't have anything under copyleft licenses anyway. The OpenSSL license has never been an issue for BSDs; it has primarily been an issue for Linux distributions and other distributors of software under copyleft licenses.
AFAIR, OpenBSD has included the GPL-licensed gcc for a long time. They have a clear preference for more permissive license, but it would seem the GPL is not a problem as such, the OpenBSD developers just prefer more liberal alternatives where possible.
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.
I know. Last time I checked, gcc still was the default C compiler on architectures clang did not support, but it was a couple years ago, and they discontinued a few architectures since (vax, alpha, probably others?).
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.
I know, but they included it for a pretty long time, so I think distributing GPL code as part of a BSD project is kosher, legally speaking. (Same goes for FreeBSD, although they, too, replaced gcc with clang some time ago.)
Incorrect. You may distribute BSD-licensed code alongside GPL code, and you can release your modifications to a BSD-licensed work under the GPL, but there is no possibility of subsuming the BSD-licensed code in the GPL-licensed code. Any attempt to do so would constitute copyright infringement against the original authors.
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.
> 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 “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).
As far as I can tell, you're saying that if a piece of GPL software includes unchanged BSD code, anyone can download that unchanged BSD code from the repository for the GPL'd piece of software and use it under the BSD license.
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?
> This is not a situation that anyone is discussing.
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.
> it would not change the fact that the BSD-licensed component is BSD-licensed.
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.
> I am free to license the whole thing to anyone as GPL.
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.
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.
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.
> you just also have to offer the complete work to them under the GPL as well
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.
By "your work" I mean "everything you have authored".
- 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").
> OpenSSL developers appear to want to focus on developing new features rather than cleaning up the mess of regressions they have created with OpenSSL 3.
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.
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.
"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."
Ehh, it doesn't seem very hasty to me. The proposal is for Alpine 3.17 or 3.18, which are 1 and 1.5 years away respectively. That's plenty of time to consider the pros and cons, try it, and revert if it ends up being a poor choice.
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.
They ignored a crash bug for a month and a half. Nobody should have to explain to a security package maintainer that a crash bug is a priority. If I were running a distro I'd be advertising to my users that there is a problem too, so they would know that the distro is considering alternatives.
Thinking about ways you can contribute would be far more productive than fantasizing about what the best possible position to be in would be when criticizing the project. Judging from the issues and commit logs, the OpenSSL project looks very busy and I'd guess they'd gladly accept genuine help.
It's fun to try to keep track of the SSL implementations distributions use/allow over time.
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).
Kind of wish we'd move TLS into the kernel at this point. Centralize the developer attention on it, and acknowledge that if the kernel is going to provide TCP sockets, it should provide all the tooling needed to secure those sockets as well.
It's not a perfectly logical argument, but kernels get patched and upgraded more often then almost any other software.
Both FreeBSD (https://www.freebsd.org/cgi/man.cgi?query=ktls&sektion=4) and Linux (https://www.kernel.org/doc/html/latest/networking/tls.html) support kernel TLS. Though only for the bulk encryption. Stream initiation and certificate verification is too complex, with more regularly changing requirements and features. So most developers would still end up using an SSL library like OpenSSL to avoid having to directly use the more complex kernel interfaces and data processing dance on connection.
Defining a common syscall interface for stream initiation and cert verification, and then implementing the logic as a Linux kernel module would be a decent compromise I think.
This would probably work fairly well for desktop/server stuff, but I can only imagine the blast radius of this decision in Android devices with often limited at best OEM update support...
It seems like Alpine's attempt at upgrading to OpenSSL 3.0 caused them a fair bit of stress, only a bit of which was caused by applications still using ancient deprecated APIs.
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.
The last time I checked - maybe 3-4 months ago - the ktls implementation in openssl still seemed, um, somewhat fragile. Undocumented behaviour changes, missing error handling, ...
No, no dedicated hardware needed. kTLS is super beneficial if you're serving static content even when using software based kernel TLS. And it only gets better when using a NIC that can do inline HW kTLS (like the Mellanox CX6-DX).
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.
Oh, interesting. It's been quite a few years since I considered speed of static serving anything beyond an academic exercise (not helped by the fact that my "play" servers only have 1gbps uplink).
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?
If you buy a >=40Gbit/s NIC, chances are high it has an offloading engine suitable for kTLS.
Much of the benefit comes from saving memory bandwidth, AFAIK.
That's not really true. Most >= 100GbE NICs don't have offload engines. The only major >= 100GbE NICS that do are the Mellanox CX6-DX, and the Chelsio T6. There are some smaller market smart NICs that do, but the larger players like Intel and Broadcom do not offer kTLS acceleration on their >= 100GbE NICs.
This is, respectfully, horseshit. OpenSSL gained (deservedly) a reputation for insecurity around the time of Heartbleed, but its governance and maintenance changed radically in the years immediately following. I would trust OpenSSL more than I would trust LibreSSL at this point. Certainly, it's one of the most aggressively surveilled security codebases on the Internet.
Or … they could contribute to the OpenSSL project. Didn’t we find out a few years ago that the project was underfunded and d very few maintainers. Seems like they could benefit from help and licensing aside could have a better chance getting it working 100% with apk and alpine.
But it's The Holy Laptop of John The Analyst, tenderly preserved in a climate-controlled vault (i.e. near the office aircon unit) since 1996. Rumor has it that its coffee stains have achieved sentience, because it's not been cleaned since John was summarily fired for gross misconduct. Its battery has long been replaced with a mains cable going through a UPS unit bought secondhand on eBay (hey, it was the 90s). It is booted only once a year, on the third week of May, when the sun hits the window of the cubicle of Bob The Security Evangelist so hard, that he actually has to stand up and go to another room.
When I was a postdoc at Berkeley we wanted to release some open source code. I talked to the professor, who is a really smart guy. We discussed various licenses and I asked about GPL. He said he had read it and simply couldn't understand what it meant, legally speaking. He read the BSD (both types) license and it made perfect sense (same for Apache and MIT).
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.
He meant that after reading it, it was unclear that it was actually a legal license that would stand up in a court of law. It's just too confusingly written. See Nelson Minar's comment at the end of this: https://web.archive.org/web/20081015194558/http://radar.orei...
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"
> Someone's lawyers seem to understand it better than he did, company's seem eager to settle rather go to trial when they are found to be violating it.
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.
Well the reason I linked to the second article is because it talks about how more and more it looks like the GPL is solid and enforceable. So expense aside, as time rolls on and more cases come up it's pretty clear that defendants assume they'll lose if they are caught violating the license terms and try to fight it.
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.)