[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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