Removing code doesn't really solve the problem

Posted Aug 28, 2017 19:34 UTC (Mon) by mjg59 (subscriber, #23239)
In reply to: Removing code doesn't really solve the problem by bangert
Parent article: Patrick McHardy and copyright profiteering (Opensource.com)

> or you could require all small and/or new contributions to be more permissive than GPL.

If something's a derivative work of the kernel (which most code contributed to the kernel is), releasing it under a more permissive license isn't an option.

Removing code doesn't really solve the problem

Posted Aug 29, 2017 6:00 UTC (Tue) by Wol (subscriber, #4433) [Link] (6 responses)

But releasing your changes *is* (not that I agree with that - the kernel is GPL2, and to insist that contributors can't use that same licence on their changes seems incredibly unFree to me).

At the end of the day, the licence the contributor wishes to use MUST be the contributor's choice, if it's to have any real meaning. If I contribute to a project, I accept that I'm expected to use the same licence, and to tell me I can't is weird. If I wish to use a compatible licence, that should be MY choice, not someone else's (that's why I think this move to force a large number of kernel interfaces "gpl only" is wrong - if the *author* and copyright owner has no desire or intention of enforcing gpl on their code, it devalues the gpl to force them to use it!).

Oh the joys of arguing about copyright and licencing ... :-(

Cheers,
Wol

Removing code doesn't really solve the problem

Posted Aug 29, 2017 21:23 UTC (Tue) by bangert (subscriber, #28342) [Link] (5 responses)

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.