4 ms·

You don't see Linus's viewpoint as contrary to the one on gnu.org? It seems like Linus is saying that the GPL allows AFS to be used with Linux (because it is n

by mahrens 13y ago

You don't see Linus's viewpoint as contrary to the one on gnu.org? It seems like Linus is saying that the GPL allows AFS to be used with Linux (because it is not a "derived work"). How is ZFS different from AFS in this respect?

rgbrenner 13y ago
No, I don't. The gnu link says CDDL is not compatible with the GPL. What Linus is saying is, if a kernel loadable module relies on kernel internals, then it may count as a derived work, and must be licensed under a GPL-compatible license. If it does not -- for example, it is a filesystem that was ported to Linux (like AFS, and zfs fits here too IMO), then it may not be a derived work, and can be licensed under a non-gpl compatible license (like the CDDL). Obviously, including the AFS or zfs into the source WOULD DEFINITELY create a derived work, and would require AFS/ZFS to be licensed under the GPL. So Linus' is only explaining how a kernel loadable module could be licensed under a GPL-incompatible license.
- Dylan16807 13y ago
  I don't understand how putting the code into the same repository/makefile changes whether it's derivative in terms of copyright.
  - mzs 13y ago
    If yo take a Makefile which say Linus had written and tack on some of your own rules, you have almost certainly (unless the original Makefile was something trivial like ::) created a derived work.
  - raimue 13y ago
    If you distribute a single source tarball with code files with different licenses, all of them apply. There may be different terms limiting what you are allowed to do with the file in each of the licenses, while the most restrictive license terms apply to the whole file. Besides the real legal issues, this also causes unnecessary confusion for users and those creating packages for binary distribution. Therefore, using multiple incompatible licenses in a single source tree is usually avoided.
    - Dylan16807 13y ago
      >If you distribute a single source tarball with code files with different licenses, all of them apply. Yes, the tarball distribution must respect all the licenses of files inside it, but once the tarball is unpacked it goes back to individual licenses per file. I understand how it's a big mess when it gets to binaries, but do any licenses actually place restrictions on what they can be tarballed with?
  - deleted 13y ago
    [deleted]
  - rgbrenner 13y ago
    It's really more than simply adding it to a repository. I can store two text files that have nothing to do with each other on my HD or in a repo or wherever, and I would not be creating a derived work. But if I have file A (kernel source) and file B (zfs code), and I compile A+B into a binary (the kernel image), then I have a single work that has been derived from A and B. When it's suggested that ZFS be added to the kernel repo, what's really being said is that a single work (kernel+zfs) should be created. In contrast, ZFS is currently a kernel loadable module. We have the kernel binary, and the module binary.. two separate works. (What Linus was clarifying was how integrated the module could be with the kernel and it still be considered a separate work.)
    - Dylan16807 13y ago
      So what if it was inside the official kernel repo but defaulted to building as a module, and anyone distributing binaries left it on the default? Would that actually satisfy the licenses or are there clauses that would get in the way?
      - rgbrenner 13y ago
        Good question. I think this is getting to specific for me to comment on. IANAL.
        _delirium 13y ago
        From my mostly second-hand knowledge, in practice even lawyers specializing in IP wouldn't have a solid answer for how to make this distinction, without looking at a specific case in detail. If it came up in a trial, the two sides would make a version of the arguments presented here: one would emphasize that the sources have now been "added to the kernel tree", a unified project managed with close integration etc. etc., while the other side would argue they were merely placed alongside the kernel sources in a version control system, like collecting short stories in an anthology.
        Dylan16807 13y ago
- mzs 13y ago
  Well written, I will add that it's pretty clear cut that zfs on linux would be a derived work of the kernel cause it has some differences specific to linux internals to make it work. That's why zfsonlinux only distributes module sources. Since it never distributes a binary, it can't run afoul of licensing.

by mahrens 13y ago

rgbrenner 13y ago

No, I don't. The gnu link says CDDL is not compatible with the GPL. What Linus is saying is, if a kernel loadable module relies on kernel internals, then it may count as a derived work, and must be licensed under a GPL-compatible license. If it does not -- for example, it is a filesystem that was ported to Linux (like AFS, and zfs fits here too IMO), then it may not be a derived work, and can be licensed under a non-gpl compatible license (like the CDDL). Obviously, including the AFS or zfs into the source WOULD DEFINITELY create a derived work, and would require AFS/ZFS to be licensed under the GPL. So Linus' is only explaining how a kernel loadable module could be licensed under a GPL-incompatible license.

Dylan16807 13y ago
I don't understand how putting the code into the same repository/makefile changes whether it's derivative in terms of copyright.
- mzs 13y ago
  If yo take a Makefile which say Linus had written and tack on some of your own rules, you have almost certainly (unless the original Makefile was something trivial like ::) created a derived work.
- raimue 13y ago
  If you distribute a single source tarball with code files with different licenses, all of them apply. There may be different terms limiting what you are allowed to do with the file in each of the licenses, while the most restrictive license terms apply to the whole file. Besides the real legal issues, this also causes unnecessary confusion for users and those creating packages for binary distribution. Therefore, using multiple incompatible licenses in a single source tree is usually avoided.
  - Dylan16807 13y ago
    >If you distribute a single source tarball with code files with different licenses, all of them apply. Yes, the tarball distribution must respect all the licenses of files inside it, but once the tarball is unpacked it goes back to individual licenses per file. I understand how it's a big mess when it gets to binaries, but do any licenses actually place restrictions on what they can be tarballed with?
- deleted 13y ago
  [deleted]
- rgbrenner 13y ago
  It's really more than simply adding it to a repository. I can store two text files that have nothing to do with each other on my HD or in a repo or wherever, and I would not be creating a derived work. But if I have file A (kernel source) and file B (zfs code), and I compile A+B into a binary (the kernel image), then I have a single work that has been derived from A and B. When it's suggested that ZFS be added to the kernel repo, what's really being said is that a single work (kernel+zfs) should be created. In contrast, ZFS is currently a kernel loadable module. We have the kernel binary, and the module binary.. two separate works. (What Linus was clarifying was how integrated the module could be with the kernel and it still be considered a separate work.)
  - Dylan16807 13y ago
    So what if it was inside the official kernel repo but defaulted to building as a module, and anyone distributing binaries left it on the default? Would that actually satisfy the licenses or are there clauses that would get in the way?
    - rgbrenner 13y ago
      Good question. I think this is getting to specific for me to comment on. IANAL.
      - _delirium 13y ago
        From my mostly second-hand knowledge, in practice even lawyers specializing in IP wouldn't have a solid answer for how to make this distinction, without looking at a specific case in detail. If it came up in a trial, the two sides would make a version of the arguments presented here: one would emphasize that the sources have now been "added to the kernel tree", a unified project managed with close integration etc. etc., while the other side would argue they were merely placed alongside the kernel sources in a version control system, like collecting short stories in an anthology.
        Dylan16807 13y ago
mzs 13y ago
Well written, I will add that it's pretty clear cut that zfs on linux would be a derived work of the kernel cause it has some differences specific to linux internals to make it work. That's why zfsonlinux only distributes module sources. Since it never distributes a binary, it can't run afoul of licensing.