Linked by Thom Holwerda on Tue 1st Aug 2006 17:50 UTC, submitted by Moulinneuf
Novell and Ximian In a change of heart, Novell has ceased distributing proprietary software modules such as 3D video drivers that plug into the Linux kernel. The change came with Novell's Suse Linux Enterprise Server 10, released in July. With the move, Novell is aligning itself with the Free Software Foundation, which shuns proprietary software in general but in particular loathes proprietary modules that run as a component of the open-source Linux kernel.
Order by: Score:
Bad decision
by Eugenia on Tue 1st Aug 2006 18:03 UTC
Eugenia
Member since:
2005-06-28

Worst decision ever. Novell is a company that sells a product. When this product doesn't do all it can do because of philosophical reasons, this is a good indication for me, the consumer, to stay the hell away from it. Why? Because instead of catter for ME (the consumer), it catters for RMS.

Reply Score: 1

RE: Bad decision
by monkeyfist on Tue 1st Aug 2006 18:08 UTC in reply to "Bad decision"
monkeyfist Member since:
2006-02-15

you want closed source software running uncontrolled in your otherwise open kernel? the heart of your machine? Use MS products then. Especially on a server- do you need
3d accel. on your servers? might as well click the free hotmail link in IE on windows server 2003(bah!)

Reply Score: 5

RE[2]: Bad decision
by Eugenia on Tue 1st Aug 2006 18:10 UTC in reply to "RE: Bad decision"
Eugenia Member since:
2005-06-28

Give me a break. They didn't only removed 3D drivers, but also NETWORK drivers. And yes, I DO want to run any driver that makes my hardware WORK. I don't give a flying monkey if it's open or closed.

Reply Score: 1

RE[3]: Bad decision
by somebody on Tue 1st Aug 2006 19:03 UTC in reply to "RE[2]: Bad decision"
somebody Member since:
2005-07-07

Give me a break. They didn't only removed 3D drivers, but also NETWORK drivers.

So? If you've bought your machine against HCL, yours weren't removed.

And yes, I DO want to run any driver that makes my hardware WORK. I don't give a flying monkey if it's open or closed.

Nobody is banning you to post install those.

And while some of you don't give a flying monkey about what kind of drivers you use, some of us do.

btw. Don't you think it is easier to add drivers than to remove? So this is completely right, ship clean so users like you can trash your OS and some have clean. Why would everybody have trashed and unclean system just for a few users like you?

Reply Score: 5

RE[4]: Bad decision
by Rocinante on Tue 1st Aug 2006 19:16 UTC in reply to "RE[3]: Bad decision"
Rocinante Member since:
2005-11-18

What are you trying to prove? Why should I have to round up all the drivers that might be proprietary BEFORE installing just because RMS doesn't like the idea of keeping them within reach or easily installable? Just do like ubuntu, asinine as it still may be IMO to do, and differentiate proprietary from free in software repos. If I need to go around getting drivers to make my hardware work, I might as well just go back to windows.

Reply Score: 2

RE[5]: Bad decision
by G. W. on Tue 1st Aug 2006 19:25 UTC in reply to "RE[4]: Bad decision"
G. W. Member since:
2006-03-17

> Just do like ubuntu, asinine as it still may be IMO to
> do, and differentiate proprietary from free in software
> repos.

This is exactly the wrong way. Ubuntu does exactly the wrong thing here.

Separating the drivers into their own repository is legally NOT an excuse. They are provided on Ubuntu webspace, so they are distributed by Ubuntu. The name of the FTP directory does NOT matter. Ubuntu becomes legally attackable this way. In other words, Ubuntu shares the legal risk with NVidia and ATI although NVidia and ATI should carry it alone.

> If I need to go around getting drivers to make my
> hardware work, I might as well just go back to windows.

Go ahead, nobody prevents you from doing that.

Reply Score: 5

RE[6]: Bad decision
by Rocinante on Tue 1st Aug 2006 19:31 UTC in reply to "RE[5]: Bad decision"
Rocinante Member since:
2005-11-18

-Separating the drivers into their own repository is legally NOT an excuse.-

It might not be legally, everywhere, but it's still a decent way to shut the zealots up who can't possibly survive unless their machine isn't "tainted" at all.

Everyone purchased software or downloaded freeware that wasn't GPL one time or another. It's no different. If it breaks the license to mix and match compiled code, then make so it works out. But to completely deny someone the software that is given away as freeware without trying to find a common ground just because of the FSF's extremist agenda is idiotic.

Reply Score: 1

RE[7]: Bad decision
by G. W. on Tue 1st Aug 2006 19:50 UTC in reply to "RE[6]: Bad decision"
G. W. Member since:
2006-03-17

> It might not be legally, everywhere, but it's still a
> decent way to shut the zealots up who can't possibly
> survive unless their machine isn't "tainted" at all.

Why do you disrespect the developer's position?

They are not "zealots", they are those who own the copyright. As opposed to public domain software, Linux is a copyrighted open source software project. It's not a user's decision to respect the copyright holders' position, users *must* respect it. It's a law.

> If it breaks the license to mix and match compiled
> code, then make so it works out.

Great proposal. Go ahead and implement a framework that allows 3D drivers to reside in the user space. It will be a lot of work, but the kernel people will probably happily accept it into the mainline kernel.

Those kernel people I know don't have any problem with proprietary software in general. They have a problem with proprietary code in the kernel because proprietary code in the kernel is just ugly.

Greg Kroah-Hartman (long-time Linux contributor, today a Novell employee) explicitly proposed using libusb for proprietary USB drivers. He doesn't want to kill proprietary drivers, he just wants to keep them out of the kernel.

Now go ahead and write something like libusb for the PCI bus and convince NVidia and ATI to use it. Novell will probably happily accept the resulting user-space driver and include it in all products.

> But to completely deny someone the software that is
> given away as freeware without trying to find a
> common ground just because of the FSF's extremist
> agenda is idiotic.

Please leave the FSF out of this discussion. The FSF doesn't contribute much to the Linux kernel (to the resulting operating system, yes, but not to the kernel). Just ignore FSF statements about the Linux kernel. What counts is the position of the actual Linux contributors.

Reply Score: 5

RE[6]: Bad decision
by zerblat on Tue 1st Aug 2006 19:44 UTC in reply to "RE[5]: Bad decision"
zerblat Member since:
2005-07-06

Actually, ATI and Nvidia aren't taking any legal risk at all. It is distributors such as Ubuntu, who are (arguably) distributing Linux and non-GPL modules together who are taking a risk. The risk is that the Linux copyright holders (any one of them) might sue for copyright infringement. Neither ATI nor Nvidia distribute Linux (AFAIK), so Linux developers wouldn't have any ground to sue them (since the GPL only restricts distribution).

Hopefully, this will put more pressure on hardware makers and give us better free drivers.

Reply Score: 2

RE[6]: Bad decision
by vimh on Tue 1st Aug 2006 21:46 UTC in reply to "RE[5]: Bad decision"
vimh Member since:
2006-02-04

AFAIK GPL says thay you even cannot link closed software with GPL libraries.

Then how would the drivers be legal regardless of whom distributed it be it hardware of software vendor? Ok, Nvidia provides a handy script that you download that when you run, compiles and links their blob. So Nvidia is off the hook here since they didn't link anything, the user did when they compiled the driver. So everybody who does this is inviolation of the GPL?

"Separating the drivers into their own repository is legally NOT an excuse."

So when does it become legal (ignoring the above compliled versus uncompiled driver question)? If the repository is on it's own independent server that doesn't use any GPL software?

So if I'm a distributor of a Linux distro, I'll build a separate BSD based server to host proprietary linux drivers. Brilliant!

Ok, so maybe that's kinda dumb. So that leaves you with downloading the drivers directly from the hardware vendors who aren't interested enough in them to provide a little bit of ease of use when installing.

It is ironic how Free as in Freedom becomes so restrictive.

While this move by Novel might be a step forward so far compliance with the GPL is concerned, it's a step backward for Linux adoption. This regression seems to be continuing.

Hardware vendors such as Nvidia and ATI aren't the only ones who need to open up a little. The GPL needs needs to play a little better with others.

Reply Score: 1

RE[7]: Bad decision
by G. W. on Tue 1st Aug 2006 22:36 UTC in reply to "RE[6]: Bad decision"
G. W. Member since:
2006-03-17

> So when does it become legal (ignoring the above
> compliled versus uncompiled driver question)?

Never. It's always a GPL violation.

> If the repository is on it's own independent server
> that doesn't use any GPL software?

No.

I think there might be a misunderstanding here. The good thing about the change is not that there is no GPL violation any more; it's still there. The good thing about the change is that Novell, a powerful Linux/OSS supporter, doesn't participate in it any more, and that the vendors of these drivers carry the legal risk alone without a Linux company helping them.

> So if I'm a distributor of a Linux distro, I'll
> build a separate BSD based server to host proprietary
> linux drivers. Brilliant!

Nonsense. The OS of the server where the modules are hosted does not matter. What matters is _who_ is hosting the modules.

> Tempest in a tea pot. This is philisophical, pure
> and simple, and most likely yet another symptom of
> the Ximian flu they caught a while back.

