[oc] Re: GNU LGPL license

[Andreas Bombe <bombe@informatik.tu-muenchen.de>]

On Thu, Apr 25, 2002 at 11:08:06AM +0100, someone forwarded by
Damjan Lampret wrote:

> > If using one of the OpenCores in our design, and then synthesizing 
> > everything is equivalent to "linking the work that uses the Library with 
> the 
> > Library", then we're obliged to share the sources of the whole synthesized 
> > netlist with the rest of the world. 

That would be a requirement of the full GPL.  But let's see:

> > In the case of software, the LGPL can indeed be circumvented by
> > dynamically linking the Library (Section 6b),

Bad choice of words.  That's not circumvention but what the LGPL is
intended for.

> > but there's no corresponding "dynamic link library" in the case of
> > hardware description cores. I believe that it's possible to
> > interpret the usage of OpenCores functional blocks in a design as a
> > "static link", thus contaminating ALL developed IP in the design by
> > the LGPL. 

In essence, the LGPL can be summarized as such:

1. The LGPL library, for which alone pretty much the GPL rules apply (on
   distribution source code has to be made available under the same
   license with no additional restrictions).

2. The library using program can have any license which doesn't clash
   with the LGPL licensed part (so e.g. no NDAs which also cover the
   library).

3. The user must be able to replace the included LGPL library with a
   different version.

It is correct that dynamically linking to a LGPL library automatically
takes care of the last requirement.

For statically linked executables that is also possible.  In practice
this means that in addition to the executable a binary object file
containing everything except for the library has to be provided, so that
the user can (statically) link another version of the library and
produce a new working executable.

With hardware it looks a bit different.  Let's say some SoC is
distributed in an FPGA.  Then there has to be at least a synthesized
version of the closed source parts available to which other versions of
the OC cores can be linked so that the result can be used to configure
the FPGA in stead of the original configuration.

It gets more difficult with ASICs.  I'm not that familiar with the tools
and processes used there.  However the LGPL would require that new ASICs
with replaced LGPL cores would have to be buildable.  I guess this could
be done by separating the parts on the die and having post place&route
layout available where different LGPL parts could be wired to.  Or
higher level netlists, if the vendor is comfortable with that.

The point is that the user has to be able to take the source of open
parts, compile/synthesize them and have a suitable form of the closed
part to do the final link bringing them together to form a working
product.

-- 
Andreas Bombe <bombe@informatik.tu-muenchen.de>    DSA key 0x04880A44
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml