OSNews

I just read the part about binary blobs in Ubuntu 7.04.

That explicitly violates the terms of the GPL. It seems Ubuntu developers are willing to upset the balance just for Beryl's god damn wobbly windows and rotating cubes.

Fedora Core:
Mod += 5

I'm interested in how it exactly violates the GPL. I know you can't include non-gpl code with GPL code, but I thought that if you include the packages separately with option to install them somewhere along the way that's some kind of loophole?

Feel free to correct me, this is one part of the GPL that's very cloudy and I would sincerely like to know where the line is drawn without diving into legalese

I think the loophole is that binary driver developers use a layer which is compatible with GPL but also allows linking to binary blobs. It's a gray area but seems OK with most kernel developers.
Distros don't ship binary drivers for two reasons:
-free software philosophy
-need for agreement with company that created the driver

I might be wrong too though

Thanks

..AND the fact that the Linux API may change at some point, making a binary driver unusable until the company cares to change it, compile it and distribute it again. Remember the infamous case of the SM56 Motorola softmodem, who got its own binary driver for exactly one kernel version, Mandrake something or other and then never again.

No, it's a violation that only the user should decide to make. There is nothing cloudy about it. You cannot legally link GPL with non-GPL compatable code. This might have been different were the kernel licensed under LGPL, but the GPL specifically prohibits it.

There kernel developers seem more pragmatic about certain underlining issues, thus their decision to continue supporting the GPLv2. But the GPL clearly states its terms regarding library linking.

Edited 2006-11-25 00:21

What if the drivers are in the package listing, and they're opt-in during the install? Who's to say that isn't what they might try to stay in terms?

Sorry but you are wrong, I program or driver that links to GPL code makes it GPL but a GPL program or driver linking none GPL code doesn't make it GPL by magic and is legal.

This is a violation of the GPL "Spirit" but not a violation of the GPL license and the spirit ain't nothing but a poor excuse to justify the holes of the GPL license.

Edited 2006-11-25 00:57

No, it's a violation that only the user should decide to make. There is nothing cloudy about it. You cannot legally link GPL with non-GPL compatable code. This might have been different were the kernel licensed under LGPL, but the GPL specifically prohibits it.

Actually the GPL does not prohibit linking to non GPL code. The GPL prohibits distributing it but nothing else. In fact the GPL explicity says that you can do anything you want to the code. The exceptions only come into play if you are distributing code. The GPL is a license to distribute, not a EULA. There is a gray area when it comes to what you consider derived works and whether or not binary blobs can be distributed if they are tied in some way to the kernel, but Nvidia gets around that because their binary is universal. If it was Linux-only a case could be made against it but kernel developers don't seem to be interested in those kinds of legal tangles anyway.

It's not necessarily a violation of the GPL. It depends on the license of the binary blob, the way the blob interacts with the kernel and copyright laws in different countries and a gazillion other things.

//I just read the part about binary blobs in Ubuntu 7.04.

That explicitly violates the terms of the GPL.//

Excuse me? What terms exactly?

The video drivers and other "binary blob" components that are being distributed by Ubuntu aren't GPL software.

Having GPL software on your system in no way requires that the systems has only GPL software installed on it.

I just read the part about binary blobs in Ubuntu 7.04.

Would you please provide a link to the part you read... because your statement below is simply not true:

That explicitly violates the terms of the GPL.

Blanket statement. Which are exactly the binary modules that explicitely violate the GPL? Nvidia? It doesn't, because it doesn't directly interact with the kernel. It uses a wrapper that is GPL on one hand, and is also compatible with Nvidia's binary blob license.

Other modules, like wifi? I don't use (k)ubuntu, but I was wondering what binary drivers they provide? If they got permission (from manufacturers) to distribute windows drivers and use it with ndiswrapper, than again, where is the explicit violation of the GPL? (again, the same case as with nvidia, ndiswrapper is GPL compatible).

I don't mean to say that all of this is OK. Nvidia, at least I can understand, because trade secrets and real patents are involved (some of which don't even belong to Nvidia, so they don't have the right to GPL it or something). OTOH, using ndiswrapper is evil, b/c it encourages vendors to neglect linux users. Theo's (OpenBSD) stance is the right one here (pressure vendors to provide specifications at least). Accepting linux binary blobs is also evil (now that might be a GPL violation, if they interact directly with the kernel!).

