Re: Re: [oc] GNU LGPL license

[Scott Zuk <szuk@telusplanet.net>]

I don't know if you've heard of the LART project, but they distribute their 
schematics under their own license.  It might be a little too free for 
opencores though...

LART project:  http://www.lart.tudelft.nl/
License:  http://www.lart.tudelft.nl/LICENSE

~Scott

On April 26, 2002 05:42 am, you wrote:
> 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