Stop whining about Ximian. Greg Kroah-Hartman, the person behind this policy change, _never_ had anything to do with Ximian. He started working for Novell long after the Ximian acquisition. And he was a major opponent of Non-GPL modules long before he went to work for Novell.

Those Novell kernel hackers with a Ximian background (e.g. Robert Love, who brought us inotify) seem to be pretty neutral about Non-GPL modules. The issue is completely _unrelated_ to Ximian.

Reply Score: 3

RE[5]: Bad decision
by somebody on Tue 1st Aug 2006 19:42 UTC in reply to "RE[4]: Bad decision"
somebody Member since:
2005-07-07

What are you trying to prove?

Exactly what I said. On the other hand I don't know what you want.

Why should I have to round up all the drivers that might be proprietary BEFORE installing just because RMS doesn't like the idea of keeping them within reach or easily installable?

Not RMS. GPL. And GPL is the license GNU/Linux is under

Just do like ubuntu, asinine as it still may be IMO to do, and differentiate proprietary from free in software repos.

When did I said that it shouldn't be like that. This is EXACTLY how it is supposed to be. Clean shipping version with trash excluded to a place which is easy accessible. But at least shipping version has to be clean.

Fedora has livna. Ubuntu has multiverse (although I have doubts about multiverse as part of ubuntu). Yes, I like that. But shipping versions already contaminated, NO THANKS.

If I need to go around getting drivers to make my hardware work, I might as well just go back to windows.

Not saying that, but if you demand on distro proprietary drivers maybe you should consider OpenSolaris or BSD. Both are under closed driver friendly license.

btw. This rather sad, you would rather see all people (a lot prefer free and clean) get windows like os, than install drivers.

/*PERSONAL*/
My only non-free piece of hw is NVidia (and even this one as proprietary only where I really need it), but as soon as first open spec graphic card pops out NVidia is history for me. I like NVidia, but I like open even more.

Edited 2006-08-01 19:44

Reply Score: 5

RE[3]: Bad decision
by G. W. on Tue 1st Aug 2006 19:07 UTC in reply to "RE[2]: Bad decision"
G. W. Member since:
2006-03-17

> Give me a break.

Sure. ;)

> They didn't only removed 3D drivers, but also
> NETWORK drivers.

Wrong. The 3D drivers were not removed, they were never included in any Novell product. There was nothing to remove.

There used to be a download solution for NVidia drivers (you could click a button in YaST to download and install the driver). This functionality was not removed, it was just changed in such a way that you have to opt-in explicitly before the package is displayed. And, most importantly, the driver now resides on NVidia/ATI webspace. This is an important difference, legally.

> And yes, I DO want to run any driver that makes my
> hardware WORK.

This is your position as someone who does mostly _use_ free/open source software. There are other people, people who _contribute_ to free/open source software. They, the contributors, are the copyright holders, not the users.

It is very unfortunate that Novell can't make your hardware work, but if it's not possible to it in a way that is accepted in the kernel community, it's not possible, sorry.

No problem: Use a Linux distro that doesn't care about upstream's feelings, like Ubuntu, Debian or Gentoo. Maybe they can continue distributing proprietary drivers for one or two more years, but sooner or later there will be a point where someone will sue them for infringing their copyright.

The GPL is a very simple license: Each work that is a derived work of a GPL licensed work must be licensed under the GPL. Kernel modules are a derived work of the kernel and have to be GPL licensed. If they are not, they are violating a copyright license, which is damn serious.

> I don't give a flying monkey if it's open or closed.

Then use a distro that doesn't give a flying monkey either. Ubuntu is very popular these days, try that.

Reply Score: 5

RE[4]: Bad decision
by sb56637 on Fri 4th Aug 2006 00:19 UTC in reply to "RE[3]: Bad decision"
sb56637 Member since:
2006-05-11

"Kernel modules are a derived work of the kernel and have to be GPL licensed. If they are not, they are violating a copyright license."

So the Nvidia 3D drivers are illegal, no matter where you get them from?

Reply Score: 1

RE[3]: Bad decision
by diegocg on Tue 1st Aug 2006 19:34 UTC in reply to "RE[2]: Bad decision"
diegocg Member since:
2005-07-08

And yes, I DO want to run any driver that makes my hardware WORK. I don't give a flying monkey if it's open or closed.


Then you may want to keep using propietary operative systems that don't cares about open source drivers, such as Mac OS X, Windows XP or BeOS. There's a reason why Linux/GNU exist, and it's freedom. I'm somewhat surprised that you're surprised that Linux developers try to avoid closed software. If Linux didn't care about freedom we'd have built a Windows Driver Model compatibility layer *long* time ago.

Edited 2006-08-01 19:38

Reply Score: 5

RE[4]: Bad decision
by linux-it on Tue 1st Aug 2006 20:58 UTC in reply to "RE[2]: Bad decision"
linux-it Member since:
2006-07-13

I have said this before Eugenia....

"And yes, I DO want to run any driver that makes my hardware WORK. I don't give a flying monkey if it's open or closed."

the fact is that you should get yourself hardware that is required to run your OS.

Everyone understands that in order to run Windows XP, you cannot get away with a C64.

So, if you really want to run linux (and I really doubt you tried hard enough to do this, given your reactions) you should do things beforehand.

regarding drivers -- the same happens to windows 2003 (I have said that before too) -- even with network drivers that only can be installed _after_ the OS runs.

And that windows 2003 installer stated "hey I do not have a driver for the network card. Shall I try to get it from the internet ?"

Talking about chickens and eggs, right ?

I feel you simply don't want to do _anything_ at all to get something running. All fine, but then you also shouldn't comment on things as they are not really appropriate, let alone correct.

See for instance the wifi drivers. They can be downloaded; nvidia/ATI drivers; they can be downloaded. It's all up to you.

Reply Score: 5

RE[3]: Bad decision
by rayiner on Tue 1st Aug 2006 22:01 UTC in reply to "RE[2]: Bad decision"
rayiner Member since:
2005-07-06

Very probably, Novell doesnt care either whether its open or closed. But theyre probably quite concerned about whether its legal or not...

Reply Score: 1

RE: Bad decision
by Maners on Tue 1st Aug 2006 18:08 UTC in reply to "Bad decision"
Maners Member since:
2005-07-26

this is rather not a philosophical reason, but more a legal reason. Propiretary modules cannot be distributed legally with GPLed software.

Reply Score: 5

RE[2]: Bad decision
by vimh on Tue 1st Aug 2006 18:23 UTC in reply to "RE: Bad decision"
vimh Member since:
2006-02-04

Legal reason? Isn't the whole idea that the proprietary drivers are linked to the kernal rather than compiled into it?

From what I understand, GPL2 does not state you cannot distribute non GPLed software with GPLed software. You justcan't compile your proprietary stuff into the GPLed code which is why they link it the drivers instead.

Reply Score: 5

RE[3]: Bad decision
by Maners on Tue 1st Aug 2006 18:53 UTC in reply to "RE[2]: Bad decision"
Maners Member since:
2005-07-26

AFAIK GPL says thay you even cannot link closed software with GPL libraries. That's why most UI toolkits such as GTK and QT are using LGPL license so that commercial software can use those toolkits. Therefore the binary drivers cannot be distributed with kernel. However, you can download and compile the binary driver module on your own. The drivers from nvidia/ati are half open - meaning the parts that interact with the kernel are open sourced, but the crucial parts that deal directly with hardware remain in a bianry form and that's how they are distrubuted on the manufactrer's sites. Once you build a kernel module out of them, you perform linking against GPL code and redistributing the reult of this is illegal. That's why we have software repositories such as livna which don't care that much about this legal issue (eg libdvdread).

Reply Score: 2

RE[4]: Bad decision
by aent on Tue 1st Aug 2006 18:59 UTC in reply to "RE[3]: Bad decision"
aent Member since:
2006-01-25

The QT is under the GPL and if you want to use it under a different license, you have to purchase a license from Trolltech, keyword being purchase. No non-GPL QT software can be released without a license from Trolltech. Thats why [nearly] all open source QT apps are GPL.

Reply Score: 1

RE[5]: Bad decision
by SEJeff on Tue 1st Aug 2006 19:24 UTC in reply to "RE[4]: Bad decision"
SEJeff Member since:
2005-11-05

And also the reason why most closed source Linux apps are gtk. Acrobat Reader, VMware, Realplayer to name a few...

Reply Score: 2

RE[5]: Bad decision
by zerblat on Tue 1st Aug 2006 19:55 UTC in reply to "RE[4]: Bad decision"
zerblat Member since:
2005-07-06

Qt is also licenced under the QPL which permits Qt to be used by software licenced under any open-source licence (i.e. even non GPL-compatible ones).

Reply Score: 2

RE[3]: Bad decision
by fithisux on Wed 2nd Aug 2006 07:59 UTC in reply to "RE: Bad decision"
fithisux Member since:
2006-01-22

Good move!!! They have a product to sell. If a driver module makes the user's system unusable, they are indirectly responsible. Right move, shows how big qquality SUSE Linux has. That is why I bought my SUSE 10.1

