| |||||||||||||
Red Hat and the GPLRed Hat and the GPLPosted Mar 9, 2011 5:13 UTC (Wed) by butlerm (subscriber, #13312)In reply to: Red Hat and the GPL by gmaxwell Parent article: Red Hat and the GPL like extensions to the kernel with proprietary binary blobs Unless the distributors of said binary blobs are jointly distributing them with the kernel itself, the chances of enforcement on the grounds of creating a derived work are slim to none. The idea that most such modules are derived works is wishful thinking. I keep waiting to hear a theory that would pass muster under US copyright law. All the ones I know of have strong precedents against them, in addition to being about the most counterproductive public policy imaginable.
(Log in to post comments)
Red Hat and the GPL Posted Mar 9, 2011 5:27 UTC (Wed) by gmaxwell (subscriber, #30048) [Link]
I keep waiting to see you point out where I claimed desktop vendor shipped proprietary video drivers distributed by video card manufacturers were the only or the most interesting issue. :) You can have you strawman back, I've got plenty of my own, thanks.
Red Hat and the GPL Posted Mar 9, 2011 6:36 UTC (Wed) by butlerm (subscriber, #13312) [Link] 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 blobsI 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.
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.
|
|||||||||||||