3 ms·
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, an
by 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 agoSo 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 agoGood question. I think this is getting to specific for me to comment on. IANAL.
- _delirium 13y agoFrom 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 agoLet me ask a slightly different question then. Does the GPLv2 ever try to control anything that is not derived from the GPL source code? Some of the FSF's saber-rattling seems to imply that either the answer is yes, or they're being misleading, or they have a completely ridiculous definition of derivation.
- rgbrenner 13y agoYes, if you link to a GPL'd library your program must also be GPL'd. That is why the LGPL was created. Only example that immediately jumps to mind. Edit: rephrased for clarity
- Dylan16807 13y agoDon't they claim that the linking rule works via derivation? As far as I understand it, the FSF would tell you that anything linked is always derivative. But that doesn't mean it's true. If you could prove that a particular instance of linking to a library was not derivative, would they still claim your program had to be GPL? As I understand it, the LGPL exists to 1. provide legal certainty and 2. allow some amount of external derivation if necessary. And it's easy to create an artificial dynamic-linking case where there is provably no derivation, using multiple libraries with the same API.
- rgbrenner 13y agoDon't they claim that the linking rule works via derivation? Yes.. it was the closest thing I could think of where the two pieces of software are fairly separated. I mean you could have a huge proprietary program, and a developer calls gsl_pow_int() from the GNU scientific library, and the entire program must be licensed under the GPL. I think that's about as close as you're going to get. If you're looking for a case where the FSF said a piece of software had to be licensed under the GPL, even though it was NOT a derivative work, I don't think you'll find it. The reason it must be a derivative is copyright law.. the GPL can't unilaterally change that.