Canonical merges GPL-incompatible kernel module ZFS to the kernel tree for Ubuntu 16.04
- Inicie sesión o regístrese para enviar comentarios
Sounds like more hurdles for Trisquel devs.
I believe it actually is very easy to remove the module. Something like:
$ rm -r /lib/modules/*/kernel/zfs
I don't see how this a problem since trisquel uses a different kernel anyway, right?
Trisquel does not use Linux-libre. Instead, it deblobs the Ubuntu kernel.
That's interesting. I didn't realize that. Wouldn't this just be one more step in the de-blobbing process?
Also, why is ZOL not free software? Is the license non-free?
It probably is one single line to add to the deblobbing script.
What is ZOL?
ZOL is probably the abbreviation of ZFS on Linux.
> Also, why is ZOL not free software? Is the license non-free?
I think it is free software, but with a GPL-incompatible license. It's illegal to combine GPL software with GPL-incompatible software, that's all.
ZFS, while GPL incompatible, is still free software. It is one of those technologies that has kept people tied to the BSDs and while other file systems like btrfs have tried, ZFS is still king.
The only problem? It cannot be merged into the mainline kernel due to conflicts with the GPL. We all know this.
Canonical makes a good chunk of their money from trademark and service contracts. If they put in the effort to include ZFS support, it will keep people on Ubuntu (and GNU/Linux in general) instead of merging to one of the BSDs.
I think there is some misinterpretation here. The actual kernel is as-is and will not need any deblobbing. Fully GPL compatible and all that. The only difference with ZFS on Ubuntu is the addition of the zfsutils-linux package at http://packages.ubuntu.com/xenial/zfsutils-linux that will install the driver as an addon. It is probably a DKMS package (much like the non-free Nvidia drivers and VirtualBox) meaning that it will not affect the shipping kernel. Canonical just makes it convenient to install the package as an additional module if you choose so to please.
If the Trisquel team is worried about ZFS, then don't have zfsutils-linux installed by default. You should still keep it in the repositories due to it being free software.
As a follow up to my post, I see that zfs-dkms is a virtual package provided by linux-image-4.4.0-6-generic.
If Trisquel wants to counter this, wouldn't the .deb files for the kernel have to exclude the installation of zfs-dkms and make sure that the zfs packages are not included on the Trisquel 8 ISOs? Of course the zfs packages should still be installable (as I said above) if needed.
More junk from Canonical. Ubuntu already had proprietary software. Now they're shipping Ubuntu with GPL violations. It will be interesting to see how long this lasts.
Doesn't the package that Canonical includes just install it via DKMS?
Dynamically linking a module is making a derivative work according to the GPL. That even is the only difference with the LGPL. Canonical is violating the GPL because the module in question is under a copylefted license (the CDDL) that is incompatible with the GPL (Linux's license): the CDDL has restrictions that the GPL does not have.
What if Canonical ships the ISOs with the ZFS package not included, but then brings it in automatically the first time you update your packages? That way your software ships without this GPL restriction.
No. Plus, even if it did, it doesn't skirt around the GPL.
This can't be legal, GPL2 forbids linking with CDDL, and oddly the Ubuntu's IP police doesn't allow to share the CD's changing the GPL clashing modules.
https://m.twitter.com/mjg59/status/700073945064611841
More information from Matthew Garrett. You can read Twitter without JS by just using the m.twitter subdomain, BTW.
I think it should be pointed out that if this is done the right way, it doesn't cause license violations. Copyright law restricts only what you can distribute. On your own computer, it has no force. For example, you could write a program using a library under the GPL and then throw away the source code to the program you wrote. That program would then be proprietary, but it wouldn't be a license violation unless you actually distributed the program to someone else.
But even if it does cause a license incompatibility, ZFS is libre. I don't think it's productive to make a fuss about a license violation unless it involves something actually unethical occurring, such as proprietary software or at least plagiarism. Avoiding license violations that don't actually include unethical activity (for example, linking together a program under the GPL with a program under a different, incompatible copyleft license) is still important (you don't want some jerk who happened to develop the program you're violating the license of going after you, and you don't want the legal situation of your code to be a confusing mess), but there's no need to chastise others for license violations themselves.
Remember, copyleft licenses are not divine commands, and their restrictions are not morals. Copyleft is a strategy to combat proprietary software, and license incompatibility between libre programs is an unfortunate side effect of this strategy.
So, in summary: if what Ubuntu is doing causes a violation of the GNU GPL or the CDDL, then Trisquel should correct this violation. However, it might not be the case. And even if it is, there's no need to criticize Canonical for it. Much less actually try to take legal action, wasting precious resources, which Matthew Garrett seems to want the SFC to do.
In fact, I'm going to have to condemn Matthew Garrett for what he advocates in that Twitter thread. What he's advocating for is infighting within the libre software community, for the purpose of preventing copyright infringement. This is supportive of the copyright industry, not us.
I tend to agree. Matt goes around and around arguing with that dude on twitter how loading a module is the same as compiling into a monolithic kernel. I disagree with him, but that is beside the point. The most important part of the situation to me is, both GPL licensed code and the ZFS code are FOSS. Worrying about that crap is best left up to lawyers. People are talking about the ZFS code like it is a Microsoft binary blob whose license agreement requires you to appoint Steve Ballmer as your child's guardian.
If you think on it, the free world's argument against proprietary software could be expressed as license incompatibility. (And let us not forget that Sun drafted the CDDL specifically to avoid inclusion in the kernel named Linux.) If they can get away with this GPL violation, what's to stop them (and others) with other GPL violations? Saying that people should ignore this and let lawyers work it out is essentially saying to ignore other people's copyright and licenses. Free software isn't just about being able to modify and share software, but about being able to LEGALLY do those things. Taking the position of ignoring problems like this begins to cast that in doubt if people aren't careful about making stuff that can be legally redistributed by others. If being able to do those things legally doesn't matter we may as well start hacking on proprietary software. Because who cares, right? "That crap is best left up to lawyers" and positioning that that it is not only unimportant to discuss but actually harmful to raise it as an issue. That is the problem raised by what Canonical is doing. It's an Ubuntu trademark violation to rebuild the kernel without ZFS, so you can't distribute Ubuntu without violating the GPL.
> If they can get away with this GPL violation, what's to stop them (and others) with other GPL violations?
That's overly paranoid. People get away with copyright infringement elsewhere all the time. The copyright industry has long known that it has to pick and choose its battles. That applies to us even more, because we don't have billions of dollars to sue everyone.
Also, copyright doesn't lose force because some other case of infringement is occurring. Suppose Canonical is infringing the GNU GPL and nothing is done about it. Suppose they then infringe the GNU GPL in the same way, but with proprietary software. Someone wishing to take action against the latter case doesn't lose standing in court because he didn't take action in the former case.
> Free software isn't just about being able to modify and share software, but about being able to LEGALLY do those things. Taking the position of ignoring problems like this begins to cast that in doubt if people aren't careful about making stuff that can be legally redistributed by others.
People are incredibly careless about copyright statuses outside of the libre software community, so I don't think minor license violations are going to "cast doubt" outside of our community. If anything, being so obsessed with being in perfect compliance with all licenses that we are willing to attack people solely for license violations, rather than using license violations as a basis to attack them for legitimately bad things (i.e. what copyleft is supposed to do), would probably make us look like obsessive-compulsive lunatics.
What's more, there's already a disconnect between at least the FSF's opinion on what the GPL permits and what the copyright holders of Linux allow to happen. Heck, what about proprietary drivers? I don't know much about Linux, but my understanding is ZFS is being used the same way proprietary drivers are, right? If I'm understanding this correctly, the thing being done with ZFS is already an established practice, the only difference here being that ZFS is not proprietary, just GPL-incompatible. So making a fuss about ZFS now is completely backwards.
> If being able to do those things legally doesn't matter we may as well start hacking on proprietary software. Because who cares, right?
But the actual code of Linux and ZFS isn't mixing. They're being linked together somehow, but they remain separate. Assuming the GPL is actually being violated, the violation is not going to spread to other code, realistically.
> It's an Ubuntu trademark violation to rebuild the kernel without ZFS, so you can't distribute Ubuntu without violating the GPL.
Sure, if it's actually a GPL violation. I remain skeptical of this assertion. But let's assume it is. Do you honestly think that anyone would actually have an incentive to start suing small distributors of Ubuntu for whatever pennies of "damages" can be collected from them based on this? Even if they do, how successful is such a campaign of malice realistically going to be? I'm sure there are much better attack vectors for innocent people than this, and some of them probably don't require already having a history contributing code to Linux.
"People get away with copyright infringement elsewhere all the time."
That doesn't make it right. Nor does it mean those those that call violators out on it should be chastised.
Ideally Oracle would change ZFS to a GPL-compatible license but I don't expect this to ever happen. The free world doesn't really look to Oracle for pro-freedom activities.
"Also, copyright doesn't lose force because some other case of infringement is occurring. Suppose Canonical is infringing the GNU GPL and nothing is done about it. Suppose they then infringe the GNU GPL in the same way, but with proprietary software. Someone wishing to take action against the latter case doesn't lose standing in court because he didn't take action in the former case."
I never said they did. The point that I was trying to make is that if this isn't a violation, then proprietary kernel modules aren't either.
"What's more, there's already a disconnect between at least the FSF's opinion on what the GPL permits and what the copyright holders of Linux allow to happen. Heck, what about proprietary drivers? I don't know much about Linux, but my understanding is ZFS is being used the same way proprietary drivers are, right? If I'm understanding this correctly, the thing being done with ZFS is already an established practice, the only difference here being that ZFS is not proprietary, just GPL-incompatible. So making a fuss about ZFS now is completely backwards."
Proprietary kernel modules are also a GPL violation so nothing's different: shipping zfs.ko is just as infringing as nvidia.ko was. In fact, please take note that they don't ship nvidia.ko because they were threatened with legal action in the mid-2000s. Canonical comparing zfs.ko to nvidia.ko was not a good idea, because they had effectively previously admitted that that was infringing. If your argument is that incorporating pre-compiled proprietary code is just fine with the GPL, your argument is bad.
"Do you honestly think that anyone would actually have an incentive to start suing small distributors of Ubuntu for whatever pennies of "damages" can be collected from them based on this?"
Proper GPL enforcement isn't about money but solely on achieving compliance. You should read up on https://sfconservancy.org/copyleft-compliance/principles.html
> That doesn't make it right.
I see we have a disagreement here. I don't consider copyright infringement itself to be unethical, largely because I advocate for the abolition of copyright.
> The point that I was trying to make is that if this isn't a violation, then proprietary kernel modules aren't either.
You talk bout GPL violation as if it's just a singular thing, but the question isn't whether someone has violated the GPL by distributing a version of ZFS that works with Linux. It's whether Canonical is violating the GPL. Based on what you say here:
> In fact, please take note that they don't ship nvidia.ko because they were threatened with legal action in the mid-2000s.
It sounds like it's not true at all that Canonical is violating the GPL with the Nvidia kernel module, because they're not distributing it. Would you say that's accurate?
I'm not entirely clear on how ZFS is being distributed for Ubuntu, which is both why I'm skeptical of the claim that they are violating the GPL and why i am not claiming that they are not. Matthew Garrett unfortunately chose to only link to a commit in a Git repository, which to me is completely meaningless.
But if what Canonical is doing with ZFS is not in violation of the GNU GPL, it doesn't follow that ZFS on Linux itself is not in violation of the GPL, and it doesn't follow that the Nvidia kernel module is not in violation of the GPL.
> Proper GPL enforcement isn't about money but solely on achieving compliance.
Yes, I know this, but you made a statement which suggested to me that you are concerned about Canonical's actions putting distributors of Ubuntu at risk. Malicious Linux copyright holders who would sue for the wrong reasons are the only potential risk to them I can think of.
Let me reiterate my position, in case it isn't clear:
- ZFS on Linux may be a GNU GPL violation. However, it should be noted that it's not a new one; it's been in development for years. It's also worth noting that the ZFS on Linux developers disagree: http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue
- Canonical may be violating the GNU GPL. This depends on whether ZFS on Linux is in violation of the GPL, and how it's being distributed for Ubuntu.
- Assuming both of the above two points are true, I still think it would be both a waste of resources and destructive for us to go after it the way we go after proprietary modifications of GPL programs. We need to focus our efforts on what actually matters. I'm not convinced that this is something that matters, because ZFS and ZFS on Linux are not proprietary, just GPL-incompatible.
- Just because we shouldn't fight Canonical on this doesn't mean we shouldn't discuss it. But discussions should be in the vain of "this is a bad idea", not "what you are doing is wrong". Unless you actually think that any copyright infringement is unethical (i.e. that copyright monopolies are morally a right that people deserve), in which case I disagree with you.
I wanted to point out that the Software Freedom Conservancy has published a blog post on this topic today: http://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/ and covers things like why the licenses are incompatible, how it doesn't matter if it's static or dynamically linked, etc.
And distributing them side by side and letting people combine them on their own? That argument didn't work when Steve Jobs tried it with GCC when he worked at NeXT. We saw how easily that fell over. On that sort of topic I especially liked their comment about how in that case "there may be arguments for contributory and/or indirect copyright infringement in many jurisdictions ... in our GPL litigation experience, we have noticed that judges are savvy at sniffing out attempts to circumvent legal requirements, and they are skeptical about attempts to exploit loopholes."
And since it's copyright infringement in both directions (violating both CDDL and GPL) Oracle's copyrights come to bear. This seems to validate the concerns I had expressed about casting doubt that that (referring to Oracle): "given its past willingness to enforce copyleft licenses, and Oracle's recent attempts to adjudicate the limits of copyright in Court. Downstream users should consider carefully before engaging in even source-only distribution."
"Mr. Ellison, tear down this wall!"
(For those that are too young to remember, they've been called the four most powerful words spoken in the 1980s: https://www.youtube.com/watch?v=YtYdjbpBk6A but imagine that that Reagan is the free world, "the wall" is the CDDL, and that Gorbachev is Larry Ellison, CEO of Oracle.)
I am a translator!
/home/gnu/Downloads/Pink Floyd - Tear Down the Wall - Part 1-deCjXe14y7E.mp4
Yet another proof that nothing original nor intelligent for that matter came out of Reginald.. :P
TEAR DOWN THE WALL!
I believe the ZFS on Linux project cannot change the license as it is a fork of the original and is bound to it. That is a shame, since ZFS is exceptional and having it on GNU/Linux would be a big deal. Especially since the more liberal BSD operating systems have it and if GNU/Linux vendors can move companies to their platform instead of BSD, they will.
In the end, ZFS is free software. It just has licensing issues if included with the restrictive GPL licenses of the kernel.
If you are going to fight Canonical on this, there are ways around it. They could just ship a dummy package on their Ubuntu ISOs and bring in the ZFS code on the next update. They wouldn't be shipping an ISO with kernel that violated the GPL (which is up for debate as ZFS is still free software) and since the code would be brought in later via an update, they could still advertise that Ubuntu supports ZFS.
FSF Issues Fresh Statement Over ZFS On Linux With GPL Enforcement: https://www.fsf.org/licensing/zfs-and-linux
Its a given at this point that Trisquel 8 will NOT have the zfs.ko module available by default. I'd like to see if the FSF statement has changed Canonical's mind in not having it by default, but maybe as a package in the repos that requires manual installation.
"Its a given at this point that Trisquel 8 will NOT have the zfs.ko module available by default."
You mean "at all." The GPL violation happens just by the distro distributing the software. Whether it's installed by default is beside the point. So yes, Trisquel will not be violating the GPL and won't have ZFS at all.
"I'd like to see if the FSF statement has changed Canonical's mind in not having it by default, but maybe as a package in the repos that requires manual installation."
Same as above: Being installed by default doesn't determine if a GPL violation is happening or not. Distributing the software does, and if it's in the Ubuntu repositories they're distributing for people to download regardless of if it's installed by default or not.
Removing ZFS packages entirely from the Trisquel repository would be taking it to the extreme as it is a FLOSS package after all. If a user chooses to manually install it, there should be nothing stopping them. It would be private use as defined by RMS via the "Privately, You Can Do As You Like" section at https://www.fsf.org/licensing/zfs-and-linux
"The GNU GPL has no substantive requirements about what you do in private; the GPL conditions apply when you make the work available to others"
"Removing ZFS packages entirely from the Trisquel repository would be taking it to the extreme"
Not at all. It is solving the GPL violation. Nothing less than that will. Even from the same article: "Developers often find this point not quite so self-evident with dynamic linking, but the situation is equally clear: if you distribute modules meant to be linked together by the user, you have made them into a combined work, and you must release the entire combined work under the GNU GPL."
So we're not talking about what someone does on their own but what the Trisquel project *distributes*. This is not the same thing, and the only solution to the distribution problem is not to be distributing it.
In the end, this will not affect Trisquel much as it is primarily used for the desktop. If a developer needs ZFS and chooses a GNU/Linux platform, it will likely be CentOS/Red Hat, Ubuntu, or one of the BSDs and not Trisquel. I'm sure you wouldn't care about that either since the majority of people here hate the concept of "cloud computing" and would rather everything be as it was with dedicated machines. I still think it was unnecessary on Canonical's end to ship a ZFS kernel module with their desktop version by default and should have put it into the server ISO.
I'm still not 100% in agreement over the compete purging of the ZFS codebase from the repositories. ZFS is free software, but there is a GPL incompatibility that keeps it out of the kernel tree. If you remove the ZFS packages (which would require the user to take action to install locally for private use), then that means you should remove all other free software from the repositories if it butts heads with the GPL. If you don't it makes you look silly and biased.
"ZFS is free software, but there is a GPL incompatibility that keeps it out of the kernel tree."
Just like a GPLv3 kernel module would be kept out. v2 and v3 are not compatible with each other, without the v2 stuff being upgraded to v3 via the "any later version clause." The kernel lacks that so it, too, would amount to a violation. You could still say that GPLv3 kernel module is free software but it doesn't change that the combination is still not allowed (and who does the linking doesn't matter, as the FSF explained in their article. So Trisquel can't get around that by saying "Oh, the user did it.") The incompatibility keeps it out of kernel.org and also stop Trisquel (and others) from being able to distribute it legally.
Why? Let's look at this another way: The software is copyrighted (both the kernel and the ZFS software.) Default copyright says you can't distribute things without violating the law. The licenses give you permission to distribute them, but only so long as you do what they say. Once you don't the license terminates (and with it, the permission.) If Trisquel continues to engage in the distribution post-termination, all you've really got is a case of someone distributing copyrighted stuff without permission. A classic copyright infringement case.
"If you remove the ZFS packages (which would require the user to take action to install locally for private use), then that means you should remove all other free software from the repositories if it butts heads with the GPL. If you don't it makes you look silly and biased."
Not all GPL-incompatible programs form a modified or extended version of the kernel so it isn't necessary to purge all GPL-incompatible software from the repositories as you propose. ZFS does, whether you personally believe it or not (The fact that you need a bunch of files from the kernel to satisfy the #include directives for successful compiling and that it uses internal kernel interfaces and not the system call interface all point to it being a derivative of the kernel and so subject to the GPL's requirements.) Trisquel can't legally distribute it without running afoul of both the GPL and CDDL and ending up in a situation of copyright infringement, as I explained. (The Software Freedom Conservancy explained why it's a violation of both licenses simultaneously.) But I don't expect you to believe them either. The FSF and Conservancy, the only organizations actively engaged in GPL enforcement (with their many years of experience and attorneys) are clearly wrong and you're right, huh? Ha!
Do you think RMS and the FSF are going to go after Canonical legally if they ship Ubuntu with the ZFS kernel? In the recent Linux Unplugged podcast (I posted the .webm link earlier), they talked to Alan Pope from Canonical about it. He didn't see it as a big deal and everyone is overreacting.
There was also some commentary from others during the show about how RMS and the FSF are actually being bullies about this. The whole "you will change your licence because I tell you to" approach that the FSF is using against Oracle will not hold up. Sun/Oracle licensed ZFS under the CDDL so it would keep it out of the Linux kernel as to not hurt their prior operating systems. Its funny that Solaris no longer exists and Oracle's "Oracle Linux" is merely a re-implentation of CentOS/Red Hat and they cannot include their own ZFS technology unless they change the license.
So will the Free Software Conservatory and the FSF go after Canonical? If they do not, then it opens the door to push around the GPL in the future as it will not hold up in court. If they do take Canonical to court, it will cause bad will between the camps and Canonical will fight back and try to take the FSF to the cleaners. The FSF will still look out of touch and overly controlling regarding the issue and will also be seen as hurting GNU/Linux adoption.
So we have here a criminal pleading not guilty. I don't think that's enough to close the case.
There are no bullies here. Canonical is the one breaking the law.
Also, only the copyright holder can go after infringers. What FSF is doing is only being consistent and upholding free software licenses.
- Inicie sesión o regístrese para enviar comentarios