Reply Score: 2

RE[2]: Bad decision
by BluenoseJake on Wed 2nd Aug 2006 16:57 UTC in reply to "RE: Bad decision"
BluenoseJake Member since:
2005-08-11

It is not illegal to ship closed drivers if they link into the kernel, only if they are COMPILED in, there is a difference, and a big one

Reply Score: 1

RE: Bad decision
by vimh on Tue 1st Aug 2006 18:13 UTC in reply to "Bad decision"
vimh Member since:
2006-02-04

Agreed. While I'd love to have entirely open code, one thing I like more is for my hardware to be well supported. If I have to use closed drivers to do it, so be it.

If I'm using OpenSuse, everything should be open. I'll take care of the proprietary stuff myself. But if I'm paying for the Suse Desktop, I want the package to work out of the box.

Reply Score: 5

RE[2]: Bad decision
by gustl on Wed 2nd Aug 2006 11:27 UTC in reply to "RE: Bad decision"
gustl Member since:
2006-01-19

"But if I'm paying for the Suse Desktop, I want the package to work out of the box."

Actually, it does!

With the Suse Dektop you pay for, the package manager just asks you, if you really want to install the non-GPLed modules, then downloads them from the VENDOR-CONTROLLED server and installs them on your machine.

This way all the legal risks are taken by the driver-manufacturers, but for the user it is only a small difference in the installation process.

Reply Score: 1

RE[3]: Bad decision
by kittynipples on Wed 2nd Aug 2006 13:09 UTC in reply to "RE[2]: Bad decision"
kittynipples Member since:
2006-08-02

"Works out of the box" does not mean "will download required drivers during/after installation." If you can't get your NIC working because the drivers weren't included, then you aren't going to be doing too much downloading.

Reply Score: 1

RE: Bad decision
by raxtor on Tue 1st Aug 2006 18:13 UTC in reply to "Bad decision"
raxtor Member since:
2006-03-20

<quote>Instead, Novell software automatically gives customers the "option to download drivers," a method that "also gives the responsibility for drivers to the vendors, which is where it belongs," Dyroff said.</quote>

So Novell gives the zealots one excuse less to shun their product, while automagically offering their customers the latest and supposedly greatest drivers directly from the vendor. I fail to see how this is bad for YOU the consumer.

Reply Score: 4

RE[2]: Bad decision
by Eugenia on Tue 1st Aug 2006 18:23 UTC in reply to "RE: Bad decision"
Eugenia Member since:
2005-06-28

Working out of the box is different than "working later". Especially if there are network drivers that you need to manually download and you don't have drivers to connect to begin with. Some users will end up in the chicken and the egg problem.

Reply Score: 1

RE[3]: Bad decision
by Sphinx on Tue 1st Aug 2006 18:34 UTC in reply to "RE[2]: Bad decision"
Sphinx Member since:
2005-07-09

Name one single closed source network driver that's not in the kernel. Any practical example at all or are we just stirring anti-novell FUD here?

Reply Score: 5

RE[4]: Bad decision
by Eugenia on Tue 1st Aug 2006 18:40 UTC in reply to "RE[3]: Bad decision"
Eugenia Member since:
2005-06-28

from the article: "some software-based modems, and ISDN networking equipment from AVM"

Reply Score: 1

RE[5]: Bad decision
by postmodern on Tue 1st Aug 2006 20:55 UTC in reply to "RE[4]: Bad decision"
postmodern Member since:
2006-01-27

So we're really talking about a small segment of installs that will require extra work due to Novell's "shunning".

Also one could load in the cdrom with the proprietary drivers that the company carefully prepared (which was packaged along with the hardware), modprobe the module or run some install script? I fail to see how this is a serious issue, and not a minor change due to the legal requirements of the GPL that Linux users are already used to living with.

Reply Score: 3

RE[4]: Bad decision
by anonymous_coward on Tue 1st Aug 2006 21:05 UTC in reply to "RE[3]: Bad decision"
anonymous_coward Member since:
2005-11-15

Name one single closed source network driver that's not in the kernel

madwifi -> http://www.fsf.org/resources/hw/net/wireless/cards.html

...and yes, I'm really happy that Novell bans proprietary Linux modules ;)

Reply Score: 1

RE[4]: Bad decision
by kittynipples on Wed 2nd Aug 2006 13:02 UTC in reply to "RE[3]: Bad decision"
kittynipples Member since:
2006-08-02

yeah, my Belkin Wireless G USB Network Adapter. I've also never been able to get my NetGear WG311v2 working without having to struggle through the NDISWRAP configuration game.

Or are these not specific enough for you?

Reply Score: 1

RE[3]: Bad decision
by rhavenn on Tue 1st Aug 2006 21:50 UTC in reply to "RE[2]: Bad decision"
rhavenn Member since:
2006-05-12

Yeah, I have a HP dv8000 laptop. Windows XP will NOT install on it (it doesn't even see the hard drives) unless I purchase a external USB floppy drive and download the SATA drivers for it because XP is too brain dead to read drivers from a CD much less actualy have the drivers on the install CD itself. What a piece of shit OS Windows XP must be according to your anology. Yes, Gentoo installs just fine out of the box with no extra drivers needed. Yes, if I disable SATA and use legacy IDE mode I can install XP as well, but I shouldn't have to. Try explaining that to Joe User.

Reply Score: 2

RE[4]: Bad decision
by DrillSgt on Tue 1st Aug 2006 23:40 UTC in reply to "RE[3]: Bad decision"
DrillSgt Member since:
2005-12-02

"Yeah, I have a HP dv8000 laptop. Windows XP will NOT install on it (it doesn't even see the hard drives) unless I purchase a external USB floppy drive and download the SATA drivers for it because XP is too brain dead to read drivers from a CD much less actualy have the drivers on the install CD itself."

Ermmm..you do know that you bought that laptop with Windows XP installed on it..right? And that if you were to use the CD's that came with it to restore your installation the drivers are slip streamed on it so it works..right? Just checking....

Reply Score: 1

RE[3]: Bad decision
by Bink on Tue 1st Aug 2006 21:51 UTC in reply to "RE[2]: Bad decision"
Bink Member since:
2006-02-19

If the hardware specifications were open and free to open source developers, it is likely your hardware would work "right out of the box" to begin with. "Open your eyes" and realize this benefits YOU (the consumer).

This is great news--seeing a commercial entity value openness. I look forward to more open hardware specifications and better supported hardware.

Reply Score: 4

RE[2]: Bad decision
by aent on Tue 1st Aug 2006 19:05 UTC in reply to "Bad decision"
aent Member since:
2006-01-25

When this product doesn't do all it can do because of philosophical reasons, this is a good indication for me, the consumer, to stay the hell away from it.
NO! They aren't doing this for philosophical reasons. Its for business reasons. They are unable to support binary proprietary modules as they can't view the soruce and debug issues with it. They're forced to support the software by contacting the other companies and hoping they fix the issues.

This should hopefully accelerate the creation of FOSS video drivers for ATI and NVIDIA cards. If that is done, its a win for EVERYONE, hell, including NVIDIA and ATI.

As said previously, the drivers are still available for SuSE, just not included.

Reply Score: 5

RE: Bad decision
by segedunum on Tue 1st Aug 2006 19:16 UTC in reply to "Bad decision"
segedunum Member since:
2005-07-06

When this product doesn't do all it can do because of philosophical reasons, this is a good indication for me, the consumer, to stay the hell away from it.

I strongly suspect that the reason why Novell has done this is not because they believe in the GPL or want to pander to the FSF, but because of legal reasons. They just seem to be scared or something. They've been steadily doing this for some time with certain drivers being moved further and further away from where a user can get at them.

Now, certainly the nVidia drivers are as legal as they possibly can be (not familiar with ATI's). Linus would rather they developed within the kernel, but nevertheless, he's acknowledged that they can do it the way that they're doing it.

The thing I don't understand is where does this leave their fancy 3D desktop with no 3D drivers? Or does this magically not apply to the desktop?

Reply Score: 3

RE[2]: Bad decision
by Thom_Holwerda on Tue 1st Aug 2006 19:27 UTC in reply to "RE: Bad decision"
Thom_Holwerda Member since:
2005-06-29

The thing I don't understand is where does this leave their fancy 3D desktop with no 3D drivers? Or does this magically not apply to the desktop?

Read the article. You are presented with a three-click download process to install either the ATI or nVIDIA drivers. I mentioned that in my review too.

Reply Score: 1

RE: Bad decision
by postmodern on Tue 1st Aug 2006 20:45 UTC in reply to "Bad decision"
postmodern Member since:
2006-01-27

Worst... head-line... ever...

Although customers can still install proprietary modules on their own, Novell's ban reflects a new balance between the open-source and proprietary realms.

They are not BANNING propriatery (or tainted) modules, they will not SHIP them pre-installed. One will boot up their SLED10 with default Xorg drivers and have to download their drivers of choice from the intertubes.

How many OSs can you count that have the latest ATi/Nvidia/Creative/Logitech drivers installed by default (or provided by a package manager by default)? Distros that do, such as Gentoo, are no more popular than distros that shun propritary software. That said, shuning of propritary software is an annoyance at most, not a pox upon ye Distro.

Edited 2006-08-01 20:46

Reply Score: 5

RE[2]: Bad decision
by Thom_Holwerda on Tue 1st Aug 2006 20:50 UTC in reply to "RE: Bad decision"
Thom_Holwerda Member since:
2005-06-29

They are not BANNING propriatery (or tainted) modules, they will not SHIP them pre-installed.

Yes. So, Novell banned proprietary drivers from its products. Conclusion: headline is correct. Whatever the hell you as a user to afterwards is irrelevant to the question.

Reply Score: 1

RE[3]: Bad decision
by JeffS on Tue 1st Aug 2006 21:13 UTC in reply to "RE[2]: Bad decision"
JeffS Member since:
2005-07-12

"Yes. So, Novell banned proprietary drivers from its products. Conclusion: headline is correct. Whatever the hell you as a user to afterwards is irrelevant to the question."

The word "ban" means you can't use said item at all, under any circumstances.

Novell is merely ending the shipment of proprietary drivers in the default install of their GPL'd Linux OS. It is then allowing obtaining the drivers, and installing them on the OS, from the hardware vendors.

That is not, I repeat NOT banning proprietary drivers, period.

Yes, a symantec argument. But the headline is very very misleading. So it's a very important distinction.

But, hey, it's ensuring lot's of hits, and subsequent posts. So more power to you!

Reply Score: 5

RE[4]: Bad decision
by Thom_Holwerda on Tue 1st Aug 2006 21:36 UTC in reply to "RE[3]: Bad decision"
Thom_Holwerda Member since:
2005-06-29

The word "ban" means you can't use said item at all, under any circumstances.

There are more words in the headline than just "to ban". You see, sentences, even crippled ones like headlines usually are, constitute of a sucject, a verb, and an object. You imply the "you" as the subject, but it is not. "Novell" is.

The key word here is Novell. Novell has removed all proprietary modules from its Linux products. By saying that Novell has banned proprietary modules, it is ment to convey the message that Novell, under no circumstances, will be shipping proprietary modules.

That has NOTHING to do with Novell's users, since they do not appear as part of the sentence. You would have a point if the headline had said: "Novell Bans Proprietary Modules for All Users and Makes it Impossible to Install Them by Making Your Computer Explode As Soon As You Type 'modprobe'.

Get it?

Reply Score: 1

RE[5]: Bad decision
by subterrific on Tue 1st Aug 2006 22:05 UTC in reply to "RE[4]: Bad decision"
subterrific Member since:
2005-07-10

The headline is a bit sensationalist and makes the reader think Novell is banning use of proprietary modules with their distribution. This is the author trying to grab the readers attention. If the headline was something bland and informative like "Closed Modules Removed From Novell Linux, Still Installable", would you have even read the article? I wouldn't have.

Reply Score: 5

RE[5]: Bad decision
by kernelpanicked on Wed 2nd Aug 2006 00:02 UTC in reply to "RE[4]: Bad decision"
kernelpanicked Member since:
2006-02-01

Ya know Thom, you and Eugenia really need to allow your posts to be moderated, if you're going to insist on posting inflammatory comments on every article. I post things that are not exactly P.C. all the time, but at least I have the nerve to handle the consequences of my own actions.

Reply Score: 3

RE[6]: Bad decision
by linux-it on Wed 2nd Aug 2006 14:44 UTC in reply to "RE[5]: Bad decision"
linux-it Member since:
2006-07-13

and I fully agree with that !

Reply Score: 1

v RE[5]: Bad decision
by h_t_r on Wed 2nd Aug 2006 05:18 UTC in reply to "RE[4]: Bad decision"
RE[3]: Bad decision
by postmodern on Tue 1st Aug 2006 22:42 UTC in reply to "RE[2]: Bad decision"
postmodern Member since:
2006-01-27

They are not BANNING propriatery (or tainted) modules, they will not SHIP them pre-installed.

Yes. So, Novell banned proprietary drivers from its products. Conclusion: headline is correct. Whatever the hell you as a user to afterwards is irrelevant to the question.


FTA...

Instead, Novell software automatically gives customers the "option to download drivers," a method that "also gives the responsibility for drivers to the vendors, which is where it belongs," Dyroff said.

How is it a BAN, when you give the users the option of circumventing it?

Edited 2006-08-01 22:55

Reply Score: 5

RE: Bad decision
by g2devi on Tue 1st Aug 2006 20:56 UTC in reply to "Bad decision"
g2devi Member since:
2005-07-09

It's not merely a philosophical decision, it's also a legal decision (compliance with the GPL) and a support issue. Quite simply, if there's a problem with a closed source kernel module, Novell won't be able to support it and if that closed source has unintended side effects (like buffer overflows or updating internal datastructures), Novell could be spending a lot of time tracking down a problem it thinks is in the kernel when in actuality is in the closed source module.

By shunning closed sourced modules, Novell is simplifying it's support structure. You can run Novell with the closed source modules, but it's a "use at your own risk" deal (precisely because if you use closed source modules, Novell can guarantee nothing).

Reply Score: 3

RE: Bad decision
by gilboa on Tue 1st Aug 2006 21:27 UTC in reply to "Bad decision"
gilboa Member since:
2005-07-06

"Worst decision ever. Novell is a company that sells a product. When this product doesn't do all it can do because of philosophical reasons, this is a good indication for me, the consumer, to stay the hell away from it. Why? Because instead of catter for ME (the consumer), it catters for RMS."

This has -nothing- to do with RMS, and everything to do with the GPL:
Like it or not, using binary module inside the kernel breaches the GPL ("Copying and distributing - section 2b") which is the heart of the OSS movement.
Even if you don't agree with the above (read: you consider binary modules to be fair play as long as their kABI-wrapper is exposed - E.g. nVidia), looking at the GPL as if it was a mere "philosophical" issue strikes me as -very- odd.

Don't get me wrong, in my view there is no right and wrong in this story: I write Kernel modules that will be immediately ported to BSD/etc if "GPL-or-die" is enforced on all kenel modules.
Never the less, I accept the right of the kernel devs to enforce the GPL, to the full extent, on anyone writing Linux kernel modules.

Novel, like RedHat before them, most not abuse the foundation on which they build their business on.

G.

Reply Score: 1

There's another reason
by JoeBuck on Tue 1st Aug 2006 21:41 UTC in reply to "Bad decision"
JoeBuck Member since:
2006-01-11

For a Linux-based company like Novell or Red Hat, all you are selling when you sell free software is support. However, if you have big hairy blobs of non-free software in your kernel, there's little you can do when the thing crashes intermittently, because you can't debug the code. You don't have the code. For that reason, Novell is better off making clear to their customers that the non-free code is not part of what is supplied by Novell; they can get it on their own and support it on their own.

Reply Score: 2

RE: Bad decision
by Jeroenverh on Tue 1st Aug 2006 22:42 UTC in reply to "Bad decision"
Jeroenverh Member since:
2006-05-21

I belief it's a real good decision. Hope that every driver will become open source. That's the way to go.
It's good for the development of the Linux kernel and good for the security.
For me, as a user, it's a reason to choose Novell.

Reply Score: 1

hmmm...
by Flatline on Tue 1st Aug 2006 18:17 UTC
Flatline
Member since:
2006-03-06

Could this also be a function of Novell's linux indemnification program?

Reply Score: 2

Not really a big deal
by Lambda on Tue 1st Aug 2006 18:38 UTC
Lambda
Member since:
2006-07-28

Novell just recognizes that Linux will never be a mainstream consumer-oriented desktop. The people that buy Suse don't really care about 3d drivers.

Reply Score: 1

RE: Not really a big deal
by jessta on Wed 2nd Aug 2006 01:07 UTC in reply to "Not really a big deal"
jessta Member since:
2005-08-17

Maybe they are hoping that by less distrobutions distributing the closed source drivers that the hardware manufacturers will be forced to open up the code. Therefore creating a better product.

These manufacturers rely on the attitude of "I don't care if they are closed source, as long as they work" to keep their product both marketable and closed source.

Freedoms are like insurance(or backups), you don't really need them as long as nothing goes wrong. But you'll be glad you had them when it does.

eg. You currently rely on Nvidia to create and fix bugs in binary only driver for their hardware.
There are bugs in an older version of the driver for your particular hardware and Nvidia isn't going to fix them because they say you should just upgrade to the latest product. This is probably fine if you have a single system. But what about if you had 1000 systems with that same hardware.

Reply Score: 3

RE[2]: Not really a big deal
by Lambda on Wed 2nd Aug 2006 08:25 UTC in reply to "RE: Not really a big deal"
Lambda Member since:
2006-07-28

Maybe they are hoping that by less distrobutions distributing the closed source drivers that the hardware manufacturers will be forced to open up the code. Therefore creating a better product.

No, nobody is going to force the hardware manufacturers to do anything. All it does is ensure that Linux will never be a mainstream desktop OS. And of course Linux doesn't have a stable API (I don't care what the reasons are), so you'll never have drivers out of the box for your hardware.

Oh well, maybe one of the BSDs or Solaris or OSX will be able to give Windows some competition, because Linux sure isn't going to.

Reply Score: 1

RE[3]: Not really a big deal
by Ookaze on Wed 2nd Aug 2006 09:18 UTC in reply to "RE[2]: Not really a big deal"
Ookaze Member since:
2005-11-14

No, nobody is going to force the hardware manufacturers to do anything. All it does is ensure that Linux will never be a mainstream desktop OS

Having no imagination and a closed mind doesn't make you right.
Nobody is going to force the hardware manufacturers to do anything, which doesn't mean nothing can.
Especially, money lost and market share lost has forced manufacturers like HP or Intel to release Open Source drivers for Linux servers.
The same will happen with the desktop. When some company order 1,000s of Linux desktops, and so choose supported hardware, some manufacturers start to notice.

And of course Linux doesn't have a stable API (I don't care what the reasons are), so you'll never have drivers out of the box for your hardware

