Slashdot Mirror
Best Open Source License For Hardware?
An anonymous reader writes "MIT recently open-sourced some really cool hardware designs, including an H.264 video decoder and an OFDM transceiver, under MIT's open source license (a.k.a. the X11 license). Now, the OpenCores FAQ recommends that people use either the GPL, LGPL, or modified BSD license; they do not mention the MIT license at all. And, according to the Free Software Foundation the GPL license can be used for hardware, but they do not list the LPGL, modified BSD, or MIT licenses as suitable for non-software. Would you or your company use hardware source-released under the MIT license? What's the best license to use for releasing hardware?"
Would anyone care to point out the practical differences between the MIT/X and the modified BSD licenses? Basically, there aren't any, so of course it makes sense for MIT to have used the MIT license.
There is no significant difference between the MIT license and the modified BSD license.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
You can also copyright the masks and layouts of the transistors. Board artwork for circuit boards has long been held as copyrightable, and the miniaturized artwork that exists on a CPU is no different. If you look at closeups of dies, you will see a © symbol occasionally, such as on this one.
Program Intellivision!
"The Free Software Foundation has a transparent agenda: GPL at all costs."
Don't spread FUD about the FSF. Their agenda is not the GPL at all costs, it is to promote free software, and those are two different things.
Counterexamples to your claim of "GPL at all costs":
- The FSF plainly says that free software does not require using the GPL [0]
- The FSF plainly says that releasing software under the modified BSD license (or another non-copyleft license) is not wrong [1]
- The FSF does not use the GPL for all of its software, because it hopes that by doing so it will promote free software [2]
[0] http://www.gnu.org/licenses/gpl-faq.html#DoesFreeSoftwareMeanUsingTheGPL
[1] http://www.gnu.org/philosophy/why-copyleft.html
[2] http://www.gnu.org/licenses/why-not-lgpl.html
You can always license it under the WTFPL, whose terms are quite simple:
--------
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
Version 2, December 2004
Copyright (C) 2004 Sam Hocevar
14 rue de Plaisance, 75014 Paris, France
Everyone is permitted to copy and distribute verbatim or modified
copies of this license document, and changing it is allowed as long
as the name is changed.
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. You just DO WHAT THE FUCK YOU WANT TO.
--------
I would say that is a relatively free license, and it satisfies your scenario, if it really *is* a problem.
Tequila: It's not just for breakfast anymore!
This kind of "hardware" has a more applicable term that differentiates it from actual hardware (boards, resistors, etc.): firmware. As the name applies, it is kind of software, but not really software, and kind of hardware, but not quite hardware. It sits somewhere in the middle. It is described by "code" (more aptly called a Hardware Description Language, or HDL) but the result is "hardware" in the form of a chip (be it an ASIC, FPGA, CPLD, etc.). It seems to be an intrinsic gray area. Should we handle it like software? Or hardware? Or both? Or neither? Answers to these types of questions are not always clean-cut.
And in case you are wondering, I design firmware for a living.
I wrote the section of the OpenCores FAQ that the story refers to so I can give a little background history.
...) it was decided that licenses such as the GPL could be applied. It is still not clear by what legal mechanism a hardware manufacturer can be forced to disclose the "open" portions of a system.
The FAQ answer was the result of an extended discussion on the OpenCores mailing lists about the best license to use. We didn't come up with a definitive answer and the GPL, LGPL, modified BSD recommendation was aimed at reducing license proliferation while giving people a choice between copyleft and non-copyleft. The MIT license was judged to be close enough to the modified BSD license (also noted by OSI) that we could just choose one of them. Reducing proliferation was an issue since people were experimenting with different homebrewed licenses with potential to fragment the community.
Open and Free licensing is still a murky issue for hardware as much of hardware falls outside of copyright. In so far as copyright applies (schematics, bitstreams, source code,
For example say someone builds an integrated circuit using GPLd VHDL from the OpenCores website. The chip might be covered by circuit layout rights but it is questionable whether copyright is applicable. It seems unclear that the GPL can be applied to a chip. A system such as a circuit board is even murkier since it is not covered by circuit layout rights and being a functional system might fall outside copyright (despite manufacturers plastering their boards with the copyright symbol). Any copyright could also be circumvented by rerunning an autorouter with a different seed to generate a different pattern of PCB tracks.
It will be very interesting to see what conclusion Eben Moglen, Mary Lou Jepsen and so on come to now that the OLPC and Pixel Qi have prompted the Free Software community to seriously examine the underpinnings of Free Hardware. A number of years ago Richard Stallman was of the view that Free Hardware was outside the mission of the FSF and freedom for hardware was not relevant since the difficulty of manufacturing was a greater barrier to freedom than the law.
*sigh*
The implemented logic is patentable (as long as it meets the other criteria, such as novelty, non-obviousness, and lack of prior art). I can make a new chip using the same logic as the current one and, if it's a different layout, then I only have to worry about patents. If the logic is patented, I'd run afoul of the patents.
Layout, though, is not a patent issue unless the layout is integral to the invention. I had asserted that layout was covered by copyright, but I was wrong. Both of us were wrong, actually, but it appears I was closer. According to Wikipedia, layouts enjoy a copyright-like protection that is separate of regular copyright law or patents, but mainly because copyright law isn't fully appropriate/adequate. There is a separate "mask work" protection that is very similar to copyright, minus the fair use exception and with a shorter term (10 years). I'm guessing that the die photos I've seen with the © are pre-1984 then. I've seen more recent photos with the (M) they mention.
Mea culpa. Learn something new every day.
--JoeProgram Intellivision!
According to WIPO, At first cut, software is the unique expression of a procedure (or method, etc.) and hardware is the physical infrastructure which allows that procedure to become tangible. When one writes "source code" for Bluespec, the end result could be an ASIC (layout-design) or some bits to tell an FPGA how to behave.
So, is that "source code" software, or a hardware design (it is obviously NOT hardware itself)? If compiled to produce the programming for an FPGA, it is closely analagous to software, but if compiled to produce masks for an ASIC, it's more like a functional specification for hardware. Industry nomenclature notwithstanding (i.e. "VHDL"), describing at a high level a logical function which ultimately causes off-the-shelf hardware (an FPGA) to behave in a certain way is not "hardware design," any more than writing a logic simulator to run under Windows is. If I tell a manufacturer to build me a green sedan with a six cylinder engine, and I doing automotive design? Can I claim a copyright which prevents anyone else from describing (creating an order) for a green sedan with six cylinders?
One might argue against that, and say that bits for an FPGA are analogous to object code for a general purpose computer, but there are significant differences. FPGAs are in general "fixed" in their operation after programming, and used for specific, static purposes which are defined at the time of manufacture (an FPGA typically isn't an H.264 decoder one minute, an Ethernet interface the next). Computers generally perform a flexible range of different functions, at the behest of an end user. When Compaq copied the interconnections in the IBM PC to create the first "clone," there were no copyright concerns (except the software in the BIOS); how is programming the interconnection of gates in an FPGA any different?
For integrated circuits, the "layout-design" (i.e. mask patterns) is copyrightable under law, but the function is clearly not. In fact, since specific text was necessary to provide copyright protection to layout-design, that seems to be an otherwise gray area, which needed that clarification. The function is determined by the interconnection of logic gates, the description of which clearly (to me) falls into the realm of patents.
Let me ask this way - assuming it didn't already exist, would a half-adder be copyrightable or patentable? Would it make a difference if it were expressed as RTL code or as transistors soldered together? Why? My response is that it is only patentable. I think it is clear why in the case of transistors. In the case of RTL code, I believe that the code itself is a functional, not creative, description of the logic involved. The creativity component is the same in both cases - RTL is just a language used to describe the invention. In copyright terms, it is like a phone book (which can't be copyrighted), it's just a list of facts (connect the output of this gate to the input of that one).
How is an H.264 decoder different?
"National Security is the chief cause of national insecurity." - Celine's First Law
Im sure this is a deliberate troll, but to avoid someone getting misinformation.... 1. You don't to publish your changes to GNU GPL code unless you are doing to distribute it. IE if you change linux to suit your environment and never sell/give away those changes you are not obliged to release code. 2. Check the license for GCC, things created with it do not have to be released under the GNU GPL. I suggest you get better lawyers, contact the FSF or at very least read the FAQ on the FSF website.
We (that's Sun Microsystems) chose the GPL as the license under which to release everything necessary to make an UltraSPARC T1 (and more recently, T2). We placed it all - RTL, tools, the lot - at OpenSPARC.Net. The license choice was for two main reasons:
While releasing hardware sources under a Free license is a different deal to software, the GPL seems to encourage the same willingness to examine and use the code as it does in software. The mechanisms for community have to be different because of the capital-intensive nature of the processes to use the code. We've still seen people rework it to fit it on FPGAs, create single-core chips for embedding and run university degree courses on it. I remain pretty happy with the license choice we made.
> so, I tried to find something wrong with "Apple's treatment of Darwin."
There is nothing whatsoever wrong with Apple's treatment of Darwin. Darwin is based on BSD-licensed open-source code, so Apple has no obligation to release Darwin source code back to the public, nor any obligation to release the sources of the other additions they add to Darwin to make their OS's. And this is what the original poster was commenting on. He didn't say Apple was doing anything wrong.
Another post indicates to me that Apple, at least sometimes, releases the sources to Darwin out of the goodness of their hearts, or for other business reasons (so people can donate bug fixes, for example).