For Approval: Open Source Hardware License

[jamey.hicks]

There are no OSI-approved licenses for open source hardware, so I am
proposing this license. It is derived from the Artistic License. This
license treats source code written in a hardware description language
such as Verilog or VHDL as a copyrighted entity, unlike the TAPR Open
Hardware License. The goal with this license is to enable the use of
open source components in commercial aggregates while requiring the
sharing of modifications to those open source components.

Jamey Hicks
Director, Nokia Research Center Cambridge

          The "Open Source Hardware License"
                 Version 0.4

                Preamble

The intent of this document is to state the conditions under which an
open source hardware Package may be copied, giving the users of the
package the right to use and distribute the Package in a more-or-less
customary fashion, to include this Package or derivatives thereof in
aggregate hardware components, plus the right to make reasonable
modifications provided those modifications to this Package are shared
with the community.

This document is intended to cover source code consisting primarily of
code written in hardware description languages such as Verilog, VHDL,
or Bluespec. All of the pre-existing OSI-certified open source
licenses included software terminology that is not applicable to open
source hardware.  This document is derived from the Artistic License,
which most closely matched the rights we would like to grant and
restrictions we would like to enforce. We have removed language
referring to the interpreter, scripts, and object code. We have also
removed the language that required that standard forms of the Package
be distributed along with modified versions.

Definitions:

    "Package" refers to the collection of files distributed by the
    Copyright Holder, and derivatives of that collection of files
    created through textual modification.

    "Executable" means the "Package" in any form other than Source
    Code. Executable forms include netlists, programming
    files/images for FPGAs, soft or hard macros for ASICs, mask
    images for ASICs, and programmable logic or ASICs.

    "Source Code" means the common form of computer code in which
    modifications are made and associated documentation included
    in or with such code.

    "Standard Version" refers to such a Package if it has not been
    modified, or has been modified in accordance with the wishes
    of the Copyright Holder as specified below.

    "Copyright Holder" is whoever is named in the copyright or
    copyrights for the package.

    "You" is you, if you're thinking about copying or distributing
    this Package.

    "Reasonable copying fee" is whatever you can justify on the
    basis of media cost, duplication charges, time of people involved,
    and so on.  (You will not be required to justify it to the
    Copyright Holder, but only to the computing community at large
    as a market that must bear the fee.)

    "Freely Available" means that no fee is charged for the item
    itself, though there may be fees involved in handling the item.
    It also means that recipients of the item may redistribute it
    under the same conditions they received it.

1. You may make and give away verbatim copies of the source form of the
Standard Version of this Package without restriction, provided that you
duplicate all of the original copyright notices and associated disclaimers.

2. You may apply bug fixes, portability fixes and other modifications
derived from the Public Domain or from the Copyright Holder.  A Package
modified in such a way shall still be considered the Standard Version.

3. You may otherwise modify your copy of this Package in any way, provided
that you insert a prominent notice in each changed file stating how and
when you changed that file, and provided that you do at least ONE of the
following:

    a) place your modifications in the Public Domain or otherwise make them
    Freely Available, such as by posting said modifications to Usenet or
    an equivalent medium, or placing the modifications on a major archive
    site such as uunet.uu.net, or by allowing the Copyright Holder to
include
    your modifications in the Standard Version of the Package.

    b) use the modified Package only within your corporation or
organization.

    c) make other distribution arrangements with the Copyright Holder.

4. You may distribute the programs of this Package in executable form,
provided that you do at least ONE of the following:

    a) accompany the distribution with the machine-readable source of
    the Package with your modifications.

    b) make other distribution arrangements with the Copyright Holder.

5. You may charge a reasonable copying fee for any distribution of this
Package.  You may charge any fee you choose for support of this
Package.  You may not charge a fee for this Package itself.  However,
you may distribute this Package in aggregate with other (possibly
commercial) programs as part of a larger (possibly commercial) software
distribution provided that you do not advertise this Package as a
product of your own.

6. The name of the Copyright Holder may not be used to endorse or promote
products derived from this software without specific prior written
permission.

7. THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.

                The End

[Allison Randal]

