5 ms·
>Have the segregated their proprietary "stuff" (whatever that is/does) into separate kernel modules, and if so, would Hellwig's suit force them to publish it?
by davexunit 10y ago
>Have the segregated their proprietary "stuff" (whatever that is/does) into separate kernel modules, and if so, would Hellwig's suit force them to publish it?
This is the crux of the issue that is being disputed. There is no "segregation" in Linux. A kernel module is a derived work of the kernel, and thus users are entitled to receive the source code for the entire work under the GPL version 2. VMWare cannot add in proprietary features.
- hbex5 10y agoIt's not entirely clear with the GPLv2 that that's the case. The FSF claims that because modules are loading into the address space of the kernel that makes them an integrated part of a single program and not mere aggregation, and are therefore covered by the GPLv2's restrictions as a derivative work. It should be noted, however, that this is merely the FSF's opinion, and this has never been definitively legally established. The GPLv3 was designed to, inter alia, eliminate such ambiguities, but added so much complexity it never really caught on outside the GNU project.
- davexunit 10y ago>It's not entirely clear with the GPLv2 that that's the case. I hear this argument a lot. It is certainly intended to be the case as it's the whole point of the GPL. VMWare is, at the very least, in clear violation of the spirit of the GPL. If it's not the case, as ruled by German courts, then the GPLv2 is useless and free software will be in deep trouble. In the US the courts have found that GPLv2 is pretty clear on this (and judges don't like those that try to find loopholes) with successful compliance cases like the Linksys WRT54G router firmware. >this is merely the FSF's opinion It's a pretty important opinion since they wrote it and know what the intent of the legalese was.
- Tomte 10y agoAnd usually ambiguities are evaluated in favor of the party who did not write the text.
- cmurf 10y agoSomething seems specious where proof of authorship is required for standing in a case. The injured party may not be the copyright holder as much as it is the entire community or even other copyright holders.
- rhizome 10y agoNot authorship per se, but copyrights to source code was pretty much the entire linchpin of SCO v. IBM.[1] I think I remember SCO trying your argument at some point (as they were wont to do), and if so it obviously didn't work. The law generally doesn't support being offended on behalf of someone else. What aspect do you think is specious? 1. https://www.techdirt.com/articles/20070810/184153.shtml https://www.techdirt.com/articles/20070810/184153.shtml
- daxelrod 10y agoIf you wish to sue someone for copyright infringement, you usually need to hold the copyright in question to have standing. If you have been injured in some other way, you are welcome to try to sue for that instead.
- dragonwriter 10y ago> It's a pretty important opinion since they wrote it and know what the intent of the legalese was. The intent of a license is defined by the person offering the license, not the person writing the license that they choose to offer.
- nitrogen 10y agoThis interpretation could imply that any software running on a GPL OS that lacks memory protection would also be forced to be GPL. The GPL has exceptions for GPL programs using proprietary OS components, but does it have the reverse? It's easy enough to claim that a kernel module is more analogous to a program running on an OS than to a library linked into a program.
- prutschman 10y agoThe relevant part of the GPL applies only when a derivative work is created. The determination of what constitutes a derivative work is the domain of copyright law. If a piece of software is not legally a copy of or a derivative work of a GPL-covered work, the GPL simply doesn't apply.
- bluejekyll 10y ago> it never really caught on outside the GNU project Actually, I think GPLv3 did something even stranger, at least something I didn't expect. I've now seen numerous entities use the GPLv3 as a mechanism to deny Companies access to that software unless they purchase a copy that is under a proprietary license. This is because some company legal departments see the GPLv3 as inherently dangerous to use. So the "Open Source" entity uses the GPLv3 to get in the door, and then offers a proprietary license that the code is sold under as an alternative to the GPLv3 for corporate use. I'm still torn on if I like this model of dual-licensing or not. It definitely gives Open Source companies an ability to earn money from Corporations that want to keep their code closed.
- EdHominem 10y agoHow is that a GPLv3 issue? You think the companies would prefer v2? But anyways, how does that deny companies access any more than simply using a proprietary license in the first place? You're already denied access to 99.9% of code written because it isn't publicly licensed at all.
- bluejekyll 10y agoIts internal legal departments of large companies (and some medium sized ones). They tend to be most highly concerned with the patent provisions in GPLv3, and yes, GPLv2 is much more palatable, though I've often seen requirements that the code is not contributed to. The denial is not from the GPL it's from the corporate legal team. This is a big reason why the Apache 2.0 and MIT licenses are much more popular among tech companies with private codebases (in addition to the Open Source code that they release).
- dragonwriter 10y agoThe ambiguity cannot be resolved in a license, because it exists in copyright law, not the license. If the kernel modules are not derivative works as defined in copyright law, then no license is needed to create or distribute them, and any restrictions in the license are of limited effect.
- tzs 10y agoThe term "derived work" is not defined in GPLv2, but it is widely believed that they meant it to mean the same thing as "derivative work", a term which is defined by copyright law. I'm going to make that assumption in the following. Note that if a work is not a derived work of the kernel, then it doesn't matter what GPLv2 says about it because you would not need permission of the kernel copyright holders to distribute the work. We only reach the question of what is a GPLv2 "derived work" once we determine that a work is a derivative work. Modules do not appear to inherently be derivative works of the kernel. Looking at the source code to various simple modules, I don't see anything in the minimal necessary code that is copied from the kernel other than the names of kernel header files and the names of some functions. It would be hard to argue that file names and function names are copyrightable, so I don't see any copyrightable kernel elements necessarily copied into simple modules. So, if I were to write a module and release it in source form only, it sure looks like I could do this in a way that would make it not a derivative work of the kernel, and so I would have no obligation to license it under GPLv2. If I were to do that, other people might have trouble using the module, for to use it they would have to compile it and combine it with a kernel. If that violates GPLv2, then they would be the ones liable for this, not me the module author. Could I be held responsible for their violation? There are a couple of ways in the US (not sure about other countries) whereby one can be held accountable for the copyright violation of another. The first is if that other is acting as an agent under one's control. That would not be applicable here. The second, contributory infringement, is when one person does something to knowingly enable someone else's infringement. For there to be contributory infringement, there are a couple of important requirements. First, there must be a direct infringement for the contributory infringer to contribute to. Second, my contribution has to be mostly only useful for infringing. I think contributory infringement is unlikely. The person who compiles and loads my module would have a very strong fair use defense against claims that they are infringing GPLv2 by combining my module and a kernel for their own use. (Also, GPLv2 kind of implies that you can do whatever you want with GPLv2 code on your own system in private, only having to obey GPL if you are going to distribute). It gets more interesting if I compile the module and release the binary. Macros in the source code may be expanded by the compilation process into code copied from kernel header files, or from the compiler. That could make the binary module a derivative work even though the module source code is not. This would depend on just what the macros expand to. It would be an interesting technical and legal project, although it would probably tick off a lot of people, to approach Linux modules that same way people approach third-party kernel modules for proprietary operating systems when the copyright holder doesn't approve: clean room reverse engineering. If the big proprietary operating system vendors, with their big legal teams and budgets and financial interest in keeping control over who runs what on their platforms, were unable to keep third parties from producing unauthorized kernel modules, I don't see why anyone would expect that Linux could do so.