Re: [ng-spice] new guy: licensing issues
> > Since we compile Spice into a library and then compile this into the
>commercial
> > version of our software, a straight GPL license will not work for us.
>Instead,
> > we would need a LGPL version of the software or the option to purchase a
> > separate commercial license.
>
> I suppose that the 'library' spice is called by some graphical front-end?
Currently, the spice library is called inside an optimization loop which is
driven by a GUI at a higher level. The same type of thing is done by several
other companies who specialize in Optimization (as opposed to synthesis) such
as Spice Opus found at "http://fides.fe.uni-lj.si/spice/" (they say they spent
a year cleaning up memory leaks in Spice; I hacked together a set of memory
management routines in a few days).
> I understand your point of view , but is the calling of a binary instead
> of loading a library such a overhead?
It depends on the size of the netlist, the size of the circuit, the type of
analyses, and the number of output points etc. For small circuits which are
quick to simulate, the overhead of netlist parsing, file output, and input
parsing is very significant. We also hijiack the spice output routines so
that output data gets written into a struct rather than going to file. We get
speedups of 30-40 on some of these circuits. For large circuits, the
simulation time dominates and running a separate binary is not an issue. The
other advantage a library form gives you is the ability to do things such as
modify circuit/model parameters without having to reparse the entire netlist.
It is also somewhat cleaner since a single binary can be shipped to the
customer.
> One solution would be to make a modular
> design (which we plan to do) so that the binary is minimal for you.
This would be very helpful in running a separate binary.
> Licensing ng-spice under LGPL rather than GPL would solve that problem of
> course.
This is one of the options that we were hoping for. However, we realize that
this project is under the gEDA umbrella which is meant to be a suite of GPL
tools. Am I right in my understanding that you are using the standard BSD
license currently and moving to a GPL license on the new, unnamed simulator?
Since the rewritten simulator is still quite a ways off, the current
development tree of ng-spice-rework is only of interest at this point. If the
BSD license stays on this, then there is no issue anyway. We would still be
wiling to make code contributions if they overlap with your own efforts.
Would your development team be interested in maintaining a
library version of ng-spice as well. Other engineers may
find this version of ng-spice useful since "simulator-in-the-loop"
optimization is becoming increasingly popular. As a last resort, or if the
performance is good enough, running a separate binary is still a possibility
for our own company.
> However , note that we also plan to use the GNU Scientific Library which
> is GPL - I haven't really thought about it, but I'm not sure we can link
> an LGPL program on a GPL library (funny situation - it should be the
>reverse:
> the simulator being GPL and the library LGPL)
I think you're right: using a GPL library would force ng-spice to be GPL as
well. Are there plans to incorporate GSL into the current development tree as
well as the new simulator?
BTW, I am on the devel mailing list as well if this discussion would be better
suited to that audience.?.
Reid
Partial thread listing:
- Re: [ng-spice] new guy: licensing issues, (continued)