Jamey Hicks wrote:
>
> There are no OSI-approved licenses for open source hardware, so I am
> proposing this license. It is derived from the Artistic License. This
> license treats source code written in a hardware description language
> such as Verilog or VHDL as a copyrighted entity, unlike the TAPR Open
> Hardware License. The goal with this license is to enable the use of
> open source components in commercial aggregates while requiring the
> sharing of modifications to those open source components.

You might want to look into basing this license on the Artistic License
version 2.0, instead of version 1.0. After spending several years
working on cleaning up the ambiguities in the original Artistic License,
I would hate to see them resurrected in a new license.

I'm happy to help. I'm very interested in seeing solid open hardware
licenses enter the field.

Allison

--
Director, The Perl Foundation
Chief Architect, Parrot VM
etc...

[jamey.hicks]

ext Allison Randal wrote:

> Jamey Hicks wrote:
>>
>> There are no OSI-approved licenses for open source hardware, so I am
>> proposing this license. It is derived from the Artistic License. This
>> license treats source code written in a hardware description language
>> such as Verilog or VHDL as a copyrighted entity, unlike the TAPR Open
>> Hardware License. The goal with this license is to enable the use of
>> open source components in commercial aggregates while requiring the
>> sharing of modifications to those open source components.
>
> You might want to look into basing this license on the Artistic
> License version 2.0, instead of version 1.0. After spending several
> years working on cleaning up the ambiguities in the original Artistic
> License, I would hate to see them resurrected in a new license.
>

I will resubmit starting with Artistic License version 2.0.

Jamey

[Wilson, Andrew-2]

Jamey Hicks wrote:
>
> There are no OSI-approved licenses for open source hardware, so I am
> proposing this license.

It is not immediately obvious to me why no existing, OSI-approved open
source licenses,
although not perhaps originally intended for such applications, could
not also be used for hardware descriptions written in VHDL or Verilog.
Granted, a strong copyleft license such as GPLv2 or v3 might raise
questions
in practice about the scope of its copyleft (e.g., if you have one
GPL'd chip on your motherboard, is the entire motherboard a
"derivative work" and therefore also subject to GPL?), but a
less aggressive copyleft license such as EPL or CDDL could (IMO)
work in practice for your proposed usage model.  Please elaborate
if I am missing something fundamental here.

Andy Wilson
Intel open source technology center

[Rod Dixon, J.D., LL.M.]

Hmm...an "open hardware" license sounds like a matter for serious discussion.  Two questions come to mind immediately: (1) what kind of copyrightable work does "hardware" refer to, and (2) if the subject of the license  is a "literary work," why wouldn't an existing open source software license be sufficient? 

Even if one could argue that an open hardware license would protect a machine design, the question remains whether such is subject to copyright.  

Rod Dixon, J.D., LL.M.

roddixon@...

On Jul 5, 2007, at 5:06 PM, Allison Randal wrote:

Jamey Hicks wrote:

There are no OSI-approved licenses for open source hardware, so I am proposing this license. It is derived from the Artistic License. This license treats source code written in a hardware description language such as Verilog or VHDL as a copyrighted entity, unlike the TAPR Open Hardware License. The goal with this license is to enable the use of open source components in commercial aggregates while requiring the sharing of modifications to those open source components.

You might want to look into basing this license on the Artistic License version 2.0, instead of version 1.0. After spending several years working on cleaning up the ambiguities in the original Artistic License, I would hate to see them resurrected in a new license.

I'm happy to help. I'm very interested in seeing solid open hardware licenses enter the field.

Allison

-- 

Director, The Perl Foundation

Chief Architect, Parrot VM

etc...

[Simon Phipps-3]

On Jul 5, 2007, at 22:23, Wilson, Andrew wrote:

>
> Jamey Hicks wrote:
>>
>> There are no OSI-approved licenses for open source hardware, so I am
>> proposing this license.
>
> It is not immediately obvious to me why no existing, OSI-approved open
> source licenses,
> although not perhaps originally intended for such applications, could
> not also be used for hardware descriptions written in VHDL or Verilog.

Sun contributed to OpenSPARC the full design of the UltraSPARC T1,  
including Verilog sources, emulators, tools and more, and used the  
GPLv2 as the license. It is thus not obvious to me either why a  
specific license is essential.

S.

[Rick Moen]

Quoting Jamey Hicks (jamey.hicks@...):

> There are no OSI-approved licenses for open source hardware, so I am
> proposing this license.

