Well, it's not that easy.
The current situation si clear, if someone uses a binary Blob, then he taints the kernel and the Kernel - Devs are no longer responsible for anything that happens. (Terms of Support)
An Opensource kernel-Module with Binary Userspace has several security, stability and maintainability Problems.
What if a change in the in-Kernel-Interfaces propagated to the Opensource-Module causes strange behavior, because the writer of the binary part made several assumptions about the Kernel-Module which are no longer true?
What if the binary part causes some security-Risk to the whole kernel? - The kernel is NOT tainted if the module is Opensource!
So the kernel-Devs could be blamed for Errors caused by some binary Thingy which they have no control over!
And thus are only parts of the concerns.
The kernel evolves every day, countless changes and patches.
And while the devs work hard to keep the userspace API unchanged, this can not always be achieved and it may be necessary to sacrifice API-Stability for sanity and security of the whole Kernel itself.
And it would NOT be ok, if just the presence of some binary driver, which depends on some stable API in a DRM-Module, would keep the devs from making significant and beneficial changes to the whole infrastructure.
So i say, if the Devs have concerns, they know why!
There are some really good points and its a matter of trust, trust in companies that don't care about the kernel, and only look at their Profit. I would not let such ppl. control my box or the further development of Linux.
Who knows...maybe this binary thing makes screenshots of your desktop every 15 seconds and emails them to the NSA...who knows..?
Things are not always as obvious as they seem...
If only open source drivers have latest kernel functions, many people may consider buying hardware with documentation and FOSS drivers. If not, voting with the wallet effect would be negligible and everything will stay the same: suspicious binary blobs, no support for new kernels, X. So if the feature is only available in free drivers I see nothing wrong.
Originally Posted by Solitary
The "voting" you can basically forget due to the limited amount of Linux users. First Win drivers have to work, because that's what the masses are using. I think a 1% sales loss would not be that critical.
First off, VIA is not nVidia. Second VIA has us used to non working drivers, mostly. Third nVidia, although known for their binary blob, delivered a working driver most of the time.
Yet a renowned company that wants to work with GNU/Linux can hold their users like nVidia since their hardware holds a huge part of the market. Their users, who adopted GNU/Linux have currently no choice but accept such a large company to provide only a closed blob.
Personally, I don't mind nVidia to provide a blob as long as they're providing a fully working driver, which has by far proved excellent. I can cope with it but will never release my attention. I can cope with it doesn't mean I agree. I just understand and am thankful that they still provide such an excellent driver.
As far as VIA is concerned, I see no acceptable justification in letting them enter a free kernel driver that only a closed source graphics driver is able to use.
That reminds me the Intel Wireless 3945 episode, where there was a driver that was open source but with closed source daemon and firmware. Fortunately Intel «tidied» up the situation a bit by moving the proprietary code into the firmware.
This situation is similar indeed, although VIA doesn't either have the same market «dimension» as Intel. They just don't deserve an exception yet. Moreover a driver is either closed or free, not half closed nor half free. GNU/Linux wants free software.
VIA doesn't have the necessary resources to provide a full Free and Open Source driver? Well, take your time, we're not in a hurry, are we?
Originally Posted by Joe Sixpack
Off-topic: I don't usually mention things like this but "I could care less" is totally wrong and it annoys the hell out of me when I see it. You're basically saying the opposite of what you wanted to because you said "could" instead of "couldn't". If you *could* care less about something, then that implies you care a great deal about the issue and you have some way to go before you don't care. If you *couldn't* care less, then you don't care at all about the issue. I don't know where people got the idea that it was "could" and not "couldn't" but I see it everywhere, usually by Americans I think (maybe it's just another American butchering of the English language?). When said aloud it doesn't really matter but when written down it just looks stupid and makes no sense, especially to people whom English isn't their first language and perhaps don't know the proper phrase.
It's because the "n't" in Couldn't is easy to leave off or not hear in conversation. So a lot of people think it's "could", as wrong as it is.
Originally Posted by fat_chris
And yes, when I was young, I was very much confused the first time I heard someone say "I could care less".
Originally Posted by Joe Sixpack
If you have this opinion there isn't much more to say about this topic, but I just want to show that there is a notable percentage of people who do not care at all or that much about whether their software is FLOSS or not and just want to have their system running properly.
Funny... if Software works good no one care about where it was made and with which licenses or pieces of thought.
But if something goes wrong, even those who did not at all care before are shouting for someone to blame.
Nothing works for eternity if there is no one who maintains it. And this is a lot harder in Linux Area if software is not FLOSS. Also, ppl. who do not care about FLOSS, do not care about their future, the future of the system they use and depend on. And this is a very dangerous idea...
If ppl. care if FLOSS or not is not that important to the Devs. They just don't want to do syssiphos-work and being blamed for errors they can neither track nor fix.
I don't have a problem with an open-source DRM getting merged that happens to be used by closed-source DDX/OpenGL drivers. However, nothing should be merged solely on the basis of "the blob needs it"; there should be some reasonably solid assurance that it's a generally useful/necessary interface that could also enable an open-source driver. Otherwise, why should kernel devs accept responsibility for maintaining the interface?
If that binary blob were being executed by an IO processor on the card instead of by the main processor, then nobody would be complaining at all, even though the two scenarios are basically equivalent.
So the open source stance is: "If the closed-source code has to be run or loaded by the main processor, then it is BAD. If the same closed-source code is on a ROM chip, then it is perfectly okay."
There is no functional difference between a software binary blob and a hardware binary blob. Why do we insist on drawing a distinction?