Hacker News new | past | comments | ask | show | jobs | submit login

> Where is he saying that you can distribute the combined work?

What's your reasoning as to why one couldn't, if we grant Linus's reasoning re: AFS as it applies to ZFS?

> Not that it matters, since he's not the license author not even the copyright holder these days...

Linux kernel community has seen fit to give its assurances re: other clarifications/exceptions. See the COPYING file.




> What's your reasoning as to why one couldn't

Simply put, because it's a license incompatible with the GPL, as it literally says so on the page of the creators of the GPL, Wikipedia, etc.

> if we grant Linus's reasoning re: AFS as it applies to ZFS?

You are the one claiming that Linus reasoning implies the AFS code combined with the Linux kernel _can be distributed_. Linux is not actually saying that in the post you quoted. I am asking for where he says that.

> Linux kernel community has seen fit to give its assurances re: other clarifications/exceptions. See the COPYING file.

It doesn't really matter; not one individual can grant "an exception" unless it was already allowed to begin with (the GPL _explicitly_ grants the system library exception). Linus even says so in the very beginning of the post you quoted ("No such exception exists. There's a clarification [...]").


> Simply put, because it's a license incompatible with the GPL, as it literally says so on the page of the creators of the GPL, Wikipedia, etc. > not one individual can grant "an exception"

"The creators of the GPL"? You mean the FSF? If you don't think Linus and the kernel devs have standing, what standing or authority do the FSF and Wikipedia have? Neither are a licensor of the Linux kernel either.

I'm saying the Linux kernel devs have seen fit to give their view, and they think it carries weight, and seems to govern the actual practice and use, and this would seem to be another analogous instance where they could give their view again.

> You are the one claiming that Linus reasoning implies the AFS code combined with the Linux kernel _can be distributed_. Linux is not actually saying that in the post you quoted. I am asking for where he says that.

Linus doesn't explicitly say this in that post. I thought that was clear enough from ... reading the linked post. However, I do feel it naturally follows from what he says. Otherwise, this discussion would have an angels on the head of a pin quality (which we're talking about the GPL on the internet, so...).

Perhaps we simply disagree about the underlying copyright jurisprudence? After all, you might say, the GPLv2 states: "But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License,..." and "a 'work based on the Program' means either the Program or any derivative work under copyright law". Maybe, you say, ZFS is a "derived work" under copyright law, if not a "derived work" given the plain meaning of derived work?

I happen to believe that courts would not be sympathetic to broad claims of what is "derived" software/infringement, like those made by the FSF, and have not been since Computer Associates v. Altai (and a long line of other cases). For example, you might see Sega v. Accolade, where a court of appeals held that Accolade could reverse engineer Sega’s video game system to create games that ran on the system, even though it involved copying Sega’s code. And I happen to believe the FSF has misled the FOSS community as to the state of the underlying copyright law with their (mis)interpretations of their licenses.


> "The creators of the GPL"? You mean the FSF? If you don't think Linus and the kernel devs have standing, what standing or authority do the FSF and Wikipedia have? Neither are a licensor of the Linux kernel either.

They are, at least, actual lawyers.

> I thought that was clear enough from ... reading the linked post. However, I do feel it naturally follows from what he says.

No, it doesn't.

If OpenAFS is a derived work, then it is in violation of the GPL to distribute it at all. i.e. _it cannot exist_ for all practical purposes.

If OpenAFS is not a derived work, then you can distribute it. You can still work on it, distribute it, and individual users may combine it with Linux on their own machines.

Under no circumstances you can distribute a Linux kernel combined with a non-GPL-compatible module and call it a day. Note that this does not depend _at all_ on whether OpenAFS is a derived work or not. The kernel combined with OpenAFS _for sure_ is a derived work of the kernel ( you really need the courts to determine that?) , and you can't distribute that without violating the GPL. AND the CDDL.

What Ubuntu does is stretching it (they never distribute binaries, only aggregate sources, which supposedly the user can one-click-combine into a derived work).


> They are, at least, actual lawyers.

Are they?

> Under no circumstances you can distribute a Linux kernel combined with a non-GPL-compatible module and call it a day.

That's exactly the Q presented -- whether the ZFS module/s licensed as CDDL is GPL compatible. I am arguing it is.

> From GPLv2, Section 2: "If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it."

If the module is not a derived work, then my understanding is you can distribute them with "the Program". See also GPLv2, Section 3.

> What Ubuntu does is stretching it (they never distribute binaries, only aggregate sources, which supposedly the user can one-click-combine into a derived work).

My understanding is that this is incorrect. Canonical ships a fully built and linked zfs.ko in a separate package from the main kernel image. See: https://packages.ubuntu.com/kinetic/amd64/linux-modules-5.19...


