[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC
On Mon, 10 Sep 2001, Michael Riepe wrote:
> 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.
How about thinking of IPs as programs? When I run a program
on an OS, the GPL license does not affect other programs that
run on the same OS. When one runs the F-CPU IP on a chip how
can it then affect the other IPs on the chip? Just imagine some
kind of a loadable cpu core if you think this is to far ahead.
If you now think of the other IPs being the 'operating system'
to run the F-CPU IP you are on my view.
> 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.
:-) There still is a difference. Otherwise there would be a
meta language where you can write your application and decide
later what to put in hardware and what to put in software.
That meta language would be a very interesting project...
To unsubscribe, send an e-mail to firstname.lastname@example.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/