Huh; I would have thought that importing MIT code into a GPL codebase (like the Linux kernel) essentially “beats out” the original MIT-licensing and instead creates an GPL-licensed fork of said code; thus making such forked code ineligible for re-import into an MIT/BSD-licensed project like the OpenBSD kernel (unless that project wants to be infected by the component’s licensing and become GPL-licensed in turn.)
Are you saying instead that the DRM drivers in the Linux kernel (the in-tree parts, I mean, not the firmware blobs) exist as an island of MIT-licensed code inside the otherwise GPL-licensed codebase?
Or are these parts of the Linux kernel not even technically in-tree, but rather developed in a separate canonical repo and frequently synchronized into the kernel as a vendored dependency? That’s the only way I can see this working; but it’s unclear to me why this state of things would have been maintained for any length of time when the Linux kernel was the only consumer…
That‘s a common misunderstanding how licenses work on HN. Often even worse: "MIT allows relicensing" (no it doesn‘t, and sub-licensing is something different).
Yes, you need to supply all of those if you distribute the Linux kernel in binary form. No, most companies don‘t do that in practice. Yes, they are in breach of all those licenses. Yes, next kernel release there will be changes.
I‘ve long been procrastinating on writing a blog post about exactly that.
The GPL is (in)famously viral. You can't base something on a GPLed codebase and say that your thing isn't covered by the GPL. The GPL is specifically designed to forbid that specific thing.
You can take BSD-licensed code and package it into a GPL bundle, which is what the kernel is doing. You can also extract the BSD-licensed code without the GPL-licensed code and it will be fine.
It depends on how closely the code is coupled to the rest of the project. Traditionally, sharing an address space carried the GPL taint. There's nuance to it, of course, but the question was never really settled, and nowadays people just ignore licenses.
OpenBSD has a strict "no GPL" policy. It does not incorporate GPL code in the kernel, and it has slowly weeded out GPL code from userland. This is one reason why it builds with Clang instead of GCC.
If Linux DRM weren't licensed under more permissive terms, OpenBSD simply wouldn't permit its inclusion.
When you link GPL code with your proprietary code into a binary (shared address space), and distribute the binary to people, those people are entitled to your proprietary source code.
When I compile my GPL code with a copy of somebody else's MIT code into a binary (shared address space), other people's copy of that MIT code is still MIT licensed.
OpenBSD 7.9 was already on the 6.18.y longterm support version for the drm(4) drivers, Jonathan Gray (jsg@) completed the update back in March, sponsored by the OpenBSD Foundation.
Correct, those are the versions in the coming release.
For those not familiar with OpenBSD, it’s had an accelerated amdgpu driver since 2019, and inteldrm/radeondrm for a few years longer, generally kept up to date with Linux stable throughout that time.
With my OpenBSD developer hat on, getting new hardware in the hands of developers is really important, many of us are hacking on 5-10 year old thinkpads that need replacing.
Shamelessly, if I may add a personal plea, in addition to funding the open source projects you use, if you can, please do consider directly supporting individual contributors/developers personally who work on those projects, many are volunteers and even a small monthly contribution could mean the difference.
"Updated sandbox for privilege-separated pre-authorization sshd process" is listed as a modification to the open-source project, but I suspect this is out-of-date.
Are sandbox profiles (or how to use them) officially documented anywhere (as non-deprecated)?
They just got burned by the documented usage of sandbox_init() going away (which didn’t even get a mention in the release notes), I can understand why they’d be unexcited about moving to a different deprecated/undocumented API.
Who is "they" ? AFAIK the OpenSSH team focuses on the OpenBSD version and others people/teams use the new releases to create/update a portable version.
So I think it would be up to the team that ports it to Apple, so I think the "Apple Team" is the ones who would worry about sandboxing.
Mostly correct. The majority of work in both is currently done by Damien and myself, who work on both.
There are a couple of people who have done significant work on OpenBSD's ssh (eg Markus, Theo) and various OpenBSD folks who add a feature or fix a bug and move on.
There is one person who currently works exclusively on -Portable (Tim Rice, who is still around although not very active these days) and at least one other in the past (Andre Lucas, who wrote the multi-platform login recording code). You can see the current set here: https://github.com/openssh/openssh-portable/blob/master/.git...
OpenBSD developer Tobias Heider (tobhe@) has already committed the first pieces of OpenBSD/arm64 support for these Qualcomm Snapdragon X2 Elite laptops.
"This gets USB, keyboard and touchpad working in ACPI mode on the HP Elitebook X G2q."
> At that time, its researchers have modified Chromium to make use of Capsicum and compared how much effort was required to make use of each sandboxing mechanism within Chromium. [..] If you’re only going to study one sandboxing mechanism in your life, it should be Capsicum. To this date, I have yet to see a better sandboxing mechanism than Capsicum.
In the years since it was added, there's a reason you can count on two hands the number of programs using it in FreeBSD. Even less using it effectively, with refactoring, and not just calling cap_enter().
Capsicum Chrome has never been committed to the official FreeBSD ports tree, it was an academic research project from 17 years ago.
Compare that instead to OpenBSD, where the Chromium port has used pledge(2) since January 2016, and unveil(2) since 2018. Enabled by default. The Mozilla Firefox ports also use both pledge and unveil since 2018-2019, and this work has even been accepted upstream.
Anyway, IME capsicum vs pledge doesn't make much of a difference because seccomp already forces you into a specific sandbox architecture; after implementing that, adjusting the result to support the rest takes (relatively) little effort. So I think the difference in adoption is more because nobody has volunteered to do the work for capsicum (and keep it up to date etc.)
Desperately trying to attract new monthly sponsors and people willing to buy me the occasional pizza with my terrible HTML skills. Is it working?
If any individuals, companies (or bitcoin millionaires) would like to help a long-time OpenBSD slacker, unslack, I'd really like to focus more of my time on open source development (and advocacy), rather than making rent. Feel free to contact me.
Desperately trying to attract new monthly sponsors and people willing to buy me the occasional pizza with my terrible HTML skills. Is it working?
If any individuals, companies (or bitcoin millionaires) would like to help a long-time OpenBSD slacker, unslack, I'd really like to focus more of my time on open source development (and advocacy), rather than making rent. Feel free to contact me.
Thanks, but unfortunately I found nothing new there that's applicable in my case. Not looking for project grants or rigid commitment/goals based funding at this time.
https://github.com/openbsd/src/tree/master/sys/dev/pci/drm
reply