[Open-graphics] Definition of Open Hardware

[Terry Hancock]

Lourens Veen wrote:
>  On Wednesday 04 October 2006 09:34, Nicolas Boulay wrote:
> > Hardware can't be easly change as software and cost something. But
> > the open hardware "user", user in the GPL way, are not the same.
> > Open hardware user are soc designer or board designer, they deal
> > with copyrighted material, plan and ideas. That's not the case with
> > the buyer of the hardware. He can't be protected by a licence based
> > on copyright or very hardly (you can't link a final product with
> > the licence on the hdl code, you can only restrict the use of the
> > hdl code).
>
>  So, it isn't the case that the ASIC mask is derived from the HDL, and
>  the actual chip is derived from the ASIC mask, producing chips is
>  copying the copyrighted design and selling them is distribution?

It is, or at least can be. But this is where a more specific "open 
hardware license" could help, by making clear what kind of requirements 
are placed on each level of distribution.

Naively, most people would tend to think of creating an in-house 
derivative design of a GPL'd design document, then manufacturing and 
distributing parts manufactured from the derivative design would not 
violate the GPL (because they're using the design, not just copying it).

However, for an open hardware project, that is a breakdown of the 
desired copyleft (improvements to the design do not get folded back into 
the project or passed on to the user).

We want the act of distributing the hardware based on the modified 
design to constitute "modification + redistribution", so that we can 
require source distribution in that case.  However, it's legally 
ambiguous whether this is is the case. A license (or super-license -- 
that is, an explanatory license grant) which is clear on this point 
would improve the situation.

And of course, there is a possibility of greater subtlety. Clearly a 
"specifications document" which says only what interfaces a desing must 
provide shouldn't confer copyleft privileges on any hardware that 
conforms to it. But a PCB created from a Gerber plot or an ASIC created 
from a mask pattern should.

Another issue is the "platform layers" issue. The GPL requires that all 
components combined with it to make a working program must also be under 
the GPL. But this clearly becomes a problem when we cross "platform" 
boundaries: that's why the GPL as written explicitly exempts the 
operating system.

But what if it didn't? It might be argued that the GPL would then 
require GPL programs to be run only on GPL'd operating systems, running 
on GPL'd computers, with GPL'd PC boards, with solely GPL'd chips, 
composed of GPL'd "IP Cores", made from GPL'd metals and plastics (i.e. 
no proprietary materials).

I think most of us don't want that.

So when we apply the idea to hardware, we assume that, e.g.:

1a) Proprietary or free materials may be used in free chips
1b) Free chip materials may be used in proprietary chips

2a) Proprietary or free chips may be used in a free PC board
2b) Free chips may be used in a proprietary PC board

3a) Proprietary or free PC boards may be used in a free PC
3b) Free PC boards may be used in a proprietary PC

4a) Proprietary or free PCs may be used for free software O/Ss
4b) Free PCs may have proprietary O/Ss installed on them

5a) Proprietary or free O/Ss may be used as a basis for free applications
5b) Free applications may be used on proprietary O/Ss

and so on.

Note how these occur in pairs: one corresponding to the "platform 
exception" (you can use proprietary low-level materials in a free 
high-level design) and the other corresponding to the "mere aggregation 
exception" (you can combine GPL and non-GPL components in a collection 
if they are not tightly bound).

Note also that I've assumed this is all in a PC, and not a rocket ship 
or a robot. Those kinds of systems would introduce other layers: 
mechanical or mechatronic components, separate electrical and plumbing 
systems, spaceframe, etc.

This strikes me as pretty intuitive for any given case, but a bit 
difficult to codify in a general way.  If there is a generic way to 
codify it, it's probably with the language of systems engineering: 
"sub-systems" and "systems".   However, it's important to realize that 
the interface points between different sub-systems in a system, and the 
line between separate sub-systems and separate systems is vague and 
tends to be decided on a system-by-system case by engineers. Our PC 
example is relatively clear-cut, because it's already such a heavily 
system-engineered, highly commoditized product.

In the software world, the biggest ambiguity is probably the issue of 
shared libraries, and this is why there is an LGPL.  The new LGPLv3 
arises as a simple extension of the new GPLv3, though, suggesting the 
possibility that GPLv3's extension language might be powerful enough to 
define hardware-applicable terms without having to break GPL 
compatibility (which would be handy, because, e.g. Open Cores already 
has lots of stuff available under the existing GPL).

Have I mentioned I wrote a seven article series in Free Software 
Magazine on this topic? Articles 1 and 6 are probably particularly 
relevant to the licensing question:

http://www.freesoftwaremagazine.com/articles/free_matter_economy
    (this includes a section on the "layers of freedom" or "platform" issue)

http://www.freesoftwaremagazine.com/articles/free_matter_economy_6
    (this is about general legal problems associated with free-licensed 
hardware)

Cheers,
Terry

-- 
Terry Hancock (hancock at AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com