> Are they?

What's this, ELIZA ?

> I am arguing it is.

That's new: none of the arguments you've presented has helped make that case yet.

I don't understand why you keep trying to argue whether the "ZFS module" _by itself_ is a derived work or not. It is irrelevant. You are distributing _the entire work_, which is obviously derived from the Linux kernel since it literally _contains it_ (or an almost verbatim copy of it). The paragraph you yourself quoted literally says the entire distribution must then be on the terms of this license (GPL), which the CDDL _forbids_.

The GPL has exceptions for "aggregation" but as I said in my opinion what Ubuntu is doing crosses the line. It can hardly be claimed to be aggregation when literally the module they ship is strictly designed to work with the kernel they ship, and it is absolutely useless otherwise. Such interpretation basically makes the LGPL meaningless.


> What's this, ELIZA ?

Do you know if any of these FSF "interpretations" are written by attorneys? I'm curious. Here[0], re: ZFS, Stallman says he solicited advice from others, at least one an attorney, but AFAIK Stallman alone is the named author. But I generally don't trust 2nd hand legal opinions of attorneys, who won't publish under their own name, and don't work for me.

> I don't understand why you keep trying to argue whether the "ZFS module" _by itself_ is a derived work or not. You are distributing _the entire work_, which is obviously derived from the Linux kernel since it literally _contains it_ (or an almost verbatim copy of it).

This is obviously a point of disagreement. You might see [1], written by an actual attorney and expert in these issues: "With the ambiguous definitions in the GPL, and rather paltry protections provided to software under the Copyright Act, kernel module code likely falls outside of the definition of 'derivative works.'"

> The paragraph you yourself quoted literally says the entire distribution must then be on the terms of this license (GPL), which the CDDL _forbids_.

Again [1], re: the paragraph I quoted and Section 0, it notes: "...[T]he GPL fails to make the distinction between a work containing the Program and a work based on the Program, or collective and derivative works as Congress defined them under the act. Combining these terms into a single all-encompassing definition is illogical, especially given the GPL’s reference in the same sentence to copyright law and the importance of those legal terms of art under the act."

Which I have to agree with! When the GPL says "The "Program", below, refers to any such program or work, and a 1) "work based on the Program" means either the Program or any derivative work under copyright law:" and then says 2) "that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language." The correct interpretation is not to conflate two distinct copyright terms. That actually the GPL applies to both. It's to read out the clearly illogical, contradictory language.

[0]: https://www.fsf.org/licensing/zfs-and-linux

[1]: https://www.networkworld.com/article/2301697/encouraging-clo...


You are quoting someone who tries to argue whether the module by itself or not is a derivative work, but I have literally say I find that irrelevant. You literally removed the part where I say "it is irrelevant" when quoting me...

You miss the point. I'm not claiming that the GPL applies to ZFS code, most definitely not when it is obviously not derived from any GPL software. Whether the ZFS Linux module is derivative or not I don't care. I am claiming that the GPL applies when you _distribute Linux itself_. What possible point of contention you could have? Linux is obviously GPL...

If you are trying to distribute Linux you have to do it under the terms of the GPL, whatever your opinion of them are, in the same way that when you want to _use_ Windows you have to use it under the terms of the Windows EULA, whatever your opinion of Windows is. Unlike the Windows EULA, the GPL doesn't put any limitations to use, so at your own home you can do whatever you want (including combining it with ZFS, if the CDDL were to allow you), but you can't distribute the combined work (because the GPL forbids you to do so)!


> Unlike the Windows EULA, the GPL doesn't put any limitations to use, so at your own home you can do whatever you want (including combining it with ZFS, if the CDDL were to allow you), but you can't distribute the combined work (because the GPL forbids you to do so)!

This is what I'm arguing is wrong. GPL explicitly allows distributing a collective/combined work, in contrast to a derived work. See, again, GPLv2, Section 2.


Which part exactly you claim allows you to do that? The only which remotely even allows you to do so is the "mere aggregation", and mere aggregation I already mentioned like 2 days ago.

The only part you mentioned so far:

> From GPLv2, Section 2: "If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it."

Is literally saying that the whole must be licensed under the GPL (note: even whether there are sections that may be considered independent and/or separate and/or derivative and/or whatever), otherwise you just can't distribute it.

Just think about it. The LGPL would make no sense if this wasn't the case.


> Is literally saying that the whole must be licensed under the GPL (note: even whether there are sections that may be considered independent and/or separate and/or derivative and/or whatever), otherwise you just can't distribute it.

You seem to think it's very clear what the "whole work" is and that it must include ZFS.

