[okfn-discuss] [ohf-licenses] [open-hw] Classification of openhardware

Wed May 14 02:00:52 UTC 2008

On Tue, May 13, 2008 at 9:34 PM, Jonathan Gray <jonathan.gray at okfn.org> wrote:
> Thanks Greg - this is very helpful!
>
>  Apart from questions of the optimum license for open hardware designs,
>  instructions, specifications etc. - I wonder what list members think of
>  the notion of a 'definition' of open hardware which would give criteria
>  for which licenses (or other legal tools) count as such. This would be
>  much like the Open Source Definition, or the Free Software Definition.
>
>  I suspect if we are largely talking about material that is
>  copyrightable, then our Open Knowledge Definition should be adequate for
>  this purpose - if consensus is reached in the open hardware community.
>
>
>    http://opendefinition.org/1.0
>
>  (Note, for example, the acceptability of Attribution and Sharealike
>  provisions, and the unacceptability of restrictions on certain kinds of
>  re-use, e.g. commercial use or making derivative works.)
>
>  Perhaps we might make make a further document which is more specific to
>  open hardware - specifying what we mean by this, and detailing any
>  further hardware specific points that are not covered in the OKD.
>
>  We've done something a little bit like this in our Open Service
>  Definition - a deliberately very minimal definition of an open service,
>  for SaaS (Software as a Service).
>
>  The Open Knowledge Foundation would be very happy to host and/or mirror
>  any work of this nature. That's what we're here for!
>
>  An open hardware definition could be useful as different groups or
>  individuals might favour slightly different licenses, or may want to
>  create their own. While license proliferation is something that we
>  probably do not want to encourage - presumably a certain amount of
>  choice is a good thing, rather that prescribing a single license. In
>  which case it might be good to have something like a standard.
>
>  What do people think?

My first thought is to ask someone from Sun Microsystems to comment.
They have open sourced a chip and have put thought into the matter. Maybe
Bill Vass http://blogs.sun.com/BVass/ could comment or provide a reference.
I think the rough idea is that the schematics (eg, those submitted
with the patent) would
have to be open source documents. I could be wrong though. This doesn't stop
them from patenting the device, so it really seems to me that an open
source hardware license
is a much different legal instrument. If you have GPL'd software then
someone can modify
it and redistribute under the GPL. You can license your hardware "open source"
but it seems to me that modifying it, making your own version, and
redistributing could
violate a patent. I'm not a lawyer and really don't know, but I'd be
happy to be corrected
on this point.

>
>  Warm regards,
>
>  Jonathan
>
>
>
>  Greg London wrote:
>  >> Frederic Renet wrote:
>  >>> And more generally how do we define open hardware ?
>  >> I've also been wondering about this.
>  >
>  > I think open hardware would center around any works which fall under
>  > copyright law, which describe and specify something which could be built
>  > as a physical device from that spec.
>  >
>  > In some cases, copyright law would apply to the spec and to the device.
>  > The simplest example would be a design for some hardware core which then
>  > got implemented in a Xilinx FPGA, and that FPGA was programmed via a
>  > compiled bitstream.
>  >
>  > The physical device operates directly off of the copyright work. The
>  > bistream is a derivative of the spec, so if the spec were protected under
>  > some copyleft license, then the bitstream would be protected the same way.
>  >
>  > The problem is, in the above example, you can take the design and convert
>  > it into an ASIC design instead of an FPGA. And that ASIC is nothing but
>  > functional bits, semiconductors and wires. And that ASIC is no longer a
>  > copyright derivative of the spec.
>  >
>  > So someone could take the original work, improve it, keep the improvements
>  > private, sell ASIC's containing those improvements, and a license such as
>  > the GNU-GPL would not be able to protect the community because the
>  > copyleft aspect of GNU-GPL is triggered only when the derivative is
>  > distributed. And an ASIC is not a distribution as far as copyright is
>  > concerned.
>  >
>  > The solution seems to be to adapt a copyleft licene which applies to all
>  > derivatives, distributed or not. This means that private derivatives are
>  > not allowed. But it also means that the private derivative that comes from
>  > someone distributing only an ASIC will still require that person to make
>  > their derivative available to the community who provided the original.
>  >
>  > It turns out there is a license that does this.
>  >
>  > The Apple Open license.
>  >
>  > It was designed for software and it was designed to close a specific
>  > loophole in GNU-GPL. Websites could take GNU-GPL software, modify it, use
>  > that modified software to host their website, and not actually distribute
>  > the software. Because they didn't distribute, they didn't have to make
>  > their changes public. So the Apple license closes this loophole by saying
>  > all derivatives must be made public, whether you distribte those
>  > derivatives or not.
>  >
>  > The one other caveat, then, would be that the Apple license would apply to
>  > the work, and to any thing into which it was compiled. Based on the way
>  > hardware works, this would be problematic, since as soon as someone pulled
>  > in a Free Hardware Fifo, the copyleft aspect of "derivative" would infect
>  > the entire chip, which would mean that most manufacturers would likely
>  > never use free hardware.
>  >
>  > To address this, I proposed that Open Hardware would use the Apple license
>  > but that the definition of "derivative" which would trigger the copyleft
>  > aspect of the license and the making-public of those  derivatives would be
>  > limited to whatever hierarchical level of the design as it exists, and
>  > down.
>  >
>  > If you instantiate an Open Hardware fifo in your design, then your design
>  > is not a derivative and does not need to be made public.
>  >
>  > If you modify the fifo design and then instantiate it in your chip, then
>  > you have to make the modificatiosn to the fifo public.
>  >
>  > An interesting side effect of this license approach is that the actual
>  > definition of what is and is not Open Hardware becomes less important.
>  >
>  > The license protects copyrighted works, and if those copyrighted works are
>  > modified, they must be made public. It becomes little different than using
>  > the Apple license to protect software or fiction or any other written work
>  > protectted by copyright law.
>  >
>  > The Open Hardware license could conceivably be used to protect software.
>  > Or to protect an ASIC design. Or to protect a design for a jet pack. Or to
>  > protect a novel. Or to protect whatever that will fall under copyright
>  > law.
>  >
>  > It just happens to be a license that specifically will protect hardware,
>  > but it does so without requiring any specific definition of what
>  > "Hardware" is.
>  >
>  > Greg
>  >
>  >
>  >
>  > _______________________________________________
>  > ohf-licenses mailing list
>  > ohf-licenses at openhardwarefoundation.org
>  > http://mail.openhardwarefoundation.org/mailman/listinfo/ohf-licenses_openhardwarefoundation.org
>
>
>
>
>  _______________________________________________
>  okfn-discuss mailing list
>  okfn-discuss at lists.okfn.org
>  http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss
>