model licenses

[felix-salfelder]

in the spirit of the discussion that arose from #343, i had a look at the .va files shipped with qucs-core. there are 52 .va files, 38 of which are GPL. the others are bsim (4), fbh (1) and hicum (9).

the bsim file headers claim that silvaco has released them under a free license, it doesn't say which. theres a link to a "press release", "Silvaco Offers Free Open-Source Verilog-A Device Models", which does not contain information i could identify as relevant.

the header of the fbh file is missing a license statement. however, it contains an email address. shall we ask for a free license for this model? a free license might not conflict with the intent of the author (i.e. i cannot see this conflicting with the current header).

the hicum models look particularly non-free. e.g. hicumL2V2p11.va does not contain a license statement. the hicumL2V2p31n.va header list some restrictions that don't look very free. but IANAL, so i can only say with certainty that the license situation is uncertain.

what shall we do about it? i think these models should be put into an (optional/independent) qucs-nonfree package... more urgently, they should be (temporarily?) removed from the repo, unless the license situation can be clarified soon.

[guitorri]

Concerning hicum. All the (updated?) upstream HICUM level 2 files have a copyright notice that allow copy, modification and redistribution. The files in our repository do not have that. We need to update.

I could not check the HICUM level 0 files (4 files) (need to register for access). We (me and @MikeBrinson) are in contact with the authors.

For bsim. I could not yet find the originals for bsim3 and bsim4 on the Silvaco website (see link to the press release). The bsim4 is listed here but nothing is said about the license. This repository has something related to bsim3/bsim4, it mentions LGPL, but some models and license statements are missing.

The bsim6 code (to be included) is GPL compatible: https://github.com/guitorri/qucs/blob/90552c12de707b3eee4a9b3f7951c35507557645/qucs-core/src/components/verilog/bsim6v10pMOS.va#L8-L47

The fbh is not explicit, but the author seems to be "giving the models away". The author page seems to be this, but the links to the models are broken. If that helps, Xyce have them (version 2.1 and 2.3) included.

Let us try to clarify things first. Then we see what needs to be removed.

Perhaps we should add the original source and patches. I thing I am doing it wrong with the bsim6, I added the patched files and the patches...

[felix-salfelder]

Any news?

no. i am still inclined to remove the dubious files before the .19 release. i do not know how to clarify things.

KiCad license issues too...

interesting. @timofonic do you happen to know what the KiCad people are doing about it?

NB: in the meantime, i have tried to use 3rd party .va models in qucs. it seems that it could work, so there's no real need to ship the files.

[guitorri]

All the HICUM L2 license headers have been updated. To me they seem to be compatible. See: https://www.iee.et.tu-dresden.de/iee/eb/forsch/Hicum_PD/HicumQ/hicumL2V2p33.va

//**************** COPYRIGHT NOTICE(Originator: Michael Schroter)****************
//*******************************************************************************

//The terms under which the HICUM/L2 software is provided are as follows:

//The Software is distributed as is, completely without expressed 
//or implied warranty or service support. Michael Schroter and his team 
//members are not liable for the condition or performance of the software. 

//Michael Schroter owns the copyright and grants users a perpetual, 
//irrevocable, worldwide, non-exclusive, royalty-free license with respect 
//to the software as set forth below.  

//Michael Schroter hereby disclaims all implied warranties.

//Michael Schroter grants the users the right to modify, copy, and  
//redistribute the software and documentation, both within the user's 
//organization and externally, subject to the following restrictions.

//1. The users agree not to charge for the model owner code itself but may 
//charge for additions, extensions, or support.

//2. In any product based on the software, the users agree to acknowledge 
//Michael Schroter that developed the model and software. This 
//acknowledgment shall appear in the product documentation.

//3. Users agree to obey all government restrictions governing 
//redistribution or export of the software. 

//4. The Users agree to reproduce any copyright notice which appears on 
//the software and documentation on any copy or modification of such 
//made available to others. 

The HICUM L0 are available under request (it is like this because the authors dropped support for these models). I could not check if the header was updated. In any case, I contacted the authors and they are wiling to change the licenses if necessary. They want to have the models included in QUCS.

Ins't the BSIM3/4 models also distributed with ngspice? If so, how did they get around the lack of copyright notice?

We should request permisson for the FBH HBT models:

© 2005-2014 FBH. Permission to make copies, either paper or electronic, of these files for personal or classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage and that the copies are complete and unmodified. Other distributing, publishing, or posting on servers requires prior written permission by FBH. By downloading these files, you agree that FBH shall not be held to any liability with respect to any claim by you or from any third party arising from or on account of the use of these files, regardless of the form of action, including negligence. In no event will FBH be liable for consequential or incidental damages of any nature whatsoever.

My question is how we should manage the sources. I think we should be keeping the original source and needed patches alongside. What is the usual method do apply patches? On bootstrap or during configure/make, what about CMake?

[felix-salfelder]

Thanks Guilherme for the update.

quoting from GPLv2. "In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License."

hicum says //2. In any product based on the software, the users agree to acknowledge //Michael Schroter that developed the model and software. This //acknowledgment shall appear in the product documentation.

my guess is, that "shall" (in the second sentence) actually means "must". otherwise there would be no implication, which i think is not intended.

then, if the documentation is unaffected by the hicum license (which is what the GPL demands), it can contain whatever seems to make sense (or any author thinks is appropriate), not what some model license demands. or the other way round: the (hicum) model license must only affect the (hicum) model, not other parts of other products, such as the QUCS documentation.

