Re: [oc] GNU LGPL license

["Marko Mlinar" <markom@opencores.org>]

I like the solution.
I think the license naming is also important. It should hear something like
'GPL' or 'LGPL' -- it sounds more free.

Marko

----- Original Message -----
From: "Richard Herveille" <richard@asics.ws>
To: <cores@opencores.org>
Sent: Friday, April 26, 2002 10:34 AM
Subject: Re: [oc] GNU LGPL license


>
> Seems like this is a real problem.
>
> One way of solving this would be to use LGPL, but add an addendum to the
> license. In such an addendum you can overrule any previously made claims.
For
> example insurance companies do this all the time. They have a basic
agreement
> which covers the insurance, but on your personal insurance paper they make
> adjustments to the basic agreement.
>
> If we add an addendum, it should state that: "As an exception to sections
5
> and 6 of the LGPL License, any company using OpenSource hardware projects
is
> not obliged to return any non-OpenSource hardware code for whatever reason
in
> whatever format, so as to protect the companies Intellectual Property
> investments. "
>
> We really need to read these lines a few times, to figure out if we
covered
> everything (and every section). But I think this should work.
>
> Richard
>
>
>
> > 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
>

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