Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC

[Michael Riepe <Michael.Riepe@stud.uni-hannover.de>]

On Mon, Sep 10, 2001 at 12:08:38PM +0200, Juergen Goeritz wrote:
[...]
> P.S. In my opinion the GPL license has a big drawback when
> you add own components on the netlist level. My standpoint
> is that this is the weak point. A netlist is comparable to
> '.o' files or libraries (vendor macro instantiations like
> gates are connected to each other in the netlist). Good
> people can write and modify netlists directly. Netlists
> mostly are produced by proprietary tools, e.g. synthesis.

One can also modify .o/.a/.so or executable files directly (I've done
that several times), but they still don't qualify as `source code'.
Whether .o files are generated with a free compiler/assembler or a
proprietary toolchain doesn't matter at all.

> When you follow this thought you end up with a system
> around the f-cpu that is completely outside the license
> coverage because libraries and operating systems (or the
> chip - in my thought) are not covered.

Quoting from the GPL (section 3):

	The source code for a work means the preferred form of the work for
	making modifications to it.  For an executable work, complete source
	code means all the source code for all modules it contains, plus any
	associated interface definition files, plus the scripts used to
	control compilation and installation of the executable.  However, as a
	special exception, the source code distributed need not include
	anything that is normally distributed (in either source or binary
	form) with the major components (compiler, kernel, and so on) of the
	operating system on which the executable runs, unless that component
	itself accompanies the executable.

The `preferred form of the work for making modifications' is the
high-level VHDL (Verilog, other HDL...) source, not the netlist (which
is a translated form).  Changes at the netlist level are not allowed
because they will be lost when a new netlist is generated from the
high-level source.

The phrase `all the source code for all modules it contains' means that
the high-level source for *all* components of the SoC must be released.

Vendor-specific gate libraries shall fall under the `special exception'
rule, since they are `normally distributed with the major components
(compiler, ...) of the operating system', that is, the synthesis tools
and/or the manufacturing process.

If interpreted in a certain way, the GPL makes sense for Free Hardware,
too.  After all, modern hardware and software development don't differ
much, and the borderline between them is moving.  You can implement most
(if not all) algorithms entirely in hardware (fast) or software that
runs on a `generic' processor (cheap), or use a mixed approach (e.g. a
hardware coprocessor for timing-critical parts).  More recent research
deals with reconfigurable computers that may be able to `compile', `load'
and `run' a `program' written in any language (including VHDL/Verilog),
or with the automated design of application-specific CPUs (plus matching
compilers) on the basis of ordinary (software) programs (see MOVE).

From a more global (visionary? crazy?) point of view, there is no
fundamental difference between hard- and software development; they use
different terminologies (for historical reasons, I guess), but they both
serve the same purpose: implementation of an algorithm.

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/