Debian Removes Binary-only Firmware From Kernel 121
mbanck writes "The Debian Linux kernel maintainer has announced that he will remove firmware from GPL'd drivers which obviously lack source code in its preferred form (i.e. something more appropriate than a hexdump inside a char[]), in accordance with the release manager's decision. The alternatives are user-space loading of the firmware via hotplug's request_firmware() API or making the vendors aware of the issue. How do the other distributions handle this?"
how other distros handle it (Score:3, Insightful)
Obviously, other distributions just include them because they want their stuff to work and don't like pissing off their userbase.
Ah, debian we love you for it though.
Re:how other distros handle it (Score:5, Insightful)
Ah, debian we love you for it though.
Yes, we do.
This is an example of a rare thing called "Integrity": sticking to your principles, even when it's inconvenient, or painful.
Lots of people are going to call Debian foolish and narrow-minded, but it's the same foolish and narrow-minded sense of principle that started this whole Free Software movement, and it seems to me that with the burgeoning commercialization of Free Software, it's very important that we have some voices who maintain the "pure" vision. Not because the commercialization is bad, but because commerce is pragmatic and that pragmatism poses some risks to a movement whose foundation is idealism.
Ultimately, making Free Software a truly viable option for computing requires a mix of both idealism and pragmatism, and we do, indeed, love Debian for providing an idealistic counterbalance.
Oh, and it's a damned fine operating system, too :-)
Re:how other distros handle it (Score:4, Insightful)
Just think 'non-US' and you'll realize that one of Debian's policies has always been to make sure not only that it works, but that it actually works legally. It only takes one C&D letter (or, if you don't fold to those, one court order/FBI visit) to fuck everything up and undo the countless man-hours that have gone into Debian.
For that matter, they are also trying to protect their end-users. IP law is a sketchy thing and we all have heard the SCO-babble about end-users being responsible for the IP within the software they use. If you remove legal issues before the software reaches the end-user... Well it's just good for everyone.
Re:how other distros handle it (Score:5, Interesting)
Except in this case the principle their sticking to is rabid legalism.
What? Debian's goal is to be a complete, *Free* operating system, where the definition of "Free" is the one put forward by RMS and the FSF, namely: Free to use, free to examine, free to modify and free to share. These binary-only firmware components are not Free. You may have freedom to use and share them, but you can't examine or modify them. Debian wants to be a Free operating system not Mostly Free, or Very Nearly Free.
What's "rabid" or "legalistic" about that?
It's pragmatism taken to an extreme.
That sentence parses just fine (no misspellings, even!) but it makes no sense. What are you trying to say? How can such an impractical decision be "pragmatism taken to an extreme"? What would that phrase mean anyway? Extremes, by definition, are not pragmatic!
It has nothing to do with FSF style "save the users from themselves" ideology.
Now you've switched to a different target, choosing to mischaracterize the FSF's position. FYI, the FSF has no intention of saving users from anyone, the FSF just wants to make it possible for people who want to to create, use, read, modify and distribute Free Software, with the assurance that the original author's wishes (that it be Free) will continue to be honored as long as the copyrights are in force. If anything, it's about saving developers from having their work misappropriated, not about saving users from anything.
Re:how other distros handle it (Score:1, Flamebait)
If the GPL had a clause (or the kernel added an exception) that would allow binary firmware, then Debian would not care about this issue. Even though the spirit of the GPL would not have changed. Even though the Debian guidelines had not changed. Even though the relation between Debian users and the hardware manufacturers had not changed. Their actions in this matter are not based on ideology, but on adhering to the exact letter of a license even though other dist
Re:how other distros handle it (Score:5, Insightful)
Yes, absurdity. It's not like anyone is ever going to accuse Linux developers of copyright infringement...
Balls (Score:2)
This only hurts Debian. (Score:1, Informative)
Comment removed (Score:5, Insightful)
Re:This only hurts Debian. (Score:2)
Doesn't this limit the programing languages that can be used to develop the code? I mean you can only include a finite number of compilers.
Also some code is massive but becomes tiny once compiled, doesn't that make no sense to include the source? What if someone wrote this firmware in Visual Basic (exageration but whatever) Linux has to miss out on it for that reason? Unfortunate.
Solution proposal from noob: Leave source online, don't include non-esential drivers with t
Comment removed (Score:4, Informative)
Re:This only hurts Debian. (Score:2, Insightful)
Re:This only hurts Debian. (Score:3, Informative)
Re:This only hurts Debian. (Score:1)
Re:This only hurts Debian. (Score:2)
Re:This only hurts Debian. (Score:1)
what makes you think Fedora is in its "infancy"? it's the same thing that Red Hat 9 was (plus the improvements that would have made it Red Hat 10). what about Red Hat 10 would have been an infant distro?
Re:This only hurts Debian. (Score:2)
I spent over a day this week wrestling with a RAID controller to discover that the closed-source binary-only driver only works with an outdated version of RedHat.
If they had released the source with a GPL-compatible licence it would have been incorporated into the kernel. Then I could've used any recent distribution and the controller would have Just Worked with no driver di
What if that's the "best" way (Score:2)
I see this as a similar problem with Lex/Yacc based applications. GCC, for example, requires bison to compile it. GCC ships with both the source grammer files and the compiled grammer file. Yes, I call the .c file compiled because it is an output file. That way, GCC can be compiled without having
Re:What if that's the "best" way (Score:3, Informative)
Which is fine. There's nothing wrong with shipping the output file so long as the original source is shipped as well. Of course it's still not strictly GPL compatible if you can't freely obtain the entire toolchain required to build it (and have that provided on request) but such is life.
Most people don't need to use the source, but if there's a bug you need to fix then that source
Re: (Score:3, Insightful)
Re:What if that's the "best" way (Score:5, Insightful)
But, a point I was trying to make, what if the toolset required to generate isn't open? There could a dozen reasons for that from technical (the device's CPU is not supported by GCC) to political (tool used by vendor is closed - either by the vendor or by NDA).
Now were back to the discusion of device proliferation and hardware compatability. This point is already begin discussed quite well with one noteable exception.
What about vendors who lock their code into on-board EEROM chips? That class of vendor surely covers over 95% of them out there. Think about it CD-ROM drives, Video card 3D engines, Printers, Phones, Music Players. These all have on-board systems. But if the firmware is locked in the device for the most part, it's out of sight, out of mind. But, when you get right down to it, there's no difference between a hex-dump in a kernel file or code locked in on-board EEPROM.
The "Great Moment" that launched Richard Stallman's crusade to liberate software was when his trying to get a printer manufacturer to give him the source code to a buggy printer so he could fix those bugs. They said no. Not long after that incident and watching computer makers "steal" X11 for their own versions of UNIX, the GPL was born.
Re: (Score:2, Interesting)
Re:What if that's the "best" way (Score:2, Insightful)
Re:What if that's the "best" way (Score:2)
tg3 Driver Affected (Score:5, Informative)
An interesting thing about this driver is that it appears to work (to the extent that most people need) without the firmware. There has been some attempt on the linux-kernel mailing list to make the firmware part of the kernel optional. That way Debian can just turn that option off and presumably remove the associated firmware from their kernel. Anyone who needs the bug fixes/features provided by the firmware can use a non-Debian kernel.
Not everyone's in favour of this idea though. There's more about it on the mailing list [google.com] if anyone's interested.
Re:tg3 Driver Affected (Score:2)
Yeah, that has been discussed on debian-devel as well. Seems the chances are good that tg3 might get back in, with a patch disabling the firmware.
Michael
Re:tg3 Driver Affected (Score:1)
Just yesterday, I installed a server with 2 3Com gigabit NICs that use the tg3 driver. I hope this is more tested by the time I need to upgrade the kernel again.
I guess it's time to set up a test server, or maybe start buying a gigabit NIC that uses a different driver.
Let me see if I've got this... (Score:5, Insightful)
There are currently some vendors whose hardware require firmware to be uploaded to them (for example, Broadcom NICs), and these vendors have esentially embedded the binary for the firmware into the kernel source.
Since the firmware is most likely not GPL, and the kernel source is GPL, we've got a GPL violation on our hands.
So the suggested fix is to have these vendors pull the firmware out into its own file, and rewrite that part of the kernel source to pull in the firmware dynamically.
Doesn't really seem like that big of a deal, unless I'm missing something?
Re:Let me see if I've got this... (Score:5, Informative)
Re:Let me see if I've got this... (Score:2)
The Stallman article is interesting, at least the last five paragraphs. The rest of the article is a rant about saying "GNU/Linux" instead of "Linux" and how Bitkeeper is evil. At least we know it was definitely written by RMS.
Overstating the message, reach false conclusion. (Score:2)
Re:Let me see if I've got this... (Score:4, Insightful)
Correction is on its way:
The GPL offers no restrictions on what code you can put into the GPL'd project. If you were putting the kernel into a non-GPL product, then that's definitely a GPL violation, but not the other way around. So, if you are allowed to put the firmware binary code into the kernel, through fair-use, a license, whatever, then it's fine to do that. If you're not licensed to do it somehow you're (to use the popular vernacular) stealing. This is probably where the dynamic-pulling of the firmware comes in. If you own the device in question, and pull the firmware right out of it, there's no question that's your right as owner of the device.
The problem here is that using binary garbage is against the spirit of the GPL. I could make a GPL'd version of a short C program that reads in a bunch of opcodes from a large array and executes them, resulting in a full-featured (browser/word processor/database/widget/whatever). Is this program open-source? Not really, but technically since it is under the GPL, Debian would allow it. They're now changing that position, and saying that this does not in fact count as open-source software, and they do not want it in their distribution.
Doesn't really seem like that big of a deal, unless I'm missing something?
Freedom never really seems like a big deal. I constantly hear people berating RMS, but contrary to popular belief, there is a purpose behind the things he does and says. Same with the Debian project. I agree it is probably going to be frustrating and stupid in the short term. But most of these strange, philosophical sort of decisions are all about long term goals and this one is no exception.
Re:Let me see if I've got this... (Score:5, Insightful)
You are allowed to put non-free firmware into the kernel and use it for yourself. But you are _not_ allowed to distribute this kernel, unless you license the firmware under GPL. Read the GPL carefully. Derived work has to be licensed under the same conditions as the original work - which is GPLv2 for the Linux kernel code.
Which way you insert code - either GPL code into non-free code or the other way round - simply makes no difference.
Re:Let me see if I've got this... (Score:3, Interesting)
Comment removed (Score:4, Informative)
PLEASE MOD PARENT ALL THE WAY UP!!! (Score:1)
Re: (Score:2)
Re: (Score:1)
Re:Let me see if I've got this... (Score:2, Insightful)
Not only the spirit, the GPL is pretty clear:
From section 3:
"The source code for a work means the preferred form of the work for making modifications to it."
Go on and modify those hexdumps.
That is absolutely wrong. WRONG! (Score:1, Insightful)
Hmm.. (Score:1, Troll)
Do we really need the sourcecode for it ?
And where does this stop ? Should we not install linux
on computers with a non open source BIOS ?
What about devices with firmware already loaded and where it need not
be loaded by a driver from an OS, should we "ban" those as well ?
Re:Hmm.. (Score:5, Interesting)
The firmware code doesn't get executed by the CPU, and thus in a sense it doesn't get executed by Linux. Firmware is used by an off-board processor, and thus I don't see a GPL violation here.
Consider if a piece of hardware needed a Magic Number string to start up. No code, no logic, no meaning; just a magic number required to activate the device. Can't we consider the firmware code as just a magic number? After all, Linux doesn't interpret or execute it.
Re:Hmm.. (Score:1)
Re:Hmm.. (Score:2)
In other words, that binary data could very well be the PREFERRED form of the firmware for everyone but the manufacturer, regardless of one's religious adherence to the GPL.
Re:Hmm.. (Score:4, Insightful)
If the firmware really is the preferred form of modification and is (along with the rest of driver) GPL'd, everything is fine. Of course, this is a bit hard to check, but talking to the vendor might help here.
But keep in mind that we are talking about the preferred form of modification here, from the POV of the vendor.
Michael
Re:Hmm.. (Score:2)
So, I decide to use my logo, and I save it as a PPM, and I include it in the source to my program. Is it a GPL v
Re:Hmm.. (Score:3, Insightful)
Debian has to be the biggest bunch of holier than thou morons... why would you intentionally make it hard on the user of your software to get something done?
And I am not even trying to troll on this. It is a valid question. There is no good reason to do this other than a few zealots who are SO out of touch with the rest of the world.
If I was using Debian in a commercial setting that required the use
Re:Hmm.. (Score:2, Insightful)
Very good point. Now what would you do if some asshole of a kernel developer decides that the drivers amount to a violation of the GPL on his code? The developer
Legal acts (Score:4, Interesting)
To distribute it like this is a violation of the GPL.
Your choices in your situation would be to add the driver yourself. The supplier could likely write a trivial patch to install it into your kernel source. You could then freely use it.
You're complaining about debian holding you hostage when it is actually the supplier of the closed module who is causing the problem. They could always release a GPL compatible driver.
Re:Legal acts (Score:3, Interesting)
Just to play devil's advocate, the GPL doesn't care too much about linked, but more about derived works. RMS has argued in the past that linking is a sure sign of a derivative, but the recent LKML arguments over the nvidia driver prove that other people disagree with that interpretation. You do not even need linking to create a derived work; I have seen argum
Linked and Derived work (Score:2)
Re:Hmm.. (Score:2)
Debian has to be the biggest bunch of holier than thou morons...
This comment makes no sense. Debian is a community-developed project, and the community who develops it has the opinion that this is the right thing for them to do with their project. In no way are they holding a gun to your head, proselytizing at your doorstep, etc. Want to change how they do things? Join the developer community and start making your voice heard. Don't care enough, or just plain don't like Debian? Don't use it! But
Re:Hmm.. (Score:1)
No it's not. It is an oligarchy of those who have commit bits to the debian source tree. Just like every other project out there. Users don't get to decide stuff like this. Heck, this VERY ISSUE was decided by a single Debian developer!
Re:Hmm.. (Score:1)
> Debian is a community-developed project
No it's not. It is an oligarchy of those who have commit bits to the debian source tree.
Which, according to the dictionary, is a community. Please try again.
Re:Hmm.. (Score:2)
Re:Hmm.. (Score:2)
Re:Hmm.. (Score:2)
Michael
Re:Hmm.. (Score:2)
Please quote from your dictionary. It sounds like it might be an amusing diversion.
OK. From the American Heritage Dictionary, Fourth Edition:
-----
community
1.
a. A group of people living in the same locality and under the same government.
b. The district or locality in which such a group lives.
2.
a. A group of people having common interests: the scientific community; the international business community.
b. A group viewed as forming a distinct segment of society: the gay community; the communit
Re:Hmm.. (Score:2)
If you go out into the world (or merely the Debian development lists) and ask "who is the Debian community", you will not be told it's only a thousand or so specific individuals. Instead you're going to be told about tens o
Re:Hmm.. (Score:1)
Add a non-free apt repository?
This is about main. There's plenty of non-free software in contrib and non-free. They're just pulling this non-free software out of main as main only contains 100% Free software. Most likely there will be a few encumbered kernels in the non-free repositories at some point, or loadable modules for hotplug.
Additionally, you could place presure on the har
Re:Hmm.. (Score:1)
The GPL is about code distribution, not everything that gets executed. If a Debian .iso came with a hex dump of a custom BIOS, then Yes, it should be removed for GPL-compatibility reasons. Really, it's not that hard to grok: if you distribute the code in a GPL'd product, you need to make the source ava
Re:Hmm.. (Score:2)
This is usually firmware for a device connected to the pc..
Do we really need the sourcecode for it ?
Because Debian can't distribute the binary code and yet still be following the Debian Free Software Guidelines.
And where does this stop ? Should we not install linux
on computers with a non open source BIOS ?
Is Debian distributing that non open source BIOS, in violation of the DFSG?
What about devices with firmware already loaded and where it need not
be loaded by a driver from an OS, s
Go Team Debian (Score:2, Insightful)
Nah, the alternative is to roll your own kernel.
The firmware licensing issue has been debated and resolved by the kernel people already.
about time (Score:5, Insightful)
This could be a very good thing for linux. It could encourage vendors to provide updated firmware that can be installed from userspace, without requiring a kernel patch. It could encourage vendors to provide firmware at all designed for linux. For some other vendors it will surely encourage them to release the source, which will only lead to a massive hack-fest and fast improvement in capabilities of the firmware, which the company can negotiate to include in their windoze product. It seems to me separating firmware is win/win for both vendors and users, even if it is rocky while the separation is taking place.
-- Bob
Re:about time (Score:3, Insightful)
Firmware is OS specific? The utility to load (or manipulate) the firmware might be, but I seriously doubt the firmeware itself is.
Re:about time (Score:3, Insightful)
It allows v
Re:about time (Score:1)
I hope you mean from the root user - giving normal users the ability to update the firmware would scare the helloutame...
that decision strikes me as bad... (Score:2, Informative)
Sorry, but I think this is a bad decision. Yes, it would be nice to have sources for more firmware available, but that doesn't strike me as a battle worth fighting right now and it doesn't strike me as something that the GPL requires. And Debian hardware support is iffy enough as it is relative to other distributions.
Re: (Score:2)
Re:that decision strikes me as bad... (Score:2)
The purpose of linking is to enable functions to call each other across compilation boundaries. The firmware cannot be called before linking and it cannot be called after linking. Hence, it didn't get linked. It simply is data that happens to be in a kernel module.
There is nothing in the GPL about how it's ok to withhold source if a part of the program gets uploaded somewhere and run on a different box.
The GPL does
Short Term Pain (Score:2)
It reminds me a bit of how Gentoo operates with Java, when you install it, emerge (apt for Gentoo) tells you to go and grab this file and put it here. That way you can e
Debian developers discussing dropping non-free (Score:2)
This is something I personally consider a bad idea, as a long time Debian user. As dcocos says, just make it available explicitly as non-free the same way the nvidia drivers are now.
Bob-
Re:Debian developers discussing dropping non-free (Score:3, Informative)
It didn't even garner a simple majority [debianplanet.org].
Even if the vote passed you still would have been able to install non-free software on your debian machine, you just wouldn't be able to install it from debian or a debian mirror. Kind of like the blackdown java packages right now.
Re:Short Term Pain (Score:2)
Michael
more importantly is.. (Score:2)
If it is a few hardware devices then it wont be a huge issue to debian users. But if suddently all wireless devices stop working ( probably overkill ) then what will be left? Replace wireless devices with your favorite hardware device that may stop working. I hope he puts out a list of all things that will stop working or will require users to do more in their configs.
Although the sentiment is good... (Score:3, Insightful)
How does RMS expect us to compile a kernel for our architecture and for every architecture which we need embedded firmware for? We could end up being required to have dozens of different compilers (think ARM7, i960, MIPS...), not to mention libraries and other tools installed. Many of these are closed source, or are restricted from distributing the source. A good example is the DSP I am using at an optical controller company - the silicon vendor is the only source of the compiler which costs $4000 U.S., not to mention that many of the libraries we use are not available in source form.
Trust me, the embedded market is a completely different picture than the desktop when it comes to development. Even if the firmware source was released it would do you no good.
Re:Although the sentiment is good... (Score:1)
"Hex strings inside a driver" are not the preferred form for modifying the firmware and are thus not "source code" under the GNU GPL. To solve this GPL incompatibility, have a userspace program (which is not considered linked to the kernel) upload the firmware to the device.
thank debian for taking up the issue (Score:4, Interesting)
keeping that out of the kernel and as something to be loaded by hotplug is the best that can be done for devices that the vendor won't (and often can't) provide full source for.
the messier issue is where do you draw the line at what is allowed and what is not? is a sequence of 20-odd magic values written to proprietary chipset registers any different than 800 bytes stored in a string and sent to the device on startup? both are equally obfuscated but only one is likely "code" in any sense due to its size.
less and less devices will bother to have any rom and firmware on them in the future as a flash rom takes space and costs money and is not needed when the OS can load it for you. tackle this now!
Re:thank debian for taking up the issue (Score:2)
> less and less devices will bother to have any rom
> and firmware on them in the future as a flash rom
> takes space and costs money and is not needed when
> the OS can load it for you. tackle this now!
ROM (not flash) is the cheapest kind of memory. RAM requires its own controller, and you can't boot from the device, obviously.
Re:thank debian for taking up the issue (Score:1)
Re:thank debian for taking up the issue (Score:2)
Re:thank debian for taking up the issue (Score:2, Insightful)
While I can understand the fuss about binary-only drivers, I think embedding firmware code should be allowed. It should be seen as data needed to initialize the device in a workable state. I think there's no difference between only a few bytes written to some registers, or a
Non-archicture microcontrollers? (Score:2)
What happens if the card has an embedded controller that uses an architecture that isn't easily compiled by gcc or something?
What do you do then?
Obviously is keep it precompiled.
This, while good intentioned, I can see breaking a lot of things which aren't really purposefully breaking a lot of things without easy solutions.
Re:Non-archicture microcontrollers? (Score:2)
--jeff++
Every time I hear someone whining about Debian... (Score:5, Insightful)
Q: "But why don't they include the accelerated NVidia driver?!? That would be useful!"
A: Because it's not Free.
Q: "But why don't they include qmail?!? That would be useful!"
A: Because it's not Free.
Q: "But why don't they include pine?!? That would be useful!"
A: Because it's not Free.
Despite that, every time Debian removes (or refuses to add) a piece of non-Free software, the "pragmists" queue up to swear that Debian is irrelevant because they don't care about market share, or that they're a bunch of extremists.
Understand this: Debian has a very explicit social contract with their users. If you continue to be surprised by their strict adherence, then either 1)you need to accept that they will always side with Freedom over pragmatism, or 2)you have a seriously warped worldview that causes you to be mystified by integrity. Either way, find something else to gripe about.
Debian is Free and increasingly popular among those of use who share that value. Every time they make a difficult decision like this, even at the expense of practicality, I respect them even more. Even if you hate Debian, you still benefit from their hard-line observation of their ideals every time you execute a bit of Free code that exists because they otherwise would have rejected it from their distributions.
I just don't why some people are still surprised each and every time. A real news article would be "Debian includes Qmail in 'main'". Now that would be a reason to criticize them. This is not.
Re:Every time I hear someone whining about Debian. (Score:3, Insightful)
The explicit social contract is the #1 reason why I stick with Debian. In the past, Debian had a number of unique features like apt and a sensi
This doesn't get front page (Score:2, Insightful)
Deciding just what is open source when it comes to the kernel gets stuck in developer section, but a rumor that Darth Vader may be setting some new fashion trends that's about 3 paragraphs long - stop the presses.
Debian's done the right thing (Score:3, Interesting)
Normally we think of the kernel as being one package licensed under the GPL. Instead, if we take Torvalds' claim as gospel (and we can since it's estoppel [google.com]), the kernel is GPL'd but ships with non-GPL'd parts. This is no conflict; the firmware is not a derived work and need not be covered under the GPL. As long as Torvalds has the right to redistribute those binary blobs, under any license, then he can distribute them with his kernel.
Debian, however, has a more difficult decision. The Debian Free Software Guidelines (DFSG [debian.org]) dictates that "The program must include source code..." and this clause applies as much to firmware as it does to the kernel core.
It's easy to criticize Debian as being overly pedantic without due concern for their users, or to say that they aren't being pragmatic. Instead Debian alongside hardline Free software advocates such as Stallman himself are being very pragmatic; their efforts of refusing non-Free software promotes the continuing development of Free software. They are consistently working towards a world of Free software, and pragmatically, compromise is a step in the wrong directory.
Maybe the code isn't shipped because we don't have compilers that will compile it. Obviously, the solution isn't to ship binary firmware with the kernel, the solution is to author a Free software compiler for this architecture! Or at least a GCC backend.
The other reason for Debian to be extremely pedantic about legal issues which is commonly overlooked is their dependence on the goodwill of their ftpmasters. The ftpmasters are the group of ISPs donating storage and bandwidth to Debian. Debian offers these people a guarantee: debian-legal (and lawyers with parent company Software in the Public Interest (SPI [spi-inc.org]) are prepared to prove that the ftpmasters do indeed have the rights to redistribute all Debian software. Now, can you prove that with the kernel firmware? What license does it fall under, since it can't possibly be the GPL without source?
Allow Debian to prove free softwares worth (Score:2, Insightful)
To be that exacting... (Score:1)
It certainly seems a reasonable (to me) limitation that I can't call my new CPU the "LinuxPentium" or "Pentium X". If however I got the name from a GPL product it is a restriction on the use of info
Re:To be that exacting... (Score:2, Informative)
In your comment you use the word information, which by itself has no legal meaning. Assuming
Re:To be that exacting... (Score:1)
You miss my point. While pentium is a trademark, the graphic logo is copyrighted. Neither is free to modify and redistribute and thus a violation of 'free software'.
Debian acknowleges this is a lesser problem than potential violation of the GLP. The question is what makes a blob of firmware a "software component" as you call i
Re:To be that exacting... (Score:2, Informative)
It's hard to get what your point is when you consistently blur the real distinctions between the different types of intellectual property. You said "While pentium is a trademark, the graphic logo is copyrighted. Neither is free to modify and redistribute and thus a violation of 'free software' "
For one thing, the word "Pentium" and the Intel graphic logo are both trademarks for Intel. No software license, especially the GPL, gives anyone the right to modify or use someone else's trademark. Also, there is
Re:Bigger issue that you realize (Score:2)
Criticism does not curtail your freedom.