I don't really care about (K)ubuntu criticism, but your statement is simply false or at the very least, misleading (not all binary blobs violate the GPL, especially explicitely as you claim). You either didn't read "the part about binary blobs" very carefully, or simply want inflate the situation to make (K)ubuntu look worse than it really is.

IANAL, but I see the "proprietary via GPL bridge" case in the following way:

1) If the GPL part is supplied in the source-code form and compiled during installation, there is no way to claim GPL violation at all, since no distribution in the binary, linked form takes place.

2) However, if the GPL part is distributed already compiled and linked with the kernel, the situation is different. Let's forget about the kernel for a minute and look at the GPL bridge and the proprietary blob first. While consisting of two parts, the bridge + blob combination is essentially a single work, since the intended purpose of the two is to work together and the former explicitly loads the latter. Now, being the copyright owner of both parts, NVidia has the right to combine them as they see fit, regardless of licenses, but the license for this combined work is not GPL! Therefore we have a non-GPL work linked to GPL kernel - which is a violation.

Good points, but your argument hinges on considering the blob+wrapper a single work. They are not. For instance, the blob works without the wrapper on other unix platforms (FreeBSD, Solaris), or non-unix platforms. They aren't entirely separate either, for the blob communicates with the kernel through the wrapper, which is analogous with the GPL situation (the restrictive license of the blob communicates with the GPL licensed kernel through the wrapper as well ). At any rate, including the NVidia driver on the ISO is certainly not an explicit GPL violation - that was just rhetorics to make the situation sound more dramatic. NVidia's case is at worst, a legal grey area, not explicit violation.


Another note: the wrapper is GPL compatible, not GPL itself as far as I know...

Other than not getting paid, what would be the difference in working for Canonical instead of Microsoft or Novell?

To those of great character and high integrity, standing up for what is right takes precedence over monetary gain or advancement at the expense of others. It is a quality I have witnessed much in the Linux community and I think that is a major difference...to answer your question.

To those of great character and high integrity, standing up for what is right takes precedence over monetary gain or advancement at the expense of others. It is a quality I have witnessed much in the Linux community and I think that is a major difference...to answer your question.

Canonical is a private company. Private companies don't get much scrutiny. How do you know what its doing is "of great character and high integrity"?

I don't know. Nor do I want to pontificate on what I (or others) think is in the hearts of Linux developers (like Canonical), although I think the product speaks for itself. I do know that from what I have seen and experienced, that the developers of Linux, by an overwhelming majority, have the interest of the many at heart, that they work to produce fine accomplishments not for the sake of money (although it helps!) but for the greater good of the world at large. That might sound corny to jaded folks, those whose lives revolve around what's in it for them and/or the almighty dollar/Euro, etc...

My unprofessional view of a very complex situation is that MS is scared of Linux and, as the adage goes "Keep your friends close and your enemies closer" applies in this deal that is producing all the controversy.

"What is right?" You don't seem to understand here, not everyone has the same opinion of what right is.

Many people think of Shuttleworth's pro-binary blob policy as wrong, many do not. Many view Novell's actions as wrong, many do not. Many view OpenBSD's vocal community actions as wrong, many do not.

Which group is right?

Well, OpenBSD's community thinks it's right for fighting for complete access to the source code of it's operating system, ensuring it's security and freedom. They are sick of waiting for a revolution that doesn't exist to make everything open source, so they fight for it. Many outsiders think they alienate the open source world from hardware manufacturers by doing this, being a vocal group that openly calls companies liers and cheats and complains about things, often in massive waves. They think that OpenBSD is a bunch of big scarey monsters that sour the relationships that they the more mild people are trying to build in their own ways.

Novell thinks it's right for trying to obtain a licensing agreement with Microsoft to ensure the safety of it's customers from any potential legal repercussions. Many think it's wrong, because it's dealing with Microsoft, well, many companies deal with Microsoft, it's hardly new and hardly evil to do so.

And Shuttleworth thinks he's right because he wants to give the users of his system the best experience possible, regardless of how, to ensure that they stay Ubuntu users in the future and don't go elsewhere. Many think it's wrong because it's using binaries instead of trying to open things up or not support things which are not going to be opened. They think that supporting any company that refuses to open up is hurting open source by not supporting those hardware makers who do support open source.

