Slashdot Mirror
Bruce Perens On Problems With the Open Hardware Model (arvideonews.com)
Bruce Perens writes: At the TAPR conference this year, I did a talk on why Open Hardware licenses don't actually work, and how it would actually hurt us if they did. I'm not saying you should stop making Open Hardware, I just want to make sure you don't assume the license works better than it actually does. Also, I explain why my latest project is 100% Open Source but the hardware design is more restrictively licensed than the Open Hardware Definition would allow. The video is here. There's a long prelude of talk about Amateur Radio stuff before the Open Hardware part. But you'll probably find it interesting. Gary didn't succeed with the Kickstarter to fund recording the entire conference this year, but he made the trip and recorded it with a multi-camera shoot anyway, at significant personal expense. If you like the video, please help cover his expenses. Even $1 would help.
No one wants to sit through a video. Just summarize the issues. I'd love to hear the convuluted logic on why Open Source works, but Open Hardware doesn't. After all, information wants to be free.
Why does any sort of non-trivial undertaking require a kickstarter nowadays? With the proliferation of dSLR's and youtube wannabes I'm sure he could find half a dozen people with the gear who would be prepared to do it for the experience. Documenting a conference doesn't require a great deal of skill or creativity, just make sure they are exposed and in focus, sounds already been sorted and they stand reasonably still.
Who is Bruce Perens? And why should I care what he thinks about open hardware? Open hardware is definitely a good thing for interoperability and security. An open hardware version of the BSD, LGPL, and GPL licenses is a good thing to provide developers varying approaches to free (as in freedom, not beer) hardware. If I buy hardware, I deserve to be able to see how it's designed. Even if I don't care about interoperability and if security isn't an issue, it makes it a lot easier for me to fix the hardware if it breaks.
Open hardware is hard mostly for economic and some legal reasons.
1) Open source works because of copyright. There is no such thing as copyright on hardware. There are patents but they are expensive and (comparatively) difficult to get. Copyright is automatic and free the moment you write something. Not so for hardware so certain types of open source licensing are off the table immediately with hardware unless someone wealthy is willing to spring for a patent and be willing to defend it.
2) Even if you intend to give away the designs, there are comparatively few people who can do anything with them. The cost of equipment needed to make/modify software is a rounding error compared with most hardware.
3) Marginal cost of production for hardware is always significant and far higher than for software. For software it is a good approximation of zero cost to make another copy. Even the simplest hardware costs substantial sums of money to produce in any quantity. This makes it far more difficult for individuals to make and modify works economically. It's somewhat like back in the day when you had to actually own an expensive printing press to publish anything. You can reduce the cost of hardware but so far we don't have any way to make it as cheap as software.
Most hardware is software long before it takes physical form. There are designs and simulations that run completely in software. The designs and simulations are what people can open source. When we are talking about open source hardware, we are really talking about software.
Right, he only takes currencies. Maybe he's full up on drugs.
The original article, and almost all of the posts following that are construing the word "Hardware" very narrowly.
* An "open CPU architecture" ...all of these are "hardware". Sure, an open CPU design is problematic because you need massive software infrastructure to maintain compilers and such. Sure, an open silicon design is almost impossible for any of us to reproduce. Sure, most of us are not going to be making custom ASICS. But we *can* all program an off-the-shelf FPGA - or have a PCB manufactured - or figure out how to assemble a 3D printer from stuff you can buy in Home Depot.
* An "open silicon design of some kind"
* An "open ASIC design"
* An "open FPGA design"
* An "open PCB design"
* An "open design for a 3D printer"
* An "open design for a modular house"
So this conversation needs to be sharply narrowed if it's going to be about the difficult stuff at the top of the list without shutting out the very successful projects at the bottom of the list.
www.sjbaker.org
Huh? Can you show an example?
Huh? Can you show an example?
Google for SystemVerilog, Verilog, or VHDL. All complex ASIC designs are developed in these languages and the design is called RTL (register-transfer level). The company Synopsys has a tool called Design Compiler that converts from RTL to gate level netlists. The netlists are then converted into silicon.
But the entire chip is able to be fully simulated prior to the production of any silicon. Except for the circuit and synthesis (RTL->netlist) guys, nearly everyone else who works on the 'frontend' pre-silicon portion of a chip is doing nothing but writing software and running simulations. The software gets nearly directly converted into hardware.
Ah, that's why stuff never works these days.
Faster! Faster! Faster would be better!
There are some great similarities, as well as differences
Similarities - your catcher in baseball is called a wicket keeper in cricket - who stands behind the batter (called a batsman in cricket). Your pitcher is called a bowler (difference explained below). You have 2 batsmen in cricket and just 2 ends, as opposed to the diamond. There are some great similarities in practice - like both catchers and keepers tend to be good batters, given them following the ball all the time that they are fielding.
Differences - as I mentioned, 2 ends instead of 4. Also, in baseball, the pitcher stands in one place and throws the ball - bending the elbow is allowed. In cricket, the bowler is allowed to run up to the wicket and then bowl - here, he can't bend his elbows, or else, it's a 'no-ball', and a run gets added to the batting side, but not to the batsman. Also, in baseball, if the batter misses 3 times and the ball ends up in the gloves of the catcher, it's the 3 strikes rule. In cricket, if a batsman keeps missing, he's fine, so long as the bat doesn't touch or nick the ball. In short, a batsman can bat for hours w/o scoring any run, whereas in baseball, from what I can gather, the team won't last long w/o scoring.
Those are some of the quick ones - I'm sure there are a ton more parallels b/w the 2 games.
Google for SystemVerilog, Verilog, or VHDL. All complex ASIC designs are developed in these languages and the design is called RTL (register-transfer level).
Pah! I am well aware with those and they are hardware description languages, not software! For example, if you run some simulations in Quartus, it is emulating hardware, not running programs.
Except they can't lock it up because it's hardware, not software. Even without a schematic, it's a trivial matter to reverse engineer the hardware and copy it. That's how the IBM PC compatibles were made (the only tricky part being the BIOS which is software). In a very real sense, ALL hardware is Open Hardware.
Support Right To Repair Legislation.
The slide at 24:49 in the video summarizes the argument:
* Open Hardware licensing attempts to work using copyright but is unsuccessful in doing so. (You can't actually enforce an Open Hardware license in the courts, where the mechanism is a copyright on an electronic circuit. You can't really copyright a circuit.)
* Open Hardware licensing only works as the developers would have it work when there is a *patent* on the design.
* Patents are expensive to pursue, and not particularly attractive to people who work on Open things.
* If the law was changed to allow electronic circuits to be copyrighted, that would actually cause more harm to the community than good. (The reasons for this are discussed later in the video.) We could, through our own actions, make that happen.
I have written a truly remarkable program which this sig is too small to contain.
Not sure what you're getting at, but it's not a summary of my talk.
Bruce Perens.
The poster you're replying to, "mr_mischef", did not summarize my talk. He just wrote jibberish. The name of the poster might have been a clue :-) The slides are here.
Bruce Perens.
I thought that "open source" as pitched by Perens and Raymond, was mainly distinguished from Stallman's Free Software
The Open Source Definition published by Mr. Raymond's organization is nearly word-for-word identical to the Debian Free Software Guidelines. Each item in the DFSG expounds on an item in FSF's definition of free software: DFSG 1 is FSF 2, DFSG 2 is FSF 1, DFSG 3 and 8 and OSD 10 are FSF 3, DFSG 4 explains how Debian applied FSF 3 to the QPL, DFSG 5 and 6 are FSF 0, DFSG 7 ensures FSF 3 applies even on a desert island, and DFSG 9 explains how Debian applies FSF 2 to collective works.
by the former's lack of restrictions on what the licensee could do with the software.
It depends on what exactly you mean by "what the licensee could do with the software." Copyleft licenses, such as the GNU General Public License, qualify under the definition. A license that bans use by a "group of persons" or in a "specific field of endeavor" would not.
Exactly what I was getting at, I can't think of any professionally designed hardware in the last twenty years that wouldn't first be designed and specified in software.
No, not really. Open Source works because there is a very low barrier to entry since the tools other than a general purpose compute are free, there is no cost of fabrication, there are economic incentives for developers even when they aren't monetary, and developers have terms available that can keep it free rather than making it a no-terms gift to big companies and child-labor manufacturers. Open Hardware licensing doesn't work to support those same terms, and the incentives are different because of the financial outlay for tools, fabrication, and facilities is larger (about $50K so far in my case) and the potential for distributed collaboration to work is lower (but we might be able to fix that for some kinds of circuits).
Consider the cost of rapid-turning a 6-layer analog PCB with 500 components to test bug fixes. I can't get below about $2000/turn. I have perfectly valid schematics that make too much noise for a good receiver as laid out, etc., so that needs board turns to fix. With Open Source software, I just recompile. So there are fundamental differences.
Bruce Perens.
If you take something like VHDL or Verilog, it looks like software but actually translates to digital circuitry elements instead of CPU instructions.
I don't think even RMS advocates for free (as in freedom) hardware.
Oy! I'm a drug-addled pothead who doesn't accept Bitcoin, you insensitive clod!
Il n'y a pas de Planet B.
Fair enough.
I came to the same conclusions when studying the possibility of "open sourcing" a data standard. Software + forking = good (or OK). Standards + forking = bad. Forking a standard, without careful control, inevitably kills it.
What, you'd rather hear from the horse's mouth than the other end of the horse?
Slashdot wasn't always this bad. Many smart people seem to have absconded and thus the S/N ratio is much higher now.
Bruce Perens.
Slashdot wasn't always this bad. Many smart people seem to have absconded and thus the S/N ratio is much higher now.
You got S/N backwards. No wonder you're having problems with your circuit.
Have a nice time.