Slashdot Mirror
Why Don't Companies Release Specs?
Mhrmnhrm asks: "With the recent activism by the OpenBSD crew focusing on release of documentation from the likes of Adaptec, Intel, and others, I'm left to wonder: why do companies insist on believing that by denying access to the specs, they somehow gain an advantage? It's not like telling a programmer how to communicate with the underlying hardware is going to tell them how it (the PCB/silicon) was designed, so why make this information secret?"
Because it would cost them money to (1) write coherent and complete documentation and (2) review that documentation to make it safe and legal for public consumption. Why would they spend all the extra time and money to do that when it doesn't bring them any more profit?
Companies exist to make money, not to be good samaritans.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
... the more common problem is that the hardware people paid to have their drivers and stuff written for them and that a great deal of their product's functionality is, in fact, within the driver rather than within the device or firmware. These drivers are then restricted by the agreement between the driver-writing entity and the hardware maker... or so they claim. ATI apparantly has this difficulty which is why we can't get really good drivers for Linux just yet.
It's because of fear of lawsuits, not a desire to hide their chip interfaces. There are just as many bad hardware patents as bad software ones. By controlling spec release with an NDA they stop the law firms from searching for violations of these bogus patents.
The damage from keeping hardware specs out of open source hands is tiny compared to getting a $400M judgement for patent violation.
Trade secret laws prevent law firms from forcing spec releases without pretty good proof of a patent violation.
I have often wondered about this myself, back in the day of the Apple IIs and TRS-80s there were almost always hardware specs available because that was what you used to program your application with. There were no drivers or OS abstraction layers, there wasn't enough memory or speed to do that so your program just talked directly to the hardware.
The first time I realized there was a problem was back in the 90s when my brother was trying to load up Linux on one of his machines and complaining that his video card wasn't supported because the people who made it (Diamond Multimedia?) wouldn't release any specs and people were having to reverse engineer how it worked. That seemed crazy to me. Back then it wasn't just a Windows world either, OS/2 was still around and DOS apps were huge. It boggled my mind that anyone would hold back information like that because releasing programming specs would encourage third party application development that made use of their hardware and ultimately boost their sales!
Sadly these days no one seems to care as long as the vendor has a Microsoft Windows XP(TM) driver available, even if the driver is half-assed and crashes some times.
Does anyone seriously doubt that they DO?
Andy Grove (ex CEO of INTEL) described how MS prevented INTEL from including certain features in H/W. Andy's reaction was life is too short to spend it fighting MS. This was INTEL not some much smaller niche player.
At places I've worked there are usually 3 reasons.
1) Design documents are written pre-release as marketing info before silicon is made. And no one wants to spend the money to go back and fix the document to how the silicon was really built.
2) A lot of silicon designs are rented IP. And there are contractual reasons for not releasing the disign information.
3) Support costs. It costs money to keep documents current and respond to document errors.
...there are no specs.
Often products are created & sold based on some back-of-a-napkin drawing that a manager handed to development. I've been fortunate in my career -- I've been lucky to get them on notebook paper. It's much nicer than trying to figure out what was drawn through the martini condensation stains...
Chip H.
They don't release the specs because the hardware is generally full of bugs that they work around in their drivers. Different versions of the hardware have their own bugs and work arounds. Sometimes I think they're too embarassed to release the specs for fear the would would see what a dogs breakfast some of their work amounts to.
Further most of them have "specs" which barely qualify for the name -- often driver writers will go read the RTL, or talk directly to the hardware guys to figure out how something works -- often much of it is not written down, and usually not in one coherent document that could be called a spec.
I know this for a fact about several producers of hardware that serves various purposes -- who, for obvious reasons, I shall not name.
Others are anal about getting things right and writing great specs -- even if they never publish them -- But I think they're in the minority.
Ian Ameline
Thing is, we're not asking for source code to the win32 driver or firmware source code or roms or verilog source for the chips.
We're just asking which pci registers to poke to get the chip to go "bleep".
So the 'source code' argument is totally out the window, irrelevant.
I was about to mod you insightful, but then I realized what the grandparent was probably talking about... the microcode. The microcode is a lot more important for recreating details. Pentium processors have a limited ability to fix silicon bugs in software. The microcode is in volatile memory, so it must be loaded on every boot by either the OS or the BIOS. It's top-secret, but access to this lower-level info might let you write a custom instruction (or not, I don't know how much the mechanism can change the operation)
An example microcode fix is for "High Temperature and Low Supply Voltage Operation May Result in Incorrect Processor Operation"
HIV Crosses Species Barrier... into Muppets
Bill: That's nice. You know, it'd be a real shame if your driver couldn't be WHQL certified, and users had to see a warning box when they ran with your card. Or worse, if there were mysterious blue screens . . .
"It'd be a real shame when our engineers show a disassembly of your driver verification software before the last windows update and after causing our drivers to break, especially in light of this conversation. There's a few judges who might see things our way."
Claims of conspiracy are just intellectual laziness. I suspect yours was a joke, but I think many people actually believe it.
Now to make my own point: I know companies have IP arrangements that prevent them from opening drivers. Wouldn't it be nice if they disclosed this fact, or gave some kind of reasonable explanation to developers other than patting them on the head and saying "no specs today, go have some cookies". I'd just like to see the FAQ of "Why isn't the driver open source" answered truthfully and reasonably completely.
I'd also like a pony.
I am no longer wasting my time with slashdot
R&D Costs for driver development can't be recouped
When BusLogic came out with their AHA1540/AQHA1542 compatible SCSI controllers, they did several things:
(1) They leveraged Adaptec's R&D effort on driver development so that they didn't have to spend their own money developing drivers.
(2) They avoid the effort of convincing Microsoft to ship with the drivers as part of Windows; never underestimate the barrier to entry a separate driver disk represents: for NT 3.51, you had to install the driver disk twice during the installation process, and a third time post-install to use a third party disk controller, and it was not well documented where or when NT 3.51 would reference the disk, not find it, and simply crash (you "just had to know").
(3) By making the card's interface compatible with an existing card, they avoided all the R&D necessary to get from a concept to a working interface.
So basically, BusLogic got a free ride on Adaptec's dime in a number of areas, and Adaptec was left holding the bag, having to charge a higher amount to recoup their R&D investment, leaving BusLogic to undercut their prices and steal their market.
That's not to say that I totally agree with Adaptec, or that bad designs which can't be safely exposed without risking physical damage to the devices (Diamond Multimedia video cards[*]) or legal repercussions (Oscillator/PLL tuned WiFi cards that don't have hard-wired frequency bands) don't exist, but I can certainly understand the position of companies who don't want to sacrifice hard-earned product lead-times, OS vendor relationships, or actual R&D results on the altar of public domain.
[*] Diamond, in particular, pisses me off, since any halfway decent software engineer could have separated the model and view from the controller, and made their cards both Open Source friendly and non-x86 architecture friendly, and the EE who wrote the firmware didn't.
-- Terry
The firmware source which you can download, unfortunately, either comes without the wireless drivers or with binary wireless drives compiled only for the embedded processor which sits in the boards. Which leads us back to square one.
Thus, since Broadcom obviously already have working Linux drivers, it would be a simple matter for them to release them. However, being a company with a bad (but recently improved) history of cooperating with the OSS community, our only option is to support and buy products from those who do it well.
There's a standard for FireWire cameras, and, having written a generic FireWire camera driver for QNX, I can report that it works.
I used to work in the DOCSIS cable modem industry, so I'm reasonably familiar with the Broadcom 335x/334x CPU family. The best I ever saw was the datasheet for the 3416 chip (tuner chip).
For those of you who aren't aware, or don't remember, Broadcom was slapped with a lawsuit by Microtune, alleging patent violations http://news.com.com/2100-1006_3-5064586.html, (one of many articles available on this subject).
So, I was tasked with providing software support for the 3416 tuner chip (the replacement for the 3415 "problem" chip) in our cable modem product, as the 3415 couldn't legally be sold in the U.S. anymore. Well, I figured it would be easy, since the datasheets for the two chips were exactly the same, except that "3415" was changed to "3416". (And, I mean exactly the same, to the word - it was only a 15 page datasheet, so I compared them).
Nope, good old Broadcom documentation does it again... I managed to study the source code for one of the newer cable modem CPUs and find the changes between the chips. The real stupid thing though: Even though there's a version register (which tells which version the chip is), they didn't update it to indicate a 3415/3416, even though they had the bits available. So, 3416 chips would show up as 3415 chips if you try to read the version number (that made things difficult).
Incidentally, Broadcom does make Linux drivers for most of it's newer hardware, they're just meant for their customers (the OEMs making the hardware, not the end-users). The general rule with Broadcom is, if you pay them a lot of money, you get excellent support. (At the previous company I worked for, I had an engineer that would get back to me within 24 hours on any issue related to the product, because we bought so many cable modem chips. When I currently work, they won't even give us the time of day, we just don't purchase enough.)
I feel your pain, I really do.
-- Joe
i argee on the video cards, it's less then 1% of the market for them and maybe not worth it. however these arguments that IP is valuable. thats just secret sauce bullshit. what do they honestly think they are so super clever that no one else has or can think up the same designs. it's just so bogus. it's the same kind of nonsense that had the USA restricting encryption software being exported. they thought they were the only ones clever enough to develope such things.
If you mod me down, I will become more powerful than you can imagine....
Your basic problem is that you aren't thinking like a hardware person. Hardware people just fundamentally don't get how software people think there is an important distinction to be drawn between the software and the hardware that runs it--and, to be fair to them, they have a point.
An awful lot of what hardware vendors are selling these days is a hardware platform for their expensive proprietary software. Take wireless network interface cards, for example. When you buy a Wi-Fi AP from some company, e.g. Apple, the price you pay includes the cut they have to pay to the vendor of the wireless interface card they use in their products. What they probably get from the hardware vendor is more than just a steady supply of hardware to its factory line-- it's the chips, plus a code drop for the driver, a maintenance agreement, and a bunch of other goodies that are all rolled up in the contract at once. The price the hardware vendor charges is divided between a per-unit total, a per-calendar-interval total and sometimes an upfront charge. The accountants have a field day.
Remembering who is paying for what helps here. You are never going to get specifications for the hardware you buy at retail, because the people who make it are never in control of the whole package from sand to plastic wrap-- they have to buy and integrate pieces from other companies, who are providing more than just chips and a few pages of programming guide. As I said, those guys are providing a hardware platform for their proprietary software and they won't let the vendors of retail systems redistribute their crown jewels. It's really that simple.
jhw
Good point, but there are ways around that. I have an Atheros WiFi card and use the MADWIFI driver for it. Most of the driver is open-source, but the core radio part is distributed binary-only. This is not just because they think it's a good idea, but because it would be in violation of FCC regulations to allow this part of the driver to be modified. However, Atheros was nice enough to provide this binary-only part compiled for many different Linux platforms and to give assistance to the people writing the rest.
Mission
Availability of a graphics card with fully published specs and open source drivers.
Note that the mission is not to actually design or make it. And:
In order to get manufacturers to make such hardware, we have to show that it will be economically viable to do so.
No mention of making it themselves. The rest of the page makes it appear that their main work is coming up with a feature list.
If you dig through the rest of the site, it appears some guy wrote some sort of emulator and they intend to convince someone else to translate it to FPGA code and put it on an FPGA, but the FPGA code probably won't be available. That's not an open source graphics card.
I believe this project is an offshoot of what was originally this guy's ideas. In fact I am pretty sure of it because the name of the guy on OpenGraphics is also Timothy Miller. I wrote those guys when that original article first hit slashdot that I was willing to pre-commit to paying $200 each for up to 5 cards, and I stand by that. But I won't pay for someone's simulation code, or for an FPGA sold by the same bullshit company as before and with a closed FPGA.
I wish someone would try to do an Open Source graphics card, I'd like to buy it. I think it it likely that people would find other uses for it -- reprogramming it to be a software radio, for example. Perhaps after the Open Graphics Card project screws around with the big companies enough, someone else will take their simulation and design and make an open graphics card.
But in the end, the Open Graphics Card project is simply producing a very detailed spec and begging one of the usual asshole companies to make a closed source version to match it. This is doomed to failure. They won't do it, and if they do there will be small undocumented differences from the spec and you won't be able to correct the spec easily or change the FPGA.
This is not a situation that can be solved by lobbying companies. I believe it can be solved by making hardware, even if you have to make your own company in the process.
It's very simple: back in the old days, when there was no monopoly, many chip manufacturers gave away thick, printed databooks. It was expensive for them, but they needed developers to use their products.
Now, however, there is a monopoly. You don't need to attract developers. The only concern is to have a driver for Windows, and having that driver included with the Windows install disk, so that your device, be it a soundcard, graphics card, or whatever, is "easier" to use. I wonder if there is a "dark hand" behind it...
Some years ago I sent a proposal to the European Comission: banning the sale in Europe of peripherals for which there is no public interface information available. It should not hurt the manufacturers, as the information can be made freely available in Internet (it's cheaper than shipping huge printed manuals), but it would have a side effect: the driver advantage for Window could disappear.
Software giants do bully hardware vendors, Microsoft and others have been shown to do it. So where's the conspiracy?
I never understood that argument. I agree that from a pure quantitative perspective it is easier to make the hardware operate out of the authorized specs if you do have the driver source code. However, any more-than-average hacker can decompile a binary driver and replace the adequate values directly in the code. Hacking the source requires very similar programming skills.
Is there some jurisprudence somewhere which states that if you provide source instead of binary to someone, you are breaking the law if that person can later on change the source code to break some regulations ? That would be damn precise and subtile from our beloved law people.
--
Go Debian!