My understanding is that OSI's licence approval process
(http://www.opensource.org/docs/certification_mark.html) is specifically
for _software_ licences.  That scope limitation came up previously when
people proposed documentation licences for certification; I suspect the
same logic applies here.

(I don't speak for OSI, however.)

--
Cheers,        English is essentially what happens when you can't decide whether
Rick Moen      the Greeks or the Romans had the better civilization, so you ask
rick@...    everybody they ever beat up on to sort it out.
                       -- John M. Ford, http://ccil.org/~cowan/essential.html

Rod Dixon, J.D., LL.M. wrote:
> Hmm...an "open hardware" license sounds like a matter for serious
> discussion.  Two questions come to mind immediately: (1) what kind of

+1

> copyrightable work does "hardware" refer to, and (2) if the subject of
> the license  is a "literary work," why wouldn't an existing open source
> software license be sufficient?
>
> Even if one could argue that an open hardware license would protect a
> machine design, the question remains whether such is subject to copyright.

On the generic issue (not the specific licence proposed):

"Subject to copyright" is an issue with all open source licences.  Some choose to specifically limit themselves to copyright, others express their permissions in terms of activities.  

I would assume open source hardware would raise different issues in different jurisdictions because of different sui generis legislation.  Eg. here in AU we have circuit layouts and designs legislation, each of which could conceivably apply.  Prima facie copyright could also apply depending on some not-entirely-simple provisions covering the applicability of copyright when the work is also eligible for design/circuit layout protection.  

I would guess therefore that a licence for open source hardware would be better expressed in terms of activites.  
 

Brendan

[Matthew Flaschen]

Brendan Scott (lists) wrote:

> I would guess therefore that a licence for open source hardware would
> be better expressed in terms of activites.

That doesn't really solve the problem.  If the design is not protected
by some right (copyright, semiconductor mask, etc.), people would be
free to violate the license.  Incidentally, GPLv3 tries to deal with
hardware by saying "“Copyright” also means copyright-like laws that
apply to other kinds of works, such as semiconductor masks."

Matthew Flaschen

Matthew Flaschen wrote:

> Brendan Scott (lists) wrote:
>
>> I would guess therefore that a licence for open source hardware would
>> be better expressed in terms of activites.
>
> That doesn't really solve the problem.  If the design is not protected
> by some right (copyright, semiconductor mask, etc.), people would be
> free to violate the license.  Incidentally, GPLv3 tries to deal with
> hardware by saying "“Copyright� also means copyright-like laws that
> apply to other kinds of works, such as semiconductor masks."

?  This is a different problem which is not solved (ie scope of rights which might possibly be licensed v what rights are in fact licensed).

Brendan
 

[Rod Dixon, J.D., LL.M.]

I have not rechecked the final version of GPLv.3 yet, but a copyright  
license cannot create copyright subject matter in contravention of the  
statute.

I think the most useful way to approach this issue is to clearly state  
what problem an open hardware license will solve. As presented, it  
seems to be a solution in search of a problem.

Rod Dixon, J.D., LL.M.
The SCTL Blog
www.cyberspaces.org

On Jul 5, 2007, at 10:37 PM, Matthew Flaschen <matthew.flaschen@...
 > wrote:

> Brendan Scott (lists) wrote:
>
>> I would guess therefore that a licence for open source hardware would
>> be better expressed in terms of activites.
>
> That doesn't really solve the problem.  If the design is not protected
> by some right (copyright, semiconductor mask, etc.), people would be
> free to violate the license.  Incidentally, GPLv3 tries to deal with
> hardware by saying "“Copyright” also means copyright-like laws th
> at
> apply to other kinds of works, such as semiconductor masks."
>
> Matthew Flaschen
>

[Matthew Flaschen]

Brendan Scott wrote:

> Matthew Flaschen wrote:
>> Brendan Scott (lists) wrote:
>>
>>> I would guess therefore that a licence for open source hardware would
>>> be better expressed in terms of activites.
>> That doesn't really solve the problem.  If the design is not protected
>> by some right (copyright, semiconductor mask, etc.), people would be
>> free to violate the license.  Incidentally, GPLv3 tries to deal with
>> hardware by saying "“Copyright� also means copyright-like laws that
>> apply to other kinds of works, such as semiconductor masks."
>
> ?  This is a different problem which is not solved (ie scope of rights which might possibly be licensed v what rights are in fact licensed).

I didn't mean to say GPLv3 solved the problem (I was just mentioning
that definition in passing).  There is no solution; if the law doesn't
grant rights for your design, the license is just a meaningless piece of
paper.

Matt Flaschen

[Matthew Flaschen]

Rod Dixon, J.D., LL.M. wrote:
> I have not rechecked the final version of GPLv.3 yet, but a copyright
> license cannot create copyright subject matter in contravention of the
> statute.

I know, and GPLv3 isn't trying to.  It is just saying that existing
statutory rights similar to copyright will be covered by the term
Copyright in GPLv3.

Matt Flaschen

[Allison Randal]

Simon Phipps wrote:

> On Jul 5, 2007, at 22:23, Wilson, Andrew wrote:
>> Jamey Hicks wrote:
>>>
>>> There are no OSI-approved licenses for open source hardware, so I am
>>> proposing this license.
>>
>> It is not immediately obvious to me why no existing, OSI-approved open
>> source licenses,
>> although not perhaps originally intended for such applications, could
>> not also be used for hardware descriptions written in VHDL or Verilog.
>
> Sun contributed to OpenSPARC the full design of the UltraSPARC T1,
> including Verilog sources, emulators, tools and more, and used the GPLv2
> as the license. It is thus not obvious to me either why a specific
> license is essential.

It's pretty obvious to me. On the simplest level, you want to use terms
describing the "work" that are relevant to hardware. Sure, you can apply
a software license to hardware by analogy, but it will never be clear.
(e.g. What do you mean by "copying the source code" of a piece of
hardware? Where does the distinction between hardware designs and
physical hardware enter into it?) We're expanding into new fields of law
here, and we need to start developing the tools of the craft.

As to the choice of which license to base it on, it's largely governed
by the intended use of the licensed hardware. If you extend the analogy
of the GPL to hardware, it implies that your open chip could only be
used within larger pieces of hardware that are also completely open.
Someday we'll get to that point, but at the moment, as we build up
momentum in open hardware, that's a huge obstacle both in convincing
companies to open up their hardware, and in convincing others to use the
open hardware.

I expect we'll end up with a small set of open hardware licenses,
representing the spectrum from BSD to GPL. And since we're starting
fresh here, we have the opportunity to set it up a logical set of
related open hardware licenses that can be selected based on intended
use, similar to Creative Commons.

Allison

[Allison Randal]

Rick Moen wrote:
>
> My understanding is that OSI's licence approval process
> (http://www.opensource.org/docs/certification_mark.html) is specifically
> for _software_ licences.  That scope limitation came up previously when
> people proposed documentation licences for certification; I suspect the
> same logic applies here.

It would be a shame if the pioneers of the open hardware movement
weren't given the opportunity to benefit from the years of hard-earned
experience in the open software community.

Allison

[Rick Moen]

Quoting Allison Randal (allison@...):

> Rick Moen wrote:
>
> >My understanding is that OSI's licence approval process
> >(http://www.opensource.org/docs/certification_mark.html) is specifically
> >for _software_ licences.  That scope limitation came up previously when
> >people proposed documentation licences for certification; I suspect the
> >same logic applies here.
>
> It would be a shame if the pioneers of the open hardware movement
> weren't given the opportunity to benefit from the years of hard-earned
> experience in the open software community.

I can't help noticing that OSI _certifying_ only software licences
wouldn't equate to it somehow hoarding its experience.  Either I'm
missing something, or perhaps you are.  ;->

--
Cheers,                English is essentially a language in which "up" has
Rick Moen              forty-seven dictionary definitions, but
rick@...    antidisestablishmentarianism is considered a "hard word."
                       -- John M. Ford, http://ccil.org/~cowan/essential.html

[jamey.hicks]

Thanks for all the comments on my posting.

There are no OSI-approved licenses expressly designed for open source
hardware. From my re-reading of the OSI-certified open source licenses,
several of them could be used without change to protect copyrighted
source code written in hardware description languages such as Verilog or
VHDL: MIT, BSD, CDDL, and EPL and GPL. None of these meets all the
requirements for our project. CDDL and EPL would fit our needs except
that at least one of the contributors, MIT, will not use a license with
explicit patent grants. The Artistic License is very close to our needs,
so I am proposing this Open Source Hardware license, derived from
Artistic License 2.0.

Jamey Hicks


          The "Open Source Hardware License"
                 Version 0.5

                Preamble

The intent of this document is to state the conditions under which an
open source hardware Package may be copied, giving the users of the
package the right to use and distribute the Package in a more-or-less
customary fashion, to include this Package or derivatives thereof in
aggregate hardware components, plus the right to make reasonable
modifications provided those modifications to this Package are shared
with the community.

This document is intended to cover source code consisting primarily of
code written in hardware description languages such as Verilog, VHDL,
or Bluespec. All of the pre-existing OSI-certified open source
licenses included software terminology that is not applicable to open
source hardware.  This document is derived from the Artistic License,
which most closely matched the rights we would like to grant and
restrictions we would like to enforce. We have removed language
referring to the interpreter, scripts, and object code. We have also
removed the language that required that standard forms of the Package
be distributed along with modified versions.

Definitions:

    * "Package" refers to the collection of files distributed by the
      Copyright Holder, and derivatives of that collection of files
      created through textual modification.
    * "Executable" means the "Package" in any form other than Source
      Code. Executable forms include netlists, programming
      files/images for FPGAs, soft or hard macros for ASICs, mask
      images for ASICs, and programmable logic or ASICs.
    * "Source Code" means the common form of computer code in which
      modifications are made and associated documentation included
      in or with such code.
    * "Standard Version" refers to such a Package if it has not been
      modified, or has been modified in accordance with the wishes
      of the Copyright Holder.
    * "Copyright Holder" is whoever is named in the copyright or
      copyrights for the package.
    * "You" is you, if you're thinking about copying or distributing
      this Package.
    * "Reasonable copying fee" is whatever you can justify on the
      basis of media cost, duplication charges, time of people involved,
      and so on. (You will not be required to justify it to the
      Copyright Holder, but only to the computing community at large
      as a market that must bear the fee.)
    * "Freely Available" means that no fee is charged for the item
      itself, though there may be fees involved in handling the item.
      It also means that recipients of the item may redistribute it
      under the same conditions they received it.

1. You may make and give away verbatim copies of the source form of the
Standard Version of this Package without restriction, provided that you
duplicate all of the original copyright notices and associated disclaimers.

2. You may apply bug fixes, portability fixes and other modifications
derived from the Public Domain or from the Copyright Holder. A Package
modified in such a way shall still be considered the Standard Version.

3. You may otherwise modify your copy of this Package in any way, provided
that you insert a prominent notice in each changed file stating how and
when you changed that file, and provided that you do at least ONE of the
following:

    a) place your modifications in the Public Domain or otherwise make them
    Freely Available, such as by posting said modifications to Usenet or
    an equivalent medium, or placing the modifications on a major archive
    site such as ftp.uu.net, or by allowing the Copyright Holder to include
    your modifications in the Standard Version of the Package.

    b) use the modified Package only within your corporation or
organization.

    c) make other distribution arrangements with the Copyright Holder.