See my comment of 2 days ago.[0] Section 2 states "...a whole which is a work based on the Program..." which is, as I've already mentioned, defined at Section 0. I'll say again -- at Section 0, it says "a work based on the Program" is either 1) the licensed program (Linux only), or 2) "any derivative work under copyright law", which ZFS is not, so the combination is such a "mere aggregation."

> Just think about it. The LGPL would make no sense if this wasn't the case.

Whether the LGPL makes sense or not is not really a concern of mine, but the LGPL also only applies to "derived works" as well.

[0]: https://news.ycombinator.com/item?id=35914449


> You seem to think it's very clear what the "whole work" is and that it must include ZFS.

And you disagree with that? Not only it is rather evident (Ubuntu distributes both in the same media, and in the same one-click installer), but you even need to admit this point in order to claim "mere aggregation" as you are now doing for the first time.

> See my comment of 2 days ago.[0] Section 2 states "...a whole which is a work based on the Program..." which is, as I've already mentioned, defined at Section 0. I'll say again -- at Section 0, it says "a work based on the Program" is either 1) the licensed program (Linux only), or 2) "any derivative work under copyright law", which ZFS is not

The "whole" here (Ubuntu) is evidently based on Linux since it literally contains it almost verbatim. You are distributing Linux. I still don't get how you can possibly disagree there. You just keep throwing the argument on whether ZFS is derivative or this or that but it is simply irrelevant.

> so the combination is such a "mere aggregation."

And now we finally get to the real core of the argument, where you are finally claiming that Ubuntu distributing ZFS alongside the kernel is just "mere aggregation", the only exception that the GPL acknowledges that would even be relevant here. It is an important exception -- otherwise all of Ubuntu would have to be GPL-compatible -- but notice that it has absolutely nothing to do with whether the parts are derivatives of each other or not, and in fact the very paragraph which introduces this exception actually mentions this _explicitly_.

Which means that, going back to your assertion, it doesn't follow from the arguments you posit that it is "mere aggregation" -- it cannot be decided based on derivative/not derivative.

As I literally said on my very first message on this discussion, Ubuntu claiming this is "mere aggregation" is stretching it. The ZFS module they ship only works with the very same kernel version they ship and viceversa (this for me is already enough to fail the "it is not derivative" claims -- but that's another story). The installer will one-click link the two for you, so that the module loads into _the same address space as the kernel_, and Ubuntu loses functionalities if you don't use the provided ZFS module and use some other filesystem module instead. They could very well just prelink zfs.ko it into the kernel and it would be practically indistinguishable. It is, in my view, impossible to claim this as "mere aggregation".

And notice that Linus claiming "OpenZFS is not derivative" won't make this any different. Even if it was God himself claiming it. The above is just legal tricky, no matter what the legal status of ZFS itself is.

> the LGPL also only applies to "derived works" as well.

And? That is the intention (and the limit) of copyright. To protect distribution of these.

A license for X software could claim that you can only distribute X alongside other software which has an even number of lines of source code and you'd have to comply with it. Not because "other software" is derivative from X or not, but because you have to comply with it to copy X.


> You just keep throwing the argument on whether ZFS is derivative or this or that but it is simply irrelevant.

And you keep saying things like this without explaining them. Perhaps I've failed in being as clear as I possibly can be, and for that I'm sorry, but this is last comment I'll add to this very long thread, because where as I've have provided references to the text, and tried to explain my thinking, you have not.

> The installer will one-click link the two for you

AFAIK this is false, as I believe I've said before. The zfs.ko is prelinked.

> The ZFS module they ship only works with the very same kernel version they ship and viceversa (this for me is already enough to fail the "it is not derivative" claims -- but that's another story).

So, your idea is because a binary module is dependent in some way upon an underlying substrate like a library or a kernel (as opposed to the source being dependent), it is a derivative work? I think that's a fine test to propose as being the test for whether a work is derivative, but you will need to point at some textual basis for that belief. So far, I don't see one from you, and AFAIK the GPLv2 does not propose a specific boundary itself other than that of "derived work."

> It is, in my view, impossible to claim this as "mere aggregation".

Again -- you have to explain "Why?" of this bare assertion. You use language like "clearly" and "evident" and "impossible" when you haven't explained yourself with reference to the GPL text and/or copyright law.

> A license for X software could claim that you can only distribute X alongside other software which has an even number of lines of source code and you'd have to comply with it. Not because "other software" is derivative from X or not, but because you have to comply with it to copy X.

There are boundaries to what are permissible covenants in a copyright license. Copyright is a actually a rather weak IP right, and one example of a very broad exception/exemption would be copyright "fair use". It's fair use to copy API definitions, for instance.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: