[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Hardware licensing (fwd)



[forwarded by so discussion can continue on the list]


Forwarded message:
> From pmaupin@jump.net  Sun Oct  8 01:06:15 2000
> Message-ID: <39E00113.DD0F793B@jump.net>
> Date: Sun, 08 Oct 2000 00:07:31 -0500
> From: Patrick Maupin <pmaupin@jump.net>
> X-Mailer: Mozilla 4.5 [en]C-CCK-MCD compaq  (Win98; U)
> X-Accept-Language: en
> MIME-Version: 1.0
> To: graham@opencollector.org, rms@gnu.org
> Subject: Hardware licensing
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> Dear sirs:
> 
> I have been following (how well, I don't know) the
> hardlicense mailing list.  I was particularly interested
> in the discussion about the non-protectability of a
> hardware embodiment of a circuit.  I _think_ I
> understand this distinction reasonably well, but
> given certain assumptions (which may or may not
> be true), I think perhaps there is a way to use
> copyright law to offer some protection despite
> this weakness.  I outline this possibility below.
> 
> As Mr. Stallman points out, a weakness in any
> copyright-based license, whether for hardware or
> software, is that if someone cares enough to
> reimplement a design, there is no real protection.
> This is not necessarily a big deal, since a major
> project such as GCC or GNU/Linux is not in any
> danger of a closed-source reimplementation happening.
> There certainly exists the possiblity for a collection
> of hardware modules to reach this same critical
> mass, assuming a few things like the licensing
> issues are dealt with.
> 
> So we concentrate on the case where a manufacturer
> is trying to use, e.g. our free verilog source code to
> make a proprietary chip without giving the proper
> concessions to the verilog author. At first glance, since
> the circuitry embodied on the actual chip is not subject
> to copyright, it might appear to be a lost cause.
> 
> However, the path from verilog to chip is not direct.
> There are, of necessity, a lot of intermediate steps.
> These intermediate steps, by definition, create derived
> works from our free verilog.
> 
> This is where the assumption comes in.  IANAL, but
> if object code and executables are subject to copyright,
> it seems to me that an EDIF file, a GDS-II file, or other
> intangible representation mechanically (or partially
> mechanically) derived from the verilog might also be
> subject to copyright.
> 
> If this assumption holds true, maybe it gives us some
> leverage in the license.  I have always felt that term 5
> of the GPL ("You are not required to accept this License,
> since you have not signed it. However, nothing else
> grants you permission to modify or distribute the Program
> or its derivative works.") is a work of pure genius.
> 
> If the act of compiling the verilog, e.g. to an EDIF file, is
> a modification of our copyrighted work (or perhaps the
> creation of a derivative work), then maybe we can insert
> a similar "hook" into our hardware license.  In layman's
> terms:  "You do not have permission to mechanically
> convert this verilog into an intermediate representation
> unless you agree to the terms of this license."
> 
> The terms of the license, of course, include whatever
> restrictions on linking with non-free hardware, disclosures
> about pinouts and processes, etc., desired by the
> hardware author.
> 
> Obviously, this is a gross simplification, but I wanted to
> get your opinions on this before I devoted too much
> thought to the issue.
> 
> Thanks,
> Pat Maupin
> 
>