Remix.run Logo
cyphar 5 days ago

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).

LegionMammal978 5 days ago | parent [-]

If you write code simply using an interface, then it's nigh-impossible to infringe on someone else's code implementing that interface, regardless of how internal or technical or particular or unstable that interface is. The provider and consumer are simply doing two different things, and are expressing two different ideas, even if you look at it under the abstract lens of SSO.

Instead, they would have to argue that your code using the interface infringes on either (a) the interface itself, or (b) some of their other code using the interface. The former case (a) has been greatly weakened in light of Oracle v. Google (especially in the driver context where you can argue for interoperability), and my impression is that the latter case (b) can often be minimized to the point that it also falls under fair use. Alternatively, the 'GPL condom' separates the ultimate user even further from any copyrightable elements of the provider's code.

The provider of the interface could try to make it so fiddly that it can only be used in one specific copyrightable way, but if it's so bad that even using a 'GPL condom' would infringe, then you could plausibly spin something from Sega v. Accolade.

In other words, I think the "generally accepted view" you refer to is extremely questionable, even in the context of kernel modules. People just steer clear of these hairy questions out of an abundance of caution, especially when their actions wouldn't net them enough money to pay for litigation. (And as it happens, Nvidia is netting tons of money!) And with a well-designed 'GPL condom', it would be a very uphill battle for the provider to argue that the ultimate user has infringed on some copyrightable element of their code.

cyphar 4 days ago | parent [-]

I disagree, but I think this is a question that could only be answered in court (and probably over several court cases).

The end-stage result of your argument would be that copyleft licenses are practically unenforceable because if you just make a separate textual file and then make reference to internal APIs in order to make extensions then you're simply using an interface regardless of the implementation and thus not bound by the license. So the strongest copyleft license you could possibly have is an even weaker form of the MPL ("function-based" rather than "file-based", and one that you could trivially bypass).

As for GPL condoms -- personally, I think a judge would not look favourably on GPL condoms precisely because they look like pedantic rules lawyering. If usage without a GPL condom would be a violation then I would be surprised if a GPL condom made a lick of difference in the eyes of a judge. But I've been surprised plenty of times, and as far as I know they've never been tested in court.

4 days ago | parent [-]
[deleted]