Talking to McHardy & misplaced blame for his actions [LWN.net]

Talking to McHardy & misplaced blame for his actions

Posted Aug 25, 2017 21:32 UTC (Fri) by pboddie (guest, #50784)
In reply to: Talking to McHardy & misplaced blame for his actions by ms-tg
Parent article: Patrick McHardy and copyright profiteering (Opensource.com)

You'd think that if the Linux Foundation were so upset about it, they'd even pay for it.

to post comments

Talking to McHardy & misplaced blame for his actions

Posted Aug 25, 2017 22:04 UTC (Fri) by corbet (editor, #1) [Link] (13 responses)

I have been in various settings where such ideas have been discussed. Ripping and replacing is definitely on people's radar. I don't know of any effort to actually do it at this point, though.

Removing code doesn't really solve the problem

Posted Aug 25, 2017 22:48 UTC (Fri) by bkuhn (subscriber, #58642) [Link] (12 responses)

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.

But, removing code is actually not as useful as it looks, particularly given the business model that McHardy is chasing. The main strategy that McHardy appears to be using is to focus on companies who are small system integrators who don't do their own engineering of the actual operating system in their products. I've done plenty of GPL enforcement in that kind of situation, and these companies are usually just confused and need education to get into compliance (usually by picking a reputable, instead of a fly-by-night, upstream vendor). Conservancy does that education work in those scenarios, and helps the violator comply.

McHardy, by contrast, just asks for a cash settlement plus an agreement to pay more money if they can't figure out how to come into compliance in a few months on their own. Then, he cashes in on that clause when the confused company, having received no education, can't get into compliance in the time allotted. (I've been leaked a few of McHardy's settlement agreements, and they've been structured as I describe.)

So, how does this relate to writing his code out of Linux? Well, most of these types of companies use very old versions of Linux. I still see Linux 2.6 active, in the wild, in products, on the shelves today. Yes, they're low-end products from companies we've all never heard of (or that we all avoid because they are known to have sub-par products). But there are hundreds, perhaps thousands, of these kinds of embedded Linux manufacturers. It'll be at least a decade before they're all using versions of Linux being released today, so writing people's copyrights out with the goal of preventing GPL enforcement is just not very effective. (And with a ten year lag, it's not even a long-term solution. After all, no one had any thought that Patrick would decide to do this when he started contributing.)

The obvious solution to me is that we need lots of no-cost, freely licensed educational materials out there to help people understand how to comply with copyleft. That's why I work on The Copyleft Guide, and I have an open door policy that anyone who asks me about compliance questions, I try my best to answer them and/or improve the Guide to answer their questions. I wish more people would help me with this, but a lot of people with the expertise to help in this way have built a business around it, so they charge huge fees for training courses and/or consulting. That's why we see so many compliance tutorial products that are non-Free (in both senses of the word).

Removing code doesn't really solve the problem

Posted Aug 26, 2017 0:57 UTC (Sat) by perlwolf (guest, #46060) [Link] (1 responses)

While the ten year gap is a serious problem, writing McHardy out of the kernel would still be a useful step. It would be useful in court (with a well-researched lawyer) to limit damages by showing that the code that gives him standing is extremely low value (in fact, part of writing that code out of the kernel could be to document how little effort was required to remove it), and that the owners of the vast majority of the code have diagnosed McHardy as a far more serious issue that the defendants. "Defendant is found guilty, damages are determined to be one Euro, no award of legal costs!" would be wonderful verdict and a strong disincentive to McHardy to continue.

Removing code doesn't really solve the problem

Posted Aug 26, 2017 1:22 UTC (Sat) by bkuhn (subscriber, #58642) [Link]

The additional issue is that some execs and lawyers are overreacting to McHardy. Raising awareness about his inappropriate activities have already slowed him down. At this point, multiple people are out there ready to help anyone who is approached by McHardy to come into compliance. Conservancy, for example, would be glad to help anyone who comes to us and wants to comply with GPL.

What I've observed is the McHardy fear being blown out of proportion to disparage all GPL enforcement in general. There is no need to marshal extensive resources for the minor problem McHardy creates. That's why I support instead marshaling resources for freely available Copyleft compliance education materials, which will help not only the McHardy situation, but generally help everyone improve compliance so anyone who imitates McHardy will fail at the start. And, people who want to do enforcement the right way can and should do so; we published the Principles to guide such enforcement. More enforcement done properly will drown out the rare outlier.

Removing code doesn't really solve the problem

Posted Aug 28, 2017 9:21 UTC (Mon) by bangert (subscriber, #28342) [Link] (9 responses)

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.

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.