Removing code doesn't really solve the problem [LWN.net]

Removing code doesn't really solve the problem

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

corbet's right that people have talked about replacing code a lot, and not just regarding McHardy. Some have even proposed there should be a "litmus test" about enforcement views before accepting any contribution to Linux and refusing to permit code in canonical versions unless each contributor agrees not to enforce. It's a scary prospect to think about some sort of purity test on enforcement before merging contributions. That's just a form of CLA, so I do hope such a proposal will be DOA, but in the current political climate, that proposal is gaining fans in the for-profit companies that use Linux.

or you could require all small and/or new contributions to be more permissive than GPL. the possibility to include GPL licensed stuff into the kernel is only awarded after a substantial contribution - say 1000 patches and at least 10000 lines changed.

to post comments

Removing code doesn't really solve the problem

Posted Aug 28, 2017 13:23 UTC (Mon) by bkuhn (subscriber, #58642) [Link]

> you could require all small and/or new contributions to be more permissive than GPL. the
> possibility to include GPL licensed stuff into the kernel is only awarded after a substantial
> contribution

There are people who are proposing not permitting upstream code to be GPL'd, and some companies refuse to contribute under GPL, but I think refusing contributions of any size that aren't GPL'd is effectively disenfranchising contributors from their rights to chose the license of their contributions, as historically Linux contributors have been permitted to pick any GPLv2-compatible license.

Also, your system has logistical problems. If one contributor 10000 line changes, but at one line at a time, they would be required under your plan to contribute under non-copyleft virtually forever.

Removing code doesn't really solve the problem

Posted Aug 28, 2017 19:34 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (7 responses)

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