[Gnucap-devel] licenses, plugins, output and nodeset

[Felix Salfelder]

On Fri, Jul 19, 2019 at 11:55:26AM +0200, somebody wrote:
>  There is no problem for me/us relating to GNU, especially in the way GNUcap
> functions: if it is possible to preserve some other licences behind the
> plugins for device models, then we should be protected enough.

In technical terms (but somewhat simplified), our license demands that
you provide the source code of binaries you distribute, if they contain
new code derived from code that you have obtained under that license.
And also, you must make available that new code under the same license.

On the other hand, ther is no need to distribute binaries containing
such things, in order to have your customers use gnucap together with
your own extensions. basically, your extensions can be as closed as you
need them to be. A practical example are the "spice-models" [1].

I am not a lawyer, and I am not getting into the details here. If you
need more authoritative advice or more explicit permission, please ask
Al.

> I suppose that any changes we make in the core, to the parser or the
> time stepping are not so sensitive; we can publish them or send the
> patches to you. What will eventually be sensitive is our application,
> but that is completely outside the scope of the source code licence,
> so it's OK.

As long as there is a clear line between your application and gnucap, I
do not see any serious problems.

Publishing patches is a start. Depending on what changes you have in
mind (especially to the core), it might be useful to keep in touch.
maintaining a fork can be a real pain.

> We might however want to support different output waveform formats.
> How far is the output-plugin system ?

The output rework basically works, requires testing. It would be good to
know if it meets your potential requirements, and/or if it needs
relevant changes before it can be merged. Ultimately Al will have to
decide.

>  I know for a fact that nodeset on the capacitors is enough for our modeling
> purpose in spectre, hspice, and hsim. But we have with these spices other
> issues, relating for example to the use of Newton-Raphson, issues which may
> or may not be better handled by GNUcap. We may indeed have to do more than
> nodeset and add some other methods of DC, in that case it will be OK for us
> to workaround it at first, by loading for example a bunch of nodesets coming
> from the DC of another simulator. So we are back to only that feature
> request as first step.

the nodeset example is now included with gnucap-python 0.0.4 [2] and is
mostly working. i did not try to make it either feature complete nor
semantically compatible to any other simulator. Testing might help...

Anything that does not require core modifications could well go into
either gnucap-python or gnucap-custom [3], depending on the language
preference. There is potentially useful stuff in other repositories i
have no time to maintain any more.

cheers
felix

[1] https://git.savannah.gnu.org/cgit/gnucap/gnucap-models.git/log/
[2] https://codeberg.org/gnucap/gnucap-python
[3] https://codeberg.org/gnucap/gnucap-custom