▲ | LegionMammal978 5 days ago | |||||||||||||||||||||||||
> (in kernel contexts a spiritually similar setup is called the "GPL condom" and my impression is that most lawyers not employed by NVIDIA consider this to not be a get-out-of-jail-free card). The whole thing with Linux's conception is that it's predicated on any and all unlicensed usage of GPL-only interfaces being copyright infringement of other usage in the kernel source. This is an extremely broad claim to make in general (especially in light of Google v. Oracle), and the 'GPL condom' approach is just to further ensure that the unlicensed side is textually unrelated to the kernel. When there's no infringement, the copyright holders can't do a single thing, except to technologically make it harder on you. Meanwhile, the whole GPL idea of linking vs. statically embedding is only applicable when you're shipping someone else's GPL-licensed code alongside your non-licensed code, in which case you're bound by its terms. If you're not shipping someone else's code, then there's plenty of ways to force a particular build, etc., in the manner that the GPL is trying to prevent. Heaven knows I've likely violated the spirit of the GPL before just through Hyrum's law. | ||||||||||||||||||||||||||
▲ | immibis 5 days ago | parent | next [-] | |||||||||||||||||||||||||
The GPL works because you create a derived work. The legal ability to create a derived work is restricted by copyright. They grant you an exception to the default restriction of copyright, but only if you comply with all of these terms. The most obvious way around it is to claim the thing you created is not a derived work. Nvidia probably has a good case for this because 99% of their code has absolutely nothing to do with the Linux kernel; making an adapter so you can plug that 99% into the kernel does not make it magically derived from it. Some random hardware driver doesn't have that same claim of being mostly independent of the kernel - graphics drivers are particularly complicated. Regardless of whether the driver is a derivative work of the kernel, the combination of the kernel and the driver is obviously derivative of both its parts and so you have to comply if you ship that, too. | ||||||||||||||||||||||||||
| ||||||||||||||||||||||||||
▲ | cyphar 5 days ago | parent | prev [-] | |||||||||||||||||||||||||
I see what you're getting at, but on the other hand there is also a difference between APIs that are intended for use by third parties that are just "regular usage of the program" and internal functions that are being exposed due to technical factors in how the source code is organised (i.e., the fact that Linux organises its code into loadable modules and does not expose all symbols to try to avoid needless breakages). To be clear -- the general view is that the GPL is viral in both cases (in fact the general view is that any user of the published interfaces of a GPL-licensed library is a derived work -- even in cases not involving compilation or linking), but I think the kernel module case is even more clear-cut than that. In my view, the fact that the Linux kernel interfaces change incredibly frequently in every release specifically in response to internal code changes really makes it hard to believe that usage out of tree is just the same as using the syscall interface (which is what NVIDIA et al. tend to argue). (Note that the Linux syscall exception is actually not the license for the entirety of Linux -- almost none of my code contributions have been under the syscall exception and the same is true for almost all Linux contributions.) For what it's worth, I think the distinction between EXPORT_SYMBOL and EXPORT_SYMBOL_GPL has been a net harm to any discussion about module-related GPL violations, precisely because there isn't an obvious line you can draw between their usage and it just muddies the waters unnecessarily (recent attempts to further lock this down seem to indicate some kernel developers agree that this was a mistake). If you imagine an analogous case with a Python program and someone adding files to it which modify the internal state of the original program through interfaces that were only visible because of technical aspects of code organisation, the case becomes far more clear and I don't think further technical shenanigans solve the underlying legal issue. Google v. Oracle was also about copying the interface itself and whether replicating said interface was fair use (which I think everyone except Oracle would find to obviously be true, otherwise the entire history of GNU and Linux would be one of copyright infringement). It was not at all concerned with creating combined works through the use of an interface. You could try to make the argument that (in light of Google v. Oracle) that the generally accepted view of users of a GPL-licensed library being derived works of said library is somewhat questionable, but I think that's a separate discussion (as I said, I think the module discussion is even more clear-cut). | ||||||||||||||||||||||||||
|