For Approval: Open Source Hardware License

[Simon Phipps-3]

On Jul 6, 2007, at 04:45, Allison Randal wrote:

> Simon Phipps wrote:
>> 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.

Maybe we are, but the trend I observe is that chip designs are more  
software than hardware until very late in the design process. The  
copyrighted source that corresponds to the physical chip has a very  
strong parallel to copyrighted source corresponding to object code.

> 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.

That was not our intent. We simply want to make sure that when  
OpenSPARC designs are used by others they contribute to the pool of  
know-how of the OpenSPARC community. There is no implication that the  
rest of the device of which the chip is a component becomes subject  
to the terms of the license.

> 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.

Even if it is, I am simply asserting that when we chose to take this  
step we considered a range of licenses for the design source and  
concluded GPLv2 was the most appropriate. I believe many OSI-approved  
Free licenses would be appropriate.

My view was and is that the right place to start is with existing  
licenses and that we should solve problems only when we encounter  
them. So far I have not encountered any in connection with OpenSPARC.

S.

[Rick Moen]

Quoting Simon Phipps (Simon.Phipps@...):

> I'm afraid the distinction between "software" and "hardware" is  
> getting harder and harder to make.

You know, there are circumstances in which I'd raise that point, too.  
However, I'd feel a bit silly raising it in circumstances where
something is described very unambiguously aas a licence specifically for
hardware _and used_ (or at least planned to be used) only for that
purpose, to a groups that certifies licences specifically for software.

(I do doubt that OSI would refuse to certify a licence actually _used_
for software, on no better grounds than it having the word "hardware" in
it.)

Nonetheless, your ability to discern shades of grey is admirable. ;->

--
Cheers,                English is essentially a text parser's way of getting
Rick Moen              faster processors built.
rick@...    -- John M. Ford, http://ccil.org/~cowan/essential.html

[Allison Randal]

Rick Moen wrote:
>> 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.  ;->

In terms of practical applications, I see two extremes, and a range in
between:

- Software and hardware are completely separate, the OSI declares itself
as only interested in software, and has absolutely no interest in
talking about hardware licenses. In which case, the discussion
continues, but somewhere else.

- Software and hardware are taken as one lump, the OSI is interested in
licenses for hardware (whether applications of existing licenses, or
creation of licenses more relevant to hardware), and this is the perfect
place to discuss the future of hardware licenses.

Flipping bits on various attributes in the two extremes defines the
alternatives between the two extremes.

Allison

[Rick Moen]

Quoting Allison Randal (allison@...):

> In terms of practical applications, I see two extremes, and a range in
> between:

I note with approval Michael Tiemann's polite but judicious reaction
when asked, recently, once again whether OSI shouldn't evaluate one of
Microsoft's licences for OSD-compliance.  He said, paraphrasing:

"Is someone actually using the licence on an actual piece of software?
If so, would that person consider submitting it?"

I know coders, and so I know they have a tendency to want to test
anything that looks like a Turing machine against a variety of inputs.  
The OSI certification process has, alas, looked to many people like a
Turing machine, with the result that they try to hurl goofy licences
at it for sundry theoretical purposes or bits of intellectual
thumb-sucking^W^W^Wexploration -- most often licences not _even_
actually in use for real pieces of software.

