This page contains information about the Open Hardware Description License. It is based on the Mozilla Public License 2.0 RC2 and is intended to be a weak copyleft license that can be applied to hardware design source code.
The primary motivation for creating the OHDL is to provide designers with a license which is clear about its applicability to hardware description (RTL) source code. The second priority is to increase participation in open source hardware design by industry through using a license which will not impinge the design it is instantiated (used) in. (This is in contrast to reciprocal, or strong copyleft, licenses which force the release of anything the design is combined with.)
The draft version of this license was published for about 6 months and I am now actively applying this to work I am doing. For example, the mor1kx processor.
I would encourage anyone actively involved in open source hardware design to considering using this license for their work. I indend for it to provide greater legal certainty and to increase the likelyhood of commerical involvement in your project.
The license text can be found here
I could not find a weak copyleft license that was unambiguous about applying to hardware descriptions.
The two particular features of license that I want are as follows. First is that it applies specifically (although not exclusively) to hardware descriptions, ie. RTL code. The second is that the license permit the use of the design along side hardware descriptions with proprietary licenses, and that the modified source be made available with any product that the source went in to.
The requirement that the license specifically apply to hardware designs addresses the problem of the fact that existing copyleft licenses explicitly state they apply to software, leaving hardware developers in licensing limbo. By stating in the license that it covers hardware descriptions, there can be almost no uncertainty that it applies to such things as HDL source code and any of its processed forms.
I am seeking to solve two licensing issues making industry reluctant or unable to participate in open source hardware design; inapplicable and strongly reciprocal licenses.
I'm of the opinion that elements of open source licensing, as described in terms relating to software, do not translate neatly to the hardware development model. One example is that of reciprocal licensing requirements which apply to other binaries you link against. The first question to be asked if you want to use existing licenses, such as the GNU GPLs, is "what is linking in hardware?" Another relevant question, if you're wanting to apply something like the lesser GNU (L)GPL to a hardware description, is "what is the equivalent of dynamic linking when using the hardware?" If you think you've got answers to those questions, then there's the issue that manufacturing and selling an item is not equivalent to compiling and distributing a binary.
Fundamentally the concept of reciprocal licensing as it applies to software linking can't be directly applied to hardware designs. Even if this is only partially correct, I can't see how the current set of reciprocal software licenses can be applied to hardware designs in any manner that makes their reciprocal requirements enforceable in a court of law.
So, clearly, I'm not sold on the (currently widespread) practice of using software licenses, reciprocal or otherwise, on hardware designs. However, I don't think it's impossible to formulate a reciprocal license to apply to hardware designs, these already exist, more or less (I think), in the TAPR OHL and CERN OHL. I'm of the opinion that this wouldn't be an approach which encourages the use of open source hardware where you're likely to see the greatest contribution: industry.
However, there is some opinion that the GPL may be applicable to hardware, see Eli Greenbaum's article in the Harvard Journal Of Law And Technology, although this highlights many uncertainties which the OHDL attempts to address.
Simply put, strongly reciprocal licenses are not feasible for commercial designs involving licensed IP, which is practically all of them.
It is my experience that hardware development projects which release their source under strictly reciprocal licenses see practically no participation by industry. This is due, in part, to the reciprocal nature of the license and the requirements that places on the rest of the design. This barrier to participation is further strengthened by today's widespread use of licenses explicitly for software (the GPLs) and the uncertainty surrounding the applicability of these licenses to a hardware description. Most commercial developers either use the IP and never disclose this fact, or steer clear all together. Both outcomes are clearly a loss for the wider open source community.
There could be a few solutions to the copyright issues commercial developers face. One possible solution is a reciprocal license applying to the open source module's top level hierarchically, and extending to anything instantiated within it. I still think this is problematic in the cases of logic inferred by synthesis tools (go ask your foundry if portions of their technology library or memory cells can be released under an open source license because they were inferred inside a design with a reciprocal license.) There's also the issue of the module boundary being blurred when "flattening" a design for certain kinds of synthesis, eliminating all hierarchical distinction. Still, hierarchical-related issues could be eliminated by saying the boundary is at the module-level when in RTL form, or that there's an exception for anything inferred by synthesis tools such as arithmetic or memory cells. In either case, you're essentially back at asking for modified source files to be shared.
So by placing the boundary of what must be disclosed at the licensed source files and anything they contain, as this weak copyleft license does, the developer's obligations are clear.
One argument against using relatively permissive licenses in open source development is that it's just playing into the hands of commercial interests who want to use the work but not release their own development done off the back of it.
The benefit of strongly reciprocal licenses, in this case, is to force new development to be shared with the original development community.
However, this only applies to development which is practical due to the availability of the required base components or, in other words, that a critical mass of work already exists for it to be worth the new developer's while to build on that. The calculation made there by the developer is whether there's more to gain from developing based on existing open source implementations and forgo a proprietary license on their work, or whether it's a better choice to implement their idea from scratch or pay for other proprietary software that lets them keep their part proprietary. This can also be seen as scaling risk for reward - going with open source development has less risk due to smaller upfront capital investment (large portions of the work are already done and you don't pay anyone for it) before you implement your idea but you can't then reap large payments for the IP and only sell your expertise as a service. An increased risk and reward situation gets you to the proprietary development model where high up front costs are encountered to buy or pay for the work you could have gotten free of cost by building on open source implementations, before doing the work you need to implement your idea but then charging for it at whatever rate the market will bear.
However the choice of open source is a non-starter if the base of work to develop on doesn't exist. Unfortunately, this is practically the state of open source IP in RTL form at the moment - there are no serious open source alternatives to proprietary IP from established vendors.
So my point is that there's no point trying to force people to develop in such a way where they cannot keep proprietary licenses on the IP they develop if they're not getting anything back for giving away their work. The critical mass of IP must exist before one can expect commercial developers to evaluate the trade off in open source's favor.
Where will the so-called critical mass come from? Well, where has it come from before? Academia, hobbyists and a handful of early-adopting commercial entities. I might be mistaken, but this is my understanding of where the critical mass of open source software came from during the late 1980s and early 1990s. The big difference, of course, is that software aint' hardware, and the software development cycle aint' the hardware development cycle. Fewer people have FPGAs, EDA tool flows and hardware design skills compared to those who have an x86 machine on their desks an Internet connection and some basic software skills which would allow you to perform software development. So I think we must accept that it will be a niche field and can't expect the same kind of growth in the amount of open source development just because we're using the same licenses as software does (which, as I've already argued, is actually not helping the cause.)
You might then say we'll never achieve the critical mass by using permissive licenses that allow developers to take, with no requirement to contribute. I would argue, first of all, that license is not entirely permissive in that it requires modifications to be contributed. It also leaves open a path for migration to more reciprocal licenses via the Subsequent license clause. Overall, my approach is aiming to increase the use of open source hardware designs in industry by using this license to make it possible for companies to even consider them in the first place. This is sure to reap some benefit for everyone - more options for companies and more contributions from them back to the community. I expect even this, although quite modest in comparison to what could be demanded, would result in improvement of the quality and quantity of open source hardware design.
The current OHDL is based on this text.
The weak copyleft style of the license was not altered, just the language used to describe what it applies to. The main substitution was "Covered Software" for "Covered Hardware Description".
The license makes clear that there's two things - hardware design source code, and any form of the work other than source code form.
My intention is for this other-than-source-code form to mean any processed form which has resulted from the hardware description undergoing some sort of processing to turn it into a different form with fundamentally the same design intent.
I think this is broad enough to cover RTL being turned into an FPGA bitstream, or going into the flow that results in a manufactured ASIC. Whether or not we can get a license like this to apply to manufactured things which contain the licensed hardware descriptions is another, but very critical, matter.
The following are intended requirements on developers:
I aim to help eliminate license-based concerns industry might have about using open source IP and participating in open source hardware development.
I intend for it to be applied by RTL developers to designs which are to be collaboratively developed and used by commercial design houses, academia and hobbyists.
I feel this license is a good choice because it provides the best of both worlds - no barriers for use by commercial developers but also the ability for those who wish to stick to the GNU GPL licenses to relicense the work, as permitted under section 2.4 "Subsequent Licenses", and use it in their projects without issue (so long as the "Incompatible With Secondary Licenses" notice isn't present.)
Provide a better explanation of where the MPL has been modified to come up with the OHDL (a diff or something)
Explore how one might get this license, or any other, to apply to manufactured items such as ASICs built with RTL licensed under it
If you wish to contact me directly you can via email (juliusbaxter at gmail com) but I'd prefer if you comment publicly via the the OpenRISC mailing lists here and here.
Back to my home page.
Page last updated November 2012