[Open-graphics] Definition of Open Hardware

Patrick McNamara wpmcnamara at yahoo.com
Fri Oct 6 19:34:13 EDT 2006


I suppose I will finally chime in with my thoughts too. :)

James Richard Tyrer wrote:
> Lourens Veen wrote:
> <SNIP>
>> Therefore I believe that we need an Open Hardware Definition. We need 
>> to know what it means, philosophically and in practice, for hardware 
>> to be open.
>
> My take on the taxonomy of hardware:
>
> I see Open (Source) Hardware as hardware for which the source code is 
> published in a hardware logic language (including adaptions of 'C'). 
> Yes, this can by CopyLefted.  If the current GPL needs some 
> modification to be totally applicable to hardware, they we need to 
> work it and issue the GPL for Hardware -- the HGPL.
>
> Perhaps we might also need an LHGPL.
>
> Or, the Open Hardware could be licensed under the modified BSD 
> license: You can do anything with this that you want except you can't 
> claim you wrote it.  But, you are not required to say who did write it.
I am rather wary of trying to write our own license for several reasons: 
confusions and complexity being two of the big ones.  The process of 
hammering out the license is complex if we actually try and take into 
account all the voices of the community and there will no doubt be 
confusion about what we are trying to do.  Though I don't really know 
how much the confusion will matter.

Regardless, I agree.  This fits my definition of Open Source Hardware.  
Everything you need to produce a working chip is available to you.  You 
may still have to figure out how you are going to come up with the 
millions of dollars necessary to turn what you have into a physical 
device, but that is an entirely separate problem.  In reality, I believe 
the GPL applies here as it stands.  The "code" for generating a chip is 
no different than the C/Java/Ruby/Forth/<insert your favorite language 
here> code used to create a computer program.  Just the compilation 
steps are different.  The issue of the PCI vs the rest of the design is 
no different than say some Perl module I write and release as part of a 
Perl/Tk application.  It is covered by the license of the entire package 
and separating it from that package does not separate it from the 
license.  Actually a Perl Module that is part of an app is a reasonable 
analogy.  If I separate that module from the application and use it 
elsewhere, I am obviously bound by the GPL to release any changes I make 
to the module, but what about the application that uses it? 

>
> Then there is proprietary hardware that has full documentation.  This 
> should include what every bit and every register and instruction 
> (except those reserved for testing) does.  If the hardware executes 
> code, this should have the same level of documentation as the 
> instruction set of a MPU.  As chips become more complex, it appears 
> that additional information is needed on exactly how to use the chip 
> for its intended purpose -- a programmer's guide is needed.  What 
> should we call this? Open Documented Hardware.
Again, I agree.  And while the OHF should support Open Hardware 
projects, if we are lucky enough to gain any influence, it should also 
lobby regular companies to produce Open Documented Hardware as JRT calls 
it.  You could also call this Open Design Hardware.  The implementation 
may not be open, but all the details necessary to produce a compatible 
replacement are, assuming you have the skills and resources to do so.  
This obviously also means that all the detail necessary to make full use 
of the device are available too.  In my mind, for a device to fall into 
this category, the documentation must come with no strings attached with 
regards to use of the documentation to fully implement the functions of 
the device.  I'm not speaking about a manufacturer excluding warranty 
for use of a device outside its intended purpose, but of agreements that 
forbid the release of drivers for example. 

Though a number of them would be loath to admit is for quasi-religious 
reasons, I would venture that most in the Open Source community would 
plenty happy if all that ever happened in the world was a shift towards 
open documentation of hardware.  In reality, this is all the Open Source 
Software community really needs.  Very few will have interest in knowing 
that the particular chip has a register on the data AND clock pins to 
help reduce clock skew.  Nor could they really do much if they felt like 
changing it.  The means to turn it into physical silicon as just beyond 
most people.

Now that is not to say that there won't be a lot of interest.  I know a 
number of folks personally who, if they found a bug in a piece of 
hardware, would likely track it all the way back to the source if they 
could.  Just for the fun of it.
>
> There are some companies that seem to fall a little or a lot below the 
> Open Documented Hardware standard but still provide documentation.  
> So, there is a gray area between this and the next.  So, there is 
> hardware which has some documentation but which is not fully documented.
>
I'm not sure what to call these either.  Perhaps these fall into that 
category of "deal with it when the problem presents itself".

Patrick M


More information about the Open-graphics mailing list