So the current situation is a fantasy ?
The stable API has nothing to do with the availability of drivers or not. Linux has plenty of drivers that work despite the unstable internal API, so a company can make one without problem. NVidia does. The true problem is not unstable API, but people prefer closing their eyes on the true problem. They don't want to admit that the manufacturer is the problem.

Oh well, maybe one of the BSDs or Solaris or OSX will be able to give Windows some competition, because Linux sure isn't going to

Linux is already doing that since years (yes, even on the desktop), it's amazing you never noticed. Living in denial or in a cave doesn't make your point right either.

Reply Score: 1

v RE[4]: Not really a big deal
by Lambda on Wed 2nd Aug 2006 17:38 UTC in reply to "RE[3]: Not really a big deal"
v Tears
by JMcCarthy on Tue 1st Aug 2006 18:55 UTC
Good
by Symgeosis on Tue 1st Aug 2006 19:35 UTC
Symgeosis
Member since:
2005-09-13

I don't see this development as a bad thing at all. The only thing that consistently breaks on my box happens to be the propriety drivers. This is why I stick with open source drivers now.

Reply Score: 5

RE: Good
by MrEcho on Tue 1st Aug 2006 20:18 UTC in reply to "Good"
MrEcho Member since:
2005-07-07

And what drivers would that be, and how do they break?

Reply Score: 0

RE[2]: Good
by macisaac on Tue 1st Aug 2006 22:22 UTC in reply to "RE: Good"
macisaac Member since:
2005-08-28

well I've had "fun" with the ati fglrx drivers (particularly when dri is enabled, which is most of the point of even using them...) causing kernel panics, freezing the box and neccessitating and a hard reset.

you don't get that using the stock xorg provided drivers.

Edited 2006-08-01 22:29

Reply Score: 3

RE[3]: Bad decision
by sbenitezb on Tue 1st Aug 2006 19:47 UTC
sbenitezb
Member since:
2005-07-22

Then go the Microsoft way. Those of us who use Linux use it because it's open source. If you have some hardware that doesn't have any open source driver, then it's your fault for not buying Linux compatible hardware. Go cry elsewere.

Reply Score: 5

RE[4]: Bad decision
by aent on Wed 2nd Aug 2006 04:18 UTC in reply to "RE[3]: Bad decision"
aent Member since:
2006-01-25

Who says everyone uses Linux because its open source? I use Linux because I believe its easier to use. I don't believe its anyone's fault for buying hardware thats not Linux compatible, its not right to blame the user. I do support Novell's move, but please don't classify all Linux users as people using it just because its open source. I use it because its the most flexible, powerful, and easy to use operating system out there IMO.

Reply Score: 3

RE[2]: Bad decision
by sbenitezb on Tue 1st Aug 2006 19:49 UTC
sbenitezb
Member since:
2005-07-22

"If I'm using OpenSuse, everything should be open. I'll take care of the proprietary stuff myself. But if I'm paying for the Suse Desktop, I want the package to work out of the box."

Well, if you apply the same to Microsoft, you still don't get it to work out of the box. Allow me to lol while you call Microsoft to request them anything you didn't get with the box.

Reply Score: 4

RE[5]: Bad decision
by sbenitezb on Tue 1st Aug 2006 19:52 UTC
sbenitezb
Member since:
2005-07-22

"from the article: "some software-based modems, and ISDN networking equipment from AVM""

Oh come on, are you serius? Software based modems are winmodems. Note the win in the name. Who's using winmodems today in the era of broadband?

Reply Score: 4

One foot in the grave
by moleskine on Tue 1st Aug 2006 20:06 UTC
moleskine
Member since:
2005-11-05

I suspect this is Novell just currying favour with the right-on vote, in other words a marketing issue really. Novell are so far behind Red Hat in the enterprise market - a 4 to 1 margin, I believe - they must be getting desperate enough to try anything.

In other news, I have stopped distributing SuSE binaries on my own hard disk since Novell got their hands on it because a) I don't like the new name, OpenSuSE, not least because it isn't open at all but a closed corporate non-community; b) SuSE has been getting harder not easier to use; and c) the package selections have been shrinking with each new release.

I now use Debian which has the inestimable advantage that it doesn't just not care about me, as a consumer, it doesn't care about anybody at all.

Reply Score: 2

RE: One foot in the grave
by G. W. on Tue 1st Aug 2006 20:14 UTC in reply to "One foot in the grave"
G. W. Member since:
2006-03-17

> I suspect this is Novell just currying favour with the
> right-on vote, in other words a marketing issue really.

Wrong. Marketing-wise, this decision is a disaster because it means a regression in hardware support. Doing this step as a marketing issue would be plain stupid.

> Novell are so far behind Red Hat in the enterprise
> market - a 4 to 1 margin, I believe - they must be
> getting desperate enough to try anything.

Wrong. Doing this - which actually means, less hardware support than before - is not a desperate try and it has nothing to do with Red Hat.

OK, actually it has something to do with Red Hat: Red Hat was in a position of legal security and Novell was not. Now it is.

> a) I don't like the new name, OpenSuSE, not least
> because it isn't open at all but a closed corporate
> non-community

As a proud member of the openSUSE community, maintaining packages in the openSUSE build service, I politely ask you to stop talking about things you don't know at all. Get a clue first.

> c) the package selections have been shrinking with
> each new release.

This is not true. You have obviously never counted the packages in the tree.

After opening up the tree, there are now more packages in the Factory tree than ever before because SUSE now has the opportunity to offer all packages including those which were maintained, but unpublished in the past because they were not commercially supportable.

Reply Score: 5

RE[2]: One foot in the grave
by moleskine on Tue 1st Aug 2006 21:10 UTC in reply to "RE: One foot in the grave"
moleskine Member since:
2005-11-05

As a proud member of the openSUSE community, maintaining packages in the openSUSE build service, I politely ask you to stop talking about things you don't know at all. Get a clue first.

I've used every edition of SuSE continuously since 2000, though I now keep it on a spare partition, as a back up, and use Debian instead. I think I have a pretty good idea of what I am talking about.

Please don't tell me that SuSE support has gotten better in the past couple of years from the POV of the single user, because it has not. Novell need to draw in a much larger and more involved community of users, and to do that they need to drop the control freakery and the presentation of a "community" distro that isn't. Otherwise folks might conclude that calling it OpenSuSE was something of an own goal. Just my 2 cents of course.

As for Novell being incapable of marketing mistakes ...

Reply Score: 1

RE[2]: One foot in the grave
by mbkumar on Wed 2nd Aug 2006 07:45 UTC in reply to "RE: One foot in the grave"
mbkumar Member since:
2006-06-28

Why the heck SUSE never includes Fortran compiler in the DVD? With SLED 10, its worse. The updater always tries to delete the gfortran package installed from openSUSE repos.

Reply Score: 0

RE: One foot in the grave
by IanSVT on Tue 1st Aug 2006 20:21 UTC in reply to "One foot in the grave"
IanSVT Member since:
2005-07-06

I suspect this is Novell just currying favour with the right-on vote, in other words a marketing issue really. Novell are so far behind Red Hat in the enterprise market - a 4 to 1 margin, I believe - they must be getting desperate enough to try anything.

The Enterprise Linux market, not the enterprise market. They still have a huge customer base on older proprietary software offerings which are slowly being moved over to the linux model, many of which are offerings Red Hat can't come close to matching at this point in time. Current NetWare shops are reluctant to move to OES Linux because it isn't up to snuff yet. OES2 might change that, but we will have to see.

Despite what this really means, sys admins supporting Novell's server products probably don't care about any of this unless it really effects their day to day job.

Edited 2006-08-01 20:23

Reply Score: 1

Makes little practical sense...
by tomcat on Tue 1st Aug 2006 20:15 UTC
tomcat
Member since:
2006-01-06

