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