Re: Simpler solution.
btrfs has been the default file system for SUSE for a few years now. Those Germans know what they are doing. I find btrfs is much more flexible than ZFS which I used to use before.
Free Software Foundation president and Gnu Public Licence (GNU GPL) author Richard Stallman has weighed in on the spat over whether Ubuntu can legally include ZFS in Linux, with a resounding “No!” Stallman has issued a statement he says “.... explains some issues about the meaning and enforcement of the GNU General Public …
The GPL and CDDL may be compatible anyway; it's never been tested in court. The version of the GPL under which the Linux kernel is licensed is rather poorly worded in this area. There's a long treatment of the linking question in ch 06 of Rosen's Open Source Licensing book at http://www.rosenlaw.com/oslbook.htm. In Rosen's opinion (which he says not to rely on, and may have changed since he wrote it), he doesn't think that the anti-linking aspects of the license will stick if things actually went to court. Canonical's lawyers seem to have come to a similar conclusion.
Although he may have written the original license, Stallman can't retrospectively change licensing terms relating to others' copyrighted code (e.g. Linux). Linux developers have licensed their contributions under a specific version of the GPL license. The developers could choose to relicense under a different version or license in theory, but in practice it would be essentially impossible to coordinate. Every single individual and corporate contributor would have to participate, and some wouldn't want to.
Essentially, the CDDL in this case says it's ok to create the combined work, and the GPL has the problem as if any GPL only symbols are used, that would be a "derivative" and require the ZFS code to be then GPL. As long as no GPL only symbols are used or used indirectly through a shim, then even per the GPL that would be a combined work and okay. It's all about how you define "combined work" vs "derivative work" and unfortunately, that requires arguing the breach of contract potentials before a judge.
Surely the only definition that is logical (asides from this API/symbol guff) is code that is derived from something GPL. A clean piece of code written to fit a known API shouldn't become tainted GPL purely by use of the API...?
Actually, yes it is. By using the GPL'd function, you've accepted that your code must also be GPL per the license terms. LGPL eliminates this potential. Check into the history of "EXPORT_SYMBOL_GPL" to see how the linux kernel has been effectively copyrighting it's API long before Oracle started making claims to the same effect. (Yeah that's gonna get downvoted but it's still true.)
That's also how I read Rosen's comments in the book. Hopefully judges deciding cases dealing with the issue will have as well, or at least assign one of their law clerks to. As I wrote further above, the problem in this particular area of law is that it isn't viewed by the judiciary are a specialty worthy of specialization on their part. Given what we all know to be the complexities involves, that's a prescription for unpredictability at best, disaster at worst.
> Capricious and a bit of an arsehole, but did something good once and now he won’t let anyone forget it.
Actually, I think he still does good.
The first thing to remember is that no-one, and I mean no-one*, "has" to write code and release it under GPL. That many people have chosen to embrace the GPL indicates that a great many people think it's "a good thing". Many of the people arguing that it's a bad thing tend to be doing so because it gets in the way of them "ripping off" someone's work and not "sharing".
I've met him, and yes he does come across as a bit of a tit. But although I disagree on some point, I respect his point of view, and I respect his integrity with it.
I'm a pragmatist myself - I use both closed non-free and open free software, both personally and for work. A foot in both camps as it were, and I can see the pros and cons both ways.
But one thing I am certain of, if it weren't for the "hardline" purists, the computing landscape would be a lot different. Even if you never use a single piece of software written with his purist views in mind, and quite possibly released under GPL, the very fact of their existence creates competition that keeps all vendors in check to some extent or other.
I suspect a few people are "too young" to remember when Microsoft seemed to have a complete and total lock on the desktop, on servers, and even on the web browser. Back then the "easy" thing to do would be to just accept that "Exploder 6" is "the standard" and work with that - it's only because enough people pushed back with open and interoperable standards that such a dominance got broken. I suspect fewer people still remember the "Unix wars" that turned something that was largely open (though not on an open licence) into a minefield of competing proprietary standards - and which in part contributed to Microsoft's rise to dominance.
Now, what's that saying about those who forget history being prone to repeat it ? Says I looking at what Red Hat (and others) are trying to do these days ...
* OK, you might argue that some people get paid to do so, but then they still made a decision at some point to take that job.
a great many people think it's "a good thing"
Argumentum ad populum. There have been one or two other ideas that "a great many people" thought were good things, and that others don't hold in such high esteem.
I suspect a few people are "too young" to remember when Microsoft seemed to have a complete and total lock on the desktop, on servers, and even on the web browser.
I've been a professional software developer for nigh onto thirty year, and I don't recall this grim era. We had viable desktop and server OSes before the Web (and thus the web browser) even existed. As, say, OS/2 on the desktop and commercial UNIXes on the server waned, Linux rose. At no point did Microsoft appear to have an overwhelming monopoly except to the ignorant.
Perhaps more importantly, there was a great deal of open source and the exchange of source code long before there was a GPL. It didn't have a fanatical ideology attached to it, but it existed nonetheless. Hell, binary-distributed proprietary software was still something of a relative novelty, having been common for only around a decade and a half at that point.
The GPL was revolutionary, but it was a cultural revolution: it spawned a movement of programmers who believed they were saving the world by doing something terribly daring and novel. But there's much less ground for arguing it really deserves much credit for the proliferation of open-source software. Linux could have been accompanied by a BSD userland just as easily, for example.
Simple Definition of capricious
: changing often and quickly; especially : often changing suddenly in mood or behavior
: not logical or reasonable : based on an idea, desire, etc., that is not possible to predict
God does not change:
Malachi 3:6 King James Version (KJV)
6 For I am the Lord, I change not; therefore ye sons of Jacob are not consumed.
"... why only others should change their licenses to make them GPL compatible?"
If someone wants to use GPL2 licensed code in their non-free proprietary product, it is they who are wanting, not the authors of the code they desire the use of. They can either deal with the terms of GPL2 or steal the code and try to conceal the theft by obfuscation, something which never works out well. If they steal it then they have hoisted the jolly roger and shown their true colours.
He has, but unfortunately he can't force people to use the newer, even more restrictive version.
One thing that's always struck me as odd about the GPL. The whole point is to give users more freedom, but it does so by putting shackles on the developers. How is it free software if it restricts the person putting all the effort into it?
No, he cannot change the licenses used for Linux.
He CAN offer a new GPL version (and there is one - version 3), but the Linux kernel cannot use it. It is set in GPL v2, and you can't get all of the authors to change their releases (some are even dead, so you have to wait another 90 years before the license can change).
Odd really. A lot of folk accept, and Linux distros offer, closed-source drivers for video and similar. Not a GPL violation it seems.
Where as ZFS is open-source and you can also modify it, hence in terms of the overall goals of GPL, a much better fit. But not compatible because? Because?
I'm guessing its something to do with linking in the kernel rather than loading a driver, but it seems a little odd and almost one of those religious-wars type of reasons (you know Catholic/Protestant, Sunni/Shia, little-end/big-end, etc)
Simple - the copyright holder, for example nVidia, can build and distribute binary blobs of their own code.
End users taking those binary blobs and loading them in their kernel does not violate GPL, though it does taint the kernel - see dmesg output after loading nvidia kernel module.
nVidia cannot, on the other hand, provide their source code to be included with the kernel unless said source code is also GPL licensed.
For Ubuntu to build and distribute binary blobs of ZFS, they would have to take ZFS source code, licensed under CDDL, and combine it with kernel source code licensed under GPL, which is not allowed under the terms of the GPL.
It is the act of distributing the resulting binary which is not allowed under the terms of the license in the first place, not users loading binary blobs of any source code license in their kernels.
The above is the reason ZFS on linux is only (for now) available as source code and users are required to build it them selves, and take the risk of being sued by the copyright holder as an individual.
"the copyright holder, for example nVidia, can build and distribute binary blobs of their own code."
"For Ubuntu to build and distribute binary blobs of ZFS, they would have to take ZFS source code, licensed under CDDL, and combine it with kernel source code licensed under GPL, which is not allowed under the terms of the GPL."
How is this different to what nVidia does? They must take their code, not under a GPL-compatible license, and "combine it with with" the kernel. Unless I'm missing something, they couldn't be distributing the binary blob without "combining it" with the kernel (i.e. compiling against the kernel).
When you compile the ZoL modules, you are creating a binary blob in the same way as nVidia. I really fail to see the distinction. If things worked the way this argument seems to suggest, anyone who released a binary kernel module would have to license it under GPL-compatible terms, and hence release the source code.
If there is a distinction, I'd love to see it.
"The difference is, and this should be obvious, is that, as the above states, nVidia is the copyright holder of the source code they used while Ubuntu are not."
Let's take a hypothetical.
I write a kernel module. The copyright is mine. I choose to distribute it under a commercial license, but it "links" to the kernel in the same way as ZoL. If what RMS and the FSF is saying is true, it would be classed as a derivative work and, therefore, would not be allowed to be distributed as a binary blob.
It doesn't matter who owns the copyright. The only thing that matters is that, if it is classed as a derivative work of GPL software, it must be released under the GPL or a compatible license.
Hence, the defining test is purely: Is it classed as a derivative work?
So what I would like to know is how the graphics card binary drivers differ from ZoL. There must be some material difference in the way it interacts with the kernel for it to fall foul of these license terms.
Once again - what you do with your own code is up to you. If _your_ code interfaces with GPL licensed code, _others_ cannot re-distribute binaries of _your_ code in any shape of form, though _you_ can.
Substitute you with either nVidia or Oracle. nVidia can and do distribute binaries. Others cannot and do not so they do not fall foul of the GPL. Same with ZoL.
Distribution is the constraint which you are, can only presume purposefully, ignoring.
"Distribution is the constraint which you are, can only presume purposefully, ignoring."
I am well aware that this would only apply if it is distributed. I am quite at liberty to take GPL code, modify it, mash it up with any other code I would like, and keep it for myself. However, if I (or anyone else) distribute it, this must be done under a GPL compatible license (if it counts as a derived work). I cannot distribute a derived work (to anyone), as a binary or as source code, unless it is under a GPL compatible license. If the nVidia drivers were classed as a derived work, they would not be allowed to distribute a binary driver under an incompatible license. It doesn't matter that they own the copyright: If it's derived, it's covered, if not, it's not.
Therefore, unless I am missing something (and I have done a lot of research on the GPL in the past), RMS and FSF are making a distinction that a ZoL binary module is a derived work, and yet for some reason nVidia's (and others') modules aren't. This is the distinction I would like to understand.
Last I checked, Linux distros can't ship with the binary nVidia blob. You have to get that elsewhere. It's not automatically included nor can they legally do so IINM. Same here. You can't pack ZoL in a Linux distro but have to go to outside channels, which poses a problem for turnkey solutions, especially offline ones.
Nobody tells Linux users can't use readily available Nvidia graphics card drivers. What GPL says and what Nvidia requires is that drivers should not be included in standard distribution. You as an end-user are free to use whatever driver/module may please but you must be careful if you try to distribute that module. Come on, folks, what's so hard to understand that Nvidia does not allow redistribution of their binary drivers ? GPL can't do anything about it but comply.
Many versions of the GPL license allow for closed source or non-GPL compatible code to be used with GPL if the two connect solely through a well-defined API or similar. This is generally how driver models are implemented and the license sees this as being different to the way that binaries are linked whether that's statically or dynamically.
Well, I'm not a lawyer (or I'd be skiing right now), but the whole "derivative work" argument around the GPL has always seemed to me to be tenuous.
Suppose I put together a library with some utility functions in it and make it available under the GPL. The GPL philosophy is that if I then write some software that makes use of those utility functions, then my software is automatically covered by the GPL - hence the existence of the LGPL without which most people probably wouldn't touch the library of utility functions with a bargepole.
However, suppose I write some application that requires a library with the same API as the GPL library of utility functions, but I don't bundle a copy of the GPL library and simply leave it to the user to supply a library of equivalent functions or write their own. Does my application get co-opted into the GPL in retrospect if and end-user chooses to link it with a GPL library? I doubt it, though since the Oracle v Google trial, I guess I could be done for infringing on the copyright in the API.
In the same way, I don't really believe that Linux drivers are a "derived work" any more than Windows drivers are - they're just bits of code making use of an API. I know that Linux has gone out of its way to avoid an API for binary drivers to encourage source availability, but there's no difference in principle between linking source code and binary code: they're both expressions of the same intellectual concept.
It seems like we're approaching a point at which this is going to have to be tested in court because uncertainty about the outcome of licence wars can only have a chilling effect on open software development.
Let's put aside GPL for a moment, OK ? Suppose you invent your totally free license and you download a binary proprietary module and include it in your work by any means you might think of. Now you start distributing your copyrighted work and for the part you wrote everything is fine. How about the proprietary one ? Do you have the legal permission to redistribute it and under which conditions ?
Put back GPL instead of your own license and see how does it change things ?
"However, suppose I write some application that requires a library with the same API as the GPL library of utility functions, but I don't bundle a copy of the GPL library and simply leave it to the user to supply a library of equivalent functions or write their own. Does my application get co-opted into the GPL in retrospect if and end-user chooses to link it with a GPL library?"
No. What people don't get about the GPL is that it only applies to *distribution*. What you do on your own computer isn't covered. You can well link proprietary software with even AGPL software as long as you don't provide such software as a service on the Internet [with a capital I. I'm a bit like Abe Simpson, I'll be deep in the cold, cold ground before I recognize the Internet with a small i].
Anyway this article is shite. It makes RMS appear much more an arsehole than he really is. If you read his thoughts on the matter, granted, he still comes across as a bit of a crafty git, but it's much more genuine: what he basically says is, FSF would kindly close an eye if it held Linux's copyright, but it doesn't; the GPLv2 is a bit too strict in this area, as the licence is formally terminated if breached, whereas the GPLv3 imposes a 60-day window to complain, after which the combined work is to be considered fair use, but Linux hasn't moved on the the GPLv3 so there you go. He doesn't even try to hide the fact that he would *love* to have copyright attributed to the FSF and that they should move on to GPLv3, but that's understandable, come on. :D
Care to mention at least one single Linux distro that distributes proprietary drivers in compliance with licensing terms of the IP owner ?
Second, ZFS is not compatible with GPL because Sun expressly wanted it so and something tells me Oracle is not in a hurry to change that.
All religions have their wild eyed prophet in the early days. But there comes a time when pragmatism takes the lead and the evangelists need to be retired to their hermit hole so new thinkers can bring the valuable core ideals to the world without the baggage.
License wars are the kind of stupidity we can do without, the key is whether the tech is free, open and works. Beyond that it's all arcane theology.
Biting the hand that feeds IT © 1998–2019