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?"
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.
You can't copyright a hardware design (that's what patents are for). You could copyright a circuit board layout, or a schematic (the graphic, not the concept), but it's pretty easy for someone to redo either.
What's the problem you're trying to solve?
"National Security is the chief cause of national insecurity." - Celine's First Law
The fuck kind of question is that? Next on Slashdot: What's the best colour?
Software is protected by copyright, that is clear. Hardware, on the other hand, not so much.
If I build a video card, the design is pretty much dictated by the chips I choose. There is probably only one way to hook them up that makes sense. The design is pretty much dictated by the data sheet.
I can see a copyright for the board layout. There is a great deal of skill involved in laying out a board that can run at reasonable speeds. In many respects though, the board's layout is dictated by the chip set so the design could be seen as the product of a journeyman rather than a creative act.
Remember that it is the creative act that results in a copyright. The decisions in the SCO vs. world cases make that clear. Most of the Unix code can't be copyrighted because it is dictated by externalities like the POSIX standard. It seems to me that hardware is even more so.
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.
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.
OpenCores does not mention the MIT license because in a nutshell it IS the BSD license. In fact many schools release code under a generally renamed BSD license with their schools name on it.
For Example: The LLVM is released under the University of Illinois/NCSA Open Source License which can be found here. Reading through it is very similiar to the BSD license
And Here is the MIT License... Look familiar?
The MIT License
Copyright (c)
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
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.
The Free Software Foundation has a transparent agenda: GPL at all costs. It's not wise to reference the FSF for an unbiased list of open source licenses.
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
Seriously... whichever license you want. It's not that they're all the same, it's that they all serve different purposes. As long as you take the appropriate steps to make sure no morons are going to try to sue you if it blows up in their faces (literally or figuratively), then the rest of the license doesn't really matter now, does it? Claim whatever rights you want, give away whatever rights you please.
Just because it's "open source" doesn't mean that you don't get to retain any rights. Pick which rights you want to keep, pick a license that suits your needs/desire, and if you don't find one, roll your own.
If you believe everything you read, you'd better not read. - Japanese proverb
Note that these designs are in BlueSpec SystemVerilog, a proprietary toolchain / synthesis environment rumored to cost over $200k/seat (but free to academic institutions willing to jump through enough hoops). That's not a lot for an ASIC design, but pretty pricey for a startup.
It's obvious that the FSF will only list GPL (or GPL compatible) licences. They have a very *very* obvious agenda which they are proud of. There opinions are *very* clearly biased in a *very* clear direction. They are a *very* poor source of information, even when it comes to there own licenses (I've found several false and misleading material on there site which they refused to fix).
FYI, to the original poster: THERE IS NO SUCH THING AS A BEST LICENSE. To think there is, is to ignore reality. The "best" license will change from person to person, from company to company,... profoundly impacted by the goals of the "project."
Who allowed this story to surface? How many times does this bullshit have to come up on this site?
Considering the expense of manufacturing hardware, the OGP (http://www.opengraphics.org) is trying to find ways to make their hardware both Free (in the Stallman sense) and also profitable. To wit, they have formed a company, Traversal Technology (http://www.traversaltech.com) to handle the monetary issues, make profit, and reinvest the money into designing and fabricating more Free-Design hardware. Their tactic is use the GPL license on all of their hardware designs in a manner much like MySQL or TrollTech. If you want to use designs from the OGP, you can either use them via the GPL (and be required to release your whole design under the GPL), or you can pay money to Traversal to acquire a commercial license that does not require you to open source your whole design. Either way, everybody wins.
If you're going to work on hardware designs, you might want to actually be able to BUILD the hardware you're designing. Putting in a way to make money from it is one good way to achieve that goal. Moreover, using a license like the GPL makes it somewhat less likely that some company will take your design, incorporate it into some product, make gobs of money, and never give you a penny.
It's very important to realize that open hardware is not the same kind of thing as open source software. Software is easy to copy. Hardware _designs_ are easy enough to copy, but physical hardware is _expensive_ to copy.
For those with gateways that see this as proxy avoidance... here's a direct link instead:
http://csg.csail.mit.edu/oshd/index.html
As a consultant for several large companies, I'd always done my work on
Windows. Recently however, a top online investment firm asked us to do
some work using Linux. The concept of having access to source code was
very appealing to us, as we'd be able to modify the kernel to meet our
exacting standards which we're unable to do with Microsoft's products.
Although we met several technical challenges along the way
(specifically, Linux's lack of Token Ring support and the fact that we
were unable to defrag its ext2 file system), all in all the process
went smoothly. Everyone was very pleased with Linux, and we were
considering using it for a great deal of future internal projects.
So you can imagine our suprise when we were informed by a lawyer that
we would be required to publish our source code for others to use. It
was brought to our attention that Linux is copyrighted under something
called the GPL, or the Gnu Protective License. Part of this license
states that any changes to the kernel are to be made freely available.
Unfortunately for us, this meant that the great deal of time and money
we spent "touching up" Linux to work for this investment firm would
now be available at no cost to our competitors.
Furthermore, after reviewing this GPL our lawyers advised us that any
products compiled with GPL'ed tools - such as gcc - would also have to
its source code released. This was simply unacceptable.
Although we had planned for no one outside of this company to ever
use, let alone see the source code, we were now put in a difficult
position. We could either give away our hard work, or come up with
another solution. Although it was tought to do, there really was no
option: We had to rewrite the code, from scratch, for Windows 2000.
I think the biggest thing keeping Linux from being truly competitive
with Microsoft is this GPL. Its draconian requirements virtually
guarentee that no business will ever be able to use it. After my
experience with Linux, I won't be recommending it to any of my
associates. I may reconsider if Linux switches its license to
something a little more fair, such as Microsoft's "Shared Source".
Until then its attempts to socialize the software market will insure
it remains only a bit player.
Thank you for your time.
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.
If the objective is to help the developing world, then there are two problems: international patenting can be expensive, but failure to patent could result in a big player patenting and then suing the originators of the design. Does every approach involve too much red tape to be worthwhile?
TFS is broken. A core is really software. It is written in code (eg. VHDL or Verilog). That source code is copyrightable just like any other code.
Engineering is the art of compromise.
Hi,
We recently published an article about open hardware licenses in Free Software Magazine:
http://www.freesoftwaremagazine.com/articles/making_open_hardware_possible
As well as Terry Hancock's article about purchasing free software friendly hardware:
http://www.freesoftwaremagazine.com/articles/purchasing_hardware_for_free_software
I think it will complement the linked articles above nicely!
Merc.
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.
Those off-the-shelf solutions are THE THING to use when for most applications. Definitely savings on time and headaches. But I've encountered a few strange situations where those solutions would not support the resolution and/or pixel rate we needed. No choice but to roll your own. Pain in the ass too!
Just because the copyright symbol is on the artwork when they etch the chip, and winds up etched onto the chip, does not mean that the etched circuit is artwork or copyrightable. The purpose of a chip die is as a device, not as an artform. Thus the chip is patentable, not copyrightable.
When our name is on the back of your car, we're behind you all the way!
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.
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
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.
Ah, but if you release an implementation of something before a patent on it is released, it can be called 'prior art' and invalidate the patent, at least I think so.
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.
Comment removed based on user account deletion
I think OpenCores is wrong. According to Richard Stallman, "the LGPL really is specifically for programs". That statment was given on the freepats list (can't point to the archives because there is a problem with the server in this moment, sorry). The terms of the LGPL are very hard to translate and apply to other works.
The GPL can be used, but if used for works other than programs, the copyright holder should attach a note clarifying the meaning of source code, linking, and other terms mentioned in the GPL so they are not ambiguous when applied to that particular work.
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.
The real question is whether you should trust the FSF in this. I know I don't.
The FSF has an agenda, and it's not "be good to the world and give unbiased information". Their main objective is "spreading the GPL" - which arguably falls in the "do good to the world" category, although I'm not entirely convinced about that. Spreading unbiased information, however, is *not* beneficial to that ulterior goal.
Note that I'm not blaming the FSF in any way; I'm not accusing them of lying. I just don't expect them to give considerations why other licenses might also work, let alone be better suited.
Consider this: Do you really expect a Ford dealer to tell you to go and buy a Mitsubishi, because he thinks it's a better car for you? I know I don't..
do you believe that prevents someone from building that circuit? Is the circuit anything other than a derivative copy (much like performing sheet music)?
You haven't answered the fundamental question - what is the characteristic in the continuum from high level descriptive language (Bluespec) through finished product (a functional H.264 decoder) that defines the transition from software to hardware, from copyrightable to patentable?
If I take a PROM, and program it so the inputs are connected to a regularly incremented binary counter, and the outputs are connected to various relays and valves which control an industrial process, is the programming in that device copyrighted, or is it an invention which requires me to apply for patent protection?
"National Security is the chief cause of national insecurity." - Celine's First Law
There is an issue regarding patents here. With the GPL you cannot distribute the software/hardware if you are aware of a patent that would affect the software/hardware. With MIT/BSD there is no such provision, so I can patent my device, and then freely distribute the designs under the MIT/BSD license. I can then sue anyone who implements those supposedly free designs for patent infingement.
The problem with this is that a lot of the question that caused trouble with the GPL and similar licenses will pop up and need to be resolved again.
Especially the old debate about what constitutes linking rises again: If I use a GPLed VHDL core in my FPGA, which part of my design do I need to publish under the GPL: Modifications to the core? The whole FPGA design? The design of cores in other FPGAs on the same board? The board layout and schematics? The system the board is used in?
Am I allowed to use proprietary ASICs on the same boards?
What about software executed by the GPLed hardware?
Using the GPL for hardware requires at least extra statements by the author clarifying these things.
The Simputer General Public License is an excellent license which allows for a good balance of commercial interests and free spirit. It allows for a short window (lag) to commit back changes in hardware. Suggest you take a look and make a modification as needed.
Unix, Computers and science fiction... What else can one want in life ?
If you've attached this to something that isn't 'software' and isn't 'associated documentation', then what does "Software" refer to?
The Open Source licenses, especially the short ones, do a good job at what they're supposed to do *for software*. But, hardware designs have a different set of issues. For one, open source licenses are predominantly *copyright* licenses.** Hardware designs are generally more the realm of patents and mask works, which have somewhat different protections. For example, GPL v2 talks about a "derivative work under copyright law." What does that mean when the thing you're trying to distribute isn't really protected by copyright?
Also, Open Source licenses are, with isolated exceptions, untested in court. Why would you take an untested license, apply it to something that it wasn't originally intended to apply to, and then expect some court to enforce it? Do you really want the first US test of an open source license to be the one where the license is attached to hardware and not to software?
If you want a license that applies to hardware, write a license that applies to hardware.
**There is probably an implied grant of a limited patent license to the extent that using the software would infringe a patent.
Tony,
Just recently I've been looking into learning about DSP and potentially starting out with a FPGA. I have looked at the Spartan-3E kit. Would you recommend it for learning? Or something else? I was hoping to stay under $100 but maybe I was fooling myself. I have a background in mechanical engineering (with essentially a math minor), but do a lot of programming and have taken a few entry-level EE classes, and am interested in digital signal processing. There's a lot of information online but it's overwhelming to dig through if you have any recommendations for someone starting out as a hobbyist I'd be glad to hear. Thanks. -philski.
FPGA have brought the cost of chip design and experimenting within the reach of mere mortals. Several
You could almost lose your Geek card for failing to take account of them !
There are even website for exchanging designes like OpenCores.
Also, Rapid prototyping is another technology that is featured a lot on
You don't necessarily need a several-thousands-of-dollars worth 3D printer from Z-corp. There are small cheap machine like the commercial Fab@home and the completely free and self boot-straping Reprap.
These brings the possibility of home made hardware much closer.
And that is without mentioning techniques that have already been available at home for ages like soldering or programming embed microcontrollers like PICs.
With all these possibility of making one's own hardware at home, the question of using open licenses and encouraging collaborative development by individual hardware hacker (vs. the classical big-corp approach) becomes perfectly valid. The barrier of entry has lowered and you don't anymore necessarily to be a huge company that only plays a tiny role along a big chain to be able to design and improve hardware.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Well of course they aren't going to mention alternatives. Contrary to their rhetoric, it's not ALL about the freedom. It's ALL about the control... just a different kind of control.
If everyone ignores the GPL, who's going to let Richard Stallman tell them what kind of software they are allowed to use? So obviously, "RMS shops" aren't going to tell you about alternatives the Stallmanistas don't want you to have. That would make them irrelevant, which defeats the entire purpose of carefully crafting a license scheme with the subversive goal of eventually seizing control of all software.
That's why FOSSies view other open source licenses, like MS-OSS or X11, to be so dangerous to them. It takes control of open source out of their hands, and attempts to put it back into the hands of the users. MS OSS is a great resource for companies who want OSS, but prefer to have the quality and support structure of MS software. As is typical, eventually the consumer decides. And since the GPL/FOSS community has no incentive to care about the consumer's wants and needs, it is not, and never will be, addressed.