Egregoros

Signal feed

Timeline

Post

Remote status

Context

8
I agree that by integrating slop into GPLed codebases, there are risks of adding code that could be derivative of GPL-incompatible code, and that would spell trouble to that who integrated it and to everyone downstream.

I expect that, if it happens, we (Linux-libre) would be in a position of unintended infringement, we wouldn't be hit first, and as soon as Linux puts its act together, we'd inherit the fix.

if third parties go about notifying us and terminating our licenses over infringement of the integrated bits, they will apply to those bits, not to the fixed upstream version.

if Linux copyright holders go about notifying and terminating licenses over the unauthorized combination with GPL-incompatible code, we'd get the grace period that the Linux community imported from GPLv3 to inherit the fixed codebase, so we should be fine.

overall it doesn't strike me as intolerable legal risk

it sucks to carry slop though, but as sally said, our goal is to make minimal changes to Linux to get an FSDG-compliant kernel. if it brings slop in it, it would only be of concern if that turned out to be nonfree (no license or incompatible license) or otherwise FSDG-incompliant. the former case would likely be handled upstream before we even knew about it. the latter would be up to ourselves, but it's hard to even imagine something like that coming up from slop.

CC: @sally@freesoftwareextremist.com
@lxo @lispi314

> it sucks to carry slop though, but as sally said, our goal is to make minimal changes to Linux to get an FSDG-compliant kernel

Yeah, I guessed it'd be this approach because that's also the same treatment Rust codebase gets even though can't be bootstrapped and every relevant compiler is proprietary, and the Rust issue is far worse and more concerning than garbage printer code snippets.

Replies

3