When you're contemplating technical decisions, there are generally 3 primary considerations: technological (whether it can be done), legal (whether it's legal or valid to do), and philosophical (whether it should be done). Eugenia is correct about this being a philosophical decision. There's simply no technological or legal reason why Novell can't continue to allow proprietary binaries in Linux drops. I think that what Novell is really trying to do here is appeal to the grassroots/least common denominator of the Linux community that puts philosophy ahead of function; aka, the RMS folks who would never install anything that isn't IP-free. Will it matter? I doubt it. Linux is primarily being used/sold in the server/backend market, where vertical integration is much more common; ie. vendors integrate specific components into a whole system and put whatever drivers are necessary on the box. Having the latest 3D video or whizbang new device drivers isn't all that important to most of these OEMs -- and those that do care will probably have sufficient leverage with device manufacturers to get them to write a proprietary driver. But, as for the small desktop Linux market, it is bad news, because it makes it that much harder for end-users to obtain drivers.

Reply Score: 2

LGPL
by MrEcho on Tue 1st Aug 2006 20:28 UTC
MrEcho
Member since:
2005-07-07

What we need is a LGPL wrapper module for the kernel so that proprietary binaries can access the kernel without having to use the header files.
And from what I can understand, Nvidia already does this on some level.
Also on the plus side of things, this wrapper could have a stable ABI/API.

Linux is choice, let us have our choice on what drivers we want to use!

Reply Score: 1

RE: LGPL
by G. W. on Tue 1st Aug 2006 20:40 UTC in reply to "LGPL"
G. W. Member since:
2006-03-17

> What we need is a LGPL wrapper module for the kernel
> so that proprietary binaries can access the kernel
> without having to use the header files.

Great proposal. Try to get this upstream. You will not succeed:

http://www.kroah.com/log/2005/11/03/

> And from what I can understand, Nvidia already does
> this on some level.

No, NVidia doesn't do this.

> Also on the plus side of things, this wrapper could
> have a stable ABI/API.

Great idea. Try to get the idea of a stable API upstream. You will not succeed:

http://lxr.linux.no/source/Documentation/stable_api_nonsense.txt

This file is part of the official Linux kernel documentation.

> Linux is choice, let us have our choice on what
> drivers we want to use!

Before setting up requirements like this one, check your position.

Are you in a position of setting up rules for the Linux driver development model? Who, you think, should set up such rules? Why not the copyright holders?

Reply Score: 3

RE[2]: LGPL
by MrEcho on Tue 1st Aug 2006 20:50 UTC in reply to "RE: LGPL"
MrEcho Member since:
2005-07-07

Yes having a stable api in the kernel would be a BAD idea. I wasn't talking about the kernel.

But there is server grade hardware out there that the Linux kernel doesn't support right now.(dealt with this last night)
And the single FACT the ATI or Nvidia will NEVER open up their driver or hardware is more cause to have a wrapper on the kernel.

Reply Score: 1

RE[2]: LGPL
by DrillSgt on Tue 1st Aug 2006 23:30 UTC in reply to "RE: LGPL"
DrillSgt Member since:
2005-12-02

"No, NVidia doesn't do this."

As stated by Linus at one point, looking for the link again, using the header files does not constitute a violation of the GPL. The Nvidia module does not link directly to the kernel, but uses an OSS system to do so. I could be wrong, but that is my understanding of it. That is why theoretically there is no problem distributing the Nvidia module legal or otherwise. The only problem comes in because the developers want everything to be open source. Fine, they have that right to do so. The kernel developers do not want Linux in wide use, or they would allow this. It really is that simple.

Reply Score: 1

RE[3]: LGPL
by G. W. on Wed 2nd Aug 2006 00:59 UTC in reply to "RE[2]: LGPL"
G. W. Member since:
2006-03-17

> looking for the link again

I want to see this post.

Linus cannot make comments in place of others. Linux is not Linus' work. Linus is neither the only contributor nor the contributor of the majority of the code.

If Linus wants to make an exception for NVidia, he needs permission from all copyright holders. Linux is distributed under the GPL, contributors contributed their work under the GPL without extra clauses unless explicitly otherwise stated.

And if Linus really makes an exception for NVidia, other companies will ask for exceptions as well, and in the end everyone will ask for ways how to bypass the GPL most efficiently.

If you really want to go this way, the result will be that Linux becomes proprietary in the long term. Why would companies want to contribute their drivers under the GPL if they don't have to? Keeping them proprietary is much more comfortable, no expensive quality review, no expensive security audits etc.

In the end, Linux will become unportable: Porting it to a new architecture will take years instead of months, like it did with Windows, because the OSS community will have to wait for blobs from the vendors. *sigh*

Reply Score: 3

RE[4]: LGPL
by DrillSgt on Wed 2nd Aug 2006 01:35 UTC in reply to "RE[3]: LGPL"
DrillSgt Member since:
2005-12-02

"Linus cannot make comments in place of others. Linux is not Linus' work. Linus is neither the only contributor nor the contributor of the majority of the code."

No, it is not that Linus spoke about the code. He spoke in terms of the GPL...am seriously looking for the link. He said Nvidia does not violate the GPL as it does not directly link to the kernel. It was a discussion on the kernel mailing lists, as well as another place. If I find it you will see what I am talking about. It was nothing making an exception for code that links to the kernel, just a statement on how Nvidia does not link to the kernel, making it not in violation of the GPL.

Reply Score: 1

RE[4]: LGPL
by elsewhere on Wed 2nd Aug 2006 02:59 UTC in reply to "RE[3]: LGPL"
elsewhere Member since:
2005-07-13

I want to see this post.

http://kerneltrap.org/node/1735
What Linus said is:

And in fact, when it comes to modules, the GPL issue is exactly the same. The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result, anything that is a derived work has to be GPL'd. It's that simple.

Now, the "derived work" issue in copyright law is the only thing that leads to any gray areas. There are areas that are not gray at all: user space is clearly not a derived work, while kernel patches clearly _are_ derived works.

But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)?

THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour.


He goes on to say later in the LKML thread that:

In contrast, these days it would be hard to argue that a new driver or filesystem was developed without any thought of Linux. I think the NVidia people can probably reasonably honestly say that the code they ported had _no_ Linux origin. But quite frankly, I'd be less inclined to believe that for some other projects out there..

Basically he's saying that the derived work clause is fuzzy. In nVidia's case specifically, the binary "blob" is OS-agnostic, they use the same binary for Win and BSD. The linux piece is simply the kernel wrapper, which is in fact GPL. So if the binary itself isn't designed specifically for linux, and the piece that is dependent on linux is GPL, then the nVidia driver is not a clear violation of the GPL.

And I think this is the core of the issue, no matter how much people want it to be black and white, it isn't. What defines a derived work? If someone uses a clean room type reverse engineering of the linux API, would that driver still infringe?

I also think Linus' point is credible because if you read the whole thread, he is admant and unforgiving about the GPL nature of the kernel, but he's willing to admit that loopholes exist. He doesn't endorse them, but he doesn't pretend otherwise. It's an uncharacteristcly pragmatic viewpoint for him.

Clearly there are cases where binary blobs compiled against a kernel and distributed as such would violate the GPL. Yet it is also evident that the manufacturers will continue to resist opening up their API's for reasons that the community refuses to accept. It doesn't matter who is right or wrong, and linux hasn't attained the saturation point yet where it can force manufacturers to comply, they'll simply walk away.

So the inevitable middle ground is going to be either a pure GPL kernel that loses commercial momentum due to the impracticality of supporting certain hardware, or we wind up with a bunch of kernel wrappers around generic drivers, or worse ndiswrapper type solutions around windows drivers.

It might make some kind of ignorant pleb, but I'll settle for nVidia's approach until something better comes along. It's not ideal, but I've never had a problem with mixing and matching driver and kernel version when necessary, since the source is provided and it's a simple step to re-compile.

Reply Score: 5

RE[5]: LGPL
by G. W. on Wed 2nd Aug 2006 03:23 UTC in reply to "RE[4]: LGPL"
G. W. Member since:
2006-03-17

Please let's try to keep the confusion at a minimum.

> In nVidia's case specifically, the binary "blob" is
> OS-agnostic, they use the same binary for Win and
> BSD.

NVidia's blob is not a kernel module, it is an object file which cannot be loaded into the kernel. It is technically impossible to load this blob into the kernel.

This object file is totally useless to a consumer, the consumer needs a kernel module. kernel module = blob + source wrapper. The kernel module can then be loaded into the kernel.

What you are currently trying to do is saying, the blob is not a kernel module and therefore not a derived work of the kernel.

The interesting point here is that you are right, but the even more interesting point is that it doesn't matter. What Novell would have to do in order to provide a usable driver is distributing the kernel module, not just the object file, and in the moment when you link the blob and the source wrapper together, it becomes a derived work of Linux.

There is no way out: Distributing Non-GPL kernel modules is in violation of the GPL. We can discuss workarounds like source wrappers and such until the end of our lives, it does not make any difference.

Read:

"Some companies try to skirt the license of the law on how they redistribute their closed source code, forcing the end user of it to do the building and linking, which then causes them to violate the GPL if they want to give that prebuilt module to anyone else. These companies are just plain unethical and wrong."

Quoted from http://www.kroah.com/log/linux/ols_2006_keynote.html

It's exactly that: NVidia's source wrapper approach is just a cheap attempt to pass all the legal problems to the users. Well, OK: If users like it that way, they can always compile and link the proprietary modules themselves, which is legal as long as they don't distribute it, but this scenario is something that a company can definetely not support commercially, it simply doesn't scale. I don't know any Linux distributor that provides commercial support for custom kernel modules.

