Re: [oc] GNU LGPL license

["Jeff Hanoch" <jeff@hanochnet.org>]

Hi all,

This is an eye-opening thread.  I have been seriously looking for a way to
use the or1200 in one of my companies ASICs.  However, after reading this, I
fear that there is no way my company's management would allow me to use it.
We manufacture high-volume consumer electronics products.  We compete in a
very cut-throat environment which in the past, competitors have copied our
designs and gone into production competing against us.  They went so far as
to use the same reference designators and component values of  the
electronic components on their circuit board.  I am quite sure that our
management would promptly crush any hopes I have of using any of these cores
if it means that we may have to provide source code for any of the
non-Opencores cores to anyone who asks.  This would be unacceptable.

I support whole-heartedly the concept of open-source, but I feel for it to
succeed and gain wide-spread use among business, there needs to be some
protection for a company's own ip.  My company has spent millions of $$$
developing it's own proprietary ASIC designs and does not want to give that
to our competitors upon their asking.  Is there something we can change to
make it such that only the Opencores cores and only changes specifically to
the particular core would have to be divulged without requiring the whole
design to be released?

Regards,
Jeff Hanoch


----- Original Message -----
From: "Damjan Lampret" <lampret@opencores.org>
To: <cores@opencores.org>
Sent: Thursday, April 25, 2002 6:08 AM
Subject: [oc] GNU LGPL license


> Folks !
>
> I thought that GNU LGPL will not cause any problems for a company that
> want to use a particular OpenCores IP block in their system. Apparently
> this might not be the case as you can see below. Any comments? What
> should we do to encourage companies to use our IP cores w/o forcing them
> to open the rest of their system just because we might use GNU LGPL?
> Maybe we should use modified GNU LGPL license? Different license?
>
> regards,
> Damjan
>
> > Damjan,
> >
> > I was indeed referring to the LGPL. Here's the problematic part of it:
>
> > 5. A program that contains no derivative of any portion of the
> Library,
> but
> > is designed to work with the Library by being compiled or linked with
> it,
> is
> > called a "work that uses the Library". Such a work, in isolation, is
> not a
> > derivative work of the Library, and therefore falls outside the scope
> of
> > this License.
> >
> > However, linking a "work that uses the Library" with the Library
> creates
> an
> > executable that is a derivative of the Library (because it contains
> portions
> > of the Library), rather than a "work that uses the library". The
> executable
> > is therefore covered by this License. Section 6 states terms for
> > distribution of such executables.
> >
> > And then, Section 6 says:
> >
> > 6. As an exception to the Sections above, you may also combine or link
> a
> > "work that uses the Library" with the Library to produce a work
> containing
> > portions of the Library, and distribute that work under terms of your
> > choice, provided that the terms permit modification of the work for
> the
> > customer's own use and reverse engineering for debugging such
> modifications.
> > ... Also, you must do one of these things:
> >
> >
> > a.. a) Accompany the work with the complete corresponding
> machine-readable
> > source code for the Library including whatever changes were used in
> the
> work
> > (which must be distributed under Sections 1 and 2 above); and, if the
> work
> > is an executable linked with the Library, with the complete
> machine-readable
> > "work that uses the Library", as object code and/or source code, so
> that
> the
> > user can modify the Library and then relink to produce a modified
> executable
> > containing the modified Library. (It is understood that the user who
> changes
> > the contents of definitions files in the Library will not necessarily
> be
> > able to recompile the application to use the modified definitions.)
> > b.. b) Use a suitable shared library mechanism for linking with the
> > Library. A suitable mechanism is one that (1) uses at run time a copy
> of
> the
> > library already present on the user's computer system, rather than
> copying
> > library functions into the executable, and (2) will operate properly
> with
> a
> > modified version of the library, if the user installs one, as long as
> the
> > modified version is interface-compatible with the version that the
> work
> was
> > made with.
> > c.. c) Accompany the work with a written offer, valid for at least
> three
> > years, to give the same user the materials specified in Subsection 6a,
>
> > above, for a charge no more than the cost of performing this
> distribution.
> > d.. d) If distribution of the work is made by offering access to copy
> from
> > a designated place, offer equivalent access to copy the above
> specified
> > materials from the same place.
> > e.. e) Verify that the user has already received a copy of these
> materials
> > or that you have already sent this user a copy.
> > For an executable, the required form of the "work that uses the
> Library"
> > must include any data and utility programs needed for reproducing the
> > executable from it. However, as a special exception, the materials to
> be
> > 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.
> >
> > 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.
> >
> > In the case of software, the LGPL can indeed be circumvented by
> dynamically
> > linking the Library (Section 6b), 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.
> >
> > Victor
>
> --
> To unsubscribe from cores mailing list please visit
> http://www.opencores.org/mailinglists.shtml
>

--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml