4 ms·

If it's a derivative work of the Linux kernel (links to internal kernel API) it should be GPL. If Samsung distribute it to users then it should do that under GP

If it's a derivative work of the Linux kernel (links to internal kernel API) it should be GPL. If Samsung distribute it to users then it should do that under GPL. Samsung should be the first to relicense it.

regularfry 13y ago
Morally you might be right. Legally it's a grey area, and practically it's almost certainly a no-go.
- scotty79 13y ago
  So basically company can take your gpld code, extend it, slap their license on the whole thing it and redistiribute binaries without the source code and nobody can slap the gpl back on where it should be because it's a gray area?
  - regularfry 13y ago
    Nope, and that's as far as we can tell not what happened here.
  - Wilya 13y ago
    This is not about the GPL'd code people take from you, it's about what they add/change to this code. Whether you can directly slap the GPL back on these modifications is very discutable. You can most certainly sue them for breaching the license, though. (and, like sister comment says, this is not what's happening here anyway)
  - siddboots 13y ago
    You can't, in general, do that. The kernel developers and the FSF have always claimed that loadable modules (like the exFat driver) are "derived works", which has a specific meaning in copyright law. In particular, the GPL very clearly says that derived works must be re-licensed under GPL. The vendors claim that "derived works" doesn't include linked code, or plug-in patterns. They say that they aren't really releasing their own kernel, just releasing the stock kernel with a bunch of proprietary applications on top, along with their proprietary kernel module. Like that guy said, it's a gray area.
    - bjornsing 13y ago
      > The kernel developers and the FSF have always claimed that loadable modules (like the exFat driver) are "derived works"... Not true [1]. 1. See e.g. http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.....
      - siddboots 13y ago
        Ah, sorry. I should not have been so blanket.

regularfry 13y ago

Morally you might be right. Legally it's a grey area, and practically it's almost certainly a no-go.

scotty79 13y ago
So basically company can take your gpld code, extend it, slap their license on the whole thing it and redistiribute binaries without the source code and nobody can slap the gpl back on where it should be because it's a gray area?
- regularfry 13y ago
  Nope, and that's as far as we can tell not what happened here.
- Wilya 13y ago
  This is not about the GPL'd code people take from you, it's about what they add/change to this code. Whether you can directly slap the GPL back on these modifications is very discutable. You can most certainly sue them for breaching the license, though. (and, like sister comment says, this is not what's happening here anyway)
- siddboots 13y ago
  You can't, in general, do that. The kernel developers and the FSF have always claimed that loadable modules (like the exFat driver) are "derived works", which has a specific meaning in copyright law. In particular, the GPL very clearly says that derived works must be re-licensed under GPL. The vendors claim that "derived works" doesn't include linked code, or plug-in patterns. They say that they aren't really releasing their own kernel, just releasing the stock kernel with a bunch of proprietary applications on top, along with their proprietary kernel module. Like that guy said, it's a gray area.
  - bjornsing 13y ago
    > The kernel developers and the FSF have always claimed that loadable modules (like the exFat driver) are "derived works"... Not true [1]. 1. See e.g. http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.....
    - siddboots 13y ago
      Ah, sorry. I should not have been so blanket.