(And then, of course, we hear blatant non-sequitur reasoning like "Well,
we borrowed that language from the Attribution Assurance Licence, and,
surely, if we frankensteined together hunks taken only from
OSD-compliant licences, the result must be, too."  But I digress.)

Getting back to my earlier point:  I greatly doubt that OSI would refuse
to examine a licence for no better reason than its title (or text)
making reference to hardware.  However, expecting that the licence
be one _actually used_ for software seems entirely reasonable, and
a good heuristic for filtering out time-wasting exercises in theory.

Time-wasting exercises in theory would include -- not to put too fine a
point on it -- determining how "completely separate" hardware and
software are.  That might be a fascinating discussion, but it has
no obvious relevance to OSI certification.

--
Cheers,                                     The Viking's Reminder:
Rick Moen                                   Pillage first, _then_ burn.
rick@...

[Matthew Flaschen]

Rick Moen wrote:

> Quoting Simon Phipps (Simon.Phipps@...):
>
>> I'm afraid the distinction between "software" and "hardware" is  
>> getting harder and harder to make.
>
> You know, there are circumstances in which I'd raise that point, too.  
> However, I'd feel a bit silly raising it in circumstances where
> something is described very unambiguously aas a licence specifically for
> hardware _and used_ (or at least planned to be used) only for that
> purpose, to a groups that certifies licences specifically for software.
>
> (I do doubt that OSI would refuse to certify a licence actually _used_
> for software, on no better grounds than it having the word "hardware" in
> it.)

If OSI considers a license specifically designed for hardware, why
should we want it to be in use for software?  It seems these are
contradictory.  OSI could reject hardware-specific licenses if it
decides they diverge from the mission too much.  If they are acceptable,
though, there is no reason to require they be in use for software.

Matt Flaschen

[Rick Moen]

Quoting Matthew Flaschen (matthew.flaschen@...):

> If OSI considers a license specifically designed for hardware, why
> should we want it to be in use for software?

I'll be glad to take a swing at your question if OSI ever expresses a
wish to "consider a licence specifically designed for hardware".  Until
that day dawns, though, your question seems a bit pointless.

> If they are acceptable, though, there is no reason to require they be
> in use for software.            ^^^^^^^^^^^^^^^^^^

Highlighted assertion is unsupported, and seems dubious on its face:
_Reasons_ OSI might wish to ask that submitted licences be _in actual use_
for software have already been cited.

--
Cheers,                            To you, this thought         Alot
Rick Moen                          I gently allot:              Isnot
rick@...                                             Aword.

[Matthew Flaschen]

Rick Moen wrote:
> Quoting Matthew Flaschen (matthew.flaschen@...):
>
>> If OSI considers a license specifically designed for hardware, why
>> should we want it to be in use for software?
>
> I'll be glad to take a swing at your question if OSI ever expresses a
> wish to "consider a licence specifically designed for hardware".  Until
> that day dawns, though, your question seems a bit pointless.

It isn't pointless, given that a license specifically designed for
hardware has been submitted (and an updated version is soon to be
submitted) and OSI is still deciding whether to consider it.

>> If they are acceptable, though, there is no reason to require they be
>> in use for software.            ^^^^^^^^^^^^^^^^^^
>
> Highlighted assertion is unsupported, and seems dubious on its face:
> _Reasons_ OSI might wish to ask that submitted licences be _in actual use_
> for software have already been cited.

Reasons for /software/ licenses to be in actual use for software have
been cited.  I have seen no reasons for /hardware/ licenses to be in
actual use for software.  The obvious reason they should not be is that
a hardware-specific license may work poorly for software.

Matthew Flaschen

[Allison Randal]

Rick Moen wrote:
>
> Getting back to my earlier point:  I greatly doubt that OSI would refuse
> to examine a licence for no better reason than its title (or text)
> making reference to hardware.  However, expecting that the licence
> be one _actually used_ for software seems entirely reasonable, and
> a good heuristic for filtering out time-wasting exercises in theory.

So, people should first release a whole bunch of software/hardware under
the new license, and then go ask the people with experience if their
license is sane and likely to be accepted?

Allison

[Rick Moen]

Quoting Matthew Flaschen (matthew.flaschen@...):

> I have seen no reasons for /hardware/ licenses to be in
> actual use for software.

Do you need help finding the archive, then -- or are you, in the
alternative, asking me to re-post?

[Rick Moen]

Quoting Allison Randal (allison@...):

> So, people should first release a whole bunch of software/hardware under
> the new license, and then go ask the people with experience if their
> license is sane and likely to be accepted?

Yesterday, in response to your earlier message, I replied:

   I can't help noticing that OSI _certifying_ only software licences
   wouldn't equate to it somehow hoarding its experience.

The comment still seems relevant.  ;->  But I might have been too
cryptic.  (If so, sorry.)

To rephrase in the form of a question:  Why are you assuming that the
only plausible means of garnering comment on a hardware licence's sanity
and acceptance prospects is to submit it to OSI's software-licence
certification process, especially when good alternatives beckon?  E.g.,
one could post, "Hey, gang, please have a look at this hardware licence
[citation], and let me know if you think it's sane and likely to be
accepted."

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

Version 0.5 of the OSHL seems compatible with the OSD.  Since, as I understand it, the OSHL is essentially a software license covering chip design source code, I am not sure why "all of the pre-existing OSI-certified open source licenses" covering software are inapplicable to "open source hardware."  

The OSHL does not purport to protect the chip; it protects source code.  And, certainly, it does not seem to matter directly in the license-approval process what type of programming language (i.e., hardware design language) is used to produce the source code.  Hence, the need for a license exclusively protecting hardware design language source code is unclear to me.  Aside from the MIT- patent issue, what unique requirements are unmet by the existing open source licenses?  

(BTW, regarding the patent issue, I am curious - do you mean MIT will not accept patent grants or will not make patent grants?)

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

roddixon@...

On Jul 6, 2007, at 9:19 AM, Jamey Hicks wrote:

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

[John Cowan]

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

> (BTW, regarding the patent issue, I am curious - do you mean MIT will  
> not accept patent grants or will not make patent grants?)

MIT claims that it will not make blanket implicit patent grants
of the form "You are licensed to use [etc.] any patents of ours you
need in order to use this software."  Many believe that the MIT
License (used on X Windows and other works) actually contains a
grant of this form due to the presence of the word "use" in it,
but of course the matter has never been tested.

As I understand it, by refusing/repudiating such grants, MIT
is reserving the right to make explicit exclusive licenses either
before or after the fact to licensees of their choice; furthermore, they
claim to be unable to keep track of what patents they have and
what might infringe what.

--
John Cowan    cowan@...    http://ccil.org/~cowan
   There was an old man                Said with a laugh, "I
     From Peru, whose lim'ricks all      Cut them in half, the pay is
       Look'd like haiku.  He              Much better for two."
                                             --Emmet O'Brien