Red Hat and the GPL [LWN.net]

Red Hat and the GPL

Posted Mar 9, 2011 6:36 UTC (Wed) by butlerm (subscriber, #13312)
In reply to: Red Hat and the GPL by gmaxwell
Parent article: Red Hat and the GPL

As the whole the kernel developers don't seem to care to enforce the license in the case of fairly overt violations, like extensions to the kernel with proprietary binary blobs

I am afraid I don't understand why pointing out that GPL-style licenses are generally unenforceable (i.e. gratuitous) in this regard is a strawman. Suppose a vendor took things one step further and distributed a device with dynamically loaded proprietary drivers. GPLv2 and GPLv3 are both vague enough that a legal action against that would probably fail as well, and there doesn't appear to be anything that could be done to fix the problem without destroying the utility of the license in the first place.

If, for example, the FSF really wanted to fix the problem in GPLv4, they could add language like: "conveyance of this code on the same media or on the same physical device with code licensed under any license incompatible with this one is not allowed under the terms of this license".

The needle the the FSF is trying to thread with both licenses involves much too general (and thus easily circumvented) descriptions of what they are trying to prohibit. "Intent" is not a stable property of a piece of software. Nor is "purpose", nor "extension". "Compatible" might be, but then the license starts to look useless again.

(Log in to post comments)

You mean routers?

Posted Mar 9, 2011 9:00 UTC (Wed) by khim (subscriber, #9252) [Link]

Suppose a vendor took things one step further and distributed a device with dynamically loaded proprietary drivers.

You mean routers? Yes, they are distributed in such form. And most (if not all) are pushing limits if not outright violationg GPL.

GPLv2 and GPLv3 are both vague enough that a legal action against that would probably fail as well, and there doesn't appear to be anything that could be done to fix the problem without destroying the utility of the license in the first place.

Where are exactly they are "vague enough"? GPLv2, in particular, quite explicitly claims that you can only distribute non-GPLed programs on the same medium if it's "mere aggregation". Router has three parts: GPLed kernel, binary blob of a WiFi driver and the rest. Remove any single one - and you don't have a router anymore, you have a brick (or semi-brick if wired Ethernet is handled by open-source driver). To claim that WiFi driver and GPLed kernel are "mere aggregation" in this case you must do a lot of squinting.

You mean routers?

Posted Mar 9, 2011 20:22 UTC (Wed) by sepreece (subscriber, #19270) [Link]

"Mere aggregation" isn't about whether the separate pieces are all needed to make the product work, it's about whether the pieces are all piece of one program. At least in some situations there's an argument that the binary blob is not part of the program, it's just a piece of data that the program installs in another device. [IANAL and I haven't read any cases that get close to this question.]

You mean routers?

Posted Mar 10, 2011 1:14 UTC (Thu) by butlerm (subscriber, #13312) [Link]

To claim that WiFi driver and GPLed kernel are "mere aggregation" in this case you must do a lot of squinting.

The problem is that the "one program" here isn't actually constructed (at best) until the router boots up, and then only in ram. So you have a proprietary driver that implements some sort of API - it doesn't even have to be the Linux API, but even if it was there is nothing stopping someone else from implementing a compatible API support.

So you look at this driver, on the same flash filesystem or whatever, and there is no reliable way to determine whether it is part of a "mere aggregation" or not, because there is no reliable definition of "mere aggregation" that includes other proprietary software in the device while excluding something that just happens to implement a compatible API. That means, as I said, that the only reliable way to do this is to make the license prohibit all joint distribution of GPL and proprietary software on the same media or on the same device, period. If the FSF is not willing to be so purist as that, it is hard to see how they are going to be successful grasping at metaphysical straws trying to decide what proprietary software can be included in a device and what can't.