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.
Big Earl: Alright guys, I'm not gonna lie to you. This is gonna get kinda weird... Two dragons.
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.
Hardware is an instantiation of my wire wrap gun, fucker.
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?
Even in ASIC design there are true hardware guys. The guys doing IO circuits without the aid of high level languages like SystemVerilog are doing hardware design. The guys taking the Design Compiler synthesis results and doing manual layout or potentially automatic place and route are all hardware guys.
Even the act of system verilog logic coding still needs some level of hardware design experience as you are constrained by setup and hold times. If you can't make timing, your software won't produce functional hardware.
So yes, the core logic design of all major ASICs today is just a software job. But there is still real hardware work going on with those designs, and the software alone is nearly useless if you don't have the hardware expertise to turn that software into functioning silicon.
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.
What are you talking about? You think people design hardware by slapping things together on a breadboard and sticking scopes around at random? LOL
OP described *exactly* how hardware is designed. All of it. That Airbus in the sky? You think people glued together some aluminum tubes, THEN designed a plane?
That CPU in your computer/phone/tablet... you know, with a billion transistors... It was entirely designed in software first....
So for showing you an example, where have you been for the last 50 years?
I don't see how that comment was a troll. I was about to send him 25 cents even though I don't have any interest in the videos he made.
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.
Life's too short to watch a talking head, so his point will be forever lost on me.
I nor you have been hurt by the ones I have worked on.
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.
Re the "debullshitted" translation:
Ouch!
That's a bit harsh, but unfortunately it does at least partly reflect what he said. Our dear Bruce is confused by the fact that he wears two different hats, and he doesn't seem to recognize when he's swapped from one to the other. He makes no effort to separate them when giving an opinion, nor uses disclaimers.
One hat is labelled "Radio amateur / FOSS evangelist", and many radio amateurs and FOSS supporters applaud him for that. The other hat is labelled "Businessman", and most radio amateurs and FOSS supporters probably couldn't care less what he thinks and even less says in that role.
Those two roles are in direct conflict, and while he'd probably say "No they're not", that would be the Businessman role speaking.
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.
He doesn't accept Bitcoin because he's not a drug-addled pothead.
Don't be surprised that most people don't accept the currency of crime.
" hardware description languages, not software"
Is VHDL sculpted? Danced? Baked? Cooked? Is it sung? Or maybe it's mimed?
" you run some simulations in Quartus, it is emulating hardware, not running programs."
Tell us the truth; you were born with the cord wrapped around your neck?
"the design is called RTL (register-transfer level)."
Um, no, RTL is part of the design process. It is not "the" design.
Curious: where did you get this level of wrongness?
What do you think SPICE is, for example?
Software is almost trivial to duplicate, and if it's open source you don't even have to pretend to feel guilty.
Hardware, on the other hand, is tricky. You need to build stuff (or at least CAD it and find someone in China to make it), debug the design, iterate until it works, go through government quality assurance hurdles, and invest your money into a whole bunch of physical stuff that might not even sell. Much riskier than just ripping off some software and dressing it up in your company's look and feel.
Besides which: I'm old enough to have worked in an electronics repair shop (remember them?) and repaired TVs and such that came with a circuit diagram (there's your open hardware design) and full service information printed and stashed inside the cabinet itself. And yet somehow the world did not come to an end...
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.
You seem to be confusing "software" with the vastly narrower category of "programs running on discrete implementations of a Turing Machine". Software is *far* broader than that.
VHDL and Verilog programs most definitely qualify as software, as do the configuration systems for quantum computers (including the quantum annealing kind), as also do the control languages for gene expression and other areas of biotech and chemistry, and the design specifications for molecular nanotechnology. The targets are different kinds of hardware in all of those cases, and there will be many more such non-Turing hardware targets as technology evolves. Add 3D printing specifications to the list too.
The only requirement for something to qualify as "software" is that it's a specification in an abstract language or environment representing and controlling the end target through a layer of abstraction, nothing else. The target doesn't even have to be digital.
Oy! I'm a drug-addled pothead who doesn't accept Bitcoin, you insensitive clod!
Il n'y a pas de Planet B.
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.
Sure, for simple FPGA designs, one can describe it in VHDL,Verilog, etc. and gosh, it will simulate just fine (at rates MUCH, MUCH slower than on the target), but when you actually make the bitstream and run it on the chip, it might not work. Furthermore, simulation is so slow, you might never simulate all the functionality. It's faster to test at full speed in hardware. However, I'll say that's "software".
Now take analog signal processing, whether high performance audio or RF or whatever. There are design tools which model various aspects, but nothing anywhere as accurate as building the board and trying it. And that's what Bruce is talking about. Each "spin" costs thousands of dollars in fab costs (cash), labor, and there's a substantial investment in hardware to test that board. You can probably test most classic "software" (i.e. something that runs on a PC) for just labor time: you've already got the PC. Even for a lot of embedded-y kinds of things (Arduino, PIC) the hardware instance is cheap, and the diagnostic tools are not too pricey (Oscilloscope, etc.).
But if you're building a real radio, you need spectrum analyzers, signal generators, etc.; Those do not come cheap (leaving aside spending substantial amounts of labor to refurbish, repair, reuse old obsolete gear.. labor hours are not "free").