Re: [oc] GNU LGPL license

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

If you want to comply with the GNU LGPL _and_ keep your work
private then place the GNU library code into a seperate ROM or into
an isolated area of your FLASH memory and provide instructions on
how to recode either. To keep your code isolated you would have to
specify that each GNU library function used must begin at a specified
offset. You can decide if you want to use a JUMP table or if you want
to reserve blocks for each function, or if you want to "link" at POST.
It is a little more work to setup, but once setup you won't experience
any more work in producing each revision of your code.

Jim Dempsey


----- Original Message -----
From: "Dautel, Rob" <Dautel@AllAmerican.com>
To: <cores@opencores.org>
Sent: Thursday, April 25, 2002 9:33 AM
Subject: RE: [oc] GNU LGPL license


> sure.. modify it, or use it as a template for our own. The original GNU
LGPL
> was written for software. While what we do seems to dance on this line, it
> is ultimately, hardware. It seems that there are those out there, no one
> here of course ;), who think of the LGPL as "the almighty word" but it's
> not, it's just an idea, words on paper. I'd like to think most, or at
least
> many of us here would agree that modification to the LGPL to suit what we
do
> and protect those who use our IP would be ok provided it was done
carefully
> and with no mal intent. Just as long as we are careful about this and
don't
> shoot ourselves in the foot by providing a loophole which allows someone
to
> withhold substantial IP modifications. Anyway, just my two cents. What do
> others think?
>
> -rob.
>
>
> > -----Original Message-----
> > From: Damjan Lampret [mailto:lampret@opencores.org]
> > Sent: Thursday, April 25, 2002 5:08 AM
> > To: cores@opencores.org
> > 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