Not everyone is out for the big bucks, and getting those big bucks isn't wrong when one does. A company has an obligation to make money for it's shareholders you know, it's not right to make 10 dollars where one could have made 12. As a publicly traded company, they must make as much money as possible, or they can and will be held accountable.

Canonical is not the Linux community, it's not even a community, it's a company, a company focused on making a Linux distribution to be sure, but a company. A community doesn't have bills to pay or a bunch of shareholders - Novell has those, Canonical lacks the shareholders because it's private, but it still has the bills. It's not in any way a community member, it's a company trying to direct and enhance the community for their purposes. Novell is doing the same thing.

Which is the right way? To try to protect your customers and dance with the devil ala Novell, or to wander on your own attacking anyone you think is your enemy ala OpenBSD, or is it to help the community with it's problems and make a buck in the process ala Ubuntu?

It depends now doesn't it? When one looks at it Novell is just as much a community member as Canonical is, likely more of one, in fact, since Novell has made or at least released the source code for more than Canonical has. Evolution and many other things have come from Novell, while there has been little new code coming out of Canonical, just the control of a distribution.

In truth, Microsoft has done what is right by all it's standards. It is obligated in the same way as Novell to make the most bucks for as little bang as possible. They just happen to have made a lot and done things you don't like.

Then maybe he should have said "standing up for what they think is right", "having moral standards".

For a lot of companies, Microsoft and Intel among them, it seems that "how much money can I get" is the only "moral standard" they understand, and the amount of people they screw over is either immaterial or a badge of honour.

Trademark, Copyright, Patent... They are not the same thing or even close. In the US, they are all governed by very different laws. The Novell <---> Microsoft deal was a patent covenant which basicly says, "Hey, we won't sue your customers so long as you dont break this agreement."

A trademark is on a name. Would you like it if I signed up for other 'nix/computer websites and started posting as NotParker? That is what a trademark is for.

Would you like it if I signed up for other 'nix/computer websites and started posting as NotParker?

No. One NotParker is much more than enough!

http://upload.wikimedia.org/wikipedia/commons/e/ea/DoNotFeedTroll.s...

Yes, but if the sole purpose of the kernel module is to load the binary blob, then how is it really any different?
That's like a hired killing; the person who ordered the kill is just a guilty as the killer himself.
At least that's the way I think the Law would see it.

Edited 2006-11-25 02:32

Thanks, that clears the NVIDIA issue for now.

Ubuntu will also be shipping ATI's proprietary display drivers.

I think it works in a simular way but is the kernel module source code licensed under GPL or compatable?

Doesn't look like it to me:

http://packages.debian.org/changelogs/pool/non-free/f/fglrx-driver/...

"2. the nVidia GPL kernel module loads the binary blob. It does _not_ link to it -> legal."


Sorry, I don't really understand that one. Isn't dynamically loading the code and using it nothing more than dynamically linking it?

On the other side, one could argue that any userspace app linking to kernel calls would then also violate GPL. But here, the kernel devs explicitely state, that they don't see it as a violation. They explicitely state otherwise in regards to the binary drivers (which nearly all work in the fashion of nVidia) though!

This issue has been beaten to death by Greg Kroah-Hartman and some other core kernel developers.

Including Linus, who unlike GKH, points out the derived work clause.

The nvidia binary driver is a universal blob that works on win and *nix using an OS-specific kernel wrapper. As Linus pointed out, it would be hard to consider the blob a derived work of the linux kernel.

Now no lawyer will ever come out in public and say this, as lawyer really aren't allowed to make public statements like this at all. But if you hire one, and talk to them in the client/lawyer setting, they will advise you of this issue."

And that is a cop-out from him. The internet is littered with lawyers giving their unsolicited opinion on everything under the sun. Lawyers are not regulated or restricted from making statements like this.

Besides, nvidia's lawyers seem to have a different opinion owing to the fact that nvidia makes *pre-compiled* kernel modules available for download specifically for Novell at Novell's request, and probably at Novell's expense as well because I'm not aware of any other distro they specifically maintain a repo for. Novell, of course, being GKH's employer.