4. You may distribute the programs of this Package executable form,
provided that you do at least ONE of the following:

    a) distribute a Standard Version of the executables and library
    files, together with instructions (in the manual page or
    equivalent) on where to get the Standard Version.

    b) accompany the distribution with the machine-readable source of
    the Package with your modifications.

    c) make other distribution arrangements with the Copyright Holder.

5. You may charge a reasonable copying fee for any distribution of
this Package. You may charge any fee you choose for support of this
Package.  You may not charge a fee for this Package itself. However,
you may distribute this Package in aggregate with other (possibly
commercial) Packages or executables as part of a larger (possibly
commercial) hardware source distribution or executable provided that
you do not advertise this Package as a product of your own.

6. The name of the Copyright Holder may not be used to endorse or promote
products derived from this software without specific prior written
permission.

7. THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.

The End

[Brian Behlendorf-2]

On Thu, 5 Jul 2007, Allison Randal wrote:
> It's pretty obvious to me. On the simplest level, you want to use terms
> describing the "work" that are relevant to hardware. Sure, you can apply a
> software license to hardware by analogy, but it will never be clear. (e.g.
> What do you mean by "copying the source code" of a piece of hardware? Where
> does the distinction between hardware designs and physical hardware enter
> into it?) We're expanding into new fields of law here, and we need to start
> developing the tools of the craft.