so no, (imo) this hicum model license is not GPL compatible (yet). i don't know what authors intend by inventing their own licenses over and over. they could just choose one of the existing, sane and safe licenses, which have been discussed already (even by nitpicks like me, but with a better legal background), and found to be compatible. find over 50 examples here.

They want to have the models included in QUCS.

this is nice, but then they should also jump the fence and stop the license headache. the only (legal) way to include models in QUCS is putting them under a (GPL) compatible license.

sorry for the noise (and the apparently bad news).

[guitorri]

I have asked at debian-legal mailing list for some advice concerning the HICUM and FBH models. https://lists.debian.org/debian-legal/2016/01/msg00013.html

[guitorri]

Things are not looking good. Please follow the thread in debian-legal.

It seems that the bsim, hicum, license stem Compact Model Coalition (CMC) recommended [1](see appendix A). Which is an issue also for older models in Ngspice [2].

Universities are releasing new models such as the HiSIM [3], which mentions open-source [4](click thru for access), but the license again seems not to be compatible with GPL.

The GPL circuit simulators projects I could check: Qucs, Ngspice, Gnucap (in gnucap-bsim) and Xyce include files with conflicting license.

Any ideas on how to approach the problem? (besides the removal of the source files)

My first idea is to summarize the problem and contact the model authors and the CMC to see if they are aware of this.

[1] https://www.si2.org/?page=1913 [2] http://sourceforge.net/p/ngspice/mailman/message/34439248/ [3] https://www.hisim.hiroshima-u.ac.jp/index.php?id=87 [4] http://home.hiroshima-u.ac.jp/usdl/HiSIM_HV/Open_Source/protect.cgi

[felix-salfelder]

thanks a lot, Guilherme.

the gap between free and just open source strikes again. i am slightly surprised that still even researchers and universities stick to the non-free licenses. but then, this only increases the pressure to find a sustainable solution...

The GPL circuit simulators projects I could check: Qucs, Ngspice, Gnucap (in gnucap-bsim) and Xyce include files with conflicting license.

(as it seems) this is not a problem for gnucap. the gnucap-bsim package is not part of the Gnucap package. and it is not meant to be distributed under the terms of the GPL.

my understanding is the following (ianal, but i did read the GPL). it is not prohibited to simulate proprietary/patented/non-free circuits with gnucap. likewise it is not forbidden to compile/use/load component/device models of any such kind. it might well be against the law to distribute binary representations of component models, but that's not what we intend to do.

if that's correct, then qucs(ator) should work in a similar way. and yes, we should check very carefully. maybe ask Al (the Gnucap author) for caveats.

Any ideas on how to approach the problem? (besides the removal of the source files)

treating component/device models as simulator input data, not as part of the simulator kernel might fix this problem.

[MikeBrinson]

Hello Guilherme I fully understand the position that you have adopted regarding Verilog-A model licences in statement #421.However, could I  point out that the the Qucs EKV v2.6 MOSFET, MESFET  and amplifier Verilog-A models I wrote from scratch without reference to the Verilog-A code from other groups.  I also placed these models under the GPL 2 licence so that all Qucs users could benefit from them.  The EKV v 2.6 and MESFET models are based on the published  model equations and the amplifier models on my published work.   Hence Qucs is entitled to distribute the source code for these models. Best wishes. Mike  Mike Brinson mbrin72043@yahoo.co.uk

  From: Guilherme Brondani Torri <notifications@github.com>

To: Qucs/qucs qucs@noreply.github.com Cc: MikeBrinson mbrin72043@yahoo.co.uk Sent: Thursday, 28 January 2016, 0:12 Subject: Re: [qucs] model licenses (#390)

See #421.— Reply to this email directly or view it on GitHub.

[felix-salfelder]

@MikeBrinson since your models are GPLd and include proper headers with license information, you should not be worried at all. (well done!).

[guitorri]

@MikeBrinson indeed, your models will be kept as they are. Later on I will invite your help to write an open letter to CMC and the model authors to check if they would consider changing to a GPL friendly license. This weekend I will talk with Wladek as well.

For the record, the ADMS package is also stuck with license issues related to the Accellera headers. See https://github.com/Qucs/ADMS/issues/35

[MikeBrinson]

Perhaps we should move to the new PYADMS?

[felix-salfelder]

Perhaps we should move to the new PYADMS?

this will not help us with the headers, except the PYADMS authors have their own (free) implementation.

and: no, we should not move. what we must do is

• let the simulator decide how to process verilog models.
• make simulators (read: drivers for simulators) interchangeable/pluggable.

[guitorri]

@MikeBrinson the https://github.com/pyadms/adms is very new, and it does not have a code generator. Even if it had one, it would take a while to port the AMDS XML scripts to a different code generator.

Going off-topic, an interesting approach would be the to have something similar to https://github.com/PyHDI/Pyverilog (or extend it). @lutherthecat might want to have a look at that.

Please continue posting ADMS related issues into its on own issue tracker.

[MikeBrinson]

Hello Felix Writing a simple, experimental, set of headers should not be thatdifficult.  It could be based on the published data in

K.S. Kundert and Olaf Zinke, "The Designer's Guide to Verilog-AMS", Kluwer Academic Publishers, Boston/Dordrecht/London, First Edition, June 2004,ISBN: 1-4020-8044-1. Mike

[guitorri]

I consider this as closed. I will communicate the model authors that we are removing their models.