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?"
Public Domain.
Why? So companies dont mind making it themselves. They profit on it. When other companies make it too, they can do so without reprisal on licenses, so the price approaches cost+"token profit".
Also, by having the circuit schematic public, hiding undesirable plans is pretty much impossible.
Nothing to see here.
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.
It doesn't matter very much which license is used - therefore there is no "best license". The people who did the work chose the license, as is their right. If they thought a different license was better, they would have chosen a different one.
The license only matters when you mix material with different licenses. I cannot quite see how this would apply for example to a h.264 decoder. The best anyone can do is respect the authors and stay with their license.
Software: Source code -> compiler -> magnetic bits on your hard drive.
Hardware: Source code -> compiler -> lots of transistors in a chip.
Copyright applies to any source code.
Yet, you still have the issue of licensing.
You can hold the sole rights of production, you can charge people for the right to produce more of the thing, you can just let anyone produce more of the thing, or presumably, you can do something in between: offer limited rights to reproduce your invention for free if certain conditions are met, which is precisely the goal of the GPL with respect to software copyright.
Is it so much of a stretch that one or more of the stock "open" software licenses might be suitable with zero or few changes in wording to apply to patent licensing as well?
Can you be Even More Awesome?!
WARNING! If you do not use the CORRECTLY APPROVED license then MICROSOFT can STEAL your hardware! That's what they did with BSD and why there IS NO BSD ANYMORE!
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.
Blue
... No, Yellow (fling)...AAAAAGH!
The FSF are responsible for the GPL and know it well so that is why they list that and not the others. It is not their purpose to list other people's stuff. The answer is to read the other licences and see what fits.
Copyright applies to the expression of an idea, not the idea itself, regardless of whether it's software, hardware, or the great-american-novel.
Hardware designs are most frequently expressed in a hardware-definition language (HDL) such as Verilog or VHDL. The HDL source can be copyrighted just like a program written in your favorite language.
It appears that Slashdot advocates a so called hardhack license. Does anyone have more info about it?
Knowledge is power. Knowledge shared is power lost.
This is the reason that TAPR created the Open Hardware License. It is available in two versions - the Open Hardware License, and the Non-Commercial Open Hardware License. The former is like GPL for hardware, and the latter provides a license that can be used to allow a company to open a design without giving their competitors the chance to use the design commercially.
It is designed to provide many protections including of the circuit designs and layouts, and patent protection.
Darryl
P.S. I am on the board of TAPR
What's the best open-source license to use for biological innovations and strains?
I personally prefer the MPL, the BSD/MIT and lGPL, but would also be interested in seeing what GPL-lovers (those who agree with the FSF's positions) have to say as well.
"The absurd is clear reasoning recognizing its limits"
-Albert Camus
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
Real hardware is a bit more challenging to release in open source form for many reasons:
* Hardware definitions are done in layout packages with very different file structures etc making it difficult to share designs across diferent tool chains.
* RF and power designs are more physical implementations than schematic ones. That is, it is easy to render a schematic in different physical forms some of which will work and some of which won't.
Engineering is the art of compromise.
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.
There is a terminology problem in referring to FPGA configurations as "Hardware." An FPGA core is a different sort of entity from Hardware or Software; the term Configware is increasingly popular term for it. The description of the algorithm should be abstracted from the metal executing a particular manifestation of the algorithm and so the licensing issues for configware are no different than licensing issues for software. Similar to issues in the traditional software world, a stumbling block for FPGA adoption is integrating proprietary cores with open source components. An interesting and difficult problem is making compilers from various linguistic paradigms to execution models appropriate for FPGA hardware or instruction stream processors. Bluespec is an example of a language that can compile to C and Verilog.
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.