Removing code doesn't really solve the problem

Posted Aug 29, 2017 21:23 UTC (Tue) by bangert (subscriber, #28342)
In reply to: Removing code doesn't really solve the problem by Wol
Parent article: Patrick McHardy and copyright profiteering (Opensource.com)

a single player could probably not pull this off, but if a group of big users/contributors of linux (ie. google, facebook, red hat et. al) collectively said, they will not accept changes to the linux kernel which are not more permissive than GPLv2 (say MIT, BSD 2 clause or Apache) this could effectively lead to a fork of the kernel.

Removing code doesn't really solve the problem

Posted Aug 29, 2017 21:54 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (4 responses)

Producing a patch that's derived from Linux but released under a more liberal license would be a violation of the GPL, so this isn't a meaningful option.

Removing code doesn't really solve the problem

Posted Aug 29, 2017 22:27 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

GPL requires for the whole derived work to be distributed under the terms no more restrictive than GPL.

But it's perfectly fine to have patch _themselves_ to be under BSD/MIT. They'll be useless without the GPL-ed code, of course.

Removing code doesn't really solve the problem

Posted Aug 29, 2017 22:36 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

> GPL requires for the whole derived work to be distributed under the terms no more restrictive than GPL.

No, specifically under the terms of the GPL - you can't be more restrictive *or* more liberal.

> But it's perfectly fine to have patch _themselves_ to be under BSD/MIT.

I think that's only the case if there's an argument that the patch itself isn't a derived work of the kernel.

Removing code doesn't really solve the problem

Posted Aug 29, 2017 22:54 UTC (Tue) by ewan (guest, #5533) [Link] (1 responses)

The licence requires derived works to be GPLed - you're assuming that only the combination of patch + kernel is a derived work, and that the patch is not. Matthew's point is that it's virtually impossible to generate a patch that is not itself already a derived work of the kernel, so that's not the case.

This is akin to the arguments around the nVidia binary, and the ZFS and OpenAFS filesystems - they've all been able to show core code that had a pre-Linux history, and so was demonstrably not a derivative of Linux, but while that might be possible for leaf drivers, it's going to be rather harder to generate any patch to (say) the scheduler, or memory management or indeed the networking core code, that's not based on the current state of that code.

Removing code doesn't really solve the problem

Posted Sep 10, 2017 8:19 UTC (Sun) by Garak (guest, #99377) [Link]

The licence requires derived works to be GPLed - you're assuming that only the combination of patch + kernel is a derived work, and that the patch is not. Matthew's point is that it's virtually impossible to generate a patch that is not itself already a derived work of the kernel, so that's not the case.

I'm skeptical of that. I wonder if I wanted to try and sell 'patches' to Stephen King novels whether or not I could find a way to do it legally where Stephen King would have no legal ability from his copyright to stop me. Suppose in my contextless patches I had a convention of reversing, pig-latinizing or rot13ing character and place names and whatever else. I kind of feel like I could or should be able to legally do that regardless of what King would prefer. Obviously King doesn't have exclusive copyright over the word 'the', though perhaps for character names. The point I'd highlight is that for any customer to be able to read the modified story, would require that they first do business with King on his terms, then choose to do so with me, and then apply the patch themselves. In such a situation I struggle to see the ethical or legal harm I would be doing to anyone.