Comment by derefr | Hacker News Reader

Comment by derefr | Hacker News Reader

Parent Full thread

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…

> I would have thought […]

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

Behold the full set of licenses and copyright notices that apply to the Linux kernel, scanned with FOSSology[1] and ScanCode[2], and curated by licensing professionals: https://raw.githubusercontent.com/Open-Source-Compliance/pac...

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.

[1] https://www.fossology.org/

[2] https://github.com/aboutcode-org/scancode-toolkit

No, you don't get to change the license on someone else's code just because you import it into your project.

Each file has their own license, and they are on the same repo.

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.

> Traditionally, sharing an address space carried the GPL taint.

Clearly two different files don't share the same address space. So no problem.

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.

Reply on news.ycombinator.com