Huh - while I can see "source code" in the language of many OSI licenses,
I never took that to mean that the licenses could only be applied to
software.  Software in source code form may have been the context in which
these licenses are described and considered, but a GPL-licensed collection
of source code, documentation, UML diagrams, paper napkin sketches, and
audio recordings of the developers' favorite original jokes, are all
still GPL-licensed.  E.g. in the Apache 2.0 license:

       "Source" form shall mean the preferred form for making modifications,
       including but not limited to software source code, documentation
       source, and configuration files.

I wouldn't want to overestimate a jury or judge, but I think anyone would
consider "code written in hardware description languages such as Verilog,
VHDL, or Bluespec" to fall into the above.

> As to the choice of which license to base it on, it's largely governed
> by the intended use of the licensed hardware. If you extend the analogy
> of the GPL to hardware, it implies that your open chip could only be
> used within larger pieces of hardware that are also completely open.
> Someday we'll get to that point, but at the moment, as we build up
> momentum in open hardware, that's a huge obstacle both in convincing
> companies to open up their hardware, and in convincing others to use the
> open hardware.

For some companies, like Sun with OpenSparc, compelling opening of larger
works would be part of the point.  For others, I would think it would
simply mean that few people would consider strong-copyleft licenses for
hardware, and would instead consider MPL, CDDL, Apache, etc.  It shouldn't
scare them away from open source entirely, unless we did a poor job of
educating them on what the licenses mean.

