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
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
