4 ms·

Bundling their driver and a custom kernel to work with it _really_ sounds like a derivative work that would be a very clear GPL violation. That would be a pret

Bundling their driver and a custom kernel to work with it _really_ sounds like a derivative work that would be a very clear GPL violation. That would be a pretty risky move legally speaking.

junon 3y ago
Not unless they open source the derivation of otherwise make the source available.
- mlyle 3y ago
  The intent of the GPL-- and Linux's interpretation thereof-- is that you can't just circumvent it by putting a thin API in for what you need and then shipping a huge closed source and/or restricted blob that integrates deeply with the GPL thing.
  - dTal 3y ago
    Funny because that's exactly how most commercial Linux-based products work, including and especially Android smartphones. In my opinion, tolerating TiVo-ization was a major and possibly fatal misstep for GPL enforcement. What is a firmware blob, if not a derived work? It stems from a "nerdy" interpretation of "linking" that considers as relevant the fact that the monolithic proprietary blob (encrypted, protected, unmodifiable) has some sort of internal interface that mirrors the way a user might use a hypothetical free version of the product (running proprietary processes on a free kernel/userland). But it ignores the fact that the user cannot in practice disentangle the product in any way. It is the user experience that should legally be the deciding factor. I realize this may be a controversial stance, but consider - what if I released a proprietary and closed source desktop application that bundled into its binary a copy of the Linux kernel? Are the specifics of how it interacts internally with this code really relevant? Is this really a different situation than code that runs bare metal?
    - admax88qqq 3y ago
      This is different thatn TiVo-ization. TiVo-ization is, releasing your code as FOSS, but enforcing in your hardware that you can only run vendor signed builds on the device, preventing users from running their own modifications to the software. Most enterprise linux derivatives do not bundle proprietary linux modules with a modified linux kernel.
      - dTal 3y ago
        TiVo, like all such products, ran proprietary software "on top" of the Linux kernel (and "underneath", typically, in the form of a closed source bootloader). As far as I know, no company bothers to apply such DRM unless they do this. So this is kind of a distinction without a difference.
        mlyle 3y ago
        The user space interface is explicitly supported to run proprietary software. It's an operating system. The kernel's license taints things that are tightly coupled with it. Even most modules are not this tightly coupled and can deal with the exported symbols. Similarly, the loader, BIOS, etc, are not encumbered by the kernel license.
        dTal 3y ago
        We are specifically addressing what happens when you take a Linux kernel (or any other GPL code), modify it, and bundle it with proprietary software, in such a way that neither the free nor proprietary software function without the other. I am arguing that, regardless of the technical details, this constitutes a derived work (and not, as is commonly argued, an "aggregate"). The FSF gently disagrees with me. Tellingly, they won't commit to a clear distinction between "derived" and "mere aggregate", calling it a "legal question", but suggest that "a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged)." I say this is a classic nerd mistake of reaching for technical solutions to social problems - the true criterion should be something more like "can the user run these components independently?".
- jacooper 3y ago
  Which they won't do because they don't want to open source their drivers, that's the whole issue.
tuetuopay 3y ago
IANAL but I don't think so. You are free to modify a GPL thing and redistribute it as long as you provide the sources. Strip the kernel of the GPL check, ship it with DGX, and provide a tarball of the patched sources.

Bundling their driver and a custom kernel to work with it _really_ sounds like a derivative work that would be a very clear GPL violation. That would be a pretty risky move legally speaking.

junon 3y ago

Not unless they open source the derivation of otherwise make the source available.

mlyle 3y ago
The intent of the GPL-- and Linux's interpretation thereof-- is that you can't just circumvent it by putting a thin API in for what you need and then shipping a huge closed source and/or restricted blob that integrates deeply with the GPL thing.
- dTal 3y ago
  Funny because that's exactly how most commercial Linux-based products work, including and especially Android smartphones. In my opinion, tolerating TiVo-ization was a major and possibly fatal misstep for GPL enforcement. What is a firmware blob, if not a derived work? It stems from a "nerdy" interpretation of "linking" that considers as relevant the fact that the monolithic proprietary blob (encrypted, protected, unmodifiable) has some sort of internal interface that mirrors the way a user might use a hypothetical free version of the product (running proprietary processes on a free kernel/userland). But it ignores the fact that the user cannot in practice disentangle the product in any way. It is the user experience that should legally be the deciding factor. I realize this may be a controversial stance, but consider - what if I released a proprietary and closed source desktop application that bundled into its binary a copy of the Linux kernel? Are the specifics of how it interacts internally with this code really relevant? Is this really a different situation than code that runs bare metal?
  - admax88qqq 3y ago
    This is different thatn TiVo-ization. TiVo-ization is, releasing your code as FOSS, but enforcing in your hardware that you can only run vendor signed builds on the device, preventing users from running their own modifications to the software. Most enterprise linux derivatives do not bundle proprietary linux modules with a modified linux kernel.
    - dTal 3y ago
      TiVo, like all such products, ran proprietary software "on top" of the Linux kernel (and "underneath", typically, in the form of a closed source bootloader). As far as I know, no company bothers to apply such DRM unless they do this. So this is kind of a distinction without a difference.
      - mlyle 3y ago
        The user space interface is explicitly supported to run proprietary software. It's an operating system. The kernel's license taints things that are tightly coupled with it. Even most modules are not this tightly coupled and can deal with the exported symbols. Similarly, the loader, BIOS, etc, are not encumbered by the kernel license.
        dTal 3y ago
        We are specifically addressing what happens when you take a Linux kernel (or any other GPL code), modify it, and bundle it with proprietary software, in such a way that neither the free nor proprietary software function without the other. I am arguing that, regardless of the technical details, this constitutes a derived work (and not, as is commonly argued, an "aggregate"). The FSF gently disagrees with me. Tellingly, they won't commit to a clear distinction between "derived" and "mere aggregate", calling it a "legal question", but suggest that "a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged)." I say this is a classic nerd mistake of reaching for technical solutions to social problems - the true criterion should be something more like "can the user run these components independently?".
jacooper 3y ago
Which they won't do because they don't want to open source their drivers, that's the whole issue.

tuetuopay 3y ago

IANAL but I don't think so. You are free to modify a GPL thing and redistribute it as long as you provide the sources. Strip the kernel of the GPL check, ship it with DGX, and provide a tarball of the patched sources.