The difference between hardware and software is already one more of form
than function.  AFAIK, anything describable in software can be burned into
silicon or reduced to an embedded system; likewise most hardware today is
emulated as software before being manufactured.  This even applies outside
of chip design - consumer product design has long been a mostly digital
process.  The biggest software company in Shanghai (I was told today, so
without reference) is one that makes control software for cutting/shaping
machines at steel mills.  I won't even get into DNA and synthetic biology.
:)  In all of those, using the word "source" to an English-language
speaker to describe the digital designs would be pretty comprehensible.

So I fall into the camp of asking for more clarification on how hardware
really is different...

I just noticed that in the Apache 2.0 license, the only place (in addition
to the above snippet) that the word "license" appears is in the disclaimer
of liability.  I guess we should have made that "works distributed under
this license" rather than "software distributed under this license" -
because we didn't intend to take liability for other kinds of works.  :)

  Brian

[Simon Phipps-3]

On Jul 6, 2007, at 02:12, Rick Moen wrote:

> Quoting Jamey Hicks (jamey.hicks@...):
>
>> There are no OSI-approved licenses for open source hardware, so I am
>> proposing this license.
>
> My understanding is that OSI's licence approval process
> (http://www.opensource.org/docs/certification_mark.html) is  
> specifically
> for _software_ licences.  That scope limitation came up previously  
> when
> people proposed documentation licences for certification; I suspect  
> the
> same logic applies here.

I'm afraid the distinction between "software" and "hardware" is  
getting harder and harder to make. The Verilog that's used to make  
the UltraSPARC T1 is definitely software, and the GPL (or any other  
Free software license approved for open source community use by OSI)  
seems 100% applicable to me.

If we allow special "hardware" licenses because the copyrighted work  
is used for that purpose, we are on a slippery slope towards many  
other specialist (an in my view redundant) sub-categories.

S.

[Wilson, Andrew-2]

Jamey Hicks wrote:

> From my re-reading of the OSI-certified open source licenses,
> several of them could be used without change to protect copyrighted
> source code written in hardware description languages such as Verilog
or
> VHDL: MIT, BSD, CDDL, and EPL and GPL. None of these meets all the
> requirements for our project. CDDL and EPL would fit our needs except
> that at least one of the contributors, MIT, will not use a license
with
> explicit patent grants.

One is tempted to say that this is a localized MIT problem and not
evidence
of lack of fitness of a number of OSI-approved licenses for this
application.  One is also tempted to say that, in a pragmatic
sense as opposed to a license-theoretic sense, designing a
piece of hardware while relying on a license without an
explicit patent grant would constitute extremely risky behavior.

Andy Wilson
Intel open source technology center