Now the kernel wrapper is compiled against the kernel, which puts it under GPL licensing. Yet it is distributed linked to a binary blob and distributed from nvidia's own public server (ftp://download.nvidia.com/novell). Clearly this would be a violation, so how are they doing it? It's not like nvidia is new to the linux game.

Maybe the fact that no lawyer will come out in public and say it is "illegal" means that it is a grey area and one that does not, in fact, have a definitive answer. After all, if the law was black and white we would not need lawyers in the first place.

Don't get me wrong, I'm not necessarily saying binary drivers are GPL compatible. I'm just saying that not all binary drivers are necessarily GPL incompatible.

Hmmmm. Comment Score: 0 -- at time of reading.

Are you sure you want to vote this comment -1?
----------------------------------------------

"Yes, this comment includes personal attacks/offensive language" Well, not really.

"Yes, this comment is off-topic" Well, not really.

"Yes, this comment is spam or includes advertisements" Well, not really.

"Yes, I disagree with this user/opinion" Aha! That's the one! *clicks*

...

"Disagreeing with a comment or a user is not a valid reason to use the moderate. Comment votes are alloted to draw attention to insightful and informative comments and remove trash and trolls from our forums. They should not be used to remove comments with which you do not agree."

Post may fit #2

Edited 2006-11-25 07:53

> Now the kernel wrapper is compiled against the kernel,
> which puts it under GPL licensing. Yet it is
> distributed linked to a binary blob and distributed
> from nvidia's own public server
> (ftp://download.nvidia.com/novell). Clearly this would
> be a violation, so how are they doing it?

Nvidia shouls have no problems doing this, since they own the copyright on both the GPL wrapper, and the binary blob. As a developer, you have to GPL the _wrapper_ because its a derivative work of the kernel, but your ovn binary blob isnt a derivative of the kernel, since the same blob is used for example on windows.

One now could argue whether the blob is a derivative work of the wrapper or not, but it isnt a derivative of the kernel and it certainly doesnt stop Nvidia distribute it under any licence they as the developers see fit. Also i dont know if this wrapper can perform some function _without_ the blob, so that one could argument it not depending on the binary blob.

As how they are doing it: They just violate the GPL when distributing the wrapper under the GPL, and hope to be so valuable for the Linux community, that nobody would enforce the GPL in their case. And nobody has done it yet for precisely the same reason.

Ubuntu should have an even larger problem, since redistributing the blob which depends on the GPL wrapper to work would be an even more clear GPL violation.

We just have to wait until someone tries to enforce the GPL in this case, if Shuttleworth and Nvidia exaggregate their GPL violations. My bet would go for GKH & Co. and for an successfull cease and desist against Ubuntu and also against Nvidia. It would just be stupid to do it _now_ or soon, since Nvidia doesnt really depend on selling their cards to some few linux users. They should wait until not GPLing the blob would hurt Nvidias sales so much, that they couldnt violate the GPL nor completely ignore the linux community.

Edited 2006-11-25 09:51

Novell could ask Nvidia to get the rights to distribute directly the drivers with SuSE.

But they haven't. Because it's illegal. So they wanted the responsibility for distributing the drivers to be on the shoulder of NVidia. That's why there's this Novell repository on nvidia.com.

I just learned that Mark S. not only invited openSUSE developers from his blog post, but he actually mailed the opensuse list about it. This is very unnecessary.

It was tacky, but this is the same guy who announced he was going to make KDE a first-class citizen on *buntu immediately following the overblown Novell gnome/kde announcement.

Still waiting.

Read the following post from an Ubuntu developer/contributor: http://www.advogato.org/person/Burgundavia/diary.html?start=113

The reply from "Shark Muddleworth" is priceless.
https://lists.ubuntu.com/archives/ubuntu-devel/2006-November/022578....

The Shark Muddleworth one was funny.

Here are some from the openSuse devs, including Andreas Jaeger, the lead developer:

Andreas: http://andreasjaeger.blogspot.com/index.html
Steve Beineri: http://www.kdedevelopers.org/blog/457
Daniel Molkentin: http://daniel.molkentin.de/blog/index.php?/archives/58-Ubuntus-Ques...

And for bonus points, Johnathan Riddell, Kubuntu's sole KDE dev: http://www.kdedevelopers.org/blog/57