The only long-term viable solution is: These drivers must be implemented in user space. Once that happens, all the legal problems are resolved and there would be nice side effects: User space drivers can't crash the kernel and the kernel <-> user space interfaces are stable.

Reply Score: 3

RE[6]: LGPL
by mkone on Wed 2nd Aug 2006 07:18 UTC in reply to "RE[5]: LGPL"
mkone Member since:
2006-03-14

"Some companies try to skirt the license of the law on how they redistribute their closed source code, forcing the end user of it to do the building and linking, which then causes them to violate the GPL if they want to give that prebuilt module to anyone else. These companies are just plain unethical and wrong."

Quoted from http://www.kroah.com/log/linux/ols_2006_keynote.html

It's exactly that: NVidia's source wrapper approach is just a cheap attempt to pass all the legal problems to the users. Well, OK: If users like it that way, they can always compile and link the proprietary modules themselves, which is legal as long as they don't distribute it, but this scenario is something that a company can definetely not support commercially, it simply doesn't scale. I don't know any Linux distributor that provides commercial support for custom kernel modules.


As far as I understand, companies can't make end users violate the GPL because GPL affects distribution. As long as one is not distributing, one cannot violate the GPL. So end users are not distributing (by assumption), so they do not violate the GPL. If the end user distributes, then they become a distributor and the rules apply. But then again, I do not see the FSF going after those people, but I have been wrong before.

So it is actually an effective of skirting around the GPL and keeping to the letter of the law. Personally, I do not see the problems with NVidia's approach.

Reply Score: 1

RE[6]: LGPL
by grat on Wed 2nd Aug 2006 15:50 UTC in reply to "RE[5]: LGPL"
grat Member since:
2006-02-02

The only long-term viable solution is: These drivers must be implemented in user space. Once that happens, all the legal problems are resolved and there would be nice side effects: User space drivers can't crash the kernel and the kernel <-> user space interfaces are stable.

Ok, I'll bite. From your comments, you're involved high up enough that you should have a fair idea of what it would take, so I ask...

What would it take in terms of coding, from both the linux community, and the hardware vendors, to make this happen?

Seriously. What would it take (preferably in layman's terms-- I have years of experience as a programmer, but have virtually ignored OS kernel code because it's not that important to my job), to implement a methodolgy for high performance, user-space drivers? Preferably ones that don't have to be rewritten each time the kernel updates.

Ideally, I'm picturing some form of kernel module that acts as an interface for user space drivers. That module could have a stable "external" API, and be adapted to "internal" API changes.

I have no idea what the performance tradeoffs would be, or if it's even a viable concept, but the driver/GPL issues are getting more and more press, and should soon start showing up in anti-linux FUD.

Reply Score: 1

RE[7]: LGPL
by Legend on Wed 2nd Aug 2006 16:18 UTC in reply to "RE[6]: LGPL"
Legend Member since:
2006-07-27

Interestingly enough, what he means is basically a http://en.wikipedia.org/wiki/Microkernel !

Reply Score: 1

RE[7]: LGPL
by draethus on Thu 3rd Aug 2006 12:27 UTC in reply to "RE[6]: LGPL"
draethus Member since:
2006-08-02

Seriously. What would it take (preferably in layman's terms-- I have years of experience as a programmer, but have virtually ignored OS kernel code because it's not that important to my job), to implement a methodolgy for high performance, user-space drivers? Preferably ones that don't have to be rewritten each time the kernel updates.

libusb already lets you send and receive control, bulk and interrupt USB packets from user space, by using the kernel's /proc/bus/usb interface. It doesn't do isochronous packets, which are real-time packets with no error checking - but those are only needed for real-time hardware, like audio and video, and should be relatively easy to add anyway. It is already entirely feasible to write a closed-source user-space scanner or printer driver with libusb - the SANE project takes this approach for scanners. libusb is fast too.

There was/is a kernel module called pcidev (anyone know more?) that lets a user-space program access PCI hardware - not sure how well it works or how efficient it is (interrupt latency must be pretty long, if you write interrupt handlers in user-space), but it's definitely possible.

The thing is, a lot of the time, to do anything useful you need to interact with the kernel. A user-space TV card driver still needs to interact with video4linux, which is in the kernel. A user-space RAID array driver still needs to interact with the kernel block device infrastructure. But, some of the time you could cheat by using a kernel-to-user-space proxy - something like fusd - though that's pretty slow.

None of this is technically infeasible or very complicated - but you need to convince people to do it...

Reply Score: 1

You know
by deathshadow on Tue 1st Aug 2006 21:19 UTC
deathshadow
Member since:
2005-07-12

I've always been amazed how closed off to practical business concerns 'open' source is... The 'free as in freedom' folks have to be some of the most closed minded people I've ever heard of.

This 'open source or nothing' bull is about as closed minded to the concerns and practices of most hardware developers as Mel Gibson would be to his daughter marrying a Isrealite... difference being the FSF and it's kine are masking themselves behind a cloak of (over)righteous freedom - a thin veil at best against anyone with at least half a brain cell.

Suprising since it's all built upon a loophole in contract law and a bunch of overglorified EULA's - meaning things like the GPL should have about as much legal standing as a unsigned pre-nup.

Reply Score: 1

Calm down
by JeffS on Tue 1st Aug 2006 21:20 UTC
JeffS
Member since:
2005-07-12

The whole argument of "Novell is doing this to cater to the FSF crowd" make no sense whatsoever. Novell is a publicly traded corporation, whose primary customer is the Enterprise. They sell to other businesses or other organizations, mostly medium to large size. That crowd really does not pay much attention to FSF philosophy.

This move, logically speaking, can only be interpreted as a CYA move. It is a violation of the GPL to include proprietary drivers in the kernel. Thus, Novell is only removing legal risk.

They are also, as another poster said, simplifying their support structure.

Reply Score: 3

Am I missing the story here?
by elsewhere on Tue 1st Aug 2006 21:52 UTC
elsewhere
Member since:
2005-07-13

Tempest in a tea pot. This is philisophical, pure and simple, and most likely yet another symptom of the Ximian flu they caught a while back.

Legal implications? Novell/Suse *never* shipped a linux kernel with closed proprietary modules pre-installed. THAT would be a GPL violation. Novell/Suse never automatically installed the drivers unless the user selected it through YOU. This is in keeping with the letter of the law for the GPL, if not so much the spirit. Shipping a CD/DVD with GPL and non-GPL products is NOT a violation of the GPL. Shipping a CD/DVD with GPL products linked by non-GPL products is. The user can do whatever the hell they want, the software vendor can't do it for them. If Novell has any lawyers left on staff, they're looking at the patent implications in mono, they're not worried about this.

Simplifying support? Novell/Suse never supported closed proprietary modules, even when they were made "available". Nothing gained here other than a little hit to customer sat.

Respecting the intent of the GPL? Sounds good, but doesn't seem in jibe with their sponsorship and mainstreaming of Xgl, for instance, which virtually forces users to install proprietary drivers. Think about that for a minute.

This is simply more of Novell's corporate identity crisis. They want the community to love them, but the community for the most part isn't interested in providing them with the annuity revenue stream and market share they're looking for, so they also want commercial concerns to love them equally. Can't let the commercial concerns love them more, otherwise they're selling out the community, but then they're getting crucified by their shareholders and analysts for ignoring common sense business requirements in the name of embracing the community. They should just make a decision one way or the other.

But in the big picture, this really changes nothing anyways.

Reply Score: 2

Good job Novell
by abraxas on Tue 1st Aug 2006 22:10 UTC
abraxas
Member since:
2005-07-07

This is a very good move for Novell. Not only will it appease the FSF and other advocates of free software but it will protect Novell. Novell, or any other linux distributor for that matter, has no control over binary drivers and cannot fix any issues that arise from their use.

Personally I am happy that Novell is excercising quality control. A completely GPL kernel allows them to fix any problems caused by the system they distribute and support. It's just not a smart move to support a system that you cannot fix.

Novell isn't doing a disservice to anyone here. They still make proprietary modules readily available through a link to the drivers online.

Everyone chastising Novell for this announcement should really be chastising the hardware manufacturers that don't distribute Linux drivers on CD with their hardware. If they make a proprietary driver for their hardware it isn't asking too much to include it on the CD.

Reply Score: 2

People have a misconception here......
by silicon on Wed 2nd Aug 2006 01:15 UTC
silicon
Member since:
2005-07-30

..... that other distros ship closed source drivers. Ubuntu does it. But how come Gentoo, Fedora and others? They have proprietary drivers on their repos which is fine.


DISCLAIMER: I am an (K)Ubuntu and Gentoo user.

Reply Score: 1

G. W. Member since:
2006-03-17

> ..... that other distros ship closed source drivers.
> Ubuntu does it. But how come Gentoo, Fedora and
> others? They have proprietary drivers on their repos
> which is fine.

I don't fully understand your post, actually, but the situation is as follows:

- Debian and derived distros including Ubuntu:

