[oc] GNU LGPL license

[Damjan Lampret <lampret@opencores.org>]

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