[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [openip] Possible problem with LGPL - advice ?
I am not a legal advisor so what I am saying here are purely opinion.
I have two answers. The short one say that should not be a problem. The
long one say that LGPL cannot be used on cores. So legally, opencores'
cores might be unprotected so we need to catch up and fix that. Design
and Documentation have a different licensing model. Cores should too.
My short answer:
> The terms in the LPGPL (see below) state that the end user must be able
> to replace the core (library) by another version. In the case of an ASIC
> production this would imply that either the synthesized netlist or the
> post-layout files for the whole chip should be provided free of charge.
I see nowhere in LGPL (I still searching for) saying "free of charge". It
is a misconcpetion of free software that free software is free (huh?).
Free as in "libre" not free like free beer. (ah!)
http://www.gnu.org/philosophy/free-sw.html
The closest thing I see is in 6c.
<< 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.>>
Which is a choice out of five of how to apply freedom to software.
And the cost of distribution (i.e. create a new asic) is quite high for a
customer. But, if he absolutly wants it, how it is a problem for you?
It is not free beer...
My long answer, a lecture of LGPL 2.1:
<< 0. This License Agreement applies to any software library or other
program which contains a notice placed by the copyright holder or other
authorized party saying it may be distributed under the terms of this
Lesser General Public License (also called "this License"). Each licensee
is addressed as "you". >>
Cores are not software library neither program. Cores are cores!
LGPL cannot be used for cores. That is my opinion.
<< A "library" means a collection of software functions and/or data
prepared so as to be conveniently linked with application programs (which
use some of those functions and data) to form executables. >>
Cores are not a collection of software functions and/or software data and
cores cannot be linked with application programs. Cores are not software!
Cores aren't use to form executables.
Chapter 1. is about distribution of source code.
Chapter 2. is about modification of LGPL source.
Chapter 3. is about "upgrading" to GPL.
Chapter 4. is about distribution of the "compiled" version.
<< 4. You may copy and distribute the Library (or a portion or derivative
of it, under Section 2) in object code or executable form under the terms
of Sections 1 and 2 above provided that you accompany it with the complete
corresponding machine-readable source code, which must be distributed
under the terms of Sections 1 and 2 above on a medium customarily used for
software interchange.
If distribution of object code is made by offering access to copy from
a designated place, then offering equivalent access to copy the source
code from the same place satisfies the requirement to distribute the
source code, even though third parties are not compelled to copy the
source along with the object code. >>
Again, cores aren't libraries or object code that can be compiled and
linked to obtain an executable. Cores are cores that are synthesized and
routed into a circuit (layout, netlist...)
But let's say it aint so. What I am reading is your customer (and only
your customer) must be able to get the LGPL source you used. If you
didn't modify it. It is still available through opencores.org.
Chapter 5.
<< 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. >>
So you can sell this part. (plus the work of integration)
<< 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. >>
We are going to cover that later.
<< When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not. Whether
this is true is especially significant if the work can be linked without
the Library, or if the work is itself a library. The threshold for this to
be true is not precisely defined by law. >>
Nice to know. (And we are still in the software world!)
Chapter 6 is about "work that use the Library"
So it apply only to software library ??
<< 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.
You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License. You must supply a copy of this License. If the work during
execution displays copyright notices, you must include the copyright
notice for the Library among them, as well as a reference directing the
user to the copy of this License. Also, you must do one of these things:>>
Assuming that we accept cores as libraries. That can be a problem. But
not impossible to solve.
Note the "must do ***ONE*** of these things:".
<< * 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.) >>
Doesn't apply unless (we considere cores are libraries and) you deliver
the source of your work to your client.
<< # 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. >>
Simply impossible since cores aren't libraries.
<< # 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.>>
ok. no problem except the fact that 6a cannot apply.
<< # 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. >>
Feasible depending of the definition you give to "materials".
<< * e) Verify that the user has already received a copy of these
materials or that you have already sent this user a copy. >>
I am not sure I understand this one. Still related to definition of
"materials".
<< For an executable, ... >>
Doesn't apply, not an executable.
Chapter 7 to 16. Usual rules fully applicable to cores without problems.
(Well, I think so.)
Conclusion:
We need a CGPL : Core General Public License or something similar. An
Open Source Licence that will fit the spirit of opencores.org. For sure
we handle source code but not library files nor object files nor
executables.
Also, the definition of a end-user isn't well defined for cores. Is the
end-user the guy that use the produced chip or the end-user is the one
that use the "software" i.e. that use the core to create a chip. This
will lead to a totally different lecture of LGPL. In that case, once it
is "burned" into an asic it is like usage of the software. You might use
GCC to compile code. Compiled code by by GCC aren't GPL.
Bonne chance!
Richard <today's devil's advocate/>
Sorry for my bad english.
On Fri, 21 Feb 2003, MikeJ wrote:
> Hi Chaps.
>
> I have received an email from someone who wishes to use an opencores core,
> but has pointed out some problems with the LGPL that many of us to
> distribute our hardware cores.
>
> advice ??
> cheers.
> MikeJ
>
>
> The terms in the LPGPL (see below) state that the end user must be able
> to replace the core (library) by another version. In the case of an ASIC
> production this would imply that either the synthesized netlist or the
> post-layout files for the whole chip should be provided free of charge.
>
> This is unacceptable. I would hope the idea behind the open cores would
> be that any changes made to the cores _themselves_ would have to be
> released. But releasing the whole ASIC project (of which the controller
> core would only be a tiny part) makes use of this type of core in any
> sort of commercial project impossible (and together with it the benefits
> of having commercial developers improve the core and release the changes
> will disappear).
>
> Is there any chance of providing an exception to those terms? Something
> like:
>
> This library is free software; you can distribute it and/or modify it
> under the terms of the GNU Lesser General Public License as published by
> the Free Software Foundation; either version 2.1 of the License, or (at
> your option) any later version. However, as an exception to section 6 of
> the GNU Lesser General Public License, you are allowed to provide the
> "work that uses the Library" in a form (e.g. hardware) that does not
> give the user the possibility to replace the Library with a modified
> version.
>
> If not I'm afraid I will have to scrap your core (like all LGPL-licensed
> cores) from my evaluation for inclusion in a future ASIC.
>
>
> --
> To unsubscribe from openip mailing list please visit http://www.opencores.org/mailinglists.shtml
>
--------------------------------------------------------------------------
1024D/BEF5DD36 Richard Prescott <rip@step.polymtl.ca>
Key fingerprint = E11B E939 8A1D 2FA8 A672 555F ABA8 DE5A BEF5 DD36
--
To unsubscribe from openip mailing list please visit http://www.opencores.org/mailinglists.shtml