Provides compiled, linked, ready-to-use closed source, proprietary kernel modules.

- Fedora:

Does not provide closed source kernel modules, but provides kernel modules under GPL-incompatible open source license like the Open Software License, IBM Public License and others. Legally *no* difference to closed-source modules (GPL incompatible is and will always be GPL incompatible, whether proprietary or not).

- Gentoo:

Does not seem to provide proprietary kernel modules. Fetches the blob from the vendor's site and links it on the user's machine, which is legally OK.

Reply Score: 1

DrillSgt
Member since:
2005-12-02

Seriously..if it is illegal to use a non-GPL module as a driver, then VMWare is illegal to use on a Linux system. At least this is the way I am seeing it, as VMWare code DOES link directly to the kernel when you run vmware-config, where the Nvidia module does NOT link to the kernel directly, but through a sort of shim. The way this is sounding is that technically even an end user can not make that link happen. The GPL has never looked this confusing to me to be honest. I use Suse currently, having started my Linux adventures with Redhat 5.0 when I needed a way to get a nat firewall up, before the appliances of netgear and such were on the market. None of my comments on this or any thread are trolls honestly, but at this point I am getting confused about things. Can I link proprietary modules to the kernel or not? If not, then the use of tools such as VMWare are illegal. Can't have it both ways, it either is or it is not, and the rules need to apply across the board.

*edit* I would have added this to my earlier reply, but I guess edit goes away after 5 minutes lol.

Edited 2006-08-02 02:10

Reply Score: 2

Znark Member since:
2006-01-09

It is not a violation of the GPL to use a non-GPL driver. You are allowed to compile and load a proprietary module. But since the binary module is a derivative work of the kernel, you can't distribute it without violating the license.

Nvidia and the others get around the GPL by distributing code which is not a derivative work of the kernel. The Nvidia driver is a binary blob and some glue code which needs to be compiled. Nvidia and the others are making the distributors into violators. Novell and Redhat are saying they won't play along.

Reply Score: 1

uh
by deanlinkous on Wed 2nd Aug 2006 05:22 UTC
deanlinkous
Member since:
2006-06-19

BRAVO! Want to use GPL software then respect the license. Don't like what it restricts, allows, or doesn't allow then go use something else...PLEASE! ;)

Reply Score: 1

open hardware
by PipoDeClown on Wed 2nd Aug 2006 05:37 UTC
PipoDeClown
Member since:
2005-07-19

Well, GPL sucks without having common stream opensource hardware. I havent seen downloadable schematics of any motherboard, networkcard, soundcard or videocard yet.

Until companies open up their hardware, any license restriction is just a farce and so are discussion about using closedsource drivers or not.

having opensource hardware should be mandatory for having opensource software. my 2 cents.

Reply Score: 1

RE: open hardware
by G. W. on Wed 2nd Aug 2006 06:08 UTC in reply to "open hardware"
G. W. Member since:
2006-03-17

> Until companies open up their hardware, any license
> restriction is just a farce

Why? The GPL works really exceptionally well for all kinds of different devices *except*

- graphics gards
- passive ISDN cards
- software modems

And most interestingly, it's always the same vendors who can't comply with the GPL:

- ATI
- NVidia
- AVM
- Conexant

=> Suspicious.

The vast majority of devices is supported by the vanilla GPL kernel, you just don't notice it because it's perceived as amatter of course that everything works out of the box, but it isn't.

Reply Score: 3

RE[2]: open hardware
by DrillSgt on Wed 2nd Aug 2006 06:38 UTC in reply to "RE: open hardware"
DrillSgt Member since:
2005-12-02

"Why? The GPL works really exceptionally well for all kinds of different devices *except*

- graphics gards
- passive ISDN cards
- software modems"


You forgot Some Raid Controllers, Current AHCI Implementation, Webcams that are not ancient, Protocols that they refuse to implement even though the libs are available such as yahoo voice and video..I'll stop now... None of these work "Out of the box", and are all important to true desktop adoption. There is no freedom with Linux, as the Linux developers decide what you can and can not use. Linux serves it's use as a low end development desktop machine or as a server. It does not suit a true desktop with denying the right to use proprietary modules. Not everyone is a developer, I am not, so I don't want to hear the next drivel about 'Write your own'. I do not have those skills, and the kernel and OSS distributions developers only listen to those that can write patches, they don't care what people want or bug reports filed. It is that attitude that has chased me back to windows after 9-10 years, because things just work and are stable there.

Reply Score: 1

RE[3]: open hardware
by G. W. on Wed 2nd Aug 2006 07:52 UTC in reply to "RE[2]: open hardware"
G. W. Member since:
2006-03-17

> There is no freedom with Linux, as the Linux
> developers decide what you can and can not use.

It's just a matter of fact that when we are talking about copyrighted software, the copyright holder can make some basic decisions. This does not conflict with the free software definition - free software is still copyrighted software.

It is definitely possible to have a fully working and supported hardware configuration on a Linux desktop or laptop system. There are hisax supported ISDN cards, there are i810 supported graphics cards, there are ALSA supported winmodems and there are ipw2200 supported wireless devices. What you can't do at the moment is buying arbitrary hardware and expecting that there are OSS drivers for everything - this would be nice, but is currently not possible.

If I didn't know that Linux does not yet have the necessary adoption as a desktop system, I'd say that it is the OEMs' task to make sure that all components are supported. See, Linux today supports much more hardware out of the box than Mac OS X ever did. This is a fact.

And why is the perceived situation that Linux works almost nowhere out of the box? Because Linux is not preinstalled by OEMs and because people are trying to install it on arbitrary crap hardware. This might change in the future, commercially supported desktop distros like SLED or Ubuntu LTS will push this process forward.

> It is that attitude that has chased me back to
> windows after 9-10 years, because things just work
> and are stable there.

This is a very honest statement and it is indeed the proposed solution for those who are already dependent on proprietary drivers.

The whole thing is mainly about preventing people from becoming dependent on these drivers.

And yes, you are right: Everything is stable on Windows. And why? Because Microsoft has the resources to maintain 4 USB subsystems, a current one and three legacy ones which are just kept for compatibility. The Linux community just doesn't have the resources to do that, it is a lot of additional work, a lot of code duplication, it increases the number of points of failure and a notable run-time overhead.

> Personally, I do not see the problems with NVidia's
> approach.

But I do, because end users having to build drivers themselves is just ugly, painful and in no way a permanent solution.

Reply Score: 3

RE[4]: open hardware
by DrillSgt on Wed 2nd Aug 2006 16:10 UTC in reply to "RE[3]: open hardware"
DrillSgt Member since:
2005-12-02

"> Personally, I do not see the problems with NVidia's
> approach.

But I do, because end users having to build drivers themselves is just ugly, painful and in no way a permanent solution."


I never looked at it that way to be honest, as I am more technically inclined so that much was and is never an issue. That is a very good point however. And for the rest of your post, thanks for taking the time, as it is well written. You made some points that I knew actually, just have been forgotten in a way as it is so transparent, such as the Windows USB subsystems. I imagine if I were a developer it would be more evident.

Reply Score: 1

You are pestering the wrong crowd.
by gustl on Wed 2nd Aug 2006 13:53 UTC in reply to "RE[2]: open hardware"
gustl Member since:
2006-01-19

Be a pain in the ass for the hardware manufacturers. Tell them to write GPLed drivers. Then they will be very much welcomed by the linux crowd.

If they write drivers which are so crappy either in coding style or in terms of bugs that they would not be accepted into the vanilla tree, then you better think twice about using them, even if yo uonly get to see the binary.

Reply Score: 1

Interesting
by Legend on Wed 2nd Aug 2006 08:33 UTC
Legend
Member since:
2006-07-27

The Linux kernel devs have no resources to maintain additional APIs (well, having several APIs for the same thing is indeed not nice, but sometimes probably unavoidable for a while), BUT they have resources to maintain a lot of drivers through every single API change in the kernel?

Interesting.

Reply Score: 1

RE: Interesting
by G. W. on Wed 2nd Aug 2006 08:35 UTC in reply to "Interesting"
G. W. Member since:
2006-03-17

> The Linux kernel devs have no resources to maintain
> additional APIs (well, having several APIs for the
> same thing is indeed not nice, but sometimes probably
> unavoidable for a while), BUT they have resources to
> maintain a lot of drivers through every single API
> change in the kernel?

Exactly.

Really simple, isn't it?

Reply Score: 1

RE[2]: Interesting
by Legend on Wed 2nd Aug 2006 08:54 UTC in reply to "RE: Interesting"
Legend Member since:
2006-07-27

Now I don't know if you agree with me that this fact is strange or want to say that it is true that maintaining the bunch that big bunch of drivers takes less time then maintaining a few APIs - and especially delegate the task of writing drivers out of the kernel itself. (but that would be something NOT wanted by the devs)

Reply Score: 1

y
by deanlinkous on Thu 3rd Aug 2006 04:43 UTC
deanlinkous
Member since:
2006-06-19

Amazing that what allowed linux to become what it is, is the same thing you claim ruins it's chances at becoming relevant.

But considering you are posting about something that you claim isn't relevant....????

Reply Score: 1