Re: Re: [oc] GNU LGPL license

["Jim Dempsey" <tapedisk@ameritech.net>]

My former reply was in regards to using a "GNU" runtime library for use by
an embedded processor within your applicaton.

In regards to creating a GNU LGPL-like statement for use by opencores
projects you could include clauses similar to

n) Works that include cores obtained from opencores, but not modified
require disclosure that said core was used and referecence to original art
being used (e.g. adder123 v ab.cd  www.pencores.org ...)

o) Derivative cores are described as modifications, no matter how trivial,
to cores obtained from opencores.org. You are permitted to freely create
derivative cores but not use them for comercial purpose until after
submission of the derivative core back to opencores.org

Add the usual weasel words...

I do have a concern about what happens if someone submits a derivative core
back to opencores.org and that the changes includes patented, copyrighted,
stolen, or other like pieces of intellectual property. Is there somewhere an
equivilent to "bans" or "Public Notices" in newspapers wherein the changes
can be openly disclosed?

Jim Dempsey



----- Original Message -----
From: "Damjan Lampret" <lampret@opencores.org>
To: <cores@opencores.org>
Sent: Friday, April 26, 2002 3:42 AM
Subject: Re: Re: [oc] GNU LGPL license


> My personal opinion is that authors seriously trying to get their open
cores into proprietary systems should not ask the company to open the rest
of their system just because their open core is used in a system. Such
extreme might work for software, but not for hardware (maybe in the future
with new technologies).
> On the other hand the licensing of a open core should be such that asks
the company to provide any improvements of the open core back to the
community. I thought GNU LGPL is exactly the right license (or1200 uses it).
After discussion with Victor I now know that GNU LGPL causes a serious
problem for the companies because the netlist should be open (as per GNU
LGPL section 5). I agree with John Dalton that we should not have tens of
different licenses, but unfortunately I haven't been able to find a license
that would both make an open core free and at the same time require changes
to get back to the community. I checked the BSD license, and it would only
make an open core free and not require any changes to come back to the
community. I checked the GNU page John suggested and GNU LGPL is the closest
to want I'd like from a license. Now what? Should we modify GNU LGPL to
better fit hardware?
>
> regards,
> Damjan
>
> On 26 Apr 2002 06:39 CET you wrote:
>
> > 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
>
>

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